what values are to be send for the traps defined in the Bridge-mib

Hi,

As part of my project i have to implement Bridge-mib in net-snmp. Two 
traps are defined in the Bridge-mib (newRoot and topologyChange).In the 
definition of the above traps its not mentioning any VARIABLES.

* What values (varibles) it should send for these traps.
   Please help me in this regards.

ANSA

_______________________________________________
Bridge-mib mailing list
Bridge-mib <at> ietf.org
https://www1.ietf.org/mailman/listinfo/bridge-mib

bridge-mib Source code

Hi ,
	
	I am doing a snmp-related project.Can i get the source code for
Bridge-MIB.txt .Please reply to me regarding this request.

Thank You,
ANSA.

From where can i get Bridge MIB Objects info in linux.

_______________________________________________
Bridge-mib mailing list
Bridge-mib <at> ietf.org
https://www1.ietf.org/mailman/listinfo/bridge-mib

FW: Static fdb table in q-bridge MIB?

-----Original Message-----
From: David Levi [mailto:dlevi <at> nortel.com] 
Sent: Monday, April 16, 2007 8:38 PM
To: Glenn Parsons; Paul Bottorff; Romascanu, Dan (Dan); Wijnen, Bert
(Bert)
Subject: Static fdb table in q-bridge MIB?

Hi All,

I was just about to make an update to the table for defining static fdb
entries in the new q-bridge MIB based on .1ah clause 12.7.7.  However,
there is no such table either in the new MIB, nor in the q-bridge MIB
from RFC 4363.  However, in RFC 4363, there is a reference to an object
called 'dot1qStaticAddress' in the DESCRIPTION of dot1qTpFdbStatus in
the dot1qTpFdbTable.  Does anybody know if there is a reason why there
is no such table in RFC 4363?  Does it make sense to add such a table in
the new q-bridge MIB?

Note that there is an equivalent table in the original bridge-mib,
called the dot1dStaticTable.  Of course, that table doesn't have a fid
in the index.  Seems like that table was lost in the translation to the
q-bridge mib.

-Dave

------------------------------------------------------------------------
David B. Levi             Nortel Networks    dlevi <at> nortelnetworks.com
Voice: +1 408 495 5138    ESN: 265-5138
------------------------------------------------------------------------

Doubt on 802.1w (max age)

Hi,

Setup:
     6 manageable switches are connected in linear fashion with root brdige
at top . In the root bridge ,max-age ,hellotime and forward-delay is
configured  as 6 ,1 and 4 .

Issue :
    In the sixth bridge ,learned value of max-age,hello time and forward
delay is found as 6 ,1 and 4.But the role of the port connected to
switch 6 alone is switching between F/R (Root) and F/D (Designated )

    We r using the source forge rstp source code for all 6 switches
    From 802.1w standard,I calculated the  rcvdinfowhile timer value for
the port connected to sixth switch as 1 (Calculation done from
updtRcvdInfoWhile()) .When port of switch 6 recieves BPDU  for every
hello time (1 sec) port role switches to F/R and on expiry of
rcvdInfoWhile timer expiry ( 1 sec ) port role switches to F/D .

   What do you think about it ?

RE: [802.1 - 1083] FW: Connectivity Fault Management MIB

Please provide clarifications for the IEEE8021-CFM-MIB in .1ag:

1. Norman Finn wrote:
> 4. The Stack Table will be revised to have the interface number, MD
> Level, VLAN ID or zero, and direction as inputs, and  produce
> Maintenance Domain index, MA index, MEPID (or 0 for MIPs) as outputs.

To my understanding, there cannot be more that one Maintenance Domains
with the same MD Level on a single Bridge. Am I right? 

2. Providing a single Bridge cannot have more than one Maintenance Domain 
with the same MD Level, then can you index the table dot1agCfmMdTable by
dot1agCfmMdLevel? In this case you don't need additional arbitrary integer
index dot1agCfmMdIndex neither dot1agCfmMdTableNextIndex. I offer 
to replace dot1agCfmMdIndex by dot1agCfmMdLevel in all relevant tables, for
example in dot1agCfmMaTable.

3. Now let's consider dot1agCfmMaTable. If the first index of this table is
dot1agCfmMdLevel, then you could use the pair {dot1agCfmMaFormat, dot1agCfmMaName}
as a second and third indexes: maximum length of index would be 1+1+1+45=48, not so
VERY long OIDs. Note that, for example, in 
DISMAN-PING-MIB (http://www.simpleweb.org/ietf/mibs/modules/IETF/txt/DISMAN-PING-MIB)
maximum index in pingCtlTable is 1+32+1+32=66.

So, the MIB would not need complex, unnatural objects dot1agCfmMdTableNextIndex
and dot1agCfmMaTableNextIndex neither type Dot1afCfmIndexIntegerNextFree; referential
integrity of tables would be provided automatically, issues of the index reusage,  increasing
and wrapping around.

4. The natural demands should be formulated:
a) When an entry in the dot1agCfmMdTable is deleted, all relevant entries in
dot1agCfmMaTable must be deleted as well, and
b)  When an entry in the dot1agCfmMaTable is deleted, all relevant entries
in dot1agCfmMepTable (etc.) must be deleted.

