GRE keepalives, again
Bosko Radivojevic
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
fine.
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? :)
Thanks!
PS. More info about GRE keepalive -
http://www.cisco.com/en/US/tech/tk827/tk369/technologies_tech_note09186a008048cffc.shtml#t6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
David Miller
Date: Mon, 15 Sep 2008 00:49:15 +0200
net...@vger.kernel.org is where networking developers are, added
to the CC:
Also, most of us are at the kernel summit and the plumbers
conference over the next few days, so don't expect any response
of substance for at least a week. Likely it will take longer,
as after returning most of us will have a huge backlog to process.
Bosko Radivojevic
> net...@vger.kernel.org is where networking developers are, added
> to the CC:
Thanks for that!
>> 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)) {
This one here is not true. I'll keep digging, but I think that this
behavior is not result of a bug. It seems I just don't know how to
turn the feature off ;)
Sincerely,
Bosko
Bosko Radivojevic
Problem is - fib_validate_source() explicitly doesn't allow any local
address to be specified as source address. I figured out I'm not the
first in need for different behavior. One of the solutions I've found
is forward_shared patch
[http://www.ssi.bg/~ja/forward_shared-2.6.25-2.diff] which exists for
centuries. Actually, it is not working for me but it is addressing the
same thing - forwarding packets with local addresses.
I've solved my problem (Cisco's GRE keepalive and Linux) with this small change:
--- linux-2.6.26.3/net/ipv4/fib_frontend.c-orig 2008-09-16
01:50:07.000000000 +0200
+++ linux-2.6.26.3/net/ipv4/fib_frontend.c 2008-09-16 01:50:27.000000000 +0200
@@ -260,7 +260,7 @@ int fib_validate_source(__be32 src, __be
net = dev_net(dev);
if (fib_lookup(net, &fl, &res))
goto last_resort;
- if (res.type != RTN_UNICAST)
+ if ((res.type != RTN_UNICAST) && !((res.type == RTN_LOCAL) &&
(dev->type == ARPHRD_IPGRE))) {
goto e_inval_res;
*spec_dst = FIB_RES_PREFSRC(res);
fib_combine_itag(itag, &res);
----------------------------------------------------------------------
I'm pretty sure this is not the right solution, if there is a need for
'solution' at all. Maybe this behavior is what we need and there is no
real need to ever forward packets coming with local source address. I
failed to find a way to test if destination address is remote end of
GRE tunnel.
I found another strange (for me, at least) thing -
ip_route_input_slow() is discarding packets if "IP is not enabled" on
the device. The only way to "enable IP" on IP_GRE interface is to
assign it an IP. Is there another way of "enabling IP" on IP_GRE
interface? I think there is no much need for assigning an IP address
to GRE interface. Am I wrong here? IP should be 'enabled' by default
for IP_GRE interfaces.
PS. Of course, I order this forwarding of encapsulated packets with
local source address to work, GRE tunnel must be created, GRE
interface have to be UP with IP address assigned and with forwarding
enabled.