Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


Multitopology Routing in cRPD

Understanding Multitopology in cRPD

cRPD enables BGP multiple RIBs functionality to support Multitopology routing (MTR) based on the routing policy with Linux FIBs (routes in forwarding plane). The applications can select required routing table based on the routing policy from the Linux FIB in cRPD for different types of traffic. Each type of traffic is defined by a topology that is used to create a new routing table for that topology. 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.

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, IS-IS, OSPF, and BGP. 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. Communities are used for BGP when exporting routes to multitopology. OSPFv3 does not support MTR. MTR discovers IGP routes and able to resolve BGP routes against the custom topologies with static and OSPF. .

You can configure separate topologies to share the same network links as needed. MTR uses a combination of control plane (routing) and forwarding plane filters.

MTR provides the ability to generate forwarding tables based on the resolved entries in the routing tables for the topologies you create. MTR and forwarding is available only on master routing instance. A dedicated RIB is created for storing the Multitopology routes. BGP multipath is not enabled on topologies.

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.

Example: Configuring Multitopology Routing with BGP in cRPD

This example shows how to configure community based multiple topologies with BGP in cRPD and unicast the traffic using MTR over network paths.


This example requires following software release:

  • cRPD 19.4R1 or later.


Multi-topology 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 1647 replicated in the associated topology routing table.

Configure topologies with BGP inet family and verify BGP import matching route into topology rib. For each topology a list of community objects must be provided such that the routing software can setup an internal ribgroup and the corresponding secondary table import policy.


Figure 1 shows topology for configuring multi-topology with BGP.

Figure 1: Multi-topology RoutingMulti-topology Routing


To configure multitopology with BGP:

CLI Quick Configuration

Configuring BGP through Multitopology Routing

Step-by-Step Procedure
  1. Configure multiple topologies.

  2. Configure static routes.

  3. Configure BGP group parameters to import matching route into topology rib. BGP uses the target community identifier to install the routes it learns in the appropriate multi-topology routing tables.


From configuration mode, confirm your configuration by entering the show protocols bgp 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.


Verifying BGP routes


To verify BGP matched routes:


From operational mode, enter the show route protocol bgp all table command:

From operational mode, enter the show route protocol bgp all table inet.0 command:


You can view BGP matching routes installed to RIB tables and when the routes without community target are available only in inet.0 table.