P2P-Probleme zw. 1821n und L-321agn unter LCOS 8.82RU1

[Aragon]

Hallo,

meine P-2-P Verbindung baut sich sporadisch zwischen einem 1821n (Master) und einem der beiden L-321agn (Slaves) ohne für mich erkennbaren Grund kurz ab und anschliessend wieder auf. Die Geräte stehen im selben Gebäude in unterschiedlichen Etagen (Master 2.OG, Slave-3 im 3.OG und Slave-0 im EG mit einer max. Distanz zw. Master und Slave von ca. 20m mit Stahlbetonwänden/decken dazwischen). Leider habe ich Moment nur den Log vom Slave-3.

Code: Alles auswählen

Slave-3> dir /Status/WLAN/Log-Table/ 

Index       Time                  Interface  Event                                                                                       Address          Reason                                                                                                                         
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
...
463         10/20/2013 12:00:40   WLAN-1     40 MHz operation permitted                                                                 SLAVE-3                                                                                                                                   
462         10/20/2013 11:50:40   WLAN-1     40 MHz operation not permitted                                                                                                                                                                                                 
461         10/20/2013 11:49:18   WLAN-1     Key handshake with peer MASTER successfully completed                     MASTER                                                                                                                                   
460         10/20/2013 11:49:18   WLAN-1     Resetting key handshake state with P2P peer MASTER                            MASTER      properties of master have changed (0x00000020)                                                                                 
459         10/20/2013 11:45:39   WLAN-1     40 MHz operation permitted                                                                  SLAVE-3                                                                                                                                    
458         10/20/2013 11:25:39   WLAN-1     40 MHz operation not permitted                                                            SLAVE-3                                                                                                                                    
457         10/20/2013 11:16:30   WLAN-1     40 MHz operation permitted                                                                  SLAVE-3
...

Warum die 40 MHz Operation vom Slave-3 hin und wieder nicht erlaubt wird und ob dies Ursache für den Key Handshake der P2P-Verbindung ist, ist mir nicht klar.

Aus meiner Sicht sehen die Level für die P2P-Verbindung aus Sicht des Masters zw. den beiden Slaves mit linkstest -n ausreichend aus. (Richtwerte für die dargestellten Level habe ich aber auch nicht) Was es mit den Werten für die Antenna 3 auf sich hat, ist mir nicht bekannt.

Code: Alles auswählen

Master> linktest -n

Station                 Address               Signal  Noise   SNR     Data 
                                              Level   Level           Rate 
------------------------------------------------------------------------------
Slave-0            SLAVE-0     -60dBm  -80dBm  20dB    HT-2-52M
(Slave-0)          (AP)                  *****   ***     ++      (52Mbps)
 Control                Antenna 1             -70dBm  -87dBm  17dB         
 Ch 6 (2437 MHz)                              ****    **      ++     
                        Antenna 2             -71dBm  -88dBm  17dB         
                                              ****    **      ++     
locally seen:           Sum                   -62dBm  -81dBm  19dB    HT-1-39M
                                              *****   ***     ++      (90Mbps)
 Control                Antenna 1             -76dBm  -96dBm  20dB         
 Ch 6 (2437 MHz)                              ***     *       ++     
                        Antenna 2             -77dBm  -85dBm  8dB          
                                              ***     **      -      
                        Antenna 3             -85dBm  -93dBm  8dB          
                                              **      *       -      
 Extension              Antenna 1             -81dBm  -96dBm  15dB         
 Ch 2 (2417 MHz)                              ***     *       ++     
                        Antenna 2             -83dBm  -85dBm  2dB          
                                              ***     **             
                        Antenna 3             -82dBm  -94dBm  12dB         
                                              ***     *       o      

Slave-3            SLAVE-3    -46dBm  -82dBm  36dB    HT-2-117M
(Slave-3)          (AP)                  ******* ***     +++++   (117Mbps)
 Control                Antenna 1             -56dBm  -91dBm  35dB         
 Ch 6 (2437 MHz)                              ******  **      ++++   
                        Antenna 2             -59dBm  -87dBm  28dB         
                                              *****   **      +++    
