View Full Version : Redundancy and failover - can StarOS do it?
MrSmith
01-21-2005, 09:56 AM
I want to do something like in this lovely network map:
http://www.thedave.us/redundant-link.gif
Right now, our wireless network is fairly fragile. There's one point-to-point link between our office and our main tower (which feeds our other towers, etc.) We had an outage on that link a couple weeks back, which just reinforced our need for some kind of redundancy.
Right now, it's (ASCII ART)
Internet --- StarOS system --- (two Trango radios) --- switch --- customers
I'd like there to be two separate links, and StarOS systems at either end. I know it will involve a bit of re-routing, but that's relatively trivial.
Can StarOS do anything like this? (If not, will v3 have any features that will help?) I know there are lots of things that look like they might help -- STP maybe, iBGP (though that might be more complexity than is needed for this). Which is the best (quickest, easiest, most reliable, whatever) way to do this?
lonnie
01-21-2005, 10:28 PM
There is a nice topic about OSPF with some awesome results posted by bminnish and oscarbravo. They have posted an excellent sample config and some ideas on what not to do as well.
It will allow redundancy for the routing.
bminish
01-22-2005, 07:03 AM
It will allow redundancy for the routing.
if both routes cost the same then OSPF should also load balance whilst both routes are up, presumably the normal stare of affairs..
The only thing to watch here though is that OSPF has no concept per-se of the actual throughput on a radio link, it only knows what you tell it about the cost of that link when you configure it.
In the case of 2 x wireless links you could end up with a situation where the link becomes very marginal due to radio related issues but OSPF will still route data down it on the basis of cost for as long as that link remains up in any capacity. However once the link actually drops out OSPF will, after a few seconds reroute traffic via the other link.
.Brendan
funkywizard
01-22-2005, 02:10 PM
any way at all around that problem of ospf routing traffic down a link that is functionally down but shown as up? can bgp help in a situation like that?
bminish
01-22-2005, 02:57 PM
any way at all around that problem of ospf routing traffic down a link that is functionally down but shown as up? can bgp help in a situation like that?
Not quite sure what you mean?
OSPF will decide a link is down if the link can't pass traffic and reroute things according to the next lowest cost route. It doesn't get the state of the link from the hardware, it only cares if a link can pass data or not.
It will also remove direct links from the routing table that it has not heard from after the dead interval. This defaults to 40 seconds and links are polled every 10 seconds (poll-interval) removed links are propagated very quickly throughout the network
In tests here we are seeing the switchover to the other higher cost route after about 15 seconds of the main route being down, once the main route comes back up we are seeing that route being used (and distributed) within 1 to 2 minutes of the route coming back.
The only issue with this behaviour over wireless is possible problem of a link that is up but not running at it's normal speed since the cost of the link is set by the configuration and does not track the changing speed of the radio link. if you have redundancy one option may be to lock your primary link to the rate you need, this way it will fail rather than associate at a lower speed if the radio path gets marginal for any reason.
BGP (Border gateway Protocol ) is of use where you are routing and you have to deal with AS (autonomous system) Numbers to manage one or more routes to the Internet and you are dealing with your own PI (Provider Independent) IP allocation. It's not really relevant in this application
.brendan
funkywizard
01-22-2005, 03:33 PM
thanks. that sounds reasonable. I would say the speed locking would be one of the better methods to deal with the possible performance problems of an (almost) down link.