Jump to content
Melde dich an, um diesen Inhalt zu abonnieren  
maeck

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

Empfohlene Beiträge

Hi,

 

ich denke das zu suchen wird was längeres. Die Frage ist jetzt erstmal, wie das Gespräch läuft - laufen die Gespräche über die Asterix oder nur der Call Control wie bei div. anderen? Was für eine Virtualisierung? Nur interne oder auch externe Gespäche? Kannst du der TK einen eigene "NIC" geben - wo wir auf dem Switch nen Monitor Port setzen können und Wireshark mitlaufen lassen können? Welche Server sind sonst noch auf der Netzwerkkarte? Viele Fragen...

 

Die Frage ist - wer das Gespräch "kickt" - sonst kommen wir da nicht weiter. Solchen Lösungswege sollte aber der Support auch vorschlagen. (Etwas erstaunt).

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Hi Board-Veteran,

 

die Gespräche laufen über die Asterisk-Anlage (ist übrigens eine MobyDick-Anlage).
Virtualisierung basiert auf Hyper-V.
Es betrifft interne und externe Gespräche.
Die TK hat bereits eine dedizierte physische NIC, auf der nur die TK-Anlage läuft.

 

Der Support hat sich drauf festgebissen, dass es die Telekom sein muss - obwohl es auch interne Gespräche betrifft (erstaunt) - oder der Cisco-Switch. Mir sagen die Asterisk-Logfiles leider zu wenig, aber scheinbar ist dort nur ein Abbruch zu erkennen und nicht mehr.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Moin,

 

Blackbox hat Wireshark an einem Monitorport vorgeschlagen, mit dem Mirrorport dazu könnte man versuchen, Ausetzern auf die Spur zu kommen.

 

Da ich bin mit Wireshark nicht vertraut, ich versuchte es wohl erstmal mit PRTG und dem Packet Sniffer am Monitorport.

bearbeitet von lefg

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Es ist erschreckend wie sehr sich die Lösungsansätze mit denen die hier bei uns verfolgt worden sind als wir eine neue IP Anlage bekommen haben gleichen...von einer systematischen Fehlersuche keine Spur, erst mal was rebooten oder auf einen anderen Host schieben, Schuld wenn möglich auf Netzwerk oder Provider schieben,...

 

Es hilft alles nix, man muss das wirklich per Packet Sniffer genau beleiuchten, bzw in meinem Fall beweisen das die Calls/Pakete eben zu 100% an die Anlage weitergegangen sind. Ich weiß, das ist super mühsam, verbraucht viel Zeit und Ressourcen, aber manchmal geht es nicht anders.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Hallo,

 

ich denke du wirst um den Monitor Port nicht umher kommen. (Da du es ja schon auf einer dedizierte NIC hast - beste Vorraussetzung).

 

Auf einen PC mit ordentlicher HDD - den Wireshark drauf und die Daten mitscheiden. Im Wireshark einstellen, das er keine "mega" Pakete macht - dann kann man die Nachher besser "händeln". Wenn der Fehler auftritt - Uhrzeit aufschreiben und Gespräch rausssuchen. Dann wissen wir mehr. Der Wireshark hat da mega viele Hilfe Funktionen für SIP Calls mitlerweile "onboard".

 

Alles andere ist Kaffeesatz lesen - leider...

 

Mike

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte überlege Dir, ob es nicht sinnvoller ist ein neues Thema zu erstellen.

Erstelle ein Benutzerkonto oder melde dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde dich hier an.

Jetzt anmelden
Melde dich an, um diesen Inhalt zu abonnieren  

×