OSPFv3 and stub interfaces without lladdr
Hi, I am trying to get ipv6 routes to openvpn server into ospf. if have an interface "tun*" { stub; }; in my bird6.conf. openvpn does not add link level addrs to its interfaces. That's why ospf ignores this interface. Ignoring it for doing ospf on it is okay, as ospf really wants to run over lladdrs. But do stub networks require a lladdr to be used in ospf? This is at least confusing to me. bird> sh int tun2 up (index=20) PtP Multicast AdminUp LinkUp MTU=1500 fdxx:xxxx:xxxx:4000::1/64 (Primary, scope site) bird> show ospf interface "tun2" ospf1: A workaround is to add fe80::1/64 to tun2 in some "up" script in openvpn, so that bird6 sees the interface. But that does not feel right, really. Cheers Christian -- www.cosmokey.com
tldr: +1metoo On 05/28/2015 06:33 PM, Christian Tacke wrote:
[...]
openvpn does not add link level addrs to its interfaces. That's why ospf ignores this interface. Ignoring it for doing ospf on it is okay, as ospf really wants to run over lladdrs. But do stub networks require a lladdr to be used in ospf? This is at least confusing to me.
Previous occurence: http://bird.network.cz/pipermail/bird-users/2012-August/007868.html And I stumbled into it in the past, (ending up using stubnet for now, hardcoding an extra copy of the set of addresses into the bird config) and I know some more, the latest being a user only a few minutes ago on IRC, running into the same issue. I just scanned RFC5340 and it looks like there's no mandatory "ignore if no link local" policy in there. It says that Link-LSAs are allowed in a stub network, so for them you'd need the lladdr, but that's not the case in "normal" simple usage. In favor of intuitive behaviour for users, I'd vote to have bird6 just happily treat stub without ipv6 link local the same way as it does with IPv4 on stub interfaces. So addresses on the lo in linux, and e.g. also the openvpn example (which I fixed in the same way, putting some fe80 on the link to satisfy bird) would work out of the box as stub. If not, adding more logging, like the following suggestion would be useful to prevent users from wasting too much time and getting frustrated: "bird6: ospfX: Not adding OSPFv3 interface $FOO to area a.b.c.d because it has no link local address configured". -- Hans van Kranenburg - System / Network Engineer T +31 (0)10 2760434 | hans.van.kranenburg@mendix.com | www.mendix.com
Hi, On Sun, May 31, 2015 at 01:34:46 +0200, Hans van Kranenburg wrote:
In favor of intuitive behaviour for users, I'd vote to have bird6 just happily treat stub without ipv6 link local the same way as it does with IPv4 on stub interfaces. So addresses on the lo in linux, and e.g. also the openvpn example (which I fixed in the same way, putting some fe80 on the link to satisfy bird) would work out of the box as stub.
We (Hans, _robbat2 and me) looked further into this, especially we started to look into the sources. We learned, that the current situation is not as easy as one might hope. As this looks like a bigger rewrite, we need to understand the current behaviour. And that is a bit strange: The idea seems be to have only one ospf-interface ("show ospf interface") per real interface / lladdr. And the networks connected to that single ospf-interface. This is in contrast to ipv4, where one has one ospf-interface per each primary address on the interface. First note: If there are multiple lladdr on one real interface, multiple ospf-interfaces are created. We gussed, that the assumption was, that there is only one lladdr per interface. --> Is this assumption covered by any RFC? I doubt so. --> Is this behaviour intended, or is this a bug? If we want to create (one or many) stub ospf-interface(s) for an interface without lladdr, the arising questions are: --> create one ospf-interface or many? --> If one, which address should be used for it? All of this gets more complex, when considering, that this has to be torn down and replaced by the "classic" stuff, if a lladdr gets added to the interface. Thoughts?
If not, adding more logging, like the following suggestion would be useful to prevent users from wasting too much time and getting frustrated: "bird6: ospfX: Not adding OSPFv3 interface $FOO to area a.b.c.d because it has no link local address configured".
If the above is too complex, then yes, better logging would certainly help. Cheers Christian -- www.cosmokey.com
On Mon, Jun 01, 2015 at 10:39:39PM +0200, Christian Tacke wrote:
Hi,
On Sun, May 31, 2015 at 01:34:46 +0200, Hans van Kranenburg wrote:
In favor of intuitive behaviour for users, I'd vote to have bird6 just happily treat stub without ipv6 link local the same way as it does with IPv4 on stub interfaces. So addresses on the lo in linux, and e.g. also the openvpn example (which I fixed in the same way, putting some fe80 on the link to satisfy bird) would work out of the box as stub.
We (Hans, _robbat2 and me) looked further into this, especially we started to look into the sources. We learned, that the current situation is not as easy as one might hope. As this looks like a bigger rewrite, we need to understand the current behaviour.
Hi There are several implementation issues related to OSPF interfaces and addresses: First, BIRD generally handle interfaces without any IP address as down regardless of their admin status. This helps in some cases (like when 802.1x negotiation should happen before using the iface) but it is limitation in cases when unnumbered interfaces should be used. Alhough this is not an issue for you as you want to use stub interfaces with global addresses, but it is is related problem. Second, OSPFv2 and OSPFv3 share most code and because OSPFv2 has separate interface-instance per network prefix, it depends mainly on address- -notifications than on iface-notifications. The same design was carried over to OSPFv3, only waiting for regular addresses was replaced by waiting for link-local addresses. This also solves issues when link-local address appears later than iface or is changed.
The idea seems be to have only one ospf-interface ("show ospf interface") per real interface / lladdr. And the networks connected to that single ospf-interface. This is in contrast to ipv4, where one has one ospf-interface per each primary address on the interface.
First note: If there are multiple lladdr on one real interface, multiple ospf-interfaces are created. We gussed, that the assumption was, that there is only one lladdr per interface. --> Is this assumption covered by any RFC? I doubt so. --> Is this behaviour intended, or is this a bug?
Well this was supposed to be handled by 'secondary' flag for an address, but it seems like Linux IPv6 behavior is different than IPv4 behavior and does not use secondary flags (muliple addresses from the same network are attached to the iface) in IPv6.
If we want to create (one or many) stub ospf-interface(s) for an interface without lladdr, the arising questions are: --> create one ospf-interface or many? --> If one, which address should be used for it?
All of this gets more complex, when considering, that this has to be torn down and replaced by the "classic" stuff, if a lladdr gets added to the interface.
Thoughts?
Proper solution would be like: 1) Have separate ospf_if_notify() for OSPFv2 and OSPFv3 like it is already done for ospf_ifa_notify[23](). 2) Add/remove OSPFv3 ifaces per interface based on events in ospf_if_notify3(), not in ospf_ifa_notify3(). 3) If there is no link-local address, interface should be stub. If link-local address apprears/disappears, interface should be unstubbified/stubbified. 4) It is likely that there are code in OSPF assuming ospf_iface->addr is non-NULL, this should be fixed It is a question what should be done when old link-local address disappears but there is another one. I think that OSPFv3 uses mainly Router ID and not IP address to identify neighbors so the address could be changed withouth much disturbance to neighbors, but i would have to check that. If you want to make a patch doing this, i would be glad, otherwise i would look at this issue in the future. -- 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."
Hi, On Tue, Jun 02, 2015 at 11:23:56 +0200, Ondrej Zajicek wrote: [...]
Proper solution would be like: [...] 4) It is likely that there are code in OSPF assuming ospf_iface->addr is non-NULL, this should be fixed [...]
I have tried to look into this. Went through all uses of ospf_iface->addr and considered them. Most are fine. Here's a list of the most interesting places: ospf/iface.c:ospf_sk_open() sk->saddr = ifa->addr->ip; ospf_sk_open is hopefully only called on non-stub interfaces... ospf/iface.c:ospf_iface_classify() This one might be called with a NULL, maybe. ospf/iface.c:ospf_iface_stubby() same ospf/packet.c:ospf_rx_hook() src_local = ipa_in_net(sk->faddr, ifa->addr->prefix, ifa->addr->pxlen); dst_local = ipa_equal(sk->laddr, ifa->addr->ip); ... if (ifa->cf->real_bcast && ipa_equal(sk->faddr, ifa->addr->ip)) that code should only be called on active links, really ospf/hello.c:ospf_send_hello() /* If there is no other target, we also send HELLO packet to the other end */ if (ipa_nonzero(ifa->addr->opposite) && !ifa->strictnbma && maybe add an "ifa->addr && " in the front here, simply? But really, understanding most of this code is currently beyond my time budget. So hopefully my findings are helpful to somone.
If you want to make a patch doing this, i would be glad, otherwise i would look at this issue in the future.
I think, it would be better, if you look into it in the future. Cheers Christian -- www.cosmokey.com
participants (3)
-
Christian Tacke -
Hans van Kranenburg -
Ondrej Zajicek