Say I have a triangle of sites - internet comes in to Site A and distributes it to Site B and Site C
Site C and Site B also have a link between them in case a primary link goes down.
Site B is significantly larger than Site C - so we are using a lot of bandwidth on Site A ↔ Site B - I’d like to choose some prefixes to route via Site C to use some of the spare capacity on A->C, C->B - but want to do it dynamically in the routing table so a link failure won’t stop those IP’s working (so don’t want to static route from A->C)
What is best practise to identify these routes and push their data via Site C using OSPF with link failure protection so all will keep working in case of any of the links failing?
My thoughts were to change distance or nexthop on ospf-in route filter - but there’s no way to only tag the routes coming from one neighbor or the other so if a link was to go down, when receiving the route from the leftover peer it’d still be trying to set the nexthop to the broken site or create a loop. If I could match to say ‘route x from neighbor y set-nexthop n’ but doesn’t seem possible?
I answered this for myself with a solution that I didn’t think would work based on an article i read.
Basically matching the cost at the originating router will automatically trigger ECMP (50/50 split), my understanding was it also took into account router hops for ECMP but it doesn’t, just cost - so where the direct link was 10/10 total cost 20 - I changed the 4 interfaces to 5 on the longer leg to give it a cost of 20 also, and ECMP kicked in.
It’d be nice to be able to engineer it a bit to say go 66/33 or 75/25 using multi-gateway routes but I haven’t found a way to do that dynamically yet, and not sure I will.
When you have a larger link and a smaller one, just make point-to-point VLAN on the larger link, put IP, advertise the network in OSPF and it will do ex 75 / 25
Thanks for the tip - seems hacky and annoying (and will waste IPv4 since i still use that on my ptp links, but might change this to private addressing in future) but would certainly help in a pinch.