| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2361.1 | This is *not* a problem, it is a normal behavior... | NETCAD::BATTERSBY | | Fri Jun 09 1995 12:36 | 18 |
| First be careful when using the word "problem". This *not* a problem.
It is a normal mode for a bridge/switch to be in a learning state
or pre-forwarding state prior to entering the forwarding state.
Any Digital bridge/switch (that I know of), will have a pre-forwarding
state before entering the forwarding state. This pre-forwarding
state lasts 30 seconds. After the bridge/switch goes into the
forwarding state, there should be normal management dialog that
will occur between a host making SNMP requests and the bridge/switch.
This holds true for the DECswitch 900EF (which is nothing more than
the current version of a DECbridge 900MX with a new bezel). So if you
are doing warm resets/restarts to the DECswitch 900EF (or to your
DECbridge 900MX), you have to wait until the switch/bridge is back into
the forwarding state.
The release note is simply advising the user of the normal behavior
of a bridge and to take this into account before conversing with it
via SNMP requests.
Bob
|
| 2361.2 | | CRONIC::LEMONS | And we thank you for your support. | Fri Jun 09 1995 12:53 | 5 |
| Thanks for the clarification, and pardon my ignorance! So 'learning mode' is a
state a bridge is in ONLY when it is powered on or reset?
Thanks
tl
|
| 2361.3 | Learning is a continual function of a bridge... | NETCAD::BATTERSBY | | Fri Jun 09 1995 14:46 | 11 |
| Not quite correct. During the preforwarding state, a bridge port is
receiving frames and learning the source addresses of these frames
and building its address table. Then it enters the forwarding state
where it continually receives and forwards frames to/from addresses
that it learns, and continues to receive and forward frames from
previously learned addresses.
So a store and forward bridge is always "learning" addresses. There are
many sources of information which go into details of this process, like
the Bridge and Extended LAN reference.
Bob
|
| 2361.4 | | NETCAD::DOODY | Michael Doody | Fri Jun 09 1995 15:39 | 5 |
| And it will go into pre-forwarding or learning any time you make a
connection change, like plugging a cable into a port.
md
|
| 2361.5 | | CRONIC::LEMONS | And we thank you for your support. | Fri Jun 09 1995 15:56 | 5 |
| Okay. But considering a steady state of no new cabling to the bridge, should
the learning that continually take place negatively impact the bridge's ability
to provide IP services to the Management Agent Module?
tl
|
| 2361.6 | | NETCAD::DOODY | Michael Doody | Fri Jun 09 1995 17:14 | 12 |
| No, normal forwarding operations of a bridge are not supposed to
affect the management of the bridge or the MAM when its used for IP
services. It is when the port that is used for communication between
Hubwatch and the MAM is in pre-forwarding state that you see the
timeouts - when the port is pre-forwarding, no communication takes
place. It should last 30 seconds and then you're done.
If you're seeing timeouts during management of your Hub and the bridge
is steady-state (you're not changing the configuration of your bridge
or anything connected to the bridge) then there is a problem.
md
|
| 2361.7 | | NETCAD::ANIL | | Wed Jun 21 1995 13:25 | 5 |
| Re .0: The quote from the HUBwatch release notes is misleading, and
the earlier responses correctly answer your questions. I'll talk
to the doc. people on getting this clarified.
Anil
|