fenris14
Goto Top

Gigaset N870 Lan Sync

Hallo,

ich bräuchte Hilfe beim Troubleshooting für ein Gigaset DECT N870, denn ich vermute das ich irgendwas übersehe.

Kurz zur Historie: Vor mehr als 3 Jahren eingeführt, lief es Anfangs unauffällig. Keine Probleme, keine Asynchronität der DECT-Zellen. Letztes Jahr mit einem ersten Update seit Einführung, ging das Drama los. Ja ja, never change a Running System und so... ein Downgrade wäre möglich gewesen, war aber nicht drin, weil die neueren Telefone sonst nicht unterstützt wurden. Das Problem war das die Basisstationen täglich mehrmals Asynchron wurden. DIe Updates von Gigaset verschlimmerten das Problem sogar. Zu der Zeit gab es riesige Threads auch in anderen Foren mit massenhaft Problemen. Im Endeffekt konnte ich es nur eindämmen, in dem ich die Basisstationen statisch IP-Adressen vergeben habe. Danach wurden die Asyncs weniger. Es war dann in einem erträglichen Maß, das alle 14 Tage mal eine Basisstation Async ging. Ich habe das dann irgendwann auf Gigaset und der schlechten Firmware geschoben.

Jetzt werden die Asyncs und die Gesprächsabbrüche in den letzten Tagen immer mehr. Ich kann es mir einfach nicht erklären. Das letzte Update Release 2.54.0 ist eingespielt seit mehreren Wochen. Das es immer nur an der Firmware liegt, wäre einfach und würde auch den Bankrott von Gigaset erklären, aber es wäre auch irgendwo zu einfach.

Zum DECT-System:

  • 14x Basisstationen N870 (Lan Sync, 1x Master, 1x LAN Master)
  • verschiendene originale Mobilteile (SL750H, S650H, S700H, SL800H Pro) ca. 38 Stück
  • Die Basisstationen befinden sich alle im selben VLAN

Zur Switch-Infrastruktur:

  • Core ist ein ICX7750 Layer3 (Commscope vormals Ruckus vormals Brocade)
  • Access-Switches an denen DECT-Zellen (aber auch andere Endgeräte) hängen, ICX7250 und ICX7450
  • untereinander mit 10Gbit LACP LAG verbunden

Fehlersuche:

Als erstes fällt auf das manche DECT-Zellen öfters Async gehen als andere, was vermuten lässt das es eine Überlastung ist. Ist aber nicht der Fall, weil zu keinem Zeitpunkt überhaupt soviele Mobilteile da in der Nähe sind um die DECT-Zelle auch nur Ansatzweise auszulasten. Auch die 10 gleichzeitigen Gespräche pro Zelle sind nicht erreichbar, weil das nicht mal über der Telefonanlage insgesamt erreicht wird.

screenshot 2023-10-06 134106

Ich habe mir dann entsprechende Zelle AP10 vorgenommen...

screenshot 2023-10-06 134251

Das es immer da wieder Peaks gibt, halte ich für normal. Spricht halt dafür das es verwendet wird und das Gespräche drüber gehen. Das er da mal ein Paket eingehend gedroppt hat, finde ist jetzt noch kein Beinbruch. Zumal man auch nicht weiß warum.

Im Log steht immer wieder, soetwas z.B.:

Oct  6 11:42:22.441 dlsd[30057]: >>> ptp-pd overshot/peak detected: obsrv-act[ns]:      41049 | obsrv-mean[ns]:      31239 | delta[ns]:       9810 | delta-rel[%]:         31

Bei der Qualitäts-Statistik wird es dann richtig gruselig...

SYS ----- : dls-mode -, syn-mode -, lan-m ----, ptp-m ----, -- state ----
          :     client,        LAN,        OFF,        OFF,    SYNC (80)
DBC ----- : dm-id ----, cluster --, cl-mask --, level ----, -- Info -----
          : 0x1035db44,          1, 0x000000ff,          2,    0xb081e000
PTP ----- : gm-id ----------------, domain ---, -------------------------
          :     589ec6.fffe.2122c1,         21
DLS ----- : m-id -----------------, ----------, DS - : pari -----, rpn --
          :     589ec6.fffe.2122c1,           ,        0x1035db44,   0x03
QUALITY - : ----------, ----------, ----------, ---------- --------------
qa cnts   : async ----, tias -----, o-thr-exc , d-thr-exc , q-idx-st ----
          :         11,        160,       3938,         14,         99.00
