Free Range Routing vs Quagga/Cisco

▼ Back in the 1990s, I used Cisco routers. Mostly rather underpowered ones such as the Cisco 2500 series. I later started using the Zebra and then Quagga routing software for the lab part of my training courses.

However, like Zebra before it, Quagga also ran out of steam but was forked by people (and companies) who saw value in the software. The Quagga fork is Free Range Routing a.k.a. FRRouting a.k.a. FRR.

As I was writing my new BGP book, I made configuration examples using Quagga. But about two thirds in, I decided to switch to FRRouting. This had the huge advantage that I could include RPKI examples. But on the other hand, I now had to revisit all my earlier configuration examples to see if they still worked under FRR. And too often, the answer was "no".

So let me list some differences between Quagga or even old school Cisco routers and FRRouting.

A really annoying change is that in FRR, it's no longer "ip as-path ..." but "bgp as-path ..." to define AS path access lists. Yes, it makes more sense. But this change immediately makes it impossible to have a configuration file that works on both Cisco/Quagga and FRR. Same thing for "ip community ..." vs "bgp community ...".

I think the solution here would have been to accept the "ip ..." syntax and translate that into "bgp ..." syntax. That way, an FRR BGP daemon could still read Quagga BGP daemon configurations and work as expected.

Another change is that with FRR, there's no way to get around "address-family ipv4".

Way, way, way back in the day, we didn't have IPv6. Actually, it took quite a while for 1990s routers like the 2500 series to gain IPv6 capability. So there was no reason to differentiate between BGP configuration commands that both apply to IPv4 and IPv6 and configuration commands that only apply to either IPv4 or IPv6.

With Cisco routers, you could always just pretend like IPv6 didn't exist and enter configurations like:

!
router bgp 65086
 no synchronization
 network 10.86.0.0 mask 255.255.0.0
 neighbor 203.0.113.83 remote-as 65083
 no auto-summary
!

On FRR, you can still paste that configuration snippet. But if you then issue "show running-config", this is what you get back:

!
router bgp 65086
 neighbor 203.0.113.83 remote-as 65083
 !
 address-family ipv4 unicast
  network 10.86.0.0/16
 exit-address-family
exit
!

Yes, it boils down to the same thing, but it looks rather different. Especially as the configuration gets longer and the non address family part and the IPv4 address family part don't fit on the screen at the same time.

Bottom line: FRR is moving away from the traditional Cisco configuration language relatively quickly, white Quagga, for BGP at least, stayed pretty close to that. So moving from Quagga to FRR is a bigger step than you might think.

Also, as much as we may be unhappy with Cisco for some of their high profile software bugs, more minor software bugs happen much more frequently in these software implementations such as Quagga and FRR. For instance, I find myself not being able to use ^(64496_)+$ to match one or more instances of AS 64496 in an AS path but nothing else. However, ^(_64496)+$ does work as expected.

Permalink - posted 2022-11-02

6-6-2012: World IPv6 Launch — the future is forever

▼ Ten years ago, on 6 June 2012, the Internet Society organized World IPv6 Launch. A year earlier, we'd had World IPv6 Day, where many (large) organizations added IPv6 addresses for their websites to the DNS for 24 hours, in order to see if that would create problems. That went mostly smoothly, with a few surprises, so a year later it was time to turn on IPv6 for real. Time for a blog post looking back on worldipv6launch.org.

I thought this would be a good excuse to do what I've done with some regularity over the years: see how well things work when I turn off IPv4 on my home network.

The IETF tried this at is meeting in March of 2008 for an hour on its meeting network, with interesting results. Back then, Windows XP was still the most widely used operating system, and although Windows XP does support IPv6, it doesn't support DNS lookups over IPv6. So the Windows XP users were left out in the cold or had to apply complex workarounds.

By the early 2010s, all operating systems had mature IPv6 implementations, but very few websites and other online services were IPv6-enabled. So with IPv4 turned off, you couldn't do much. Since then, that's gotten a lot better. And it took a while, but many (most?) ISPs now routinely provide IPv6 connectivity along with IPv4.

