BGP Local Autonomous System

CUSTOMER use XYZ ISP. Assume that if in a case XYZ goes down or overtake by other ISP like ABC above example is set for the understanding of LOCAL AS feature. You see here CUSTOMER has 300 AS and XYZ has 200 AS. On the case of overtaking XYZ via ABC then we cannot able to configuration on a customer router. To come out with this problem we use the LOCAL AS feature. No-PREPEND feature to use for that only customer AS will go to in ABC router. REPLACE AS use to avoiding the local AS and customer AS.

If you are studying so first try a little topology to understand those topics.

LOCAL Autonomous System:

Review of BGP neighborship: 23.0.0.3 remote autonomous system is 300 and also the local autonomous system is 200 and also we are using next hope self-command on XYZ router for traffic pass (from R2 to R3). Same configuration for ABC router. Now R2 sends both autonomous systems to the customer for all prefixes.

BGP Configuration on ABC router: BGP configuration with R2 router as basic BGP config. Use remote Autonomous system 100 and Pass a network 1.1.1.1 for testing. Same as on R2 router for R3 router.

BGP configuration on customer Router: BGP configuration with R3 router as basic BGP config. Use remote Autonomous system 200 and Pass a network 3.3.3.3  for testing.

BGP configuration on XYZ ISP router: BGP configuration with R2 router as basic BGP config. Use remote Autonomous system 300 and Pass a network 1.1.1.1 for testing. But on R2 own autonomous now use 100 due to migration with R1 and after that what will happen and what need to do for implement we are showing you that all below.

Autonomous system number miss-match error coming because now ABC ISP takes over the XYZ ISP. Now XYZ ISP work on 100 autonomous systems and R3 customer router show miss match errors of Autonomous system. The above screenshot clears the configuration of how it happens. For comes out of these problems we are using LOCAL AS features on XYZ ISP.

LOCAL AS command configuration on XYZ R2 router:

Neighbour ship with R3 has been established:

LOCAL AS has been properly worked now. After the take over the XYZ ISP by ABC ISP we cannot suffer the customer and not able to configure the customer end router easily or in a little time. You can see the above picture that neighbor 23.0.0.3 think that 200 autonomous connected with then as per customer end configuration but here right now XYZ changed with ABC ISP and ABC have own Autonomous system 100. But ABC wants his customer to work in the per same condition without suffering. For this, we are using LOCAL AS function on providing an edge router.

One more thing if we want to totally ignore the XYZ autonomous system then we are using no prepend feature

No-Prepend Autonomous System:

R2# neighbour 23.0.0.3 local-as 200 no-prepend

Via this command used to exit own autonomous to send another. R2 sends the only customer R3 autonomous system to the R1 router.

R2# neighbour 23.0.0.3 local-as 200 no-prepend replace-as

This command used to send real autonomous systems locally. (LOCAL Autonomous system and customer autonomous system avoid)

Note:- NO-PREPEND work on incoming EBGP neighbor & REPLACE AUTONOMOUS SYSTEM work, ongoing EBGP neighbor.

=============after all of this we can ask to customer change your configuration=============

Dual Autonomous System:

Dual AS: R2# neighbor 23.0.0.3 local-as 200 no-prepend replace-as dual-as

Accept either real autonomous or from the EBGP peer. Now if R3 customer changes our Autonomous system with 100 autonomous system neighbor will be up due to dual autonomous system already on the R2 router.

All this the way of migration of an ISP with another ISP. An ISP has many customers on own autonomous system, so on the migration time of an ISP it is not possible to change the customer end configuration. All the above commands are used on edge provider router like R2.

signal

Leave a Reply

Your email address will not be published. Required fields are marked *

Comments (1)