Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Autonomous Systems for BGP Sessions

 

Understanding the BGP Local AS Attribute

When an Internet service provider (ISP) acquires a network that belongs to a different autonomous system (AS), there is no seamless method for moving the BGP peers of the acquired network to the AS of the acquiring ISP. The process of configuring the BGP peers with the new AS number can be time-consuming and cumbersome. Sometimes customers do not want to or are not immediately able to modify their peer arrangements or configuration. During this kind of transition period, it can be useful to configure BGP-enabled devices in the new AS to use the former AS number in BGP updates. This former AS number is called a local AS.

Using a local AS number permits the routing devices in an acquired network to appear to belong to the former AS.

For example, ISP A, with an AS of 200, acquires ISP B, with an AS of 250. ISP B has a customer, ISP C, that does not want to change its configuration. After ISP B becomes part of ISP A, a local AS number of 250 is configured for use in EBGP peer sessions with ISP C. Consequently, the local AS number of 250 is either prepended before or used instead of the global AS number of 200 in the AS path used to export routes to direct external peers in ISP C.

If the route is received from an internal BGP (IBGP) peer, the AS path includes the local AS number prepended before the global AS number.

The local AS number is used instead of the global AS number if the route is an external route, such as a static route or an interior gateway protocol (IGP) route that is imported into BGP. If the route is external and you want the global AS number to be included in the AS path, you can apply a routing policy that uses as-path-expand or as-path-prepend. Use the as-path-expand policy action to place the global AS number behind the local AS number. Use the as-path-prepend policy action to place the global AS number in front of the local AS number.

For example:

user@R3# run show route 1.1.1.1 protocol bgp

In a Layer 3 VPN scenario, in which a provider edge (PE) device uses external BGP (EBGP) to peer with a customer edge (CE) device, the local-as statement behaves differently than in the non-VPN scenario. In the VPN scenario, the global AS number defined in the master instance is prepended to the AS path by default. To override this behavior, you can configure the no-prepend-global-as in the routing-instance BGP configuration on the PE device, as shown here:

The Junos operating system (Junos OS) implementation of the local AS attribute supports the following options:

  • Local AS with private option—When you use the private option, the local AS is used during the establishment of the BGP session with an EBGP neighbor but is hidden in the AS path sent to other EBGP peers. Only the global AS is included in the AS path sent to external peers.

    The private option is useful for establishing local peering with routing devices that remain configured with their former AS or with a specific customer that has not yet modified its peer arrangements. The local AS is used to establish the BGP session with the EBGP neighbor but is hidden in the AS path sent to external peers in another AS.

    Include the private option so that the local AS is not prepended before the global AS in the AS path sent to external peers. When you specify the private option, the local AS is prepended only in the AS path sent to the EBGP neighbor.

    For example, in Figure 1, Router 1 and Router 2 are in AS 64496, Router 4 is in AS 64511, and Router 3 is in AS 64510. Router 2 formerly belonged to AS 64497, which has merged with another network and now belongs to AS 64496. Because Router 3 still peers with Router 2 using its former AS (64497), Router 2 needs to be configured with a local AS of 64497 in order to maintain peering with Router 3. Configuring a local AS of 64497 permits Router 2 to add AS 64497 when advertising routes to Router 3. Router 3 sees an AS path of 64497 64496 for the prefix 10/8.

    Figure 1: Local AS Configuration
    Local AS Configuration

    To prevent Router 2 from adding the local AS number in its announcements to other peers, use the local-as 64497 private statement. This statement configures Router 2 to not include local AS 64497 when announcing routes to Router 1 and to Router 4. In this case, Router 4 sees an AS path of 64496 64510 for the prefix 10.222/16.

  • Local AS with alias option—In Junos OS Release 9.5 and later, you can configure a local AS as an alias. During the establishment of the BGP open session, the AS used in the open message alternates between the local AS and the global AS. If the local AS is used to connect with the EBGP neighbor, then only the local AS is prepended to the AS path when the BGP peer session is established. If the global AS is used to connect with the EBGP neighbor, then only the global AS is prepended to the AS path when the BGP peer session is established. The use of the alias option also means that the local AS is not prepended to the AS path for any routes learned from that EBGP neighbor. Therefore, the local AS remains hidden from other external peers.

    Configuring a local AS with the alias option is especially useful when you are migrating the routing devices in an acquired network to the new AS. During the migration process, some routing devices might be configured with the new AS while others remain configured with the former AS. For example, it is good practice to start by first migrating to the new AS any routing devices that function as route reflectors. However, as you migrate the route reflector clients incrementally, each route reflector has to peer with routing devices configured with the former AS, as well as peer with routing devices configured with the new AS. To establish local peer sessions, it can be useful for the BGP peers in the network to use both the local AS and the global AS. At the same time, you want to hide this local AS from external peers and use only the global AS in the AS path when exporting routes to another AS. In this kind of situation, configure the alias option.

    Include the alias option to configure the local AS as an alias to the global AS configured at the [edit routing-options] hierarchy level. When you configure a local AS as an alias, during the establishment of the BGP open session, the AS used in the open message alternates between the local AS and the global AS. The local AS is prepended to the AS path only when the peer session with an EBGP neighbor is established using that local AS. The local AS is hidden in the AS path sent to any other external peers. Only the global AS is prepended to the AS path when the BGP session is established using the global AS.

    Note

    The private and alias options are mutually exclusive. You cannot configure both options with the same local-as statement.

  • Local AS with option not to prepend the global AS—In Junos OS Release 9.6 and later, you can configure a local AS with the option not to prepend the global AS. Only the local AS is included in the AS path sent to external peers.

    Use the no-prepend-global-as option when you want to strip the global AS number from outbound BGP updates in a virtual private network (VPN) scenario. This option is useful in aVPN scenario in which you want to hide the global AS from the VPN.

    Include the no-prepend-global-as option to have the global AS configured at the [edit routing-options] hierarchy level removed from the AS path sent to external peers. When you use this option, only the local AS is included in the AS path for the routes sent to a customer edge (CE) device.

  • Number of loops option—The local AS feature also supports specifying the number of times that detection of the AS number in the AS_PATH attribute causes the route to be discarded or hidden. For example, if you configure loops 1, the route is hidden if the AS number is detected in the path one or more times. This is the default behavior. If you configure loops 2, the route is hidden if the AS number is detected in the path two or more times.

    For the loops number statement, you can configure 1 through 10.

    Note

    If you configure the local AS values for any BGP group, the detection of routing loops is performed using both the AS and the local AS values for all BGP groups.

    If the local AS for the EBGP or IBGP peer is the same as the current AS, do not use the local-as statement to specify the local AS number.

    When you configure the local AS within a VRF, this impacts the AS path loop-detection mechanism. All of the local-as statements configured on the device are part of a single AS domain. The AS path loop-detection mechanism is based on looking for a matching AS present in the domain.

