Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Example: Configuring Multitopology Routing for Class-Based Forwarding of Voice, Video, and Data Traffic

This example shows how to use multitopology routing (MTR) to choose a topology path based on an application, either voice or video.

Requirements

This example requires that Junos OS Release 9.0 or later is running on the provider core devices.

Overview

In this example, the network is running OSPF and internal BGP (IBGP) in the core, but not MPLS. Even without traffic engineering, voice traffic uses one set of links, and video traffic uses a different set of links. This traffic might or might not be destined for the same IP address. In some cases, both applications traverse the same link. The solution uses MTR-based OSPF and BGP, along with firewall filters to direct different traffic types over designated links. The routers use a fairly similar set of configurations, which reduces complexity and improves network management.

The OSPF topologies are defined to support each service offering over the OSPF area. The links of a topology must be contiguous, consistent with a typical OSPF area. IBGP routes in each routing topology automatically use the associated OSPF topology routing table for protocol next-hop route resolution. No special route resolution configurations are required. In this solution, multiple topologies can be configured over the same link. However, traffic in each application service class cannot traverse links unless they are configured for the topology designated for that service. Figure 1 shows a diagram of this case. Contiguous paths for routing the voice topology are shown with dotted lines, and paths for routing the video topology are shown with dashed lines.

For a complete set of configurations for all of the devices in the topology, see CLI Quick Configuration. The remainder of the example focuses on Device CE1 and Device PE1.

Figure 1 shows the sample topology.

Figure 1: Multitopology OSPF and IBGP for Designating Links Belonging to Voice and Video ServicesMultitopology OSPF and IBGP for Designating Links Belonging to Voice and Video Services

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Device CE1

Device CE2

Device PE1

Device PE2

Device P1

Device P2

Device P3

Device P4

Configuring Device CE1

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.

To configure Device CE1:

  1. Configure the interfaces.

    For demonstration purposes, the example places an Ethernet interface into loopback mode and configures several addresses on this loopback interface. The addresses are then announced to the network.

  2. Configure the external BGP (EBGP) connection to Device PE1.

  3. Configure the routing policy that announces the addresses that are configured on interface fe-0/1/0.

  4. Configure the routing policy that tags voice routes with the video community attribute, and video routes with the voice community attribute.

  5. Apply the set_community export policy so that direct routes are exported from the routing table into BGP.

    Apply the inject_directs export policy to announce the addresses that are configured on interface fe-0/1/0.

  6. Configure the autonomous system (AS) number.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, show policy-options, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

If you are done configuring the device, enter commit from configuration mode.

Configuring Device PE1

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.

