Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 300
  • Last Modified:



I'm currently bench testing 2 alcatel 7800 switches. I am testing Link aggregation between the 2 using 2 Gigabit Firbe conections, and 2 X 100MB Ethernet Cable conections.

that gives 4 conections aggregated to give (i think) 2 Gigabit + 200 Mbit links.  (around 2.2 gig of bandwidth??)

i thought id test this out so i pinged the second switch from a laptop conected to the first switch.

i entered ping -l 65500 -t

65500 bytes is the MAX amount of bytes i can ping.
i just used start/run/ and opened it approx 20 times, giving me a lot of Pings going over this Aggregated link i created.

i would assume that bandwidth of 2.2 gigabit would be sufficient for these pings to go through without any trouble. i used an online calculator and in megabytes 65500  = 0.06247 MB. i  know its not accurate but i then used the windows calculator  X 20 and got 1.2494MB, so just over 1 MB. (is this correct?)

i would assume that i would have no problems with there being such high bandwidth, but a lot of the pings in many of the windows were timming out, giving very slow response times of 100 MS.

can anyone explain this to me?
I'm sure what i've written might not be totally clear so if you need me to explain something then just ask.

I'd like to know why these small pints were timing out over such Large Bandwidth??
  • 2
1 Solution
Three things:

1.) Most of the link aggregation I've seen (on Cisco and Nortel) the links have to be the same - they have to be ALL fiber GigE, or ALL Copper 100Mb.  Unless Alcatel is doing something these guys can't, then you might be having an issue adding 100Mb copper to 1Gb Fiber link aggregators.

2.)  Usually, when links are aggregated they use a statistical load balancing based on a hashing algorithm that picks a port to transmit based on either destination IP or destination MAC.  Therefore, when there are many connections, they are statistically load balanced (although it is certainly possible to have more over one than the other - just depends on an average).  However, going from point A to point B, since the destinations are always the same, the algorithm always picks the same transmit port.  Therefore, you don't really have the full link aggregated bandwidth between points A and B, you just have the bandwidth of one of those connections, and the assurance that if one fails, there's others there to pick up the slack.

3.)  When you ping with exceptionally large packets, all those packets are fragmented and put in a transmit queue.  They still go out one at a time.  It's not like you're pushing them all out the door at once.  Then they have to be reassembled on the other side.  The fragmentation and reassembly takes time.  Time seems like latency which seems like less bandwidth than you expect.

I would recommend a better tester - Solar Winds Engineering Toolset has a cool one called WAN killer.  You'd need to run several of these and use your forwarding tables to figure out which link is being utilized.  You can get an eval at:  http://www.solarwinds.net/Tools/Miscellaneous/WAN%20Killer/index.htm

Hope this helps.

bluebirds1984Author Commented:
yeah that helped a lot, thanks for that!

ill see if i can use this app to test the link agg.

You're welcome! :)

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now