Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


Example: Configuring a Routing Policy to Advertise the Best External Route to Internal Peers

The BGP protocol specification, as defined in RFC 1771, specifies that a BGP peer shall advertise to its internal peers the higher preference external path, even if this path is not the overall best (in other words, even if the best path is an internal path). In practice, deployed BGP implementations do not follow this rule. The reasons for deviating from the specification are as follows:

  • Minimizing the amount of advertised information. BGP scales according to the number of available paths.

  • Avoiding routing and forwarding loops.

There are, however, several scenarios in which the behavior, specified in RFC 1771, of advertising the best external route might be beneficial. Limiting path information is not always desirable as path diversity might help reduce restoration times. Advertising the best external path can also address internal BGP (IBGP) route oscillation issues as described in RFC 3345, Border Gateway Protocol (BGP) Persistent Route Oscillation Condition.

The advertise-external statement modifies the behavior of a BGP speaker to advertise the best external path to IBGP peers, even when the best overall path is an internal path.


The advertise-external statement is supported at both the group and neighbor level. If you configure the statement at the neighbor level, you must configure it for all neighbors in a group. Otherwise, the group is automatically split into different groups.

The conditional option limits the behavior of the advertise-external setting, such that the external route is advertised only if the route selection process reaches the point where the multiple exit discriminator (MED) metric is evaluated. Thus, an external route is not advertised if it has, for instance, an AS path that is worse (longer) than that of the active path. The conditional option restricts external path advertisement to when the best external path and the active path are equal until the MED step of the route selection process. Note that the criteria used for selecting the best external path is the same whether or not the conditional option is configured.

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:

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 and advertise-external statements.

For example, the following configuration can be used as a BGP export policy toward internal peers to mark routes advertised due to the advertise-external 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.


Junos OS 9.3 or later is required.


This example shows three routing devices. Device R2 has an external BGP (EBGP) connection to Device R1. Device R2 has an IBGP connection to Device R3.

Device R1 advertises Device R2 does not set the local preference in an import policy for Device R1’s routes, and thus has the default local preference of 100.

Device R3 advertises with a local preference of 200.

When the advertise-external statement is not configured on Device R2, is not advertised by Device R2 toward Device R3.

When the advertise-external statement is configured on Device R2 on the session toward Device R3, is advertised by Device R2 toward Device R3.

When advertise-external conditional is configured on Device R2 on the session toward Device R3, is not advertised by Device R2 toward Device R3. If you remove the then local-preference 200 setting on Device R3 and add the path-selection as-path-ignore setting on Device R2 (thus making the path selection criteria equal until the MED step of the route selection process), is advertised by Device R2 toward Device R3.


To configure the advertise-external statement on a route reflector, you must disable intracluster reflection with the no-client-reflect statement, and the client cluster must be fully meshed to prevent the sending of redundant route advertisements.

When a routing device is configured as a route reflector for a cluster, a route advertised by the route reflector is considered internal if it is received from an internal peer with the same cluster identifier or if both peers have no cluster identifier configured. A route received from an internal peer that belongs to another cluster, that is, with a different cluster identifier, is considered external.


Figure 1 shows the sample network.

Figure 1: BGP Topology for advertise-externalBGP Topology for advertise-external

CLI Quick Configuration shows the configuration for all of the devices in Figure 1.

The section #configuration148__policy-advertise-external-st describes the steps on Device R2.


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

Device R2

Device R3


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:

  1. Configure the device interfaces.

  2. Configure OSPF or another interior gateway protocol (IGP).

  3. Configure the EBGP connection to Device R1.

  4. Configure the IBGP connection to Device R3.

  5. Add the advertise-external statement to the IBGP group peering session.

  6. Configure the autonomous system (AS) number and the router ID.


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.


Confirm that the configuration is working properly.

Verifying the BGP Active Path


On Device R2, make sure that the prefix is in the routing table and has the expected active path.



Device R2 receives the route from both Device R1 and Device R3. The route from Device R3 is the active path, as designated by the asterisk (*). The active path has the highest local preference. Even if the local preferences of the two routes were equal, the route from Device R3 would remain active because it has the shortest AS path.

Verifying the External Route Advertisement


On Device R2, make sure that the route is advertised toward Device R3.



Device R2 is advertising the route toward Device R3.

Verifying the Route on Device R3


Make sure that the prefix is in Device R3’s routing table.



Device R3 has the static route and the BGP route for

Note that the BGP route is hidden on Device R3 if the route is not reachable or if the next hop cannot be resolved. To fulfill this requirement, this example includes a static default route on Device R3 (static route next-hop

Experimenting with the conditional Option


See how the conditional option works in the context of the BGP path selection algorithm.


  1. On Device R2, add the conditional option.

  2. On Device R2, check to see if the route is advertised toward Device R3.

    As expected, the route is no longer advertised. You might need to wait a few seconds to see this result.

  3. On Device R3, deactivate the then local-preference policy action.

  4. On Device R2, ensure that the local preferences of the two paths are equal.

  5. On Device R2, add the as-path-ignore statement.

  6. On Device R2, check to see if the route is advertised toward Device R3.

    As expected, the route is now advertised because the AS path length is ignored and because the local preferences are equal.