Dual wan suggestions (please)

Post #346,378 by crazy 8/19/11 6:59:00 AM Reply	Dual wan suggestions (please) We got a comcast bus line and a verizon t1 (well, not really t1, but they call it that and it is that speed). We are not adding any if possible. The location sucks and the options are not great. The t1 is our primary line. Desktop surfing goes out over it, and email comes in over it. We have a web email interface over ssl, and a couple of remote pc connections, but low corporate traffic for the most part. The comcast line is the random secondary line, but it is not integrated with the network, and if you can surf the comcast line, you can't get to the rest of it, it requires a patch panel swap. And once you are on that side, you are on the "outside". The verizon t1 goes out in the rain. It usually is back up the next day, and the corporate direction was to ignore it since the business impact was minimal. Verizon has been on strike. Our t1 has been down for about 5 days now. Inbound mail is caught at a vendor web service, stored on the cloud, and picked up via browser for the few people who require it. Our website is hosted "out there", but it is integrated for configurations and order receipt with our internal systems, so that's broken for now. I have short term and long term goals, and the short term might be discarded depending on how soon Verizon is back to work, which means I need some odds on strike resolution possibility to make a decision. GFL. Sigh. Ok, back to tech. I want to be able to use both the t1 and the cable lines. I want to load balance, round robin fashion. I want to do it via some type of supported device (years ago I hand configured this stuff under OpenBSD). I know I will NOT get any speed increases, and the speeds will be dramatically different depending on your traffic type. Inbound traffic over the comcast line is 10 times faster than the t1. But outbound traffic (and we have webcasts that send slide shows and audio streams) will be much slower on the comcast line, and if we do any real comcast uploading, the download speed will tank because uploads affects downloads. So configurability is important. I assume (but am not sure) incoming email connections will be driven by multiple MX records. Once the email hits the device (coming in from either connection) it should then bounce the packets to the server in the same way it does now. Is there anything else I need to think about on that side? Ok, I got a hardware budget of $1,300 (not really, but I tossed the number around it will probably be accepted). I got that number from this device: Peplink 210: http://www.peplink.c...-spec/#comparison I do NOT get my user/groups bandwidth control, though, until I go up to the 310, along with some other functionality. Something tells me I need another $700. Man, it's tough dealing with small business where every dollar counts. But if I do this in my own BSD box, the inhouse guy will never be able to support it, and I need to be able to hand off and walk away for the next project. I'm not stuck on this device. Are there any others you recommend in the price range? Thanks
Post #346,394 by Another Scott 8/19/11 8:55:45 AM Reply	I assume Cisco would be more than happy to sell something. I don't know enough about this stuff to offer any suggestions. I'm sure there are lots of choices, from Cisco on down. Presumably on-board management smarts (being able to segregate everything) is where the cost is going to come in. http://www.amazon.co...%3Adual+wan+cisco Good luck. Cheers, Scott.
Post #346,399 by crazy 8/19/11 9:04:10 AM Reply	hate cisco hatem hatem hatem. Highend ridiculously expensive, and the support contracts are insane. Low end is linksys crap. But thanks anyway.
Post #346,401 by folkert 8/19/11 9:14:48 AM Reply	You won't like my suggestion. You'd be better off and cheaper and more maintainable using the OpenBSD stuff. The internal IT guy, if he can read instructions, that you provide, he can maintain it. Seriously, I don't care for black boxes as they die at unexpected times and are typically tough to replace as nobody knows how they work. At least with the BSD box, you can backup the configs and reset/replace the machine should it die some horrible death. Its really a simple firewalled routing issue. Put costs on the interfaces for certain types of traffic and it should just take care of itself. The tricky part will be the external Website using primary and secondary IPs... since most web apps don't have/understand failover... it never even gets in the spec nor does it usually work if it does need to do it.
Post #346,431 by boxley 8/19/11 2:15:25 PM Reply	seconded Any opinions expressed by me are mine alone, posted from my home computer, on my own time as a free American and do not reflect the opinions of any person or company that I have had professional relations with in the past 55 years. meep
Post #346,432 by crazy 8/19/11 2:23:26 PM Reply	Says the 2 professional admins who deal with this all the time
Post #346,442 by boxley 8/19/11 3:15:57 PM Reply	no, I deal with routers and network groups but you control all pieces of the operation because of size. Most of these small appliances are running a form of linux and iptables under the hood so you might as well control the whole thing yourself. You might be surprised (or not) at how many big name pizza boxes run a form of linux under the hood in network and SAN space Any opinions expressed by me are mine alone, posted from my home computer, on my own time as a free American and do not reflect the opinions of any person or company that I have had professional relations with in the past 55 years. meep
Post #346,474 by crazy 8/20/11 6:45:39 AM Reply	Oh c'mon. Do I seem that dumb? I've been following device evolution for years, ever since the 1st TIVO and low end routers and cable boxes started using it. And when the high end router advertising protocols and gbit bandwidth showed up on the Linux devices, I knew they owned the market. I'm surprised when they are NOT linux based. Which has nothing to do with installing a general purpose do anything operating system, and then deciding the exact pieces to install, and then configuring each of the pieces to work together, and then creating a failover box since if I'm not around it can not be recreated by anyone else (at least anyone else available). And keep in mind when this box goes down, the entire company will stop working. This is not an isolated "use occasionally" system, this is the cornerstone of how people deal with the outside world. Note: That recipe is the same for any dedicated 3rd party box over a self install, and it usually makes sense for smaller companies who do not have multiple techs to draw from. You don't even need to know what it is doing to know that a supported black box solution where the cost of development and support is spread across many devices is usually the cheaper solution, and almost always the SAFER solution than any home brew, no matter how much better the home brew solution is. Note: This equation goes away the second you have 2 full time techs working for the company. 2 techs can be leveraged many times over what a single tech can do, no matter how good the single one is, because they can get past the single person dependency issues. Of course, it means accepting the limitations of the box. What I usually do is get a black box, use it until I hit the limitation, and then recreate the expandable Linux or BSD equivalent and start using that as a backup or extra. But I want a supported box to start off with, and I want it for a fall-back if I hit a problem with my home brew solution. Ok?

Welcome to IWETHEY!