Agfeo ES 730 mit HP Procurve, Probleme mit VoIP

Das ist schon tödlich und bedingt vermutlich diese Fehler.
Der Duplex Mismatch resultiert in einer erhöhten Collision Anzahl die den Packet Flow am Port behindert und massiv in der Performance einschränkt.
Je höher der Traffic desto höher die Collisions. Ein Teufelskreis....
Das ist ein gravierender Fehler im Netz den du asap fixen solltest. In der Regel macht man das mit statischen Speed und Doplex Settings auf beiden Seiten also Switch UND Anlage.
Speed- und Duplex Settings sollten also niemals einseitig gemacht werden !

Nein !
Das ist de facto der Speed/Duplex Mismatch !

Das Beste ist immer wenn sich beide Seiten einigen können. Der Fehler zeigt das die Autonegotiation irgendwo nicht sauber funktioniert.
Was passiert wenn du einen kleinen ungemanagten 5 Port Dummswitch dazwischenschaltest und die beiden Ports wieder auf Auto (Autonegotiation) setzt ?
Können die dann den Speed auskaspern?
Dann sollte auch das Problem verschwunden sein.
Zu 98% liegt es am Autonegotiation Fehler, das liegt auf der Hand.
Wieso muss man das "nachfragen" ?? Das sieht doch jeder Laie im GUI des Anlagen Setups in den Einstellungen der Netzwerkparameter ?!

Traurig
Hat die nichtmal ein CLI oder einen Kommando Prompt bei dem das möglich ist ?!
Versuchs erstmal mit dem "Zwischenswitch".

1) Lass uns bitte erstmal wissen, was du für einen Switch hat, das ist hier die elementare Voraussetzung.

2) Der Ausdruck und die Interpretation "Duplex-Mismatch" ist gefährlich, da das viele Ursachen haben kann.

3) 100MBit/s Half-Duplex ist alles andere, als ein Beinbruch, ich denke nur an unsere Cisco ATA 186-Boxen, die verbinden sich mit 10MBit/s Half-Duplex, was auch richtig ist.
Auch hier meckern unsere Cisco-Switche mit Mismatch und Collisions etc, was für Half-Duplex aber korrekt ist.

4) IGMP ausschalten

Reicht noch nicht, bitte ganz genau, hier kann der Teufel wirklich im Detail stecken. Wenn du z.B. nur ein 100MBit/s-Modell hast, brauchst du unter Umständen ein gutes altes Crossover-Kabel zur Verbindung zwischen TK und Switch.


Werden wir sehen.


- Multicast ist höchstens metastabil und benötigt eine zu 100% funktionierende Infrastruktur
- Multicast macht nur Sinn, wenn man auch eine Anwendung für hat, ansonsten ist es, wie Broadcast, nur ein unnötiger Subnet-Störenfried. Und Voice benötigt kein Multicast, es sei denn, ihr habt Paging im Einsatz.

Ok, dann nimm dem Switchport der TK noch das Auto-MDIX weg, je nachdem welchen Kabeltyp du aktuell benutzt. Auch setz den Port wieder fest auf 100MBit/s Half-Duplex.

Firmware der HP-Switche ist aktuell? Grundsätzlich wird im Bereich Voice/QoS am meisten gefixt.

Dann ohne Multicast die Telefonie nochmal testen.

Das Telefon hast du testweise auch direkt auf dem Switch hängen, oder ist das weiterhin übers Patchpanel verbunden?

Gude,

die TK hat ne 10/100/1000er NIC on Board. Scheint als wäre die 100HDx fest drin, stells doch einfach auf 1Gbit fest, den Switchport ebenfalls, fertsch.

Ich meine den Switchport, an welchem die TK angeschlossen ist

An der TK kann man durchaus was verstellen. Kann das sein, dass du nur einen eingeschränkten User hast und der Anlageneinrichter für sowas kommen muss, falls ihr sie nicht selbst gekauft hat? Die Anlage kann definitiv 10/100 HDx und FDx sowie 1Gbit.

Fazit: Neuen und vernünftigen Switch kaufen und kein HP Mist

Moin allerseits,

auch ich kann die Selbe Problematik bestätigen.
Agfeo AS 200 LAN II in eine ES 628 getauscht.
Telefone und DECT Systeme sind geblieben.
4 Jahre Problemloser Betrieb mit der AS.
Bis auf ein paar Nebenswitches ausschließlich Cisco SG300 Switches im Netzwerk.
Auf sämtlichen Ports an allen Switches durchweg keine Fehler nur die Elements Sammelt durchweg Single Collision Frames, Late Collisions und Excessive Collisions.
Die Elements ist auch das einzige Gerät im gesamten Netz was auf 100Mbit HDx fungiert.
Verbaut ist wie bereits festgestellt eine Gigabit Karte.
Die Einstellungsmöglichkeit der NIC ist fest in der Firmware implementiert und laut aussage von agfeo auf 100mbit HDx eingestellt.
Der Fehler taucht auch bei uns immer sporadisch auf und steigert sich nach einiger Zeit immer mehr von Gerät zu Gerät. bis letztendlich keine Telefonie mehr möglich ist.
Nach Anlagenneustart hat man dann wieder einige zeit Ruhe.

