thorsten85
Goto Top

Agfeo ES 730 mit HP Procurve, Probleme mit VoIP

Hallo zusammen,

wir haben bei einem Kunden das Problem, das VoIP Telefonate teilweise abbrechen oder einer der Teilnehmer nicht verstanden wird.

Nach einem Neustart der TK-Anlage funktioniert es oft für einige Zeit wieder.
Seltsam ist, das es mit einer alten AS40 bis vor kurzem, bei gleicher Netzwerkkonfiguration, einwandfrei funktionierte.

Auf dem Switch sehe ich am Port zur Anlage immer ein Duplex-Mismatch.
Laut Agfeo hat der Port 100HDx, aber egal ob ich Autonegotiation einstelle oder fest auf 100HDx der Fehler taucht auf.

Die Telefonate über die Systemtelefone funktionieren immer einwandfrei.

Voice hat auf den Switchen ein eigenes VLAN.

Was wir bis jetzt getan haben:

- Kabel zur Anlage getauscht
- Anlage getauscht


Konfig des VLANs:

vlan 5
name "VOICE_VLAN"
untagged 18,21-22
tagged 12,23-24
no ip address
ip igmp
qos priority 6
voice
exit


Mir gehen langsam die Ideen aus oder übersehe ich was?

Danke und Gruß,

Thorsten

Content-Key: 331787

Url: https://administrator.de/contentid/331787

Ausgedruckt am: 19.03.2024 um 07:03 Uhr

Mitglied: SlainteMhath
SlainteMhath 10.03.2017 um 12:42:05 Uhr
Goto Top
Moin,

schon mal den einen anderen Port bzw. Switch versucht?

lg,
Slainte
Mitglied: Thorsten85
Thorsten85 10.03.2017 um 12:53:55 Uhr
Goto Top
Hi,

Port am Switch haben wir schon gewechselt, von 21 auf 22.
Den Switch haben wir noch nicht getauscht...

Gruß,

Thorsten
Mitglied: aqui
aqui 10.03.2017 um 13:15:04 Uhr
Goto Top
Auf dem Switch sehe ich am Port zur Anlage immer ein Duplex-Mismatch.
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 !
Mitglied: Thorsten85
Thorsten85 10.03.2017 um 13:22:21 Uhr
Goto Top
Moin,

also der Port am Switch klemmt mit 1m Kabel direkt an der Anlage, welche laut Agfeo 100HDx hat.
Habe ich auch am Switch so eingestellt...same shit

Oder meinste der Fehler könnte auch noch woanders im Netzwerk liegen?

Ich habe nun noch einmal bei Agfeo schriftlich nachgefragt wie deren Karte/Port eingestellt ist.

Danke schon mal.
Mitglied: aqui
aqui 10.03.2017 aktualisiert um 13:33:57 Uhr
Goto Top
Oder meinste der Fehler könnte auch noch woanders im Netzwerk liegen?
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.
Ich habe nun noch einmal bei Agfeo schriftlich nachgefragt wie deren Karte/Port eingestellt ist.
Wieso muss man das "nachfragen" ?? Das sieht doch jeder Laie im GUI des Anlagen Setups in den Einstellungen der Netzwerkparameter ?!
Mitglied: Thorsten85
Thorsten85 10.03.2017 um 13:35:53 Uhr
Goto Top
Müsste ich mal testen mit dem kleinen Dummswitch.

Auf der TK-Anlage kann ich leider nix am Port einstellen aber einen Versuch ist es Wert.

Danke.
Mitglied: aqui
aqui 10.03.2017 aktualisiert um 13:43:35 Uhr
Goto Top
Auf der TK-Anlage kann ich leider nix am Port einstellen aber einen Versuch ist es Wert.
Traurig face-sad
Hat die nichtmal ein CLI oder einen Kommando Prompt bei dem das möglich ist ?!
Versuchs erstmal mit dem "Zwischenswitch".
Mitglied: chgorges
chgorges 10.03.2017 um 17:32:30 Uhr
Goto Top
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
Mitglied: Thorsten85
Thorsten85 10.03.2017 um 17:44:30 Uhr
Goto Top
Hi,

1) Es ist ein HP/Arbua Procurve 2530 an dem die TK-Anlage hängt. Da hinter kommen noch zwei weitere 2530 an denen jeweils ein paar Telefone angeschlossen sind. (Insgesamt 8 VoIP Telefone)

2) OK

3) Klar ist 100HDx von mir aus OK, nur woher dann die Aussetzer?

4) Warum? Bzw. wo siehst du da ein Problem?

Danke!
Mitglied: chgorges
chgorges 10.03.2017 um 17:57:27 Uhr
Goto Top
Zitat von @Thorsten85:

