FRR 0.6.3 OSPF seems to break with IP aliases



  • I noticed my OSPF adjacency (that was working perfectly fine before) mysteriously stopped working between my pfSense box and my USG after a new boot drive install, and also a package update to FRR. Looking at the post about FRR OSPF changes about the network command being deprecated yielded no real results, so figured I'd post to see if anyone else was running into the same issue and see if there are any real workarounds.

    I spun up 2 identical pfSense VMs with only FRR and an open interface between the two. OSPF works perfectly fine if there are only 2 IP addresses involved (10.0.0.1/30 and 10.0.0.2/30 for example). If a virtual IP is assigned to at least one interface that OSPF is forming over (re: network command deprecated, you have to use interfaces now), then it gets stuck in an INIT/DROTHER state until the virtual IP is removed and the ospf process restarted. The logs also get spammed with "interface ospf_read network address is not the same", and duplicate hellos are being sent (one from the VIP, one from the actual interface IP) when looking at a packet capture. Looking at the routes show that the virtual IP gets picked up.

    This is a problem when using pfBlocker since it binds to LAN by default, and is recommended to be kept there (which is my case since the USG is downstream of the pfSense box). Moving the listening port to localhost and restarting ospfd seems to fix the issue since the VIP isn't on an OSPF interface anymore.

    Falling back to Quagga resolved the issue instantly since the network command lets me only include the LAN interface IP I'm interested in. Has anyone else ran into this issue or found a solution that isn't removing VIPs?

    pfSense log spam that appears:
    Aug 2 21:22:07 ospfd 81843 interface bce1:10.10.10.1: ospf_read network address is not same [10.0.0.2]

    Where 10.10.10.1 is the pfBlocker VIP and my actual LAN IP is 10.0.0.2.


  • Rebel Alliance Developer Netgate

    IMO, the pfBlocker VIP should be on localhost, not LAN. The traffic still arrives at the firewall that way, and it will answer it fine from any interface. I'm not sure why they'd recommend keeping it there vs localhost.

    You really shouldn't have multiple subnets on a single interface if you can avoid it.

    While the old network statements may have masked the issue, it's ultimately a design problem with the setup that should be corrected.


  • Galactic Empire

    @jimp said in FRR 0.6.3 OSPF seems to break with IP aliases:

    IMO, the pfBlocker VIP should be on localhost, not LAN. The traffic still arrives at the firewall that way, and it will answer it fine from any interface. I'm not sure why they'd recommend keeping it there vs localhost.

    I did wonder that myself Jim a while back, Localhost isn't a valid option under the DNSBL Webserver Configuration.

    Maybe @BBcan177 knows why.



  • @jimp said in FRR 0.6.3 OSPF seems to break with IP aliases:

    IMO, the pfBlocker VIP should be on localhost, not LAN. The traffic still arrives at the firewall that way, and it will answer it fine from any interface. I'm not sure why they'd recommend keeping it there vs localhost.

    You really shouldn't have multiple subnets on a single interface if you can avoid it.

    While the old network statements may have masked the issue, it's ultimately a design problem with the setup that should be corrected.

    While I agree that it's odd, the issue still exists that a VIP on an OSPF interface will break it. Any workarounds other than to just not use a VIP on an OSPF interface (not an adequate solution IMO, others may disagree), or is it a legitimate issue? Secondary IP addresses exist on standard networking hardware and still work fine with OSPF as far as I'm aware, though normal subinterfaces are generally not the interface itself, but int.#.


  • Rebel Alliance Developer Netgate

    FreeBSD doesn't have a concept of "subinterfaces" in that way. There are VLANs, naturally, but that's a different concept.

    There may be a general issue with FRR and additional interface addresses using a /32 mask, as it fails with the same error message even with a VIP in the same subnet as the interface address with a /32 mask. The network statement wouldn't help with that scenario.

    If there is a VIP in the same subnet as the interface with the same mask as the interface address, it works fine. If there is a VIP in a different subnet with a normal (non-32) mask, it works fine.

    I'd open a bug report upstream with FRR directly and see what they have to say about it, but again, moving the /32 VIP to localhost should be fine in theory. Or changing the VIP mask to something that is an actual subnet, not a single address.



  • @jimp said in FRR 0.6.3 OSPF seems to break with IP aliases:

    FreeBSD doesn't have a concept of "subinterfaces" in that way. There are VLANs, naturally, but that's a different concept.

    There may be a general issue with FRR and additional interface addresses using a /32 mask, as it fails with the same error message even with a VIP in the same subnet as the interface address with a /32 mask. The network statement wouldn't help with that scenario.

    If there is a VIP in the same subnet as the interface with the same mask as the interface address, it works fine. If there is a VIP in a different subnet with a normal (non-32) mask, it works fine.

    I'd open a bug report upstream with FRR directly and see what they have to say about it, but again, moving the /32 VIP to localhost should be fine in theory. Or changing the VIP mask to something that is an actual subnet, not a single address.

    Makes sense that FreeBSD works that way. I may have to open a bug report with FRR since this definitely does not work with pfBlocker natively if you only have a WAN and a LAN interface since localhost cannot even be set as the listening port in DNSBL (or WAN for that matter; I only have my VPN interface and LAN available). Trying to add a CIDR prefix ends up in the VIP address looking like "10.10.10.1/24/32", so it's hardcoded to be a /32 it seems.

    You can manually change what the VIP binds to in the VIP settings, but it automatically changes back to what's set in DNSBL any time a sync is performed.

    @BBcan177 any ideas on this one? What's your POV as the pfBlocker dev?


Log in to reply