I’m aware that VRF allows to have conflicting address spaces on a routers interfaces, that’s cool and all, but what if they weren’t conflicting and you just wanted to split a router so it would act like if it were two routers, each side would have its own WAN and possibly connect to a remote single address (that’s the best example I could come up with, up in a minute) but that would be no issue because each is its own, right?
Say, I have a remote gateway that routes two WANs to two tunnels down a local router. I want to load balance those two WANs but I want to do it locally, not on then remote side. I just have to map the 1-to-1 in and out. Sure it can be done easily with NAT, specially since NAT would have to happen anyway at the remote end when the traffic crosses over to the RFC1918 space. But what if I just — y’know… — wanted each side to be unaware of the other, like for reaching the public IP address an interface through the other locally? i.e; from LocalTUN-A ping RemoteWAN-B which would be forwarded to LocalTUN-B ( src:LocA→exits:RemA→dst:RemB→fwd+natto:LocB ), thus I could ping through the Internet the other local interface for…umm.. I don’t know a good reason for it, TBH, but that would be kind of cool. Can VRF be used for this?
Sounds silly but I really want to learn the possibilities; the last time I played with VRF I just locked myself out. I made this drawing to help myself explaining:
I’m also wondering what if is indeed doable, would OSPF on the router that both VRFs connect to, would somehow inform them about each other? Or would they see it as and identical OSPF …domain?— IDK ?. Although, now that I think of it, since they’d be independent, static routing could be used as well. So never mind I guess, unless you have something to add I’m happy to listen.
Yes, thats how VRF’s often are used to setup 2 or more “virtual” routers in the same box or for security reasons where you want to isolate the mgmt-interface as much as possible against the customer traffic or if you want to deal with multiple customers at once in the same box where they all will probably use the same IP-range - without VRF you would get collissions.
Note that when it comes to VRF’s regular NOS (network operating systems) such as Cisco IOS, Arista EOS, Juniper JUNOS etc use the VRF terminology for both setting up a dedicated routingtable but also to isolate physical and logical interfaces within this VRF.
When it comes to Linux (which Mikrotik is based on) things are a bit different. VRF in Linux lingo is only about a separate routingtable - the interface itself will still be able to receive and send packets for other networks so you lose the interface isolation. For that you also need something called NETNS (network namespaces) to isolate the interface the same way as VRF also does on regular NOSes.
I think Mikrotik behaves like a regular NOS that is VRF in Mikrotik is both a separate routingtable AND isolation of the interface to only be able to talk to other interfaces who are part of the same VRF.
Note however that VRF support for various services and features in Mikrotik is currently somewhat broken. For example the /ip/dns doesnt behave correctly even if a “vrf=” syntax was added to it in 7.15 stable, same with logging who cannot send logs to a syslog server on any other vrf than the vrf=main and so on. So it should work in your case with routing protocols but dont count on it when it comes to Mikrotik (test before you buy).
VRF-aware services in RouterOS is still under implementation. Even Cisco IOS took a while to make all system services VRF-aware.
But in the most cases you run your management & monitoring in the “main” table, and customers in individual tables. Then it’s no issue that syslog or dns isn’t VRF-aware.
I guess that Mikrotik has very different customer-base. I’m guessing that the majority of customers requests is about cheaper boxes, faster wifi, pppoe-stuff, different variants of vpn, etc. etc. Cisco and Arista is Enterprise customers only.
Linux got real VRF support in about 4.3 i think (2015-2016). Before that it had to be some proprietary solution.
