From: Peter van Oene (pvo@xxxxxxxxxxxx)
Date: Mon May 06 2002 - 21:21:44 GMT-3
Although I don't doubt the world could do with some automated collusion
detection schemes, I'm sure you meant to infer collision detection ;-)
In full duplex Ethernet, separate Tx and Rx paths are defined which thereby
create a collision free environment. Hence, collision detection becomes
irrelevant and actually impossible in these cases. Collisions in half
duplex are expected, though should not exceed 5-10% of total capacity in
healthy (highly subjective term) networks.
Pete
At 01:49 PM 5/6/2002 -0400, masaled wrote:
>Remember full-duplex disables collusion detection (CD)therefore you will see
>plenty of collusions. Collusion detection is available in half duplex mode
>and therefore you may see less or no collusions.
>
>Duncan
>
>-----Original Message-----
>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
>Scott Morris
>Sent: Monday, May 06, 2002 1:14 PM
>To: 'Leigh Anne Chisholm'; 'Church, Chuck'; 'Jeff Szeto';
>ccielab@groupstudy.com; 'Abraham, Ajith'
>Subject: RE: (Long) Network Slow
>
>
>On the switch-end (the full duplex side), you would not see any
>collisions. On the half-duplex end, you would.
>
>However, as someone else noted, there is typically a log message that
>pops up on the screen about duplex mismatch. Not sure why it's not on
>here, which is why I personally leaned toward the cabling.
>
>Scott
>
>-----Original Message-----
>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
>Leigh Anne Chisholm
>Sent: Monday, May 06, 2002 12:55 PM
>To: Church, Chuck; 'Jeff Szeto'; ccielab@groupstudy.com; Abraham, Ajith
>Subject: RE: (Long) Network Slow
>
>
>If it were a duplex mismatch, you should see the collision and late
>collision counters incrementing. This would be because full-duplex
>disables the carrier sense mechanism and may send data at the same time
>another station is sending data.
>
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
>
> > Church, Chuck
> > Sent: Monday, May 06, 2002 10:24 AM
> > To: 'Jeff Szeto'; 'ccielab@groupstudy.com'
> > Subject: RE: (Long) Network Slow
> >
> >
> > Jeff,
> >
> > Sounds like a duplex problem. Your switch is hard-coded to 100
>full.
> > Is your server? Check Monitor/LAN whether it's full or half. Try
> > setting the switch to auto/auto and see what the interface comes up
> > with. Otherwise try setting the switch to 100 half, and see if the
> > errors go away. Half duplex is much better than a mismatch.
> > Hard-coding both sides to 100 full should be the best combination.
> > Email me offline if you need some help configuring it on the NW side.
>
> > Hope this helps.
> >
> > Chuck Church
> > Sr. Network Engineer
> > CCIE #8776, MCNE, MCSE
> > US Tennis Association
> > 70 W. Red Oak Lane
> > White Plains, NY 10604
> > 914-696-7199
> >
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
>
> > Jeff Szeto
> > Sent: Monday, May 06, 2002 12:30 AM
> > To: ccielab@groupstudy.com
> > Subject: OT: (Long) Network Slow
> >
> >
> > Hi Group,
> >
> > Sorry for this OT thread, but I need help.
> >
> > My friend's network has a novell file server and an email server.
> > Users complain sometimes it takes a long time to open a file or an
> > email attachment. All the PCs and servers are connected via two 3500
> > switches which are interconnected via gigabit module.
> >
> > I check the switches and see the port that connecting to novell server
>
> > has many errors (see the show interface below), while the other ports
> > seems OK.
> >
> > FastEthernet0/35 is up, line protocol is up
> > Hardware is Fast Ethernet, address is 0008.a3d0.f863 (bia
>0008.a3d0.f863)
> > MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
> > reliability 255/255, txload 1/255, rxload 1/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 1d01h
> > Queueing strategy: fifo
> > Output queue 0/40, 0 drops; input queue 0/75, 0 drops
> > 5 minute input rate 225000 bits/sec, 64 packets/sec
> > 5 minute output rate 68000 bits/sec, 61 packets/sec
> > 4839382 packets input, 1992532408 bytes
> > Received 21073 broadcasts, 0 runts, 0 giants, 0 throttles
> > 24545 input errors, 24545 CRC, 0 frame, 302 overrun, 302 ignored
> > 0 watchdog, 236 multicast
> > 0 input packets with dribble condition detected
> > 7751432 packets output, 3144451132 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
> >
> >
> > I also use a sniffer to see what is happening. Although not much was
> > found, I list the major finding below. They appear from time to time
> > and my lead to the
> > problem.
> > There is no loop on the switches and users have the permissions for
>the
> > files.
> >
> > Source ---> Destination ----- Summary
> > PC Netware Loops on same request
> > Netware PC Request Denied
> > PC Email Ser Ack Too Long
> > PC Email Ser Window Frozen
> >
> > Any suggestions are welcome and appreciated.
> > Thank you in advance
> >
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:58:52 GMT-3