Proposing a patch for bird

[Pierre Pfister]

You are right, the solution is not as simple as I suggested.

An algorithmically simple way to solve the issue could be to delete the neighbor's state when the source address changes (and start again from init state). But this is really not elegant.

A better solution probably exists. I think I'm going to read the specs (ow, it's so long…), and maybe I'll be able to propose a better solution.

Anyway, this only happens when someone "plays with the wires", so I guess it has never been observed. Unfortunately, in my context, it's very important to support such events.

Cheers,

Pierre


On Oct 16, 2013, at 3:45 PM, Ondrej Zajicek <santiago at crfreenet.org> wrote:

> On Tue, Oct 15, 2013 at 05:22:22PM +0200, Pierre Pfister wrote:
>> It is not said which source address should be kept among all received 
>> Hello packets from the same neighbor. In current implementation, the first 
>> is used.
> 
> I think that RFC 2328 10.5 par. "When receiving an Hello Packet from ..."
> and RFC 5340 4.2.2.1. more or less says that last received IP should be
> saved in neighbor structure.
> 
>> In some cases, the neighbor's source address can change. But, in OSPFv3, 
>> neighbors are always identified by their IDs. If we don't keep the latest 
>> address as the neighbor's address, all HELLO packets will be correctly 
>> considered, but further unicast packet sent to the router that changed its 
>> address may not be received, making the link state blocking indefinitly.
>> 
>> Cases where the source address can change are:
>> - A wire's end is moved from one port to another.
>> - For some reason, a router decides to change its Active Interface, which 
>> choice is implementation dependent. 
> 
> On the second thought, i am nor sure if the patch is entirelly correct - 
> at least, we have to recompute routing tables to update nexthops in
> routes to the new IP. If a wire is moved from one port to another, then
> also the iface ID would change and router-LSA have to be reoriginated.
> 
> But it is true that the specification does not describe any kind of
> event related to such change.
> 
> -- 
> Elen sila lumenn' omentielvo
> 
> Ondrej 'SanTiago' Zajicek (email: santiago at 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."