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

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.

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

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

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

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.

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

Craig

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

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

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

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

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