Example: Configuring a Local AS for EBGP Sessions

This example shows how to configure a local autonomous system (AS) for a BGP peer so that both the global AS and the local AS are used in BGP inbound and outbound updates.

Requirements

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

Overview

Use the local-as statement when ISPs merge and want to preserve a customer’s configuration, particularly the AS with which the customer is configured to establish a peer relationship. The local-as statement simulates the AS number already in place in customer routers, even if the ISP’s router has moved to a different AS.

This example shows how to use the local-as statement to configure a local AS. The local-as statement is supported for BGP at the global, group, and neighbor hierarchy levels.

When you configure the local-as statement, you must specify an AS number. You can specify a number from 1 through 4,294,967,295 in plain-number format. In Junos OS Release 9.1 and later, the range for AS numbers is extended to provide BGP support for 4-byte AS numbers as defined in RFC 4893, BGP Support for Four-octet AS Number Space. In Junos OS Release 9.3 and later, you can also configure a 4-byte AS number using the AS-dot notation format of two integer values joined by a period: <16-bit high-order value in decimal>.<16-bit low-order value in decimal>. For example, the 4-byte AS number of 65,546 in plain-number format is represented as 1.10 in the AS-dot notation format. You can specify a value from 0.0 through 65535.65535 in AS-dot notation format. Junos OS continues to support 2-byte AS numbers. The 2-byte AS number range is 1 through 65,535 (this is a subset of the 4-byte range).

Figure 2 shows the sample topology.

Figure 2: Topology for Configuring the Local AS
Topology for Configuring the Local
AS

In this example, Device R2 formerly belonged to AS 250 and now is in AS 200. Device R1 and Device R3 are configured to peer with AS 250 instead of with the new AS number (AS 200). Device R2 has the new AS number configured with the autonomous-system 200 statement. To enable the peering sessions to work, the local-as 250 statement is added in the BGP configuration. Because local-as 250 is configured, Device R2 includes both the global AS (200) and the local AS (250) in its BGP inbound and outbound updates.

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

Configuring Device R1

Step-by-Step Procedure

The following example requires you to 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 interfaces.
  2. Configure external BGP (EBGP).
  3. Configure the routing policy.
  4. Configure a static route to the remote network between Device R2 and Device R3.
  5. Configure the global AS number.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

When you are done configuring the device, enter commit from configuration mode.

Configuring Device R2

Step-by-Step Procedure

The following example requires you to 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 R2:

  1. Configure the interfaces.
  2. Configure EBGP.
  3. Configure the local autonomous system (AS) number.
  4. Configure the global AS number.
  5. Configure the routing policy.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

When you are done configuring the device, enter commit from configuration mode.

Configuring Device R3

Step-by-Step Procedure

The following example requires you to 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 R3:

  1. Configure the interfaces.
  2. Configure EBGP.
  3. Configure the global autonomous system (AS) number.
  4. Configure a static route to the remote network between Device R1 and Device R2.
  5. Configure the routing policy.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

When you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Checking the Local and Global AS Settings

Purpose

Make sure that Device R2 has the local and global AS settings configured.

Action

From operational mode, enter the show bgp neighbors command.

user@R2> show bgp neighbors

Meaning

The Local AS: 250 and Local System AS: 200 output shows that Device R2 has the expected settings. Additionally, the output shows that the options list includes LocalAS.

Checking the BGP Peering Sessions

Purpose

Ensure that the sessions are established and that the local AS number 250 is displayed.

Action

From operational mode, enter the show bgp summary command.

user@R1> show bgp summary
user@R3> show bgp summary

Meaning

Device R1 and Device R3 appear to be peering with a device in AS 250, even though Device R2 is actually in AS 200.

Verifying the BGP AS Paths

Purpose

Make sure that the routes are in the routing tables and that the AS paths show the local AS number 250.

Action

From configuration mode, enter the set route protocol bgp command.

user@R1> show route protocol bgp
user@R3> show route protocol bgp

Meaning

The output shows that Device R1 and Device R3 appear to have routes with AS paths that include AS 250, even though Device R2 is actually in AS 200.

