[Problem] snom 720/760 MegaBug bei Mischbetrieb von 10/100 Mbit/s Ethernet und Gigabit-Ethernet

[al3x]

Hallo liebe snom community,

ich möchte euch kurz über ein großes Problem mit den snom 720/760 berichten.
Bei meinem Arbeitgeber setzen wir seit Dezember letzten Jahres snom 720 Geräte ein.
Inzwischen ist die Anzahl der Geräte auf 120 Stück gewachsen, jedoch mit einem
momentanen Zuwachsstopp. Vereinzelt haben wir auch snom 760 Geräte zum Test.

1. Wir haben eine logische Trennung zwischen dem Daten- und VoIP-Netz durch VLANs.
2. Unsere Infrastruktur ist noch im Bereich der Edge-Ports vorwiegend mit 10/100 MBit/s PoE-fähigen Ports ausgestattet.
3. Aufgrund von Kostenersparnis in unserer strukturierten Verkabelung sind die PC's über die Telefone verbunden.
4. Telefone sind im tagged VLAN und PCs im untagged VLAN.
5. Zwischen PC und Telefon & Telefon und Switch herrscht Autonegotiation!
6. snom 720/760 Firmware Version im Test: 8.7.x.x bis zur 8.7.4.7 beta

Diese soeben genannten Aspekte sind die Ursache nun für folgendes Phänomen:
Ein Datentransfer von einer beliebigen Datei auf ein NFS- oder CIFS share ist entweder nicht möglich oder bricht auf eine
Datenrate von bis zu 100 kbit/s zusammen.
Das Problem ist nicht mit einer Flow Control oder Jumbo frame Einstellung am Switch zu lösen.

Unsere Erkenntnis:
- Bei einem Gigabit Edge-Port mit exakt der gleichen Ausgangssituation
- oder bei einem gemeinsamen Netz der Telefone und PCs, also keiner logischen Trennung durch VLANs, tritt das Phänomen nicht in Kraft.

snom hält sich mit dem Problem sehr verdeckt. Jedoch ist über uns seit nunmehr 3 Monaten diesbzgl. ein Bug bei snom offen.
Leider bisher ohne Ergebnisse. Mit anderen Worten snom tappt im Dunkeln.

 

[foschi]

Für eine (brauchbare) Fehleranalyse fehlen Deinem Posting ne Menge Infos. Was bezweckst Du also damit?

Grüße nach F!

 

[rappspeed]

Hi!

Ich habe gerade bei snom nachgehakt. Das Problem ist erkannt. Man wird sich mit Euch in Verbindung setzen.

Grüßle

Christian

 

[hhansen06]

Hatten bis vor kurzem ähnliche Probleme mit den 760ern ... Lösung war einfach: andere Telefone ...

 

[rappspeed]

Servus!

Kann ich da noch irgendwas für Euch tun oder habt Ihr in der Sache noch Fragen?

Grüßle

Chris

 

[al3x]

Hallo Foschi,

bevor ich üppige Details liefere und dem ein oder anderen Gehirnknoten verursache, wollte ich einfach das generelle Problem mit der Telefonserie von snom ansprechen.
Zweck des Ganzen ist einen Kanal zu finden um andere darauf aufmerksam zu machen und damit anderen vielleicht die irreführende Fehlersuche zu ersparen.
Also teile ich die Probleme
Wir bereits aber auch hier kommentiert, ist ja snom an der Ursache dran.

 

[snoman]

Ich habe das mal versucht nachzustellen.

1) 760 im VLAN 100
2) Am PC Port ein 821 ohne VLAN
3) 760 hängt an 100MBit Switch mit Autonegotiation

Systeminformationen zeigen auf dem 760:

Net Port: Connection Type: 100 Mbit Full Duplex
Status: connected

PC Port: Connection Type: 1000 Mbit Full Duplex
Status: connected

Systeminformationen zeigen auf dem 821:

Net Port: Connection Type: 1000 Mbit Full Duplex
Status: connected

PC Port: Connection Type:
Status: not connected

Wenn ich das richtig verstanden habe, ist das auch Ihre Konfiguration?

