Proposing a patch for bird
Hello, I am using bird as an OSPFv3 daemon and I encountered a bug while playing with the wires. Therefore, I would like to propose this correcting patch. If you have any more formal way to do it, please tell me. I looked at your gitlab, but couldn't find any way to propose a patch. Cheers, Pierre Pfister ---------------Here is my own commit's commentary that explains the patch--------- [DEBUG] Keep latest source address as neighbor's address In RFC5340, it is stated: "For all link types except virtual links, the Neighbor IP address is set to the IPv6 source address in the IPv6 header of the received OSPF Hello packet." 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. 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. ---------------Here is the patch as provided by git-------------- diff --git a/proto/ospf/hello.c b/proto/ospf/hello.c index 58e87bb..0fbedc3 100644 --- a/proto/ospf/hello.c +++ b/proto/ospf/hello.c @@ -152,6 +152,12 @@ ospf_hello_receive(struct ospf_packet *ps_i, struct ospf_iface *ifa, n->iface_id = ntohl(ps->iface_id); #endif } +#ifdef OSPFv3 + else if (!ipa_equal(n->ip, faddr)) { + OSPF_TRACE(D_EVENTS, "Neighbor address changed from %I to %I", n->ip, faddr); + n->ip = faddr; + } +#endif ospf_neigh_sm(n, INM_HELLOREC); pnrid = (u32 *) ((struct ospf_hello_packet *) (ps + 1));
On Tue, Oct 15, 2013 at 05:22:22PM +0200, Pierre Pfister wrote:
Hello,
I am using bird as an OSPFv3 daemon and I encountered a bug while playing with the wires.
Therefore, I would like to propose this correcting patch. If you have any more formal way to do it, please tell me. I looked at your gitlab, but couldn't find any way to propose a patch.
Hello Thanks for the patch. The change seems OK, i merged it. -- 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 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@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."
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@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@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."
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@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@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 Mon, Oct 21, 2013 at 01:42:45PM +0200, Pierre Pfister wrote:
Hello,
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.
OK, applied. -- 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)
-
Ondrej Zajicek -
Pierre Pfister