Switching

I do not trully understand the impact of the "protocols rstp interface ge-x/x/x edge" statement.

 

J-TechLibrary mentions:

For Rapid Spanning Tree Protocol (RSTP), VLAN Spanning Tree Protocol (VSTP), or Multiple Spanning Tree Protocol (MSTP), configure interfaces as edge ports or edge interfaces. Edge ports do not expect to receive BPDUs. If a BPDU is received, the port becomes a nonedge port and the Edge interfaces immediately transition to a forwarding state.

 

Okay thats clear, but this is also the case with interfaces that are not configured with the interface ge-x/x/x edge statement.

 

That same TechLibrary article https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/edge-edit-protocols-stp.html) (Ethernet Switching Feature Guide) states:

 

NOTE

Although the edge configuration statement appears in the [edit protocols stp interface (all | interface-name)] or [edit protocols rstp force-version stp interface (all | interface-name)] hierarchy on the switch, this statement has no effect on the switch operation if you configure it.

 

What is the meaning of: "no effect"... Does the "protocols rstp interface ge-x/x/x edge" statement have no effect/impact at all? So what is the function of this statement?

Configuring a port as edge allows it to enter the forwarding state immediately, and bypass the listening and learning states. 

 

The tech note is indicating that stp and rstp operating in forced stp mode do not support the edge feature.

Thank you for your response,

 

You are telling me that edge is a rstp feature, not supported with stp.

 

OK, but I still don't get it:

Listening is a stp state, not a rstp state. Furthermore, in rstp, point-to-point (= full duplex) links, transition to forwardig state without waiting for the forward delay timer to expire as with stp. This is standard rstp behaivior so the "edge" command doesn't seem to make sense. Thats my point.

Hi Jean,

Answered inline.

---

@Jean de la Cour wrote:

Thank you for your response,

 

You are telling me that edge is a rstp feature, not supported with stp.

 

OK, but I still don't get it:

Listening is a stp state, not a rstp state. Furthermore, in rstp, point-to-point (= full duplex) links, transition to forwardig state without waiting for the forward delay timer to expire as with stp. This is standard rstp behaivior so the "edge" command doesn't seem to make sense. Thats my point.

[Ans] You're right - when a port (point-to-point and full-duplex) just has RSTP enabled, and it doesn't receive any BPDU on it then it transitions to forwarding stable immediately (RSTP default behavior). And this behavior is the same if this port was manually configured as an edge port i.e. "set protocols rstp interface <> edge". The difference in port behavior is when the port does receive a BPDU.

A normal port with RSTP enabled would start participating in spanning-tree (send out BPDUs, elect RSTP state etc.). Whereas a manually defined edge port gives us control with as to what action we want the port to take if it receives a BPDU, using CLI "set protocols rstp bpdu-block-on-edge". Also lets us decide on the port recovery after it's blocked by a BPDU received:

https://kb.juniper.net/InfoCenter/index?page=content&id=KB24166&cat=EX_Series&actp=LIST (non-ELS only)
https://www.juniper.net/documentation/en_US/junos/topics/topic-map/spanning-tree-bpdu-protection.html (includes ELS and non-ELS config examples of how to recovery blocked edge ports)

---

Regarding the previous note and your question on it, I agree with the above explanation - the knob doesn't take any effect on the switch if you had STP enabled one way or other.

 

https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/edge-edit-protocols-stp.html 

NOTE
Although the edge configuration statement appears in the [edit protocols stp interface (all | interface-name)] or [edit protocols rstp force-version stp interface (all | interface-name)] hierarchy on the switch, this statement has no effect on the switch operation if you configure it.

And your question:
"What is the meaning of: "no effect"... Does the "protocols rstp interface ge-x/x/x edge" statement have no effect/impact at all? So what is the function of this statement?"

The NOTE doesn't say "protocols rstp interface ge-x/x/x edge", it says "set prototocls rstp force-version interface ..." :), although I see your point and hope I've answered it above.

 

Hope this helps.

 

Regards,
-r.

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

If this solves your problem, please mark this post as "Accepted Solution."
Kudos are always appreciated :).

Miryaz,

 

Thank you for your response,

 

