Ich bereite einen Belastungstest eines WLAN-Systems im Klassenzimmer vor. Alle Schüler schalten zu Beginn der Stunde ihre Laptops ein, woraufhin der Webbrowser gestartet wird, und dann beginnen sie mit der Unterrichtseinheit. Dazu müssen sie eine Flash-basierte Unterrichtseinheit (von einem Server in der Schule) herunterladen. Der Download ist in der Regel 0,5 bis 2 MB groß.
In einigen Fällen beträgt die Ladezeit 5 oder 10 Minuten. Ich möchte daher alle Teile des Systems überwachen, um mit Sicherheit sagen zu können, wo die Engpässe sind und wie viele Clients einen einzelnen WLAN-Zugangspunkt sinnvoll nutzen können. Wir planen daher, Tests mit bis zu 50 Clients durchzuführen und zu sehen, was passiert (ich weiß, dass die meisten Leute 20 bis 25 Clients pro Zugangspunkt empfehlen, aber der Client möchte dies testen – und ich möchte gute Daten erhalten, um es dem Client auf die eine oder andere Weise zu zeigen).
Ich weiß bereits, wie man den Server überwacht. Der WLAN-Zugangspunkt unterstützt SNMP und scheint ziemlich viele Variablen bereitzustellen, aber ich möchte mich nicht durch zu viel wühlen müssen.
Die Frage ist also: Welche WLAN-bezogenen Variablen müssen unbedingt überwacht werden, um zu erkennen, wann das System überlastet ist, Clients warten, Kollisionen auftreten usw.?
Ich lasse mir gerne die generischen Namen der Dateien nennen und suche selbst in ihnen, aber wenn Sie die Details sehen wollen/müssen, dann ist der von uns verwendete Zugangspunkt derUbiquity Nanostation 2. Die MIB-Dateien für Ubiquity-Produkte sind unten auf der Seite verlinkt.ihre SNMP-Seite. Allerdings habe ich auch festgestellt, dass sie zumindest einen Teil derMikrotik MIB.
Antwort1
Der einfache Ansatz wäre, die IF-MIB::ifInOctets.<ifIndex>/ IF-MIB::ifOutOctets.<ifIndex>OIDs regelmäßig zu überwachen und mit der verfügbaren Bandbreite abzugleichen. In Ihrer verknüpften MikroTik-MIB können Sie die aktuell eingestellten Raten ermitteln, indem Sie mtxrWlStatTxRate: 1.3.6.1.4.1.14988.1.1.1.1.1.2.<ifIndex>und mtxrWlStatRxRate: lesen 1.3.6.1.4.1.14988.1.1.1.1.1.3.<ifIndex>. Dabei werden natürlich keine drahtlosen Besonderheiten berücksichtigt, aber Sie erhalten eine ungefähre Vorstellung davon, ob die insgesamt verfügbare Bandbreite auf Ihrer Schnittstelle der Engpass ist (das ist wahrscheinlich der Fall, wenn Sie eine Nutzung nahe der gesamten Kanalkapazität feststellen).
Sofern Ihre Stationen oder Antennen nicht an einem ungünstigen Standort sind und der Äther auf der Frequenz des gewählten Kanals sauber ist, können Sie im Allgemeinen mit einem Durchsatz von etwa 2–3 MB/s pro einzelnem G-Kanal (54 MB/s, 2,4 GHz) rechnen.
Wenn Sie spezifischere Informationen zu Wiederholungsversuchen und Fehlern von der AP-Seite benötigen, können Sie die dot11CountersTabelle der IEEE802dot11 MIB lesen – insbesondere die dot11RetryCount, dot11MultipleRetryCountund dot11FailedCount-Werte der entsprechenden Instanz.
802.11 kennt keine Kollisionen, dafür aber Physical Carrier Sensing und optional eineRTS/CTS-Handshakevor der Übertragung von Frames. Durch die Überwachung dot11RTSFailureCounterhalten Sie eine ungefähre Vorstellung davon, wie oft eine RTS-Anforderung nicht von einem CTS beantwortet wird und der sendenden Station daher der Kanal nicht gewährt wird.
Beachten Sie, dass Sie möglicherweise eine relativ geringe Anzahl von Wiederholungsversuchen und RTS-Fehlern sehen, wenn Ihr Access Point den Großteil des Datenverkehrs erzeugt (d. h. die Stationen empfangen hauptsächlich Daten). Sie sollten sich auch IF-MIB::ifOutDiscards.<ifIndex>die drahtlose Schnittstelle oder IF-MIB::ifInDiscards.<ifIndex>die kabelgebundene Schnittstelle ansehen, da diese Zahlen immer dann ansteigen, wenn der Puffer voll ist und keine weiteren Frames empfangen kann (d. h. der AP sendet mit voller Geschwindigkeit, aber Frames an der Ethernet-Schnittstelle kommen immer mit einer höheren Geschwindigkeit an).
Antwort2
Wenn Sie dem Client lediglich beweisen möchten, dass er den AP überlastet, können Sie die OIDs dot11RetryCount und dot11MultipleRetryCount verwenden.
dot11RetryCount - 1.2.840.10036.2.2.1.4
dot11MultipleRetryCount - 1.2.840.10036.2.2.1.5
Dadurch erhalten Sie eine grobe Schätzung, wie überlastet die Luft ist. Sobald die Anzahl der Wiederholungsversuche mehr als etwa 10 % des dot11TransmittedFrameCount erreicht, werden Sie Verlangsamungen feststellen.
Hier ist der MIB-Objekt-Walker von Cisco – er sollte hilfreich sein, wenn Sie andere zu untersuchende OIDs herausfinden müssen.