Zum Inhalt wechseln


Foto

Cisco C3560G Port protokollieren, wegen evtl. Verbindungsabbrüchen?


  • Bitte melde dich an um zu Antworten
19 Antworten in diesem Thema

#1 maeck

maeck

    Senior Member

  • 326 Beiträge

 

Geschrieben 24. November 2016 - 20:13

Hallo zusammen,

 

wir haben einen Cisco Switch C3560G-48Port und ich würde gerne bei einem Port protokollieren, ob es Verbindungsabbrüche gibt.

Hintergrund: Wir haben eine Asterisk-basierte VoIP-Telefonanlage (als virtuelle Maschine) die direkt auf den zentralen C3560-Switch geht. Wir haben immer wieder Verbindungsabbrüche bei Telefonaten - auch bei interner Telefonie. Das ist bei unterschiedlichen IP-Telefonen der Fall. Der Telefonanlagen-Support sagt, dass innerhalb der Asterisk-Telefonanlage nur zu sehen ist, dass der Call abbricht, aber ohne Fehler. Deswegen wird vermutet, dass auf dem Weg von der Asterisk-Anlage zum Telefon etwas nicht stimmt. Dazwischen gibt es aber nur Kabel und den Cisco-Switch.

 

Jetzt würde ich gerne sowohl auf den Ports der IP-Telefone (die das Problem haben), also auch bei dem der zur virtuellen Maschine geht, protokollieren, ob es Verbindungsabbrüche gibt. Die physische Netzwerkkarte die die virtuelle Maschine verwendet, habe ich schon gewechselt - ohne Erfolg.

 

Machen meine Gedanken Sinn? Ist es möglich, auf dem C3560 etwas sinnvolles zu protokollieren?

 

Gruß Marcel


Bearbeitet von maeck, 24. November 2016 - 20:14.


#2 magheinz

magheinz

    Newbie

  • 1.368 Beiträge

 

Geschrieben 24. November 2016 - 21:29

rein theoretisch könntest du den Port mitlesen. Aber ob das wirklich hilft?

Wie währe es denn mit einem Softphone auf einem Rechner und parallel wireshark laufen lassen?

 

UP/Down-Status der ports solltest du auch im Logfile auf dem Switch finden.



#3 Otaku19

Otaku19

    Expert Member

  • 1.948 Beiträge

 

Geschrieben 25. November 2016 - 17:14

SPAN Port wäre möglich, eben in verbindung mit den genannten: log  + tcpdump auf den Endsystemen sollte man recht schnell analysieren können was das Problem ist. Nur eiens verrät mir das Bauchgefühl...ein switch verliert im regefall nicht einfach so frames ;)


Done: 640-801; 640-553; 642-524; 642-515; 642-892; 642-832; 642-504; 640-863; 642-627; 642-874; 642-785; ITIL v3 Foundation
Enterasys Systems Engineer; CompTIA Sec+; CompTIA Mobility+; CISSP; CISSP-ISSAP; Barracuda NGSE/NGSX; CISM


#4 maeck

maeck

    Senior Member

  • 326 Beiträge

 

Geschrieben 25. November 2016 - 20:46

Danke für eure Anregungen.

 

 

Wie währe es denn mit einem Softphone auf einem Rechner und parallel wireshark laufen lassen?

Habe ich schon probiert und darüber (leider) bisher keine Aussetzer. Es betrifft auch nicht jedes Telefon, sondern nur manche und es wandert. Habe die Telefone schon getauscht, was kein Erfolg gezeigt hat.

 

 

Nur eiens verrät mir das Bauchgefühl...ein switch verliert im regefall nicht einfach so frames ;)

Würde gerne mehr über dein Bauchgefühl hören ... :) ... bei dem beschriebenen Setting, wo würdest du den Fehler vermuten oder suchen?



#5 DocData

DocData

    Board Veteran

  • 1.284 Beiträge

 

Geschrieben 26. November 2016 - 07:07

Bei der TK Anlage...

Ein Wrack ist kein Ort, an dem ein Schatz schlummert...


#6 blackbox

blackbox

    Board Veteran

  • 1.078 Beiträge

 

Geschrieben 26. November 2016 - 19:17

Hi,

 

wie äußert sich denn der Fehler - ist das ganze im selben VLAN - hast du etwas mehr Infos. Ich glaube auch nicht das es der Switch so ist - vor allem wenn du schreibst, das das Gespräch abbricht. Da muss ja mehr wie ein Paket flöten gehen. Denke auch da muss woanderst gesucht werden.


Done: CCNP ; CCDP ; CCNA Video - Voice - Security - Wireless ; HP Master ASE Network 2011 ; ASE Blade V8 ; ASE Proliant V8;


#7 lefg

lefg

    Expert Member

  • 20.492 Beiträge

 

Geschrieben 26. November 2016 - 21:26

Sind Anlage und Telefone in einem VLAN dafür geführt und hat dieses Priorität?

 

