One the best documentation jobs I've seen of the amount of traffic generated by systems doing basic housekeeping functions and actual user and application functions was from MS Press - the title is "Notes From the Field: Network Traffic Optimization" or something along those lines. While it only deals with Windows servers and clients (NT4 server is the most used, but there is some info on 2k), it is a great reference for this kind of info. Well worth the admission price, especially if you have to deal with any Windows machine on a network.
Andras -----Original Message----- From: Chuck Larrieu [mailto:[EMAIL PROTECTED]] Sent: Friday, October 12, 2001 7:45 AM To: [EMAIL PROTECTED] Subject: RE: File servers [7:22665] PO said: how much bandwidth does it really take to log in? Interesting question, to be looked at in a number of ways. These days I mostly telecommute. A couple of months ago all of a sudden, I found that if I dialed in before 7:45 a.m. or after 9:00 a.m. things were fine. But during that hour and a quarter period it might take as long as 30 minutes of constant redials to get into the network. The usual error message was 718 - timed out waiting for a response from the server. I was authenticated to the dial in servers, but could not get any further. Of course I was all over the Help Desk, who finally just to get rid of me admitted that ( according to them ) the server admins had made some changes to the scripts and processes that resulted in each dial-in user generating well over two dozen server requests. In effect, the company created it's own DDoS against the login servers. As there are a LOT of telecommuters and roaming users in my company, this apparently adds up. We dial into Cisco access routers. I don't know the authentication server, but we subsequently attach to one or more NT servers, including Exchange. I know that the Exchange portion of the login script seems to drag forever - probably 45 seconds to a minute. Even when I'm in the office, at 100 mbs full duplex, the login process seems to take longer than one might think. I'm guessing that a good part of the problem is the login script, the attachment process to the various NT servers, and the NT laptops most people in my part of the company use. In a former life, I worked in a company that used a particular server based application that according to the folks who did my net baseline ( using Sniffer, of course ) was generating something like 27 conversations during the application authentication process - something that contributed greatly to WAN clogging. I guess lots of little packets, even during the login process, can cause problems. Chuck -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Priscilla Oppenheimer Sent: Friday, October 12, 2001 6:48 AM To: [EMAIL PROTECTED] Subject: RE: File servers [7:22665] Leigh Anne, You certainly bring up some good points that people tend to forget about, but the true answer, as usual, is "it depends." It think it's unlikely that the clients are stuffing 6400 Mbps on the uplink. First of all, they are only sending in one direction. If they were all using all of their send capacity, it would be 3200, which is still a lot more than the send capacity of the uplink port (100 Mbps), granted. However, how much bandwidth does it really take to log in? I studied this and documented it in the Designing Cisco Networks course and in Top-Down Network Design. This was a while ago, but things haven't changed that much. They send lots of packets, but they don't send them that fast usually. Of course, PCs are a lot faster these days, but I bet their speed doesn't help much with network applications. He didn't say if the applications are on the server and being downloaded from the server, or possibly even run from the server, which does increase the amount of traffic, but it's still not going to add up to 3200 Mbps I bet. He needs to study the traffic. That's the bottom line. He did take the first step, and the uplink is not overloaded according to this: reliability 255/255, txload 5/255, rxload 26/255 Output queue 0/40, 0 drops; input queue 0/75, 0 drops etc. Gotta run. I could say more, but my husband made dinner! I can't be late for that! ;-) Priscilla At 09:42 PM 10/11/01, Leigh Anne Chisholm wrote: >Patrick, > >The original poster didn't say that it's just one or two apps that he's >having problems with--but rather than it's everything on one or two >application servers. Application servers are typically highly utilized and >see lots of traffic from end users. They easily push large amounts of data >down to client workstations because you're not talking about simple end-user >data but rather applications. > >Giving end-users the ability to run at full-duplex 100 Mbps on a 32 port >switch with uplinks to the server also only being able to accommodate 100 >Mbps full-duplex is by design, silly in my experience. At peak times such >as the early morning when everyone is logging on and accessing what they >need to start the day, in such an environment you're likely to easily >overwhelm the uplink to the server because there are potentially 31 other >ports trying to stuff an aggregated 6400 Mbps through a 200 Mbps pipe. Now >in reality, that's not going to happen. Upload and download traffic aren't >equal but the cause and effect are the same. I've been there--I've >experienced this exact network design and it wasn't pretty. It took >end-users 3 hours to log onto the NetWare server, and things continually >crawled all day until we realized what the consultant had done. Having >brought each client down to 10 Mbps half duplex substantially improved >network performance. > >If you also look at the statistics provided by the original poster, you'd >notice that there's nothing on that particular port that identifies other >possible causes for the network to be slow. Typically, end users won't >complain about a network being slow unless they've experienced better >performance previously. The question I asked before posting, is what could >cause this network to slow down? Collisions? No. Problems with frames? >No. The servers unable to handle the load? Possibly... but multiple >servers at once? Unlikely. And even if it's proved that today the uplinks >are able to handle the traffic demand, end-users will demand more and more >bandwidth placing more and more strain on the uplink. Eventually that >uplink will crumble and require upgrading. > >I treat switching much like designing a sewer system. Most of the time >things operate fine in a design such as the original poster's, but expect >floods. And those floods are common in the morning, and after lunch. Some >days are better than others. Designing a system that's able to handle the >traffic flow consistently is the optimal goal. > > > > -----Original Message----- > > From: Patrick Ramsey [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, October 11, 2001 9:42 AM > > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > > Subject: RE: File servers [7:22665] > > > > > > Leigh Anne, > > > > logically, I see your point 100% and used to subscribe to this > > theory as well. BUT This type of solution should only be put in > > place after MUCH testing has been done. There are so many more > > things to look at than just the one or two apps running slowly. > > Taking each client down to 10half doesn't just slow down activity > > to the server but depending on how well the original segment was > > designed could cause a TON of collisions and slow downs. > > Also...how much activity does each client throw to the server? > > If each client sends bursts of say 20-30mb(most apps wouldn't > > know how to push30mb! :) ), is that really taxing the server? > > It's hard to believe that even at 30mb, that each client is > > pushing that much data at the same time...If it's data entry, > > chances are that each client is standing still for periods and > > pushing very little data at any given time. ( I would estimate > > less less than 2mb) > > > > BUT, in the grand scheme of things, what about shares to other > > servers and other workstations? Copying 10gig databases across > > the wire at 10half compared to 100full is a really big deal. And > > printing... Sending a print job to 100mb print server is > > tremendously more speedy than 10half. > > > > I truely think the logic you mention is good logic but should be > > used on a case by case basis after much research. And on a side > > note, I usually subscribe to the 8/1 theory. For every 8mb you > > think you need, purchase 1mb...this is the same for LAN segments > > as well as WAN segments. It's kept me out of trouble up to this > > point.. :) > > > > Couple'a more of my $.02 > > > > -Patrick > > > > >>> "Leigh Anne Chisholm" 10/10/01 05:01PM >>> > > Other than upgrading your uplinks to Gigabit Ethernet to accommodate the > > aggregation of inbound bandwidth, it's the only other solution. > > By limiting > > the amount of traffic contending for your links to the servers at > > the client > > end, you'll see less retransmissions. Less retransmissions, less traffic. > > Less traffic, better performance. > > > > It's quite erroneous to think lowering bandwidth and duplex will decrease > > your performance... > > > > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of > > > khramov > > > Sent: Wednesday, October 10, 2001 2:46 PM > > > To: [EMAIL PROTECTED] > > > Subject: Re: File servers [7:22665] > > > > > > > > > I am running full duplex on all devices. One of the filers is > > > connected to > > > my core > > > switches and the other one to a access layer switch and I am same > > > experiencing problems > > > on both devices. If I lower the speed on the filers or switch. > > I do not > > > think that it > > > is going to solve the problem. It might create another one - > > > unhappy users. > > > > > > > > > Leigh Anne Chisholm wrote: > > > > > > > You need to decrease the speed at which your clients connect to > > > the switch. > > > > > > > > Try this experiment. Take 20 1" in diameter 5" long tubes, tie them > > > > together. Take another 1" tube, put a funnel into the end. > > > Now pour water > > > > into the 10 1" tubes. The water runs through the 20 tubes > > fine but the > > > > aggregation tube with the funnel overflows because it's not > > > wide enough to > > > > handle the load. If sewer systems were designed this way, > > you'd have a > > > > flood when it poured. > > > > > > > > Essentially, you're flooding your network. You're giving your > > > clients way > > > > too much bandwidth initially and forcing each to share a > > small uplink to > > > the > > > > server. Instead, try setting each client to 10 Mbps half > > duplex. Even > > > > though your speed is less, you'll likely notice a performance > > > improvement. > > > > Once you've established that that works fine, bump people from > > > half to full > > > > duplex. If network connectivity decreases, go back to half duplex. > > > > > > > > Don't overload your uplinks... > > > > > > > > -- Leigh Anne > > > > > > > > -----Original Message----- > > > > From: khramov [mailto:[EMAIL PROTECTED]] > > > > Sent: Wednesday, October 10, 2001 2:26 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: Re: File servers [7:22665] > > > > > > > > 100 Mb , full duplex > > > > Leigh Anne Chisholm wrote: > > > > What are the client systems set to for speed and duplex? > > > > > -----Original Message----- > > > > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of > > > > > khramov > > > > > Sent: Wednesday, October 10, 2001 2:00 PM > > > > > To: [EMAIL PROTECTED] > > > > > Subject: Re: File servers [7:22665] > > > > > > > > > > > > > > > I do not really see any retransmission it is mostly timeouts. > > > And I get > > > a > > > > > time out on > > > > > every 11th or 12th packet so I can see a pattern in there. So I > > > > > think that > > > > > points to a > > > > > config problem either with a switch or a filer.. > > > > > 1. Both switch and filer run at 100 Mb Full duplex > > > > > 2. I am using default forwarding on the switch, I belive it is > > > > > cut through > > > > > > > > > > here is output from sh int: > > > > > FastEthernet0/32 is up, line protocol is up > > > > > Hardware is Fast Ethernet, address is 0005.dd42.fba0 (bia > > > > > 0005.dd42.fba0) > > > > > MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, > > > > > reliability 255/255, txload 5/255, rxload 26/255 > > > > > Encapsulation ARPA, loopback not set > > > > > Keepalive not set > > > > > Full-duplex, 100Mb/s, 100BaseTX/FX > > > > > ARP type: ARPA, ARP Timeout 04:00:00 > > > > > Last input never, output 00:00:00, output hang never > > > > > Last clearing of "show interface" counters 21:52:27 > > > > > Queueing strategy: fifo > > > > > Output queue 0/40, 0 drops; input queue 0/75, 0 drops > > > > > 5 minute input rate 10415000 bits/sec, 1458 packets/sec > > > > > 5 minute output rate 2276000 bits/sec, 1243 packets/sec > > > > > 111402006 packets input, 1918210356 bytes > > > > > Received 19795 broadcasts, 0 runts, 0 giants, 0 throttles > > > > > 3 input errors, 3 CRC, 0 frame, 0 overrun, 0 ignored > > > > > 0 watchdog, 0 multicast > > > > > 0 input packets with dribble condition detected > > > > > 94788383 packets output, 2865242584 bytes, 0 underruns > > > > > 0 output errors, 0 collisions, 0 interface resets > > > > > 0 babbles, 0 late collision, 0 deferred > > > > > 0 lost carrier, 0 no carrier > > > > > 0 output buffer failures, 0 output buffers swapped out > > > > > > > > > > Leigh Anne Chisholm wrote: > > > > > > > > > > > What is the speed of your uplink ports? What is the speed of the > > > > > connection > > > > > > to the servers? Is it possible you're creating a bottleneck by > > > allowing > > > > > too > > > > > > much traffic to be received by the switch that can't be > > > > > funneled to another > > > > > > switch or to the server? > > > > > > > > > > > > What type of forwarding are you using? Are you using > > > store-and-forward > > > > > > switching or cut-through? What does the traffic look like on the > > > > > > network--are you seeing a lot of retransmissions? > > > > > > > > > > > > Do you have any duplex mismatch issues where the host is > > > using a duplex > > > > > > different than the switch? > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf > > Of > > > > > > khramov > > > > > > Sent: Wednesday, October 10, 2001 11:49 AM > > > > > > To: [EMAIL PROTECTED] > > > > > > Subject: File servers [7:22665] > > > > > > > > > > > > > > > > > > I've a couple NetApps file servers that are directly connected to > > 3548 > > > > > > switch. Users have been complaining about slow access to the > > servers. > > > > > > I've done some extensive testing as far as the hardware side > > > > and media. > > > > > > One thing that I found that I believe identifies the problems > > > > is when I > > > > > > ping filer from the switch with 100 packets or more every 11th or > > 12th > > > > > > packet times out. To be more specific it does not actually times > > out > > > > > > but the response time jumps to 20 -30 ms. We've > > determined that by > > > > > > pinging filer from Linux workstation. Any ideas... > > > > > > > > > > > > Thanks, > > > > > > Alex > > > > > > > > > > > > [GroupStudy.com removed an attachment of type text/x-vcard which > > > > > > had a name > > > > > > of khramov.vcf] > > > > > > > > [GroupStudy.com removed an attachment of type text/x-vcard which > > > > had a name > > > > of khramov.vcf] > > > > [GroupStudy.com removed an attachment of type text/x-vcard which > > had a name > > of khramov.vcf] ________________________ Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=24022&t=22665 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
