ON THIS PAGE
Example: Configuring BGP to Advertise Inactive Routes
By default, BGP readvertises only active routes.
To have the routing table export to BGP the best route learned by
BGP even if Junos OS did not select it to be an active route, include
the advertise-inactive
statement:
advertise-inactive;
In Junos OS, BGP advertises BGP routes that are installed or
active, which are routes selected as the best based on the BGP path
selection rules. The advertise-inactive
statement allows
nonactive BGP routes to be advertised to other peers.
If the routing table has two BGP routes where one is active
and the other is inactive, the advertise-inactive
statement
does not advertise the inactive BGP prefix. This statement does not
advertise an inactive BGP route in the presence of another active
BGP route. However, if the active route is a static route, the advertise-inactive
statement advertises the inactive BGP route.
The advertise-inactive
statement does not help to advertise the
inactive route from the VRF when the router is configured as a route reflector.
Junos OS also provides support for configuring a BGP export policy that matches the state of an advertised route. You can match either active or inactive routes, as follows:
policy-options { policy-statement name{ from state (active|inactive); } }
This qualifier only matches when used in the context of an export
policy. When a route is being advertised by a protocol that can advertise
inactive routes (such as BGP), state inactive
matches routes
advertised as a result of the advertise-inactive
(or advertise-external
) statement.
For example, the following configuration can be used
as a BGP export policy to mark routes advertised due to the advertise-inactive
setting with a user-defined community. That community can be later
used by the receiving routers to filter out such routes from the forwarding
table. Such a mechanism can be used to address concerns that advertising
paths not used for forwarding by the sender might lead to forwarding
loops.
user@host# show policy-options policy-statement mark-inactive { term inactive { from state inactive; then { community set comm-inactive; } } term default { from protocol bgp; then accept; } then reject; } community comm-inactive members 65536:65284;
Requirements
No special configuration beyond device initialization is required before configuring this example.
Overview
In this example, Device R2 has two external BGP (EBGP) peers, Device R1 and Device R3.
Device R1 has a static route to 172.16.5/24. Likewise, Device
R2 also has a static route to 172.16.5/24. Through BGP, Device R1
sends information about its static route to Device R2. Device R2 now
has information about 172.16.5/24 from two sources—its own static
route and the BGP-learned route received from Device R1. Static routes
are preferred over BGP-learned routes, so the BGP route is inactive
on Device R2. Normally Device R2 would send the BGP-learned information
to Device R3, but Device R2 does not do this because the BGP route
is inactive. Device R3, therefore, has no information about 172.16.5/24
unless you enable the advertise-inactive
command on Device
R2, which causes Device R2 to send the BGP-learned to Device R3.
Topology
Figure 1 shows the sample network.