I initially tried to turn off IPv4 on my home router, but no dice: you can turn off IPv6, but not IPv4. So I replaced the home router that came with my FTTH service with a Mikrotik, which has no such limitations.

The good news is that my main networked devices all had no issue using IPv6: my Macs, iPhone, iPad, AppleTV 4K and LG TV. Not sure about my Onkyo receiver, but I never use any networked services on that anyway. My Sony UHD blu-ray player wouldn't run its Netflix app or software update check over IPv6, but the IPv6 version of the built-in network connectivity checker was happy with the connectivity. In the settings it said IPv4 had priority over IPv6, but no way to change that. Strange.

On the LG TV and the AppleTV most of the video streaming apps work fine over IPv6. Not Amazon Prime or the Dutch public broadcasting apps, though. Podcasts are pretty bad. I found four IPv6-related podcasts, and only two of them would load over IPv6. And of all the others I tried, just one.

Websites are hit and miss. It seems especially the big ones served up by content delivery networks work over IPv6, while web based applications often don't work over IPv6. Annoying examples are Twitter and Fastmail. Third party iPhone and iPad apps are also somewhat underperforming. Podcast player Pocket Casts will sync over IPv6, but as noted, most podcasts won't load over IPv6. Overcast doesn't sync over IPv6. Dutch public transport planning apps also didn't work.

Although most of Apple's stuff has supported IPv6 for years, controlling smart home devices through Homekit remotely (over the internet) doesn't work with just IPv6. And Siri doesn't work over IPv6.

Right now, if you're an IPv4-only user (or content provider) that doesn't cause any problems. It's up to the IPv6-only users to figure out a way to reach the IPv4 world. It will be interesting to see how long it takes before we reach the tipping point where this flips and important services are only available over IPv6, so IPv4 users have to find a way to talk to the IPv6 world. I'm guessing not very soon.

Ok, time to turn IPv4 back on so I can listen to some podcasts.

Permalink - posted 2022-06-07

OSPF: time to get rid of the totally not so stubby legacy

▼ Recently, I was looking through some networking certification material. A very large part of it was about OSPF. That's fair, OSPF is probably the most widely used routing protocol in IP networks. But the poor students were submitted to a relentless sequence of increasingly baroquely named features: stub areas, not-so-stubby-areas, totally stubby areas, culminating in totally not-so-stubby areas.

Can we please get rid of some of that legacy? And if not from the standard documents or the router implementations, then at least from the certification requirements and training materials?

Shortest path first, but not so fast

The Open Shortest Path First routing protocol (OSPF, Internet Standard 54) was first defined in RFC 1131 in 1989. So in internet time, OSPF is truly ancient. The base OSPFv2 specification is over 200 pages, with additional extensions in separate documents spanning the early 1990s to the late 2010s.

OSPF is powered by Edsgar Dijkstra's shortest path first algorithm. SPF is a relatively efficient algorithm for finding the shortest path between two places, in the real world or in a network. Still, in a large network there's a lot of paths to check until you can be sure you've found the shortest one. The problem here is that for a network that's 10 times larger, SPF needs 60 times as long to run. So if a router in a network with, say, 100 routers, needs a second to do its SPF calculations after an update, in a network with 1000 routers that takes a minute, and in a network with 10,000 routers an hour.

So in order to make OSPF useful in large networks, you can split your network into different areas. The SPF calculations are then contained to the routers within each area. So rather than calculate SPF over a 10,000-router network, you could have 100 areas with 100 routers each. Then routers that connect two areas would have to calculate SPF over 100 routers for two areas, so 2 seconds rather than an hour worth of SPF calculations.

But if each of those 10,000 routers still injects two, three or four address blocks into OSPF, that means the OSPF database will have something like 30,000 entries. So now updating and remembering all those address blocks becomes a bottleneck. Solution: summarize link advertisements. So if routers in area 35 advertise address blocks 10.35.1.x, 10.35.2.x, … 10.35.95.x, rather than push out all that information to all 10,000 routers throughout the network, the area border routers for area 35 simply say “10.35.x.x” to the rest of the network.

