No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

RSVP-TE tunnel can not be established on NE40E

Publication Date:  2012-07-27 Views:  68 Downloads:  0
Issue Description
During log checkup we found something quite worring about our RSVP-TE setup on the core ring.
Some of the RSVP-TE tunnels don't seem to have either primary or secondary path. We were unable to find any pattern to that behaviour.
In the attached spreadsheet we have a list of all tunnels defined between our devices. THe devices are connected in a loop link this:
akl-grafton-core1 -> akl-sky-core2 -> akl-sky-core1 -> akl-newton-core2 -> akl-newton-core1 -> akl-grafton-core2 -> akl-grafton-core1
columns F to P show the paths of the tunnels (column names are short versions of the devices names). As you can see some tunnels are missing.
 
Everything seems to be working correctly, but I believe that at this stage we don't have the redundancy we would like to have.
I the logs of akl-sky-core1 I found the following entries:
 
Apr 15 2008 11:59:12 akl-sky-core1 %%01RSVP/3/LOOP_PATH(l): There is a loop in PATH message(Tunnel ID=111,Egress Address=172.16.31.242).
Apr 15 2008 11:59:12 akl-sky-core1 %%01RSVP/3/LOOP_PATH(l): There is a loop in PATH message(Tunnel ID=116,Egress Address=172.16.31.254).
Apr 15 2008 11:59:12 akl-sky-core1 %%01RSVP/3/LOOP_PATH(l): There is a loop in PATH message(Tunnel ID=101,Egress Address=172.16.31.242).
Apr 15 2008 11:59:12 akl-sky-core1 %%01RSVP/3/LOOP_PATH(l): There is a loop in PATH message(Tunnel ID=119,Egress Address=172.16.31.242).
(date is 24h behind acutal time).
We seems to have more problems with akl-sky-core1. I just tried to establish 2 new RSVP-TE tunnels. To and from an NE40E in Lambie Drive (akl-ldv-core1). The tunnel from akl-ldv-core1 to akl-sky-core1 came up without any problems, but from akl-sky-core1 to akl-ldv-core1 it stays as up/down.
Alarm Information
 akl-grafton-core1 -> akl-sky-core2 -> akl-sky-core1 -> akl-newton-core2 -> akl-newton-core1 -> akl-grafton-core2 -> akl-grafton-core1
columns F to P show the paths of the tunnels (column names are short versions of the devices names). As you can see some tunnels are missing.
 
Everything seems to be working correctly, but I believe that at this stage we don't have the redundancy we would like to have.
I the logs of akl-sky-core1 I found the following entries:
 
Apr 15 2008 11:59:12 akl-sky-core1 %%01RSVP/3/LOOP_PATH(l): There is a loop in PATH message(Tunnel ID=111,Egress Address=172.16.31.242).
Apr 15 2008 11:59:12 akl-sky-core1 %%01RSVP/3/LOOP_PATH(l): There is a loop in PATH message(Tunnel ID=116,Egress Address=172.16.31.254).
Apr 15 2008 11:59:12 akl-sky-core1 %%01RSVP/3/LOOP_PATH(l): There is a loop in PATH message(Tunnel ID=101,Egress Address=172.16.31.242).
Apr 15 2008 11:59:12 akl-sky-core1 %%01RSVP/3/LOOP_PATH(l): There is a loop in PATH message(Tunnel ID=119,Egress Address=172.16.31.242).
(date is 24h behind acutal time).
Handling Process
check ip address on each equipment. delete conflict ip address on NE40E which configured in wrong way. All TE tunnel come back normally.
Root Cause
Ip address conflict in MPLS TE configured scenorio. So TE tunnel can not be established completely.
Suggestions
IP address on each interface of all core router which configure MPLS TE tunnel should be unique. Even the interface has been shut down. It still be checked by TE process of NE40E. CSPF can not calculate normally to get a tunnel to destination.
To avoid this scenario in your network environment.

END