Sind die Telefone auf Ports getrennt von den PC oder gibt es gemeinsamen Anschluss, die PC an den Telefonen?


Das Messbare messen, das Nichtmessbare messbar machen. Galilei.

 

Diskutiere nicht mit ***en, denn sie ziehen dich auf ihr Niveau und schlagen dich dort mit Erfahrung! (Hab ich bei Tom abgeguckt)

 

Koinzidenz begründet keine Korrelation und ist kein Beweis für Kausalität. (Hab ich bei Daniel abgeguckt) https://de.wikipedia...rgo_propter_hoc

 

Absolutistischer“ Geschäftsführungs-Dogmatismus, der jedwede Empirie aus der „Werkstatt“ schlichtweg ignoriert , führt eben zumeist früher als später ….  (Hab ich von Klabautermann)


#8 DocData

DocData

    Board Veteran

  • 1.284 Beiträge

 

Geschrieben 27. November 2016 - 11:39

Sind Anlage und Telefone in einem VLAN dafür geführt und hat dieses Priorität?

 

Erfahrung von mir aus etlichen Projekten: VoIP und Priorisierung ist tot. Die Telefone verpassen ihren Daten meist selber die entsprechenden Priorisierungsinformationen, die Switches müssen es nur noch berücksichtigen. Und angesichts moderner Codes und der Tatsache, dass diese Informationen nur im Engpass verwendet werden, muss man da nicht viel Hirnschmalz reinstecken.


Ein Wrack ist kein Ort, an dem ein Schatz schlummert...


#9 Otaku19

Otaku19

    Expert Member

  • 1.948 Beiträge

 

Geschrieben 29. November 2016 - 16:54

Prioisierung ist überhaupt nicht tot, es macht schon Sinn die Markierung der Pakete so nah wie möglich an der Quelle zu machen, wenn man der Quelle vertrauen kann, dann soll sie eben direkt die Werte setzen. Es muss dann aber durchgängig ein sinnvolles Konzept her. "Sinnvollerweise" konfiguriert sich QoS auf einem 6500er anders als auf einem 4500er und von einem Nexus fange ich lieber erst garnicht an :)

Die Priorisierung arbeitet quasi ständig, sortiert ja nur die queues um, das bandbreitenmanagement greift nur ein wenn es sein muss...QoS ist dazu da um gute situationene besser zu machen, nicht um ein Netz das schon völlig überlastet ist wieder hinzubiegen.


  • blackbox gefällt das

Done: 640-801; 640-553; 642-524; 642-515; 642-892; 642-832; 642-504; 640-863; 642-627; 642-874; 642-785; ITIL v3 Foundation
Enterasys Systems Engineer; CompTIA Sec+; CompTIA Mobility+; CISSP; CISSP-ISSAP; Barracuda NGSE/NGSX; CISM


#10 maeck

maeck

    Senior Member

  • 326 Beiträge

 

Geschrieben 03. Dezember 2016 - 16:59

Die Telefone sind in einem eigenen VLAN. Die Gbit-Ports sind im Trunk-Mode und führen Telefon-VLAN2 und normales Netzwerk-VLAN1. Eine Priorisierung für vlan2 ist aktiv.

 

Die Computer hängen mit 100Mbit hinterm Telefon.

Ein Softphone am Computer (hinterm Telefon) mit gleichem Telefon-User hat bisher keine Abbrüche.

 

Problem ist, dass der Telefonanlagen-Hersteller in den Logfiles (wohl) nur sehen kann, dass es Abbrüche gibt, aber nicht warum. Aufgrund dessen beharrt er darauf, dass die Abbrüche nicht der Asterisk-Anlage zuzusprechen sind, sondern des Netzwerks.

Ich habe schon alle Hardware-Teile "auf dem Weg" testweise ausgetauscht, bis auf den Cisco-Switch selbst.



#11 lefg

lefg

    Expert Member

  • 20.492 Beiträge

 

Geschrieben 03. Dezember 2016 - 17:26

Ob sich die Ethernet-Ports, die Protokoll-Aushandlung, nicht verträgt? RJ-47Buchse defekt, gerissen? Sowas in der Art? Ich hab sowas schon gehabt. Energiesparmodus des Interfaces, fehlerhaft?


Das Messbare messen, das Nichtmessbare messbar machen. Galilei.

 

Diskutiere nicht mit ***en, denn sie ziehen dich auf ihr Niveau und schlagen dich dort mit Erfahrung! (Hab ich bei Tom abgeguckt)

 

Koinzidenz begründet keine Korrelation und ist kein Beweis für Kausalität. (Hab ich bei Daniel abgeguckt) https://de.wikipedia...rgo_propter_hoc

 

Absolutistischer“ Geschäftsführungs-Dogmatismus, der jedwede Empirie aus der „Werkstatt“ schlichtweg ignoriert , führt eben zumeist früher als später ….  (Hab ich von Klabautermann)


