Tag Archives: Routing

Route server feature-rich and automatic configuration

So, lately I’ve spent my spare cycles on a tool to automate route servers configuration and, finally, ARouteServer came out: “A Python tool to automatically build (and test) feature-rich configurations for BGP route servers.”

Actually I don’t know how this idea came to my mind, I’ve never run an Internet Exchange nor a route server. Simpl(y|istically) I thought that an open source tool, which everyone can contribute to, with some good builtin features and based on an abstract definition of policies which are automatically converted into BGP-speaker-specific configuration files would have been useful to the community.

Thought to be used with any BGP speaker, currently it has been focused on the BIRD implementation to shorten development times and to have something that could be usable. TL/DR: a couple of YAML files (general policies + clients list) and some configuration knobs bring to a BIRD configuration that offers RPKI/IRRDB validation, BGP filtering best-practices, blackhole filtering capabilities, announcement control via BGP communities and other features.

A live testing framework also allows to run custom scenarios to simulate a real clients/server environment where it’s possible to test the configurations produced by the script.

Reviews and testing needed

Now, as said previously, I’ve never run a route server: the project needs reviews, advices and testing from the real life. Anyone who wants to contribute or share his/her point of views is more than welcome! Please open an issue on GitHub or drop me a message for any comment.

Large BGP Communities playground

Lately, in the IETF Inter-Domain Routing (idr) area, various efforts are going on to push a (IMHO) winning idea to solve a 32-bits-wide problem: standard BGP communities are no longer enough to describe routing policies which involve 4-byte ASNs. For example, how can I tell my transit provider to not announce my prefixes to AS65551 (a 4-byte ASN) using a schema like 65500:nnn do not announce to peer nnn? Well, draft-heitz-idr-large-community proposes a simple and quick solution to this problem: Large BGP Communities (http://largebgpcommunities.net/ for more info).

Many vendors seem to like the idea, some of them have already published a working implementation, others plan to work on it in the (hopefully) near future.

In order to test current implementations and see them with my own eyes I wanted to build a Large BGP community playground, just a way to have the new code up & running quickly. Hopefully I will keep it up to date as soon as more vendors release their code.

GoBGP:

# gobgp neighbor 192.0.2.2 adj-in
Network Next Hop AS_PATH Age Attrs
203.0.113.1/32 192.0.2.2 65536 00:14:49 [{Origin: i} {LargeCommunity: [ 65536:1:2]}]

ExaBGP:

Thu, 15 Sep 2016 14:15:18 5 routes peer 192.0.2.3 ASN 65537 << UPDATE (1) ( 4) attributes origin incomplete as-path [ 65537 ] large-community 65537:3:4

It’s on GitHub: comments or suggestions would be greatly appreciated.

RIPE Atlas Tracepath v0.3.0

I released a new version of my web application RIPE Atlas Tracepath: v0.3.0. It reads results from RIPE Atlas traceroute measurements and shows Autonomous Systems that probes go through to reach the target.

UPDATE: new versions have been released since this post, with new features and bug fixes: please take a look at the project’s page on GitHub.

In the beginning it was a simple Python script/CGI; the new release has been totally rewritten, it’s now based on the D3.js visualization library and uses a more elegant Python backend based on Flask/WSGI.

Among the new features, probes are also displayed and linked to their origin AS; for those that completed the traceroute toward the target the avg RTT is also rendered in form of a scale of colors. Multiple Autonomous Systems can now be selected and moved together on the graph, in order to obtain the layout that best describes the analyzed scenario.

A demo can be found here. It only shows results from measurement ID 1674977, a traceroute from 50 probes all over the world toward www.ripe.net:

Graph of traceroute to www.ripe.net

More details can be found on the GitHub page; feel free to use/edit/fork/improve it as you whish!

A quick glance at longer than /24 IPv4 prefixes

Yesterday RIPE Labs announced a new test to measure propagation of longer than /24 IPv4 prefixes. The scope of these prefixes is to allow small allocations from the 23.128/10 net block that ARIN reserved to facilitate IPv6 deployment, but it could be impaired by filters and routing policies commonly deployed all around the net.

While looking forward to the RIPE results I couldn’t help glancing at the current situation as seen by a bunch of RIPE Atlas probes, so I performed some small tests on my own.

Read more …

RIPE Atlas: a script to show ASes traversed in traceroute

I released a small Python script which reads results from RIPE Atlas traceroute measurements and shows Autonomous Systems traversed by probes to reach the target: ripeatlastracepath.

UPDATE: the version of RIPE Atlas Tracepath that this post refers to is outdated. A new, totally rewritten version has been released.
The old version of this tool has been moved in the GitHub old_style branch

It uses a library that I wrote to cache RIPEstat results about IP addresses details (ASN, prefix, …), in order to improve performance and to avoid a flood of requests: ipdetailscache.

More details can be found on my GitHub profile page.

A demo can be found here. It can’t be used to process other measurements, it only shows results from measurement ID 1674977, a traceroute from 50 probes all over the world toward www.ripe.net. You can drag&drop ASes to build the layout that best describes your scenario and, once done, you can “save” the graph for later usage. In this demo the “Load graph” button gives a preset of JSON data representing the example graph below:

Graph of traceroute to www.ripe.net

These scripts are not so elegant, but do the job! 😉 They are on GitHub.com, feel free to use/edit/fork/improve them as you whish!