Catalyst 4500 Series Switch Software Configuration Guide, IOS XE 3.9.xE and IOS 15.2(5)Ex

Virtual Network Tags Provide Path Isolation

It is not uncommon to have different user groups running on the same IP infrastructure. Various business reasons require traffic isolation between different groups. The figure below shows two user groups, Red and Green, running on the same network. Prior to network virtualization, there is no separation of traffic between the two groups. Users in the Red user group can access the server in the Green user group, and vice versa.

Without network virtualization, path isolation can be achieved by using access control, which is expensive to maintain, prone to error and does not support unique routing and forwarding tables per network

Figure 83-1 Network without Virtualization

Virtual networks provide a coarse-grained segmentation of different user groups on one physical network. By configuring virtual networks, you can virtualize a single IP infrastructure to provide a number of virtual networks end to end. In the figure below, a single IP infrastructure is virtualized into two VPNs by creating two VRFs, Red and Green.

Figure 83-2 Network with Virtualization

In addition to utilizing VRFs to provide device-level separation, each virtual network has path isolation from the other. Path isolation is achieved by tagging the traffic so it carries the same tag value throughout the same virtual network. Each network device along the path uses the tags to provide separation among different VRFs. A single tag number ties VRF red, for example, on one device to VRF red on another device.

Virtual Network Tags

Each VPN and associated EVN has a tag value that you assign during configuration. The tag value is global, meaning that on each device, the same EVN must be assigned the same numerical tag value. Tag values range from 2 to 4094.

An EVN is allowed on any interface that supports 802.1q encapsulation, such as Fast Ethernet, Gigabit Ethernet, and port channels. To allow for backward compatibility with the VRF-Lite solution, the vLAN ID field in the 802.1q frame is used to carry the virtual network tag.

Traffic that carries a virtual network tag is called tagged traffic. Traffic that does not carry a virtual network tag is called untagged traffic.

Tags are illustrated in the following configuration with two VRFs, red and green:

A virtual network is defined as a VRF instance with a virtual network tag assigned.

vnet Global

A predefined EVN known as vnet global is on the device. It refers to the global routing context and it corresponds to the default RIB. In figure 2 and figure 3, vnet global is represented by a black line connecting devices. The vnet global carries untagged traffic. By default, interfaces belong to the vnet global. Furthermore, vnet global is always running on trunk interfaces. The vnet global is also known as the default routing table.

Note IPv6 traffic is supported in vnet global only.

Edge Interfaces and EVN Trunk Interfaces

User devices are connected to a Layer 2 switch port, which is assigned to a VLAN. A VLAN can be thought of as a Layer 2 VPN. Customers will group all of the devices that need to be supported in a common Layer 3 VPN in a single VLAN. The point where data traffic is handed off between a VLAN and VRF is called an edge interface.

An edge interface connects a user device to the EVN and in effect defines the boundary of the EVN. Edge interfaces connect end devices such as hosts and servers that are not VRF-aware. Traffic carried over the edge interface is untagged. The edge interface classifies which EVN the received traffic belongs to. Each edge interface is configured to belong to only one EVN.

An EVN trunk interface connects VRF-aware devices together and provides the core with a means to transport traffic for multiple EVNs. Trunk interfaces carry tagged traffic. The tag is used to de-multiplex the packet into the corresponding EVN. A trunk interface has one subinterface for each EVN.

The vnet trunk command is used to define an interface as an EVN trunk interface.

An EVN interface uses two types of interfaces: edge interfaces and trunk interfaces. An interface can be an edge or trunk interface, but not both. Figure 3 illustrates devices A and D, which have edge interfaces that belong to VRF Red. Devices D and E have edge interfaces that belong to VRF Green.

Devices B, C, D, F, and G have trunk interfaces that make up the EVN core. These five devices have interfaces that belong to both VRF Red and VRF Green.

Figure 83-3 EVN Edge and EVN Trunk Interfaces

Identifying Trunk Interfaces in Display Output

Because a trunk interface carries multiple EVNs, sometimes it is not sufficient to display only the trunk interface name. When it is necessary to indicate that display output pertains to a particular EVN running on the trunk interface, the convention used is append a period and the virtual network tag, making the format interface.virtual-network-tag. Examples are gigabitethernet1/1/1.101 and gigabitethernet1/1/1.102.

