Patchwork ip_gre: When TOS is inherited, use configured TOS value for non-IP packets

login
register
mail settings
Submitter David Ward
Date Jan. 27, 2013, 11:04 p.m.
Message ID <1359327899-8153-1-git-send-email-david.ward@ll.mit.edu>
Download mbox | patch
Permalink /patch/216080/
State Accepted
Delegated to: David Miller
Headers show

Comments

David Ward - Jan. 27, 2013, 11:04 p.m.
A GRE tunnel can be configured so that outgoing tunnel packets inherit
the value of the TOS field from the inner IP header. In doing so, when
a non-IP packet is transmitted through the tunnel, the TOS field will
always be set to 0.

Instead, the user should be able to configure a different TOS value as
the fallback to use for non-IP packets. This is helpful when the non-IP
packets are all control packets and should be handled by routers outside
the tunnel as having Internet Control precedence. One example of this is
the NHRP packets that control a DMVPN-compatible mGRE tunnel; they are
encapsulated directly by GRE and do not contain an inner IP header.

Under the existing behavior, the IFLA_GRE_TOS parameter must be set to
'1' for the TOS value to be inherited. Now, only the least significant
bit of this parameter must be set to '1', and when a non-IP packet is
sent through the tunnel, the upper 6 bits of this same parameter will be
copied into the TOS field. (The ECN bits get masked off as before.)

This behavior is backwards-compatible with existing configurations and
iproute2 versions.

Signed-off-by: David Ward <david.ward@ll.mit.edu>
---
 net/ipv4/ip_gre.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)
David Miller - Jan. 29, 2013, 7:06 p.m.
From: David Ward <david.ward@ll.mit.edu>
Date: Sun, 27 Jan 2013 18:04:58 -0500

> A GRE tunnel can be configured so that outgoing tunnel packets inherit
> the value of the TOS field from the inner IP header. In doing so, when
> a non-IP packet is transmitted through the tunnel, the TOS field will
> always be set to 0.
> 
> Instead, the user should be able to configure a different TOS value as
> the fallback to use for non-IP packets. This is helpful when the non-IP
> packets are all control packets and should be handled by routers outside
> the tunnel as having Internet Control precedence. One example of this is
> the NHRP packets that control a DMVPN-compatible mGRE tunnel; they are
> encapsulated directly by GRE and do not contain an inner IP header.
> 
> Under the existing behavior, the IFLA_GRE_TOS parameter must be set to
> '1' for the TOS value to be inherited. Now, only the least significant
> bit of this parameter must be set to '1', and when a non-IP packet is
> sent through the tunnel, the upper 6 bits of this same parameter will be
> copied into the TOS field. (The ECN bits get masked off as before.)
> 
> This behavior is backwards-compatible with existing configurations and
> iproute2 versions.
> 
> Signed-off-by: David Ward <david.ward@ll.mit.edu>

Seems reasonable, applied.  Thanks.

I worry though about the case where tiph comes from skb->data rather
than the tunnel parameter block, can you describe why this new behavior
is OK in that situation too.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
David Ward - Feb. 6, 2013, 9:23 p.m.
On 01/29/2013 02:06 PM, David Miller wrote:
>
> From: David Ward <david.ward@ll.mit.edu>
> Date: Sun, 27 Jan 2013 18:04:58 -0500
>
> > A GRE tunnel can be configured so that outgoing tunnel packets inherit
> > the value of the TOS field from the inner IP header. In doing so, when
> > a non-IP packet is transmitted through the tunnel, the TOS field will
> > always be set to 0.
> >
> > Instead, the user should be able to configure a different TOS value as
> > the fallback to use for non-IP packets. This is helpful when the non-IP
> > packets are all control packets and should be handled by routers outside
> > the tunnel as having Internet Control precedence. One example of this is
> > the NHRP packets that control a DMVPN-compatible mGRE tunnel; they are
> > encapsulated directly by GRE and do not contain an inner IP header.
> >
> > Under the existing behavior, the IFLA_GRE_TOS parameter must be set to
> > '1' for the TOS value to be inherited. Now, only the least significant
> > bit of this parameter must be set to '1', and when a non-IP packet is
> > sent through the tunnel, the upper 6 bits of this same parameter will be
> > copied into the TOS field. (The ECN bits get masked off as before.)
> >
> > This behavior is backwards-compatible with existing configurations and
> > iproute2 versions.
> >
> > Signed-off-by: David Ward <david.ward@ll.mit.edu>
>
> Seems reasonable, applied.  Thanks.
>
> I worry though about the case where tiph comes from skb->data rather
> than the tunnel parameter block, can you describe why this new behavior
> is OK in that situation too.
>

Sorry for the late reply, I have not been well for the past few days.

The case you mentioned will occur when dev->header_ops has been set (to 
ipgre_header_ops).  In that case, ipgre_header() is called before 
ipgre_tunnel_xmit().  It pushes the outer IP header onto the SKB ahead 
of time, copying the contents from the IP header in the tunnel parameter 
block.

So even in this case, the TOS value that we check is taken from the 
tunnel parameter block, not the inner IP header.

David

Patch

diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 303012a..e4c8817 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -818,8 +818,8 @@  static netdev_tx_t ipgre_tunnel_xmit(struct sk_buff *skb, struct net_device *dev
 
 	ttl = tiph->ttl;
 	tos = tiph->tos;
-	if (tos == 1) {
-		tos = 0;
+	if (tos & 0x1) {
+		tos &= ~0x1;
 		if (skb->protocol == htons(ETH_P_IP))
 			tos = old_iph->tos;
 		else if (skb->protocol == htons(ETH_P_IPV6))