Example: Configuring a Private Local AS for EBGP Sessions

This example shows how to configure a private local autonomous system (AS) number. The local AS is considered to be private because it is advertised to peers that use the local AS number for peering, but is hidden in the announcements to peers that can use the global AS number for peering.

Requirements

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

Overview

Use the local-as statement when ISPs merge and want to preserve a customer’s configuration, particularly the AS with which the customer is configured to establish a peer relationship. The local-as statement simulates the AS number already in place in customer routers, even if the ISP’s router has moved to a different AS.

When you use the private option, the local AS is used during the establishment of the BGP session with an external BGP (EBGP) neighbor, but is hidden in the AS path sent to other EBGP peers. Only the global AS is included in the AS path sent to external peers.

The private option is useful for establishing local peering with routing devices that remain configured with their former AS or with a specific customer that has not yet modified its peer arrangements. The local AS is used to establish the BGP session with the EBGP neighbor, but is hidden in the AS path sent to external peers in another AS.

Include the private option so that the local AS is not prepended before the global AS in the AS path sent to external peers. When you specify the private option, the local AS is prepended only in the AS path sent to the EBGP neighbor.

Figure 3 shows the sample topology.

Figure 3: Topology for Configuring a Private Local AS
Topology for Configuring
a Private Local AS

Device R1 is in AS 64496. Device R2 is in AS 64510. Device R3 is in AS 64511. Device R4 is in AS 64512. Device R1 formerly belonged to AS 64497, which has merged with another network and now belongs to AS 64496. Because Device R3 still peers with Device R1, using its former AS, 64497, Device R1 needs to be configured with a local AS of 64497 in order to maintain peering with Device R3. Configuring a local AS of 64497 permits Device R1 to add AS 64497 when advertising routes to Device R3. Device R3 sees an AS path of 64497 64496 for the prefix 10.1.1.2/32, which is Device R2's loopback interface. Device R4, which is behind Device R3, sees an AS path of 64511 64497 64496 64510 to Device R2’s loopback interface. To prevent Device R1 from adding the local AS number in its announcements to other peers, this example includes the local-as 64497 private statement. The private option configures Device R1 to not include the local AS 64497 when announcing routes to Device R2. Device R2 sees an AS path of 64496 64511 to Device R3 and an AS path of 64496 64511 64512 to Device R4. The private option in Device R1's configuration causes the AS number 64497 to be missing from the AS paths that Device R1 readvertises to Device R2.

Device R1 is hiding the private local AS from all the routers, except Device R3. The private option applies to the routes that Device R1 receives (learns) from Device R3 and that Device R1, in turn, readvertises to other routers. When these routes learned from Device R3 are readavertised by Device R1 to Device R2, the private local AS is missing from the AS path advertised to 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

Device R2

Device R3

Device R4

Configuring Device R1

Step-by-Step Procedure

The following example requires you to 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 interfaces.
  2. Configure the EBGP peering session with Device R2.
  3. Configure the EBGP peering session with Device R3.
  4. Configure the routing policy.
  5. Configure the global autonomous system (AS) number.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, 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.

Repeat the configuration as needed for the other devices in the topology.

Verification

Confirm that the configuration is working properly.

Checking Device R2’s AS Paths

Purpose

Make sure that Device R2 does not have AS 64497 in its AS paths to Device R3 and Device R4.

Action

From operational mode, enter the show route protocol bgp command.

user@R2> show route protocol bgp

Meaning

Device R2’s AS paths do not include AS 64497.

Checking Device R3’s AS Paths

Purpose

Make sure that the local AS 64497 is prepended only in the AS path sent to the EBGP neighbor R3 . Device R3 sees an AS path of 64497 64496 for the prefix 10.1.1.2/32, which is Device R2's loopback interface.

Action

From operational mode, enter the show route protocol bgp command.

user@R3> show route protocol bgp

Meaning

Device R3’s route to Device R2 (prefix 10.1.1.2) includes both the local and the global AS configured on Device R1 (64497 and 64496, respectively).

Understanding the Accumulated IGP Attribute for BGP

The interior gateway protocols (IGPs) are designed to handle routing within a single domain or an autonomous system (AS). Each link is assigned a particular value called a metric. The distance between the two nodes is calculated as a sum of all the metric values of links along the path. The IGP selects the shortest path between two nodes based on distance.

BGP is designed to provide routing over a large number of independent ASs with limited or no coordination among respective administrations. BGP does not use metrics in the path selection decisions.

The accumulated IGP (AIGP) metric attribute for BGP enables deployment in which a single administration can run several contiguous BGP ASs. Such deployments allow BGP to make routing decisions based on the IGP metric. In such networks, it is possible for BGP to select paths based on metrics as is done by IGPs. In this case, BGP chooses the shortest path between two nodes, even though the nodes might be in two different ASs.

The AIGP attribute is particularly useful in networks that use tunneling to deliver a packet to its BGP next hop. The Juniper Networks® Junos® operating system (Junos OS) currently supports the AIGP attribute for two BGP address families, family inet labeled-unicast and family inet6 labeled-unicast.

AIGP impacts the BGP best-route decision process. The AIGP attribute preference rule is applied after the local-preference rule. The AIGP distance is compared to break a tie. The BGP best-route decision process also impacts the way the interior cost rule is applied if the resolving next hop has an AIGP attribute. Without AIGP enabled, the interior cost of a route is based on the calculation of the metric to the next hop for the route. With AIGP enabled, the resolving AIGP distance is added to the interior cost.

