[f-nsp] Spanning-tree event on single VLAN brings down LAG?

[Eldon Koyle]

Which flavor of spanning tree are you running?

-- 
Eldon

On Wed, Oct 10, 2018 at 11:32 AM Howard, Christopher <
Christopher-Howard at 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 at puck.nether.net
>
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp at puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/foundry-nsp/attachments/20181010/f7b5a88c/attachment-0001.html>