By default, when a trunk interface is configured, all of the EVNs and associated virtual network tags are configured, and a virtual network subinterface is automatically created. As stated above, a period and the virtual network tag number are appended to the interface number.

In the following example, VRF red is defined with virtual network tag 3. Hence, the system created Fast Ethernet 0/0/0.3 (in VRF red).

You can display this hidden interface with the show derived-config command and see that all of the commands entered on Fast Ethernet 0/0/0 have been inherited by Fast Ethernet 0/0/0.3:

Single IP Address on Trunk Interfaces

A trunk interface can carry traffic for multiple EVNs. To simplify the configuration process, all the subinterfaces and associated EVNs have the same IP address assigned. In other words, a trunk interface is identified by the same IP address in different EVN contexts. This is because each EVN has a unique routing and forwarding table, thereby enabling support for overlapping IP addresses across multiple EVNs.

Relationship Between VRFs Defined and VRFs Running on a Trunk Interface

By default, the trunk interfaces on a router will carry traffic for all VRFs defined by the vrf definition command. For example, in the following configuration, every VRF defined on the router is included on the interface:

interface FastEthernet 1/0/0 vnet trunk ip address 10.1.1.1 255.255.255.0

However, you might want to enable only a subset of VRFs over a certain trunk interface for traffic separation purposes. This is achieved by creating a VRF list, which is referenced in the vnet trunk command. When a trunk interface is enabled with a VRF list, only VRFs on the list are enabled on the interface. The exception is that vnet global is always enabled on the trunk interface.

In the following example, only the two specified VRFs on the list (red and green) are enabled on the interface:

VRF Awareness

A device connected to a virtual network may not understand virtual network tags and can send and receive only untagged traffic. Such a device is referred to as VRF unaware. For example, a laptop computer is usually VRF unaware.

By contrast, a device that can send and receive tagged traffic and therefore takes the tag value into account when processing such traffic is known as VRF aware. For example, a VRF-aware server shared among different EVNs could use the virtual network tag to distinguish requests received and send responses. A VRF-aware device is connected to the EVN using a trunk interface, as shown in figure 4.

Figure 83-4 VRF Aware Server

The term “VRF aware” can also be used to describe a software component running on the device. A software component is VRF aware if it can operate on different EVNs. For example, ping is VRF aware because it allows you to choose the EVN to which you want to send the ping packet.

Routing Protocols Supported by EVN

Each EVN runs a separate instance of a routing protocol. This allows each EVN to fine-tune its routing separately and also limits fate sharing. Different virtual networks may run different routing protocols concurrently.

EVN supports static routes, OSPFv2, and PIM, MSDP, and IGMP for multicast routing.

Packet Flow in a Virtual Network

Packets enter an EVN through an edge interface, traverse multiple trunk interfaces, and exit the virtual network through another edge interface. At the ingress edge interface, packets are mapped from a VLAN into a particular EVN. Once the packet is mapped to an EVN, it is tagged with the associated virtual network tag. The virtual network tag allows the trunk interface to carry packets for multiple EVNs. The packets remain tagged until they exit the EVN through the egress edge interface.

On the edge interface, the EVN associated with the interface is used for route lookup. On the trunk interface, the virtual network tag carried in the packet is used to locate the corresponding EVN for routing the packets.

If the egress interface is an edge interface, the packet is forwarded untagged. However, if the egress interface is a trunk interface, the packet is forwarded with the tag of the ingress EVN.

The figure below illustrates how traffic from two VRFs, red and green, can coexist on the same IP infrastructure, using the tags 101 and 102.

Figure 83-5 Packet Flow in a Virtual Network

The packet flow from Laptop 1 to Server 1 in VRF red occurs as follows:

1. Laptop 1 send an untagged packet to Server 1.

2. Device A receives the packet over an edge interface, which is associated with VRF red.

a. Device A does route lookup in VRF red and sees that the next hop is Device B through a trunk interface.

b. Device A encapsulates the packet with VRF red’s tag (101) and sends it over the trunk interface.