qa stats  : ptp-pd ---, ptp-d ----, dls-d ----, tias-max -, q-idx-lt ----
stddev    :        377,        241,        474,       2056,         96.57
TIMIMG -- : ----------, ----------, ----------, ---------- --------------
CURRENT - : ptp-pd ---, ptp-d ----, dls-d ----, osc-idx --, -------------
[ns]      :      31058,         57,       -180,        157
STATS --- : rms ------, min ------, max ------, mean ----- +/- stddev ---
p(av)[ns] :  160000931,  160000897,  160000962,  160000931 +/-         15
frq[MHz]  :  13.823920,  13.823917,  13.823922,  13.823920 +/-   0.000001
osc-idx   :        156,        156,        157,        156 +/-          0
ptp-pd[ns]:      31080,      30685,      31568,      31079 +/-        183
ptp-d[ns] :        192,       -426,        406,         26 +/-        190
dls-d[ns] :        163,       -439,        425,         -0 +/-        163
eof dls-stats ===========================================================

Abgesehen von den 11 Asyncs, "o-thr-exc" massiv erhöht innerhalb von wenigen Wochen. Der Counter sagt aus, wie of er über 500ns geschossen ist. Das ist die magische Grenze bei Gigaset bis zu der das System als funktional gilt. Allerdings trifft es nur zu, wenn es über einen längeren Zeitraum festgestellt wird. Das "ptp-d" als rms nur 192ns hat, ist davon auszugehen das immer nur einen kurzen Peak gibt. Das selbe Spiel bei "dls-d" wo die magische Grenze bei 1000ns liegt, aber eben auch nur über einen längeren Zeitraum.

https://teamwork.gigaset.com/gigawiki/pages/viewpage.action?pageId=10148 ...

Komischerweise habe ich durchweg ein Lan Sync Quality "q-id-lt" von weit über 90%. Dennoch kommt es immer wieder zu Asychronitäten.

Dann dachte ich das es an Kupfer-Kabeln zu dem DECT liegen kann: Weder am Switch noch am Gerät wurden Kabelfehler aufgezeichnet.

RX packets:87760063 errors:0 dropped:2346310 overruns:0 frame:0

Warum er hier soviele Pakete droppt, ist mir schleierhaft. Ob das normal ist, weiß ich ebenfalls nicht. Ich kann hier nur vermuten: Doppelte übertragende PTP oder Sync-Pakete, solange bis er antwortet.

Am Switch sieht es so aus...

GigabitEthernet1/1/31 is up, line protocol is up
  Port up for 51 day(s) 1 hour(s) 30 second(s)
  Hardware is GigabitEthernet, address is 
  Configured speed auto, actual 100Mbit, configured duplex fdx, actual fdx
  Configured mdi mode AUTO, actual MDI
  EEE Feature Disabled
  Untagged member of L2 VLAN 30, port state is FORWARDING
  BPDU guard is Disabled, ROOT protect is Disabled, Designated protect is Disabled
  Link Error Dampening is Disabled
  STP configured to ON, priority is level0, mac-learning is enabled
  MACsec is Disabled
  Flow Control is config enabled, oper enabled, negotiation disabled
  Mirror disabled, Monitor disabled
  Mac-notification is disabled
  VLAN-Mapping is disabled
  Not member of any active trunks
  Not member of any configured trunks
  Port name is Gigaset DECT
  IPG MII 96 bits-time, IPG GMII 96 bits-time
  MTU 1500 bytes
  MMU Mode is Store-and-forward
  300 second input rate: 1904 bits/sec, 2 packets/sec, 0.00% utilization
  300 second output rate: 8784 bits/sec, 6 packets/sec, 0.00% utilization
  93485246 packets input, 13756771907 bytes, 0 no buffer
  Received 2612 broadcasts, 11811 multicasts, 93470823 unicasts
  0 input errors, 0 CRC, 0 frame, 0 ignored
  0 runts, 0 giants
  190245703 packets output, 32966867418 bytes, 0 underruns
  Transmitted 597523 broadcasts, 95619127 multicasts, 94029053 unicasts
  0 output errors, 0 collisions
  Relay Agent Information option: Disabled
  Protected: No
  MAC Port Security: Disabled

UC Egress queues:
Queue counters    Queued packets    Dropped Packets
         0            18668529                   0
         1                   0                   0
         2             1551408                   0
         3                   0                   0
         4             1693856                   0
         5            27656327                   0
         6               34023                   0
         7            56261478                   0


MC Egress queues:
Queue counters    Queued packets    Dropped Packets
         0              311769                   0
         1              675424                   0
         2               11109                   0
         3            83381781                   0

Der Switch-Port langweilt sich im Großen und Ganzen.

