I see. When i do `ping -I vrf2` to address that was leaked from vrf1
it selects source address that's set as local in vrf1 routing table.
Is this expected behavior? I guess, forwarding packets from vrf1 to
vrf2 local address won't help here.
6 mar. 2021 - 17:12, David Ahern [off-list ref]:
On 3/2/21 3:57 AM, Greesha Mikhalkin wrote:
quoted
Main goal is that 100.255.254.3 should be reachable from vrf2. But
after this setup it doesn’t work. When i run `ping -I vrf2
100.255.254.3` it sends packets from source address that belongs to
vlan1 enslaved by vrf1. I can see in tcpdump that ICMP packets are
sent and then returned to source address but they're not returned to
ping command for some reason. To be clear `ping -I vrf1 …` works fine.
I remember this case now: VRF route leaking works for fowarding, but not
local traffic. If a packet arrives in vrf2, it should get forwarded to
vrf1 and on to its destination. If the reverse route exists then round
trip traffic works.
From: David Ahern <hidden> Date: 2021-03-12 16:39:57
On 3/10/21 1:34 AM, Greesha Mikhalkin wrote:
I see. When i do `ping -I vrf2` to address that was leaked from vrf1
it selects source address that's set as local in vrf1 routing table.
Is this expected behavior? I guess, forwarding packets from vrf1 to
vrf2 local address won't help here.
That's the way the source address selection works -- it takes the fib
lookup result and finds the best source address match for it.
Try adding 'src a.b.c.d' to the leaked route. e.g.,
ip ro add 172.16.1.0/24 dev red vrf blue src 172.16.2.1
where red and blue are VRFs, 172.16.2.1 is a valid source address in VRF
blue and VRF red has the reverse route installed.
That's the way the source address selection works -- it takes the fib
lookup result and finds the best source address match for it.
Try adding 'src a.b.c.d' to the leaked route. e.g.,
ip ro add 172.16.1.0/24 dev red vrf blue src 172.16.2.1
where red and blue are VRFs, 172.16.2.1 is a valid source address in VRF
blue and VRF red has the reverse route installed.
Tried to do that. Added reverse route to vrf red like that:
ip ro add vrf red 172.16.2.1/32 dev blue
172.16.2.1 is selected as source address when i ping. But now, when i
look at `tcpdump icmp` i only see requests:
172.16.2.1 > 172.16.1.3: ICMP echo request, id 9, seq 10, length 64
And no replies and anything else. If i look into tcpdump on machine
that's pinged -- it doesn't receive anything.
So it looks like it's not using nexthops from vrf red in that case.
Maybe it has something to do with how address is setup. In routing
table it looks like:
local 172.16.2.1 dev vlanblue proto kernel scope host src 172.16.2.1
From: David Ahern <hidden> Date: 2021-03-15 18:42:01
On 3/15/21 11:10 AM, Greesha Mikhalkin wrote:
quoted
That's the way the source address selection works -- it takes the fib
lookup result and finds the best source address match for it.
Try adding 'src a.b.c.d' to the leaked route. e.g.,
ip ro add 172.16.1.0/24 dev red vrf blue src 172.16.2.1
where red and blue are VRFs, 172.16.2.1 is a valid source address in VRF
blue and VRF red has the reverse route installed.
Tried to do that. Added reverse route to vrf red like that:
ip ro add vrf red 172.16.2.1/32 dev blue
172.16.2.1 is selected as source address when i ping. But now, when i
look at `tcpdump icmp` i only see requests:
172.16.2.1 > 172.16.1.3: ICMP echo request, id 9, seq 10, length 64
And no replies and anything else. If i look into tcpdump on machine
that's pinged -- it doesn't receive anything.
So it looks like it's not using nexthops from vrf red in that case.
Maybe it has something to do with how address is setup. In routing
table it looks like:
local 172.16.2.1 dev vlanblue proto kernel scope host src 172.16.2.1
VRF is implemented via policy routing. did you re-order the FIB rules?
Reordered. Output of `ip rule`:
1000: from all lookup [l3mdev-table]
32765: from all lookup local
32766: from all lookup main
32767: from all lookup default
Unfortunately, that didn't help.