tkaczma@gryf.net wrote:
On Wed, 12 Jan 2000, Eyal Traitel wrote:
Can you specify more on your MAC address trick ?
I think what he means is that he has all the addresses nicely distributed over the number of trunking interfaces he has on the filer. I assume that by "dumb" he means MAC hashing, a method of distributing load among ethernet interfaces based on the ethernet address. Usually x last bits are used where 2^x ~= number of interfaces in the trunk. I haven't found (not that I looked very hard) documentation on what happens in this scenario if one of the trunk links dies. If someone can point me to that excerp of the standard/documentation I'd appreciate it.
Correct. I have two interfaces per trunk. I have two trunks per filer quad card. I have one quad card per filer. The Cisco 5505 (Ethernet in this case, not ATM) supports a maximum of four interfaces per trunk. If an interface in a two-interface trunk dies, all traffic re-routes to the remaining interface. The algorithm in the 5505 XORs the last two bits of the sending and receiving MAC addresses to determine the port number. With a large number of clients, this tends to even out. With only four clients, I had to make a truth table of desired results, then change client MAC addresses to achieve the result.
Please read on as I've missed Michael's response quoted below.
"Michael S. Keller" wrote:
There's not much to check. It goes in one switch port and out another on the same switch. The interfaces show no errors.
I haven't found anyone yet that has convinced me that duplex negotiation works. I've seen it NOT work too many times and when it doesn't the performance turns worse and worse as congestion increases. I'd hard set the switch and the boxes (including the netapp) to full-duplex if in fact that is what your boxes support.
Duplex is forced full at the switch and at the clients. I fixed that months ago. netstat shows no collisions at the clients or at the filers.
Make sure it isn't your clients that are having problems with large packets as well as the switch. There are certain options in ATM switches, if I'm recalling correctly, that will effectively reduce your maximum ethernet frame size. That could also put a damper on large packets as they use several maximum sized frames.
I'm not saying that it isn't a problems with NACs, but my experience tells me to look into the networking before jumping to any conclusions. My networking group swore that our performance problems were due to NACs. In fact they were so entrenched in their ideas that they didn't believe me that NACs purposely "ignored" ICMP packets under some conditions. It turned out that we had a case of duplex mismatch between the NACs and the switches. The NAC was happily chuging at full-duplex which it autonegotiated and the switch decided that half-duplex was good enough for some of the interfaces. Also, check the ethernet card on the NAC, I already replaced two of them - well, we have about 20 NACs, but nevertheless I didn't expect it. See what kind of performance you're getting with just one interface enabled at a time and then rotate through the interfaces.
I may try that, but not immediately.