The problem with routing registries

Anyone who has followed me or I have done IP work for knows I am a fan of Internet Routing Registries (IRR).  However, there is a glaring issue with these registries.  I will use the example I ran into today.

A downstream client of a WISP client bought 67.158.57.0/24 off the open market about a year ago.  They finally have things in place where they are looking to announce this IP space to the world.  I helped them set up BGP to my client ISP and sent out the normal LOAs to the upstream providers.  I received this back from Hurricane Electric.

The IRR entry for this prefix does not list 14333.
https://www.radb.net/query?keywords=67.158.57.0%2F24
Please update IRR and let me know. I can add this to your prefix filter.

And a Subsequent followup message

I can add this prefix to your filter, based on the LOA. However the reason we require IRR entries for prefixes is because our peers only accept our re-announcements if there are correct IRR entries authorizing the announcement. 

Can you confirm what the source ASN will be for this announcement?
If a customer of yours is going to re-announce this to you, and that ASN is listed on:
https://www.radb.net/query?keywords=67.158.57.0%2F24
Then this will work. However if you plan to announce this sourced from your ASN 14333, this will not be picked up past our network.

This highlights one of the glaring issues with registries.  There are no checks and balances when it comes to stale data in registries. The same is true with access lists in provider routers.

What I am guessing happened is when the /20 block was carved up and sold it’s information was never removed from the routing registry.  Since this is RADb and it does not talk directly with ARIN we have some inconsistencies going on.

The following RFC illustrates many of the issues folks run into.
https://tools.ietf.org/html/rfc7682
From the summary of the document

As discussed above, many of the problems that have traditionally stifled IRR deployment have, themselves, become historical. However, there are still real operational considerations that limit IRR usage from realizing its full effectiveness.

To further complicate this Hurricane Electric is referencing data in RADb, which is a paid registry.

So what are am I going to have to do? In order to make this right, I will have to reach out to RADB and have them edit the registry to start with. Since this customer, nor the ISP, are members of RADb it will take time.

My Mum 2019 BGP presentation

This content is for Patreon subscribers of the j2 blog. Please consider becoming a Patreon subscriber for as little as $1 a month. This helps to provide higher quality content, more podcasts, and other goodies on this blog.
To view this content, you must be a member of Justin Wilson's Patreon at $0.01 or more
Already a qualifying Patreon member? Refresh to access this content.

How VRFs work

From Wikipedia https://en.wikipedia.org/wiki/Virtual_routing_and_forwarding
virtual routing and forwarding (VRF) is a technology that allows multiple instances of a routing table to co-exist within the same router at the same time. One or more logical or physical interfaces may have a VRF and these VRFs do not share routes therefore the packets are only forwarded between interfaces on the same VRF

Need an ASN, IP space? I have a package for you.

Are you intimidated by getting an ASN to participate in BGP? Do you not have the time to learn all the ins and out of dealing with ARIN to get IP space or routing registries? Let me help you.

The ARIN starter package
-Organization ID and POC IDs setup
-Paperwork to get your own ASN
-Paperwork for your own IPV6 allocation
-Paperwork for an IPV4 /24
-ASN validation
-Documentation and maintenance documents
Cost $899 plus ARIN fees

Add Ons
-RPKI Setup $199
-Routing Registry setup $199

Add-ons are priced to add-on to the starter package.  Please let me know if you need just the add-ons for a proper quote.

Cisco ORF (Outbound route filtering)

Outbound Route Filtering (ORF) is a Cisco proprietary feature that prevents the unnecessary exchanging of routes that are subject to inbound filtering. This, in turn, minimizes bandwidth across the links and reduces CPU cycles upon the router during the processing of the neighbor UPDATE.

ORF works by the router transmitting its inbound filters to its neighbor, which the neighboring router then applies outbound.

great article on how to do this if you are running Cisco routers and your provider is too.

https://community.cisco.com/t5/networking-documents/bgp-orf-outbound-route-filtering-capability/ta-p/3153286

For Patreon Subscribers: Access to Mikrotik Speedtest servers

I am happy to announce a special new tier for my Patreon subscribers. I have now installed a network of speedtest servers in 15 locations in the United States and one overseas as part of stage 1. Patreon subscribers who subscribe to this extra tier of service will be presented with a members-only username and password for testing to each of these.

Stage two will be a looking glass so you can test how your BGP routes look in various spots on the Internet. You will know what Upstreams each location has to better assist you in diagnosing BGP or just getting a view of how your network interacts with the Internet.

Visit my Patreon Page for more details.

“Glue addresses” in networking

Imagine this scenario.  You have bought an IP or DIA circuit from someone that is going to provide your network with bandwidth.  Typically this company will make the connection, IP wise, over a /30 or even a /29 of IP space.  I have called this the “glue address” for many years.  This is the IP address that binds (the glue reference) you to the other provider’s network. They can route you IP blocks over that glue address or you can establish BGP across it, but it is the static address which binds the two networks together.

Some network folks call this a peering address.  This isn’t wrong but can infer you are doing BGP peering across the address.  You aren’t always doing BGP across the glue address.

#routinglight #packetsdownrange

Noction: BGP in Large Networks

Are you running a large scale BGP network? Need some tips and help on what to optimize and what your next steps to optimize your setup?

Using iBGP with loopback addresses
Making sure all routers know next hop and loopback addresses
Whether to use route reflectors rather than an iBGP full mesh
Where to originate prefixes
Where and how to filter announcements

Using BGP in large scale networks and how to get the most out of it. Paper by Noction

How I learned to love BGP communities and so can you

This content is for Patreon subscribers of the j2 blog. Please consider becoming a Patreon subscriber for as little as $1 a month. This helps to provide higher quality content, more podcasts, and other goodies on this blog.
To view this content, you must be a member of Justin Wilson's Patreon at $1 or more
Already a qualifying Patreon member? Refresh to access this content.

BGP Confederations

In network routing, BGP confederation is a method to use Border Gateway Protocol (BGP) to subdivide a single autonomous system (AS) into multiple internal sub-AS’s, yet still advertise as a single AS to external peers. This is done to reduce the number of entries in the iBGP routing table.  If you are familiar with breaking OSPF domains up into areas, BGP confederations are not that much different, at least from a conceptual view.

And, much like OSPF areas, confederations were born when routers had less CPU and less ram than they do in today’s modern networks. MPLS has superseded the need for confederations in many cases. I have seen organizations, who have different policies and different admins break up their larger networks into confederations.  This allows each group to go their own directions with routing policies and such.

if you want to read the RFC:https://tools.ietf.org/html/rfc5065