Pingverluste 54-g

[schibulski]

Hallo Zusammen,

wir haben hier an der Uni jetzt insgesamt vier L-54g Access-Points in Betrieb. Auf jedem ist die aktuelle FW 4.02 installiert und der Bridgemode ist aktiv.

Fehlerbeschreibung:

1 - Pingverluste wenn das LAN-Interface angepingt wird. Diese Pingverluste sind phasenweise (sprich 100 pings laufen durch, die naechsten 5 bis 10 bleiben unbeantwortet, das Interface antwortet wieder, es kommt wieder zu einer Phase von Pingausfaellen, usw.)

2 - Dieses Verhalten tritt nicht auf, wenn der Client von dem gepingt wird ueber WLAN mit dem AP direkt verbunden ist.

3 - Ist der AP nicht anpingbar, so sind an dem AP angemeldete Clients weiterhin pingbar. (Dies bestaetigt indirekt Punkt 2 - es wird wohl weiterhin brav gebridget, der angemeldete Client bekommt von den Ausfaellen nichts mit (was natuerlich sehr positiv ist))

4 - Wir konnten dieses Verhalten standortunabhaengig und mit verschiedenen Routern und Switchen (Xylan und Nortel Passport) nachvollziehen.

5 - Die vier APs fallen unabhaengig voneinander aus.

Nach einem Blick in trace + ip-router fiel auf das die Ausfaelle mit Multicast Anfragen zusammenfielen. (UPnP 239.255.255.250:1900) Daraufhin wurde der Multicastbereich in der Firewall komplett gesperrt. Die Pingverluste reduzierten sich, blieben aber trotzdem erhalten.

Jetzt meine Frage. Gibt es irgendeinen automatischen Mechanismus der das LAN Interface fuer kurze Zeit deaktiviert (und dieses "Felhverhalten" erklaeren koennte) und wenn ja welcher und wie ist dieser zu umgehen (Im Syslog sieht man keinen Eintrag der auf IDS oder eine DOS Attacke hindeutet)

Insgesamt ist dieses Verhalten sehr aergerlich, da es ein vernuenftiges Administrieren und Monitoring der Buechsen verhindert. Ich hatte mir mal den Spass erlaubt ueber zwei Tage die Kisten anzupingen und hatte Pingverluste von 10 Prozent.

Dieses Verhalten korrespondiert im uebrigen mit folgenden Thread:

http://www.lancom-forum.de/topic,361,-H ... 4g%3F.html

Das Geraet im Lanmonitor verabschiedet sich natuerlich fuer kurze Zeit, da es vom Lanmonitor nicht mehr erreicht werden kann.

Mit freundlichen Gruessen,

Jupp

[alf29]

Moin,

eventuell ist einfach die Broadcast-Last bei Euch auf dem Netz zu hoch. Broadcasts
muß der AP in die Funkzelle weiterreichen, und wenn dort Clients mit aktivierten
Power-Saving stehen, muß der AP die Pakete bis zum nächsten Beacon zwischenpuffern.
Die Menge der Paketpuffer im Gerät ist aber beschränkt...

Ansonsten kann's sich eventuell lohnen, die Basic-Rate auf z.B. 11MBit heraufzusetzen,
das ist auch die Rate, mit der die Broadcsts auf das WLAN herausgeschickt werden.

Gruß Alfred

[schibulski]

Hallo Zusammen,

erst einmal recht herzlichen Dank fuer die Antwort. Jetzt habe auch ich endlich Zeit gefunden mich um die Loesungsvorschlaege zu kuemmern.

eventuell ist einfach die Broadcast-Last bei Euch auf dem Netz zu hoch. Broadcasts
muß der AP in die Funkzelle weiterreichen, und wenn dort Clients mit aktivierten
Power-Saving stehen, muß der AP die Pakete bis zum nächsten Beacon zwischenpuffern.
Die Menge der Paketpuffer im Gerät ist aber beschränkt...

Die Pingverluste tauchen auch auf, wenn keine Clients am AP angemeldet sind.

Eine globale Statistik findet sich in der Paket-Transport-Statistik. Ich habe den AP resetet und eine halbe Stunde laufen lassen (in der Zeit war er zweimal fuer einen kurzen Augenblick (ca. 30 sekunden) nicht erreichbar), das Ergebnis findet sich hier.

Code: Alles auswählen

Paket-Transport-Statistik
Ifc Rx-Pakete Tx-Pakete Rx-Broadcasts Rx-Multicasts Rx-Unicasts Tx-Broadcasts Tx-Multicasts Tx-Unicasts 
LAN-1 29116 14215 10113 1802 13451 59 239 13917 

Das Verhaeltnis von Rx-Pakete zu Rx-Broadcasts betraegt ungefaehr Eins zu Drei, genau gesprochen 168 Broadcast Pakete in der Minute. Ist das ausreichend um das Interface in die Knie zu zwingen?

Ich habe mich ueber WLAN an den AP angemeldet und gesniffert (Habe also hinter dem AP gesessen). Bei den Ausfaellen konnte ich keine Auffaelligkeiten (Broadcaststuerme oder aehnliches) feststellen.

Kann ich es irgendwo im AP sehen, ob der Packetpuffer des LAN Interfaces ueberlaueft?

Ansonsten kann's sich eventuell lohnen, die Basic-Rate auf z.B. 11MBit heraufzusetzen,
das ist auch die Rate, mit der die Broadcsts auf das WLAN herausgeschickt werden.

Hat leider auch nicht geholfen.

Ansonsten haben wir natuerlich ein grosses Wireless Netz mit 80 APs und in Hoch-Zeiten bis zu 100 Clients. Auffallend ist nur, das die nicht Lancom APs (es duerften so um die 75 sein) der gleichen Broadcastlast ausgesetzt sind wie die Lancom 54g, und dieses Fehlverhaten nicht zeigen. Haben die 54g wirklich so einen kleinen Puffer, dass Sie den Dienst versagen, oder ist noch eine andere Erklaerung moeglich.

Mit freundlichen Gruessen,

Jupp

[alf29]

Moin,

nein, so eine Last sollte den AP eigentlich nicht in
Schwierigkeiten bringen (wenn da keine extremen
Bursts dabei sind).

Was das jetzt sein könnte, weiß ich aber so auch nicht,
ich würde mal parallel seriell auf das Gerät gehen
und einen ARP/ICMP-Trace mitlaufen lassen.

Gruß Alfred