3. Device B receives the packet over a trunk interface. Seeing virtual network tag 101, Device B identifies that the packet belongs to VRF red.

a. Device B does route lookup in VRF red and sees that the next hop is Device C through a trunk interface.

b. Device B encapsulates the packet with VRF red’s tag (101) and sends it over the trunk interface.

4. Device C receives the packet over a trunk interface. Using virtual network tag 101, Device C identifies that the packet belongs to VRF red.

a. Device C does route lookup in VRF red and sees that the next hop is Device D through a trunk interface.

b. Device C encapsulates the packet with VRF red’s tag (101) and sends it over the trunk interface.

5. Device D receives the packet over a trunk interface. Using virtual network tag 101, Device D identifies that the packet belongs to VRF red.

a. Device D does route lookup in VRF red and sees that the next hop is through an edge interface.

b. Device D sends the untagged packet over the edge interface to Server 1.

6. Server 1 receives the untagged packet originated from Laptop 1.

Command Inheritance on EVN Trunk Interfaces

One of the benefits of EVN is the ability to easily configure multiple EVNs on a common trunk interface without the need to configure each interface associated with an EVN individually. An EVN trunk interface takes advantage of the fact that the configuration requirements for different EVNs will be similar over a single trunk interface. When specific commands are configured on the trunk interface, they define default values that are inherited by all EVNs running over the same interface, including vnet global. If you feel that the settings are acceptable for all of the EVNs sharing an interface, then no individual configuration is necessary.

For example, the OSPF hello interval can be set for all EVNs over the trunk interface with the following configuration:

Overriding Command Inheritance Virtual Network Interface Mode

You can set up EVNs on the same trunk interface to have different configurations, by override inherited values using specific commands in virtual network interface mode for individual EVNs. In this mode, the command’s settings override the Cisco default value or the value you set in interface configuration mode.

In interface configuration mode, entering the vnet name command causes the system to enter virtual network interface mode.

Beginning in Cisco IOS XE Release 3.9.1E, you can override the inherited IP address for subinterfaces. For more information, see Changing the Inherited IP Address for Subinterfaces.

The following list displays the commands for which inherited values can be overridden:

Removing Overrides and Restoring Values Inherited from EVN Trunk

The no and default keywords result in different outcomes, depending on whether they are used for a trunk interface or in virtual network interface mode. This section describes the different outcomes.

When the no or default keyword is entered before a command on a trunk interface, the trunk is restored to the system’s default value for that command. (This is standard behavior resulting for the no or default keyword).

When the default keyword is entered before a command in virtual network interface mode, the override value is removed and the value that is inherited from the trunk is restored. The override value for the specific EVN is no longer in effect.

In the following example, the trunk interface is configured with an OSPF cost of 20, but VRF blue overrides that value with an OSPF cost of 30:

When the following commands are entered, the OSPF cost value is restored to 20, which is the cost inherited from the trunk interface. (Note that 20 is not the default value of the ip ospf cost command.)

Determining if No Form of Commands Appear in Configuration Files

If a command switches a feature on or off, the no form of the command appears in the configuration file when configured. Nonvolatile generation (NVGEN) overrides the setting from the EVN trunk, as shown in the following example:

If a command takes an argument in its syntax, such as ip ospf cost cost, the no form of the command will remove the configuration, but does not appear in the configuration file. That is, it will not be NVGEN’ed because the user could enter ip ospf cost default-value to override the inherited value.

EVN Compatibility with VRF-Lite

EVN is wire compatible with VRF-Lite. In other words, on the outside, 802.1q, SNMP MIBs, and all the EVN infrastructure will look exactly the same as VRF-Lite.

In the figure below, both devices have VRFs defined. The device on the left uses VRF-Lite, and the device on the right uses an EVN trunk with tags. The two configurations follow the figure.

Example: VRF-Lite Subinterface Configuration EVN Trunk Configuration

SQoS and EVN

Quality of Service (QoS) configurations are applied to the main physical interface on an EVN trunk. The QoS policy affects all traffic that flows out the physical interface in all the VRFs at the same time. In other words, QoS and network virtualization are mutually independent. For example, traffic marked with the DSCP value specified for voice will be put into the voice queue if the packet is from the red VRF, blue VRF, or green VRF. The traffic for all the VRFs is queued together.