Hat sich bei euch mittlerweile ein "Lösungsszenario" eingestellt?
Sonst muss ich zwangsweise wieder auf die AS "downgraden"
Die lief mit 100mbit VDx sehr Stabil und hatte auch einen gescheiten Telefonlog ;)

Insgsamt muss ich doch sagen ich bin mit der Elements bisher SEHR enttäuscht.
Hoffe Agfeo bessert Zeitnah mit Updates zumindest mal die Telefonanlagen Basis-Standarts nach.
Finde es irgendwie beschämend für einen vermeintlichen Business Anbieter etwas herauszubringen, was teilweise nicht mal die Funktionalitäten einer Fritzbox in sachen VOIP beinhaltet. (Sry für den Off-Topic anteil im Beitrag)

Beste Grüße!

Ja sehe ich leider auch so.
Wurde bei euch der "Austausch" berechnet? Weil der Fehler ja offensichtlich nicht bei der einen Anlage liegt, sondern direkt bei dem Produkt selbst, sprich Agfeo alle Vorwürfe von sich weist.

Die Firmware 1.12 ist für unsere Anlage noch nicht released. Ich bin derzeit aktuell bei der 1.10.

Wenn doch die ST 40 nicht funktionieren warum wird das denn nicht als Hinweis beigelegt?
Etwa weil dann keiner Umsteigt weil alles erneuert werden muss? Kann ich mir nicht anders Vorstellen.

Meiner Meinung nach wurde hier ein nicht einmal ansatzweise ausgereiftes Produkt auf den Markt geworfen nur um den Anschluss durch ALL IP nicht zu verpassen. Den Kunden durch spätere Updates zu besänftigen ist in diesem Segment einfach nur traurig.
Und die Tatsache, dass die Gigabit Schnittstelle durch die Firmware deaktiviert ist, halte ich persönlich Kartellrechtlich für ein sehr schmales Brett, da ja Explizit hierfür bei den Technischen Daten geworben wurde. Aber das ist ja eine andere Geschichte.

Das hört sich nicht gut an uns spricht de facto für einen Speed und Duplex Mismatch an diesem Port.
Sieht so aus als ob die Agfeo kein Autonegotiation beherrscht
Fast nicht vorstellbar in heutiger Zeit....
Auch vollkommen unverständlich das ein Hersteller ein Endgerät im Halfduplex Betrieb festnagelt. So gut wie alle Switches supporten heute ausnahmslos Fullduplex.
Halfduplex bedingt dann das Problem das der Switch an dem Port nicht zugleich senden und empfangen kann. Im Zeifel muss er Daten in den Portbuffern puffern.
Bei Billigswitches wie HP oder den Cisco 300 sind die natürlich aus Kostengründen minimalst ausgelegt oder bei HP nur ein mickriger Pool den sich dynamisch dann 24 oder 48 Ports teilen.
Worst case bedeutet das das Frames verloren gehen sollte der Puffer überlaufen. Das resultiert dann in Aussetzern und Abbrüchen.
Es ist de facto nicht nachvollziehbar warum Agfeo so einen Mist da baut. Technik kann es nicht sein, denn darunter werkelt unter Garantie ein Linux und das kann seit Jahrzehnten mit Full- und Halfduplex umgehen.
Sogar eine kleine Auerswald bekommt das problemlos hin ! Alle anderen auf dem VoIP Sektor auch.

Was passiert wenn du den Cisco mal auf einen festen statischen Speed und Duplex Wert am Port einstellst ?? 100Mbit, Halfduplex.
Zählen diese Collision Counter dann weiterhin hoch ??
Sollte dann nicht mehr der Fall sein und das Problem fixen...eigentlich.

Dein HP-Gehate nervt ;)


Klar gehen die Collisions hoch, das ist netzwerkbasiert. Wo Halbduplex, da Collisions. Wir haben Cisco ATA-Boxen im Einsatz, die sich mit 10MBit/s HD verbinden und auf 2960ern Cisco-Switchen selbst bei festeingestellten Ports massiv Collisions verursachen und trotzdem einwandfrei funktionieren.

Ihr könnt euch noch so arg auf die Collisions versteifen, das ist nicht der springende Punkt, da es kein Fehler ist.