Eine Aufzeichnung des Traces über längeren Zeitraum habe ich gemacht, aber führt immer zu nichts, weil man nie genau sagen kann wann genau die DECT-Zelle async wird. Der Zeitraum kann mehrere Minuten andauern zwischen "es wurde erkannt das async ist" und "Neu synchronisieren" in der Zeit sind tausende Pakete eingegangen und man weiß nicht nach was man suchen soll.

Hat jemand eine Idee wonach man suchen könnte um dem Problem auf die Spur zu kommen? Wenn es ein Firmware-Problem ist, was ich nicht ausschließen kann, wie kann ich es dennoch optimieren damit es wieder in einem erträglicheren Rahmen läuft?

Gruß

Content-Key: 61687433117

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

Printed on: July 19, 2024 at 09:07 o'clock

Member: NordicMike
NordicMike Oct 06, 2023 at 12:53:07 (UTC)
Goto Top
Schau mal ob du die Empfangsstärke findest, also die dB Werte zwischen den Stationen. Wenn diese grenzwertig niedrig sind, reichen kleinste Änderungen, dass es zu einem Fehler kommt.
Member: Fenris14
Fenris14 Oct 06, 2023 at 13:04:53 (UTC)
Goto Top
Die Sendeleistung würde ja nur Sinn machen, wenn sie sich darüber auch Synchronisieren. Was ja nicht der Fall ist, da explizit LAN Sync verwendet wird.

Einzige Einstellung die ich finden konnte, war die Reduzierung der Sendeleistung bei der Verwendung einer externen Antenne:

screenshot 2023-10-06 150233

Es stellt sich natürlich die Frage wie die Mobilteile sich verhalten. Bleiben sie lange an einer DECT-Zelle angemeldet oder bleiben da kleben, auch wenn die Stärke des Signals schon eher schlecht ist, oder springen sie zeitig zur nächst besseren Signalquelle. Leider kann man das über die Werkzeuge die einem Gigaset mit gibt, nicht herausfinden. Zumindest habe ich bisher nichts gefunden.
Member: tikayevent
tikayevent Oct 06, 2023 updated at 13:28:22 (UTC)
Goto Top
Ist dein komplettes Switch-Setup PTP-tauglich?

Wir setzen die großen Netgear-Switches ein und da gibt es bei manchen Switchtypen Einschränkungen für den PTP-Betrieb.

Da wir damals in einem unserer Objekte PTP nicht sauber laufen lassen konnten, sind wir auf die Syncronisation per Luftschnittstelle zurückgewechselt.

Das Problem zeigt sich beim Handover. Nur in diesem Fall müssen die Basen syncronisiert sein. Wenn du zwischen zwei Basen wechselst, die in dem Moment nicht synchronisiert sind, bricht die Verbindung mit hoher Wahrscheinlichkeit ab, sobald du den Bereich der abgebenden Zelle verlässt.
Member: Fenris14
Fenris14 Oct 06, 2023 updated at 13:46:01 (UTC)
Goto Top
Das ist mir gegenwärtig nicht ganz klar muss ich gestehen. Laut diesem Eintrag im Configuration Guide:

https://docs.commscope.com/bundle/fastiron-08095-managementguide/page/GU ...

... soll es für alle Switches die ich hier im Einsatz habe und die Version 08095 haben, eine Option "ptp-clock" geben. Gefunden habe ich diese Option zum Aufrufen bisher nur beim ICX7750. Aber dort ist es nicht aktivierbar, weil es generell für einen Stack nicht supported wird. Bei den anderen, ICX7250 und ICX7450, ist es nicht auswählbar.

Sollte mich aber wundern, wenn solche Switches aus dem hohen Preissegment das nicht voll supporten.

Es ist ja auch nicht so das es dauerhaft nicht funktioniert. Ich kann mit dem Telefon durch das gesamte Haus spazieren und habe keine Probleme. Aber sporadisch, jetzt eben häufiger, verlieren die Basen ihren Sync.

Sync per Luftschnittstelle hatten wir ausgeschlossen, weil es sonst wegen der dicken Granitwände zu Problemen kommt, wenn man in ein anderes Stockwerk geht. Allerdings könnte man das dennoch, wenn man jetzt einmal dabei ist, testen.
Member: Fenris14
Fenris14 Oct 06, 2023 updated at 14:00:39 (UTC)
Goto Top
Aber das scheint wirklich das Problem zu sein. LAN Sync ist nicht der Standard. Per Default ist es DECT, also Luftschnittstelle.

