Inter-AS MPLT Option B - AS Loops

Inter-AS MPLS Option B connections have limitations with regards to AS-Path manipulation. In the example topology, traffic from AS200 inside a "dirty" VRF is sent into AS100 for scrubbing/filtering before being returned back into AS200 again but returning inside a "clean" or "scubbed" VRF.

R1 is originating a default route from AS100 inside a "clean" VRF over an Inter-AS Opt B link to the vMX router. The vMX has an eBGP Opt A link inside the "clean" VRF to the IOS-XRv device, which in this example is the scrubbing/filtering device. The scrubber sends the default route out of its 2nd link back into the vMX over an eBGP Opt A link but now into the "dirty" VRF on the vMX. The vMX needs to send the default route back over the same (or another) Inter-AS Opt B link to AS200 now inside the "dirty" VRF.

On the vMX AS200 will already be in the AS-Path for this default route and various filtering/scrubbing/firewalling devices have limited BGP feature support, the vMX needs to strip or replace AS200 from the AS-PATH of the default route before it sends the route back to AS200 inside the "dirty" VRF. It is likely that the scrubbing device can't make path manipulations.

AS-Override can't be used here because it applies to egress advertisements and only to the AS number of the eBGP neighbour. For example, as-override on the eBGP Opt A session between the vMX and scrubber inside the "clean" VRF would only remove any trace of AS100 from the AS_PATH, not AS200 as that isn't the eBGP peers AS number.

One option would be to use "allow-as in X" on the AS200 devices (and "advertise-peer-as" on the vMX otherwise Junos won't send the route!) however, with Inter-AS Opt B links this affects all L3 VPNs being signalled over this eBGP sessions.

It is worth noting that just between the vMX and scrubbing device, AS100 will appear in the default route AS_PATH as it is sent from the scrubber back to the vMX inside the "dirty" VRF however, since this is an Opt A peering another option exists here, "local-as". On the Opt B links even the "allow-as in N" won't work without adding that option to all the iBGP neighbours inside AS200 in order for them to accept BGP UPDATES from the ASBR with their own AS number in the path.

It is not possible to originate a new default route from the vMX using "set routing-instances VPN_A routing-options aggregate route 0.0.0.0/0 as-path path 100" or "set routing-instances VPN_A routing-options generate route 0.0.0.0/0" in this Inter-AS Opt B scenario. If the aggregate or generated route on the vMX is preferred over the default route learnt over the Opt B peering then the next-hop for aggregate or generated routes is programmed into the vMX FIB, which is a discard next-hop. This means the vMX would drop all traffic following the default route. If the Opt B learnt route is preferred the aggregate is never advertised and the Opt B learnt route has the AS_PATH loop.

There are only two ways to solve this issue. An Option A peering is required for this specific L3 VPN between the vMX ASBR and R1 ASBR to allow the vMX to originate a default route with a next-hop of R1. Alternatively in an end-to-end label switched scenario (with no Option A links in the middle) setting the VRF on the vMX to use a per-vrf/table label would make the vMX perform an IP lookup for any labelled packets routing along this LSP (meaning paths would hit the vMX due to it originating a new default route but upon IP lookup match against a more specific prefix learnt from R1).

---