 John Galt Forward, March Premium join:2004-09-30 Happy Camp
·CenturyLink
| Network Backhaul Fallback and Redundancy Here is a network design for an area...
I would like to have two separate feeds to the network, one of them being a wireline T-1 and the other a wireless backhaul to the NOC. Both of these would be active to provide redundancy and fallback in case of route disruptions.
The wireless feed would probably have more capacity than the T-1, so it would be the primary backhaul and the T-1 would provide back-up.
At each of the routers (the distribution point to users with multiple APs) there are multiple paths to the NOC.
The question is: what is the best way to implement this redundancy, and keep the data flowing correctly under normal circumstances and re-routing automatically in case of link failure? -- A is A | |
|
  gmcintire Graham Premium join:2005-08-09 Blue Ridge, TX
| Re: Network Backhaul Fallback and Redundancy Actually, that's similar to a design I've been considering using a T1 and DSL. The best solution to use would be OSPF dynamic routing. It allows you to assign cost-based routes, etc, so certain routes are preferred over others. RIP would work as well, but it is extremely limited and only works based on hops. It always takes the shortest number of hops necessary to get to it's destination. | |
|
  AMD Phreak Premium join:2003-12-14
| I would suggest that you implement routers at each site using something like OSPF or EIGRP or your favorite protocol. You will need to do some configuration on each router so as to set link costs and what not, so that traffic hits the BH before picking the T-1 route. Using this method, the entire network would be routed, so that in the event of the link between say E and C goes out because 6 and 2 got wiped out the router at E would automatically re-route traffic through B and D. When the router cannot see one another like in this situation, they will exchange routing tables and auto update each other so that the new route is formed.
In the event that the BH or T-1 goes out, the same happens. You will need to program the routers at the BH and t-1 sites so that it passes public ip's properly onto the network in the event that something pukes.
All in all, this is how it should be done anyway. Running a bridged network may be cheaper and easier to do, you run into some serious issues doing such. There are other benefits to this setup, such as enhanced control over the network (traffic) as well as enhanced security. | |
|
  John Galt Forward, March Premium join:2004-09-30 Happy Camp
·CenturyLink
| Does this all still apply if I have two separate providers?
In theory I will be using the same upstream provider (since bandwidth is extremely cheap through them), but if I wanted to have upstream provider redundancy...what would I need to change (if anything)? -- A is A | |
|
 |   sporkme drop the crantini and move it, sister Premium,MVM join:2000-07-01 Morristown, NJ
·Optimum Online
| Re: Network Backhaul Fallback and Redundancy said by John Galt :Does this all still apply if I have two separate providers? No, it gets much more tricky. Each provider would be giving you a range of addresses. The network you've described looks too small to be doing BGP with your upstreams. I would say if you want multiple providers, bring them to a central point (your datacenter) and run BGP with two providers there. Then within your own network use OSPF to handle failover between multiple backhauls to your datacenter and your PoP(s). OSPF is probably the easiest link state protocol to setup, and it works extremely well. You will need "real" routers if you don't want to pull your hair out with OSPF (unless your routers are OpenBSD, which has a very nice ospfd implementation). -- enjoy zesty ranch man-flavored baby tacos responsibly | |
|
 |  nwn Premium join:2004-03-05 Centerville, IN
| Depends on whether you need public IPs inside. If you can do everything private inside, OSPF should find the 'up' path and get your traffic through. If you need public IPs, then you will need to go with something like Sporkme suggests. -- Scott | |
|
 cmaenginsb Premium,MVM join:2001-03-19 Palmdale, CA
| sporkme, one of the single greatest thing about a wireless topology is that you do not have to be dependant on a single NOC or distribution center. Why go to the expense of providing redundancy on the network if you backhaul to the same NOC.
That being said, a T-1 is not the most suitable to be exchanging the BGP updates that are required to provide 2 redundant paths. Additionally you need a larger router than the standard T-1 to do this.
Of course the other question is if this is a natted network which means you just need to have the problem of setting up OSPF. -- CCNA, Comtrain Certified Tower Climber | |
|
 lutful Premium join:2005-06-16 Ottawa, ON
·TekSavvy Solutions..
| said by John Galt :keep the data flowing correctly under normal circumstances and re-routing automatically in case of link failure? I would mark up the diagram with policy and failover scenario that "makes sense" at each node and then sit down and write a big Mikrotik script.
Since it most likely will NOT be the best solution, I would then keep tinkering with the script until the cows come home | |
|
 |  DejanCDN
join:2004-11-17 Kuwait
| Re: Network Backhaul Fallback and Redundancy We are about to implement this using Foundry's ServerIron ISP load balancing switches. No need for BGP, it's all done transparently by the switch. This solution is normally costly, but we got some refurbished units at VERY low prices, so it's great. Basically, each box can NAT from internal IPs to up to 8 different ISP IPs, so you can have up to 8 connections to the outside, with very advanced load balancing. | |
|
 anmangla
join:2005-12-22 319455
1 edit |  There kind of backhaul solution is possible with a wireless equipments which supports STP feature.
As per my knowledge smartBridges airHaul Nexus can achieve this kind of Connectivity with a redundancy from an alternate path
Thanks Anup Mangla
Mod note: edit for commercial info. | |
|
 |  DejanCDN
join:2004-11-17 Kuwait | Re: Network Backhaul Fallback and Redundancy STP will keep one link working at a time, won't do anything if you want 2 or more links to work at the same time and be load balanced. | |
|
  viperm Carpe Diem Premium join:2002-07-09 Winchester, CA
| Hey Deja where did you find the foundry switches thats all we use in our Datacenter and each tower location and are always looking for a good deal. Also do you know what Firmware / IOS your running on it? we are looking for ones that have the firmware that allow ports to operate as both VLANS and not at the same time. The current firmware only allows to run all ports in VLAN or all off not mixed mode.
| |
|
 |  DejanCDN
join:2004-11-17 Kuwait
| Re: Network Backhaul Fallback and Redundancy Actually, we are a Foundry reseller, and bought back old ServerIron XLs from a client. However, there are a lot of companies in USA that sell refurbished Foundry stuff, try Google. As for firmware, no idea, but I will try to find out from our techies. | |
|
 cmaenginsb Premium,MVM join:2001-03-19 Palmdale, CA
| Dejan, if you implement NAT then of course you don't need BGP. However if you are dealing with customers with public static IPs you will only be able to have them work on 1 of the providers unless you run BGP. -- CCNA, Comtrain Certified Tower Climber | |
|
 |  DejanCDN
join:2004-11-17 Kuwait | Re: Network Backhaul Fallback and Redundancy I understand that. However, in the Middle East, only 1 ISP offers BGP4 hat I know of - at a price! Others won't even discuss it. Besides, Foundry ServerIron does some other neat stuff, such as proxy DNS etc. | |
|
 cmaenginsb Premium,MVM join:2001-03-19 Palmdale, CA | Dejan, yeah when you deal with stuff overseas it's different, I also know you knew that but I wanted to make sure those with less networking experience did know as well. -- CCNA, Comtrain Certified Tower Climber | |
|
 |
|
 |