On Mon, Jun 8, 2015 at 1:33 PM, Hannes Frederic Sowa <han...@stressinduktion.org> wrote: > On Mon, Jun 8, 2015, at 22:22, Shrijeet Mukherjee wrote: >> On Mon, Jun 8, 2015 at 12:58 PM, Hannes Frederic Sowa >> <han...@stressinduktion.org> wrote: >> > Hi Shrijeet, >> > >> > 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. > > This model is usable on its own, especially if one does not need routing > daemons > or user space software dealing with VRFs and sending out packets. > >> 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 > > I think this would be great. > > Last time I looked into the patches it was not yet clear if we can do > that > without holding strong references to the other interfaces. Hopefully > this can > be done by just passing down the table ids to the slaves during > initializing > and teardown of the master vrf interface. > > Bye, > Hannes
We can do that, and the hooks are all available. But do we want to cut out the fib_rules ? this would close out the opportunity for someone to insert a fib_rule to override the rule which directs to a VRF device. Personally don't have a strong opinion, but want to make sure we understand that choice. -- 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