| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 3208.1 | You're seeing normal behavior | NETCAD::BATTERSBY | | Mon Jan 29 1996 17:37 | 35 |
| This appears to be a normal behavior.
The 900EF has 7 receive and transmit queues, one for each Ethernet
port. Each queue is 128 entries long. The FDDI receive and transmit
queue is 256 entries long.
Now, if you have a 900EF switch with no ports connected to an active
LAN for any sustained amount of time (over 5 minutes or more roughly),
the switch operational firmware will place each of the ports in
what is referred to as a broken state (not broken in the hardware
sense of broken). IE: the firmware places the inactive port in a
state that does not require active monitoring by the firmware like an
active port would require of the firmware.
Lets look at a situation where a cable is connected to a port. If this
cable is connected to another device with no traffic activity, but
does provide "connectivity" to the 900EF port, then the EF port will
go into pre-forwarding, then forwarding and will then start sending
"hello" messages once a second. If you divide 128 (transmit queue entries)
by 60 seconds, you get a little over 2 minutes. So if you remove a
cable from a port that has no other LAN traffic activity other than
the hello messages the port itself is tranmitting, it will take as much
as 2 minutes to come back to the forwarding state when you plug the
cable back in. You can observe that this will dramatically speed up
if you have any single port connected to an extended LAN with a normal
level of traffic. Now you go back to another port and do the remove/plug
with the cable and the port will come back right away. So the more
traffic you have passing through any individual port (filling up the
receive and transmit queues), the faster the firmware will wrap around
to the first queue entry and wake up the port again.
So, there is no parameter that you can set to bring the forwarding
state to a shorter time. You just need to have more traffic coming
into *any* port on the 900EF and the response time for going into
forwarding (when you remove and plug back in a cable), will be much
faster on all the other ports.
I hope this explanation makes sense, and helps answer your question.
Bob
|
| 3208.2 | Maybe dot1dStpBridgeForwardDelay? | NETCAD::GALLAGHER | | Fri Feb 02 1996 09:23 | 62 |
| >Is there any parameter setting that we can set to bring the port in
>"forwarding" state in a shorter time?
I'm not the best person to answer this, but from my limited research
it appears this MIB object might help. (I don't think HUBwatch allows
you the set it.)
> dot1dStpBridgeForwardDelay OBJECT-TYPE
> SYNTAX Timeout (400..3000)
> ACCESS read-write
> STATUS mandatory
> DESCRIPTION
> "The value that all bridges use for ForwardDelay
> when this bridge is acting as the root. Note that
> 802.1D-1990 specifies that the range for this
> parameter is related to the value of
> dot1dStpBridgeMaxAge. The granularity of this
> timer is specified by 802.1D-1990 to be 1 second.
> An agent may return a badValue error if a set is
> attempted to a value which is not a whole number
> of seconds."
> REFERENCE
> "IEEE 802.1D-1990: Section 4.5.3.10"
> ::= { dot1dStp 14 }
(This is from "The Bridge MIB" [RFC 1493], p 17.)
It appears that you have to identify and change your root bridge's
ForwardDelay - or change ForwardDelay on all the customers bridges.
(Either way doesn't sound like a good time to me.)
The definition of ForwardDelay is attached.
Another tidbit; I seems to remember that the default ForwardingDelay
was 30 seconds. Don't know if this was IEEE recommended, or a DEC default.
-Shawn
> dot1dStpForwardDelay OBJECT-TYPE
> SYNTAX Timeout
> ACCESS read-only
> STATUS mandatory
> DESCRIPTION
> "This time value, measured in units of hundredths
> of a second, controls how fast a port changes its
> spanning state when moving towards the Forwarding
> state. The value determines how long the port
> stays in each of the Listening and Learning
> states, which precede the Forwarding state. This
> value is also used, when a topology change has
> been detected and is underway, to age all dynamic
> entries in the Forwarding Database. [Note that
> this value is the one that this bridge is
> currently using, in contrast to
> dot1dStpBridgeForwardDelay which is the value that
> this bridge and all others would start using
> if/when this bridge were to become the root.]"
> REFERENCE
> "IEEE 802.1D-1990: Section 4.5.3.6"
> ::= { dot1dStp 11 }
|
| 3208.3 | Default values chosen for very good reasons..... | NETCAD::BATTERSBY | | Fri Feb 02 1996 12:40 | 14 |
| What Shawn has presented is, as he says true for the root bridge
in an extended LAN topology. the reason for the default forwarding
delay value, is to accomodate a very large variety of extended LAN
configurations. The defaults have been proven to work over a number
of bridge products that Digital has built in the past, and are in fact
the defaults that the IEEE specs also call out and recommend for using
for default values. I've been told in the past that playing with the
value of the forwarding delay amongst other bridging parameters is
asking for trouble unless one has a lot of experience with configuring
Extended LANs and also has a lot of experience with configuring 802
compliant bridges, neither which I believe one would find alot of
customers having.
Bob
|
| 3208.4 | | NPSS::MDLYONS | Michael D. Lyons DTN 226-6943 | Mon Feb 05 1996 14:00 | 29 |
| A small nit:
According to the 802.1d spec:
802.1d Recommended DEC bridge Range
value default
Bridge Hello Time 2.0 1.0 1.0 - 10.0
Bridge Forward Delay 15.0 15.0 4.0 - 30.0
Bridge Max Age 20.0 15.0 6.0 - 40.0
Those values are in seconds - the granularity is also seconds.
XLII calls it: 802.1d calls it:
-------------- ---------------
Forward delay Forward delay (but it's 1/2 of the DEC value)
Listen Time Max Age
Preforwarding state Listening + Learning (two states)
Backup state Blocking state
...these are not always exact matches - check the specs for precise
information. DEC "Forward delay" is twice the 802.1d "Forward delay" because
ours covers the amount of time spent in the "preforwarding" state, which is
really divided into two states in the 802.1d spec (the "listening" to
"learning" state).
MDL
|
| 3208.5 | Any intentions to modify it and bring it up faster? | HTSC19::KENNETH | | Tue Feb 06 1996 01:53 | 7 |
| Hi,
Just one more question. Now I know that it is normal for DECbridge 900EF.
Does our Engineering has any intention to modify the firmware so that can
bring the port to forwarding state a little bit faster?
Kenneth
|
| 3208.6 | | NETCAD::GALLAGHER | | Tue Feb 06 1996 09:03 | 20 |
| Kenneth,
>Does our Engineering has any intention to modify the firmware so that can
>bring the port to forwarding state a little bit faster?
No, because:
- there is a mechanism for changing the delays,
- delays are not bad.
You can change spanning tree bridge/switch characteristics using the
bridge MIB.
The delays allow time for the spanning tree to stabilize. The learning
delay allows the bridge/switch to learn the network configuration before
entering the forwarding state. This allows it to make better forwarding
decisions. A bridge with zero delay, for example, would begin flooding
all port because it didn't know any better.
-Shawn
|