ifMauMediaAvailable - if Mau Media Available - MAU-MIB

MIBs list

With IPHost Network Monitor you can run simple snmp requests against a Cisco device in your network.

ifMauMediaAvailable

if Mau Media Available
1.3.6.1.2.1.26.2.1.1.5

10BASE-T, 10BASE-F) then this is equivalent to the link test fail state/low light function. For an AUI or a coax (including broadband) MAU this indicates whether or not loopback is detected on the DI circuit. The value of this attribute persists between packets for MAU types AUI, 10BASE5, 10BASE2, 10BROAD36, and 10BASE-FP. The value other(1) is returned if the mediaAvailable state is not one of 2 through 18. The value unknown(2) is returned when the MAU's true state is unknown; for example, when it is being initialized. At power-up or following a reset, the value of this attribute will be unknown for AUI, coax, and 10BASE-FP MAUs. For these MAUs loopback will be tested on each transmission during which no collision is detected. If DI is receiving input when DO returns to IDL after a transmission and there has been no collision during the transmission then loopback will be detected. The value of this attribute will only change during non-collided transmissions for AUI, coax, and 10BASE-FP MAUs. For 100Mbps and 1000Mbps MAUs, the enumerations match the states within the respective link integrity state diagrams, fig 32-16, 23-12 and 24-15 of sections 32, 23 and 24 of [IEEE802.3]. Any MAU which implements management of auto-negotiation will map remote fault indication to remote fault. The value available(3) indicates that the link, light, or loopback is normal. The value notAvailable(4) indicates link loss, low light, or no loopback. The value remoteFault(5) indicates that a fault has been detected at the remote end of the link. This value applies to 10BASE-FB, 100BASE-T4 Far End Fault Indication and non-specified remote faults from a system running auto-negotiation. The values remoteJabber(7), remoteLinkLoss(8), and remoteTest(9) SHOULD be used instead of remoteFault(5) where the reason for remote fault is identified in the remote signaling protocol. The value invalidSignal(6) indicates that an invalid signal has been received from the other end of the link. invalidSignal(6) applies only to MAUs of type 10BASE-FB. Where an IEEE Std 802.3-2002 clause 22 MII is present, a logic one in the remote fault bit (reference section 22.2.4.2.8 of that document) maps to the value remoteFault(5), and a logic zero in the link status bit (reference section 22.2.4.2.10 of that document) maps to the value notAvailable(4). The value notAvailable(4) takes precedence over the value remoteFault(5). Any MAU that implements management of clause 37 Auto-Negotiation will map the received RF1 and RF2 bit values for Offline to offline(10), Link Failure to remoteFault(5) and Auto-Negotiation Error to autoNegError(11). For 10 Gb/s, the enumerations map to the states within the Reconciliation Sublayer state diagram as follows: NoFault maps to the enumeration 'available(3)' LocalFault maps to the enumeration 'notAvailable(4)' RemoteFault maps to the enumeration 'remoteFault(5)' The enumerations 'pmdLinkFault(12)', 'wisFrameLoss(13)', 'wisSignalLoss(14)', 'pcsLinkFault(15)', 'excessiveBER(16)', and 'dxsLinkFault(17)' and 'pxsLinkFault(18)' should be used instead of the enumeration 'notAvailable(4)' where the reason for the local fault can be identified through the use of the MDIO Interface. Where multiple reasons for the local fault state can be identified only the highest precedence error should be reported. The precedence in descending order is as follows: pxsLinkFault pmdLinkFault wisFrameLoss wisSignalLoss pcsLinkFault excessiveBER dxsLinkFault

Back to MAU-MIB MIB page.

IPHost Network monitor allows you to monitor ifMauMediaAvailable on Cisco device via the SNMP protocol. Download IPHost Network Monitor (500 monitors for 30 days, 50 monitors free forever) to start monitoring Cisco wireless switches right now.

Easy monitoring of ifMauMediaAvailable with IPHost tools

MIBs list