Control-Plane VirtualizationRouting 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 alsoit'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.