BGP—Support for iBGP Local-AS

Prior to the BGP—Support for iBGP Local-AS feature, the neighbor local-as command was used on a route reflector to
customize AS_PATH attributes for routes received from an eBGP
neighbor. The neighbor local-as command can now be used to enable the sending of the iBGP attributes (LOCAL_PREF, ORIGINATOR_ID, CLUSTER_ID, and CLUSTER_LIST) over an iBGP local-AS session. This functionality is useful when merging two autonomous systems, when it is advantageous to keep the iBGP attributes in routes.

Prior to the BGP—Support for iBGP Local-AS feature, the RR should not have been configured to change iBGP attributes. With the introduction of this feature, the RR can be configured to change iBGP attributes, providing more flexibility.

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see
Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to
www.cisco.com/​go/​cfn. An account on Cisco.com is not required.

Restrictions for Support for iBGP Local-AS

This feature is not supported for a peer that belongs to a confederation.

iBGP neighbors that are in a single AS are put into a separate update group from iBGP neighbors that are configured with the iBGP Local-AS feature.

Two iBGP neighbors that are in two different autonomous systems and that are configured with the same iBGP Local-AS number are put into separate update groups.

Information About Support for iBGP Local-AS

Support for iBGP Local-AS

Prior to the Support for iBGP Local-AS feature, the neighbor local-as command was used to
customize AS_PATH attributes for routes received from an eBGP
neighbor. When a peer (or peer group) was configured with the neighbor local-as command and the neighbor remote-as command that specified the
same AS number, that peer acted as an iBGP local-AS client, causing the
local-AS number to be prepended to routes from that neighbor. However, the connection with the neighbor was not an iBGP connection, which meant
that some attributes were not preserved in outgoing updates.
Updates were propagated as if the peer were an eBGP peer, and
therefore the LOCAL_PREF, ORIGINATOR_ID, CLUSTER_ID, and CLUSTER_LIST attributes were not added to the route during re-advertisement
because those attributes apply to iBGP.

There
can be scenarios where the network administrator wants those
attributes to be passed unmodified, typically to facilitate the merging of two
autonomous systems. The Support for iBGP Local-AS feature causes BGP to treat an iBGP local-AS connection as an iBGP connection and pass those four attributes unmodified.

In such a scenario, an RR is in one AS; the routers in the other AS become RR clients and keep their existing AS number. The RR is configured with the neighbor remote-as
command and the neighbor local-as command that specify that neighbor (client) or peer group and its AS
number. The session with that neighbor is treated as iBGP when
the RR advertises routes received in the session to iBGP peers that have
no neighbor local-as command configured. The RR transparently passes BGP updates to and from the client routers in the other AS, passing the LOCAL_PREF, ORIGINATOR_ID, CLUSTER_ID, and CLUSTER_LIST attributes unmodified
instead of dropping them.

The figure below illustrates a scenario where this feature is being used to facilitate the merging of two autonomous systems. The route reflector (R3) and R4 belong to AS 1000; R1 and R6 belong to AS 3000. The RR is configured with the neighbor local-as command and the neighbor remote-as command, both specifying AS 3000. Even though the routers belong to two different autonomous systems, the local preference value is preserved in the updates from the client (R6) to the RR, and out to the other clients.

Figure 1. Support for iBGP Local-AS to Preserve iBGP Policies Between Two Autonomous Systems

Prior to the Support for iBGP Local-AS feature, the RR should not have been configured to change iBGP attributes. With the introduction of this feature, the RR can be configured to change iBGP attributes. This flexibility is achieved by configuring the neighbor allow-policy command on the RR, and configuring an outbound route map to send attributes downstream to peers.

Benefits of iBGP Local-AS

One use case for this feature is when merging two ISPs that have different autonomous system numbers. It is desirable to preserve attributes that are considered internal (LOCAL_PREF, ORIGINATOR_ID, CLUSTER_ID, and CLUSTER_LIST) in the routes that are being passed to a different autonomous system. Configuring this feature causes these iBGP attributes in the advertised
routes to be passed on to the second AS rather than dropped.