#12 maeck

maeck

    Senior Member

  • 326 Beiträge

 

Geschrieben 03. Dezember 2016 - 17:41

Ports habe ich schon getauscht, Kabel/Telefon ebenfalls.

 

Das Problem ist nicht nur bei einem Telefon, sondern wandert.

Und es ist nicht bei jedem Gespräch. Mal nach 10 Sek des Gesprächs, mal nach 30 Sekunden, mal nach 2min.



#13 lefg

lefg

    Expert Member

  • 20.492 Beiträge

 

Geschrieben 03. Dezember 2016 - 19:06

Mit Ports meine ich nicht die får die Endgeræte sondern får die Telefonanlage, den Telefonserver. Es geht auch nicht ums Tauschen.

 

Ich beschreibe mein Erlebnis mal so: Das Drucken auf einen Ricoh Kopierer war manchmal zøgerlich, der Ricoh-Service schloss das Gerät an seinen Laptop an, es war alles in Ordnung. Ich schloss mein Gerät an den Switch, es schien alles in Ordnung. Zusammengeschaltet funktionierte es nicht richtig. Ich setzte die Port-Einstellung an beiden Geräten auf100FD und es war gut. Der später festgestellte Defekt war der RJ-45 Connector des Ricoh.

 

In einem anderen Fall: Einige Damen beschwerten sich über dsd zögerliche Drucken, andere nicht so sehr, zufrieden waren die aber auch nicht mehr, das war mal besser. Nach einem Aus- und Einschalten der beiden Switche hatte niemand daran mehr eine Verbindung. Auch ein Factory Reset besserte nichts. Geräte ausgetauscht, dann alles gut.

An den Geräten schienen alle Anzeigen normal, die LED leuchteten, blinkten aber nicht mehr so richtig, da musste man schon genau hinschauen. Es waren die eingebauten Netzteile, die gaben noch Spannung ab, aber die Gleichspannung war nicht mehr glatt genug.

 

Ob sowas bei Cisco-Qualität passieren kann? Keine Ahnung


Bearbeitet von lefg, 03. Dezember 2016 - 19:19.

Das Messbare messen, das Nichtmessbare messbar machen. Galilei.

 

Diskutiere nicht mit ***en, denn sie ziehen dich auf ihr Niveau und schlagen dich dort mit Erfahrung! (Hab ich bei Tom abgeguckt)

 

Koinzidenz begründet keine Korrelation und ist kein Beweis für Kausalität. (Hab ich bei Daniel abgeguckt) https://de.wikipedia...rgo_propter_hoc

 

Absolutistischer“ Geschäftsführungs-Dogmatismus, der jedwede Empirie aus der „Werkstatt“ schlichtweg ignoriert , führt eben zumeist früher als später ….  (Hab ich von Klabautermann)


#14 maeck

maeck

    Senior Member

  • 326 Beiträge

 

Geschrieben 03. Dezember 2016 - 20:45

Irgendwas stimmt mit deinem Zeichensatz nicht ... ich versteh nicht richtig, was du mir vorschlägst.

Die Telefonanlage ansich ist virtualisiert. Ich habe sie bereits auf einen anderen Host umgezogen, um die Netzwerkkarte des Hosts auszuschließen. Auch auf dem neuen Host gleiche Symtome. Danach habe ich die Telefonanlage auf einer neuen virtuellen Maschine von Grund auf neu installiert und alle Einstellungen neu vorgenommen - gleiches Ergebnis.



#15 lefg

lefg

    Expert Member

  • 20.492 Beiträge

 

Geschrieben 03. Dezember 2016 - 21:12

 

Irgendwas stimmt mit deinem Zeichensatz nicht ... ich versteh nicht richtig, was du mir vorschlägst.

 

Ich hab nicht aufgepasst und keinen deutschen Zeichensatz verwendet. Ich habe nichts vorgeschlagen.

 

Ich habe lediglich einige Möglichkeiten geschildert aus meiner Erfahrung zur Anregeung.

 

Was bleibt jetzt noch übrig?

 

Ob der Cisco die von dir gewünschte Möglichkeit bietet? RTFM! Kontaktiere den Support!


Bearbeitet von lefg, 03. Dezember 2016 - 21:14.

Das Messbare messen, das Nichtmessbare messbar machen. Galilei.

 

Diskutiere nicht mit ***en, denn sie ziehen dich auf ihr Niveau und schlagen dich dort mit Erfahrung! (Hab ich bei Tom abgeguckt)

 

Koinzidenz begründet keine Korrelation und ist kein Beweis für Kausalität. (Hab ich bei Daniel abgeguckt) https://de.wikipedia...rgo_propter_hoc

 

Absolutistischer“ Geschäftsführungs-Dogmatismus, der jedwede Empirie aus der „Werkstatt“ schlichtweg ignoriert , führt eben zumeist früher als später ….  (Hab ich von Klabautermann)