Network virtualization is a solution that allows a network administrator to create multiple isolated network partitions overlaid on top of a common physical network infrastructure. This model helps enable customers to create multiple networks, without the additional investment in hardware (Figure 1).
Figure 1. Typical Virtual Networks
Network virtualization addresses business challenges that range from simple to complex.
Simple scenarios include enterprises that want to provide Internet access to visitors (guest access). The requirement, in this case, is to allow visitors only an external Internet access but to prevent unauthorized connections to the enterprise internal resources and services. This can be achieved by dedicating a logical "virtual network" on top of an existing physical network that supports employee global access to handle the entire guest communication path. Without virtualization technology in place, achieving this would require dedicated devices, resources for managing those devices to ensure security, and defining policies using access control lists (ACLs) at every edge node of the network.
Another simple driver for network virtualization is the creation of a logical partition dedicated to the machines that have been quarantined as a result of a Network Admission Control (NAC) posture validation. In this case, it is essential to guarantee isolation of these devices in a remediation segment of the network, where only access to remediation servers is possible until the process of cleaning and patching the machine is successfully completed.
Complex scenarios include enterprise IT departments acting as a service provider, offering network services to multiple enterprise "customers" that need logical isolation between them. What makes the solution complex is when there is an additional requirement to support shared services (for example, Domain Name System [DNS], Dynamic Host Configuration Protocol [DHCP]) across multiple customers. This requirement can also be achieved using network virtualization.
Moreover, as the demand on campus networks grows in complexity, so does the need to separate groups of network users and resources into logical partitions. Network virtualization facilitates resource pooling and operational alignment; it provides multiple solutions for centralizing services and security policies while preserving the high availability, manageability, security, and scalability benefits of the existing campus design.
The architecture of an end-to-end network virtualization solution targeted to satisfy the requirements listed above can be addressed using device-level separation and path isolation techniques.
Network Virtualization in a Campus Network
Within the campus environment, network virtualization can be subdivided into two requirements. The first level is device-level separation, which includes Layer 2 VLANs and Layer 3 virtual routing and forwarding (VRF) instances. The second level is path Isolation, which maintains device-level separation across the interconnecting links between the virtualized devices. The path Isolation techniques we are going to focus on for Virtual Network Manager (VNM) are 802.1Q, generic routing encapsulation (GRE), and Multiprotocol Label Switching (MPLS) VPN (RFC 4364).
A typical IP network is a combination of Layer 3 (routed) and Layer 2 (switched) domains. To support network virtualization in the campus, network designs should use both switching (Layer 2) technologies at the network edge (access) and routing (Layer 3) technologies at the network core (distribution and core layers).
The virtualization at the network access layer (Layer 2) by means of VLANs is a well-proven concept. What is now required is a mechanism that allows the extension of the logical isolation over the routed portion of the network. This is made possible using VRF technology, which allows for the virtualization of the Layer 3 devices.
Unlike the legacy techniques, such as use of access control lists for path isolation, VRF represents a new approach called control plane-based path isolation. Control plane-based path isolation techniques restrict the propagation of routing information so that every virtual network has its own specific routing tables and updates.
• Virtualize to lower cost/increase flexibility: Virtualization lets customers use more of their network assets with greater efficiency, allowing them to realize cost savings even as requirements for devices, systems, services, and applications grow. Thus it contributes to effective reduction of operating expenses (OpEx), while helping to ensure improved IT productivity, thereby delivering operational excellence.
• Based on existing hierarchical campus and WAN designs: Most enterprise customers have their infrastructure built for LAN and WAN needs based on hierarchical design. Virtualization as a new technology does not mandate a change in underlying network design and fits well in the same infrastructural setup. This helps customers in quick deployment with minimal outage time.
• Scalable end-to-end IP-based virtualization solution: A number of customers have deployed VLANs in Layer 2 for creating network virtualization at the Layer 2 level. The advent of Layer 3 network virtualization technology and its ability to map with Layer 2 VLANs help in building a scalable end-to-end network virtualization solution.
• Varying levels of access privileges within an enterprise: Almost every enterprise needs solutions for granting different levels of access to customers, vendors, and partners as well as employees on the campus LAN. A visiting vendor, for instance, needs only to connect to the Internet while on campus, and the organization needs to help ensure that the vendor cannot gain access to corporate resources.
• Regulatory compliance: Some businesses are required by laws or rules to separate segments of a larger organization. For example, in a financial company, banking needs to remain separate from trading. Office buildings commonly require the separation of different departments, such as human resources and customer service in a corporate setting, or a police department and a fire department in a municipal office building.
• Network simplification for very large enterprises: In the case of very large campus networks such as airports, hospitals, or universities, the need for security between different groups or departments has in the past required the building and management of separate physical networks, an undertaking that is costly and difficult to manage.
• Network consolidation: In mergers and acquisitions, there is often a need to integrate the acquired company's network expeditiously.
• Outsourcing: As outsourcing and offshoring proliferate, subcontractors must demonstrate absolute isolation of information between clients. This is especially critical when a contractor services competing companies.
• Enterprises providing network services: Often retail chains support kiosks for other companies or on-location Internet access for patrons; similarly, airports serving multiple airlines and retailers can provide isolated and common services with a single network.
What Is VRF?
A VRF instance 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.
When the devices are virtualized using VRF, the virtual instances in the various devices must be interconnected to form a virtual network. Three main path Isolation techniques for VRF-based data path virtualization are GRE tunnels, MPLS VPN (RFC 2547), and 802.1Q.
The choice of data path virtualization depends on how far the VRFs are from each other. The first two techniques (GRE and MPLS VPN) are used for multihop data path virtualization: the virtual devices are usually not directly connected, and a tunnel mechanism is necessary to link them over an IP cloud that is commonly not virtualized.
IEEE 802.1q is used when supporting VRF-Lite on a hop-by-hop basis. Using the hop-by-hop virtualization technique, every network device is virtualized, together with all the devices' physical interconnections.
The scope of discussion is limited to using VRF-Lite end-to-end for network virtualization.
What Is VRF-Lite?
VRF-Lite, which also goes by the generic name of multi-VRF, provides device-level separation by creating a separate routing and forwarding table for each virtual network. Each VRF is associated with a unique instance of the interior gateway routing protocol that enables the exchange of routes, with the directly connected neighbor devices on the same virtual network. Further, each interface is associated with either the global or one of the virtual routing tables. Interfaces in a VRF can be either physical, such as Ethernet ports, or logical, such as subinterfaces (SIs), or switched virtual interfaces (SVIs).
In VRF-Lite, starting at the access layer, VLANs are used to maintain device-level separation. IEEE 802.1Q is used to tie the access layer VLANs to the distribution layer where these VLANs are associated with a VRF. At the distribution layer, the VLAN is associated with an SVI. At the distribution layer, the SVI is linked to the VRF. The distribution layer is then interconnected on a hop-by-hop basis with other core campus devices using 802.1Q trunks. Path isolation is achieved between all the core devices using 802.1Q VLAN tags. Each outgoing packet is tagged with an 802.1Q tag, so that at each hop along the way, grouping and isolation between the packets is maintained. The association between a VRF and an 802.1Q tag is done at every hop to maintain separation.
At the core and distribution layers, the separation created by a VLAN at Layer 2 is maintained at Layer 3 by using separate VRFs on a device level and 802.1Q tags on a path level.
In summary, the benefits of a VRF-Lite end-to-end approach over typical VLAN-based logical isolation in campus deployments are:
• Robust control plane that uses Layer 3 routing protocols rather than Spanning Tree Protocol.
• From a data plane perspective, the same concept of VLAN tags can be reused and extended in order to provide logical isolation on each point-to-point link interconnecting the Layer 3 virtualized network devices.
Advantages of VRF-Lite
• IP address space conservation: Each VRF maintains an independent routing domain. This characteristic provides the flexibility of using any IP address space for any given virtual network, regardless of whether it overlaps or conflicts with the address spaces of other virtual networks. Therefore, each group can independently use private IP addressing. In this scenario, Network Address Translation (NAT) is not required. (Note: NAT might still be required in order to send traffic to the Internet.)
• Robust control and data plane: VRF-Lite end-to-end approach uses a more robust control plane based on Layer 3 routing protocols rather than Spanning Tree. From a data plane perspective, the familiar concept of VLAN tags is reused in order to provide logical isolation on each point-to-point link interconnecting the virtualized network devices.
• Widely supported across the Cisco Catalyst® family of products: Unlike GRE and MPLS-VPN, which currently benefit hardware support only on Catalyst 6500 platforms, VRF-Lite is natively supported across the different Catalyst switch models. As seen in Table 1, it is one of the virtualization technologies that have extensive platform support.
Table 1. Platform Support
Number of VRFs
VRF-Lite only (EMI)
VRF-Lite only (EMI)
3750 Metro Series
• End-to-end path isolation: VRF-Lite can be deployed without changing the IP characteristics of the underlying network and without introducing additional control plane components (such as Multiprotocol Border Gateway Protocol [MP-BGP] used in MPLS-VPN). Further, the same routing protocols that run in most enterprise campus networks (Enhanced Interior Gateway Routing Protocol [EIGRP] and Open Shortest Path First [OSPF]) can be virtualized and used in the context of each deployed virtual network.
• Flexibility: Each created virtual network represents an exact replica of the underlying physical infrastructure (as shown in Figure 2): this is due to the nature of the VRF-Lite end-to-end approach that requires the virtualization of every network device, together with the device's interconnections.
Figure 2. Creation of Virtual Networks
• Cost Advantage: Each logical network can be designed by using the campus best practices that should already be deployed in the underlining physical infrastructure. The final result is a reduction in the operational expenses of running the overall virtualized network infrastructure.
Challenges with Deploying VRF-Lite End to End
Labor-intensive provisioning: The primary challenge faced during the deployment of VRF-Lite in a campus LAN is one of operational complexity involved in iteratively provisioning multiple parameters of VRFs at every node and interface on the existing physical infrastructure. Depending on the combination of the total number of virtual networks required and the overall size of the network (that is, how many devices need to be virtualized), this could be a very labor-intensive process. Further addition of a new user group (or a virtual network) would also involve manual reconfiguration of each connected network device that may be participating in such a virtual network. As a design practice, network managers should factor in the processing and memory requirements for routing processes, management, packet forwarding, and so on.
Also, visualizing multiple VRFs existing in the network and troubleshooting these VRFs become challenging for network administrators.
These challenges are addressed by Virtual Network Manager.
Virtual Network Manager
VNM is a management application that released along with LMS 3.2 to ease the provisioning, monitoring, and troubleshooting of virtualized campus networks. The initial support will be limited to campuses supporting deployments of Layer 2 VLANs and VRF-Lite for device-level separation and 802.1Q for path Isolation. For this release, VNM support is basically restricted to Cisco 6500 series, Cisco ME 6500 series, ASR, Router 7200, Router 7600, ISR 2800, ISR 1800 and ISR 3700 devices only.
CiscoWorks LAN Management Solution (LMS) is a very powerful suite of network management applications that simplifies the configuration, administration, monitoring, and troubleshooting of Cisco networks. Its capabilities can improve the accuracy and efficiency of operations staff, increase the availability of networks through proactive planning, and increase network security. Its rich data environment allows the automation of device manageability tasks, visibility into the network's health and capability, and identification and localization of network trouble. Being delivered as a module within the CiscoWorks LMS product, VNM eliminates the need to learn, purchase, or deploy yet another management tool for managing virtual networks.
This document focuses on how VNM can help users to overcome the labor-intensive VRF-Lite deployments and manual reconfigurations that are required on multiple connected network devices of a campus LAN network. An example of an airport network environment is considered to illustrate a typical VRF-Lite deployment using VNM.
Consider an international airport scenario where the following challenges are assigned to the network administrator of the international airport. The network should be designed in such a way that it meets all of the following requirements:
• Some of the user networks should be local to the airport and don't need external connectivity.
• Availability of Internet access must be 100 percent to airport authorities for communication between international terminals.
• Others, however, might need access from within the network to the Internet (Internet kiosks, lounges).
• Multiple tenants may need secured access from the Internet to their network (for remote support of third-party applications such as SAP, and so on).
• Network is to serve as a "transit" network for larger networks, where provider edge nodes not only offer connectivity to access switches but rather learn routes from adjacent Layer 3 switches or routers with large customer networks behind them.
In this context, the technology choice is typically driven by factors like:
• Scalability of the technology to accommodate the future growth and expansion of the airport's infrastructure
• Need for granular allocation of resources to users based on parameters like time-intervals (contract-based users), departments (for example, airport staff, guest users, customers, partners)
• Network availability and reliability constraints of the underlying services (for example, air traffic control, the airport's SAP or other employee services, Internet kiosks) being used
Figure 3. Network Diagram of International Airport
Consider that the network design of the international airport is as shown in Figure 3. In order to cater to diverse needs of the different user groups, separate virtual networks are built and deployed over the common existing physical network infrastructure. This would provide administrators the advantages of VRF technology, which was discussed earlier.
Mapping User Groups to Virtual Networks
Table 2 summarizes the different departments available in the international airport. Separate VRFs are created to cater to the distinct network connectivity requirements of each of these departments. The details of how to create VRFs using VNM for each of these departments will be explained in the VRF-Lite deployment section below. For now, let's assume the network should be configured and designed to meet the following requirements given by the airport network administrators with the underlying infrastructure as shown in Figure 3.
Table 2. User Profiles and Department Details
Air control and tower communication
Pilots, signaling staff
VLAN 1 to VLAN 25
VLAN 26 to VLAN 30
Need 100 percent availability 24 hours a day, 7 days a week
Baggage distribution, video surveillance
Department staff, higher authorities
VLAN 31 to VLAN 40
VLAN 41 to VLAN 50
They are local to the airport.
VLAN 51 to VLAN 60
Mostly local, but might have to connect to external agencies during emergency situations
VLAN 61 to VLAN 100
Lounge access, Internet kiosks
VLAN 100 to VLAN 200
Internet access for personal use
Airline 1, Airline 2, and so on
VLAN 201 to VLAN 500
Need secured access over the Internet to their network
VRF_Airline1, VRF_Airline2, and so on
Partner 1, Partner 2
VLAN 501 to VLAN 600
VLAN 601 to VLAN 700
Conferences and exhibitions
Event 1, Event 2
VLAN 701 to VLAN 750
VLAN 751 to VLAN 800
Have access for limited time period
Deploying VRF-Lite End to End Using VNM
In the following sections, different facets of deploying and managing VRF-Lite end to end in an airport are discussed in detail. Typically, VNM would be used for discovery and monitoring of existing VRFs, checking the readiness of the network for VRF, configuration of VRFs, and troubleshooting the virtual networks.
Virtualization is the need of the hour in the enterprise world today. Virtual routing and forwarding has evolved considerably and is becoming increasingly popular. The value VNM could add to the network that has already deployed VRFs is the focus of this section.
Assume that the enterprise under study already has deployed the following VRFs in the network:
Let's say the administrative staff, airport employees, and event organizers are connected to 10.10.0.1, 10.10.0.2, and 10.10.0.3 access switches, respectively. Now VNM can be used to discover the existing VRFs in your network. For this, the prerequisite is that all devices participating in VRF need to be managed in the Campus Manager 5.2 application, and at least one data collection cycle should have been run. Once this is complete, go to LMS Portal >> Functional view >> VNM >> Home. The VNM homepage appears as shown in Figure 4.
The VNM homepage is a comprehensive dashboard that summarizes the information about VRFs discovered from the network. It provides access to all other VNM features, such as configuration, reporting, and troubleshooting.
Figure 4. VNM Homepage
The summary information about the VRFs in the network as discovered during the latest VRF collection is shown in the VNM homepage. Please note that the three VRFs that were created on the airport network for administrators, services, and temporary events are listed in the table with information about the number of devices participating in each of these VRFs. The description clearly highlights that these VRFs got discovered by the VRF collectors. Detailed information regarding the devices and interfaces participating in each VRF can be obtained by clicking each VRF hyperlink.
VRF-Lite discovery runs at regular intervals, concurrent to Campus Manager data collection, to be in tune with actual network configuration. Campus Manager data collection by default runs every day in an interval of four hours. The user would also be able to schedule data collection at a more frequent interval from Campus Manager >>Administration >> Data collection >> Schedule Data Collection.
In Topology Services, all those VRFs discovered by VNM will be listed in the topology filters under the VRF List category. Figure 5 shows the list of VRFs discovered by VNM.
Figure 5. Topology Map View of the Airport Network
In case the network under study had no VRFs already deployed, the VRF homepage would show a blank table with no VRFs. Nevertheless, VNM assesses the capability of existing network infrastructure to support VRF technology.
What if the airport network administrator decides to deploy VRF in the network? After the assessment of the existing infrastructure, VNM classifies the devices into two categories, based on the data collected by Campus Manager and VNM.
• VRF capable devices
• VRF supported devices
VRF Capable Devices
The count of VRF capable devices shows the devices that are hardware ready but need software updates on the Cisco IOS
® Software images running on them. Clicking the hyperlink as shown in Figure 6 launches the detailed report showing the list of devices falling under this category.
Figure 6. Readiness Status
The VRF readiness report listing the capable devices is shown in Figure 7.
Figure 7. VRF Capable Device Report
From Topology Services, this can be viewed by selecting the filter VRF Capable from the Readiness category (Figure 8).
Figure 8. Capable Filter
Please note that in the remarks column there will be a message stating whether the device is being managed by CiscoWorks Resource Manager Essentials (RME) or not. In order to upgrade the device with the minimum supported image, the device has to be managed in RME. Once this is done, selecting the device and clicking Upgrade will take you to the RME software image upgrade screen. The software image management feature provides recommendation of incremental images supported for the specific hardware. The user can select the required image from the list of available images obtained from Cisco.com and upgrade the Cisco IOS Software images in order to upgrade the software capability of devices to support VRF deployment. Once this is done, the next scheduled VRF collection could reassess and identify these devices as VRF supported devices.
VRF Supported Devices
The count of VRS supported devices includes devices that are both hardware and software ready. These devices can readily be used for discovering, creating, editing, extending, and deleting VRFs on the network. You can click the hyperlink on the VNM homepage to see the list of supported devices from the readiness report (Figure 9).
Figure 9. Supported Devices Report
In Toplogy Services this can be viewed by clicking the VRF supported filter under the Readiness category (Figure 10).
Figure 10. Supported Device Filter in Topology Services
This category in the report lists those devices in the network that have Layer 3 functionality but don't have support for virtualization. This may be because the hardware on these devices does not support virtualization.
Adding a New Department to the Network
VNM allows users to perform end-to-end virtualization configuration including all the physical interconnections that exist between the two nodes that are being virtualized. This happens in a step-by-step process.
Let us consider that in the airport scenario under discussion, there is a new airline Westjet that has signed a contract and obtained the landing rights to the airport. It is required that a separate virtual network be created for this airline for communicating and signaling to the administration and airline authorities in the lounge. This could be achieved with the help of the Create VRF option in VNM as described below.
Consider that Airline_westjet has to be created for the purpose of this discussion. This airline is connected to the switch 10.10.0.4. Let us see how virtualization of the physical network is carried out using the create VRF workflow in VNM, consisting of three steps:
1. Virtualization of network devices
2. Virtualization of interconnections
3. Virtualization of routing protocols
Further, the section assumes a more typical campus deployment with a switched access deployment containing Layer 2 only devices at the access layer. Thus only distribution and core blocks with Layer 3 functionality are used for configurations in the examples below. In case of a routed access deployment, configuration of the access layer would be fairly similar to the configuration done below.
Virtualization of Network Devices (Launching Workflow from Topology Services)
Create workflow can be invoked either from the homepage or from Topology Services. Selecting the devices and right-clicking the optionshows the possible VNM launch points as shown in Figure 11. This is available only for those devices that appear in the VRF supported list.
Figure 11. VRF Options in Topology Services
Clicking Create VRF takes you to the Create VRF flow in VNM. The page appears as shown in Figure 12 and lets the user provide a unique name for the VRF and provide a unique route distinguisher for the VRF.
Figure 12. Create VRF
Virtualization of Network Links
The next step in the creation flow is virtualization of the network links. Clicking the Next button leads you to the interface to the VRF mapping screen. This screen allows users to virtualize the network links connecting the selected devices. The virtualization of links involves creation of logical interfaces in each of them. Typically campus deployments contain either switched trunk links or routed links connecting the core and distribution blocks. In the former, switched virtual interfaces are the logical interfaces used to achieve logical isolation of traffic, while in the latter sub interfaces are used.
The choice is usually based on the existing network infrastructure and the capabilities of the existing devices. VNM has a metadata repository that provides information about the capabilities of various device families supported by it and the preferred virtual interface to be created in them. When the chosen devices are not directly connected, clicking Next prompts you with an error message stating that the devices are isolated. You can only create VRFs on devices that are contiguously connected to each other.
Using the detailed network information gathered during data collection and the preferences in the metadata repository, VNM chooses the most appropriate logical interface for virtualizing a given link. The existing configuration in the device would take precedence over the application defaults for the chosen device as specified in the metadata repository. Please refer to Table 4 in the technical caveats section for more details.
Once the choice is made, VNM creates a new logical interface and deduces the associated information, such as:
• IP address of the physical interface, which is reused on the logical interface (since VRFs allow overlapping IP address space; for more details refer to the technical caveats section). It is possible for the user to edit the IP addresses to be configured on the interfaces.
• Native VLAN that should be used for communicating between the two devices. This is required only when the two interfaces are hybrid in nature, such as an SVI and an SI.
• VLAN that should be used for this virtual link. It is important to note that VNM finds the next possible free VLAN common to both ends and uses this for virtualization. This greatly reduces the headache of searching for free VLANs on both the devices when this task is done manually.
• In case the choice of logical interface is SVI and the underlying physical interface is not trunking, the user interface shows a hyperlink in the isTrunk column. This could be used to configure the trunk on the associated physical interface. The trunk configuration happens immediately. Even if customers cancel the VNM configuration, trunk creation will not be rolled back. It is important to note that the trunk is mandatory for the SVI-SVI combination, and unless done, VRF cannot be created.
• The UI shows the trunk as "Not Applicable" when either of the selected devices is a Layer 3 device.
Figure 13 gives a detailed picture of the associated configuration screen with the various parameters autosuggested by VNM. The administrator has the choice of changing any parameter as required.
Figure 13. Interface Mapping
Clicking the Next button from this screen will take you to the routing protocol configuration page as shown in Figure 14. This allows you to perform virtualization of routing protocols.
Figure 14. Routing Protocol Configuration
The routing protocols supported for VNM phase 1 are EIGRP and OSPF. The commands that will be deployed on the device are shown under the Commands column in the table. Clicking the View Global link gives the entire set of commands pertaining to the routing protocol available on the device. Clicking the edit icon in the routing protocol column will open an editable command window, which is used for editing the commands and the routing protocols that have to be deployed on the device. It is important to note that there will not be any validation done on the edited commands. The commands will be pushed as is on to the devices. Figure 15 shows the command snippet in the editable command window.
One of the main advantages of the VRF-Lite end-to-end approach is being able to use inside each virtual network the same routing protocol already implemented to provide connectivity in the physical infrastructure (the "global table"). This is not a mandatory requirement, since a different routing protocol could theoretically be used in the context of each VRF, but it is a recommended best practice in order to lower the operational complexity of running these multiple virtual networks. So the user interface allows the use of existing Interior Gateway Protocol (IGP) configuration or creates a new one for this VRF.
Figure 15. Routing Protocol Edit Option
The summary of the creation flow appears when the user clicks the Next button from this screen. You can either click the Finish button to complete the VRF creation on selected devices or go back to the previous screen if you want to edit some configuration. The creation of VRF is scheduled as a job. Once the creation job is completed, it will automatically trigger a Campus Manager data collection followed by the VNM collection.
VRF-Lite Deployment to the Access Layer
Once the VRF is created, to create an end-to-end virtualized flow, we need to assign it to the edge VLAN(s) that are originating from the access switches. Users in these particular VLANs only will be participating in the selected VRF. In this case study, as described in the Table 2 user profiles and the departments, pilots have been assigned VLANs 1 to 25, and signaling authorities have been assigned VLANs 26 to 30. To understand the workflow, let's say we need to virtualize the pilots in VLANs 3 and 4 to be part of VRF_control_unit. This could be done as described below.
Figure 16 shows the devices in the airport network. The edge VLANs have to be assigned to the VRF created on the first Layer 3 hop device in the distribution layer. Selecting the distribution device, First_floor, and right-clicking it give you the options to assign edge VLANs to this distribution device.
Figure 16. Assign Edge VLAN from Topology Services
Alternatively Figure 17 shows the homepage where VRF_control_unit is being chosen. The user can select the option Assign Edge VLAN to map VLANs to the selected VRF.
Figure 17. Assign Edge VLAN from VNM Homepage
Select the distribution switch (Layer 2/Layer 3 device) that is sitting at the distribution layer collecting the traffic that is flowing from the access layer switches. Figure 19 shows a device selector with only devices that have the VRF_control_unit configured in them, since First_floor is the distribution switch that is aggregating all traffic that is flowing from the access layer switch to which pilots in VLANs 3 and 4 are connected, Access_switch1. Instantly if the user wants to create VLANs on the access switches, he or she can do so by selecting the device from the topology map and clicking the create VLAN option as shown in Figure 18.
Figure 18. Create VLAN from Topology Services
Figure 19. Assign Edge VLAN: Select Devices
Clicking the Next button at the bottom of the screen will take you to the VLAN to VRF mapping screen as shown in Figure 20.
Figure 20. VLAN to VRF Mapping
In Figure 20, when the user selects the check box against the blank text box, the text box gets populated with the VLAN string. The user has to provide the virtual interface name in order to map the VLANs in the access device to VRFs in the Layer 2/Layer 3 device. The VLAN ID field gets prepopulated with corresponding values. The user has to provide the IP address that has to be assigned for the virtual interfaces and provide the subnet mask for the assigned IP address. This step effectively creates a virtual interface (Layer 3) for an existing VLAN on the device (Layer 2), or creates a new VLAN and associates a virtual interface for the newly created Layer 2 VLAN. Once this is done, the VRF Assignment field gets populated with the selected VRF. Here it is VRF_control_unit. It should be noted that when a checkbox that is already mapped to the selected VRF is unselected, this interface will be unmapped to the VRF and will be reassigned a global interface. This could be inferred from the VRF Assignment column in the table shown in Figure 20.
The gear icon shown next to the configuration text box is used to allow the selected VLAN to pass through the trunk interface. Clicking this icon will open the screen shown in Figure 21.
Figure 21. Layer 2 Trunk Configuration
Select the check box and click Apply to allow the VLAN to pass through the trunk interface Gi4/9. The Layer3 Features tab (Figure 22) allows users to create redundancy and Dynamic Host Configuration Protocol (DHCP) protocols for the newly created interface. Users have to select the method by which they like to create redundancy, namely Hot Standby Router Protocol (HSRP), Gateway Load Balancing Protocol (GLBP), or Virtual Router Redundancy Protocol (VRRP), and provide the group number and IP address of the virtual router. In order to create DHCP for the selected switched virtual interface, the user has to provide the DHCP server address and click Apply.
Figure 22. Layer 3 Feature Configuration
Clicking Next will display the summary of the commands that will be displayed on the device. This is shown in Figure 23.
Figure 23. Assign Edge VLAN Summary
Click the Finish button to deploy the commands on the selected distribution layer devices.
Using Edit VRF Option
Assume that the airport allows access to the Internet for guests and transit users. These users can connect through the lounge computers and kiosks using a predefined user ID and password. Assume the airport administrative authorities have received requests for more kiosks in the airport lounge. However the administrators have decided that all of these users are not critical and hence and would not need 100 percent availability of Internet connection. This has to be translated into the appropriate network change.
Assume that there are also enough access switch ports present for the additional lounge kiosks and that these access switches are connected to two distribution layer switches for resilience. Hence there arises a need to add more VLANs to meet the requirement, and these VLANs are to be mapped to the existing VRF, VRF_guests. It is also required that the administrator remove the redundant distribution layer switch that is already participating in this VRF based on the decision that has been taken by the authorities. This could be done in two steps using the VNM tool, as described below.
Step 1. Removing the redundant switch
From the homepage, select the VRF, VRF_guest, and click the Edit VRF button at the bottom of the homepage as shown in Figure 24. This can also be done from the topology map by right-clicking the devices on which you want to edit the VRF parameters.
Figure 24. Editing VRF
The screen shown in Figure 25 appears. The VRF selected in the previous step is preselected. Please note that there are three devices participating in the selected VRF. This is evident from Figure 24.In the next step we will remove the redundant Layer 2/Layer 3 distribution switch, Distribution_switch, which was available for resilience. Click Next to proceed with interface mapping.
Figure 25. Editing Devices in Edit VRF Flow
Figure 26 shows the interface connecting the two devices. The user has to provide the IP address for these logical interfaces and the appropriate subnet mask and click Next.
Figure 26. Edit Interface Mapping
The screen shown in Figure 27 appears. Please note that there are only two devices shown here. The third device, Distribution_switch, which was there for resilience, has been removed now. Click Next to see the summary of commands that would be configured on the device. Click Finish to deploy the configuration on to the device.
Figure 27. Editing Routing Protocol Configuration
Step 2. Adding users
In order to add users to the particular VRF, we need to add VLANs to the access switch and map these VLANs to the distribution layer switches. The first two steps in the workflow are similar to the steps given in the section "VRF-Lite Deployment to the Access Layer." After selecting the distribution layer devices, click Next to map VLAN to VRF. Assuming there were already 61-70 VLANs participating in VRF_guest, add two more VLANs, VLAN 71 and VLAN 72, to the VRF to cater to new requests as shown in Figure 28.
Figure 28. Edit VLAN to VRF Mapping
Provide the appropriate IP address and subnet mask and click Next to go to the summary page. Check for correctness of the input parameters and click Finish to deploy commands on to the devices.
Using Extend VRF Option
Let's assume that the airport administrative security task force wants to implement more stringent security measures in the airport. This change warrants a creation of a new segment separately within the airport. There are also policies that have to be defined as to which departments this segment needs to communicate with. This could be made much simpler when VRF is implemented in the network. In the network under study, there are already VRFs that have been deployed for internal communication between various departments. Thus, a video surveillance department when created can be mapped to the existing VRF_internal so that communication can happen smoothly between various departments as always. The following approach can be adopted to deal with this kind of situation faced by the network administrators.
Figure 29. Extend Option in VNM Homepage
In Figure 29, select VRF_internal, which you want to extend to Admin_switch1 where the video surveillance segment is connected. The screen shown in Figure 30 appears.
Figure 30. Extend VRF Device Selection
Now the VRF named VRF_internal is preselected. Expand the All Devices category in the device selector. This will show only those devices that are not already participating in the selected VRF. Select the device Admin_switch1 in which you are planning to configure or extend the existing VRF, namely VRF_internal.
Figure 31. Extend: Interface Mapping
The screen in Figure 31 appears on clicking Next. Select the interface that has to be mapped to the VRF and provide the IP address to be configured for each of the subinterfaces.
The screen shown in Figure 32 appears. Please note that the routing protocol configuration for Distribution_switch1 shows two protocols, OSPF and EIGRP. You can select either one of them from the drop-down list and proceed with the configuration.
Click Next to view the summary of commands that will be deployed on the extended device list. Check for the correctness of the parameters provided as input and click Finish to deploy the configuration.
Figure 32. Extend: Routing Protocol Configuration
Table 3 shows the differences between Edit VRF and Extend VRF.
Table 3. Edit Versus Extend Differentiation
The user wants to edit VRF parameters such as VLANs and the IP addresses of interfaces
• When the user wants to add additional device(s) to the existing VRFs
• When the user wants to add additional interfaces to the existing VRFs
Allows users to modify
Only VRF parameters and not existing interfaces
Route distinguisher and description; does not allow users to edit or add interfaces on the devices participating in the existing VRFs
Deleting a VRF
In the network under discussion, there are VRFs that are created for specific events and conferences to cater to their connectivity needs. Once these events are over, it is necessary to delete these VRFs, basically for purposes of security of information and access. Due to the existence of these unused routing instances of VRFs, there may also be performance issues on the core devices and distribution layer devices. Thus freeing up the network resources is absolutely necessary.
VNM allows users to do this in a simple manner quickly, following the steps given below. Consider in the airport scenario, VRF_temporary_event_1 is complete and network administrators want to delete the configurations pertaining to this from all the devices that were participating on this.
Select VRF_temporary_event_1 and click the Delete VRF option as shown in Figure 33.
Figure 33. Delete Option in VNM Homepage
Alternatively, select the device or devices from which you want to remove the VRF from the map and right-click to delete the VRF (Figure 34).
Figure 34. Delete Option from Topology Services
The device selector as shown in Figure 35 lists all the devices participating in this particular VRF. Click the devices on which you want to delete the VRFs and click Next.
Figure 35. Delete: Select Devices
Check the summary page, which is displayed with commands as shown in Figure 36, and confirm by clicking Finish. A job will be created that will delete VRF_event_temporary from the selected devices. It is important to note that the SIs and the SVIs that were created while creating the VRF will be removed, and the IP address that was associated will be freed up. However the VLANs that were created during the flow will not be deleted from the device.
Figure 36. Deletion Summary
Visualizing Virtualization in Your Physical Network
Once VRF has been deployed on to the devices, it becomes essential for the network administrators to manage these VRFs and have a consolidated list of all VRFs in the network for documentation purposes. It also becomes important to visualize them as they appear in a real physical network. This would help in planning for future network growth and to accommodate incoming newer requirements. To address this need, VNM helps users visualize these physical network elements and their association with the logical or virtual segments over the topology map. The following things are possible through the Topology Services module in Campus Manager 5.2:
• Visualizing readiness status
• Visualizing VRF participating devices
• Visualizing link virtualization
Visualizing Readiness Status
In Topology Services, a separate category called VRF has been added to the filters. There are two subcategories available, Readiness and VRF List. In Expanding Readiness, there are two status items listed, namely VRF Capable Devices and VRF Supported Devices. The explanations for and ways to view the readiness status of the airport network in Topology Services were provided in the section "Readiness Reporting." Selecting the categories will highlight devices that fall under the capable and supported devices, respectively.
Visualizing VRF Participating Devices
The second category, VRF List, displays all the VRFs that have been discovered by VNM in the network. Selecting a particular VRF will highlight those devices participating in the selected VRF. Figure 37 highlights those devices that are participating in VRF_internal.
Figure 37. Visualizing VRF Devices in Topology Services
Visualizing Link Virtualization
This status gives you additional information on the virtualization status of the interfaces along with the devices. When the interfaces in certain devices participating in VRFs are not virtualized, the communication of end users connected to the network would be interrupted. This necessitates network administrators to visualize and troubleshoot by looking into the configuration of VRFs.
There are three virtualization states that are possible. When the user selects one of the VRFs from the filter, the link will be highlighted in any of the following three colors:
• Black color: This indicates that the interfaces in both the ends of the link are participating in the selected VRF.
• Cyan color: This indicates that only one of the interfaces is participating in the selected VRF. Hovering the mouse over the link displays details of which interface is participating in a tool tip. The user can thus infer that the other end of the link has not yet been virtualized. The user can then right-click the device containing this interface and proceed with virtualizing this link.
• Gray color: This indicates that neither of the interfaces connecting the device has been virtualized. The user can right-click these devices from the topology map and proceed with virtualizing this link.
Figure 37 highlights the devices that are participating in VRF_internal in the airport network along with the tool tip showing that only the interface belonging to the Distribution_airline switch is participating in VRF_internal.
Reports allow users to view details of all the VRFs and devices that are ready for VRFs in a single place. All or selected details can be exported to a comma-separated value (CSV) file or can be printed by clicking the respective options from the report.
There are two VNM report categories:
• VNM readiness report
• VRF report
VNM readiness report has already been discussed in the section "Readiness Reporting."
VRF report can be launched from VNM >> Reports >> Report Generator >> VNM Reports. From this page the user can view the details of VRFs based on devices by selecting devices from the device selector or details of one or more VRFs by selecting the VRFs from the VRF selector. If users want to know just the details of a single VRF, they can do so by selecting the VRF name hyperlink from VNM homepage. They can also select a particular VRF and click Show Details to view the information pertaining to this specific VRF.
Figure 38 gives you the details pertaining to the VRF VRF_guest on the Layer 2/Layer 3 switch Distribution_airline present on the airport network.
Figure 38. VNM Device-Based Report
Troubleshooting Problems in Connectivity
While the complexity of troubleshooting physical connectivity of the network elements itself requires considerable efforts, the complexity is increased in the case of virtual network and connectivity issues. To troubleshoot VRF, the network administrator needs to ping all participating devices hop by hop to detect which is the problem device. VNM tools help avoid this repetitive effort by introducing troubleshooting VRF devices using ping and traceroute mechanisms. Figure 39 clearly explains how this feature could be used for the airport network under discussion.
Using Ping and Traceroute to Troubleshoot
The user has to select the source device, Distribution_airline. From the VRF drop-down list, the user can select either a single VRF or select the Global table. The source interface is populated based on the VRF selected. This will list only those interfaces that are participating in the selected VRF. Selecting the Global table will list all the IP addresses configured on the device. The destination device selector list is populated based on the selected VRF. The user has to select the destination interface that needs to be pinged from the source through the selected VRF. Clicking the View command will display the command that will be executed on the device. Click Ping to run the command. The result is displayed in the result pane.
You can also use traceroute to troubleshoot devices participating in VRF. This is more helpful to troubleshoot at which point the communication fails in a specific path configured in a specific VRF. When the Enable Bi-directional option is selected, the traceroute command will be executed in both directions between the source and the destination interface. This option is used when the user wants to troubleshoot whether the selected devices are reachable though a particular VRF in either of the directions.
Figure 39 shows the result of the ping command execution.
Figure 39. Troubleshooting Using Ping
Using Show Results to Troubleshoot
This option is used to troubleshoot Layer 3 device connectivity for a specific VRF. The command executed is specific to a particular routing protocol that is used for virtualizing. The VRF can be selected based on the selected source device. The user has to select the routing protocol to troubleshoot. Clicking Show Results will execute the predefined command "Show ip eigrp vrf VRF_internal neighbors". This will look for the neighbors in the selected VRF instance's EIGRP routing table. This helps the user to discern if the neighbor device is reachable through the specific VRF. See Figure 40.
Figure 40. Troubleshooting Using Show Results
• Automatic suggestion of VLANs for each link:
In different workflows like creating/extending VRFs, VLANs that need to be created are automatically suggested by VNM. The chosen VLAN should be available for use in both ends of the links. If the application is not able to find a VLAN within the boundary conditions or if the administrator wants to use his or her own choice, the administrator has to provide a suitable VLAN. The VLAN that is created is added to the allowed list of the underlying trunk. In general, the suggestion is influenced by the following factors:
– Type of the devices:
– Pure Layer 3 devices don't support SVI, and the entire VLAN range (2 to 4096) can be used when creating subinterfaces.
– Devices that have both Layer 2 and Layer 3 capabilities support both VTP and Internal VLANs, so the range is restricted.
– Type of logical interface:
– SVIs are associated with Layer 2 VLANs, and they could be restricted to VTP VLAN range (0 to 1005).
– Subinterfaces are associated with internal VLANs, and typically they are allocated in the range 1006 to 4096.
– Further, since the internal VLANs are automatically created when subinterfaces are created, the internal VLAN allocation policy configured on the device also plays a pivotal role.
• Interface configuration-related issues:
– As already discussed, the choice of logical interface is an involved decision and is taken after consideration of a number of parameters. Table 4 summarizes the decision process.
Table 4. Decision Process
Is physical interface configured with IP address?
Are subinterfaces configured?
Are SVIs configured?
Preferred mode as suggested by metadata repository
Choice made by VNM
Use SI for virtualization
Use SI for virtualization
Use SI for virtualization
Use SI for virtualization
Use SI for virtualization
Use SVI for virtualization
– As seen in Table 4, VNM would follow the strategy of least change to the existing configuration. So if a device has a switch port, VNM would prefer creating SVIs on this device after changing the switch port to trunking. In this context, the access VLAN assigned to that switch port before trunk configuration would be configured as a native VLAN after trunk configuration to preserve global traffic.
– In some device families like cat4k, sub interface configuration may not be supported, so VNM would be forced to use SVIs as the logical interface. So an existing routed interface may need to be changed to a switched interface, and hence the global traffic could be affected. To avoid this disruptive traffic, a new SVI is created and configured with the IP address of the initial routed interface configured to carry the global traffic.
– While configuring trunks on an Interface, there could be a temporary loss of connectivity on the underlying link. So it should be ensured that CiscoWorks is connected to the device using a redundant link so that the connectivity from the VNM server to the device is not lost.
A virtual LAN, commonly known as a VLAN, is a group of hosts with a common set of requirements that communicate as if they were attached to the broadcast domain, regardless of their physical location. A VLAN has the same attributes as a physical LAN, but it allows for end stations to be grouped together even if they are not located on the same network switch.
• Native VLAN
A native VLAN is a default VLAN, associated with an 802.1Q trunk interface.
VPN Routing and Forwarding 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. Because the routing instances are independent, the same or overlapping IP addresses can be used without conflicting with each other.
A switch virtual interface is a VLAN of switch ports represented by one interface to a routing or bridging system. There is no physical interface for the VLAN, and the SVI provides the Layer 3 processing for packets from all switch ports associated with the VLAN.
In telecommunications and computer networking, a subinterface is a division of one physical interface into multiple logical interfaces. Routers commonly employ subinterfaces for a variety of purposes, most common of these are for routing traffic between VLANs, and in nonbroadcast multiple access networks such as Frame Relay or ATM.
In computer networking and telecommunications, Multiprotocol Label Switching refers to a mechanism that directs and transfers data between wide area networks (WANs), nodes with high performance, regardless of the content of the data. MPLS makes it easy to create "virtual links" between nodes on the network, regardless of the protocol of their encapsulated data.
Generic routing encapsulation is a tunneling protocol developed by Cisco that can encapsulate a wide variety of protocol packet types inside IP tunnels, creating a virtual point-to-point link to Cisco routers at remote points over an IP internetwork.
Open Shortest Path First is a dynamic routing protocol for use in Internet Protocol networks. Specifically, it is a link-state routing protocol and falls into the group of interior gateway protocols, operating within an autonomous system. It is defined as OSPF Version 2 in IPv4. The updates for IPv6 are specified as OSPF Version 3.
Enhanced Interior Gateway Routing Protocol is a Cisco proprietary routing protocol loosely based on their original IGRP. EIGRP is an advanced distance-vector routing protocol, with optimizations to minimize both the routing instability incurred after topology changes, as well as the use of bandwidth and processing power in the router.
A virtual private network is a computer network in which some of the links between nodes are carried by open connections or virtual circuits in some larger network, such as the Internet, as opposed to running across a single private network. The Link Layer protocols of the virtual network are said to be tunneled through the transport network. One common application is to secure communications through the public Internet, but a VPN does not need to have explicit security features such as authentication or content encryption.