ASR9K Upgrade and Route-Policy for Service Provider Upstream Peers

[matt.malott]

Hello!

Apologies, as this will likely be a lengthy post. I work for a regional ISP with multiple upstream internet connections and multiple customers that BGP peer with our AS and share their prefixes to the internet through us. Currently, we have an as-path ACL that is applied to our internet providers' BGP sessions in the outbound direction. This way, we can prevent one upstream provider from using our AS as a transit AS to another of our upstream provider ASes. For example, if our AS is 100, our internet provider's AS is 300 and a customer's AS is 200 we would apply this ACL to our ISP with AS 300.

ip as-path access-list 1 permit ^$ (locally originated routes)
ip as-path access-list 1 permit ^100_[0-9]*$ (I think this allows for advertisement of prefixes learned from our own AS via iBGP)
ip as-path access-list 1 permit ^200(_200)*$ (allows for advertisement of customer with AS 200's prefixes and for them to use prepends if they choose)

I inherited this setup, but it seems mostly okay and has been working for us for quite some time in our current ASR1K border routers. The downside is that we have to edit this ACL every time a new customer wants to BGP peer with our AS, which has some impactful potential if a mistake is made.

So, we recently purchased some shiny new ASR9K devices to replace our ASR1Ks in this role. My plan is to eliminate our "border" network, which currently peers with an MPLS L3VPN (VRF INTERNET) as an eBGP peer. I'd like to create a new VRF with a new L3VPN named BORDER and leak a default route into our VRF INTERNET. This way, I can take a full routing table on border devices, but keep the full table from populating on less powerful devices without doing a ton of filtering on a neighbor by neighbor basis. I think I have most of the configuration figured out for this (I'd love to hear thoughts/suggestions though), but the RPL is confusing me a little. I'd like to come up with a route-policy that allows us to advertise prefixes learned from customer ASes but not from our upstream internet providers. I have an untested theory as-path ACL that I think would accomplish this below. it would be applied to our internet peer's BGP session in the out direction. Assume the same ASes as the earlier example:

ip as-path access-list 1 deny ^300_$

ip as-path access-list 1 permit ^$

ip as-path access-list 1 permit ^100_$

ip as-path access-list 1 permit ^[0-9]_$

Am I correct in my theory that this would allow all prefixes learned from all ASes would be advertised to this peer EXCEPT prefixes learned from AS300? If so, this would allow me to peer with customers with editing this ACL at the border every time.

Additionally, I understand that these ACLs, our route-maps, and their prefix-lists would have to be configured using RPL. I am aware of the if/then/else ability of RPL, which is awesome. However, I would need a way to deny prefixes learned from certain ASes (internet providers) first, which can be done with an AS-set and if/then statement, but after that, I would need a separate if/then statement to allow the prefixes and ASes that I do want to advertise. Could someone more experienced than I provide some insight into how this is typically done in an SP environment? I also understand that my current setup may be able to gain efficiency, so I would love to hear suggestions with regard to best practices in this area.

If you've made it this far, thank you so much for your time and help!

[decode.chr13]

Hi Matt,

1) VRF: border, with 0/0 in it is good idea. It would be good to also have a pair of RR, to be able to send full table to your customers.

2) For RPL you can have a very useful and quick training with examples here:

https://community.cisco.com/t5/service-providers-documents/asr9000-xr-understanding-and-using-rpl-route-policy-language/ta-p/3117050

Don’t be afraid or A9K. :-)

They are much better choice then A1K for SP.

Good luck

[matt.malott]

I couldn't agree more! I am pretty familiar with basic MPLS features on the ASR9K, but we haven't needed RPL until now, so I am just starting the learning curve there. Thank you very much for the information! I will take a look and soak up as much as possible!

[decode.chr13]

This is a bit of nonsense to me, but I might be wrong. 

ip as-path access-list 1 deny ^300_$

  * in normal setups you will never be able to send routes to your upstream with his own AS. So, I find this useless. 

ip as-path access-list 1 permit ^$

  * Ok, but again normal behavior of BgP

ip as-path access-list 1 permit ^100_$

  * I don’t think you see that in your network. That 100_ is visible on your provider side. 

ip as-path access-list 1 permit ^[0-9]_$

  * this is “permit any any” :), so again useless. 

For strict customer control you must allow AS + prefixes for each customer. This is public info found in databases (ripe, radb)

In your setup your setup, if AS200 announces 8.8.8.0/24 you allow it. This will upset about half planet if propagation succedes :-)

[matt.malott]

I see what you mean. We would apply this ACL to the outbound BGP config for the other ISPs that we peer with (not AS300). I only included one internet provider in my example, which was a mistake on my part. So, a better example would be to apply the same list to a different provider with AS400. The "permit any" lines in the list are essentially to get around the explicit deny. I believe the thought was that we need the ^100_[0-9]$ to advertise routes with our own AS in the path for iBGP purposes, but now that I think of it, we really don't need this. We also have a "deny private space" prefix list applied to prevent private space coming in from our upstream providers so that we only get a public internet routing table from each of them. I left this detail out in my original post as well.

As far as customer control, this list is for the upstream neighbors we peer with. We have have a prefix-list/as-path ACL tied to a route-map on our access equipment (ASR920/NCS540) to filter inbound routes from our customers to prevent them from advertising the universe to us. Generally, customers only want a default route, so this can be done on our access gear. Customers wanting a full table we have to use a L2VPN of VPLS to get them to a border device to facilitate this. We also use a prefix-list with our as-path ACL from above to make sure that we only advertise what we want. This way, even if a customer advertises the universe to us AND our inbound filter is wrong, the route won't be propagated to our upstream peers.

Also, I am learning a great deal already from the post you provided earlier. Thank you very much for the info. I don't know how I missed it in my initial search!