locally seen:           Sum                   -46dBm  -81dBm  35dB    HT-2-104M
                                              ******* ***     ++++    (240Mbps)
 Control                Antenna 1             -62dBm  -96dBm  34dB         
 Ch 6 (2437 MHz)                              *****   *       ++++   
                        Antenna 2             -65dBm  -85dBm  20dB         
                                              *****   **      ++     
                        Antenna 3             -62dBm  -93dBm  31dB         
                                              *****   *       ++++   
 Extension              Antenna 1             -64dBm  -96dBm  32dB         
 Ch 2 (2417 MHz)                              *****   *       ++++   
                        Antenna 2             -67dBm  -85dBm  18dB         
                                              *****   **      ++     
                        Antenna 3             -68dBm  -94dBm  26dB         
                                              ****    *       +++    

...                                                             ++     

Die eigentliche Grund meiner Untersuchungen war, dass WLAN-Clients beim Roaming Probleme haben und beim Hangover time outs melden.

Vielleicht hat jemand im Forum eine Idee, welche Ursache(n) dies haben könnte.

Gruß

Peter

[alf29]

Moin,

Warum die 40 MHz Operation vom Slave-3 hin und wieder nicht erlaubt wird und ob dies Ursache für den Key Handshake der P2P-Verbindung ist, ist mir nicht klar.

Da schaltet eher der Master sporadisch auf 20 MHz zurück. Bei 2.4 GHz gibt es einige Regeln, nach denen der AP zwangsweise von 40 auf 20 MHz herunterschalten muß - die P2P-Slaves damit automatisch mit. Dazu gehören z.B. Im Überlappungsbereich auftauchende nicht-11n-Funknetze. Du ist wahrscheinlich ein AP in der Nachbarschaft, den das 1821 manchmal "sieht" und machmal nicht.

In den WLAN-Radio-Einstellungen (auf der CLI) gibt es einen Schalter "40MHz-erzwingen", mit dem diese Funktionen abgeschaltet werden können (und Du dann durch eine WiFi-Zulassung fallen würdest...).

Gruß Alfred

[Aragon]

Hallo Alfred,

danke für den Tip. Leider kommt bei der Fehlersuche und -beseitigung häufig eins zum anderen.

Das Problem beim Roaming konnte mit der Anpassung meiner WPA1/2 und TKIP/AES Einstellungen des Masters und der Slaves abgestellt werden. (Der Übersicht im WLANmonitor sei Dank) In allen Syslogs sind bis jetzt keine "handover time out" Meldungen mehr zu finden. Den Schalter 40MHz-erzwingen habe ich noch nicht gesetzt und so tritt der Key Handshake der P2P-Verbindungen noch immer auf.

Weil gestern Abend sehr viele WLAN Errors auf dem Master und einem der Slaves aufliefen, war das Monitoring der Geräte mit LANCOM Mitteln kaum noch möglich. Das anhaken von "Transmit only Unicats, suppress multicast and broadcasts" unter GUI->Wireless LAN-> Logical WLAN Settings->Network für die SSIDs (nicht P2P) hat keine Besserung gebracht. Das Network Discovery Tool NeDi hat mir heute Morgen für die Zeit sehr viele Broadcasts und annährend so viele Fehler auf den WLAN-1-1 Interfaces des Masters und des Slave-3 gemeldet. 1,2 Mios über eine Stunde sind ein bisschen viel. Heute über den Tag waren es auf allen WLAN-1-1 Interfaces immer noch 200.000/h. Gibt es eine Möglichkeit mit LC-Tools festzustellen woher die Broadcasts kommen?

Gruß

Peter

[alf29]

Moin,

In allen Syslogs sind bis jetzt keine "handover time out" Meldungen mehr zu finden.

Ein Handover-Timeout ist auch nicht so schlimm, wie das im Log vielleicht klingt. Der Client an sich ist problemlos zu dem anderen AP gewechselt, der Handover ist nur der Vorgang, mit dem der neue AP dem alten mitteilt, daß der Client jetzt 'bei ihm' ist, so daß der alte AP den Client aus seinen Tabellen austragen kann. Bisweilen gibt der Client dem neuen AP aber gar keine Info, wo er vorher eingebucht war (z.B. beim allerersten Einbuchen), dann schickt der neue AP den Handover Request 'auf Verdacht' als Multicast heraus, und falls sich da niemand angesprochen fühlt, gibt es eben die Meldung 'Handover Timeout'.

Den Schalter 40MHz-erzwingen habe ich noch nicht gesetzt und so tritt der Key Handshake der P2P-Verbindungen noch immer auf.