To configure Device PE1:

  1. Configure the interfaces.

    The forwarding plane uses a firewall filter to indicate which topology forwarding table traffic should use. In this case, you must configure a firewall filter on all interfaces related to routing topologies. In general, all multitopology OSPF interfaces in the core where topologies are configured have input firewall filters. In addition, the ingress interfaces, where traffic from a CE device enters a PE device toward the core, have firewall filters configured. This configuration on Device PE1 shows a firewall filter applied to the ingress interface (connected to the CE device) and to the two core-facing interfaces (connected to Device P1 and Device P3).

  2. Configure the autonomous system (AS) number.

  3. Configure BGP.

  4. Configure a next-hop self routing policy to ensure that the IBGP devices use the loopback address on Device PE1 as the next-hop address on all IBGP route advertisements.

    This way, Device PE1 serves as the gateway router for EBGP routes.

  5. Apply the next-hop self policy to the IBGP sessions.

  6. Configure the voice and video topologies, which enable you to use these topologies with OSPF and BGP.

    The names voice and video are local to the router. The names are not propagated beyond this router. However, for management purposes, a consistent naming scheme across routers in a multitopology environment is convenient.

  7. Apply the community tags to identify the voice and video topologies by configuring a routing topology name and BGP community value.

    In Junos OS, multitopology support for BGP is based on the community value in a BGP route. This configuration determines the association between a topology and one or more community values and populates the topology routing tables. Arriving BGP updates that have a matching community value are replicated in the associated topology routing table. You decide which BGP community values are associated with a given topology.

    This configuration causes BGP updates that are received with community value target:40:40 to be added into topology routing table :voice.inet.0 (in addition to the default routing table inet.0). Updates that are received with community value target:50:50 are added into topology routing table :video.inet.0 (in addition to the default routing table inet.0).

  8. Enable and disable multitopology OSPF on particular interfaces.

    Enable multitopology OSPF designations only on desired interfaces, as shown in Figure 1. On interface fe-1/2/1.6 facing Device P1, enable the voice topology, and disable the video topology. On interface fe-1/2/2.9 facing Device P3, enable the video topology, and disable the voice topology.

    When a topology ID is configured under OSPF, the topology is automatically enabled on all interfaces under OSPF. To disable a topology or to add a metric, you must add an explicit configuration.

    For readability purposes, each topology is configured under each desired OSPF interface even though this default behavior occurs when the topology ID is configured. Configure higher metric values on a link to make the link less preferred than another available link.

  9. Configure the firewall filter.

    After routing topologies are configured, traffic must go through a firewall filter to make use of routing topology forwarding tables. For basic routing topologies, where traffic is first entering the core network, apply an input firewall filter to the ingress interface. Additionally, add firewall filters to interfaces where multitopology OSPF is configured. All routers must use the same firewall filter to associate packets with a topology to ensure consistent forwarding and to avoid routing loops or packet loss.

    The forwarding plane handles traffic as it enters the router and exits out a particular interface. To inspect traffic and use a specified topology forwarding table to perform next-hop lookups, configure an input firewall filter on each interface where routing topology support is desired. Use a regular firewall filter to identify packet characteristics.

    In general, for application-level differentiation, it is convenient to use DiffServ code points (DSCPs). When there is a firewall filter match, the firewall instructs the route lookup to use a particular topology forwarding table. Packet attributes are identified in the from clause, followed by a then clause indicating the topology forwarding table for use in forwarding next-hop lookups. This configuration notifies the router which traffic uses a routing topology forwarding table and which traffic uses the default forwarding table. The last term, which is named default, specifies the use of the default forwarding table.

    These firewall configurations show source addresses and DSCPs used to sort voice, video, and default traffic. DSCPs are practical because you can set them at or near a CE device and because the information is intact across the network. For instance, here class of service (CoS) is configured for expedited traffic. DSCPs are also practical when the same IP address is used for different applications.

  10. Enable CoS on the interfaces.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, show policy-options, show routing-options, show firewall, and show class-of-service commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

If you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Verifying the OSPF Interfaces

Purpose

Verify that the OSPF interfaces are configured to belong to one or more topologies.

Action

From operational mode, enter the show (ospf | ospf3) interface interface-name detail command.

Meaning

This output shows that the voice topology was added to the fe-1/2/1.6 interface on Device PE1. The topology name is voice, and the MT-ID is 126. The video topology is disabled on this interface. The cost of the interface is 10.

The Router-LSA originated and flooded by the router includes all relevant topology information for specific interfaces, such as MT-ID and metric. If MTR is not configured on an OSPF interface, then the Router-LSA does not include any topology information for that interface. OSPF neighbors might or might not support multitopology OSPF. That is, a particular link is not used to calculate OSPF routes for a topology unless routers at both ends of the link announce that link as part of the topology. If multitopology OSPF is not supported in neighboring OSPF routers or is not configured to do so, then topology information in LSAs received by the neighbor is ignored.

Verifying the Routes

Purpose

Make sure that the routes are in the expected routing tables and that the expected communities are attached to the routes.

Action

From operational mode, enter the show route detail command on Device PE1.

Meaning

This output shows BGP route 11.19.130.0/24 with community value target:40:40. Because the route matches the criteria for the voice topology, it is added to both the default and voice topology routing tables (inet.0 and :voice.inet.0). Device PE1 learns the route from Device CE1 through EBGP and then injects the route into IBGP.

