Simple GNS3 CHR test:
ether1 to PC1
ether2 to PC2
ether1 10.20.10.1/24
ether2 10.20.20.1/24
vrf a ether1
vrf b ether2
Why PC1, that is in vrf a, can ping 10.20.20.1 - interface ether2 on MikroTik that is in vrf b ?
PC1 cant ping PC2 - that is OK, but why can it ping that ether1 IP address???
Can someone explain it.
Multihomed IP device does not need any routing to access the other interface IP addresses of that device. It’s like a loopback (interface) address, as long as the request gets to the device it will respond with that loopback address.
This is true when you are in a single VRF (main) context but it is not expected to behave like this in a multi VRF environment. Mikrotik has not a fully functioning VRF implementation like other vendors have. Hopefully this gets corrected in v7.
Current RouteOS VRF implementation is not true VRF but more “VRF-like” policy routing.
RouterOS uses standard Linux ip routing tables and provides ‘VRF Lite’. This is simply due to all local addresses being added to a default table (255) and there being a default routing rule (0) which references this table ahead of any that are custom added (defining a RouterOS VRF).
You can see this behaviour by connecting to any Linux system and running:
[admin@rhel6 ~]# ip rule list
0: from all lookup 255
32766: from all lookup main
32767: from all lookup default
[admin@rhel6 ~]# ip route show table 255
broadcast 192.168.1.0 dev eth0 proto kernel scope link src 192.168.1.3
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
local 192.168.1.3 dev eth0 proto kernel scope host src 192.168.1.3
broadcast 192.168.1.255 dev eth0 proto kernel scope link src 192.168.1.3
broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
Any IP, broadcast or loop back subnet is automatically present in table 255.