[c-nsp] bgp PIC Edge & neighbor shutdown

Tue Aug 15 09:57:37 EDT 2017

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 <adamv0025 at netconsultings.com>:

> > 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::
>
>

-- 
С уважением,
Владимир Троицкий