joakim.tjernlund at transmode
Jun 20, 2012, 7:36 PM
Post #5 of 12
> Hi everyone,
Re: [DESIGN] zebra unnumbered IP address infrastructure
[In reply to]
> 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.
Got some spare time so a few comments.
> - 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
Didn't there was any issues here, may I have forgotten.
> (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
Setting up ppp links is mostly the pppd job and what addresses to use.
> (3) correctly handling routes resulting from this setup (on-link
I don't get this on-link route?
> 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.
hmm, we usally have one IP address, this IP is used both on the eth0 I/F
and on all the ppp links. Was this what you had in mind?
> 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.
Yes, that is why you in Linux configures an local IP on you ppp I/Fs
> - 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
> 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
hmm, need to look at this when at home but ..
how do you handle ppp links here ?
> 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.
Cumulus work is based on one of my older patches and these are flawed. Any
SPF algo. that tries to find interfaces by seaching the LSA for matching IP addresses/
ifindexs are bound to fail in some cases. I found this the hard way.
Do the SPF part my way and it wont matter what IP address(if any) you use, Quagga
won't care and will just work and the SPF will be much faster.
> 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,
I don't know what part you are thinking of but the SPF part won't care or
be the limiting factor.
> 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.
No, that should not be needed I hope.
> So, comments very welcome, prototype code will follow in a bit,
Yes, please. I don't understand all of the above so code will help.
I have pointed you to my SPF patches several times and all I get
is that the don't apply anymore. That tells me that noone has
really looked at them nor understood them.
Quagga-dev mailing list
Quagga-dev [at] lists