MPLS - Using the BGP Allow-AS in feature
When deploying an MPLS layer 3 VPN topology, and when using BGP as the routing protocol between the CE and PE, there are situations where the Allow-AS In BGP feature must be used. This is particularly the case when the ASN used at both remote customer sites is the same.
Take a look at the following topology:
Note that both CE1 and CE2 are in ASes with the same ASN. eBGP loop prevention mechanisms will not allow prefixes to be exchanged between CE1 and CE2 because of the fact that the same AS number appears in the AS Path.
One way to resolve this is to use a different ASN. However, there are situations in which it is preferrable to keep the same ASN and use the Allow-AS In feature. These reasons include:
- The use of public ASes - If these are public ASNs, then the choice of ASN is constrained, which may require you to use the same ASN at multiple remote sites.
- 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 necessitating the use of Allow-AS-In.