Image of Cortney & Jeremy

Allowing customers to manipulate routing using BGP communities

by Jeremy L. Gaddis on March 20, 2009 · 7 comments

in Networking

UPDATE: I made a video demonstration of this as well. You can find it at the bottom of this post. Let me know what you think! Thanks.

Upon request, and as a sort of “continuation” of a prior post, “Using BGP communities to influence routing“, I’m going to demonstrate how to permit this to occur (and configure it!) from the service provider perspective.

Recall our topology:

For simplicity, I’m only going to deal with the configurations on R1 and R2 in this post (R3’s configuration is nearly identical to R2’s). Also, because I’m doing this on real gear in my lab at work and I’m currently at home, we’ll be using our FastEthernet 0/1 interfaces (instead of FastEthernet 0/0, as depicted in the diagram). IP addresses and such will remain the same.

Remember that R1 has four loopback interfaces (172.31.0.1/24, 172.31.1.1/24, 172.31.2.1/24, and 172.31.3.1/24). R1 and R2’s IP addresses are 172.16.12.1 and 172.16.12.2 (/24), respectively.

First, let’s go ahead and bring up R2’s FastEthernet 0/1 interface:

R2# conf t
R2(config)# interface fa0/1
R2(config-if)# ip address 172.16.12.2 255.255.255.0
R2(config-if)# no shutdown

Let’s configure the interfaces on R1:

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/1
R1(config-if)# ip address 172.16.12.1 255.255.255.0
R1(config-if)# no shutdown
R1(config-if)# end

Make sure we have connectivity:

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 = 1/2/4 ms

Now we’ll work on setting up R2, the service provider router. Remember that we’re supporting two communities that our customers can send to us:

  • 200: set local preference to 200
  • 500: set local preference to 500

Any routes received without one of these communities will have the local preference set to 150 (this wasn’t in the previous post, but I’m adding it here so we can show off a few things later).

First, we’ll tell R2 that we want to display BGP communities in the “new” AA:NN format:

R2(config)# ip bgp-community new-format

We need to set up two “community lists”. These are what our route maps will match on:

R2(config)# ip community-list 1 permit 65001:200
R2(config)# ip community-list 2 permit 65001:500

Now we can configure our route-map. They should fairly self-explanatory:

R2(config)# route-map CUSTOMER_IN permit 10
R2(config-route-map)# match community 1
R2(config-route-map)# set local-preference 200
R2(config-route-map)# route-map CUSTOMER_IN permit 20
R2(config-route-map)# match community 2
R2(config-route-map)# set local-preference 500
R2(config-route-map)# route-map CUSTOMER_IN permit 30
R2(config-route-map)# set local-preference 150

Can you understand what those do? By this point, hopefully you can!

Let’s go ahead and configure R2’s BGP peering with R1 and apply the CUSTOMER_IN route map to the neighbor:

R2(config)# router bgp 65001
R2(config-router)# neighbor 172.16.12.1 remote-as 65065
R2(config-router)# neighbor 172.16.12.1 soft-reconfiguration inbound
R2(config-router)# neighbor 172.16.12.1 next-hop-self
R2(config-router)# neighbor 172.16.12.1 route-map CUSTOMER_IN in

At this point, we’re all set on the service provider (R2) side. All we need is for the BGP session to come up and R1 to start advertising routes to the service provider. Let’s configure R1 to also display BGP communities in the “new” AA:NN format:

R1(config)# ip bgp-community new-format

Now, before we go messing around with any route-maps on R1, let’s get the BGP session up first:

R1(config)# router bgp 65065
R1(config-router)# neighbor 172.16.12.2 remote-as 65001
R1(config-router)# neighbor 172.16.12.2 soft-reconfiguration inbound
R1(config-router)# neighbor 172.16.12.2 send-community

Verify that BGP is up and running:

R1# show ip bgp summary
BGP router identifier 172.31.3.1, local AS number 65065
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
172.16.12.2     4 65001       4       4        1    0    0 00:00:21        0

Now let’s go ahead and begin advertising our four (loopback) networks:

R1(config)# router bgp 65065
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

How do things look from the service provider (R2) side of things?

R2# show ip bgp
BGP table version is 5, local router ID is 172.16.12.2
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
*> 172.31.0.0/24    172.16.12.1              0    150      0 65065 i
*> 172.31.1.0/24    172.16.12.1              0    150      0 65065 i
*> 172.31.2.0/24    172.16.12.1              0    150      0 65065 i
*> 172.31.3.0/24    172.16.12.1              0    150      0 65065 i

Well, there’s our routes. They are most definitely showing up. Notice that R2 has assigned them a local preference of 150 (the default is 100). This is because the routes did not have any communities associated with them, so they “fell through” the route-map on R2 and were “caught” by the last entry (“30″), which assigned them a local preference of 150.

Let’s set up two route maps on R1:

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

Can you figure out what those do? By assigning one of the two route maps here to our BGP adjacency with R2, we’re setting one of the community values that R2 supports.

Let’s apply the LOCAL_PREF_200 route-map and clear our adjacency:

R1(config)# router bgp 65065
R1(config-router)# neighbor 172.16.12.2 route-map LOCAL_PREF_200 out
R1(config-router)# do clear ip bgp 172.16.12.2

Now what do we see on R2?

R2# show ip bgp | in 172.16.12.1
*> 172.31.0.0/24    172.16.12.1              0    200      0 65065 i
*> 172.31.1.0/24    172.16.12.1              0    200      0 65065 i
*> 172.31.2.0/24    172.16.12.1              0    200      0 65065 i
*> 172.31.3.0/24    172.16.12.1              0    200      0 65065 i

Aha! Now R2 has assigned a local preference value of 200 to our routes. Can you guess what will happen if we apply the LOCAL_PREF_500 route-map on R1?

R1(config-router)# no neighbor 172.16.12.2 route-map LOCAL_PREF_200 out
R1(config-router)# neighbor 172.16.12.2 route-map LOCAL_PREF_500 out
R1(config-router)# do clear ip bgp 172.16.12.2

I bet you know what R2’s BGP table is going to look like now, don’t you!?

R2# show ip bgp | in 172.16.12.1
*> 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

Bingo! R2 has now assigned a local preference value of 500 to our advertised routes! See how easy that is? Now go out there and change how your SP routes to you!

Note: If you found this useful, please do leave me a comment below and let me know. Also, if there are specific examples or “how to’s” you’re looking for, let me know that too. I’m always looking for good ideas for things to write about!

{ 7 comments… read them below or add one }

Leave a Comment

Previous post:

Next post: