Previously I’ve covered using weight, local preference, and AS path prepending to influence routing between autonomous systems running BGP. Today we’ll look at one of the common methods for influencing routing, and that is BGP community values.
BGP communities are simply values attached to a route that is sent to BGP peers. This values have special meanings to the peers and cause specific actions to be taken, depending upon the values assigned. A customer who is multi-homed to a service provider can often use communities to tell the service provider how to route traffic to the customer autonomous system (AS).
For this example, let’s assume the following topology:
We are the customer (AS 65065) and R1 is our router. We are multi-homed to our service provider (AS 65001) with a 100 Mbit/s connection to R2 and a T-1 connection to R3. R2 and R3 are connected over a 100 Mbit/s connection as well.
Since the IP addresses being used are not illustrated in the diagram, here is a table with the IP addresses we are using:
ROUTER INTERFACE IP/MASK
--------------------------------------
R1 Fa0/0 172.16.12.1/24
Se1/0 172.16.13.1/24
R2 Fa0/0 172.16.12.2/24
Fa1/0 172.16.23.2/24
R3 Fa0/0 172.16.23.3/24
Se1/0 172.16.13.3/24
In addition, our router (R1) has four loopback interfaces (Loopback0, Loopback1, Loopback2, and Loopback3) with the following IP addresses assigned, respectively: 172.31.0.1/24, 172.31.1.1/24, 172.31.2.1/24, and 172.31.3.1/24.
Okay, so let’s get our loopbacks configured and IP connectivity up between R1/R2 and R1/R3:
R1# conf t
R1(config)# interface loopback 0
R1(config-if)# ip address 172.31.0.1 255.255.255.0
R1(config-if)# interface loopback 1
R1(config-if)# ip address 172.31.1.1 255.255.255.0
R1(config-if)# interface loopback 2
R1(config-if)# ip address 172.31.2.1 255.255.255.0
R1(config-if)# interface loopback 3
R1(config-if)# ip address 172.31.3.1 255.255.255.0
R1(config-if)# interface fa0/0
R1(config-if)# ip address 172.16.12.1 255.255.255.0
R1(config-if)# no shutdown
R1(config-if)# interface se1/0
R1(config-if)# ip address 172.16.13.1 255.255.255.0
R1(config-if)# no shutdown
R1(config-if)# end
Let’s make sure we can ping both R2 and R3:
R1# ping 172.16.12.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.12.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/12/24 ms
R1# ping 172.16.13.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.13.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/12/20 ms
Alright, so far, so good. We have four networks that we want to advertise into BGP — the four /24 subnets assigned to our loopback interfaces. Before we do this, however, let’s take another look at our topology. Recall that we have connections into AS 65001: a 100 Mbit/s connection to 172.16.12.2 and a 1.544 Mbit/s connection to 172.16.13.3. Sure would be nice if we could tell AS 65001 to send our traffic over that 100 Mbit/s connection, wouldn’t it? Well, we can!
Our service provider, AS 65001, allows us to use the communities attribute of BGP to influence how they route our traffic. In this (simplified) example, there are three different communities we can use:
- 200: set local preference to 200
- 500: set local preference to 500
If we send routes to AS 65001 with a community of 65001:200, the SP’s routers will set the local preference on those routes to 200. If we send routes to AS 65001 with a community of 65001:500, the SP’s routers will set the local preference on those routes to 500. How handy is that?
Because of how the BGP best path selection algorithm works, we want our SP’s routers to assign a higher local preference to the routes it receives from us over that 100 Mbit/s connection, so we’ll send those routes with a community of 65001:500. Just for good measure, we’ll attach community 65001:200 to the routers we send to 172.16.13.3 over the T-1 connection as well.
Let’s go ahead and set up BGP, but don’t start advertising any routes just yet:
R1(config)# ip bgp-community new-format
R1(config)# router bgp 65065
R1(config-router)# neighbor 172.16.12.2 remote-as 65001
R1(config-router)# neighbor 172.16.12.2 next-hop-self
R1(config-router)# neighbor 172.16.12.2 send-community
R1(config-router)# neighbor 172.16.13.3 remote-as 65001
R1(config-router)# neighbor 172.16.13.3 next-hop-self
R1(config-router)# neighbor 172.16.13.3 send-community
We are all set to begin advertising our routes, with the appropriate communities attached. The next thing we need to do is create a pair of route maps. We’ll apply these route maps outbound to the BGP peers and these are what we will use to attach our communities to the routes:
R1(config)# route-map LOCAL_PREF_200 permit 10
R1(config-route-map)# set community 65001:200
R1(config-route-map)# route-map LOCAL_PREF_500 permit 10
R1(config-route-map)# set community 65001:500
Lookin’ good so far, right? Let’s apply those route map to our BGP peers:
R1(config)# router bgp 65065
R1(config-router)# neighbor 172.16.12.2 route-map LOCAL_PREF_500 out
R1(config-router)# neighbor 172.16.13.3 route-map LOCAL_PREF_200 out
That was easy enough. Now, let’s advertise those loopbacks:
R1(config-router)# network 172.31.0.0 mask 255.255.255.0
R1(config-router)# network 172.31.1.0 mask 255.255.255.0
R1(config-router)# network 172.31.2.0 mask 255.255.255.0
R1(config-router)# network 172.31.3.0 mask 255.255.255.0
Let’s take a look at how the SP sees our routes:
R2# sh ip bgp | in 65065
*> 172.31.0.0/24 172.16.12.1 0 500 0 65065 i
*> 172.31.1.0/24 172.16.12.1 0 500 0 65065 i
*> 172.31.2.0/24 172.16.12.1 0 500 0 65065 i
*> 172.31.3.0/24 172.16.12.1 0 500 0 65065 i
R3# sh ip bgp | in 65065
*>i172.31.0.0/24 172.16.23.2 0 500 0 65065 i
* 172.16.13.1 0 200 0 65065 i
*>i172.31.1.0/24 172.16.23.2 0 500 0 65065 i
* 172.16.13.1 0 200 0 65065 i
*>i172.31.2.0/24 172.16.23.2 0 500 0 65065 i
* 172.16.13.1 0 200 0 65065 i
*>i172.31.3.0/24 172.16.23.2 0 500 0 65065 i
* 172.16.13.1 0 200 0 65065 i
If we ping/traceroute from R3 to one of R1′s loopbacks, we should see that traffic first passes to R2 before being sent to R1 (which is our goal):
R3# ping 172.31.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.31.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/17/36 ms
R3# traceroute 172.31.0.1
Type escape sequence to abort.
Tracing the route to 172.31.0.1
1 172.16.23.2 4 msec 12 msec 16 msec
2 172.16.12.1 16 msec * 32 msec
Success!
Refer to http://evilrouters.net/
