Project

General

Profile

Actions

Bug #9204

closed

ospfd: GRE tunnels became unnumbered since 2.4.4

Added by Firstname Surname about 3 years ago. Updated 11 months ago.

Status:
Needs Patch
Priority:
Normal
Assignee:
-
Category:
FRR
Target version:
-
Start date:
12/16/2018
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Affected Version:
2.4.4_1
Affected Plus Version:
Affected Architecture:
All

Description

I have recently tested an upgrade to 2.4.4_1, from 2.4.3. It is a hub and spoke type setup with GRE over IPSec, ipv4 + ipv6, ospf/ospf3 + BGP route reflectors, peering over loopbacks. Hubs are pfsense, spokes are Cisco or Juniper.

I want to upgrade mainly because of VTI support.

Upgrade was largely painless, bar one issue: all of my IPv4 GRE tunnels now show as unnumbered interfaces in ospfd (so use ifindex link IDs) and there seems to be no way around it. This of course broke all of IPv4 routing, because on the spokes the tunnels are still standard addressed p2p links. Result: adjacencies are formed, but spokes accept no routes from the hub.

I will provide more details in due course and report if this can be tracked down to a specific FRR change. I am also going to give VTIs a try but chances are that it will be the same case with those.

Workaround I am going to try is converting all tunnels on spokes to unnumbered, moving the IPs from tunnels to dummy loopbacks.

In any case, this is a bit of a showstopper for anyone running OSPF over GRE.

Note that there is no issue with ospf3d, or doesn't seem to be.

Actions #1

Updated by Firstname Surname almost 3 years ago

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.

Actions #2

Updated by Jim Pingle over 2 years ago

  • Category set to FRR
  • Status changed from New to Feedback
  • Priority changed from High to Normal

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.

Actions #3

Updated by Firstname Surname over 2 years ago

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.

Actions #4

Updated by Viktor Gurov about 2 years ago

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

Actions #5

Updated by Jim Pingle about 2 years ago

  • Status changed from Feedback to Needs Patch

Looks like it's already been raised upstream with FRR, and the issue is still open: https://github.com/FRRouting/frr/issues/3973

Nothing we can do here but wait until FRR patches their bug.

Actions #6

Updated by Firstname Surname 11 months ago

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.

Actions #7

Updated by Jim Pingle 11 months ago

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

Actions #8

Updated by Firstname Surname 11 months ago

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
Actions #9

Updated by Firstname Surname 11 months ago

...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.

Actions

Also available in: Atom PDF