Network Systems DesignLine | A Virtualization Technologies Primer: Theory--Part IV




November 24, 2006

A Virtualization Technologies Primer: Theory--Part IV

Part IV of this multi-part series excerpted from 'Network Virtualization,' published by Cisco Press, takes you back to layer 2 again, to virtual switched interfaces (VFIs) and virtual firewall contexts.

Here are Part I, Part II,and Part III.

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 [CDs] 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 tunnel s 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 6 shows a short configuration extract that will make this clearer. Figure 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" thy re connected by a 802.1q trunk on VLAN100. The thin lines between each PE are the actual pseudowires defined in the 12 vfi statement of Example 6.

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


Figure3. VPLS Topology


Example 6. VFI Configuration

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 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 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 that belong to VLAN 102.


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

Next: Network Device Virtualization Summary and Data-Path Virtualization

About the Authors
Kumar Reddy is a Manager of Technical Marketing Engineering at Cisco Systems. Kumar has more than 15 years of industry experience. He has held a variety of technical roles at Cisco, including working with service provider customers as a systems engineer, as a technical specialist for both digital subscriber line (DSL) and Ethernet products and technology and, most recently, designing end-to-end systems for small and medium-size businesses.

Before joining Cisco Kumar taught unsuspecting engineering students in Paris and worked as a programmer in Tokyo. Kumar has a degree in Computer Engineering from Trinity College, Dublin, Ireland.

Victor Moreno is a Technical Marketing Engineer at Cisco Systems and a Cisco Certified Internetworking Expert (CCIE). He has more than 10 years of industry experience and is a recognized expert in the field of virtual enterprise networks and has been involved with enterprise network virtualization since 2001. Victor has a degree in electrical engineering from the Simon Bolivar University in Caracas, Venezuela and a Master degree from the University of York, England, and specializations from Stanford University.

To contact any of the authors, please email: reviews@ciscopress.com and use Network Virtualization/post question as the subject line.

Title: Network Virtualization.ISBN: 1-58705-248-2 Authors: Victor Moreno, Kumar Reddy. Chapter 4: A Virtualization Technologies Primer: Theory.Published by Cisco Press.

Reproduced from the book Network Virtualization. Copyright [2006], Cisco Systems, Inc. Reproduced by permission of Pearson Education, Inc., 800 East 96th Street, Indianapolis, IN 46240. Written permission from Pearson Education, Inc. is required for all other uses.

*Visit Cisco Press for a detailed description and to learn how to purchase this title.