Subject: [Bridge-mib] New trap

From: "ravikumarb" <[email-masked]>
Date: Mon, 17 Jul 2006 18:24:37 +0530

Hi,

We would like to porpose a new trap for bridges so that they can detect malfunctioning neighbour bridges. Lets call it as "neighbourUnreachable". This trap will be generated by the bridge if it doesn't receive 5 consecutive Hello BPDUs from a port, which was receiving these messages earlier. This trap will be useful to detect cases where the bridge and its ports were functioning properly for some time and suddenly started malfunctioning due to a hardware glitch or a software bug. Note that link failure (down) trap won't be raised as the link is UP from the PHY point of view. This is analogous to Hello messages used by Routing Protocols to detect routing peers. This trap will be very useful for the NMS to take appropriate actions. Note that this is very different from "topologyChange" trap, which just tells that the port has transitioned to Blocking State from Forwarding State. This trap tells that the bridge is not functioning properly at all from the port's point of view. It has a specific meaning and is detected fast. Following would be its structure:

neighbourUnreachable NOTIFICATION-TYPE
    OBJECTS     { dot1dBaseBridgeAddress dot1dBasePort dot1dBasePortIfIndex }
    STATUS      current
    DESCRIPTION
        "A neighbourUnreachable trap is sent by a bridge when it
        doesn't receive 5 consecutive Hello BPDUs. This will
        allow a bridge to detect malfunctions of the neighbour
        bridge even when the link state to the neighbour bridge
        is UP. It is analogous to Hello messages used by Routing
        Protocols to detect whether the neighbour router is
        functional."
    ::= { dot1dNotifications 3 }

Please let us know your thoughts regarding the proposed trap.

Thanks & Regards,
Ravi

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

_______________________________________________
Bridge-mib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bridge-mib

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 17 Jul 2006 10:09:15 -0400

Hi,

Maintenance of the Bridge Mib modules has been taken over by the IEEE
802.1 WG.

As a result, this proposal is out of scope for the Bridge MIB WG
mailing list.
   The appropriate mailing list for IEEE 802.1 MIB module discussion
   is [email-masked].
   To subscribe to the STDS-802-1-L list, go to
   http://www.ieee802.org/1/email-pages/
   To see the general information about 802,1, including how they
   work and how to participate, go to http://www.ieee802.org/1/
   To see presentations on the technology, go to
   http://www.ieee802.org/1/files/public/ and look in the docs2004,
   docs2005, and docs2006 directories. 

David Harrington
[email-masked] 
[email-masked]
[email-masked]
co-chair, Bridge-MIB WG 

> -----Original Message-----
> From: ravikumarb [mailto:[email-masked]] 
> Sent: Monday, July 17, 2006 8:55 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Bridge-mib] New trap
> 
> 
> Hi,
> 
> We would like to porpose a new trap for bridges so that they 
> can detect malfunctioning neighbour bridges. Lets call it as 
> "neighbourUnreachable". This trap will be generated by the 
> bridge if it doesn't receive 5 consecutive Hello BPDUs from a 
> port, which was receiving these messages earlier. This trap 
> will be useful to detect cases where the bridge and its ports 
> were functioning properly for some time and suddenly started 
> malfunctioning due to a hardware glitch or a software bug. 
> Note that link failure (down) trap won't be raised as the 
> link is UP from the PHY point of view. This is analogous to 
> Hello messages used by Routing Protocols to detect routing 
> peers. This trap will be very useful for the NMS to take 
> appropriate actions. Note that this is very different from 
> "topologyChange" trap, which just tells that the port has 
> transitioned to Blocking State from Forwarding State. This 
> trap tells that the bridge is not functioning properly at all 
> from the port's point of view. It has a specific meaning and 
> is detected fast. Following would be its structure:
> 
> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION 
> intended solely for the use of the addressee(s). If you are 
> not the intended recipient, please notify the sender by 
> e-mail and delete the original message. Further, you are not 
> to copy, disclose, or distribute this e-mail or its contents 
> to any other person and any such actions are unlawful. This 
> e-mail may contain viruses. Infosys has taken every 
> reasonable precaution to minimize this risk, but is not 
> liable for any damage you may sustain as a result of any 
> virus in this e-mail. You should carry out your own virus 
> checks before opening the e-mail or attachment. Infosys 
> reserves the right to monitor and review the content of all 
> messages sent to or from this e-mail address. Messages sent 
> to or from this e-mail address may be stored on the Infosys 
> e-mail system.