From: David Ahern <dsahern@gmail.com>
To: Ben Greear <greearb@candelatech.com>,
Sowmini Varadhan <sowmini05@gmail.com>
Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Nicolas Dichtel <nicolas.dichtel@6wind.com>,
netdev <netdev@vger.kernel.org>
Subject: Re: VRFs and the scalability of namespaces
Date: Mon, 29 Sep 2014 17:43:43 -0600 [thread overview]
Message-ID: <5429EEAF.9030702@gmail.com> (raw)
In-Reply-To: <54299019.3050604@candelatech.com>
On 9/29/14, 11:00 AM, Ben Greear wrote:
> On 09/29/2014 09:50 AM, Sowmini Varadhan wrote:
>> On Mon, Sep 29, 2014 at 12:40 PM, Ben Greear <greearb@candelatech.com> wrote:
>>> On 09/29/2014 06:06 AM, David Ahern wrote:
>>
>>>
>>> We have implemented support for at least most of this (excepting duplicate IPs)
>>> using routing tables, rules, and (optionally, xorp as the router).
>>>
>>
>> My undertanding of multiple routing-tables/rules was that they
>> are closer in semantics to switch/router ACLs than to VRFs, eg.,
>> one big difference is that an interface can belong to exactly one
>> VRF at a time, which is not mandated by multiple routing-tables/rules.
>>
>> Was I mistaken?
>
> You can effectively force an interface to belong to a particular virtual
> router (table). It is not trivial to do, and possibly I have still not
> covered every possible case. Some rules grow somewhat exponentially as
> interfaces are added to virtual routers (ie, preference 10 rules).
An interesting way of doing it; thanks for the reference point.
Fundamentally the design should be able to assign interfaces to a single
VRF, support duplicate IP addresses on different interfaces in different
VRFs and be able to scale to 10,000+ netdevices -- devices representing
physical ports as well as logical interfaces built on top of them (e.g.,
sub-interfaces).
David
next prev parent reply other threads:[~2014-09-29 23:43 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-26 22:37 VRFs and the scalability of namespaces David Ahern
2014-09-26 23:52 ` Stephen Hemminger
2014-09-27 0:00 ` David Ahern
2014-09-27 1:25 ` Eric W. Biederman
2014-09-29 12:34 ` David Ahern
2014-09-27 13:29 ` Hannes Frederic Sowa
2014-09-27 14:09 ` Hannes Frederic Sowa
2014-09-29 13:06 ` David Ahern
2014-09-29 16:40 ` Ben Greear
2014-09-29 16:50 ` Sowmini Varadhan
2014-09-29 17:00 ` Ben Greear
2014-09-29 23:43 ` David Ahern [this message]
2014-09-29 23:50 ` Hannes Frederic Sowa
2014-09-30 1:15 ` Ben Greear
2014-09-29 18:05 ` Cong Wang
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=5429EEAF.9030702@gmail.com \
--to=dsahern@gmail.com \
--cc=ebiederm@xmission.com \
--cc=greearb@candelatech.com \
--cc=hannes@stressinduktion.org \
--cc=netdev@vger.kernel.org \
--cc=nicolas.dichtel@6wind.com \
--cc=sowmini05@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.