27 Apr

Cloudflare hosting F root server

A few days some folks in internet community noticed Cloudflare AS13335 announcing F root server’s routes covering prefix



Above tweet shows that case is clearly not a mistake but rather some sort of arrangement between Cloudflare and ISC (which is responsible for F-root). There was another discussion on DNS-OARC mailing list here.

From our bgp.he.net tool, one can analyse route propagation for F root’s AS3557.


Here we can see that routes are visible from AS13335 to Telefonica AS13335. One can safely assume that AS12956 (considered to be a Tier1 / transit free network as per list here) is not a customer of Cloudflare. So the fact that still route is being announced to Telefonica gives an impression that AS3557 is downstream of Cloudflare.

It’s hard to say on the kind of arrangement as I still see many of instances of F-root are being hosted directly by ISC from hostname.bind query triggered via local RIPE Atlas probes in those regions. It could be that Cloudflare is hosting a part of this setup say in developing region where they have their caching PoPs. Yet to see a detailed blog post from Cloudflare about it. (I like their detailed blog!)

06 Apr

Route filter generation for Mikrotik RouterOS via IRR

A while back I posted about routing filter generation via bgpq3 for Cisco (ios and XR) and Juniper JunOS based routers. I have received a number of emails in last few months about automated filter generation for Mikrotik routeros. Since Mikrotik’s CCRs are getting quite popular across small to mid-sized ISPs.

So this blog post is about ways for generating filter config for a given ASN via IRR. One can use such logic with some kind of remote login mechanism like rancid (look for mtlogin here).

I tried building around bgpq3 but it seems more easy with another popular tool in the domain called IRR Power Tools. Once IRR Power Tools (IRRPT) is setup, it allows us to fetch prefixes based via Internet Routing Registries and also aggregates them.


So, for instance, let’s pick AS54456:


So now we have got prefixes and this includes both basic route objects as well as aggregates.


It offers a nice interface for generation of config for Cisco, Juniper, Extreme, Foundry and Force10. Example:


So I put a routeros instance in a VM to test and create config from their CLI. Config looks something like this:

This seems logical and can be scripted. So one can have a script to read the aggregate file and if aggregate says /24 one can put it directly in the filter else allow filter up to /24 from whatever range the pool starts and similar logic in IPv6.

So here’s the script:


So the script works except with a small bug in IPv6 aggregation which is the issue with IRRPT and I have reported same on their GitHub project page here.


An example of the script in progress for Cloudaccess AS54456:


Here’s another example of it in action with NPCI’s AS132351





Thinking to automate? 

The config between ***start*** and ***end*** can be pasted directly in CLI with Mikrotik. I would not recommend using it for manual filtering of any larger network. Automated filtering where filters are generated regularly makes sense but manual filtering without automation can be damaging. One can use a script like this for connecting to smaller networks. Also, IRRPR offers diff management via CVS (I hope they come up with git on that part) and it comes with an option to trigger email update so Network admins can know when to manually update. I would prefer that for non-commit based platforms since with Cisco ios or Mikrotik routeros it can be tricky to auto update prefix list. If one does no ip prefix list before triggering update it will cause a major noticeable impact. So ideal way to manage that on non-commit based devices would be to maintain a list of prefixes separately in the plain text file or a database and diff it against old one & only push for changes. Do-able and should be preferred that way instead of deleting and re-adding the whole list while automating.


Time to get back to work! 🙂