Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    FRR 0.6.7_6 sending OSPFv3 packets with incorrect OSPF checksum

    Scheduled Pinned Locked Moved FRR
    9 Posts 2 Posters 1.0k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • T
      techstone
      last edited by

      Hi,

      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?

      Thanks,
      -Martin

      1 Reply Last reply Reply Quote 0
      • viktor_gV
        viktor_g Netgate
        last edited by

        Try to disable hw checksum offload on the System / Advanced / Networking page:
        Screenshot from 2020-10-02 08-54-10.png

        1 Reply Last reply Reply Quote 0
        • T
          techstone
          last edited by

          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:

          993c2ab7-528f-4fcf-8af9-51bc94831786-image.png

          Side note: using ss -nm on the Linux FRR box I have confirmed that upon reception, the Linux kernel drops these Hellos with the incorrect checksum.

          1 Reply Last reply Reply Quote 0
          • viktor_gV
            viktor_g Netgate
            last edited by

            What type of hypervisor you are using? VmWare, Hyper-V or KVM?
            What network interface?

            1 Reply Last reply Reply Quote 0
            • T
              techstone
              last edited by

              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.

              1 Reply Last reply Reply Quote 0
              • T
                techstone
                last edited by techstone

                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.

                1 Reply Last reply Reply Quote 0
                • T
                  techstone
                  last edited by

                  I think I may narrowed it down (observations on the VM).

                  On a given OSPFv3 interface, if there is no static IPv6 address configured:
                  4db41e21-a393-4d54-b91c-06b2e782fc78-image.png
                  the link-local address is used as source and the checksum is OK.

                  However, if a static IPv6 address is configured:
                  9b7d768d-304f-4908-93c7-7262aed8d701-image.png 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...

                  1 Reply Last reply Reply Quote 0
                  • viktor_gV
                    viktor_g Netgate
                    last edited by

                    Please check this with the VirtIO network driver and the latest version of VirtualBox (6.1.14)

                    1 Reply Last reply Reply Quote 0
                    • T
                      techstone
                      last edited by

                      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.

                      1 Reply Last reply Reply Quote 0
                      • First post
                        Last post
                      Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.