By default, a BGP speaker will reject any updates if it sees its own ASN in the AS_path attribute. This is to prevent any routing loops. However, some scenarios require the router to accept the prefixes with the same ASN.
For example, there could be an MPLS cloud from a service provider that connects multiple customer sites, and some of these sites might have the same ASN. As shown in the below diagram, Router A and Router D have the same ASN of 100 and they connect to the MPLS network peering with the service provider router at respective sites.
By default, the routes are denied on Router A advertised from Router D and vice versa.
“allowas-in” is a BGP configuration option that allows a BGP router to accept routes from its peers even if the routes contain its own AS number in the AS_PATH attribute. This can be useful in certain scenarios, such as in a confederation or when dealing with route reflectors.
Here’s a simple example of the configuration:
Router A
router bgp 100
neighbor 10.10.1.1 remote-as 200
neighbor 10.10.1.1 allowas-in
Router D
router bgp 100
neighbor 10.40.1.1 remote-as 300
neighbor 10.40.1.1 allowas-in
This configuration allows the BGP Router A in AS 100 to accept routes from its neighbor in AS 200 even if the routes contain AS 100 in the AS_PATH attribute for the routes advertised from Router D .
Remember that the usage of “allowas-in” should be carefully considered, as it can potentially lead to routing loops if not used appropriately in the specific network design.
Alternatively, AS override option can also be used to overcome such a scenario. But this has to be applied on the service provider router as it would replace the customer AS number with its own ASN when advertising back to the CE router.
Leave a Reply