netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Brent Cook <bcook@breakingpoint.com>
To: David Miller <davem@davemloft.net>
Cc: <netdev@vger.kernel.org>
Subject: Re: [PATCH 1/2] ipv4/ipv6: Prepare for new route gateway semantics.
Date: Fri, 27 Jan 2012 12:59:51 -0600	[thread overview]
Message-ID: <201201271259.51534.bcook@breakingpoint.com> (raw)
In-Reply-To: <20120126.155544.2054995753871805122.davem@davemloft.net>

On Thursday, January 26, 2012 02:55:44 PM David Miller wrote:
> In the future the ipv4/ipv6 route gateway will take on two types
> of values:
> 
> 1) INADDR_ANY/IN6ADDR_ANY, for local network routes, and in this case
>    the neighbour must be obtained using the destination address in
>    ipv4/ipv6 header as the lookup key.
> 
> 2) Everything else, the actual nexthop route address.
> 
> So if the gateway is not inaddr-any we use it, otherwise we must use
> the packet's destination address.

Under what cases would this be expected to help keep the # of lookup keys at a 
minimum? I tried some experiments with these changes against a topology like 
this:

6RD CE         Router         Linux 6RD BR            IPv6 Server
1.1.1.200  ->  1.0.0.1  -> 1.0.0.2 - 2001:1234:1  ->  2001:1234:2

Behind the 6RD CE, we simulate a few thousand hosts connecting to the server.

This seems to still have the effect of adding a few thousand neighbor entries, 
one for each packet the IPv6 server sends to one of the IPv6 addresses behind 
the CE.

The addresses modulate as follows:

2001:5678::1 - 2001:5678::ffff

I might have expected the nexthop route address for packets directed to the 
tunneled IPv6 hosts to be the same for all destination IPs. Would it be 
helpful for me to dig in and find out what the lookup key ends up being in 
this case?

> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
>  net/ipv4/route.c |    5 +++++
>  net/ipv6/route.c |   16 +++++++++++++++-
>  2 files changed, 20 insertions(+), 1 deletions(-)
> 
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index bcacf54..4eeb8ce 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -1117,10 +1117,15 @@ static struct neighbour *ipv4_neigh_lookup(const
> struct dst_entry *dst, const vo static const __be32 inaddr_any = 0;
>  	struct net_device *dev = dst->dev;
>  	const __be32 *pkey = daddr;
> +	const struct rtable *rt;
>  	struct neighbour *n;
> 
> +	rt = (const struct rtable *) dst;
> +
>  	if (dev->flags & (IFF_LOOPBACK | IFF_POINTOPOINT))
>  		pkey = &inaddr_any;
> +	else if (rt->rt_gateway)
> +		pkey = (const __be32 *) &rt->rt_gateway;
> 
>  	n = __ipv4_neigh_lookup(&arp_tbl, dev, *(__force u32 *)pkey);
>  	if (n)
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index 8c2e3ab..7d7f306 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -121,9 +121,23 @@ static u32 *ipv6_cow_metrics(struct dst_entry *dst,
> unsigned long old) return p;
>  }
> 
> +static inline const void *choose_neigh_daddr(struct rt6_info *rt, const
> void *daddr) +{
> +	struct in6_addr *p = &rt->rt6i_gateway;
> +
> +	if (p->s6_addr32[0] | p->s6_addr32[1] |
> +	    p->s6_addr32[2] | p->s6_addr32[3])
> +		return (const void *) p;
> +	return daddr;
> +}
> +
>  static struct neighbour *ip6_neigh_lookup(const struct dst_entry *dst,
> const void *daddr) {
> -	struct neighbour *n = __ipv6_neigh_lookup(&nd_tbl, dst->dev, daddr);
> +	struct rt6_info *rt = (struct rt6_info *) dst;
> +	struct neighbour *n;
> +
> +	daddr = choose_neigh_daddr(rt, daddr);
> +	n = __ipv6_neigh_lookup(&nd_tbl, dst->dev, daddr);
>  	if (n)
>  		return n;
>  	return neigh_create(&nd_tbl, daddr, dst->dev);

  parent reply	other threads:[~2012-01-27 18:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-26 20:55 [PATCH 1/2] ipv4/ipv6: Prepare for new route gateway semantics David Miller
2012-01-26 21:24 ` YOSHIFUJI Hideaki
2012-01-26 21:29   ` David Miller
2012-01-27 18:59 ` Brent Cook [this message]
2012-01-27 21:34   ` David Miller

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=201201271259.51534.bcook@breakingpoint.com \
    --to=bcook@breakingpoint.com \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    /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).