In article , wrote: :I manage a small network (75 desktops, 4 servers) with a single HP :Procurve 4000m switch which has one 1-port gigabit module and the other :7 modules having ten 10/100 ports. I've got two HP Proliant DL servers :with dual gigabit NICS. Obvioulsy, with only one gigabit port, I can :only hook one of the NICS on one of the servers to it. What I'm :thinking of doing is purchasing a separate smaller Linksys 16 port :gigabit switch (under $400) so I can team the dual NICS on both of the :proliant servers to get 2GB on each. FWIW, the two servers are a :terminal server which hosts about 15-20 users (currently dual NIC'd at :200 Mbps), and our main database/file/print server (only one NIC at :1GBps) which sees some pretty heavy use. Both are win2k.
I'd think it likely that that plan is headed for trouble.
:My questions, therefore, are:
:1) I'm guessing I can plug the Linksys into the Procurve through the :gigabit port, correct? Should I be using a CAT 6 cable for this or :will CAT 5e do?
Cat5e will do, at least for moderate distances.
:2) Since the Linksys is a managed switch
Could you check that again? Last time I checked about 3 months ago, the least expensive *managed* gigabit switch I could find was about $1000. The $400 Linksys switches were NOT managed at the time.
:I could configure Port :trunking. Is this something that should always be done when setting up :dual NICS (primary goal is load balancing with lesser emphasis on fault :tolerance)?
Port trunking? As in putting in multiple 802.1Q VLANs? That's not going to help fault tolerance: if your fault tolerance is MAC based then the MAC in the other VLAN would not be visible; if your fault tolerance is IP based then the two ports would have to be in different subnets in order to be able to select the proper port during normal operations.
: I tried port trunking when configuring dual 100 NICS on :the terminal server, but saw no readily apparent benefit.
Do you perhaps mean port aggregation?
Port aggregation depends on the algorithm being used to distribute the packets between the available links. I don't recall which algorithms the Procurves have available. Often the algorithms are based upon taking the last N bits (2^N >= number of aggregated ports) of the source or destination and using that as the link index; sometimes the source and destination bits are xor'd. Unless you have configured per-packet load balancing on your aggregation ports (I -seem- to recall seeing that the Procurve could do that), the result is that any one source + destination MAC pair will always use the same link. Aggregating N ports does not get you N times the bandwidth (unless per-packet): instead it gives you opportunities to parallelize up to N different streams. Like a multilane highway: your car can't drive at 180 miles per hour just because there are three lanes, but 3 cars can independantly drive at 60 miles per hour on the three lanes.
:3) Will this scenario actually give me noticeable improvements? I :don't want to invest even a little bit of money if improvements are :minimal.
If you are expecting heavy traffic over the gigabit ports, then chances are that you will be disappointed with the $400 Linksys. On the consumer gigabit devices, the aggregate throughput supported is usually fairly low. Many of the consumer gigabit devices use the same chipset, so you pretty much have to take a jump in price class in order to get serious simultaneous bandwidth. Something like a Cisco Cat2960 perhaps; I imagine others will pitch in with other reliable high-throughput devices. [Note: there have been some reports of bad experiences with Netgear's line of managed gigabit switches, which look nice on paper...]