Der ist eigentlich auch nicht schlimm - der Slave bekommt die Änderung der Kanalbreite mit dem nächsten Beacon mit und der Handshake dauert ~40ms. Die dadurch bedingte Unterbrechung bewegt sich also im Sub-Sekundenbereich.

Weil gestern Abend sehr viele WLAN Errors auf dem Master und einem der Slaves aufliefen, war das Monitoring der Geräte mit LANCOM Mitteln kaum noch möglich.

Welchen Fehlerzähler meinst Du jetzt genau? Derer gibt es im WLAN ja deutlich mehr als einen

Das anhaken von "Transmit only Unicats, suppress multicast and broadcasts" unter GUI->Wireless LAN-> Logical WLAN Settings->Network für die SSIDs (nicht P2P) hat keine Besserung gebracht.

Das ist nicht weiter verwunderlich, denn zum einen werden Multi/Broadcasts auf dem WLAN ohne Empfängerbestätigung verschickt, d.h. es kann gar keinen Tx-Fehler dabei geben, zum anderen werden Mutli/Broadcasts über eine P2P-Strecke ohnehin in Unicasts "verpackt", der Schalter beeinflußt also nur in einer Funkzelle eingebuchte Clients.

Das Network Discovery Tool NeDi hat mir heute Morgen für die Zeit sehr viele Broadcasts und annährend so viele Fehler auf den WLAN-1-1 Interfaces des Masters und des Slave-3 gemeldet.

Verstehe ich das richtig, daß Du mit diesem Tool Werte in der MIB-2 explizit für die einzelne SSID und nicht für das physikalische Interface abgefragt hast? Sind das dann die ifInNUcastPkts oder eine andere OID?

1,2 Mios über eine Stunde sind ein bisschen viel. Heute über den Tag waren es auf allen WLAN-1-1 Interfaces immer noch 200.000/h. Gibt es eine Möglichkeit mit LC-Tools festzustellen woher die Broadcasts kommen?

WLAN-Data Trace geht immer (den natürlich nicht übers WLAN starten!). Mal ganz direkt gefragt: Du bist aber sicher, daß Du Dir keine Schleife gebaut hast und Broad-Multicasts in Kreis umherlaufen? Wir hatten mal einen Kunden, der meinte, es wäre eine gute Idee, P2P-Links zwischen allen drei APs zu konfigurieren, ohne Spanning Tree einzuschalten

Gruß Alfred

[Aragon]

Hallo Alfred,

erstmal danke für deine Antworten.

Moin,

In allen Syslogs sind bis jetzt keine "handover time out" Meldungen mehr zu finden.

Ein Handover-Timeout ist auch nicht so schlimm, wie das im Log vielleicht klingt. Der Client an sich ist problemlos zu dem anderen AP gewechselt, der Handover ist nur der Vorgang, mit dem der neue AP dem alten mitteilt, daß der Client jetzt 'bei ihm' ist, so daß der alte AP den Client aus seinen Tabellen austragen kann. Bisweilen gibt der Client dem neuen AP aber gar keine Info, wo er vorher eingebucht war (z.B. beim allerersten Einbuchen), dann schickt der neue AP den Handover Request 'auf Verdacht' als Multicast heraus, und falls sich da niemand angesprochen fühlt, gibt es eben die Meldung 'Handover Timeout'.

Den Schalter 40MHz-erzwingen habe ich noch nicht gesetzt und so tritt der Key Handshake der P2P-Verbindungen noch immer auf.

Der ist eigentlich auch nicht schlimm - der Slave bekommt die Änderung der Kanalbreite mit dem nächsten Beacon mit und der Handshake dauert ~40ms. Die dadurch bedingte Unterbrechung bewegt sich also im Sub-Sekundenbereich.

Weil gestern Abend sehr viele WLAN Errors auf dem Master und einem der Slaves aufliefen, war das Monitoring der Geräte mit LANCOM Mitteln kaum noch möglich.

Welchen Fehlerzähler meinst Du jetzt genau? Derer gibt es im WLAN ja deutlich mehr als einen

Rx-Errors, Retries und Multiple-Retries. Es fehlt mir die Erfahrung wie viele Errors/Frames oder Retries/Frames im "Normalen" liegen

Code: Alles auswählen

