cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1340
Views
0
Helpful
1
Replies

BGP PIC and convergence time

eero.suominen
Level 1
Level 1

Hello there,

I am have built a lab to analyze and test a BGP PIC functionality.


All 4 devices are emulating IOS XR 9Ks.

In the topology, I have 2 Route-Reflectors and 2 Clients. Both clients has established BGP connection to each Route-Reflector. As IGP I am using IS-IS. From both RR-1 and RR-2, prefixes 0.0.0.0/0 and 77.77.77.0/24 are advertised.

I have configured PIC on PE-1 and it's has a backup path installed to RIB and CEF. See the whole configuration of PE-1 as an attchement.

RP/0/0/CPU0:PE1#sh bgp 77.77.77.0
Mon Oct 10 11:52:29.598 UTC
BGP routing table entry for 77.77.77.0/24
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                192         192
Last Modified: Oct 10 11:52:10.737 for 00:00:18
Paths: (2 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Not advertised to any peer
  Local
    10.0.0.1 (metric 10) from 10.0.0.1 (10.0.0.1)
      Origin incomplete, metric 0, localpref 100, valid, internal, best, group-best
      Received Path ID 0, Local Path ID 1, version 192
  Path #2: Received by speaker 0
  Not advertised to any peer
  Local
    10.0.0.2 (metric 20) from 10.0.0.2 (10.0.0.2)
      Origin incomplete, metric 0, localpref 100, valid, internal, backup, add-path
      Received Path ID 0, Local Path ID 14, version 192

RP/0/0/CPU0:PE1#sh cef 77.77.77.0
Mon Oct 10 11:53:16.025 UTC
77.77.77.0/24, version 867, internal 0x5000001 0x0 (ptr 0xa13fa674) [1], 0x0 (0x0), 0x0 (0x0)
 Updated Oct 10 11:52:10.360
 local adjacency 192.168.1.5
 Prefix Len 24, traffic index 0, precedence n/a, priority 4
   via 10.0.0.1/32, 3 dependencies, recursive [flags 0x6000]
    path-idx 0 NHID 0x0 [0xa13fa9f4 0x0]
    next hop 10.0.0.1/32 via 10.0.0.1/32
   via 10.0.0.2/32, 3 dependencies, recursive, backup [flags 0x6100]
    path-idx 1 NHID 0x0 [0xa13fa3f4 0x0]
    next hop 10.0.0.2/32 via 10.0.0.2/32

When I shut all the physical link on RR-1, I run debug on PE1 to see how fast convergence time I will get for prefix 77.77.77.0/24.
What I can see that it takes quite long time for IS-IS to make 10.0.0.1/32 unreachable and also it's strange that it is doing recursion for the host 10.0.0.1/32 for the default route.

RP/0/0/CPU0:Oct 10 10:56:34.738 : mpls_ldp[1181]: %ROUTING-LDP-5-HELLO_ADJ_CHANGE : VRF 'default' (0x60000000), Link hello adjacency (192.168.1.5, GigabitEthernet0/0/0/0) with Nbr 10.0.0.1:0 is DOWN (Discovery Hello Hold Timer expired)
RP/0/0/CPU0:Oct 10 10:56:52.586 : isis[1010]: %ROUTING-ISIS-5-ADJCHANGE : Adjacency to RR1 (GigabitEthernet0/0/0/0) (L2) Down, Holdtime expired
RP/0/0/CPU0:Oct 10 10:56:52.746 : bgp[1052]: [default-crit] (ip4u): Received RIB notification: nexthop 10.0.0.1/32 is now UNREACHABLE
RP/0/0/CPU0:Oct 10 10:56:53.746 : ipv4_rib[1149]: %ROUTING-RIB-7-SERVER_ROUTING_DEPTH : Recursion loop looking up prefix 10.0.0.1 in Vrf: "default" Tbl: "default" Safi: "Unicast" added by bgp
RP/0/0/CPU0:Oct 10 10:56:55.766 : bgp[1052]: [default-crit] (ip4u): Calculated bestpath for net=77.77.77.0/24, nver=184, nfl=0x04003092, pelemver=184: oldbest=0x109ebfc0(10.0.0.2/32,10.0.0.1,0), newbest=0x109ebe6c(10.0.0.2/32,10.0.0.2,0), bumpv=0
RP/0/0/CPU0:Oct 10 10:56:55.766 : bgp[1052]: [default-crit] (ip4u): Change best path for net=77.77.77.0/24, nver=184, nfl=0x04003092: oldbest=0x109ebfc0: PELEM=0x10a0bf28(lpathid=1, ver=184, fl=0x00000101, path=0x109ebe6c)
RP/0/0/CPU0:Oct 10 10:56:55.766 : bgp[1052]: [default-crit] (ip4u): Update flags for net=77.77.77.0/24, nver=184, nfl=0x04003092: oldtblattr=0x10399be4, oldnh=0x10e16fa4: PELEM=0x10a0bf28(lpathid=1, ver=184, fl=0x00000101, path=0x109ebe6c)
RP/0/0/CPU0:Oct 10 10:56:55.766 : bgp[1052]: [default-crit] (ip4u): Alternate best path [1]: net=77.77.77.0/24, nver=184, nfl=0x04003092: pelemextcount=0: altbest=0x0(NULL,0.0.0.0,0)
RP/0/0/CPU0:Oct 10 10:56:55.766 : bgp[1052]: [default-crit] (ip4u): Calculated adpaths for select[1]: net=77.77.77.0/24, nver=184, nfl=0x04003092, protectmpath=0::: pelemfl=0x00000022, pelemcount=1, pelemextcount=0, backupnonmpathcount=0, bumpv=0

See the attachement for full debug messages.

I am not quite sure what debug message I am supposed to look for the backup path to kick in for RIB and FIB? Maybe you can advice.

What is the main reason why the convergence is taking so long, over 20 seconds? Is the non-optimized IS-IS, I am running without BFD.

Let me know if you can assist

1 Reply 1

xthuijs
Cisco Employee
Cisco Employee

PIC has 2 flavors right, that is core and edge. core operation is sort of native already where you'll have 2 next hops available for the same path.

fib is hierachical and I think this picture here below will visualize it a bit.

what you test with pIC is that not every prefix is converging at a different time, but WHEN the trigger is given all prefixes converge at that same instance.

so you're still "waiting" for the trigger to be received, if you are shutting interfaces, you'll be waiting for the dead timer of the IGP to notify you.

if you are using BFD then the adj is brought down faster so you'll converge all your prefixes then also.