Introduction
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
root> show route advertising-protocol bgp 100.69.0.5
fortune-50.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 100.69.0.2/31 Self IPE4 RIB-ADJ-OUT
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
root> help topic bgp advertise-peer-as
... In addition, the software does not
advertise those routes back to any EBGP peers that are in the same AS as
the originating peer, regardless of the routing instance. You can modify
this behavior by including the advertise-peer-as statement in the
configuration...On router docs explaining advertise-peer-as
And now we can check the router to see if it is advertising the route
root> show route advertising-protocol bgp 100.69.0.5
fortune-50.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 100.69.0.2/31 Self I
* 100.70.0.0/24 Self 65500 IPE4 ADJ-RIB-OUT
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.
root@CE2> show route receive-protocol bgp 100.69.0.4
inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 100.69.0.2/31 100.69.0.4 65000 ICE2 ADJ-RIB-IN
To make the receiving router accept looped routes, we need to configure loops
set protocols bgp group ebgp neighbor 100.69.0.4 family inet unicast loops 2
root@CE2> show route receive-protocol bgp 100.69.0.4
inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 100.69.0.2/31 100.69.0.4 65000 I
* 100.70.0.0/24 100.69.0.4 65000 65500 ICE2 ADJ-RIB-IN
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.
root@CE2> show route 100.70.0.0/24 extensive
inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
*BGP Preference: 170/-101
AS path: 65000 65500 I (Looped: 65500) CE2 RIB-LCL
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
... Compare the AS path of an incoming advertised route with the AS number of
the BGP peer under the group and replace all occurrences of the peer AS
number in the AS path with its own AS number before advertising the route
to the peer ...On router docs explaining as-override
Notice that the AS advertised is now the AS of the service provider
root> show route advertising-protocol bgp 100.69.0.5
fortune-50.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 100.69.0.2/31 Self I
* 100.70.0.0/24 Self 65000 IPE4 RIB-ADJ-OUT
And the CE router is happy with that without making any changes
root@CE2> show route 100.70.0.0/24 extensive
inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
*BGP Preference: 170/-101
AS path: 65000 65000 I
CE1 RIB-LCL
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!
