BGP path selection

[michaelhawkins]

According to all the Cisco documentation I've read, setting the weight of a BGP route higher than another identical BGP route should trump all other routing decisions. This would mean that a route learned from eBGP would be consdered better than an iBGP route if the weight of the eBGP route was higher than the iBGP route.

Is everything I just said correct? I ask because my MPLS PE router isn't picking the eBGP route despite my having configured the weight to be much higher than for the iBGP learned routes.

[Harold Ritter]

The weight is indeed the first thing that is considered in the BGP best path selection process.

Just one precision though. The eBGP path would be selected over the iBGP path given that all other attributes are equals.

Could you please post the output of a show ip bgp for the specific prefix so we can see what is going on.

Thanks,

[michaelhawkins]

Here is the output...

WPEDG01#sho ip bgp vpnv4 vrf CORPNET 209.208.175.128 BGP routing table entry for 1000:4:209.208.175.128/25, version 1451 Bestpath Modifiers: always-compare-med

Paths: (3 available, best #1, table CORPNET)

Not advertised to any peer

Local

192.168.211.225 (metric 5) from 192.168.211.225 (192.168.211.225)

Origin incomplete, metric 200, localpref 100, valid, internal, best

Extended Community: SoO:1006:4 RT:1000:4 Cost:pre-bestpath:129:64512

0x8800:0:65529 0x8801:105:7680 0x8802:65281:56832 0x8803:65281:1500

0x8804:65237:2865128014 0x8805:9:200

65521

172.26.16.6 (via CORPNET) from 172.26.16.6 (172.26.16.45)

Origin incomplete, metric 200, localpref 100, weight 200, valid, external

Extended Community: RT:1000:4

65524

172.26.16.5 (via CORPNET) from 172.26.16.5 (172.26.16.41)

Origin incomplete, metric 200, localpref 100, weight 200, valid, external

Extended Community: RT:1000:4

WPEDG01#sho ip route vrf CORPNET 209.208.175.128 Routing entry for 209.208.175.128/25

Known via "bgp 65235", distance 200, metric 200, type internal

Redistributing via eigrp 105

Advertised by eigrp 105 metric 1500 20110 255 1 1500

Last update from 192.168.211.225 11:53:12 ago

Routing Descriptor Blocks:

* 192.168.211.225 (Default-IP-Routing-Table), from 192.168.211.225, 11:53:12 a go

Route metric is 200, traffic share count is 1

AS Hops 0, BGP network version 0

WPEDG01#

[Harold Ritter]

I should have been more specific when I said that the weight is the first thing considered by the BGP best path selection process. This is not true anymore when the BGP cost community is used. The BGP cost community may be used to take precedence and be evaluated first by the BGP best path selection process.

In your scenario, the BGP cost community is set on the first path (iBGP) and not on the other two (eBGP). The absence of the cost community on the eBGP path is interpreted as a value of 2147483647 by the selection process, hence the iBGP path being selected since this is the first thing to select the best path and a lowest value (64512) is preferred.

For more information the the BGP cost community and how it can be used to influence the best path selection process, refer to the following URL:

http://www.cisco.com/en/US/products/sw/iosswrel/ps1829/products_feature_guide09186a008053b5b6.html

Hope this helps,

[michaelhawkins]

Excellent news!

I applied the following route-map to incoming updates:

route-map CORPNETBgpFromWPDMZ2A permit 10

match ip address CORPNETBgpFromWPDMZ2A

set extcommunity cost pre-bestpath 0 64000

!

route-map CORPNETBgpFromWPDMZ2B permit 10

match ip address CORPNETBgpFromWPDMZ2B

set extcommunity cost pre-bestpath 0 64000

And here is the result when the route is not sourced through eBGP (ie: the link was shut to the route source):

WPEDG01#sho ip bgp vpnv4 vrf CORPNET 209.208.175.128

BGP routing table entry for 1000:4:209.208.175.128/25, version 1440

Bestpath Modifiers: always-compare-med

Paths: (1 available, best #1, table CORPNET)

Flag: 0x820

Not advertised to any peer

Local

192.168.211.225 (metric 5) from 192.168.211.225 (192.168.211.225)

Origin incomplete, metric 200, localpref 100, valid, internal, best

Extended Community: SoO:1006:4 RT:1000:4 Cost:pre-bestpath:129:64512

0x8800:0:65529 0x8801:105:7680 0x8802:65281:56832 0x8803:65281:1500

0x8804:65237:2865128014 0x8805:9:200

And here is the result when the route IS sourced through eBGP (ie: the link is back up to the route source):

WPEDG01#sho ip bgp vpnv4 vrf CORPNET 209.208.175.128

BGP routing table entry for 1000:4:209.208.175.128/25, version 1444

Bestpath Modifiers: always-compare-med

Paths: (2 available, best #2, table CORPNET)

Advertised to update-groups:

5

65521

172.26.16.6 (via CORPNET) from 172.26.16.6 (172.26.16.45)

Origin incomplete, metric 200, localpref 100, weight 200, valid, external

Extended Community: RT:1000:4 Cost:pre-bestpath:0:64000

65524

172.26.16.5 (via CORPNET) from 172.26.16.5 (172.26.16.41)

Origin incomplete, metric 200, localpref 100, weight 200, valid, external,

best

Extended Community: RT:1000:4 Cost:pre-bestpath:0:64000

So thanks, it worked!

But here's another question or two. I have set the community ID to 0 and the pre-bestpath cost to 64000. However, the route coming from the distant side has an ID of 129 and pre-bestpath cost of 64512.

Is the community ID taken into consideration in the routing decision? Does an EIGRP SOO route-map affect that number so that I need to be careful as to my choice of community ID? When I redistribute Eigrp into BGP vrf's, is there a correlation between the pre-bestpath value? If so, what is the correlation?

I ask because we insert some routes into this vrf via EIGRP and apply a SOO route map to those routes while at other sites we accept BGP and will need to apply a pre-bestpath value to those routes. Therefore, I need to be careful as to how I apply routing policy and I always prefer to establish a specific policy that can be communicated in documentation and hold our network engineers to that standard for deployments.

Many thanks.

Mike Hawkins

[Harold Ritter]

Here's some answers to your questions.

- The community id is taken in consideration only if the cost value are equals.

- An EIGRP SOO route-map doesn't affect the cost community.

- When redistrbuting from EIGRP to BGP after 12.0(27)S the cost community is set by default as follow:

Internal EIGRP route = community id of 128

External EIGRP route = community id of 129

The cost value is set to the value of the composite metric.

Hope this helps,

[michaelhawkins]

Thanks Harold,

Those answers were exactly what I was after and many thanks but why wouldn't that information be in the "BGP Cost Community" document posted in Cisco's site?

That information is incredibly useful and important to understanding the way in which EIGRP routes are handled by BGP. I reread the document and I just don't see that information in there. Perhaps we could get a docu request going to add that information so others don't spend untold hours on it.

Thanks again,

Michael Hawkins

[Harold Ritter]

Very good point Michael. The section on EIGRP in the BGP cost community document is very minimal.

I will request for the additional information to be added.

Thanks,

[michaelhawkins]

Harold,

I forgot to mention the other document that needs that information too. That would be the document called "EIGRP MPLS VPN PE-CE Site of Origin (SoO)". This one also would benefit a great deal with the inclusion of the cost community information that you provided to me.

Thanks again,

Mike Hawkins