On Thu, Feb 26, 2015 at 08:16:06PM +0000, John Arnold (GNS) wrote: > Forwarding to the dev list, a discussion from quagga-users. Discussion in > this thread: > https://lists.quagga.net/pipermail/quagga-users/2015-February/013960.html > > There appears to be a bug in setting broadcast address for interfaces > configured with /31 mask (RFC3021). Mask should be set to 255.255.255.255 > but is being set to 0.0.0.0 > > I did some digging and it appears there was a patch for RFC3021 back in 2002 > that was later reverted (performance reasons?) > https://code.google.com/p/google-quagga/source/detail?r=00df0c1e80811f3cf5eca0b28e720bf1bcc84a53<https://code.google.com/p/google-quagga/source/detail?r=00df0c1e80811f3cf5eca0b28e720bf1bcc84a53&path=/ripd/ripd.h> > > This was patched to support IPv6: > http://marc.info/?l=zebra&m=103850734408456 > > , and then later all reverted: > -2003-09-29 Paul Jakma <[email protected]> > - > - * zebra/connected.c: revert the 'generic PtP' patch as it causes > - far too many problems. > Etc. > > Also found reference to /31 handling in /lib/prefix.c/.h helper utility: > /* given the address of a host on a network and the network mask length, > * calculate the broadcast address for that network; > * special treatment for /31: returns the address of the other host > * on the network by flipping the host bit */ > > There's a decade of history to go through, but I see some various threads > about PtP links, /31, Ethernet broadcast handling and it's not clear what the > intent is or how it's handled. But it's definitely not RFC3021 compliant. > > Any thoughts/ideas here? History lesson or anything else helpful? I can > work on a patch but I'm new to this code base. > > Thanks, > John > > > From: John Arnold (GNS) > Sent: Wednesday, February 25, 2015 4:13 PM > To: '[email protected]' > Subject: Re: subnet /31 > > Hi, > > Is configuring Ethernet interfaces with /31 via zebra bugged? Broadcast > address gets configured as 0.0.0.0 and pings to the far side don't work. > I've reviewed RFC3021 and I think the broadcast address is supposed to be set > to link local broadcast, 255.255.255.255. > > >> Apply /31 via quagga: > quagga-router# conf t > quagga-router(config)# int e00-1 > quagga-router(config-if)# ip address 50.0.0.0/31 > quagga-router(config-if)# end > quagga-router# write mem > Building Configuration... > Integrated configuration saved to /etc/quagga/Quagga.conf > [OK] > > root@r1:/home/amazon# ifconfig e00-1 > e00-1 Link encap:Ethernet HWaddr ec:f4:bb:fc:21:74 > inet addr:50.0.0.0 Bcast:0.0.0.0 Mask:255.255.255.254 > inet6 addr: fe80::eef4:bbff:fefc:2174/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:25599 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:500 > RX bytes:0 (0.0 B) TX bytes:4786165 (4.7 MB)
So quagga seems to not be setting the broadcast, and it ends up as 0.0.0.0, which isn't right. > Applying ip/subnet via ifconfig works (pings work) yet gives a weird > broadcast address: > > >> apply /31 via ifconfig: > > root@amazon:/home/amazon# ifconfig e00-1 50.0.0.0/31 > root@amazon:/home/amazon# ifconfig e00-1 > e00-1 Link encap:Ethernet HWaddr ec:f4:bb:fc:21:74 > inet addr:50.0.0.0 Bcast:50.255.255.255 Mask:255.255.255.254 > inet6 addr: fe80::eef4:bbff:fefc:2174/64 Scope:Link > UP BROADCAST MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:25605 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:500 > RX bytes:0 (0.0 B) TX bytes:4787287 (4.7 MB) > > And anecdotally I found some references to RFC3021 broadcast addresses being > miscalculated in ifupdown code, so perhaps ifconfig is bugged too. ifupdown is debian (IFAIK), ifconfig is totally unrelated to ifupdown. ifupdown in current debian does it correctly, ifconfig appears to use old class based broadcast addresses for the given IP, ignoring the prefix specified. That seems like a bug obviously. > Using the newer libraries I see the same result as quagga (broadcast 0.0.0.0): > > >> add /31 via iproute2 tools > > root@amazon:/home/amazon# ip addr add 50.0.0.0/31 dev e00-1 > root@amazon:/home/amazon# ip addr show dev e00-1 > 8: e00-1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group > default qlen 500 > link/ether ec:f4:bb:fc:21:74 brd ff:ff:ff:ff:ff:ff > inet 50.0.0.0/31 scope global e00-1 > valid_lft forever preferred_lft forever > inet6 fe80::eef4:bbff:fefc:2174/64 scope link > valid_lft forever preferred_lft forever > root@amazon:/home/amazon# ifconfig e00-1 > e00-1 Link encap:Ethernet HWaddr ec:f4:bb:fc:21:74 > inet addr:50.0.0.0 Bcast:0.0.0.0 Mask:255.255.255.254 > inet6 addr: fe80::eef4:bbff:fefc:2174/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:25613 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:500 > RX bytes:0 (0.0 B) TX bytes:4788783 (4.7 MB) So that seems to do the same as quagga, which is to not set the broadcast and hence get the wrong result. So perhaps the kernel could be smarter about it, or maybe it thinks user space should know what it is doing when using /31 and specify the correct broadcast. It seems all the methods that use netlink is getting 0.0.0.0 as the broadcast and not working, while ifconfig is doing something weird that somewhat works (but I suspect might not always work), and ifupdown is doing the right thing. Of course if you ask 'ip a' what the state is, the broadcast isn't listed when it is 0.0.0.0, so perhaps it is ifconfig incorrectly showing the broadcast. Of course if ping doesn't work, then maybe the kernel isn't doing the right thing if broadcast isn't set. -- Len Sorensen _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
