Does bpdufilter enabled globally really work for portfast ports?

Unanswered Question
Dec 24th, 2009

Hello.

I know the topic bpdufilter had been discussed many times in the forum but it looks to me none of the topics talked about whether it really works as stated in the cisco documents (or maybe I didn't find the right topic?). anyways here's my question.

First, I understand what was supposed to happen according to cisco press, that "If a BPDU is received on a Port Fast-enabled interface, the interface loses its Port Fast-operational status, and BPDU filtering is disabled."[1]. However, somehow I couldn't see the effect after the following configuration steps. Here's what I did:

platform: 2*3550 switches, topology:

----------fe0/3                    fe0/3---------

| sw1  |----------------------------------|sw2  |

----------                                   --------

the port fe0/3 on both switches are  access mode vlan 1. sw2 is the root bridge for vlan 1.

both sw1 and sw2 have"spanning-tree portfast enable"

at this point I "show spanning-tree int f0/3 detail" and saw bpdu received increasingly. I then unpluged the cable between sw1 and sw2 from f0/3 on sw1.

Then I had only sw1 configured"spanning-tree portfast bpdufilter default". Now, according to the document, when I plug the cable between the switches back into the port f0/3 on sw1, the port should receive BPDU from sw2, and therefore "loses its Port Fast-operational status, and BPDU filtering is disabled". The former also implies that the port should start the normal STP process, meaning going through "listening" "learning"...etc, after 30s, the port goes into forwarding, right?

NO. The port went immediately into forwarding right after I plugged the cable back in."show spanning-tree int f0/3" didn't see any lsn, lrn status. The portfast operation looked still working. What went wrong?

I believe that there was something wrong in my testing above, however I couldn't figure that out. Could some one please help me here?

Thanks a lot!

[1]http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_25_see/configuration/guide/swstpopt.html#wp1046220

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (3 ratings)
Loading.
Giuseppe Larosa Thu, 12/24/2009 - 08:29

Hello,

wellcome to the bpdu guard fan club !!!!

the right tool in an enterprise environment is BPDU guard that is the right companion for STP portfast on user ports.

Playing with STP bdpu filter in a lab may be interesting, but having bridging loops in production network caused by STP bdpu filter is not a good thing.

You can find several threads of people that had troubles (= loops) caused by STP Bdpu filter I would stay away from it.

STP bpdu filter can be useful for a L2 service provider to avoid to join its STP with customer's STP.

Hope to help

Giuseppe

CSCO10936521 Thu, 12/24/2009 - 08:47

Thank you for your quick reply.


However my question is not related to bpduguard. it's solely about the effect of "portfast bpdufilter default". The senario is stated in the above post. Why it's not working as it should be according to the documents? Or did I do it wrong?


at your comments:

the right tool in an enterprise environment is BPDU guard that is the right companion for STP portfast on user ports.

IMHO,BPDUguard and BPDUfilter fufill different purposes.That's why they both exsit in the IOS to select.

Playing with STP bdpu filter in a lab may be interesting, but having bridging loops in production network caused by STP bdpu filter is not a good thing.

I don't care the loops in the context of my testing. It's solely to prove what's being said in the Cisco document.

You can find several threads of people that had troubles (= loops) caused by STP Bdpu filter I would stay away from it.

It is not my question whether in real production we should stay away from that or not (even though I believe you are right), but again in my test, I don't care the loops. Whether there is a loop won't affect my testing. I just want to see that with "portfast bpdufilter default" eanbled globally, in a portfast port, when bpdu is received, THE PORTFAST OPERATION WILL BE LOST AND THE NORMAL SPANNING TREE PROCESS WILL START.

Hope to help

This general comment that I've also seen in some other threads doesn't help a lot. Sorry.


I believe that there must be something wrong that I did in my test. Could anyone please advise how to make this work? Thanks a million.

Peter Paluch Fri, 12/25/2009 - 05:20

Hello,

I believe that it is necessary to clarify a few things first.

First of all, you seem to be somewhat confusing the BPDUFilter and the STP PortFast features. As far as their functionality is concerned, they are independent. The STP PortFast is an implementation of the RSTP Edge Port feature that allows a port to transition immediately into Forwarding state after being connected. The BPDUFilter is a feature that prevents sending and optionally receiving BPDUs on a port. What may be confusing at first is that the BPDUFilter behaves differently when it is activated on a port and differently when it is activated globally.

If the BPDUFilter is activated directly on port (be it a PortFast port or not, trunk or access port) using the command spanning-tree bpdufilter enable:

  • The port does not send out BPDUs
  • The port ignores any BPDUs received

If the BPDUFilter is activated globally using the command spanning-tree portfast bpdufilter default:

  • It applies only to ports that are in PortFast mode
  • After a port goes up, it sends 11 BPDUs in the usual intervals (given by the STP Hello interval)
  • If no BPDU is received during this time, the port stops sending BPDUs
  • If during this time or at any other later time the port receives a BPDU, the BPDUFilter is deactivated on that port and it will start sending and processing BPDUs according to usual STP rules

Second, what you were trying to replicate in your experiment was basically to see how a PortFast port loses its edge status after receiving a BPDU. Why did you configure your switches with BPDU Filtering, then? For your experiment, it shall be completely sufficient to just make that port a PortFast-enabled port and leave the BPDUFilter untouched - do not combine these two features together when in fact you are interested in exploring just one of them - their interaction only confuses things instead of making them clearer for you to observe.

Third, even with only PortFast on your Fa0/3 ports, you may not see what you expect. Note that in your topology, one of your switches will be the STP root and it will be the one originating BPDUs. The other switch will not send any BPDUs towards the root switch out its root port until there is a topology change detected. Now, after you connect the Fa0/3 ports, it the root switch sends out its BPDU sooner than the non-root switch, the non-root switch will not send any BPDUs towards the root switch. As a result, the root switch will not hear any BPDU on its port towards non-root switch, and will retain the PortFast status of the port. Of course, the non-root switch shall immediately lose the PortFast status on its root port. You should be able to confirm this fact using the command show spanning-tree interface fa0/3 portfast.

Often, when I wanted to explore the behavior of BPDU Guard, BPDU Filter or STP PortFast on a port, I have connected two switches together through an intermediary hub (an optionally forced the switch ports to believe that this is a point-to-point link if I wanted to experiment with RSTP/MSTP). This way, I could observe what is happening on the link quite easily and I was able to inject BPDUs from a third party without influencing the two switches. For this purpose, a simple hub is still more operative than a SPAN port.

After reading this, please try to sort out what you are really seeking to see - PortFast or BPDUFilter - and if there are still unclear things, please feel free to ask further.

Best regards,

Peter

CSCO10936521 Fri, 12/25/2009 - 06:40

Hi Peter,

Thank you for your kind reply. Please find my comment in line in red

Hello,

I believe that it is necessary to clarify a few things first.


If the BPDUFilter is activated globally using the command spanning-tree portfast bpdufilter default:

  • If during this time or at any other later time the port receives a BPDU, the BPDUFilter is deactivated on that port and it will start sending and processing BPDUs according to usual STP rules

observed. I've seen that the BPDUFilter was deactivated because I saw the port started to send and receive BPDU again.However, I think you didn't mension another behavoir here, that " If a BPDU is received on a Port Fast-enabled interface, the interface loses its Port Fast-operational status"

Second, what you were trying to replicate in your experiment was basically to see how a PortFast port loses its edge status after receiving a BPDU. Why did you configure your switches with BPDU Filtering, then? For your experiment, it shall be completely sufficient to just make that port a PortFast-enabled port and leave the BPDUFilter untouched - do not combine these two features together when in fact you are interested in exploring just one of them - their interaction only confuses things instead of making them clearer for you to observe.

I'm sorry but I'm not 100% sure what you meant here by "it shall be completely sufficient to just make that port a PortFast-enabled port and leave the BPDUFilter untouched". As I clarified above, what I wanted to replicate was the fact that a PORTFAST PORT WOULD LOSE IT'S PORTFAST OPERATIONAL STATUS ", if the "BPDUFilter is activated globally using the command spanning-tree portfast bpdufilter default"(your words) . Now, I think what I might get confused is whether "PORTFAST PORT LOSE IT'S PORTFAST OPERATIONAL STATUS" would lead to the port to "CYCLE THROUGH THE REGULAR SPANNING-TREE PROCESS: "LSN"->"LRN"->"FORWARDING, or not? Because this is what exactly I wanted to see in my experiment. However, I saw that the port went to forwarding immediately.

Third, even with only PortFast on your Fa0/3 ports, you may not see what you expect. Note that in your topology, one of your switches will be the STP root and it will be the one originating BPDUs. The other switch will not send any BPDUs towards the root switch out its root port until there is a topology change detected. Now, after you connect the Fa0/3 ports, it the root switch sends out its BPDU sooner than the non-root switch, the non-root switch will not send any BPDUs towards the root switch. As a result, the root switch will not hear any BPDU on its port towards non-root switch, and will retain the PortFast status of the port. Of course, the non-root switch shall immediately lose the PortFast status on its root port. You should be able to confirm this fact using the command show spanning-tree interface fa0/3 portfast.

As what I drew in the topology (sorry for the format it changed after posting the message), the sw2 has been hard coded to be the root whist I tested the BPDUFilter on sw1, by which I made sure that the port f0/3 on SW1 could receive BPDU.

Often, when I wanted to explore the behavior of BPDU Guard, BPDU Filter or STP PortFast on a port, I have connected two switches together through an intermediary hub (an optionally forced the switch ports to believe that this is a point-to-point link if I wanted to experiment with RSTP/MSTP). This way, I could observe what is happening on the link quite easily and I was able to inject BPDUs from a third party without influencing the two switches. For this purpose, a simple hub is still more operative than a SPAN port.

Agreed.

After reading this, please try to sort out what you are really seeking to see - PortFast or BPDUFilter - and if there are still unclear things, please feel free to ask further.

Again, Thank you very much for your patient and detailed explanation.Best regards.

Jim

Peter Paluch Fri, 12/25/2009 - 13:36

Hello Jim,

You wrote:

However, I think you didn't mension another behavoir here, that " If a BPDU is received on a Port Fast-enabled interface, the interface loses its Port Fast-operational status"

Not if the BPDUFilter is activated directly on an interface. If the BPDUFilter is activated directly on an interface (and it does not matter if the interface is PortFast enabled or not), then all BPDUs received on such port are dropped and not processed - as if they never arrived. Therefore, if you activate the BPDUFilter directly on an interface, it will drop all received BPDUs before the PortFast code can see them - so such a port will never lose its PortFast status even if it receives BPDUs.

Of course, if the BPDUFilter is activated globally then, according to what I have described earlier, the BPDUs get processed, in which case a PortFast enabled port will lose its PortFast status.

If I understand you correctly, what you actually want to see is that when a port is PortFast enabled and at the same time, the BPDU Filter is activated globally, both these features get deactivated after the port receives a BPDU. Is this correct?

Now, I think what I might get confused is whether "PORTFAST PORT LOSE IT'S PORTFAST OPERATIONAL STATUS" would lead to the port to "CYCLE THROUGH THE REGULAR SPANNING-TREE PROCESS: "LSN"->"LRN"->"FORWARDING, or not?

Honestly, I do not know for sure but I would not bet on that. Losing the PortFast status is also connected with another issue: a port that is PortFast enabled does not generate topology changes when it goes up or down, or with legacy STP, when it goes into blocking state. Losing a PortFast status means that if the port goes into blocking state or goes down, it will generate a topology change event. With this in mind, I would rather verify the PortFast status of a port using the show spanning-tree interface fa0/3 portfast command instead of looking at its STP states.

So give it a try and please come back with any news or questions you might have. I'm looking forward to read it.

Best regards,

Peter

CSCO10936521 Sat, 12/26/2009 - 19:35

Thanks Peter,

I finally verified the bpdu status with the command you suggested. With the following observations I know understand what you said:

1. Without any bpdufilter enabled, just by portfast alone, if a portfast-enabled port sees BPDU, the portfast will be disabled (verified with show spanning-tree interface portfast); if the port connects to a host, the portfast remains enabled.


2. With the bpdufilter enabled globally, if this port sees BPDU, in addition to the portfast being disabled, the port also sends/receives BPDU normally, meaning the bpdufilter is also deactivated. However, if bpdufilter is only enalbed on this port, the port still doesn't send/receive any BPDU.

However, regardless of whether the portfast is enabled or disabled as seen in the output of show spanning-tree interface portfast, I never saw the port going through "LSN" "LRN". I still have some confusion about this part I believe.

The motivation for my test was actually from my client's request. They wanted me to configure all access ports to portfast because by default policy those ports should only connect to workstations. However it happend in history that some people connected their own group switches into the production network. This action could be either illegitimate or legitimate, depending on whether the management could approve it, therefore it cannot be simplly rejected by implementing BPDUguard. To make the things simple, they wanted the ports get out of the portfast status and start regular SPT if a switch is connected instead. At first I thought this was simple, I set up my little lab as described in the initial post to show them the effect, but when they asked me how come the port didn't go through the regular STP process, I couldn't answer. Any suggestions?

I really appreciate you for helping me clear many concepts up.

Best regards

Jim

Peter Paluch Sun, 12/27/2009 - 14:29

Hello,

At first I thought this was simple, I set up my little lab as described in the initial post to show them the effect, but when they asked me how come the port didn't go through the regular STP process, I couldn't answer.

I am sorry - I do not have any definitive answer to this question (I assume you are running legacy PVST+ and not the Rapid STP/RPVST+, that would be an important difference). Perhaps other friends here can answer this one more competently.

I can only hypothesize from what we have seen that a PortFast port that receives a BPDU makes an immediate decision upon its arrival. For example, in your particular case, the PortFast enabled port Fa0/3 turned out to be the root port for Sw1 after receiving the BPDU from Sw2. It is quite clear that such a port should remain unblocked, therefore, the switch probably decided to leave that port in the forwarding state. It would be interesting to see what would happen if the switch Sw1 had a different root port leading to Sw2, and the Fa0/3 would be yet another port leading to Sw2 that should be - depending on the switch BIDs - either designated forwarding, or alternate blocking (I am using the RSTP terminology here but it is backwards applicable to the STP as well) - whether such port would go over the Blocking/Listening/Learning states. I would test it in my lab and I would also turn on individual STP debugs to see what is going on the switch but unfortunately, I do not have access to the lab equipment during the following week so I am unable to confirm it myself.

Sorry for not being able to explain more at the moment

Best regards,

Peter

Giuseppe Larosa Mon, 12/28/2009 - 02:24

Hello Jim,

first of all, I think that Peter has done a great job clarifying the differences in IOS based switches between configuration at the port level and at the global level.

I've rated his posts accordingly.

About your test results I think they confirm that STP bpu filter is still a dangerous tool: bypassing listening and learning state is not safe in legacy STP.

What if the same group switch is connected with two cables to your infrastructure switches?

For correctness, I would say that what you see may be considered a SW defect so it may be time to open a service request regarding this behaviour of STP bpdu filter.


Getting a feedaback from TAC may help you in presenting the test results to managers.

Hope to help

Giuseppe

Mohamed Sobair Sun, 12/27/2009 - 01:49

Hi Peter,

According to the documentation, BPDU filter prevents ((Portfast Enabled Ports)) from transmitting BPDUs. However, I havent seen it in any documentation mentioning only drops the RECIEVED BPDU on a port rather than the sending BPDUs.

could you elaborate more on some documentaion regarding this subject

Here is part of the documentation of How BPDU filter works:

http://www.cisco.com/en/US/docs/switches/lan/catalyst4000/7.4/configuration/guide/stp_enha.html#wp1020084

Mohamed

Peter Paluch Sun, 12/27/2009 - 14:49

Hello Mohamed,

I am glad you asked. The documentation you have referenced in the provided URL concerns the BPDU Filter implementation in the CatOS operating system.

In the IOS for Catalyst switches, the BPDU Filter feature seems to be implemented differently. Consider, for example, the following link:


http://cisco.com/en/US/docs/switches/lan/catalyst2960/software/release/12.2_52_se/configuration/guide/swstpopt.html#wp1046220

Specifically, it says:

The BPDU filtering feature can be globally enabled on the switch or can be enabled per interface, but the feature operates with some differences.

At the global level, you can enable BPDU filtering on Port Fast-enabled interfaces by using the spanning-tree portfast bpdufilter default global configuration command. This command prevents interfaces that are in a Port Fast-operational state from sending or receiving BPDUs. The interfaces still send a few BPDUs at link-up before the switch begins to filter outbound BPDUs. You should globally enable BPDU filtering on a switch so that hosts connected to these interfaces do not receive BPDUs. If a BPDU is received on a Port Fast-enabled interface, the interface loses its Port Fast-operational status, and BPDU filtering is disabled.

At the interface level, you can enable BPDU filtering on any interface by using the spanning-tree bpdufilter enable interface configuration command without also enabling the Port Fast feature. This command prevents the interface from sending or receiving BPDUs.

Note that the documentation is even conflicting itself here - regarding the global level BPDU Filter configuration, it says that it "prevents interfaces [ ... ] from sending or receiving BPDUs" while later, it states that "If a BPDU is received [ ... ] the BPDU Filtering is disabled". If the port was prevented from receiving (i.e. processing) BPDUs, how would it be able to disable the BPDU Filter upon receiving a BPDU?

In any case, on IOS-based Catalyst platforms, the BPDU Filter behavior differs according to how it was activated, and this was the basis of my description of how the BPDU Filter works in my previous post. The details that are not described in the documentation were gathered from CCNP:BCMSN curricula for Networking Academies, and from my personal observation when experimenting with this feature.

Best regards,

Peter

Actions

This Discussion