BPDUs - to send or not to send

[dmease]

Hi,

We have a 4500, and are looking into future server virtualisation, and as such, the switch ports that are connected to the servers are configured as trunk ports, and given ports are configured as follows:

interface GigabitEthernetx/y

switchport trunk encapsulation dot1q

switchport mode trunk

logging event link-status

spanning-tree portfast trunk

As we have 25 VLANs configured on this switch, it appears that each interface configured along these lines adds 25 instances to STP.

Due to the number of ports configured this way, the STP process is constantly running at around 35% CPU, so I was looking at ways of cutting this useage down.

My question is as follows, based on the following links (I appreciate that these links are based on 6500, but I assume that this specific process is the same):

-----

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.1E/native/configuration/guide/stp_enha.html#wp1042489

"STP PortFast causes a Layer 2 LAN interface configured as an access port to enter the forwarding state immediately, bypassing the listening and learning states"

"When configured for PortFast, a port is still running the spanning tree protocol."

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.1E/native/configuration/guide/stp_enha.html#wp1033403

"PortFast BPDU filtering can also be configured on a per-port basis. When PortFast BPDU filtering is explicitly configured on a port, it does not send any BPDUs and drops all BPDUs it receives."

-----

Question 1: Does the above imply that if a port is configured as portfast, that it still continues to send BPDUs out of this port? If it does, could anybody point me to a summary example of why it would do this?

Question 1a: If it does, will BPDU filtering (on a per-port basis) cut down the amount of processing, or will the BPDU essentially still get processed before it is dropped?

Question 1b: Again, if it does, will cutting down on the allowed VLANs with 'switchport trunk allowed vlan' command cut the CPU useage down?

Question 2: If a portfast port doesnt send BPDUs, and only a few ports on the switch are not configured as portfast, would there be any other reason why the CPU useage for this process would be so high?

Question 3: I am currently trying to get my head around MST - does anybody think this would be a potential option, and if so, does MST have to be configured on all of the switches? What could be the consequences of misconfiguring this?

Question 4: If i dont want the ports connected to the servers to participate in STP, would there be any issues with disabling STP on this port?

Any help would be greatly appreciated.

cheers,

[villi1977]

Hello.

My cisco is WS-C3560-24TS-S

My ios c3560-ipservicesk9-mz.122-52.SE

My aunomus is 196714

Please hemk my ios dont support bgp after 65635.

Avaliable ios for cisco WS-C3560-24TS-S with suppot bgp after 65635.

Please help my.

Please answer my.

[vazquez.jorge]

Hello,

I think I can help.

1. When portfast is enable on a interface, the port instead of waiting for about 30 - 50 seconds to pass traffic, it will skip listening and learning states (each add about 15 seconds). This is a problem for access nodes on these interfaces because when a pc is connected, it will send out a DHCP request. It will continue to send out DHCP request for about 30 seconds. Well, spanning tree takes about 30 - 50seconds, and the pc will fail to get a dhcp ip address. (this is just one example of spanning tree causing temporary problems). By enabling portfast, you cut down the timer to pass traffic, and (in this case) the pc will have enough time to pass the dhcp request and get a reply.

1a. bdpu filter will not pass or receive/process traffic. But very aware, this should only be used on access devices, NOT to other switches. Many times, I have configured the port with bdpu filter for a workstation, only to find out that the end users stick a small switch and somehow manage to loop it back and cause a broadcast storm. Lock it down with mac address port security and/or bdpu guard (this function will cause the port to go into err-dis if it receives any BDPU packets) and it should fix the problem.

2. Portfast has nothing to do with eliminating/filtering BDPU packets, it just eliminates the listening and learning states. In case you do enable portfast and it goes to another switch, you might create a temporary loop in the network but it will correct itself after a few seconds (30 seconds?). But it can take longer depending on the network, and it will cause network wide convergence, taking longer to get everything back to normal. On top of that, if the new switch has a lower mac address than your core switches, it will become root bridge, on an inferior switch. This can have devasting effects if you are unaware of the intruder switch on your network. BDPU packets will be send and processed (received) by a port with portfast enabled.

3. MST.. I am not 100% on this, but I will take a stab at it. MST, what it does (from what I understand) instead of the core switch sending out BDPU packets to every vlan, it send one BDPU packet to each mst group (in my environment, we have two group with each having about 100 vlans), this cuts down on BDPU packets thus cutting down on processing power on your switch. You will have to do more research on this cause again, I might be incorrect but the general idea I am sure its correct. MST does have to be configured on all switches participating on the network. I do not think its compatible with other versions of stp. I don't think I have to explain what are the consequences of misconfiguration. :-)

4. I do not think you truly disable stp on any port. But I have never seen stp causing problems or even issues when configured correctly.

I hope this helps.

[dmease]

Hi!

Many thanks for your answer. I am currently studying for the BCMSN, so need to get my head down a little more when it comes to this subject by the looks of things :-)

Sorry, but I have a couple more questions based on the above:

1) If I do configure the 'switchport trunk allowed vlan xxx' command, does STP stop sending BPDUs for VLANs that are not allowed over that trunk? May be obvious but I cant find confirmation of that anywhere.

2) If I enable BPDU filtering on port x/y, does the switch go through the process of creating an outbound BPDU for that port before dropping/filtering it, or does it not bother with that at all?

Thanks for your assistance so far!

cheers,

[Giuseppe Larosa]

Hello Darren,

1)

your understanding is correct and actually relying on automatic pruning (VTP pruning) does NOT limit the number of STP instances.

some low end switches can handle only 64 or 128 STP instances and this can become a scalability problem when the number of vlans in the campus is more then these numbers.

Several colleagues have reported problems caused by this.

2)

BPDU filtering not recommend in an enteprise environment.

>> If I enable BPDU filtering on port x/y, does the switch go through the process of creating an outbound BPDU for that port before dropping/filtering it, or does it not bother with that at all?

Switch BPDUs differs only in:

source MAC address = port MAC address

sender port id = port id of port

the BPDU is prepared once the root port is elected and reflects root path cost as seen on the root port.

I think it is not a problem if the BPDU is prepared and then dropped for the BPDU filtering enabled on the port.

Hope to help

Giuseppe

[vazquez.jorge]

1) If I do configure the 'switchport trunk allowed vlan xxx' command, does STP stop sending BPDUs for VLANs that are not allowed over that trunk? May be obvious but I cant find confirmation of that anywhere.

It depends on which stp you are running, but it does not contain vlan information, only port costs, ports, addresses, and priorities.

2) If I enable BPDU filtering on port x/y, does the switch go through the process of creating an outbound BPDU for that port before dropping/filtering it, or does it not bother with that at all?

It simply shuts it down. No passing or receiving (otherwords does not process incoming or outgoing). Like the other posters says, its usually not recommended, but there are situations where its called for. Example includes, Let's say company-x bought out company-y, now both companies are one. Well at one point they will have to be connected, but you are not ready for a company network wide official convergence. Well, you might not want one network to take root control over the other network. On the two switches where the networks meet, you enable BDPU filtering, to make sure one network doesnt become root for both causing unwanted changes. Now both networks can talk to each other without actually becoming one network.

One more note, stp BDPU hellos are sent every 3 seconds. These packets are very small and I do not think should be the focus of your problems. Is your 4500 switch fully populated? At what speeds? 100MB? 1,000MB? You might be oversubscribing, or hitting it hard, the backplane on that 4500 switch.