[quagga-dev 11462] Possible Bug in BGPd

John quagga at johnbond.org
Tue Sep 2 11:56:00 BST 2014


Hello List,

I recently came across an issue which i believe is a bug.  My testing
indicates that if you have two IPv6 Interfaces which are in the same
prefix as a neighborer, when you receive a route it is installed against
the interface that is lexicographically lower.  To explain further it is
best to use an example.

I have ubutntu 12.04 LTS systems running quagga Version 0.97.3.  With
the following configuration

Router 1
/etc/network/interfaces
https://gist.github.com/b4ldr/899774651076eb6dc602#file-router1-interfaces

/etc/quagga/bgpd.conf
https://gist.github.com/b4ldr/899774651076eb6dc602#file-router1-bgpd

Router 2
/etc/network/interfaces
https://gist.github.com/b4ldr/899774651076eb6dc602#file-router2-interfaces

/etc/quagga/bgpd.conf
https://gist.github.com/b4ldr/899774651076eb6dc602#file-router2-bgpd

Configured like this everything works correctly and router2 is able to
successfully ping the dummy interface in router 1.  The following shows
relevant output with working configuration

Router 1
https://gist.github.com/b4ldr/899774651076eb6dc602#file-router1-working

Router 2
https://gist.github.com/b4ldr/899774651076eb6dc602#file-router2-working

The problem i see is when i change the address of dummy0 from
2001:DB8::42/48 to 2001:DB8::42/47.  The change in subnet mask means
that the interface is now on the same connected network as the Ethernet
address used for the bgp session.  When this happens i see the following
route inserted in to router1

B>* ::/0 [20/0] via fe80::a00:27ff:fe02:e9f2, dummy0, 00:01:25

(full output -
https://gist.github.com/b4ldr/899774651076eb6dc602#file-router1-broken)

Notice that this has installed the route to on the dummy interface

I see this route on router 2
B>* 2001:db8::/48 [20/0] via fe80::7c52:97ff:fe39:f4b7, eth1, 00:02:59

(full output -
https://gist.github.com/b4ldr/899774651076eb6dc602#file-router2-broken)

Notice here that the via address is the Link-Local address of dummy0 on
router 1.

I attempted to add the following configuration on router 1 however this
had no effect, but the documentation does state that this configuration
is deprecated

 neighbor 2001:DB8:1::1 interface eth0.

I preformed some testing and i have noticed the if, in linux, i change
the interface name of eth0 to ath0.  Then things start to work again

Router 1:

B>* ::/0 [20/0] via fe80::a00:27ff:fe02:e9f2, ath0, 00:01:30

Route is installed to ath0

(full output -
https://gist.github.com/b4ldr/899774651076eb6dc602#file-router1-fix1)

Router 2:

B>* 2001:db8::/48 [20/0] via fe80::a00:27ff:fe15:bd18, eth1, 00:03:02

we now go via the link-local address of ath0 (previously named eth0)

(full output -
https://gist.github.com/b4ldr/899774651076eb6dc602#file-router2-fix1)

So it would seem that quagga chooses which interface to install routes
against and the link-local address it sends in the Next Hop field based
on which interface name is lexicographically first.

I have tried to locate documentation on what the correct behavior should
be or even what the expected behavior of quagga should be and i have
come up short.  However my expectation would be that the the link local
address of 2001:DB8:1::64 (eth0/ath0) should be preferred in both cases
for one or both of the following reasons.
	- 2001:DB8:1::64 is the next hop so its link-local address should be sent
	- 2001:DB8:1::64/64 is a more specific prefix then 2001:DB8::42/47

Another way which i thought one may be able to work around this option
is to stop sending the additional link-local address in announcements.
>From my reading of rfc2545, this would seem to be valid however i was
unable to find a configuration option in quagga/bgpd.

Sorry for all the links however having all of the output in-line was
making the email some what difficult to read.  Please let me know if you
would like further clarification or for me to preform further testing.
I am also in the irc room as balder (CEST) if you want to to get more
information there.

Thanks John









More information about the Quagga-dev mailing list