BGP PIC (Prefix Independent Convergence) Core & Edge

This topic is to discuss the following lesson:

Great lesson, Rene!

I studied this from the Cisco documentation but they never explained in clear terms what was going on, but you managed it!

Small typo (should be 88.88.88.88/32?):

88.88.88.88/43 via 192.168.24.4 interface GigabitEthernet0/1

Also could you provide the configs for PIC edge, at the end?

===

Just came across this quote from Cisco:

PIC core ensures fast convergence for BGP routes when there is a link or node failure in the core that causes a change in the IGP reachability to a remote BGP next-hop address.

PIC edge ensures fast convergence to a BGP backup path when an external (eBGP) edge link or an external neighbor node fails.

In your example you use iBGP between PE’s for obvious reasons, so I’m a bit surprised they say PIC edge is for “external neighbours”?

Hello Chris

Thanks for pointing that out, I’ll let Rene know…

I’ll also let him know about the request for the configurations for PIC edge.

The Cisco comment is indeed correct. Even though iBGP is run between PEs in the network, it is still the routes that the PE routers connect to (other AS’s, namely external networks) that are involved in an edge link failing or an external neighbor node failing. You still have to find a route via another PE to the external route.

I hope this has been helpful!

Laz

Thanks Laz.

Still don’t really agree though - PIC edge is clearly addressing data plane convergence for IBGP neighbours in a service provider environment.

I just can’t see how that can be possible be called “external neighbours”, which implies the BGP neighbour operates in a different AS when in fact it doesn’t. The external customer may not even be running BGP!

Oh well!

Hi Chris,

If you still need them, I just added the configs for PIC edge.

I agree that this Cisco quote is a bit strange. PIC edge is really about fast failover to an edge router in your own network.

Rene

Hi Rene,
Wonderful explanation, probably not found anywhere.
My question is until when PE1 will use PE4 as NH in PIC edge? In case PE3 is up again, will it be revertive ?
2nd question-: if MPLS is enabled in ISP, will we have H-LFIB as well?

hi Rene and staff,

i read BGP PIC Core, thanks for this great explanation
Using hierarchical FIB, CEF (and BGP) are ready to go a very short time after IGP reconverge in the core (ospf in this case)
You have to configure the simple command “cef table output-chain …”
Perhaps it is a basic question, but
in the lesson, it seems that this command has to be configured only on PE routers (PE1, PE2, PE3, PE4) and not on P routers
Could you explained why ?
Does the type of FIB on P2 and P1 (flat versus hierarchical) involve the performance of the core too ?
Thanks

Hello Dominique

The specific example was within the BGP PIC Core section, which means that we are attempting to decrease convergence time in the event that a core router (P router) fails. Because the PE routers are those that are on the edge of the BGP AS, and they contain the routes to the prefixes at each customer, it is these routers that require the hierarchical FIB enabled. The P routers simply interconnect the PE routers and do not need to know about the multiple prefixes that exist at the customers. So in the event of a core failure, the remaining functioning core routers will not have many prefixes to reconverge. The edge routers however will have many (millions?) of prefixes to reconverge. So although you can apply it to a core router, such a command would only beneficial to edge and not core routers.

I hope this has been helpful!

Laz

Thank you Laz, it is very useful to help me understand the situation in PIC core

What i understand is:
P1 and P2 are (more/very) essential for IGP OSPF to find the routes between PE routers
When P1 fails, does the BGP table on P2 change just a little or do not change at all ? (for me do not change at all, but i am not sure)
When P1 comes back, do BGP tables on P routers (P1, P2) change a little or do not change at all ?

So BGP has not to reconverge on P routers (As i asked just above, i am not sure if BGP has to reconverge a little or not at all)
But regarding the size, the BGP table on P routers have the same size like PE routers; because P2 as RR has all the NLRI from PE routers, and with iBGP it advertise his clients (and P1 is client); is it right ?

At the end why not use hierachical FIB on P routers instead of flat FIB ? as it is just a command to play ?
(The starting point of this discussion is that Rene does not use hierachical FIB in the lesson for P routers)
Thanks
Best regards

Hi Dominique,

The BGP entries in P2 won’t change since from P2’s perspective, nothing changes:

P2#show ip bgp

     Network          Next Hop            Metric LocPrf Weight Path
 * ia 8.8.8.8/32       7.7.7.7                  0    100      0 8 i
 *>i                   6.6.6.6                  0    100      0 8 i
 * ia 88.88.88.88/32   7.7.7.7                  0    100      0 8 i
 *>i                   6.6.6.6                  0    100      0 8 i

The next hop doesn’t change:

P2#show ip cef 6.6.6.6
6.6.6.6/32
  nexthop 192.168.56.6 GigabitEthernet0/4

In this topology, it’s not needed to enable hierachical FIB. It doesn’t hurt just to enable it on all routers though. I think on IOS XE, it’s even enabled by default.

The key thing to remember is that PIC core is useful when the path to get to the next hop changes. In this topology, that’s not the case for P2. Let’s imagine that in between P2 and PE3/PE4 we have a P3 and P4 router, P2 uses P3 as the path to get to PE3/PE4. When P3 fails, P2 has to reconverge to P4. That’s a scenario where a hierarchical FIB on P2 would be useful.

Hope this helps!

Rene