Introduction
The NX-OS supports Virtual Routing and Forwarding (VRF) instances that define unique L3 routing domains. Each VRF contains its own Address Space, Unicast, and Multicast routing tables that make decisions independent from each other. The NX-OS does not allow internal route-leaking between VRF instances today. All unicast and multicast routing protocols support VRFs. When you configure a routing protocol in a VRF, you set routing parameters for the VRF that are independent of routing parameters in another VRF for the same routing protocol instance. By default, Cisco NX-OS uses the VRF of the incoming interface to select which routing table to use for a route lookup. VRFs require no license. Any feature not included in a license package is bundled with the Cisco NX-OS system images and is provided at no extra charge to you.
Cisco NX-OS can virtualize each VDC to support virtual routing and forwarding instances (VRFs). You can configure multiple VRFs in a VDC. Each VRF contains a separate address space with unicast and multicast route tables for IPv4 and IPv6 and makes routing decisions independent of any other VRF. A VRF name is local to a VDC, so you can configure two VRFs with the same name if the VRFs exist in different VDCs.
Management VRF and Default VRF
Each router has a management VRF and a default VRF:
Management VRF
- The management VRF is for management purposes only.
- Only the mgmt 0 interface can be in the management VRF.
- The mgmt 0 interface cannot be assigned to another VRF.
- The mgmt 0 interface is shared among multiple VDCs.
- No routing protocols can run in the management VRF (static only).
Default VRF
- All Layer 3 interfaces exist in the default VRF until they are assigned to another VRF.
- Routing protocols run in the default VRF context unless another VRF context is specified.
- The default VRF uses the default routing context for all show commands.
- The default VRF is similar to the global routing table concept in Cisco IOS.
Limitations for VRF
VRFs have the following configuration guidelines and limitations:
• When you make an interface a member of an existing VRF, Cisco NX-OS removes all Layer 3 configurations. You should configure all Layer 3 parameters after adding an interface to a VRF.
• You should add the mgmt0 interface to the management VRF and configure the mgmt0 IP address and other parameters after you add it to the management VRF.
• If you configure an interface for a VRF before the VRF exists, the interface is operationally down until you create the VRF.
• Cisco NX-OS creates the default and management VRFs by default. You should make the mgmt0 interface a member of the management VRF.
• The write erase boot command does not remove the management VRF configurations. You must use the write erase command and then the write erase boot command.
VRF Configuration
Create the VRF Context:
n7000(config)# vrf context Test-VRF
n7000(config-vrf)# ip ?
Assign Interfaces to the VRF:
n7000(config-router-vrf)# interface ethernet 1/13
n7000(config-if)# vrf member Test-VRF
n7000(config-if)# ip address 10.142.1.1 255.255.255.0
n7000(config-if)# interface loopback 10
n7000(config-if)# vrf member Test-VRF
n7000(config-if)# ip address 10.142.10.1 255.255.255.0
Create the VRF Routing Process:
n7000(config-vrf)# feature ospf
n7000(config)# router ospf 10
n7000(config-router)# vrf Test-VRF
n7000(config-router-vrf)# router-id 10.142.10.1
VRF Verification
Verify VRF Context:
n7000# show vrf
VRF-Name VRF-ID State Reason
Test-VRF 3 Up --
default 1 Up --
management 2 Up --
Verify VRF Interfaces:
n7000# show vrf interface
Interface VRF-Name VRF-ID
mgmt0 management 2
loopback10 Test-VRF 3
Ethernet1/1 default 1
Ethernet1/2 default 1
<Text Omitted>
Ethernet1/10 default 1
Ethernet1/11 default 1
Ethernet1/12 default 1
Ethernet1/13 Test-VRF 3
Verify VRF Routes:
n7000# show ip route vrf Test-VRF
IP Route Table for VRF "Test-VRF"
'*' denotes best ucast next-hop '**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
0.0.0.0/32, 1 ucast next-hops, 0 mcast next-hops
*via Null0, [220/0], 00:04:17, local, discard
159.142.1.0/24, 1 ucast next-hops, 0 mcast next-hops, attached
*via 159.142.1.1, Ethernet1/13, [0/0], 00:01:08, direct
159.142.1.0/32, 1 ucast next-hops, 0 mcast next-hops, attached
Related Information
PVLAN Implementation in Nexus for Traffic Management
vPC Best Practices for Nexus 7000 and 5000
