Configuring Priority for Route Prefixes in RPD Infrastructure
Prefix prioritization helps users to prioritize certain routes or prefixes for better convergence and to provide differentiated services. In a network with a large number of routes, it is sometimes important to control the order in which routes get updated due to changes in the network topology. At a system level, Junos OS implements reasonable defaults based on heuristics to determine the order in which routes get updated. However, the default behavior is not always optimal. Prefix prioritization provides the user the ability to control the order in which the routes get updated from LDP or OSPF to rpd, and rpd to kernel. The Junos OS policy language is extended to let the user set relative priority (high and low) for prefixes through the existing import policy in protocols. Based on the tagged priority, the routes are placed in different priority queues. In the event of a topology change, high priority prefixes are updated in the routing table first, followed by low priority prefixes. Within the same priority level, routes will continue to be updated in lexicographic order. Routes that are not explicitly assigned a priority are treated as medium priority.
Before you begin to configure prefix prioritization in rpd for protocols such as OSPF, LDP, and BGP:
Configure the router interfaces.
Configure MPLS.
Configure the OSPF, BGP, and LDP protocols.
To configure the priority high
for the OSPF
protocol:
LDP inherits from OSPF.
To configure priority high
for LDP:
Configure the policy term that imports from OSPF.
[edit policy-options policy-statement policy-name] user@host# set term term-name
For example:
[edit policy-options policy-statement ospf-import] user@host# set term ospf_ldp
Configure the term to accept routes and priority from OSPF.
[edit policy-options policy-statement ospf_import term ospf_ldp] user@host# set from protocol ospf user@host# set from route-filter destination-prefix match-type
For example:
[edit policy-options policy-statement ospf_import term ospf_ldp] user@host# set from protocol ospf user@host# set from route-filter 172.16.25.3/32 exact
Verify the configuration.
[edit] user@host# show policy-options policy-statement ospf-import { term ospf_ldp { from { protocol ospf ; route-filter 172.16.25.3/32 exact; } then { priority high; accept; } } }
To configure the priority high
for the BGP
protocol:
Configure the policy term.
[edit policy-options policy-statement policy-name] user@host# set term term-name
For example:
[edit policy-options policy-statement prio-for-bgp] user@host# set term bgp_prio
Specify the desired route as a match condition.
[edit policy-options policy-statement prio-for-bgp term bgp_prio] user@host# set from protocol bgp user@host# set from route-filter destination-prefix match-type
For example:
[edit policy-options policy-statement prio-for-bgp term bgp_prio] user@host# set from protocol bgp user@host# set from route-filter 172.16.50.1/32 exact
Specify that the route is to be accepted and set the priority
high
for the route if the previous conditions are matched.[edit policy-options policy-statement prio-for-bgp term bgp_prio] user@host# set then priority high user@host# set then accept
Verify the configuration.
policy-statement prio_for_bgp { term bgp_prio { from { protocol bgp; route-filter 172.16.50.1/32 exact; } then { priority high; accept; } } }
For BGP, you can also configure priority based on the route-distinguisher (RD) value in case of L3VPN. For example, you can configure priority for BGP with route-distinguisher 51.51.51.51:111.
To configure priority for BGP based on the route-distinguisher (RD) value:
Configure the policy term.
[edit policy-options policy-statement policy-name] user@host# set term term-name
For example:
[edit policy-options policy-statement prio-for-bgp] user@host# set term bgp_prio
Specify the desired route as a match condition.
[edit policy-options policy-statement prio-for-bgp term bgp_prio] user@host# set from rib bgp.l3vpn.0 user@host# set from route-filter destination-prefix match-type user@host# set from route-distinguisher route-distinguisher value
For example:
[edit policy-options policy-statement prio-for-bgp term bgp_prio] user@host# set from rib bgp.l3vpn.0 user@host# set from route-filter 172.16.1.1/32 exact user@host# set from route-distinguisher RD1
Specify that the route is to be accepted and set the priority
high
for the route if the previous conditions are matched.[edit policy-options policy-statement prio-for-bgp term bgp_prio] user@host# set then priority high user@host# set then accept
Verify the configuration.
policy-statement prio_for_bgp { term bgp_prio { from { protocol rib bgp.l3vpn.0; route-filter 172.16.1.1/32 exact; route-distinguisher RD1; } then { priority high; accept; } } }
Low priority prefixes are installed only after the high
priority prefixes in the routing table. You can also configure priority low
similarly to priority high
for the routes you
want to set to low priority.
Priority is applied only when routes are pushed from RIB to FIB. Therefore, you cannot modify the priority of routes that are already installed. Changing the priority of routes already installed does not make sense. If you try changing the priority of routes already installed, there is a show output difference:
user@R1> show route 172.16.25.3 extensive | match state
State: <FlashAll>
State: <Active Int HighPriority> <=== OSPF
Validation State: unverified
State: <FlashAll>
State: <Active Int> <=== LDP
Validation State: unverified
As the route is already installed in FIB, LDP does not show the priority as High.
Restarting the routing daemon to remove the routes and adding it again reflects the proper priority from both the OSPF and LDP protocol perspective.
user@R1>restart routing
Routing protocols process signalled but still running, waiting 8 seconds more Routing protocols process started, pid 4512 user@R1>show route 172.16.25.3 extensive |match state
State: <FlashAll> State: <Active Int HighPriority> <=== OSPF Validation State: unverified State: <FlashAll> State: <Active Int HighPriority> <=== LDP Validation State: unverified