# VRF

Published articles for VRF.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## Use of VRF in dual WAN setup

DevFeed: [Use of VRF in dual WAN setup](<https://devfeed.tech/articles/use-of-vrf-in-dual-wan-setup-39784.md>)

Original publisher: [Read original article](<https://anuragbhatia.com/post/2026/08/mikrotik-vrf-dual-wan/>)

Published: 2026-08-03T20:58:23Z

Content type: tutorial

Language: en

Sources: [Personal blog of Anurag Bhatia](<https://devfeed.tech/sources/personal-blog-of-anurag-bhatia.md>)

Topics: [networking](<https://devfeed.tech/topics/networking.md>), [MikroTik](<https://devfeed.tech/topics/mikrotik.md>), [Prometheus](<https://devfeed.tech/topics/prometheus.md>), [Containers](<https://devfeed.tech/topics/containers.md>)

Tags: [containers](<https://devfeed.tech/tags/containers.md>), [mikrotik](<https://devfeed.tech/tags/mikrotik.md>), [prometheus](<https://devfeed.tech/tags/prometheus.md>), [router](<https://devfeed.tech/tags/router.md>), [routing](<https://devfeed.tech/tags/routing.md>), [routing-table](<https://devfeed.tech/tags/routing-table.md>), [vrf](<https://devfeed.tech/tags/vrf.md>)

### AI overview

This article describes migrating a MikroTik home router from multiple routing tables to a VRF-based dual-WAN design. It explains how shared routing domains caused router-bound traffic to return through the wrong ISP during partial outages and made ISP-specific routing for measurement containers difficult. VRFs provide separate layer-3 routing domains for the WAN links, while Prometheus and Semaphore handle packet-loss-based switchover.

### Source excerpt

Over the weekend I migrated my home router from multiple routing tables to a VRF-based design, placing each WAN uplink into its own VRF. While multiple routing tables worked for basic policy routing, they have some limitations and that led to several edge cases that became increasingly difficult to work around. Issues with the setup: If the active default route pointed to ISP1, traffic arriving on ISP1 naturally returned via ISP1. However, traffic terminating on the router and arriving via ISP2 would also be replied to through ISP1, since both uplinks still shared the same routing domain. This did not cause issues for traffic on devices below the router but was bad for traffic terminating on the router interface itself. Due to the above reason, I recently lost access to my home router while I was out of the country because ISP1 had a partial outage (their transit went down, peering stayed up) & due to distributed tooling, the auto switch trigger could not happen either to take care of it. Packets from ISP 2 were being returned via the ISP1 route & thus blackholed. I have a special case where I want most of the devices on a redundant setup but some devices (containers) on specific ISP only. These are measurement containers running blackbox exporter behind a specific ISP as well as RIPE Atlas. I don't want these to switch over for accuracy of measurement. Without VRF it was ugly config-wise, as ISP1 failure will lead to ISP2 routing even when the specific routing table did not have that route. Old Setup My old setup was running multiple routing table pairs: ISP1 only & ISP1 as primary (ISP2 as secondary) ISP2 only & ISP2 as primary (ISP1 as secondary) All WAN interfaces, LAN interfaces and routing tables were in the same single "Main" VRF. This by default takes care of full outage events, fibre cuts, etc. For packet loss-based switchover, I have set up Prometheus + Semaphore as covered in this post last year. Understanding VRF VRF is Virtual Routing and Forwarding. It