BGP PIC Edge provides sub second convergence time in the case of edge link or node failure. BGP PIC is a useful for MPLS VPN service and can be provided by the Service provider as a value added service thus might provide additional revenue. BGP PIC provides sub second converge time in case link or node failure, and BGP PIC edge covers the edge failure cases.
Sub second convergence is not possible without PIC – Prefix Independent Convergence for BGP.
I am explaining this topic in deep detail in “BGP Zero to Hero” course.
Figure -1 BGP PIC (Prefix Independent Convergence) Edge
In order BGP PIC Edge to work, edge IBGP devices ( Ingress PEs and ASBRs ) need to support BGP PIC and also they need to receive backup BGP next hop.
In the above topology, R1 is the ingress PE, R4 and R5 are the ASBR nodes.Route Reflector is shown in the data path but it is not recommended in real network design.
Unfortunately backup next hop is not sent when BGP Route Reflector is introduced since RR selects and advertise only the best path for the given prefix.
For example, in the above topology, R6 and R7 both sends, 192.168.0.0/24 network but R1 can learn from the RR only one exit point (BGP next-hop), either R4 or R5.
There are many ways to send more than one best path from BGP RR but let’s not talk about them in this article, instead let’s assume, R1 learns the 192.168.0.0/24 prefix from R4 and R5.
How BGP PIC Edge Works ?
Let’s assume link between R1 learns the 192.168.0.0/24 prefix from R4 and R5 and choose the best exit point as R4. In this case R5 is marked as backup/alternate next hop and programmed into the FIB (Forwarding Information Base) of R1.
Let’s examine some failure and see how BGP PIC takes an action. – BGP PIC edge in case of edge link fails but ASBR doesn’t set next-hop self-
In case R4-46 link fails and R4 doesn’t set next-hop to itself (No next-hop self). In that case, link between R4 and r6 is advertised to the IGP. When R4-R6 link fails, R1 learns the failure from the IGP. BGP Next-hop tracking feature helps here.
IGP protocols register to the BGP Next-hop tracking process (Similar to IGP to BFD registration right ? )
When R1 learns the link failure between R4-R6, it immediately changes the BGP next hop for the 192.168.0.0/24 prefix to the R5. This switchover is done in less than a second regardless of the number of prefixes. Which mean even though you have million of BGP prefixes which need to be updated, still sub second convergence. (In this example for the simplicity only 192.168.0.0/24 prefix) – BGP PIC edge in case of edge link fails and ASBR set’s next-hop self –
When R4 sets BGP next hop to it self (It is done by setting the loopback as next-hop), since the loopback interface won’t go down, even though R1 learns the link failure (if the R4-R6 link is redistributed into IGP) from IGP, it doesn’t trigger BGP next-hop tracking to fails the BGP next hop , because BGP next hop for the 192.168.0.0/24 prefix is not the R4-R6 link address but the R4 loopback.
In this case R1 continue to send the traffic for the 192.168.0.0/24 prefix to the R4. But since the link between R4-R6 fails, when R4 receives the traffic destined to 192.168.0.0/24, it should send towards R5 immediately. (That’s why in the beginning I said, not only Ingress nodes, but also ASBRs should learn the alternate next-hop)
When do you set next-hop self on the edge BGP node ?
In MPLS VPN environment it is the best practice and almost mandatory to set the BGP next hop to the PE loopback. With that, transport LSP can be created to that PE loopback. So far in the examples, BGP PIC edge protected the link failures. – BGP PIC edge in case of edge node failure – What if R4 fails ? How R1 would reach to that failure ?
In case R4 fails, IGP will trigger the BGP Next-hop tracking and R1 can change the next-hop as R5 for all the BGP prefixes. Convergence is again sub-second regardless of a number of BGP prefixes.
Orhan Ergun, CCIE/CCDE Trainer, Author of Many Networking Books, Network Design Advisor, and Cisco Champion 2019/2020/2021
He created OrhanErgun.Net 10 years ago and has been serving the IT industry with his renowned and awarded training.
Wrote many books, mostly on Network Design, joined many IETF RFCs, gave Public talks at many Forums, and mentored thousands of his students.
Today, with his carefully selected instructors, OrhanErgun.Net is providing IT courses to tens of thousands of IT engineers.