[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACP96tSp91XYo_UasZexb6c6Krru3LEJvDwEWSgKYgPHJmTkHw@mail.gmail.com>
Date: Thu, 9 Jul 2015 19:28:58 +0200
From: Sowmini Varadhan <sowmini05@...il.com>
To: David Ahern <dsa@...ulusnetworks.com>
Cc: netdev <netdev@...r.kernel.org>,
Shrijeet Mukherjee <shm@...ulusnetworks.com>,
Roopa Prabhu <roopa@...ulusnetworks.com>,
Andy Gospodarek <gospo@...ulusnetworks.com>,
jtoppins@...ulusnetworks.com, nikolay@...ulusnetworks.com,
ddutt@...ulusnetworks.com,
Hannes Frederic Sowa <hannes@...essinduktion.org>,
Nicolas Dichtel <nicolas.dichtel@...nd.com>,
Stephen Hemminger <stephen@...workplumber.org>,
hadi@...atatu.com, "Eric W. Biederman" <ebiederm@...ssion.com>,
David Miller <davem@...emloft.net>
Subject: Re: [RFC net-next 3/6] net: Introduce VRF device driver - v2
On Thu, Jul 9, 2015 at 7:19 PM, David Ahern <dsa@...ulusnetworks.com> wrote:
> On the to-do list to use cmsg to specify a VRF for outbound packets using
> non-connected sockets. I do not believe it is going to work, but need to
> look into it.
>
>> What about setting ipsec policy for interfaces in the vrf?
>From a purely parochial standpoint, how would rds sockets work in this model?
Would the tcp encaps happen before or after the the vrf "driver" output?
Same problem for NFS.
>From a non-parochial standpoint. There are a *lot* of routing apps that actually
need more visibility into many details about the "slave" interface: e.g., OSPF,
ARP snoop, IPSLA.. the list is pretty long.
I think it's a bad idea to use a "driver" to represent a table lookup. Too many
hacks will become necessary.
--Sowmini
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists