5020 VoIP Netzwerkprobleme

Aktuelle TK-Anlagen COMpact 5010/5020 VoIP
1

Hallo zusammen,
unsere Telefonanlage ist korrekt in unser Firmennetzwerk eingebunden. Ich habe aber das Problem, daß in regelmäßigen Abständen die Anlage nicht mehr auf Ihre IP reagiert. Dies tritt so alle 2-3 Wochen auf. Erst nach einem Neustart der Anlage steht die Konfigurationsmaske wieder zur Verfügung. Wir merken das immer beim Faxversand. Plötzlich meldet dieser einen Fehler und kann sich nicht mehr mit der Anlage verbinden. Faxe werden dann trotzdem angenommen, in der Anlage gespeichert aber nicht mehr weitergeleitet. Es scheint so, als verliere Sie ihre komplette Netwerkanbindung. Hat jemand eine Idee woran das liegen könnte. Kann ich irgendwo ein Fehlerprotokoll auslesen oder so?

Viele Grüße
halousi

2

Bringe die Anlage auf denn neuesten Firmwarestand. Danach müßte dieses Problem behoben sein.:stupid:

3

Hallo, neuste Firmware ist drauf 4.2C. Noch eine Idee? Das Problem ist, daß ich den Fehler nicht reproduzieren kann. Er tritt nur sporadisch auf und dann hilft nur noch Stecker ziehen und warten. Nach dem Neustart funktioneirt wieder alles für 3-4 Wochen.

4

Wie ist der sonstige Anlagenzustand?

  • Kann man in diesem Zustand noch telefonieren (über ISDN/POTS)?
  • Ist die Bedienoberfläche der 5020 über Ethernet erreichbar?
  • Was sieht man an den LEDs? Blinkt die LAN-LED (gelbe LED, dritte von links) dauernd?
  • Findet gleichzeitig irgendein Internettraffic über den Router statt?
  • Hast Du (für VoIP) irgendwelche Ports am Router geöffnet bzw. an die 5020 weitergeleitet?

Bei mir gab es ein ähnliches Phänomen. Dabei hat es sich um einen DoS-Angriff von außen auf die Anlage gehandelt. Durch den DoS-Schutz kam der Angreifer zwar nicht auf die Anlage, aber der Traffic hat die ordnungsgemäße Funktion der LAN-Verbindung verhindert.

Das Problem konnte durch Umstellungen am Router (Schließen der VoIP-Ports) behoben werden.

Gruß … Yeti

5

Moinsens,

könnte natürlich auch ein hardeware-problem sein.
Man könnte, um das besser einzugrenzen, tatsächlich mal das Netzwerk sniffen, um sich den Traffic zur / von der Anlage zu visualisieren. Zusätzlich mal ein Fachgespräch mit der Firewall zu führen, kann auch nichts schaden.

Feste IP hat die TK hoffentlich, strukturierte und geprüfte Verkabelung ist vorhanden? Der Switch kann keinen Treffer weghaben? DNS im LAN läuft problemlos?

LG, Thomas

6

Hi,
wir haben hier ein ähnliches Problem mit einer Auerswald Commander Basic 2. Alle zwei bis vier Tage ist die Anlage nicht mehr im Netzwerk zu erreichen, ein Pingen schlägt fehl. Einfach weg. Ein einfacher Neustart bringt die Anlage wieder zurück, bis sie nach einigen Tagen wieder verschwindet. Anruf beim Support brachte nix, DoS kann auch ausgeschlossen werden.

@halousi: wurde dein Problem mit der 5020 gelöst?

Gruß, Peter

7

Bei mir wird die anlage oder das Telefon nach einigen tagen auch langsamer, da hilft auch bei mir nur ein neustart der anlage.

8

Hi,

ich muss zugeben, das sich meine 5020 vor ein paar Tagen ebenfalls aus dem LAN verabschiedet hat, was bei mir funktionell nicht bemerkbar ist (Voicemail/Fax gehen über So an die C3000). Ich wollte nur mal schnell was konfigurieren …

Allerdings habe ich auch noch eine Firmware 4.0D drauf :floet:

Wenn es da keine Lösung aus dem Auerswald gibt und man benötigt die LAN-Funktion täglich, bleibt eigentlich nur das Monitoring des NIC der TK mit einem geeigneten Tool. Ich gugge mal übers Wochende, ob ich mein PRTG mit der Auerswaldtechnik anfreunden kann - Info folgt (so ich das nicht vergesse - Ü40 :rofl:).

LG, Thomas

9

Hi,
bei mir ist auch nach 1 - 3 Wochen die Verbindung zur Compact 5020 weg. Die Anlage läuft (meist) weiter, lässt sich aber über das Netz nicht mehr ansprechen. Ein Neustart lässt die Verbindung wieder zu. Die neuste Firmware ist geladen.
Gibt es ein Tool zur Überwachung der Verbindung oder einen Patch der Firmware?
Gruß
Joachim

10

Servus,

ich kann nur bestätigen das meine 5020 auch in unregelmäßigen Abständen das gleiche “nicht ansprechbar sein über das Webinterface” von sich gibt. Es ist absolut nicht voraussehbar wann es passiert, oder durch was es hervorgerufen wird. Ich merk es dann erst wenn ich entsprechend von Teilnehmern im Haus bzw. von Externen Anrufern (übers Handy) mitgeteilt bekomme das ich nicht zu erreichen bin. Wenn ich dann Versuch eine meiner Rufnummern anzurufen stelle ich fest das ich nicht entsprechend der konfig durchgeschaltet werde auf die angegebenen TNs. (Fehler durchsage Tcom) Und somit nur ein Neustart der Anlage das Problem löst.

COMpact 5020 VoIP
Firmwareversion Version 4.2E - Build 000
Datum 16.01.2014

Kann auch leider noch keine Info geben ob das Update evtl. das Problem behebt. Ich bin einfach mal guter Dinge.
Andererseits kann ich auch sagen, das ich diese Probleme nicht hatte als noch an meinem nativen ISDN Anschluss (TCom) hatte. Die Anlage lief mit dem ISDN Anschluss (ohne Voip) ohne jegliche Probleme , … bis natürlich auf die selbst durchgeführten reboots (weg. updates usw.).

Ich sach mal sollte meine Anlage wieder wie beschrieben fiese Matenten macht meld ich mich entsprechend.

11

In dem Fall solltest Du das auf jedem Fall auch dem Auerswald-Support melden (aber bitte erst nach Update auf die aktuelle Firmware)

Gruss
Marco

12

Zum einen ist auch die aktuelle Firmware Version 4.2E - Build 000 noch nicht ganz fehlerfrei (einfach links oben auf das Logo klicken), aber sie ist die beste Wahl! Das Problem mit der IP-Adresse hatte ich selten, aber dafür alle anderen beschriebenen umso heftiger.

Eine Verbesserung bringt, mal das USB Stick gegen ein neues zu tauschen, (dabei unbedingt immer die Sprachdatei importieren - nicht kopieren!), dann klappt das vermutlich mit der Faxzustellung wieder :).

Manchmal vergisst die Anlage die Einstellungen, ob und was geschickt werden soll, Auch die Checkboxen sind leer. Klickt man dann einen beliebigen Radiobutton an, ist alles wieder da, hängt aber nicht an der Konfigurationssteuerung, vielleicht aber an dem Umstand, das man aufwändig konfiguriert hat …

Es gibt auch noch so einige Timing-, Codec- und Softwareprobleme seitens der Telekom. Das ist mittlerweile dem Service und dem Vertrieb bekannt und laut den Aussagen einiger Techniker (im Vertrauen erzählt, gut wenn man einige Jahre zusammen Musik gemacht hat) kriegen sie das eine oder andere Problem auch nicht so schnell in den Griff - sprich, die wehren sich ganz und gar nicht mehr, wenn man das Thema Rückportierung zum alten ISDN anspricht …

Für mich war das schon öfter eine sinnvolle Option, zuletzt am Montag!

13

Moin,

da sich der NIC meiner C3000 auch (sehr selten) weghängt - via ISDN arbeitet das Büchschen trotzdem völlig normal … nur werden halt eingegangene voice- oder Faxnachrichten nicht mehr via smtp weitergereicht, lass ich den NIC über mein LAN-monitoring halt mitbeobachten. So kann ich zumindest einen Neustart initiieren - zumindest, wenn ich vor Ort bin. Allerdings habe ich auch noch eine Vorkriegsfirmware drauf.

LG, Thomas

14

Ich möchte diesen Thread nochmal mit einer Beobachtung von mir aufwärmen…

Bei einer 5020 mit Firmware 4.0H und ISDN-Amtsleitung beobachte ich, daß gelegentlich Gespräche auf einem COMpact 2500 VoIP AB abgehackt klingen. Deshalb habe ich mal versucht, Störungen im Netzwerk zu lokalisieren. Dazu habe ich einem im Netzwerk vorhandenen Linux-Server einen Cron-Job aufs Auge gedrückt, zu Telefonzeiten alle Sekunde einen Ping sowohl auf die Telefonanlage als auch eins der betroffenen Telefone abzusenden und die Antworten in Log-Dateien wegzuschreiben (Beispiel):

telefon17 steht dabei für den DNS-Namen des Telefons bzw. der Telefonanlage.

Im Ergebnis sehe ich in 3 Stunden (10800 Pings) an den Antworten des Telefons nichts, was mich stutzen läßt (Zusammenfassung; Beispiel):

10800 packets transmitted, 10800 received, 0% packet loss, time 10805490ms rtt min/avg/max/mdev = 0.539/0.618/2.056/0.072 ms

An der Telefonanlage sieht das aber schon etwas anders aus:

10800 packets transmitted, 10800 received, 0% packet loss, time 10804542ms rtt min/avg/max/mdev = 0.779/1.146/1000.923/9.670 ms
Es ist schon mal gut, daß kein einziges Paket verloren ging. Die Antwortzeiten der Telefonanlage sind höher als die des Telefons. Seltsam ist neben einem einzelnen Ausreißer von 1000ms auch, daß bei ansonsten typischen knapp 1ms Ping-Zeiten manchmal Wellen von ca. 20 Sekunden Dauer auftreten, bei denen die Antwortzeiten schlagartig auf ca. 9ms ansteigen, dann innerhalb von 8 Sekunden erst nur langsam fallen, dann aber wie exponentiell innerhalb der nächsten gut 10 Sekunden auf Normalwerte zurückgehen.

Heute hatte ich auch ein Ereignis, bei dem mir mein Telefonnutzer “Aussetzer” berichtet hat, wo ich meine, daß so eine “Welle” zeitgleich mit den berichteten Aussetzern aufgetreten ist. (Es ist natürlich schwierig, die Zeitangaben der Nutzer sekundengenau mit den Logs zu korrelieren.)

Probleme mit LAN-Kabeln und Switch halte ich anhand der Beobachtungen für unwahrscheinlich: ich habe noch nie ein einziges verlorenes Paket gesehen. An Störungen durch anderen Traffic im LAN (z.B. von PCs) glaube ich auch nicht, da sowohl Server, Telefon, Telefonanlage , Router und PCs direkt am Switch hängen.

Ich werde das mal weiter beobachten und wäre an vergleichbaren Berichten interessiert.

Abschließend: mir ist bewußt, daß die Firmware dieser 5020 alt ist. Ich würde aber gerne von einem Firmware-Update absehen. Ich habe noch eine zweite 5020 mit Firmware 4.2E im Einsatz; der werde ich demnächst mal auf ähnliche Weise zu Leibe rücken.

Grüße, lakonix

15

Hi,

ich gebe zwar mal zu, dass eine rtt von 2s schon mal recht heftig ist, aber wenn Du kein eigenes Netz für das TK-Geraffel hast und z.B. der switch ausreichend unintelligent ist, kann so ein Mini-broadcast-storm viele Ursachen haben, ein fehlerhafter NIC, irgendjemand kommt mit der autonegation nicht zurecht und, und, und - das macht in layer2-switches schon mal eine Aufregung. Um das sauber zu diagnostizieren müsstest Du das ganze LAN sniffen und selbst das wäre ohne Erfolgsgarantie. An meiner 3000 hängt sich schlicht der NIC weg, andere Ursache ausgeschlossen.
Gott und PRTG haben mir die Gelassenheit gegeben, dass zu tolerieren :rofl:, zumal das extrem seltene Ereignisse sind (Vollmond und wenigsten 3 schwarze Katzen, die mitternachts den Weg in die Praxis gefunden haben sind Mindestvoraussetzungen).
Blöd ist natürlich, wenn das an einer TK passiert, an der Telefone hängen … aber wenn das häufiger auftritt, wäre eine via TCP/IP schaltbare Steckdose eventuell Mittel der Wahl.

LG, Thomas

16

Nur um Mißverständnissen vorzubeugen: die Telefonanlagen-NIC hat sich noch nie weghängt.

Der Switch ist ein klassischer unmanaged Switch, D-Link DGS-1016D oder ähnlich. Warum sollte ein Mini-Broadcast-Storm Auswirkungen auf die Pingzeiten der Telefonanlage haben, aber nicht auf das Telefon? Warum soll sich die 5020 davon beeindrucken lassen, aber nicht das 2500 VoIP AB?

Grüße, lakonix

17

Ich halte die ausgegebenen Zeiten jetzt auch nicht für so dramatisch, wenn Du dort einen besseren Baumarktswitch verbastelt hast, aber je nachdem, welche Last und welchen overhead der auf einem Port hat, kann der schon mal so reagieren, da ihm TCP/IP-Korrekturen fehlen - ein intelligenter Ausgleich ist da nicht möglich. QoS kann der aber?

Sind die pings parallel gelaufen?

LG, Thomas

18

Das hätte ich auch gesagt, wenn es nicht die zusätzlichen Beobachtungen gäbe wie Aussetzer und die seltsamen „Wellen“. Ich füge unten mal eine ein.

Ja, die laufen über jeweils 3 Stunden parallel. Wie synchron die beiden untereinander laufen, kann ich auf Basis harter Fakten nicht sagen. Es sind zwei parallel laufende Tasks, die per Cron gestartet werden. Ich glaube nicht, daß die auf die Millisekunde synchron laufen.

Nehmen wir mal an, es habe einen Broadcast-Sturm gegeben, oder der Switch macht „Ärger“. Wie erklärt sich dann, daß ich in der Kette vom Server über den Switch zum Telefon und zurück folgendes sehe

rtt min/avg/max/mdev = 0.539/0.618/2.056/0.072 ms

bei der Telefonanlage aber

rtt min/avg/max/mdev = 0.779/1.146/1000.923/9.670 ms

Auch wenn ich mal den einzelnen Ausreißer mit 1000 Millisekunden (!!) ignoriere, ist es offensichtlich, daß zur Telefonanlage die RTT sehr viel stärker schwankt. Da kommen nur folgende Komponenten in Frage: a) der Port des Switch zur Telefonanlage hin, b) die LAN-Verbindung, c) die Telefonanlage.

Ich persönlich halte die Telefonanlage für am meisten verdächtig. Hier auch noch ein Auszug aus den Logs, wo ich eine dieser „Wellen“ sehe:

