The BGP local-as / no-prepend/replace-as feature is a “Not Supported Feature”, a non-starter. As an alternative, cisco recommends the customer use a CE solution called Optimized Edge Routing (OER).

The following comments regarding AS# changes are based upon Cisco’s recommendation:

The BGP local-as/no-prepend/replace-as feature is a knob in Cisco IOS added to assist customers in migrating from one AS to another AS, and should only be implemented as a short term workaround while networks are migrated. BGP prepends the autonomous system number from each BGP network that a route traverses. This behavior is designed to maintain network reach ability information and to prevent routing loops from occurring. Configuring this feature incorrectly could create routing loops. This is not intended to be used long term and can introduce operational support issues within ISP ’s network.

This feature, by it’s very nature, breaks the routing loop protection automatically provided by BGP since ISP is not adding their AS to the AS-PATH and the customer is also peering with another provider. These loops could lead to extended outages to the customer due to the fact that the problem would be sporadic and difficult to troubleshoot.

An example scenario is described below.
- ISP advertises 10.1.1.0/24 (Customer site B) to Customer site A overwriting our AS of 999 with AS 65111.
- Customer site A readvertises 10.1.1.0/24 (Customer site B) back to ISP , which would be accepted as ISP is not AS 65111 and ISP ’s AS 999 in not listed in the AS path.
- ISP ’s PE connected to Customer site A will advertise the update of 10.1.1.0/24 to the route reflector’s (RR).
- ISP ’s RR’s will use IGP metrics to pick best path and forward on to ISP PE’s, which would result in other Customer sites (C, D, etc) homed to those
PE’s receiving the wrong path creating routing loops.
- This starts the churning of the BGP route for 10.1.1.0/24 within the GMPLS network, including RR’s and advertisements to ISP PE’s and other customer
sites off of those PE’s. Once the churn begins, ISP will have no way of knowing for sure where the advertisement should be coming from and the delay in
troubleshooting this could be extended dramatically.

Please note the example above only uses one route. Potentially, this could occur with numerous routes from numerous customer locations. This would also
lead to an increase in memory utilization and processor utilization on the PE routers as noted in the past with similar EIGRP-related routing loop issues.

In later IOS versions you can actually see via a debug what the expected as is, eg

bad OPEN, remote AS is 400, expected 10

Another interesting topic I ran into under BGP lately is the use of template to create ibgp peering instead of using peer group.

It’s kinda interesting