Bird 2.x / OSPF v3 over ptp tunnels
Hello. I have some sites linked via wiregard tunnels, and exchanging route information with OSPF, using bird (mostly) One of my routers is running bird 2.0.7, while others runs 1.6.6 (due to different distributions) All OSPF v2 is running well, with configs like : interface "wg-*" { type ptp; }; OSPFv3 runs fine between bird 1.6 routers, but it does not with the bird 2.0 one. Here is its config : protocol ospf v3 ospfv3 { ipv6 {}; area 0 { interface "eth*" { stub; }; interface "wg*" { type ptp; cost 20; stub no; }; }; } Alas, it does not send any Hello packets on links. The remote routers do send their hellos, but they are ignored. It looks like bird put these interfaces in stub mode : linux3:/etc# birdc show ospf in ospfv3 BIRD 2.0.7 ready. ospfv3: Interface eth0 (IID 0) Type: broadcast Area: 0.0.0.0 (0) State: Waiting (stub) Priority: 1 Cost: 10 ECMP weight: 1 Hello timer: 10 Wait timer: 40 Dead timer: 40 Retransmit timer: 5 Designated router (ID): 0.0.0.0 Designated router (IP): :: Backup designated router (ID): 0.0.0.0 Backup designated router (IP): :: Interface wg4b (IID 0) Type: ptp Area: 0.0.0.0 (0) State: PtP (stub) Priority: 1 Cost: 20 ECMP weight: 1 Hello timer: 10 Wait timer: 40 Dead timer: 40 Retransmit timer: 5 Interface wg4a (IID 0) Type: ptp Area: 0.0.0.0 (0) State: PtP (stub) Priority: 1 Cost: 20 ECMP weight: 1 Hello timer: 10 Wait timer: 40 Dead timer: 40 Retransmit timer: 5 With OSPF v2, it does not : linux3:/etc# birdc show ospf in ospfv2 BIRD 2.0.7 ready. ospfv2: Interface wg4b (peer 172.16.101.21) Type: ptp Area: 0.0.0.0 (0) State: PtP Priority: 1 Cost: 200 ECMP weight: 1 Hello timer: 10 Wait timer: 40 Dead timer: 40 Retransmit timer: 5 Interface wg4a (peer 172.16.101.17) Type: ptp Area: 0.0.0.0 (0) State: PtP Priority: 1 Cost: 200 ECMP weight: 1 Hello timer: 10 Wait timer: 40 Dead timer: 40 Retransmit timer: 5 These interfaces have some IPv6 addresses, as it's needed for bird communications : 7: wg4b: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 state UNKNOWN qlen 1000 inet6 fe80::3/128 scope link valid_lft forever preferred_lft forever 8: wg4a: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 state UNKNOWN qlen 1000 inet6 fe80::3/128 scope link valid_lft forever preferred_lft forever Do you have tips on how to make them work ? Thanks, -- Bastien
Hi, On mar. 11 févr. 17:52:29 2020, Bastien Durel wrote:
7: wg4b: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 state UNKNOWN qlen 1000 inet6 fe80::3/128 scope link valid_lft forever preferred_lft forever 8: wg4a: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 state UNKNOWN qlen 1000 inet6 fe80::3/128 scope link valid_lft forever preferred_lft forever
Don’t put fe80 addresses by hand and definitely not with /128, let your kernel handles this. -- Alarig
On Tue, 2020-02-11 at 18:18 +0100, Alarig Le Lay wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hi,
On mar. 11 févr. 17:52:29 2020, Bastien Durel wrote:
7: wg4b: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 state UNKNOWN qlen 1000 inet6 fe80::3/128 scope link valid_lft forever preferred_lft forever 8: wg4a: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 state UNKNOWN qlen 1000 inet6 fe80::3/128 scope link valid_lft forever preferred_lft forever
Don’t put fe80 addresses by hand and definitely not with /128, let your kernel handles this.
I always wondered why not /128 ? In IPV4 they are just fine. Jocke
On mar. 11 févr. 18:27:43 2020, Joakim Tjernlund wrote:
On Tue, 2020-02-11 at 18:18 +0100, Alarig Le Lay wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hi,
On mar. 11 févr. 17:52:29 2020, Bastien Durel wrote:
7: wg4b: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 state UNKNOWN qlen 1000 inet6 fe80::3/128 scope link valid_lft forever preferred_lft forever 8: wg4a: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 state UNKNOWN qlen 1000 inet6 fe80::3/128 scope link valid_lft forever preferred_lft forever
Don’t put fe80 addresses by hand and definitely not with /128, let your kernel handles this.
I always wondered why not /128 ? In IPV4 they are just fine.
Because OSPF uses multicast. In IPv4 the route is implicitly on all interfaces. With IPv6, it’s the link-local. So if your address is /128 no route is added, and multicast can’t work. -- Alarig
Joakim Tjernlund wrote on 11/02/2020 19:27:
On Tue, 2020-02-11 at 18:18 +0100, Alarig Le Lay wrote:
On mar. 11 févr. 17:52:29 2020, Bastien Durel wrote:
7: wg4b: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 state UNKNOWN qlen 1000 inet6 fe80::3/128 scope link valid_lft forever preferred_lft forever 8: wg4a: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 state UNKNOWN qlen 1000 inet6 fe80::3/128 scope link valid_lft forever preferred_lft forever
Don’t put fe80 addresses by hand and definitely not with /128, let your kernel handles this.
I always wondered why not /128 ? In IPV4 they are just fine.
Because IPv6 Link-Local *IS* using a /64 prefix. [0] \-> rfc4291, Sec. 2.5.6 [1] If you assign link local addresses with any other mask length than 64. You cannot assume the software will behave as you expect. Because using < 64 > is outside the scope of how the link local addresses are defined in the RFC. Chriztoffer [0]: https://packetlife.net/blog/2011/apr/28/ipv6-link-local-addresses/ [1]: https://tools.ietf.org/html/rfc4291#section-2.5.6
Le mardi 11 février 2020 à 18:18 +0100, Alarig Le Lay a écrit :
Hi,
On mar. 11 févr. 17:52:29 2020, Bastien Durel wrote:
7: wg4b: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 state UNKNOWN qlen 1000 inet6 fe80::3/128 scope link valid_lft forever preferred_lft forever 8: wg4a: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 state UNKNOWN qlen 1000 inet6 fe80::3/128 scope link valid_lft forever preferred_lft forever
Don’t put fe80 addresses by hand and definitely not with /128, let your kernel handles this.
Hello, The kernel does not add link-local addresses on wireguard interfaces. But you're right about /128, I forget to type /64 on this end of the tunnel. Now it works :) Thanks a lot ! -- Bastien Durel DATA Intégration des données de l'entreprise, Systèmes d'information décisionnels. bastien.durel@data.fr tel : +33 (0) 1 57 19 59 28 fax : +33 (0) 1 57 19 59 73 12 avenue Raspail, 94250 GENTILLY France www.data.fr
participants (4)
-
Alarig Le Lay -
Bastien Durel -
Chriztoffer Hansen -
Joakim Tjernlund