Ich habe dann mit iperf einen Bandbreitentest über eine Stunde laufen lassen und habe rund 50MBit gemessen zum 821. Ich bekomme das gleiche Ergebniss, wenn ich das 821 direkt an den Switch hänge. Ich kann somit keinen Unterschied feststellen.

Frage: Könnten Sie mal zwischen 2 PCs durch das Phone mit dem VLAN einen Test mit iperf laufen lassen. Als TCP und UDP. Und dann noch mal den PC am Switch direkt, um die Ergebnisse zu vergleichen.

 

[al3x]

Hi snoman,

bitte keinen Bandbreiten- bzw. Netzwerkgeschwindigkeitstest durchführen. Dieses Problem ist nicht mit iperf oder ähnlichen Testing-Tools nachzustellen.
Alles schon im Programm gehabt
Tatsache ist eben, dass gerade mit Protokollen wie SMB (CIFS) und NFS der Fehler kenntlich gemacht werden kann. Also eine triviale Geschwindigkeits-Messung mit UDP oder TCP-Paketen ist
nicht aussagekräftig. Mit iperf haben wir ohne VLAN die gleichen Werte wie mitVLAN erzielen können.
Zudem spreche ich hier vom snom 720/760. Bei dem Modell 821 habe ich keine Erfahrungswerte!
Eventuell kann man mit entsprechenden rsize und wsize Parametern den Fehler rekonstruieren, habe ich noch nicht ausprobiert.

 

[snoman]

Das 821 ist nur hinter dem 760 als iperf Zielgerät gewesen, um den PC zu simulieren, d.h. der Traffic geht durch das 760 mit dem VLAN durch, wie bei Ihnen beschrieben.

OK, Sie haben also das selbe Ergebnis, dass es mit Bandbreitentests nicht nachzuvollziehen ist. Das heißt es sind spezifische NFS und CIFS Probleme, die eventuell mit den Eigenheiten des jeweiligen Protokolls zu tun haben.

NFS ist standardmäßig UDP. Was CIFS benutzt weiß ich jetzt nicht. Haben Sie zum Test den NFS-Client auf dem PC mal auf TCP umgestellt? Nur um sicherzugehen, d.h. dass ein HTTP Download im Browser z.B. ohne Probleme und schnell geht?

 

[snoman]

Ich habe weitere Tests durchgeführt.

Ich habe jetzt einen Laptop mit 1000MBit hinter dem 760. Also:
1) 760 ist im VLAN 100 Prio 5
2) 760 NET Port ist connected zu 100Mbit Switch mit Auto-Negotiation
3) Laptop connected zum 720 PC Port mit 1000MBit Auto-Negotiation
4) Laptop ist in keinem VLAN

Ich habe dann in jeweiligen Tests NFS und CIFS Shares gemountet und jeweils ein 1G Datei in beide Richtungen kopiert. Bei NFS und CIFS lag der Transfer jeweils bei ca. 7-8 MB/s für beide Richtungen.

Ich kann somit auch per NFS/CIFS den Bandbreiteneinbruch nicht reproduzieren.

 

[al3x]

Hallo snoman,

vielleicht sollte ich nochmal die genaue Ausgangssituation beschreiben:

1. Das snom 720 ist über ein PoE-fähigen Edge-Port mit 100MBit/s an einem HP ProCurve Switch 2610-48-PWR (J9089A) verbunden
2. Zwischen snom 720 und dem Switch herrscht Autonegotiation und es wird 100MBit/s + Full Duplex ausgehandelt
3. Am Switch ist ein VLAN 3333 mit LLDP-MED und QoS Priority 6 für VoIP Telefone eingerichtet, alle Ports sind getagged
4. Für die PC's ist ein VLAN 10 angelegt, natürlich an den Edge-Ports untagged gesetzt
5. Ein PC ist am snom 720 per Gigabit mit Full Duplex verbunden
6. Nochmal festzuhalten, PC ist im VLAN 10 untagged und das snom 720 im VLAN 3333 tagged
7. Der Datentransfer einer Datei beispielsweise 1GB groß wird auf ein entferntes Netzlaufwerk gestartet, entweder als NFS oder CIFS
8. In der Konstellation tritt genau das besagte Phänomen auf

