Network Device Virtualization


One of the characteristics of a VN is that it provides what are essentially private communication paths between members of a group over a shared infrastructure. This creates two requirements for the network infrastructure:

  • Traffic from one group is never mixed with another For sending and receiving traffic over shared links, tunnels (many borrowed from existing virtual private network [VPN] solutions) can guarantee data separation. Network devices need to enforce group separation in their internal memory (for example, during routing table lookups, access lists processing, or NetFlow statistics gathering).

  • Each VN has a separate address space This requirement is derived from the fact that VNs offer the same characteristics as a physical network. Address space and forwarding within it are two of the most basic aspects of any network.

Note

In this section, we start with a narrow definition of device virtualization as creating a separate address space within a network device. However, you can think of this as a special case of a more general definition of a virtualized device, which is the ability for an administrator to allocate device resources to different uses. The first device resource we consider is address space, but as we proceed through both the chapter and book, we include different layers of device policy control mechanisms, such as quality of service (QoS) and security rules. Therefore, the final picture of a virtualized device will be much closer to the general definition.


The first problem to solve is how to virtualize the forwarding plane in a way that meets the requirements for address and traffic flow separation. Depending on the type of device, the virtual separation can go by the following names:

  • Virtual LAN (VLAN)

  • Virtual routing and forwarding (VRF)

  • Virtual forwarding instance (VFI)

  • Virtual firewall context

Layer 2: VLANs

VLANs are a good example of a piece of the virtualization puzzle that has been around for quite some time. A VLAN is a logical grouping of ports on a switch that form a single broadcast domain. Ports in a VLAN can communicate only with other ports in the same VLAN. How a given switch does this is implementation dependent, but a common solution is for the switch to tag each frame with a VLAN number as it arrives on a port. When a frame is sent to other ports, the output hardware copies the packet only if it is configured with the VLAN number carried in the frame.

On an Ethernet switch, there is typically a single MAC table, which maps ports to MAC addresses. To support VLANs (and simple Layer 2 virtualization), the MAC table has a field for the VLAN number on which the station was discovered, as demonstrated in Example 4-1.

Example 4-1. Switch MAC Table

 Switch# show mac-address-table ... Non-static Address Table: Destination Address  Address Type  VLAN  Destination Port -------------------  ------------  ----  -------------------- 0010.0de0.e289       Dynamic          1  FastEthernet0/1 0010.7b00.1540       Dynamic          2  FastEthernet0/5 0010.7b00.1545       Dynamic          2  FastEthernet0/5 0060.5cf4.0076       Dynamic          1  FastEthernet0/1 0060.5cf4.0077       Dynamic          1  FastEthernet0/1 0060.5cf4.1315       Dynamic          1  FastEthernet0/1 0060.70cb.f301       Dynamic          1  FastEthernet0/1 00e0.1e42.9978       Dynamic          1  FastEthernet0/1 00e0.1e9f.3900       Dynamic          1  FastEthernet0/1 

Note

Note that the output in Example 4-1 was taken from http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_command_reference_chapter09186a0080417db7.html#wp1021274.


The summary effect of the VLANs is to partition the switch into logical Layer 2 domains. Each domain has its own address space and packets from one domain are kept separate from those of another.

Layer 3: VRF Instances

VRFs are to Layer 3 as VLANs are to Layer 2 and delimit the domain of an IP network within a router. The Cisco website has a more formal definition:

VRFA VPN Routing/Forwarding instance. A VRF consists of an IP routing table, a derived forwarding table, a set of interfaces that use the forwarding table, and a set of rules and routing protocols that determine what goes into the forwarding table.

Unlike the VLAN scenario, where an extra column in the MAC table is adequate, a VRF partitions a router by creating multiple routing tables and multiple forwarding instances. Dedicated interfaces are bound to each VRF.

Figure 4-1 shows a simple logical representation of a router with two VRFs: RED and GREEN. 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. An interface cannot be in multiple VRFs at the same time.

Figure 4-1. Multiple VRFs on a Router


You can see in Figure 4-1 how a VRFs provide separate layer paths between routed interfaces. RED packets can never end up on a GREEN interface.

Note

There is a way to share routes between VRFs, but that is beyond the scope of this introduction. Interested readers should consult the references in the appendix for specialized texts on Multiprotocol Label Switching VPNs (MPLS VPNs).


It is easy to see VRFs on a router. Example 4-2 shows the RED and GREEN VRFs, with their interfaces. Example 4-2 shows overlapping IP addresses on the Serial interfaces. Example 4-3 gives an interface-centric view of the same data.

