Dell OS10 VRF Configuration and Verification Guide

Dell SmartFabric OS10 supports full VRF (virtual routing and forwarding) instances, but the feature is often skipped because the management VRF is enabled by default and covers the most obvious use case. Once you need overlapping address space, tenant separation or a management plane that survives a data-plane outage, you need non-default VRFs. This guide walks through creating a VRF, attaching interfaces, running a routing protocol inside it, leaking a specific prefix on purpose, and verifying that the separation actually holds. Every command below is OS10 syntax and can be pasted into a non-transaction-based configuration session.

What a VRF actually isolates on OS10

A VRF creates a separate routing table, a separate set of interface bindings and a separate FIB entry space. Interfaces that are not explicitly bound to a VRF stay in the default VRF. Because the tables are independent, the same prefix (for example 10.0.0.0/16) can exist in two VRFs with different next hops. Management VRF (ip vrf management) is a special non-deletable instance used to keep the management port out of the global table.

If you are coming from Cisco, the concept maps one-to-one to the "VRF-Lite" pattern where each VRF gets its own routing protocol process — see Cisco IOS VRF-Lite configuration for the equivalent workflow.

Prerequisites and syntax note

OS10# configure terminal
OS10(config)# ip vrf BLUE          ! create / enter VRF context
OS10(config-vrf)# exit
OS10(config)# show ip vrf

Always work in non-transaction-based mode when touching the management VRF; transaction-based mode buffers configuration and can briefly remove the management address, which locks you out of the switch. For a full revert workflow see OS10 factory reset and default gateway recovery.

Step 1 — Create the VRF and bind interfaces

OS10(config)# ip vrf BLUE
OS10(config-vrf)# description Tenant-Blue
OS10(config-vrf)# exit

OS10(config)# interface ethernet 1/1/10
OS10(config-if)# description BLUE-uplink
OS10(config-if)# no switchport
OS10(config-if)# ip vrf forwarding BLUE
OS10(config-if)# ip address 172.16.10.1/30
OS10(config-if)# no shutdown

ip vrf forwarding must be applied before the IP address, because binding an interface to a VRF removes any address already configured on it. This ordering trap is the single most common reason an interface comes up with no L3 connectivity after a VRF rollout.

Step 2 — Static routing inside the VRF

OS10(config)# ip route vrf BLUE 10.200.0.0/24 172.16.10.2
OS10(config)# show ip route vrf BLUE

Note the vrf BLUE keyword position: in OS10 the VRF goes immediately after the command family, not at the end. Getting this wrong returns a syntax error rather than a silent misconfiguration, so it is easy to catch.

Step 3 — A routing protocol per VRF (BGP example)

OS10(config)# router bgp 65010
OS10(config-router-bgp)# vrf BLUE
OS10(config-router-bgp-vrf)# router-id 10.10.10.1
OS10(config-router-bgp-vrf)# address-family ipv4 unicast
OS10(config-router-bgp-af)# neighbor 172.16.10.2 remote-as 65020
OS10(config-router-bgp-af)# neighbor 172.16.10.2 activate
OS10(config-router-bgp-af)# exit-address-family

BGP import into the VRF RIB requires the route to be selected in the VRF context — checking show ip bgp vrf BLUE summary before blaming the peer saves a lot of time. A complete BGP build-up and verification sequence is documented in Dell OS10 BGP configuration.

Step 4 — Controlled route leaking

There is no blanket import between VRFs. Two supported patterns exist:

! (a) static leak: a host route in the default VRF pointing at a VRF interface
OS10(config)# ip route 10.10.10.50/32 172.16.10.1 vrf BLUE

! (b) targeted redistribution with a route map (recommended)
OS10(config)# ip prefix-list LEAK-TO-DEFAULT seq 10 permit 10.10.10.0/24
OS10(config)# route-map LEAK permit 10
OS10(config-route-map)# match ip address prefix-list LEAK-TO-DEFAULT
OS10(config-route-map)# set tag 500
OS10(config-route-map)# exit

Filtering on a prefix list rather than "leak everything" keeps the default table free of tenant routes and prevents accidental transit. Route-map mechanics are covered in OS10 route map configuration.

Verification commands that actually prove separation

show ip vrf                         ! instances + bound interfaces
show ip interface                   ! per-interface VRF membership
show ip route vrf BLUE              ! BLUE RIB only
show ip route vrf management        ! management table only
show ip bgp vrf BLUE summary        ! protocol up inside the VRF
show ip arp vrf BLUE                ! ARP table scope
ping vrf BLUE 172.16.10.2
traceroute vrf BLUE 10.200.0.1

ping and traceroute both need the vrf keyword; a plain ping from the default VRF to a BLUE-only address should fail, and that failure is itself the proof that isolation is real.

Troubleshooting checklist

Symptom                              Check
Interface up but no ARP              ip vrf forwarding applied before ip address?
BGP neighbor Idle                    neighbor under the correct vrf/address-family?
Route missing from VRF RIB           route present in RIB but not selected (next-hop?)
Management unreachable after change  were you in transaction-based mode?
Ping works, app does not             is the app source interface in the right VRF?

FAQ

Q: Can I delete the management VRF? No — it is reserved. You can remove interfaces from it and re-add them to the default VRF.
Q: How many VRFs does OS10 support? Platform dependent; S5200/S4100 series support a limited hardware VRF count (typically 64), so check the release notes before designing per-tenant VRFs at scale.
Q: Does VXLAN EVPN use VRFs? Yes — per-tenant VRFs are the standard model, with route leaking handled by EVPN symmetric IRB instead of static leaks.

原文链接：https://www.dell.com/support/manuals/en-us/dell-emc-smartfabric-os10/smartfabric-os-user-guide-10-5-3/vrf-configuration