Rethinking Security Policies for IPv6

You’ve been assigned the task of deploying adding IPv6 to your network so you can finally feel the dual stack warm and fuzzies. The process for doing so should be something along the lines of:

  • Put some of those just-too-long-to-memorize IPv6 addresses on your router interfaces.
  • Choose an IPv6 capable routing protocol to share the prefixes throughout your network.
  • Clone your IPv4 security policies and ACLs to permit hosts on the public Internet to access your servers.

Easy, right? Those first two items are a step in the right direction, but the third item is most likely going to cause you some trouble. I’m guessing that somewhere in an ACL on your network there’s a couple of statements that look similar to this:

The ACL is probably not that simple, but we’ll keep it short for discussion’s sake. The most important part here is that TCP port 80 traffic is allowed to two hosts by IP address destination, and TCP port 21 is allowed to one host also by IP address destination. These statements work because you know exactly which IP addresses are configured on the servers and they’re most likely the only IP address configured on the servers’ NICs.  This is where IPv6 changes everything you know about security policies.

Continue reading

Monitor your BGP Advertised Routes with Paramiko

This post moves back to the basics and covers how to perform screen scraping using python and a helpful SSH library called Paramiko. Although the example below is about a specific task of checking the BGP outbound advertised routes of a device, the script can be reused to perform screen scraping for any output that the device offers. This example is for a Cisco IOS device, but it should work on many devices with a few tweaks in the commands sent and regex strings.

I’ve used inline comments for the explanations in the example below, but feel free to ask questions about this example or screen scraping other specific data. Here’s the GitHub Gist version if you want to fork and make your own changes. Continue reading

Processing and Storing BGP Messages in MongoDB

This entry is part 6 of 6 in the series Influence Routing Decisions with python and ExaBGP

Now that you know how to advertise prefixes to BGP peers with ExaBGP and are familiar with how to use this to influence traffic in your network, let’s change gears and look at processing BGP messages between ExaBGP and its peers. Since ExaBGP uses JSON for message data, I figured it would be a good opportunity to use MongoDB so the message information can easily be stored into a database for data collection and analysis.

ExaBGP & MongoDB

Continue reading

Control BGP Advertisements to eBGP peers with ExaBGP

This entry is part 5 of 6 in the series Influence Routing Decisions with python and ExaBGP

We know that ExaBGP can be used to inject BGP routes into an AS that you control. It’s a very helpful feature that allows you to automate reachability and traffic flows within your network. But what if you want to you ExaBGP to influence what is advertised, or in this case, not advertised to external peers that are not willing to peer with your ExaBGP service?

BGP PeeringsOur scenario is this: We have a prefix attached to our SW. The CE router learns about this prefix from SW via OSPF, and then advertises the prefix out to the Internet via the PE router. This prefix is anycasted so it is also advertised out of a different location. In order to withdraw the prefix from the PE and therefore the Internet we would need to manually filter the prefix outbound via route-map, or stop the advertisement from the SW which would also remove the resource from local resources. Continue reading

Give ExaBGP an HTTP API with SimpleHTTPServer or Flask

This entry is part 3 of 6 in the series Influence Routing Decisions with python and ExaBGP

We’ve covered how to setup ExaBGP and peer with a router, and then how to use python to add  and remove advertised routes in BGP either with static definitions or dynamically through health checking. There may be some of you out there with some sort of application that is already monitoring routes and you’re trying to figure out how to connect it with ExaBGP for the actual interaction part? Well, what if we add an HTTP API to ExaBGP to give programmatic access to ExaBGP from some external utility? I’ll go over two ways to do this using the python built-in SimpleHTTPServer or Flask.

Using SimpleHTTPServer

This option is great since you don’t need to install any extra modules. It seems to be pretty lightweight and should be enough for some basic HTTP interaction with ExaBGP. The basic functions that we need this API to do are receive a form via HTTP POST and print that to STDOUT. Since ExaBGP is executing the python script, the STDOUT output will be visible to the ExaBGP process. After the ExaBGP command is printed, we’ll return the command to the browser as confirmation that the call was successful. Here’s the example:

