After route recursion to remotely leaked VPN routes is enabled, a route can inherit the label and tunnel ID of a route leaked from the remote end. Then, the device can forward data through the tunnel to which the route recurses.
A static route needs recursion if its next hop is indirect. To enable the static route to recurse to a cross route on the remote VPN, run the ip route recursive-lookup bgp-vpnv4-route enable command. If a static route recurses to a cross route on the remote VPN, the static route can inherit the label and tunnel ID of the cross route. Then, the device can forward data through the tunnel to which the static route recurses.
In some upgrade scenarios, however, you need to prevent a static route from recursing to a cross route on the remote VPN to ensure that the path along which traffic is forwarded remains unchanged before and after the upgrade. In Figure 1, a BGP VPNv4 peer relationship is established between AGG1, AGG2 and RSG. L3VE interfaces are configured on AGGs and VPN instances are bound to the L3VE interfaces, so that the CSG can access the L3VPN. To forward traffic, BGP is configured on AGGs to import direct routes between the CSG and AGGs and static routes are configured between AGGs and Node B. The static routes are destined to 1.1.1.1/32 and share the next hop, which is the address of the interface connecting AGGs on the CSG.
Before the upgrade, the static routers configured on AGGs cannot recurse to a cross route on the remote VPN. Therefore, the downstream traffic path is Link A. After the upgrade, however, the static routers configured on AGGs can recurse to a cross routes on the remote VPN by default. The static route configured on AGG2 will recurse to the cross route 11.11.11.0/24 on AGG1 and inherits its label and tunnel ID. After the recursion, the static route on AGG2 will advertise routes to the RSG based on the BGP VPNv4 peer relationship. The RSG receives the routes with the same prefix from AGG1 and AGG2. Therefore, the RSG may select the route from AGG2 as the optimal route. The traffic forwarding path may transfer to Link B, which is different from Link A before the upgrade. To prevent the preceding problem, run the ip route recursive-lookup bgp-vpnv4-route disable command on AGGs to prevent the static routes from recursing to the cross routes on the remote VPN.
In Figure 2, PE1 and PE2 are IBGP peers, and CE1 and PE1 are IGP neighbors. PE2 learns the IP address of CE1's loopback interface, and an EBGP peer relationship is established between CE1 and PE2 using loopback interface IP addresses. By default, the BGP routes that PE2 learns from CE1 through the EBGP peer connection cannot recurse to remotely leaked VPN routes. As a result, traffic fails to be forwarded. To address this problem, run the ip route recursive-lookup inherit-label-route enable command to allow the BGP routes to recurse to remotely leaked VPN routes. After the BGP routes inherit the labels and Tunnel IDs of the remotely leaked VPN routes, traffic can be correctly forwarded.
Before configuring route recursion to remotely leaked VPN routes, configure basic BGP/MPLS IP VPN.
This command mainly applies to BGP/MPLS IP VPN scenarios.
Run the display current-configuration command in the system view to check whether route recursion to remotely leaked VPN routes is enabled.