netdev - Re: [RFC net-next 3/3] rcv path changes for vrf traffic

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 8 Jun 2015 13:22:18 -0700
From:	Shrijeet Mukherjee <shm@...ulusnetworks.com>
To:	Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc:	Nicolas Dichtel <nicolas.dichtel@...nd.com>,
	David Ahern <dsahern@...il.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Jamal Hadi Salim <hadi@...atatu.com>,
	David Miller <davem@...emloft.net>,
	Stephen Hemminger <stephen@...workplumber.org>,
	Netdev <netdev@...r.kernel.org>,
	Roopa Prabhu <roopa@...ulusnetworks.com>,
	Andy Gospodarek <gospo@...ulusnetworks.com>,
	Jon Toppins <jtoppins@...ulusnetworks.com>,
	Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
Subject: Re: [RFC net-next 3/3] rcv path changes for vrf traffic

On Mon, Jun 8, 2015 at 12:58 PM, Hannes Frederic Sowa
<hannes@...essinduktion.org> wrote:
> Hi Shrijeet,
>
> From an architectural level I think the output path looks good. For the
> input path I would also to propose my (I think) more flexible solution:
>
> For rx layer I want to also propose my try:
>
> [PATCH net-next RFC] net: ipv4: arp: strong end system model semantics by per-interface local table override
>
> By allowing to direct routing table lookups to a specific table based
> on the incoming interface for IPv4 and ARP, we start to behave like a
> strong end host system without tweaking arp_* sysctl settings.
>
> The main motivation behind this patch was input and forwarding support
> in a VRF like model. Maybe it also helps for hardware offloading by
> allowing reducing rule complexity.
>
> An example:
>
> $ ip rule flush
> $ ip rule del
> $ ip rule del
> $ ip rule add inherit-table
> 0:      from all inherit-table
>
> This by default still uses RT_TABLE_LOCAL until we set up per interface
> route tables:
>
> $ ip link set dev enp0s25 ipv4-rt-table-id 100
> $ ip -d link ls dev enp0s25
> 2: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
>     link/ether e4:7f:b2:1b:4c:61 brd ff:ff:ff:ff:ff:ff promiscuity 0 ipv4-rt-table-id 100 addrgenmode none
>
> This let's incoming and arp requests use routing table 100. The system
> will stop responding to arp requests as we don't have any entries in
> this routing table.


I like this model in general, as it addresses the issue that I have
not addressed around connected routes.

This would force local and directly connected host routes to be learnt
into the correct table.

It does bring the question up then.

1. The driver already knows the vrf device to table map
2. If the device also knows the final device to table map

then do we need to use fib_rules and just lookup the table directly.
It does make the configuration a little longer since each component
device now needs configuration when you add/del a member from a vrf.

If people generally agree and we want to skip the fib_rule lookup,
then I can make it such that enslaving already takes the dev-table id
as well, and then the process of enslaving in the nominal VRF case
becomes

ip link add vrf-dev type vrf table foo ipv4-rt-table-id bar
ip link set eth2 master vrf-dev

Does that work ?
--
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