[.Wall of Text ahead. TL;DR: unnumbered configuration in zebra as "ip
unnumbered <IP|interface+label>" on interface level, protocols get & use
that.]
Hi everyone,
since there have been various efforts to make Quagga able to deal with
unnumbered configurations, we've picked off a subtopic, namely the
address configuration groundwork, and had some discussions about how to
go at it. This was under the context of cleaning up the OSPF unnumbered
support and therefore involved the OSR (as mergers) and Cumulus
Networks (as the most recent handlers of the code). (Look at the Cc:
list for who was involved.)
[.Arguably, this could've been discussed directly on list, alas we
realised that halfway into the discussion ;) - next time. Either way
we're still fully open for input here, we just had to figure our own
heads first.]
Either way, here's it for additional feedback.
- generally, Quagga needs some way to configure an unnumbered setup.
Implicit assumptions (e.g. assuming a /32 prefix is unnumbered) only
lead to surprises for the user. Therefore, there needs to be some
configuration somewhere.
- there's actually three (and a half) parts to it:
(1) making the routing daemons behave in ignorance of the subnet mask
and accept neighbors with random IPs
(2) selecting a source address to be used for originating packets on
the unnumbered interface and handling that address correctly (ARP)
and (2 1/2) configuring this address to possibly be shared among
multiple unnumbered interfaces
(3) correctly handling routes resulting from this setup (on-link
routes)
So, after lengthy discussions involving a lot of perspectives, what it
came down to is:
- configuration of an interface for unnumbered operation makes the most
sense in zebra. While theoretically possible to handle parts or all
of it in the routing daemon (ospfd in this case), this does not bode
well for correct handling of the unnumbered address itself. Either
way the address would need some configuration; having a regular
configured address suddenly turn out unnumberd would be weird.
- another rather obvious argument for zebra involvement is os-specific
details to unnumbered operation. Those belong into zebra with the
interface setup. That wouldn't preclude "split" configuration for
(1) vs. (2) above (having one half of the config in zebra and the
other half in ospfd), but splitting like this would open the door
for mismatched non-working configurations.
- note that (1) [disabling subnet mask application] and (2) [selecting
an address for use] cannot be split reasonably, since, as soon as
you lose the subnet mask to associate incoming packets, you also
lose the regular way to associate a local address
- we're assuming that an unnumbered configuration doesn't make sense to
be mixed in with regular configured prefixes. Either you have one or
more regular addresses, or you have an unnumbered setup with exactly
one address to be used on-link.
If you have a setup that requires mixing these modes, please speak up
now! We're not excluding the possibility, just no one could come up
with a sensible setup that includes this.
- the address to be selected for use on the interface must be well
defined. It will break ACLs and firewall setups if the kernel or
zebra suddenly select a different address for the OSPF packets.
- this sadly implies that Cisco-style "ip unnumered Lo3" doesn't work
since there usually is only one loopback interface with Quagga,
which may have multiple addresses. However, it does work with
labeled addresses. More below.
- correct handling of (3) above - onlink routes - is a generic problem
and not really related to unnumbered operation. It's a prerequisite
though.
So, what we ended up with is an user interface that looks like this:
! zebra
!
interface lo
ip address 192.168.234.56/32
ip address 192.168.123.45/32 label foobar
!
! direct IP reference
!
interface eth1
ip unnumbered 10.0.0.2
interface eth2
ip unnumbered 10.0.0.2
interface eth3
ip unnumbered 10.0.0.78
!
! or interface + label reference
!
interface eth4
ip unnumbered lo:foobar
interface eth5
ip unnumbered lo:foobar
!
And no immediate configuration changes to ospfd (albeit interface-level
"ip ospf area" is very useful for unnumbered setups, it's a separate
item to be added on its own.)
On the code level, there is going to be a new IP_UNNUMBERED flag. This
might actually be a flag on the address or on the interface (Comments
welcome, for now this doesn't seem to make much of a difference, either
way zebra couldn't configure unnumbered operation without specifying an
IP address under this model.)
Also, zebra would enforce that there is either a bunch of normal
prefixes or exactly one unnumbered address on an interface. See the
bulletpoint about mixing these above.
In the end, this is pretty much a "KISS" solution, but interestingly
enough the two submissions so far (Joakim's and Cumulus's) both went
different ways, with Joakim just configuring "unnumbered" without
selecting an IP and with Cumulus not having any config flag at all - so
this is not quite an (or "the") obvious design.
Also note that these design choices leave open the choice of actually
adding the IP address to the interface or alternatively fiddling with
ARP settings and having the interface truly unnumbered. Linux, at
least, supports both. Joakim's idea seems to be doing the latter,
Cumulus on the other hand assumed the former. We can actually have a
switch for it in zebra if need be, and we can abstract away OS specifics
in a zebra backend.
So, comments very welcome, prototype code will follow in a bit,
-David
unnumbered <IP|interface+label>" on interface level, protocols get & use
that.]
Hi everyone,
since there have been various efforts to make Quagga able to deal with
unnumbered configurations, we've picked off a subtopic, namely the
address configuration groundwork, and had some discussions about how to
go at it. This was under the context of cleaning up the OSPF unnumbered
support and therefore involved the OSR (as mergers) and Cumulus
Networks (as the most recent handlers of the code). (Look at the Cc:
list for who was involved.)
[.Arguably, this could've been discussed directly on list, alas we
realised that halfway into the discussion ;) - next time. Either way
we're still fully open for input here, we just had to figure our own
heads first.]
Either way, here's it for additional feedback.
- generally, Quagga needs some way to configure an unnumbered setup.
Implicit assumptions (e.g. assuming a /32 prefix is unnumbered) only
lead to surprises for the user. Therefore, there needs to be some
configuration somewhere.
- there's actually three (and a half) parts to it:
(1) making the routing daemons behave in ignorance of the subnet mask
and accept neighbors with random IPs
(2) selecting a source address to be used for originating packets on
the unnumbered interface and handling that address correctly (ARP)
and (2 1/2) configuring this address to possibly be shared among
multiple unnumbered interfaces
(3) correctly handling routes resulting from this setup (on-link
routes)
So, after lengthy discussions involving a lot of perspectives, what it
came down to is:
- configuration of an interface for unnumbered operation makes the most
sense in zebra. While theoretically possible to handle parts or all
of it in the routing daemon (ospfd in this case), this does not bode
well for correct handling of the unnumbered address itself. Either
way the address would need some configuration; having a regular
configured address suddenly turn out unnumberd would be weird.
- another rather obvious argument for zebra involvement is os-specific
details to unnumbered operation. Those belong into zebra with the
interface setup. That wouldn't preclude "split" configuration for
(1) vs. (2) above (having one half of the config in zebra and the
other half in ospfd), but splitting like this would open the door
for mismatched non-working configurations.
- note that (1) [disabling subnet mask application] and (2) [selecting
an address for use] cannot be split reasonably, since, as soon as
you lose the subnet mask to associate incoming packets, you also
lose the regular way to associate a local address
- we're assuming that an unnumbered configuration doesn't make sense to
be mixed in with regular configured prefixes. Either you have one or
more regular addresses, or you have an unnumbered setup with exactly
one address to be used on-link.
If you have a setup that requires mixing these modes, please speak up
now! We're not excluding the possibility, just no one could come up
with a sensible setup that includes this.
- the address to be selected for use on the interface must be well
defined. It will break ACLs and firewall setups if the kernel or
zebra suddenly select a different address for the OSPF packets.
- this sadly implies that Cisco-style "ip unnumered Lo3" doesn't work
since there usually is only one loopback interface with Quagga,
which may have multiple addresses. However, it does work with
labeled addresses. More below.
- correct handling of (3) above - onlink routes - is a generic problem
and not really related to unnumbered operation. It's a prerequisite
though.
So, what we ended up with is an user interface that looks like this:
! zebra
!
interface lo
ip address 192.168.234.56/32
ip address 192.168.123.45/32 label foobar
!
! direct IP reference
!
interface eth1
ip unnumbered 10.0.0.2
interface eth2
ip unnumbered 10.0.0.2
interface eth3
ip unnumbered 10.0.0.78
!
! or interface + label reference
!
interface eth4
ip unnumbered lo:foobar
interface eth5
ip unnumbered lo:foobar
!
And no immediate configuration changes to ospfd (albeit interface-level
"ip ospf area" is very useful for unnumbered setups, it's a separate
item to be added on its own.)
On the code level, there is going to be a new IP_UNNUMBERED flag. This
might actually be a flag on the address or on the interface (Comments
welcome, for now this doesn't seem to make much of a difference, either
way zebra couldn't configure unnumbered operation without specifying an
IP address under this model.)
Also, zebra would enforce that there is either a bunch of normal
prefixes or exactly one unnumbered address on an interface. See the
bulletpoint about mixing these above.
In the end, this is pretty much a "KISS" solution, but interestingly
enough the two submissions so far (Joakim's and Cumulus's) both went
different ways, with Joakim just configuring "unnumbered" without
selecting an IP and with Cumulus not having any config flag at all - so
this is not quite an (or "the") obvious design.
Also note that these design choices leave open the choice of actually
adding the IP address to the interface or alternatively fiddling with
ARP settings and having the interface truly unnumbered. Linux, at
least, supports both. Joakim's idea seems to be doing the latter,
Cumulus on the other hand assumed the former. We can actually have a
switch for it in zebra if need be, and we can abstract away OS specifics
in a zebra backend.
So, comments very welcome, prototype code will follow in a bit,
-David