Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Example: Enabling BGP Route Advertisements

 

Junos OS does not advertise the routes learned from one EBGP peer back to the same external BGP (EBGP) peer. In addition, the software does not advertise those routes back to any EBGP peers that are in the same autonomous system (AS) as the originating peer, regardless of the routing instance. You can modify this behavior by including the advertise-peer-as statement in the configuration.

If you include the advertise-peer-as statement in the configuration, BGP advertises the route regardless of this check.

To restore the default behavior, include the no-advertise-peer-as statement in the configuration:

The route suppression default behavior is disabled if the as-override statement is included in the configuration. If you include both the as-override and no-advertise-peer-as statements in the configuration, the no-advertise-peer-as statement is ignored.

Requirements

No special configuration beyond device initialization is required before you configure this example.

Overview

This example shows three routing devices with external BGP (EBGP) connections. Device R2 has an EBGP connection to Device R1 and another EBGP connection to Device R3. Although separated by Device R2 which is in AS 64511, Device R1 and Device R3 are in the same AS (AS 64512). Device R1 and Device R3 advertise into BGP direct routes to their own loopback interface addresses.

Device R2 receives these loopback interface routes, and the advertise peer-as statement allows Device R2 to advertise them. Specifically, Device R1 sends the 192.168.0.1 route to Device R2, and because Device R2 has the advertise peer-as configured, Device R2 can send the 192.168.0.1 route to Device R3. Likewise, Device R3 sends the 192.168.0.3 route to Device R2, and advertise peer-as enables Device R2 to forward the route to Device R1.

To enable Device R1 and Device R3 to accept routes that contain their own AS number in the AS path, the loops 2 statement is required on Device R1 and Device R3.

Topology

Figure 1: BGP Topology for advertise-peer-as
BGP Topology for advertise-peer-as

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

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 CLI User Guide.

To configure Device R1:

  1. Configure the device interfaces.
  2. Configure BGP.
  3. Prevent routes from Device R3 from being hidden on Device R1 by including the loops 2 statement.

    The loops 2 statement means that the local device’s own AS number can appear in the AS path up to one time without causing the route to be hidden. The route is hidden if the local device’s AS number is detected in the path two or more times.

  4. Configure the routing policy that sends direct routes.
  5. Apply the export policy to the BGP peering session with Device R2.
  6. Configure the autonomous system (AS) number.

Step-by-Step Procedure

To configure Device R2:

  1. Configure the device interfaces.
  2. Configure BGP.
  3. Configure Device R2 to advertise routes learned from one EBGP peer to another EBGP peer in the same AS.

    In other words, advertise to Device R1 routes learned from Device R3 (and the reverse), even though Device R1 and Device R3 are in the same AS.

  4. Configure a routing policy that sends direct routes.
  5. Apply the export policy.
  6. Configure the AS number.

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.

Device R1

Device R2

If you are done configuring the devices, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Verifying the BGP Routes

Purpose

Make sure that the routing tables on Device R1 and Device R3 contain the expected routes.

Action

  1. On Device R2, deactivate the advertise-peer-as statement in the BGP configuration.

  2. On Device R3, deactivate the loops statement in the BGP configuration.



  3. On Device R1, check to see what routes are advertised to Device R2.

    user@R1> show route advertising-protocol bgp 10.0.0.2
  4. On Device R2, check to see what routes are received from Device R1.

    user@R2> show route receive-protocol bgp 10.0.0.1
  5. On Device R2, check to see what routes are advertised to Device R3.

    user@R2> show route advertising-protocol bgp 10.1.0.2
  6. On Device R2, activate the advertise-peer-as statement in the BGP configuration.

  7. On Device R2, recheck the routes that are advertised to Device R3.

    user@R2> show route advertising-protocol bgp 10.1.0.2
  8. On Device R3, check the routes that are received from Device R2.

    user@R3> show route receive-protocol bgp 10.1.0.1
  9. On Device R3, activate the loops statement in the BGP configuration.



  10. On Device R3, recheck the routes that are received from Device R2.

    user@R3> show route receive-protocol bgp 10.1.0.1

Meaning

First the advertise-peer-as statement and the loops statement are deactivated so that the default behavior can be examined. Device R1 sends to Device R2 a route to Device R1’s loopback interface address, 192.168.0.1/32. Device R2 does not advertise this route to Device R3. After activating the advertise-peer-as statement, Device R2 does advertise the 192.168.0.1/32 route to Device R3. Device R3 does not accept this route until after the loops statement is activated.