Category: News

INEX’s Shiny New Route Servers

Copy of an article I wrote on INEX’s own blog for longevity – original published here on April 10 2019.

In this article, we talk about the new route servers that we deployed across all three peering platforms at INEX during February 2019 and, particularly, RPKI support.

Most route server instances at internet exchanges (IXPs) perform prefix filtering based on route/route6 objects published by internet routing registries (IRRDBs). INEX members would be used to creating these through RIPE’s database. However there are many other registries and the data quality of some of these IRRDB objects is often poor, with problems relating to missing, stale and incorrectly duplicated information.

A typical IRRDB entry would resemble the following:

route:          192.0.2.0/24
descr:          Example IPv4 route object
origin:         AS65500
created:        2004-12-06T11:43:57Z
last-modified:  2016-11-16T22:19:51Z
source:         SOME-IRRDB

RPKI

RPKI is a public key infrastructure framework designed to secure the internet’s routing infrastructure in a way that replaces IRRs with a database where trust is assigned by the resource holder. The equivalent of a route object in RPKI is called a ROA (Route Origin Authorisation). It is a cryptographically secure triplet of information which represents a route, the AS that originates it and the maximum prefix length that may be advertised. An example of an IPv4 and an IPv6 ROA would be:

( Origin AS,  Prefix,         Max Length )
( AS65500,    2001:db8::/32,  /48        )
( AS65501,    192.0.2.0/24,   /24        )

ROAs are typically created through your own RIR (so, RIPE for most INEX members). These RIRs are called trust anchors in RPKI. RIPE have created an extremely easy wizard for creating ROAs through the LIR Portal.

To implement RPKI in a router, the router needs to build and maintain a table of verified ROAs from the five RIRs/trust anchors. The easiest way of doing this is to use a local cache server which pulls and validates the ROAs from the trust anchors and uses a new protocol called RPKI-RTR to feed that information to routers. Currently there are three validators: RIPE’s RPKI Validator v3; Routinator 3000 from NLnetLabs; and Cloudflare’s GoRTR. INEX currently uses the former two.

RPKI validation of a route against the table of ROAs yields one of three possible results:

  • VALID: a ROA exists for the route and both the prefix length is within the allowed range and the origin ASN matches.
  • INVALID: a ROA exists for the route but either (or both) the prefix length is outside the allowed range and/or the origin ASN is different.
  • UNKNOWN: no ROA exists for the route.

UNKNOWN is a common response as the database has only a fraction of the prefix coverage as IRR databases do. We are now in a multi-year transition from IRR to RPKI route validation while ROAs are created.

Bird V2

As well as RPKI support, we have also upgrading all route servers to Bird v2.

This is a significant rewrite to Bird which, for v1, maintained separate code and daemons for IPv4 and IPv6. Bird v2 merges these code bases and also introduces support for new SAFIs such as l3vpns / mpls.

Overall, the configuration changes required were minimal and INEX continues to run separate daemons of Bird v2 for IPv4 and IPv6 daemons. Route servers are CPU intensive and separate daemons allows for maximum stability, keeps the configuration clean and fits into the existing deployment processes we have built up with IXP Manager.

Route Server Filtering Flow

Our work on the new route servers will be released to the community as part of IXP Manager v5 shortly. The new filtering flow is enumerated below. One of the key new features is that if any route fails a step, we use internal large community tagging to indicate this and the specific reason to our members through the IXP Manager looking glass (more on that later).

  1. Filter small prefixes (>/24 for IPv4, >/48 for IPv6).
  2. Filter martian / bogon ranges.
  3. Sanity check to ensure the AS path has at least one ASN and no more than 64.
  4. Sanity check to ensure the peer ASN is the same as first ASN in the prefix’s AS path.
  5. Prevent next-hop hijacking (where a member advertises a route but puts the next hop as another member’s router rather than their own). We do allow same-AS’s to specify their other router(s).
  6. Filter known transit networks.
  7. Ensure that the origin AS is in set of ASNs from member’s AS-SET. See below for some additional detail on this.
  8. RPKI validation. If it is RPKI VALID, accept the route. If it is RPKI INVALID then filter it.
  9. If the route is RPKI UNKNOWN, revert to standard IRRDB filtering.

Regarding step 7 above, an AS-SET is another type of IRRDB database entry where a network which also acts as a transit provider for other networks can enumerate the AS numbers of those downstream networks. This is something RPKI does not yet support but it is being worked on – see AS-Cones.

Lastly we have enhanced the BGP large community support to allow our members request as-path prepends on announcements to specific members over the route servers. For these and more supported communities, see the INEX route server page here.

Bird’s Eye and the Looking Glass

