Tha hail-mary of IT - reboot! ;) Just saw your post Bryan - and funnily enough I am working through the same lab again today.
I didn't see the issue you spoke about but I concur with Rick's sentiments... On a side note - have either of you ever seen this behavior... sometimes when I go to set parameters in a route-map, the parameter I'm trying to set (say local-pref) is just being echoed back to me and not taking in the route-map. Only way so far I find to "fix" this and let the statement take is to reboot and then re-apply the set statement. I've seen this with 12.2T and 12.3T code and it's annoying having to reboot to get it to take. Cheers, Con. On Sun, Sep 20, 2009 at 3:58 PM, Bryan Bartik <[email protected]> wrote: > 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 > > _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
