Mailing List Archive

Spanning-tree event on single VLAN brings down LAG?
We had network event deeper in our network that resulted in some kind of
spanning tree event as evidenced by a TC (topology change) on our L2-only
ICX6610 stack. What surprised us was that one VLAN going into a blocking
state resulted in the south bound LAG going down.

This is probably not right, but the root bridge for VLAN 294 is on the
ICX6610 stack. VLAN 294 is on both LAGs (and no other port/LAG)

Three questions:
a) when a STP event occurs is it normal that a VLAN goes into Blocking on
all the ports where it is present?
b) when a VLAN goes into blocking should all the physical (or LAG) ports
associated with that VLAN go down?
c) does configuring spanning tree on the port-based VLAN but disabling
spanning-tree on the physical (or LAG) ports prevent the physical port (or
LAG) going down?

Frank

============================================================================
====
Oct? 9?21:35:22 STP: VLAN 294 Port 1/3/6 Bridge TC Event (MakeBlking)?
Oct? 9?21:35:22 STP: VLAN 294 Port 1/3/6 STP State -> BLOCKING (MakeBlking)?
Oct? 9?21:35:25 System: Logical link on dynamic lag interface ethernet 2/3/8
is down.?
Oct? 9?21:35:25 System: Logical link on dynamic lag interface ethernet 3/3/4
is down.?
Oct? 9?21:35:26 System: Logical link on dynamic lag interface ethernet 3/3/8
is down.?
Oct? 9?21:35:29 Trunk: Group (1/3/8, 2/3/8, 3/3/4, 3/3/8) removed by 802.3ad
link-aggregation module.?
Oct? 9?21:35:29 STP: VLAN 4 Port 1/3/8 STP State -> BLOCKING (PortDown)?
Oct? 9?21:35:29 STP: VLAN 4 Port 1/3/8 STP State -> DISABLED (PortDown)
etc.

Event
|
Transport
| |
| | (1/3/6 & 2/3/6)
| |
ICX6610 (L2)
| | | |
| | | | (1/3/8, 2/3/8, 3/3/4, 3/3/8)
| | | |
Core (L3)



_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp
Re: Spanning-tree event on single VLAN brings down LAG? [ In reply to ]
One vlan getting blocked by spanning tree should not bring down the lag. The vlan should only block on the interfaces required to remove the loop. As far as I know, if you have spanning tree enabled on the vlan, but disabled on the physical port, then the physical port no longer participates in spanning tree for any vlan.


Here's config from one of my switches. This is an ICX7750 with 8.0.30r code, same code that ICX6610 can run.


lag lag-name dynamic id 1

ports ethernet 1/1/2 ethernet 2/1/2

primary-port 1/1/2

deploy

!

vlan 123 name vlan-name by port

tagged ethe 1/1/2 ethe 2/1/2

spanning-tree 802-1w

!

interface ethernet 1/1/2

spanning-tree 802-1w admin-pt2pt-mac


A snipped output from "show 802-1w" below with vlans in both discarding and forwarding states on that lag.

--- VLAN 404 [ STP Instance owned by VLAN 404 ] ----------------------------
1/1/2 128 2000 T F ALTERNATE DISCARDING 2000 0001609c9fd73700

--- VLAN 999 [ STP Instance owned by VLAN 999 ] ----------------------------
1/1/2 128 2000 T F ALTERNATE DISCARDING 2000 0001609c9fd73700

--- VLAN 2007 [ STP Instance owned by VLAN 2007 ] ---------------------------
1/1/2 128 2000 T F ROOT FORWARDING 0 0000609c9fd73700

--- VLAN 2057 [ STP Instance owned by VLAN 2057 ] ---------------------------
1/1/2 128 2000 T F ROOT FORWARDING 0 0000609c9fd73700

-Christopher


On Wed, 2018-10-10 at 11:59 -0500, Frank Bulk wrote:

We had network event deeper in our network that resulted in some kind of

spanning tree event as evidenced by a TC (topology change) on our L2-only

ICX6610 stack. What surprised us was that one VLAN going into a blocking

state resulted in the south bound LAG going down.


This is probably not right, but the root bridge for VLAN 294 is on the

ICX6610 stack. VLAN 294 is on both LAGs (and no other port/LAG)


Three questions:

a) when a STP event occurs is it normal that a VLAN goes into Blocking on

all the ports where it is present?

b) when a VLAN goes into blocking should all the physical (or LAG) ports

associated with that VLAN go down?

c) does configuring spanning tree on the port-based VLAN but disabling

spanning-tree on the physical (or LAG) ports prevent the physical port (or

LAG) going down?


Frank


============================================================================

====

Oct 9 21:35:22 STP: VLAN 294 Port 1/3/6 Bridge TC Event (MakeBlking)

Oct 9 21:35:22 STP: VLAN 294 Port 1/3/6 STP State -> BLOCKING (MakeBlking)

Oct 9 21:35:25 System: Logical link on dynamic lag interface ethernet 2/3/8

is down.

Oct 9 21:35:25 System: Logical link on dynamic lag interface ethernet 3/3/4

is down.

Oct 9 21:35:26 System: Logical link on dynamic lag interface ethernet 3/3/8

is down.

Oct 9 21:35:29 Trunk: Group (1/3/8, 2/3/8, 3/3/4, 3/3/8) removed by 802.3ad

link-aggregation module.

Oct 9 21:35:29 STP: VLAN 4 Port 1/3/8 STP State -> BLOCKING (PortDown)

Oct 9 21:35:29 STP: VLAN 4 Port 1/3/8 STP State -> DISABLED (PortDown)

etc.


Event

|

Transport

| |

| | (1/3/6 & 2/3/6)

| |

ICX6610 (L2)

| | | |

| | | | (1/3/8, 2/3/8, 3/3/4, 3/3/8)

| | | |

Core (L3)





_______________________________________________

foundry-nsp mailing list

foundry-nsp@puck.nether.net<mailto:foundry-nsp@puck.nether.net>

