Proposing a patch for bird

[Pierre Pfister]

Hello,

I took some time to read OSPFv2 and 3 spec, and here are my conclusions.

In OSPFv2, the bug I point shouldn't occur. Indeed, neighbors are identified with their addresses (Not on all links, but when it is not, we the link can probably not be changed like that).

In OSPFv3, the bug occurs when we ear a neighbor with a new link-local source address.
- If the reason is that we changed the link, the link id will be different. Therefore, a NEIGHBOR_CHANGED event will be risen.
  An new election is triggered, the neighbor's state goes to init, and then an LSA is sent, which makes the routing table to be recomputed.
- If the reason is that the neighbor's interface address just changed, I guess the neighbor should modify it's Link LSA, which will be synchronized with neighbors, and the routing table will be recomputed.

Therefore, I think the patch is necessary, and sufficient.

I tested it today, and I saw that the routing table is modified in short timing, according to the new source-address.

I hope I'm clear enough.


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."