SNMP: Switch: Datenübertragungsrate

Herstelller und Modellnummer des Switch wären Hilfreich!
Bei Ciso in der Console: show snmp-server oidlist

Ok! Jetzt kennen wir den Hersteller und die Modellreihe. Fehlt nur noch die genaue Modellbezeichnung bzw. Modellnummer und dann:

#include <IE.au3>
$sURL = "http://lmgtfy.com/?q=Huawei+Quidway+MIB"
$sModellNr = ""
While $sModellNr = false
$sModellNr = InputBox("SNMP OID finden", "Bitte Modellnummer eingeben: ")
WEnd
$sURL &= "+" & $sModellNr
$oIE = _IECreate($sURL)

SCNR

Oh mal wieder ein Thema für mich.
Also es gibt in SNMP 3 Wege den Traffic herauszubekommen.
Der erste ist ein Standard-Weg, den nutzen alle Monitoringprogramme.
SNMP Baum

1. Hersteller unabhängig (32-Bit Counter)
OID 1.3.6.1.2.1.2.2.1.16 die 16 ist dann schon der Wert z.B. für outOctets.
Hier kannst du auch noch andere Sachen abfragen. (siehe Bild)

2. Das sind die 32-Bit Werte die der Hersteller in seiner eigenen Mib angibt. Den Pfad dorthin kann die der Hersteller geben. Er liegt im Enterprice Zweig.
3. Das sind die 64-Bit Werte die der Hersteller in seiner eigenen Mib angibt. Den Pfad dorthin kann die der Hersteller geben. Er liegt im Enterprice Zweig.
Diese sind meist mit "Hi" gekenzeichnet.

32-64 Bit Counter
Auszug aus dem RFC2233 http://www.ietf.org/rfc/rfc2233.txt

Zitat

3.1.6. Counter Size

As the speed of network media increase, the minimum time in which
a 32 bit counter will wrap decreases. For example, a 10Mbs stream
of back-to-back, full-size packets causes ifInOctets to wrap in
just over 57 minutes; at 100Mbs, the minimum wrap time is 5.7
minutes, and at 1Gbs, the minimum is 34 seconds. Requiring that
interfaces be polled frequently enough not to miss a counter wrap
is increasingly problematic.
A rejected solution to this problem was to scale the counters; for
example, ifInOctets could be changed to count received octets in,
say, 1024 byte blocks. While it would provide acceptable
functionality at high rates of the counted-events, at low rates it
suffers. If there is little traffic on an interface, there might
be a significant interval before enough of the counted-events
occur to cause the scaled counter to be incremented. Traffic
would then appear to be very bursty, leading to incorrect
conclusions of the network's performance.

Instead, this memo adopts expanded, 64 bit, counters. These
counters are provided in new "high capacity" groups. The old,
32-bit, counters have not been deprecated. The 64-bit counters
are to be used only when the 32-bit counters do not provide enough
capacity; that is, when the 32 bit counters could wrap too fast.

For interfaces that operate at 20,000,000 (20 million) bits per
second or less, 32-bit byte and packet counters MUST be used. For
interfaces that operate faster than 20,000,000 bits/second, and
slower than 650,000,000 bits/second, 32-bit packet counters MUST
be used and 64-bit octet counters MUST be used. For interfaces
that operate at 650,000,000 bits/second or faster, 64-bit packet
counters AND 64-bit octet counters MUST be used.

These speed thresholds were chosen as reasonable compromises based
on the following:

(1) The cost of maintaining 64-bit counters is relatively high,
so minimizing the number of agents which must support them is
desirable. Common interfaces (such as 10Mbs Ethernet) should
not require them.

(2) 64-bit counters are a new feature, introduced in SNMPv2. It
is reasonable to expect that support for them will be spotty
for the immediate future. Thus, we wish to limit them to as
few systems as possible. This, in effect, means that 64-bit
counters should be limited to higher speed interfaces.
Ethernet (10,000,000 bps) and Token Ring (16,000,000 bps) are
fairly wide-spread so it seems reasonable to not require 64-
bit counters for these interfaces.

(3) The 32-bit octet counters will wrap in the following times,
for the following interfaces (when transmitting maximum-sized
packets back-to-back):

- 10Mbs Ethernet: 57 minutes,

- 16Mbs Token Ring: 36 minutes,
- a US T3 line (45 megabits): 12 minutes,

- FDDI: 5.7 minutes

(4) The 32-bit packet counters wrap in about 57 minutes when 64-
byte packets are transmitted back-to-back on a 650,000,000
bit/second link.

As an aside, a 1-terabit/second (1,000 Gbs) link will cause a 64 bit
octet counter to wrap in just under 5 years. Conversely, an
81,000,000 terabit/second link is required to cause a 64-bit counter
to wrap in 30 minutes. We believe that, while technology rapidly
marches forward, this link speed will not be achieved for at least
several years, leaving sufficient time to evaluate the introduction
of 96 bit counters.

When 64-bit counters are in use, the 32-bit counters MUST still be
available. They will report the low 32-bits of the associated 64-bit
count (e.g., ifInOctets will report the least significant 32 bits of
ifHCInOctets). This enhances inter-operability with existing
implementations at a very minimal cost to agents.

The new "high capacity" groups are:

(1) the ifHCFixedLengthGroup for character-oriented/fixed-length
interfaces, and the ifHCPacketGroup for packet-based interfaces;
both of these groups include 64 bit counters for octets, and

(2) the ifVHCPacketGroup for packet-based interfaces; this group
includes 64 bit counters for octets and packets.
Network speeds are increasing. The range of ifSpeed is limited to
reporting a maximum speed of (2**31)-1 bits/second, or approximately
2.2Gbs. SONET defines an OC-48 interface, which is defined at
operating at 48 times 51 Mbs, which is a speed in excess of 2.4Gbs.
Thus, ifSpeed is insufficient for the future, and this memo defines
an additional object: ifHighSpeed.

The ifHighSpeed object reports the speed of the interface in
1,000,000 (1 million) bits/second units. Thus, the true speed of the
interface will be the value reported by this object, plus or minus
500,000 bits/second.

Alles anzeigen

Ich hoffe ich konnte helfen.
Hier nochmal die Huawei-MIB http://www.oidview.com/mibs/2011/HUAWEI-MIB.html

MfG
Der_Doc