Project

General

Profile

Bug #9204

ospfd: GRE tunnels became unnumbered since 2.4.4

Added by Firstname Surname 12 months ago. Updated 4 months ago.

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

0%

Estimated time:
Affected Version:
2.4.4_1
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.

History

#1 Updated by Firstname Surname 9 months 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.

#2 Updated by Jim Pingle 4 months 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.

#3 Updated by Firstname Surname 4 months 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.

Also available in: Atom PDF