As well as IXP Manager, INEX has also written and open sourced a secure micro service for querying Bird daemons called Bird’s Eye. IXP Manager uses this to provide a web-based looking glass into our route collectors and servers. We have recently released v1.2.1 of Bird’s Eye which adds support for Bird v2.

We have greatly enhanced IXP Manager’s looking glass to support both Bird v2 and the large communities we use to tag filtered reasons. You can explore any of INEX’s route servers to see this yourself – for example this is route server #1 for IPv4 on INEX LAN1. When members log into IXP Manager they will also find a new Filtered Prefixes tool which will summarise any filtered routes across all 12 of INEX’s route server instances.

More Information

We have spoken about this at a number of conferences recently:

Migrating Legacy Web Applications to Laravel

I gave a talk on migrating legacy web applications to Laravel at last year’s Laravel Live UK conference in London. Those that rated it gave it high marks which is always brilliant feedback to receive.

2018 was Laravel Live UK’s inaugural conference and it was a packed house. They’ve just announced the dates for 2019 and I would strongly recommend attending for anyone using or interested in use Laravel.

Following the conference, I wrote up the talk as an article and it has just been published in the March 2019 edition of php[architect]. This is an excellent magazine which I’ve subscribed to for a few years now – the digital edition is very reasonable and comes as a DRM-free PDF onto an app on your phone/pad or downloaded to your computer.

As it happens, they chose this article as the teaser for this issue and so it is freely available online here and downloadable as a PDF here. But seriously, if you are a PHP developer, you need to subscribe to this magazine.

Lastly, if you are interested in the slide deck from the conference, you can download them here – but the article is a much better way to understand this material.

Switching Between PHP Versions on MacOS

When switching between different PHP projects (or different branches of one PHP project), you often need to switch PHP versions. Particularly as older libraries will not run on newer versions of PHP. After losing patience with how the otherwise excellent Homebrew handles this, I stumbled upon this super-useful tool: switch-php.

This seems to have been written for PHP developers and integrates brilliantly with Laravel Valet. Here’s an example of switching from PHP 7.3 to 7.2:

$ php -v 
PHP 7.3.0 (cli) (built: Dec  7 2018 11:00:11) ( NTS ) 
Copyright (c) 1997-2018 The PHP Group 

$ switch-php 7.2 
Valet stopped ✔ 
PHP switched ✔ 
Valet started ✔ 

You are now using PHP 7.2.13 

$ php -v 
PHP 7.2.13 (cli) (built: Dec  7 2018 10:41:23) ( NTS ) 
Copyright (c) 1997-2018 The PHP Group

Three Rock in the Fog

A quick New Year’s walk up to Three Rock and the Fairy Castle in the fog this morning.

  • You can normally see Dublin here!
  • The Fairy Castle.


Star Trek: Voyager – The 2016 Rewatch

I watched the first episode of Star Trek: Voyager in my Junior Cert year in the function room of a pub with the local Star Trek fan club in early 1995. It was recorded in the US on a NTSC video tape, mailed over to the club runners in Limerick, copied and sent to local clubs around the country and then played on a compatible VCRs.

It was a different era – but, on reflection, a much more sociable one. These episodes, straight from the US, were enjoyed in groups with a few drinks. The new upcoming series will must likely be watched instead in darkened rooms, alone and as downloaded via BitTorrent (every bit as (il)legal as our Voyager viewing).

Voyager came around at a fairly hectic time for me. Started in my Junior Cert year, season 3 hitting my Leaving Cert year and the remaining seasons clashing with a fairly hectic college social life. I don’t think I ever missed an episode but it was certainly a non-linear erratic viewing. It left me with an overall poor impression of the show. So much so that I’ve never rewatched the series in order and in a short space of time until just these last two months. Almost twenty years later.

And that’s a pity. On rewatching, it was a great show. It also bodes well for what Bryan Fuller will do with the new series, Star Trek: Discovery. 

