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

Tue Oct 16 14:54:29 EDT 2018

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 at 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 at utc.edu>
> *Sent:* Thursday, October 11, 2018 8:55 AM
> *To:* foundry-nsp at puck.nether.net; frnkblk at 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 at 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 at utc.edu>
> *Sent:* Wednesday, October 10, 2018 12:32 PM
> *To:* foundry-nsp at puck.nether.net; frnkblk at 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 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
>

-- 

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/foundry-nsp/attachments/20181016/5d797b76/attachment.html>