The AIGP attribute is an optional non-transitive BGP path attribute and is specified in Internet draft draft-ietf-idr-aigp-06, The Accumulated IGP Metric Attribute for BGP.

Example: Configuring the Accumulated IGP Attribute for BGP

This example shows how to configure the accumulated IGP (AIGP) metric attribute for BGP.

Requirements

This example uses the following hardware and software components:

  • Seven BGP-speaking devices.

  • Junos OS Release 12.1 or later.

Overview

The AIGP attribute enables deployments in which a single administration can run several contiguous BGP autonomous systems (ASs). Such deployments allow BGP to make routing decisions based on the IGP metric. With AIGP enabled, BGP can select paths based on IGP metrics. This enables BGP to choose the shortest path between two nodes, even though the nodes might be in different ASs. The AIGP attribute is particularly useful in networks that use tunneling to deliver a packet to its BGP next hop. This example shows AIGP configured with MPLS label-switched paths.

To enable AIGP, you include the aigp statement in the BGP configuration on a protocol family basis. Configuring AIGP on a particular family enables sending and receiving of the AIGP attribute on that family. By default, AIGP is disabled. An AIGP-disabled neighbor does not send an AIGP attribute and silently discards a received AIGP attribute.

Junos OS supports AIGP for family inet labeled-unicast and family inet6 labeled-unicast. The aigp statement can be configured for a given family at the global BGP, group, or neighbor level.

By default, the value of the AIGP attribute for a local prefix is zero. An AIGP-enabled neighbor can originate an AIGP attribute for a given prefix by export policy, using the aigp-originate policy action. The value of the AIGP attribute reflects the IGP distance to the prefix. Alternatively, you can specify a value, by using the aigp-originate distance distance policy action. The configurable range is 0 through 4,294,967,295. Only one node needs to originate an AIGP attribute. The AIGP attribute is retained and readvertised if the neighbors are AIGP enabled with the aigp statement in the BGP configuration.

The policy action to originate the AIGP attribute has the following requirements:

  • Neighbor must be AIGP enabled.

  • Policy must be applied as an export policy.

  • Prefix must have no current AIGP attribute.

  • Prefix must export with next-hop self.

  • Prefix must reside within the AIGP domain. Typically, a loopback IP address is the prefix to originate.

The policy is ignored if these requirements are not met.

Topology Diagram

Figure 4 shows the topology used in this example. OSPF is used as the interior gateway protocol (IGP). Internal BGP (IBGP) is configured between Device PE1 and Device PE4. External BGP (EBGP) is configured between Device PE7 and Device PE1, between Device PE4 and Device PE3, and between Device PE4 and Device PE2. Devices PE4, PE2, and PE3 are configured for multihop. Device PE4 selects a path based on the AIGP value and then readvertises the AIGP value based on the AIGP and policy configuration. Device PE1 readvertises the AIGP value to Device PE7, which is in another administrative domain. Every device has two loopback interface addresses: 10.9.9.x is used for BGP peering and the router ID, and 10.100.1.x is used for the BGP next hop.

The network between Device PE1 and PE3 has IBGP peering and multiple OSPF areas. The external link to Device PE7 is configured to show that the AIGP attribute is readvertised to a neighbor outside of the administrative domain, if that neighbor is AIGP enabled.

Figure 4: Advertisement of Multiple Paths in BGP
Advertisement of Multiple Paths in
BGP

For origination of an AIGP attribute, the BGP next hop is required to be itself. If the BGP next hop remains unchanged, the received AIGP attribute is readvertised, as is, to another AIGP neighbor. If the next hop changes, the received AIGP attribute is readvertised with an increased value to another AIGP neighbor. The increase in value reflects the IGP distance to the previous BGP next hop. To demonstrate, this example uses loopback interface addresses for Device PE4’s EBGP peering sessions with Device PE2 and Device PE3. Multihop is enabled on these sessions so that a recursive lookup is performed to determine the point-to-point interface. Because the next hop changes, the IGP distance is added to the AIGP distance.

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 P1

Device P2

Device PE4

Device PE1

Device PE2

Device PE3

Device PE7

Configuring Device P1

Step-by-Step Procedure

The following example requires you to 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 P1:

  1. Configure the interfaces.

  2. Configure MPLS and a signaling protocol, such as RSVP or LDP.

  3. Configure BGP.

  4. Enable AIGP.

  5. Configure an IGP, such as OSPF, RIP, or IS-IS.

  6. Configure the router ID and the autonomous system number.

  7. If you are done configuring the device, commit the configuration.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Configuring Device P2

Step-by-Step Procedure

The following example requires you to 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 P2:

  1. Configure the interfaces.

  2. Configure MPLS and a signaling protocol, such as RSVP or LDP.

  3. Configure BGP.

  4. Enable AIGP.

  5. Configure an IGP, such as OSPF, RIP, or IS-IS.

  6. Configure the router ID and the autonomous system number.

  7. If you are done configuring the device, commit the configuration.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Configuring Device PE4

Step-by-Step Procedure

The following example requires you to 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 PE4:

  1. Configure the interfaces.

  2. Configure MPLS and a signaling protocol, such as RSVP or LDP.

  3. Configure BGP.

  4. Enable AIGP.

  5. Originate a prefix, and configure an AIGP distance.

    By default, a prefix is originated using the current IGP distance. Optionally, you can configure a distance for the AIGP attribute, using the distance option, as shown here.

  6. Enable the policies.

  7. Configure a static route.

  8. Configure an IGP, such as OSPF, RIP, or IS-IS.

  9. Configure the router ID and the autonomous system number.

  10. If you are done configuring the device, commit the configuration.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Configuring Device PE1

