Today’s post is about BGP Communities. Here is an explanation of them from Cisco:

A community is a group of prefixes that share some common property and can be configured with the BGP community attribute. The BGP Community attribute is an optional transitive attribute of variable length. The attribute consists of a set of four octet values that specify a community. The community attribute values are encoded with an Autonomous System (AS) number in the first two octets, with the remaining two octets defined by the AS. A prefix can have more than one community attribute. A BGP speaker that sees multiple community attributes in a prefix can act based on one, some or all the attributes. A router has the option to add or modify a community attribute before the router passes the attribute on to other peers.

Here is a table listing the Well Known Communities from Cisco:

Note that the “Internet” community is somewhat disputed. For more information on that, check out Ivan Pepelnjak’s post.

So, in short, the BGP Community attribute is used to group common routes and treat them in a certain manner. Today we’re going to look at the CCIP Topology I’ve been working with. We well accomplish one of the requirements using a BGP Community setting. The requirement we’re looking at is:
No customer AS should ever be used as a transit between ISPs, configure this on the customer and ISP sides of the BGP relationship.

We’re only going to focus on the customer side this time. We will set the “no-export” community on incoming routes from our providers. This isn’t a typical application of BGP Communities (that I know of), but I thought it would be interesting. Previous to this I was using AS-Path ACLs to prevent AS9330 from becoming a transit. Here’s our topology:

(click image for fullsize)
We’re focusing on PE1, Peer1 and CE4. We will prevent AS9300 from becoming a transit between the two providers.

First we will use some show commands on the provider side to verify that AS9300 is a transit:

Peer1#sh ip bgp neigh 38.19.4.2 routes
...
   Network          Next Hop            Metric LocPrf Weight Path
*> 5.22.77.0/24     38.19.4.2                0             0 9300 ?
*  10.10.10.10/32   38.19.4.2                              0 9300 6500 4700 ?
*  11.33.97.0/24    38.19.4.2                              0 9300 6500 4700 ?
*  15.11.11.0/24    38.19.4.2                              0 9300 6500 4700 ?
*> 17.17.17.17/32   38.19.4.2                0             0 9300 ?
*  19.21.31.0/24    38.19.4.2                              0 9300 6500 4700 ?
*  21.47.11.0/24    38.19.4.2                              0 9300 6500 4700 ?
*  32.113.18.0/24   38.19.4.2                              0 9300 6500 4700 ?
*  37.3.115.0/24    38.19.4.2                              0 9300 6500 4700 ?
*  38.19.4.0/30     38.19.4.2                0             0 9300 ?
*  43.55.112.0/24   38.19.4.2                              0 9300 6500 4700 ?
*  54.22.77.0/24    38.19.4.2                              0 9300 6500 4700 ?
*  55.12.75.0/24    38.19.4.2                              0 9300 6500 4700 ?
*  64.12.38.0/30    38.19.4.2                              0 9300 6500 4700 ?
...
 
PE1#sh ip bgp neigh 91.7.36.2 routes
...
   Network          Next Hop            Metric LocPrf Weight Path
*> 5.22.77.0/24     91.7.36.2                0             0 9300 ?
*  9.9.9.9/32       91.7.36.2                              0 9300 1200 ?
*> 17.17.17.17/32   91.7.36.2                0             0 9300 ?
*  21.47.8.0/24     91.7.36.2                              0 9300 1200 ?
r  27.9.41.0/30     91.7.36.2                              0 9300 1200 ?
*  28.71.14.0/30    91.7.36.2                              0 9300 1200 ?
*  32.83.18.0/24    91.7.36.2                              0 9300 1200 ?
*  38.19.4.0/30     91.7.36.2                0             0 9300 ?
*  43.6.82.0/24     91.7.36.2                              0 9300 1200 ?
*  54.92.77.0/24    91.7.36.2                              0 9300 1200 ?
*  65.5.91.0/24     91.7.36.2                              0 9300 1200 ?
*  76.12.36.0/24    91.7.36.2                              0 9300 1200 ?
*  87.3.85.0/24     91.7.36.2                              0 9300 1200 ?
r> 91.7.36.0/30     91.7.36.2                0             0 9300 ?
*> 91.47.113.0/24   91.7.36.2                0             0 9300 ?
*> 96.59.76.0/24    91.7.36.2                0             0 9300 ?
*  98.41.22.0/24    91.7.36.2                              0 9300 1200 ?
...

