Für uns „Normalos“ leider nicht :hang:
Da könnte man höchstens mal ins Log schauen. Hätte auch ggfs. auf eine SIP-Attacke getippt (hatte ich mal vor 2 Jahren, das hatte mir die Business damals sogar bis zum Reset gebracht), aber ohne Portfreigabe fällt das natürlich aus. Zumal das Blacklisting sowas ja auch verhindern sollte …
Hallo Marco,
Da muß ich jetzt mal ganz blöd fragen… Du meinst einen Log (Log-Datei), die über die Weboberfläche der 5020 zur Verfügung steht? Ich finde da im GUI aber nix dazu :mad:
Im übrigen habe ich die Pings zu den Nutzungszeiten der Telefone mal durchlaufen lassen. Wenn ich vereinzelt Antwortzeiten von der Telefonanlage von einigen 100 Millisekunden beobachte, ist das definitiv zu viel, da brauche ich mich über Sprachaussetzer nicht wundern. Das betroffene Telefon hat dagegen bei ca. 100000 Pings nicht eine Antwortzeit von >3 Millisekunden geliefert. Da mache ich mir keine Sorgen mehr, bei der Telefonanlage aber sehr wohl.
Ich habe noch eine zweite 5020 im Einsatz, dort mit neuester Firmware 4.2E. Diese Anlage monitore ich jetzt mal zu Vergleichszwecken ebenfalls mit Pings. Nächstes Wochenende werde ich dazu berichten.
Grüße, lakonix
[quote=“Marco, post:21, topic:4191”]
Da könnte man höchstens mal ins Log schauen.[/quote]
Ideen dazu?
ich habe übrigens jetzt mal die Ping-Logs meiner zweiten 5020 angeguckt, die mit Formware 4.2E läuft. Da sehe ich ganz ähnliche Dinge wie in der anderen Anlage.
Zum einen tauchen ganz vereinzelt erratisch (3 Pings von 21600 Pings, also 6 Stunden) einzelne Ausreißer von 100 bis zu 1000 Millisekunden auf. Seltsam, seltsam. Des weiteren sehe ich aber auch die schon berichteten Wellen. Die beginnen häufig (nicht immer mit einem Spike von bis zu 20 Millisekunden, dann manchmal eine einzelne schnelle Antwort, gefolgt von Welle, die mehr oder weniger schnell abklingt.
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=5689 ttl=64 time=0.979 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=5690 ttl=64 time=0.850 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=5691 ttl=64 time=0.820 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=5692 ttl=64 time=1.01 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=5693 ttl=64 time=20.7 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=5694 ttl=64 time=5.29 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=5695 ttl=64 time=5.17 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=5696 ttl=64 time=5.20 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=5697 ttl=64 time=5.19 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=5698 ttl=64 time=4.21 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=5699 ttl=64 time=3.27 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=5700 ttl=64 time=3.43 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=5701 ttl=64 time=3.29 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=5702 ttl=64 time=3.29 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=5703 ttl=64 time=3.49 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=5704 ttl=64 time=2.32 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=5705 ttl=64 time=2.41 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=5706 ttl=64 time=1.47 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=5707 ttl=64 time=1.14 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=5708 ttl=64 time=0.956 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=5709 ttl=64 time=0.840 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=5710 ttl=64 time=9.59 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=1796 ttl=64 time=0.986 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=1797 ttl=64 time=0.851 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=1798 ttl=64 time=0.880 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=1799 ttl=64 time=0.818 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=1800 ttl=64 time=7.79 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=1801 ttl=64 time=21.6 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=1802 ttl=64 time=1.38 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=1803 ttl=64 time=6.84 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=1804 ttl=64 time=5.98 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=1805 ttl=64 time=5.92 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=1806 ttl=64 time=5.91 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=1807 ttl=64 time=6.11 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=1808 ttl=64 time=5.92 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=1809 ttl=64 time=5.97 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=1810 ttl=64 time=6.01 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=1811 ttl=64 time=5.13 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=1812 ttl=64 time=5.02 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=1813 ttl=64 time=5.03 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=1814 ttl=64 time=5.19 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=1815 ttl=64 time=5.08 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=1816 ttl=64 time=5.09 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=1817 ttl=64 time=5.33 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=1818 ttl=64 time=4.13 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=1819 ttl=64 time=4.15 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=1820 ttl=64 time=3.27 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=1821 ttl=64 time=2.17 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=1822 ttl=64 time=2.20 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=1823 ttl=64 time=2.30 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=1824 ttl=64 time=2.26 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=1825 ttl=64 time=2.27 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=1826 ttl=64 time=2.36 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=1827 ttl=64 time=1.31 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=1828 ttl=64 time=0.836 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=1829 ttl=64 time=9.31 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=1830 ttl=64 time=1.01 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=1831 ttl=64 time=0.844 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=1832 ttl=64 time=0.846 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=1833 ttl=64 time=0.858 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=1834 ttl=64 time=0.919 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=5351 ttl=64 time=1.16 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=5352 ttl=64 time=1.06 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=5353 ttl=64 time=1.20 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=5354 ttl=64 time=20.8 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=5355 ttl=64 time=1.36 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=5356 ttl=64 time=8.92 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=5357 ttl=64 time=9.06 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=5358 ttl=64 time=8.80 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=5359 ttl=64 time=7.95 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=5360 ttl=64 time=8.08 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=5361 ttl=64 time=0.970 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=5362 ttl=64 time=0.820 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=5363 ttl=64 time=0.907 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=5364 ttl=64 time=0.854 ms
64 bytes from pc-00008.domain.local (192.168.0.8): icmp_seq=5365 ttl=64 time=0.848 ms
Ich glaube hier nicht mehr an einen Zufall, dazu ist das zu wiederkehrend, noch dazu in einem zweiten Netzwerk.
Kann es sein, daß die 5020 in dem Moment ordentlich zu rechnen hat, z.B. mit Verbindungsaufbau, kodieren oder was auch immer?
Grüße, lakonix
Hi,
Zufälle gibt es immer. Probier doch mal, was passiert, wenn Du die TK direkt mit einem PC/Laptop über RJ45 verbindest und dann den Ping laufen lässt … Wenn die Anlage da unauffällig ist, kannst Du zumindest schon mal die NIC der Anlage als Schuldigen ausschliessen.
Danach würde ich step by step das setup wieder erweitern, bis das Phänomen erneut auftritt.
LG, Thomas
p.s.: zumindest im Windows-Bereich habe ich schon erlebt, dass ein lokal an der Belastungsgrenze rödelnder Server den LAN-Port dichtmacht - ob jetzt TCP/IP wegschmiert oder der Treiber … keine Ahnung.
Also, das Verhalten tritt an zwei Anlagen in unterschiedlichen (aber ähnlich aufgebauten) Netzwerken auf, daher glaube ich weder an einen Zufall noch an einen Hardwaredefekt.
Ebenso wenig glaube ich, daß mir das Testsetup einen Streich spielt, denn warum sehe ich in den Log-Files keinerlei Wellen bei Pings auf die 2500 VoIP Telefone, aber auf die Telefonanlage. Bei beiden Anlagen / Netzwerken hängen alle Komponenten jeweils an einem Switch (keine Kaskadierung).
Die 5020 direkt mit einem Monitor-PC zu verbinden, ist eine gute Idee, nur muß ich dazu den produktiven Betrieb an den 2500 VoIP-Telefonen lahmlegen 
In den sauren Apfel werde ich am Wochenende wohl tatsächlich mal beißen.
Grüße, lakonix
So, nun ein paar Testergebnisse vom Wochenende.
Test 1: isoliertes Netz; 5020 mit Router direkt verbunden
[list]
[]direkte Verbindung 5020 mit 1:1 LAN-Kabel, kein Switch!
[]Router IPCop, fast Vanilla, nur DHCP eingerichtet, kein Internetzugang
[]keinerlei sonstige Devices im Netzwerk
[]Telefonanlage (feste IP-Adresse) im Ruhezustand (keine Telefonate)
[/list]
Hier liefert ein Ping über 10 Minuten nur Unauffälliges, max. Pingzeit liegt im Bereich um 1 Millisekunde, der Durchschnitt bei ca. 0.75 Millisekunden
Test 2: isoliertes Netz; 5020 über Switch mit Router direkt verbunden
[list]
[*]wie Test 1, nur daß statt der direkten Verbindung nun ein preiswerter unmanaged 8-Port Switch dazwischen saß, folglich zwei 1:1 LAN-Kabel
[/list]
Hier liefert ein Ping über 10 Minuten keine signifikaten Abweichungen zum Szenario von Test 1.
Test 3: isoliertes Netz: 5020 über Switch mit Router und drei 2500 VoIP verbunden
[list]
[*]wie Test 2, nur daß drei 2500 VoIP dazugekommen sind; deren IP-Adressen werden über DHCP zugewiesen
[/list]
Hier liefert ein Ping auf die Telefonanlage über 10 Minuten keine signifikaten Abweichungen zum Szenario von Test 1. Die Pingzeiten zu den 2500 VoIP liegt signifikant niedriger; um 0.5 Millisekunden. Auch die mittlere Schwankung ist niedriger als bei der 5020.
Test 4: isoliertes Netz: 5020 über Switch mit Router und drei 2500 VoIP verbunden; Belastungstest
[list]
[]wie Test 3, nur daß ich nun “Unruhe” per Telefonanrufen erzeugt habe
[/list]
Hier sind nun Dinge zu beobachten, die ich noch nicht komplett / vollständig einordnen kann:
[list]
[]Wenn ich den Hörer eines 2500 VoIP abhebe, treten beim Ping auf die Telefonanlage einzelne “Spikes” von bis zu 10 Millisekunden auf. Diese "Spikes sind bei parallel laufendem Ping auf die 2500 VoIP nicht zu beobachten. Ansonsten sind die Pingzeit bei max. 1 Millisekunde.
[]Wenn ich die Nummer eines zweiten 2500 VoIP im Netz wähle und der Apparat läutet, sehe ich keine Veränderung, siehe Vorpunkt.
[]Hebe ich den Hörer des läutenden Apparates ab, so sehe ich häufig eine der von mir beobachteten Wellen: die Pingzeit der Telefonanlage steigt auf knapp 10 Millisekunden. Die Antwortzeiten gehen dann wieder nach 10 bis 20 Sekunden wieder zurück auf ca. 1 Millisekunde. Gleichzeitig ist die Pingzeit des anrufenden Telefon unverändert um 0.5 Millisekunden.
[]Manchmal scheint es so zu sein, daß ich bei bestehender Telefonverbindung (komplette akustische Ruhe in beiden Telefonen) die o.g. Wellen durch Hineinpusten in den Hörer erneut auslösen kann.
[]Manchmal treten die Wellen beim Abheben des Hörer des läutenden Apparates aber auch nicht auf.
[*]Wenn ich von einem 2500 VoIP die Verbindung zu einem analogen internen Apparat aufbaue, sieht das ähnlich aus wie oben beschrieben, bloß daß die Pingzeiten der Telefonanlage nicht so deutlich steigen.
[/list]
Test 5: Verhalten in produktivem Netzwerk
[list]
[*]wie Test 4, nur daß 5020 und drei 2500 VoIP im produktiven Netzwerk an einem unmanaged Switch hängen (Router IPCop, ein Linux-Server, ein Druckerserver, ein WLAN-Accesspoint mit über WLAN angebundenem Win7 Laptop)
[/list]
Hier kann ich keine signifanten Unterschiede zum Test 4 erkennen.
Meine Zusammenfassung und Schlußfolgerungen:
[list]
[]Ich sehe keine Indizien, daß die Netzwerkinfrastruktur (isoliert vs. nicht isoliert) einen Beitrag liefert. Ich glaube nicht, daß die Ursachen der Wellen im Netzwerk oder dessen Aufbau zu suchen sind.
[]Ich sehe an den 2500 VoIP Telefonen keinerlei Änderung der Ping-Zeiten. Ich glaube nicht, daß es sich lohnt, in deren Richtung nachzugraben.
[]Ich sehe Anhaltspunkte für ein seltsames Ping-Verhalten der 5020. Dies kann ich noch nicht 100%ig reproduzieren.
[]An ein Hardwarproblem glaube ich nicht, weil ich diese Wellen ja auch an einer zweiten 5020 in einem anderen Netzwerk gesehen habe.
[]Ich behaupte ausdrücklich (noch) nicht, daß die Pingzeiten-Wellen mit der Ursache für die bei mir beobachteten Störungen in der Telefonqualität zusammenhängen. Ausschließen kann ich das aber auch noch nicht.
[]Die bei mir in Langzeit-Pings beobachteten Ausreißer von >> 20 Millisekunden konnte ich heute bei den Tests nicht beobachten.
[/list]
Derzeit bin ich mit meinem Latein am Ende, was ich hier weiter machen kann, denn für mich deuten alle Indizien auf die 5020. Am einfachsten wäre es, wenn es einen Zugang zur Konsole der 5020 gäbe. Weitere Tests von außen in Richtung 5020 erscheinen mir wie ein Stochern im Nebel.
Ist jemand in der Lage, meine o.g. Tests nachzubauen und (hoffentlich!) die Testergebnisse zu reproduzieren?
Hat jemand Ideen zum weiteren Vorgehen?
Grüße, lakonix
Hi,
mein Fazit:
Duck und weg …
BTW: eventuell ist ja die verbaute CPU tatsächlich so schwach, dass sie mit dem en- und decoden bei VOIP keinen Platz mehr für die ordnungsgemässe Funktion des OS mehr lässt … wobei ich das Verhalten mit meinen 2500VOIP (in Bezug auf Aussetzer) nicht nachvollziehen kann. Aber: die Teile stehen an wenig genutzten Arbeitsplätzen.
Ich schau mal, ob ich die Woche meine Mädels mal überzeugen kann, intern darüber zu telefonieren während ich gleichzeitig einen ping -t auf die TK schicke.
LG, Thomas
Steckt bei Euch ein 2VoIP oder 6VoIP-Modul in der Anlage? Oder laufen die VoIP’s ohne diese rein auf der CPU?
Pingtest ist nicht immer sooo aussagekräftig, die Prio ist hier mit Sicherheit nicht sehr hoch und andere Prozesse/Pakete werden sicherlich bevorzugt. Da kann so ein Ping auch schonmal was länger dauern, wenn es gerade mal hoch her geht. Die 5020 ist ein feines Teil, aber eben auch keine 6000er 
Letztendlich ist es egal, wenn mal ein Ping ausreißt. Aber sobald Sprachstörungen im LAN auftreten oder die Anlage gar nicht mehr reagiert, sollte man wirklich mal schauen …
Administration → Protokolle → Servicedaten
@Doc: Im Vergleich zur CPU der 5020 langweilen sich Deine 2500er VoIP geradezu! 
Moin,
ich habe das gestern und heute mal bei mir (2VOIP, Mischumgebung ISDN- und VOIP-Telefone) und bei einem Freund (6VOIP, nur VOIP-Telefone) im Betrieb mal mit einem ping über ca. 20 Minuten versucht, nachzustellen.
Ich sehe im Gespräch den Ping von < 1ms auf =1ms steigen, sonst ändert sich da nix (der Windows-ping aus der CMD ist da leider nicht genauer). Diese Wellen kann ich da nicht nachvollziehen - allerdings kann ich auch nicht den genauen Bezug zu den Stationen herstellen, ein wenig arbeiten muss ich nebenbei auch noch. Aber meinem Freund stehen nur 2500 VOIP.
Wir hantieren aber auch noch mit Firmwareständen, die durch das Reichsnachrichtenministerium zugelassen wurden 
LG, Thomas
Da findet sich bei mir nur die Möglichkeit „Download eines TK-Anlagen-Images ( Data - Partition )“. Wenn ich mir diese Datei herunterlade und mit einem reinen Texteditor angucke, sehe ich nur Zeichensalat.
Ja, in meinen beiden Anlagen steckt jeweils ein 6VoIP-Modul.
Mir ist klar, daß ich die Ping-Zeiten nicht überbewerten sollte. Aber ich bin dem nachgegangen, weil mir die Nutzer von abgehackten Telefonaten berichteten. Ich selber habe das nie beobachtet, wenn ich mal vor Ort war. Deshalb eben die Krücke mit dem Ping-Test als unabhängigem externen Monitoring.
Für andere Ideen hinsichtlich Monitoring, sei es Netzwerk oder „Auslastung“ der 5020 wäre ich sehr dankbar.
Grüße, lakonix
Hi lakonix,
zu den Log-Files kann ich Dir leider auch nicht weiterhelfen.
Mir kam aber noch etwas anderes in den Sinn. Bei den 5020ern beobachte ich ab und an mal, dass bestimmte (billige) USB-Sticks die Kistchen mehr belasten, als andere.
Wenn Du jetzt sagst, dass das nur manchmal auftritt (und natürlich immer nur dann, wenn man selbst grad nicht vor Ort ist ) … kannst Du ja mal probieren, ob die Störungen immer dann auftreten, wenn gerade etwas auf den USB-Stick (ich behaupte) geschrieben wird. Z.B. Fax empfangen, Anrufbeantworter wird gerade besprochen…
Natürlich vorausgesetzt Du nutzt den eingebauten AB / Faxbox …
Gruß Dauerbesetzt
Hallo Dauerbesetzt,
an der Anlage, bei der mir das zuerst aufgefallen ist, steckt kein USB-Stick, an der anderen Anlage steckt ein Original-Auerswald 1GByte Stick, der mit einem 2500 VoIP Telefon geliefert wurde.
Also gute Idee, aber das kann es auch nicht sein
Grüße. lakonix