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
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
