Re: GRE keepalives, again

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



From: "Bosko Radivojevic" <bosko.radivojevic@xxxxxxxxx>
Date: Mon, 15 Sep 2008 00:49:15 +0200

netdev@xxxxxxxxxxxxxxx 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.

> 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
> 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 majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Netdev]     [Ethernet Bridging]     [Linux 802.1Q VLAN]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Git]     [Bugtraq]     [Yosemite News and Information]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux PCI]     [Linux Admin]     [Samba]

  Powered by Linux