OSPF type broadcast over GRE for NRHP
I am trying to use BIRD to run OSPF inside a Phase 3 DMVPN using OpenNHRP. The problem I'm seeing is that it appears to be impossible to force type broadcast on a GRE interface. When I try, the message "Cannot use interface gre1 as broadcast, forcing nbma" is logged. This may normally make sense, but the OpenNHRP daemon captures multicast traffic on it's interface and forwards it appropriately. A configuration parameter to bypass this protection and allow broadcast on a GRE interface would be very helpful.
I've had this issue myself when i was investigating DMVPN using OpenNHRP. It's a simple patch to remove the check / enforcement needed in bird, can't remember where now though since it was a while ago. When the check was removed i could set the interface to any type i wanted and i got ospf routing to work. No drawbacks detected during the testing. 2015-03-02 21:49 skrev Clint Armstrong:
I am trying to use BIRD to run OSPF inside a Phase 3 DMVPN using OpenNHRP. The problem I'm seeing is that it appears to be impossible to force type broadcast on a GRE interface. When I try, the message "Cannot use interface gre1 as broadcast, forcing nbma" is logged.
This may normally make sense, but the OpenNHRP daemon captures multicast traffic on it's interface and forwards it appropriately.
A configuration parameter to bypass this protection and allow broadcast on a GRE interface would be very helpful.
On Mon, Mar 02, 2015 at 03:49:48PM -0500, Clint Armstrong wrote:
I am trying to use BIRD to run OSPF inside a Phase 3 DMVPN using OpenNHRP. The problem I'm seeing is that it appears to be impossible to force type broadcast on a GRE interface. When I try, the message "Cannot use interface gre1 as broadcast, forcing nbma" is logged.
This may normally make sense, but the OpenNHRP daemon captures multicast traffic on it's interface and forwards it appropriately.
A configuration parameter to bypass this protection and allow broadcast on a GRE interface would be very helpful.
Hi Kernel reports whether the interface supports multicast and BIRD checks it to see whether it can use modes using multicast on that iface (OSPF 'broadcast' mode in reality uses multicast). You could disable the check by commenting out these lines in proto/ospf/iface.c: if ((ifa->type == OSPF_IT_BCAST) && !(iface->flags & if_multi_flag)) ifa->type = OSPF_IT_NBMA; But perhaps the simpler way is to fix the value reported by kernel: ip link set greXXX multicast on After that, BIRD accepts the interface as multicast and OSPF broadcast mode can be used. ip a a: 5: gre_x@NONE: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1476 qdisc noqueue state UNKNOWN group default birdc show interfaces: gre_x up (index=5) PtP Multicast AdminUp LinkUp MTU=1476 I don't know about DMVPN / OpenNHRP, but for regular PtP GRE (and other) tunnels it works without problems (packets are just send to the other side). Linux kernel should report multicast flag for PtP GRE tunnels, not reporting it is IMHO a long-term bug in Linux kernel. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On Tue, Mar 03, 2015 at 12:34:18PM +0100, Ondrej Zajicek wrote:
On Mon, Mar 02, 2015 at 03:49:48PM -0500, Clint Armstrong wrote:
I am trying to use BIRD to run OSPF inside a Phase 3 DMVPN using OpenNHRP. The problem I'm seeing is that it appears to be impossible to force type broadcast on a GRE interface. When I try, the message "Cannot use interface gre1 as broadcast, forcing nbma" is logged.
This may normally make sense, but the OpenNHRP daemon captures multicast traffic on it's interface and forwards it appropriately.
A configuration parameter to bypass this protection and allow broadcast on a GRE interface would be very helpful.
Hi
Kernel reports whether the interface supports multicast and BIRD checks it to see whether it can use modes using multicast on that iface (OSPF 'broadcast' mode in reality uses multicast).
You could disable the check by commenting out these lines in proto/ospf/iface.c:
if ((ifa->type == OSPF_IT_BCAST) && !(iface->flags & if_multi_flag)) ifa->type = OSPF_IT_NBMA;
But perhaps the simpler way is to fix the value reported by kernel:
ip link set greXXX multicast on
After that, BIRD accepts the interface as multicast and OSPF broadcast mode can be used.
Well, my previous e-mail is wrong. It describes how it perhaps should work, but as i just check, (on Linux) BIRD ignores multicast flag, instead uses IFF_LOOPBACK / IFF_POINTOPOINT / IFF_BROADCAST to determine capabilities of the interface. Which means that PtP GRE interfaces works by default (as missing multicast flag does nothing) but setting multicast flag is ignored. Could you report what 'ip a l' reports for your DMVPN GRE devices? -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
participants (3)
-
Clint Armstrong -
Ondrej Zajicek -
oskar＠cetex.se