BGP Allowas-in feature needs to be understood well in order to understand the BGP loop prevention behavior, But also, why the BGP Allowas-in configuration might create a dangerous situation, and what are the alternatives of BGP Allowas-in will be explained in this post.
What is the BGP Allowas-in feature?
BGP Allow-as-in feature is used to allow the BGP speaker to accept the BGP updates even if its own BGP AS number is in the AS-Path attribute.
By default EBGP loop prevention is, if any BGP speaker sees its own AS Number in the BGP update, then the update is rejected, thus the advertisement cannot be accepted. But there might be situations to accept the prefixes, thus there are two options to overcome this behavior.
Either accepting the BGP update even if the AS number is in the AS-Path list, with the BGP Allow AS feature or changing the behavior with the BGP AS Override feature. Without BGP Allowas, let's see what would happen.
In this topology, Customer BGP AS is AS 100. The customer has two locations. Service Provider, in the middle, let's say providing MPLS VPN service for the customer. As you can understand from the topology, Service Provider is running EBGP with the Customer, because they have different BGP Autonomous Systems. The service provider in the above topology has BGP AS 200.
Left customer router, when it advertises BGP update message to the R2, R2 sends to R3 and when R3 sends to R4, R4 wouldn't accept the BGP update, When R4 receives that update, it will check the AS-Path attribute and would see its own BGP AS number in the AS Path.
Thus is by default rejected, due to EBGP loop prevention.If the router sees its own BGP AS number, anywhere (Origin AS, any mid-AS, or last AS) in the AS Path, it doesn't accept the BGP update. But what if, like in the above picture, the customer wants to, or needs to use the same BGP AS number in every location that they have. In this case, they need to accept the BGP update, otherwise, end-to-end reachability cannot be achieved.
There are two solutions to the above requirement. By the way, not accepting prefixes/BGP updates is not a problem. It is just how BGP works. One of the solutions is, that R2 receives a BGP update from R1 with AS 100, then R3 receives from R2, and in the BGP AS Path, it is still AS 100 at R3. With BGP AS Override feature, R3 can change customers' BGP AS numbers with its own BGP AS number. So, R3 during advertisement to R4 replaces BGP AS 100 with BGP AS 200.
Change the AS number with its own AS number.And finally, when R4 receives it since it won't see its own AS number in the BGP update, R4 accepted the announcements, and end-to-end connectivity is achieved.With the BGP Allowas-in feature, R3 when it advertises the BGP update to R4, it doesn't change the BGP AS 100 and sends to R4, BGP AS 100 as Origin AS. The BGP configuration at R4 will allow the prefixes although the AS number in the BGP AS Path list shows as Origin AS as AS 100 which is the R4's own AS number as well.