Example 4-2. Displaying VRFs

 Router# show ip vrf   Name                Default RD        Interfaces   RED                 100:1             Ethernet1/0, Ethernet1/2, Serial2/0.102   GREEN               100:2             Serial2/0.103, Serial2/1.103, Ethernet4/2 Example 4-3 Displaying interface to VRF mapping Router# show ip vrf interfaces Interface       IP-Address      VRF            Protocol Ethernet1/0     130.22.0.33     RED            up Ethernet1/2     130.77.0.33     RED            up Serial2/0.102   130.77.0.33     RED            up Serial2/0.103   130.77.0.33     GREEN          up Serial2/1.102   130.77.0.33     GREEN          up Ethernet4/2     130.22.0.33     GREEN          up router# 

FIBs and RIBs

Before looking at the routing information for a VRF, we need to introduce the routing table's two main data structures, which are used to find the egress interface for a given packet: the Forwarding Information Base (FIB) and the Routing Information Base (RIB). Long gone are the days when a router maintained a single routing table on which it did linear, longest-prefix searches against destination IP addresses.

The FIB is a database of information used to forward packets. When a packet is received on a routed interface, the router looks up the destination address in the FIB to find the next hop for the packet.

The FIB structure is particularly efficient for resolving longest-prefix matches, and Cisco IOS resolves all route redirections so that a single lookup can yield the entry for the next hop of a packet. Cisco literature often mentions an adjacency concept when presenting the FIB. An adjacency is any node in the network that is reachable with a single Layer 2 hop. It so happens that Cisco IOS also maintains a data structure of adjacencies, which contains, among other things, interface and MAC layer rewrite information for all possible next hops. FIB entries point to the adjacency table, and in the remainder of this chapter, we group the two together and refer simply to the FIB. Hardware-based forwarding paths use the FIB concept, as does Cisco Express Forwarding (CEF).

Because it contains both Layer 2 and Layer 3 information, the FIB can be updated by several sources, such as routing protocol and Address Resolution Protocol (ARP) updates.

The RIB is the memory structure that contains classic routing data. The RIB can contain recursive routes. If a packet destination is not in the FIB, the router "punts" the packet to a slow processing path and resolves the destination next hop using the RIB.

When you enable VRFs, there are multiple instances of information in the FIB and RIB. You can see routing information with show ip route vrf name command, as shown in Example 4-3. Except for the first line, which identifies the VRF, there is no difference from the regular show ip route output.

Example 4-3. VRF Routing Table Information

 R104#show ip route vrf RED Routing Table: RED Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP        D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area        N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2        E1 - OSPF external type 1, E2 - OSPF external type 2        i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2        ia - IS-IS inter area, * - candidate default, U - per-user static route        o - ODR, P - periodic downloaded static route Gateway of last resort is not set      20.0.0.0/24 is subnetted, 1 subnets O       20.0.0.0 [110/11121] via 40.0.0.1, 00:00:02, Tunnel0      40.0.0.0/24 is subnetted, 1 subnets C       40.0.0.0 is directly connected, Tunnel0      30.0.0.0/24 is subnetted, 1 subnets C       30.0.0.0 is directly connected, Ethernet0/0 

The adjacencies for any routing entry in the VRF must resolve to different interfaces, even if the IP addresses on the interface are identical. Example 4-4 has a FIB entry for 40.0.0.2 from the global routing table, and Example 4-5 has the same information for the RED VRF. These examples are deliberately simple, but you can use the show ip cef forwarding vrf name detail command to peruse the FIB in all its glory.

Example 4-4. FIB Output for Global Routing Table

 R104#show ip cef Prefix                Next Hop             Interface 0.0.0.0/0             drop                 Null0 (default route handler entry) 0.0.0.0/32            receive 40.0.0.0/24           attached             Loopback1 40.0.0.0/32           receive 40.0.0.2/32           receive 40.0.0.255/32         receive 

Example 4-5. FIB Output for VRF RED

 R104#show ip cef vrf RED Prefix              Next Hop              Interface 0.0.0.0/0           drop                  Null0 (default route handler entry) 0.0.0.0/32          receive 40.0.0.0/24         attached              Tunnel0 40.0.0.0/32         receive 40.0.0.2/32         receive 

The term global is used to refer to the routing instances and tables that are not in a VRF, as in "global routing table" or "global address space."

When discussing VRFs, it is common to hear questions about resource allocation, such as "how are router resources allocated between VRFs?" This is a natural question, even if it is not logical! There are no special rules to prioritize data from one VRF to be processed quicker than data from other VRFs. A VRF exists in the memory plane of a device, not in the scheduling plane, which is what per-VRF traffic prioritization would require.