5. If the WG continue to use the arbitrary integer index dot1agCfmMdIndex with different
ranges for associated and not-associated, then instead of a single object dot1agCfmMaTableNextIndex
two objects must be defined, one per a such range, let us say:
dot1agCfmMaTableVlanedNextIndex (0, 1..4094) and 
dot1agCfmMaTableNonVlanedNextIndex (0, 16777217..4294967295).

And what is more, why second indexes in dot1agCfmMaEntry cannot be repeated inside
different domains? In other words object dot1agCfmMaTableNextIndex should be per MD.

Thanks, Alex

RE: Connectivity Fault Management MIB

Please provide clarifications for the IEEE8021-CFM-MIB in .1ag:

1. If dot1agCfmStackMepId==0 (a MEP is not configured on an interface),  what
value does index dot1agCfmMdIndex have in dot1agCfmStackTable?

2. Why the index, for example, in dot1agCfmMdTable is an single integer
one (dot1agCfmMdIndex) and not a pair {dot1agCfmMdFormat, dot1agCfmMdName}?
In this case we will not need the object dot1agCfmMdTableNextIndex, etc.

3. The same concerns dot1agCfmMaIndex vs. {dot1agCfmMaFormat, dot1agCfmMaName}. In another words, why
cannot we index 
dot1agCfmMaTable by index {dot1agCfmMdFormat, dot1agCfmMdName, dot1agCfmMaFormat, dot1agCfmMaName}?

4. Why do we have both the field dot1agCfmMaMoreThanOneVid and a special interval for dot1agCfmMaIndex to
reflect a association with VLAN? IMHO simpler method is to have in this table number of VLANs, that may be 0.

5. In the Table 17-1 object dot1agCfmMdIndex is referred to 12.14.2.1.2:b, but 12.14.2.1.2:b describes
"An MD Level". Could you use integer index dot1agCfmStackLevel instead? 

Thanks, Alex

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:dromasca <at> avaya.com]
Sent: Wednesday, November 15, 2006 12:10 AM
To: MIB Doctors; Bridge-Mib (E-mail)
Subject: [Bridge-mib] Connectivity Fault Management MIB 

The IEEE 802.1 P802.1ag/D7.1 - Connectivity Fault Management is running
a recirculation ballot. 

The full standard draft is available at: 

http://www.ieee802.org/1/files/private/ag-drafts/d7/802-1ag-d7-1.pdf

The MIB module in txt format is available at: 

http://www.ieee802.org/1/files/private/ag-drafts/d7/8021ag71.mib

Please review and provide comments until 11/23 to me, Bert, or the IEEE
802.1 WG e-mail list. 

Folks who need the IEEE Web site username and password for the purpose
of reviewing these documents are invited to approach me or Bert. 

Dan

_______________________________________________
Bridge-mib mailing list
Bridge-mib <at> ietf.org
https://www1.ietf.org/mailman/listinfo/bridge-mib

**********************************************************************************************************************

The information contained in this e-mail message and its attachments is privileged and confidential, and
is protected from unauthorized use or dissemination or by intellectual property rights. The
information is intended only for the use of the individual or entity named above. If the reader of this
message is not the intended recipient, you are hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited. If you have received this communication in error,
please notify MRV immediately by telephone, or by e-mail and delete the message from your computer.

Thank you!

************************************************************************************************************

 
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************

Connectivity Fault Management MIB

The IEEE 802.1 P802.1ag/D7.1 - Connectivity Fault Management is running
a recirculation ballot. 

The full standard draft is available at: 

http://www.ieee802.org/1/files/private/ag-drafts/d7/802-1ag-d7-1.pdf

The MIB module in txt format is available at: 

http://www.ieee802.org/1/files/private/ag-drafts/d7/8021ag71.mib

Please review and provide comments until 11/23 to me, Bert, or the IEEE
802.1 WG e-mail list. 

Folks who need the IEEE Web site username and password for the purpose
of reviewing these documents are invited to approach me or Bert. 

Dan

 

Out of Office AutoReply: Returned mail: see transcript for details

_______________________________________________
Bridge-mib mailing list
Bridge-mib <at> ietf.org
https://www1.ietf.org/mailman/listinfo/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:

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***

Question on IETF rfc4364; dot1qStaticUnicastTable

_______________________________________________
Bridge-mib mailing list
Bridge-mib <at> ietf.org
https://www1.ietf.org/mailman/listinfo/bridge-mib