06 Feb

Alternate to IRINN IRR manual entry / ALTDB

IRINN (Indian Registry for Internet Names and Numbers) is a NIR (National Internet Registry) for India operating under the APNIC RIR (Regional Internet Registry). IRINN is run and managed by NIXI. It’s a decent NIR and was set up in 2012. Indian organisations have the option to either maintain relation with APNIC or with IRINN.

A large number of small networks prefer IRINN because it’s annual charges are 25000 INR / $351 USD against APNIC’s membership fee which is over 2x of that.

There are a couple of key disadvantages of using IRINN:

  1. The membership portal is rather limited and the entire process of creating, updating route objects as well as AS SETs via IRINN is rather a manual process. One raises a ticket and during working days IRINN processes those requests & updates the IRR entries. In backend entries just go in the APNIC’s IRR.
  2. Process of creating/updating/maintaining RPKI ROAs is also rather manual.

As of now there’s not much one can do about #2 other than just following manual process by opening a ticket with IRINN but for #1 if you have a challenge that it’s rather slow to update/change because it is a manual process.

Introduction to IRR’s

IRR or Internet Routing Registry is just the public register for BGP related activities. Logic is that one first publishes what one wants to do and then does it. So I can say I want to originate 2402:b580::/32 from AS58901, publish it one of the publicly visible registers (known as IRRs) and then I actually announce the pool.

So who can run an IRR?

Anyone can! IRRd software is open source and one can use it to set up an IRR server. The old and most widely used IRRd is available here and the new version of IRRd (IRRd version 4) is here which is quite advanced, offers many excellent features. What makes IRRs run by APNIC, ARIN, RIPE, RADB etc popular is the fact that RADB mirrors them all and a large number of tools default to RADB for generating the filtering config. As per data available here, RADB mirrors 23 other IRRs besides serving from its own database. So one can get entry to either of these available IRRs based on relation one has with them for creating the route objects or AS SETs and it just works.

ALTDB

Many people know of RADB which is run by merit. It’s a paid option and many networks use that for maintaining route objects. There’s also a free IRR called ATLDB. It’s free to create an account on it and approval of account is a manual process but once approved, creation/updation of route objects as well as AS SETs is all automated and works via email with a specific syntax. Unfortunately, there’s not much on the ALTDB website except a whois lookup tool, however, if you want to read in detail about IRR as well as using ALTDB, the Fremont Cabal Internet Exchange has an excellent guide on that (here).

The basic logic here is to do following: Create a maintainer object > Define routing policy of the ASN (peers, transit, downstream etc) > Create AS SET (if you have BGP downstream customers) > Create route objects for your IPv4 and IPv6 prefixes > Publish your ASSET on PeeringDB. Again one can follow the detailed steps given on the FCIX website.

Here’s an example of it in action for a test prefix of the pool I use:
2402:b580::/32

As of now, there’s no corresponding route object with it. Here’s a quick check on RADB:

anurag@devops01 ~> whois -h whois.radb.net 2402:b580::/32
%  No entries found for the selected source(s).
anurag@devops01 ~>

As of now, there’s no route object for it. Let’s say I want to start originating from AS58901, so I will put following in a plain text mail and send it to ALTDB email ID (auto-dbm@altdb.net) which processes these requests automatically.

route6:     2402:b580::/32
descr:      Anurag Bhatia R&D Network IPv6 Pool
origin:     AS58901
mnt-by:     MAINT-AS58901
changed:    me@anuragbhatia.com 20200205
source:     ALTDB

It’s important to send email in cleartext. One can check how to do that in a specific email client or web interface one uses. For Gmail the option is here:

I get following in reply from ALTDB:

And now query to RADB gives us:

anurag@devops01 ~> whois -h whois.radb.net 2402:b580::/32
route6:     2402:b580::/32
descr:      Anurag Bhatia R&D Pool
origin:     AS58901
mnt-by:     MAINT-AS58901
changed:    me@anuragbhatia.com 20200205
source:     ALTDB
anurag@devops01 ~>

And here goes the example of creating AS SET: AS-ANURAG. I sent following to the ATLDB:

as-set:     AS-ANURAG
descr:      Anurag Bhatia's AS SET
members:    AS58901
mnt-by:     MAINT-AS58901
changed:    me@anuragbhatia.com 20200205
source:     ALTDB

Upon confirmation, I get when I query RADB:

anurag@devops01 ~> whois -h whois.radb.net AS-ANURAG
as-set:     AS-ANURAG
descr:      Anurag Bhatia's AS SET
members:    AS58901
mnt-by:     MAINT-AS58901
changed:    me@anuragbhatia.com 20200205
source:     ALTDB
anurag@devops01 ~>

Remember if you happen to use ALTDB, make sure to ask IRINN to delete your route objects after you have successfully created them on ALTDB. Duplicate entries just add to the junk in IRR.

Further reading

  1. My detailed presentation on IRR last year at Singapore NOG: Let’s talk about the routing security
  2. Automated configuration of BGP on edge routers by University of Amsterdam
02 Feb

Basic traffic engineering for maximising peering traffic

Hello world from Gujarat! This is my 3rd visit to Gujarat. 🙂

Coming to today’s post: I have noticed ISPs doing really crazy things to maximise traffic on peerings and IXPs. Some of those are bad and some are very bad. Additionally I came across this comment and thought to put this quick post.

Example of some bad ways to increase IXP traffic:

  • Using upstream’s ASN to keep AS path shorter (yes, believe me I have seen that!)
  • Prepending a few hundred times on the transit
  • Deaggregate prefixes all the way upto /24s in IPv4 and /48s in IPv6.

and more!

Some quick fundamental ways to maximise traffic on the peering (both direct PNIs as well as IXP peering):

Inbound traffic

  1. Aggregate your prefixes. That is if your allocation is a /22, ensure you originate /22 to transit only. If there are multiple transits, announce /22s on both and then announce a /23 or /24 as needed to increase traffic on one or other link. DO NOT announce /24s on all!
  2. Announce a second level aggregate at peerings. That is if allocation is /22, announce two corresponding /23s on peerings. If allocation is /20, announce /20 on transit and /21s on peerings.
  3. Avoid prepends. They do not help much because for other side (which is sending you traffic), it will simply pick routes based on it’s own set of localpref and localpref wins over AS path length.
  4. Setup bilateral BGP sessions over the IX fabric. Do not rely only on route servers because many large content networks do not announce their critical heavy traffic routes on the route server (due to risk of leak as well as lack of control) but do that over the bilateral sessions.

Outbound traffic

Plan 4 set of local preferences. Any number will do but for example:

400 – Downstream customer routes
300 – Routes learnt from PNI interconnects
200 – Routes learnt from the IX peering
100 – Routes learnt from the IP transit

Additionally, it’s a good idea to use BGP communities internally. Logic there is to simply tag all the routes you are learning from anywhere whether it’s peer or transit or customer. Based on tag, one can have an export policy and easily announce those routes. That also helps in preventing route leaks specially in multi-homed customer setups significantly.