Solved: Re: Help with a question on Edge port

Steph1963 · ‎08-10-2011

Hi,

I have found that question for the Tswitch exam and not really sure if it makes sense.

What two things will occur when an edge port receives BPDU

The port becomes a normal STP switch port

The port immediately transisitions to a forwarding state

The port immediately transitions to the err-disable state

The switch generates a Topology Change Notification.

Answers: The port becomes a normal STP switch port & The switch generates a Topology Change Notfiicaton

Can somebody confirm me that an edge port is a concept that is more related to RSTP than STP and that portfast must be enable before a port can becomes and edge port.

If I am not mistaken, STP will send a TCN BPDU only on a port changed (up/down), I am not sure how would react Spanning-Tree if a port is up for a while and suddenly receives a BPDU. Does it really send a Topology Change Notification since the port was up before it receives the BPDU.

Thanks for your help

Stephane

Peter Paluch · ‎08-11-2011

Gentlemen,

I apologize for posting this reply lately.

My testing topology constituted a switch whose PortFast-enabled port Fa0/1 was connected to another switch, while there was already a Gi0/1 link between the switches serving as the root port link. On the another switch, I used the BPDUFilter feature to control the sending of BPDUs towards my PortFast port. Following is the transcript of show and debug command outputs on the switch with the PortFast port:

Sw2(config-if)#do show span sum

Switch is in pvst mode

Root bridge for: none

Extended system ID is enabled

Portfast Default is disabled

PortFast BPDU Guard Default is disabled

Portfast BPDU Filter Default is disabled

Loopguard Default is disabled

EtherChannel misconfig guard is enabled

UplinkFast is disabled

BackboneFast is disabled

Configured Pathcost method used is short

Name Blocking Listening Learning Forwarding STP Active

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

VLAN0001 0 0 0 1 1

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

1 vlan 0 0 0 1 1

Sw2(config-if)#do show span

VLAN0001

Spanning tree enabled protocol ieee

Root ID Priority 8193

Address f4ac.c191.9200

Cost 4

Port 25 (GigabitEthernet0/1)

Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)

Address 0021.1c3e.a200

Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Aging Time 300 sec

Interface Role Sts Cost Prio.Nbr Type

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

Gi0/1 Root FWD 4 128.25 P2p

Sw2(config-if)#do show run int gi0/1

Building configuration...

Current configuration : 60 bytes

!

interface GigabitEthernet0/1

switchport mode access

end

Sw2(config-if)#do show run int fa0/1

Building configuration...

Current configuration : 91 bytes

!

interface FastEthernet0/1

switchport mode access

shutdown

spanning-tree portfast

end

Sw2(config-if)#int fa0/1

Sw2(config-if)#no shut

Sw2(config-if)#

*Mar 2 09:56:16.221: STP SW: BANDWIDTH CHANGE: FastEthernet0/1 new bandwidth 100000(100000) kbits/sec

*Mar 2 09:56:16.221: STP SW: 1 virtual port being added single: Fa0/1.1

*Mar 2 09:56:16.221: STP SW: 1 virtual port link up single: Fa0/1.1

*Mar 2 09:56:16.230: STP CFG: found port cfg FastEthernet0/1 (315F284)

*Mar 2 09:56:16.230: set portid: VLAN0001 Fa0/1: new port id 8001

*Mar 2 09:56:16.230: Created spanning tree port Fa0/1 (2380F6C) for tree VLAN0001 (3379CAC)

*Mar 2 09:56:16.230: STP: PVST vlan 1 port Fa0/1 created, ext id 315F284

*Mar 2 09:56:16.230: Enabling spanning tree port: FastEthernet0/1 (2380F6C)

*Mar 2 09:56:16.230: STP SW: Fa0/1 new blocking req for 1 vlans

*Mar 2 09:56:16.230: STP: VLAN0001 Fa0/1 ->jump to forwarding from blocking

*Mar 2 09:56:16.230: STP: stp_helper_remove_from_other_queues closing EV:0 for empty request

*Mar 2 09:56:16.230: STP SW: Fa0/1 new forwarding req for 1 vlans

*Mar 2 09:56:16.230: STP Helper: Fa0/1 forwarding 1 vlans agg 1 q 0 dur 0ms

*Mar 2 09:56:16.230: STP Helper: will sleep, processed 1, yield 0ms

*Mar 2 09:56:16.565: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to up

*Mar 2 09:56:17.572: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to up

Sw2(config-if)#do show span

VLAN0001

Spanning tree enabled protocol ieee

Root ID Priority 8193

Address f4ac.c191.9200

Cost 4

Port 25 (GigabitEthernet0/1)

Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)

Address 0021.1c3e.a200

Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Aging Time 300 sec

Interface Role Sts Cost Prio.Nbr Type

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

Fa0/1 Desg FWD 19 128.1 P2p Edge

Gi0/1 Root FWD 4 128.25 P2p

Sw2(config-if)#do show span int fa0/1 portfast

VLAN0001 enabled

Sw2(config-if)#

Sw2(config-if)# ! At this moment, BPDUs were allowed

Sw2(config-if)# ! to be sent towards the PortFast port from another switch

Sw2(config-if)#

*Mar 2 09:57:53.244: STP CFG: found port cfg FastEthernet0/1 (315F284)

*Mar 2 09:57:53.244: STP: VLAN0001 sent Topology Change Notice on Gi0/1

*Mar 2 09:57:53.244: STP SW: Fa0/1 new blocking req for 1 vlans

*Mar 2 09:57:53.244: STP[1]: Generating TC trap for port FastEthernet0/1

*Mar 2 09:57:53.244: STP: VLAN0001 Fa0/1 -> blocking

*Mar 2 09:57:53.244: STP Helper: Fa0/1 blocking 1 vlans agg 1 q 0 dur 0ms

*Mar 2 09:57:53.244: STP Helper: will sleep, processed 1, yield 0ms

*Mar 2 09:57:54.250: STP SW: VLAN1: age time set to 15 secs

*Mar 2 09:57:54.250: STP SW: VLAN1: topology change over - this bridge is not root

Sw2(config-if)#do show span

VLAN0001

Spanning tree enabled protocol ieee

Root ID Priority 8193

Address f4ac.c191.9200

Cost 4

Port 25 (GigabitEthernet0/1)

Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)

Address 0021.1c3e.a200

Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Aging Time 15 sec

Interface Role Sts Cost Prio.Nbr Type

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

Fa0/1 Altn BLK 19 128.1 P2p ! Note - not edge anymore

Gi0/1 Root FWD 4 128.25 P2p

Sw2(config-if)#

Sw2(config-if)#do show span int fa0/1 portfast

VLAN0001 disabled

Sw2(config-if)#

As you can see from the debugs above, the Fa0/1 port was considered PortFast-enabled until it received a BPDU. Then, a topology change was sent - presumably as the result of moving the Fa0/1 to the Blocking state - and subsequent displaying of the STP configuration and PortFast state on the port revealed that port as disabled for the PortFast operation.

Regarding the debugs, I had almost all STP debugs activated except those that display the received and sent BPDUs, and those which clearly did not correspond to our situation (MSTP debugs, uplinkfast debugs, etc.)

Following the results, I believe that we can safely say that when a PortFast enabled port receives a BPDU, it loses its PortFast status. According to my further experiments, a topology change is sent when the usual requirements are met: in STP, a previously Forwarding port becomes non-forwarding, or a previously non-forwarding port becomes Forwarding.

Best regards,

Peter

View solution in original post

Peter Paluch · ‎08-10-2011

Hello Stephane,

Answers: The port becomes a normal STP switch port & The switch generates a Topology Change Notfiicaton

Yes, those two answers are correct.

Can somebody confirm me that an edge port is a concept that is more  related to RSTP than STP and that portfast must be enable before a port  can becomes and edge port.

This is true, however, the edge port concept that is IEEE-standardized was at least partially inspired by the PortFast feature that Cisco introduced for the legacy STP in the times the RSTP did not yet exist. An edge port cannot be reliably detected automatically, rather, it must be configured explicitly. Cisco decided that the command to designate a port as an edge port will remain as the spanning-tree portfast to provide seamless transition from STP to RSTP without a need to modify the switch configuration.

If I am not mistaken, STP will send a TCN BPDU only on a port changed  (up/down), I am not sure how would react Spanning-Tree if a port is up  for a while and suddenly receives a BPDU.

For edge (or PortFast-enabled) ports, their state changes are not considered as topology changes. However, if an edge (or PortFast-enabled) port indeed receives a BPDU, it will lose its edge/PortFast status until the port is disconnected, and this event of losing the edge/PortFast status is considered a topology change.

Feel welcome to ask further!

Best regards,

Peter

Mohamed Sobair · ‎08-10-2011

Hi Stephane,

Your Understanding is correct. an Edge port is a concept of RSTP and the portfast has to be enabled on the port before it can be considered an Edge port.

However, by default without adding additional STP features command, an RSTP Edge port DOESNT turns to be a normal STP port neither generate a TCN if it recieves BPDUs.

This symptoms is true, when Spanning-tree Portfast BPDUFILTER is enabled Globally on the Switch. Thats why a precaution must be taken when configuring portfast on a port cause it could lead to Spanning-tree loop if not configured correctly on a real Edge port that Shouldnt recieves BPDU.

HTH

Mohamed

Peter Paluch · ‎08-10-2011

Hello Mohamed,

One of your statements caught my attention:

However, by default without adding additional STP features command, an  RSTP Edge port DOESNT turns to be a normal STP port neither generate a  TCN if it recieves BPDUs.

To my best knowledge, the situation is exactly the opposite - even without configuring any other STP features besides a simple spanning-tree portfast on a port, if such a port receives a BPDU, it does turn into a normal (non-edge) port and causes a topology change event to be generated. I even remember labbing this up during my BCMSN training and confirming it the way I understand it.

Can you somehow confirm your statement or provide a documentation link where I could have a more info about this?

Best regards,

Peter

Mohamed Sobair · ‎08-10-2011

Hello Peter,

Lets confirm this concept first? If your statement is true , then why the need of (BPDUFILTER) and (BPDUGuard) Features?

I am positive this is not the case, because its mentioned in the documentation and my very previous understanding to an Edge port is that precaution should be taken before configuration should be done carefully as it could easily introduce Spanning-tree loops if not configured in the correct ports. This means, an STP Portfast port, doenst turn the port to a normal STP port or else , because by difinition, if this happes, this would be considered STP loop mitigation. otherwise there is no need for those features

This is why , We have those Features (BPDUFILTER and BPDUGUARD) to predict from such situations.

Unfortunately, I dont have documentation in Hand now describing it, but I will search and let you know if I find any.

Regards,

Mohamed

Peter Paluch · ‎08-10-2011

Hello Mohamed,

Thanks for responding. Let me start by quoting the document "Understanding Rapid Spanning Tree Protocol" at:

http://www.cisco.com/en/US/tech/tk389/tk621/technologies_white_paper09186a0080094cfa.shtml#edge

that says:

An edge port that receives a BPDU immediately loses edge port status and becomes a normal spanning tree port.

You are suggesting that an edge port can introduce loops (which is correct) which it would not do if it was able to revert to non-edge operation (this implication is incorrect). Note here that the problem with switching loops with edge ports is somewhat different. Let us assume that we have an edge port which is connected to another switch via a redundant link, and thus, if it becomes Forwarding, it will form a switching loop.

Understandably, after such a port is connected, it will immediately become Forwarding because of its edge port state. This will form a switching loop immediately, and that is what all the documentation is talking about. However, an edge port still sends and processes BPDUs, and after receiving an BPDU, it will cease to be an edge port, and will fall back to non-edge port operation. The problem is that there is a window of up to 2 seconds (in default STP configuration) until a BPDU from the other end is received, which may cause such a strong broadcast storm that the switches won't actually be able to process any more BPDUs. Hence, the switching loop formed by an edge port connected to another switch may be transient. The important thing to remember here is that a PortFast port is still able to both send and receive BPDUs, and an arrival of BPDU will make the edge port to change to non-edge operation.