Checking the Resolving BGP Next Hops

Purpose

Check the protocol next hop and forwarding next hop.

Action

From operational mode, enter the show route detail command on Device PE2.

Meaning

A typical IBGP core has BGP routes with protocol next hops that resolve using the underlying IGP routes. IBGP routes in a topology routing table have protocol next-hop IP addresses. By default, the same topology routing table is used to look up and resolve the protocol next-hop IP address to a forwarding next hop. This output from Device PE2 shows the same BGP route as seen in the previous example: 11.19.130.0/24. The route is being shown from a different perspective, that is, from Device PE2 as an IBGP route. Similarly, this IBGP route is added to both inet.0 and :voice.inet.0 on Device PE2. However, while each route has the same protocol next hop, each route has a different forwarding next hop (ge-0/0/3.0 instead of ge-0/1/4.0). The reason for this difference is when the protocol next-hop IP address 10.255.165.93 is resolved, it uses the corresponding routing table (inet.0 or :voice.inet.0) to look up the protocol next hop.

Examining the Protocol Next Hop

Purpose

Check the protocol next hop and forwarding next hop.

Action

From operational mode, enter the show route command on Device PE2.

Meaning

This output from Device PE2 shows the protocol next hop of 11.19.130.0/24, which is IP address 10.255.165.93, thus further demonstrating how IBGP route 11.19.130.0/24 resolves its protocol next hop. The forwarding next hops of 10.255.165.93 match the IBGP forwarding next hops of route 11.19.130/24 as shown in the previous example. Observe here that the IP address 10.255.165.93 is also in routing table :video.inet.0. This address is the loopback address of Device PE1, and as such, resides in all three routing tables. This example also shows how traffic entering Device PE2 destined to 11.19.130.0/24 exits out different interfaces depending on its associated topology. The actual traffic is marked in such a way that a firewall filter can direct the traffic to use a particular topology routing table.

Verifying the OSPF Neighbor

Purpose

Make sure that the expected topologies are enabled on the OSPF neighbor.

Action

From operational mode, enter the show ospf neighbor 10.0.0.21 extensive command on Device P2.

Meaning

This Device P2 output shows OSPF neighbor PE2 (10.0.0.21), where multitopology OSPF default and video are multitopology OSPF participants. The Bidirectional flag shows that the neighbor is configured using the same multitopology OSPF ID.

Checking the Router LSA

Purpose

Check the links where video and voice topologies are enabled.

Action

From operational mode, enter the show ospf database lsa-id 10.255.165.203 extensive command on Device P2.

Meaning

This Device P2 output shows the Router-LSA originated by Device PE2. The LSA shows links where video and voice topologies are enabled (in addition to the default topology).

Checking How Traffic Traverses the Network

Purpose

Make sure that the expected paths are used.

Action

From operational mode, enter the traceroute command on Device CE1.

The first example output shows a traceroute over the voice topology goes from Device CE1 to Device CE2 where DSCPs are set. The routes are resolved over :voice.inet.0. This traceroute path follows the voice path CE1-PE1-P1-P2-PE2-CE2

This output shows a traceroute from Device CE1 to Device CE2 for voice where no DSCPs are set. The routes are resolved over inet.0, and the resulting path is different from the previous case where the DSCPs are set. This traceroute path follows the default path CE1-PE1-P4-PE2-CE2.

This output shows a traceroute from Device CE1 to Device CE2 for video traffic where the firewall filter is based on the destination address. The routes are resolved over :video.inet.0 . This traceroute follows the video path CE1-PE1-P3-P4-PE2-CE2.

This output shows a traceroute from Device CE1 to Device CE2 for video where DSCPs are set. The DSCP bits are directing Device PE1 to use the topology table :voice.inet.0. Because there is no entry in the voice routing table for video routes, traffic is dropped.