switch diameter...

the ieee 802.1d standard recommends a diameter for the tree of 7 switches.  this means that any two switches should not be more than 7 hops apart...

the default hello time for the tree is 2 seconds... in other words, if the default hello time was set to 1 second (it can be from 1 to 10 seconds) the bpdu traffic for the tree would double...

knowing that bpdu's at two seconds is already a heavy load for any switch:

als2#debug spann bpdu                                                          
als2#                                                                          
Apr 17 05:47:11: STP: VLAN0001 rx BPDU: config protocol = ieee, packet from Fas
Apr 17 05:47:11: STP: enc 01 80 C2 00 00 00 00 0B 5F C9 00 07 00 26 42 42 03   
Apr 17 05:47:11: STP: Data     00000000006001000B5FC90000000000006001000B5FC9000
Apr 17 05:47:11: STP: VLAN0001 Fa0/7:0000 00 00 00 6001000B5FC90000 00000000 600
Apr 17 05:47:11: STP(1) port Fa0/7 supersedes 0                                
Apr 17 05:47:1                                                                 
als2#1: STP: VLAN0001 Fa0/17 tx BPDU: config protocol=ieee                     
    Data : 0000 00 00 00 6001000B5FC90000 00000013 80010009B752D780 8011 0100 10

setting for 1 second would be unwise...  remember to un all before the debug, then up arrow twice to recall the command and enter,  as a good practice before running debugs... setting hellos for longer will make the bpdu output to the terminal more palatable..

as always, running debugs on a production network is at your risk... you'll need an understanding boss...

changing timers is most effective at the root switch as the timers will then be propagated throughout the diameter...

also changing stp timers is a tricky proposition at best, and not recommended... leave that shit alone...

for stp enhancements, see...

 http://insearchofthecert.blogspot.com/2012/02/guest-post-warren-sullivan.html

telnet with nix..

telnet is a lot more flexible with nix... it's native, and you can do a lot... i can do this from the desktop also, but i chose to represent this from the vm...

i telnetted to all the switches and turned on debug ip icmp on the dls's so i could witness real time debugging from one machine to the other... problem is i do a lot of experiments that may cause a connection drop with telnet, and that is where some kind of access server would come in handy... still researching the most cost effective way to accomplish that, and without too many headaches, and console cables..

have i mentioned yet today that i hate windows...

the flexibility here is quite nice...

say hello ospf

don't forget to issue un all first, then:

r2620_01#debug ip ospf hello

OSPF hello events debugging is on
r2620_01#
1d08h: OSPF: Rcv hello from 3.3.3.3 area 0 from Serial0/0 11.0.0.3
1d08h: OSPF: End of hello processing
1d08h: OSPF: Rcv hello from 2.2.2.2 area 0 from Serial0/1 10.0.0.2
1d08h: OSPF: End of hello processing
1d08h: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 192.168.1.50
1d08h: OSPF: Send hello to 224.0.0.5 area 0 on Serial0/0 from 11.0.0.1
1d08h: OSPF: Send hello to 224.0.0.5 area 0 on Serial0/1 from 10.0.0.1
1d08h: OSPF: Rcv hello from 100.0.0.1 area 0 from FastEthernet0/0 192.168.1.100
1d08h: OSPF: End of hello processing
1d08h: OSPF: Rcv hello from 3.3.3.3 area 0 from Serial0/0 11.0.0.3
1d08h: OSPF: End of hello processing
1d08h: OSPF: Rcv hello from 2.2.2.2 area 0 from Serial0/1 10.0.0.2
1d08h: OSPF: End of hello processing
1d08h: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 192.168.1.50
1d08h: OSPF: Send hello to 224.0.0.5 area 0 on Serial0/0 from 11.0.0.1
1d08h: OSPF: Send hello to 224.0.0.5 area 0 on Serial0/1 from 10.0.0.1
1d08h: OSPF: Rcv hello from 100.0.0.1 area 0 from FastEthernet0/0 192.168.1.100
1d08h: OSPF: End of hello processing
1d08h: OSPF: Rcv hello from 3.3.3.3 area 0 from Serial0/0 11.0.0.3
1d08h: OSPF: End of hello processing
1d08h: OSPF: Rcv hello from 2.2.2.2 area 0 from Serial0/1 10.0.0.2
1d08h: OSPF: End of hello processing
1d08h: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 192.168.1.50
1d08h: OSPF: Send hello to 224.0.0.5 area 0 on Serial0/0 from 11.0.0.1
1d08h: OSPF: Send hello to 224.0.0.5 area 0 on Serial0/1 from 10.0.0.1
1d08h: OSPF: Rcv hello from 100.0.0.1 area 0 from FastEthernet0/0 192.168.1.100
1d08h: OSPF: End of hello processing
1d08h: OSPF: Rcv hello from 3.3.3.3 area 0 from Serial0/0 11.0.0.3
1d08h: OSPF: End of hello processing
1d08h: OSPF: Rcv hello from 2.2.2.2 area 0 from Serial0/1 10.0.0.2
1d08h: OSPF: End of hello processing
1d08h: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 192.168.1.50
all possible debugging has been turned off
r2620_01#

it's a whole new world out there...

spanning-treed...

i asked michael the network cat exactly what it is that spanning-tree does...
he replied, it prevents switching loops...
precisely...

so in case you don't have a meshed network, what then michael?

it causes a lot of traffic, slows down your ports, doesn't block any ports because there are no redundant links, but gives you nice output and bridge and port status information, lots of debugging stuff if you want to see it, and many other features that will be tested by cisco...

ok then... the right answer is the cisco answer...

why? how? wtf...

why hasn't cisco fabricated rj-45 to usb console cables?
so you can go out and spend 40 bucks to buy a 3rd party adapter...

when a root bridge is established, why is its priority 32769?
because of  sys-id-ext 1

how often does spanning-tree send hellos?
every 2 seconds

if you debug spanning-tree you can expect a lot of output at the console, so how do you preempt this?
by issuing the command un all before issuing the command debug spanning-tree... why?
so you can stop the madness by pressing up arrow and enter, to turn it off...

from a telnet session you issue debug spanning-tree... why isn't there any output to the screen?
you haven't issued terminal monitor from privileged-exec mode, that's why...

to accomplish convergence, what states must the ports be in?
blocking and forwarding

and how long does convergence take?
50 seconds

how do you turn off stp to get rid of this 50 second shit on a port?
in interface configuration mode use spanning-tree portfast and the the interface will move to forwarding on linkup