Do Enterprises Need VRFs?

One of my readers sent me a long of questions titled “Do enterprise customers REALLY need VRFs?

The only answer I could give is “it depends” (it’s like asking “Do animals need wings?”), and here’s my attempt at building a decision tree:

You can use the decision tree to figure out whether you need VRFs in your data center or in your enterprise WAN.

Do you have multiple security zones or tenants (organizations)?

No: You don’t need VRFs

You might have to treat the guest VLAN as a separate tenant whose traffic has to be pulled back to the central firewall.

Yes:

Do you plan to span these zones across multiple sites (or data centers)?

Yes: I would use VRFs. You might want to use stretched VLANs, and I wish you luck.

No:

Will you implement tenants or security zones with multiple segments or distributed firewalls (also marketed as microsegmentation)?

Distributed firewalls: You might think you don’t need VRFs, but maybe you still do unless all hosts use the same exit from the subnet. If the hosts from different security zones (or tenants) need different exit points (aka service insertion), you’re better off using different routing domains for them.

Different tenants or security zones might use different load balancers, in which case you’d need either multiple segments (or routing domains) or source NAT on the load balancer to ensure symmetrical traffic flow.

Multiple segments:

Do you need a separate routing domain for each security zone or tenant within a site?

No: You don’t need VRFs, VLANs are good enough.

Yes: You probably need VRFs.

More on separate routing domains

You might be wondering whether you need a routing domain for a tenant or security zone, or whether a simple VLAN would be good enough. The only answer I can give for a multi-tenant setup is “it depends” (on your service definition), but there’s an easy answer for security zones.

  • If it’s OK that all traffic exiting a security zone passes through a firewall (or load balancer) that serves as the default gateway, then you don’t need a routing domain (and VRF) for the security zone.
  • If you want to split traffic based on destinations and send it to multiple exit points (next hops) then it’s better to implement a security zone as a routing domain instead of configuring static routes on all hosts.

Need an example for the second scenario? How about network-based backup – do you really want to pump all backup traffic through an expensive firewall?

5 comments:

  1. We have three different zones. External datacenter networks, internal datacenter networks, office networks. Some sites have all three of them. We use different VRFs for that, exactly because we don't want to use stretched VLANs, and use RIP on VMs to announce their location for VM mobility. And firewalls with interfaces in all three VRFs for inter-VRF traffic.

    Can't say it's simple but it works with less headaches than one routing domain.
  2. Couple of clarifications.

    1) Why would some one need separate routing domain for each security or tenant within a site unless they use same subnets ?.

    2) Are these decision tree applicable to micro-segmentation ?.
    Replies
    1. #1 - Reread the last section
      #2 - Yes. Microsegmentation is a marketing name for distributed firewalls. Added to the tree.
  3. Hi Ivan.

    You provided network based backups as an example to route based on destination ip. Is not simple PBR good enough rather than complicated VRFs ?
    Replies
    1. That's a personal preference. You call PBR simple, I consider VRFs simpler than distributed PBR, which you'd have to have in virtualized environments with VM mobility.

      Also, in your case you'd need devices that allow you to configure PBR on L2-only interfaces (or you'd be back in VRF world).
Add comment
Sidebar