An dieser Stelle der Wichtigkeit halber nenne ich es wieder:
- Bei einem Gigabit Edge-Port mit exakt der gleichen Ausgangssituation
- oder bei einem gemeinsamen Netz der Telefone und PCs, also keiner logischen Trennung durch VLANs, tritt das Phänomen nicht in Kraft.

 

[snoman]

Den Unterschied zu meiner Konfiguration sehe ich nur im HP Switch.

2. Ist abgebildet.
3. Habe ich per Hand und nicht über LLDP gesetzt, sollte kein Unterschied machen.
4. Da es am HP Port getaggt/untagged wird, ist es für das Phone und PC transparent. Somit kann ich auch ein komplett untagged Netz hier nehmen. Das war mein Setup.
5. Ist abgebildet.

Hier müssen noch mehr Dinge reinspielen. Wie ist der Flow-Control zwischen Switch und Phone bzw. Phone und PC.

 

[al3x]

Hallo snoman,

also irgendwie drehen wir uns im Kreis herum. Das Problem ist bei uns jederzeit rekonstruierbar.
Egal ob nun CIFS oder NFS verwendet wird. Auch egal ob nun die LAN-Karte am Laptop/PC mit einem Chipsatz von INTEL, Broadcom oder Realtek ausgestattet ist.
Flow Control ist bei den HP Switches standardmäßig deaktiviert. Das ist auch bei uns so belassen.
Ob nun am Telefon Flow Control aktiv ist oder nicht, können wir nicht beeinflussen, jedoch muss beide Seiten dies auch unterstützen, sonst macht es ja keinen Sinn.
Genau das gleiche gilt auch zwischen PC und Telefon.
Mal so neben bei, wir haben auch Gigabit Telefone von einem anderen Hersteller, mit diesen wir noch nie solche Probleme hatten, in der gleichen Ausgangssituation!
Daher können wir das auch nicht so ganz nachvollziehen.

 

[snoman]

Gleich um eventuell den Eindruck entgegenzuwirken. Es geht nicht darum zu sagen, dass das Problem nicht existiert. Es geht darum die Teststellung zu bekommen, so dass wir es nachvollziehen können. Nur wenn wir es bei uns hinkriegen, können wir es fixen. Und das ist nur meine Aussagen, dass wir es bisher nicht hinbekommen haben. Irgendwo muss ja das Detail sein, was zur Zeit noch den Unterschied zwischen Ihrer Installation und unserer ist.

 

[snoman]

Wir habe jetzt eine Testumgebung mit einem HP ProCurve 2610-24/12-PWR genau so aufgebaut. Ich kann es aber immer noch nicht so nachvollziehen. Aber was mir aufgefallen ist:

1) Der PC zeigt bei Auto-Neg mit 1000MBits bei iperf eine asymmetrische Bandbreite, wenn iperf im Dualmodus betrieben wird. Wenn nur eine Richtung alleine getestet wird, tritt das Phänomen nicht auf. Ist dies bei Ihnen auch so? Z.B.

iperf -c 10.110.23.163 -i 1 -t 3600 -d
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to 10.110.23.163, TCP port 5001
TCP window size: 82.3 KByte (default)
------------------------------------------------------------
[  5] local 10.110.23.51 port 57339 connected with 10.110.23.163 port 5001
[  4] local 10.110.23.51 port 5001 connected with 10.110.23.163 port 38883
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0- 1.0 sec   652 KBytes  5.34 Mbits/sec
[  5]  0.0- 1.0 sec  5.75 MBytes  48.2 Mbits/sec
[  4]  1.0- 2.0 sec   506 KBytes  4.15 Mbits/sec
[  5]  1.0- 2.0 sec  5.62 MBytes  47.2 Mbits/sec
[  4]  2.0- 3.0 sec   495 KBytes  4.05 Mbits/sec
[  5]  2.0- 3.0 sec  5.50 MBytes  46.1 Mbits/sec
[  4]  3.0- 4.0 sec   536 KBytes  4.39 Mbits/sec
[  5]  3.0- 4.0 sec  6.25 MBytes  52.4 Mbits/sec
[  4]  4.0- 5.0 sec   568 KBytes  4.66 Mbits/sec
[  5]  4.0- 5.0 sec  6.75 MBytes  56.6 Mbits/sec
[  4]  5.0- 6.0 sec   530 KBytes  4.34 Mbits/sec
[  5]  5.0- 6.0 sec  5.75 MBytes  48.2 Mbits/sec

