How to seperate STP domains

Answered Question
Jul 1st, 2009
User Badges:

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

Correct Answer by xcz504d1114 about 7 years 10 months ago

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.8 (9 ratings)
Loading.
xcz504d1114 Wed, 07/01/2009 - 19:02
User Badges:
  • Bronze, 100 points or more

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

asaykao73 Wed, 07/01/2009 - 19:08
User Badges:

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

wandering_997 Wed, 07/01/2009 - 19:18
User Badges:

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.



asaykao73 Wed, 07/01/2009 - 19:34
User Badges:

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

xcz504d1114 Wed, 07/01/2009 - 19:36
User Badges:
  • Bronze, 100 points or more

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 and you will see on the far right it will say "P2p"


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

asaykao73 Wed, 07/01/2009 - 19:43
User Badges:

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

Correct Answer
xcz504d1114 Wed, 07/01/2009 - 19:47
User Badges:
  • Bronze, 100 points or more

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

asaykao73 Thu, 07/02/2009 - 14:35
User Badges:

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.

xcz504d1114 Thu, 07/02/2009 - 18:30
User Badges:
  • Bronze, 100 points or more

I was always under the impression that would disable all the guard features (bpdu including), good information, thanks!


Craig

Francois Tallet Mon, 07/06/2009 - 11:01
User Badges:
  • Gold, 750 points or more

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

xcz504d1114 Mon, 07/06/2009 - 11:22
User Badges:
  • Bronze, 100 points or more

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

Francois Tallet Tue, 07/07/2009 - 08:22
User Badges:
  • Gold, 750 points or more

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

xcz504d1114 Tue, 07/07/2009 - 08:38
User Badges:
  • Bronze, 100 points or more

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

asaykao73 Mon, 07/06/2009 - 15:49
User Badges:

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





xcz504d1114 Mon, 07/06/2009 - 17:56
User Badges:
  • Bronze, 100 points or more

A loop is independent of the root bridge, a root bridge just defines the path the traffic should take to its Layer 2 destination. Broadcast traffic, multicast traffic (if no multicast routing is happening) and unknown unicast traffic will be looped because neither of those ports are in a blocking state.


His suggestion of a L2TP would most definitely solve that.


Craig

Francois Tallet Tue, 07/07/2009 - 08:26
User Badges:
  • Gold, 750 points or more

Yes, you would have a loop there. Be careful that it's not STP that creates the loop, it's the data;-) So disabling STP, or restricting its operation generally increases the risk of loop...

Your options are peering with your customer (running STP with them, with rootguard at the edge if you want). Else you can tunnel their BPDUs (in which case, your "provider" network will look like a big hub to them). Or you can prevent them from sending you any BPDUs, in which case I would enable BPDU guard.

That's all depending on your relation with this other domain. For example, if they are susceptible of launching a DOS attack on your edge switches, by blasting BPDUs, you want BPDUguard. If you are under the same administrative control, you can peer. If you are not under the same administrative control but you "trust" them, then you can tunnel.

Regards,

Francois

asaykao73 Sun, 07/12/2009 - 18:18
User Badges:

Thanks for your help Francois. I'll digest everything :)

Actions

This Discussion