4

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?

  • 2
    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. – rnxrx May 15 '17 at 2:25
  • @mxrx Thanks for this. I had thought about that - and surely you're right. I was just hoping there was a middle-ground before I went deploying an automation framework for total of 4 routers. So extrapolating from this, every peer would get their own unique route-map? And it's just up to automation to inject all the standard stuff into each one? That way (because each peer has their own route-maps) things like setting custom communities or localprefs per peer can still be done on a case-by-case basis in each route-map. Would that be a fair evaluation? – Geekman May 15 '17 at 12:08
  • @mxrx I guess I'm trying to find a BGP config that is a good balance between being flexible for day-to-day operations (temporary changes for troubleshooting etc) and being able to roll-out over-arching changes on a growing network. – Geekman May 15 '17 at 12:12
  • It doesn't need to be an overarching framework. These things tend to start as really simple scripts that pop out a standard template with certain values filled in (like the AS of the customer, for example). So - in your case the script might bring together the contents of UPSTREAM_TRANSIT_IMPORT and UPSTREAM_TRANSIT_EXPORT (..pulled from include files) with some specific entries for the customer's specific ASN. It doesn't mean you have to set up a whole relational database - just simple text processing. You can even use copy-and-paste into the router to keep it simple. – rnxrx May 16 '17 at 1:09
  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer. – Ron Maupin Aug 9 '17 at 18:47
4

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!)

0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.