So, some early, unedited and initial reflections on the rewatch:

  • Janeway was a great captain. Played by a great actor, Kate Mulgrew, who was able to perfectly balance strength and compassion. Sisko will always win it for me but, bloody hell, Janeway is battling for number two pretty strongly right now in my head. I haven’t watched TNG in a while which may help, but, still, credit where credit is due here.
  • Why the fuck was the ship never at warp? This is a crew trying to get home. But every opening shot has them out of warp before diverting to check out whatever this weeks interest was. Sure, it was a financial decision as green screen f/x are expensive. But surely you can re-use the exterior of the ship at warp to set the scene ad infinitum and then don’t put the characters at a window! This broke my heart in nearly every episode. 
  • Character mental breakdowns: there were a few times were characters were effectively given mental breakdowns for the purposes of a story. This happens too often in Star Trek I think. For example Tom Paris in Thirty Days. The biggest culprit of all was Janeway in Equinox. Yeah, I get she’s pissed off at another Star Fleet captain going over the edge (massively). But turning her into an crazed Ahab (with his obsessive quest to catch the whale) was not credible. Nor was nearly-torturing a crewman and confining Chakotay to quarters believable. It just didn’t work for me.
  • The Doctor was brilliant. This was entirely down to the fantastic acting of Robert Picardo. I felt the writers discovered this themselves as we went through the first two seasons. The doctor episodes were always a joy.
  • The Year of Hell: I imagine some hoped for seven years of this. I did too before my rewatch. It was always my biggest criticism. This two-parter is one of the best episodes of the series. I’m not sure how much influence Ron Moore had on this (he’s not credited as a writer). But he went onto create the re-imaging Battlestar Galactica which – when I watched it – felt like what Voyager could have been.
  • The Borg. In the beginning it felt a bit lazy to bring them in. I don’t recall if it had been established in TNG is they were from the Delta Quadrant or not. If it had, it wasn’t lazy. But, if not, then vice-versa. In the end the Borg added to Voyager (none the least with Seven of Nine) but also the Borg Queen / Janeway playoffs.
  • The finale: ah, sigh. I just found the use of time travel a bit lazy here too. The Admiral/Captain playoffs were great as were many other elements. But, I don’t know, it would have been nice to solve it themselves without another time travel episode. And, speaking of mental breakdowns, I’m still not convinced Janeway’s character would have broken the temporal prime directive in the first place.
  • Q. Should never have made an appearance in Voyager as every time every viewer was just screaming “send them home!”.
  • Lastly, like the other series’: too much reliance on the holodeck for story telling. You’re in space for crying out loud! Plenty of stories out there.

This is a post in the series Daily January 2016 – generally rushed and unedited.

Personal Profile for INEX

I was asked to write a personal profile for INEX in <= 300 words. Reproduced here.

If you want to confuse Barry, ask him where he’s from: born in Cork, spent his formative years in Galway and married into Dublin. He got a honours degree in Maths, his first love, from NUI, Galway in 2001 and went on to do four years research in information theory in UCD’s Computer Science department.

In 2005 he took a job with imag!ne to help build their ADSL broadband service from scratch to a position where it supported tens of thousands of subscribers. Barry branched out on his own in 2007 when he formed his own consultancy business, Open Solutions, which continued working with imag!ne as well as building up a portfolio of network, VoIP and web application development customers.

It was 2008 when Nick Hilliard, INEX’s CTO, approached Barry to provide a couple days operational support to INEX. Little did Barry realise what a huge part of his life INEX would become – both here in Ireland supporting INEX’s infrastructure and membership but also as part of the larger European and international IXP community.

Barry is the lead developer of IXP Manager (http://www.ixpmanager.org/) – a full stack management system for IXPs which includes an administration and customer portal; provides end to end provisioning; and both teaches and implements best practice. INEX is very proud to say that this project is now in use at over 33 IXPs and has grown legs of its own with the wider community sponsoring a full-time developer.

INEX has always been happy to help other IXPs and, through our relationship with the Internet Society (ISOC), RIPE and Euro-IX, Barry has travelled to countries with a less developed internet infrastructure to advise on best practice, has delivered a number of IXP Manager workshops and contributes to policy development.

Installing PHP7 on FreeBSD 10

Specifically, at time of writing, it’s PHP 7.0.3 on FreeBSD 10.1. Note that I would expect PHP7 to be officially available in FreeBSD and would hope that these instructions become redundant fast. Check for this with:

pkg search php70

At time of writing, the port we’re looking at is in development on Github here and it was announced on the FreeBSD ports mailing list here.

As you may gather from the above, PHP7 is available via ports only, not pkgng as yet. To install, proceed as follows:

portsnap fetch
cd /usr/ports
git clone https://github.com/miwi-fbsd/miwi-ports.git git-ports-php7
cd git-ports-php7
rsync -av ./* ../
portsnap fetch extract

Now remove your existing php:

pkg info | grep php
pkg remove ... ... ...

And install php70:

cd /usr/ports/lang/php70
make
make install

Follow this by installing any other PHP extensions you require. Note that in /usr/ports/Mk/bsd.php.mk I had to add the following at line 283 for database/php70-pdo_mysql to install:

_USE_PHP_VER70= ${_USE_PHP_ALL} phar sqlite3

Also note that Apache 2.4 is required. But who’s using 2.2 these days? Right..?