“A VRF is a separate routing table inside a router” is a correct definition, but it taught my team nothing. They had spent years building four separate networks, and I was asking them to merge those into one. This post is about the picture that finally worked for explaining a VRF on an SPBM fabric, the one thing I had to fix in it after I published it, and the exact spot where it makes no sense to push it any further. The story is on LinkedIn. Below, I dive further into the mechanics I didn’t have room for there.
Four networks, one rumor
Years before I joined the campus network team, an outage taught my predecessors to distrust shared infrastructure. By the time I arrived, the details survived only as rumor, but the rule survived intact: any network that needed separation got its own switches and its own fiber. Campus, wireless, voice and IoT each ran on a separate stack. That cost multiplier stayed invisible for a long time. By 2024, every MDF held up to four of them.
I don’t blame the rule. It was a sensible answer to a bad experience. It just never got re-examined, because nobody could say for sure what the bad experience had been.
Tenants and the VRF on an SPBM Fabric
Then the campus moved to an SPBM fabric: IS-IS link state in the control plane, MAC-in-MAC in the data plane. Now I had to explain one shared backbone to people who had spent years building separate ones.
The first move was easy. I called each existing air-gapped stack a tenant. Each tenant got its own Layer 3 service on its own I-SID, and the vocabulary did a lot of the work for me. The VRF was the hard part. A routing table that is logically separate but rides the same physical backbone is not an intuitive thing to hold in your head the first time.
The router analogy
I stopped trying to define a VRF and started with something every engineer in the room already trusted. A packet arrives at a router, destined for another interface on that same router. No routing protocol has to go find it. The router already knows, because the connected route is sitting in the table. (The table is there. It is the protocol that isn’t needed. I’m careful about that distinction, because someone always asks.)
A VRF that spans the fabric behaves like that one router. The edge nodes are the blades. The core nodes are the backplane. Only the edge nodes hold the tenant VRF tables. The core moves frames between the blades, but no core node makes a per-tenant routing decision. That is not the same as saying the core is passive; every node in an SPBM fabric runs SPF on the same link-state database. Nothing in the core holds a tenant VRF.
It took many whiteboard sessions, and there was no single moment where the room changed. The change was gradual. The questions got better. Which blade holds this VRF? Is the destination behind a blade that hosts it? Those questions have answers you can go and check, and once the team started asking them without me in the room, I knew the picture had done its job.
What I got wrong in the first version
In the LinkedIn post I wrote that “each switch is a blade.” A network engineer in the comments pushed back on the analogy, and the pushback was fair. The more accurate version is that the edge nodes are the blades and the core nodes are the backplane. So I now say that a VRF spans the BEBs that host it, not the whole fabric.
The same engineer offered a second picture that I like better than I expected to. A VRF does for IP routing what a VLAN does for bridging: each VRF has its own route table, the way each VLAN has its own MAC table, and how those tables get built is a separate question. That picture and mine don’t compete. Theirs explains what a VRF is. Mine explains where the tables live in an SPBM fabric.
Separation of fate, at the edge
As I remember the design intent, tenants sat on edge pairs mostly for separation of fate. Paired edges gave each MDF dual uplinks, with VRRP for gateway reachability and SMLT so that a single edge failure didn’t take the tenant down.
As of October 2026, the fabric has 6 BCBs and 14 BEBs. Many (if not most) MDF uplinks have moved to Fabric Attach since the 2024 deployment; it would be speculation on my part to turn “many” or “most” into a number. To give you a rough ballpark, there are between 90 and 100 buildings on the main campus.
Where the analogy stops
The backplane is a good place to stop the analogy. A slot in a chassis suggests hard isolation. A VRF gives you logical isolation. The picture doesn’t travel well, one step further, into “a VRF boundary is a slot boundary.” That would be promising more isolation than a VRF delivers. As the network engineer pointed out in the comments on LinkedIn, the team with the wrong picture in mind winds up troubleshooting from the wrong model, which is worse than having no model at all.
I leaned on the same backplane picture in an earlier post, where it justified keeping hosts off the core. Different argument, same rule: a model earns trust by telling you where it ends.
A fear can outlive its evidence by decades. A good mental model gives people something to reason with in its place, as long as it says out loud what it doesn’t cover. When you teach VRFs to someone who has only ever worked on a single device, what picture do you use, and where do you make yourself stop?
Leave a Reply
You must be logged in to post a comment.