Understanding Multitopology Routing for Class-Based Forwarding of Voice, Video, and Data Traffic
Multitopology routing (MTR) enables you to configure class-based forwarding for different types of traffic, such as voice, video, and data. Each type of traffic is defined by a topology that is used to create a new routing table for that topology. MTR provides the ability to generate forwarding tables based on the resolved entries in the routing tables for the custom topologies you create. In this way, packets of different classes can be routed independently from one another.
To run MTR, you must configure IP routing. MTR supports OSPFv2, static routes, and BGP. You must configure an interior gateway protocol (IGP), such as OSPFv2 or static routing, Configure BGP to add routes learned through BGP to the appropriate custom topologies. MTR also supports filter-based forwarding, which enables you to match traffic on the ingress interface with a specific type of forwarding class and then forward that traffic to the specified topology.
OSPF in MTR
OSPF in MTR uses a single instance of OSPF to carry connectivity and IP reachability information for different topologies. That information is used to calculate shortest-path-first (SPF) trees and routing tables. OSPF for MTR supports protocol extensions that include metrics that correspond to different topologies for link and prefix reachabilty information. The type-of-service (TOS) metric field is used to advertise the topology-specific metric for links and prefixes belonging to that topology. The TOS field is redefined as MT-ID in the payload of router, summary, and Type 5 and Type 7 AS-external link-state advertisements (LSAs).
Under MTR, each OSPF interface continues to belong to a single area. Therefore, by default, all topologies share the same area boundaries. As a result, attributes of an area, such as stubbiness, are independent of the topology. By default, all topologies configured for OSPF are enabled on all interfaces. However, you can disable one or more configured topologies on an interface. You can thus allocate an interface for a specific topology. In Figure 1, Area 51 includes an interface that is uniquely allocated to voice traffic, and Area 0 includes an interface that is uniquely allocated to data traffic. Each topology thus corresponds to a different OSPF area that shares a boundary.
BGP in MTR
BGP in MTR provides the ability to resolve BGP routes against
configured topologies. An inbound policy is used to select routes
for inclusion in the appropriate routing tables for the topologies.
The default behavior for virtual private networks (VPNs) that use
MPLS for forwarding packets over the backbone and that use BGP for
distributing routes over the backbone is to place BGP route updates
in the bgp.l3vpn routing table. Figure 2 shows a BGP peer operating in an environment that conforms
with the requirements in RFC 2547, BGP/MPLS VPNs. The figure shows how a BGP peer configured for MTR performs secondary
route resolution.
The BGP peer in a standard VPN topology places prefixes for
routes it learns in the bgp.l3vpn routing table, which
does not result in automatic updates to the forwarding table. Under
BGP in MTR, when BGP receives a route from a peer, it attempts to
resolve that route against a route in the inet.0 routing
table. If the route is resolved, it is placed in that table, which
generates a forwarding state. If you have configured a community target
identifier that matches the import policy for the topology, routing
and forwarding states are added to the tables for the topology.
Because MTR provides support for BGP to perform secondary route resolution, as Figure 3 shows, MTR is able to create two distinct network paths for each type of traffic. Each router advertises BGP routes that need to be resolved against the IGP routes for each topology. Based on the IGP metrics configured for each topology, for all routes that originate from Router 4 (R4), the upper path between R1 and R4, which traverses R2 and R3, is selected for voice traffic, whereas the lower path between R1 and R4, which traverses R5 and R6, is selected for data traffic.
