Aruba & ProVision-based
1748171 Members
4149 Online
108758 Solutions
New Discussion юеВ

Re: HP Switch stack question

 
Davel1982
Occasional Visitor

HP Switch stack question

Hi

2x 2920 Core switches with 2x HP Edge switches connecting

If you have a stacked pair of switches (so 2x HP Procurve 2920 connected in a ring configuration with stacking cables) - then how should trunks be configured (etherchannels for the non HP switch aware) to access switches?

If I go to the Menu CLI and it lists the ports of both switches, I assume that if I setup a trunk on ports 23 and 24 on switch 1 then I need to setup the same on switch 2.  

- Do I set these up as two trunks with 2 ports from each switch contributing?  (ie - Trunk 1 with ports from Switch 1 ports 21,22 and Switch 2 ports 21,22, Trunk 2 with ports from Switch 1 ports 23,24 and Trunk 2 with ports from Switch 2 ports 23,24
- Or do I set them up as four trunks? (Ie Trunk 1 with ports from Switch 1 ports 21,22, Trunk 2 with ports from Switch 1 ports 23,24, Trunk 3 with ports from Switch 2 ports 21,22, Trunk 4 with ports from Switch 2 ports 23,24)

Hopefully makes sense  - I have tested it with option 1 above and fails over without issue but just wanted to confirm the best practice

Thanks

3 REPLIES 3
parnassus
Honored Contributor

Re: HP Switch stack question

Wait...reset: a Stack is a logical switch so physical ports belonging to Switch 1 and physical ports belonging to Switch 2 are logically managed and seen as part of the new Stack logical entity...let's say you have two separated Switches:

  • Switch 1 Ports [1-24] (24 ports)
  • Switch 2 Ports [1-24] (24 ports)

Once you enable and form the Stack those ports are then seen as a whole:  Switch 1 1/[1-24] (Member/Port) and Switch 2 2/[1-24] (Member/Port)...so the entire Stack will manage ports 1/[1-24] + 2/[1-24]:

  • Stack Ports 1/[1-24] + 2/[1-24] (48 ports)

In other terms:

"For features configured on specific switch ports in a stack, configuration procedures are the same as for standalone switches, but port designations for the ports in the stack are modified. Each port is identified by the stack member ID of its switch followed by a slash and then the port number as shown on the switch"

that's to say that if you need to setup a Port Trunking Group originating from (or terminating to) the Stack you just need to select what physical ports to include in the Trunking Group remembering that you will be limited - in doing so - by the peer end setup (Port Trunks/LAGs should co-terminate between logical switches pairs: in absence of a Virtual Switch - that we call Stack here - then that statement means that Port Trunks/LAGs should co-terminate between physical switches pairs).

If there is a peer access Switch you want to connect to the Stack via aggregated links (Port Trunk/LAG) then you should just define needed number of members ports (number of links)...and then decide how to distribute (if you want to do so) those links from the peer access Switch to the corresponding Port Trunk defined on the Stack...so you have at least two options:

  • terminating on ports belonging to just one member of the stack (if so the Port Trunk Group on the Stack will be created involving only ports of Member 1 or ports of Member 2), as example: int 1/[21-24] lacp active will setup a LACP Port Trunk of 4 physical ports of Member 1 of the Stack...the peer Switch should setup a corresponding Port Trunk or LAG with 4 physical ports of same characteristic (LACP, Speed, Full-Duplex, etc.)...that way the link aggregation originating on the peer Switch will terminate physically on a single physical Switches (which is also a Stack Member) and it will also co-terminate those links on the same logical Switch (the Stack).
  • terminating on ports belonging to both members of the Stack (if so the Port Trunk Group on the Stack will be created involving some ports of Member 1 and some other ports of Member 2), as example: int 1/23 1/24 2/23 2/24 lacp active will setup a LACP Port Trunk of 4 physical ports involving 2 ports of Member 1 and other 2 ports of Member 2, no problem so far...the peer Switch should be configured with a corresponding Port Trunk or LAG with 4 physical ports of same characteristics (LACP, Speed, Full-Duplex, etc.)...that way the link aggregation originating on the peer Switch will terminate physically on two separate physical Switches (both are Stack Members) but it will also - and that is the important part - co-terminate on the same logical Switch (the Stack!).

The important part is: how you want to distribute aggregated links coming from the peer Switch(es)? because the answer to this question will let you configure very easily Port Trunking on Stack side.


I'm not an HPE Employee
Kudos and Accepted Solution banner
Davel1982
Occasional Visitor

Re: HP Switch stack question

Brilliant answer!

If I am just looking at connecting the two edge switches to the logical core stack in a typical hub and spoke configuration then what is the best practice?

I understand both are possible based on the below, I just want to know which is the best in a standard setup?

Many thanks

parnassus
Honored Contributor

Re: HP Switch stack question

Supposing you have just two links per Access Switch to be dedicated/reserved for uplinking purposes to the Stack (and a corresponding total of 2+2=4 ports on the whole Stack)...and based on what I wrote you above...a possible good approach would be to configure one LACP Port Trunk (Trk1) with 2 member links (ports) on each physical Access Switch.

Then configure two LACP Port Trunks (Trk1 and Trk2) on the Stack with 2 member links (ports) each one; my advise is to use one port of Stack Member 1 and one port of the Stack Member 2 as Port Trunk member ports: doing so you gain (a) resiliency against generic port/link failure (thanks to Port Trunking approach between the Stack and the Access Switch), (b) resiliency against any Stack Member failure (since you're gonig to use distributed ports, any Port Trunk will survive the failure of one Stack Member for the traffic going to - or leaving from - devices connected to the Stack member survival), (c) traffic balancing on any Port Trunk (since you will use LACP, especially when traffic shape is many to many).

Just and example:

  • Access Switch 1: Trk1 with member ports 23 and 24
  • Access Switch 2: Trk1 with member ports 23 and 24
  • Stack: Trk1 with member ports 1/23 and 2/23
  • Stack: Trk2 with member ports 1/24 and 2/24
  • Access Switch 1 Trk1 links to Stack Trk1
  • Access Switch 2 Trk1 links to Stack Trk2
  • Links originating from Access Switch 1 Trk1 (23+24) spread across Stack members (Ports 1/23 and 2/23)
  • Links originating from Access Switch 2 Trk1 (23+24) spread across Stack members (Ports 1/24 and 2/24)

Clearly it's important to understand first where your traffic goes to justify such approach (suppose your Servers are all connected to just one member of the Stack and so aren't multi-homed against the Stack...then probably will be better - if most of the internal traffic goes to/from Servers and Clients connected to the Access side - to use Port Trunk ports resident on the same Stack Member in which Servers are connected).


I'm not an HPE Employee
Kudos and Accepted Solution banner