http://puck.nether.net/mailman/listinfo/foundry-nsp
Re: Spanning-tree event on single VLAN brings down LAG? [ In reply to ]
Which flavor of spanning tree are you running?

--
Eldon

On Wed, Oct 10, 2018 at 11:32 AM Howard, Christopher <
Christopher-Howard@utc.edu> wrote:

> One vlan getting blocked by spanning tree should not bring down the lag.
> The vlan should only block on the interfaces required to remove the loop.
> As far as I know, if you have spanning tree enabled on the vlan, but
> disabled on the physical port, then the physical port no longer
> participates in spanning tree for any vlan.
>
>
> Here's config from one of my switches. This is an ICX7750 with 8.0.30r
> code, same code that ICX6610 can run.
>
> lag lag-name dynamic id 1
>
> ports ethernet 1/1/2 ethernet 2/1/2
>
> primary-port 1/1/2
>
> deploy
>
> !
>
> vlan 123 name vlan-name by port
>
> tagged ethe 1/1/2 ethe 2/1/2
>
> spanning-tree 802-1w
>
> !
>
> interface ethernet 1/1/2
>
> spanning-tree 802-1w admin-pt2pt-mac
>
>
>
> A snipped output from "show 802-1w" below with vlans in both discarding
> and forwarding states on that lag.
>
> --- VLAN 404 [ STP Instance owned by VLAN 404 ]
> ----------------------------
> 1/1/2 128
> 2000 T F ALTERNATE DISCARDING 2000 0001609c9fd73700
>
> --- VLAN 999 [ STP Instance owned by VLAN 999 ]
> ----------------------------
> 1/1/2 128
> 2000 T F ALTERNATE DISCARDING 2000 0001609c9fd73700
>
> --- VLAN 2007 [ STP Instance owned by VLAN 2007 ]
> ---------------------------
> 1/1/2 128
> 2000 T F ROOT FORWARDING 0 0000609c9fd73700
>
> --- VLAN 2057 [ STP Instance owned by VLAN 2057 ]
> ---------------------------
> 1/1/2 128
> 2000 T F ROOT FORWARDING 0 0000609c9fd73700
>
> -Christopher
>
>
> On Wed, 2018-10-10 at 11:59 -0500, Frank Bulk wrote:
>
> We had network event deeper in our network that resulted in some kind of
>
> spanning tree event as evidenced by a TC (topology change) on our L2-only
>
> ICX6610 stack. What surprised us was that one VLAN going into a blocking
>
> state resulted in the south bound LAG going down.
>
>
> This is probably not right, but the root bridge for VLAN 294 is on the
>
> ICX6610 stack. VLAN 294 is on both LAGs (and no other port/LAG)
>
>
> Three questions:
>
> a) when a STP event occurs is it normal that a VLAN goes into Blocking on
>
> all the ports where it is present?
>
> b) when a VLAN goes into blocking should all the physical (or LAG) ports
>
> associated with that VLAN go down?
>
> c) does configuring spanning tree on the port-based VLAN but disabling
>
> spanning-tree on the physical (or LAG) ports prevent the physical port (or
>
> LAG) going down?
>
>
> Frank
>
>
> ============================================================================
>
> ====
>
> Oct 9 21:35:22 STP: VLAN 294 Port 1/3/6 Bridge TC Event (MakeBlking)
>
> Oct 9 21:35:22 STP: VLAN 294 Port 1/3/6 STP State -> BLOCKING (MakeBlking)
>
> Oct 9 21:35:25 System: Logical link on dynamic lag interface ethernet 2/3/8
>
> is down.
>
> Oct 9 21:35:25 System: Logical link on dynamic lag interface ethernet 3/3/4
>
> is down.
>
> Oct 9 21:35:26 System: Logical link on dynamic lag interface ethernet 3/3/8
>
> is down.
>
> Oct 9 21:35:29 Trunk: Group (1/3/8, 2/3/8, 3/3/4, 3/3/8) removed by 802.3ad
>
> link-aggregation module.
>
> Oct 9 21:35:29 STP: VLAN 4 Port 1/3/8 STP State -> BLOCKING (PortDown)
>
> Oct 9 21:35:29 STP: VLAN 4 Port 1/3/8 STP State -> DISABLED (PortDown)
>
> etc.
>
>
> Event
>
> |
>
> Transport
>
> | |
>
> | | (1/3/6 & 2/3/6)
>
> | |
>
> ICX6610 (L2)
>
> | | | |
>
> | | | | (1/3/8, 2/3/8, 3/3/4, 3/3/8)
>
> | | | |
>
> Core (L3)
>
>
>
> _______________________________________________
>
> foundry-nsp mailing list
>
> foundry-nsp@puck.nether.net
>
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>
Re: Spanning-tree event on single VLAN brings down LAG? [ In reply to ]
Plain STP as this time.



From: foundry-nsp <foundry-nsp-bounces@puck.nether.net> On Behalf Of Eldon Koyle
Sent: Wednesday, October 10, 2018 3:32 PM
To: foundry-nsp <foundry-nsp@puck.nether.net>
Subject: Re: [f-nsp] Spanning-tree event on single VLAN brings down LAG?



Which flavor of spanning tree are you running?



--

Eldon



On Wed, Oct 10, 2018 at 11:32 AM Howard, Christopher <Christopher-Howard@utc.edu <mailto:Christopher-Howard@utc.edu> > wrote:

One vlan getting blocked by spanning tree should not bring down the lag. The vlan should only block on the interfaces required to remove the loop. As far as I know, if you have spanning tree enabled on the vlan, but disabled on the physical port, then the physical port no longer participates in spanning tree for any vlan.





Here's config from one of my switches. This is an ICX7750 with 8.0.30r code, same code that ICX6610 can run.



lag lag-name dynamic id 1
ports ethernet 1/1/2 ethernet 2/1/2
primary-port 1/1/2
deploy
!
vlan 123 name vlan-name by port
tagged ethe 1/1/2 ethe 2/1/2
spanning-tree 802-1w
!
interface ethernet 1/1/2
spanning-tree 802-1w admin-pt2pt-mac





A snipped output from "show 802-1w" below with vlans in both discarding and forwarding states on that lag.