This is very simply verified by connecting two switches together, A and B. On B, deactivate the STP for all VLANs. On A, set the port towards B as an edge port and verify it using the show spanning-tree interface Fa0/x portfast command - it should report it as enabled. Then reactivate the STP on switch B and again verify the PortFast status on the switch A - it should report it as disabled. Also running debugs on STP on switch A should reveal the same fact of losing the PortFast status.

Regarding the BPDU Guard and BPDU Filter enhancements, they are additional tools to prevent those transient loops from occuring or simply to radically protect ports that should not receive BPDUs at all (the BPDU Guard), or to prevent processing and sending BPDUs altogether if that is necessary for whatever reason (the BPDU Filter). However, it is not their task to make an edge port fall back to non-edge. A BPDU Guard makes a port err-disabled, not a non-edge port. The BPDUFilter, on the other hand, will prevent a port from hearing BPDUs altogether if configured on an interface level, essentially preventing from even detecting that a BPDU has arrived.

Does this all make sense? Please do continue discussing!

Best regards,

Peter

Mohamed Sobair · ‎08-10-2011

Hi Peter,

from your Qoute:

An edge port that receives a BPDU immediately loses edge port status and becomes a normal spanning tree port.
At this point, there is a user-configured value and an operational value for the edge port state.

its mentioning that , at this point there is a user-configured value for the edge port state.

A transient STP loop is some what different and its related to our discussion here, a Transient STP loop occurs on a transient bridges and on ports that transit immediately to STP forwarding state without moving to all STP port states. also as per Cisco, a transit STP loop could last for long time causing immediate Network Outages for a long time. one of the reason could lead to this is having such situation and the other is having Spanning-tree uplinkfast implemented on Transient bridges. and this what my all point, is that still transient STP loop is a loop that can be caused by misconfiguration or un predected STP portfast once a BPDU is recieved. if an Edge port loses its Edge port status, then it SHOULDNT introduce transient STP loop, because its simply goes through STP port states which could result in blocking or forwarding it.

The Whole point of having an Edge port is to disable/minimize TCN on a Switching Network, So an Edge port doesnt send TCN. The TCN should be generated once the port leaves its an Edge port role or if the port is moved from Blocking to forwarding or vice versa.

I still say without additional STP features, the port wouldnt change its role once it recieves BPDU.

Regards,

Mohamed

Peter Paluch · ‎08-10-2011

Hello Mohamed,

at this point there is a user-configured value for the edge port state.

Exactly! The user-configured value is what the user wants the port to be (i.e. the presence of the spanning-tree portfast command) while the operational value is showing what the port really is. The very reason for having a user-configured an an operational value is precisely the result of the fact that a PortFast-configured port does not need to operate in PortFast mode - as a result of receiving a BPDU.

if an Edge port loses its Edge port status, then it SHOULDNT introduce  transient STP loop, because its simply goes through STP port states  which could result in blocking or forwarding it.

To make sure we are actually speaking about the same thing: a transient STP loop means a temporary STP loop, i.e. a loop that exists only for a limited, finite time. An edge port may cause transient, i.e. temporary STP loops exactly because of the fact that it keeps its edge status and become immediately forwarding until it receives a BPDU from the neighboring switch. In other words, the transient, i.e. temporary loop, will be formed in the time between the moment the edge port was connected and the moment the same port received a BPDU. Surely, after the BPDU was received, the loop will be broken as a natural result of the port becoming a normal non-edge STP port.

The Whole point of having an Edge port is to disable/minimize TCN on a Switching Network

I am sorry but I do not agree with this statement. It is true that an edge port does not cause TCNs and it has benefits on a switched network. However, in my opinion, the primary reason for an edge port to exist is to immediately become Forwarding after being connected, eliminating the usual 30s delay during which the end hosts are still cut off the network.

I still say without additional STP features, the port wouldnt change its role once it recieves BPDU.

I guess that if my arguments do not ring to you, our only option is to verify that on a real hardware. Do you have a pair of Catalysts handy that you could perform the experiment I have described in my previous reply? If not, I can make that test in approximately 8 hours when I get back to lab.

