07-01-2009 06:48 PM - edited 03-06-2019 06:33 AM
Is there a way to stop a colo customer's switch from participating in spanning-tree within our network?
An example, we're a colo hosting provider. Each colo customer gets their own vlan.
On our edge switch we assign the customer a vlan like so:
interface GigabitEthernet0/43
description Colo Customer #1
switchport access vlan 903
switchport mode access
speed 10
duplex full
no cdp enable
The customer has their own switch which they plug into Gi0/43.
Spanning-tree has calculated that the root bridge for Vlan 903 is the customer's switch.
switch1#sh spanning-tree vlan 903
VLAN0903
Spanning tree enabled protocol ieee
Root ID Priority 32769
Address 000e.833b.d780
Cost 3100
Port 43 (GigabitEthernet0/43)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/43 Root FWD 3100 128.43 P2p
Gi0/49 Desg FWD 3004 128.49 P2p
Gi0/50 Desg FWD 3020 128.50 P2p
Is there a way to stop the customer's switch from participating in spanning-tree so it doesn't become the root bridge? I've tried applying both "spanning-tree bpdufilter enable" and "spanning-tree bpduguard enable" on the interface but when I do this I lose data flow to the customer's network (see below).
Example 1:
interface GigabitEthernet0/43
spanning-tree bpdufilter enable
switch1#sh spanning-tree interface g0/43
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/43 Desg BKN*3100 128.43 P2p *LOOP_Inc
This occurs because we have "spanning-tree loopguard default" turned on by default so if the port doesn't receive any BPDUs, it goes into a broken (block) state.
Example 2:
interface GigabitEthernet0/43
spanning-tree bpduguard enable
switch1#sh spanning-tree interface g0/43
no spanning tree info available for GigabitEthernet0/43
switch1-g1-cr-mel#sh int g0/43
GigabitEthernet0/43 is down, line protocol is down (err-disabled)
So how do I continue to make the customer's network reachable whilst at the same time stopping their switch from participating in spanning tree with us.
Spanning tree config on the switch:
spanning-tree mode pvst
spanning-tree loopguard default
no spanning-tree optimize bpdu transmission
spanning-tree extend system-id
spanning-tree uplinkfast
Thanks.
Andy
Solved! Go to Solution.
07-01-2009 07:47 PM
I'm glad that worked out for you! If you find any caveats please post it, I don't think i would ever find another situation to manually adjust the link type, but morbid curiosity drives me sometimes :)
I don't believe there are any caveats, I think it's just the way spanning-tree treats the port, if you were to configure it as half-duplex, spanning-tree would default to a shared link-type and make the assumption you were connected to a hub, spanning-tree is still working as intended as far as I am aware.
Good Luck with the rest,
Craig
07-01-2009 07:02 PM
Spanning-tree cannot be turned off on a per port basis, you can disable it per VLAN or globally on the switch.
"no spanning-tree vlan ..."
But I don't think that would give the desired effects you are looking for. In this instance, I would change my root bridge priority to be lower than his, or if that wasn't possible, I would communicate directly with the customer to change his priority.
You can change your bridge priority by using:
"spanning-tree vlan 903 root primary"
Or instead of using the keywords "root primary" there is also a priority keyword, just remember that when you use the priority keyword, the priority has to be set in increments of 4096.
HTH,
Craig
07-01-2009 07:08 PM
Hi Craig,
Thanks for your reply. I didn't think it was possible to turn of STP on a per basis form what I've read.
We will be manually setting the root bridge to be our distribution switches shortly (which will address where the root will be), but for the moment I was wondering if there was a way to disable STP between us and our customers.
Thanks.
Andy
07-01-2009 07:18 PM
hi Andy,
It's hard to stop the STP interaction bwtween u and customers if you are using the same STP protocol.
and I think there're something you can do below
(a) disable stp either side
or
(b) force your switch be root, and enabling rootguard on your side
or
(c) use layer 3 connection between u and customers
or
(d) enable bpdufilter on the port connected to customers. And you must not enable bpdufilter globally, take care of this.
07-01-2009 07:34 PM
Hi Wandering,
Thanks for the reply...
(a) disable stp either side
Not sure if we want to do this because we need our edge switches to be part of our spanning tree topology.
(b) force your switch be root, and enabling rootguard on your side
It is likely that this is what we'll be doing.
(c) use layer 3 connection between u and customers
Not an option at this moment, but thanks for the suggestion.
Cheers.
Andy
07-01-2009 07:36 PM
Not without running into the same problem you already had with the loopguard feature.
BPDU filter is the best option.
You could get around the loopguard feature though, loopguard only protect point to point interfaces.
Do a show spanning-tree interface
You can try to go into your interface and issue "spanning-tree link-type shared"
Then you should be able to use BPDU filter on that port without loopguard disabling your port... Never tried anything like that but I don't see why it wouldn't work.
HTH,
Craig
07-01-2009 07:43 PM
Hi Craig,
That has done the trick. No BPDU's received on the interface connecting the customer's switch and spanning-tree therefore elects a new root bridge. Cool!
interface GigabitEthernet0/43
spanning-tree bpdufilter enable
spanning-tree link-type shared
switch1#sh spanning-tree vlan 903
VLAN0903
Spanning tree enabled protocol ieee
Root ID Priority 33671
Address 0015.2be0.aa40
Cost 3009
Port 49 (GigabitEthernet0/49)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 50055 (priority 49152 sys-id-ext 903)
Address 001d.e697.2680
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 15
Uplinkfast enabled
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/43 Desg FWD 3100 128.43 Shr
Gi0/49 Root FWD 3004 128.49 P2p
Gi0/50 Altn BLK 3020 128.50 P2p
switch1#sh spanning-tree vlan 903 detail
Port 43 (GigabitEthernet0/43) of VLAN0903 is designated forwarding
Port path cost 3100, Port priority 128, Port Identifier 128.43.
Designated root has priority 33671, address 0015.2be0.aa40
Designated bridge has priority 50055, address 001d.e697.2680
Designated port id is 128.43, designated path cost 3009
Timers: message age 0, forward delay 0, hold 0
Number of transitions to forwarding state: 1
Link type is shared
Bpdu filter is enabled
BPDU: sent 0, received 0
I'll go read up on the difference between a shared and p2p link now incase there's some caveats to this approach.
Many Thanks,
Andy
07-01-2009 07:47 PM
I'm glad that worked out for you! If you find any caveats please post it, I don't think i would ever find another situation to manually adjust the link type, but morbid curiosity drives me sometimes :)
I don't believe there are any caveats, I think it's just the way spanning-tree treats the port, if you were to configure it as half-duplex, spanning-tree would default to a shared link-type and make the assumption you were connected to a hub, spanning-tree is still working as intended as far as I am aware.
Good Luck with the rest,
Craig
07-02-2009 02:35 PM
There is another work around for this.
You can turn off loopguard on the port with the command "spanning-tree guard none". I'm testing this on Cisco 3560.
Other switch platforms may use the command "no spanning-tree guard" - but using this command on the 3560 had no effect and did not over ride the global setting of "spanning-tree loopguard default".
interface GigabitEthernet0/43
spanning-tree bpdufilter enable
spanning-tree guard none
Doing it this way means you do not have to change the link type to "shared" and the link remains a P2P link.
07-02-2009 06:30 PM
I was always under the impression that would disable all the guard features (bpdu including), good information, thanks!
Craig
07-06-2009 11:01 AM
The link type configuration is irrelevant. You might want to enable to enable portfast (portfast trunk) while you're at it.
It is not recommended to run STP with a source you don't trust. So with this configuration, you'll avoid any STP interaction with your customer. However, you won't be able to prevent a loop should the customer connects in another location in your network.
A solution could be to tunnel your customer's BPDUs across your domain by using L2PT.
Regards,
Francois
07-06-2009 11:22 AM
Given that his port is an access port not a trunk port, and if he wants to have BPDU filter on all portfast interfaces, and at that point I don't believe you can L2TP BPDU's if they are filtered (never attempted to do so, would be interesting to see which process takes precedence though), then yes simply enabling portfast trunk would also solve the problem.
Changing the link-type bypasses the loop guard feature which is globally enabled on the switch and allows him to enable BPDU-filter on the single interface with his current configuration.
Craig
07-07-2009 08:22 AM
Hi Craig,
That's indeed a question of precedence. When doing L2TP, the bpdufilter is just there to prevent the provider's BPDUs to reach the customer site. Customer's BPDUs are tunneled before being filtered;-)
Loopguard does not do anything on designated ports anyway, that's why you don't need to play with the link type. Even if you wanted to disable loopguard, you have an interface command that allows you to do so.
Regards,
Francois
07-07-2009 08:38 AM
That's actually good to know about the order in which tunneling / BPDU filtering takes place, thanks for the info.
In Andy's post right after mine, he had put the command for disabling loopguard on a per-interface basis, completely eliminating the need to change the link-type, I didn't even think to look at a command for that at the time, I knew it was globally enabled and skipped over that thought process :)
Craig
07-06-2009 03:49 PM
Hi Francois,
Thanks for the informative reply.
So based on what you're saying, if we had the same customer plug into different switches in our network and disabled spanning tree on the access port, a loop might occur for that customer's vlan?
Eg:
customer1 (vlan 100) --> switch1 --> dist switches <-- switch2 <-- customer1 (vlan 100)
If the root bridge for vlan 100 is on the distribution switch, is a loop still possible for vlan 100 if spanning tree was disabled at the ports on swith1 and switch2 for the customer? We're using PVST.
Thanks.
Andy
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide