This section provides an overview of NSV. This section includes the following topics:

Virtual routing and forwarding (VRF) is a technology used in computer networks that allows multiple instances of a routing table to coexist within the same router at the same time. VRF partitions a router by creating multiple routing tables and multiple forwarding instances. Because the routing instances are independent, you can use the same or overlapping IP addresses without conflict.

You can implement VRF in a network device by having distinct routing tables, one per VRF. Dedicated interfaces are bound to each VRF.

In Figure 16‑1, the red table can forward packets between interfaces E1/0, E1/2, and S2/0.102. The green table, on the other hand, forwards between interfaces E4/2, S2/0.103, and S2/1.103.

The simplest form of VRF implementation is VRF Lite, as shown in Figure 16‑2. VRF Lite uses VRFs without multiprotocol label switching (MPLS). In this implementation, each router within the network participates in the virtual routing environment in a peer-based fashion. This extends multiple VPNs from a provider edge (PE) device onto non-MLPS customer edge (CE) devices, which support multiple VRFs. It also replaces the requirement for separate, physical CE devices.

NSV is a Riverbed network design option that leverages the Riverbed WDS solution by deploying SteelHeads in an existing MPLS deployment using VRF. Riverbed recommends using NSV in an MPLS/VRF environment to deploy SteelHeads while retaining existing overlapping address spaces.

The concept of NSV originates in an MPLS VPN environment with multiple hosts in the same source VPN. The hosts require access to different servers in various destination VPNs. This is a difficult deployment to implement if a particular subinterface is VRF-attached. A subinterface is a way to partition configuration information for certain subsets of traffic that arrive or leave a physical interface.

NSV uses the IOS MPLS VPN VRF Select feature, which essentially eases the requirement of a VRF-attached subinterface.

The VRF Select feature uses policy-based routing (PBR) at the ingress interface of the VRF router to determine which VRF to forward traffic to. In most cases, the VRF router is a PE device. In a VRF-Lite implementation, the VRF router is a CE device. The VRF router determines the routing and forwarding of packets coming from the customer networks (or VPNs). The access control list (ACL) defined in the PBR route map matches the source IP address of the packet. If it finds a match, it sends the packet to the appropriate MPLS VPN (the VRF table).

For more information about PBR, see Policy-Based Routing Virtual In-Path Deployments.

The VRF table contains the virtual routing and forwarding information for the specified VPN. It forwards the selected VPN traffic to the correct MPLS label switched path (LSP), based upon the destination IP address of the packet.

NSV with VRF Select removes the association between the VRF and the subinterface. Decoupling the VRF and the subinterface allows you associate more than one MPLS VPN to the subinterface. The subinterface remains in the IPv4 dimension in VRF Select (as compared to the VPNv4 address space, in which it resides when it is VRF-attached). The subinterface is still IPv4-based, but it becomes aware of VRF Select by replacing the ip vrf forwarding Cisco command with ip vrf receive command.

The result is that the subinterface becomes Not-So-VRF. The subinterface still resides in the global IPv4 table, but it now uses PBR for the VRF switch. The PBR route map matches criteria based on traffic flows to be optimized.

Cisco recommends the following minimum IOS releases for an MLPS VPN VRF Selection using PBR deployment.

Before configuring NSV, review the following information:

This example shows the following deployment scenario:

This deployment is the basis for the configuration shown in Configuring NSV.

Figure 16‑3 shows a logical in-path NSV deployment in a VRF network environment.

Figure 16‑4 shows the NSV deployment shown in Figure 16‑3 with intercepted and optimized flows.

Figure 16‑5 shows the NSV deployment with bypassed flows in the event that the data center SteelHead fails.

This section describes how to configure NSV. This section includes the following topics:

The configuration in this section uses the parameters set up in Example NSV Network Deployment.

This section shows the overview of the basic steps to configure NSV with VRF Select. The following sections describe each step in detail.

The following sections describe each of these steps in detail.

The data center PE or CE router determines the routing and forwarding of packets coming from the customer networks or VPNs. This device requires the most configuration.

