From: Steffen Klassert <steffen.klassert@secunet.com>
To: netdev@vger.kernel.org
Cc: Christophe Gouault <christophe.gouault@6wind.com>,
Saurabh Mohan <saurabh.mohan@vyatta.com>
Subject: [PATCH RFC v2 09/13] ip_tunnel: Make vti work with i_key set
Date: Mon, 16 Dec 2013 10:24:28 +0100 [thread overview]
Message-ID: <20131216092428.GZ31491@secunet.com> (raw)
In-Reply-To: <20131216091835.GQ31491@secunet.com>
Vti uses the o_key to mark packets that were transmitted or received
by a vti interface. Unfortunately we can't apply different marks
to in and outbound packets with only one key availabe. Vti interfaces
typically use wildcard selectors for vti IPsec policies. On forwarding,
the same output policy will match for both directions. This generates
a loop between the IPsec gateways until the ttl of the packet is
exceeded.
The gre i_key/o_key are usually there to find the right gre tunnel
during a lookup. When vti uses the i_key to mark packets, the tunnel
lookup does not work any more because vti does not use the gre keys
as a hash key for the lookup.
This patch workarounds this my not including the i_key when comupting
the hash for the tunnel lookup in case of vti tunnels.
With this we have separate keys available for the transmitting and
receiving side of the vti interface.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/ipv4/ip_tunnel.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index 90ff957..4bc7a6e 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -228,13 +228,17 @@ static struct hlist_head *ip_bucket(struct ip_tunnel_net *itn,
{
unsigned int h;
__be32 remote;
+ __be32 i_key = parms->i_key;
if (parms->iph.daddr && !ipv4_is_multicast(parms->iph.daddr))
remote = parms->iph.daddr;
else
remote = 0;
- h = ip_tunnel_hash(itn, parms->i_key, remote);
+ if (!(parms->i_flags & TUNNEL_KEY) && (parms->i_flags & VTI_ISVTI))
+ i_key = 0;
+
+ h = ip_tunnel_hash(itn, i_key, remote);
return &itn->tunnels[h];
}
--
1.7.9.5
next prev parent reply other threads:[~2013-12-16 9:24 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-16 9:18 [PATCH RFC v2 0/13] vti4: prepare namespace and interfamily support Steffen Klassert
2013-12-16 9:19 ` [PATCH RFC v2 01/13] xfrm4: Add IPsec protocol multiplexer Steffen Klassert
2013-12-16 9:19 ` [PATCH RFC v2 02/13] esp4: Use the IPsec protocol multiplexer API Steffen Klassert
2013-12-16 9:20 ` [PATCH RFC v2 03/13] esp4: Export esp4_err Steffen Klassert
2013-12-16 9:21 ` [PATCH RFC v2 04/13] ah4: Use the IPsec protocol multiplexer API Steffen Klassert
2013-12-16 9:21 ` [PATCH RFC v2 05/13] ah4: Export ah4_err Steffen Klassert
2013-12-16 9:22 ` [PATCH RFC v2 06/13] ipcomp4: Use the IPsec protocol multiplexer API Steffen Klassert
2013-12-16 9:23 ` [PATCH RFC v2 07/13] ipcomp4: Export ipcomp4_err Steffen Klassert
2013-12-16 9:23 ` [PATCH RFC v2 08/13] xfrm: Add xfrm_tunnel_skb_cb to the skb common buffer Steffen Klassert
2013-12-16 12:54 ` Nicolas Dichtel
2013-12-16 13:02 ` Steffen Klassert
2013-12-16 9:24 ` Steffen Klassert [this message]
2013-12-16 9:25 ` [PATCH RFC v2 10/13] vti: Update the ipv4 side to use it's own receive hook Steffen Klassert
2013-12-16 9:26 ` [PATCH RFC v2 11/13] xfrm4: Remove xfrm_tunnel_notifier Steffen Klassert
2013-12-16 9:27 ` [PATCH RFC v2 12/13] vti4: Use the on xfrm_lookup returned dst_entry directly Steffen Klassert
2013-12-16 9:28 ` [PATCH RFC v2 13/13] vti4: Support inter address family tunneling Steffen Klassert
2014-01-07 16:11 ` [PATCH RFC v2 0/13] vti4: prepare namespace and interfamily support Christophe Gouault
2014-01-07 19:45 ` Christophe Gouault
2014-01-14 7:51 ` Steffen Klassert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131216092428.GZ31491@secunet.com \
--to=steffen.klassert@secunet.com \
--cc=christophe.gouault@6wind.com \
--cc=netdev@vger.kernel.org \
--cc=saurabh.mohan@vyatta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).