[an error occurred while processing this directive][an error occurred while processing this directive]

Example: Multitopology Routing Configuration

In this example, an MPLS network is running RSVP label-switched paths (LSPs) in the core. The network carries both best effort (BE) and expedited forwarding (EF) traffic, and the same destination prefixes are used for both types of traffic. A voice topology is created to enable the network to send EF traffic over the LSPs, but permit BE traffic to traverse the IP path. The voice, or EF traffic, is placed in the voice topology. The data, or BE traffic, is placed in the default topology. The voice and default topologies each create separate routing tables for storing routes, and each routing table creates a separate forwarding table. For each destination prefix, a different route is added to each topology-specific routing table. These routes are BGP routes. You configure filter-based forwarding so that the destination lookup is done in the two topology-specific routing tables based on the DSCP marking of the incoming packet. As Figure 1 shows, MTR thus enables you to build two routes to the destination prefixes, one using LSP next hops for voice traffic and one using IP next hops for data traffic. The protocol next hop is resolved differently for each type of traffic. For voice EF traffic, routes from the inet.3 routing table are taken into account, and for BE data traffic, only routes from the inet.0 routing table are taken into account.

Figure 1: Route Resolution in Multitopology Routing

Image g016894.gif

Configure the interfaces:

[edit]interfaces {so-0/0/1 {unit 0 {family inet {address 1.13.1.1/24}family iso;family mpls;}}fe-2/2/0 {unit 0 {family inet {address 1.12.1.1/24}family iso;family mpls;}}fe/2/2/1 {unit 0 {family inet {filter {input topo_selection; # Apply a firewall filter on the ingress interface.
# This filter performs filter-based forwarding for the voice topology.
}
family iso;family mpls;}
}
}

Configure the voice topology. Configure a route resolution policy so that IPv4 routes for data traffic are resolved through the inet.0 routing table, which functions as the routing table for the default topology. Configure a route resolution policy so that routes for voice traffic are resolved through the routing table for the voice topology (:voice.inet.0) and the MPLS routing table (inet.3).

[edit]routing-options {autonomous-system 65300;resolution {rib inet.0 {resolution-ribs inet.0; # Specify use of the inet.0 routing table to resolve
# IPv4 data traffic. This action prevents this traffic from being resolved using
# the MPLS routing table (inet.3).
}
rib :voice.inet.0 {resolution-ribs [ inet.3 :voice.inet.0 ]; # Specify use of the MPLS routing
# table (inet.3) and the routing table for the voice topology (:voice.inet.0)
# to resolve IPv4 voice traffic. This action prevents voice traffic from being
#resolved using the inet.0 routing table.
}
}
topologies {family inet {topology voice;}}}

Configure MPLS using RSVP label-switched paths. Configure BGP so that routes learned through BGP are installed in the appropriate routing table. In this example, the topology statement is used to install BGP routes for voice traffic into the routing table for the voice topology (:voice.inet.0). This action overrides the default behavior to resolve BGP routes only through the inet.0 or inet.3 routing tables. Configure an interior gateway protocol (IGP). In this example, you configure OSPF.

[edit]protocols {rsvp {interface all;interface fxp0.0 {disable;}}mpls {label-switched-path to_r3 {to 10.255.14.222;primary test;}path test {1.12.1.2 strict;}interface all;}bgp {group int {type internal;local-address 10.255.14.223;family inet {unicast {topology voice {community 70:1;}}}neighbor 10.255.14.220;neighbor 10.255.14.218;neighbor 10.255.14.222;}}ospf {topology voice topology-id 32;traffic-engineering;area 0.0.0.0 {interface lo0.0 {passive;}interface all;interface fxp0.0 {disable;}interface fe-2/2/1.0 {metric 1;}interface fe-2/2/0.0 {metric 1;}interface so-0/0/1.0 {metric 1;}}}}

Configure a class-of-service classifier on the ingress interface. In this example, the classifier type is inet-precedence, which evaluates incoming IPv4 packets and requires only the upper three bits of the DSCP field.

[edit]class-of-service {interfaces {fe-2/2/1 {unit 0 {classifiers {inet-precedence default;}}}}}

Configure filter-based forwarding. This filter is applied to the ingress interface. Traffic marked for expedited forwarding is forwarded to the routing table for the voice topology. All other traffic is forwarded to the routing table for the default topology.

[edit]firewall {family inet {filter topo_selection {term ef {from {forwarding-class expedited-forwarding;}then {topology voice; # Forward expedited-forwarding traffic to the routing
# table for the voice topology (:voice.inet.0).
accept;}
}
term default {then accept; # Forward all other traffic to the routing table for the default
# topology (inet.0).
}
}
}
}

Verifying Your Work

To verify proper operation of Multitopology Routing, use the following commands:

  • show route summary
  • show route table routing-table-name
  • show route rib-groups

Published: 2010-04-15

[an error occurred while processing this directive]