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

Andrew J. Schorr aschorr at telemetry-investments.com
Tue Jun 3 15:55:47 BST 2008


Hi,

On Tue, Jun 03, 2008 at 04:47:21PM +0200, Joakim Tjernlund wrote:
> This is my concern too. Some configuration is needed IMHO to specify
> unnumbered i/f. My take is that we could add a new attribute in 
> zebra to specify a shared address. The admin will have to define what
> the shared address is.
> Each time an i/f added, zebra can check if the local PtP address matches
> the shared IP and toggle the ZEBRA_INTERFACE_UNNUMBERED flag for that
> i/f.

That could work, but it limits flexibility somewhat.  For example,
consider ospf router A.  It has 1 ethernet interface with address
192.168.1.1/24.  It has 3 PtP interfaces.  The first interface
is connected to router B, and has local address 192.168.1.1/32
and peer address 192.168.2.1/32.  It wants to run this interface
using the current quagga PtP behavior.  It has 2 more PtP interfaces
that are both connected to router C, and these interfaces both have
a local address of 192.168.1.1/32 and a remote peer address
of 192.168.3.1/32.

So if you decide that 192.168.1.1/32 is a special "shared" address,
and any PtP link with this local address should run in unnumbered mode,
then you lose the ability to connect to router B using the old method.

You could overcome this if you instead specify the pair of local
192.168.1.1/32 and peer 192.168.2.1/32 addresses to decide which interfaces
should use unnumbered behavior.  If that is what you are proposing (to
use both the local and peer address to decide if the interface is
unnumbered), then that will work great in the Linux paradigm, and I would
support that approach.  But if you use only the local address, then I think
you do not have enough information to make this decision, and I would
instead support using an explicit "unnumbered" interface attribute.

I hope I'm making sense, I've been having some trouble following this
thread, so perhaps I'm confused.

Regards,
Andy



More information about the Quagga-dev mailing list