[c-nsp] BGP outbound route-map support for community-lists not working ?

[Reuben Farrelly]

I've been experimenting with a new (and what I thought was improved 
design/modification) in terms of our internal and external BGP routing, 
and I've hit a bit of a snag.

We are largely an end user AS but we do have a couple of eBGP customers 
connecting to us who require AS transit.

Essentially the design I have in mind is like this:

(internet,ebgp) rt1 -- sw1 -- sw2 -- sw3 - sw4 - rt2 (internet,ebgp)

rt1 and rt2 are 2851 ISRs running 15.1(4)M3.  I also have a 7200 running 
the same version of code in another POP.

Between rt1 all the way towards the right, through the switches and to 
rt2 we're running the same AS - but not a full table - just prefixes 
specific to our AS and our customers only.  The two ebgp routers would 
not have a direct iBGP relationship.  There are a whole lot of /28s, 
/29s, /30s etc within iBGP of which most are allocated to end customers 
who do not have their own IP range (the majority of customers).

I'm looking to create a configuration that requires minimal changes if, 
for example, a new customer connects in with their own IP block and more 
importantly, allows maximum flexibility in terms of selecting upstream 
route advertisements.  [In practice we have three upstream facing 
routers, and about another six peers so anything I can do to avoid 
reconfiguring each and every router every time we need a prefix added is 
a big part of the end goal].

The grand big picture plan I had was to use communities to do all the work.

I was looking to tag all of the iBGP generated routes with a community 
of 100:700 and 100:701 (so customer statics and connecteds get a 
different community) and set no-export on them.  They can stay within 
our AS.
I was also looking to install a static route to Null0 for the /21 and a 
couple of /23's at other POPs that our network runs, and tag these with 
the community 100:7 using a route-map combined with a prefix-list.

When a new customer comes along the plan was to add a static route, and 
tag that route with 100:74XX.  Thus we can easily distinguish between 
customer owned and our own internally generated routes.

This all pretty much works as planned.  The addition of communities to 
routes in the inbound direction works as expected.  No problem there.

Now what I was intending to do on the edge of the network facing our 
upstreams (eBGP) is to use the communities that are already set, to 
control what prefixes are advertised to our upstreams, something like this:

1. Routes with 100:100 and 100:101 would be dropped on account of the 
no-export community on those routes (just to be sure).

2. Customer /24 routes all fall within a well defined match of community 
values depending on the POP - 7400-7499.  Easy enough to come up with a 
regex to match...

3. Our /21 and /23's which are null0 holddown routes, are tagged with 
the community 100:7

The problem lies in #2 and #3.

I was expecting this would work:

--------

router bgp 100
<>
  address-family ipv4
   neighbor 10.1.1.1 activate
   neighbor 10.1.1.1 send-community
   neighbor 10.1.1.1 inherit peer-policy UPSTREAM-POLICY
  exit-address-family

  template peer-policy UPSTREAM-POLICY
   route-map POLICY-OUT out
   prefix-list BOGON-PREFIXES in
   remove-private-as
   maximum-prefix 450000 98 warning-only
  exit-peer-policy

route-map POLICY-OUT permit 10
  description description Advertise all Customer Subnets Upstream
  match community CUSTOMER-BGP
!
route-map POLICY-OUT permit 20
  description description Advertise Core Subnets (null routes) Upstream
  match community CORE-EXTERNAL-BGP

ip community-list expanded CUSTOMER-BGP permit 100:74..

ip community-list expanded CORE-EXTERNAL-BGP permit 100:7

---------

But it seems it doesn't work:

rt1#show ip bgp neighbors 10.1.1.1 advertised-routes
Total number of prefixes 0
rt1#

What am I missing here?

Adding a static route, adding a route map and adding a single entry 
prefix-list to one core router and then everything else working like 
clockwork because of community settings would be ideal :-)

If outbound route-maps cannot be used to match communities for the 
purposes of route advertisements, are there any other mechanisms to 
achieve this goal without "touching" each edge router every time a 
change is required?

Are there any alternatives or tweaks that I could make to this design to 
perhaps even improve it?

Thanks,
Reuben