Your browser failed to load CSS style sheets. Your browser or web proxy might not support elliptic-curve TLS

Building network automation solutions

6 week online course

Start now!
back to overview

Beware of the pre-bestpath cost extended BGP community

One of my readers sent me an interesting problem a few days ago: the BGP process running on a PE-router in his MPLS/VPN network preferred an iBGP route received from another PE-router to a locally sourced (but otherwise identical) route. When I looked at the detailed printout, I spotted something “interesting” – the pre-bestpath cost extended BGP community.

PE2#sh ip bgp vpnv4 vrf XXX 0.0.0.0 
BGP routing table entry for 172.16.1.105:0:0.0.0.0/0, version 159367

Paths: (2 available, best #1, table XXX)
Local, imported path from 100:0:0.0.0.0/0
172.16.1.104 (metric 11) from 172.16.1.104 (172.16.1.104)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Extended Community: RT:100:0 Cost:pre-bestpath:129:25600 0x8800:0:0
0x8801:100:0 0x8802:65280:25600 0x8803:65281:1500
0x8804:1936:184188929 0x8805:9:0 0x8806:0:184188929 mpls labels in/out nolabel/372 Local
10.251.0.130 from 0.0.0.0 (172.16.1.105)
Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced
Extended Community: RT:100:0

The BGP cost community modifies the BGP path selection process: if the cost community has ABSOLUTE_VALUE (displayed as pre-bestpath) point-of-insertion, it’s considered before the “standard” BGP path selection attributes (yes, it’s stronger than weight).

BGP paths without the cost community are assumed to have a pretty high cost value (2147483647, as explained by Cisco’s documentation), causing the iBGP route to be better than the local route (which had no cost community).

The cost extended BGP community is usually seen in networks running EIGRP between PE-and CE-routers that try to cope with multihomed customer sites. Although you could change it manually with the set extcommunitiy cost command in numerous places where a route-map can be used, it should not appear in my reader’s network – his default route was a simple static route redistributed into BGP without a route-map.

It turned out he stumbled upon a bug; he was using EIGRP in the same VRF, and removing and re-enabling EIGRP-to-BGP redistribution in the VRF address family removed the stray cost community from the default route. Obviously that fix isn’t always applicable – you can’t simply bounce EIGRP redistribution every time a BGP prefix gets a weird set of communities – but fortunately you can ignore the cost community with the bgp bestpath cost-community ignore router configuration command.

No comments:

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Sidebar