The first step is to define the VRF tables for the SteelHead. For example, you define two VRF tables for SteelHead 40: custa for the customer and wds_a to use as a dummy VRF table. The dummy VRF table is not tied to any interface. It redirects traffic with a corresponding default route, which points to or exits at the subinterface to the SteelHead.

The next step configures the subinterfaces and VRF routing protocol. In this example, you configure the following subinterfaces and define the OSPF VRF routing protocol:

This example configures the LAN subinterface f0/0.40, which interconnects SteelHead 40 to use VRF custa. Later, you point the dummy VRF wds_a to a default route (in this example, f0/0.40). This enables a PBR route map at f0/0.49 to redirect incoming traffic from Server 49 to Client 42 to SteelHead 40 for optimization.

In this example, because Client 42 is in the VPN custa (VRF custa), the traffic must return to the VRF custa routing path after optimization. For this redirection to work, the SteelHead 40 must reside in VRF custa and not VRF wds_a.

VRF Select requires a control mechanism such as PBR to select which particular VRF table a data packet goes to. The next step is to configure a PBR route map, which provides a matching criteria for incoming traffic and sets the VRF table.

The following step decouples the association between VRF and a subinterface. It implements NSV by replacing the ip vrf forwarding Cisco command with ip vrf receive command.

The result is that the subinterface is becomes Not-So-VRF. The subinterface still resides in the global IPv4 table, but it now uses PBR for the VRF switch. The PBR route map matches criteria based on traffic flows to be optimized.

Static routes play a crucial role in an NSV deployment, because you use them to fine-tune the routing. The primary, default static route points to the in-path interface to redirect incoming traffic for optimization. (In the following example, traffic is redirected to 10.4.40.101 of SteelHead 40).

The command keyword track 1 determines whether the in-path IP address of the SteelHead is reachable. The primary, default static route is used only when the in-path IP address for the SteelHead is reachable. If it becomes unreachable, the primary route is removed from the routing table. The second, floating route serves as a backup to avoid blackholing traffic and ensure flow continuity.

In this example, when the primary route is removed from the routing table because the SteelHead is unreachable, the second route becomes effective at an administrative weight of 250, points to the WAN interface e1/0, and avoids blackholing traffic to ensure flow continuity.

Also, in this example, because f0/0.49 (where Server 49 is connected) is still in the IPv4 global address space, you must make it visible in VRF custa. To do this, you assign a third static route, associating it with VRF custa. The third static route points to Server 49 (10.4.49.88) in VRF custa and redistributes it into OSPF.

IP SLA uses the ICMP echo protocol to monitor the availability status of the SteelHead in-path IP address every 5 seconds (in this example, IP address 10.4.40.101 for SteelHead 40:custa). This is tied to the primary default route through the tracking mechanism. The tracking mechanism prevents routing to an unavailable IP destination when the in-path IP address for the SteelHead is down (in this example, SteelHead 40:custa).

A typical branch office router is a PE VRF or CE VRF Lite device. Its configuration is minimal and standard. In most environments you probably do not need to configure this device.

The data center SteelHead (in this example, VRF custa) is another vital component of an NSV deployment. Its configuration is very simple; you simply enable the logical in-path interface.

The SteelHead deployed at the branch office needs slightly more configuration than the data center SteelHead. Because you are only implementing VRF Select for redirecting the data center LAN-side traffic, you must define fixed-target rules for the WAN-side traffic.

The following example uses SteelHead 42:custa.

You can also use auto-discovery to eliminate configuring fixed-target rules if you disassociate the WAN interface (in this example, P4R1 e1/0) from the VRF (in this example, custa) the same way you disassociated the LAN interface using VRF select as described in Decoupling VRF from the Subinterface to Implement NSV.

The branch office SteelHead could also be a SteelHead Mobile. In this deployment, you could use the Mobile Controller to facilitate configuring the fixed-target rules.

For information about the Mobile Controller, see the SteelCentral Controller for SteelHead Mobile User’s Guide.