> dir /Status/WLAN/Errors/
Ifc       Rx-Errors   Tx-Errors   Stack-Errors  NIC-Errors  Bus-Errors  Queue-Errors  Tx-Discarded   Retries         Multiple-Retries           Soft-Retries          Dupe-Discarded   Undecryptables      Aged                 Michael-Errors   IV-Sequence-Errors   Rx-CRC-Errors   Rx-Aggr.-Discarded   Rx-PHY-Errors   Rx-Restarts   Rx-Dscr-Underflow      Rx-FIFO-Overflow      Tx-FIFO-Underflow   
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
WLAN-1    56604       17639       0             0           0           0             26             264830          196058                     0                     108              0                   0                    0                0                    56604           5355                 0               0             0                      0                     0                   
root@Master:/
> dir /Status/WLAN/Interpoints/Accesspoint-List/

Index      MAC-Address     Link-Active           Rx-Phy-Signal    Tx-Rate      Rx-Rate      Eff.-Tx-Rate   Eff.-Rx-Rate   Link-Phy-Signal  Identification            Interpoint-Peer-Name          QoS       40MHz-Mode    Max-A-MSDU-Len      Max-A-MPDU-Len      Short-Preamble    Short-Guard-Interval      Key-Handshake-Role    Keying-State       WPA-Version   Key-Type         Tx-Bytes             Rx-Bytes             Throughput  Max.-Throughput  Tx-Packets  Tx-Errors  Total-Retries         Rx-Packets  Tx-Limit   Rx-Limit   Alarm-State                   
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
P2P-1-1    00a057xxxxxx    Yes                   28               HT-2-26M     HT-1-39M     60             90             33               Slave-0              SLAVE-0                  Yes       Yes           3839                32767               No                20/40MHz                  Authenticator         Done               WPA2          AES-CCM          1320055072           51205918             778 B       417.9 KB         978254      1325       917619                492404      0          0          No                            
P2P-1-2    00a057yyyyyyy    Yes                   54               HT-2-104M    HT-2-104M    240            240            60               Slave-3              SLAVe-3                  Yes       Yes           3839                32767               No                20/40MHz                  Authenticator         Done               WPA2          AES-CCM          59628599             36255674             4.7 KB      338.7 KB         135203      11         6494                  124001      0          0          No                            

Das anhaken von "Transmit only Unicats, suppress multicast and broadcasts" unter GUI->Wireless LAN-> Logical WLAN Settings->Network für die SSIDs (nicht P2P) hat keine Besserung gebracht.

Das ist nicht weiter verwunderlich, denn zum einen werden Multi/Broadcasts auf dem WLAN ohne Empfängerbestätigung verschickt, d.h. es kann gar keinen Tx-Fehler dabei geben, zum anderen werden Mutli/Broadcasts über eine P2P-Strecke ohnehin in Unicasts "verpackt", der Schalter beeinflußt also nur in einer Funkzelle eingebuchte Clients.

Das Network Discovery Tool NeDi hat mir heute Morgen für die Zeit sehr viele Broadcasts und annährend so viele Fehler auf den WLAN-1-1 Interfaces des Masters und des Slave-3 gemeldet.

NeDi nutzt einen Fallback Mechanismus über den Interface-Namen und kommt dabei wohl ein wenig durcheinander. Kann ich nachvollziehen bei den Werten die LCOS 8.82RU für 1821n und L-321agn zurück liefert.

Code: Alles auswählen

$ snmpwalk -v 2c -c public 172.16.x.y 1.3.6.1.2.1.31.1.1.1.1
...
IF-MIB::ifName.1 = STRING: WLAN-1
IF-MIB::ifName.2 = STRING: LAN-1
IF-MIB::ifName.3 = STRING: WLAN-1
...

Dadurch werden die Counter des Interfaces WLAN-1 im NeDi dem Interface WLAN-1-1 zugeordnet und so angezeigt. Hätte mir auch auffallen können.

Verstehe ich das richtig, daß Du mit diesem Tool Werte in der MIB-2 explizit für die einzelne SSID und nicht für das physikalische Interface abgefragt hast? Sind das dann die ifInNUcastPkts oder eine andere OID?

Es werden wirklich die Counter des physikalischen Interfaces WLAN-1 gemeint.

1,2 Mios über eine Stunde sind ein bisschen viel. Heute über den Tag waren es auf allen WLAN-1-1 Interfaces immer noch 200.000/h. Gibt es eine Möglichkeit mit LC-Tools festzustellen woher die Broadcasts kommen?

