0

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?

divB
  • 538
  • 1
  • 6
  • 22
  • 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. – Peter Zhabin Oct 17 '21 at 10:07
  • Have you got firewall on any of the nodes? If yes and the default policy is drop - have you allowed OSPF protocol? – Tomek Oct 17 '21 at 12:17
  • @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. – divB Oct 17 '21 at 22:56
  • @Tomek yes and temporarily disabled. – divB Oct 17 '21 at 22:56

1 Answers1

0

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.

Sakamoto Poteko
  • 1
  • 1
  • 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. – Ron Maupin Apr 08 '22 at 14:04
  • Yep that's true. OP is running on ptp I believe that requires mcast. – Sakamoto Poteko Apr 08 '22 at 16:13
  • 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. – Ron Maupin Apr 08 '22 at 16:25
  • 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. – Sakamoto Poteko Apr 21 '22 at 11:11