On 10/27/17 2:59 PM, Jeff Barnhill wrote: > w/regards to this comment: > You have a remote address with no qualification about which VRF to > use for the lookup. > > I was using this to enslave the tunnel: > sudo ip link set jtun vrf myvrf > > and assumed this would be enough to cause all tunnel traffic to be > part of this VRF. > > You are right about the tunnel link/dev configuration. (re-stating to > be sure we are saying the same thing) I can use either the VRF device > or the v4 device and the packet will get sent. If I use the VRF > device, when the reply packet is received, the tunnel is found > successfully. If I use the v4 device, then I need the patch you > provided earlier to successfully look up the tunnel. You mentioned > that both should be supported...Back to my previous comment about > enslaving the tunnel...shouldn't a tunnel being enslaved to a VRF also > be enough to allow sending and receiving on any device in that VRF > (that is, not having to configure the link/dev on the tunnel) ?
Sure, it could be done that way. I guess the question is whether we want to allow the tunnel device and the underlying device to be in separate VRFs. I have always taken the approach that every device with an address can be in a separate routing domain. Here, that means the tunnel devices can be in 1 VRF, and the underlying connection in a separate VRF (or no VRF). > > Fyi...with regards to the v4 ping, adding the loopback address/network > didn't work for me. I'll see if I can get anymore info on this and > maybe start a new thread. > > Thanks, > Jeff > > > jeff@VM2:~$ ping -I myvrf 127.0.0.1 > ping: Warning: source address might be selected on device other than myvrf. > PING 127.0.0.1 (127.0.0.1) from 127.0.0.1 myvrf: 56(84) bytes of data. > ^C > --- 127.0.0.1 ping statistics --- > 3 packets transmitted, 0 received, 100% packet loss, time 2051ms > > jeff@VM2:~$ sudo ip addr add dev myvrf 127.0.0.1/8 > jeff@VM2:~$ ping -I myvrf 127.0.0.1 > PING 127.0.0.1 (127.0.0.1) from 127.0.0.1 myvrf: 56(84) bytes of data. > ^C > --- 127.0.0.1 ping statistics --- > 7 packets transmitted, 0 received, 100% packet loss, time 6149ms > > jeff@VM2:~$ ip addr list myvrf > 4: myvrf: <NOARP,MASTER,UP,LOWER_UP> mtu 65536 qdisc noqueue state UP > group default qlen 1000 > link/ether 82:2b:08:8f:a9:f3 brd ff:ff:ff:ff:ff:ff > inet 127.0.0.1/8 scope host myvrf > valid_lft forever preferred_lft forever This is v4.14 kernel? Something else? The 127.0.0.1 address on vrf device has been supported since the v4.9 kernel. ip ro ls vrf myvrf? perf record -e fib:* -a -g -- ping -I myvrf -c1 -w1 127.0.0.1 perf script --> does it show lookups in the correct table for this address?
