There is no canned solution to achieve that at the moment though we have some demand for dynamic IKEv2 routing to pass limited information such as a metric. We are seriously considering the feature but as always, any use case (and ideally business case) is always welcome to help our Product Managers take a decision. This remains hypothetical until it ships.
In them meantime, I will build on the HSRP option that seems to match the question really well.
To ensure the return traffic goes to the secondary when it is online, we can give each device in the branch a distinct identity. Assuming certificates, the OU can be used to contain "primary" or "backup".
Two hub profiles can be created to match either primary or backup. Each profile can apply a distinct authorization profile. Each authorization profile can accept remote prefixes but apply a different administrative distance (and tag) on the received route. In this case, we would make sure that the admin distance from the primary spoke is _higher_ than the admin distance of the secondary spoke.
When the secondary spoke connects, it will exactly overlap with the primary branch prefix but have a lower admin distance and thus the secondary branch route will override the primary in the routing table (RIB) of the hub.
This boils down to having the hub select the preferred path based on the branch identity/identities that connect to it.
Depending on the exact use case, there may be alternative (completely different) designs.
Please note that if security is not crucial (e.g. no need for RADIUS route filtering etc.), you can still use a routing protocol to get back the possibility of advertising the prefix.
- Fred from the RADKit team
