ON THIS PAGE
Example: Configuring Dynamic Routing Policies
This example shows how to configure routing policy objects in a dynamic database that is not subject to the same verification required in the standard configuration database.
Requirements
No special configuration beyond device initialization is required before configuring this example.
Overview
The verification process required to commit configuration changes can entail a significant amount of overhead and time.
The time it takes to commit changes to the dynamic database is much shorter than for the standard configuration database. You can reference these policies and policy objects in routing policies you configure in the standard database. BGP is the only protocol to which you can apply routing policies that reference policies and policy objects configured in the dynamic database. After you configure and commit a routing policy based on the objects configured in the dynamic database, you can quickly update any existing routing policy by making changes to the dynamic database configuration.
Because Junos OS does not validate configuration changes to the dynamic database, when you use this feature, you should test and verify all configuration changes before committing them.
Figure 1 shows the sample network.
The example includes three routers with external BGP (EBGP) sessions established. Only Device R1 makes use of the dynamic database.
On Device R0’s fe-1/2/1 interface, multiple IPv4 interfaces are configured, and
a routing policy injects these prefixes into BGP, using the from interface fe-1/2/1.0 policy condition as a shorthand method for specifying all of the IP addresses configured
on Device R0’s fe-1/2/1 interface.
Likewise, on Device R2’s fe-1/2/3 interface, multiple IPv4 addresses are configured, and a routing policy injects these prefixes into BGP. Device R2’s configuration is slightly different from Device R0’s in that Device R2’s configuration demonstrates the use of a prefix list.
On Device R1, in the dynamic database, two prefix lists are defined, one for the interface addresses learned from Device R0 and another for the interface addresses learned from Device R2. Device R1’s standard database contains routing policies with prefix lists that are similar to those defined in the dynamic database.
In its peer session with Device R0, Device R1 has the static-database policies applied. In contrast, in its peer session with Device R2, Device R1’s configuration references the dynamic database.
The results of these different configurations are analyzed in the Verification section.
CLI Quick Configuration shows the configuration for all of the devices in Figure 1.
The section #configuration776__policy-dynamic-st describes the steps on Device R1’s dynamic database.
The section #configuration776__policy-standard-st describes the steps on Device R1’s standard database.
Configuration
Procedure
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 R0
set interfaces fe-1/2/0 unit 0 family inet address 10.0.0.1/30 set interfaces fe-1/2/1 unit 0 family inet address 172.16.4.1/24 set interfaces fe-1/2/1 unit 0 family inet address 172.16.3.1/24 set interfaces fe-1/2/1 unit 0 family inet address 172.16.2.1/24 set interfaces fe-1/2/1 unit 0 family inet address 172.16.1.1/24 set interfaces fe-1/2/1 unit 0 family inet address 172.16.5.1/24 set interfaces fe-1/2/1 unit 0 family inet address 172.16.6.1/24 set interfaces fe-1/2/1 unit 0 family inet address 172.16.7.1/24 set interfaces fe-1/2/1 unit 0 family inet address 172.16.8.1/24 set interfaces fe-1/2/1 unit 0 family inet address 172.16.9.1/24 set interfaces fe-1/2/1 unit 0 family inet address 172.16.10.1/24 set interfaces lo0 unit 0 family inet address 10.255.14.151/32 set protocols bgp group ext type external set protocols bgp group ext neighbor 10.0.0.2 export t2 set protocols bgp group ext neighbor 10.0.0.2 peer-as 200 set policy-options policy-statement t2 from interface fe-1/2/0.0 set policy-options policy-statement t2 from interface fe-1/2/1.0 set policy-options policy-statement t2 then accept set routing-options router-id 10.255.14.151 set routing-options autonomous-system 100
Device R1 Dynamic Database
[edit dynamic] set policy-options prefix-list dyn_prfx1 172.16.1.0/24 set policy-options prefix-list dyn_prfx1 172.16.2.0/24 set policy-options prefix-list dyn_prfx1 172.16.3.0/24 set policy-options prefix-list dyn_prfx1 172.16.4.0/24 set policy-options prefix-list dyn_prfx1 172.16.5.0/24 set policy-options prefix-list dyn_prfx1 172.16.6.0/24 set policy-options prefix-list dyn_prfx1 172.16.7.0/24 set policy-options prefix-list dyn_prfx1 172.16.8.0/24 set policy-options prefix-list dyn_prfx2 172.16.2.0/24 set policy-options prefix-list dyn_prfx2 172.16.3.0/24 set policy-options prefix-list dyn_prfx2 172.16.4.0/24 set policy-options prefix-list dyn_prfx2 172.16.5.0/24 set policy-options prefix-list dyn_prfx2 172.16.6.0/24 set policy-options policy-statement dyn_policy1 term t1 from prefix-list dyn_prfx1 set policy-options policy-statement dyn_policy1 term t1 then accept set policy-options policy-statement dyn_policy1 term t2 then reject set policy-options policy-statement dyn_policy2 term t1 from prefix-list dyn_prfx2 set policy-options policy-statement dyn_policy2 term t1 then accept set policy-options policy-statement dyn_policy2 term t2 then reject
Device R1 Standard Database
set interfaces fe-1/2/0 unit 0 family inet address 10.0.0.2/30 set interfaces fe-1/2/2 unit 0 family inet address 10.1.0.1/30 set interfaces fe-1/2/1 unit 0 family inet address 172.16.4.2/24 set interfaces fe-1/2/1 unit 0 family inet address 172.16.3.2/24 set interfaces fe-1/2/1 unit 0 family inet address 172.16.2.2/24 set interfaces fe-1/2/1 unit 0 family inet address 172.16.1.2/24 set interfaces fe-1/2/1 unit 0 family inet address 172.16.5.2/24 set interfaces fe-1/2/1 unit 0 family inet address 172.16.6.2/24 set interfaces fe-1/2/1 unit 0 family inet address 172.16.7.2/24 set interfaces fe-1/2/1 unit 0 family inet address 172.16.8.2/24 set interfaces fe-1/2/1 unit 0 family inet address 172.16.9.2/24 set interfaces fe-1/2/1 unit 0 family inet address 172.16.10.2/24 set interfaces fe-1/2/3 unit 0 family inet address 172.16.22.2/24 set interfaces fe-1/2/3 unit 0 family inet address 172.16.23.2/24 set interfaces fe-1/2/3 unit 0 family inet address 172.16.24.2/24 set interfaces fe-1/2/3 unit 0 family inet address 172.16.25.2/24 set interfaces fe-1/2/3 unit 0 family inet address 172.16.26.2/24 set interfaces lo0 unit 0 family inet address 192.168.0.2/32 set protocols bgp group to_r0 idle-after-switch-over 300 set protocols bgp group to_r0 neighbor 10.0.0.1 import dyn_policy1 set protocols bgp group to_r0 neighbor 10.0.0.1 export dyn_policy2 set protocols bgp group to_r0 neighbor 10.0.0.1 peer-as 100 set protocols bgp group to_R2 import static_policy1 set protocols bgp group to_R2 export static_policy2 set protocols bgp group to_R2 idle-after-switch-over 300 set protocols bgp group to_R2 neighbor 10.1.0.2 peer-as 300 set policy-options prefix-list static_prfx1 172.16.22.0/24 set policy-options prefix-list static_prfx1 172.16.23.0/24 set policy-options prefix-list static_prfx1 172.16.24.0/24 set policy-options prefix-list static_prfx1 172.16.25.0/24 set policy-options prefix-list static_prfx2 172.16.1.0/24 set policy-options prefix-list static_prfx2 172.16.2.0/24 set policy-options prefix-list static_prfx2 172.16.3.0/24 set policy-options prefix-list static_prfx2 172.16.4.0/24 set policy-options policy-statement dyn_policy1 dynamic-db set policy-options policy-statement dyn_policy2 dynamic-db set policy-options policy-statement static_policy1 term t1 from prefix-list static_prfx1 set policy-options policy-statement static_policy1 term t1 then accept set policy-options policy-statement static_policy1 term t2 then reject set policy-options policy-statement static_policy2 term t1 from prefix-list static_prfx2 set policy-options policy-statement static_policy2 term t1 then accept set policy-options policy-statement static_policy2 term t2 then reject set routing-options autonomous-system 200
Device R2
set interfaces fe-1/2/2 unit 0 family inet address 10.1.0.2/30 set interfaces fe-1/2/3 unit 0 family inet address 172.16.22.1/24 set interfaces fe-1/2/3 unit 0 family inet address 172.16.23.1/24 set interfaces fe-1/2/3 unit 0 family inet address 172.16.24.1/24 set interfaces fe-1/2/3 unit 0 family inet address 172.16.25.1/24 set interfaces fe-1/2/3 unit 0 family inet address 172.16.26.1/24 set interfaces lo0 unit 0 family inet address 192.168.0.3/32 set protocols bgp group to_vin neighbor 10.1.0.1 export p1 set protocols bgp group to_vin neighbor 10.1.0.1 peer-as 200 set policy-options prefix-list ppx1 172.16.22.0/24 set policy-options prefix-list ppx1 172.16.23.0/24 set policy-options prefix-list ppx1 172.16.24.0/24 set policy-options prefix-list ppx1 172.16.25.0/24 set policy-options prefix-list ppx1 172.16.26.0/24 set policy-options policy-statement p1 term t1 from family inet set policy-options policy-statement p1 term t1 from prefix-list ppx1 set policy-options policy-statement p1 term t1 then accept set routing-options autonomous-system 300
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Use the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.
To configure Device R1’s dynamic database:
Enter configuration mode for the dynamic database.
user@R1> configure dynamic Entering configuration mode [edit dynamic]
Create a prefix list for the interface addresses learned from Device R0.
[edit dynamic policy-options prefix-list dyn_prfx1] user@R1# set 172.16.1.0/24 user@R1# set 172.16.2.0/24 user@R1# set 172.16.3.0/24 user@R1# set 172.16.4.0/24 user@R1# set 172.16.5.0/24 user@R1# set 172.16.6.0/24 user@R1# set 172.16.7.0/24 user@R1# set 172.16.8.0/24
Create a prefix list for the interface addresses learned from Device R2.
[edit dynamic policy-options prefix-list dyn_prfx2] user@R1# set 172.16.2.0/24 user@R1# set 172.16.3.0/24 user@R1# set 172.16.4.0/24 user@R1# set 172.16.5.0/24 user@R1# set 172.16.6.0/24
Configure the routing policies.
[edit dynamic policy-options policy-statement dyn_policy1] user@R1# set term t1 from prefix-list dyn_prfx1 user@R1# set term t1 then accept user@R1# set term t2 then reject user@R1# set term t1 from prefix-list dyn_prfx2 user@R1# set term t1 then accept user@R1# set term t2 then reject
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Use the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.
To configure Device R1’s standard database:
Create the router interfaces.
[edit interfaces] user@R1# set fe-1/2/0 unit 0 family inet address 10.0.0.2/30 user@R1# set fe-1/2/2 unit 0 family inet address 10.1.0.1/30 user@R1# set fe-1/2/1 unit 0 family inet address 172.16.4.2/24 user@R1# set fe-1/2/1 unit 0 family inet address 172.16.3.2/24 user@R1# set fe-1/2/1 unit 0 family inet address 172.16.2.2/24 user@R1# set fe-1/2/1 unit 0 family inet address 172.16.1.2/24 user@R1# set fe-1/2/1 unit 0 family inet address 172.16.5.2/24 user@R1# set fe-1/2/1 unit 0 family inet address 172.16.6.2/24 user@R1# set fe-1/2/1 unit 0 family inet address 172.16.7.2/24 user@R1# set fe-1/2/1 unit 0 family inet address 172.16.8.2/24 user@R1# set fe-1/2/1 unit 0 family inet address 172.16.9.2/24 user@R1# set fe-1/2/1 unit 0 family inet address 172.16.10.2/24 user@R1# set fe-1/2/3 unit 0 family inet address 172.16.2.2/24 user@R1# set fe-1/2/3 unit 0 family inet address 172.16.3.2/24 user@R1# set fe-1/2/3 unit 0 family inet address 172.16.4.2/24 user@R1# set fe-1/2/3 unit 0 family inet address 172.16.5.2/24 user@R1# set fe-1/2/3 unit 0 family inet address 172.16.6.2/24 user@R1# set lo0 unit 0 family inet address 192.168.0.2/32
Create routing policies that reference the policies in the dynamic database.
[edit policy-options] user@R1# set policy-statement dyn_policy1 dynamic-db user@R1# set policy-statement dyn_policy2 dynamic-db
Configure BGP peering with Device R0.
[edit protocols bgp group to_r0] user@R1# set neighbor 10.0.0.1 peer-as 100
Apply the dynamic database policies to the BGP peering with Device R0.
[edit protocols bgp group to_r0] user@R1# set neighbor 10.0.0.1 import dyn_policy1 user@R1# set neighbor 10.0.0.1 export dyn_policy2
Configure a prefix list for prefixes learned from Device R0.
[edit policy-options prefix-list static_prfx2] user@R1# set 172.16.1.0/24 user@R1# set 172.16.2.0/24 user@R1# set 172.16.3.0/24 user@R1# set 172.16.4.0/24
Configure a prefix list for prefixes learned from Device R2.
[edit policy-options prefix-list static_prfx1] user@R1# set 172.16.2.0/24 user@R1# set 172.16.3.0/24 user@R1# set 172.16.4.0/24 user@R1# set 172.16.5.0/24
Configure the static database policies.
[edit policy-options policy-statement static_policy1] user@R1# set term t1 from prefix-list static_prfx1 user@R1# set term t1 then accept user@R1# set term t2 then reject [edit policy-options policy-statement static_policy2] user@R1# set term t1 from prefix-list static_prfx2 user@R1# set term t1 then accept user@R1# set term t2 then reject
Configure BGP peering with Device R2.
[edit protocols bgp group to_R2] user@R1# set neighbor 10.1.0.2 peer-as 300
Apply the static database policies to the BGP peering with Device R2.
[edit protocols bgp group to_R2] user@R1# set import static_policy1 user@R1# set export static_policy2
(Optional) Configure the router not to reestablish the BGP peering sessions after an active nonstop routing switchover either for a specified period or until you manually reestablish the session.
This statement is particularly useful with dynamic routing policies because the dynamic database is not synchronized with the backup Routing Engine when nonstop active routing (NSR) is enabled. As a result, if a switchover to a backup Routing Engine occurs, import and export policies running on the primary Routing Engine at the time of the switchover might no longer be available. Therefore, you might want to prevent a BGP peering session from automatically being reestablished as soon as a switchover occurs.
[edit protocols bgp] user@R1# set group to_r0 idle-after-switch-over 300 user@R1# set group to_R2 idle-after-switch-over 300
Configure the autonomous system (AS) number.
[edit routing-options] user@R1# set routing-options autonomous-system 200
Results
Confirm your configuration by entering the show command from configuration
mode in the dynamic database, and the show interfaces, show protocols, show policy-options and show routing-options commands from configuration
mode in the standard database. If the output does not display the intended configuration,
repeat the instructions in this example to correct the configuration.
Device R1 Dynamic
[edit dynamic]
user@R1# show
policy-options {
prefix-list dyn_prfx1 {
172.16.1.0/24;
172.16.2.0/24;
172.16.3.0/24;
172.16.4.0/24;
172.16.5.0/24;
172.16.6.0/24;
172.16.7.0/24;
172.16.8.0/24;
}
prefix-list dyn_prfx2 {
172.16.2.0/24;
172.16.3.0/24;
172.16.4.0/24;
172.16.5.0/24;
172.16.6.0/24;
}
policy-statement dyn_policy1 {
term t1 {
from {
prefix-list dyn_prfx1;
}
then accept;
}
term t2 {
then reject;
}
}
policy-statement dyn_policy2 {
term t1 {
from {
prefix-list dyn_prfx2;
}
then accept;
}
term t2 {
then reject;
}
}
}
Device R1 Standard
[edit]
user@R1# show interfaces
fe-1/2/0 {
unit 0 {
family inet {
address 10.0.0.2/30;
}
}
}
fe-1/2/1 {
unit 0 {
family inet {
address 172.16.4.2/24;
address 172.16.3.2/24;
address 172.16.2.2/24;
address 172.16.1.2/24;
address 172.16.5.2/24;
address 172.16.6.2/24;
address 172.16.7.2/24;
address 172.16.8.2/24;
address 172.16.9.2/24;
address 172.16.10.2/24;
}
}
}
fe-1/2/2 {
unit 0 {
family inet {
address 10.1.0.1/30;
}
}
}
fe-1/2/3 {
unit 0 {
family inet {
address 172.16.2.2/24;
address 172.16.3.2/24;
address 172.16.4.2/24;
address 172.16.5.2/24;
address 172.16.6.2/24;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.0.2/32;
}
}
}
user@R1# show protocols
bgp {
group to_r0 {
idle-after-switch-over 300;
neighbor 10.0.0.1 {
import dyn_policy1;
export dyn_policy2;
peer-as 100;
}
}
group to_R2 {
import static_policy1;
export static_policy2;
idle-after-switch-over 300;
neighbor 10.1.0.2 {
peer-as 300;
}
}
}
user@R1# show policy-options
prefix-list static_prfx1 {
172.16.2.0/24;
172.16.3.0/24;
172.16.4.0/24;
172.16.5.0/24;
}
prefix-list static_prfx2 {
172.16.1.0/24;
172.16.2.0/24;
172.16.3.0/24;
172.16.4.0/24;
}
policy-statement dyn_policy1 {
dynamic-db;
}
policy-statement dyn_policy2 {
dynamic-db;
}
policy-statement static_policy1 {
term t1 {
from {
prefix-list static_prfx1;
}
then accept;
}
term t2 {
then reject;
}
}
policy-statement static_policy2 {
term t1 {
from {
prefix-list static_prfx2;
}
then accept;
}
term t2 {
then reject;
}
}
user@R1# show routing-options autonomous-system 200;
If you are done configuring the device, enter commit from configuration mode.
Verification
Confirm that the configuration is working properly.
- Checking the Configured Policies on Device R1
- Checking the Routes Advertised from Device R0 to Device R1
- Checking the Routes That Device R1 Is Receiving from Device R0
- Checking the Routes Advertised from Device R2 to Device R1
- Checking the Routes That Device R1 Is Receiving from Device R2
- Checking the Routes That Device R1 Is Advertising to Device R0
- Checking the Routes That Device R1 Is Advertising to Device R2
Checking the Configured Policies on Device R1
Purpose
Verify that Device R1 has the dynamic and static policies in effect.
Action
From Device R1, enter the show policy command.
user@R1> show policy Configured policies: dyn_policy1 dyn_policy2 static_policy1 static_policy2 dyn_policy1 dyn_policy2
Meaning
The dynamic policies are listed two times because they are configured two times, the first and central configuration in the dynamic database. The secondary configuration is in the static database, where the dynamic database is referenced, as shown here:
Configured in the Dynamic Database
policy-statement dyn_policy1 {
term t1 {
from {
prefix-list dyn_prfx1;
}
then accept;
}
term t2 {
then reject;
}
}
policy-statement dyn_policy2 {
term t1 {
from {
prefix-list dyn_prfx2;
}
then accept;
}
term t2 {
then reject;
}
}
Referenced from the Static Database
policy-statement dyn_policy1 {
dynamic-db;
}
policy-statement dyn_policy2 {
dynamic-db;
}
Checking the Routes Advertised from Device R0 to Device R1
Purpose
Verify that Device R0’s routing policy is working.
Action
From Device R0, enter the show route advertising-protocol bgp command,
using the neighbor address for Device R1.
user@R0> show route advertising-protocol bgp 10.0.0.2 inet.0: 28 destinations, 28 routes (28 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 172.16.1.0/24 Self I * 172.16.2.0/24 Self I * 172.16.3.0/24 Self I * 172.16.4.0/24 Self I * 172.16.5.0/24 Self I * 172.16.6.0/24 Self I * 172.16.7.0/24 Self I * 172.16.8.0/24 Self I * 172.16.9.0/24 Self I * 172.16.10.0/24 Self I * 10.0.0.0/30 Self I
Meaning
Device R0 is sending the expected routes to Device R1.
Checking the Routes That Device R1 Is Receiving from Device R0
Purpose
Verify that Device R1’s import routing policy is working.
Action
From Device R1, enter the show route receive-protocol bgp command,
using the neighbor address for Device R0.
user@R1> show route receive-protocol bgp 10.0.0.1 inet.0: 35 destinations, 51 routes (35 active, 0 holddown, 4 hidden) Prefix Nexthop MED Lclpref AS path 172.16.1.0/24 10.0.0.1 100 I 172.16.2.0/24 10.0.0.1 100 I 172.16.3.0/24 10.0.0.1 100 I 172.16.4.0/24 10.0.0.1 100 I 172.16.5.0/24 10.0.0.1 100 I 172.16.6.0/24 10.0.0.1 100 I 172.16.7.0/24 10.0.0.1 100 I 172.16.8.0/24 10.0.0.1 100 I
Meaning
Some of the routes that are sent by Device R0 are not received by Device R1.
The routes 172.16.9.0/24, 172.16.10.0/24, and 10.0.0.0/30 are missing. This is because Device
R1’s import policy, applied to the BGP peering session with Device R0 using the import dyn_policy1 statement, specifically defines a prefix list limited to the following
routes:
prefix-list dyn_prfx1 {
172.16.1.0/24;
172.16.2.0/24;
172.16.3.0/24;
172.16.4.0/24;
172.16.5.0/24;
172.16.6.0/24;
172.16.7.0/24;
172.16.8.0/24;
}
Checking the Routes Advertised from Device R2 to Device R1
Purpose
Verify that Device R2’s routing policy is working.
Action
From Device R2, enter the show route advertising-protocol bgp command,
using the neighbor address for Device R1.
user@R2> show route advertising-protocol bgp 10.1.0.1 inet.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 172.16.2.0/24 Self I * 172.16.3.0/24 Self I * 172.16.4.0/24 Self I * 172.16.5.0/24 Self I * 172.16.6.0/24 Self I
Meaning
Device R2 is sending the expected routes to Device R1.
Checking the Routes That Device R1 Is Receiving from Device R2
Purpose
Verify that Device R1’s import routing policy is working.
Action
From Device R1, enter the show route receive-protocol bgp command,
using the neighbor address for Device R0.
user@R1> show route receive-protocol bgp 10.1.0.2 inet.0: 35 destinations, 51 routes (35 active, 0 holddown, 4 hidden) Prefix Nexthop MED Lclpref AS path 172.16.2.0/24 10.1.0.2 300 I 172.16.3.0/24 10.1.0.2 300 I 172.16.4.0/24 10.1.0.2 300 I 172.16.5.0/24 10.1.0.2 300 I
Meaning
One of the routes that is sent by Device R2 is not received by Device R1. The
route 172.16.6.0/24 is missing. This is because Device R1’s import policy, applied to
the BGP peering session with Device R2 using the import static_policy1 statement,
specifically defines a prefix list limited to the following routes:
prefix-list static_prfx1 {
172.16.2.0/24;
172.16.3.0/24;
172.16.4.0/24;
172.16.5.0/24;
}
Checking the Routes That Device R1 Is Advertising to Device R0
Purpose
Verify that Device R1’s export routing policy is working.
Action
From Device R1, enter the show route advertising-protocol bgp command,
using the neighbor address for Device R0.
user@R1> show route advertising-protocol bgp 10.0.0.1 inet.0: 35 destinations, 51 routes (35 active, 0 holddown, 4 hidden) Prefix Nexthop MED Lclpref AS path * 172.16.2.0/24 Self I * 172.16.3.0/24 Self I * 172.16.4.0/24 Self I * 172.16.5.0/24 Self I * 172.16.6.0/24 Self I
Meaning
Perhaps unexpectedly, the route that Device R1 did not receive through BGP from Device R2 (172.16.6.0/24) is nonetheless being advertised by Device R1 through BGP to Device R0. This is happening for two reasons. The first reason is that route 172.16.6.0/24 is in Device R1’s routing table, albeit as a direct route, as shown here:
user@R1> show route 172.16.6.0/24 protocol direct
inet.0: 35 destinations, 51 routes (35 active, 0 holddown, 4 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.6.0/24 *[Direct/0] 2d 22:51:41
> via fe-1/2/3.0The second reason is that Device R1’s export policy, applied to the BGP peering
session with Device R0 using the export dyn_policy2 statement, specifically defines
a prefix list limited to the following routes:
prefix-list dyn_prfx2 {
172.16.2.0/24;
172.16.3.0/24;
172.16.4.0/24;
172.16.5.0/24;
172.16.6.0/24;
}
Note the inclusion of 172.16.6.0/24.
Checking the Routes That Device R1 Is Advertising to Device R2
Purpose
Verify that Device R1’s export routing policy is working.
Action
From Device R1, enter the show route advertising-protocol bgp command,
using the neighbor address for Device R2.
user@R1> show route advertising-protocol bgp 10.1.0.2 inet.0: 35 destinations, 51 routes (35 active, 0 holddown, 4 hidden) Prefix Nexthop MED Lclpref AS path * 172.16.1.0/24 Self I * 172.16.2.0/24 Self I * 172.16.3.0/24 Self I * 172.16.4.0/24 Self I
Meaning
Device R1 is sending the expected routes to Device R2. Device R1’s export
policy, applied to the BGP peering session with Device R2 using the export static_policy2 statement, specifically defines a prefix list limited to the following routes:
prefix-list static_prfx2 {
172.16.1.0/24;
172.16.2.0/24;
172.16.3.0/24;
172.16.4.0/24;
}