Unnumbered OSPF Interfaces in Quagga (and Cumulus)
Carlos Mendioroz sent me an interesting question about unnumbered interfaces in Cumulus Linux and some of the claims they make in their documentation.
TL&DR: Finally someone got it! Kudos for realizing how to use an ancient trick to make data center fabrics easier to deploy (and, BTW, the claims are exaggerated).
Why am I excited about unnumbered interfaces?
Every data center fabrics vendor claims how easy it is to configure their fabrics. Plug in the cables and the devices almost self-configure the fabric (or you might have to add a single configuration command like switchport mode fabric). Messing up the wiring? No problem, It All Just Works™.
These same vendors require you to configure IPv4 subnets on point-to-point links in a layer-3 leaf-and-spine fabric. Messing up the wiring? We wish you a happy troubleshooting!
Can we get around the requirement of configuring IPv4 subnets on links that connect two routed interfaces on adjacent switches? Of course – we’ve been using unnumbered interfaces on point-to-point links for ages. It’s just that the routing protocol programmers haven’t realized the days of thick coax cable are gone; in this century most people use Ethernet on point-to-point links. There’s even a 6-year-old informational RFC describing this idea.
To be fair, some vendors did implement unnumbered Ethernet interfaces. For example, some Cisco IOS images have support for unnumbered VLAN and Ethernet interfaces, but cannot run routing protocols over them. Not exactly what I’ve been looking for. Does any other vendor fare better? Write a comment.
And now for the claims
The Cumulus documentation claims:
In OSPFv2, configuring unnumbered interfaces reduces the links between routers into pure topological elements, and thus dramatically simplifies network configuration and reconfiguration. In addition, routing database contains only the real networks, hence memory footprint is reduced and SPF is faster.
Let’s walk through all of these claims:
Configuring unnumbered interfaces reduces the links between routers into pure topological elements
Translated into engineering terms: the Type-1 (router) LSA no longer contains the stub networks for inter-router subnets. You can do something similar on Cisco IOS with OSPF prefix suppression.
… and thus dramatically simplifies network configuration and reconfiguration.
Marketese for “we don’t check IP subnets in OSPF hello packets”.
In addition, routing database contains only the real networks,
I don’t know what they call the routing database. OSPF database contains exactly the same number of LSAs, the routing table does contain smaller number of routes (but see also prefix suppression).
… hence memory footprint is reduced and SPF is faster.
Memory footprint is reduced. SPF speedup is probably measured in per mils – after all, the router considers the stub networks attached to Type-1 router LSAs only in the second part of the SPF algorithm, which has linear complexity.
I love the way Quagga handles point-to-point Ethernet links – it does make the task of building a layer-3-only leaf-and-spine fabric much easier and error-resistant, but do you really have to call it dramatic?
Debugging? Of course there will be drawbacks (as always with the unnumbered interfaces). Example: traceroute will not identify individual transit interfaces, just boxes.
We haven't implemented it yet in Cumulus Linux, but there is an RFC that can help with the traceroute issue:
you might recognize one of the former Googlers...
- an interface with netmask /32 address is not recognized as OSPF interface, even being point-to-point.
- OSPF is choking on a host with several identical IP addresses (as you say here http://blog.ipspace.net/2008/10/ospf-breaks-when-faced-with-overlapping.html that "OSPF gets totally confused when two interfaces have the same IP address.")
How come? Does Cumulus ship their own Quagga version to handle these two issues?
See also http://docs.cumulusnetworks.com/display/CL25/Open+Shortest+Path+First+-+OSPF+-+Protocol#OpenShortestPathFirst-OSPF-Protocol-ConfigurationTip:UnnumberedInterfaces for details.
Yes, except for 'virtual interfaces', called so in RFC5340: "The IPv6 interface address of a virtual link MUST be an IPv6 address having global scope, instead of the link-local addresses used by other interface types."
What can be the reason for this exception? And does it mean that if I have OSPFv3 running over a point-to-point IPv6 VPN link, then I must configure and "waste" a two-host IPv6 network?
VPN link is (usually) an interface, and standard interface numbering rules apply.