CLI Quick Configuration shows the configuration for all of the devices in Figure 1.
The section #configuration163__policy-advertise-inactive-st describes the steps on Device R2.
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 R1
set interfaces fe-1/2/0 unit 0 family inet address 10.0.0.1/30 set interfaces lo0 unit 0 family inet address 192.168.0.1/32 set protocols bgp group to_R2 type external set protocols bgp group to_R2 export send-static set protocols bgp group to_R2 neighbor 10.0.0.2 peer-as 200 set policy-options policy-statement send-static term 1 from protocol static set policy-options policy-statement send-static term 1 then accept set routing-options static route 172.16.5.0/24 discard set routing-options static route 172.16.5.0/24 install set routing-options autonomous-system 100
Device R2
set interfaces fe-1/2/0 unit 0 family inet address 10.0.0.2/30 set interfaces fe-1/2/1 unit 0 family inet address 10.0.0.5/30 set interfaces lo0 unit 0 family inet address 192.168.0.2/32 set protocols bgp group to_R1 type external set protocols bgp group to_R1 neighbor 10.0.0.1 peer-as 100 set protocols bgp group to_R3 type external set protocols bgp group to_R3 advertise-inactive set protocols bgp group to_R3 neighbor 10.0.0.6 peer-as 300 set routing-options static route 172.16.5.0/24 discard set routing-options static route 172.16.5.0/24 install set routing-options autonomous-system 200
Device R3
set interfaces fe-1/2/1 unit 0 family inet address 10.0.0.6/30 set interfaces fe-1/2/0 unit 9 family inet address 10.0.0.9/30 set interfaces lo0 unit 0 family inet address 192.168.0.3/32 set protocols bgp group ext type external set protocols bgp group ext peer-as 200 set protocols bgp group ext neighbor 10.0.0.5 set routing-options autonomous-system 300
Procedure
Step-by-Step Procedure
The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.
To configure Device R2:
Configure the device interfaces.
[edit interfaces] user@R2# set fe-1/2/0 unit 0 family inet address 10.0.0.2/30 user@R2# set fe-1/2/1 unit 0 family inet address 10.0.0.5/30 user@R2# set lo0 unit 0 family inet address 192.168.0.2/32
Configure the EBGP connection to Device R1.
[edit protocols bgp group to_R1] user@R2# set type external user@R2# set neighbor 10.0.0.1 peer-as 100
Configure the EBGP connection to Device R3.
[edit protocols bgp group to_R3] user@R2# set type external user@R2# set neighbor 10.0.0.6 peer-as 300
Add the
advertise-inactive
statement to the EBGP group peering session with Device R3.[edit protocols bgp group to_R3] user@R2# set advertise-inactive
Configure the static route to the 172.16.5.0/24 network.
[edit routing-options static] user@R2# set route 172.16.5.0/24 discard user@R2# set route 172.16.5.0/24 install
Configure the autonomous system (AS) number.
[edit routing-options] user@R2# set autonomous-system 200
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.
user@R2# 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 10.0.0.5/30; } } } lo0 { unit 0 { family inet { address 192.168.0.2/32; } } }
user@R2# show protocols bgp { group to_R1 { type external; neighbor 10.0.0.1 { peer-as 100; } } group to_R3 { type external; advertise-inactive; neighbor 10.0.0.6 { peer-as 300; } } }
user@R2# show routing-options static { route 172.16.5.0/24 { discard; install; } } autonomous-system 200;
If you are done configuring the device, enter commit
from configuration mode.
Verification
Confirm that the configuration is working properly.
- Verifying the BGP Active Path
- Verifying the External Route Advertisement
- Verifying the Route on Device R3
- Experimenting with the advertise-inactive Statement
Verifying the BGP Active Path
Purpose
On Device R2, make sure that the 172.16.5.0/24 prefix is in the routing table and has the expected active path.
Action
user@R2> show route 172.16.5 inet.0: 7 destinations, 8 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.5.0/24 *[Static/5] 21:24:38 Discard [BGP/170] 21:21:41, localpref 100 AS path: 100 I, validation-state: unverified > to 10.0.0.1 via fe-1/2/0.0
Meaning
Device R2 receives the 172.16.5.0/24 route from both Device R1 and from its own statically configured route. The static route is the active path, as designated by the asterisk (*). The static route path has the lowest route preference (5) as compared to the BGP preference (170). Therefore, the static route becomes active.
Verifying the External Route Advertisement
Purpose
On Device R2, make sure that the 172.16.5.0/24 route is advertised toward Device R3.
Action
user@R2> show route advertising-protocol bgp 10.0.0.6 inet.0: 6 destinations, 7 routes (6 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 172.16.5.0/24 Self 100 I
Meaning
Device R2 is advertising the 172.16.5.0/24 route toward Device R3
Verifying the Route on Device R3
Purpose
Make sure that the 172.16.6.0/24 prefix is in Device R3’s routing table.
Action
user@R3> show route 172.16.5.0/24 inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.5.0/24 *[BGP/170] 00:01:19, localpref 100 AS path: 200 100 I, validation-state: unverified > to 10.0.0.5 via fe-1/2/1.0
Meaning
Device R3 has the BGP-learned route for 172.16.5.0/24.
Experimenting with the advertise-inactive Statement
Purpose
See what happens when the advertise-inactive
statement is removed from the BGP configuration on Device R2.
Action
On Device R2, deactivate the
advertise-inactive
statement.[edit protocols bgp group to_R3] user@R2# deactivate advertise-inactive user@R2# commit
On Device R2, check to see if the 172.16.5.0/24 route is advertised toward Device R3.
user@R2> show route advertising-protocol bgp 10.0.0.6
As expected, the route is no longer advertised.
On Device R3, ensure that the 172.16.5/24 route is absent from the routing table.
user@R3> show route 172.16.5/24
Meaning
Device R1 advertises route 172.16.5/24 to Device R2,
but Device R2 has a manually configured static route for this prefix.
Static routes are preferred over BGP routes, so Device R2 installs
the BGP route as an inactive route. Because the BGP route is not active,
Device R2 does not readvertise the BGP route to Device R3. This is
the default behavior in Junos OS. If you add the advertise-inactive
statement to the BGP configuration on Device R2, Device R2 readvertises
nonactive routes.