--- VLAN 404 [ STP Instance owned by VLAN 404 ] ----------------------------

1/1/2 128 2000 T F ALTERNATE DISCARDING 2000 0001609c9fd73700



--- VLAN 999 [ STP Instance owned by VLAN 999 ] ----------------------------

1/1/2 128 2000 T F ALTERNATE DISCARDING 2000 0001609c9fd73700



--- VLAN 2007 [ STP Instance owned by VLAN 2007 ] ---------------------------

1/1/2 128 2000 T F ROOT FORWARDING 0 0000609c9fd73700



--- VLAN 2057 [ STP Instance owned by VLAN 2057 ] ---------------------------

1/1/2 128 2000 T F ROOT FORWARDING 0 0000609c9fd73700



-Christopher





On Wed, 2018-10-10 at 11:59 -0500, Frank Bulk wrote:

We had network event deeper in our network that resulted in some kind of
spanning tree event as evidenced by a TC (topology change) on our L2-only
ICX6610 stack. What surprised us was that one VLAN going into a blocking
state resulted in the south bound LAG going down.

This is probably not right, but the root bridge for VLAN 294 is on the
ICX6610 stack. VLAN 294 is on both LAGs (and no other port/LAG)

Three questions:
a) when a STP event occurs is it normal that a VLAN goes into Blocking on
all the ports where it is present?
b) when a VLAN goes into blocking should all the physical (or LAG) ports
associated with that VLAN go down?
c) does configuring spanning tree on the port-based VLAN but disabling
spanning-tree on the physical (or LAG) ports prevent the physical port (or
LAG) going down?

Frank

============================================================================
====
Oct 9 21:35:22 STP: VLAN 294 Port 1/3/6 Bridge TC Event (MakeBlking)
Oct 9 21:35:22 STP: VLAN 294 Port 1/3/6 STP State -> BLOCKING (MakeBlking)
Oct 9 21:35:25 System: Logical link on dynamic lag interface ethernet 2/3/8
is down.
Oct 9 21:35:25 System: Logical link on dynamic lag interface ethernet 3/3/4
is down.
Oct 9 21:35:26 System: Logical link on dynamic lag interface ethernet 3/3/8
is down.
Oct 9 21:35:29 Trunk: Group (1/3/8, 2/3/8, 3/3/4, 3/3/8) removed by 802.3ad
link-aggregation module.
Oct 9 21:35:29 STP: VLAN 4 Port 1/3/8 STP State -> BLOCKING (PortDown)
Oct 9 21:35:29 STP: VLAN 4 Port 1/3/8 STP State -> DISABLED (PortDown)
etc.

Event
|
Transport
| |
| | (1/3/6 & 2/3/6)
| |
ICX6610 (L2)
| | | |
| | | | (1/3/8, 2/3/8, 3/3/4, 3/3/8)
| | | |
Core (L3)



_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net <mailto:foundry-nsp@puck.nether.net>
http://puck.nether.net/mailman/listinfo/foundry-nsp


_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net <mailto:foundry-nsp@puck.nether.net>
http://puck.nether.net/mailman/listinfo/foundry-nsp
Re: Spanning-tree event on single VLAN brings down LAG? [ In reply to ]
No, that VLAN is tagged on that port. We’re running plain STP on the stack; transport doesn’t use STP, but based on PBB-TE.



Frank



From: George B <georgeb@gmail.com>
Sent: Wednesday, October 10, 2018 1:13 PM
To: Frank Bulk <frnkblk@iname.com>
Subject: Re: [f-nsp] Spanning-tree event on single VLAN brings down LAG?



Is that VLAN untagged on that port? Looks to me like it blocked LACP packets. What type of spanning tree is running on the stack and the transport device?





On Wed, Oct 10, 2018, 09:59 Frank Bulk <frnkblk@iname.com <mailto:frnkblk@iname.com> > wrote:

We had network event deeper in our network that resulted in some kind of
spanning tree event as evidenced by a TC (topology change) on our L2-only
ICX6610 stack. What surprised us was that one VLAN going into a blocking
state resulted in the south bound LAG going down.

This is probably not right, but the root bridge for VLAN 294 is on the
ICX6610 stack. VLAN 294 is on both LAGs (and no other port/LAG)

Three questions:
a) when a STP event occurs is it normal that a VLAN goes into Blocking on
all the ports where it is present?
b) when a VLAN goes into blocking should all the physical (or LAG) ports
associated with that VLAN go down?
c) does configuring spanning tree on the port-based VLAN but disabling
spanning-tree on the physical (or LAG) ports prevent the physical port (or
LAG) going down?

Frank

============================================================================
====
Oct 9 21:35:22 STP: VLAN 294 Port 1/3/6 Bridge TC Event (MakeBlking)
Oct 9 21:35:22 STP: VLAN 294 Port 1/3/6 STP State -> BLOCKING (MakeBlking)
Oct 9 21:35:25 System: Logical link on dynamic lag interface ethernet 2/3/8
is down.
Oct 9 21:35:25 System: Logical link on dynamic lag interface ethernet 3/3/4
is down.
Oct 9 21:35:26 System: Logical link on dynamic lag interface ethernet 3/3/8
is down.
Oct 9 21:35:29 Trunk: Group (1/3/8, 2/3/8, 3/3/4, 3/3/8) removed by 802.3ad
link-aggregation module.
Oct 9 21:35:29 STP: VLAN 4 Port 1/3/8 STP State -> BLOCKING (PortDown)
Oct 9 21:35:29 STP: VLAN 4 Port 1/3/8 STP State -> DISABLED (PortDown)
etc.

Event
|
Transport
| |
| | (1/3/6 & 2/3/6)
| |
ICX6610 (L2)
| | | |
| | | | (1/3/8, 2/3/8, 3/3/4, 3/3/8)
| | | |
Core (L3)



_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net <mailto:foundry-nsp@puck.nether.net>
http://puck.nether.net/mailman/listinfo/foundry-nsp
Re: Spanning-tree event on single VLAN brings down LAG? [ In reply to ]
Christopher,



