PeeringDB & Internet Exchange peering Part 3: generating router configurations

In the previous two posts we wrote about using PeeringDB to find information about potential peers and obtain the peering details using the REST API with a simple PHP script. (Please read those two posts first.) With this, it’s possible to automate parts of the peering request process.

Of course, requesting peerings is only the beginning. Once you’ve found a network willing to peer, you have to configure your routers. Doing this manually takes time and easily leads to mistakes. So today we present a script that provides router configurations to generate peering configurations.

However, our script only generates the configuration lines that are required to set up a peering. Before that can happen, a lot of configuration needs to be in place already. This is the base configuration in our example:

What we do here is define two peer groups for peers on the GNIX exchange: one for IPv4 and one for IPv6. As is usual with eBGP, the IPv4 sessions are only activated for IPv4 and the IPv6 sessions only for IPv6. Note that there are no issues using the same name for the IPv4 and IPv6 prefix lists, as those are define with ip prefix-list import … and ipv6 pref-list import … respectively. Both peer groups refer to the same route map localpref110 that is used to increase the local preference for peers to 110, so peering routes are preferred over routes learned from transit providers. (Configuring the localpref110 route map is left as an exercise for the reader.) Note that when you take a look at the configuration, it may look different, as IPv4-specific configuration is often placed directly under router bgp … rather than under the address-family ipv4 unicast heading.

With the base configuration in place, we’re almost ready to start generating peering configurations. This works by combining the details for our own AS with the details of another AS. We don’t request our own information from PeeringDB each time we generate a peering configuration, both because the PeeringDB API isn’t very fast and also so we can customize our own information. Rather, we set up a configuration file, which looks like this:

This file needs to exist under the name config.txt in the directory from where we run our script. The rtr_name line is the name for the router. In this case, there are two routers connected to two internet exchanges. However, if one router connects to both exchanges, simply change the name so it’s the same for both exchanges.

In order to save on typing, you can use the generateconfig.php script. Provide your own AS number as an argument and the script will generate the configuration information from PeeringDB. For instance:

And to create the config file:

A previous config.txt file is overwritten. Find the generateconfig.php script as well as the routerconfig.php script here:

With the configuration in place, it’s time to run the routerconfig.php script. This script takes as its input a router name, the AS number of a peer and optionally an MD5 password:

If we now run the script with the configuration file above in place and provide the AS number of a peer, this is the result:

The script finds all the internet exchanges that we and our peer have in common, and then generates peering configurations for the ones where the indicated router is present. (So it’s necessary to run the script for each router separately.)

The script outputs configuration lines that configure the desired peerings based on the IP addresses listed in PeeringDB, which you can copy and paste into the router configuration. It’s a good idea to double check the output, sometimes there’s outdated or incorrect IP addresses in PeeringDB.

The peer group reference is address family specific, hence we need to specify address-family ipv6 unicast first before we can set the IPv6 peer group.

It shouldn’t be too hard to modify the script to generate configurations for different types of routers. Have a look at the function genconfig_cisco that starts at line 127. This function is called from the function genconfig that starts at line 110, where you can add extra lines to refer to additional router types. Note that genconfig_cisco is called for “router types” cisco, quagga and brocade. For our purposes, Cisco and Quagga configurations are identical and Brocade only has a slightly different router bgp command syntax.

So have a look at these scripts and start configuring internet exchange peerings faster than ever.