You can go for a software version that will need you to patch the kernel of your choice or go for an already made Rack mount box with failover/redundancy capabilities plus Gigabit ethernet.
Ours has't gone down for 3 years.Got a newer one recently at roughly $5000 worth it;-) .Note; It's not just a bandwidth manager (router,firewall,brigde name it) all on Linux! Good for a network tool/machine
Rgrds
Ronny
Mark Tinka wrote:
On Tuesday 19 April 2005 17:55, Guido Sohne wrote:Apologies for the delay in responding. A storm collapsed the mast serving my area with wireless connectivity.No worries... another redundant connectivity?Last mile is wireless. Motorola Canopy, I believe.What kind of (bandwidth) management capabilities do you get on this device. I've heard popular deployment of these units, but haven't had personal experience with them yet.I'll look into this. We had to create a private network to route between the existing internal network and the public network.Hmmh... can you draw and ASCII? Are public/private networks synonymous with public/private IP's, or simply network segmentation?Both of these networks use public IP addresses and my problem was how to send packets to the router.>From where? Not sure I understand.I think it should be possible to forward packets from the bandwidth manager (if it is setup as a bridge) to a new default gateway.This is the thing - with the bandwidth manager running as a bridge, no forwarding is required. Packets are presented to the bandwidth manager ingress/egress ports (depending on direction of packet travel), processed by the bandwidth management process, transported over the high speed backplane to the exit port, and that's it. You could say it's a switch that analyzes packets, but doesn't route them. Any IP addressing information (IP/Mask/Gateway) configured on this device is purely for management purposes (remote access, monitoring, e.t.c.), and not for production purposes (bandwidth management).I wonder if it is simpler to do that or to keep the existing private network ...Whichever is simpler and doesn't introduce unnecessary overhead, complexity or points of failure.Both. I have settled on Shorewall and I think it is very nice because it allows you to think at a higher level than iptables rules.Never used this before, but a quick browse on www.shorewall.net reveals it provides a user-friendly interface to IPTables.Yes. The box talks directly to the router and proxies HTTP for internal clients.So the redirection to the cache box is done by the bandwidth manager? Just need to make sure I understand this right.Cache hits are returned at full speed.At full speed to the customer, at contracted bandwidth to the customer, all the way to the last mile?Once in a while I get about 30k/second when one of my requests hits the cache. The cache is setup to keep many small objects in memory and to keep many large objects on disk.A very good design.I am recommending to the client that they firewall connections from the client side as well. The idea is to insulate customers from each other and to avoid the client's internal network being a 'soft' spot, security wise. Do you have any recommendations for this?Being a wireless network, it's definitely a broadcast multi-access medium. So if you put customers in a single subnet, e.g., /28, those customers will more than likely *see* each other. I usually like to simulate a point-to-point leased line connection on a BMA network by using Ethernet sub-interfaces (not meant for this, but does the trick). This would mean using 802.1q VLAN trunking on your switch/router ports. You then have an Ethernet sub-interface for each customer, assigning a /30 for the point-to-point connection - this would be a first-line filter of broadcast messages. You need to be wary of router performance when running 802.1q trunking.Acknowledgement packets and other TCP connection overhead that involves very small packets are sent first. It takes up less than 4kbit / second but enables other incoming connections which are waiting for an ACK to send the next packets. HTTP traffic, mail traffic etc are sent next but have access to much higher bandwidth. What happens is that there is a slight pause while waiting to send the overhead packets, and everything else then comes in faster as a result.Sounds like QoS.We also cache DNS traffic since we realized that the customer's web browser first makes a DNS lookup, then the transparent proxy makes the same DNS lookup.This is pretty standard.There is no internal DNS, so caching makes things respond faster by avoiding the satellite uplink/downlink latency where possible.Yes.Do you have any recommendation for bandwidth managers? Thanks for taking the time to respond. It has been very interesting indeed.Well, aside from the (lack of sufficient) support, I do have very good experience with ET. The device has really great price/performance characteristics, when pitched up against the 3 other big names - Allot, Packeteer and Xedia. Overall, you can easily have 20 times more throughput on an ET that costs up to 4x less than the other vendors. It runs a proprietary bandwidth management program on (a tuned) FreeBSD or Linux (prefer to boot FreeBSD), and will push 100BaseT as well as Gig-E. If you let me know what your requirements are, I could give you a specific box to look at, and you can take it from there. Mark.-- G. _______________________________________________ LUG mailing list [email protected] http://kym.net/mailman/listinfo/lug %LUG is generously hosted by INFOCOM http://www.infocom.co.ug/_______________________________________________ LUG mailing list [email protected] http://kym.net/mailman/listinfo/lug %LUG is generously hosted by INFOCOM http://www.infocom.co.ug/
-- *************************************************************************** / ''We can't become what we need to be by remaining what we are''\ \ ,, ,,/ ***************************************************************************
_______________________________________________ LUG mailing list [email protected] http://kym.net/mailman/listinfo/lug %LUG is generously hosted by INFOCOM http://www.infocom.co.ug/
