Defining hierarchical BGP route-maps

Question

I work for an MSP with a relatively small network. We're implementing a new set of Cisco ASR 1001-Xs on our edge and I'm trying to improve our BGP configuration.

The routers are running: IOS XE Version 03.16.05.S / Version 15.5(3)S5

One problem I'm trying to solve, is how to make the configuration reasonably scalable in terms of making changes across multiple peers. I imagine this surely must be possible for larger ISP networks with 10s or 100s of BGP peer configurations.

Specifically, I am hoping to define multiple levels of import/export route-maps, where I can define a general route-map for all transit peers, one for customers, one for IXes, etc. Then as a 2nd level of route-maps applied after that would be AS-specific route-maps for the particular peer.

What I've tried

BGP Templates

I've tried using BGP templates, defining a UPSTREAM_TRANSIT peer-policy, inherited by a more AS-specific template such as UPSTREAM_TRANSIT_AS1234.

 template peer-policy UPSTREAM_TRANSIT
  route-map UPSTREAM_TRANSIT_IMPORT in
  route-map UPSTREAM_TRANSIT_EXPORT out
  soft-reconfiguration inbound
  send-community
 exit-peer-policy

 template peer-policy UPSTREAM_TRANSIT_AS1234
  route-map UPSTREAM_TRANSIT_AS1234_IMPORT in
  route-map UPSTREAM_TRANSIT_AS1234_EXPORT out
  inherit peer-policy UPSTREAM_TRANSIT 1
 exit-peer-policy

The problem here is that even though I can specify inheritance and import/export route-maps, the child simply overrides the parent, so it does not become cumulative.

Example

Here's an example of what I'm trying to achieve.

First, I've defined two route-maps that I intend to be inherited by all BGP transit peers called UPSTREAM_TRANSIT_IMPORT and UPSTREAM_TRANSIT_EXPORT. In this:

• I've defined a prefix list called MARTIANS and want to block some basic martian subnets on all imports/exports for all transit and peering peers.
• I want to match against the NO_EXPORT BGP community and prevent export to all transit peers.
• Another prefix list for RFC1918 addresses, which should also not be exported or imported to a transit peer.
• In future I would plan to add matching of communities to do Set LocalPref, AS Prepend etc... For downstream customers, and I'd have a similar CUSTOMER_TRANSIT_IMPORT/EXPORT route-map for that.

Then, I've defined in my AS-specific route-maps I have something like:

• Only export prefixes to this AS the ones I want to announce
• Import all prefixes, or maybe only import domestic prefixes by matching a certain community.
• When importing prefixes from this peer, set a few BGP Informational communities so I can tell: Which transit provider did I get the prefixes from; which POP did it come from; etc.

I've got a full list of BGP communities I plan to work towards supporting on our network, in-line with what you might see from a larger transit provider, as we're working on growing our network.

So I want to make the configuration as easy as possible to make these kinds of changes as possible. As well, to allow us to easily impact routing policy changes as widely or narrowly as we need. So this is why I need to put some kind of hierarchical structure in place.

And the other reason is that I'm sure this must be a solved problem for larger ISPs. How can I do this?

Answer 1

In larger carriers it's actually a lot more common to actually generate the route-maps (and associated peering configurations) from some kind of provisioning database via a script. The idea is that things like series of includes, conditionals based on peer, etc are more easily achieved off the box. This is also a win because it enables provisioning consistency, allows for first-tier folks to provision without CLI access, etc.

This was the comment I made a while ago, reposted as an answer.

I'll also add that the other benefit of generating the route-maps is that variances in syntax (between vendors or within vendors using multiple operating systems) are normalized. It also ultimately allows for possibilities like downstream customers to edit their individual advertisements/policies in some kind of limited/sane way and to (hopefully) allow for careful, sane netizenship on the part of carriers to prevent bogus advertisements from making their way to the wider Internet (ok..this one is just wishful thinking!)

Answer 2

In XR (not sure about XE) you can do 'apply' in the middle of a route-policy. So you would do like:

route-policy test
apply generic-policy
if something then something else
end route-policy

And this would run 'generic-policy' in the middle of the 'test' route-policy. However, it looks like XE uses route-maps and not route-policies, so unfortunately that capability isn't available to you. route-maps in XE appear to be discrete objects and you can't chain them in that way.