Step-by-Step Procedure

The following example requires you to 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 PE1:

  1. Configure the interfaces.

  2. Configure MPLS and a signaling protocol, such as RSVP or LDP.

  3. Configure BGP.

  4. Enable AIGP.

  5. Enable the policies.

  6. Configure an IGP, such as OSPF, RIP, or IS-IS.

  7. Configure the router ID and the autonomous system number.

  8. If you are done configuring the device, commit the configuration.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Configuring Device PE2

Step-by-Step Procedure

The following example requires you to 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 PE2:

  1. Configure the interfaces.

  2. Configure MPLS and a signaling protocol, such as RSVP or LDP.

  3. Configure BGP.

  4. Enable AIGP.

  5. Originate a prefix, and configure an AIGP distance.

    By default, a prefix is originated using the current IGP distance. Optionally, you can configure a distance for the AIGP attribute, using the distance option, as shown here.

  6. Enable the policies.

  7. Enable some static routes.

  8. Configure an IGP, such as OSPF, RIP, or IS-IS.

  9. Configure the router ID and the autonomous system number.

  10. If you are done configuring the device, commit the configuration.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Configuring Device PE3

Step-by-Step Procedure

The following example requires you to 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 PE3:

  1. Configure the interfaces.

  2. Configure MPLS and a signaling protocol, such as RSVP or LDP.

  3. Configure BGP.

  4. Enable AIGP.

  5. Enable the policies.

  6. Configure an IGP, such as OSPF, RIP, or IS-IS.

  7. Configure the router ID and the autonomous system number.

  8. If you are done configuring the device, commit the configuration.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Configuring Device PE7

Step-by-Step Procedure

The following example requires you to 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 PE7:

  1. Configure the interfaces.

  2. Configure BGP.

  3. Enable AIGP.

  4. Configure the routing policy.
  5. Configure the router ID and the autonomous system number.

  6. If you are done configuring the device, commit the configuration.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Verification

Confirm that the configuration is working properly.

Verifying That Device PE4 Is Receiving the AIGP Attribute from Its EBGP Neighbor PE2

Purpose

Make sure that the AIGP policy on Device PE2 is working.

Action

user@PE4> show route receive-protocol bgp 10.9.9.5 extensive

Meaning

On Device PE2, the aigp-originate statement is configured with a distance of 20 (aigp-originate distance 20). This statement is applied to route 55.0.0.0/24. Likewise, the aigp-originate distance 30 statement is applied to route 99.0.0.0/24. Thus, when Device PE4 receives these routes, the AIGP attribute is attached with the configured metrics.

Checking the IGP Metric

Purpose

From Device PE4, check the IGP metric to the BGP next hop 10.100.1.5.

Action

user@PE4> show route 10.100.1.5

Meaning

The IGP metric for this route is 2.

Verifying That Device PE4 Adds the IGP Metric to the AIGP Attribute

Purpose

Make sure that Device PE4 adds the IGP metric to the AIGP attribute when it readvertises routes to its IBGP neighbor, Device PE1.

Action

user@PE4> show route advertising-protocol bgp 10.9.9.1 extensive

Meaning

The IGP metric is added to the AIGP metric (20 + 2 = 22 and 30 + 2 = 32), because the next hop is changed for these routes.

Verifying That Device PE7 Is Receiving the AIGP Attribute from Its EBGP Neighbor PE1

Purpose

Make sure that the AIGP policy on Device PE1 is working.

Action

user@PE7> show route receive-protocol bgp 10.0.0.9 extensive

Meaning

The 44.0.0.0/24 route is originated at Device PE4. The 55.0.0.0/24 and 99.0.0.0/24 routes are originated at Device PE2. The IGP distances are added to the configured AIGP distances.

Verifying the Resolving AIGP Metric

Purpose

Confirm that if the prefix is resolved through recursion and the recursive next hops have AIGP metrics, the prefix has the sum of the AIGP values that are on the recursive BGP next hops.

Action

  1. Add a static route to 66.0.0.0/24.

  2. Delete the existing terms in the aigp policy statement on Device PE2.

  3. Configure a recursive route lookup for the route to 66.0.0.0.

    The policy shows the AIGP metric for prefix 66.0.0.0/24 (none) and its recursive next hop. Prefix 66.0.0.0/24 is resolved by 55.0.0.1. Prefix 66.0.0.0/24 does not have its own AIGP metric being originated, but its recursive next hop, 55.0.0.1, has an AIGP value.

  4. On Device PE4, run the show route 55.0.0.0 extensive command.

    The value of Metric2 is the IGP metric to the BGP next hop. When Device PE4 readvertises these routes to its IBGP peer, Device PE1, the AIGP metric is the sum of AIGP + its Resolving AIGP metric + Metric2.

    Prefix 55.0.0.0 shows its own IGP metric 20, as defined and advertised by Device PE2. It does not show a resolving AIGP value because it does not have a recursive BGP next hop. The value of Metric2 is 2.

    user@PE4> show route 55.0.0.0 extensive
  5. On Device PE4, run the show route 66.0.0.0 extensive command.

    Prefix 66.0.0.0/24 shows the Resolving AIGP, which is the sum of its own AIGP metric and its recursive BGP next hop:

    66.0.0.1 = 0, 55.0.0.1 = 20, 0+20 = 20

    user@PE4> show route 66.0.0.0 extensive

