This is actually expected behavior. The PE routers don’t need to be able to reach the loopback of the CE routers. They don’t need that information in their routing tables because you will never have direct communication between a PE router and the customer network. However, PE routers must be able to direct transient traffic (traffic that doesn’t originate from themselves) to the intended destination, and this is achieved using the BGP VPN table, which we can see with the command show ip bgp vpnv4 all like so:
PE1#show ip bgp vpnv4 all
BGP table version is 4, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf CUSTOMER)
*> 1.1.1.1/32 192.168.12.1 0 0 12 i
*>i 5.5.5.5/32 4.4.4.4 0 100 0 12 i
PE1#
Here, you can see that PE1 has a next hop assigned for both the 1.1.1.1 and the 5.5.5.5 networks, which route traffic to their intended destinations.
So why do we need to redistribute when using other routing protocols (eg mpls l3 vpn ospf pe-ce and rip pe-ce), as opposed to when using ml3vpn BGP PE-CE?
The need to redistribute routing information between protocols arises when using different routing protocols in different parts of a network, such as in MPLS L3 VPNs with OSPF or RIP as the PE-CE protocol. Redistribution helps achieve customer network connectivity on the CEs, as well as correct route exchange between the CE and PE devices.
When using OSPF or RIP as the PE-CE routing protocol, redistribution is necessary because these IGPs don’t inherently have the capabilities to carry VPN-specific information RDs and RTs. As a result, the PE routers need to redistribute the customer routes received from OSPF or RIP into BGP which is used in the MPLS core network. BGP is capable of carrying this VPN-specific information by using address families and is thus better suited for MPLS VPN environments.
On the other hand, when using BGP as the PE-CE routing protocol, there is no need for redistribution because BGP can directly carry VPN-specific information. Since the same protocol is used both between the PE and CE routers and within the service provider’s core network, there’s a seamless exchange of routing information.
So the problem described in this lesson is that the two customers are using the same BGP AS number which would cause them not to install eachother’s routes due to eBGP’s loop prevention system.
Now, it makes perfect sense if the ASes the customers are using are public because it would be a hassle to register a public AS for each of their locations that they want to interconnect using MPLS, so they’d just use the same one and that’s where Override and Allow AS IN could be implemented .
However, what prevents us (as the customer) from just using a private BGP AS number for each location?
That way we wouldn’t have to register any public ASNs and the Allow AS IN and Override options shouldn’t be necessary, right? We could just use a different private ASN for each of our locations.
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.
Are there any use cases for allowas-in if your BGP neighbor is IOS-XR? From what I read regarding Cisco documentation, XR doesn’t advertise a prefix to a neighbor whose AS it finds in AS_PATH of the prefix.
So unless the peering XR neighbor is configured with as-override, it will not advertise the prefix anyway, which means we’ll never get to use allowas-in properly.
This is another one of those behavior differences between IOS/IOS-XE and IOS-XR. The short answer is that yes, there are still cases where allowas-in is still relevant for IOS-XE implementations.
Indeed, IOS-XR does perform an outbound AS-path loop check by default. When a route’s leftmost AS matches a single-session eBGP neighbor’s AS, XR will suppress advertising that prefix to that neighbor, even before the receiving router’s inbound check can reject it.
However, there are legitimate scenarios where allowas-in remains necessary with an IOS-XR neighbor:
When the XR router is the receiver, not the sender: If your CE is IOS-XR but the far-end (PE or another CE) is IOS/IOS-XE, that far-end won’t suppress the route on send. Your XR box will receive a prefix with its own AS in the path and must use allowas-in to accept it, in exactly the same way as an IOS router.
When XR’s outbound suppression doesn’t apply: Cisco’s own documentation states the suppression only triggers if the neighbor is the sole member of its BGP update-group and the customer AS is the leftmost AS in the path. Multi-session designs, iBGP re-advertisement, or prepending scenarios bypass this suppression. In such cases, the route is advertised normally, and the receiver needs allowas-in.
The design is not deterministic: Cisco explicitly warns that update-group membership can vary unpredictably across routers. Relying on XR’s implicit outbound filter alone is unreliable. The recommended approach is to configure as-override (or deliberately as-path-loopcheck out disable) on the sender side to make behavior deterministic, ensuring the receiving side’s allowas-in works consistently.
So allowas-in isn’t useless with XR, but it is insufficient by itself unless the XR-side outbound check is also addressed. The standard fix remains as-override on the PE combined with allowas-in on the CE, just as in IOS designs. The difference is that XR adds an extra layer of outbound filtering you must account for in your design. Make sense?