Adam, James, thank you for the input! Unfortunately I have no test boxes now so I can't do a proper tests without maintenance window planning. May be I will do it later.
I only have some old data from our ops team. Here is a starting point of this question: RP/0/RSP0/CPU0:asr9001-asbr1# show bgp vrf INTERNET 87.245.194.1 > Fri Oct 28 04:07:00.170 Ural > > BGP routing table entry for 87.245.192.0/18, Route Distinguisher: > 12345:100 > Versions: > Process bRIB/RIB SendTblVer > Speaker 57484045 57484045 > Local Label: 395745 > Last Modified: Oct 28 04:06:10.191 for 00:00:50 > > RP/0/RSP0/CPU0:asr9001-asbr1#sh route vrf INTERNET 87.245.194.1 > Fri Oct 28 04:07:20.631 Ural > > Routing entry for 87.245.192.0/18 > Known via "bgp 12345", distance 200, metric 89 > Tag 8359, type internal > Installed Oct 28 04:07:00.560 for 00:00:20 > > RP/0/RSP0/CPU0:asr9001-asbr1#sh cef vrf INTERNET 87.245.194.1 > Fri Oct 28 04:07:36.065 Ural > > 87.245.192.0/18, version 1441462329, internal 0x1000001 0x0 (ptr > 0xa5b97f80) [1], 0x0 (0x0), 0x208 (0xba2f4040) > Updated Oct 25 17:58:17.540 > After a significant delay a SW-FIB entry (and probably HW-FIB entry) for this prefix was still pointing to disabled neighbor although there was a backup path for this prefix. It looks like this SW-FIB updating delay differs for different prefixes. Of course, the old data-plane path was still operational as Adam mentioned, but this delay confused me a little bit. After reading some PIC-related BRCARKs I assume the PIC should work only in case of data-path failure. Shutting down the BGP neighbor doesn't broke the data-path (interface and next-hop remain 'healthy') so there is no PIC trigger for that and prefixes may be updated one-by-one during SW convergence. I didn't find any significant proofs or any list of PIC triggers so it is only my thoughts and assumptions. 2017-08-15 14:00 GMT+05:00 <[email protected]>: > > Vladimir Troitskiy > > Sent: Friday, August 11, 2017 10:59 AM > > > > Hi all, > > > > BGP PIC Edge on an egress PE tracks PE-CE interface and switches to > backup > > path immediately when link to the CE goes down. But what if I manually > > shutdown the PE-CE eBGP session? Does it trigger immediate CEF update on > > the egress PE (ASR9k)? > > -- > Interesting question, to get the exact numbers for your setup I suggest you > hook it up in a loop with Ixia or Spirent to get the actual numbers. > Let's do a little thought experiment to see what might be going on under > the > hood. > Let's assume you shut down the session on local (A)end. > If BGP session is shut down, then BGP on local (A) end will immediately > withdraw all prefixes learned via that session, (BGP on remote (B) end will > terminate the session after receiving BGP Cease NOTIFICATION). > -now I think what you're really asking is whether this is done in a PIC > way > (i.e. triggers artificial BGP-NH invalidation thus all prefixes at once) or > not (BGP withdraws prefix by prefix and notifies RIB for each), and my > answer is I don't know. > But I think it actually doesn't matter because the data-plane is still > operational on both ends (remember the interface is still up and can serve > traffic that was not rerouted yet). > Imagine that node A has the following FIB: > 10.2.0.0/24 > ... > 100.2.0.0/24 > ... > 200.2.0.0/24 > All pointing to B and programed with backup path via A2. > > In time t0 BGP already managed to withdraw B's NH for 10.2.0.0/24 (cause > BGP > always walks the table from top to bottom) so this prefix now points to A2. > Also in time t0 A received a one packet destined to each of three prefixes > above. > - Packet to destination in 10.2.0.0/24 will be using the alternate > next-hop > (A's backup) that is A2. > - Packets to destinations in 100.2.0.0/24 and 200.2.0.0/24 will still be > routed to B in time t0 - but that's ok since the link is operational so > packets will be delivered to B and B can route these packets to correct > destinations (cause it most likely learned routes for 100.2.0.0/24 and > 200.2.0.0/24 via iBGP session -so these are unaffected by the A-B session > shut). > So no loss in this direction. > > But in the opposite direction it depends on how B is set up. > If B manages to withdraw route, for source addresses of the above packets, > as a result of BGP session to A going down and does not yet have any usable > alternative path via B2, then the return traffic from B to A will be > dropped on B until the B's AS converges and traffic starts flowing through > B2. > > > > adam > > > netconsultings.com > ::carrier-grade solutions for the telecommunications industry:: > > -- С уважением, Владимир Троицкий _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
