VRF troubles

[ka291]

default config by first start
—

/ip vrf add disabled=no interfaces=eth5 name=UP5

/ip vrf add disabled=no interfaces=trusted name=_trusted
bridge “trusted” + eth4 + dhcp server

____

When I ping
[admin@MikroTik] > ping 10.123.20.1 vrf=UP5
SEQ HOST SIZE TTL TIME STATUS
0 10.123.20.1 56 64 1ms29us
1 10.123.20.1 56 64 644us
2 10.123.20.1 56 64 644us
3 10.123.20.1 56 64 682us
4 10.123.20.1 56 64 636us
sent=5 received=5 packet-loss=0% min-rtt=636us avg-rtt=727us max-rtt=1ms29us

Then ping is OK
[admin@MikroTik] > ping 10.123.20.1 vrf=_trusted
SEQ HOST SIZE TTL TIME STATUS
0 10.123.20.1 56 64 566us
1 10.123.20.1 56 64 666us
2 10.123.20.1 56 64 586us
3 10.123.20.1 56 64 615us
4 10.123.20.1 56 64 615us
sent=5 received=5 packet-loss=0% min-rtt=566us avg-rtt=609us max-rtt=666us

Is OK
[admin@MikroTik] > ping 10.123.20.1
SEQ HOST SIZE TTL TIME STATUS
0 no route to host
1 no route to host
2 no route to host
sent=3 received=0 packet-loss=100%

When I ping after a minute
[admin@MikroTik] > ping 10.123.20.1 vrf=_trusted
SEQ HOST SIZE TTL TIME STATUS
0 10.123.20.1 timeout
1 10.123.20.1 timeout
2 10.123.20.1 timeout
sent=3 received=0 packet-loss=100%

when I ping again in a minute
[admin@MikroTik] > ping 10.123.20.1 vrf=_trusted
SEQ HOST SIZE TTL TIME STATUS
0 10.123.20.1 timeout
sent=1 received=0 packet-loss=100%

when I ping
[admin@MikroTik] > ping 10.123.20.1 vrf=UP5
SEQ HOST SIZE TTL TIME STATUS
0 10.123.20.1 56 64 637us
1 10.123.20.1 56 64 698us
sent=2 received=2 packet-loss=0% min-rtt=637us avg-rtt=667us max-rtt=698us

and when I ping right now
[admin@MikroTik] > ping 10.123.20.1 vrf=_trusted
SEQ HOST SIZE TTL TIME STATUS
0 10.123.20.1 56 64 626us
1 10.123.20.1 56 64 664us
sent=2 received=2 packet-loss=0% min-rtt=626us avg-rtt=645us max-rtt=664us

Please help me. How to fix it ?

[CGGXANNX]

FYI, instead of the script in your screenshot, you can use this:

and the default route will also be installed correctly in the specified tables with the specified distances:

As for the issue with :ping: I could also reproduce your finding. But it appears to be only a bug in :ping not in VRF. If instead of :ping you test with /tool traceroute then the behavior should be correct and the correct routes should be used.

Using the packet sniffer, I could see that the ICMP packets are sent out through the correct interface, and the response packets also arrive correctly at the correct interface on the router. It's only the :ping tool that ignores those response packets afterwards.

Also in my tests, when the ping with @_trusted timeouts, even a ping with @main, that has a totally different default route, to a different destination, suffices for ping with @_trusted to work again right afterwards.

With /tool traceroute behaving correctly, and the packets going out and in correctly, this should be classified as a :ping bug and maybe you can report that bug to MikroTik.

[ka291]

Great. Thank you.

[fischerdouglas]

I agree with @CGGXANNX's solution!
Install the route in the tables you want, controlled directly by dhclient, and "ta-da!" Everything works!

And it's ideal for a simple scenario.

But for a slightly more complex scenario, you could have dhclient install the route only in the VRF/Routing Table it belongs to, and control the leak to other tables (including even L3VPN if you have a separate internet link on each router), using BGP.

The BGP routleak examples at Virtual Routing and Forwarding - VRF - RouterOS - MikroTik Documentation are simple but work very well.

P.S.: Both methods, having dhclient set the route or using a BGP leak, are far superior to that jerry-rig with mark-routing and mangle approach.