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?
1 Like
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
1 Like
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 iThe next hop doesn’t change:
P2#show ip cef 6.6.6.6
6.6.6.6/32
nexthop 192.168.56.6 GigabitEthernet0/4In 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
Hi Guys,
Thank you very much for this information. Regarding to this command “cef table output-chain build favor convergence-speed”, it is available for Cat4k SUP7E?. Cat4k is running IOS XE release code, so my question here is, this command is enabled by default on IOS XE? or just in IOS XR and NX-OS?.
thank you!
Hello Juan
According to this Cisco documentation, this command is supported in the CIsco IOS XE release. This command was actually introduced in IOS 12.2(33)SRA and integrated fully into 12.4(20)T.
I hope this has been helpful!
Laz
Hi,
Can you explain the difference between BGP PIC Edge and BGP-additional-path?
Thanks
1 Like
Hi Rene,
what if we use BGP confederation within AS not route reflector, how can we establish PIC edge?
Hello Ilgar
Whether you use route reflectors, or confederations, the results are the same. The PIC Edge feature is enabled simply by configuration BGP additional paths so that backup routes can be installed in the BGP table and the FIB. This would take place whether or not you use considerations or route reflectors, as long as there are indeed additional available paths.
I hope this has been helpful!
Laz
1 Like
Hi Rene,
In the section of the course “BGP PIC Core”, after having applied the configs of each router and having obtained the same results as you in terms of the show command, I cannot join the network (ping) behind CE2 from PE1. is this normal?
PE1#show ip cef 6.6.6.6
6.6.6.6/32
nexthop 192.168.24.4 GigabitEthernet1/0
nexthop 192.168.25.5 GigabitEthernet2/0
PE1#show ip cef | include 8.8
8.8.8.8/32 192.168.24.4 GigabitEthernet1/0
88.88.88.88/32 192.168.24.4 GigabitEthernet1/0
PE1#ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
PE1#Hello Parfait
The topology in the lesson is not fully configured to provide a demonstration of BGP PIC and does not include configurations for full reachability on the network. If you notice, only the CE2 router has a BGP network command. No other routers are advertising any networks. This was done so that the lesson can focus on the way in which that particular network is being advertised throughout the topology, using the two types of BGP PIC.
In your particular case, the ping reaches the CE2 router, but CE2 has no route back to PE1. If you want to obtain connectivity between these devices, you will have to advertise the network on the PE1 router that is being used as the source of the ping.
I hope this has been helpful!
Laz
Thanks, I understand now
1 Like
Hi all, great lesson.
About PIC Core, doing a GNS3 lab with same topology. When enabling the hierarchical FIB structure, should i see another output in show ip cef? i still see the same structure and BGP prefixes with OSPF next hop. Is there a way to see the hierarchical structure?
Last, if i run show cef table i have:
Output chain build favors:
platform: not configured
CLI: not configured
operational: convergence-speed
By entering the command it changes the line CLI to:
CLI: convergence-speed
I guess even if i don’t configure it, by default it is operational?
Thanks in advance.
Hello Marios,
It depends on the platform / OS (version). In your case, it seems to be enabled by default yes.
Here’s an example of IOSv where I didn’t configure anything yet:
Router#sh run all | incl output-chain
cef table output-chain build favor defaultWhen I look at show cef table it shows:
Router#show cef table
Global information:
Output chain build favors:
platform: not configured
CLI: memory-utilization
operational: memory-utilizationOnce I change it to cef table output-chain build favor convergence-speed it looks like this:
Router#show cef table
Global information:
Output chain build favors:
platform: not configured
CLI: convergence-speed
operational: convergence-speedThe output of show ip cef remains the same. I tried some of the other show cef and show ip cef commands to see if I could see the hierarchical structure but I didn’t. If you do, let me know 
Rene
Rene
1 Like