Use Multitopology Routing (MTR) to configure service differentiation through class-based forwarding. Two primary components comprise MTR configuration: independent topology configuration and traffic classification configuration.

A topology is defined as a subset of devices and links in a network for which a separate set of routes is calculated. The entire network itself, for which the usual set of routes is calculated, is known as the base topology. The base topology (or underlying network) is characterized by the Network Layer Reachability Information (NLRI) that a device uses to calculate the global routing table to make routing and forwarding decisions. The base topology is the default routing environment that exists prior to enabling MTR.

Any additional topologies are known as class-specific topologies and are a subset of the base topology. Each class-specific topology carries a class of traffic and is characterized by an independent set of NLRI that is used to maintain a separate Routing Information Base (RIB) and Forwarding Information Base (FIB). This design allows the device to perform independent route calculation and forwarding for each topology.

MTR creates a selection of routes within a given device upon which to forward to a given destination. The specific choice of route is based on the class of the packet being forwarded, a class that is an attribute of the packet itself. This design allows packets of different classes to be routed independently from one another. The path that the packet follows is determined by classifiers configured on the devices and interfaces in the network. The figure below shows a base topology, which is a superset of the red, blue, and green topologies.

Figure 1. MTR Base Topology

The figure below shows an MTR-enabled network that is configured using the service separation model. The base topology (shown in black) uses NLRI from all reachable devices in the network. The blue, red, and purple paths each represent a different class-specific topology. Each class-specific topology calculates a separate set of paths through the network. Routing and forwarding are independently calculated based on individual sets of NLRI that are carried for each topology.

Figure 2. Defining MTR Topologies

The figure below shows that the traffic is marked at the network edge. As the traffic traverses the network, the marking is used during classification and forwarding to constrain the traffic to its own colored topology.

Figure 3. Traffic Follows Class-Specific Forwarding Paths

The same topology can have configured backup paths. In the figure below, the preferential path for the voice topology is represented by the solid blue line. In case this path becomes unavailable, you can configure MTR to choose the voice backup path represented by the dotted blue line. Both of these paths represent the same topology and none overlap.

Figure 4. MTR Backup Contingencies Within a Topology

The figure below shows the MTR forwarding model at the system level. When a packet arrives at the incoming interface, the marking is examined. If the packet marking matches a topology, the associated topology is consulted, the next hop for that topology is determined, and the packet is forwarded. If there is no forwarding entry within a topology, the packet is dropped. If the packet does not match any classifier, it is forwarded to the base topology. The outgoing interface is a function of the colored route table in which the lookup is done.

Figure 5. MTR Forwarding at the System Level

MTR is implemented in Cisco software according to a address family and subaddress family basis. MTR supports up to 32 unicast topologies (including the base topology) and a separate multicast topology. A topology can overlap with another or share any subset of the underlying network. You configure each topology with a unique topology ID. You configure the topology ID under the routing protocol, and the ID is used to identify and group NLRI for each topology in updates for a given protocol.

