Understanding Multitopology Routing
Multitopology routing 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.
Service providers and enterprises can use multitopology routing (MTR) to engineer traffic flow across a network. MTR can be used with direct and static routes, OSPF, and BGP. MTR can be configured for unicast and multicast IP, using the Junos® operating system (Junos OS). With basic unicast IP, an IBGP core runs on top of OSPF to direct traffic based on application types, such as voice or video. For multicast, Protocol Independent Multicast (PIM) is used, in conjunction with multitopology OSPF and BGP, to direct multicast traffic over particular paths based on traffic characteristics.
In a network carrying multiple traffic types, you often need to direct different types of application traffic over multiple links depending on their link characteristics. For example, voice traffic requires links that are less likely to incur latency, jitter, or packet loss. File traffic, on the other hand, requires links that have large amounts of available bandwidth. MTR is a way to direct traffic to follow specified paths. You can use MTR to extend a traditional MPLS network into a segment where only IP forwarding is supported. With MTR, each traffic type is handled in its own conceptually incongruent topology, and yet runs on top of the same underlying network. You can configure separate topologies to share the same network links as needed. MTR uses a combination of control plane (routing) and forwarding plane (firewall filters). Each topology uses the unified control plane to make routing decisions for traffic associated with that topology. In addition, each topology has a separate forwarding table and, in effect, a dedicated forwarding plane for each topology. This forwarding plane not only directs traffic using its own forwarding table, but also simultaneously handles sophisticated functionality, such as queuing for class of service (CoS), that can be applied to a topology. As traffic enters the router, fields within a packet determine to which topology the traffic belongs.
Multitopology routing 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.
One way to manage traffic flow is to group links into specific routing topologies based on application requirements. Each routing topology can be thought of as of a set of contiguous links. MTR provides a way for you to manage each set of links uniquely by directing traffic types to flow over specified links. This solution uses a combination of routing (control plane) and firewall filtering (forwarding plane) configurations. Figure 1 shows a network with two topologies configured: voice (dotted lines) and video (dashed lines). Note there is also a default routing topology (solid line).
You can configure MTR for BGP, OSPF, and static routes. When a routing topology is created, it has its own forwarding table.
Packet forwarding uses firewall filters to examine packets as they enter the router over an interface. These filters determine whether a specific topology or the default forwarding table should be used to make packet forwarding decisions. If applicable, firewall filters evaluate packet attributes, such as destination IP address, Differentiated Services code points (DSCPs), or next-level protocol headers, to determine which topology to use. In fact, any item in a packet that is recognized by a firewall filter can be used to direct the packet next-hop lookup to use a particular topology. Once the packet is directed to use a topology, the destination IP address must be in the topology forwarding table. Otherwise, the packet is dropped.
The following topics provide background information about multitopology routing:
Routing Table Naming Conventions for Multitopology Routing
Routing topologies have their own routing tables, similar to
any other routing table created by default or by a rib-group configuration with a few differences. The routing table name indicates
that the routing table is associated with a topology by prepending
a colon (:) to the name. For example, a routing topology
named voice has a routing table named :voice.inet.0. When
routing topologies are configured under routing-options, a new routing table for each topology is created.
Each routing protocol creates a routing table based on the topology name, the instance name, and the purpose of the table. A routing table for each topology uses the following format:
logical-system-name/routing-instance-name:topology-name.protocol.identifier
The routing instance string is included only if the instance
is not the primary. The logical system string is included only if
the logical system identifier has a value other than 0 (zero).
Each routing table for a topology includes a colon (:) before the
topology name that also separates the routing-instance name from the
topology name. protocol is the protocol
family, which can be inet or inet6. identifier is a positive integer that specifies
the instance of the routing table. Table 1 shows specific examples of routing tables for various topologies.
Name of Routing Table |
Description |
|---|---|
|
Master instance, voice topology, unicast IPv4 routes |
|
Master instance, voice topology, unicast IPv6 routes |
|
Master instance, voice topology, ingress label-switched paths (LSPs) |
|
Logical system private, voice topology, unicast IPv4 routes |
|
Virtual-router customer-A, voice topology, unicast IPv4 routes |
|
Virtual-router customer-B, voice topology, ingress LSPs |
|
Virtual-router customer-A, voice topology, unicast carrier-of-carriers IPv4 routes |
To run multitopology routing (MTR), you must configure IP routing. MTR supports OSPF version 2 (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 is also supported on logical systems and the virtual router routing instance. No other routing instance type is supported on MTR.
Filter-Based Forwarding Support
By default, the ingress interface forwards traffic to the default topology for each configured routing instance. MTR 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. You can further define how traffic is handled for each forwarding class by configuring additional firewall filters that match traffic for such values as the IP precedence field or the Differentiated Services code point (DSCP).