I didn't see an easy way to achieve this behavior without affecting
the non-VRF routing lookups (such as deleting non-VRF rules). We have
some automated tests that were looking for specific responses, but, of
course, those can be changed. Among a few of my colleagues, this
became a discussion abo
On 4/13/18 2:23 PM, Jeff Barnhill wrote:
> It seems that the ENETUNREACH response is still desirable in the VRF
> case since the only difference (when using VRF vs. not) is that the
> lookup should be restrained to a specific VRF.
VRF is just policy routing to a table. If the table wants the looku
Thanks for the response, David. I'm not questioning the need to stop
the fib lookup once the end of the VRF table is reached - I agree that
is needed. I'm concerned with the difference in the response/error
returned from the failed lookup.
For instance, with vrf "unreachable default" route, I get
On 4/12/18 10:54 AM, Jeff Barnhill wrote:
> 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,
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 unre
On 10/31/17 4:20 PM, Jeff Barnhill wrote:
> I was surprised that nlmsg_parse in fib_nl_newrule() didn't pick this
> up, but I verified that the received value for this attribute was 0,
> not 1 (w/o the patch).
It only checks minimum length, not exact length.
On 10/31/17 4:20 PM, Jeff Barnhill wrote:
> Thanks, David. Those slides are extremely helpful.
>
> Also, I ran into a bug that manifested on big endian architecture:
>
> diff --git i/drivers/net/vrf.c w/drivers/net/vrf.c
> index b23bb2fae5f8..a5f984689aee 100644
> --- i/drivers/net/vrf.c
> +++ w
Thanks, David. Those slides are extremely helpful.
Also, I ran into a bug that manifested on big endian architecture:
diff --git i/drivers/net/vrf.c w/drivers/net/vrf.c
index b23bb2fae5f8..a5f984689aee 100644
--- i/drivers/net/vrf.c
+++ w/drivers/net/vrf.c
@@ -1130,7 +1130,7 @@ static int vrf_fi
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
Your comments on the tunnel VRF and underlay VRF being different make
sense and is more flexible. I think assigning the dev/link to the
same VRF as the tunnel master accomplishes the same thing that I
originally had in mind.
ping v4 loopback...
jeff@VM2:~$ ip route list vrf myvrf
127.0.0.0/8 dev
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 tunn
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 th
On 10/26/17 11:19 PM, Jeff Barnhill wrote:
> Thanks, David.
>
> I corrected the static route, applied the patch, and set the
> link/output dev on the tunnel and it works now. Is it required to set
> the link/output dev? I was thinking that this should not be required
> for cases where the outgoi
Thanks, David.
I corrected the static route, applied the patch, and set the
link/output dev on the tunnel and it works now. Is it required to set
the link/output dev? I was thinking that this should not be required
for cases where the outgoing device is not known, for instance on a
router or dev
On 10/25/17 9:28 PM, Jeff Barnhill wrote:
> Thanks, David.
>
> VM1:
> sudo ip addr add 192.168.200.1/24 dev enp0s8 broadcast 192.168.200.255
> sudo ip link set enp0s8 up
> sudo ip route add 192.168.210.0/24 nexthop via 192.168.200.3 dev enp0s8
> sudo ip tunnel add jtun mode sit remote 192.168.210.
Thanks, David.
VM1:
sudo ip addr add 192.168.200.1/24 dev enp0s8 broadcast 192.168.200.255
sudo ip link set enp0s8 up
sudo ip route add 192.168.210.0/24 nexthop via 192.168.200.3 dev enp0s8
sudo ip tunnel add jtun mode sit remote 192.168.210.2 local 192.168.200.1
sudo ip -6 addr add 2001::1/64 dev
On 10/25/17 2:45 PM, Jeff Barnhill wrote:
> Are v6/sit tunnels working with VRFs?
>
> For instance, I have a very simple configuration with three VMs
> running 4.13.0-16 (Ubuntu Server 17.10) kernels. VM3 is setup as a
> router for separation. VM1 and VM2 have static routes to each other
> via V
Are v6/sit tunnels working with VRFs?
For instance, I have a very simple configuration with three VMs
running 4.13.0-16 (Ubuntu Server 17.10) kernels. VM3 is setup as a
router for separation. VM1 and VM2 have static routes to each other
via VM3. All VMs have v4 interfaces configured. If I setu
18 matches
Mail list logo
