EIGRP can only be used on service VRFs, not on the global VRF. Therefore, route leaking isn't supported for routes from the global VRF to the service VRFs, and between service VRFs for the EIGRP protocol.

Redistribution in EIGRP requires bandwidth, load, reliability, delay, and MTU settings to select the best path.

Service-side NAT is not supported with route leaking between the global VRF and service VRFs.

NAT is not supported with transport VRF route leaking.

IPv6 address family is not supported for route leaking.

Inter-service VRF route leaking is not supported on Cisco IOS XE Catalyst SD-WAN devices with multi-tenancy.

Route leaking using centralized policy is not supported.

Route leaking across different devices or sites using export policies in Cisco Catalyst SD-WAN is not supported.

Each service VRF can leak (import and export) a maximum of 1000 routes.

Only prefix-lists, tags, and metrics can be matched in route maps that are used to filter leaked routes.

Overlay Management Protocol (OMP) routes do not participate in VRF route leaking to prevent overlay looping.

Static routes that point to a next-hop resolved through a prefix replicated from a service-side VPN into the global routing table (GRT) are not supported. However, you can configure a static route in a service VPN and replicate it into the GRT.

Route replicate with all keyword is not recommended.

When configuring route leaking for a VRF, the route-replicate command under global-address-family ipv4 should not use the all keyword as the protocol for the unicast option. Instead, specify a particular protocol (e.g., connected ) to prevent route looping.

Redistribution of replicated routes into BGP (which were imported into the global routing table from a VRF or into another VRF) is not supported within the same topology. For example, to redistribute a connected route from the BGP global routing table that was originally replicated from VRF 1, use redistribute connected vrf 1 instead of redistribute connected.