Thanks for sharing. Your explanation regarding vlan enablement versus port disablement makes sense to me.



I plan to turn up 802.1w in a future maintenance window.



From the Brocade ICX6610 logs is it clear if the ICX6610 turned down the 10G ports, or did the core router link it down and the ICX6610 was merely documenting that it was being pulled down?



Frank



From: Howard, Christopher <Christopher-Howard@utc.edu>
Sent: Wednesday, October 10, 2018 12:32 PM
To: foundry-nsp@puck.nether.net; frnkblk@iname.com
Subject: Re: [f-nsp] Spanning-tree event on single VLAN brings down LAG?



One vlan getting blocked by spanning tree should not bring down the lag. The vlan should only block on the interfaces required to remove the loop. As far as I know, if you have spanning tree enabled on the vlan, but disabled on the physical port, then the physical port no longer participates in spanning tree for any vlan.





Here's config from one of my switches. This is an ICX7750 with 8.0.30r code, same code that ICX6610 can run.



lag lag-name dynamic id 1
ports ethernet 1/1/2 ethernet 2/1/2
primary-port 1/1/2
deploy
!
vlan 123 name vlan-name by port
tagged ethe 1/1/2 ethe 2/1/2
spanning-tree 802-1w
!
interface ethernet 1/1/2
spanning-tree 802-1w admin-pt2pt-mac





A snipped output from "show 802-1w" below with vlans in both discarding and forwarding states on that lag.



--- VLAN 404 [ STP Instance owned by VLAN 404 ] ----------------------------

1/1/2 128 2000 T F ALTERNATE DISCARDING 2000 0001609c9fd73700



--- VLAN 999 [ STP Instance owned by VLAN 999 ] ----------------------------

1/1/2 128 2000 T F ALTERNATE DISCARDING 2000 0001609c9fd73700



--- VLAN 2007 [ STP Instance owned by VLAN 2007 ] ---------------------------

1/1/2 128 2000 T F ROOT FORWARDING 0 0000609c9fd73700



--- VLAN 2057 [ STP Instance owned by VLAN 2057 ] ---------------------------

1/1/2 128 2000 T F ROOT FORWARDING 0 0000609c9fd73700



-Christopher





On Wed, 2018-10-10 at 11:59 -0500, Frank Bulk wrote:

We had network event deeper in our network that resulted in some kind of
spanning tree event as evidenced by a TC (topology change) on our L2-only
ICX6610 stack. What surprised us was that one VLAN going into a blocking
state resulted in the south bound LAG going down.

This is probably not right, but the root bridge for VLAN 294 is on the
ICX6610 stack. VLAN 294 is on both LAGs (and no other port/LAG)

Three questions:
a) when a STP event occurs is it normal that a VLAN goes into Blocking on
all the ports where it is present?
b) when a VLAN goes into blocking should all the physical (or LAG) ports
associated with that VLAN go down?
c) does configuring spanning tree on the port-based VLAN but disabling
spanning-tree on the physical (or LAG) ports prevent the physical port (or
LAG) going down?

Frank

============================================================================
====
Oct 9 21:35:22 STP: VLAN 294 Port 1/3/6 Bridge TC Event (MakeBlking)
Oct 9 21:35:22 STP: VLAN 294 Port 1/3/6 STP State -> BLOCKING (MakeBlking)
Oct 9 21:35:25 System: Logical link on dynamic lag interface ethernet 2/3/8
is down.
Oct 9 21:35:25 System: Logical link on dynamic lag interface ethernet 3/3/4
is down.
Oct 9 21:35:26 System: Logical link on dynamic lag interface ethernet 3/3/8
is down.
Oct 9 21:35:29 Trunk: Group (1/3/8, 2/3/8, 3/3/4, 3/3/8) removed by 802.3ad
link-aggregation module.
Oct 9 21:35:29 STP: VLAN 4 Port 1/3/8 STP State -> BLOCKING (PortDown)
Oct 9 21:35:29 STP: VLAN 4 Port 1/3/8 STP State -> DISABLED (PortDown)
etc.

Event
|
Transport
| |
| | (1/3/6 & 2/3/6)
| |
ICX6610 (L2)
| | | |
| | | | (1/3/8, 2/3/8, 3/3/4, 3/3/8)
| | | |
Core (L3)



_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net <mailto:foundry-nsp@puck.nether.net>
http://puck.nether.net/mailman/listinfo/foundry-nsp
Re: Spanning-tree event on single VLAN brings down LAG? [ In reply to ]
Looking at your log, 1/3/6 is where the block event happened. I would not expect the 6610 to have dropped the lag because of this, no matter which version of spanning tree you're running, because 1/3/6 is not a part of that lag.

Just some ideas:
- It could have been dropped on the other end by either the same or an unrelated event and you're just seeing the documentation of that on the 6610.
- I've seen before where a loop drove the switch CPU high enough to flap lags. Since spanning tree blocked the port that should have protected the CPU, unless there are other ports not participating in spanning tree on that vlan.
- A coincidence, but I admit the chances of that are unlikely with the timing of the lag drop.

-Christopher


On Thu, 2018-10-11 at 08:07 -0500, frnkblk@iname.com wrote:
Christopher,

Thanks for sharing. Your explanation regarding vlan enablement versus port disablement makes sense to me.

I plan to turn up 802.1w in a future maintenance window.

From the Brocade ICX6610 logs is it clear if the ICX6610 turned down the 10G ports, or did the core router link it down and the ICX6610 was merely documenting that it was being pulled down?

Frank

From: Howard, Christopher <Christopher-Howard@utc.edu>
Sent: Wednesday, October 10, 2018 12:32 PM
To: foundry-nsp@puck.nether.net; frnkblk@iname.com
Subject: Re: [f-nsp] Spanning-tree event on single VLAN brings down LAG?

One vlan getting blocked by spanning tree should not bring down the lag. The vlan should only block on the interfaces required to remove the loop. As far as I know, if you have spanning tree enabled on the vlan, but disabled on the physical port, then the physical port no longer participates in spanning tree for any vlan.