Es gibt nur ein Handvoll Switches, selbst bei den großen Herstellern die scheinbar PTP-tauglich sind. Bei Cisco sind es paar wenige Catalysten/Nexus, bei Brocade nur bei den Datacenter also ICX7750 aufwärts... aber nur dann wenn sie sich in keinem Stack befinden.

Hier eine scheinbar nicht ganz aktuelle Liste:

https://en.wikipedia.org/wiki/List_of_PTP_implementations

Behelfen kann man sich wohl, entweder mit dedizierter Hardware physisch getrennt, also auch kein VLAN oder eben DECT-Sync. Auch mit speziellen PTP-Switches, aber eben auch nur getrennt. Da gibt es paar Hersteller wie z.B. Perle oder FibroLAN.

Es ist bei mir scheinbar auch nur solange gut gegangen, weil meine Switches das Problem mir dem QoS sehr gut kaschieren konnten. Aber das geht natürlich nur solange wie die Bandbreite und Anzahl der Pakete überschaubar bleibt. Dadurch das Unternehmen auch gewachsen ist, wird es das Problem sein.

Das ist gerade eine echte Offenbarung. Mir war gar nicht bewusst das da so ein Zauber drum gemacht werden muss.
Member: tikayevent
tikayevent Oct 06, 2023 at 16:06:01 (UTC)
Goto Top
IP und Ethernet nicht echtzeitfähig und das ist schon lange bekannt.

Gab es früher Probleme mit der Sync. über die Luftschnittstelle oder wurde es einfach nur ausgeschlossen, weil man meinte, das es nicht funktioniert?
Wir haben mit fünf Basen 15000m2 Betonbau samt Außenbereich bespaßt, via Luftschnittstelle, weil die LAN-Sync. Probleme gemacht hat. Zu dem Zeitpunkt hatten wir noch Avayaswitches im Einsatz (sind in der gleichen Preisregion wie deine Switches unterwegs) und die kamen mit dem Synctraffic gar nicht klar.

Selbst die DECT-TDM-Systeme haben in der Regel die Basen untereinander via Luftschnittstelle syncronisiert, weils einfach besser funktionierte als über den Kabelweg.
Member: Fenris14
Fenris14 Oct 06, 2023 at 16:13:10 (UTC)
Goto Top
Nochmal weiter recherchiert zu ICX Switches, falls einem das auch mal auf die Füße fällt:

Ab Version 10.0.00 unterstützen es nur noch ICX7550, ICX7650 und ICX7850. Mit hoher Wahrscheinlichkeit auch die neuen ICX8200er.

Bis Version 08.0.95: ICX7150 und ICX7850.

Das deckt sich mit anderen Herstellern, da sind immer nur eine sehr überschaubare Menge an Modellen wirklich tauglich für PTP.

Ansonsten kann man nur Switch Hops reduzieren oder eben DECT Sync verwenden. Ich habe letzteres gerade konfiguriert. Mal sehen wie es laufen wird.
Member: Fenris14
Fenris14 Oct 06, 2023 updated at 16:27:02 (UTC)
Goto Top
Gab es früher Probleme mit der Sync. über die Luftschnittstelle oder wurde es einfach nur ausgeschlossen, weil man meinte, das es nicht funktioniert?

Ich kann mich leider nicht mehr genau erinnern. Ich habe mir sagen lassen das wir anfangs DECT Sync hatten und dann wegen Problemen auf LAN umgestiegen sind.

Wir haben hier 14 Stück für 5 Etagen. Grob 4500m² + 2000m² Außenbereich. Aber eben viele Mobilteile, in Kombination mit vielen Störquellen. Die Störquellen sind vielfältig: Angefangen von einem Grundstück mitten in der Stadt, zu medizinischen Geräten, hinzu Treppenaufgängen die sehr Massiv gebaut sind und so einige Signale wegschlucken. Selbst einige Zwischenwände sind aus 80er Ziegelwand. Dazu noch teilweise Feuerschutztüren. Da hatten wir in einem Raum auch explizit Probleme, weshalb uns auch da LAN Sync seitens Gigaset empfohlen wurde. Auch haben wir einen Fahrstuhl, da verliert man immer mal wieder das Signal.

Wir hatten vorher eine Elmeg Anlage die sogar von Gigaset mit projektiert wurde, die aber letztendlich überhaupt nicht lief. Wir haben dann alles original Gigaset Basen genommen und die an die projektierten Stellen angeschlossen. So wie es Gigaset ausgeleuchtet hatte.

Aber Ja, im Nachhinein haben wir es teilweise etwas zu gut gemeint mit der Anzahl der DECT-Zellen.