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.