Cisco software supports legacy (pre-Multitopology Routing (MTR) IP multicast behavior by default. MTR support for IP multicast must be explicitly enabled. Legacy IP multicast uses reverse path forwarding (RPF) on routes in the unicast Routing Information Base (RIB) to build multicast distribution trees (MDTs).

MTR introduces a multicast topology that is completely independent from the unicast topology. MTR integration with multicast allows you to control the path of multicast traffic in the network.

The multicast topology maintains separate routing and forwarding tables. The following list summarizes MTR multicast support that is integrated into Cisco software:

• Conventional longest match support for multicast routes.
• RPF support for Protocol Independent Multicast (PIM).
• Border Gateway Protocol (BGP) MDT subaddress family identifier (SAFI) support for Inter-AS VPNs (SAFI number 66).
• Support for static multicast routes integrated into the ip route topology command (modifying the ip mroute command).

As in pre-MTR software, you enable multicast support by configuring the ip multicast-routing command in global configuration mode. You enable MTR support for multicast by configuring the ip multicast rpf multitopology command. After the device enters global address family configuration mode, you then enter the topology command with the base keyword; global topology configuration parameters are applied in this mode.

Multitopology Routing (MTR) cannot be enabled on a device until traffic classification is configured, even if only one class-specific topology is configured. Traffic classification is used to configure topology-specific forwarding behaviors when multiple topologies are configured on the same device. Traffic classification must be applied consistently throughout the network. Class-specific packets are associated with the corresponding topology table forwarding entries.

Traffic classification is configured when you use the modular quality of service (QoS) CLI (MQC). MTR traffic classification is similar to QoS traffic classification. However, there is an important distinction. MTR traffic classification is defined globally for each topology, rather than at the interface level as in QoS.

A subset of differentiated services code point (DSCP) bits is used to encode classification values in the IP packet header. You configure a class map to define the traffic class by entering the class-map class-map-name command in global configuration mode. Only the match-any keyword is supported for MTR. You associate the traffic class with a policy by configuring the policy-map type class-routing ipv4 unicast command in global configuration mode. You activate the policy for the topology by configuring the service-policy type class-routing command in global address family configuration mode. Then you associate the service policy with all interfaces on the device.

You can configure MTR traffic classification and IP Differentiated Services or IP Precedence-based traffic classification in the same network. However, MTR requires exclusive use of some subset of the DSCP bits in the IP packet header for specific topology traffic. In a network where MTR and QoS traffic classification are configured, you must carefully coordinate simultaneous configuration.

You must enable IP routing on the device for Multitopology Routing (MTR) to operate. MTR supports static and dynamic routing in Cisco software. You can enable dynamic routing per topology to support interdomain and intradomain routing. Route calculation and forwarding are independent for each topology. MTR support is integrated into Cisco software for the following protocols:

• Border Gateway Protocol (BGP)
• Enhanced Interior Gateway Routing Protocol (EIGRP)
• Integrated Intermediate System-to-Intermediate System (IS-IS)
• Open Shortest Path First (OSPF)

You apply the per-topology configuration in router address family configuration mode of the global routing process (router configuration mode). The address family and subaddress family are specified when the device enters address family configuration mode. You specify the topology name and topology ID by entering the topology command in address family configuration mode.

You configure each topology with a unique topology ID under the routing protocol. The topology ID is used to identify and group Network Layer Reachability Information (NLRI) for each topology in updates for a given protocol. In OSPF, EIGRP, and IS-IS, you enter the topology ID during the first configuration of the topology command for a class-specific topology. In BGP, you configure the topology ID by entering the bgp tid command under the topology configuration.

You can configure class-specific topologies with different metrics than the base topology. Interface metrics configured on the base topology can be inherited by the class-specific topology. Inheritance occurs if no explicit inheritance metric is configured in the class-specific topology.

You configure BGP support only in router configuration mode. You configure Interior Gateway Protocol (IGP) support in router configuration mode and in interface configuration mode.

By default, interfaces are not included in nonbase topologies. For routing protocol support for EIGRP, IS-IS, and OSPF, you must explicitly configure a nonbase topology on an interface. You can override the default behavior by using the all-interfaces command in address family topology configuration mode. The all-interfaces command causes the nonbase topology to be configured on all interfaces of the device that are part of the default address space or the virtual routing and forwarding (VRF) instance in which the topology is configured.

The configuration of a Multitopology Routing (MTR) topology in interface configuration mode allows you to enable or disable MTR on a per-interface basis. By default, a class-specific topology does not include any interfaces.

You can include or exclude individual interfaces by configuring the topology interface configuration command. You specify the address family and the topology (base or class-specific) when entering this command. The subaddress family can be specified. If no subaddress family is specified, the unicast subaddress family is used by default.

You can include globally all interfaces on a device in a topology by entering the all-interfaces command in routing topology configuration mode. Per-interface topology configuration applied with the topology command overrides global interface configuration.

The interface configuration support for MTR has these characteristics:

• Per-interface routing configuration: Interior Gateway Protocol (IGP) routing and metric configurations can be applied in interface topology configuration mode. Per-interface metrics and routing behaviors can be configured for each IGP.
• Open Shortest Path First (OSPF) interface topology configuration: Interface mode OSPF configurations for a class-specific topology are applied in interface topology configuration mode. In this mode, you can configure an interface cost or disable OSPF routing without removing the interface from the global topology configuration.
• Enhanced Interior Gateway Routing Protocol (EIGRP) interface topology configuration: Interface mode EIGRP configurations for a class-specific topology are applied in interface topology configuration mode. In this mode, you can configure various EIGRP features.
• Intermediate System-to-Intermediate System (IS-IS) interface topology configuration: Interface mode IS-IS configurations for a class-specific topology are applied in interface topology configuration mode. In this mode, you can configure an interface cost or disable IS-IS routing without removing the interface from the global topology configuration.

The base topology is the superset of all topologies in the network. It is defined by Network Layer Reachability Information (NLRI) for all reachable devices regardless of the deployment model that is used. Multitopology Routing (MTR) can be deployed using the service separation MTR model, or it can deployed using the overlapping MTR model. Each model represents a different approach to deploying MTR. However, these models are not mutually exclusive. Any level of variation of a combined model can be deployed.

Multitopology Routing (MTR) supports both full and incremental deployment configurations. To support these options, MTR provides two different, configurable forwarding rules: strict forwarding mode for full deployment and incremental forwarding mode for an incremental deployment.

The section provides guidelines and procedures for enabling or disabling Multitopology Routing (MTR) in a production network. These guidelines assume that all participating networking devices are running a software image that supports MTR. The guidelines are designed to prevent major traffic interruptions due to misconfiguration and to minimize temporary transitional effects that can occur when you introduce or remove a topology from a network. The following guidelines must be implemented in the order that they are described:

First, create a class-specific topology on all networking devices and enable incremental forwarding mode by entering the forward-base command in address family topology configuration mode. Configure incremental forwarding whenever a topology is introduced or removed from the network. The topology is defined as a global container at this stage. No routing or forwarding can occur within the topology. Routing protocol support should not be configured.

Second, configure classification rules for the class-specific topology. You must consistently apply classification on all devices in the topology; each device has identical classifier configuration. You activate the topology when you attach a valid classification configuration to the global topology configuration. You can use ping and traceroute commands to verify reachability for interfaces and networking devices that are in the same topology and configured with identical classification.

Third, configure routing protocol support and static routing. Configure the devices in the topology one at a time. This configuration should include an interface, router process, and routing protocol-specific metrics and filters.

Enable routing in the topology by using a physical pattern in a contiguous manner relative to a single starting point. For example, configure all interfaces on a single device, and then all interfaces on each adjacent device. Follow this pattern until the task is complete. The starting point can be on the edge or core of the network. This recommendation is designed to increase the likelihood that class-specific traffic is forwarded on the same paths in the incremental topology as it is on the full topology when MTR is completely deployed.

If your network design requires strict forwarding mode, you should disable incremental forwarding only after you configure routing on all devices in a given topology. At this stage, MTR is fully operational. Class-specific traffic is forwarded only over devices within the topology. Traffic that is not classified or destined for the topology is dropped.

When disabling a topology, reenable incremental forwarding mode. Remove custom route configuration, such as route summarization and default routes before disabling a topology, and reapply custom route configuration only after the topology is reenabled. This recommendation is designed to prevent traffic interruption because some destinations might be obscured during the transition. Custom route configuration is most useful when all of the more-specific routes are available in the routing table of the topology.

Note	These guideliens apply only when a given classifier is enabled or disabled for a given topology. All other MTR configuration, including interface and routing protocol-specific configuration (other than the topology ID) can be modified dynamically as necessary.

1.    enable


2.    configure terminal


3.    ip multicast-routing [vrf name]


4.    ip multicast rpf multitopology


5.    global-address-family ipv4 [multicast | unicast]


6.    topology {base | topology-name}


7.    route-replicate from {multicast | unicast} [topology {base | name}] protocol [route-map name | vrf name]


8.    use-topology unicast {base | topology-name}


9.    shutdown


10.    end


11.    show topology [cache [topology-id] | ha [detail | interface | lock | router] [all | ipv4 | ipv6 | vrf vpn-instance]]

Device> enable 

Device# configure terminal 

Device(config)# ip multicast-routing 

Device(config)# ip multicast rpf multitopology 

Device(config)# global-address-family ipv4 multicast

Device(config-af)# topology base 

Device(config-af-topology)# route-replicate from unicast topology VOICE ospf route-map map1

Device(config-af-topology)# use-topology unicast VIDEO 

Device(config-af-topology)# shutdown 

Device(config-af-topology)# end 

Device# show topology detail

Before You Begin

Note	Following the correct order of the commands in this task is very important. Ensure that all configuration that affects traffic classification is complete before entering the service-policy type class-routing command.

1.    enable


2.    configure terminal


3.    class-map match-any class-map-name


4.    match [ip] dscp dscp-value [dscp-value dscp-value dscp-value dscp-value dscp-value dscp-value dscp-value]


5.    exit


6.    policy-map type class-routing ipv4 unicast policy-map-name


7.    class {class-name | class-default}


8.    select-topology topology-name


9.    exit


10.    exit


11.    global-address-family ipv4 [multicast | unicast]


12.    service-policy type class-routing policy-map-name


13.    end


14.    show topology detail


15.    show policy-map type class-routing ipv4 unicast [interface [type number]]


16.    show mtm table

Device> enable

Device# configure terminal

Device(config)# class-map match-any VOICE-CLASS 

Device(config-cmap)# match ip dscp 9 

Device(config-cmap)# exit 

Device(config)# policy-map type class-routing ipv4 unicast VOICE-CLASS-POLICY 

Device(config-pmap)# class VOICE-CLASS 

Device(config-pmap-c)# select-topology VOICE 

Device(config-pmap-c)# exit 

Device(config-pmap)# exit 

Device(config)# global-address-family ipv4 

Device(config-af)# service-policy type class-routing VOICE-CLASS-POLICY 

Device(config-af)# end 

Device# show topology detail

Device# show policy-map type class-routing ipv4 unicast

Device# show mtm table

Perform this task to activate a Multitopology Routing (MTR) topology inside an address family by using the Border Gateway Protocol (BGP). This task is configured on Device B in the figure below and must also be configured on Device D and Device E. In this task, a scope hierarchy is configured to apply globally, and a neighbor is configured in router scope configuration mode. Under the IPv4 unicast address family, an MTR topology that applies to video traffic is activated for the specified neighbor. There is no interface configuration mode for BGP topologies.

Figure 8. BGP Network Diagram

1.    enable


2.    configure terminal


3.    router bgp autonomous-system-number


4.    scope {global | vrf vrf-name}


5.    neighbor {ip-address | peer-group-name} remote-as autonomous-system-number


6.    neighbor {ip-address | peer-group-name} transport {connection-mode {active | passive} | path-mtu-discovery | multi-session | single-session}


7.    address-family ipv4 [mdt | multicast | unicast]


8.    topology {base | topology-name}


9.    bgp tid number


10.    neighbor ip-address activate


11.    neighbor {ip-address | peer-group-name} translate-topology number


12.    end


13.    clear ip bgp topology {* | topology-name} {as-number | dampening [network-address [network-mask]] | flap-statistics [network-address [network-mask]] | peer-group peer-group-name | table-map | update-group [number | ip-address]} [in [prefix-filter] | out | soft [in [prefix-filter] | out]]


14.    show ip bgp topology {* | topology} summary

Device> enable 

Device# configure terminal 

Device(config)# router bgp 45000 

Device(config-router)# scope global 

Device(config-router-scope)# neighbor 172.16.1.2 remote-as 45000

Device(config-router-scope)# neighbor 172.16.1.2 transport multi-session

Device(config-router-scope)# address-family ipv4 

Device(config-router-scope-af)# topology VIDEO 

Device(config-router-scope-af-topo)# bgp tid 100

Device(config-router-scope-af-topo)# neighbor 172.16.1.2 activate

Device(config-router-scope-af-topo)# neighbor 172.16.1.2 translate-topology 200 

Device(config-router-scope-af-topo)# end 

Device# clear ip bgp topology VIDEO 45000

Device# show ip bgp topology VIDEO summary

1.    enable


2.    configure terminal


3.    ip prefix-list list-name [seq number] {deny | permit} network/length [ge ge-length] [le le-length]


4.    route-map map-name [permit | deny] [sequence-number]


5.    match ip address {access-list-number [access-list-number ... | access-list-name...] | access-list-name [access-list-number ... | access-list-name] | prefix-list prefix-list-name [prefix-list-name...]}


6.    exit


7.    router bgp autonomous-system-number


8.    scope {global | vrf vrf-name}


9.    address-family ipv4 [mdt | multicast | unicast]


10.    topology {base | topology-name}


11.    import topology {base | topology-name} [route-map map-name]


12.    end

Device> enable 

Device# configure terminal 

Device(config)# ip prefix-list TEN permit 10.2.2.0/24

Device(config)# route-map 10NET

Device(config-route-map)# match ip address prefix-list TEN

Device(config-route-map)# exit

Device(config)# router bgp 50000 

Device(config-router)# scope global 

Device(config-router-scope)# address-family ipv4 

Device(config-router-scope-af)# topology VIDEO 

Device(config-router-scope-af-topo)# import topology VOICE route-map 10NET

Device(config-router-scope-af-topo)# end 

Before You Begin

Define a topology globally before configuring the per-interface topology configuration.

Note	Interfaces cannot be excluded from the base topology by design. However, an Interior Gateway Protocol (IGP) can be excluded from an interface in a base topology configuration.

1.    enable


2.    configure terminal


3.    interface type number


4.    topology ipv4 [multicast | unicast] {topology-name [disable] | base}


5.    end

Device> enable

Device# configure terminal

Device(config)# interface Ethernet 0/0 

Device(config-if)# topology ipv4 VOICE 

Device(config-if-topology)# end 

1.    enable


2.    ping [vrf vrf-name | topology topology-name] protocol [target-address] [source-address]


3.    traceroute [vrf vrf-name | topology topology-name] [protocol] destination

Device> enable

Device# ping topology VOICE ip

Device# traceroute VOICE