WLAN-Data Trace geht immer (den natürlich nicht übers WLAN starten!). Mal ganz direkt gefragt: Du bist aber sicher, daß Du Dir keine Schleife gebaut hast und Broad-Multicasts in Kreis umherlaufen? Wir hatten mal einen Kunden, der meinte, es wäre eine gute Idee, P2P-Links zwischen allen drei APs zu konfigurieren, ohne Spanning Tree einzuschalten

Mit den P2P Channels bin ich mir recht sicher, mit den Broadcast als Ursache für die vielen WLAN Fehler/Retries eher nicht. Ein wenig verwirrend war, dass das LLDP über die P2P-Verbindungen und der Brücke im Master den jeweils anderen Slave (lt. NeDi) sieht. Ist das schon eine Schleife? Oder nachvollziehbar weil der 1821n ja kein LLDP kann? Am Master die Brücke zw. den P2P Channels abzuschalten ist für das IAPP-Protokol nicht sinnvoll. Es könnten auch Störungen von anderen Access Points im 2.4GHz Band sein. Deine Empfehlung den SNR zw. 15...30dB zu halten ist bei dem Slave-0 mit 13-14dB schon unterschritten. Könnte die Umschaltung auf das 5GHz Band eine Verbesserung des SNRs versprechen?

Gruß Alfred

[/quote]

Gruß Peter

[alf29]

Moin,

Rx-Errors, Retries und Multiple-Retries. Es fehlt mir die Erfahrung wie viele Errors/Frames oder Retries/Frames im "Normalen" liegen

Also für P2P-1-1 sieht man z.B. etwa eine Million Pakete sowie etwa 5 Millionen Wiederholungen. Das bedeutet, jedes Paket wurde im Schnitt 5 mal wiederholt, bis es beim Gegenüber ankam, was entsprechend auf den Durchsatz (auch auf der anderen P2P-Strecke) drückt. Das SNR ist mit 28% --> ca. 18 dB auch nicht mehr allzu toll und dementsprechend reicht es nicht für die höchste Bitrate. Die Ratenadaption probiert immer wieder höhere Raten, um zu prüfen, ob die Verbindung zwischenzeitlich besser geworden ist, das dürfte für einen Gutteil der Wiederholungen gut sein. Üblicherweise ist dann die Lösung, den Max-HT-MCS-Wert in den Übertragungseinstellungen zu begrenzen, so daß höhere Bitraten erst gar nicht versucht werden. Bit einschließlich LCOS 8.84 läßt sich dieser Wert aber nicht einzeln pro P2P-Partner einstellen, man würde sich damit also die (viel bessere) Verbindung auf P2P-1-2 unnötig limitieren. Dort sind es bei 130000 Paketen nur etw 120000 Wiederholungen, alsao im Schnitt weniger als eine Wiederholung pro Paket, und die Menge echt verlorener Pakete ist verschwindend klein.

Dadurch werden die Counter des Interfaces WLAN-1 im NeDi dem Interface WLAN-1-1 zugeordnet und so angezeigt. Hätte mir auch auffallen können.

Tja, das ist leider so eine Altlast, daß das physische WLAN-Interface genauso heißt wie die erste SSID, während die erste SSID eher WLAN-n-1 heißen sollte. Leider ist man aktuell nicht bereit, das zu ändern, wegen der geheiligten Rückwärtskompatibilität, es könnte ja irgendein wichtiger Kunde meckern, daß seine Skripte auf einmal nicht mehr funktionieren

Mit den P2P Channels bin ich mir recht sicher, mit den Broadcast als Ursache für die vielen WLAN Fehler/Retries eher nicht.

Tja, schau Dir doch einfach an, was da so an Paketen durchrauscht. Wenn es ständig der gleiche Broad/Multicast ist, dann ist der Verdacht auf eine Schleife sehr hoch. Wir hatten aber auch schon andere Fälle, wo irgendein anderes Gerät IP-Multicasts in das eigene Netz zurückgespiegelt hat.

Ein wenig verwirrend war, dass das LLDP über die P2P-Verbindungen und der Brücke im Master den jeweils anderen Slave (lt. NeDi) sieht. Ist das schon eine Schleife? Oder nachvollziehbar weil der 1821n ja kein LLDP kann?

