Does radv protocol (re)scan interfaces on IPv6?
I am trying to isolate an issue with the radv protocol running on IPv6 I have possibly the world's simplest radv configuration: protocol radv evrradv { interface "-evrr-000000", "evrr-*" { max ra interval 4; }; } The idea here is that the router provides radv information on all interfaces with names starting evrr- except evrr-000000. What I am seeing is that if I add another interface, radv does not appear to work. A reload produces: # birdc6 reload evrradv BIRD 1.3.4 ready. evrradv: reload failed This doesn't help A restart produces: # birdc6 restart evrradv BIRD 1.3.4 ready. evrradv: restarted This fixes things, and radv appears to work. I am quite sure this used to work with the same software a little while ago, but it may be that I'm going mad. Should radv pick up creation and deletion of new interfaces? Might this be something related to the ordering of applying the IP address and taking the interface up or something? How is this meant to work? This is an old version of bird (1.3.4), but initial tests indicate the same is happening on a relatively recent version (I'll attempt to reproduce this further). I don't really want to restart bird6's radv protocol every time I add an interface as this is quite frequent. -- Alex Bligh
On Mon, Sep 01, 2014 at 12:57:57PM +0100, Alex Bligh wrote:
I am trying to isolate an issue with the radv protocol running on IPv6
I have possibly the world's simplest radv configuration:
protocol radv evrradv { interface "-evrr-000000", "evrr-*" { max ra interval 4; }; }
The idea here is that the router provides radv information on all interfaces with names starting evrr- except evrr-000000.
What I am seeing is that if I add another interface, radv does not appear to work.
This should work. Could you check whether 'evrradv: Adding interface XXX' log message is logged if you enable debug messages for evrradv? Also what you mean by 'add another interface'? The interface is created, or just bringed up? If the interface is also created, could you try to wait several seconds between the interface creation and activation? Are there any error messages in log?
A reload produces:
Reload is only for route export/import, not relevant to radv. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On 2 Sep 2014, at 12:52, Ondrej Zajicek <santiago@crfreenet.org> wrote:
This should work. Could you check whether 'evrradv: Adding interface XXX' log message is logged if you enable debug messages for evrradv?
We've managed to find the cause of the problem, which is deeply strange. We were disabling duplicate address detection after setting the link up. If we move this to disabling DAD before setting the link up, the problem does not arise. Note that this is just *detection* - it wasn't actually discovering a duplicate address or anything. I'll check the logs if this is still interesting.
Also what you mean by 'add another interface'? The interface is created, or just bringed up?
We were 1. creating a new interface (a veth interface) 2. adding IP addresses, 3. then bringing the link up. We were doing doing disabling DAD after step 3, but are now doing it after step 2, which appears to eliminate the problem. Not disabling DAD at all is also fine (save of course in the situations where we need it disabled - VMware I'm looking at you).
If the interface is also created, could you try to wait several seconds between the interface creation and activation?
I could try that for debugging purposes if you like, though we appear to have fixed the problem for now. Why this fixes the problem is a mystery!
Are there any error messages in log?
Not that we noticed. -- Alex Bligh
On Tue, Sep 02, 2014 at 08:22:11PM +0100, Alex Bligh wrote:
On 2 Sep 2014, at 12:52, Ondrej Zajicek <santiago@crfreenet.org> wrote:
This should work. Could you check whether 'evrradv: Adding interface XXX' log message is logged if you enable debug messages for evrradv?
We've managed to find the cause of the problem, which is deeply strange. We were disabling duplicate address detection after setting the link up. If we move this to disabling DAD before setting the link up, the problem does not arise. Note that this is just *detection* - it wasn't actually discovering a duplicate address or anything.
Yes, i suspected something like that. Generally, when the interface is created or bringed up, link-local address is automatically assigned, but it is marked as tentative, which BIRD ignores. We should probably wait until the the tentative flag for link-local address is removed. I think it probably tries to bind a socket on that tentative address, which fails (although that should be logged). -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
participants (2)
-
Alex Bligh -
Ondrej Zajicek