GRE keepalives, again

From: Bosko Radivojevic
Date: Sun Sep 14 2008 - 18:49:27 EST

Hi all

Ten days ago I asked if anyone has some info regarding Cisco's GRE
keepalive support. Later I've realized that idea behing that feature
is quite simple and nice. As it says on Cisco site:

> Router constructs the inner IP header and GRE header with a Protocol
> Type (PT) of 0. It then sends that packet out its tunnel interface, which
> results in the encapsulation of the packet with the outer IP header and a
> GRE header with PT = IP

Using the same idea, I've written small userspace app that do almost
the same - instead of constructing "inner" packet with GRE header, I'm
constructing UDP packet (it is easier to receive it in user space).
After all, that "keepalive" packet looks like - IP|GRE|IP|UDP. When
other end decapsulate it, inner IP|UDP packet should be sent back to
the originating end. So, my primary task to support GRE keepalives on
Linux side in Cisco-to-Linux "network" is accomplished. It's working

Problem is the other situation, when Cisco is sending keepalives, or
if a GRE tunnel is created between two Linux boxes and my app started
on any of them. Linux is not sending back the "inner" packet (when
"keepalive" packet is decapsulated on the other end, inner IP|UDP or
IP|GRE packet should be sent back to the originating end). Nor Cisco's
generated, nor generated by my app.

At the beginning I taught it has something with rp_filters or
something "adjustable" in /proc/sys/net/... But I was wrong. What
could be a reason for this behavior? I spent some time trying to debug
this, and it looks like inner packet never leave ip_gre code. It looks
like the journey of the packet ends in ipgre_ecn_decapsulate() at the
very beginning: if (INET_ECN_is_ce(iph->tos)) {

Does anyone have some hint for me? :)


PS. More info about GRE keepalive -
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at