Verifying the Presence of AIGP Attributes in BGP Updates

Purpose

If the AIGP attribute is not enabled under BGP (or the group or neighbor hierarchies), the AIGP attribute is silently discarded. Enable traceoptions and include the packets flag in the detail option in the configuration to confirm the presence of the AIGP attribute in transmitted or received BGP updates. This is useful when debugging AIGP issues.

Action

  1. Configure Device PE2 and Device PE4 for traceoptions.

  2. Check the traceoptions file on Device PE2.

    The following sample shows Device PE2 advertising prefix 99.0.0.0/24 to Device PE4 (10.9.9.4) with an AIGP metric of 20:

    user@PE2> show log bgp
  3. Verify that the route was received on Device PE4 using the show route receive-protocol command.

    AIGP is not enabled on Device PE4, so the AIGP attribute is silently discarded for prefix 99.0.0.0/24 and does not appear in the following output:

    user@PE4> show route receive-protocol bgp 10.9.9.5 extensive | find 55.0.0.0
  4. Check the traceoptions file on Device PE4.

    The following output from the traceoptions log shows that the 99.0.0.0/24 prefix was received with the AIGP attribute attached:

    user@PE4> show log bgp

Meaning

Performing this verification helps with AIGP troubleshooting and debugging issues. It enables you to verify which devices in your network send and receive AIGP attributes.

Understanding AS Override

The AS override feature allows a provider edge (PE) router to change the private autonomous system (AS) number used by a customer edge (CE) device on an external BGP (EBGP) session running on a VPN routing and forwarding (VRF) access link. The private AS number is changed to the PE AS number. Another CE device connected to another PE device sees the EBGP route coming from the first site with an AS path of provider-ASN provider-ASN, instead of provider-ASN site1-ASN. This allows enterprise networks to use the same private ASN on all sites.

The AS override feature offers a clear management advantage to the service provider because BGP by default does not accept BGP routes with an AS path attribute that contains the local AS number.

In an enterprise network with multiple sites, you might wish to use a single AS number across sites. Suppose, for example that two CE devices are in AS 64512 and that the provider network is in AS 65534.

When the service provider configures a Layer 3 VPN with this setup, even if the MPLS network has routes towards Device CE1 and Device CE2, Device CE1 and Device CE2 do not have routes to each other because the AS path attribute would appear as 64512 65534 64512. BGP uses the AS path attribute as its loop avoidance mechanism. If a site sees its own AS number more than once in the AS path, the route is considered invalid.

One way to overcome this difficulty is with the as-override statement, which is applied to the PE devices. The as-override statement replaces the CE device's AS number with that of the PE device, thus preventing the customer AS number from appearing more than once in the AS path attribute.

If a customer uses AS path prepending to make certain paths less desirable and the service provider uses AS override, each CE AS number occurrence in the AS-path is changed to the service provider AS number. For example, suppose that all customer sites use the same AS number, say 64512. If the ISP uses AS number 65534, one customer site sees the path to another site as 65534 65534. If the customer prepends 64512 on a particular path to make it less desirable, another customer site sees that path as 65534 65534 65534.

Example: Configuring a Layer 3 VPN with Route Reflection and AS Override

Suppose that you are a service provider providing a managed MPLS-based Layer 3 VPN service. Your customer has several sites and requires BGP routing to customer edge (CE) devices at each site.

Requirements

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

Overview

This example has two CE devices, two provider edge (PE) devices, and several provider core devices. The provider network is also using IS-IS to support LDP and BGP loopback reachability Device P2 is acting as a route reflector (RR). Both CE devices are in autonomous system (AS) 64512. The provider network is in AS 65534.

The as-override statement is applied to the PE devices, thus replacing the CE device's AS number with that of the PE device. This prevents the customer AS number from appearing more than once in the AS path attribute.

Figure 5 shows the topology used in this example.

Figure 5: AS Override Topology
AS Override Topology

CLI Quick Configuration shows the configuration for all of the devices in Figure 5. The section Step-by-Step Procedure describes the steps on Device PE1.

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 CE1

Device P1

Device P2

Device P3

Device PE1

Device PE2

Device CE2

Step-by-Step Procedure

The following example requires you to 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 AS override:

  1. Configure the interfaces.

    To enable MPLS, include the protocol family on the interface so that the interface does not discard incoming MPLS traffic.

  2. Add the interface to the MPLS protocol to establish the control plane level connectivity.

    Set up the IGP so that the provider devices can communicate with each other.

    To establish a mechanism to distribute MPLS labels, enable LDP. Optionally, for LDP, enable forwarding equivalence class (FEC) deaggregation, which results in faster global convergence.

  3. Enable the internal BGP (IBGP) connection to peer with the RR only, using the IPv4 VPN unicast address family.
  4. Configure the routing instance, including the as-override statement.

    Create the routing-Instance (VRF) on the PE device, setting up the BGP configuration to peer with Device CE1.

  5. Configure the router ID and the AS number.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, show routing-instances, and show routing-options commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

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

Verification

Confirm that the configuration is working properly.

Checking AS Path to the CE Devices

Purpose

Display information on Device PE1 about the AS path attribute for the route to Device CE2’s loopback interface.

Action

On Device PE1, from operational mode, enter the show route table VPN-A.inet.0 10.255.6.6 command.

user@PE1> show route table VPN-A.inet.0 10.255.6.6

Meaning

The output shows that Device PE1 has an AS path for 10.255.6.6/32 as coming from AS 64512.