64 bytes from pc-00008.localdomain.xy (192.168.1.8): icmp_seq=2306 ttl=64 time=0.854 ms 64 bytes from pc-00008.localdomain.xy (192.168.1.8): icmp_seq=2307 ttl=64 time=0.909 ms 64 bytes from pc-00008.localdomain.xy (192.168.1.8): icmp_seq=2308 ttl=64 time=1.08 ms 64 bytes from pc-00008.localdomain.xy (192.168.1.8): icmp_seq=2309 ttl=64 time=0.914 ms 64 bytes from pc-00008.localdomain.xy (192.168.1.8): icmp_seq=2310 ttl=64 time=0.856 ms 64 bytes from pc-00008.localdomain.xy (192.168.1.8): icmp_seq=2311 ttl=64 time=7.22 ms 64 bytes from pc-00008.localdomain.xy (192.168.1.8): icmp_seq=2312 ttl=64 time=7.03 ms 64 bytes from pc-00008.localdomain.xy (192.168.1.8): icmp_seq=2313 ttl=64 time=6.97 ms 64 bytes from pc-00008.localdomain.xy (192.168.1.8): icmp_seq=2314 ttl=64 time=7.15 ms 64 bytes from pc-00008.localdomain.xy (192.168.1.8): icmp_seq=2315 ttl=64 time=6.94 ms 64 bytes from pc-00008.localdomain.xy (192.168.1.8): icmp_seq=2316 ttl=64 time=6.73 ms 64 bytes from pc-00008.localdomain.xy (192.168.1.8): icmp_seq=2317 ttl=64 time=6.67 ms 64 bytes from pc-00008.localdomain.xy (192.168.1.8): icmp_seq=2318 ttl=64 time=6.73 ms 64 bytes from pc-00008.localdomain.xy (192.168.1.8): icmp_seq=2319 ttl=64 time=5.57 ms 64 bytes from pc-00008.localdomain.xy (192.168.1.8): icmp_seq=2320 ttl=64 time=4.48 ms 64 bytes from pc-00008.localdomain.xy (192.168.1.8): icmp_seq=2321 ttl=64 time=3.52 ms 64 bytes from pc-00008.localdomain.xy (192.168.1.8): icmp_seq=2322 ttl=64 time=3.31 ms 64 bytes from pc-00008.localdomain.xy (192.168.1.8): icmp_seq=2323 ttl=64 time=3.21 ms 64 bytes from pc-00008.localdomain.xy (192.168.1.8): icmp_seq=2324 ttl=64 time=3.43 ms 64 bytes from pc-00008.localdomain.xy (192.168.1.8): icmp_seq=2325 ttl=64 time=3.12 ms 64 bytes from pc-00008.localdomain.xy (192.168.1.8): icmp_seq=2326 ttl=64 time=3.01 ms 64 bytes from pc-00008.localdomain.xy (192.168.1.8): icmp_seq=2327 ttl=64 time=3.02 ms 64 bytes from pc-00008.localdomain.xy (192.168.1.8): icmp_seq=2328 ttl=64 time=3.09 ms 64 bytes from pc-00008.localdomain.xy (192.168.1.8): icmp_seq=2329 ttl=64 time=2.81 ms 64 bytes from pc-00008.localdomain.xy (192.168.1.8): icmp_seq=2330 ttl=64 time=1.75 ms 64 bytes from pc-00008.localdomain.xy (192.168.1.8): icmp_seq=2331 ttl=64 time=0.986 ms 64 bytes from pc-00008.localdomain.xy (192.168.1.8): icmp_seq=2332 ttl=64 time=0.938 ms 64 bytes from pc-00008.localdomain.xy (192.168.1.8): icmp_seq=2333 ttl=64 time=0.843 ms 64 bytes from pc-00008.localdomain.xy (192.168.1.8): icmp_seq=2334 ttl=64 time=0.844 ms 64 bytes from pc-00008.localdomain.xy (192.168.1.8): icmp_seq=2335 ttl=64 time=0.871 ms 64 bytes from pc-00008.localdomain.xy (192.168.1.8): icmp_seq=2336 ttl=64 time=0.871 ms 64 bytes from pc-00008.localdomain.xy (192.168.1.8): icmp_seq=2337 ttl=64 time=0.934 ms

Ich möchte einfach mal eine vielleicht an den Haaren herbeigezogene Arbeitshypothese einwerfen. Wenn die CPU der Telefonanlage während dieser Welle heftig beschäftigt wäre, dann würde das die Knackser auf dem Telefon und die erhöhten Antwortzeiten zwanglos erklären.

Grüße, lakonix

19

Hi lakonix,

nur ein Gedanke - irgendwelche Portforwardings in Deinem DSL-Router auf die 5020 hast Du nicht zufällig?
Mein Gedanke ist der, dass die Anlage evtl. aus dem Internet mit Anfragen zugeschüttet wird - und zwar in einer Menge, dass sie nicht damit fertig wird.

Vielleicht ein freigegebener “Wartungszugang” auf das Webinterface der Anlage? Oder weil mal ein SIP-Problemchen existierte mal unbedacht ein paar Ports freigegeben?

ICMP-Requests - also das was gemeinhin als Ping bezeichnet wird - werden auf derartigen (Linux-)Systemen schon direkt im Linuxkernel beantwortet, also auf kürzestem Wege. Die beobachteten schwankenden RTTs sprechen somit für eine stark ausgelastete CPU in der Anlage. Wohlgemerkt im Linuxkernel stark ausgelastet…

Gruß Dauerbesetzt

20

Guter Gedanke, aber Portforwarding ist in den von mir betreuten Netzen tabu: Fernzugänge laufen ausschließlich ausschließlich über VPN… Als Router setze ich BTW http://www.ipcop.org/ ein.

Gibt es eine Möglichkeit, die CPU-Auslastung der 5020 zu loggen, im Idealfall von außen? Gibt es gar eine Möglichkeit, eine Konsole auf der 5020 zu öffnen, wenn ja wie?

Grüße, lakonix