In BGP loop prevention rules, routers should prune routes in phase two of path selection where their AS is already apart of the the AS_PATH BGP attribute. This causes an interesting problem for service providers providing L3VPNs to customers via two independent eBGP connections
Topology
Default behavior
Juniper, by default, will not advertise routes from an ASN back to the same ASN. Therefore, when CE1 sends routes to PE2 and those routes get reflected from RR1 to PE4, we will not see PE4 attempt to send them to CE2
Solution 1 (advertise-peer-as + loops)
One solution to the problem is that we could tell PE4 to stop caring about whether or not it is advertising a wonky route using advertise-peer-as
And now we can check the router to see if it is advertising the route
Unfortunately, this solution also requires the CE router to make a change as well. Even though the Juniper is now advertising the route, the receiving router still plays by the rules defined in the BGP RFC for path selection.
If the AS_PATH attribute of a BGP route contains an AS loop, the BGP
route should be excluded from the Phase 2 decision function.
To make the receiving router accept looped routes, we need to configure loops
We are now accepting the route. By saying loops 2, we tell the router to allow 1 loop and discard any routes having 2 loops or more. Additionally, the looped routes will be marked as such in the router outputs as seen below.
Solution 2 (as-override)
If you're looking for a one-stop-shop method, you could lie to your CE router about the AS_PATH by using as-override
Notice that the AS advertised is now the AS of the service provider
And the CE router is happy with that without making any changes
Conclusion
This one got me good. AS_PATH loops aren't my first thought when customers are not receiving their routes correctly, but now I know!