On Mon, Jun 8, 2015 at 12:58 PM, Hannes Frederic Sowa <han...@stressinduktion.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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