We see that AS9300 is advertising “internet” routes to each provider, potentially making it a transit AS.

Now let’s configure “no-export” on CE4:

route-map No-Export permit 10
 set community no-export
!
router bgp 9300
 neighbor 38.19.4.1 remote-as 1200
 neighbor 38.19.4.1 route-map No-Export in
 neighbor 91.7.36.1 remote-as 6500
 neighbor 91.7.36.1 route-map No-Export in

We have created a route-map which sets the “no-export” community. We then apply the route-map to our neighbors inbound. This will set the “no-export” community for all routes received from our providers.

Now let’s verify that it is working on CE4:

CE4#sh ip bgp  11.33.97.0
BGP routing table entry for 11.33.97.0/24, version 166
Paths: (2 available, best #1, table Default-IP-Routing-Table, not advertised to EBGP peer)
  Not advertised to any peer
  6500 4700
    91.7.36.1 from 91.7.36.1 (5.5.5.5)
      Origin incomplete, localpref 100, valid, external, best
      Community: no-export
  1200 4700
    38.19.4.1 from 38.19.4.1 (223.234.8.1)
      Origin incomplete, localpref 100, valid, external
      Community: no-export

We see that the prefix “11.33.97.0/24″ does have the “no-export” community set.

Now let’s verify that our providers are not seeing “internet” routes from AS9300:

Peer1#sh ip bgp neigh 38.19.4.2 routes
...
   Network          Next Hop            Metric LocPrf Weight Path
*> 5.22.77.0/24     38.19.4.2                0             0 9300 ?
*> 17.17.17.17/32   38.19.4.2                0             0 9300 ?
*  38.19.4.0/30     38.19.4.2                0             0 9300 ?
*> 91.7.36.0/30     38.19.4.2                0             0 9300 ?
*> 91.47.113.0/24   38.19.4.2                0             0 9300 ?
*> 96.59.76.0/24    38.19.4.2                0             0 9300 ?
*> 101.45.197.0/24  38.19.4.2                0             0 9300 ?
*> 118.55.12.0/24   38.19.4.2                0             0 9300 ?
*> 142.113.218.0/24 38.19.4.2                0             0 9300 ?
*> 151.12.75.0/24   38.19.4.2                0             0 9300 ?
*> 160.141.0.0      38.19.4.2                0             0 9300 i
*> 171.71.54.0/24   38.19.4.2                0             0 9300 ?
*> 197.37.31.0      38.19.4.2                0             0 9300 ?
*> 217.3.115.0      38.19.4.2                0             0 9300 ?
 
PE1#sh ip bgp neigh 91.7.36.2 routes
...
   Network          Next Hop            Metric LocPrf Weight Path
*> 5.22.77.0/24     91.7.36.2                0             0 9300 ?
*> 17.17.17.17/32   91.7.36.2                0             0 9300 ?
*  38.19.4.0/30     91.7.36.2                0             0 9300 ?
r> 91.7.36.0/30     91.7.36.2                0             0 9300 ?
*> 91.47.113.0/24   91.7.36.2                0             0 9300 ?
*> 96.59.76.0/24    91.7.36.2                0             0 9300 ?
*> 101.45.197.0/24  91.7.36.2                0             0 9300 ?
*> 118.55.12.0/24   91.7.36.2                0             0 9300 ?
*> 142.113.218.0/24 91.7.36.2                0             0 9300 ?
*> 151.12.75.0/24   91.7.36.2                0             0 9300 ?
*> 160.141.0.0      91.7.36.2                0             0 9300 i
*> 171.71.54.0/24   91.7.36.2                0             0 9300 ?
*> 197.37.31.0      91.7.36.2                0             0 9300 ?
*> 217.3.115.0      91.7.36.2                0             0 9300 ?

Here we see that it is working! Our providers are only seeing prefixes that originated in AS9300.

That’s all for this post. We have used BGP Communities to accomplish one of the requirements in the CCIP Lab challenge. Tell me what you think!

Colby

Colby Glass has been in IT since 2002. He is currently a network engineer with a Cisco Gold partner and holds the CCNP R/S, CCNP DC, CCDP, CCIP, JNCIA-ER and ITILv3: Foundations certifications.

More Posts