Chapter 4: A Virtualization Technologies Primer: Theory

Cisco Press

1 2 3 4 5 Page 5
Page 5 of 5

Data-Path Virtualization Summary

We presented several different protocols that can be used for data-path virtualization. Two of them are suitable for Layer 2 traffic only: 802.1q, which is configured on each hop, and L2TPv3 which is configured end to end. IPsec is suitable for IP transport. Finally, GRE and MPLS LSPs can be used for either Layer 2 or Layer 3. GRE is another IP tunnel protocol, configured only on endpoints. MPLS creates a new forwarding path and is configured on all hops in a network.

Control-Plane Virtualization—Routing Protocols

Data-path virtualization essentially creates multiple separate logical networks over a single, shared physical topology. To move packets across these VNs, you need to need a routing protocol.

The most familiar virtualized control plane is probably Per VLAN Spanning Tree (PVST), which has a separate spanning-tree instance for each VLAN running on a switch. Even through PVST has been around longer than the term virtualization, it illustrates the central point we are making here very crisply. Different logical networks have different topologies and, therefore, different optimal paths. Switches have to run different spanning-tree calculations for each such network.

The remainder of this section deals with extensions to routing protocols to allow them to run with multiple routing instances. However, we will return to the topic of control-plane virtualization, because many different router and switch functions, such as NetFlow, DHCP, RADIUS, and so on, need to receive the same treatment and become VRF aware.


Note - The need for VRF awareness was introduced in the section on device virtualization earlier in the chapter. This is particular to Cisco platforms. In more general terms, features applied or related to the data path, such as NetFlow, RADIUS, and so on, need to support virtualization also—it's not as simple as creating multiple routing tables.


VRF-Aware Routing

Cisco's major interior gateway protocol (IGP) routing protocol implementations are VRF aware. This means that they understand that certain routes may be placed only in certain routing tables. The routing protocols manage this by peering within a constrained topology, where a routing protocol instance in a VRF peers with other instances in the same VN. No special information is added to the route advertisements to identify VRF names, so routing instances must communicate over private links.

With some protocols (for example, BGP), a single routing instance can manage multiple VRF tables; with others (for example, OSPF), a different routing process runs for every VRF. Remember that in both cases, every VRF requires a route optimization calculation, so increasing the number of VRFs does have a computational impact on a network device.

Chapter 5 has more information on the end-to-end setup. This section just covers the main concepts.

VRF per Process: OSPF

OSPF has a different routing process for each VRF. The first implementation was rather strict, with a maximum of 32 processes. Furthermore, two processes are reserved for static and connected routes. Recent software enhancements lift this limitation. You are now limited to 32 VRFs per process, but the number of processes is now fixed by the network devices' CPU and memory limitations (300 to 10,000 depending on the platform).

Example 4-19 shows how an OSPF process is associated with the RED VRF. The networks advertised by this process should be in the same VRF.

Example 4-19  Per-VRF OSPF Configuration

router ospf 2000 vrf RED
 log-adjacency-changes
 
 network 20.0.0.0 0.0.0.255 area 0
 network 40.0.0.0 0.0.0.255 area 0

VRF Address Families: EIGRP, RIP, and BGP

For the other routing protocols, a single process can manage all the VRFs, and the Cisco IOS address-family command is used to configure per-VRF route policy. Example 4-20 shows how to configure RIP for two VRFs, RED and GREEN. Each VRF has overlapping entries for network 13.0.0.0.

Example 4-20 Per-VRF RIP Configuration

router rip
 version 2
 !
 address-family ipv4 vrf RED
 version 2
 network 11.0.0.0
 network 13.0.0.0
 no auto-summary
 exit-address-family
 !
 address-family ipv4 vrf GREEN
 version 2
 network 12.0.0.0
 network 13.0.0.0
 no auto-summary
 exit-address-family
!

Example 4-21 shows an iBGP per-VRF Configuration.

Example 4-21 Per-VRF iBGP Configuration

