From: David Ahern <dsa@cumulusnetworks•com>
To: "Eric W. Biederman" <ebiederm@xmission•com>
Cc: netdev@vger•kernel.org, shm@cumulusnetworks•com,
roopa@cumulusnetworks•com, gospo@cumulusnetworks•com,
jtoppins@cumulusnetworks•com, nikolay@cumulusnetworks•com,
ddutt@cumulusnetworks•com, hannes@stressinduktion•org,
nicolas.dichtel@6wind•com, stephen@networkplumber•org,
hadi@mojatatu•com, davem@davemloft•net, svaidya@brocade•com,
mingo@kernel•org, luto@amacapital•net
Subject: Re: [net-next 0/16] Proposal for VRF-lite - v3
Date: Tue, 28 Jul 2015 10:02:01 -0600 [thread overview]
Message-ID: <55B7A779.6040906@cumulusnetworks.com> (raw)
In-Reply-To: <87egjtz6kn.fsf@x220.int.ebiederm.org>
On 7/27/15 2:30 PM, Eric W. Biederman wrote:
> This paragraph is false when it comes to sockets, as I have already
> pointed out.
>
> - VPN Routing and Forwarding (RFC4364 and it's kin) implies isolation
> strong enough to allow using the the same ip on different machines
> in different VPN instances and not have confusion.
>
> - The routing table is not the only table in the kernel that uses
> an ip address as a key.
>
> The result is that you can combine packets fragments that come in
> on different interfaces (irrespective of your VPN), confuse tcp
> parameters between interfaces, scramble your ipsec connections and I
> don't know what else.
The duplicate IP address is a problem with the networking stack today;
the VRF device does not introduce it. The VRF device does allow
duplicate IP addresses within a namespace but separate VRFs, though yes
various places that rely solely on source address like IP fragmentation
do need to be fixed.
I looked at the IPv4 fragmentation code yesterday and will continue
today. So help me with the history: is there any reason why the device
index is not used today? It seems like a straight forward change.
1. simple netdevices with the same IP address
--> no problem using index in the lookup
2. 2 ipsec tunnels -- different netdevices, same IP address
--> no problem using index
3. stacked devices like bonding and team interfaces appear to the stack
as a single device
--> no problem using index of stacked device
4. If an interface is deleted and a new one is created with the same IP
address then we want to fail the lookup
--> no problem using index
5. other???
Is there a use case where I can't add ifindex of the incoming device (or
higher level device if skb->dev is changed) to the hash and lookup for
fragments?
>> Version 3
>> - addressed comments from first 2 RFCs with the exception of the name
>> Nicolas: We will do the name conversion once we agree on what the
>> correct name should be (vrf, mrf or something else)
>
> Not so. I described the deep problems between your goals and your
> implementation and they are not even mentioned let alone addressed.
I have addressed comments to the extent that I can. As I stated in my
last followup to you Eric I did not understand your point. I asked for
clarification, a --verbose if you will. I can't read your mind, so I
need you to elaborate on your points to be able to respond and address
your concerns.
>
>> - packets flow through the VRF device in both directions allowing the
>> following:
>> - tcpdump -i vrf<n>
>> - tc rules on vrf device
>> - netfilter rules on vrf device
>>
>> Ingo/Andy: I added you two as a start point for the proposed task related
>> changes. Not sure who should be the reviewer; please let me know
>> if someone else is more appropriate. Thanks.
>
> It looks like you are trying to implement a namespace that isn't a
> namespace. Given that it is broken by design you have my nack.
This is an L3 separation within a namespace, not a device level
separation which is what namespaces provide.
David
next prev parent reply other threads:[~2015-07-28 16:02 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-27 18:30 [net-next 0/16] Proposal for VRF-lite - v3 David Ahern
2015-07-27 18:30 ` [PATCH net-next 01/16] net: Refactor rtable allocation and initialization David Ahern
2015-07-27 18:30 ` [PATCH net-next 02/16] net: export a few FIB functions David Ahern
2015-07-27 18:30 ` [PATCH net-next 03/16] net: Introduce VRF related flags and helpers David Ahern
2015-07-27 18:30 ` [PATCH net-next 04/16] net: Use VRF device index for lookups on RX David Ahern
2015-07-27 18:30 ` [PATCH net-next 05/16] net: Use VRF device index for lookups on TX David Ahern
2015-07-27 18:30 ` [PATCH net-next 06/16] net: Tx via VRF device David Ahern
2015-07-27 18:31 ` [PATCH net-next 07/16] net: Add inet_addr lookup by table David Ahern
2015-07-27 18:31 ` [PATCH net-next 08/16] net: Fix up inet_addr_type checks David Ahern
2015-07-27 18:31 ` [PATCH net-next 09/16] net: Add routes to the table associated with the device David Ahern
2015-07-27 18:31 ` [PATCH net-next 10/16] net: Use passed in table for nexthop lookups David Ahern
2015-07-27 18:31 ` [PATCH net-next 11/16] net: Use VRF device index for socket lookups David Ahern
2015-07-27 18:31 ` [PATCH net-next 12/16] net: Add ipv4 route helper to set next hop David Ahern
2015-07-27 18:31 ` [PATCH net-next 13/16] net: Introduce VRF device driver - v2 David Ahern
2015-07-27 20:01 ` Nikolay Aleksandrov
2015-07-28 16:22 ` David Ahern
2015-07-27 18:31 ` [PATCH net-next 14/16] net: Add sk_bind_dev_if to task_struct David Ahern
2015-07-27 20:33 ` Eric W. Biederman
2015-07-28 12:19 ` Hannes Frederic Sowa
2015-07-28 13:54 ` Eric W. Biederman
2015-07-28 14:20 ` Hannes Frederic Sowa
2015-07-28 16:01 ` Eric Dumazet
2015-07-28 16:07 ` David Ahern
2015-07-28 16:52 ` Eric Dumazet
2015-07-28 15:25 ` Andy Lutomirski
2015-07-28 16:11 ` David Ahern
2015-07-28 17:12 ` Tom Herbert
2015-07-27 18:31 ` [PATCH net-next 15/16] net: Add chvrf command David Ahern
2015-07-27 18:31 ` [PATCH] iproute2: Add support for VRF device David Ahern
2015-07-27 20:30 ` [net-next 0/16] Proposal for VRF-lite - v3 Eric W. Biederman
2015-07-28 16:02 ` David Ahern [this message]
2015-07-28 17:07 ` Eric W. Biederman
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=55B7A779.6040906@cumulusnetworks.com \
--to=dsa@cumulusnetworks$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=ddutt@cumulusnetworks$(echo .)com \
--cc=ebiederm@xmission$(echo .)com \
--cc=gospo@cumulusnetworks$(echo .)com \
--cc=hadi@mojatatu$(echo .)com \
--cc=hannes@stressinduktion$(echo .)org \
--cc=jtoppins@cumulusnetworks$(echo .)com \
--cc=luto@amacapital$(echo .)net \
--cc=mingo@kernel$(echo .)org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=nicolas.dichtel@6wind$(echo .)com \
--cc=nikolay@cumulusnetworks$(echo .)com \
--cc=roopa@cumulusnetworks$(echo .)com \
--cc=shm@cumulusnetworks$(echo .)com \
--cc=stephen@networkplumber$(echo .)org \
--cc=svaidya@brocade$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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