Re: Bird just doesn't want to find OSPF neighbors although they are there and can communicate
On Wed, Oct 20, 2021 at 05:33:03AM +0200, Lukas Haase wrote: > Hi Ondrej, > > > On Tue, Oct 19, 2021 at 07:49:09AM +0200, Lukas Haase wrote: > > > I have googled like crazy but haven't found both pages yet. > > > Maybe I should use DuckDuckGo finally. > > > While those didn't fix the problem yet they are helpful. Thanks! > > > > > > > Have you tried setting the type to 'ptmp' or 'ptp' instead of 'nbma'? > > > > > > Yes, I tried ptp. > > > To my understanding, bird should stop sending multicast packets. > > > Instead, it continued to send packets to 224.0.0.5. > > > Why is that? Doesn't make sense to me at all. > > > > Hi > > > > OSPF on PtP interfaces should always use multicast (by specification). > > It is generally assumed that if you have (real) ptp iface, you do not > > need dst address, you just send it to the other end (so you can also > > always deliver multicast). > > Is the difference between ptp and broadcast then only a protocol difference > but on IP level it is identical? (I.e., the IP packets have src address of > the sender and destination address 224.0.0.5)? On IP level: Broadcast - some messages (e.g. Hellos, LSA floods) are sent as multicast, some as unicast (e.g. retransmissions) PtP - all messages are sent as multicast (BIRD, including v2.0.8, used to send some messages as unicast, but that is wrong and fixed in dev branch) NBMA - all messages are sent as unicast PtMP - generally unicast, but Hellos depend on implementation On protocol level: Broadcast and NBMA - networks are represented in LSA database as nodes PtP and PtMP - direct links between routers in LSA database > Also how about ptmp? > It seems when I set bird to ptmp, the IP packets do *not* have the 224.0.0.5 > as destination address but the address given as "neighbor". This is what > makes it work for me, I guess. > > I found this: > 1. https://forum.mikrotik.com/viewtopic.php?t=179552 > 2. https://docs.nycmesh.net/networking/vpnwireguardospf/ > > The latter one writes: "# Use PtP is going to a Mikrotik Router. BIRD and > Mikrotik dont speak the same PTMP". > > Indeed, as mentioned above (and linked in the forum), Mikrotik uses 224.0.0.5 > in ptmp whereas bird does not. > Does this mean bird is RFC incompliant for ptmp? > What is meant by "BIRD and Mikrotik dont speak the same PTMP" ? PtMP is kind of underspecified in RFC. It is supposed to run on strange interfaces like virtual circuits over PSTN without broadcast capability and without full end-to-end connectivity (in contrast to NBMA, which expects full end-to-end connectivity). RFC 2328 assumes two ways to find neighbors on PtMP networks - manual configuration (as done by BIRD) or iface-specific out-of-band detection (like externa info about active circuits, or in Wireguard case, that might be list of known wg neighbors). Some implementations use multicast Hello to find neighbors when running on ethernet, but that is outside of spec. > > > What are the exact conditions that the other station shows up as OSPF > > > neighbor. I confirmed already with tcpdump that the OSPF Hello packages > > > appear on the interface and both look *identical* (in terms of Hello > > > Timer, Dead Timer, Mask, Priority). > > > What could possible happen that bird would not add such packets to the > > > neighbor list? > > > > It is possible that BIRD just ignores the packet as it does not match its > > src/dst address. > > You could enable 'debug all' to see if there are Hello packets logged by > > BIRD. > > Oct 20 03:28:54 endpoint2 bird: test: Starting routing table calculation > Oct 20 03:28:54 endpoint2 bird: test: Starting routing table calculation for > area 0.0.0.0 > Oct 20 03:28:54 endpoint2 bird: test: Starting routing table calculation for > inter-area (area 0.0.0.0) > Oct 20 03:28:54 endpoint2 bird: test: Starting routing table calculation for > ext routes > Oct 20 03:28:54 endpoint2 bird: test: Starting routing table synchronisation > Oct 20 03:28:54 endpoint2 bird: test > added [best] 192.168.56.228/30 dev > wg-tun > Oct 20 03:28:54 endpoint2 bird: test < rejected by protocol 192.168.56.228/30 > dev wg-tun > Oct 20 03:28:58 endpoint2 bird: test: Wait timer fired on wg-tun > Oct 20 03:28:58 endpoint2 bird: test: Interface wg-tun changed state from > Waiting to DR > Oct 20 03:28:59 endpoint2 bird: test: Updating router state for area 0.0.0.0 > Oct 20 03:29:03 endpoint2 bird: test: HELLO packet sent via wg-tun > Oct 20 03:29:05 endpoint2 bird: test: HELLO packet received from nbr > 192.168.56.228 on wg-tun > Oct 20 03:29:05 endpoint2 bird: test: Bad HELLO packet from nbr > 192.168.56.228 on wg-tun - eligibility mismatch (1) .. > Indeed, bad hello packet. But what the heck? Why? This is the relevant error message (which whould be here even without 'debug all'). List of configured neighbors also contain information whether they are eligible for DR/BDR role. Endpoint1 (192.168.56.228) wants to be eligible (priority > 0), but in endpoint2
Re: Bird just doesn't want to find OSPF neighbors although they are there and can communicate
Hi Ondrej, > On Tue, Oct 19, 2021 at 07:49:09AM +0200, Lukas Haase wrote: > > I have googled like crazy but haven't found both pages yet. > > Maybe I should use DuckDuckGo finally. > > While those didn't fix the problem yet they are helpful. Thanks! > > > > > Have you tried setting the type to 'ptmp' or 'ptp' instead of 'nbma'? > > > > Yes, I tried ptp. > > To my understanding, bird should stop sending multicast packets. > > Instead, it continued to send packets to 224.0.0.5. > > Why is that? Doesn't make sense to me at all. > > Hi > > OSPF on PtP interfaces should always use multicast (by specification). > It is generally assumed that if you have (real) ptp iface, you do not > need dst address, you just send it to the other end (so you can also > always deliver multicast). Is the difference between ptp and broadcast then only a protocol difference but on IP level it is identical? (I.e., the IP packets have src address of the sender and destination address 224.0.0.5)? Also how about ptmp? It seems when I set bird to ptmp, the IP packets do *not* have the 224.0.0.5 as destination address but the address given as "neighbor". This is what makes it work for me, I guess. I found this: 1. https://forum.mikrotik.com/viewtopic.php?t=179552 2. https://docs.nycmesh.net/networking/vpnwireguardospf/ The latter one writes: "# Use PtP is going to a Mikrotik Router. BIRD and Mikrotik dont speak the same PTMP". Indeed, as mentioned above (and linked in the forum), Mikrotik uses 224.0.0.5 in ptmp whereas bird does not. Does this mean bird is RFC incompliant for ptmp? What is meant by "BIRD and Mikrotik dont speak the same PTMP" ? > > For this reason I went for nbma. > > > > Now I have tried ptmp and magically the two see each other now. Does make > > ZERO sense to me. > > Why would ptmp work and nbma not? > > I literally just replaced "nbma" with "ptmp" (kept "neighbors" the same, > > for example). > > I am not sure whether NBMA in BIRD works with /31 prefixes. These are > really ptp prefixes and are usually used with PtP mode. Could you try > /30 prefix? I just did. No change unfortunately. As initially reported, both OSPF hello messages show up on both ends via tcpcump and both ends do not show the neighbor at all. When I just change "nbma" to "ptmp" it works again. Crazy!! > Although technically, Wireguard is more PtMP than NBMA, but for two peers > it should not matter. I think for this wireguard link I may be happy with ptmp but I also have a link with a Mikrotik router over GRE that doesn't work either. broadcast and ptp for some reason do not work; ptmp does not work because they are not the same so what's left is nbma which seems to work on Mikrotik side. For this reason I'd like to understand why the heck nbma does not even work between two birds. Regardless, I will open a new thread for the Mikrotik one. > > What are the exact conditions that the other station shows up as OSPF > > neighbor. I confirmed already with tcpdump that the OSPF Hello packages > > appear on the interface and both look *identical* (in terms of Hello Timer, > > Dead Timer, Mask, Priority). > > What could possible happen that bird would not add such packets to the > > neighbor list? > > It is possible that BIRD just ignores the packet as it does not match its > src/dst address. > You could enable 'debug all' to see if there are Hello packets logged by BIRD. Oct 20 03:28:54 endpoint2 bird: test: Starting routing table calculation Oct 20 03:28:54 endpoint2 bird: test: Starting routing table calculation for area 0.0.0.0 Oct 20 03:28:54 endpoint2 bird: test: Starting routing table calculation for inter-area (area 0.0.0.0) Oct 20 03:28:54 endpoint2 bird: test: Starting routing table calculation for ext routes Oct 20 03:28:54 endpoint2 bird: test: Starting routing table synchronisation Oct 20 03:28:54 endpoint2 bird: test > added [best] 192.168.56.228/30 dev wg-tun Oct 20 03:28:54 endpoint2 bird: test < rejected by protocol 192.168.56.228/30 dev wg-tun Oct 20 03:28:58 endpoint2 bird: test: Wait timer fired on wg-tun Oct 20 03:28:58 endpoint2 bird: test: Interface wg-tun changed state from Waiting to DR Oct 20 03:28:59 endpoint2 bird: test: Updating router state for area 0.0.0.0 Oct 20 03:29:03 endpoint2 bird: test: HELLO packet sent via wg-tun Oct 20 03:29:05 endpoint2 bird: test: HELLO packet received from nbr 192.168.56.228 on wg-tun Oct 20 03:29:05 endpoint2 bird: test: Bad HELLO packet from nbr 192.168.56.228 on wg-tun - eligibility mismatch (1) Oct 20 03:29:13 endpoint2 bird: test: HELLO packet sent via wg-tun Oct 20 03:29:13 endpoint2 bird: test: HELLO packet sent via wg-tun Oct 20 03:29:23 endpoint2 bird: test: HELLO packet sent via wg-tun Oct 20 03:29:25 endpoint2 bird: test: HELLO packet received from nbr 192.168.56.228 on wg-tun Oct 20 03:29:25 endpoint2 bird: test: Bad HELLO packet from nbr 192.168.56.228 on wg-tun - eligibility mismatch (1) Oct 20 03:29:34 endpoint2 bird: test: HELLO packet
Re: Bird just doesn't want to find OSPF neighbors although they are there and can communicate
On Tue, Oct 19, 2021 at 07:49:09AM +0200, Lukas Haase wrote: > I have googled like crazy but haven't found both pages yet. > Maybe I should use DuckDuckGo finally. > While those didn't fix the problem yet they are helpful. Thanks! > > > Have you tried setting the type to 'ptmp' or 'ptp' instead of 'nbma'? > > Yes, I tried ptp. > To my understanding, bird should stop sending multicast packets. > Instead, it continued to send packets to 224.0.0.5. > Why is that? Doesn't make sense to me at all. Hi OSPF on PtP interfaces should always use multicast (by specification). It is generally assumed that if you have (real) ptp iface, you do not need dst address, you just send it to the other end (so you can also always deliver multicast). > For this reason I went for nbma. > > Now I have tried ptmp and magically the two see each other now. Does make > ZERO sense to me. > Why would ptmp work and nbma not? > I literally just replaced "nbma" with "ptmp" (kept "neighbors" the same, for > example). I am not sure whether NBMA in BIRD works with /31 prefixes. These are really ptp prefixes and are usually used with PtP mode. Could you try /30 prefix? Although technically, Wireguard is more PtMP than NBMA, but for two peers it should not matter. > There is also another problem: One of my clients is a Mikrotik router. > This thing supports "broadcast, "ptp", "ptmp" and "nmba". However, I can > weirdly only configure "NBMA Neighbors". > I have tried this link with ipip, GRE, all types of connections but still no > luck yet. > > Seriously, the last time setting something up was that much of a hassle was > sendmail 25 years ago :-( For some reason, VPN interfaces often have rather strange quirks, like missing link-local addressess, not working multicast, or completely broken routing in OpenVPN. OTOH, i use BIRD OSPF on PtP GRE tunnels without any problems or tweaks (in PtP mode). > Based on one of your links it is also suggested that MTU could be the issue. > I checked but all my MTUs are consistent (1420 for the wireguard tunnel and > 1476 for the GRE tunnel). I still tried "tx length 1300". No change. This should not be necessary, BIRD learns tx length from iface MTU. > > WireGuard tunnels are default ptp between the server and clients (if > > multiple client-peers are configured on the same tunnel interface on > > the server). > > > > Or "just" ptp if only one peer is configured for a single wg tunnel on > > each side. > > This is the case but as above, this is just not working. > And on eiher side of tcpdump are still multicast packets visible (224.0.0.5) > > What are the exact conditions that the other station shows up as OSPF > neighbor. I confirmed already with tcpdump that the OSPF Hello packages > appear on the interface and both look *identical* (in terms of Hello Timer, > Dead Timer, Mask, Priority). > What could possible happen that bird would not add such packets to the > neighbor list? It is possible that BIRD just ignores the packet as it does not match its src/dst address. You could enable 'debug all' to see if there are Hello packets logged by BIRD. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: Bird just doesn't want to find OSPF neighbors although they are there and can communicate
Hi Chriztoffer,
> Gesendet: Montag, 18. Oktober 2021 um 00:47 Uhr
> Von: "Chriztoffer Hansen"
> An: "Lukas Haase"
> Cc: "BIRD Users List (bird-users@network.cz)"
> Betreff: Re: Bird just doesn't want to find OSPF neighbors although they are
> there and can communicate
>
> On Mon, 18 Oct 2021 at 02:01, Lukas Haase wrote:
> > I am having big trouble getting Bird/OSPF working. I broke it down to a
> > simple setup:
> > Point-to-point wireguard link between Node1 (192.168.56.224/31) and Node2
> > (192.168.56.225/31) using nbma.
> > There were nothing but troubles with multicast and to avoid all these
> > hassles for now, I directly switched to nbma.
> >
> > Config Station 1:
> >
> > protocol ospf test {
> > area 0.0.0.0 {
> > interface "wg-tun" {
> > cost 10;
> > type nbma;
> > authentication cryptographic;
> > password "VWj3QH8LAtWIzQca";
> > neighbors {
> > 192.168.56.225;
> > };
> > };
> > };
> > }
> >
> >
> > Config Station 2:
> >
> > protocol ospf test {
> > area 0.0.0.0 {
> > interface "wg-tun" {
> > type nbma;
> > cost 10;
> > authentication cryptographic;
> > password "VWj3QH8LAtWIzQca";
> > neighbors {
> > 192.168.56.224;
> > };
> > };
> > };
> > }
>
> https://duckduckgo.com/?q=ospf+over+wireguard=brave=web
> https://idndx.com/ospf-over-wireguard/
> https://docs.nycmesh.net/networking/vpnwireguardospf/
I have googled like crazy but haven't found both pages yet.
Maybe I should use DuckDuckGo finally.
While those didn't fix the problem yet they are helpful. Thanks!
> Have you tried setting the type to 'ptmp' or 'ptp' instead of 'nbma'?
Yes, I tried ptp.
To my understanding, bird should stop sending multicast packets.
Instead, it continued to send packets to 224.0.0.5.
Why is that? Doesn't make sense to me at all.
For this reason I went for nbma.
Now I have tried ptmp and magically the two see each other now. Does make ZERO
sense to me.
Why would ptmp work and nbma not?
I literally just replaced "nbma" with "ptmp" (kept "neighbors" the same, for
example).
There is also another problem: One of my clients is a Mikrotik router.
This thing supports "broadcast, "ptp", "ptmp" and "nmba". However, I can
weirdly only configure "NBMA Neighbors".
I have tried this link with ipip, GRE, all types of connections but still no
luck yet.
Seriously, the last time setting something up was that much of a hassle was
sendmail 25 years ago :-(
Based on one of your links it is also suggested that MTU could be the issue. I
checked but all my MTUs are consistent (1420 for the wireguard tunnel and 1476
for the GRE tunnel). I still tried "tx length 1300". No change.
> WireGuard tunnels are default ptp between the server and clients (if
> multiple client-peers are configured on the same tunnel interface on
> the server).
>
> Or "just" ptp if only one peer is configured for a single wg tunnel on
> each side.
This is the case but as above, this is just not working.
And on eiher side of tcpdump are still multicast packets visible (224.0.0.5)
What are the exact conditions that the other station shows up as OSPF neighbor.
I confirmed already with tcpdump that the OSPF Hello packages appear on the
interface and both look *identical* (in terms of Hello Timer, Dead Timer, Mask,
Priority).
What could possible happen that bird would not add such packets to the neighbor
list?
Thanks,
Lukas
Re: Bird just doesn't want to find OSPF neighbors although they are there and can communicate
Hi Ondrej, > On Mon, Oct 18, 2021 at 02:01:07AM +0200, Lukas Haase wrote: > > Hi, > > > > I am having big trouble getting Bird/OSPF working. I broke it down to a > > simple setup: > > Point-to-point wireguard link between Node1 (192.168.56.224/31) and Node2 > > (192.168.56.225/31) using nbma. > > There were nothing but troubles with multicast and to avoid all these > > hassles for now, I directly switched to nbma. > > Hi > > What do you get from 'birdc show ospf interface'? Node 1: # birdc show ospf interface BIRD 1.6.8 ready. test: Interface wg-tun (192.168.56.224/31) Type: nbma Area: 0.0.0.0 (0) State: DR Priority: 1 Cost: 10 Hello timer: 10 Poll timer: 20 Wait timer: 5 Dead timer: 40 Retransmit timer: 2 Designated router (ID): 192.168.56.193 Designated router (IP): 192.168.56.224 Backup designated router (ID): 0.0.0.0 Backup designated router (IP): 0.0.0.0 Node 2: # birdc show ospf interface BIRD 1.6.8 ready. test: Interface wg-tun (192.168.56.224/31) Type: nbma Area: 0.0.0.0 (0) State: DR Priority: 1 Cost: 10 Hello timer: 10 Poll timer: 20 Wait timer: 5 Dead timer: 40 Retransmit timer: 2 Designated router (ID): 192.168.56.194 Designated router (IP): 192.168.56.225 Backup designated router (ID): 0.0.0.0 Backup designated router (IP): 0.0.0.0 Thanks, Lukas
Re: Bird just doesn't want to find OSPF neighbors although they are there and can communicate
On Mon, Oct 18, 2021 at 02:01:07AM +0200, Lukas Haase wrote: > Hi, > > I am having big trouble getting Bird/OSPF working. I broke it down to a > simple setup: > Point-to-point wireguard link between Node1 (192.168.56.224/31) and Node2 > (192.168.56.225/31) using nbma. > There were nothing but troubles with multicast and to avoid all these hassles > for now, I directly switched to nbma. Hi What do you get from 'birdc show ospf interface'? -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: Bird just doesn't want to find OSPF neighbors although they are there and can communicate
On Mon, 18 Oct 2021 at 02:01, Lukas Haase wrote:
> I am having big trouble getting Bird/OSPF working. I broke it down to a
> simple setup:
> Point-to-point wireguard link between Node1 (192.168.56.224/31) and Node2
> (192.168.56.225/31) using nbma.
> There were nothing but troubles with multicast and to avoid all these hassles
> for now, I directly switched to nbma.
>
> Config Station 1:
>
> protocol ospf test {
> area 0.0.0.0 {
> interface "wg-tun" {
> cost 10;
> type nbma;
> authentication cryptographic;
> password "VWj3QH8LAtWIzQca";
> neighbors {
> 192.168.56.225;
> };
> };
> };
> }
>
>
> Config Station 2:
>
> protocol ospf test {
> area 0.0.0.0 {
> interface "wg-tun" {
> type nbma;
> cost 10;
> authentication cryptographic;
> password "VWj3QH8LAtWIzQca";
> neighbors {
> 192.168.56.224;
> };
> };
> };
> }
https://duckduckgo.com/?q=ospf+over+wireguard=brave=web
https://idndx.com/ospf-over-wireguard/
https://docs.nycmesh.net/networking/vpnwireguardospf/
Have you tried setting the type to 'ptmp' or 'ptp' instead of 'nbma'?
WireGuard tunnels are default ptp between the server and clients (if
multiple client-peers are configured on the same tunnel interface on
the server).
Or "just" ptp if only one peer is configured for a single wg tunnel on
each side.
type broadcast|bcast --> BIRD detects a type of a connected network
automatically, but sometimes it's convenient to force use of a
different type manually. On broadcast networks (like ethernet),
flooding and Hello messages are sent using multicasts (a single packet
for all the neighbors). A designated router is elected and it is
responsible for synchronizing the link-state databases and originating
network LSAs. This network type cannot be used on physically NBMA
networks and on unnumbered networks (networks without proper IP
prefix).
type pointopoint|ptp --> Point-to-point networks connect just 2
routers together. No election is performed and no network LSA is
originated, which makes it simpler and faster to establish. This
network type is useful not only for physically PtP ifaces (like PPP or
tunnels), but also for broadcast networks used as PtP links. This
network type cannot be used on physically NBMA networks.
type nonbroadcast|nbma --> On NBMA networks, the packets are sent to
each neighbor separately because of lack of multicast capabilities.
Like on broadcast networks, a designated router is elected, which
plays a central role in propagation of LSAs. This network type cannot
be used on unnumbered networks.
type pointomultipoint|ptmp --> This is another network type designed
to handle NBMA networks. In this case the NBMA network is treated as a
collection of PtP links. This is useful if not every pair of routers
on the NBMA network has direct communication, or if the NBMA network
is used as an (possibly unnumbered) PtP link.
https://bird.network.cz/?get_doc=20=bird-6.html
Re: Bird just doesn't want to find OSPF neighbors although they are there and can communicate
Hi Lukas, Am 18.10.21 um 02:01 schrieb Lukas Haase: I am having big trouble getting Bird/OSPF working. I broke it down to a simple setup: Point-to-point wireguard link What do you want to achieve? AFAIK the wireguard VPN does its own routing and will only send to IPs that are in its configuration. I have not figured out yet how to utilize a routing protocol (OSPF or BGP) on a wireguard link. Regards -- Robert Sander Heinlein Consulting GmbH Schwedter Str. 8/9b, 10119 Berlin http://www.heinlein-support.de Tel: 030 / 405051-43 Fax: 030 / 405051-19 Zwangsangaben lt. §35a GmbHG: HRB 220009 B / Amtsgericht Berlin-Charlottenburg, Geschäftsführer: Peer Heinlein -- Sitz: Berlin
Bird just doesn't want to find OSPF neighbors although they are there and can communicate
Hi,
I am having big trouble getting Bird/OSPF working. I broke it down to a simple
setup:
Point-to-point wireguard link between Node1 (192.168.56.224/31) and Node2
(192.168.56.225/31) using nbma.
There were nothing but troubles with multicast and to avoid all these hassles
for now, I directly switched to nbma.
Config Station 1:
protocol ospf test {
area 0.0.0.0 {
interface "wg-tun" {
cost 10;
type nbma;
authentication cryptographic;
password "VWj3QH8LAtWIzQca";
neighbors {
192.168.56.225;
};
};
};
}
Config Station 2:
protocol ospf test {
area 0.0.0.0 {
interface "wg-tun" {
type nbma;
cost 10;
authentication cryptographic;
password "VWj3QH8LAtWIzQca";
neighbors {
192.168.56.224;
};
};
};
}
- Ping from both sides to the other works.
Yet the neighbor table just stay empty:
node1:~# birdc show ospf neighbors
BIRD 1.6.8 ready.
test:
Router ID Pri State DTime Interface Router IP
node1:~#
node2~:# birdc show ospf neighbors
BIRD 1.6.8 ready.
test:
Router ID Pri State DTime Interface Router IP
node2:~#
Both OSPF Hello are received via tcpdump (see below).
What else can be missed?
Thanks,
Lukas
node1:~# tcpdump -n -vvv -i wg-tun 'proto ospf'
tcpdump: listening on wg-tun, link-type RAW (Raw IP), capture size 262144 bytes
23:41:09.515892 IP (tos 0xc0, ttl 1, id 65434, offset 0, flags [none], proto
OSPF (89), length 80)
192.168.56.224 > 192.168.56.225: OSPFv2, Hello, length 44
Router-ID 192.168.56.193, Backbone Area, Authentication Type: MD5 (2)
Key-ID: 1, Auth-Length: 16, Crypto Sequence Number: 0x00012747
Options [External]
Hello Timer 10s, Dead Timer 40s, Mask 255.255.255.254, Priority 1
Designated Router 192.168.56.224
23:41:19.589835 IP (tos 0xc0, ttl 1, id 10125, offset 0, flags [none], proto
OSPF (89), length 80)
192.168.56.225 > 192.168.56.224: OSPFv2, Hello, length 44
Router-ID 192.168.56.194, Backbone Area, Authentication Type: MD5 (2)
Key-ID: 1, Auth-Length: 16, Crypto Sequence Number: 0x00209357
Options [External]
Hello Timer 10s, Dead Timer 40s, Mask 255.255.255.254, Priority 1
Designated Router 192.168.56.225
node2:~# tcpdump -n -vvv -i wg-tun 'proto ospf'
tcpdump: listening on wg-tun, link-type RAW (Raw IP), snapshot length 262144
bytes
23:41:29.723176 IP (tos 0xc0, ttl 1, id 2705, offset 0, flags [none], proto
OSPF (89), length 80)
192.168.56.224 > 192.168.56.225: OSPFv2, Hello, length 44
Router-ID 192.168.56.193, Backbone Area, Authentication Type: MD5 (2)
Key-ID: 1, Auth-Length: 16, Crypto Sequence Number: 0x00012748
Options [External]
Hello Timer 10s, Dead Timer 40s, Mask 255.255.255.254, Priority 1
Designated Router 192.168.56.224
23:41:39.732903 IP (tos 0xc0, ttl 1, id 12839, offset 0, flags [none], proto
OSPF (89), length 80)
192.168.56.225 > 192.168.56.224: OSPFv2, Hello, length 44
Router-ID 192.168.56.194, Backbone Area, Authentication Type: MD5 (2)
Key-ID: 1, Auth-Length: 16, Crypto Sequence Number: 0x00209358
Options [External]
Hello Timer 10s, Dead Timer 40s, Mask 255.255.255.254, Priority 1
Designated Router 192.168.56.225
