[quagga-dev 1082] Re: point-to-point patch
paul at clubi.ie
Tue Apr 27 16:52:54 BST 2004
On Mon, 26 Apr 2004, Andrew J. Schorr wrote:
> I am attaching a patch to enhance quagga support for point-to-point
> interfaces. Based on my (perhaps incomplete) understanding of the
> current code, it is mostly designed to support PtP connections
> where the local and peer addresses are borrowed from other
> interfaces and specified with a /32 netmask. In the case where one
> wants to have a specifically assigned subnet (typically /30) for a
> PtP link (not sharing IP addresses with other interfaces), quagga
> does not seem to work. Under linux using the iproute2 tools, it is
> certainly possible to assign a subnet to a PtP link, and it is
> optional whether to specify a peer address in such a case. This
> patch gets quagga to support that scenario.
> The zebra daemon allows for the possibility of a PtP interface
> where the local address is present, but not the peer address.
> However, in zebra/zserv.c:zsend_interface_address_add(), the code
> translates a NULL destination address pointer into a 0.0.0.0
> address. So the child daemons (e.g. ripd, or ospfd) never receive
> the destination address as a NULL pointer, instead they get
> 0.0.0.0. So my patch fixes that problem.
How do you describe a NULL pointer on the wire? Your patch changes
the destination address field from a statically sized field ==
sizeof(prefix length of address family) containing 0's to a single 0
char? I dont see why that's needed.
> Also, in zebra/rt_netlink.c:netlink_interface_addr(), I had to add
> a memcmp to ignore the peer address when it's the same as the local
> address (this is copied from
> iproute2/ip/ipaddress.c:print_addrinfo(). Without that patch, zebra
> thinks that the local address is also the peer address in the
> situation where a peer address was never assigned.
> Other than that, it's a question of patching the lib and daemon
> directories to stop assuming that the connected->destination
> pointer is non-NULL. This involves some minor patches to ripd and
> bgpd (not tested), and some more significant patches to ospfd.
That assumption is correct though.
> In general, my patches get the code to behave the same as it
> did before if the connected->destination address is present and the
> prefixlen is IPV4_MAX_PREFIXLEN (32). If the destination address
> is missing, or the prefixlen is not 32, then it is assumed that a
> specific subnet has been dedicated to the PtP link, and the PtP
> interface is not identified by the peer address.
Ok, this assumption is fine. You noted the lack of dereference in
link_ptop_set() in quagga-users 1821, why not just fix that to
actually compare the contents to INADDR_ANY? As you noted, that
function otherwise follows the spec.
> I hope somebody finds this patch helpful, and it would be great if
> it could be integrated into CVS. I am very interested in any
> comments you may have, positive or negative; I know this is very
> desirable functionality for our site, and I hope others are
You've done a good bit of investigating, nice on. I question though
whether such wide-ranging changes are needed, is fixing
checks on co->destination not enough?
Paul Jakma paul at clubi.ie paul at jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam at dishone.st
The trouble with opportunity is that it always comes disguised as hard work.
-- Herbert V. Prochnow
More information about the Quagga-dev