[Bridge-mib] topologyChange TRAP-TYPE
hans.de_vleeschouwer@alcatel.be Wed, 31 March 2004 10:55 UTC
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13647 for <bridge-archive@odin.ietf.org>; Wed, 31 Mar 2004 05:55:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8dN8-00040f-Eo for bridge-archive@odin.ietf.org; Wed, 31 Mar 2004 05:55:02 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2VAt2mi015413 for bridge-archive@odin.ietf.org; Wed, 31 Mar 2004 05:55:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8dN6-0003zs-Qx; Wed, 31 Mar 2004 05:55:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8dMW-0003y8-Jc for bridge-mib@optimus.ietf.org; Wed, 31 Mar 2004 05:54:24 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13575 for <bridge-mib@ietf.org>; Wed, 31 Mar 2004 05:54:20 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8dMT-0002u3-00 for bridge-mib@ietf.org; Wed, 31 Mar 2004 05:54:21 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8dLT-0002lP-00 for bridge-mib@ietf.org; Wed, 31 Mar 2004 05:53:19 -0500
Received: from colt-na165.alcatel.fr ([62.23.212.165] helo=smail.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1B8dKp-0002fX-00 for bridge-mib@ietf.org; Wed, 31 Mar 2004 05:52:39 -0500
Received: from bemail06.netfr.alcatel.fr (bemail06.netfr.alcatel.fr [155.132.251.30]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i2VAqdIe001856 for <bridge-mib@ietf.org>; Wed, 31 Mar 2004 12:52:39 +0200
Received: from alcatel.be ([138.203.191.85]) by bemail06.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004033112523712:2927 ; Wed, 31 Mar 2004 12:52:37 +0200
Message-ID: <406AA2F5.3020102@alcatel.be>
Date: Wed, 31 Mar 2004 12:52:37 +0200
From: hans.de_vleeschouwer@alcatel.be
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: bridge-mib@ietf.org
X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 03/31/2004 12:52:37, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 03/31/2004 12:52:38, Serialize complete at 03/31/2004 12:52:38
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
X-Alcanet-MTA-scanned-and-authorized: yes
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Subject: [Bridge-mib] topologyChange TRAP-TYPE
Sender: bridge-mib-admin@ietf.org
Errors-To: bridge-mib-admin@ietf.org
X-BeenThere: bridge-mib@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/bridge-mib>, <mailto:bridge-mib-request@ietf.org?subject=unsubscribe>
List-Id: <bridge-mib.ietf.org>
List-Post: <mailto:bridge-mib@ietf.org>
List-Help: <mailto:bridge-mib-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/bridge-mib>, <mailto:bridge-mib-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Hi, I am new to this group, so plse forgive me if my questions have been asked before... I have 2 questions on how to handle the topologyChange TRAP-TYPE in RSTP. The description states that: "A topologyChange trap is sent by a bridge when any of its configured ports transitions from the Learning state to the Forwarding state, or from the Forwarding state to the Blocking state. 1) During the RSTP syncing phase there are temporary transitions to and from the forwarding state (the moving cut). With the above definition every single of those transitions will cause a trap although they do not imply any topology change. Is this realy the intented behavior in RSTP for this trap? 2) I assume that the state 'Blocking' must be read in RSTP (ref table 17.1 in IEE802.1w-2001) as '(port-state == Discarding) + (port-role == Alternate or Backup)' This means that if the MAC goes operationally down causing the link to leave the forwarding state this will not be reported via a TRAP. It is unclear for me why this is so, because to me it appears that this a real topology changing event. Thanks, Hans. the transition from Forwarding to _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib
- [Bridge-mib] topologyChange TRAP-TYPE hans.de_vleeschouwer