It's unclear the ports used (interface 50 of both Switches) to connect to your Meraki...in any case using trunk 50 trk1 trunk is incorrect...are you sure you want to aggregate just one port (50!) into a logical port (trk1) with non protocol (trunk trunking mode <-- HP ProCurve jargon, not Cisco here!) and then you apply tagged memberships (and untagged membership) to some VLANs for that logical port? I doubt.
If the topology is:
- SW01 Interface 50 to Meraki Interface X
- SW02 Interface 50 to Meraki Interface Y
then you should review your Switch configurations for both interfaces 50.
I'm not an HPE Employee
Cheers,
from show lldp - executed on SW01 - what I understand is that:
- SW01 interface 35 <---> interface 8 SW04 (J9029A HP ProCurve 1800)
- SW01 interface 47 <---> interface 50 SW02
- SW01 interface 48 <---> LAN Meraki Firewall
- SW01 interface 50 <---> interface 48 SW03
so, in my opinion, you have all (and only) single link uplinks interconnecting SW01 to SW02, SW03, SW04 and the Meraki Firewall. No aggregated links here (so no Port Trunking, trunks in HP jargon, at all).
You just need to set each interface of an uplink's pair to be a tagged member of each VLAN you need to transport between those peers (Switch to Switch or Switch to Meraki). Access ports remain untagged member of desired VLAN.
If the Meraki is responsible (and it is from what I saw) of IP Routing and Access between VLANs...permitting or denying inter-VLAN traffic...then, as example, the interface 48 it is already a tagged member of those VLANs:
- VLAN 100
- VLAN 90
- VLAN 80
- VLAN 60
- VLAN 20
- VLAN 1 (that's somewhat strange because, generally, an uplink interface would be leaved an untagged member of VLAN 1).
It's clear that if you need to transport (to permit) those VLANs to other downlinked switches (SW02, SW03 and so on) then on each downlink you should ensure that you use the same tagging/untagging schema applied on both interlink ends. So a first check is to understand if that's the case (SW01 47 <--> 50 SW02 and SW01 50 <--> 48 SW03, eventually SW01 35 <--> 8 SW04).
With regards to Spanning Tree I would set spanning-tree priority 0 (highest = root of Spanning Tree) on the topology center (SW01) and then an higher value - as example 8 (default) - on remaining Switches. I would also try to understand if you can use RSTP (Rapid STP) instead of just STP.
Given that, the Meraki is your core point, responsible for inter-VLANs routing/access.
I'm not an HPE Employee
First: interfacev 13 on SW02.
What is connected to that interface? is it a Client aware or not aware of VLAN Tagging (IEEE 802.1Q)? I ask that because, generally, an edge device is unaware of the fact its traffic will be leave the switch tagged...so seeing that you untagged that port on VLAN 20 will make me think that, correctly, on that client NIC port there isn't any tagging reference.
I'm not an HPE Employee
With regard to MDI mode the show interfaces brief command you used shows the MDI mode each port is currently using.
Try to (a) check the quality of cabling (straight is OK for both edge devices and also for uplinks since the usage of Auto-MDI mode) and try (b) on both switches to change the MDI mode setting for investigated ports to Auto (auto-mdix)...with the command interface X mdix-mode auto-mdix where X is the interface number (which should already be the default -> check with show interfaces config if it is before doing the change)...consider that in the case of ports configured for auto-mdix, the MDI mode appears as either MDI or MDIX, depending upon which option the considered port has negotiated with the device on the other end of the link.
With regard to SW01 port 35 and the Unmanaged Switch I suspect there is something related to untagged VLAN transported on that downlink (SW01 Port 35 is, correctly, only an untagged member of VLAN 20 which is not the Default VLAN 1...the Unmanaged Switch doesn't "understand" VLANs...I like this point of view "...simply put the unmanaged switch would not be able to know what VLANs it would or would not send over the link that might or might not be a trunk (this is CISCO terminology...in HP jargon such trunk is a port that has at least one tagged VLAN). Neither will it has knowledge of what VLAN is the native VLAN (the only one on the trunk that is not tagged <- so the untagged). So what would happen if one put it in on a trunk port? well in my mind either the native vlan would work and the switch would throw away all the others, or the unmanaged switch will drop all. but we do not know which since there are many different unmanaged switches and at least some of them would behave differently." so...even if you are passing VLAN 20 untagged to the Unmanaged Switch...this can't be sufficient to let it to work correctly...solution: use a Managed Switch (as all others are).
I'm not an HPE Employee