Re: Disabling spanning tree

Hah!

The problem is:

The question said to disable spanning tree:

Switch(config-if)#spanning-tree bpdufilter en
Switch(config-if)#do sh spann
VLAN0001
  Spanning tree enabled protocol ieee
  Root ID Priority 32769
             Address 001a.e2c4.3180
             This bridge is the root
             Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
  Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
             Address 001a.e2c4.3180
             Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
             Aging Time 300
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- --------
--------------------------------
Gi0/1 Desg FWD 4 128.1 P2p
Gi0/2 Desg FWD 4 128.2 P2p
Gi0/3 Desg FWD 4 128.3 P2p
Gi0/4 Desg FWD 4 128.4 P2p
Gi0/5 Desg FWD 4 128.5 P2p
Gi0/6 Desg FWD 4 128.6 P2p
Gi0/7 Desg FWD 4 128.7 P2p
Gi0/8 Desg FWD 4 128.8 P2p

Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- --------
--------------------------------
Gi0/11 Desg FWD 100 128.11 Shr

Now if it were said to simply stop spanning-tree I'd be more prone to agree.

But since the exam guide you probably have is probably vague at best, you
are probably correct.

If the writer could not interpret the question and then translate it to
English.... Well you get the point.

Now if your question said to efffectively disable the spanning tree
operation or something to that effect.

I'm debugging the spanning tree operation and this is what happens and damn
it happens a lot:

51.552: STP SW: TX: opt: VLAN1: bpdu cnt 8, chunk 0
*Mar 1 04:28:51.552: STP SW: TX: opt: VLAN1: ieee chunk 1, sstp chunk 2
*Mar 1 04:28:51.552: STP SW: TX: opt: VLAN1: ieee port count 8, sstp port
count 0
*Mar 1 04:28:51.552: optimized ieee bpdus to be sent on chunk 1
*Mar 1 04:28:51.552: idb GigabitEthernet0/2, vlan 1
*Mar 1 04:28:51.552: idb GigabitEthernet0/3, vlan 1
*Mar 1 04:28:51.552: idb GigabitEthernet0/4, vlan 1
*Mar 1 04:28:51.552: idb GigabitEthernet0/5, vlan 1
*Mar 1 04:28:51.552: idb GigabitEthernet0/6, vlan 1
*Mar 1 04:28:51.552: idb GigabitEthernet0/7, vlan 1
*Mar 1 04:28:51.552: idb GigabitEthernet0/8, vlan 1
*Mar 1 04:28:51.552: idb GigabitEthernet0/11, vlan 1

Now if you'll notice - G0/1 the port I configured "spanning-tree bpdufilter
enable" on...

is not sending any bpdu's (I've got one switch in front of me so it can't
receive if it wanted to - but it would not by virtue of the command
issued.).

==================

Here's what happened on G0/2 with dot1q-tunnel

Switch(config-if)#do sh run int g0/2
Building configuration...
Current configuration : 81 bytes
!
interface GigabitEthernet0/2
 switchport mode dot1q-tunnel
 no cdp enable
end
Switch(config-if)#do sh span
VLAN0001
  Spanning tree enabled protocol ieee
  Root ID Priority 32769
             Address 001a.e2c4.3180
             This bridge is the root
             Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
  Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
             Address 001a.e2c4.3180
             Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
             Aging Time 15
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- --------
--------------------------------
Gi0/1 Desg FWD 4 128.1 P2p
Gi0/2 Desg FWD 4 128.2 P2p
Gi0/3 Desg FWD 4 128.3 P2p
Gi0/4 Desg FWD 4 128.4 P2p
Gi0/5 Desg FWD 4 128.5 P2p
Gi0/6 Desg FWD 4 128.6 P2p
Gi0/7 Desg FWD 4 128.7 P2p
Gi0/8 Desg FWD 4 128.8 P2p

======================================

The problem is since this is probably not a series of tasks from one of the
local vendors - lots of speculation but no substance.

So in this case the question is vague and probably meant don't participate
in the spanning-tree process.

By disabling the sending or reception of bpdu's - this is accomplished.

No Switchport - would not be a solution as Tony said when he came to the
rescue and mentioned that this port was going to be placed in a given vlan
in a previous task.

Effectively the Spanning-Tree Election has on that port has been disabled.

Blogs and organic groups at http://www.ccie.net
Received on Thu Apr 23 2009 - 23:50:15 ART