Glossary

VRF

Virtual Routing and Forwarding

What is VRF

VRF (Virtual Routing and Forwarding), also known as a VPN instance, is a way of logically dividing a single physical device into multiple independent virtual routers. Each VRF instance behaves like a separate device, with its own routing table, its own routing process, and its own set of assigned interfaces — even though they're all running on the same physical hardware.

That logical separation is what makes VRF useful: it lets one physical device carry completely isolated data or services for different tenants, departments, or customers. In MPLS VPN deployments, for example, VRF is what lets a single provider-edge device serve multiple customers at once — each customer's routes live in a separate VRF, so their traffic stays isolated even if two customers happen to use the exact same private IP address range.

How VRF Works

A single physical device can maintain multiple VRFs simultaneously, and each one is really a self-contained virtual router: its own routing table, the specific interfaces assigned to it, and the routing rules that apply only within it. Traffic and routes in one VRF are invisible to every other VRF by default — there's no overlap, no shared table, and no risk of one tenant's routes conflicting with another's.

Building a working VRF deployment comes down to a few steps. First, a VRF instance is created and given a name. Interfaces — VLAN, Ethernet, LAG, sub-interface, loopback, or management — are then bound to a specific VRF, which is what actually determines which traffic belongs to which isolated routing domain; this is commonly used to assign different users or departments to different VRFs, directly solving the problem of overlapping address spaces and conflicting local routes on a shared device.

Because VRFs are isolated by design, communication between them doesn't happen automatically — if two VRFs genuinely need to reach each other, an explicit inter-VRF route has to be configured, specifying both which VRF the route belongs to and which VRF its next hop lives in. Without that explicit route, VRFs stay exactly as isolated as intended.

Why VRF is Beneficial

  • True routing isolation on shared hardware: Multiple independent routing domains coexist on a single device without any risk of route leakage or address conflict between them.

  • Solves IP overlap without renumbering: Departments, tenants, or customers can use the exact same private address ranges as each other, because their routing tables are completely separate.

  • Enables secure multi-tenancy: A service provider can serve many customers from one physical device while guaranteeing that each customer's traffic and routes stay invisible to every other customer.

  • Interconnection stays deliberate, not accidental: Because inter-VRF communication requires an explicit route, isolation is the default state — connectivity between VRFs only happens when someone configures it on purpose.

  • Reduces physical infrastructure needs: Instead of deploying separate physical routers per tenant or department, VRF delivers the same isolation guarantees on infrastructure that's already there.

At Asteraix

What We Can Do at Asteraix

AsterNOS implements VRF as a first-class CLI construct, making multi-tenant routing isolation straightforward to configure and verify.

  • Simple VRF creation and naming: vrf <vrf-name> creates a new VRF instance directly from global configuration, with names allowed to use letters, numbers, and ., _, - characters — flexible enough to match whatever naming convention an operator's network already uses.

  • Safeguards against accidental deletion: AsterNOS won't delete a VRF that still has interfaces bound to it, or one that has a VNI configured — protecting against a misconfiguration that could silently break routing for an entire department or tenant.

  • Broad interface-type support: VRF binding works across VLAN, Ethernet, link-aggregation, sub-interface, loopback, and management interfaces, so the same isolation model applies consistently regardless of how a given interface is built.

  • Explicit, controllable inter-VRF routing: ip route <destination> <next-hop> [nexthop-vrf <vrfname>] lets operators configure exactly which routes are allowed to cross VRF boundaries, and where their next hop lives — keeping cross-VRF connectivity fully intentional and auditable.

  • Per-VRF MAC configuration: mac <HH:HH:HH:HH:HH:HH> lets operators assign a specific MAC address to a VRF instance directly, useful for deployments with strict addressing requirements across virtual routing domains.

  • Straightforward verification: show vrf brief and show vrf interface give operators an immediate view of configured VRFs and exactly which interfaces are bound to each one — the fastest way to confirm a multi-tenant isolation design is actually behaving as configured.