Hi David, In the slides referenced, you recommend adding an "unreachable default" route to the end of each VRF route table. In my testing (for v4) this results in a change to fib lookup failures such that instead of ENETUNREACH being returned, EHOSTUNREACH is returned since the fib finds the unreachable route, versus failing to find a route altogether.
Have the implications of this been considered? I don't see a clean/easy way to achieve the old behavior without affecting non-VRF routing (eg. remove the unreachable route and delete the non-VRF rules). I'm guessing that programmatically, it may not make much difference, ie. lookup fails, but for debugging or to a user looking at it, the difference matters. Do you (or anyone else) have any thoughts on this? Thanks, Jeff On Sun, Oct 29, 2017 at 11:48 AM, David Ahern <dsah...@gmail.com> wrote: > On 10/27/17 8:43 PM, Jeff Barnhill wrote: >> ping v4 loopback... >> >> jeff@VM2:~$ ip route list vrf myvrf >> 127.0.0.0/8 dev myvrf proto kernel scope link src 127.0.0.1 >> 192.168.200.0/24 via 192.168.210.3 dev enp0s8 >> 192.168.210.0/24 dev enp0s8 proto kernel scope link src 192.168.210.2 >> >> Lookups shown in perf script were for table 255. Is it necessary to >> put the l3mdev table first? If I re-order the tables, it starts >> working: > > Yes, we advise moving the local table down to avoid false hits (e.g., > duplicate addresses like this between the default VRF and another VRF). > > I covered that and a few other things at OSS 2017. Latest VRF slides for > users: > http://schd.ws/hosted_files/ossna2017/fe/vrf-tutorial-oss.pdf
