pfSense » pfSense Packages

I think the root of the problem is frr incorrectly detecting that GRE tunnels have /32 netmasks - this makes them unnumbered.

: ifconfig gre1 | grep netmask
    inet x.x.x.1 --> x.x.x.2 netmask 0xfffffffc 

: vtysh -c "show int gre1" | grep peer
  inet x.x.x.1/32 peer x.x.x.2/30 unnumbered

Instead of picking up the peer mask, frr uses the local address to classify the mask of the interface.

I doubt this is fixed since the offending code (frr/zebra/connected.c) has not been touched, but I'll give this a try when I get a chance.

Jim Pingle wrote:

Can you test this with the current version of FRR (preferably on 2.5.0, if 2.4.4 doesn't work)?

FRR OSPF underwent a major overhaul since this was reported, and the underlying FRR was upgraded multiple times.

same issue on pfSense 2.5.0.a.20191230.2321 with FRR 0.6.3_1

FRR have been silent, but it looks like the person who raised this has a patch. What's your policy here, do you apply patches or use released code as a rule? Having this fixed would be awesome - in my case I can't even move to VTI, which is something I wanted to do for years now - because on the platform I have on the other end of the VTI, unnumbered VTIs don't work. As is, this issue cripples the use of GRE and VTI on pfSense with ospfd. Really makes me wonder how many people do routing over tunnels... to add insult to injury, frr's ospf3d is restricted to inet6, although ospf3 can happily carry both AFs.

Typically we would wait until it's in an official release.

OK - I just tested that fix.

root@fb122-frrtest:~ # ifconfig gre0
gre0: flags=8011<UP,POINTOPOINT,MULTICAST> metric 0 mtu 1476
    options=80000<LINKSTATE>
    tunnel inet 1.2.3.4 --> 5.6.7.8
    inet 10.1.1.1 --> 10.1.1.2 netmask 0xfffffffc
    groups: gre
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

Vanilla FRR 7.5:

root@fb122-frrtest:~ # vtysh -c "show int gre0" 
% Can't open configuration file /usr/local/etc/vtysh.conf due to 'No such file or directory'.
Interface gre0 is up, line protocol is up
  Link ups:       1    last: 2021/02/22 21:49:38.01
  Link downs:     0    last: (never)
  vrf: default
  index 3 metric 1 mtu 1476 speed 0 
  flags: <UP,POINTOPOINT,RUNNING,MULTICAST>
  Type: Unknown
  inet 10.1.1.1/32 peer 10.1.1.2/30 unnumbered
  Interface Type Other
  Interface Slave Type None
    input packets 0, bytes 0, dropped 0, multicast packets 0
    input errors 0
    output packets 0, bytes 0, multicast packets 0
    output errors 0
    collisions 0

After the change:

root@fb122-frrtest:~ # vtysh -c "show int gre0" 
% Can't open configuration file /usr/local/etc/vtysh.conf due to 'No such file or directory'.
Interface gre0 is up, line protocol is up
  Link ups:       1    last: 2021/02/22 21:53:38.80
  Link downs:     0    last: (never)
  vrf: default
  index 3 metric 1 mtu 1476 speed 0 
  flags: <UP,POINTOPOINT,RUNNING,MULTICAST>
  Type: Unknown
  inet 10.1.1.1/32 peer 10.1.1.2/30
  Interface Type Other
  Interface Slave Type None
    input packets 0, bytes 0, dropped 0, multicast packets 0
    input errors 0
    output packets 0, bytes 0, multicast packets 0
    output errors 0
    collisions 0

...I mean, this is not a proper test, I need to bring up a live tunnel and get some LSAs going first.

But when this is fixed and released, this will be the first time for about ten years that I will be able to upgrade pfSense without manual patching or workarounds... well, and upgrading some packages with every major FreeBSD bump.

Here we are 5 years later. Still not fixed.

But the code has been updated a bit. pfSense+ 24.03 still contains the same bug, though - and OSPF is unusable with GRE tunnels.

The following patch appears to fix zebra in frr 9.1, the code base used in 24.03. The affected file remains connected.c:

62,66c62,73
< if (ifc->address->prefixlen IPV4_MAX_BITLEN)
< SET_FLAG(ifc->flags, ZEBRA_IFA_UNNUMBERED);
< else
< UNSET_FLAG(ifc->flags, ZEBRA_IFA_UNNUMBERED);
< }
---

if (CONNECTED_PEER(ifc)) {
if (ifc->destination->prefixlen IPV4_MAX_BITLEN)
SET_FLAG(ifc->flags, ZEBRA_IFA_UNNUMBERED);
else
UNSET_FLAG(ifc->flags, ZEBRA_IFA_UNNUMBERED);
} else {
if (ifc->address->prefixlen == IPV4_MAX_BITLEN)
SET_FLAG(ifc->flags, ZEBRA_IFA_UNNUMBERED);
else
UNSET_FLAG(ifc->flags, ZEBRA_IFA_UNNUMBERED);
}
}

It appears from the upstream discussion that this patch can cause other issues, so applying it is likely to break existing setups. This is the reason it hasn't been merged into an official release.