Wired

I have a 5308 switch acting as a building router (I know it's super old, and have plans to upgrade it with a 5406R in a few weeks, but doing it in 2 parts is how this network upgrade ended up working out).  It's connected to a VSF of 3 2930F switches with a trunk of 2 1000BT connections.

------------------------------
Adam Forsyth
------------------------------

Hello Adam, in a similar scenario if I were you I would switch from a non-Protocol (Trunk) Port Trunk to a LACP driven Port Trunk, on both ends this means:

trunk C12,C13 trk4 lacp <- HP ProCurve 5308 side
trunk 1/48,3/48 trk2 lacp <- VSF Aruba 2930F side

and here show lacp and show trunk commands are your friends.

To perform the change (from trunk mode to lacp mode) you should destroy the <Trk-Id> logical interfaces on both ends so plan it accordingly (expect some disruption).

Also check VLAN memberships of both <Trk-Id> logical interfaces to see if they match each others: use the show vlan ports ethernet <trkX> details command (VLANs membership's patterns should match in a trk4 versus trk2 comparison).

Verify settings of C12, C13, 1/48 and 3/48 interfaces in order to see if they "match" (especially Speed and Duplex mode, say all 1Gbps and all Full-Duplex Auto-Negotiation); if you're going to change trunk mode to lacp mode on those Port Trunks do start from physical interfaces in their default state (clear statistic counters, reset VLAN membership to VLAN 1 default untagged)...in other terms, if you have doubts, try to start from scratch, it's not mandatory nor essential...but it could help...you can also just reconfigure them (with cabling disconnected)...it's just a way to do things step-by-step starting from a known operational state.

I would also check the VSF status of your three Aruba 2930F Switches (since you're terminating the physical links coming from the standalone HP ProCurve 5308xl C12 and C13 ports, respectively into VSF Member 1 port 48 and VSF Member 3 port 48...the good health of VSF plays a role here).

A well formed Port Trunk (Link Aggregation) should have no issue with Spanning Tree since (M|R)STP, once enabled, will see the aggregation as one interface (so no blocking action will occur on Port Trunk member interfaces).

Eventually you can do few customizations on Trunk ports (as example, set the point-to-point mac option to true on both the logical Trk4 and Trk2 interfaces <- this because the link is between two peer switches).

Hope you're moving from a standalone HP ProCurve 5308xl to a VSF of Aruba 5400R zl2...or, at least, to a single Aruba 5400R zl2 with two Management Modules (with NonStop Redundancy enabled)...if you are forced to use the HP ProCurve 5308xl for longer than expected then a good thing would be to use Trk4 member ports from different modules (if you can)...so if a module in which there is one member port fails, the Trk4 will survive.

------------------------------
Davide Poletto
------------------------------

Original Message:
Sent: Sep 24, 2021 07:36 PM
From: Adam Forsyth
Subject: Trunk configuration of an uplink between switches

I have a 5308 switch acting as a building router (I know it's super old, and have plans to upgrade it with a 5406R in a few weeks, but doing it in 2 parts is how this network upgrade ended up working out).  It's connected to a VSF of 3 2930F switches with a trunk of 2 1000BT connections.

On the 5308 the trunk is configured like this:

trunk C12-C13 Trk4 Trunk

On the 2930F side the trunk is configured like this:

trunk 1/48,3/48 trk2 trunk

This should match and work properly, right?  I do it all the time in lots of different places on our network, and it works just fine.  I ask because this configuration had been working fine for a few weeks, but yesterday I got reports that users on the network in this building were having difficulty.  I started looking into it and found that we were having packet loss of 60% or more, and when pinging different things ping was reporting duplicates being received.  

So, I started suspecting a network loop (despite the fact that spanning tree is configured and should eliminate a loop should a user create one).  I finally figured out the loop was the connection between these two switches.  If I disconnected one of the links, the network would recover and everything would start working fine again.  If I reconnected it, performance would degrade and I'd start seeing the duplicate ping packets again.

For now I've left the uplink with one connection of the trunk unplugged, and it continues to work fine.  Does anyone have an idea of what's going wrong in this situation?

------------------------------
Adam Forsyth
------------------------------

Original Message:
Sent: 9/25/2021 3:26:00 AM
From: parnassus
Subject: RE: Trunk configuration of an uplink between switches

Hello Adam, in a similar scenario if I were you I would switch from a non-Protocol (Trunk) Port Trunk to a LACP driven Port Trunk, on both ends this means:

trunk C12,C13 trk4 lacp <- HP ProCurve 5308 side
trunk 1/48,3/48 trk2 lacp <- VSF Aruba 2930F side

and here show lacp and show trunk commands are your friends.

To perform the change (from trunk mode to lacp mode) you should destroy the <Trk-Id> logical interfaces on both ends so plan it accordingly (expect some disruption).

Also check VLAN memberships of both <Trk-Id> logical interfaces to see if they match each others: use the show vlan ports ethernet <trkX> details command (VLANs membership's patterns should match in a trk4 versus trk2 comparison).

Verify settings of C12, C13, 1/48 and 3/48 interfaces in order to see if they "match" (especially Speed and Duplex mode, say all 1Gbps and all Full-Duplex Auto-Negotiation); if you're going to change trunk mode to lacp mode on those Port Trunks do start from physical interfaces in their default state (clear statistic counters, reset VLAN membership to VLAN 1 default untagged)...in other terms, if you have doubts, try to start from scratch, it's not mandatory nor essential...but it could help...you can also just reconfigure them (with cabling disconnected)...it's just a way to do things step-by-step starting from a known operational state.

I would also check the VSF status of your three Aruba 2930F Switches (since you're terminating the physical links coming from the standalone HP ProCurve 5308xl C12 and C13 ports, respectively into VSF Member 1 port 48 and VSF Member 3 port 48...the good health of VSF plays a role here).

A well formed Port Trunk (Link Aggregation) should have no issue with Spanning Tree since (M|R)STP, once enabled, will see the aggregation as one interface (so no blocking action will occur on Port Trunk member interfaces).

Eventually you can do few customizations on Trunk ports (as example, set the point-to-point mac option to true on both the logical Trk4 and Trk2 interfaces <- this because the link is between two peer switches).

Hope you're moving from a standalone HP ProCurve 5308xl to a VSF of Aruba 5400R zl2...or, at least, to a single Aruba 5400R zl2 with two Management Modules (with NonStop Redundancy enabled)...if you are forced to use the HP ProCurve 5308xl for longer than expected then a good thing would be to use Trk4 member ports from different modules (if you can)...so if a module in which there is one member port fails, the Trk4 will survive.

------------------------------
Davide Poletto
------------------------------

Original Message:
Sent: Sep 24, 2021 07:36 PM
From: Adam Forsyth
Subject: Trunk configuration of an uplink between switches

I have a 5308 switch acting as a building router (I know it's super old, and have plans to upgrade it with a 5406R in a few weeks, but doing it in 2 parts is how this network upgrade ended up working out).  It's connected to a VSF of 3 2930F switches with a trunk of 2 1000BT connections.

On the 5308 the trunk is configured like this:

trunk C12-C13 Trk4 Trunk

On the 2930F side the trunk is configured like this:

trunk 1/48,3/48 trk2 trunk

This should match and work properly, right?  I do it all the time in lots of different places on our network, and it works just fine.  I ask because this configuration had been working fine for a few weeks, but yesterday I got reports that users on the network in this building were having difficulty.  I started looking into it and found that we were having packet loss of 60% or more, and when pinging different things ping was reporting duplicates being received.  

So, I started suspecting a network loop (despite the fact that spanning tree is configured and should eliminate a loop should a user create one).  I finally figured out the loop was the connection between these two switches.  If I disconnected one of the links, the network would recover and everything would start working fine again.  If I reconnected it, performance would degrade and I'd start seeing the duplicate ping packets again.

For now I've left the uplink with one connection of the trunk unplugged, and it continues to work fine.  Does anyone have an idea of what's going wrong in this situation?

------------------------------
Adam Forsyth
------------------------------

Hello Adam,

"Are LACP trunks preferred in general? I've used them only where the HP/Aruba switch is connected to something that is made by another manufacture (which is an infrequent occurrence on our network). Since the non lacp version of a trunk seems to be hp's default, I assumed that was preferred for some reason going back to whenever I first learned the concept of a trunk years ago."

In my opinion, yes they should be preferred over the non protocol mode (trunk). I'm not so sure about trunk being the HP default (now or in the past)...I believe there isn't/wasn't a default (indeed the option trunk versus lacp needs to be specified explicitly).

Personally I use LACP as often as possible (disregarding the peer's device "identity"...from my PoV if the peer device supports LACP IEEE 802.3ad I go with LACP, no doubt) and the only case where I was forced to fallback and use the trunk mode was when I connected a ESXi node and the licensed ESXi did not support LACP (note: most of the VMware deployments I worked on adopted a - say "non-top" - licensing model that is able to support only Virtual Standard Switch types and VSS types don't support LACP as it happens instead with Virtual Distributed Switch types, VDS types do but to be deployed they require a particular licensing).

The point is that - speaking about an HP/HPE/Aruba Switch - a Port Trunk (Links Aggregation) operating with "trunk" mode (thus Non Protocol or called also "Static") doesn't exchange any info with peer's link aggregation logical interface as instead is going to happen when the Port Trunk operates with "lacp" mode (thus driven by Protocol or called "LACP Static"): I tend to prefer the fact that there is a Control Protocol exchanging LACPDU with the logical interface on the other end (instead on not having that) and that some adjustments are permitted too (see lacp options like min-active-links and enable-timer) especially useful when Port Trunk's members are more than two physical ports.

If you're going to setup links aggregations between HP/HPE/Aruba switches and so your network is somewhat omogeneous I really don't see the reason for not going with LACP as often as possible (and even if your Port Trunks are limited to two physical ports).

Hashing algorithm used to address links balancing for egressing traffic works behind the scene in any case (<Trk-Id> trunk versus <Trk-Id> lacp).

VLAN membership can be applied indifferently to <Trk-Id> trunk and to <Trk-Id> lacp (the only exception is the case of lacp active which generates a Dynamic logical interface of the form <Dyn-Id>). so - from that PoV - operating as you're used of with LACP doesn't change the way you untag and/or tag those logical interfaces.

"My plan is that the 5406R that replaces the 5308 will have 2 management modules."

That's good but...personal experience...from the PoV of resiliency...a VSF deployment would be probably better IMHO if chassis is considered a SPoF (clearly VSF comes at the price of an additional Aruba 5406R zl2 Chassis + two PSUs + necessary V3 zl2 modules and, among them, at least a 8x10 SFP+ Module per chassis for DACs + one MM per chassis + at least two-to-four DACs for VSF Inter-Switch Links).

Edit: back on track...were BPDU filtering and Loop Protect applied on ports dedicated to access/edge devices? it's pretty strange a Port Trunk (trunk or lcap) to cause such issue...

------------------------------
Davide Poletto
------------------------------

Original Message:
Sent: Sep 25, 2021 11:20 AM
From: Adam Forsyth
Subject: Trunk configuration of an uplink between switches

Are LACP trunks preferred in general?  I've used them only where the HP/Aruba switch is connected to something that is made by another manufacture (which is an infrequent occurrence on our network).  Since the non lacp version of a trunk seems to be hp's default,  I assumed that was preferred for some reason going back to whenever I first learned the concept of a trunk years ago.

I used  "show lldp info remote-device" to double check that I had the ports that I intended connected to one another

show vsf shows that the status of the vsf health is good (topology is a ring, and all 3 members are present as are their vsf links.

My plan is that the 5406R that replaces the 5308 will have 2 management modules.

--

Adam Forsyth Director of Network and Systems Information Technology Services P 563.387.1402 E forsytad@luther.edu W http://www.luther.edu

Original Message:
Sent: 9/25/2021 3:26:00 AM
From: parnassus
Subject: RE: Trunk configuration of an uplink between switches

Hello Adam, in a similar scenario if I were you I would switch from a non-Protocol (Trunk) Port Trunk to a LACP driven Port Trunk, on both ends this means:

trunk C12,C13 trk4 lacp <- HP ProCurve 5308 side
trunk 1/48,3/48 trk2 lacp <- VSF Aruba 2930F side

and here show lacp and show trunk commands are your friends.

To perform the change (from trunk mode to lacp mode) you should destroy the <Trk-Id> logical interfaces on both ends so plan it accordingly (expect some disruption).

Also check VLAN memberships of both <Trk-Id> logical interfaces to see if they match each others: use the show vlan ports ethernet <trkX> details command (VLANs membership's patterns should match in a trk4 versus trk2 comparison).

Verify settings of C12, C13, 1/48 and 3/48 interfaces in order to see if they "match" (especially Speed and Duplex mode, say all 1Gbps and all Full-Duplex Auto-Negotiation); if you're going to change trunk mode to lacp mode on those Port Trunks do start from physical interfaces in their default state (clear statistic counters, reset VLAN membership to VLAN 1 default untagged)...in other terms, if you have doubts, try to start from scratch, it's not mandatory nor essential...but it could help...you can also just reconfigure them (with cabling disconnected)...it's just a way to do things step-by-step starting from a known operational state.

I would also check the VSF status of your three Aruba 2930F Switches (since you're terminating the physical links coming from the standalone HP ProCurve 5308xl C12 and C13 ports, respectively into VSF Member 1 port 48 and VSF Member 3 port 48...the good health of VSF plays a role here).

A well formed Port Trunk (Link Aggregation) should have no issue with Spanning Tree since (M|R)STP, once enabled, will see the aggregation as one interface (so no blocking action will occur on Port Trunk member interfaces).

Eventually you can do few customizations on Trunk ports (as example, set the point-to-point mac option to true on both the logical Trk4 and Trk2 interfaces <- this because the link is between two peer switches).

Hope you're moving from a standalone HP ProCurve 5308xl to a VSF of Aruba 5400R zl2...or, at least, to a single Aruba 5400R zl2 with two Management Modules (with NonStop Redundancy enabled)...if you are forced to use the HP ProCurve 5308xl for longer than expected then a good thing would be to use Trk4 member ports from different modules (if you can)...so if a module in which there is one member port fails, the Trk4 will survive.

------------------------------
Davide Poletto

Original Message:
Sent: Sep 24, 2021 07:36 PM
From: Adam Forsyth
Subject: Trunk configuration of an uplink between switches

I have a 5308 switch acting as a building router (I know it's super old, and have plans to upgrade it with a 5406R in a few weeks, but doing it in 2 parts is how this network upgrade ended up working out).  It's connected to a VSF of 3 2930F switches with a trunk of 2 1000BT connections.

On the 5308 the trunk is configured like this:

trunk C12-C13 Trk4 Trunk

On the 2930F side the trunk is configured like this:

trunk 1/48,3/48 trk2 trunk

This should match and work properly, right?  I do it all the time in lots of different places on our network, and it works just fine.  I ask because this configuration had been working fine for a few weeks, but yesterday I got reports that users on the network in this building were having difficulty.  I started looking into it and found that we were having packet loss of 60% or more, and when pinging different things ping was reporting duplicates being received.  

So, I started suspecting a network loop (despite the fact that spanning tree is configured and should eliminate a loop should a user create one).  I finally figured out the loop was the connection between these two switches.  If I disconnected one of the links, the network would recover and everything would start working fine again.  If I reconnected it, performance would degrade and I'd start seeing the duplicate ping packets again.

For now I've left the uplink with one connection of the trunk unplugged, and it continues to work fine.  Does anyone have an idea of what's going wrong in this situation?

------------------------------
Adam Forsyth
------------------------------