Hi,

1) Es ist ein HP/Arbua Procurve 2530 an dem die TK-Anlage hängt. Da hinter kommen noch zwei weitere 2530 an denen jeweils ein paar Telefone angeschlossen sind. (Insgesamt 8 VoIP Telefone)

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.

2) OK

3) Klar ist 100HDx von mir aus OK, nur woher dann die Aussetzer?

Werden wir sehen.

4) Warum? Bzw. wo siehst du da ein Problem?

- 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.
Mitglied: Thorsten85
Thorsten85 10.03.2017 um 18:07:14 Uhr
Goto Top
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.


2x HP ProCurve Switch 2530-24G-PoE+, 28-Port, managed (J9773A)
1x HP ProCurve Switch 2530-48G-PoE+, 52-Port, managed (J9772A)

Dazu noch ein paar 8 Port von HP, da ist aber kein Telefon angeschlossen.

4) Warum? Bzw. wo siehst du da ein Problem?

- 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 macht es keinen Sinn, nehm ich raus.
Mitglied: chgorges
chgorges 10.03.2017 um 18:36:02 Uhr
Goto Top
Zitat von @Thorsten85:
2x HP ProCurve Switch 2530-24G-PoE+, 28-Port, managed (J9773A)
1x HP ProCurve Switch 2530-48G-PoE+, 52-Port, managed (J9772A)

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?
Mitglied: shadynet
shadynet 12.03.2017 um 13:19:20 Uhr
Goto Top
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.
Mitglied: Thorsten85
Thorsten85 13.03.2017 aktualisiert um 11:41:06 Uhr
Goto Top
Zitat von @chgorges:


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.


An der TK kann ich nix einstellen, das ist anscheinend fest vorgegeben.

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

Muss ich mal prüfen, ist wahrscheinlich nicht der aktuellste Stand.

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

Nein, ist auch etwas schwierig, die Probleme sind nicht dauerhaft an einem Gerät bzw. Arbeitsplatz aus zu machen...


Zitat von @shadynet:

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 kann da leider nichts einstellen...
Mitglied: chgorges
chgorges 13.03.2017 um 11:54:56 Uhr
Goto Top
Zitat von @Thorsten85:

Zitat von @chgorges:


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.


An der TK kann ich nix einstellen, das ist anscheinend fest vorgegeben.

Ich meine den Switchport, an welchem die TK angeschlossen ist face-smile
Mitglied: Thorsten85
Thorsten85 13.03.2017 um 12:05:24 Uhr
Goto Top
Zitat von @chgorges:

Zitat von @Thorsten85:

Zitat von @chgorges:


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.


An der TK kann ich nix einstellen, das ist anscheinend fest vorgegeben.

Ich meine den Switchport, an welchem die TK angeschlossen ist face-smile

Achso, wir haben jetzt erstmal nen dummen Switch dazwischen geklemmt und testen damit.
Mitglied: shadynet
shadynet 13.03.2017 um 22:20:37 Uhr
Goto Top
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.
Mitglied: Thorsten85
Thorsten85 14.03.2017 um 11:31:49 Uhr
Goto Top
Zitat von @shadynet:

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.

Also ich kann da nix einstellen...
Wenn du das kannst, sag mir bitte wo, denn selbst der Agfeo Support sagt, das die Einstellung aktuell nicht änderbar ist.

Vielen Dank.
Mitglied: aqui
aqui 14.03.2017 um 12:26:37 Uhr
Goto Top
Fazit: Neuen und vernünftigen Switch kaufen und kein HP Mist face-wink
Mitglied: Thorsten85
Thorsten85 14.03.2017 um 12:47:41 Uhr
Goto Top
Der Switch macht bis jetzt nen guten Job und HP hat bis jetzt immer ausgereicht... face-wink

Wir haben entdeckt, dass einige Telefone, obwohl das Gespräch eigentlich beendet ist, die Verbindung weiterhin aufrecht erhalten.

Agfeo arbeitet dran...
Mitglied: nova14
nova14 05.04.2017 um 14:57:06 Uhr
Goto Top
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!
Mitglied: Thorsten85
Thorsten85 05.04.2017 aktualisiert um 15:59:37 Uhr
Goto Top
Moin,

ich sehe schon, wir teilen tatsächlich unser Leid.

Wir haben in der letzten Woche Montag, die neueste Firmware installiert (1.12). Seit dem keine Fehler mehr, zumindest noch nicht.
Oft hatten wir 14 Tage Ruhe, dann gings wieder los.

