Influencing BGP path selection with the extcommunity cost attribute

Many of you out there should be familiarized with the BGP path selection process,
but I bet some of you (as me, until I recently found out) didn’t knew that by using the
extcommunity cost attribute, we might be able to somehow modify the BGP path
selection algorithm.

So what is the extended community cost attribute?.

The BGP Cost Community feature introduces the cost extended community
attribute. The cost community is a non-transitive extended community
attribute that is passed to internal BGP (iBGP) and confederation peers but
not to external BGP (eBGP) peers. The cost community feature allows you to
customize the local route preference and influence the best path selection
process by assigning cost values to specific routes.

This next diagram will be the topology I’ll be working on to demonstrate how this
could be done:

First, we build a basic BGP configuration on every router according to the diagram
above. After that is done, if we take a look on R1 BGP table it should look like this:

R1#sh ip bgp
BGP table version is 2, local router ID is 192.168.123.1
Status codes: s suppressed, d damped, h history, * valid, > best, 
i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
* i10.10.10.0/24    192.168.123.3            0    100      0 400 i
*>i                 192.168.123.2            0    100      0 400 i

R1#sh ip bgp 10.10.10.0
BGP routing table entry for 10.10.10.0/24, version 4
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Flag: 0xA60
  Not advertised to any peer
  400
    192.168.123.3 from 192.168.123.3 (192.168.123.3)
      Origin IGP, metric 0, localpref 100, valid, internal
  400
    192.168.123.2 from 192.168.123.2 (192.168.123.2)
      Origin IGP, metric 0, localpref 100, valid, internal, best

We can see that both paths for prefix 10.10.10.0/24 (a loopback  interface on R4)
have the same attributes. If we follow the steps in the BGP path selection algorithm,
we can deduce that the next hop 192.168.123.2 is being chosen as the best path
because it’s the path announced by the router with the lowest router-id, in this
case R2.

Imagine you are in the lab, and they give you a task stating something like

“Make R1 to prefer the route to 10.10.10.0/24 through R3 but, without modifying
local preference, weight, as-path, bgp router-id or IGP metric to next-hop”
(evil I know  ). This is one case when the extcommunity cost could result useful.

Let’s do the configuration, we need to make R1 and R3 send community values:

R1(config)#router bgp 123 
R1(config-router)#neighbor 192.168.123.3 send-community both
!
R3(config)#router bgp 123 
R3(config-router)#neighbor 192.168.123.1 send-community both

Then on R3, we build a route-map, where the extcommunity cost setting will take place:

R3(config)#ip prefix-list TRICKY-TASK permit 10.10.10.0/24 
R3(config)#route-map TASK permit 10 
R3(config-route-map)#match ip add prefix-list TRICKY-TASK 
R3(config-route-map)#set extcommunity cost 1 100 
R3(config-route-map)#exit 
!
R3(config)#route-map TASK permit 20 
R3(config-route-map)#exit

And then we apply the route-map in R3 for the R1 neighbor relationship,
and clear the BGP process for that neighbor:

R3(config)#router bgp 123 
R3(config-router)#neighbor 192.168.123.1 route-map TASK out 
R3(config-router)#do clear ip bgp * soft out

That’s it, now we need to verify. To do that, we take a look at R1’s BGP table so we
can see the effect of the route-map in the route:

BGP routing table entry for 10.10.10.0/24, version 5 
Paths: (2 available, best #1, table Default-IP-Routing-Table) 
Flag: 0xA60 Not advertised to any peer 400
    192.168.123.3 from 192.168.123.3 (192.168.123.3) 
Origin IGP, metric 0, localpref 100, valid, internal, 
best Extended Community: Cost:igp:1:100
  400 192.168.123.2 from 192.168.123.2 (192.168.123.2) 
Origin IGP, metric 0, localpref 100, valid, internal