LANCOMs, die keinen Support für LLDP haben oder bei denen LLDP abgeschaltet ist, lassen LLDP-Pakete transparent durch. So ähnlich wie ein 'dummer Hub'...

Könnte die Umschaltung auf das 5GHz Band eine Verbesserung des SNRs versprechen?

Bei 5 GHz ist die Dämpfung eher höher als bei 2.4 GHz. Ehrlich: für zwei Stahlbetondecken dazwischen läuft die Sache noch vergleichsweise gut, ich habe schon Fälle gesehen, wo in so einem Szenario gar nichts mehr ging.

Gruß Alfred

[Aragon]

Hallo Alfred,

Moin,

Rx-Errors, Retries und Multiple-Retries. Es fehlt mir die Erfahrung wie viele Errors/Frames oder Retries/Frames im "Normalen" liegen

Also für P2P-1-1 sieht man z.B. etwa eine Million Pakete sowie etwa 5 Millionen Wiederholungen. Das bedeutet, jedes Paket wurde im Schnitt 5 mal wiederholt, bis es beim Gegenüber ankam, was entsprechend auf den Durchsatz (auch auf der anderen P2P-Strecke) drückt. Das SNR ist mit 28% --> ca. 18 dB auch nicht mehr allzu toll und dementsprechend reicht es nicht für die höchste Bitrate. Die Ratenadaption probiert immer wieder höhere Raten, um zu prüfen, ob die Verbindung zwischenzeitlich besser geworden ist, das dürfte für einen Gutteil der Wiederholungen gut sein. Üblicherweise ist dann die Lösung, den Max-HT-MCS-Wert in den Übertragungseinstellungen zu begrenzen, so daß höhere Bitraten erst gar nicht versucht werden. Bit einschließlich LCOS 8.84 läßt sich dieser Wert aber nicht einzeln pro P2P-Partner einstellen, man würde sich damit also die (viel bessere) Verbindung auf P2P-1-2 unnötig limitieren. Dort sind es bei 130000 Paketen nur etw 120000 Wiederholungen, alsao im Schnitt weniger als eine Wiederholung pro Paket, und die Menge echt verlorener Pakete ist verschwindend klein.

Dadurch werden die Counter des Interfaces WLAN-1 im NeDi dem Interface WLAN-1-1 zugeordnet und so angezeigt. Hätte mir auch auffallen können.

Tja, das ist leider so eine Altlast, daß das physische WLAN-Interface genauso heißt wie die erste SSID, während die erste SSID eher WLAN-n-1 heißen sollte. Leider ist man aktuell nicht bereit, das zu ändern, wegen der geheiligten Rückwärtskompatibilität, es könnte ja irgendein wichtiger Kunde meckern, daß seine Skripte auf einmal nicht mehr funktionieren

Mit den P2P Channels bin ich mir recht sicher, mit den Broadcast als Ursache für die vielen WLAN Fehler/Retries eher nicht.

Tja, schau Dir doch einfach an, was da so an Paketen durchrauscht. Wenn es ständig der gleiche Broad/Multicast ist, dann ist der Verdacht auf eine Schleife sehr hoch. Wir hatten aber auch schon andere Fälle, wo irgendein anderes Gerät IP-Multicasts in das eigene Netz zurückgespiegelt hat.

Das Monitoring mit NeDi habe ich auf die IF-MIB::ifInNUcastPkts mit der OID 1.3.6.1.2.1.2.2.1.12 umgestellt. Die Zahl bleibt am WLAN-1 Interface aller drei Geräte mit ca. 200-230T/h in der gleichen Größenordnung. Pro Sekunde sind das gerade mal um die 60 Pakete. Damit ist der Verdacht eines Broadcaststurms oder einer Schleife für mich obsolet. (Ein Testaufbau im Büro mit diversen AP in der Nähe, liefert ohne aktive P2P-Verbindungen und ohne assoziierte Clients ca. 160T ifInNUcastPkts pro Std. im "Leerlauf")

Ein wenig verwirrend war, dass das LLDP über die P2P-Verbindungen und der Brücke im Master den jeweils anderen Slave (lt. NeDi) sieht. Ist das schon eine Schleife? Oder nachvollziehbar weil der 1821n ja kein LLDP kann?

LANCOMs, die keinen Support für LLDP haben oder bei denen LLDP abgeschaltet ist, lassen LLDP-Pakete transparent durch. So ähnlich wie ein 'dummer Hub'...

