Hi guys,
I'm testing gre with Cisco, but once keepalive is enabled on Cisco side, it shows tunnel protocol down, tried setting accept_local sysctl parameter to 1 but didn't work, suggest any fix
Same here, seems like tunnel goes up only if it's initiated from Openwrt, same trouble with EoIP.
OpenWrt 22.03.5 r20134-5f15225c1e / LuCI openwrt-22.03 branch git-23.093.57104-ce20b4a
GRE keepalive are two packages. The request package goes from the sender to the recipient, the response package goes the other way around.
If I'm not mistaken, there's no specific protocol the recipient must support, nothing the recipient must understand and answer properly.
The sender creates the answer package itself. That is, the very package it expects to get back. The sender wraps that package in a GRE package as if it would come from the remote end through the tunnel. Then the sender wraps that wrapped package into a GRE package it intends to send through the tunnel and sends it on the wire.
So GRE keepalive is basically GRE in GRE.
The remote side peels the outer GRE package away, detects another GRE package (pointing in the opposite direction), and sends it back.
So I guess if GRE keepalive doesn't work, that's some routing issue, something not related to GRE but to routing in general. The Cisco documentation talks about GRE keepalive not working if there's "VRF" (iVRF and fVRF) in place. I'm not sure about Cisco terminology, but I guess that's more or less that firewall/routing thing I was talking about.
Do you have your GRE interfaces in OpenWRT firewall zones? Have you tried playing around with input and forward accept rules? I've never tried that, but my assumption would be (on how I explained GRE keepalive works) one would need at least forward enabled on the GRE interface.
What do you actually need that keepalive for? Imho knowing the state of a link is only necessary if you try to act on it. I'm talking about createing one GRE tunnel through a 1GE fiber line and another one on a 250MBit DSL line. You want different routes with different metrics that would favor the fast link but would automatically fall back to the slow link once the "calbe is plugged". Hence the keepalive, which works as "the calbe is plugged". Unless you are not planning on acting on up/down events I see no point in adding keepalive.
I wouldlike to add, as another option: BFD which is protocol independent. See https://en.m.wikipedia.org/wiki/Bidirectional_Forwarding_Detection
I can not comment on your explanation but sounds valid...
Hi guy, thanks for the respons, to resolve the issue for keepalive reposnse, i wrote an userland app, which is listening on the gre interface with pcap, check if packet is gre keepalive or not, if it is then extracting the dst addr from packet, opening a raw socket and sending that packet back to intended dst addr, regarding tweaks in firewall, i tried those but as per some stack overflow comment linux kernel drops the packet with source address as local unless setted explicitly for in sysctl but that wan not working for me,
hi, i know bfd is way better than gre keepalive, but it can not be implemented as other end of the gre tunnel is not in my control, and guy handling that is insisting on gre keepalive.
1 Like
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.