Hi,
Sorry to be replying late. But it has been 2 days since I have been working with solutions for your network. Being a CCIE for routing switching, I had all the access to required equipment and hence had someone from my office setup equipment exactly as per your scenario. Even though chances of what you need to be achieving are bleek, I will publish result for what I have tried so far as to people who are willing to help you out can understand problems with the solution.
- •1) Initialy , I thought about manipulating metric for the prefix, but as I figure out that in a link state routing protocol, end to end visibility is important and hence, we at any point of time can change the link state database for 2 different routers. I means that all the routers need to have the same link state database. Hence the fisrt option of manipulating metric is lost.
- •2) Second I though about changing the administrative distance. I figured that maybe if we could change the AD of routes from 2 difference neighbours, the route with lower AD value would be preferred. :-P. Ok then I remember… blah…. Metric is preferred first, then the AD value.
So now I started to think out of best practises. Being a CCIE, it is important that we think out of the “BEST PRACTICE”fashion.
How about we have a static route with tracking via IP SLA on the backup route device and redistribute it in ospf to the neighbour device with a lower metric. OK!!! . But it seems to have a problem.
OSPF will always prefer an intra-area route, then an inter-area route and lastly an external route. Hence even with a lower metric, the internal route across the primary link would be chosen.
Now I was in a fix, so we tried something else.
Like the above I did think about HSRP, but it will eventually follow the link which is preferred by OSPF. HSRP only will get information till the GATEways. They do not influence routing decisions. This decision is still OSPF.
And apart from that, the manipulation possible on only one side makes it even more difficult.
And so I started to think whether there was a way to manipulate Multicast so that we could just route the multicast traffic over the backup link.
But then think about something known as RPF. As multicast flows it will perform a reverse path forwarding for the packet at every hop. So till your OSPF routes don’t be pointing in the opposite direction, its not going to work.
I also though about creating static mroutes for the particular multicast traffic, but once applied, we could not failover to the primary path if the backup went down. Creating static mroutes with tracking is not an option.
So I am back to the square one. But am still working with the scenario. I have a couple of guys on my team work on it. Seems that we are closer to a particular solution, but it doesn’t seem best practise.
Will let you know tomorrow for any updates.
Regards
Rustom Billimoria
CCIE R/S#24798