AGFEO kennt das Symptom, nach einigen bösen Telefonaten stellte sich folgendes heraus:
Die "alten" ST40 IP beenden teilweise die Telefonate nicht richtig. D.h. obwohl aufgelegt wurde sendet das ST40 dauerhaft UDP Pakete, irgendwann wird das zu viel und nix geht mehr. Zumindest an den IP Telefonen und bei Dect.

Wir haben seit Wochen Wireshark laufen und wenn die Probleme auftreten, kann ich z.B. Nachts stundenlange "Telefongespräche" sehen.

Als Workaround haben wir die Anlage dann eine zeitlang 1-2mal die Woche, abends neugestartet.

Gruß, Thorsten

Edit: Und ja, das ist wirklich unterirdisch. Vor allem die Antworten die oft vom Support kommen. Wir haben nun die dritte Anlage beim Kunden, weil erstmal immer ein Hardware defekt vermutet wurde. Uns wollte man nicht glauben.
Mitglied: nova14
nova14 05.04.2017 um 16:21:14 Uhr
Goto Top
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.
Mitglied: aqui
aqui 05.04.2017 aktualisiert um 16:27:26 Uhr
Goto Top
durchweg Single Collision Frames, Late Collisions und Excessive Collisions.
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 face-smile
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.
Mitglied: chgorges
chgorges 05.04.2017 aktualisiert um 16:56:33 Uhr
Goto Top
Zitat von @aqui:
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.

Dein HP-Gehate nervt ;)

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 ??

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.
Mitglied: Thorsten85
Thorsten85 05.04.2017 aktualisiert um 16:54:48 Uhr
Goto Top
Zitat von @nova14:

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.

Nein, da wurde nichts berechnet, wäre ja noch schöner. Wir haben nach dem ersten Tausch bereits drauf hingewiesen, dass es aus unserer Sicht kein Hardware defekt ist.


Zitat von @aqui:

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.

Haben wir direkt nach dem ersten Tausch versucht, keine Besserung. Wie aber bereits erwähnt, die Collisions sind nicht das Problem. Sondern wohl eher die nicht enden wollenden Telefonate ;)
Mitglied: aqui
aqui 05.04.2017 aktualisiert um 17:04:03 Uhr
Goto Top
Deine HP-Gehate nervt ;)
Es ist aber ja leider die nackte Wahrheit und außerdem ist ja auch Cisco genannt... face-wink Ging ja auch nur darum einmal die Problematik zu erklären.
Klar gehen die Collisions hoch, das ist netzwerkbasiert.
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.
Wo Halbduplex, da Collisions
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.
selbst bei festeingestellten Ports massiv Collisions verursachen und trotzdem einwandfrei funktionieren.
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.
Mitglied: chgorges
chgorges 05.04.2017 aktualisiert um 17:24:02 Uhr
Goto Top
Zitat von @aqui:
Da wo diese Counter 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 wenig verstanden hast.

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

Auch das ist wieder barer 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.

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).

Auch das ist wiede rnur halbrichtig, denn die Collision Warunung kommt vom Cisco CDP und hat dich vermutlich verwirrt.

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.

Die Collisions steigen 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.

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 ...

Insofern resultiert daraus das dein laienhaftes Statement das das "kein Fehler" ist natürlich schlicht falsch ist.

Siehe Link oben.

Wenn du mal in Ruhe nachdenkst solltest du das auch selber einsehen...oder nochmal die Grundlagen über Twisted Pair Ethernet nachlesen !

Die sind mir alle bekannt...

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.

Danke.
Mitglied: Thorsten85
Thorsten85 24.04.2017 um 17:30:41 Uhr
Goto Top
Hallo zusammen,

nach nun 3 Wochen ohne Probleme, treten nun die ersten Symptome wieder auf.
Am Donnerstag haben wir den "Sniffer" abgebaut und den dummen Switch zwischen TK und "Core-Switch" abgebaut.
Heute fängt der Sch*** wieder an...

Von Agfeo kam bis jetzt nichts hilfreiches.

Gruß,
Thorsten
Mitglied: nova14
nova14 24.04.2017 um 19:10:23 Uhr
Goto Top
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
Mitglied: Thorsten85
Thorsten85 25.04.2017 um 09:51:40 Uhr
Goto Top
Hi,

guter Ansatz um zumindest den Kunden ruhig zu halten. Das kann aber nicht die Lösung sein.
Wir haben gestern Abend/Nacht die Anlage neugestartet, das bringt aktuell leider keinen Erfolg mehr. Erst der Neustart der Telefone oder ein komplettes Ausschalten der Anlage behebt das Problem.

Hab jetzt nochmal ne nette Mail an Agfeo geschrieben.

Gruß, Thorsten