Hey Rick, I was thinking something along those lines. Especially since I just pasted the configs all at once...not allowing things to converge in order. I noticed when I cleared OSPF on R7 the TE metric showed up as 10. Then I just rebooted all the routers and now all the TE metrics are showing up proper. Lesson learned: be patient and reboot :)
On Sun, Sep 20, 2009 at 8:44 AM, Rick Mur <[email protected]> wrote: > Are you sure that the IGP was converged before the tunnels tried to start > determining their path.I can imagine that when RSVP tells the tunnel that > everything is fine and IGP is not fully converged this would happen. > > Try loading those configs again, but with the tunnels shutdown. Then no > shut them as the IGP is converged. > > I told this a few times, but MPLS features like TE and CsC can be a bit > buggy in IOS 12.2S (12.0S is way better) and not function 100%. So the order > in which you enter the commands can be important as processes can hang > sometimes if you don't do it in the right way :-) > > -- > > Regards, > > Rick Mur > CCIE2 #21946 (R&S / Service Provider) > Sr. Support Engineer – IPexpert, Inc. > URL: http://www.IPexpert.com > > On 20 sep 2009, at 15:46, Bryan Bartik wrote: > > Hello, > > I was troubleshooting an MPLS inter-area tunnel that was working fine > yesterday. I loaded my saved configs this morning and the tunnels were down. > The topology is as follows: > > R7---R6 = area 876 > R7---R8 = area 876 > R8---R6 = area 0 > > Basically a full mesh of 3 routers with the R6/R8 link in area 0. R6/R8 > loopbacks are in area 0 as well. There is an explicit tunnel from R7 that > goes through R6 on towards R8. The tunnel is configured with an explicit > path: > > R7#sho run int tun 78 > interface Tunnel78 > ip unnumbered Loopback0 > tunnel destination 6.7.8.8 > tunnel mode mpls traffic-eng > tunnel mpls traffic-eng path-option 1 explicit name R7-R8 > > R7#sho ip explicit-paths > PATH R7-R8 (loose source route, path complete, generation 4) > 1: next-address 192.168.76.6 <---R7/R6 link in area 876 > 2: next-address loose 192.168.86.8 <---R6/R8 link in area 0 > > During troubleshooting I noticed the TE metric was listed as invalid in > "sho mpls traffic-eng topology" > > IGP Id: 6.7.8.7, MPLS TE Id:6.7.8.7 Router Node (ospf 1 area 876) > link[0]: Point-to-Point, Nbr IGP Id: 6.7.8.6, nbr_node_id:2, gen:3 > frag_id 0, Intf Address:192.168.76.7, Nbr Intf > Address:192.168.76.6 > TE metric:invalid, IGP metric:10, attribute flags:0x0 > physical_bw: 100000 (kbps), max_reservable_bw_global: 75000 > (kbps) > max_reservable_bw_sub: 0 (kbps) > > So I change the path-selection method to IGP and the path came up. > > R7(config)#int tun 78 > R7(config-if)#tunnel mpls traffic-eng path-selection metric igp > 01:28:06: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel78, changed > state to up > > I can't find much information about why the TE metric was invalid, and I > never ran into this before. So I switched the path-selection metric back to > te and the tunnel stayed up, even after shutting/no shutting. > > My question is: What gives? Why is the TE metric listed as invalid? And why > did switching the path-selection method to igp make the tunnel come up but > switching it back not make it go down? > > Thanks, > > -- > Bryan Bartik > CCIE #23707 (R&S), CCNP > Sr. Support Engineer - IPexpert, Inc. > URL: http://www.IPexpert.com > _______________________________________________ > For more information regarding industry leading CCIE Lab training, please > visit www.ipexpert.com > > > -- Bryan Bartik CCIE #23707 (R&S), CCNP Sr. Support Engineer - IPexpert, Inc. URL: http://www.IPexpert.com
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
