With this lab, we would explain the problem statement and solution for it.
Problem statement-
§ R8 and R9 both external nodes are advertising same NLRI 10.10.10.10/32 to AS100.
§ R1 and R2 both received NLRI 10.10.10.10/32 from R8 and R9 respectively through eBGP.
§ RR(R3) received NLRI from both R1 and R2. But RR selected one Path as best. In this example- RR selecting R1 as best path. We have not used any policy (Local pf) to influence the BGP decision.
§ RR(R3) has advertised only one best route which is via R1 to R6.
§ R6 would receive NLRI 10.10.10.10/32 from RR with R1 as best path. R6 would program this in to forwarding chain.
§ Since R6 has received only one Path, he would advertise the same to R7.
§ R7 would have 10.10.10.10/32 NLRI. Traffic from R7 would go to R8 in ASN 8.
We have Expectation, if R1 or R1-R8 WAN link or R8 went down then switchover to R2-R9 should be in sub-seconds. But this would not happen, because none of the routers has backup route programmed in forwarding plane.
RR advertising 10.10.10.10/32 NLRI with R1 path as best, hence R6 would have not have any knowledge about 2nd path existence through R2. R6 would learn about R2 if and only if R3 advertised this as best route which is possible only if R1 fails.
F As we know, to achieve sub-seconds of Convergence, 2nd best path must be available on all nodes and must be programmed in the forwarding chain.
Tasks-
Ø In this topology
· R1, R2, R3, R4, R6 in AS-100.
§ R3 acting as Route-reflector (RR).
§ R1, R2, R6 are MPLS Edge Nodes
§ R1 is connected to CPE R8 and would be running eBGP with R8
§ R2 is connected to CPE R9 and would be running eBGP with R9
§ R6 is connected to CPE R7 and would be running eBGP with R7
· R7 in AS-7, will advertise 10.10.10.10/32 via eBGP to R1
· R8 in AS-8, will advertise 10.10.10.10/32 via eBGP to R2
· R9 in AS-9, will receive 10.10.10.10/32 via eBGP From R6
Ø Configure AS-100 for OSPF/LDP/BGP
· Run OSPF process 1 on routers R1, R2, R3, R4, R6 with area 0. Remember do not run OSPF in outgoing interfaces of another AS.
· Enable MPLS LDP on R1, R2, R3, R4, R6. Remember do not run LDP in outgoing interfaces of another AS.
· Configure BGP AS-100 (autonomous system) on R3, R3 act as a route-reflector (RR). Configure iBGP session of R1, R2, R6 with RR R3. R1, R2, R6 act as client of R3. Use peering address as loopback 0 address.
Ø Configure AS-7 for BGP
· Configure BGP ASN-7 (autonomous system) on R7. create eBGP session between R7 and R6. Use peering address as WAN address.
· Advertise network 172.1.0.7/32 on R7.
· Configure Loopback1 with Network 10.10.10.10/32 and advertise over IPv4 eBGP.
Ø Configure AS-8 for BGP
· Configure BGP ASN-8 (autonomous system) on R8. create eBGP session between R8 and R1. Use peering address as WAN address.
· Advertise network 172.1.0.8/32 on R8.
· Configure Loopback1 with Network 10.10.10.10/32 and advertise over IPv4 eBGP.
Ø Configure AS-9 for BGP
· Configure BGP ASN-9 (autonomous system) on R9. create eBGP session between R9 and R2. Use peering address as WAN address.
· Advertise network 172.1.0.9/32 on R9.
Configuration Steps for AS100-
Ø Step 1- Configure Ospf
Ø Step 2- Configure LDP
Ø Step3- Configure BGP
R1 |
R2 |
R3 |
router ospf 1 router-id 1.1.0.1 area 0 interface Loopback0 ! interface GigabitEthernet0/0/0/1 ! ! ! |
router ospf 1 router-id 1.1.0.2 ! interface Loopback0 ip ospf 1 area 0 ! interface GigabitEthernet2 ip ospf 1 area 0 !
|
router ospf 1 router-id 1.1.0.3 area 0 interface Loopback0 ! interface GigabitEthernet0/0/0/3 ! ! ! |
R4 |
R6 |
router ospf 1 router-id 1.1.0.4 ! interface Loopback0 ip ospf 1 area 0 ! interface GigabitEthernet0/1 ip ospf 1 area 0 ! interface GigabitEthernet0/2 ip ospf 1 area 0 ! interface GigabitEthernet0/3 ip ospf 1 area 0 ! interface GigabitEthernet0/4 ip ospf 1 area 0 ! interface GigabitEthernet0/5 ip ospf 1 area 0
|
router ospf 1 router-id 1.1.0.6 area 0 interface Loopback0 ! interface GigabitEthernet0/0/0/5 ! ! ! |
Step 2-Enable MPLS LDP on R1, R2, R3, R4, R6. Remember do not run LDP in outgoing interfaces of another AS.
R1 |
R2 |
R3 |
mpls ldp router-id 1.1.0.1 interface GigabitEthernet0/0/0/1 ! ! |
mpls label protocol ldp ! interface GigabitEthernet2 mpls ip !
|
mpls ldp router-id 1.1.0.3 interface GigabitEthernet0/0/0/3 ! ! |
R4 |
R6 |
mpls label protocol ldp ! interface GigabitEthernet0/1 mpls ip ! interface GigabitEthernet0/2 mpls ip ! interface GigabitEthernet0/3 mpls ip
! interface GigabitEthernet0/4 mpls ip ! interface GigabitEthernet0/5 mpls ip
|
mpls ldp router-id 1.1.0.6 interface GigabitEthernet0/0/0/5 !
|
Step3- Configure BGP AS-100 (autonomous system) on R3, R3 act as a route-reflector (RR). Configure iBGP session of R1, R2, R6 with RR R3. R1, R2, R6 act as client of R3. Use peering address as loopback 0 address.
R3 |
R1 |
R6 |
router bgp 100 bgp router-id 1.1.0.3 address-family ipv4 unicast ! neighbor 1.1.0.1 remote-as 100 update-source Loopback0 address-family ipv4 unicast route-reflector-client ! ! neighbor 1.1.0.2 remote-as 100 update-source Loopback0 address-family ipv4 unicast route-reflector-client ! ! neighbor 1.1.0.6 remote-as 100 update-source Loopback0 address-family ipv4 unicast route-reflector-client ! ! ! |
router bgp 100 bgp router-id 1.1.0.1 address-family ipv4 unicast ! neighbor 1.1.0.3 remote-as 100 update-source Loopback0 address-family ipv4 unicast next-hop-self ! ! |
router bgp 100 bgp router-id 1.1.0.6 address-family ipv4 unicast ! neighbor 1.1.0.3 remote-as 100 update-source Loopback0 address-family ipv4 unicast next-hop-self ! ! |
R2 |
router bgp 100 bgp router-id 1.1.0.2 no bgp default ipv4-unicast neighbor 1.1.0.3 remote-as 100 neighbor 1.1.0.3 update-source Loopback0 ! address-family ipv4 neighbor 1.1.0.3 activate neighbor 1.1.0.3 next-hop-self exit-address-family |
Configuration Steps for AS7-
§ Configure BGP ASN-7 (autonomous system) on R7. create eBGP session between R7 and R6. Use peering address as WAN address.
§ Advertise network 172.1.0.7/32 on R7.
R7 |
R6 |
router bgp 7 bgp router-id 172.1.0.7 no bgp default ipv4-unicast neighbor 172.1.67.6 remote-as 100 ! address-family ipv4 network 172.1.0.7 mask 255.255.255.255 neighbor 172.1.67.6 activate exit-address-family
|
router bgp 100 bgp router-id 1.1.0.6 address-family ipv4 unicast ! neighbor 172.1.67.7 remote-as 7 address-family ipv4 unicast route-policy pass in route-policy pass out ! ! !
route-policy pass pass end-policy !
|
Configuration Steps for AS8-
§ Configure BGP ASN-8 (autonomous system) on R8. create eBGP session between R8 and R1. Use peering address as WAN address.
§ Advertise network 172.1.0.8/32 on R8.
R8 |
R1 |
router bgp 8 bgp router-id 172.1.0.8 no bgp default ipv4-unicast neighbor 172.1.18.1 remote-as 100 ! address-family ipv4 network 10.10.10.10 mask 255.255.255.255 network 172.1.0.8 mask 255.255.255.255 neighbor 172.1.18.1 activate exit-address-family |
router bgp 100 bgp router-id 1.1.0.1 address-family ipv4 unicast ! neighbor 172.1.18.8 remote-as 8 address-family ipv4 unicast route-policy pass in route-policy pass out ! !
route-policy pass pass end-policy !
|
Configuration Steps for AS9-
§ Configure BGP ASN-9 (autonomous system) on R9. create eBGP session between R9 and R2. Use peering address as WAN address.
§ Advertise network 172.1.0.9/32 on R9.
R9 |
R2 |
router bgp 9 bgp router-id 172.1.0.9 no bgp default ipv4-unicast neighbor 172.1.29.2 remote-as 100 ! address-family ipv4 network 10.10.10.10 mask 255.255.255.255 network 172.1.0.9 mask 255.255.255.255 neighbor 172.1.29.2 activate exit-address-family |
router bgp 100 bgp router-id 1.1.0.2 no bgp default ipv4-unicast neighbor 172.1.29.9 remote-as 9 ! address-family ipv4 neighbor 172.1.29.9 activate exit-address-family ! |
§ Configure interface Loopback 1 in both AS- 8 and 9 and advertise in BGP address-family IPv4.
R8 |
R9 |
interface Loopback1 ip address 10.10.10.10 255.255.255.255 ! router bgp 8 bgp router-id 172.1.0.8 ! address-family ipv4 network 10.10.10.10 mask 255.255.255.255 exit-address-family |
interface Loopback1 ip address 10.10.10.10 255.255.255.255 ! router bgp 9 bgp router-id 172.1.0.9 ! address-family ipv4 network 10.10.10.10 mask 255.255.255.255 exit-address-family |
Default BGP behaviour without BGP-PIC
§ AS8 and AS9 has advertise same pfix 10.10.10.10/32 to AS100
§ R1 and R2 received 10.10.10.10/32 and advertised to RR(R3)
§ R3 received Multiple Paths (R1 and R2) for the NLRI 10.10.10.10/32
§ R3 would advertise single best selected path as per BGP decision algorithm to R6
Check default traffic flow from AS-7 to AS-8 and AS-9 for pfix 10.10.10.10/32.
R8
§ AS8 has advertise same pfix 10.10.10.10/32 to AS100
R8#show bgp ipv4 unicast
<Snip..>
Network Next Hop Metric LocPrf Weight Path
*> 10.10.10.10/32 0.0.0.0 0 32768 i
*> 172.1.0.7/32 172.1.18.1 0 100 7 i
*> 172.1.0.8/32 0.0.0.0 0 32768 i
*> 172.1.0.9/32 172.1.18.1 0 100 9 i
Given output shows R8 advertise the pfix 10.10.10.10/32.
R9
§ AS9 has advertise same pfix 10.10.10.10/32 to AS100
R9#show bgp ipv4 unicast
<Snip..>
Network Next Hop Metric LocPrf Weight Path
*> 10.10.10.10/32 0.0.0.0 0 32768 i
*> 172.1.0.7/32 172.1.29.2 0 100 7 i
*> 172.1.0.8/32 172.1.29.2 0 100 8 i
*> 172.1.0.9/32 0.0.0.0 0 32768 i
Given output shows R9 advertise the pfix 10.10.10.10/32.
Check BGP IPv4 routing table on R1
R1
RP/0/0/CPU0:R1#show bgp ipv4 unicast summary
<Snip..>
Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd
1.1.0.3 0 100 233 231 10 0 0 03:47:33 2
172.1.18.8 0 8 254 231 10 0 0 03:47:45 2
RP/0/0/CPU0:R1#show bgp ipv4 unicast
<Snip..>
Network Next Hop Metric LocPrf Weight Path
*> 10.10.10.10/32 172.1.18.8 0 0 8 I >>>>Learnt from AS8
*>i172.1.0.7/32 1.1.0.6 0 100 0 7 i
*> 172.1.0.8/32 172.1.18.8 0 0 8 i
*>i172.1.0.9/32 1.1.0.2 0 100 0 9 i
Processed 4 pfixes, 4 paths
Given output shows R1 receive pfix 10.10.10.10/32 from R8 with next-hop 172.1.18.8.
§ R1 would advertise 10.10.10.10/32 to RR(R3)
RP/0/0/CPU0:R1#show bgp ipv4 unicast 10.10.10.10/32 detail >>>adv to RR(R3)
<Snip..>
Paths: (1 available, best #1)
Advertised to peers (in unique update groups):
1.1.0.3
Path #1: Received by speaker 0
Flags: 0x4000000001040003, import: 0x00
Advertised to peers (in unique update groups):
1.1.0.3
8
172.1.18.8 from 172.1.18.8 (172.1.0.8)
Origin IGP, metric 0, localpf 100, valid, external, best, group-best
Received Path ID 0, Local Path ID 1, version 5
Origin-AS validity: not-found
Given output shows R1 receive pfix 10.10.10.10/32 from R8 with next-hop 172.1.18.8 and advertise to RR (R3).
RP/0/0/CPU0:R1#sh route 10.10.10.10/32
Routing entry for 10.10.10.10/32
Known via “bgp 100”, distance 20, metric 0
Tag 8, type external
Installed Feb 17 06:16:16.766 for 00:00:05
Routing Descriptor Blocks
172.1.18.8, from 172.1.18.8, BGP external
Route metric is 0
No advertising protos.
RP/0/0/CPU0:R1#sh cef 10.10.10.10/32 detail
Thu Feb 17 06:23:58.225 UTC
10.10.10.10/32, version 47, internal 0x5000001 0x0 (ptr 0xa13bdf74) [1], 0x0 (0x0), 0x0 (0x0)
Updated Feb 17 06:16:16.776
local adjacency 172.1.18.8
Prefix Len 32, traffic index 0, pcedence n/a, priority 4
gateway array (0xa1251ce8) reference count 2, flags 0x4010, source rib (7), 0 backups
[1 type 3 flags 0x48501 (0xa12ed5b4) ext 0x0 (0x0)]
LW-LDI[type=0, refc=0, ptr=0x0, sh-ldi=0x0]
gateway array update type-time 1 Feb 17 06:00:40.710
LDI Update time Feb 17 06:00:40.710
via 172.1.18.8/32, 2 dependencies, recursive, bgp-ext [flags 0x6020]
path-idx 0 NHID 0x0 [0xa13bdb74 0x0]
next hop 172.1.18.8/32 via 172.1.18.8/32
Load distribution: 0 (refcount 1)
Hash OK Interface Address
0 Y GigabitEthernet0/0/0/3 172.1.18.8
R2
Check BGP IPv4 routing table on R2
R2#show bgp ipv4 unicast summary
<Snip..>
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
1.1.0.3 4 100 227 248 5 0 0 03:41:26 3
172.1.29.9 4 9 249 248 5 0 0 03:41:40 2
R2#show bgp ipv4 unicast
<Snip..>
Network Next Hop Metric LocPrf Weight Path
* i 10.10.10.10/32 1.1.0.1 0 100 0 8 i
*> 172.1.29.9 0 0 9 I >>>>Learnt from AS9
*>i 172.1.0.7/32 1.1.0.6 0 100 0 7 i
*>i 172.1.0.8/32 1.1.0.1 0 100 0 8 i
*> 172.1.0.9/32 172.1.29.9 0 0 9 i
R2#show bgp ipv4 unicast 10.10.10.10/32
BGP routing table entry for 10.10.10.10/32, version 2
Paths: (2 available, best #2, table default)
Advertised to update-groups:
2
Refresh Epoch 1
8
1.1.0.1 (metric 3) from 1.1.0.3 (1.1.0.3)
Origin IGP, metric 0, localpf 100, valid, internal
Originator: 1.1.0.1, Cluster list: 1.1.0.3
rx pathid: 0, tx pathid: 0
Refresh Epoch 1
9
172.1.29.9 from 172.1.29.9 (172.1.0.9)
Origin IGP, metric 0, localpf 100, valid, external, best
rx pathid: 0, tx pathid: 0x0
Output shows R2 receive pfix 10.10.10.10/32 from R9 with Next-hop 172.1.29.9 but he is also receiving same NLRI from RR(R3). R2 making eBGP learnt route as best route out of two options. This decision is based on BGP best path selection algorithm. If we want RR learnt route to become best then we need apply policy (LP/AS-path etc.)
R2#sh ip route 10.10.10.10
Routing entry for 10.10.10.10/32
Known via “bgp 100”, distance 20, metric 0
Tag 9, type external
Last update from 172.1.29.9 00:26:51 ago
Routing Descriptor Blocks:
* 172.1.29.9, from 172.1.29.9, 00:26:51 ago
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 9
MPLS label: none
R2#sh ip cef 10.10.10.10 255.255.255.255 detail
10.10.10.10/32, epoch 2, flags [rib only nolabel, rib defined all labels]
recursive via 172.1.29.9
attached to GigabitEthernet3
R3
Check BGP IPv4 routing table on R3(RR)
RP/0/0/CPU0:R3#show bgp ipv4 unicast summary
<Snip..>
Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd
1.1.0.1 0 100 228 230 9 0 0 03:44:25 2
1.1.0.2 0 100 239 219 9 0 0 03:33:24 2
1.1.0.6 0 100 228 229 9 0 0 03:44:16 1
RP/0/0/CPU0:R3#show bgp ipv4 unicast
<Snip..>
Network Next Hop Metric LocPrf Weight Path
*>i10.10.10.10/32 1.1.0.1 0 100 0 8 i>>>>Learnt from R1
* i 1.1.0.2 0 100 0 9 i>>>>Learnt from R2
*>i172.1.0.7/32 1.1.0.6 0 100 0 7 i
*>i172.1.0.8/32 1.1.0.1 0 100 0 8 i
*>i172.1.0.9/32 1.1.0.2 0 100 0 9 i
Processed 4 pfixes, 5 paths
Given output shows R3 receive pfix 10.10.10.10/32 from R1 and R2 with next-hops 1.1.0.1 and 1.1.0.2 but making best only from R1. This decision is based on BGP best path selection algorithm.
RP/0/0/CPU0:R3#show bgp ipv4 unicast 10.10.10.10/32 detail
<Snip..>
Paths: (2 available, best #1)
Advertised to update-groups (with more than one peer):
0.2
Path #1: Received by speaker 0
Flags: 0x4000000001040207, import: 0x00
Advertised to update-groups (with more than one peer):
0.2
8, (Received from a RR-client)
1.1.0.1 (metric 3) from 1.1.0.1 (1.1.0.1)
Origin IGP, metric 0, localpf 100, valid, internal, best, group-best
Received Path ID 0, Local Path ID 1, version 5
Path #2: Received by speaker 0
Flags: 0x4000000001000207, import: 0x20
Not advertised to any peer
9, (Received from a RR-client)
1.1.0.2 (metric 3) from 1.1.0.2 (1.1.0.2)
Origin IGP, metric 0, localpf 100, valid, internal, group-best
Received Path ID 0, Local Path ID 0, version 0
Above output shows that R3 RR made 10.10.10.10/32 best from R1 and advertised to R2 and R6. RR has advertised only the best route not the 2nd best.
R6
Check BGP IPv4 routing table on R6
RP/0/0/CPU0:R6#show bgp ipv4 unicast summary
<Snip..>
Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd
1.1.0.3 0 100 226 225 10 0 0 03:41:30 3
172.1.67.7 0 7 248 225 10 0 0 03:41:50 1
RP/0/0/CPU0:R6#show bgp ipv4 unicast
<Snip..>
Network Next Hop Metric LocPrf Weight Path
*>i10.10.10.10/32 1.1.0.1 0 100 0 8 i>>>best via R1
*> 172.1.0.7/32 172.1.67.7 0 0 7 i
*>i172.1.0.8/32 1.1.0.1 0 100 0 8 i
*>i172.1.0.9/32 1.1.0.2 0 100 0 9 i
Processed 4 pfixes, 4 paths
Given output shows R6 receive pfix 10.10.10.10/32 from R3 (RR) with next-hop 1.1.0.1. R6 has received only one Path through R1 for the NLRI 10.10.10.10/32
RP/0/0/CPU0:R6#show bgp ipv4 unicast 10.10.10.10/32 detail
<Snip..>
Last Modified: Jan 16 06:39:27.548 for 03:40:58
Paths: (1 available, best #1)
Advertised to peers (in unique update groups):
172.1.67.7
Path #1: Received by speaker 0
Flags: 0x4000000001040007, import: 0x20
Advertised to peers (in unique update groups):
172.1.67.7
8
1.1.0.1 (metric 3) from 1.1.0.3 (1.1.0.1)
Origin IGP, metric 0, localpf 100, valid, internal, best, group-best
Received Path ID 0, Local Path ID 1, version 9
Originator: 1.1.0.1, Cluster list: 1.1.0.3
/* We can see in BGP RIB output that only single route received from RR */
Given output shows R6 receive pfix 10.10.10.10/32 from R3 (RR) with next-hop 1.1.0.1 and advertise to R7.
RP/0/0/CPU0:R6#sh route 10.10.10.10
Routing entry for 10.10.10.10/32
Known via “bgp 100”, distance 200, metric 0
Tag 8, type internal
Installed Feb 17 06:11:53.716 for 00:16:20
Routing Descriptor Blocks
1.1.0.1, from 1.1.0.3
Route metric is 0
No advertising protos.
/* We can see in RIB output that only single Next Hop programmed */
RP/0/0/CPU0:R6#sh cef 10.10.10.10/32 detail
10.10.10.10/32, version 26, internal 0x5000001 0x0 (ptr 0xa13bdff4) [1], 0x0 (0x0), 0x0 (0x0)
Updated Feb 17 06:11:53.736
local adjacency 1.1.46.4
Prefix Len 32, traffic index 0, pcedence n/a, priority 4
gateway array (0xa1251e5c) reference count 2, flags 0x4010, source rib (7), 0 backups
[1 type 3 flags 0x68501 (0xa12ed5b4) ext 0x218 (0xa15271e0)]
LW-LDI[type=0, refc=0, ptr=0x0, sh-ldi=0x0]
gateway array update type-time 1 Feb 17 06:11:53.736
LDI Update time Feb 17 06:11:53.736
via 1.1.0.1/32, 2 dependencies, recursive [flags 0x6000]
path-idx 0 NHID 0x0 [0xa13be074 0x0]
next hop 1.1.0.1/32 via 1.1.0.1/32
Load distribution: 0 (refcount 1)
Hash OK Interface Address
0 Y GigabitEthernet0/0/0/5 1.1.46.4
/* We can see in CEF output that only single Next Hop programmed */
Check BGP IPv4 routing table on R7
R7
R7#show bgp ipv4 unicast summary
<Snip..>
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.1.67.6 4 100 189 208 5 0 0 03:05:49 3
R7#show bgp ipv4 unicast
<>
Network Next Hop Metric LocPrf Weight Path
*> 10.10.10.10/32 172.1.67.6 0 100 8 i
*> 172.1.0.7/32 0.0.0.0 0 32768 i
*> 172.1.0.8/32 172.1.67.6 0 100 8 i
*> 172.1.0.9/32 172.1.67.6 0 100 9 i
Given output shows R7 receive pfix 10.10.10.10/32 from R6 with next-hop 172.1.67.6.
Trace pfixes 10.10.10.10/32 from R7
R7
R7#tr 10.10.10.10 source 172.1.0.7 num
Type escape sequence to abort.
Tracing the route to 10.10.10.10
VRF info: (vrf in name/id, vrf out name/id)
1 172.1.67.6 6 msec 3 msec 3 msec
2 * * *
3 1.1.14.1 21 msec 7 msec 8 msec
4 172.1.18.8 13 msec * 15 msec
Given output shows on R7 reach pfix 10.10.10.10/32 via R1 to ASN 8.
v By default, BGP speaker does not advertised multiple paths for any given NLRI, only best path is advertised by any BGP speaker to other Peers.
v BGP Add-Path is the Solution for the Advertisement of multiple paths
In this lab we have seen the default behaviour of BGP, AS-100 R3 (RR) received pfix 10.10.10.10/32 from R1 and R2 but R3 (RR) advertise the best path. R3(RR) received pfix 10.10.10.10/32 with two next-hops 1.1.0.1 and 1.1.0.2 but made it best via R1 and advertised to R6.
BGP behaviour with BGP-PIC
BGP PIC used BGP Add-path feature to achieve faster convergence. We use the name PIC which stands for Prefix Independent Convergence. We would explain this later in detail that how it is independent of number of pfixes in the table.
“Add-Path is the feature developed with RFC7911. If we enable Add-Path on any of BGP speaker where multiple-Paths are available then that BGP speaker can advertised best path as well as 2nd best path among multiple available paths to other BGP Peers”. “add-path” feature is negotiated as a capability on AFI/SAFI basis.
In this above example, R3 have two paths available and with this knob he can advertised both paths to R6. But if R3 would have more than two paths Available, then he would advertise one best route and which ever be the 2nd best among rest of available would be advertised to R6.
The main issues under bgp Updates, If BGP tries to advertise any NLRI with any change in attributes then it replaces the pvious announcement of that pfix. This behaviour is known as an Implicit Withdraw which is default case in BGP. So BGP Peers whenever calculate backup path and send to remote Peer then remote Peer would simply replaces the old one with new one by considering its update on the old one. Hence there is no separate backup path routes.
This pvents the advertisement of multiple paths for the same pfix but with RFC7911 by adding extra configuration, we can advertise multiple paths for the same NLRI.
This is the capability added in the BGP by RFC7911. During open message exchange BGP Peers negotiate for this feature. In order for a BGP speaker to advertise multiple paths for the same address pfix, a new identifier called Path identifier has been introduced. In combination both Path identifier and Prefix NLRI together identifies the path of any pfix.
Above Pcap Capture shows BGP update packet, in which same NLRI 10.10.10.10/32 is being advertised with two different Path id 1&2.
If two Paths for any NLRI then Path identifier would be different for both PATH and combination of one Path identifier together with NLRI make the distinction with other one.
Without Add-Path capability Update message NLRI encoding
With Add-Path capability Update message NLRI encoding
Path identifier is local to the BGP speaker which means if any Router received pfixes NLRI with multiple paths then it is the responsibility of that router to assign different Path identifier. A BGP speaker that re-advertises a route MUST generate its own Path Identifier to be associated with the re-advertised route.
When you configure Add path then
§ BGP Peers exchange optional ADD PATH capability during session establishment in Open message
§ NLRIs in the BGP update message get modified.
§ Multiple paths for same NLRI get advertised.
For exchanging add-path capability between both BGP Nodes must be configured for Add Path capability configuration.
RP/0/0/CPU0:A#show bgp ipv4 unicast nei 1.1.0.2
<Snip..>
For Address Family: IPv4 Unicast
BGP neighbor version 13
Update group: 0.2 Filter-group: 0.2 No Refresh request being processed
NEXT_HOP is always this router
AF-dependent capabilities:
Additional-paths Send: advertised and received
Additional-paths Receive: advertised and received
Route refresh request: received 0, sent 0
<Snip..>
B #show bgp ipv4 unicast neighbors 1.1.0.1
BGP neighbor is 1.1.0.3, remote AS 100, internal link
BGP version 4, remote router ID 1.1.0.2
<Snip..>
For address family: IPv4 Unicast
Additional Paths send capability: advertised and received
Additional Paths receive capability: advertised and received
Session: 1.1.0.3
BGP table version 7, neighbor version 7/0
Output queue size : 0
Index 2, Advertise bit 1
2 update-group member
<Snip..>
Below is the format of ADD PATH capability-
AFI/SAFI-talks about for which address family this feature has been configured. It is supported only for IPv4 and VPNv4.
Send/Receive:
There are three values has been defined so far
Receive -Value 1- Configured Peer to receive multi-path routes
Send Value 2- Configured Peer to send multi-path routes
Both Send and Receive-Value 3- Configured Peer to receive and send multi-path routes
Add-Path capability is configured in two ways:
1. Global Configuration under address-family- This enables the capability for all the Neighbor or VRFs
2. Per-neighbor basis- Only particular BGP Neighbor or particular VRF is get enable.
Commands:
IOS XE
(Conf t)#router bgp 100
(config-router#address-family ipv4 unicast >>>> It could be IPV4 or VPNV4 address-family >>>>>
(config-router)#bgp additional-paths ?
install Additional paths to install into RIB
receive Receive additional paths from neighbors
select Selection criteria to pick the paths
send Send additional paths to neighbors
router bgp 100
!
address-family ipv4
bgp additional-paths send >>> if BGP speaker want to advertised multiple paths for a NLRI >>>>
or
bgp additional-paths receive >>> if BGP speaker want to receive multiple paths for a NLRI >>>>
or
bgp additional-paths send receive >>>if BGP speaker want to send/receive multiple paths for a NLRI >>>
exit-address-family
###### This Above CLI would be require for Add-Path capability exchange. This CLI would not help to advertise and install backup path. For the advertisement and path installation we also need to use below CLI.#####
************** Additional Path Install *********************
Conf t)#router bgp 100
(config-router#address-family ipv4 unicast >>>> It could be IPV4 or VPNV4 address-family >>>>>
(config-router)#bgp additional-paths ?
install Additional paths to install into RIB
receive Receive additional paths from neighbors
select Selection criteria to pick the paths
send Send additional paths to neighbors
(config-router)#bgp additional-paths select ?
all Select all available paths
backup Select backup path
best Select best N paths
best-external Select best-external path
group-best Select group-best path
************** Additional Path advertise *********************
Conf t)#router bgp 100
(config-router#address-family ipv4 unicast
config-router-af)#neighbor <x.x.x.x> advertise additional-paths ?
all Select all available paths
best Select best N paths
group-best Select group-best paths
config-router-af)#neighbor <x.x.x.x> advertise additional-paths best ?
<2-3> Number of best paths in additional paths to be selected
>>>>> We can advertise number of best path to peer. It shows 2-3 because if we have one which means only best route and 2-3 repsent 2nd best and 3rd best.Number of best advertisements have platform and release depandancy >>>>>>
IOS XR
(config)#router bgp 100
(config-bgp)#address-family ipv4 unicast
(config-bgp-af)#additional-paths ?
receive Additional paths Receive capability
selection Additional paths selection
send Additional paths Send capability
router bgp 100
address-family ipv4 unicast >>>> It could be IPV4 or VPNV4 address-family >>>>>
bgp additional-paths send >>> if BGP speaker want to advertised multiple paths for a NLRI >>>>
or >>> if BGP speaker want to receive multiple paths for a NLRI >>>>
additional-paths receive
or >>>if BGP speaker want to send/receive multiple paths for a NLRI >>>
additional-paths receive
additional-paths send
!
###### This Above CLI would be require for Add-Path capability exchange. This CLI would not help to advertise and install backup path. For the advertisement and path installation we also need to use below CLI.#####
************** Additional Path Install and Advertise *********************
config)#router bgp 100
(config-bgp)#address-family ipv4 unicast
(config-bgp-af)#additional-paths ?
receive Additional paths Receive capability
selection Additional paths selection
send Additional paths Send capability
(config-bgp-af)#additional-paths selection route-policy TEST
(config)#route-policy TEST >>>In XR, under RPL we have multiple option for add path >>>>
(config-rpl)#set path-selection ?
all BGP all paths
backup BGP backup path
best-path BGP best path
group-best BGP group best path
multipath BGP multipath
(config-rpl)#set path-selection backup ?
<1> decimal number 1
parameter Identifier specified in the format: ‘$’ followed by alphanumeric ch
aracters
(config-rpl)#set path-selection backup 1 ?
advertise Advertise the path >>>>>> use this knob if only need to advertise >>>>>
install Install the path >>>>> use this knob if backup path needs to install >>>>
For Selected Prefixes Route-policy: >>>> RPL can be created for selected pfix also >>>
route-policy TEST
if destination in (10.10.10.10/32) then
set path-selection backup 1 advertise
else
pass
endif
end-policy
F Configuration changes will take effect either the next session establishment or BGP session Reset.
Most important point which we need to understand for this feature, “Add-path” knob gives you two functions-
1. Advertising backup route
2. Installing backup route in forwarding plane.
This would be very confusing sometime when we don’t understand where we need to use both features together on the router in the topology and where we can just use Backup route Advertisement only. Let’s understand 1st individual Router’s role in the topology-
In the topology, we have below routers
§ MPLS Edge Nodes which includes ingress and Egress Edge Node
· Customer Service Termination are on Edge nodes. Traffic entering and leaving from Edge Nodes.
· Edge Node need customer routes to be available on them so that routing can happen.
· Edge Nodes need primary best route along with Backup routes. Both Primary (Best) route and Backup route must be program on forwarding plane to get faster convergence.
· Edge nodes need both features (backup adv + Backup install)
· RR advertise the backup or additional path to PEs, PEs only installs the backup paths when the “bgp additional-paths install” command is configured under address-family.
§ MPLS Core LSR nodes
· Core nodes does not carry any Customer/BGP pfixes hence there is no option for add-path configuration.
· It is implicitly clear that even Core Node does not have Add-path but they all must be configured IGP fast reroute feature like IPFRR, RLFA, TI-LFA etc.
§ Route-Reflectors
· Route reflectors if not inline which means no traffic forwarding. In this case RR are placed just for control plane reflection. Route installation require if chassis actively forwarding traffic which would not be the case if RRs are not inline.
· Add-Path advertise feature would be enough on RR. We can safely skip install knob. This would save lot of memory and CPU on RR which we would waste otherwise and can be major scale issue since RR in-house routes of entire network.
Configuring the same Topology with BGP-PIC-
We must compare output of all routers after BGP PIC configuration and compare with the OLD outputs without
Configuration on R3 (RR)
R3
route-policy ADD-PATH >> Define Route-policy ADD-PATH >>>
set path-selection backup 1 advertise >> Backup Path advertisement to Edge Nodes >>>
end-policy
!
router bgp 100
bgp router-id 1.1.0.3
address-family ipv4 unicast
additional-paths receive >>>> TO enable add-path capability
additional-paths send >>>> TO enable add-path capability
additional-paths selection route-policy ADD-PATH
!
Configuration on R1(Edge)
R1
route-policy ADD-PATH >>Define Route-policy ADD-PATH
set path-selection backup 1 advertise >>Backup Path advertisement to RRs >>>
end-policy
!
router bgp 100
bgp router-id 1.1.0.1
address-family ipv4 unicast
additional-paths receive
additional-paths send
additional-paths selection route-policy ADD-PATH
!
Configuration on R2(Edge)
R2
router bgp 100
bgp router-id 1.1.0.2
!
address-family ipv4
bgp advertise-best-external
bgp additional-paths send receive
bgp additional-paths install
exit-address-family
********** If want to configure per neighbor **************
router bgp 100
bgp router-id 1.1.0.2
!
address-family ipv4
bgp additional-paths send receive
bgp additional-paths install
neighbor 1.1.0.3 advertise additional-paths all
exit-address-family
Configuration on R6(Edge)
R6
route-policy ADD-PATH >>Define Route-policy ADD-PATH
set path-selection backup 1 advertise >>Set Path selection backup
end-policy
!
router bgp 100
bgp router-id 1.1.0.6
address-family ipv4 unicast
additional-paths receive
additional-paths send
additional-paths selection route-policy ADD-PATH
!
Ø Verifying the control plane
v Add-path capability exchange via Open message during BGP session establishment:
RP/0/0/CPU0:R1#show bgp ipv4 unicast nei 1.1.0.3
<Snip..>
For Address Family: IPv4 Unicast
BGP neighbor version 13
Update group: 0.2 Filter-group: 0.2 No Refresh request being processed
NEXT_HOP is always this router
AF-dependent capabilities:
Additional-paths Send: advertised and received
Additional-paths Receive: advertised and received
Route refresh request: received 0, sent 0
<Snip..>
R2#show bgp ipv4 unicast neighbors 1.1.0.3
BGP neighbor is 1.1.0.3, remote AS 100, internal link
BGP version 4, remote router ID 1.1.0.3
<Snip..>
For address family: IPv4 Unicast
Additional Paths send capability: advertised and received
Additional Paths receive capability: advertised and received
Session: 1.1.0.3
BGP table version 7, neighbor version 7/0
Output queue size : 0
Index 2, Advertise bit 1
2 update-group member
<Snip..>
RP/0/0/CPU0:R3#sh bgp ipv4 unicast nei 1.1.0.1
<Snip..>
Outbound message logging enabled, 3 messages buffered
For Address Family: IPv4 Unicast
BGP neighbor version 10
Update group: 0.2 Filter-group: 0.2 No Refresh request being processed
Route-Reflector Client
AF-dependent capabilities:
Additional-paths Send: advertised and received
Additional-paths Receive: advertised and received
Route refresh request: received 0, sent 0
2 accepted pfixes, 2 are bestpaths
RP/0/0/CPU0:R6#show bgp ipv4 unicast neighbors 1.1.0.3
<Snip..>
For Address Family: IPv4 Unicast
BGP neighbor version 20
Update group: 0.2 Filter-group: 0.4 No Refresh request being processed
NEXT_HOP is always this router
AF-dependent capabilities:
Additional-paths Send: advertised and received
Additional-paths Receive: advertised and received
Route refresh request: received 0, sent 0
4 accepted pfixes, 3 are bestpaths
<Snip..>
Check BGP IPv4 routing table on R8
R8
R8#show bgp ipv4 unicast
<Snip..>
Network Next Hop Metric LocPrf Weight Path
*> 10.10.10.10/32 0.0.0.0 0 32768 i
*> 172.1.0.7/32 172.1.18.1 0 100 7 i
*> 172.1.0.8/32 0.0.0.0 0 32768 i
*> 172.1.0.9/32 172.1.18.1 0 100 9 i
Given output shows R8 advertise the pfix 10.10.10.10/32.
Check BGP IPv4 routing table on R9
R9
R9#show bgp ipv4 unicast
<Snip..>
Network Next Hop Metric LocPrf Weight Path
*> 10.10.10.10/32 0.0.0.0 0 32768 i
*> 172.1.0.7/32 172.1.29.2 0 100 7 i
*> 172.1.0.8/32 172.1.29.2 0 100 8 i
*> 172.1.0.9/32 0.0.0.0 0 32768 i
Given output shows R9 advertise the pfix 10.10.10.10/32.
Check BGP IPv4 routing table on R1
RP/0/0/CPU0:R1#show bgp ipv4 unicast
<Snip..>
Network Next Hop Metric LocPrf Weight Path
* i10.10.10.10/32 1.1.0.2 0 100 0 9 i
* i 1.1.0.2 0 100 0 9 i
*> 172.1.18.8 0 0 8 i
*>i172.1.0.7/32 1.1.0.6 0 100 0 7 i
* i 1.1.0.6 0 100 0 7 i
*> 172.1.0.8/32 172.1.18.8 0 0 8 i
*>i172.1.0.9/32 1.1.0.2 0 100 0 9 i
* i 1.1.0.2 0 100 0 9 i
RP/0/0/CPU0:R1#sh bgp ipv4 unicast 10.10.10.10/32 detail
BGP routing table entry for 10.10.10.10/32
Versions:
Process bRIB/RIB SendTblVer
Speaker 80 80
Flags: 0x040030b2+0x00020200; backup available;
Last Modified: Feb 18 08:01:59.868 for 00:05:03
Paths: (2 available, best #2)
Advertised to peers (in unique update groups):
1.1.0.3
Path #1: Received by speaker 0
Flags: 0x4000000001040007, import: 0x20
Not advertised to any peer
9
1.1.0.2 (metric 3) from 1.1.0.3 (1.1.0.2)
Origin IGP, metric 0, localpf 100, valid, internal, group-best, backup, add-path
Received Path ID 8, Local Path ID 4, version 80
Originator: 1.1.0.2, Cluster list: 1.1.0.3
Path #2: Received by speaker 0
Flags: 0x4000000001040003, import: 0x20
Advertised to peers (in unique update groups):
1.1.0.3
8
172.1.18.8 from 172.1.18.8 (172.1.0.8)
Origin IGP, metric 0, localpf 200, valid, external, best, group-best
Received Path ID 0, Local Path ID 1, version 69
Origin-AS validity: not-found
RP/0/0/CPU0:R1#sh cef 10.10.10.10/32 detail
10.10.10.10/32, version 138, internal 0x5000001 0x0 (ptr 0xa13bdf74) [1], 0x0 (0x0), 0x0 (0x0)
Updated Feb 18 08:01:59.773
local adjacency 172.1.18.8
Prefix Len 32, traffic index 0, pcedence n/a, priority 4
gateway array (0xa1251de0) reference count 1, flags 0x405010, source rib (7), 0 backups
[1 type 3 flags 0x48501 (0xa12ed5f0) ext 0x0 (0x0)]
LW-LDI[type=0, refc=0, ptr=0x0, sh-ldi=0x0]
gateway array update type-time 1 Feb 18 08:01:59.773
LDI Update time Feb 18 08:01:59.773
via 1.1.0.2/32, 3 dependencies, recursive, backup [flags 0x6100]
path-idx 0 NHID 0x0 [0xa13bdcf4 0x0]
next hop 1.1.0.2/32 via 1.1.0.2/32
via 172.1.18.8/32, 3 dependencies, recursive, bgp-ext [flags 0x6020]
path-idx 1 NHID 0x0 [0xa13bdb74 0x0]
next hop 172.1.18.8/32 via 172.1.18.8/32
Load distribution: 0 (refcount 1)
Hash OK Interface Address
0 Y GigabitEthernet0/0/0/3 172.1.18.8
RP/0/0/CPU0:R1#sh route 10.10.10.10/32
Fri Feb 18 08:07:24.011 UTC
Routing entry for 10.10.10.10/32
Known via “bgp 100”, distance 20, metric 0
Tag 8
Number of pic paths 1 , type internal and external
Installed Feb 18 08:01:59.753 for 00:05:24
Routing Descriptor Blocks
1.1.0.2, from 1.1.0.3, BGP backup path
Route metric is 0
172.1.18.8, from 172.1.18.8, BGP external
Route metric is 0
No advertising protos.
Few important points to understand from above outputs-
§ R1 and R2 both are edge nodes. Both receiving 10.10.10.10/32 from EBGP. R6 is another Edge node but on receiving side.
§ Both are advertising their eBGP learnt route 10.10.10.10/32 to RR. So in this particular scenario RR always have two routes. Now RR would run BGP decision algorithm and make one Path as best which can be either R1 or R2. In this case R1 became the best path.
§ AS per default BGP Rule, RR would advertise best route to R2, R6 nodes. If we want backup routes which is via R2 also be advertise by RR then “set path-selection backup 1 advertise” with RPL must be applied under address-family.
§ This update would be received by R1/R2 and R6 for both best and backup route.
§ All three routers would install both routes in to BGP/RIB/CEF tables.
Check BGP IPv4 routing table on R2
R2
R2#sh bgp ipv4 unicast
BGP table version is 11, local router ID is 1.1.0.2
Status codes: s suppssed, 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-compssed,
Origin codes: i – IGP, e – EGP, ? – incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*bi 10.10.10.10/32 1.1.0.1 0 100 0 8 i
*> 172.1.29.9 0 0 9 i
*>i 172.1.0.7/32 1.1.0.6 0 100 0 7 i
*>i 172.1.0.8/32 1.1.0.1 0 100 0 8 i
*> 172.1.0.9/32 172.1.29.9 0 0 9 i
R2# sh bgp ipv4 unicast
BGP table version is 5, local router ID is 1.1.0.2
Status codes: s suppssed, 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-compssed,
Origin codes: i – IGP, e – EGP, ? – incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*>i 10.10.10.10/32 1.1.0.1 0 200 0 8 i
*b x 172.1.29.9 0 0 9 i
*>i 172.1.0.7/32 1.1.0.6 0 100 0 7 i
*>i 172.1.0.8/32 1.1.0.1 0 200 0 8 i
*> 172.1.0.9/32 172.1.29.9 0 0 9 i
/* See the difference between these two above outputs for the same command-
1st one is without applying Local Prefrence on R1 hence R2 would make his eBGP learn route as best.”b flag” is associated from RR learnt route with R1 as next-hope.
2nd output , we have applied Local Prefrence 200 on R1 which enforce R2 to choose R1 as best route over his own eBGP learn route. In this case R2 should not suppose to advertise eBGP learn route because it is not best route. But knob “best-external” would make this route to advertise. Output shows flag “X” which means best external route. */
R2#sh bgp ipv4 unicast 10.10.10.10/32
BGP routing table entry for 10.10.10.10/32, version 2
Paths: (2 available, best #1, table default)
Advertise-best-external
Advertised to update-groups:
18 19
Refresh Epoch 1
8
1.1.0.1 (metric 3) from 1.1.0.3 (1.1.0.3)
Origin IGP, metric 0, localpf 200, valid, internal, best
Originator: 1.1.0.1, Cluster list: 1.1.0.3
rx pathid: 0x1, tx pathid: 0x0
Refresh Epoch 1
9
172.1.29.9 from 172.1.29.9 (172.1.0.9)
Origin IGP, metric 0, localpf 100, valid, external, backup/repair, advertise-best-external , recursive-via-connected
rx pathid: 0, tx pathid: 0
R2#sh ip cef 10.10.10.10 255.255.255.255 detail
10.10.10.10/32, epoch 2, flags [rib only nolabel, rib defined all labels]
recursive via 1.1.0.1
nexthop 1.1.24.4 GigabitEthernet2 label 19
recursive via 172.1.29.9, repair
attached to GigabitEthernet3
R2#sh ip route 10.10.10.10
Routing entry for 10.10.10.10/32
Known via “bgp 100”, distance 200, metric 0
Tag 8, type internal
Last update from 1.1.0.1 00:07:18 ago
Routing Descriptor Blocks:
* 1.1.0.1, from 1.1.0.3, 00:07:18 ago
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 8
MPLS label: none
R2#sh ip route repair-paths
<snip…>
1.0.0.0/8 is variably subnetted, 11 subnets, 2 masks
O 1.1.0.1/32 [110/3] via 1.1.24.4, 1d02h, GigabitEthernet2
C 1.1.0.2/32 is directly connected, Loopback0
O 1.1.0.3/32 [110/3] via 1.1.24.4, 1d01h, GigabitEthernet2
O 1.1.0.4/32 [110/2] via 1.1.24.4, 1d02h, GigabitEthernet2
O 1.1.0.6/32 [110/3] via 1.1.24.4, 1d02h, GigabitEthernet2
O 1.1.14.0/24 [110/2] via 1.1.24.4, 1d02h, GigabitEthernet2
C 1.1.24.0/24 is directly connected, GigabitEthernet2
L 1.1.24.2/32 is directly connected, GigabitEthernet2
O 1.1.34.0/24 [110/2] via 1.1.24.4, 1d01h, GigabitEthernet2
O 1.1.45.0/24 [110/2] via 1.1.24.4, 1d02h, GigabitEthernet2
O 1.1.46.0/24 [110/2] via 1.1.24.4, 1d02h, GigabitEthernet2
10.0.0.0/32 is subnetted, 1 subnets
B 10.10.10.10 [200/0] via 1.1.0.1, 00:44:25 >>>> Best path >>>>
[RPR][200/0] via 172.1.29.9, 00:44:25 >>>> backup path >>>>
172.1.0.0/16 is variably subnetted, 5 subnets, 2 masks
B 172.1.0.7/32 [200/0] via 1.1.0.6, 00:44:25
B 172.1.0.8/32 [200/0] via 1.1.0.1, 00:44:25
B 172.1.0.9/32 [20/0] via 172.1.29.9, 00:44:25
C 172.1.29.0/24 is directly connected, GigabitEthernet3
L 172.1.29.2/32 is directly connected, GigabitEthernet3
Check BGP IPv4 routing table on R3 (RR)
R3
RP/0/0/CPU0:R3#show bgp ipv4 unicast
<Snip..>
Network Next Hop Metric LocPrf Weight Path
*>i10.10.10.10/32 1.1.0.1 0 100 0 8 i
* i 1.1.0.2 0 100 0 9 i
*>i172.1.0.7/32 1.1.0.6 0 100 0 7 i
*>i172.1.0.8/32 1.1.0.1 0 100 0 8 i
*>i172.1.0.9/32 1.1.0.2 0 100 0 9 i
RP/0/0/CPU0:R3#sh bgp ipv4 unicast 10.10.10.10/32
Fri Feb 18 10:43:31.170 UTC
BGP routing table entry for 10.10.10.10/32
Versions:
Process bRIB/RIB SendTblVer
Speaker 124 124
Last Modified: Feb 18 08:53:09.899 for 01:50:21
Paths: (2 available, best #1)
Advertised to update-groups (with more than one peer):
0.1
Path #1: Received by speaker 0
Advertised to update-groups (with more than one peer):
0.1
8, (Received from a RR-client)
1.1.0.1 (metric 3) from 1.1.0.1 (1.1.0.1)
Origin IGP, metric 0, localpf 100, valid, internal, best, group-best
Received Path ID 0, Local Path ID 1, version 124
Path #2: Received by speaker 0
Advertised to update-groups (with more than one peer):
0.1
9, (Received from a RR-client)
1.1.0.2 (metric 3) from 1.1.0.2 (1.1.0.2)
Origin IGP, metric 0, localpf 100, valid, internal, group-best, backup, add-path
Received Path ID 0, Local Path ID 9, version 124
RP/0/0/CPU0:R3#sh route 10.10.10.10
Routing entry for 10.10.10.10/32
Known via “bgp 100”, distance 200, metric 0
Tag 8, type internal
Installed Feb 18 08:53:10.294 for 01:58:55
Routing Descriptor Blocks
1.1.0.1, from 1.1.0.1
Route metric is 0
No advertising protos.
RP/0/0/CPU0:R3#sh cef 10.10.10.10/32 detail
10.10.10.10/32, version 219, internal 0x5000001 0x0 (ptr 0xa13bdf74) [1], 0x0 (0x0), 0x0 (0x0)
Updated Feb 18 08:53:10.313
local adjacency 1.1.34.4
Prefix Len 32, traffic index 0, pcedence n/a, priority 4
gateway array (0xa1251a00) reference count 2, flags 0x4010, source rib (7), 0 backups
[1 type 3 flags 0x68501 (0xa12ed44c) ext 0x218 (0xa1527280)]
LW-LDI[type=0, refc=0, ptr=0x0, sh-ldi=0x0]
gateway array update type-time 1 Feb 18 08:53:10.313
LDI Update time Feb 18 08:53:10.313
via 1.1.0.1/32, 2 dependencies, recursive [flags 0x6000]
path-idx 0 NHID 0x0 [0xa13bdaf4 0x0]
next hop 1.1.0.1/32 via 1.1.0.1/32
Load distribution: 0 (refcount 1)
Hash OK Interface Address
0 Y GigabitEthernet0/0/0/3 1.1.34.4
/* Above output commands on RR router R3, CEF output does not show more than one route which is the best route programmed. Backup route is not programmed on CEF table, though it is visible on BGP table. This is because RR in this topology is not inline and not forwarding any traffic so there is no point to keep backup route install in CEF table. If we want to install then we need to use add-path install feature. RR placements are based on design and topology. If RR are coming in forwarding path(Inline) then “install” knob is must to achive fast convergence. */
RP/0/0/CPU0:R6#show bgp ipv4 unicast
<Snip..>
Network Next Hop Metric LocPrf Weight Path
*>i10.10.10.10/32 1.1.0.1 0 100 0 8 i
* i 1.1.0.2 0 100 0 9 i
*> 172.1.0.7/32 172.1.67.7 0 0 7 i
*>i172.1.0.8/32 1.1.0.1 0 100 0 8 i
*>i172.1.0.9/32 1.1.0.2 0 100 0 9 i
Processed 4 pfixes, 5 paths
Given output shows R6 receive pfix 10.10.10.10/32 from R3 (RR) with both next-hops 1.1.0.1 and 1.1.0.2.
RP/0/0/CPU0:R6#show bgp ipv4 unicast 10.10.10.10/32 detail
<Snip..>
Paths: (2 available, best #1)
Advertised to peers (in unique update groups):
172.1.67.7
Path #1: Received by speaker 0
Flags: 0x4000000001040007, import: 0x20
Advertised to peers (in unique update groups):
172.1.67.7
8
1.1.0.1 (metric 3) from 1.1.0.3 (1.1.0.1)
Origin IGP, metric 0, localpf 100, valid, internal, best, group-best
Received Path ID 1, Local Path ID 1, version 20
Originator: 1.1.0.1, Cluster list: 1.1.0.3
Path #2: Received by speaker 0
Flags: 0x4000000001040007, import: 0x20
Not advertised to any peer
9
1.1.0.2 (metric 3) from 1.1.0.3 (1.1.0.2)
Origin IGP, metric 0, localpf 100, valid, internal, group-best, backup, add-path
Received Path ID 2, Local Path ID 2, version 20
Originator: 1.1.0.2, Cluster list: 1.1.0.3
RP/0/0/CPU0:R6#sh cef 10.10.10.10/32 detail
10.10.10.10/32, version 185, internal 0x5000001 0x0 (ptr 0xa13be1f4) [1], 0x0 (0x0), 0x0 (0x0)
Updated Feb 18 08:53:11.163
local adjacency 1.1.46.4
Prefix Len 32, traffic index 0, pcedence n/a, priority 4
gateway array (0xa1251ed8) reference count 1, flags 0x404010, source rib (7), 0 backups
[1 type 3 flags 0x68501 (0xa12ed668) ext 0x218 (0xa1527280)]
LW-LDI[type=0, refc=0, ptr=0x0, sh-ldi=0x0]
gateway array update type-time 1 Feb 18 08:53:11.163
LDI Update time Feb 18 08:53:11.163
via 1.1.0.1/32, 3 dependencies, recursive [flags 0x6000]
path-idx 0 NHID 0x0 [0xa13be074 0x0]
next hop 1.1.0.1/32 via 1.1.0.1/32
via 1.1.0.2/32, 3 dependencies, recursive, backup [flags 0x6100]
path-idx 1 NHID 0x0 [0xa13bdbf4 0x0]
next hop 1.1.0.2/32 via 1.1.0.2/32
Load distribution: 0 (refcount 1)
Hash OK Interface Address
0 Y GigabitEthernet0/0/0/5 1.1.46.4
RP/0/0/CPU0:R6#sh route 10.10.10.10/32
Fri Feb 18 11:13:37.427 UTC
Routing entry for 10.10.10.10/32
Known via “bgp 100”, distance 200, metric 0
Tag 8
Number of pic paths 1 , type internal
Installed Feb 18 08:53:11.144 for 02:20:26
Routing Descriptor Blocks
1.1.0.1, from 1.1.0.3
Route metric is 0
1.1.0.2, from 1.1.0.3, BGP backup path
Route metric is 0
No advertising protos.
/* All above output shows that R6 edge node receiving Best and Backup path from RR and installing both in BGP/RIB/CEF table. */
Check BGP IPv4 routing table on R7
R7
R7#show bgp ipv4 unicast summary
<Snip..>
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.1.67.6 4 100 189 208 5 0 0 03:05:49 3
R7#show bgp ipv4 unicast
<Snip..>
Network Next Hop Metric LocPrf Weight Path
*> 10.10.10.10/32 172.1.67.6 0 100 8 i
*> 172.1.0.7/32 0.0.0.0 0 32768 i
*> 172.1.0.8/32 172.1.67.6 0 100 8 i
*> 172.1.0.9/32 172.1.67.6 0 100 9 i
Given output shows R7 receive pfix 10.10.10.10/32 from R6 with next-hop 172.1.67.6.
Trace pfixes 10.10.10.10/32 from R7
R7
R7#tr 10.10.10.10 source 172.1.0.7 num
Type escape sequence to abort.
Tracing the route to 10.10.10.10
VRF info: (vrf in name/id, vrf out name/id)
1 172.1.67.6 6 msec 3 msec 3 msec
2 * * *
3 1.1.14.1 21 msec 7 msec 8 msec
4 172.1.18.8 13 msec * 15 msec
Given output shows on R7 reach pfix 10.10.10.10/32 via R1.
This Lab topology is incomplete, because most of the time customer who ask fast convergence for Service pfixes have resilient setup on CPE side. In this example we have used independent CPEs with not Dual connectivity or backdoor connectivity. In this case if any one of Edge node down or connectivity between Edge and CPE goes down then it would be regular process because there is no 2nd path available. With Resilient CPE topology we need to configure BGP-PIC Add-path knob on CPE side as well so that CPE also can program backup path on BGP/RIB and CEF table.
If we modify the topology as show below, R8 CPE has dual connectivity with R1 and R2. R8 would have route learn from both MPLS Edge Node
If we want end to end fast convergence in this topology, then we need to configure BGP-PIC Add-path knob for both backup advertise and backup install.