[quagga-dev 5423] Re: [PATCH] RFC 2328, chap 8.1:

Joakim Tjernlund joakim.tjernlund at transmode.se
Mon Jun 2 16:22:01 BST 2008

On Mon, 2008-06-02 at 15:56 +0100, paul at clubi.ie wrote:
> On Mon, 2 Jun 2008, Joakim Tjernlund wrote:
> > hmm, that could work once lsa_link_ptop_set() uses ifIndex I guess. 
> > But this might be an incompatible change and require some sort of 
> > manual config I think.
> Why?

Current quagga will try to match it with a connected remote address and 
will fail. 

> > Any chance one can get away with a NULL oi?
> Not really.

too bad :(

> > Seems easier to just use a IP for the router, iff I have 
> > the correct oi. Should not that work too?
> I guess it could. If you send a packet via a PtP link, the other side 
> is bound to get it and process it through its IP layer, isn't it? You 
> might have to test that ;). (Preferably with at least a few different 
> OSes..).

But this is already a known method(I think). Look at the old route
 route  [-v]  [-A  family]  add [-net|-host] target [netmask Nm] [gw Gw]
              [metric N] [mss M] [window W]  [irtt  I]  [reject]  [mod]  [dyn]
              [reinstate] [[dev] If]

notice the last [[dev] If]?
Here the details of dev If:

 dev If       force  the  route to be associated with the specified device, as
              the kernel will otherwise try to determine the device on its own
              (by  checking already existing routes and device specifications,
              and where the route is added to). In most  normal  networks  you
              won’t need this.

              If  dev  If is the last option on the command line, the word dev
              may be omitted, as it’s the default. Otherwise the order of  the
              route modifiers (metric - netmask - gw - dev) doesn’t matter.

Saw this if the OSPF RFC too:
[4] Note that no host route is generated for, and no IP packets can
    be addressed to, interfaces to unnumbered point-to-point networks.
    This is regardless of such an interface's state.
Not sure what to make of that.

> > I was hoping to to get "unnumbered" PtP i/f's to work automatically 
> > iff one had choose the local PtP IP addresses wisely, namely the 
> > routerID. That is, all PtP i/f's would use the routerID as its 
> > local IP address. link_data in the LSAs would then hold the 
> > routerID as well.
> The router-ID isn't an IP address though. Advertising it as an IP 
> address could break virtual-links, where the administrator has not 
> configured the ID as a local IP address (virtual-link is unicast).

Yes, but in my suggestion you would have to make routerID a
real IP address iff you want "unnumbered" PtP links too. Is that
too much you think?

> It might be hard to avoid need to configure an IP address for use by 
> unnumbered addresses. Either way, zebra will have to be taught to 
> detect shared-addresses and flag all or one of them as 'unnumbered'.

Perhaps one could add a command to ospf/zebra that will specify such an
address, default would be routerID. Then all PtP links that
have that address will be considered "unnumbered". That way
you don't have to flag every PtP i/f it is numbered or unnumbered.


More information about the Quagga-dev mailing list