It is indeed a very valid use case.
For that to work, you would use Transfer Networks.
Under Network Design > WAN, you have certainly created a MPLS WAN. You can define the subnets that are known on the MPLS WAN under Transfer Networks.
Make sure you configure an IP address to ping check, a core router in the DC or a PE router on MPLS network would do the job.
In addition, make sure you configure the uplink to use its Internal IPv4 address for AutoVPN (Network Design > Uplink, select your MPLS uplink for the site and go to the AutoVPN tab).
Just to comfirm...
So, when I specify theese transfer networks under MPLS WAN, I'm telling the Gateway that when it receives a packet with destination IP address belong to remote site network, it should forward the packet to its ullink-mpls interface, is that correct? So this transfer networks acts like a static routes?
no explicity stactic or dinamic routing is needed?
But theese transfer networks also are know by the AutoVPN WAN because theese networks/zones exist in another sites insite the same organization.
(acording to my understanding, transfer networks are networks that aren't part of LAN zones iside the organization), as user guide explains here.
So, if it works as expected, there are two posible paths to reach romote sites networks.
1. AutoVPN WAN
2: MPLS WAN.
Then I can perform traffic decisions (fail over or load balance) with the feature path selection (traffic rules), rigth?
Transfer networks will indeed work as static routes for the WAN, for the "underlay".
If the destination IP is in a remote site equipped with Riverbed SDWAN, the route will be learned via the Overlay and the SteelConnect Manager. By default, Overlay network is always preferred.
If the destination IP is in a remote site with a traditional router, the underlay will be used.
With 2.11 coming up, you will have the ability to create a path rule that forces the traffic to go via the underlay