Hello David
Just a clarification. The problem described is that two sites of the same customer are using the same BGP AS number, not two separate customers. This is probably what you meant, I’m just clarifying for the record.
You are correct that a “solution” to the problem is simply to use different ASes, and this can be easily done especially if you are using private ASes. However, there are reasons to keep the ASes the same, and for some organizations, it may be worth it, and if so, the Allow-AS-In feature is necessary. Under what circumstances would you want to keep the same AS? Well, here are a few:
- Routing policies - some organizations may have applied routing policies based on AS numbers. Changing the AS number could mean reworking these polices which may be more time-consuming and expensive than using the Allow-AS-in feature.
- BGP features dependent on AS number - there may be BGP features or design principles that are dependent on AS number such as BGP confederations and AS_PATH prepending and filtering.
- Simplicity - some customers may just want to keep the same AS throughout their remote networks for operational simplicity. This way they don’t have to get involved in eBGP routing and related configurations, especially if they may have tens or hundreds of remote sites.
- Network design - A customer may also be constrained in the choice of their ASN due to the nature of the rest of their network, network infrastructure that exists beyond the MPLS interconnections of their remote sites.
So although the use of different ASes at each remote site is a solution to the problem presented, there are reasons to maintain the same AS at remote sites (even with private ASNs) necessitating the use of Allow-AS-In.
I hope this has been helpful!
Laz