[quagga-dev 10373] Re: [PATCH] ospfd: restore nexthop IP for p2p interfaces

Joakim Tjernlund joakim.tjernlund at transmode.se
Fri Mar 22 10:13:53 GMT 2013

James Li <jli at cumulusnetworks.com> wrote on 2013/03/22 01:05:51:
> On 3/21/13 3:27 PM, Joakim Tjernlund wrote:
> > James Li <jli at cumulusnetworks.com> wrote on 2013/03/21 19:45:09:
> >> On 3/21/13 11:23 AM, Joakim Tjernlund wrote:
> >>> James Li <jli at cumulusnetworks.com> wrote on 2013/03/21 17:53:08:
> >>>> On 3/21/13 2:22 AM, Joakim Tjernlund wrote:
> >>>>> James Li <jli at cumulusnetworks.com> wrote on 2013/03/20 21:48:10:
> >>>>>> On 3/20/13 1:39 PM, Joakim Tjernlund wrote:
> >>>>>>>>> should work fine. How might it break (even without the lsa_pos
> >>>>> changes)?
> >>>>>>> Identifying the correct ptop I/F using IP address won't fly when
> > you
> >>>>> have
> >>>>>>> the
> >>>>>>> same IP addresses on several ptop links.
> >>>>>> Interfaces are identified via ifindex for unnumbered, and there 
> > a
> >>>>>> flag on the ifp data structure to specify it as UNNUMBERED.
> >>>>> Ah, right. My memory fails me. Your version will work as long as
> >>>>> both sides uses unnumbered and sets ifindex in Router LSA.
> >>>>>
> >>>>> This is what I want to avoid actually:
> >>>>> Setting ifindex i RLSA is useless to the other routers and it will
> >>> make
> >>>>> some routers(inkl. older Quagga) fail to interop.
> >>>> the ifindex was never meant to be used by other routers. It's meant
> > for
> >>>> resolving the local egress interface ID from the router LSA links.
> >>> ifindex was set because from OSPF RFC pov unnumbered ptp's I/F does
> > not
> >>> have an IP address and you had to put something there so ifindex
> > became
> >>> it.
> >>> You don't send out useless info just because you have a local
> > dependency
> >>> on it.
> >>>
> >>> People later used that to get at their own I/F because they hadn't
> > figure
> >>> out my clever way of doing it :)
> >> You then need to take the debate to IETF and change the RFC. Until 
> >> RFC is changed, we will follow RFC and RFC clearly states:
> >>
> >> "For unnumbered point-to-point links, the Link Data field should be 
> >> to the unnumbered interface's MIB-II [Ref8] ifIndex value."
> > The spec also states that unnumbered I/Fs do not have an IP address.
> > Following the spec to the letter we will never have unnumbered I/Fs,
> > right?
> well yes, an unnumbered interface does not have its own unique IP 
> address. It borrows IP address from another interface.

No, according to the spec, unnumbered does not have an IP address. PDUs 
sent are using
some IP address but the ptp I/F itself does not have an IP address (and 
then no connected routes either)
You are describing how Linux emulates unnumbered I/Fs. This works well but 
it is not how OSPF
defines them.

So if we go the hardcore spec way, we don't have unnumbered at all, pick 

> > So we can end the unnumbered discussion here by that fact or we
> > can recognise that the spec has holes, errors and is vaguely written
> > and go from there, pick one.
> I would be careful making a statement like that. The RFC was validated 
> by multiple implementations from multiple vendors over the last 2 

No need, the spec is arcane and hard to get 100% right. You think all 
vendors got it right the first time they tried?

> >>>>> I propose we don't do that to ease interop. Several other vendors
> >>> already
> >>>>> do
> >>>>> this like newer BIRD. There was an discussion on IETF OSPF mail 
> >>> and
> >>>>> the
> >>>>> conclusion was that this does NOT violate the OSPF spec.
> >>>> If by interop, you mean one side is unnumbered, and the other side 
> >>>> numbered (like old Quagga), then it's really a configuration error
> > and
> >>>> will not be supported.
> >>> Why not? It doesn't cost us anything.
> >> Because it doesn't make any sense. Please distinguish "interop" with
> >> "configuration error", and the key point here is unnumbered 
> >> need to be *explicitly* configured.
> > Why do they need to be configured? Where is that stated or what use 
> > are you thinking about?
> For a numbered interface, you need to explicitly configure its IP 
> address; for an unnumbered interface, you need to explicitly configure 
> that you are borrowing an IP address. In linux, you just configure an 
> existing IP address, but that is still *explicit* in the sense that it's 

> not a unique IP address.

None of that implies you need to have an additional unnumbered config 
option, you
just configure your ptp I/F with the IP addresses you want to use.
So again, what do you want to do with an extra unnumbered config option?

> > Please note that this is separate from sending ifindex as noted in 1)
> > below.
> >
> > There is nothing in the spec that states the both ptp interfaces need 
> > be
> > configured the same w.r.t unnumbered vs. numbered. Got that confirmed 
> > Acee Lindem too
> The spec has never said this setup needs to be supported either.
> >> An "interop" issue, or backward compatibility issue, is when new 
> >> with numbered interfaces does not work with old Quagga with numbered
> >> interfaces. And we don't have this issue, they will work happily
> >> together with numbered interfaces on both end.
> >>
> >> We have an issue when administrator chooses to *explicitly* configure
> >> unnumbered on the new Quagga, but does not (upgrade and) configure
> >> unnumbered on the old Quagga. That's a configuration error.
> > No, it is a bug in old Quagga as it doesn't impl. unnumbered at all.
> > To workaround that bug you propose we always configure unnumbered
> > vs. numbered and I propose we just send the IP address always.
> ok let's talk about your approach. why do you want to send the IP 
> You do that because the old Quagga uses that information. Why does old 
> Quagga need that? Does it
> a) need the IP address to do SPF route calculation?
> or
> b) need that IP address for SPF nexthop calculation?
> The anwer is b), agree?


> now is it the right design to use that IP 
> address in nexthop calculation? As shown by Chrisian's current diff, 
> it's not the right design. The IP address can be easily derived from the 

> neighbor data structure. So what does that mean?

what I said before, old Q is buggy and so are some other routers.
Cristian's diff is to correct a bug in fairly recent Q, with old
Q I am talking about Q before my new SPF algorithm.

> That means old Quagga's reliance on that IP address is a bug. And now 
> you want a solution so that the new Quagga can inter-operate with this 
> bug? and as part of the solution you propose a protocol packet format 
> that is directly violating RFC?
> The bug should be fixed, not inter-operated.

of course it should be fixed and it is fixed in Q, but real installs out
there cannot update the whole network in one go

Anyhow, this is my suggestion and I not going to debate the ifindex
anymore. It is up to Q maintainers what they want to do.
I don't care really, all our deployed routers are fxiaed long ago.


More information about the Quagga-dev mailing list