Best regards,

Peter

Mohamed Sobair · ‎08-10-2011

Peter,

Please dont take this personal, I am not understimating you , However, this is my concept and it was for long time.

I now sure that we have confused the original poster throughout the whole threat, and I admit we really need some one like Francois Tallet here just to eleminate this doubt.

Surely, the use of an Edge port is to transit the port immediately into forwarding state a long with eleminating TCN to be generated. and I agree with you that a transient loop is a temporarly loop but as I illustrated and mentioned from people that have more experience and knowledge than you and me, is that without those features, a transeint STP loop may last for long time preventing it from becoming a loop for short time.

In anyway, I dont have a real Switches here for a LAB , all my current switches is in a production Network and I cant perform this test with it. So I suggest you perform it instead. let me know the output of two things:

1- The resulted port not being and Edge port while recieving BPDU. which in turns if this happens, it will cause the port to send a TCN which should be.

We also welcomes any intervention to this discussion from other people.

Regards,

Mohamed

Peter Paluch · ‎08-10-2011

Mohamed,

Don't worry, I am not taking this personally at all

without those features, a transeint STP loop may last for long time preventing it from becoming a loop for short time.

I am not doubting this fact but my explanation of this loop formation is different from yours. You are stating that the edge port won't fall back to non-edge operation upon receiving a BPDU, hence creating long-lasting loops. I am stating that the edge port is capable of falling back to non-edge operation but in the meantime, as a result of the broadcast storm, the CPU on the switch may be so overloaded it is not capable of actually processing the received BPDU, thereby permitting the loop to exist for extended period of time.

Mr. Tallet's comment on this would certainly be most welcome.

I will conduct the test in the lab in the morning and let you know. Stay tuned

Best regards,

Peter

Jon Marshall · ‎08-10-2011

We also welcomes any intervention to this discussion from other people.

Well we cross posted but i guess that means i'm welcome

Your'e right, Francois would be very useful around about now.

is that without those features, a transeint STP loop may last for long time preventing it from becoming a loop for short time.

it shouldn't matter though because all the conditions we are discussing rely on the receipt of a BPDU. We know what happens with BPDUGuard ie. the port is error disabled. But for the other 2 cases the receipt of a BPDU will change the status immediately from portfast to normal STP port (well BDPUfiltering globally enabled anyway).

There should be no significant difference in delay between the 2 ie. portfast with and without BPDUFiltering because the cause of the change is the receipt of a BPDU.

I have to admit, it's times like this i wish i had access to the lab i used to have when i was in my last job.

Jon

Jon Marshall · ‎08-10-2011

Mohamed / Peter

Apolgies for "butting in" but it's an interesting discussion. I agree with what Peter is saying and just wanted to put forward a slightly different explanation that may or may not help. If it doesn't then by all means just ignore me and carry on as you were

Lets confirm this concept first? If your statement is true , then why the need of (BPDUFILTER) and (BPDUGuard) Features?

The above simply give you more options as to what to do when a BPDU is received. So for example BDPUGuard is very useful if you want to stop users connecting switches to their PC/laptop ethernet cable at their desk. You don't want this switch to become part of your network topology. So it is simply a further option. You are right when you say care should be taken in enabling portfast but the above example shows with all the care in the world by the network administrator there are still things beyond their control.

But the basic point of an edge port transitioning to a normal spanning tree port holds true and it has to happen simply because BPDUGuard/BPDUfilter are optional features. If they are optional that obviously means you don't need to configure them which means RSTP itself must have a way of protecting against loops, otherwise it wouldn't be very good at what it is meant to do. See this link for 6500 switches on BPDUGuard/BPDUfilter and note that the chapter is titled "Configuring Optional STP features" -

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/stp_enha.html

note the point of the above link is not for you to read up on them because i know you understand what they do (i wouldn't insult you like that !), it is purely to show that the features you mention are indeed optional and that RSTP will still try to prevent loops with or without them.

Jon

Peter Paluch · ‎08-11-2011