Checking How the Route to Device CE2 Is Advertised

Purpose

Make sure the route to Device CE2 is advertised to Device CE1 as if it is coming from the MPLS core.

Action

On Device PE1, from operational mode, enter the show route advertising-protocol bgp 10.0.0.1 command.

user@PE1> show route advertising-protocol bgp 10.0.0.1

Meaning

The output indicates that Device PE1 is advertising only its own AS number in the AS path.

Checking the Route on Device CE1

Purpose

Make sure that Device CE1 contains only the provider AS number in the AS path for the route to Device CE2.

Action

From operational mode, enter the show route table inet.0 terse 10.255.6.6 command.

user@CE1> show route table inet.0 terse 10.255.6.6

Meaning

The output indicates that Device CE1 has a route to Device CE2. The loop issue is resolved with the use of the as-override statement.

One route is hidden on the CE device. This is because Junos OS does not perform a BGP split horizon. Generally, split horizon in BGP is unnecessary, because any routes that might be received back by the originator are less preferred due to AS path length (for EBGP), AS path loop detection (IBGP), or other BGP metrics. Advertising routes back to the neighbor from which they were learned has a negligible effect on the router's performance, and is the correct thing to do.

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

Disabling Attribute Set Messages on Independent AS Domains for BGP Loop Detection

BGP loop detection for a specific route uses the local autonomous system (AS) domain for the routing instance. By default, all routing instances belong to a single primary routing instance domain. Therefore, BGP loop detection uses the local ASs configured on all of the routing instances. Depending on your network configuration, this default behavior can cause routes to be looped and hidden.

To limit the local ASs in the primary routing instance, you can configure an independent AS domain for a routing instance. The independent domain is separate from the primary routing instance and keeps the AS paths of the independent domain from being shared with the AS path and the AS path attributes of other domains.

By default, independent domains use transitive path attribute 128 (attribute set) messages to tunnel the independent domain’s BGP attributes through the internal BGP (IBGP) core. However, the attribute set message behavior for independent domains is undesired in many cases. If you only want to configure independent domains to maintain the independence of local ASs in the routing instance, and perform BGP loop detection only for the specified local ASs in the routing instance, you can disable the attribute set messages.

To disable attribute set messages on an independent domain, include the independent-domain no-attrset statement:

  1. Select the routing instance that contains the independent domain you want to modify. You can select the routing instance from the following hierarchy levels:
    • [edit routing-instances routing-instance-name]

    • [edit logical-systems logical-system-name routing-instances routing-instance-name]

  2. Disable attribute set messages on the independent domain.
    Tip

    When you disable attribute set messages, we recommend that you specify the AS number of the primary routing instance. This ensures that the primary routing instance AS is treated as a local AS in the routing instance and is used for BGP loop detection.

After you specify a routing instance for an independent domain, the local ASs are only associated with that routing instance. That means BGP loop detection uses only the local ASs defined in the routing instance.

Example: Ignoring the AS Path Attribute When Selecting the Best Path

If multiple BGP routes to the same destination exist, BGP selects the best path based on the route attributes of the paths. One of the route attributes that affects the best-path decision is the length of the AS paths of each route. Routes with shorter AS paths are preferred over those with longer AS paths. Although not typically practical, some scenarios might require that the AS path length be ignored in the route selection process. This example shows how to configure a routing device to ignore the AS path attribute.

Requirements

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

Overview

On externally connected routing devices, the purpose of skipping the AS path comparison might be to force an external BGP (EBGP) versus internal BGP (IBGP) decision to remove traffic from your network as soon as possible. On internally connected routing devices, you might want your IBGP-only routers to default to the local externally connected gateway. The local IBGP-only (internal) routers skip the AS path comparison and move down the decision tree to use the closest interior gateway protocol (IGP) gateway (lowest IGP metric). Doing this might be an effective way to force these routers to use a LAN connection instead of their WAN connection.

Caution

When you include the as-path-ignore statement on a routing device in your network, you might need to include it on all other BGP-enabled devices in your network to prevent routing loops and convergence issues. This is especially true for IBGP path comparisons.

In this example, Device R2 is learning about the loopback interface address on Device R4 (4.4.4.4/32) from Device R1 and Device R3. Device R1 is advertising 4.4.4.4/32 with an AS-path of 1 5 4, and Device R3 is advertising 4.4.4.4/32 with an AS-path of 3 4. Device R2 selects the path for 4.4.4.4/32 from Device R3 as the best path because the AS path is shorter than the AS path from Device R1.

This example modifies the BGP configuration on Device R2 so that the AS-path length is not used in the best-path selection.

Device R1 has a lower router ID (1.1.1.1) than Device R3 (1.1.1.1). If all other path selection criteria are equal (or, as in this case, ignored), the route learned from Device R1 is used. Because the AS-path attribute is being ignored, the best path is toward Device R1 because of its lower router ID value.

Figure 7 shows the sample topology.

Figure 7: Topology for Ignoring the AS-Path Lengh
Topology for Ignoring the AS-Path
Lengh

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

Device R4

Device R5

Configuring Device R2

Step-by-Step Procedure

The following example requires you to 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 R2:

  1. Configure the interfaces.
  2. Configure EBGP.
  3. Configure the autonomous system (AS) path attribute to be ignored in the Junos OS path selection algorithm.
  4. Configure the routing policy.
  5. Configure some static routes.
  6. Configure the autonomous system (AS) number and the router ID.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, 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. Repeat the configuration on the other devices in the network, changing the interface names and IP addresses, as needed.

