A Journey in Aggregation
15 · APR ·2010
As Network Manager at Fluidata, I’m often pulled into sales calls to provide technical consultation on the various products and services somebody may be considering purchasing from us. These calls can be quite eye opening, and in particular have given me an understanding of the reputation of certain services in the market place. One such thing I’ve learnt from this, is that that bonded services (despite being around for many years), are still viewed with a large amount of scepticism by IT managers, and are generally considered less reliable than single line services.
The reputation of bonded services is probably not helped by the presence of load balanced solutions on the market place. Load balancing is a canny way of improving bandwidth at a relatively low cost, but its various limitations can tarnish ‘true’ bonding by association.
The fundamental problem with load balanced solutions is they can only ever have control of one end of a connection. This limits the solutions to combining only upstream bandwidth, but in a way that makes them look like data is coming from two separate subnets. Utilising extra bandwidth from load balanced solutions then becomes very tricky, and because traffic is arriving from different public IP addresses, with each line potentially having a different latency - it’s even more difficult to create a single stream of data.
With true bonding however, a connection should to all intents and purposes should act as one fat pipe. This is achieved either via protocols such MLPPP or by using extra hardware. The inherent issues with load balancing are overcome, but unfortunately a side effect of either method is the reduction of the solutions maximum transition unit.
For some businesses a reduction in MTU might be nothing to get too concerned over, but if for instance you were running business critical applications (such as SQL replication) over these links, then you could start to experience some strange errors.
This is because these applications are quite often programmed to expect a full 1500 byte MTU to perform with, and it can be quite difficult to change this, giving rise to performance issues such as failed backups or slow replication rates.
Early Fluidata bonded solutions, despite having the advantage of bonding over different networks and technologies, had this limit on MTU, dragging connections down as low as 1300 bytes.
Since then, however, with the help of large amounts R&D, we’ve discovered subtle ways and means of overcoming this inherent drawback.
We can proudly say now, that with our fourth generation PureFluids we can offer a service with a full 1500 byte MTU; that detects dropped lines and recovers from these in less than 5 seconds, while also automatically alerting our engineers to line issues. There is now no need for a separate aggregation server either, this is all now done in a 1U Cisco chassis, providing the customer with a resilient connection that doesn’t use up all of their rack space.
The solution has been tested with VPNs, VoIP calls, Video Conferencing, general web traffic and all continue to operate perfectly in the event of a line failing.