Prior to the BGP—Support for iBGP Local-AS feature, the RR should not have been configured to change iBGP attributes. With the introduction of this feature, the RR can be configured to change iBGP attributes. This flexibility is achieved by configuring the neighbor allow-policy command on the RR, and configuring an outbound route map to send iBGP attributes downstream to peers.

How to Configure iBGP Local-AS

Configuring iBGP Local-AS

Configure the iBGP Local-AS feature on a route reflector when you want iBGP attributes to be preserved in updates to a neighbor or peer group in another AS. Optionally, you can enable the route reflector to change iBGP attributes sent to a neighbor.

Note

This task includes the optional neighbor allow-policy command that enables you to configure the route reflector to change iBGP attributes, but it does not include the route map that actually changes iBGP attributes.

The output includes the phrase “allow-policy” if the neighbor allow-policy command was configured for that neighbor.

Step 17

show ip bgp vpnv4 all update-groupupdate-group

Example:

Device# show ip bgp vpnv4 all update-group 2

(Optional) Displays the information for the update group.

The output includes the phrase “Allow-policy” if the neighbor allow-policy command was configured for neighbors in the update group.

Step 18

show ip bgp vpnv4 all neighbors
{ip-address
| ipv6-address}

Example:

Device# show ip bgp vpnv4 all neighbors 192.168.3.3

(Optional) Displays information about the neighbor.

The output includes the remote AS and local AS, which will indicate the same AS number when the Support for iBGP Local-AS feature is configured.

Configuration Examples for iBGP Local-AS

Example: Configuring iBGP Local-AS

The example configures a route reflector (RR) in AS 4000 to treat BGP sessions with the peer group rr-client-2 in AS 2500 as iBGP sessions.
That is, iBGP attributes (LOCAL_PREF, ORIGINATOR_ID, CLUSTER_ID, and CLUSTER_LIST) will not be dropped from routes in advertisements to and from the peer group; the attributes will be passed unmodified. AS 2500 will be prepended to the AS_PATH attribute in routes to and from the peer group.

Additionally, the neighbor allow-policy command configures that the network administrator can configure iBGP policies on the RR. That is, an outbound route map can be configured to change attributes that are sent to the downstream peers. In this example, the feature is applied to VPNv4 and VPNv6 address families.

Additional References for Support for iBGP Local-AS

Related Documents

“BGP Support for Dual AS Configuration for Network AS Migrations” module
in the IP Routing: BGP Configuration Guide, Cisco IOS XE Release 3S

Technical Assistance

Description

Link

The Cisco Support website provides extensive online resources,
including documentation and tools for troubleshooting and
resolving technical issues with Cisco products and technologies.

To receive security and technical information about your
products, you can subscribe to various services, such as the
Product Alert Tool (accessed from Field Notices), the Cisco
Technical Services Newsletter, and Really Simple Syndication
(RSS) Feeds.

Access to most tools on the Cisco Support website requires a
Cisco.com user ID and password.

Feature Information for BGP—Support for iBGP Local-AS

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to
www.cisco.com/​go/​cfn. An account on Cisco.com is not required.

Table 1 Feature Information for BGP—Support for iBGP Local-AS

Feature Name

Releases

Feature Information

BGP—Support for iBGP Local-AS

15.3(2)S

15.3(3)M

Prior to the BGP—Support for Local-AS feature, the neighbor local-as command was used on a route reflector to
customize AS_PATH attributes for routes received from an eBGP
neighbor. The neighbor local-as command can now be used to enable the sending of the iBGP attributes (LOCAL_PREF, ORIGINATOR_ID, CLUSTER_ID, and CLUSTER_LIST) over an iBGP local-AS session. This functionality is useful when merging two autonomous systems, when it is advantageous to keep the iBGP attributes in routes.

Prior to the BGP—Support for iBGP Local-AS feature, the RR should not have been configured to change iBGP attributes. With the introduction of this feature, the RR can be configured to change iBGP attributes, providing more flexibility.