Note

Creating a VRF does not automatically consume a significant amount of memory. However, the expectation is that you will add routes to the VRFs and in this case be careful that the sum of entries in the virtual routing tables does not exceed the capacity of the device. In truth, this is not much different from standard best practices governing route table size.


Traffic processing happens according to the same rules as on a device with no VRFs:

1.

Traffic enters the router.

2.

The ingress policy is applied.

3.

Routing and forwarding lookup occurs.

4.

The egress policy is applied.

5.

Traffic is forwarded.

Obviously, the ingress and egress policies can include QoS statements that prioritize traffic to or from a particular interface or address, but the fact that a packet belongs to a particular VRF has no impact on those policies. It simply alters what happens in Step 3 of the preceding list.

It is far more common to want to bind an interface or packet flow to a particular VRF based on policy criteria. For example, all interfaces from a certain user domain are bound to a single company VRF, or packets with a 10.0.0.0/8 source address are bound to a guest VRF. We look at this in great detail in some of the design chapters.

Virtual and Logical Routers

A VRF is not the same thing as a completely virtualized device, even if they are sometimes confused as such (it is true that some marketing literature encourages such confusion). They simply allow routers to support multiple address spaces. This is some distance from a fully virtualized device, where resources can be more or less arbitrarily allocated to tasks.

Virtualized devices do exist, however, and, to cut through the fog of confusion, it is helpful to have a taxonomy of terms to start with:

  • A logical router (LR) uses hardware partitioning to create multiple routing entities on a single device. An LR can run across different processors on different cards of a router. All the underlying hardware and software resources are dedicated to an LR. This includes network processors, interfaces, and routing and forwarding tables. LRs provide excellent fault isolation but do require abundant hardware to implement.

  • A virtual router (VR) uses software emulation to create multiple routing entities. The underlying hardware is shared between different router processes (note that we mean an entire instance of something like the nonkernel parts of IOS, not a single router process). In a well-implemented virtual router, users can see and change only the configuration and statistics for "their" router.

Note

The previous definitions and Figure 4-2 were derived from RST-4314 2004 Networkers "Advances in Router Architecture: The CRS-1 and IOS-XR," by David Tsiang and David Ward.

Figure 4-2. Logical and Virtual Routers



From the preceding list and Figure 4-2, which gives a pictorial idea of the difference between VRs and LRs, you can see that only the LR is completely virtualized. Because of the cost involved of having all that extra hardware and device management, LRs tend to be high-end systems. A VR is a software-based virtualization solution, where all the tasks share the same hardware resources.

In both cases, the granularity of what is virtualized can differ. Some implementations allow multiple router processes (for instance, one VR per customer domain), others allow you to allocate resources to tasks (an LR can have Border Gateway Protocol [BGP] running on one hardware subsystem and Intermediate System-to-Intermediate System [IS-IS] on another, for example).

VRF Awareness

Now that there are multiple routing and forwarding instances on a router, many of the router subsystems that use the information in these tables (which is a long list) need to become "VRF aware." A VRF-aware feature can be configured to refer to routing and forwarding information from a specific VRF and understand that only certain subinterfaces can be used with certain VRFs. Without this information, the feature uses the global table. For example, to assign an interface to a VRF, the basic interface ip address command was modified to take a VRF name parameter and become ip address vrf NAME forwarding.

Note

VRF awareness is an important implementation detail. Unfortunately, no canonical list exists of VRF-aware features (the list keeps growing), so the best approach is to check the latest online documentation or pester your Cisco representative.


If all features required for a particular application are VRF aware, you can use VRFs to emulate a VR and hence provide virtualized device functionality. This is the approach you will see used in the design sections of this book.

Layer 2 Again: VFIs

VFI is a service-specific partition on a switch that associates attachment circuits in the form of VLANs with virtual switched interfaces (VSIs).

If that did not make much sense, it is useful to have some background on the service itself, namely Virtual Private LAN Services (VPLS), to understand VFIs.

VPLS is a Layer 2 LAN service offered by service providers (SPs) to connect Ethernet devices over a WAN. The customer devices (call them customer edges [CEs] for now; we review this in more detail in Chapter 5, "Infrastructure Segmentation Architectures") are all Ethernet switches. However, the SP uses a Layer 3 network running Multiprotocol Label Switching (MPLS) to provide this service. The device on the edge of the SP network is called a provider edge (PE). Its role is to map Ethernet traffic from the customer LAN to MPLS tunnels that connect to all the other PEs that are part of the same service instance. The PEs are connected with a full mesh of tunnels and behave as a logical switch, called a VSI. Another way to think about this is to see the VPLS service as a collection of Ethernet ports connected across a WAN. A VSI is a set of ports that forms a single broadcast domain.

