Thursday, February 12, 2015

Experimenting with the CSR1000v REST API

This all started because we occasionally want to block traffic from an IP address or two for a short time. Our firewall is a pain to configure for this sort of thing: adding a drop for a single IP address literally takes 10 minutes. You have to open a fat client, create an object, add the object to a group, save the config, verify the config, push the config, etc.

You configure a "trigger router" that speaks iBGP with the rest of your BGP-speaking routers (usually your Internet edge or transit routers), but doesn't participate in traffic forwarding.

On each edge/transit router you configure a static route to null0 for an unused /32, usually 192.0.2.1: ip route 192.0.2.1 255.255.255.255 null0

On each edge/transit router you configure loose-mode unicast RPF filtering on your outside interfaces: ip verify source reachable-via any. This has a special property: packets from any source for which the uRPF next-hop resolves to Null0 will be dropped.

When you want to drop traffic from a particular host (e.g. 1.1.1.2), you configure a static host route on the trigger router and redistribute it into BGP by matching its tag: ip route 1.1.1.2 255.255.255.255 null0 tag 666.

The effect of this is that the edge routers see the iBGP route to the "bad" address as a /32 with a next-hop of 192.0.2.1. Because the next-hop for 192.0.2.1 recursively resolves to null0, the loose uRPF feature drops traffic from the bad host at the edge.

In my case, I wanted to use the CSR1000v as the trigger router. (At this point, somebody's thinking "Why not use a Linux BGP daemon?") That's a valid approach; I just want to use the CSR1000v.

You can't set tags either. Furthermore, the same thing holds true for static routes with the "name" argument. (Incidentally, the error message seems to indicate that the IOS XE API is written in Python.)

The problem with this is that without tags, there's no convenient way to filter the RTBH black hole trigger routes at the time of redistribution. You can't set route-maps on BGP network statements via the API either, so no joy there.

The best option to me seems to be to redistribute all static routes, but filter on prefix-length rather than tag:

But then you have to make sure that you never have any /32s that aren't trigger routes... a strategy which is prone to configuration mistakes.

Because SRTBH seems like a natural use-case for API automation, I hope Cisco fixes this soon.

[added]
Other interesting things I've found: the static route configuration API doesn't allow you to add equal-cost static routes. For example, if I already have a 1.1.1.5/32 route and I add another one, I get a 404:

The same thing goes for adding other items: I tried adding a name-server twice, and got a similar error. I would think that the API would be idempotent where possible (such as when adding a duplicate nameserver), and require clarifying attributes otherwise. With equal-cost static routes for example, it could throw a 40x unless an extra attribute like {"allow-equal-cost":true} is present in the POST request.

AWS Training in Bangalore - Live Online & ClassroommyTectra Amazon Web Services (AWS) certification training helps you to gain real time hands on experience on AWS. myTectra offers AWS training in Bangalore using classroom and AWS Online Training globally. AWS Training at myTectra delivered by the experienced professional who has atleast 4 years of relavent AWS experince and overall 8-15 years of IT experience. myTectra Offers AWS Training since 2013 and retained the positions of Top AWS Training Company in Bangalore and India.

IOT Training in Bangalore - Live Online & ClassroomIOT Training course observes iot as the platform for networking of different devices on the internet and their inter related communication. Reading data through the sensors and processing it with applications sitting in the cloud and thereafter passing the processed data to generate different kind of output is the motive of the complete curricula. Students are made to understand the type of input devices and communications among the devices in a wireless media.