2920 DTP functionality, cabling/config verification

[jw1n5]

Problem:

Every few nights we have a VM host cluster that bounces VMs around because of link loss between the nodes. The nodes are cabled into the GS748Tv3 switches mentioned below, which then connect to the 2920 stack. Essentially, link is lost between the nodes, hearbeats are missed, and VMs migrate. No other issues seem to be occurring at the time but it is typically afterhours that it happens and only a few people are working. Syslogs from the core show a slew of STP events and uptime on the GS748Tv3s reflects that *both* of those switches have restarted.

Goal/Question:

I'd like to confirm that configuration and cabling to the 2920s is correct and see if there is any advice for a better approach (mesh, ring, etc). This very well could be a problem with the Netgear switches but I just want to rule out any configurations to the stack that might be problematic.

Details:

Our environment has a stack of two HP 2920-48G switches at the core. These switches are doing our routing with an ASA 5510 in front. There are a total of 6 other switches throughout the environment, two Netgear GS748Tv3s, two Powerconnect 5524s, and two Netgear GS724Tv3. The Netgears are the original distribution switches, the Dells are iSCSI/VMWare cluster switches and, as mentioned, the HPs are the core switches.

We have only two VLANs, nothing overly complicated there. For the cabling, we have LAGs/Trunks from all of the switches to the cores. 

The LAGs/Trunks are configured as follows:

TRK1
Core SW1 1/48 > Distribution SW1 1/45
Core SW2 2/48 > Distribution SW1 1/46

TRK2
Core SW1 1/47 > Distribution SW2 1/45
Core SW2 2/47 > Distribution SW2 1/46

TRK3
Core SW1 1/46 > Distribution SW3 1/45
Core SW2 2/46 > Distribution SW3 1/46

And so on.

The trunks on the HP cores all show as up and LACP shows active partnerships on each port of the trunks. Spanning tree shows all trunks in forwarding state. The other switches also have two port LAGs configured, using LACP. We don't have any other connections between the switches, everything just feeds back to the cores. 

As I understand it, the 2920s support DTP so I believe this is technically an acceptable configuration but, as I mentioned, I am just checking to see if 1) it isn't acceptable, 2) it works but could use some improvements.

Attached crude visio diagram, syslogs from the stack, and below is some output from the config and LACP/Trunk status

CoreSWStack# sh run

Running configuration:

; hpStack_WB Configuration Editor; Created on release #WB.15.15.0008
; Ver #06:08.18.f3.ff.35.0d:22

stacking
   member 1 type "J9728A" mac-address 1458d0-96bf40
   member 2 type "J9728A" mac-address 1458d0-96df40
   exit
hostname "CoreSWStack"
trunk 1/48,2/48 trk1 lacp
trunk 1/47,2/47 trk2 lacp
trunk 1/46,2/46 trk3 lacp
trunk 1/45,2/45 trk4 lacp
trunk 1/44,2/44 trk5 lacp
trunk 1/43,2/43 trk6 lacp
logging 10.0.254.244
logging notify running-config-change
timesync sntp
sntp unicast
sntp 60
sntp server priority 1 10.0.254.245
time daylight-time-rule continental-us-and-canada
time timezone -360
ip route 0.0.0.0 0.0.0.0 172.16.16.1
ip routing
snmp-server community "public" unrestricted
snmp-server location "Server Room"
oobm
   ip address dhcp-bootp
   member 1
      ip address dhcp-bootp
      exit
   member 2
      ip address dhcp-bootp
      exit
   exit
vlan 1
   name "DEFAULT_VLAN"
   no untagged 1/1,2/1
   untagged 1/2-1/42,1/A1-1/A2,1/B1-1/B2,2/2-2/42,2/A1-2/A2,2/B1-2/B2,Trk1-Trk6
   ip address 10.0.254.254 255.255.255.0
   exit
vlan 99
   name "Wireless VLAN"
   tagged 1/1,1/40-1/42,2/1,Trk1-Trk4
   ip address 10.0.99.254 255.255.255.0
   ip helper-address 10.0.254.245
   exit
vlan 254
   name "External"
   untagged 1/1,2/1
   ip address 172.16.16.2 255.255.255.252
   exit
spanning-tree
spanning-tree Trk1 priority 4
spanning-tree Trk2 priority 4
spanning-tree Trk3 priority 4
spanning-tree Trk4 priority 4
spanning-tree Trk5 priority 4
spanning-tree Trk6 priority 4
spanning-tree priority 0 force-version rstp-operation
no tftp server
no autorun
no dhcp config-file-update
no dhcp image-file-update
password manager

CoreSWStack# sh lacp

                           LACP

          LACP      Trunk     Port                LACP
   Port   Enabled   Group     Status    Partner   Status
   ----   -------   -------   -------   -------   -------
   1/43   Active    Trk6      Up        Yes       Success
   1/44   Active    Trk5      Up        Yes       Success
   1/45   Active    Trk4      Up        Yes       Success
   1/46   Active    Trk3      Up        Yes       Success
   1/47   Active    Trk2      Up        Yes       Success
   1/48   Active    Trk1      Up        Yes       Success
   2/43   Active    Trk6      Up        Yes       Success
   2/44   Active    Trk5      Up        Yes       Success
   2/45   Active    Trk4      Up        Yes       Success
   2/46   Active    Trk3      Up        Yes       Success
   2/47   Active    Trk2      Up        Yes       Success
   2/48   Active    Trk1      Up        Yes       Success


CoreSWStack# sh trunk

 Load Balancing Method:  L3-based (default)

  Port   | Name                             Type      | Group Type
  ------ + -------------------------------- --------- + ----- --------
  1/43   |                                  100/1000T | Trk6  LACP
  1/44   |                                  100/1000T | Trk5  LACP
  1/45   |                                  100/1000T | Trk4  LACP
  1/46   |                                  100/1000T | Trk3  LACP
  1/47   |                                  100/1000T | Trk2  LACP
  1/48   |                                  100/1000T | Trk1  LACP
  2/43   |                                  100/1000T | Trk6  LACP
  2/44   |                                  100/1000T | Trk5  LACP
  2/45   |                                  100/1000T | Trk4  LACP
  2/46   |                                  100/1000T | Trk3  LACP
  2/47   |                                  100/1000T | Trk2  LACP
  2/48   |                                  100/1000T | Trk1  LACP

[jw1n5]

Well, it appears the root cause is a battery backup problem. The site has been known to have fluctuations in power that trigger alerts 'On battery power in response to unknown'. We hadn't received one of these alerts in some time, so I checked UPS logs and found the UPS needed some configuration updates for mail relaying. While I was in there, I ran a self-test and this caused both of the Netgear switches to drop. I will be doing another test, off-hours, as well making a point to getting the switches on different battery backups once we sort out the issues with the current one.

In any case, I have some confidence restored in the configuration and the Netgear switches - as much as one can have in such a thing, anyways.

However, if there are any pointers out there or mistakes in the configuration, as is stands, input would be appreciated.

Thanks