Here's config from one of my switches. This is an ICX7750 with 8.0.30r code, same code that ICX6610 can run.


lag lag-name dynamic id 1

ports ethernet 1/1/2 ethernet 2/1/2

primary-port 1/1/2

deploy

!

vlan 123 name vlan-name by port

tagged ethe 1/1/2 ethe 2/1/2

spanning-tree 802-1w

!

interface ethernet 1/1/2

spanning-tree 802-1w admin-pt2pt-mac


A snipped output from "show 802-1w" below with vlans in both discarding and forwarding states on that lag.

--- VLAN 404 [ STP Instance owned by VLAN 404 ] ----------------------------
1/1/2 128 2000 T F ALTERNATE DISCARDING 2000 0001609c9fd73700

--- VLAN 999 [ STP Instance owned by VLAN 999 ] ----------------------------
1/1/2 128 2000 T F ALTERNATE DISCARDING 2000 0001609c9fd73700

--- VLAN 2007 [ STP Instance owned by VLAN 2007 ] ---------------------------
1/1/2 128 2000 T F ROOT FORWARDING 0 0000609c9fd73700

--- VLAN 2057 [ STP Instance owned by VLAN 2057 ] ---------------------------
1/1/2 128 2000 T F ROOT FORWARDING 0 0000609c9fd73700

-Christopher


On Wed, 2018-10-10 at 11:59 -0500, Frank Bulk wrote:

We had network event deeper in our network that resulted in some kind of

spanning tree event as evidenced by a TC (topology change) on our L2-only

ICX6610 stack. What surprised us was that one VLAN going into a blocking

state resulted in the south bound LAG going down.



This is probably not right, but the root bridge for VLAN 294 is on the

ICX6610 stack. VLAN 294 is on both LAGs (and no other port/LAG)



Three questions:

a) when a STP event occurs is it normal that a VLAN goes into Blocking on

all the ports where it is present?

b) when a VLAN goes into blocking should all the physical (or LAG) ports

associated with that VLAN go down?

c) does configuring spanning tree on the port-based VLAN but disabling

spanning-tree on the physical (or LAG) ports prevent the physical port (or

LAG) going down?



Frank



============================================================================

====

Oct 9 21:35:22 STP: VLAN 294 Port 1/3/6 Bridge TC Event (MakeBlking)

Oct 9 21:35:22 STP: VLAN 294 Port 1/3/6 STP State -> BLOCKING (MakeBlking)

Oct 9 21:35:25 System: Logical link on dynamic lag interface ethernet 2/3/8

is down.

Oct 9 21:35:25 System: Logical link on dynamic lag interface ethernet 3/3/4

is down.

Oct 9 21:35:26 System: Logical link on dynamic lag interface ethernet 3/3/8

is down.

Oct 9 21:35:29 Trunk: Group (1/3/8, 2/3/8, 3/3/4, 3/3/8) removed by 802.3ad

link-aggregation module.

Oct 9 21:35:29 STP: VLAN 4 Port 1/3/8 STP State -> BLOCKING (PortDown)

Oct 9 21:35:29 STP: VLAN 4 Port 1/3/8 STP State -> DISABLED (PortDown)

etc.



Event

|

Transport

| |

| | (1/3/6 & 2/3/6)

| |

ICX6610 (L2)

| | | |

| | | | (1/3/8, 2/3/8, 3/3/4, 3/3/8)

| | | |

Core (L3)







_______________________________________________

foundry-nsp mailing list

foundry-nsp@puck.nether.net<mailto:foundry-nsp@puck.nether.net>

http://puck.nether.net/mailman/listinfo/foundry-nsp
Re: Spanning-tree event on single VLAN brings down LAG? [ In reply to ]
We did not expect the “1/3/8, 2/3/8, 3/3/4, 3/3/8” LAG to drop, either – two network engineering consultants that I’ve shared this with don’t have good theories yet, either.



You’re right, the ICX6610 could have just been documenting the LAG member drops instead of initiating it, I just don’t know how to figure that out.



Frank



From: Howard, Christopher <Christopher-Howard@utc.edu>
Sent: Thursday, October 11, 2018 8:55 AM
To: foundry-nsp@puck.nether.net; frnkblk@iname.com
Subject: Re: [f-nsp] Spanning-tree event on single VLAN brings down LAG?



Looking at your log, 1/3/6 is where the block event happened. I would not expect the 6610 to have dropped the lag because of this, no matter which version of spanning tree you're running, because 1/3/6 is not a part of that lag.



Just some ideas:

- It could have been dropped on the other end by either the same or an unrelated event and you're just seeing the documentation of that on the 6610.

- I've seen before where a loop drove the switch CPU high enough to flap lags. Since spanning tree blocked the port that should have protected the CPU, unless there are other ports not participating in spanning tree on that vlan.

- A coincidence, but I admit the chances of that are unlikely with the timing of the lag drop.



-Christopher





On Thu, 2018-10-11 at 08:07 -0500, frnkblk@iname.com <mailto:frnkblk@iname.com> wrote:

Christopher,



Thanks for sharing. Your explanation regarding vlan enablement versus port disablement makes sense to me.



I plan to turn up 802.1w in a future maintenance window.



From the Brocade ICX6610 logs is it clear if the ICX6610 turned down the 10G ports, or did the core router link it down and the ICX6610 was merely documenting that it was being pulled down?



Frank



From: Howard, Christopher <Christopher-Howard@utc.edu <mailto:Christopher-Howard@utc.edu> >
Sent: Wednesday, October 10, 2018 12:32 PM
To: foundry-nsp@puck.nether.net <mailto:foundry-nsp@puck.nether.net> ; frnkblk@iname.com <mailto:frnkblk@iname.com>
Subject: Re: [f-nsp] Spanning-tree event on single VLAN brings down LAG?



One vlan getting blocked by spanning tree should not bring down the lag. The vlan should only block on the interfaces required to remove the loop. As far as I know, if you have spanning tree enabled on the vlan, but disabled on the physical port, then the physical port no longer participates in spanning tree for any vlan.





