On Tue, Jun 9, 2015, at 00:44, Shrijeet Mukherjee wrote: > 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.
Hmm, wouldn't that still work with a target I added in my patch? The only problem I see is that people might build up rules which are not symmetric and thus vrf behavior differs from input and output path. One addition to ease this is to add a interface selector which matches on both, iif and oif. Also we must still keep in mind that rules are matched linearly by using a list, hundreds of vrfs would thus first have match hundreds of ip rules. Bye, Hannes -- 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
