Rate and give feedback:  Feedback Received. Thank You!

Rate and give feedback: 

X

This document helped resolve my issue

Yes No

Additional Comments

800 characters remaining

May we contact you if necessary?

Name:  

E-mail: 

Enter a valid Email ID

Need product assistance? Contact Juniper Support

Submit

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply.

English  

English

Example: Configuring BGP 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.

Note: 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:

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 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.

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 65535:65284;

Requirements

Junos OS 9.3 or later is required.

Overview

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 172.16.6.0/24. Device R2 does not set the local preference in an import policy for Device R1’s routes, and thus 172.16.6.0/24 has the default local preference of 100.

Device R3 advertises 172.16.6.0/24 with a local preference of 200.

When the advertise-external statement is not configured on Device R2, 172.16.6.0/24 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, 172.16.6.0/24 is advertised by Device R2 toward Device R3.

When advertise-external conditional is configured on Device R2 on the session toward Device R3, 172.16.6.0/24 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), 172.16.6.0/24 is advertised by Device R2 toward Device R3.

Topology

Figure 1 shows the sample network.

Figure 1: BGP Topology for advertise-external

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

The section Step-by-Step Procedure 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.

Step-by-Step Procedure

1. Configure the device interfaces.
   [edit interfaces]user@R2# set fe-1/2/0 unit 0 description to-R1user@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 description to-R3user@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
2. Configure OSPF or another interior gateway protocol (IGP).
   [edit protocols ospf area 0.0.0.0]user@R2# set interface fe-1/2/1.0user@R2# set interface lo0.0 passive
3. Configure the EBGP connection to Device R1.
   [edit protocols bgp group ext]user@R2# set type externaluser@R2# set peer-as 100user@R2# set neighbor 10.0.0.1
4. Configure the IBGP connection to Device R3.
   [edit protocols bgp group int]user@R2# set type internaluser@R2# set local-address 192.168.0.2user@R2# set neighbor 192.168.0.3
5. Add the advertise-external statement to the IBGP group peering session.
   [edit protocols bgp group int]user@R2# set advertise-external
6. Configure the autonomous system (AS) number and the router ID.
   [edit routing-options ]user@R2# set router-id 192.168.0.2user@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.

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 conditional Option

Verifying the BGP Active Path

Purpose

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

Action

inet.0: 8 destinations, 9 routes (8 active, 1 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.6.0/24      *[BGP/170] 00:00:07, localpref 200, from 192.168.0.3
                      AS path: I, validation-state: unverified
                    > to 10.0.0.6 via fe-1/2/1.0
                    [BGP/170] 03:23:03, 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.6.0/24 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

Purpose

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

Action

inet.0: 8 destinations, 9 routes (8 active, 1 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  172.16.6.0/24           10.0.0.1                     100        100 I

Meaning

Device R2 is advertising the 172.16.6.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

inet.0: 7 destinations, 8 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.6.0/24      *[Static/5] 03:34:14
                      Reject
                    [BGP/170] 06:34:43, localpref 100, from 192.168.0.2
                      AS path: 100 I, validation-state: unverified
                    > to 10.0.0.5 via fe-1/2/0.6

Meaning

Device R3 has the static route and the BGP route for 172.16.6.0/24.

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 0.0.0.0/0 next-hop 10.0.0.5).

Experimenting with the conditional Option

Purpose

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

Action

1. On Device R2, add the conditional option.
   [edit protocols bgp group int]user@R2# set advertise-external conditionaluser@R2# commit
2. On Device R2, check to see if the 172.16.6.0/24 route is advertised toward Device R3.
   
   user@R2> show route advertising-protocol bgp 192.168.0.3

   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.
   [edit policy-options policy-statement send-static term 1]user@R3# deactivate logical-systems R3 then local-preference user@R3# commit
4. On Device R2, ensure that the local preferences of the two paths are equal.
   
   user@R2> show route 172.16.6.0/24

   inet.0: 8 destinations, 9 routes (8 active, 0 holddown, 0 hidden)
   + = Active Route, - = Last Active, * = Both
   
   172.16.6.0/24      *[BGP/170] 08:02:59, localpref 100
                         AS path: 100 I, validation-state: unverified
                       > to 10.0.0.1 via fe-1/2/0.0
                       [BGP/170] 00:07:51, localpref 100, from 192.168.0.3
                         AS path: I, validation-state: unverified
                       > to 10.0.0.6 via fe-1/2/1.0

5. On Device R2, add the as-path-ignore statement.
   [edit protocols bgp]user@R2# set path-selection as-path-ignore user@R2# commit
6. On Device R2, check to see if the 172.16.6.0/24 route is advertised toward Device R3.
   
   user@R2> show route advertising-protocol bgp 192.168.0.3

   inet.0: 8 destinations, 9 routes (8 active, 0 holddown, 0 hidden)
     Prefix                  Nexthop              MED     Lclpref    AS path
   * 172.16.6.0/24           10.0.0.1                     100        100 I

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