Here's config from one of my switches. This is an ICX7750 with 8.0.30r code, same code that ICX6610 can run.



lag lag-name dynamic id 1
ports ethernet 1/1/2 ethernet 2/1/2
primary-port 1/1/2
deploy
!
vlan 123 name vlan-name by port
tagged ethe 1/1/2 ethe 2/1/2
spanning-tree 802-1w
!
interface ethernet 1/1/2
spanning-tree 802-1w admin-pt2pt-mac





A snipped output from "show 802-1w" below with vlans in both discarding and forwarding states on that lag.



--- VLAN 404 [ STP Instance owned by VLAN 404 ] ----------------------------

1/1/2 128 2000 T F ALTERNATE DISCARDING 2000 0001609c9fd73700



--- VLAN 999 [ STP Instance owned by VLAN 999 ] ----------------------------

1/1/2 128 2000 T F ALTERNATE DISCARDING 2000 0001609c9fd73700



--- VLAN 2007 [ STP Instance owned by VLAN 2007 ] ---------------------------

1/1/2 128 2000 T F ROOT FORWARDING 0 0000609c9fd73700



--- VLAN 2057 [ STP Instance owned by VLAN 2057 ] ---------------------------

1/1/2 128 2000 T F ROOT FORWARDING 0 0000609c9fd73700



-Christopher





On Wed, 2018-10-10 at 11:59 -0500, Frank Bulk wrote:

We had network event deeper in our network that resulted in some kind of
spanning tree event as evidenced by a TC (topology change) on our L2-only
ICX6610 stack. What surprised us was that one VLAN going into a blocking
state resulted in the south bound LAG going down.

This is probably not right, but the root bridge for VLAN 294 is on the
ICX6610 stack. VLAN 294 is on both LAGs (and no other port/LAG)

Three questions:
a) when a STP event occurs is it normal that a VLAN goes into Blocking on
all the ports where it is present?
b) when a VLAN goes into blocking should all the physical (or LAG) ports
associated with that VLAN go down?
c) does configuring spanning tree on the port-based VLAN but disabling
spanning-tree on the physical (or LAG) ports prevent the physical port (or
LAG) going down?

Frank

============================================================================
====
Oct 9 21:35:22 STP: VLAN 294 Port 1/3/6 Bridge TC Event (MakeBlking)
Oct 9 21:35:22 STP: VLAN 294 Port 1/3/6 STP State -> BLOCKING (MakeBlking)
Oct 9 21:35:25 System: Logical link on dynamic lag interface ethernet 2/3/8
is down.
Oct 9 21:35:25 System: Logical link on dynamic lag interface ethernet 3/3/4
is down.
Oct 9 21:35:26 System: Logical link on dynamic lag interface ethernet 3/3/8
is down.
Oct 9 21:35:29 Trunk: Group (1/3/8, 2/3/8, 3/3/4, 3/3/8) removed by 802.3ad
link-aggregation module.
Oct 9 21:35:29 STP: VLAN 4 Port 1/3/8 STP State -> BLOCKING (PortDown)
Oct 9 21:35:29 STP: VLAN 4 Port 1/3/8 STP State -> DISABLED (PortDown)
etc.

Event
|
Transport
| |
| | (1/3/6 & 2/3/6)
| |
ICX6610 (L2)
| | | |
| | | | (1/3/8, 2/3/8, 3/3/4, 3/3/8)
| | | |
Core (L3)



_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net <mailto:foundry-nsp@puck.nether.net>
http://puck.nether.net/mailman/listinfo/foundry-nsp
Re: Spanning-tree event on single VLAN brings down LAG? [ In reply to ]
If you have a lag, perhaps you have no loops and can filter bpdu's to see
if it stops happening. Also consider rstp instead of stp.

On Thu, Oct 11, 2018 at 4:33 PM Frank Bulk <frnkblk@iname.com> wrote:

