Hi Rene,
Thanks for lesson does EBGP support PIC feature?
Hello Ankush
The PIC feature doesnât really relate directly to iBGP and eBGP operation. However, each PIC type does correspond loosely to iBGP and eBGP.
Notice that the PIC core feature is used to allow the FIB to change the IGP next-hop to reach the already established BGP next hop. Although this does not affect the BGP operation, it does allow iBGP to reconverge faster, to reach the next-hop IP that is determined by iBGP. So in a sense, PIC core deals more with iBGP.
Similarly, PIC edge deals with failures that affect eBGP peerings. By creating a backup BGP entry, routing can reconverge faster in the event of a failure. In this sense, PIC edge deals more with eBGP.
I hope this has been helpful!
Laz
Hi people. Congratulations for this post!
I have one doubt. I make the same scenario in my lab, but in BGP PIC Edge my PE1 donât receive the backup path to reach the loopback CE2. I enable debug in PE1 an receive this message
Jan 31 05:44:01.876: BGP(0): 5.5.5.5 rcvd NEW PATH UPDATE (bp/be - Permit)w/ prefix: 66.66.66.66/32, label 1048577, bp=Y, be=N
*Jan 31 05:44:01.876: BGP(0): 5.5.5.5 rcvd UPDATE w/ prefix: 66.66.66.66/32, - DO BESTPATH
*Jan 31 05:44:01.876: BGP(0): Calculating bestpath (no bump) for 66.66.66.66/32 :path_count:- 1/0, best-path =3.3.3.3, bestpath runtime :- 1 ms(or 1000 usec) for net 66.66.66.66
PE1-AS200#
*Jan 31 05:44:32.340: BGP(0): 192.168.10.2 rcv UPDATE w/ attr: nexthop 192.168.10.2, origin i, originator 0.0.0.0, merged path 100 200 666, AS_PATH , community , extended community , SSA attribute
*Jan 31 05:44:32.340: BGPSSA ssacount is 0
*Jan 31 05:44:32.340: BGP(0): 192.168.10.2 rcv UPDATE about 6.6.6.6/32 -- DENIED due to: AS-PATH contains our own AS;
*Jan 31 05:44:32.340: BGP(0): 192.168.10.2 rcv UPDATE about 66.66.66.66/32 -- DENIED due to: AS-PATH contains our own AS;
MY config in PE1 and P2 (RR) is below
PE1
router bgp 200
bgp router-id 1.1.1.1
bgp log-neighbor-changes
neighbor 5.5.5.5 remote-as 200
neighbor 5.5.5.5 update-source Loopback0
neighbor 192.168.10.2 remote-as 100
!
address-family ipv4
bgp additional-paths install
neighbor 5.5.5.5 activate
neighbor 5.5.5.5 next-hop-self
neighbor 5.5.5.5 additional-paths receive
neighbor 5.5.5.5 soft-reconfiguration inbound
neighbor 192.168.10.2 activate
neighbor 192.168.10.2 soft-reconfiguration inbound
exit-address-family
P2 RR
P2-RR#show runn | s bgp
router bgp 200
bgp router-id 5.5.5.5
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 200
neighbor 1.1.1.1 update-source Loopback0
neighbor 2.2.2.2 remote-as 200
neighbor 2.2.2.2 update-source Loopback0
neighbor 3.3.3.3 remote-as 200
neighbor 3.3.3.3 update-source Loopback0
neighbor 4.4.4.4 remote-as 200
neighbor 4.4.4.4 update-source Loopback0
neighbor 44.44.44.44 remote-as 200
neighbor 44.44.44.44 update-source Loopback0
!
address-family ipv4
bgp additional-paths select all
neighbor 1.1.1.1 activate
neighbor 1.1.1.1 route-reflector-client
neighbor 1.1.1.1 soft-reconfiguration inbound
neighbor 2.2.2.2 activate
neighbor 2.2.2.2 route-reflector-client
neighbor 2.2.2.2 additional-paths send
neighbor 2.2.2.2 advertise additional-paths all
neighbor 2.2.2.2 soft-reconfiguration inbound
neighbor 3.3.3.3 activate
neighbor 3.3.3.3 route-reflector-client
neighbor 3.3.3.3 soft-reconfiguration inbound
neighbor 4.4.4.4 activate
neighbor 4.4.4.4 route-reflector-client
neighbor 4.4.4.4 soft-reconfiguration inbound
neighbor 44.44.44.44 activate
neighbor 44.44.44.44 route-reflector-client
neighbor 44.44.44.44 soft-reconfiguration inbound
exit-address-family
R2 BGP Table
P2-RR#show ip bgp 6.6.6.6
BGP routing table entry for 6.6.6.6/32, version 37
Paths: (2 available, best #2, table default)
Path not advertised to any peer
Refresh Epoch 1
666, (Received from a RR-client), (received & used)
44.44.44.44 (metric 3) from 44.44.44.44 (44.44.44.44)
Origin IGP, metric 0, localpref 100, valid, internal, all
rx pathid: 0, tx pathid: 0x1
Path advertised to update-groups:
4
Refresh Epoch 1
666, (Received from a RR-client), (received & used)
3.3.3.3 (metric 3) from 3.3.3.3 (3.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0
P2-RR#show bgp
BGP table version is 38, local router ID is 5.5.5.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
* ia6.6.6.6/32 44.44.44.44 0 100 0 666 i
*>i 3.3.3.3 0 100 0 666 i
* ia66.66.66.66/32 44.44.44.44 0 100 0 666 i
*>i 3.3.3.3 0 100 0 666 i
* i 100.100.100.100/32
192.168.11.2 0 100 0 100 i
*>i 1.1.1.1 0 100 0 100 i
Why PE1 donât receive the alternate backup?
Hello Pedro
First of all, youâre using somewhat different IP addresses and ASes from the lesson, so I canât be sure of exactly whatâs happening.
However, I can tell you that the error message you are seeing is a loop prevention mechanism of eBGP. If a route is advertised to an eBGP router that contains the AS of the local router, then that route is denied. It seems that the router with IP address 192.168.10.2 (CE1?) is advertising the 6.6.6.6 and 66.66.66.66 routes (your CE2?) with an AS path that contains AS 100, which is the AS within which PE1 belongs. More information about this can be found at this NetworkLessons Note.
But it is strange that CE1 would be advertising these routes to PE1, but I canât help you further without knowing more about your topology. Let us know some more about your setup so that we can help you further.
I hope this has been helpful!
Laz
Hello Rene, quick question
when you execute PE1#show ip route 6.6.6.6
it only gives you one ospf path ( 192.168.24.4, from 6.6.6.6, 00:15:49 ago, via GigabitEthernet0/1), but you should get two (another one via gig0/2) since everything is equal
Hello @yqpmateo ,
This is done on purpose. I increased the OSPF cost on the interfaces of P2:
Above, we have a small provider network in AS 2 with routers running iBGP. P2 is our route reflector in this network. We have two customers, CE1 and CE2. CE2 is advertising two prefixes in BGP. Within AS 2, we use OSPF as the IGP. I increased the cost on the interfaces of the P2 router so that P1 is the preferred path.
Rene
I had the same thought. I do not see any difference between BGP PIC Edge and BGP-additional paths.
Hello Jason
At first glance yes, you are indeed correct, it looks like BGP PIC edge is the same as BGP additional paths. However, BGP PIC Edge actually uses BGP additional paths as the mechanism through which it fulfills its purpose. But it is called BGP PIC only if:
- The âinstallâ keyword is used so that the path actually becomes a backup path.
- It is implemented at the edge of the specific BGP AS, as shown in the BGP PIC lesson.
So I would say that BGP PIC Edge is a scenario where BGP additional paths is used under specific circumstances, to ensure quick convergence of edge BGP routers. Does that make sense?
For more info, take a look at this Cisco documentation that describes various scenarios under which PIC can be configured:
I hope this has been helpful!
Laz
Thank You for the nice explanation. I have a question about how the BGP attributes behave in the case of BGP PIC. Do we need to maintain the same attributes in the case of primary and backup path? Like local preference, weight, etc
Hello Rajeev
BGP PIC is not directly dependent on BGP attributes such as local preference, weight, etc. Itâs more about the alternate paths that BGP has precomputed in case of a failure.
BGP attributes such as local preference, weight, etc. are used in determining the best path for BGP. The primary and backup paths are chosen based on these attributes. If you want the same path selection process for your backup path as your primary, then yes, you would want to maintain the same attributes, but itâs not obligatory.
When BGP PIC is in use, additional paths that are not selected as the best path but qualify as valid paths (per BGP rules) are pre-installed in the forwarding table. Upon primary path failure, the router will immediately switch to the backup path without re-evaluating all attributes. The pre-installation of backup paths into the forwarding table enables a faster switchover, as the control plane does not have to recompute the best path during convergence.
Remember, BGP attributes are used to manipulate traffic flow in your network. They donât directly influence the BGP PIC process, but they do determine which paths are available for BGP PIC to use as primary and backup. So, while theyâre not part of BGP PIC, theyâre still very important for controlling your traffic flow.
I hope this has been helpful!
Laz
Thank You for the details
1 Like