cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1179
Views
5
Helpful
5
Replies

BGP Path selection issue with MP-BGP

Ulrich Nguelet
Level 1
Level 1

This is the output i got from CCIE TShoot that i am trying to solve. But it looks like something wrong and I cannot explain. I went through a lot of document explaining bgp path selection and I still cannot explain why bgp chooses the ‘internal’ route over the ‘external’ one. even if I set the weight higher.

 Can someone help please.

 

R18#sh bgp vpnv4 u all 180.10.123.0/25
BGP routing table entry for 65000:65000:180.10.123.0/25, version 26
Paths: (2 available, best #2, table SiteA)
Advertised to update-groups:
23
Refresh Epoch 1
65004
180.10.186.0 (via vrf SiteA) from 180.10.186.0 (172.16.1.6)
Origin incomplete, metric 0, localpref 100, weight 1000, valid, external
Extended Community: RT:65000:65000
rx pathid: 0, tx pathid: 0
Refresh Epoch 1
Local
199.8.2.100 (metric 2) (via default) from 199.8.2.100 (199.8.2.100)
Origin incomplete, metric 117760, localpref 100, valid, internal, best
Extended Community: RT:65000:65000 Cost:pre-bestpath:128:117760
0×8800:32768:0 0×8801:56:5632 0×8802:65283:2560 0×8803:65281:1400
0×8806:0:2886729991
mpls labels in/out nolabel/16
rx pathid: 0, tx pathid: 0×0

1 Accepted Solution

Accepted Solutions

Hi Ulrich,

 

The internal path is selected based on the pre-bestpath community. According to the following document, the external does get the value of x by default, given that it does have a pre-bestpath community.

 

Note Paths that are not configured with the cost community attribute are considered by the best path selection process to have the default cost-value (half of the maximum value [4294967295] or 2147483647).

 

https://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/s_bgpcc.html#wp1027186

 

Regards,

Regards,
Harold Ritter, CCIE #4168 (EI, SP)

View solution in original post

5 Replies 5

Julio E. Moisa
VIP Alumni
VIP Alumni

Hi,

Could you please provide the config and topology, the output is displaying info known via vrf and other locally. 




>> Marcar como útil o contestado, si la respuesta resolvió la duda, esto ayuda a futuras consultas de otros miembros de la comunidad. <<

Hi Julio,

 

Thanks for your quick response. Attached you will find the topology. And this is the scenario.

SiteA has the subnet 180.10.123.0/25 connected in one of his interfaces, and it advertises it to the cloud network and also to R18 (via BGP).

SiteB get the advertisement of that subnet from the cloud Network and advertises it to R17 via EIGRP.

R17 originate the subnet into his BGP RIB via redistribution in vrf SiteB and advertises it to R18 via BGP.

On the Other hand, R18 gets the subnet from SiteA directly as an eBGP route, but it looks like this eBGP route is still less preferred than the one received from R17.

 

R17 Config and BGP RIP

router bgp 65000
no bgp default ipv4-unicast
neighbor 199.8.2.200 remote-as 65000
neighbor 199.8.2.200 update-source Loopback0
!
address-family ipv4
exit-address-family
!
address-family vpnv4
neighbor 199.8.2.200 activate
neighbor 199.8.2.200 send-community extended
exit-address-family
!
address-family ipv4 vrf SiteB
redistribute eigrp 56
exit-address-family
end

 

R17#sh bgp vpnv4 u all 180.10.123.0/25
BGP routing table entry for 65000:65000:180.10.123.0/25, version 131
Paths: (1 available, best #1, table SiteB)
Advertised to update-groups:
14
Refresh Epoch 1
Local
180.10.197.1 (via vrf SiteB) from 0.0.0.0 (199.8.2.100)
Origin incomplete, metric 117760, localpref 100, weight 32768, valid, sourced, best
Extended Community: RT:65000:65000 Cost:pre-bestpath:128:117760
0x8800:32768:0 0x8801:56:5632 0x8802:65283:2560 0x8803:65281:1400
0x8806:0:2886729991
mpls labels in/out 16/nolabel
rx pathid: 0, tx pathid: 0x0
BGP routing table entry for 65000:65001:180.10.123.0/25, version 132

 

R18 Config and BGP RIP

 

router bgp 65000
no bgp default ipv4-unicast
neighbor 199.8.2.100 remote-as 65000
neighbor 199.8.2.100 update-source Loopback0
!
address-family ipv4
exit-address-family
!
address-family vpnv4
neighbor 199.8.2.100 activate
neighbor 199.8.2.100 send-community extended
exit-address-family
!
address-family ipv4 vrf SiteA
neighbor 180.10.186.0 remote-as 65004
neighbor 180.10.186.0 activate
neighbor 180.10.186.0 weight 1000
exit-address-family
!
end

 

BGP routing table entry for 65000:65000:180.10.123.0/25, version 26
Paths: (2 available, best #2, table SiteA)
Advertised to update-groups:
23
Refresh Epoch 1
65004
180.10.186.0 (via vrf SiteA) from 180.10.186.0 (172.16.1.6)
Origin incomplete, metric 0, localpref 100, weight 1000, valid, external
Extended Community: RT:65000:65000
rx pathid: 0, tx pathid: 0
Refresh Epoch 1
Local
199.8.2.100 (metric 2) (via default) from 199.8.2.100 (199.8.2.100)
Origin incomplete, metric 117760, localpref 100, valid, internal, best
Extended Community: RT:65000:65000 Cost:pre-bestpath:128:117760
0x8800:32768:0 0x8801:56:5632 0x8802:65283:2560 0x8803:65281:1400
0x8806:0:2886729991
mpls labels in/out nolabel/16
rx pathid: 0, tx pathid: 0x0

Hi Ulrich,

 

The internal path is selected based on the pre-bestpath community. According to the following document, the external does get the value of x by default, given that it does have a pre-bestpath community.

 

Note Paths that are not configured with the cost community attribute are considered by the best path selection process to have the default cost-value (half of the maximum value [4294967295] or 2147483647).

 

https://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/s_bgpcc.html#wp1027186

 

Regards,

Regards,
Harold Ritter, CCIE #4168 (EI, SP)

Hi Harold,

 

Many thanks, that denifitely explains the behavior and prevents me from having more headaches :)

 I first tried to ignore the bgp bestpath cost on R18, it solves the issue but only on R18. Then I lowered the cost community on R18. This solution is probably the best because now R17 knows the best path to the subnet is via R18.

 

Below the configuration applied and the result.

R18

router bgp 65000
no bgp default ipv4-unicast
neighbor 199.8.2.100 remote-as 65000
neighbor 199.8.2.100 update-source Loopback0
!
address-family ipv4
exit-address-family
!
address-family vpnv4
neighbor 199.8.2.100 activate
neighbor 199.8.2.100 send-community extended
exit-address-family
!
address-family ipv4 vrf SiteA
neighbor 180.10.186.0 remote-as 65004
neighbor 180.10.186.0 activate
neighbor 180.10.186.0 route-map COST-COMMUNITY in
exit-address-family


ip as-path access-list 2 permit _65004$

route-map COST-COMMUNITY permit 10
match as-path 2
set extcommunity cost pre-bestpath 127 117760


R18#sh bgp vpnv4 u all 180.10.123.0/25
BGP routing table entry for 65000:65000:180.10.123.0/25, version 9
Paths: (1 available, best #1, table SiteA)
Advertised to update-groups:
32
Refresh Epoch 1
65004
180.10.186.0 (via vrf SiteA) from 180.10.186.0 (172.16.1.6)
Origin incomplete, metric 0, localpref 100, valid, external, best
Extended Community: RT:65000:65000 Cost:pre-bestpath:127:117760
mpls labels in/out 65/nolabel
rx pathid: 0, tx pathid: 0x0


R17

R17#sh bgp vpnv4 u all 180.10.123.0/25
BGP routing table entry for 65000:65000:180.10.123.0/25, version 285
Paths: (2 available, best #1, table SiteB, RIB-failure(17) - next-hop mismatch)
Not advertised to any peer
Refresh Epoch 1
65004
199.8.2.200 (metric 2) (via default) from 199.8.2.200 (199.8.2.200)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Extended Community: RT:65000:65000 Cost:pre-bestpath:127:117760
mpls labels in/out nolabel/65
rx pathid: 0, tx pathid: 0x0
Refresh Epoch 1
Local
180.10.197.1 (via vrf SiteB) from 0.0.0.0 (199.8.2.100)
Origin incomplete, metric 117760, localpref 100, weight 32768, valid, sourced
Extended Community: RT:65000:65000 Cost:pre-bestpath:128:117760
0x8800:32768:0 0x8801:56:5632 0x8802:65283:2560 0x8803:65281:1400
0x8806:0:2886729991
rx pathid: 0, tx pathid: 0