> We did not expect the “1/3/8, 2/3/8, 3/3/4, 3/3/8” LAG to drop, either –
> two network engineering consultants that I’ve shared this with don’t have
> good theories yet, either.
>
>
>
> You’re right, the ICX6610 could have just been documenting the LAG member
> drops instead of initiating it, I just don’t know how to figure that out.
>
>
>
> Frank
>
>
>
> *From:* Howard, Christopher <Christopher-Howard@utc.edu>
> *Sent:* Thursday, October 11, 2018 8:55 AM
> *To:* foundry-nsp@puck.nether.net; frnkblk@iname.com
> *Subject:* Re: [f-nsp] Spanning-tree event on single VLAN brings down LAG?
>
>
>
> Looking at your log, 1/3/6 is where the block event happened. I would not
> expect the 6610 to have dropped the lag because of this, no matter which
> version of spanning tree you're running, because 1/3/6 is not a part of
> that lag.
>
>
>
> Just some ideas:
>
> - It could have been dropped on the other end by either the same or an
> unrelated event and you're just seeing the documentation of that on the
> 6610.
>
> - I've seen before where a loop drove the switch CPU high enough to flap
> lags. Since spanning tree blocked the port that should have protected the
> CPU, unless there are other ports not participating in spanning tree on
> that vlan.
>
> - A coincidence, but I admit the chances of that are unlikely with the
> timing of the lag drop.
>
>
>
> -Christopher
>
>
>
>
>
> On Thu, 2018-10-11 at 08:07 -0500, frnkblk@iname.com wrote:
>
> Christopher,
>
>
>
> Thanks for sharing. Your explanation regarding vlan enablement versus
> port disablement makes sense to me.
>
>
>
> I plan to turn up 802.1w in a future maintenance window.
>
>
>
> From the Brocade ICX6610 logs is it clear if the ICX6610 turned down the
> 10G ports, or did the core router link it down and the ICX6610 was merely
> documenting that it was being pulled down?
>
>
>
> Frank
>
>
>
> *From:* Howard, Christopher <Christopher-Howard@utc.edu>
> *Sent:* Wednesday, October 10, 2018 12:32 PM
> *To:* foundry-nsp@puck.nether.net; frnkblk@iname.com
> *Subject:* Re: [f-nsp] Spanning-tree event on single VLAN brings down LAG?
>
>
>
> One vlan getting blocked by spanning tree should not bring down the lag.
> The vlan should only block on the interfaces required to remove the loop.
> As far as I know, if you have spanning tree enabled on the vlan, but
> disabled on the physical port, then the physical port no longer
> participates in spanning tree for any vlan.
>
>
>
>
>
> Here's config from one of my switches. This is an ICX7750 with 8.0.30r
> code, same code that ICX6610 can run.
>
>
>
> lag lag-name dynamic id 1
>
> ports ethernet 1/1/2 ethernet 2/1/2
>
> primary-port 1/1/2
>
> deploy
>
> !
>
> vlan 123 name vlan-name by port
>
> tagged ethe 1/1/2 ethe 2/1/2
>
> spanning-tree 802-1w
>
> !
>
> interface ethernet 1/1/2
>
> spanning-tree 802-1w admin-pt2pt-mac
>
>
>
>
>
> A snipped output from "show 802-1w" below with vlans in both discarding
> and forwarding states on that lag.
>
>
>
> --- VLAN 404 [ STP Instance owned by VLAN 404 ]
> ----------------------------
>
> 1/1/2 128
> 2000 T F ALTERNATE DISCARDING 2000 0001609c9fd73700
>
>
>
> --- VLAN 999 [ STP Instance owned by VLAN 999 ]
> ----------------------------
>
> 1/1/2 128
> 2000 T F ALTERNATE DISCARDING 2000 0001609c9fd73700
>
>
>
> --- VLAN 2007 [ STP Instance owned by VLAN 2007 ]
> ---------------------------
>
> 1/1/2 128
> 2000 T F ROOT FORWARDING 0 0000609c9fd73700
>
>
>
> --- VLAN 2057 [ STP Instance owned by VLAN 2057 ]
> ---------------------------
>
> 1/1/2 128
> 2000 T F ROOT FORWARDING 0 0000609c9fd73700
>
>
>
> -Christopher
>
>
>
>
>
> On Wed, 2018-10-10 at 11:59 -0500, Frank Bulk wrote:
>
> We had network event deeper in our network that resulted in some kind of
>
> spanning tree event as evidenced by a TC (topology change) on our L2-only
>
> ICX6610 stack. What surprised us was that one VLAN going into a blocking
>
> state resulted in the south bound LAG going down.
>
>
>
> This is probably not right, but the root bridge for VLAN 294 is on the
>
> ICX6610 stack. VLAN 294 is on both LAGs (and no other port/LAG)
>
>
>
> Three questions:
>
> a) when a STP event occurs is it normal that a VLAN goes into Blocking on
>
> all the ports where it is present?
>
> b) when a VLAN goes into blocking should all the physical (or LAG) ports
>
> associated with that VLAN go down?
>
> c) does configuring spanning tree on the port-based VLAN but disabling
>
> spanning-tree on the physical (or LAG) ports prevent the physical port (or
>
> LAG) going down?
>
>
>
> Frank
>
>
>
> ============================================================================
>
> ====
>
> Oct 9 21:35:22 STP: VLAN 294 Port 1/3/6 Bridge TC Event (MakeBlking)
>
> Oct 9 21:35:22 STP: VLAN 294 Port 1/3/6 STP State -> BLOCKING (MakeBlking)
>
> Oct 9 21:35:25 System: Logical link on dynamic lag interface ethernet 2/3/8
>
> is down.
>
> Oct 9 21:35:25 System: Logical link on dynamic lag interface ethernet 3/3/4
>
> is down.
>
> Oct 9 21:35:26 System: Logical link on dynamic lag interface ethernet 3/3/8
>
> is down.
>
> Oct 9 21:35:29 Trunk: Group (1/3/8, 2/3/8, 3/3/4, 3/3/8) removed by 802.3ad
>
> link-aggregation module.
>
> Oct 9 21:35:29 STP: VLAN 4 Port 1/3/8 STP State -> BLOCKING (PortDown)
>
> Oct 9 21:35:29 STP: VLAN 4 Port 1/3/8 STP State -> DISABLED (PortDown)
>
> etc.
>
>
>
> Event
>
> |
>
> Transport
>
> | |
>
> | | (1/3/6 & 2/3/6)
>
> | |
>
> ICX6610 (L2)
>
> | | | |
>
> | | | | (1/3/8, 2/3/8, 3/3/4, 3/3/8)
>
> | | | |
>
> Core (L3)
>
>
>
>
>
> _______________________________________________
>
> foundry-nsp mailing list
>
> foundry-nsp@puck.nether.net
>
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>
>
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>

--

E-Mail to and from me, in connection with the transaction
of public
business, is subject to the Wyoming Public Records
Act and may be
disclosed to third parties.
Re: Spanning-tree event on single VLAN brings down LAG? [ In reply to ]
Daniel,



The feedback I received from another consultant is that perhaps the topology change seen by VLAN 294 passed down from the ICX6610 to our core router (Cisco 7600), but since we don’t have dual-mode enabled on the Brocade the core router’s PVST updates to the ICX6610 (which are typically on VLAN 1, untagged) resulted in the LAG between the ICX6610 and core router being torn down.



We’re planning to move to RSTP or RPVST.



Frank



From: Daniel Schmidt <daniel.schmidt@wyo.gov>
Sent: Tuesday, October 16, 2018 1:54 PM
To: frnkblk@iname.com
Cc: foundry-nsp@puck.nether.net
Subject: Re: [f-nsp] Spanning-tree event on single VLAN brings down LAG?



If you have a lag, perhaps you have no loops and can filter bpdu's to see if it stops happening. Also consider rstp instead of stp.



On Thu, Oct 11, 2018 at 4:33 PM Frank Bulk <frnkblk@iname.com <mailto:frnkblk@iname.com> > wrote:

We did not expect the “1/3/8, 2/3/8, 3/3/4, 3/3/8” LAG to drop, either – two network engineering consultants that I’ve shared this with don’t have good theories yet, either.



