Thanks to all who replied. The interesting thing is that the BPDUs you
finally saw are just the ordinary configuration BPDUs. It seems like a
really bad idea to use debug span tree since those BPDUs happen every 2
seconds. But, like I said before, that's OK. I see these things as an
opportunity! ;-)
Thank-you very much for looking into this.
Priscilla
At 12:40 AM 8/25/01, Paul Werner wrote:
>Comments within and below.
>
> > Does anyone have a router acting as a bridge in their lab
>network?
>
>Yes, a bunch of 2500s running everything from 12.09 to 12.2(3)
>and experimental smokin IPv6 code. I also have a BFR (Cisco
>7000) running 11.2(16)
>
> > Cisco documentation claims that there is a "debug span"
>command that
> > shows
> > BPDU frames in hex as they come in. Now, I think this is an
>awful idea,
> > since they come in every 2 seconds, but for a project I'm
>working on I
> > need
> > to find out if the command really exists.
>
>For starters, this appears to be one of those commands that has
>been propagated over the years as a recurring mistake in the
>command summaries. Just to let you know, this command first
>appeared in IOS 8.3 (yes, you are reading that correctly :-)
>
>http://www.cisco.com/univercd/cc/td/doc/product/software/ssr83/r
>pc_r/53998.htm#xtocid1116650
>
>Although the command was released in 8.3 code, very little was
>mentioned about it in terms of what you should see and how to
>interpret it. That appears to have been documented in IOS
>9.21, which is shown here:
>
>http://www.cisco.com/univercd/cc/td/doc/product/software/ssr921/
>dcr/80432.htm#xtocid755369
>
>It indicates the same sort of information that you read in the
>12.2 command reference. My guess is that right about at that
>time the Kalpana switches were becoming the rage, bridging was
>taking a back seat to routing and the focus was on routing and
>routing protocols. Although the functionality and debugs for
>bridging did improve over the years, the documentation does not
>appear to have kept up. For example, here is what my 12.2(3)
>cisco 2511 has to say about the debugs available:
>
>2511#debug spa?
>spanning-tree
>
>2511#debug spa
>2511#debug spanning-tree ?
> all All Spanning Tree debugging messages
> bpdu Spanning tree bridge protocol data units
> bpdu-opt Optimized BPDU handling
> config Spanning tree config changes
> etherchannel EtherChannel support
> events Spanning tree topology events
> exceptions Spanning tree exceptions
> general Spanning tree general
> pvst+ PVST+ events
> root Spanning tree root events
> snmp Spanning Tree SNMP handling
>
>Just for grins, I turned them all on and configured an IEEE
>bridge with routing disabled. Here is what I get:
>
>2511#sh span
>
> Bridge group 1 is executing the ieee compatible Spanning Tree
>protocol
> Bridge Identifier has priority 32768, address 0000.0c92.7624
> Configured hello time 2, max age 20, forward delay 15
> Current root has priority 32768, address 0000.0c83.e2d0
> Root port is 3 (Serial0), cost of root path is 647
> Topology change flag not set, detected flag not set
> Number of topology changes 3 last change occurred 00:38:31 ago
> from Serial0
> Times: hold 1, topology change 35, notification 2
> hello 2, max age 20, forward delay 15
> Timers: hello 0, topology change 0, notification 0, aging 300
>
> Port 3 (Serial0) of Bridge group 1 is forwarding
> --More--
>01:00:03: Returning spanning tree stats @ 5CEDA0
>01:00:03: Returning spanning tree port stat Port path cost
>647, Port priority
>128, Port Identifier 128.3.
> Designated root has priority 32768, address 0000.0c83.e2d0
> Designated bridge has priority 32768, address 0000.0c83.e2d0
> Designated port id is 128.6, designated path cost 0
> Timers: message age 2, forward delay 0, hold 0
> Number of transitions to forwarding state: 3
> BPDU: sent 57, received 1502
>
> Port 4 (Serial1) of Bridge group 1 is blocking
> Port path cost 647, Port priority 128, Port Identifier 128.4.
> Designated root has priority 32768, address 0000.0c83.e2d0
> Designated bridge has priority 32768, address 0000.0c83.e2d0
> Designated port id is 128.7, designated path cost 0
> Timers: message age 2, forward delay 0, hold 0
> Number of transitions to forwarding state: 1
> BPDU: sent 56, received 1509
>
>Here are the debugs:
>
>2511#sh deb
>Spanning Tree:
> Spanning Tree general debugging is on
> Spanning Tree Exceptions debugging is on
> Spanning Tree BPDU debugging is on
> Spanning Tree event debugging is on
> Spanning Tree root changes debugging is on
> Spanning Tree configuration debugging is on
> Spanning Tree etherchannel support debugging is on
> Spanning Tree PVST+ debugging is on
> Spanning Tree uplinkfast debugging is on
> Spanning Tree uplinkfast exceptions debugging is on
> Spanning Tree backbonefast general debugging is on
> Spanning Tree backbonefast detail debugging is on
> Spanning Tree backbonefast exceptions debugging is on
> Spanning Tree optimized bpdu handling debugging is on
> Spanning Tree optimized bpdu handling detail debugging is on
> Spanning Tree optimized bpdu handling packet level debugging
>is on
> Spanning Tree SNMP support debugging is on
>
>Here is the output from the debugs after one minute:
>
>nada...
>
>I was prepared to give up, but on a whim I decided that
>something just didn't "feel right". Why do we have debugs in
>many cases? Usually to point out some sort of problem that
>needs to be fixed. What sort of problem would need to be fixed
>in a bridged environment? Yes, you guessed it - the bridge
>loop. I tried to do this on my 2511 between the two serial
>interfaces, but the router was too smart for that (it reported
>that I has internally looped the two interfaces. So, I needed
>a router that had two LAN interfaces. I decided to go back to
>my BFR. I had a crossover cable ready and plugged it into E2/0
>and E2/1. I then proceeded to turn on the debugs (same ones
>you have - events and tree). here is what I saw:
>
>ST: Ethernet2/1
>0000000000008000000C00700000000000008000000C007000805B0000140002
>000F00
>ST: Ethernet2/1
>0000000000008000000C00700000000000008000000C007000805B0000140002
>000F00
>ST: Ethernet2/1
>0000000000008000000C00700000000000008000000C007000805B0000140002
>000F00
>
>When I broke the loop, the decode went away. It would appear
>that this was designed to try and track down bridge loops. It
>seems that the command evolved over time (as they usually do)
>and different subcommands were put in to add granularity. The
>base command however that gives the functionality you desire is:
>
>debug spanning tree
>
>and later,
>
>debug spanning-tree bpdu
>
>HTH,
>
>Paul Werner
>
> >
> > My routers will not run IOS beyond 11.0. (Hey, they were
>free! ;-) They
> > do
> > not support "debug span." They only support "debug span
>events" which
> > shows
> > this:
> >
> > Albany#debug span events
> > Spanning Tree event debugging is on
> > Albany#
> > ST: Topology Change rcvd on Ethernet0
> > ST: Topology Change rcvd on Ethernet1
> > ST: Topology Change rcvd on Ethernet0
> > ST: Topology Change rcvd on Ethernet1
> >
> > I'm wondering 2 things:
> >
> > Does "debug span events" still exist? (It's not in the
>documentation.)
> >
> > Does "debug span" exist? (It is in the documentation but
>doesn't work on
> > my
> > routers.)
> >
> > Could anyone try it for me and send me output?
> >
> > By the way, if you don't have bridging working on your
>routers, it's
> > really
> > easy to configure:
> >
> > bridge 1 protocol ieee
> > int e0
> > bridge-group 1
> > int e1
> > bridge-group 1
> >
> > THANK-YOU!!!!!!
> >
> > Priscilla
>
>________________________________________________
>Get your own "800" number
>Voicemail, fax, email, and a lot more
>http://www.ureach.com/reg/tag
________________________
Priscilla Oppenheimer
http://www.priscilla.com
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=17342&t=17165
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
