On 3/15/21 11:10 AM, Greesha Mikhalkin wrote: >> 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? http://schd.ws/hosted_files/ossna2017/fe/vrf-tutorial-oss.pdf