You are stating that:  “The difference in port behavior is when the port does receive a BPDU. A normal port with RSTP enabled would start participating in spanning-tree (send out BPDUs, elect RSTP state etc.). Whereas a manually defined edge port gives us control with as to what action we want the port to take if it receives a BPDU, using CLI "set protocols rstp bpdu-block-on-edge". Also lets us decide on the port recovery after it's blocked by a BPDU received”

 

What you actually describe is BPDU protection,  and indeed you have to configure BPDU protection in conjunction with set protocols rstp interface xx-x/x/x edge.

 

As earlier mentioned: “this statement has no effect on the switch operation if you configure it” . So, in fact, "set protocols rstp interface xx-x/x/x edge" is only labeling the fysical interface so it can be used in conjunction with configuring BPDU protection?

 

Do I now understand is well?

Hello Jean,

"As earlier mentioned: "this statement has no effect on the switch operation if you configure it" . So, in fact, "set protocols rstp interface xx-x/x/x edge" is only labeling the fysical interface so it can be used in conjunction with configuring BPDU protection?"
A manually configured edge port immediately moves to forwarding state where as a normal port with just RSTP enabled, takes a couple of seconds more (in DISCARDING state) to listen for BPDUs before it moves to forwarding state and starts operating like an "Edge" port. The difference is that the state machine reads an edge-configured port as "Edge" immediately.

---(refreshed at 2019-03-24 02:15:28 UTC)--- PORT ENABLED
---(refreshed at 2019-03-24 02:15:30 UTC)---
Routing Instance Name : default-switch
Logical Interface flags (DL - disable learning, AD - packet action drop,
LH - MAC limit hit, DN - interface down,
MMAS - Mac-move action shutdown, AS - Autostate-exclude enabled,
SCTL - shutdown by Storm-control, MI - MAC+IP limit hit)

Logical Vlan TAG MAC MAC+IP STP Logical Tagging
interface members limit limit state interface flags
xe-0/0/0:1.0 65535 0 untagged
v101 101 65535 0 Forwarding untagged


Normal Port:
---(refreshed at 2019-03-24 02:13:37 UTC)--- PORT ENABLED
---(refreshed at 2019-03-24 02:13:38 UTC)---
Routing Instance Name : default-switch
Logical Interface flags (DL - disable learning, AD - packet action drop,
LH - MAC limit hit, DN - interface down,
MMAS - Mac-move action shutdown, AS - Autostate-exclude enabled,
SCTL - shutdown by Storm-control, MI - MAC+IP limit hit)

Logical Vlan TAG MAC MAC+IP STP Logical Tagging
interface members limit limit state interface flags
xe-0/0/0:1.0 65535 0 untagged
v101 101 65535 0 Discarding untagged
---(refreshed at 2019-03-24 02:13:39 UTC)---
Routing Instance Name : default-switch
Logical Interface flags (DL - disable learning, AD - packet action drop,
LH - MAC limit hit, DN - interface down,
MMAS - Mac-move action shutdown, AS - Autostate-exclude enabled,
SCTL - shutdown by Storm-control, MI - MAC+IP limit hit)

Logical Vlan TAG MAC MAC+IP STP Logical Tagging
interface members limit limit state interface flags
xe-0/0/0:1.0 65535 0 untagged
v101 101 65535 0 Discarding untagged
---(refreshed at 2019-03-24 02:13:40 UTC)---
Routing Instance Name : default-switch
Logical Interface flags (DL - disable learning, AD - packet action drop,
LH - MAC limit hit, DN - interface down,
MMAS - Mac-move action shutdown, AS - Autostate-exclude enabled,
SCTL - shutdown by Storm-control, MI - MAC+IP limit hit)

Logical Vlan TAG MAC MAC+IP STP Logical Tagging
interface members limit limit state interface flags
xe-0/0/0:1.0 65535 0 untagged
v101 101 65535 0 Forwarding untagged


Hope this helps.

Regards,
-r.

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

If this solves your problem, please mark this post as "Accepted Solution."
Kudos are always appreciated :).

Okay, now its clear to me.

It's like the Cisco portfast command.

 

Thank you.

 

With regards,

 

Jean

Sorry I am reviving this thread, it is even more confusing after I read through this thread.

