It sure sounds like your servers have enough power to handle 100 users (dual 1333 MHz processors). But if you are really concerned about performance, you'll want to do more investigation. The software could be slow. As I mentioned, with a sniffer you can often pinpoint the probable cause of slowness. Sometimes, it's a layer 8 problem (whiny users ;-)
I wanted to comment on this statement you made: "Sniffer always seems to get the frame type wrong. we're using 802.2 and it always says 802.3 frames!" A sniffer just tells you what it sees. Unless you're using some truly awful analyzer software (not Network Associates), it's not lying. You may want to verify the configuration of frame types on all servers, routers, clients. Maybe you're just misunderstanding what the sniffer is saying, though. A standard IEEE 802.3 frame has an 802.3 and 802.2 header. Network Associates calls this an 802.3 frame. (Look inside these packets to see if there's also an 802.2 header present.) Novell calls this an ETHERNET_802.2 frame. Cisco calls is a SAP frame. WildPackets EtherPeek calls is an IEEE 802.3 LSAP frame! Most of the world, though, just considered it an typical 802.3 frame. Be wary of Novell terminology. A Novell "raw" frame has just an IEEE 802.3 header, with no 802.2 header. Network Associates calls this a Novell Proprietary frame. Novell calls it a ETHERNET_802.3 frame. Cisco calls is a novell-ether frame. WildPackets calls is an IEEE 802.3 IPX frame! This frame type is only used on older Novell implementations and only Novell would call it an 802.3 frame. The rest of the world knows that IEEE requires an 802.2 header to follow an 802.3 header. Cisco has some pictures of frames here, if this has confused you. In this document they call the Novell raw format "802.3-Only Encapsulation." http://www.cisco.com/warp/public/105/encheat.html Priscilla At 03:47 PM 4/25/02, Luis Wiedemann wrote: >Every workstation is forced at 10/100/half, depending on the physical lines. >we have to force half duplex at the workstation and server because our >datacenter hosts our oracle DB for the teller and customer accounts, so we >need the error correction/detection with full duplex. our server is a compaq >proliant dual pIII 1333mhz with 3 10k 30 gig scsi running in raid 5. im not >entirely convinced that our server is getting hit too hard. it supports >about 100 users. it is however running NW 5.1, which i am not too largely a >fan of. i will run sniffer for a while and see what i get. im not tfamiliar >with packet sniffing. i can do it, im just not too sure what im looking at! >and sniffer always seems to get the frame type wrong. we're using 802.2 and >it always says 802.3 frames! anyway... thanks for any suggestions, i guess i >just wanted to make sure the switches were configured properly, but it seems >that compared to routers, they're pieces of cake when you're not even >worrying about vlans! > >Thanks again >Luis >""Priscilla Oppenheimer"" wrote in message >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > You did the most important thing, enabling portfast. That will speed up > > performance on startup. Also check for a duplex mismatch problem on every > > port. You may want to hard code everything as full duplex, (assuming the > > ports just connect a single device). Don't rely on auto-negotiation since > > it doesn't work a lot of the time. (On the other hand, there are cases > > where auto-negotiation works better than hard-coding, so do some testing > > first.) > > > > Keeping STP enabled shouldn't be a problem. It's the safest thing to do > > unless you are absolutely sure nobody is going to add any switches to the > > network in a redundant way. It's hard to ensure that. These days if you > > order a hub from some vendors, you get a switch anyway. End users could > > order a hub to add devices somewhere in the network and actually get a > > switch and possibly cause problems. > > > > STP won't affect the routers unless they are configured as bridges, which > > they probably aren't. > > > > STP does send BPDU packets every two seconds, which some people could > > consider a performance issue. These packets go to a multicast address. A > > good network interface card (in end devices or routers) will ignore those > > multicasts and not interrupt the CPU. Unfortunately, not all PC NICs are > > that good. > > > > Regarding testing the performance, do you have any before and after stats? > > How was the performance before you swapped out the hubs and put in > > switches? Maybe it was never so hot to start with. > > > > On the other hand, it is possible that the servers actually liked being in > > a shared Ethernet environment and are overwhelmed by a switched > > environment. In a shared environment, contention for the medium would slow > > down the requests to the server. Now the server may be getting requests > > much more quickly than before. What is the CPU on the servers? > > > > What protocols are you running? TCP/IP or IPX/NCP or NWLink (Novell's > > NetBIOS?) With TCP and NetBIOS you can often prove that the problem isn't > > with the network if you have a Sniffer. You can show that the server ACKs > > quickly but then takes a long time to process requests. If ACKs are >getting > > through quickly, then the network is OK. > > > > Priscilla > > > > At 11:57 AM 4/23/02, Luis Wiedemann wrote: > > >Well...the branches dont have more than 24 hosts, including the server. >all > > >branches with the exception of the main branch only consist of one novell > > >5.1 server, one 24 port wc-2950-24, and a 1720 router that connects the > > >branches to our main branch, which then go to the datacenter through a >2620. > > >we have nothing to do with the routers as the data center suppllies the > > >support and config for the routers. > > > > > >the main branch has 10 switches. mainly 2950-24's but we also have 2 > > >2950-48g's and a 3508 to connect a few switches via fiber gigbit. i did >port > > >fast all of the client ports on all of the switches. im also hearing bad > > >things about STP. A co-worker has been saying that in his experience with > > >intel? and hp? switches that STP was a horrible thing to have on. of >course > > >cisco says to keep it on. we dont have redundant links in our network so >how > > >important is it? our datacenter says that it may also be affecting the > > >routers? > > > > > >So far this group has been awesome with some very useful info. i hope one > > >day i can help as much as you guys/gals do! > > > > > > > > > > > >thanks again > > > > > >Luis > > > > > >""Luis Wiedemann"" wrote in message > > >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > > hey all, > > > > im new to the newsgroup, nad pretty new to real workd cisco. my > > experience > > > > comes mainly from reading cisco press and sybex books along with a few > > > > virtual labs. now im consulting for a small bank that just implemented >a > > > > swicthed network from thier old stacked hubs. everything is going OK >but > > i > > > > still feel that the network may be a bit laggy. not sure if its the > > >switches > > > > or what, so my real question is.... what are the first things you do >when > > > > confuring a new switch? I know I run the setup and configure IP, >Netmask > > , > > > > Default GW etc....we dont have any redundant links, so should i >disable > > >STP? > > > > how about port fast? its only one vlan, and we only have one swicth >per > > > > subnet, except for the main branch which has one switch per dept, but > > they > > > > all connect to the same server and there are no routers for internal > > > > traffic, only to connect to the branches via fractional t1's. so i >dont > > > > think vlans are an option here...anyway...you guys/gals know of any > > >special > > > > things i should be looking for? > > > > > > > > tia > > > > luis > > ________________________ > > > > Priscilla Oppenheimer > > http://www.priscilla.com ________________________ Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=42597&t=42276 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
