FRR 0.6.7_6 sending OSPFv3 packets with incorrect OSPF checksum
I'm doing some testing and I am trying to setup OSPFv3 adjacencies between four VMs:
- Linux (CentOS 8.2) with FRR 7.4
- OpenBSD 6.7 with ospf6d
- FreeBSD 12.1 with frr7-7.3.1
- pfSense (2.4.5-RELEASE-p1) with package frr 0.6.7_6
The adjacencies come up just fine between Linux, OpenBSD and FreeBSD, but not on the pfSense. In the neighbor list, pfSense shows all three neighbors in INIT state. On the three other VMs the neighbor list shows all three, but not the pfSense.
Running tcpdump on the Linux box shows that it receives OSPFv3 Hellos from all other VMs (including the pfSense) as well as sends its own OSPF Hellos. But somehow the Linux, OpenBSD and FreeBSD VMs all seem to be ignoring the Hellos from the pfSense.
I compared all four Hellos in Wireshark and the only differences I have found are that:
- the pfSense uses its configured IPv6 address as the source while the other three use their link-local addresses
- Wireshark reports the checksum on the OSPF packet coming from the pfSense as "incorrect" (all other three are "good")
Will a bad checksum make the other VMs ignore the OSPFv3 Hellos? If so, what could account for the incorrect checksum? A misconfiguration on my part? Something I missed?
Try to disable hw checksum offload on the System / Advanced / Networking page:
I tried you suggestion @viktor_g and rebooted the pfSense VM, but unfortunately the checksum error is still present in sent OSPFv3 Hellos from the pfSense:
Side note: using
ss -nmon the Linux FRR box I have confirmed that upon reception, the Linux kernel drops these Hellos with the incorrect checksum.
What type of hypervisor you are using? VmWare, Hyper-V or KVM?
What network interface?
Since this is just for testing a network design, I am running the VM on VirtualBox 6.1 on my ArchLinux home computer. The virtual NIC is an Intel PRO/1000 MT Desktop (82540EM). All other VMs are running on the same VirtualBox with the same adapter type.
We have two Netgate XG-1541s in production. Although there are not connected to any OSPF peers, I nonetheless installed the FRR package on one of them and configured OSPFv3 on one of the interfaces and then captured the Hellos.
Lo and behold, these ones do not show any OSPF checksum error. Another difference in the trace is that the link-local IPv6 address is used for the source of these Hellos, compared to the configured interface IPv6 address in the case of the pfSense instance on a VM. I don't know if there is a correlation between these two things are it's just a coincidence. I will compare the configurations between the physical box and the VM more closely to see if I spot any difference that could account for these differences.
I think I may narrowed it down (observations on the VM).
On a given OSPFv3 interface, if there is no static IPv6 address configured:
the link-local address is used as source and the checksum is OK.
However, if a static IPv6 address is configured:
that static address is used as the sourceand the checksum is considered incorrect.
Perhaps OSPF6D calculates the checksum with the link-local value in all situations, but if the OS then sends it out with the configured static address the checksum is no longer valid? Does that make sense (assuming that the source and destination IP addresses are taken into account when calculating the OSPF checksum)?
On my FreeBSD VM I also configured a static IPv6 address, but FRR uses the link-local address nonetheless. I'm not sure what can account for this behavioral difference between pfSense and stock FreeBSD...
Please check this with the VirtIO network driver and the latest version of VirtualBox (6.1.14)
On VirtualBox 6.1.14, with the exact same pfSenseVM, but one of the interfaces changed from 82540EM to virtio, I still see the configured IPv6 address used as the source OSPF6 address, so changed the vNIC type didn't change the behavior.
However, the funny thing is that I then added two new vNICs to the VM (one 82540EM and one virtio) and then configured an IPv6 address and OSPF6 on both. Lo and behold, both new interfaces send out OSPF6 Hellos with the link-local address!
I compared the interface and frrospf6dinterfaces>config sections for those interfaces and they're the same as the interface that use the configured IPv6 address. I really can't explain the behavior in difference that I'm observing.