2) Wenn auf dem 760 der PC-Port mit 100MBit Full gesetzt wird, habe ich auch im unidirectionalen Test mit iperf eine schlechte Bandbreite. Ist das 760 eventuell so eingestellt?

3) Wenn auf dem 760 der PC-Port mit 100MBit Half gesetzt wird, sehe ich beide Probleme 1) + 2) nicht.

Könnten Sie den PC-Port mal auf 100 MBit Half setzen und gucken, ob es eine Veränderung gibt?

Ergänzung:
Man darf den PC nicht auf Auto-Neg stellen, wenn man den PC-Port des 760 fest auf 100MBit Full oder Half setzt, da dann laut Spec an dem PC immer Half gesetzt wird. Also man muss dann auch beim PC direct auf 100MBit Full oder Half setzen.

 

[al3x]

Hallo, wie bereits gesagt mit Iperf haben wir das Problem nicht nachstellen können. Aber wo sie es gerade sagen, Iperf wurde von uns noch nicht mit bidirektionaler Verbindung getestet bzw. im dualtest (-d). Bisher nur immer mit TCP oder UDP und mit mehreren Threads.
Zum wiederholten Male, grundsätzlich ist die Port-Einstellung bei uns immer in beiden Richtungen auf Autonegotiation konfiguriert.
Und völlig klar ist, wie Autonegotiation sich im Ethernet verhällt, das sollte man natürlich wissen.
Falls eine Gegenseite Autonegotiation nicht unterstützt oder abgeschaltet hat, kann die andere Gegenseite die Übertragungsgeschwindigkeit über "Parallel Detection" ermitteln. Eine Bestimmung des Duplex-Modus ist dabei aber nicht möglich! Daher wird immer Halb-Duplex ausgehandelt.

 

[snoman]

Da wir das Szenario bei uns so nachgestellt haben, mit der Ausnahme dass wir ein "HP ProCurve 2610-24/12-PWR" anstatt des "HP ProCurve 2610-48-PWR" benutzt haben, und den Effekt nicht gesehen haben, bleibt ja nur, was ich auch schon mal angesprochen habe, dass es im Protokoll liegen muss. Ich habe den Test in einer reinen Linuxumgebung durchgeführt, d.h. Server (NFS/Samba/CIFS) als auch Laptop liefen unter Linux. Ist es ihn Ihrem Fall auf beiden Seiten Windows oder gemischt Sever Linux und Windows Client?

 

[al3x]

In der bekannten Ausgangssituation:

Hallo snoman,

vielleicht sollte ich nochmal die genaue Ausgangssituation beschreiben:

1. Das snom 720 ist über ein PoE-fähigen Edge-Port mit 100MBit/s an einem HP ProCurve Switch 2610-48-PWR (J9089A) verbunden
2. Zwischen snom 720 und dem Switch herrscht Autonegotiation und es wird 100MBit/s + Full Duplex ausgehandelt
3. Am Switch ist ein VLAN 3333 mit LLDP-MED und QoS Priority 6 für VoIP Telefone eingerichtet, alle Ports sind getagged
4. Für die PC's ist ein VLAN 10 angelegt, natürlich an den Edge-Ports untagged gesetzt
5. Ein PC ist am snom 720 per Gigabit mit Full Duplex verbunden
6. Nochmal festzuhalten, PC ist im VLAN 10 untagged und das snom 720 im VLAN 3333 tagged
7. Der Datentransfer einer Datei beispielsweise 1GB groß wird auf ein entferntes Netzlaufwerk gestartet, entweder als NFS oder CIFS
8. In der Konstellation tritt genau das besagte Phänomen auf

An dieser Stelle der Wichtigkeit halber nenne ich es wieder:
- Bei einem Gigabit Edge-Port mit exakt der gleichen Ausgangssituation
- oder bei einem gemeinsamen Netz der Telefone und PCs, also keiner logischen Trennung durch VLANs, tritt das Phänomen nicht in Kraft.

ist Windows 7 mit 64 Bit und Linux (Ubuntu und Red Hat) als Test verwendet worden. Bei Windows mit CIFS und unter Linux mit NFS.
In beiden Fällen gleiches Phänomen.