It is a fact that even a port is configured as edge port, it can still turn to be a non-edge port when a bpdu is received, then what is the point of configuring a port as edge port? Just to turn the port to forward state quicker? The weird thing is this happens even when “bpdu-block-on-edge” is configured. Which brings another question, if designating a port as edge port has no effect, how does rstp decide a port is edge port and therefore blocks bpdu on that port in the first place? Don’t I like Cisco IOS’s spanning tree implementation!

What edge port configuration does is it will simply assume that the port is a port connected to host and it is not suppose (doesnt expect)  to receive bpdu and hence can transition fast to the forwarding state.

If we configure edge port with "bpdu-block-on-edge" then if a bpdu is indeed recieved on the edge port then to prevent loop the interface will be shut.

 

Hope this helps.

You would think for a 30+ year old protocol we'd get this stuff obviously straight -:(  OK, what I say may not be 100% accurate, but here goes:

 

#1 This statement below says if interface is enabled for STP edge setting does nothing.  This can be done using either using stp option under protocols or force-version stp option under RSTP.

 

NOTE

Although the edge configuration statement appears in the [edit protocols stp interface (all | interface-name)] or [edit protocols rstp force-version stp interface (all | interface-name)] hierarchy on the switch, this statement has no effect on the switch operation if you configure it. 

 

So from this point forward only discuss around RSTP.  Note that RSTP analysis, also covers VSTP and MSTP.  

 

For RSTP configuration, setting the port to edge, I believe, tells the interface NOT to send BPDUs, unless one is received.  If one is received, to then transition to forwarding state immediately and then start sending and receiving BPDUs, unless somehow reset.  Doc's do not seem to cover this, but my best guess is disable/enable/reset/maybe commit causes the interface it to go back to plain edge mode?

 

This is "sort of" like OSPF passive, with an activate option.

 

There is an additional knob called block-on-bpdu.  I "think" this maybe completely independant of RSTP edge configuration, although the doc's seem to imply requires edge config to function - no real idea?  I have no idea what the operation is for an interface with no RSTP edge configured - maybe it does nothing, maybe it provide commit error. The config option is under the protocol RSTP not under edge, and this is the reason for my confusion!  Anyway, . . .

 

This knob has 3 options - disable/drop/shutdown.  Now I "think" this additional behavior is:

 

Disable -  Disable the whole instance, which to me really only applies maybe to MSTP, or maybe it disabled the instance for the whole VLAN with VSTP?  I really have no idea what the actual difference is between Disable and Shutdown, but there must be something.

 

What confuses is me is disable-timeout.  From name, I would think this extra setting is [only] associated with 'disable' knob, but I think it works with shutdown, or maybe both disable and shutdown.  If it is associated with shutdown, why not label it shutdown-timeout or disable-shutdown-timer?  Again confused.

 

Drop - drop the incoming received BPDU but keep the interface up. So basically drop adds in the operation of keep interface up for STP/RSTP enabled interfaces, but dropping received BPDUs, which I think it does but default in at least some products by default.  See below.

 

I 'believe' (at least for EX/QFX from some recent testing) that no matter how an interface is set for STP/RSTP (that is enabled or even deleted) the interface NEVER forwards BPDU.  With disable, maybe expected flood does NOT happen, at least for some Broadcom based models.  

 

Shutdown - for both STP/RSTP shutdown the interface. Only way to recover is reset or via disable-timeout.  See prior discussion on why this extra function is not called shutdown-timeout.

 

I am sure there are some people out there much more knowledgeable from an actual operation standard point, that can maybe answer my confusion or provide better clear answers.  Hopefully it will not take another 30 years to get this crystal clear!

 

HTH

I am having trouble understanding RSTP configuration new to Juniper. I'm trying to help a customer out with network convergance issues... the switches seem to crash during a vulnerability scan. QFX5100 distribution switches and EX4200s access switches. 

I dont know what to configure and where? help?

Thanks Matteo

 

This is the only rstp configuration i could find on the switches.

}
rstp {
interface xe-0/0/11;
interface xe-0/0/13;
interface xe-0/0/14;
interface xe-0/0/15;
interface xe-0/0/16;
interface xe-0/0/17;
interface xe-0/0/18;
interface xe-0/0/19;
...........
bpdu-block-on-edge;
}

 

and this on 2 others

}
}
rstp;
lldp {
interface all;