This section includes the following topics:

The following table shows the licensing requirements for this feature:

VRFs have the following configuration guidelines and limitations in a VRF-lite scenario:

• When you make an interface a member of an existing VRF, Cisco NX-OS removes all Layer 3 configuration. 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 configuration. You must use the write erase command and then the write erase boot command.

VRF-lite has the following guidelines and limitations:

• A switch with VRF-lite has a separate IP routing table for each VRF, which is separate from the global routing table.

• Because VRF-lite uses different VRF tables, the same IP addresses can be reused. Overlapped IP addresses are allowed in different VPNs.

• VRF-lite does not support all MPLS-VRF functionality; it does not support label exchange, LDP adjacency, or labeled packets.

• Multiple virtual Layer 3 interfaces can be connected to a VRF-lite switch.

• The switch supports configuring a VRF by using physical ports, VLAN SVIs, or a combination of both. The SVIs can be connected through an access port or a trunk port.

• The Layer 3 TCAM resource is shared between all VRFs. To ensure that any one VRF has sufficient CAM space, use the maximum routes command.

• The total number of routes supported by all the VRF's is limited by the size of the TCAM.

• VRF-lite supports BGP, RIP, and static routing.

• VRF-lite does not support EIGRP.

• VRF-lite does not affect the packet switching rate.

• Multicast cannot be configured on the same Layer 3 interface at the same time.

VRF route leaking has the following guidelines and limitations:

• Route leaking is supported between any two non-default VRFs. It is also supported between the default VRF and any other VRF.

• Route leaking to the default VRF is not allowed because it is the global VRF.

• You can restrict route leaking to specific routes using route map filters to match designated IP addresses.

• By default, the maximum number of IP prefixes that can be leaked is set to 1000 routes. This number can be configured to any value from 0 to 1000.

• VRF route leaking requires an Enterprise license, and BGP must be enabled.

This example shows how to configure VRF Red, add an SNMP server to that VRF, and add an instance of OSPF to VRF Red:

configure terminal
vrf context Red
snmp-server host 192.0.2.12 use-vrf Red
router ospf 201
interface ethernet 1/2
vrf member Red
ip address 192.0.2.1/16
ip router ospf 201 area 0

This example shows how to configure VRF Red and Blue, add an instance of OSPF to each VRF, and create an SNMP context for each OSPF instance in each VRF:

configure terminal
!Create the VRFs
vrf context Red
vrf context Blue
!Create the OSPF instances and associate them with each VRF
feature ospf
router ospf Lab
vrf Red
router ospf Production
vrf Blue
!Configure one interface to use ospf Lab on VRF Red
interface ethernet 1/2
vrf member Red
ip address 192.0.2.1/16
ip router ospf Lab area 0
no shutdown
!Configure another interface to use ospf Production on VRF Blue
interface ethernet 10/2
vrf member Blue
ip address 192.0.2.1/16
ip router ospf Production area 0
no shutdown
!configure the SNMP server
snmp-server user admin network-admin auth md5 nbv-12345
snmp-server community public ro
!Create the SNMP contexts for each VRF
snmp-server context lab instance Lab vrf Red
snmp-server context production instance Production vrf Blue
Use the SNMP context lab to access the OSPF-MIB values for the OSPF instance Lab in VRF Red in the previous example.

This example shows how to configure route leaking between two non-default VRF's, and from the default VRF to a non-default VRF:

feature bgp
vrf context Green
ip route 33.33.33.33/32 35.35.1.254
address-family ipv4 unicast
route-target import 3:3
route-target export 2:2
export map test
import map test
import vrf default map test
interface Ethernet1/7
vrf member Green
ip address 35.35.1.2/24
vrf context Shared
ip route 44.44.44.44/32 45.45.1.254
address-family ipv4 unicast
route-target import 1:1
route-target import 2:2
route-target export 3:3
export map test
import map test
import vrf default map test
interface Ethernet1/11
vrf member Shared
ip address 45.45.1.2/24
router bgp 100
address-family ipv4 unicast
redistribute static route-map test
vrf Green
address-family ipv4 unicast
redistribute static route-map test
vrf Shared
address-family ipv4 unicast
redistribute static route-map test
ip prefix-list test seq 5 permit 0.0.0.0/0 le 32
route-map test permit 10
match ip address prefix-list test
ip route 100.100.100.100/32 55.55.55.1
nexus# show ip route vrf all
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]

'%<string>' in via output denotes VRF <string>
55.55.55.0/24, ubest/mbest: 1/0, attached
*via 55.55.55.5, Lo0, [0/0], 00:07:59, direct
55.55.55.5/32, ubest/mbest: 1/0, attached
*via 55.55.55.5, Lo0, [0/0], 00:07:59, local
100.100.100.100/32, ubest/mbest: 1/0
*via 55.55.55.1, [1/0], 00:07:42, static
IP Route Table for VRF "management"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
0.0.0.0/0, ubest/mbest: 1/0
*via 10.29.176.1, [1/0], 12:53:54, static
10.29.176.0/24, ubest/mbest: 1/0, attached
*via 10.29.176.233, mgmt0, [0/0], 13:11:57, direct
10.29.176.233/32, ubest/mbest: 1/0, attached
*via 10.29.176.233, mgmt0, [0/0], 13:11:57, local
IP Route Table for VRF "Green"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
33.33.33.33/32, ubest/mbest: 1/0
*via 35.35.1.254, [1/0], 00:23:44, static
35.35.1.0/24, ubest/mbest: 1/0, attached
*via 35.35.1.2, Eth1/7, [0/0], 00:26:46, direct
35.35.1.2/32, ubest/mbest: 1/0, attached
*via 35.35.1.2, Eth1/7, [0/0], 00:26:46, local
44.44.44.44/32, ubest/mbest: 1/0
*via 45.45.1.254%Shared, [20/0], 00:12:08, bgp-100, external, tag 100
100.100.100.100/32, ubest/mbest: 1/0
*via 55.55.55.1%default, [20/0], 00:07:41, bgp-100, external, tag 100
IP Route Table for VRF "Shared"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
33.33.33.33/32, ubest/mbest: 1/0
*via 35.35.1.254%Green, [20/0], 00:12:34, bgp-100, external, tag 100
44.44.44.44/32, ubest/mbest: 1/0
*via 45.45.1.254, [1/0], 00:23:16, static
45.45.1.0/24, ubest/mbest: 1/0, attached
*via 45.45.1.2, Eth1/11, [0/0], 00:25:53, direct
45.45.1.2/32, ubest/mbest: 1/0, attached
*via 45.45.1.2, Eth1/11, [0/0], 00:25:53, local
100.100.100.100/32, ubest/mbest: 1/0
*via 55.55.55.1%default, [20/0], 00:07:41, bgp-100, external, tag 100
nexus(config)#

The following topics can give more information on VRFs:

• Cisco Nexus 9000 Series NX-OS Fundamentals Configuration Guide, Release 7.x

• Cisco Nexus 9000 Series NX-OS System Management Configuration Guide, Release 7.x

For additional information related to implementing virtualization, see the following sections:

• Related Documents

• Standards