Even better: if an area only connects to the “backbone” area (area 0) and doesn't learn any routing information from other areas or from outside OSPF, it's a stub area that really doesn't even need to know anything that's happening in the rest of the network, so let's give it a default route to reach the rest of the world.

Variations on a stubby theme

Stub areas still have some OSPF routing information from other areas. We can get rid of that too, and then we have a totally stubby area.

On the other hand, maybe we want to import external routing information into OSPF even in our stub area, and then propagate that external information to other areas. This makes for a not-so-stubby area.

And who said you can't have your cake and eat it: let's make our totally stubby area not-so-stubby, and we'll have a totally not-so-stubby area, guaranteeing certification income for years to come. (See Wikipedia's page on OSPF for more details.)

Spring cleaning

As protocol designers, we're really good at adding more capabilities, more options. As network architects and engineers, we're really good at adding complexity to make our networks do something they won't do out of the box. But we can't just keep adding options and complexity without ever taking any of it away. At least not if we want to have a fighting chance at teaching our craft to the next generation so we can retire at some point.

Our routers/computers are now 1000 times as fast and have 1000 times the memory as the 68030-based routers/computers back in 1990. OSPF implementations support incremental SPF.

10,000 routers in one area will melt the network operations center long before the SPF calculations melt the router CPUs. I've personally worked on a network with 600 routers in area 0 back in 1999. SPF performance was the least of our concerns.

So I'm calling it: OSPF areas and summarization are now legacy. New and current OSPF networks should just use a flat area 0 rather than try to micromanage the information flow between areas. Students should no longer have to learn how areas work, and only be informed about the various flavors of stubbiness as an example of humorous naming that doesn't age well.

Permalink - posted 2022-05-12

My first big Ars Technica story in 2007: "Everything you need to know about IPv6"

▼ Fifteen years ago today, Everything you need to know about IPv6 was the first big story I wrote for Ars Technica.

Ah, those innocent days of the past when we still had more than a billion fresh IPv4 addresses to burn through... Back in those days, it was common to hear that IPv6 was unnecessary if we just used NAT. I decided to address this argument proactively as follows:

This is usually when someone brings up NAT. Home routers (and a lot of enterprise equipment) use a technique called "network address translation" so that a single IP address can be shared by a larger number of hosts. The discussion usually goes like this:

"Use NAT, n00b. All 1337 of my Linux boxes share a single IP and it's safer, too!"

"NAT is not a firewall."

"NAT sucks."

"You suck."

Still makes me smile to this day. One thing I didn't remember is how I illustrated the vastness of the IPv6 address space:

40 or 48 bits would have given us more than a trillion or even 281 trillion addresses, respectively, and 64 bits would have been a nice round number. But as the axiom goes, once bitten, twice shy, so the IETF opted for 128 bits this time around. The total number of possible addresses that this gives us:

340,282,366,920,938,463,463,374,607,431,768,211,456

To put this into perspective: there are currently 130 million people born each year. If this number of births remains the same until the sun goes dark in 5 billion years, and all of these people live to be 72 years old, they can all have 53 times the address space of the IPv4 Internet for every second of their lives.

You may also like my last (so far?) IPv6 story on Ars Technica from 2016: IPv6 celebrates its 20th birthday by reaching 10 percent deployment.

As we're discussing IPv6 anyway, a short status update:

Right now, Google's IPv6 statistics show that during week days, 33% of Google users have IPv6, wile during the weekends it's 38%. So it looks like more people have IPv6 at home than at work. These numbers seem to be increasing at a few percentage points per year.

Looking at the map, the dark green countries are all around 45 - 55 % or so IPv6 adoption, with India being in the lead at 61%.

I don't remember when Belgium reached 50% IPv6 adoption, but it was several years ago; they were already at 30% in 2014. They're now at 56.55%. So it seems that reaching 50% IPv6 adoption is fairly doable, but growing (much) beyond that seems to be more difficult.

Permalink - posted 2022-03-08