Es ist aber ja leider die nackte Wahrheit und außerdem ist ja auch Cisco genannt... Ging ja auch nur darum einmal die Problematik zu erklären.
Sorry, aber das ist netwerktechnischer Blödsinn. Weisst du vermutlich aber auch selber oder du hast es falsch ausgedrückt.
Collisions sind niemals netzwerkbasiert. Schon mal gar nicht an einem Port, denn ein Store and Forward Switch wie die beiden obigen gibt solche Collisions niemals über die Backplane weiter. Kann er technisch prinzipienbedingt auch gar nicht. Sie sind einzig bezogen auf den Port.
Da wo diese Counter an Ports ungewöhnlich hochzählen ist immer auch ein Problem am Endgerät vorhanden. "Netzwerk" basierend ist also Unsinn und zeigt eher das du Switchtechnik nicht oder nur sehr wenig verstanden hast.
Auch das ist wieder laienhafter Unsinn. Ein Switch oder Endgerät was saubere Autongetioation macht kann damit umgehen. Wenn beide Seiten sauber auf Halfduplex negotiaten an einem Port kann ein entsprechend ausgestatteter Switch wunderbar damit umgehen. Thema Portbuffer...

Collisions entstehen immer nur dann wenn die Autonegotiation nicht klappt, beide Seiten also eine unterschiedliche Information über den jeweiligen Duplex Mode und/oder Speed haben. Ist auch vollkommen klar, denn die Duplex Seite sendet auch wenn die andere Seite sendet...da Duplex wo Senden und Empfang gleichzeitig möglich ist wie der Name es schon sagt. Die andere Seite kann das aber nicht (Halbduplex) so das beide zugleich senden und die Frames damit "kollidieren" am Port.
Auch das ist wieder nur halbrichtig, denn die Collision Warnung kommt vom Cisco CDP und hat dich vermutlich verwirrt.
Wenn man CDP am Port aber deaktiviert um eine automatische Umschaltung zu verhindern und beide Seiten entsprechend statisch fest und gleichermaßen konfiguriert in Bezug auf Duplex Mode und Speed funktioniert das natürlich problemlos.

Natürlich wird ein Port auch immer mit Collisions funktionieren nur eben mit ziemlich eingeschränkter Performance, da die höherliegenden Protokollschichten im TCP das durch Retransmissions wieder ausgleichen. Bei wenig Traffic merkt ein Anwender das nur sehr bedingt. UDP ist das tödlicher, denn das hat diesen Recovery Mechanismus nicht.
Die Collisions steigen dann exponentiell mit der Portlast. In sofern tolerieren das nicht alle Endgeräte unendlich.
Immer ist es aber ein Zeichen von miskonfigurierten Komponenten oder einem nachlässigen Netzwerk Admin.
Insofern resultiert daraus das dein laienhaftes Statement das das "kein Fehler" ist diese Annahme natürlich schlicht falsch ist.
Wenn du mal in Ruhe nachdenkst solltest du das auch selber einsehen...oder wenn nicht besser nochmal die Grundlagen über Twisted Pair Ethernet nachlesen !
Recht hast du aber mit der Tatsache das die Collisions nicht die Ursache sind sondern nur das Symptom einer falschen Endgeräteprogramierung der Hardware in der Agfeo.
Auch mit dem billigen Longshine Switch vom Blödmarkt Grabbeltisch sollte das kollisionsfrei klappen.

Demnach auch die CCNPs, die ich an der Hand habe?


Das Gegenteil ist bei mir q.e.d. Bzw. dass, wenn ein Gerät fest auf HD und der Switchport auf Auto läuft, auch daraus nicht zwingend ein Problem resultiert (obwohl es schlampig konfiguriert ist, wo ich dir Recht gebe).


Mich verwirren deine Aussagen, die Collisions auf dem Interface gehen hoch, sobald das Gerät angesprochen wird, bzw. wenn Traffic auf dem Interface stattfindet, unabhängig vom CDP... Kein Traffic = Kein Hochzählen des Collision-Counters.


Cisco ATA 186 Boxen, vorkonfiguriert und auf 10MBit/s festeingestellt, heißt deiner Meinung nach, dass (dein heiliges) Cisco die Boxen schon falsch ausliefert?

Und demnach hat sich Cisco mit dem "laienhaften" Statement, dass man aus Kollisionen nichts schließen kann und diese grundsätzlich kein Problem darstellen, selber disqualfiziert? http://www.cisco.com/c/en/us/support/docs/interfaces-modules/port-adapt ...


Siehe Link oben.


Die sind mir alle bekannt...


Danke.

Hallo,

Ich beobachte das ganze Zurzeit mit einem Netzwerkmonitor, welcher mich benachrichtigt wenn ein Netzwerkport wo ein Telefon angeschlossen ist über einen längeren Zeitraum dauerhaft über 85kbits Traffic aufweist. Konnte somit beim letzten Fehler innerhalb von kurzer Zeit das entsprechende Telefon neustarten und die Fehler waren weg. Jetzt beobachte ich erstmal ob es immer vom selben Telefon kommt oder von verschiedenen. Bislang ist es aber mit Monitoring bei dem einen Fehler geblieben.

Gruß zurück,
Kai