I think I'd look at a sniffer as a quick check of what's happening--especially if you can catch it just before the freeze. One problem with device compatibility is matching up the exact models in use -- which 3COM NICs, and which switch. I don't know a source of compatiblity info off the top of my head, though vendor forums sometimes get into that sort of thing. Your Cisco source (do you have a VAR you purchase from, or a Rep you work with?) might have some data.
As I look back at your original post, you have the NetGear with flow control and a D-Link without, but in one of your replies you said this network has 7 clients and one server. Is there a way to operate it without the D-Link? The data sheet on the NetGear says it has 8 ports... would that leave you without an uplink to the outside? Or even (as an ugly test) two workstations on a hub to one port, just to take the D-Link out and not have a multi-vendor situation? I'm not sure, in this size network, that you would really lose any noticeable performance if you didn't have flow control, unless the docs/spreadsheets/access DB were really large files coming across the network. Ideas, Priscilla?? Annlee [EMAIL PROTECTED] wrote: > Thank you Annlee, this is enlightening. > > My users mainly use word/excel documents along with a small access database. > > I know that sounds awful but what performance gain I will loose by using a > "cheap" switch that does not do flow control? > > If I where able to convince my client and we used a Cisco switch, how could > I verify that the 3COM cards are compatible with the Cisco gears? > > Would you use a sniffer and analyze the traffic or is there a simpler way? > > Thanks, > > Pierre-Alex > > > ----- Original Message ----- > From: "Annlee" > To: > Cc: > Sent: Friday, August 29, 2003 10:09 PM > Subject: Re: 802.3x switch traffic disruption [7:74455] > > > >>A Google search on "802.3x" yields a lot of discussion of flow control >>issues people seem to have -- linux as well as windows clients. One >>item I found at the IEEE's web page was this: >>http://grouper.ieee.org/groups/802/3/efm/public/email/msg02446.html >> >>/quote >>In working with Ethernet for over 20 years, the one functionality that is >>most severely vendor dependant is 802.3x "Flow Control". Perhaps it is >>partly the politics of the 802.3WG. Perhaps the politics of IETF pushing >>their flow and rate adaptation to the exclusion of other layer or >>types is >>partly to blame. In some cases it marketing decisions on the part of >>vendors that cause them to improperly implement 802.3x in their >>interfaces >>and systems. For those vendors that are purely Ethernet and expect >>themselves to do things right, 802.3x Flow Control works to a level and >>quality that is at first surprising to their customers. If you want more >>information about my experiences with vendors and their >>implementations of >>802.3x, continue to read. >> >>...and it goes on, at some length. >> >>FWIW >> >>Annlee >> >>[EMAIL PROTECTED] wrote: >> >>>No, I don't think I have a design issue: the network has 7 clients and 1 >>>server so the architecture is very simple. My client was complaining of > > slow > >>>speed when opening files. My approach was to optimize at every layer >>>possible. Choosing 802.3x feature was just one thing among others I did > > to > >>>speed up file access. >>> >>>1) I moved them from a bus architecture, to a switched architecture, >>>replacing all the coax cabling with twisted pair. >>>2) When I replaced the NICs I went for NIC that could do flow control > > and > >>>chose a "brand name" switch that supported the same feature. (Yes I > > should > >>>have chosen Cisco for the Switch, but how do you convince you client to > > pay > >>>"more" for something that appears to do the same thing?). >>>3) I replaced the OS on the clients (Windows Millennium) with Windows > > XP > >>>professional. Optimized the page file (and removed it from the > > system/boot > >>>partition). Disabled unnecessary services. >>>4) On the server side, I used SCSI hard disks and the fastest SCSI >>>controller I could find on the market. Optimized the server to death. >>>5) I did not mess-up with modifying TCP Window parameters because I > > thought > >>>that was not necessary. >>> >>>The speed increase is visible, but with the network freezing up twice > > this > >>>week, all my work has taken a serious credibility hit. I have replaced > > their > >>>Switch with one of my personal Cisco switches after the second > > incident. My > >>>plan is to leave the switch ( a Cisco 2924XL) there for a week or two so > > I > >>>can monitor network activity and gather statistics . Then I don't > > know... > >>>The switch belongs to my CCIE rack so I will either have to sell it to > > them > >>>or buy them another inexpensive switch. :>) >>> >>> >>> >>> >>> >>>----- Original Message ----- >>>From: "annlee" >>>To: >>>Sent: Friday, August 29, 2003 7:24 PM >>>Subject: Re: 802.3x switch traffic disruption [7:74455] >>> >>> >>> >>> >>>>Netgear does have its problems... >>>>http://www.dslreports.com/shownews/31774?mode=flat >>>> >>>>That said, all the inexpensive devices have problems of one sort or >>>>another. I think it's a case of getting what you paid for / caveat >>>>emptor. For small networks clients, I always try to get them to buy >>>>one step higher quality than they wanted to pay for (since if they >>>>understood the ramifications, they wouldn't need me). It rarely works >>>>though ... which does tend to lead to repeat business... >>>> >>>>Annlee >>>> >>>>Priscilla Oppenheimer wrote: >>>> >>>> >>>> >>>>>It sounds like the Netgear Layer 2 802.3 flow control is buggy. It >>> >>>sounds >>> >>> >>>>>like you can't turn it off, though, because it's not a managed switch. >>>>>Should have bought Cisco!? :-) >>>>> >>>>>You can turn it off on the workstations, though, and I would somewhat >>>>>hesitantly recomment that. You might risk other problems by disabling >>> >>>it. >>> >>> >>>>>Flow control should be negotiated with autonegotiation, but we know how >>>> >>>>well >>>> >>>> >>>>>that works for duplex mode. Nontheless, if it were me, I think I would >>> >>>turn >>> >>> >>>>>it off on the workstations carefully, as a test to start with. >>>>> >>>>>I'd be interested in other people's opinions, but I think flow control >>> >>>at >>> >>> >>>>>the data-link-layer is risky and unnecessary anyway. >>>>> >>>>>No offence to Netgear (really!) but I'm not sure I would trust them to >>> >>>do >>> >>> >>>>it >>>> >>>> >>>>>right, especially on a low-end switch. So, let's say a switch port has >>> >>>been >>> >>> >>>>>flow controlled and told not to send any packets for a while. What does >>> >>>it >>> >>> >>>>>do with the packets? How much buffering can it support? Does it have >>>>>features to avoid head-of-the-line blocking? Will the flow control on >>> >>>that >>> >>> >>>>>interface cause problems for other interfaces? >>>>> >>>>>TCP already does end-to-end flow control. Of course, not every >>> >>>application >>> >>> >>>>>uses TCP, but a lot do. I think that's a better way to handle it. >>>>> >>>>>And one final comment, if you really need to be flow controlling >>> >>>traffic, >>> >>> >>>>>perhaps you should just upgrade the bandwidth? Ethernet flow control >>> >>>sounds >>> >>> >>>>>like a bandaid over a design problem to me.... >>>>> >>>>>What do others think? Do you use 802.3x flow control? Thanks. >>>>> >>>>>Priscilla >>>>> >>>>> >>>>> >>>>>[EMAIL PROTECTED] wrote: >>>>> >>>>> >>>>> >>>>>>I need some expert option on the following matter: >>>>>> >>>>>>I have a Netgear Fast Ethernet Switch FS608 (which does 802.3x >>>>>>Flow >>>>>>control) connected to a DLink 5 port switch (no flow control) >>>>>> >>>>>>Twice this week, the FS608 locked itself causing ALL traffic in >>>>>>the company >>>>>>to be disrupted. The problem was solved by power cycling the >>>>>>switch. >>>>>> >>>>>>All the clients on the FS608 have 3Com network cards that >>>>>>support flow >>>>>>control. >>>>>> >>>>>>Here are my questions: >>>>>> >>>>>>1) Are there some caviat in running 802.3x I am not aware of? >>>>>>I did >>>>>>extensive research before implementing this and did not find >>>>>>any issues with >>>>>>the implementation of the technology? >>>>>> >>>>>>2) Is there an issue of running 802.3x on one switch and not on >>>>>>the other? >>>>>> >>>>>>3) I could turn off the 802.3x feature on all the workstations >>>>>>but I can't >>>>>>turn it off on the FS608. This is NOT a managed switch. Any >>>>>>suggestion on >>>>>>how to troubleshoot this problem? >>>>>> >>>>>>Thank you, >>>>>> >>>>>>Pierre-Alex >>>>> >>>>>**Please support GroupStudy by purchasing from the GroupStudy Store: >>>>>http://shop.groupstudy.com >>>>>FAQ, list archives, and subscription info: >>>> >>>>http://www.groupstudy.com/list/cisco.html >>>>**Please support GroupStudy by purchasing from the GroupStudy Store: >>>>http://shop.groupstudy.com >>>>FAQ, list archives, and subscription info: >>> >>>http://www.groupstudy.com/list/cisco.html Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=74529&t=74455 -------------------------------------------------- **Please support GroupStudy by purchasing from the GroupStudy Store: http://shop.groupstudy.com FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