You’re right, the ICX6610 could have just been documenting the LAG member drops instead of initiating it, I just don’t know how to figure that out.



Frank



From: Howard, Christopher <Christopher-Howard@utc.edu <mailto:Christopher-Howard@utc.edu> >
Sent: Thursday, October 11, 2018 8:55 AM
To: foundry-nsp@puck.nether.net <mailto:foundry-nsp@puck.nether.net> ; frnkblk@iname.com <mailto:frnkblk@iname.com>
Subject: Re: [f-nsp] Spanning-tree event on single VLAN brings down LAG?



Looking at your log, 1/3/6 is where the block event happened. I would not expect the 6610 to have dropped the lag because of this, no matter which version of spanning tree you're running, because 1/3/6 is not a part of that lag.



Just some ideas:

- It could have been dropped on the other end by either the same or an unrelated event and you're just seeing the documentation of that on the 6610.

- I've seen before where a loop drove the switch CPU high enough to flap lags. Since spanning tree blocked the port that should have protected the CPU, unless there are other ports not participating in spanning tree on that vlan.

- A coincidence, but I admit the chances of that are unlikely with the timing of the lag drop.



-Christopher





On Thu, 2018-10-11 at 08:07 -0500, frnkblk@iname.com <mailto:frnkblk@iname.com> wrote:

Christopher,



Thanks for sharing. Your explanation regarding vlan enablement versus port disablement makes sense to me.



I plan to turn up 802.1w in a future maintenance window.



From the Brocade ICX6610 logs is it clear if the ICX6610 turned down the 10G ports, or did the core router link it down and the ICX6610 was merely documenting that it was being pulled down?



Frank



From: Howard, Christopher <Christopher-Howard@utc.edu <mailto:Christopher-Howard@utc.edu> >
Sent: Wednesday, October 10, 2018 12:32 PM
To: foundry-nsp@puck.nether.net <mailto:foundry-nsp@puck.nether.net> ; frnkblk@iname.com <mailto:frnkblk@iname.com>
Subject: Re: [f-nsp] Spanning-tree event on single VLAN brings down LAG?



One vlan getting blocked by spanning tree should not bring down the lag. The vlan should only block on the interfaces required to remove the loop. As far as I know, if you have spanning tree enabled on the vlan, but disabled on the physical port, then the physical port no longer participates in spanning tree for any vlan.





Here's config from one of my switches. This is an ICX7750 with 8.0.30r code, same code that ICX6610 can run.



lag lag-name dynamic id 1
ports ethernet 1/1/2 ethernet 2/1/2
primary-port 1/1/2
deploy
!
vlan 123 name vlan-name by port
tagged ethe 1/1/2 ethe 2/1/2
spanning-tree 802-1w
!
interface ethernet 1/1/2
spanning-tree 802-1w admin-pt2pt-mac





A snipped output from "show 802-1w" below with vlans in both discarding and forwarding states on that lag.



--- VLAN 404 [ STP Instance owned by VLAN 404 ] ----------------------------

1/1/2 128 2000 T F ALTERNATE DISCARDING 2000 0001609c9fd73700



--- VLAN 999 [ STP Instance owned by VLAN 999 ] ----------------------------

1/1/2 128 2000 T F ALTERNATE DISCARDING 2000 0001609c9fd73700



--- VLAN 2007 [ STP Instance owned by VLAN 2007 ] ---------------------------

1/1/2 128 2000 T F ROOT FORWARDING 0 0000609c9fd73700



--- VLAN 2057 [ STP Instance owned by VLAN 2057 ] ---------------------------

1/1/2 128 2000 T F ROOT FORWARDING 0 0000609c9fd73700



-Christopher





On Wed, 2018-10-10 at 11:59 -0500, Frank Bulk wrote:

We had network event deeper in our network that resulted in some kind of
spanning tree event as evidenced by a TC (topology change) on our L2-only
ICX6610 stack. What surprised us was that one VLAN going into a blocking
state resulted in the south bound LAG going down.

This is probably not right, but the root bridge for VLAN 294 is on the
ICX6610 stack. VLAN 294 is on both LAGs (and no other port/LAG)

Three questions:
a) when a STP event occurs is it normal that a VLAN goes into Blocking on
all the ports where it is present?
b) when a VLAN goes into blocking should all the physical (or LAG) ports
associated with that VLAN go down?
c) does configuring spanning tree on the port-based VLAN but disabling
spanning-tree on the physical (or LAG) ports prevent the physical port (or
LAG) going down?

Frank

============================================================================
====
Oct 9 21:35:22 STP: VLAN 294 Port 1/3/6 Bridge TC Event (MakeBlking)
Oct 9 21:35:22 STP: VLAN 294 Port 1/3/6 STP State -> BLOCKING (MakeBlking)
Oct 9 21:35:25 System: Logical link on dynamic lag interface ethernet 2/3/8
is down.
Oct 9 21:35:25 System: Logical link on dynamic lag interface ethernet 3/3/4
is down.
Oct 9 21:35:26 System: Logical link on dynamic lag interface ethernet 3/3/8
is down.
Oct 9 21:35:29 Trunk: Group (1/3/8, 2/3/8, 3/3/4, 3/3/8) removed by 802.3ad
link-aggregation module.
Oct 9 21:35:29 STP: VLAN 4 Port 1/3/8 STP State -> BLOCKING (PortDown)
Oct 9 21:35:29 STP: VLAN 4 Port 1/3/8 STP State -> DISABLED (PortDown)
etc.

Event
|
Transport
| |
| | (1/3/6 & 2/3/6)
| |
ICX6610 (L2)
| | | |
| | | | (1/3/8, 2/3/8, 3/3/4, 3/3/8)
| | | |
Core (L3)



_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net <mailto:foundry-nsp@puck.nether.net>
http://puck.nether.net/mailman/listinfo/foundry-nsp


_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net <mailto:foundry-nsp@puck.nether.net>
http://puck.nether.net/mailman/listinfo/foundry-nsp



E-Mail to and from me, in connection with the transaction
of public business, is subject to the Wyoming Public Records
Act and may be disclosed to third parties.