Hi, I am testing BGP next-hop tracking on SRC2 code release for the 7600. I have a pretty simple setup as follows:
PE1 ----- P1 ------- | / | | | RR1 | PE3 | \ | | PE2 ----- P2 ------- PE1 and 2 are 7600's running 12.2(18)SXF5. RR1 is a 7204VXR running 12.0(32)S2. PE3 is the 7600 running 12.2(33)SRC2 where I am concentrating my tests. I have IS-IS and LDP running between all routers advertising next-hop loopbacks. All 3 PE's have VPNv4 iBGP sessions to RR1 and are configured as RR clients. Next-hop tracking is turned off on the RR. I have a VRF configured on all 3 PE's with different RD's like so: ! ip vrf convergence-test description vrf for convergence testing rd 1000:[1-3] route-target export 1000:4 route-target import 1000:4 ! On PE1 and PE2 I have a SVI in the convergence-test VRF with IP's in the range 192.168.10.0/24 which I am redistributing into BGP (on the back of both PE's I have a switch in this VLAN with a host hanging off and VRRP running on the PE's). Here is the VPNv4 routing table on PE3 for the VRF: PE3#sh ip bgp vpnv4 vrf convergence-test BGP table version is 621, local router ID is xx.xxx.128.239 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 1000:3 (default for vrf convergence-test) * i192.168.10.0 xx.xxx.128.247 0 100 0 ? *>i xx.xxx.128.246 0 100 0 ? *> 192.168.11.0/30 0.0.0.0 0 32768 ? *>i192.168.16.128/30 xx.xxx.128.246 0 100 0 ? The loopback of PE1 is .246 and PE2 is .247 so you can see that the preferred next-hop is currently PE1. Now the problem I have is when I shutdown the loopback of PE1 to remove it from the IGP, PE3 appears to notice this and runs the BGP next-hop tracking scanner after the default 5 second wait (I can see this happen in debugs) but appears to do nothing after that. The route for 192.168.10.0/24 via .246 is not removed from the VPNv4 table and stays active until the BGP scanner (default 60 seconds) is run and it withdraws the route (or the RR BGP scanner is run and withdraws the route via BGP). Once this happens, then the VPNv4 route updates to 192.168.10.0/24 via .247 as it should. I am expecting to see the VPNv4 route change after the default 5 second wait for the next-hop scanner but this is not the case. Does anyone have any ideas or have experienced similar issues to this? TIA, Dan Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trade marks of British Sky Broadcasting Group plc and are used under licence. British Sky Broadcasting Limited (Registration No. 2906991), Sky Interactive Limited (Registration No. 3554332), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of British Sky Broadcasting Group plc (Registration No. 2247735). All of the c! ompanies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD. _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/