Enabling a Subset of VRFs over a Trunk Interface

To create a VRF list and enable only a subset of VRFs over a trunk interface, enter the following commands:

Note This task presumes that the VRF has already been configured.

Configuring EVN Edge Interfaces

Perform this task to configure an edge interface, which connects a user device to a virtual network. Traffic carried over an edge interface is untagged. The edge interface determines which virtual network the received traffic belongs to. Each edge interface is mapped to only one virtual network.

Verifying EVN Configuration

Enter the following commands to verify your configuration. All the existing VRF show commands are supported in virtual networks. If a device has a mix of VRFs and virtual networks, the various show vrf commands will include both VRFs and virtual networks in the output.

Changing the Inherited IP Address for Subinterfaces

All subinterfaces created on the vnet interface inherit values from the main interface.

Beginning in Cisco IOS XE Release 3.9.1E, you can change the inherited IP address for subinterfaces in interface vnet configuration mode:

For example, consider the following configuration:

Example: Virtual Networks Using OSPF with network Commands

In this example, network commands associate a shared VRF interface with a base VRF and two named VRFs, red and blue. There are three OSPF instances because each VRF needs its own OSPF instance. OSPF 1 has no VRF, so it is vnet global.

Example: Virtual Networks Using OSPF with ip ospf vnet area Command

This example differs from the prior example regarding the association between OSPF instances and a particular interface. In this example, OSPF is running on all of the virtual networks of a trunk interface. The ip ospf vnet area command associates the GigabitEthernet 0/0/0 interface with the three OSPF instances.

Example: Overriding Command Inheritance

In the following example, the OSPF cost of 30 for VRF blue overrides the OSPF cost of 20 for the other VRFs on the interface:

The show derived command indicates the subinterface changed to a cost of 30:

Example: Enabling an Attribute to vnet Global Only

Similarly, you might want to enable an attribute to vnet global only. To do so, use the vnet global interface submode, as follows:

Example: Command Inheritance and Virtual Network Interface Mode Override in a Multicast Environment

The following example illustrates command inheritance and virtual network interface mode override in a multicast network. A trunk interface leverages the fact that configuration requirements from different VRFs will be similar over the same trunk interface. Eligible commands configured on the trunk interface are inherited by all VRFs running over the same interface.

In this example, IP multicast (PIM sparse mode) is configured on the trunk interface, which has several VRFs:

The user decides that he does not want IP multicast configured for VRF red on GigabitEthernet 0/1/0, so he uses the virtual network interface mode override. IP Multicast is disabled for VRF red only. The no ip pim command disables all modes of Protocol Independent Multicast (PIM), including sparse mode, dense mode, and sparse-dense mode, for VRF red.

Example: EVN Using IP Multicast

The following example configures PIM sparse mode and leverages Anycast RP for RP redundancy. In this example, only one VRF is configured.

The example shows how to enable multicast routing globally and on each L3 interface. The black text indicates the group of commands configuring the global table; the red text indicates the group of commands configuring VRF red.

!

Routing Context for EXEC Mode Reduces Repetitive VRF Specification

There may be occasions when you want to issue several EXEC commands to apply to a single virtual network. In order to reduce the repetitive entering of virtual routing and forwarding (VRF) names for multiple EXEC commands, the routing-context vrf command allows you to set the VRF context of such EXEC commands once, and then proceed using EXEC commands.

The table below shows four EXEC commands in Cisco IOS XE software without routing context and in routing context. Note that in the left column, each EXEC command must specify the VRF. In the right column, the VRF context is specified once and the prompt changes to reflect that VRF; there is no need to specify the VRF in each command.

traceroute Output Indicates VRF Name and VRF Tag

The output of the traceroute command is enhanced to make troubleshooting easier by displaying the incoming VRF name/tag and the outgoing VRF name/tag, as shown in the following example:

Debug Output Filtering Per VRF

Using EVN, you can filter debug output per VRF by using the debug condition vrf command. The following is sample output from the debug condition vrf command:

CISCO-VRF-MIB