When the configured routing instance is active on an ACX node running Junos 23.2 alongside vrf-import/export route leaking policies on an L3VPN, RTBL (route table lookup) next-hops are installed in the forwarding plane, a construct not supported on this platform in this release, causing traffic to the affected prefix to fail.

In deployments where an NMS subnet is shared across multiple L3VPN routing instances via route leaking, the configured routing instance is used to redistribute the NMS prefix. When this routing instance is active on an ACX node alongside the following vrf-import/export policies applied to a customer VRF, the Junos RPD installs the leaked route with an RTBL next-hop type in the forwarding table rather than a concrete interface or label-switched next-hop.

set routing-instances <VRF> vrf-import shared-nms-import

set routing-instances <VRF> vrf-export shared-nms-export

An RTBL next-hop defers forwarding resolution to runtime rather than resolving to a definitive interface or MPLS label at route installation time. This construct is not supported on the ACX forwarding architecture in Junos 23.2 and results in traffic being dropped or misforwarded to the affected subnet.

Ping and traffic to the NMS prefix (e.g. 217.X.X.X/28) fails when sourced from a remote PE via the affected L3VPN.

The affected prefix appears in the forwarding table with rtbl as the next-hop type:

217.X.X.X/28 user 0 rtbl 555260 1

217.X.X.X/32 user 0 rtbl 555260 1

The affected VRF routing table shows both a Direct route (via IRB) and a BGP route for the same prefix, with the Direct route winning as the active entry.

The remote PE, receives duplicate VPN label advertisements for the same prefix, one from each routing instance participating in the route leak.

Traffic and ping succeed when RI is deactivated, confirming the routing instance as the trigger.

The configured routing instance causes the NMS prefix to be installed locally on the ACX node via a directly attached IRB interface. When the vrf-import policy then leaks this prefix into the customer VRF, RPD cannot resolve the leaked route to a concrete forwarding next-hop and instead installs an RTBL (route table lookup) next-hop, instructing the PFE to perform a secondary routing table lookup at packet forwarding time.

RTBL next-hops are not supported in the ACX forwarding plane architecture under Junos 23.2. The result is traffic being dropped or misforwarded.

Supported configuration (Junos 23.2)

Remove the configured routing instance from the ACX node. The vrf-import/export policies alone are sufficient to achieve NMS route leaking into the customer VRF and do not trigger RTBL next-hop creation. Traffic resolution falls back to the BGP-learned next-hop with a valid MPLS VPN label.

deactivate routing-instances <Configured name>

commit

Not Supported configuration in Junos 23.2 EVO:

Having RI configuration active and vrf-import/export route leaking policies in place on an ACX node simultaneously. This combination creates RTBL next-hops and is explicitly unsupported.

Alternative topology (if the configured RI is required for resiliency)

If the RI must remain active for firewall attachment or resiliency purposes, the routing instance and associated IRB should be moved to an MX node.

The ACX then operates as a pure transit node forwarding labeled traffic without needing to install RTBL next-hops locally.

After removing RI, confirm that RTBL next-hops are no longer present and the prefix resolves via a standard next-hop:

show route forwarding-table | match rtbl

show route <prefix> table <VRF>

show route receive-protocol bgp <peer> table <VRF> <prefix> extensive

Expected: no rtbl entries for the NMS prefix, single VPN label advertisement on the remote PE, and successful ping end-to-end.