from your diagram, i don't see anything for the ospf to have ecmp? am I missing something?
let us say, all links are ether with default cost of 10.
Or, we could say that A<>B is 10, B<>C is 10, and A<>C is 20 like I did in my initial post.
To re-iterate, ROS6 forms ECMP just fine in the above example.
And in all other examples where different paths with potentially different number of hops still add up to the same total costs.
I have been able to reproduce this new ROS7 behavior on the test bench with 4 different kinds of hardware, on every version of ROS7 up to the latest @ 7.9.1, and whether every router in the test is running ROS7 or whether it is a mixture of 6 & 7.
The ROS7 routers refuse to ECMP two paths with different hop numbers regardless of cost settings.
maybe, that is maybe - two bridged tunnels on b, from ab and bc - could give you ac ecmp. i think that is what you did, hence you were introduced to your next problem: how about if there are many sites to config?
Yes that is exactly what I've had to do to work around the problem so far, given that the offending router is a hardware upgrade that can't do less than ROS7.
And we do have many sites to config, and I do
want to avoid creating a spaghetti mess of tunnels just to try to stay ahead of the problem.
I'd rather get the "ECMP is impossible unless number of hops is identical" bug out of the way instead, and I'm digging my heels against any more ROS7 deployments until that gets resolved.
Though if any other folks have ideas for more maintainable workarounds, I am all ears. It doesn't have to work "just like it used to" as long as it can in fact work
in some maintainable manner or another.
For example: We've got an ongoing project to try to vet all of our delivery paths for >1504 L2MTU, then maybe MPLS-TE could play a part.
Someone I was chatting with thought that maybe iBGP could work as a stop-gap. Cue thousand-yard stare