HP A5800 RSTP and Vlans help

[jblackburn2]

I have two HPE A5800 core switches, core 1 and core 2. RSTP is enabled on both core switches and on all my edge switches which are mainly HP2350-48G. All my edge switches are connected to both core switches where possible which is basically most of them. I inherited the site and at the moment the lan is flat with no vlans, I want to change this for obvious reasons.
My question is around vlans and how to design the vlan layout with this topology using best practice.
Should I be replicating the same vlans on each core switch or should each core switch have different vlans? I don’t quite understand how a device passing through core1 which is then diverted to core 2 works.
My core switches are at the top of the topology linked with a bridge and are being used for the routing.

Any advise or reading material would be much appreciated

[parnassus]

If your two core switches are just uplinked together via a simple (or aggregated) link (PVID 1 I suppose, given your description)...and RSTP is deployed correctly then Core 1 and Core 2 have different RSTP Priorities...so one is the STP Root...that's a thing to consider.

If RSTP is deployed also on Access Switches and most of them are connected to both Core Switches concurrently (one uplink to Core 1 and one other uplink to Core 2)...then one uplink is (or should be) blocked by STP...that's correct and by design.

A question then rise: who is responsible for IP routing? ...only you have the answer.

An alternative approach would be thinking about a redesign: implement IRF with your two Core Switches, they will became a single logical entity. Connect via Port Trunking (Aggregated Links) - using LACP wherever possible - each Aruba 2530 so one originating LACP member link will terminate on IRF 1 and the other one will terminate on IRF 2 (STP will not block one of these links...since each Aruba will see one logical Switch)...linking your Access layer that way enhance link resiliency and would also enhance (under some traffic conditions) the available bandwidth between edge/core.

Defining and permitting VLANs will just a matter of deciding how many to implement centrally on IRF and where do you need to transport (permit) them down to the edge...since the IP routing will happen on the IRF acting as a real resilient core (the IRF, in any case, should be configured with RSTP Priority 0, the highest).

[jblackburn2]

IRF is actually my ultimate goal but I was looking for a quick win in its current state without a redesign.

I think my issue is the understanding of where the routing happens :) Core 1 and core 2 are aggregate linked with core 1 set as the root. stp instance on core 1 is instance 0 priority 4096, core 2 is instance 0 priority 8192. Core 1 would always be the root unless its off or unless i setup instances and assigned them to vlans.

If vlan 10 is say 10.1.100.1 /24 I would have to have this vlan set on both core switches with the routing set on both. So that if the best route through core 1 wasn't available it would go through core 2 without an issue? Effectively a mirror of each other?

I would achieve failover (if core 1 or core 2 failed) but I wouldn't be getting the most effective setup in terms of traffic balancing unless I wired it that way?

[parnassus]

If IRF is out of radar (IRF would be not only the best option but also the fastest way to reach a very stable and resilient configuration for your routing core...and it will avoid you to look for VRRP)...you have basically two main paths in front of you:

(a) deploying VRRP (routing feature resiliency and this will require you to adjust your actual setup as IRF will require).
(b) not deploying VRRP (and basically staying with the scenario you have now with some necessary adjustements).

[parnassus]

VLAN (SVI) and IP Routing are generally something that is deployed on (Standalone/Clustered) Core: so just one Switch which is responsible for IP Routing (no resiliency if no IRF or if no VRRP is considered)...and VLANs definitions with their IP addresses are defined on that Core position...that way distribution and access requires just uplinks tagging VLANs you need to distribute (and, generally, untagging ports devoted to access device). The Core will be responsible for intra-VLANs routing as well as for static routes (not to mention last resort route to Gateway)...the point is having two such identical Switch is the perfect scenario to develop VRRP or IRF.

[jblackburn2]

Thanks Parnassus

Very useful information. I will carry on with adding in vlans as it will help me very short term. I'm unable to drop a switch until July but I will look at configuring IRF when i can do so in July.

Do you know if I can replicate my intented plans in anyway in a virtual enviroment. i can only find a cisco based program for this and not a HP one.

[parnassus]

---

@jblackburn2 wrote: Do you know if I can replicate my intented plans in anyway in a virtual enviroment. i can only find a cisco based program for this and not a HP one.

---

Read this long thread...to get an idea of the discussed H3C Cloud Lab simulation tool (on Google there are some good blogs about how to setup and use it correctly).

To download the H3C Cloud Lab (valid for Comware 7 based devices) use this link.

[jblackburn2]

Fantastic. thanks again