I recently saw this addition to incontol SF tunnels and whilst useful in practice how it works doesnt really help if you have a routing protocol peering for route advertisements.
The issue is that when you use this DR tunnel setup it creates a master and slave tunnel but both are active and both advertise routes using OSPF, with different costs but this isnt ideal.
In the scenarios I have with customers we have this OSPF peering (and soon to be BGP on one) from the hubs with customer core routers, the issue is that with the current DR tunnel setup is that it advertises the remote site routes from both hubs at the same time.
What would be ideal is either:
1: The slave tunnel is in a standby mode, not active and not advertising the OSPF routes from the branch to the hub.
or
2: The slave tunnel is active but does not advertise any OSPF branch routes until the master tunnel fails.
This would make the DR mode for SF tunnels much more usable, right now I have 3x customers with split redundant hubs and we’ve had to write a manual process to follow to failover due to the issue with the branch networks being advertised from both hubs simultaneously.
With the carriers kit they ignore costs, in fact they dont really like to use OSPF and prefer BGP which we can now switch to however the issue is that the same routes get advertised from both hubs at the same time. Am not sure how this works on BGP yet but would assume it takes the OSPF learned routes from the SF tunnels and re-distributes them into BGP so we’d be back with the same problem of the branch routes being advertised from both hubs at the same time.
Its not something we can change or influence hence the request to change how it works as we would be able to install split site auto failover hubs with no need for manual intervention as we have to now.