SOLVED
As I understood it you need to interconnect two Aruba 2920 24 ports Switches together and distribute on those Switches your VLANs (no routing between VLANs)...and, between those Switches, you're planning a total of four Trunks (BAGGs), each BAGG will have two member interfaces...It seems (as far I can see...not on the configuration, I suspect) you want to keep separated each VLAN traffic also at "Trunk level" reserving each Trunk for its specific VLAN traffic...Isn't it?
Just a question: why don't you define and use just a single BAGG (exactly a Port Trunk configured to use LACP) by aggregating *up to* (not more) 8 interfaces on each Switch (to resemble your configuration, let's say, ports 2, 4, 10, 12, 16, 18, 23 and 24 on Switch 1 and ports 1, 3, 9, 11, 15, 17, 23 and 24 on Switch 2...even if - If I were you - I would try to use less consecutive ports - as example just four ports: 21, 22, 23 and 24 - on each unit) and then permits only required VLANs (1, 10 and 20) to traverse that one single BAGG?
Probably having eight 1 Gbps aggregated interfaces would be enough or would be really oversizing with respect to have respectively four Trunks with two member interfaces each one (...maybe you can obtain same performances just using a BAGG with only four aggregated ports with the benefit of saving four ports you can use for your edge devices...)...but I can't judge since I don't know what is your real inter-Switch traffic requirements per VLAN and I'm just guessing what you want to achieve.
Something like:
# interface Bridge-Aggregation1 port link-type trunk port trunk permit vlan 1 10 20 link-aggregation mode dynamic #
where the Bridge-Aggregation1 (BAGG) has these interfaces as its members:
# interface GigabitEthernet1/0/21 port link-type trunk port trunk permit vlan 1 10 20 port link-aggregation group 1 # interface GigabitEthernet1/0/22 port link-type trunk port trunk permit vlan 1 10 20 port link-aggregation group 1 #
interface GigabitEthernet1/0/23
port link-type trunk
port trunk permit vlan 1 10 20
port link-aggregation group 1
#
interface GigabitEthernet1/0/24
port link-type trunk
port trunk permit vlan 1 10 20
port link-aggregation group 1
#
Probably you should avoid to configure IP Addressing on each VLAN...this to disable automatic IP Routing between so configured VLANs.
I think that Spanning Tree then will "automagically" managed by that BAGG so no further configuration on that side is required (at least at basic level).
I'm not an HPE Employee
OK, in that Reference Architecture (which refers to Switch models IMHO not comparable with Aruba 2920, at least in terms of number of features, raw performances and potential connectivity capabilities) HP used that connection schema because they haven't a chance to consider something like IRF, VSF or Backplane Stacking using those Switches (if both your units are very near the Aruba 2920 can be deployed with a Chain/Ring backplane stacking topology using specific Stacking Modules - you need a pair for two Switches, and Stacking Cables 0.5, 1 or 3 meters long - you need a pair to implement Ring Topology)...technologies that semplified (and semplify) actual possible setups.
Look for Aruba 2920 Switch Series stacking technical white paper or look for discussion yet developed under ProVision/ProCurve category.
Consider that two Aruba 2920 in Ring backplane Stack can reach 40 Gbps (Full-Duplex) inter-Switch traffic throughput...and are seen as a single (logical) virtual Switch...so, in the end, you have to worry about your VLANs (an BAGGs) definitions as you were working on a single big (non modular) virtual Switch with 96 ports totally available to edge/server connections.
Then, probably, you can go down the SFP+/10GbE route when you consider Switch/Servers (Node A, B and Quorum+Storage Servers) connections...a thing I would consider since the 10G technology is now more common (and less expensive) than in the past.
I'm not an HPE Employee
ioka wrote: HP 2920 model is replacement for 2910, isn't it? (I have two Aruba 2920-24G Switches)
Yes, the Aruba 2920 Switch Series can be considered - somewhat - a modern "replacement" for the legacy HPE 2910al Switch Series.
ioka wrote: I know about Stacking Modules, but did not want to do ring topology because in this case VLAN management would be from OS side, I wanted to do it more hardware way (switches side) as possible, i believe it is more secure))
What do you mean with "...from OS side" when you're referring to VLANs management in stacked Aruba 2920 with Ring Topology?
IMHO, in both cases VLAN management does happen - and it's Switch-defined - on ports (logical or physical) so where is the difference?
The main difference I see - maybe I'm wrong - is that (a) with the backplane stacked ring topology you achieve resiliency and higher bandwith (so higher throughput) between any port to any port from any stack member to any stack member...overcoming the embedded limitations of that reference design where instead (b) each physical port trunk setup between the 2910al switches is then physically limited (in terms of its specific throughput) by the performances of its aggregated port members; in both cases you then have to configure/manage VLANs (on ports and on LAGs) on the Switch/Switches...but in case (b) you "feel" that each VLAN (which is a logical entity) is somewhat hardware binded to its specific physical connection.
I'm not an HPE Employee
Well, I wrote something like...not exactly like: I know that ProVision and Comware based Switches use different synatxes (and so commands) to perform basically the same operations on common features...setting up a basica Port Trunking is the perfect example!
I'm not an HPE Employee