router bgp 100
 no synchronization
 bgp log-neighbor-changes
 no auto-summary
 !
 address-family ipv4 vrf RED
 redistribute connected
 neighbor 14.0.0.1 remote-as 100
 neighbor 14.0.0.1 update-source loopback100
 neighbor 14.0.0.1 activate
 no auto-summary
 no synchronization
 exit-address-family
 !
 address-family ipv4 vrf GREEN
 redistribute connected
 neighbor 15.0.0.1 remote-as 100
 neighbor 15.0.0.1 update-source loopback200
 neighbor 15.0.0.1 activate
 no auto-summary
 no synchronization
 exit-address-family
!

Multi-Topology Routing

Multi-Topology Routing (MTR) is a recent innovation at Cisco. As the name suggests, it creates multiple routing topologies across a shared, common infrastructure. However, MTR does not try to be yet another VPN solution. Instead, it creates paths through a network that you can map to different applications or classes of applications, with the understanding that, by separating traffic in this way, you can provide better performance characteristics to certain critical applications.

MTR bases its operation on the creation of separate RIBs and FIBs for each topology. The separate RIBs and FIBs are created within a common address space. Thus, MTR creates smaller topologies that are a subset of the full topology (also known as the base topology). The main difference between MTR and a VPN technology is that, with MTR, a single address space is tailored into many topologies that could overlap; whereas VPNs create totally separate and independent address spaces.

Thus, MTR must carry out two distinct functions:

  • At the control plane—Color the routing updates, so that the different topology RIBs are populated accordingly. Based on these RIBs, the corresponding FIBs are to be written.

  • At the forwarding plane—Identify the topology to which each packet belongs and use the correct FIB to forward the packet.

At each hop, there will be a set of prefixes and routes in the RIB for each topology. The contents of these RIBs are dynamically updated by routing protocol colored updates. Based on this RIB information, a separate FIB is built for each topology.

To forward traffic over different topologies, the router looks for a code point in each packet and chooses an FIB based on this code point. A first implementation of MTR uses differentiated services (DiffServ) code point (DSCP) as such a code point, but other code points could be used by future implementations. The DSCP value is used as a pointer to the correct forwarding table, and the packet's destination address is used to make a forwarding decision based on the information in the topology's FIB. MTR uses the terminology of color to refer to separate topologies. So, a RED value in a packet's DSCP field is recognized by the router, which will forward the packet using the RED forwarding table (FIB).

MTR must run contiguously across a network, and the color mappings must be consistent (that is, you cannot use DSCP X as Green on one hop but as Red on the next). MTR does not allow you to double dip: If the destination route is not in the routing table of the color a packet is using, the packet can either be dropped or forwarded over the base topology—there are no lookups in "backup topologies" other than the base topology (which is equivalent to regular routing).

MTR does not change how routing works; it just runs across multiple topologies (using a single process with colored updates).

Control-Plane Virtualization Summary

Control-plane virtualization refers to adaptations made to routing protocols to be able to operate on virtualized devices. We concentrated on per-VRF routing because that is the main tool we use for design. However, VRs and LRs also run separate routing instances in a similar manner to the one shown here. In all cases, there are no changes to the protocol "on the wire." MTR is an interesting new development that can also be categorized in the virtualized control-plane bucket.

Summary

This chapter covered a lot of ground. The basic idea is that there are different levels of virtualization: device, data path, and control path. There are different constructs and protocols to implement for each of these, and, depending on the problem you need to solve, you can combine these to arrive at an overall network design.

This chapter avoided all discussion of architecture, the better to focus on protocol and implementation details. The next chapter covers hub-and-spoke and RFC 2547 architectures.

Copyright © 2007 Pearson Education. All rights reserved.

Learn more about this topic

 
Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Related:

Copyright © 2007 IDG Communications, Inc.

1 2 3 4 5 Page 5
Page 5 of 5
SD-WAN buyers guide: Key questions to ask vendors (and yourself)