In many ways, a VSI behaves just as you would expect a regular switch to. When a PE receives an Ethernet frame from a customer device, it first learns the source address, as would any switch, before looking at the destination MAC address and forwarding the frame. If the port mapping for the destination MAC address is unknown, or is a broadcast, the frame is sent to all PEs that are part of the VSI. The PEs use split horizon to avoid creating loops, which in turn means that no spanning tree is needed across the SP network.

Obviously, the previous explanation hides a fair amount of detail, but it should be enough to give a high-level view of what is going on.

Once again, there is a need to define and manage groups of isolated ports and tunnels on a switch. The VLAN construct is too limited, and a VRF is strictly a Layer 3 affair, so it is necessary to come up with a new virtual device structure for VPLS, called a VFI.

The VFI lists addresses of all the PEs that form a VSI. Recall that VPLS uses a full mesh of point-to-point tunnels for inter-PE connectivity, so there will be connections to each PE listed. The customer-facing ports map VLANs to a VFI name. Example 4-6 shows a short configuration extract that will make this clearer. Figure 4-3 shows the corresponding network topology. The thick line represents the VLAN that runs across the MPLS backbone and connects the VSIs on the PE devices. The CE switches "think" they are connected by a 802.1q trunk on VLAN100. The thin lines between each PE are the actual pseudowires defined in the l2 vfistatement of Example 4-6.

Figure 4-3. VPLS Topology


Note

A pseudowire is a tunnel. The term is often used in the context of a Layer 2 service.


Example 4-6. VFI Configuration

 l2 vfi VPLSA manual  vpn id 100  neighbor 13.13.13.13. encapsulation mpls  neighbor 12.12.12.12 encapsulation mpls interface loopback 1  ip address 11.11.11.11 255.255.255.255 interface fastethernet1/0  switchport  switchport mode dot1qtunnel  switchport access vlan 100 interface vlan 100  no ip address  xconnect vfi VPLSA 

VPLS configuration has two components. The first, which we have already referred to, defines the mesh of pseudowires that together act as a virtual switch. The second maps the VLAN trunk port to a VSI using the xconnect command. This appears at the end of Example 4-6.

Virtual Firewall Contexts

Device virtualization is not limited to switches and routers. As a final example, consider a firewall device. For essentially economic reasons, you might want to share a single firewall between multiple different customers or network segments. Each logical firewall needs to have a complete set of policies, dedicated interfaces for incoming and outgoing traffic, and users authorized to manage the firewall.

Many vendors provide this capability today and undoubtedly have their own, well-chosen name for it, but on Cisco firewalls the term context is used to refer to a virtual firewall. Unlike VRFs, VFIs, or VLANs, a context is an emulation of a device (so an example of the VR concept discussed earlier in this chapter).

Firewall contexts are a little unusual in the way they assign a packet to a context. All the partitions we have seen up to now have static assignment of interfaces (you can assign IP packets to a VRF dynamically. We cover that later). A firewall module looks at an incoming packet's destination IP address or Ethernet VLAN tag to decide which context a packet belongs to. All the firewall needs is for one of the two fields to be unique. So, either each context has a unique IP address space on its interfaces or the address space is shared, but each context is in a different VLAN.

Figure 4-4 shows a simple setup with an Ethernet switch connected to a firewall context using two VLANs. The switch binds the VLANs to VRF BLUE (at the top) and VRF RED. The firewall has two different contexts. The blue one receives all frames on VLAN 101 and the red one gets VLAN 102. In this way, packets from the outside (on the right side of the figure) that belong to VLAN 101 go through a different set of firewall rules than those belong to VLAN 102.

Figure 4-4. VRF on Switch Connected to Firewall Contexts Across VLANs


Network Device Virtualization Summary

True device virtualization allows resources to be allocated to tasks, or applications. We looked at four different primitives that virtualize the forwarding paths on switches or routers: VLAN and VFI for Layer 2, VRF for Layer 3, and contexts for firewalls. Each of these functions slightly differently. VRFs have the most extensive tie-ins with other features, which we use extensively in the design sections. Before covering data-path virtualization, one word about data center designs. We are focusing on network devices exclusively in this book and do not address the details of server and storage virtualization, which are two important topics in their own right.




Network Virtualization
Network Virtualization
ISBN: 1587052482
EAN: 2147483647
Year: 2006
Pages: 128

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net