<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>VRF on Personal blog of Anurag Bhatia</title>
    <link>https://anuragbhatia.com/tags/vrf/</link>
    <description>Recent content in VRF on Personal blog of Anurag Bhatia</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Tue, 04 Aug 2026 02:28:23 +0530</lastBuildDate><atom:link href="https://anuragbhatia.com/tags/vrf/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Use of VRF in dual WAN setup</title>
      <link>https://anuragbhatia.com/post/2026/08/mikrotik-vrf-dual-wan/</link>
      <pubDate>Tue, 04 Aug 2026 02:28:23 +0530</pubDate>
      
      <guid>https://anuragbhatia.com/post/2026/08/mikrotik-vrf-dual-wan/</guid>
      <description>&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Issues with the setup:&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;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.&lt;/li&gt;
&lt;li&gt;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) &amp;amp; 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 &amp;amp; thus blackholed.&lt;/li&gt;
&lt;li&gt;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 &lt;a href=&#34;https://github.com/prometheus/blackbox_exporter&#34;&gt;blackbox exporter&lt;/a&gt; behind a specific ISP as well as &lt;a href=&#34;https://github.com/Jamesits/docker-ripe-atlas&#34;&gt;RIPE Atlas&lt;/a&gt;. I don&amp;rsquo;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.&lt;/li&gt;
&lt;/ol&gt;
&lt;br /&gt;
&lt;h3 id=&#34;old-setup&#34;&gt;Old Setup&lt;/h3&gt;
&lt;p&gt;My old setup was running multiple routing table pairs:&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;ISP1 only &amp;amp; ISP1 as primary (ISP2 as secondary)&lt;/li&gt;
&lt;li&gt;ISP2 only &amp;amp; ISP2 as primary (ISP1 as secondary)&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;All WAN interfaces, LAN interfaces and routing tables were in the same single &amp;ldquo;Main&amp;rdquo; 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 &lt;a href=&#34;https://anuragbhatia.com/post/2025/01/event-driven-automation-with-prometheus/&#34;&gt;this post&lt;/a&gt; last year.&lt;/p&gt;
&lt;br /&gt;
&lt;h3 id=&#34;understanding-vrf&#34;&gt;Understanding VRF&lt;/h3&gt;
&lt;p&gt;VRF is Virtual Routing and Forwarding. It allows &amp;ldquo;virtual partitioning&amp;rdquo; of the router in L3 terms. Different physical &amp;amp; VLAN interfaces can be part of different VRFs, and they have no connectivity with each other at all unless routes are leaking between the VRFs. Thus a router with VRF - Main, ISP1 &amp;amp; ISP2 acts like three separate routers. It&amp;rsquo;s like a VLAN for layer3. In Mikrotik it can get confusing as one can create multiple isolated routing tables in the same Main VRF however since WAN interfaces are also in the same main VRF, the default route from the main table takes out if a next-hop becomes unavailable on an interface.&lt;/p&gt;
&lt;br /&gt;
&lt;h3 id=&#34;new-setup&#34;&gt;New Setup&lt;/h3&gt;
&lt;p&gt;With three VRFs in place (default + 2 other), I have isolated each uplink in its own VRF. Also, removed the ISP1-only &amp;amp; ISP2-only routing tables, as VRF creates its own isolated table. Most of the policy-routing logic remains unchanged. Mangle does the marking of routing to steer traffic &amp;amp; mangle rules for an address list where IPs are enabled or disabled from external tooling based on how I want to route the traffic. Every WAN-facing route now belongs to the corresponding VRF instead of the Main routing domain. And since these act like separate routers, I had to add a path for the return route as well. So e.g if 172.16.0.0/24 on say VLAN10 (in Main VRF) communicates via VRF-ISP2 via mangle-marked routing, the VRF-ISP2 routing table needed an interface route to return the traffic. For VLANs specific to these ISPs, I added them in the respective ISP VRF. These VLANs are also trunked to my home server, where they map directly onto Docker networks, allowing selected containers to live natively inside a specific ISP VRF&lt;/p&gt;
&lt;p&gt;In hindsight, I should have switched to VRFs much earlier. Multiple routing tables worked for a long time, but they started showing their limits as the network became more complex. VRFs make the separation explicit, and the router behaves much closer to how I actually expect it to.&lt;/p&gt;
</description>
    </item>
    
  </channel>
</rss>