Port trunking / link aggregation problem

What protocol are they using?

This is done so that packets from a single flow don't get reordered. This can happen when links are of unequal length, or packets within a given flow are of different size (e.g. a max sized frame which gets put on one link followed by several min-sized frames on the other links; the min-sized frames would be received before the max-sized frame). Reordering can cause problems with some protocols, and with TCP, it could potentially lead to retransmissions resulting in loss of performance.

As a result typical switches allow you to do load balancing based on one or more of the following criteria:

- The source/destination MAC addresses.

- The source/destination IP addresses (if the packet is IP).

- The source/destination transport port (if the packet is TCP or UDP).

That's correct.

Cheap switches typically won't look deep enough in the packets. But regardless, if you have only two machines talking to each other with one active flow between them (defined by a combination of the 3 criteria mentioned above), then it would be hard to find a switch that will be able to load balance the traffic. You would have to find a switch that does some form of proprietary load balancing. I'm not aware of any.

On the other hand, if the two machines are talking over several flows, i.e. different transport ports, then you might want to look for a switch that can load balance traffic based on the source and destination ports in addition to the IP addresses. With that you would get some amount of load balancing although it would be far from perfect.

Anoop

Definetely the most important case is a Windows workstation accessing Samba file shares on a Linux server. So, standard Windows file sharing with workgroups (no NT domain controller).

So, the minimum requirement would be to find switches that can spread packets sent from different transport ports from the same IP / MAC address to different links within a trunk?

Any suggestions about lower-end switches (manufactures, product families) that are capable to do this?

Regards, Timo

I don't know enough about how this protocol works, but my guess is that if it is running over IP, a client/server communication would happen over a single source/destination TCP port pair.

Yes, that was the suggestion assuming you had multiple flows, but I really doubt that that is true in your situation. Because of issues with reordering, the load distribution algorithms work well only when you have a fairly large number of flows.

Alas, I don't know of any low-end products that do this.

Anoop

this implies your G.SHDSL interface has an Ethernet interface and acts as an Ethernet bridge?

since an Ethernet device is blind to the higher level protocols - this is basically all it can do.

Part of the "assumption set" within Ethernet is that the network doesnt play around with the order of packets.

Yes

No

Maybe you should look at kit designed to aggregate SDSL lines at the bit level - i have seen adverts for DSLAM like devices that can do this (but never seen them used).

The other alternative i suggest is to move to IP routing.

If you use a router that supports multiple G.SHDSL interfaces, then you may be able to use layer 3 load balancing across multiple pipes. Or possibly use MLPPP to "dice" packets and send the fragments in parallel over multiple links (although this is going to be CPU intensive, and you need to test it rather than assuming it will work).

i dont know of any cheap routers that can do that (although there must be some out there), but the Cisco 2811s and higher models can support 4 * SHDSL interfaces, and the other options to potentially give you 4 lines in parallel.

And this isnt going to be cheap even if you get a good discount - $2.5k list for a 2811, and $950 for each SDSL interface.....

definitely time to look at proper surge arrestors.

Or - throw this idea in the bin and pay for fibre (either a rented pipe or dark fibres) - that should give 100 or 1000 Mbps on 1 link......

And I'd wonder if the request/response nature of the protocol is able to keep the existing pipe full to begin with? Are there enough outstanding requests at at time to fill the exsiting pipe?

rick jones

As stated multilink PPP is the way that this is usually done.

There may be other kit available have a look for sdsl Inverse Multiplexer (multiplexor too) will still cost though.

Timo, Have you looked at loop bonding or phy aggregation technology instead. For example:

Arthur.