Supported Platforms
Related Documentation
- M, MX, PTX, T Series
- Example: Configuring Multitopology Routing Based on a Multicast Source
Example: Configuring Multitopology Routing Based on Applications
Understanding Multitopology Routing Based on Applications
Multitopology routing (MTR) 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.
To run MTR, you must configure IP routing. MTR supports 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 also 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.
OSPF in MTR
OSPF in MTR uses a single instance of OSPF to carry connectivity and IP reachability information for different topologies. That information is used to calculate shortest-path-first (SPF) trees and routing tables. OSPF for MTR supports protocol extensions that include metrics that correspond to different topologies for link and prefix reachabilty information. The type-of-service (TOS) metric field is used to advertise the topology-specific metric for links and prefixes belonging to that topology. The TOS field is redefined as MT-ID in the payload of router, summary, and Type 5 and Type 7 AS-external link-state advertisements (LSAs).
Under MTR, each OSPF interface continues to belong to a single area. Therefore, by default, all topologies share the same area boundaries. As a result, attributes of an area, such as stubbiness, are independent of the topology. By default, all topologies configured for OSPF are enabled on all interfaces. However, you can disable one or more configured topologies on an interface. You can thus allocate an interface for a specific topology. In Figure 1, Area 51 includes an interface that is uniquely allocated to voice traffic, and Area 0 includes an interface that is uniquely allocated to data traffic. Each topology thus corresponds to a different OSPF area that shares a boundary.
Figure 1: MTR-OSPF Area Boundary
BGP in MTR
BGP in MTR provides the ability to resolve BGP routes against configured topologies. An inbound policy is used to select routes for inclusion in the appropriate routing tables for the topologies. The default behavior for virtual private networks (VPNs) that use MPLS for forwarding packets over the backbone and that use BGP for distributing routes over the backbone is to place BGP route updates in the bgp.l3vpn routing table. Figure 2 shows a BGP peer operating in an environment that conforms with the requirements in RFC 2547, BGP/MPLS VPNs. The figure shows how a BGP peer configured for MTR performs secondary route resolution.
Figure 2: BGP Route Resolution
The BGP peer in a standard VPN topology places prefixes for routes it learns in the bgp.l3vpn routing table, which does not result in automatic updates to the forwarding table. Under BGP in MTR, when BGP receives a route from a peer, it attempts to resolve that route against a route in the inet.0 routing table. If the route is resolved, it is placed in that table, which generates a forwarding state. If you have configured a community target identifier that matches the import policy for the topology, routing and forwarding states are added to the tables for the topology.
Because MTR provides support for BGP to perform secondary route resolution, as Figure 3 shows, MTR is able to create two distinct network paths for each type of traffic. Each router advertises BGP routes that need to be resolved against the IGP routes for each topology. Based on the IGP metrics configured for each topology, for all routes that originate from Router 4 (R4), the upper path between R1 and R4, which traverses R2 and R3, is selected for voice traffic, whereas the lower path between R1 and R4, which traverses R5 and R6, is selected for data traffic.
Figure 3: Route Resolution for MTR
Example: Configuring Multitopology Routing Based on Applications
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 4 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 4 shows the sample topology.
Figure 4: Multitopology 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 CLI User Guide.
To configure Device CE1:
- 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.
[edit interfaces]user@CE1# set fe-0/1/0 fastether-options loopbackuser@CE1# set fe-0/1/0 unit 0 family inet address 11.19.130.1/24user@CE1# set fe-0/1/0 unit 0 family inet address 11.19.131.1/24user@CE1# set fe-0/1/0 unit 0 family inet address 11.19.132.1/24
user@CE1# set fe-1/2/0 unit 1 description to-PE1user@CE1# set fe-1/2/0 unit 1 family inet address 10.0.0.1/30
user@CE1# set lo0 unit 97 family inet address 10.255.165.97/32 primary - Configure the external BGP (EBGP) connection to Device
PE1.[edit protocols bgp group ebgp]user@CE1# set type externaluser@CE1# set local-address 10.0.0.1user@CE1# set peer-as 100user@CE1# set neighbor 10.0.0.2
- Configure the routing policy that announces the addresses
that are configured on interface fe-0/1/0.[edit policy-options policy-statement inject_directs]user@CE1# set term a from protocol directuser@CE1# set term a from interface fe-0/1/0.0user@CE1# set term a then next policyuser@CE1# set term a then acceptuser@CE1# set term b then reject
- Configure the routing policy that tags voice routes with
the video community attribute, and video routes with the voice community
attribute.[edit policy-options policy-statement set_community]user@CE1# set term a from route-filter 11.19.130.0/24 exactuser@CE1# set term a from route-filter 11.19.131.0/24 exactuser@CE1# set term a then community add voiceuser@CE1# set term a then accept
user@CE1# set term b from route-filter 11.19.132.0/24 exactuser@CE1# set term b from route-filter 11.19.133.0/24 exactuser@CE1# set term b then community add videouser@CE1# set term b then accept
user@CE1# set term default then accept
[edit policy-options community]user@CE1# set video members target:50:50user@CE1# set voice members target:40:40 - 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.
[edit protocols bgp group ebgp]user@CE1# set export set_communityuser@CE1# set export inject_directs - Configure the autonomous system (AS) number.[edit routing-options]user@CE1# set autonomous-system 101
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:
- 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).
[edit interfaces]user@PE1# set fe-1/2/0 unit 2 description to-CE1user@PE1# set fe-1/2/0 unit 2 family inet filter input ef_pathuser@PE1# set fe-1/2/0 unit 2 family inet address 10.0.0.2/30
user@PE1# set fe-1/2/1 unit 6 description to-P1user@PE1# set fe-1/2/1 unit 6 family inet filter input ef_pathuser@PE1# set fe-1/2/1 unit 6 family inet address 10.0.0.6/30
user@PE1# set fe-1/2/2 unit 9 description to-P3user@PE1# set fe-1/2/2 unit 9 family inet filter input ef_pathuser@PE1# set fe-1/2/2 unit 9 family inet address 10.0.0.9/30
user@PE1# set lo0 unit 93 family inet address 10.255.165.93/32 primary - Configure the autonomous system (AS) number.[edit routing-options]user@PE1# set autonomous-system 100
- Configure BGP.[edit protocols bgp group ibgp]user@PE1# set type internaluser@PE1# set local-address 10.255.165.93user@PE1# set neighbor 10.255.165.111user@PE1# set neighbor 10.255.165.203user@PE1# set neighbor 10.255.165.113user@PE1# set neighbor 10.255.165.95user@PE1# set neighbor 10.255.165.99
[edit protocols bgp group ebgp]user@PE1# set type externaluser@PE1# set local-address 10.0.0.2user@PE1# set peer-as 101user@PE1# set neighbor 10.0.0.1 - 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.
[edit policy-options policy-statement nhs]user@PE1# set then next-hop self - Apply the next-hop self policy to the IBGP sessions.[edit protocols bgp group ibgp]user@PE1# set export nhs
- 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.
[edit routing-options topologies family inet]user@PE1# set topology voiceuser@PE1# set topology video - 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).
[edit protocols bgp group ibgp family inet unicast]user@PE1# set topology voice community target:40:40user@PE1# set topology video community target:50:50
[edit protocols bgp group ebgp family inet unicast]user@PE1# set topology voice community target:40:40user@PE1# set topology video community target:50:50 - Enable and disable multitopology OSPF on particular interfaces.
Enable multitopology OSPF designations only on desired interfaces, as shown in Figure 4. 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.
[edit protocols ospf ]user@PE1# set topology voice topology-id 126user@PE1# set topology video topology-id 52
[edit protocols ospf area 0.0.0.0]user@PE1# set interface fe-1/2/1.6 metric 10user@PE1# set interface fe-1/2/1.6 topology video disableuser@PE1# set interface fe-1/2/1.6 topology voice
user@PE1# set interface fe-1/2/2.9 metric 10user@PE1# set interface fe-1/2/2.9 topology voice disableuser@PE1# set interface fe-1/2/2.9 topology video
user@PE1# set interface lo0.93 passive - 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.
[edit firewall family inet filter ef_path]user@PE1# set term ef from forwarding-class expedited-forwardinguser@PE1# set term ef then topology voice
user@PE1# set term video from source-address 11.19.132.0/24user@PE1# set term video from source-address 11.19.133.0/24user@PE1# set term video from source-address 11.19.142.0/24user@PE1# set term video from source-address 11.19.144.0/24user@PE1# set term video then topology video
user@PE1# set term default then accept - Enable CoS on the interfaces.[edit class-of-service interfaces]user@PE1# set fe-1/2/0 unit 2 classifiers inet-precedence defaultuser@PE1# set fe-1/2/1 unit 6 classifiers inet-precedence defaultuser@PE1# set fe-1/2/2 unit 9 classifiers inet-precedence default
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
- Verifying the Routes
- Checking the Resolving BGP Next Hops
- Examining the Protocol Next Hop
- Verifying the OSPF Neighbor
- Checking the Router LSA
- Checking How Traffic Traverses the Network
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.
user@PE1> show ospf interface fe-1/2/1.6 detailInterface State Area DR ID BDR ID Nbrs fe-1/2/1.6 DR 0.0.0.0 10.255.165.93 10.255.165.99 1 Type: LAN, Address: 10.0.0.6, Mask: 255.255.255.252, MTU: 1500, Cost: 10 DR addr: 10.0.0.6, BDR addr: 10.0.0.5, Priority: 128 Adj count: 1 Hello: 10, Dead: 40, ReXmit: 5, Not Stub Auth type: None Protection type: None Topology default (ID 0) -> Cost: 10 Topology video (ID 52) -> Disabled, Cost: 10 Topology voice (ID 126) -> Cost: 10
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.
user@PE1> show route 11.19.130.0/24 detailinet.0: 29 destinations, 30 routes (29 active, 0 holddown, 0 hidden)
11.19.130.0/24 (1 entry, 1 announced)
*BGP Preference: 170/-101
Next hop type: Router, Next hop index: 812
Address: 0xb9f064c
Next-hop reference count: 22
Source: 10.0.0.1
Next hop: 10.0.0.1 via fe-1/2/0.2, selected
Session Id: 0x600004
State: <Active Ext>
Local AS: 100 Peer AS: 101
Age: 3d 21:44:07
Task: BGP_101.10.0.0.1+51873
Announcement bits (3): 0-KRT 3-BGP_RT_Background 4-Resolve tree 3
AS path: 101 I
Communities: target:40:40
Accepted
Localpref: 100
Router ID: 10.255.165.97
Secondary Tables: :voice.inet.0
:voice.inet.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden)
11.19.130.0/24 (1 entry, 1 announced)
*BGP Preference: 170/-101
Next hop type: Router, Next hop index: 812
Address: 0xb9f064c
Next-hop reference count: 22
Source: 10.0.0.1
Next hop: 10.0.0.1 via fe-1/2/0.2, selected
Session Id: 0x600004
State: <Secondary Active IndepResolution Ext>
Local AS: 100 Peer AS: 101
Age: 3d 21:44:07
Task: BGP_101.10.0.0.1+51873
Announcement bits (2): 0-KRT 1-Resolve tree 1
AS path: 101 I
Communities: target:40:40
Accepted
Localpref: 100
Router ID: 10.255.165.97
Primary Routing Table inet.0
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 detailinet.0: 29 destinations, 30 routes (29 active, 0 holddown, 0 hidden)
11.19.130.0/24 (1 entry, 1 announced)
*BGP Preference: 170/-101
Next hop type: Indirect
Address: 0xb9f0e04
Next-hop reference count: 12
Source: 10.255.165.93
Next hop type: Router, Next hop index: 262153
Next hop: 10.0.0.37 via fe-1/2/0.38
Session Id: 0x700004
Next hop: 10.0.0.41 via fe-1/2/1.42, selected
Session Id: 0x700005
Protocol next hop: 10.255.165.93
Indirect next hop: bb8c000 262154 INH Session ID: 0x700007
State: <Active Int Ext>
Local AS: 100 Peer AS: 100
Age: 3d 4:27:40 Metric2: 30
Task: BGP_100.10.255.165.93+179
Announcement bits (3): 0-KRT 3-BGP_RT_Background 4-Resolve tree 3
AS path: 101 I
Communities: target:40:40
Accepted
Localpref: 100
Router ID: 10.255.165.93
Secondary Tables: :voice.inet.0
:voice.inet.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden)
11.19.130.0/24 (1 entry, 1 announced)
*BGP Preference: 170/-101
Next hop type: Indirect
Address: 0xb9f0f34
Next-hop reference count: 6
Source: 10.255.165.93
Next hop type: Router, Next hop index: 1188
Next hop: 10.0.0.37 via fe-1/2/0.38, selected
Session Id: 0x700004
Protocol next hop: 10.255.165.93
Indirect next hop: bb8c1d8 262177 INH Session ID: 0x700007
State: <Secondary Active IndepResolution Int Ext>
Local AS: 100 Peer AS: 100
Age: 3d 2:00:20 Metric2: 30
Task: BGP_100.10.255.165.93+179
Announcement bits (2): 0-KRT 1-Resolve tree 1
AS path: 101 I
Communities: target:40:40
Accepted
Localpref: 100
Router ID: 10.255.165.93
Primary Routing Table inet.0Meaning
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.93inet.0: 29 destinations, 30 routes (29 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.255.165.93/32 *[OSPF/10] 3d 04:37:26, metric 30
> to 10.0.0.37 via fe-1/2/0.38
to 10.0.0.41 via fe-1/2/1.42
:voice.inet.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.255.165.93/32 *[OSPF/10] 3d 02:10:04, metric 30
> to 10.0.0.37 via fe-1/2/0.38
:video.inet.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.255.165.93/32 *[OSPF/10] 3d 02:03:16, metric 30
> to 10.0.0.41 via fe-1/2/1.42Meaning
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.
user@P2> show ospf neighbor 10.0.0.21 extensiveAddress Interface State ID Pri Dead 10.0.0.21 fe-1/2/0.22 Full 10.255.165.111 128 39 Area 0.0.0.0, opt 0x52, DR 10.0.0.22, BDR 10.0.0.21 Up 3d 06:09:50, adjacent 3d 06:09:50 Topology default (ID 0) -> Bidirectional Topology video (ID 52) -> Bidirectional
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.
user@P2> show ospf database lsa-id 10.255.165.203
extensive OSPF database, Area 0.0.0.0
Type ID Adv Rtr Seq Age Opt Cksum Len
Router 10.255.165.203 10.255.165.203 0x80000063 1552 0x22 0xdff3 80
bits 0x0, link count 3
id 10.255.165.203, data 255.255.255.255, Type Stub (3)
Topology count: 2, Default metric: 0
Topology video (ID 52) -> Metric: 0
Topology voice (ID 126) -> Metric: 0
id 10.0.0.38, data 10.0.0.38, Type Transit (2)
Topology count: 2, Default metric: 10
Topology video (ID 52) -> Metric: 200
Topology voice (ID 126) -> Metric: 10
id 10.0.0.42, data 10.0.0.42, Type Transit (2)
Topology count: 1, Default metric: 10
Topology video (ID 52) -> Metric: 10
Topology default (ID 0)
Type: Transit, Node ID: 10.0.0.42
Metric: 10, Bidirectional
Type: Transit, Node ID: 10.0.0.38
Metric: 10, Bidirectional
Topology video (ID 52)
Type: Transit, Node ID: 10.0.0.42
Metric: 10, Bidirectional
Type: Transit, Node ID: 10.0.0.38
Metric: 200, Bidirectional
Topology voice (ID 126)
Type: Transit, Node ID: 10.0.0.38
Metric: 10, Bidirectional
Aging timer 00:34:08
Installed 00:25:49 ago, expires in 00:34:08, sent 00:25:47 ago
Last changed 3d 01:45:51 ago, Change count: 10Meaning
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
user@CE1> traceroute 11.19.140.1 source 11.19.130.1
tos 160traceroute to 11.19.140.1 (11.19.140.1) from 11.19.130.1, 30 hops max, 40 byte packets 1 10.0.0.2 (10.0.0.2) 2.015 ms 1.924 ms 1.770 ms 2 10.0.0.5 (10.0.0.5) 1.890 ms 1.010 ms 0.974 ms 3 10.0.0.34 (10.0.0.34) 0.986 ms 1.031 ms 0.973 ms 4 10.0.0.38 (10.0.0.38) 1.213 ms 1.065 ms 1.154 ms 5 11.19.140.1 (11.19.140.1) 1.696 ms 4.286 ms 1.332 ms
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.1traceroute to 11.19.140.1 (11.19.140.1) from 11.19.130.1, 30 hops max, 40 byte packets 1 10.0.0.2 (10.0.0.2) 1.654 ms 1.710 ms 1.703 ms 2 10.0.0.5 (10.0.0.5) 1.790 ms 1.045 ms 0.975 ms 3 10.0.0.18 (10.0.0.18) 0.989 ms 1.041 ms 0.983 ms 4 10.0.0.42 (10.0.0.42) 0.994 ms 1.036 ms 1.002 ms 5 11.19.140.1 (11.19.140.1) 1.329 ms 2.248 ms 2.225 ms
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.1traceroute to 11.19.142.1 (11.19.142.1) from 11.19.132.1, 30 hops max, 40 byte packets 1 10.0.0.2 (10.0.0.2) 1.126 ms 1.300 ms 0.995 ms 2 10.0.0.10 (10.0.0.10) 0.981 ms 1.018 ms 0.991 ms 3 10.0.0.30 (10.0.0.30) 0.997 ms 1.886 ms 1.952 ms 4 10.0.0.42 (10.0.0.42) 1.800 ms 1.038 ms 0.980 ms 5 11.19.142.1 (11.19.142.1) 1.367 ms 1.352 ms 1.328 ms
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.
user@CE1> traceroute 11.19.142.1 source 11.19.132.1
tos 160traceroute to 11.19.142.1 (11.19.142.1) from 11.19.132.1, 30 hops max, 40 byte packets 1 10.0.0.2 (10.0.0.2) 1.135 ms !N 1.007 ms !N 0.954 ms !N
Related Documentation
- M, MX, PTX, T Series
- Example: Configuring Multitopology Routing Based on a Multicast Source
Published: 2013-07-22
Supported Platforms
Related Documentation
- M, MX, PTX, T Series
- Example: Configuring Multitopology Routing Based on a Multicast Source
