Anwender klagen über schlechte Verbindungsqualität

[jens.ebinger 10]

Hallo.

 

Anwender klagen über schlechte Verbindungsqualität, Netzwerktimeouts, Outlook bockig etc.

 

Wir haben Cisco-Switche, aber ich kenn mich nicht aus.

 

Mit Alcatel und 3com kenn ich mich ein wenig aus, aber mit Cisco :-(

 

Was kann ich wie checken?

 

Ciao.

[Wordo 11]

Tausch den Switch, ansonsten wuerd ich den Fehler woanders suchen (z.B. beim Anwender)

[jens.ebinger 10]

Tausch den Switch

Die Altbau-Switche sind inzwischen im M-Bau, und die M-Bau-Switche im Neubau ... "lustige" Reise nach Jerusalem hat schon stattgefunden. :shock: :mad: :rolleyes:

[SecurityMaker 10]

Hallo,

 

bevor der switch getauscht wird sollte mal eine netzwerk analyse stattfinden ob nicht irgendwo ein netzwerkknoten einen leistungseinbruch erleidet oder irgendwelche firewall regeln die leistung runterdrosseln.

 

würde dir empfehlen das du mal programme von Network Management, Discovery and Monitoring Tools from SolarWinds.Net oder WildPackets - Home Page ausprobierst. bei solarwind gibt es auch speziele anwendungen die Cisco Router/Switches analysieren.

[fu123 10]

Hi,

 

Fehlersuche bei Voice ist nicht einfach. Es kommt darauf an wo Voice gemacht wird. Nur Netzintern, zu einem anderen Standort, eventuell über eine Standleitung. Es gibt sehr viele Fehlerquellen. Manchmal ist der Flaschenhals z.B. nur eine falsche Duplexeinstellung auf einem Switch. Grundsätzlich solltest du wissen, wo Delay auftreten kann. Wenn du dann dort die entsprechende Bandbreite nicht erhöhen kannst, dann brauchst du QoS. Viel Erfolg bei der Fehlersuche.

 

Fu

[mr._oiso 10]

Hi Jens,

 

wie fu123 schon erwähnte, würde ich mir mal die einzelnen Port's auf den Switches

näher ansehen.

switch#show interfaces

 

Sieht dann etwa so aus !

 

 

FastEthernet0/3 is down, line protocol is down

Hardware is Fast Ethernet, address is 0004.4d02.3b83 (bia 0004.4d02.3b83)

Description: A-21 - SonosWuerfel

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 20:00:05, output 19:56:53, output hang never

Last clearing of "show interface" counters never

Queueing strategy: fifo

Output queue 0/40, 0 drops; input queue 0/75, 0 drops

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

11485939 packets input, 801270952 bytes

Received 98215 broadcasts, 16258 runts, 0 giants, 0 throttles

16787 input errors, 284 CRC, 245 frame, 0 overrun, 0 ignored

0 watchdog, 75323 multicast

0 input packets with dribble condition detected

22274462 packets output, 4161405405 bytes, 0 underruns

0 output errors, 0 collisions, 2 interface resets

0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier

0 output buffer failures, 0 output buffers swapped out

 

Diese Werte können Aufschluss auf die/den Übeltäter geben. Bei der Duplexeinstellung

kann man sich heute kaum noch auf die Protokolle LACP oder PAGP verlassen.

Bei Festinstallationen (keine Notebooks) lohnt sich eventuell die feste Einstellung.

Betreibst Du eventuell noch andere Protokolle im Netz ? (IPX,Apple etc ?)

Dann Check mal die Clients (z.B. Novellclient für Windows)

 

Diese Werte können zum besseren Überblick auch vorher mal gecleared werden.

 

switch#clear counters

switch#clear counter int fast 0/x

 

Tip am Rande : Speziell unter XP nimmt sich an den Netzwerkkarten der QoS-Paketplaner ne ganze menge an Ressourcen. Oftmals unnötigt aktiviert. Somit verliert der Adapter angeblich ca. 40% Cache, was sich in der Applikation nachhaltig bemerkbar macht.

Diesen abschalten bringt schon eine ganze Menge mehr !

 

Gruß

 

Mr. Oiso

[fu123 10]

 

Diese Werte können Aufschluss auf die/den Übeltäter geben. Bei der Duplexeinstellung

kann man sich heute kaum noch auf die Protokolle LACP oder PAGP verlassen.

 

Hi Jens,

 

LACP und PAGP sind Negotiation-Protokolle für Etherchannel. Das eine ist proprietär und das andere ein IEEE Standard.

 

Ansonsten 100% agree. Ich habe auch mal einen alten "Hub" an einer Standleitung gefunden, der die falsche Duplexeinstellung hatte. Wenn z.B. überhaupt irgendwelche Collisions auf einem Port sind, dann ist es keine Full Duplex. Full Duplex is immer kollisionsfrei!

 

Oder z.B. auch schon mal ein 2950 der mit dem Converter nicht richtig auf 10 Mbit full duplex lief. Erst nach einem IOS Upgrade klappte es dann. War ein IOS Bug.

 

 

Fu