Bird just doesn't want to find OSPF neighbors although they are there and can communicate

[Ondrej Zajicek]

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 its neighbor entry is configured to be non-eligible. See the
example in OSPF config:

    neighbors {
        192.168.120.1 eligible;
        192.168.120.2;
        192.168.120.10;
    };

You should have this in your config:

    neighbors {
        192.168.56.228 eligible;
    };


Well, it is not particularly well documented and defaults for priority
and for neighbor eligibility are conflicting. But NBMA networks are
supposed to have just small number of eligible nodes, that is why
non-eligible neighbors are the default, while eligible are marked
with flag.

This is relevant only for NBMA, so that is why PtMP worked for you.

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