Score:0

How to configure bird OSPF for ipip link?

us flag

I have a simple ipip tunnel between 192.168.56.254/31 and 192.168.56.255/31.

My simple test config on 192.168.56.254/31 looks like:

protocol ospf test
{
        import none;
        export none;

        area 0.0.0.0 {
                interface "ipip-tun" {
                        cost 5;
                        type ptp;
                        authentication none;
                        neighbors {
                                192.168.56.255;
                        };
                };
        };
}

192.168.56.255/31 is a Mikrotik router. Both instances can't see themselves.

In tcpdump on 192.168.56.254/31, I see:

08:26:11.634115 IP 192.168.56.254 > 224.0.0.5: OSPFv2, Hello, length 44
08:26:11.990261 IP 192.168.56.255 > 224.0.0.5: OSPFv2, Hello, length 44

In the packet sniffer on the Mikrotik device I can see the transmitted packages (also to the multicast address) but no received one.

It confuses me that even the ptp mode uses multicast. Is this normal? If yes, are any configurations for the ipip tunnel required to make multicast work?

Peter Zhabin avatar
cn flag
Your dump suggests that at least on the BIRD side of the tunnel OSPF Hellos are received appropriately. Do a `tcpdump -vvv` on BIRD side to see Hello parameters and pay attention to OSPF process ID, hello and dead timers - these should match on both ends, otherwise OSPF behaves exactly as you see it.
fr flag
Have you got firewall on any of the nodes? If yes and the default policy is drop - have you allowed OSPF protocol?
us flag
@PeterZhabin With tcpdump both messages are **identical** on bird side. I switched to "nbma" to avoid multicast issues. Firewall turned off. On the mikrotik side I can now see the Bird as neighbor. But the neighbor list on the bird side is still empty. Drives me nuts. I meanwhile also configured another bird instance over wireguard p2p link. Same story: No firewall, tcpdump on each side sees identical hello messages. Yet both sides show empty neighbors.
us flag
@Tomek yes and temporarily disabled.
Score:0
io flag

IPIP tunnel supports unicast only while OSPF ptp runs on mcast, that's why you're not getting the packet on the other side. If you need multicast, use GRE tunnel.

Ron Maupin avatar
us flag
OSPF can be configured to use unicast. It only uses multicast on broadcast links, but it can use unicast on NBMA links, and it can even be configured to use unicast on broadcast links.
io flag
Yep that's true. OP is running on ptp I believe that requires mcast.
Ron Maupin avatar
us flag
No, multicast is only used on broadcast links, e.g. ethernet. The OP simply needs to define the neighbors, and that will use unicast. Multicast is for a network where there may be multiple neighbors and it elects DR/BDR. The neighbors then use two multicast groups: one to send to the DR/BDR. and one used by the DR/BDR to send to all the neighbors. It makes no sense to use multicast on a point-to-point link, so you define the neighbor and it uses unicast.
io flag
Ehh, I think in BIRD he should specify as ptmp instead of ptp. Looks like BIRD is only sending mcast traffic if it's ptp, while unicast traffic is sent with ptmp.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.