Könnte die Umschaltung auf das 5GHz Band eine Verbesserung des SNRs versprechen?

Bei 5 GHz ist die Dämpfung eher höher als bei 2.4 GHz. Ehrlich: für zwei Stahlbetondecken dazwischen läuft die Sache noch vergleichsweise gut, ich habe schon Fälle gesehen, wo in so einem Szenario gar nichts mehr ging.

Zur Reduzierung der Retrise im WLAN werden für die schlechtere der beiden P2P Verbindungen leistungsfähigere Rundstrahler (zwei AirLancer Extender O-360ag pro Gerät) beschafft. Dadurch soll der SNR verbessert und die Physik der Installation auf stabilere Beine gestellt werden. Die von mir ausgewählten O-360ag-Antennen sind zwar nur für den 802.11a/g Standard gedacht, aber wenn ich zwei davon pro AP einsetze, kriege ich auch den 802.11n Standard hin.

Für zwei SSIDs (nicht P2P) habe ich VLAN Gruppenschlüssel aktiviert. Damit sollten zukünftig die NonUnicasts besser einem logischen WLAN-Interface zuordbar sein. Sind die VLAN Gruppenschlüssel auch für die P2P Verbindungen sinnvoll einsetzbar? Welche Seiteneffekte sind damit zu erwarten.

Für das Langzeit-Monitoring des phy. WLAN-1 Interfaces und der dort gelieferten LANCOM MIBs, muss ich mit einem anderen Network Monitoring Tool übernehmen. Ich schau mir mal Cacti an.

Gruß

Peter

[alf29]

Moin,

Zur Reduzierung der Retrise im WLAN werden für die schlechtere der beiden P2P Verbindungen leistungsfähigere Rundstrahler (zwei AirLancer Extender O-360ag pro Gerät) beschafft. Dadurch soll der SNR verbessert und die Physik der Installation auf stabilere Beine gestellt werden. Die von mir ausgewählten O-360ag-Antennen sind zwar nur für den 802.11a/g Standard gedacht, aber wenn ich zwei davon pro AP einsetze, kriege ich auch den 802.11n Standard hin.

Good luck. Aber meine praktische Erfahrung ist, daß man das durch Stahlbetondecken oder -wände verlorene SNR nicht sinnvoll wieder hereinholen kann. Wichtig: Die O-360ag hat zwar eine Richtwirkung aber in der Ebene, die senkrecht zum Antennenstab steht - d.h. wenn man sie irgendwo senkrecht in einem Raum hinstellt, dann sind oben und unten die Richungen, in denen sie besonders schwach ist. Diese Antenne ist dazu gedacht, eine Fläche auszuleuchten, und nicht in Richtung oberer und unterer Geschosse.

Für zwei SSIDs (nicht P2P) habe ich VLAN Gruppenschlüssel aktiviert. Damit sollten zukünftig die NonUnicasts besser einem logischen WLAN-Interface zuordbar sein. Sind die VLAN Gruppenschlüssel auch für die P2P Verbindungen sinnvoll einsetzbar? Welche Seiteneffekte sind damit zu erwarten.

Diese Feature bezieht sich einzig und allein auf SSIDs, und zwar für den Fall, daß auf einer SSID mehrere Clients eingebucht sind, die in unterschiedliche VLANs einsortiert wurden (ist bei Verwendung von 802.1X ein gängiges Szenario). Dort hat man bei nicht VLAN-getaggtem Traffic das Problem, daß die Clients in einem VLAN auch die Multi/Broadcasts 'sehen', die für das andere VLAN gedacht sind. Dieses Feature verhindert das, indem pro VLAN ein anderer Schlüssel für die Broad/Multicasts verwendet wird, und die Clients kennen nur den Gruppenschlüssel 'ihres' VLANs. Geht aktuell aber nur für maximal drei VLANs. Mit P2P-Strecken hat das Feature nichts zu tun, dort gibt es zum einen keine Multi/Broadcasts (bzw. sie werden zur Übertragung in Unicasts verpackt), und auch keine eingebuchten Clients, die einzeln mit VLAN-Id verwaltet werden. Wer auf einer P2P-Strecke VLANs trennen will, richtet sie als VLAN-Trunk-Port ein, so wie man das mit einem Ethernet-Strang auch macht.

Gruß Alfred