Verification

Confirm that the configuration is working properly.

Checking the Neighbor Status

Purpose

Make sure that from Device R2, the active path to get to AS 4 is through AS 1 and AS 5, not through AS 3.

Note

To verify the functionality of the as-path-ignore statement, you might need to run the restart routing command to force reevaluation of the active path. This is because for BGP, if both paths are external, the Junos OS behavior is to prefer the currently active path. This behavior helps to minimize route-flapping. Use caution when restarting the routing protocol process in a production network.

Action

From operational mode, enter the restart routing command.

user@R2> restart routing

From operational mode, enter the show route 4.4.4.4 protocol bgp command.

user@R2> show route 4.4.4.4 protocol bgp

Meaning

The asterisk (*) is next to the path learned from R1, meaning that this is the active path. The AS path for the active path is 1 5 4, which is longer than the AS path (3 4) for the nonactive path learned from Router R3.

Understanding Private AS Number Removal from AS Paths

By default, when BGP advertises AS paths to remote systems, it includes all AS numbers, including private AS numbers. You can configure the software so that it removes private AS numbers from AS paths. Doing this is useful when any of the following circumstances are true:

  • A remote AS for which you provide connectivity is multihomed, but only to the local AS.

  • The remote AS does not have an officially allocated AS number.

  • It is not appropriate to make the remote AS a confederation member AS of the local AS.

Most companies acquire their own AS number. Some companies also use private AS numbers to connect to their public AS network. These companies might use a different private AS number for each region in which their company does business. In any implementation, announcing a private AS number to the Internet must be avoided. Service providers can use the remove-private statement to prevent advertising private AS numbers to the Internet.

In an enterprise scenario, suppose that you have multiple AS numbers in your company, some of which are private AS numbers, and one with a public AS number. The one with a public AS number has a direct connection to the service provider. In the AS that connects directly to the service provider, you can use the remove-private statement to filter out any private AS numbers in the advertisements that are sent to the service provider.

The AS numbers are stripped from the AS path starting at the left end of the AS path (the end where AS paths have been most recently added). The routing device stops searching for private ASs when it finds the first nonprivate AS or a peer’s private AS. If the AS path contains the AS number of the external BGP (EBGP) neighbor, BGP does not remove the private AS number.

Note

As of Junos OS 10.0R2 and later, if there is a need to send prefixes to an EBGP peer that has an AS number that matches an AS number in the AS path, consider using the as-override statement instead of the remove-private statement.

The operation takes place after any confederation member ASs have already been removed from the AS path, if applicable.

The software is preconfigured with knowledge of the set of AS numbers that is considered private, a range that is defined in the Internet Assigned Numbers Authority (IANA) assigned numbers document. The set of 16 bit AS numbers reserved as private are in the range from 64,512 through 65,534, inclusive. The 32 bit AS numbers reserved as private are in the range from 4,200,000,000 through 4,294,967,294 inclusive.

Example: Removing Private AS Numbers from AS Paths

This example demonstrates the removal of a private AS number from the advertised AS path to avoid announcing the private AS number to the Internet.

Requirements

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

Overview

Service providers and enterprise networks use the remove-private statement to prevent advertising private AS numbers to the Internet. The remove-private statement works in the outbound direction. You configure the remove-private statement on a device that has a public AS number and that is connected to one or more devices that have private AS numbers. Generally, you would not configure this statement on a device that has a private AS number.

Figure 8 shows the sample topology.

Figure 8: Topology for Removing a Private AS from the Advertised AS Path
Topology for Removing a
Private AS from the Advertised AS Path

In this example, Device R1 is connected to its service provider using private AS number 65530. The example shows the remove-private statement configured on Device ISP to prevent Device R1’s private AS number from being announced to Device R2. Device R2 sees only the AS number of the service provider.

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 ISP

Device R2

Device ISP

Step-by-Step Procedure

The following example requires you to 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 ISP:

  1. Configure the interfaces.
  2. Configure EBGP.
  3. For the neighbor in autonomous system (AS) 200 (Device R2), remove private AS numbers from the advertised AS paths.
  4. Configure the AS number.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, 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. Repeat the configuration on Device R1 and Device R2, changing the interface names and IP address, as needed, and adding the routing policy configuration.

Verification

Confirm that the configuration is working properly.

Checking the Neighbor Status

Purpose

Make sure that Device ISP has the remove-private setting enabled in its neighbor session with Device R2.

Action

From operational mode, enter the show bgp neighbor 192.168.20.1 command.

user@ISP> show bgp neighbor 192.168.20.1

Meaning

The RemovePrivateAS option shows that Device ISP has the expected setting.

Checking the Routing Tables

Purpose

Make sure that the devices have the expected routes and AS paths.

Action

From operational mode, enter the show route protocol bgp command.

user@R1> show route protocol bgp
user@ISP> show route protocol bgp
user@R2> show route protocol bgp

Meaning

Device ISP has the private AS number 65530 in its AS path to Device R1. However, Device ISP does not advertise this private AS number to Device R2. This is shown in the routing table of Device R2. Device R2’s path to Device R1 contains only the AS number for Device ISP.

Checking the AS Path When the remove-private Statement Is Deactivated

Purpose

Verify that without the remove-private statement, the private AS number appears in Device R2’s routing table.

Action

From configuration mode on Device ISP, enter the deactivate remove-private command and then recheck the routing table on Device R2.

user@R2> show route protocol bgp

Meaning

Private AS number 65530 appears in Device R2’s AS path to Device R1.