Using Flask

If you have bigger plans for the HTTP side of things and want to work with a web framework like Flask, this example is for you. The biggest difference is that you will have to install Flask and its dependencies, although that’s easy:

$ pip install flask

Now we’ll create a Flask file to listen for prefix commands via HTTP POST calls and print them to STDOUT so ExaBGP can do its magic:

Before you run off and put this on your production systems I have a couple disclaimers:

  • This script uses the built-in Flask debug HTTP server. It’s fine for lab use, but I would use gunicorn and nginx for real heavy lifting.
  • The script doesn’t do any validation of the command. A better script would make sure it’s a valid command and prefix.
  • Flask defaults to listening on the localhost address on TCP port 5000. You can change this though and I highly recommend reading Flask’s QuickStart article to familiarize yourself with the many options.

Hooking the HTTP API up to the ExaBGP process

Update the conf.ini file to run this script instead of our previous health check example:

And now when we run $ exabgp conf.ini, you’ll see the confirmation of running the python script at the end of the output, along with the debug output of both Flask or SimpleHTTPServer:

Once either HTTP service is running (somewhat wrapped by the ExaBGP process), we can make HTTP POST calls via command line (curl, wget) or via a GUI HTTP tool (Postman). I’ll show a quick example of both:


Postman:Postman - HTTP POST


When we run show bgp on the router, we can see our advertised network:

So, there’s a real quick and dirty way to allow external calls to ExaBGP for your RIB manipulation. The next post will cover more advanced peering and advertising options with ExaBGP.

Using service health checks to automate ExaBGP

This entry is part 2 of 6 in the series Influence Routing Decisions with python and ExaBGP

If you haven’t read the intro post to this series, Getting Started with ExaBGP, check that article out first as this post will be expanding on the previous example to show how to use python for more automated interaction with ExaBGP.

The first example I’ll cover is using a basic health check test to determine if a route should be announced or withdrawn from BGP. Here is our python script with comments inline:

Continue reading

ExaBGP and python: Getting Started

This entry is part 1 of 6 in the series Influence Routing Decisions with python and ExaBGP

I’m really excited about these next few posts. I’ve been doing some research on BGP and automating routing decisions with python, which led to my discovery of ExaBGP. ExaBGP is dubbed “The BGP swiss army knife”, and I’m early in my experimentation with this tool, but it seems to be a very easy way to peer with your BGP routers and control the advertisement of networks.

This post will cover basic setup of ExaBGP and peering with a router, as well as how you can tie in python to present control for the advertisement of routes. The next post will use the Flask web framework to offer a simple HTTP API for adding/removing routes. I hope the following posts will be along the lines of receiving the BGP UPDATE messages from peered routers to monitor and analyze advertised networks.

Continue reading

OnePK – Configuring and Assigning an ACL

This entry is part 5 of 5 in the series Getting started with Cisco OnePK

During my research of the ACL module of OnePK I found some interesting behaviors. I think this feature isn’t fully cooked as it has some definite room for improvement. The ACL module (found in onep.policy) doesn’t have a way to interact with existing ACLs and ACEs on an IOS device. The ACLs seem to be intended for on-the-fly ACL configuration but with a couple caveats:

  • Applying an ACL to an interface overwrites the existing ACL for that direction. Interfaces must play by the rule: ‘One ACL per direction’.
  • Make sure to use OnepLifetime.ONEP_PERSISTENT to keep ACLs applied after the OneP session is disconnected.

First I’ll cover ACL management with OneP, and then I’ll use the onep.vty module to show how to workaround some of the shortcomings.

Continue reading

OnePK – Pulling information from an IOS device

This entry is part 3 of 5 in the series Getting started with Cisco OnePK

The first logical step in controlling your network with python is to have a way of pulling important information from your network devices. This post will cover the gathering of interface and routing table information. In order to keep examples short and to the point, they  will use the script as a connection module as discussed in the second post of the series. My goal for these examples isn’t to show what you should have in your OnePk apps, but rather to introduce you to basic concepts so you can see how the different pieces work and how you might be able to get the information necessary in your applications. Continue reading