Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Example: Configuring Multitopology Routing to Provide Redundancy for Multicast Traffic over Separate Network Paths

 

This example shows how to use multitopology routing (MTR) to provide redundancy for multicast traffic over separate network paths. That is, two multicast sources send the same multicast stream, yet for redundancy purposes in the case of link failure, the two streams use disjoint paths.

Note

Note there is no standard defined at this time for using MTR extensions to PIM.

Requirements

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

Overview

Assume that each source providing redundant multicast streams, S1 and S2, have different IP subnet addresses. Each source sends multicast traffic using different groups: G1 and G2. Further, assume that S1 and S2 are attached to the same customer edge (CE) device and use BGP to announce routes to the provider edge (PE) router.

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 BGP for Designating Links Belonging to Voice and Video Services
Multitopology OSPF and BGP 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 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 as direct routes. These routes simulate a group of BGP routes with communities attached.

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

    The CE router nearest to the multicast servers announces the multicast source IP addresses to the PE routers using EBGP. The source addresses are announced with both family inet unicast and family inet multicast, thus causing the BGP route to be added to the default routing table, inet.0, and to the multicast routing table, inet.2. Both sets of routes are injected by the PE router into IBGP.

  3. Configure PIM on the interfaces.
  4. Configure the routing policy that announces the addresses that are configured on interface fe-0/1/0.
  5. Configure the routing policy that tags some routes with the red community attribute and other routes with the blue community attribute.

    The CE router advertises routes through EBGP to the PE router. These routes are advertised as BGP family inet multicast routes with communities set for two different groups. Policies identify the two groups of BGP routes.

  6. Apply the set_community export policy so that the direct routes are exported into BGP.

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

  7. Use rib-groups to simulate a group of BGP routes with communities attached and announced as multicast routes.

    This configuration creates a multicast routing table and causes PIM to use the multicast routing table inet.2.

  8. 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 CLI User Guide.

To configure Device PE1:

  1. Configure the interfaces.
  2. Configure secondary addresses, 1.1.1.30 and 2.2.2.30.

    A specific protocol next-hop IP address is required for each topology on each router injecting IBGP routes. You can configure multiple secondary loopback IP addresses on a router to be used as protocol next-hop addresses. This configuration shows nonprimary IP addresses 1.1.1.30/32 and 2.2.2.30/32 configured on loopback interface lo0 for use in the red and blue topologies, respectively.

    A group of BGP routes associated with a routing topology use the same unique protocol next hop. For instance, if you configure a PE router to handle two routing topologies, then you would also configure two unique nonprimary addresses under loopback interface lo0.

  3. Associate each nonprimary loopback IP address with a topology for inclusion in the associated topology routing table.

    Configure the loopback IP address and topology under an OSPF interface statement. You must specifically disable all other topologies known to OSPF for two reasons. First, the loopback address specific to a topology must reside in only one topology routing table. Second, once the topology is added to OSPF, the topology defaults to being enabled on all subsequent interfaces under OSPF.

    The Device PE1 configuration places the loopback address 1.1.1.30/32 into the OSPF database as a stub route under this router’s OSPF Router-LSA. It belongs to the red and default topologies, but not to the blue topology. The loopback address 1.1.1.30/32 is installed in the remote core routers’ topology routing tables inet.0 and :red.inet.0, (but not in :blue.inet.0). Use a similar configuration for the blue loopback address 2.2.2.30/32.

  4. Enable OSPF on the interfaces, and configure specific OSPF link metrics on topologies to identify paths and build trees to different servers.

    Links can support all routing topologies to provide backup should a primary multicast path fail.

    When a multicast tree gets built through PIM join messages directed toward the source, it follows the most preferred path. A multicast tree to a different multicast source (in a different routing topology) can create another tree along a different path.

  5. Create the multicast routing table inet.2, and configure PIM to use the inet.2 routing table.

    Set up a separate routing table for multicast lookups. It is populated with routes from inet.2. The inet.2 routing table is populated by routes of type multicast.

  6. Configure PIM to use the routes in inet.2.
  7. Enable PIM on the interfaces.
  8. Configure the router to perform route resolution on protocol next hops using specified routing tables.

    The protocol next hop is used to determine the forwarding next-hop interface out of which to forward PIM join messages. This configuration directs inet.2 route resolution to use topology routing tables :red.inet.0 and :blue.inet.0 for protocol next-hop IP address lookups.

    You can specify up to two routing tables in the resolution configuration. A key element to this solution is that the protocol next-hop address resides in only one topology routing table. That is, the protocol next hop belongs to a remote PE secondary loopback address and is injected into only one topology routing table. The route resolution scheme first checks routing table :red.inet.0 for the protocol next-hop address. If the address is found, it uses this entry. If it is not found, the resolution scheme checks routing table :blue.inet.0. Hence, only one topology routing table is used for each protocol nexthop address.

  9. Configure the autonomous system (AS) number.
  10. Configure BGP.
  11. Set the protocol next hop when exporting EBGP routes into IBGP.

    Configure the ingress Device PE1 router to set the BGP route’s protocol next-hop address when exporting the route into IBGP.

    BGP uses an export policy to set the next hop when injecting the EBGP routes into IBGP.

    This configuration is an export policy where there are three possibilities of next hops being set. Route 1.1.1.30 is associated with the red topology. Route 2.2.2.30 is associated with the blue topology. For the default next-hop self policy, the primary loopback address 10.255.165.93 on Device PE1 is used.

    The nhs_test policy sets the protocol next-hop based on the community in the BGP update.

  12. Apply the next-hop self policies to the IBGP sessions.
  13. 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.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, and show routing-options, and show policy-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.

Verification

Confirm that the configuration is working properly.

Checking the IBGP routes in inet.2

Purpose

Make sure that the routes injected into IBGP by Device PE1 have next hops that are based on the topology to which they belong.

Action

From operational mode, enter the show route table extensive command.

user@PE1> show route 11.19.130.0/24 table inet.2 extensive

Meaning

This output shows an IBGP route in the inet.2 routing table, as seen from Device PE1. The route was originally injected into IBGP by Device PE1, where the next hop was set based on the topology to which the route belonged. The BGP community value determined the topology association.

The route 11.19.130/24 belongs to the red topology because it has a community value of target:40:40. The protocol next hop is 1.1.1.30, and the forwarding next hop is ge-1/2/1.42.

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.

user@PE1> show route 11.19.130.0/24 detail

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.

user@PE2> show route 11.19.130.0/24 detail

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.

user@PE2> show route 10.255.165.93

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 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 | ospf3) neighbor extensive command on Device P2.

user@P2> show ospf neighbor 10.0.0.21 extensive

Meaning

This Device P2 output shows OSPF neighbor PE2 (10.0.0.21), where multitopology OSPF default and video are 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 extensive command on Device P2.

user@P2> show ospf database lsa-id 10.255.165.203 extensive

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 that 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.

user@CE1> traceroute 11.19.140.1 source 11.19.130.1 tos 160

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.

user@CE1> traceroute 11.19.140.1 source 11.19.130.1

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.

user@CE1> traceroute 11.19.142.1 source 11.19.132.1

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 the video routes, traffic is dropped.

user@CE1> traceroute 11.19.142.1 source 11.19.132.1 tos 160