Mailing List Archive

I am sure I am going to have comments on this but as I am on vacation I cannot
invest the time required ATM.

I want to see the patches first though.

Jocke

-----quagga-dev-bounces@lists.quagga.net wrote: -----
To: quagga-dev@lists.quagga.net
From: David Lamparter
Sent by: quagga-dev-bounces@lists.quagga.net
Date: 19/06/2012 20:51
Cc: Scott Feldman <sfeldma@cumulusnetworks.com>, Bill Shetti <bill@opensourcerouting.org>, Avneesh Sachdev <avneesh@opensourcerouting.org>, David Lamparter <equinox@opensourcerouting.org>, Martin Winter <mwinter@opensourcerouting.org>, JR Rivers <jrrivers@cumulusnetworks.com>
Subject: [quagga-dev 9455] [DESIGN] zebra unnumbered IP address infrastructure

[.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

_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
http://lists.quagga.net/mailman/listinfo/quagga-dev



[attachment "signature.asc" removed by Joakim Tjernlund/Transmode]
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
http://lists.quagga.net/mailman/listinfo/quagga-dev

> - 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.

Linux does IPv4 unnumbered links differently from Cisco. On Cisco, an
unnumbered link borrows an IP address from another interface. On Linux,
you simply configure multiple interfaces with the same IP.

In order to support this in your routing protocol, you need to specify
both the interface and the gateway IP when installing a route, either
with or without the "onlink" flag.

Note that Quagga-RE has support for Linux-style unnumbered interfaces
with Babel. I've been lobbying for the same to be done for RIP, but
Denis is nervous about breaking it.

Note further that the issue doesn't exist for IPv6 -- link-local
addresses avoid the issue.

> (1) making the routing daemons behave in ignorance of the subnet mask
> and accept neighbors with random IPs

That's what the "onlink" flag does. See commit b9c1e9 in Quagga-RE.

> (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

On Linux, that's done automatically by the kernel if you configure the
same address on multiple interfaces.

> (3) correctly handling routes resulting from this setup (on-link
> routes)

I'm not sure what you mean by that.

> So, comments very welcome, prototype code will follow in a bit,

I fear that you're trying to do your own thing, and ignoring the
existing support in the Linux kernel.

-- Juliusz
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
http://lists.quagga.net/mailman/listinfo/quagga-dev

On Wed, Jun 20, 2012 at 02:43:58PM +0200, Juliusz Chroboczek wrote:
> > - 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.
>
> Linux does IPv4 unnumbered links differently from Cisco. On Cisco, an
> unnumbered link borrows an IP address from another interface. On Linux,
> you simply configure multiple interfaces with the same IP.

Yes, either that or you don't configure an address at all. That also
works and seems to be ran that way in production by some people.

> In order to support this in your routing protocol, you need to specify
> both the interface and the gateway IP when installing a route, either
> with or without the "onlink" flag.

Yes, that's point (3) below.

> Note that Quagga-RE has support for Linux-style unnumbered interfaces
> with Babel. I've been lobbying for the same to be done for RIP, but
> Denis is nervous about breaking it.

RIP unnumbered is, uh, academic. I've found a reference to it in a book
at the university library, but after asking around there seem to be no
users (and big name vendor support seems questionable).

> > (1) making the routing daemons behave in ignorance of the subnet mask
> > and accept neighbors with random IPs
>
> That's what the "onlink" flag does. See commit b9c1e9 in Quagga-RE.

No, that's (3). (1) is ospfd accepting packets and forming adjacencies
with neighbors that don't match some subnet mask. A simple enable bit
for ospfd to behave differently.

> > (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
>
> On Linux, that's done automatically by the kernel if you configure the
> same address on multiple interfaces.

Yes, as long as you put the address on the interface. Some people have
been running setups with "truly" unnumbered interfaces, where this
suddenly breaks.

> > (3) correctly handling routes resulting from this setup (on-link
> > routes)
>
> I'm not sure what you mean by that.

The "onlink" routes.

> > So, comments very welcome, prototype code will follow in a bit,
>
> I fear that you're trying to do your own thing, and ignoring the
> existing support in the Linux kernel.

No I'm not starting to hack the Linux kernel :). Also, getting this on
BSD is desirable; support for other OSes is indeed one of the reasons
for adding an explicit "ip unnumbered" configuration statement. If,
say, GNU Hurd, requires a special rain dance to enable unnumbered IPs,
we can support that too.


-David

> 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.

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.

Agreed.

>
> - 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
> routes)

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
> 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
> !


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.

Jocke
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
http://lists.quagga.net/mailman/listinfo/quagga-dev

>
>
> On Wed, Jun 20, 2012 at 02:43:58PM +0200, Juliusz Chroboczek wrote:
> > > - 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.
> >
> > Linux does IPv4 unnumbered links differently from Cisco. On Cisco, an
> > unnumbered link borrows an IP address from another interface. On Linux,
> > you simply configure multiple interfaces with the same IP.
>
> Yes, either that or you don't configure an address at all. That also
> works and seems to be ran that way in production by some people.
>
> > In order to support this in your routing protocol, you need to specify
> > both the interface and the gateway IP when installing a route, either
> > with or without the "onlink" flag.
>
> Yes, that's point (3) below.
>
> > Note that Quagga-RE has support for Linux-style unnumbered interfaces
> > with Babel. I've been lobbying for the same to be done for RIP, but
> > Denis is nervous about breaking it.
>
> RIP unnumbered is, uh, academic. I've found a reference to it in a book
> at the university library, but after asking around there seem to be no
> users (and big name vendor support seems questionable).
>
> > > (1) making the routing daemons behave in ignorance of the subnet mask
> > > and accept neighbors with random IPs
> >
> > That's what the "onlink" flag does. See commit b9c1e9 in Quagga-RE.
>
> No, that's (3). (1) is ospfd accepting packets and forming adjacencies
> with neighbors that don't match some subnet mask. A simple enable bit
> for ospfd to behave differently.
>
> > > (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
> >
> > On Linux, that's done automatically by the kernel if you configure the
> > same address on multiple interfaces.
>
> Yes, as long as you put the address on the interface. Some people have
> been running setups with "truly" unnumbered interfaces, where this
> suddenly breaks.

"Truly" unnumbered links is about what IP address you report to the remote side.

To have any control of used source address in Linux you always assing an IP
to your ppp I/Fs(it can by any address, one that is alredy used on some other I/F too).
Then you decide if you want to report that IP address to the remote side or not.
Linux pppd support either way.

Jocke
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
http://lists.quagga.net/mailman/listinfo/quagga-dev

On Jun 20, 2012, at 5:43 AM, Juliusz Chroboczek wrote:

>> - 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.
>
> Linux does IPv4 unnumbered links differently from Cisco. On Cisco, an
> unnumbered link borrows an IP address from another interface. On Linux,
> you simply configure multiple interfaces with the same IP.
>
> In order to support this in your routing protocol, you need to specify
> both the interface and the gateway IP when installing a route, either
> with or without the "onlink" flag.
>
> Note that Quagga-RE has support for Linux-style unnumbered interfaces
> with Babel. I've been lobbying for the same to be done for RIP, but
> Denis is nervous about breaking it.
>
> Note further that the issue doesn't exist for IPv6 -- link-local
> addresses avoid the issue.

I think that this is the gist of much of the discussion. The patch we submitted assumed that IP address configuration was done in the kernel as you've indicated. Our use case centers on point-to-point Ethernets and rfc5309 (http://www.rfc-editor.org/rfc/rfc5309.txt) which observes that we can use /32 addresses on interfaces and still form peering relationships.

We believe (or believed based on noodling on Joakim's comments) that ospfd needs to understand that an interface is allowed to form an adjacency with a non-subnet peer on a broadcast media. This meant that ospfd needed to know (either explicitly or implicitly) that it's behavior during next hop calculation and route insertion is different on these interfaces.

PS- I may be off base, but there is a side benefit to this solution that is not realized with IPv6 link local addresses... on broadcast media, we don't need to define a subnetwork for each which is then advertised in the routing protocol.

>
>> (1) making the routing daemons behave in ignorance of the subnet mask
>> and accept neighbors with random IPs
>
> That's what the "onlink" flag does. See commit b9c1e9 in Quagga-RE.
>
>> (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
>
> On Linux, that's done automatically by the kernel if you configure the
> same address on multiple interfaces.
>
>> (3) correctly handling routes resulting from this setup (on-link
>> routes)
>
> I'm not sure what you mean by that.
>
>> So, comments very welcome, prototype code will follow in a bit,
>
> I fear that you're trying to do your own thing, and ignoring the
> existing support in the Linux kernel.
>
> -- Juliusz
> _______________________________________________
> Quagga-dev mailing list
> Quagga-dev@lists.quagga.net
> http://lists.quagga.net/mailman/listinfo/quagga-dev


_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
http://lists.quagga.net/mailman/listinfo/quagga-dev

On Thu, Jun 21, 2012 at 07:40:22AM -0700, JR Rivers wrote:
> PS- I may be off base, but there is a side benefit to this solution
> that is not realized with IPv6 link local addresses... on broadcast
> media, we don't need to define a subnetwork for each which is then
> advertised in the routing protocol.

Link-local subnets are not advertised in the routing protocol, that's
the point of being link-local :) ... relatedly, people who put
global-scope IPv6 addresses on PtP router links deserve a high-five - in
the face, with a chair. *cough*

The IPv6 solution is much cleaner. It doesn't give a frak about
broadcast or PtP media. You throw a fe80::/64 on the link and work with
that. After all this discussion about unnumbered, I kinda wish we could
just drop IPv4 support and move to IPv6 ;)


-David

Thanks for the clarification!

On Jun 21, 2012, at 8:02 AM, David Lamparter wrote:

> On Thu, Jun 21, 2012 at 07:40:22AM -0700, JR Rivers wrote:
>> PS- I may be off base, but there is a side benefit to this solution
>> that is not realized with IPv6 link local addresses... on broadcast
>> media, we don't need to define a subnetwork for each which is then
>> advertised in the routing protocol.
>
> Link-local subnets are not advertised in the routing protocol, that's
> the point of being link-local :) ... relatedly, people who put
> global-scope IPv6 addresses on PtP router links deserve a high-five - in
> the face, with a chair. *cough*
>
> The IPv6 solution is much cleaner. It doesn't give a frak about
> broadcast or PtP media. You throw a fe80::/64 on the link and work with
> that. After all this discussion about unnumbered, I kinda wish we could
> just drop IPv4 support and move to IPv6 ;)
>
>
> -David

_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
http://lists.quagga.net/mailman/listinfo/quagga-dev

>
> On Jun 20, 2012, at 5:43 AM, Juliusz Chroboczek wrote:
>
> >> - 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.
> >
> > Linux does IPv4 unnumbered links differently from Cisco. On Cisco, an
> > unnumbered link borrows an IP address from another interface. On Linux,
> > you simply configure multiple interfaces with the same IP.
> >
> > In order to support this in your routing protocol, you need to specify
> > both the interface and the gateway IP when installing a route, either
> > with or without the "onlink" flag.
> >
> > Note that Quagga-RE has support for Linux-style unnumbered interfaces
> > with Babel. I've been lobbying for the same to be done for RIP, but
> > Denis is nervous about breaking it.
> >
> > Note further that the issue doesn't exist for IPv6 -- link-local
> > addresses avoid the issue.
>
> I think that this is the gist of much of the discussion. The patch we submitted assumed that IP
> address configuration was done in the kernel as you've indicated. Our use case centers on
> point-to-point Ethernets and rfc5309 (http://www.rfc-editor.org/rfc/rfc5309.txt) which observes
> that we can use /32 addresses on interfaces and still form peering relationships.
>
> We believe (or believed based on noodling on Joakim's comments) that ospfd needs to understand
> that an interface is allowed to form an adjacency with a non-subnet peer on a broadcast media.
> This meant that ospfd needed to know (either explicitly or implicitly) that it's behavior during
> next hop calculation and route insertion is different on these interfaces.

ah, rfc5309. I have looked at that one but as we don't use such ptp links I never looked too hard.
However, we are not there yet. First regular ppp links must be usable in unnumbered setups.
You need some version of my "lsa_pos" patch and use it in nexthop_calculation.

Once you have that and start using unnumbered with some complexity, like two links between the same two routes, you
will find new bugs were Q breaks down because Q really don't handle the same IP address/no IP address on several links.
You will find fixes to those in patch work too, just ask.

Jocke

Jocke
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
http://lists.quagga.net/mailman/listinfo/quagga-dev

Got some questions on your feedback:

On Thu, Jun 21, 2012 at 04:36:57AM +0200, Joakim Tjernlund wrote:
> > (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.

Just to clarify here - as you're using it, pppd always sets you up with
a local and a peer address? Or do you have cases where the peer address
is not known?

(If the latter is the case, can you post sample configs for that?)

> > (3) correctly handling routes resulting from this setup (on-link
> > routes)
>
> I don't get this on-link route?

(see other mail)

> > - 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?

No, I was referring to having an unnumbered/shared address /and/ a
regular subnet in parallel on one interface. Doesn't make much sense
for PPP, but relevant for 5309 PtP over LAN.

> > - 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

(See question above, do you have setups with unknown peer addr?)

> > 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 ?

"oops"

Totally forgot about that. Your variant had "unnumbered" without IP
address, we didn't see the point of splitting it like that... I see the
point now.
(That's also why I didn't post code yet.)

Also, thanks, your question helped me figure out a misunderstanding I
had myself about the actual goal of RFC 5309. I had assumed the scope
of it to be much larger, allowing any kind of unnumbered operation on
LANs - but that's not the case.

> 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.

We're looking into it.

> > 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.

I fully admit to being guilty of the latter, but that's changing.

Cheers,

-David

_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
http://lists.quagga.net/mailman/listinfo/quagga-dev

>
> Got some questions on your feedback:
>
> On Thu, Jun 21, 2012 at 04:36:57AM +0200, Joakim Tjernlund wrote:
> > > (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.
>
> Just to clarify here - as you're using it, pppd always sets you up with
> a local and a peer address? Or do you have cases where the peer address
> is not known?

No, in our use we always have the remote ppp address. We like the connected route
it brings so that we can telnet/ssh on hop at a time when routing isn't setup/working.
I have played with the thought to have real unnumberd IFs but sofar I have
not acted on that :)

>
> (If the latter is the case, can you post sample configs for that?)
>
> > > (3) correctly handling routes resulting from this setup (on-link
> > > routes)
> >
> > I don't get this on-link route?
>
> (see other mail)
>
> > > - 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?
>
> No, I was referring to having an unnumbered/shared address /and/ a
> regular subnet in parallel on one interface. Doesn't make much sense
> for PPP, but relevant for 5309 PtP over LAN.
>
> > > - 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
>
> (See question above, do you have setups with unknown peer addr?)

No(as stated above) but that does not change that. You would always
assign an local IP to your ppp IFs to control your source address. What to
report to the remote side is the question. Either you don't report
your local IP address and then you end up with a true unnumbered IF or
you report it(this is how pppd in linux works). If you report your
IP you can choose whether to run OSPF in unnumbered mode or not.

>
> > > 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 ?
>
> "oops"
>
> Totally forgot about that. Your variant had "unnumbered" without IP
> address, we didn't see the point of splitting it like that... I see the
> point now.
> (That's also why I didn't post code yet.)

Why this "fear" to post work in progress? Just label it RFC and show what you have.
This "closed" development isn't helping anyone.

>
> Also, thanks, your question helped me figure out a misunderstanding I
> had myself about the actual goal of RFC 5309. I had assumed the scope
> of it to be much larger, allowing any kind of unnumbered operation on
> LANs - but that's not the case.
>
> > 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.
>
> We're looking into it.

Thanks, they might need some polish but the general idea is still there.

Jocke
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
http://lists.quagga.net/mailman/listinfo/quagga-dev