- Integrated Systems
- About Us
- Integrated Systems
- About Us
01-21-2019 08:00 AM - edited 01-22-2019 12:18 AM
Migration from MSTP to RSTP with a Transport VLAN between two Routing Switches
I inherited a quite large network which, not only from the pure Spanning Tree standpoint, I discovered a little bit problematic to manage (it was basically unmanaged and now I want to fix what I consider a mess).
bird's-eye view network topology:
Three HP ProCurve IP routing switches - (A), (B) and (C) - are the actual fundation of a quite large plant's network: network topology is a star (no physical loops) where (A) is the main center, (B) and (C) are two vertexes of this star where sub-stars link various access switches.
There are about one hundred of Access Switches involved (all HP/Aruba).
- (A) and (B) are used to manage networks on offices and warehouses
- (C) is used to manage networks on production lines
- (B) and (C) are both connected to (A) via Trunks (aggregated ports)
- (A) is connected to Firewall to reach external nets (Internet/Intranets)
- (A) has a Default Route to Firewall
- (B) instead of having IP Routing enabled should work with just (A) as Default Gateway on one of its transported VLANs
- (A), (B) and (C) have IP Routing enabled
Figuratively (A) and (B) are on the "West" side of an island divided internally by a river, (A) links the island to mainland (Internet) via Firewall, (C) is on the "East" side of the island and it is isolated, only a bridge (a "transport" VLAN) exists between (A) and (C):
- (A) Transport VLAN "P2P" has IP Address 192.168.244.253 (Subnet /29 255.255.255.248)
- (C) Transport VLAN "P2P" has IP Address 192.168.244.254 (Subnet /29 255.255.255.248)
So only (A) and (C) are member of a "transport" VLAN (/29), the aggregated trunk between them - on each side - is properly tagged on this "transport" Peer-to-Peer VLAN.
Additionally (A) and (C) have various static routes (as necessary): (A) points to gateway (C) routing switch to reach VLANs Subnets hidden behind it (VLANs managed and defined only in routing switch (C)) and (C) does the same to reach some of VLANs defined on routing switch (A).
Now the bad part:
- (A) is set with STP on MSTP operation mode and MSTP configuration name: 0016b97c4800 Priority 32768 (so 8)
- (B) is set with STP on MSTP operation mode and MSTP configuration name: 2c59e55b2100 Priority 32768 (so 8)
- (C) is set with STP on MSTP operation mdoe and MSTP configuration name: 6c3be566a000 Priority 4096 (so 1)
From what I know different MSTP Configuration Names (if not manually set they refers to Switch MAC Addresses) mean MSTP Different Regions (https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-c03080657) so from what I understood this make MSTP simply not configured properly.
- (C) has Priority 4096 (1), RSTP enabled access switches connected to (A) and (B) see switch (C) as STP Root and all path costs to root I saw point to (C).
I've few questions about this situation, the very first is:
- if I modify STP operation mode from MSTP to RSTP on (A) and (B) forcing Priority 0 on (B) [*], provided that I already do that on all connected access Switches, what will happen?
- How should I configure (R)STP on (A), (B) and eventually (C) considering that (A) and (C) are sharing a common "transport" VLAN and they routes each others?
- From the spanning tree standpoint is there a way to keep Networks behind (C) separated [**]?
If questions above are practically or theoretically incorrects what will be the best approach to fix/manage STP considering I'm slowly moving all Access switches to (R)STP?
[*] the long term idea is to transfer all the routing functions from (A) to (B) because (A) is going to be dismissed, the mid term idea is to just fix the STP mess keeping (A) and assigning it the (R)STP Root role.
[**] that's because we have mainly full control on networks managed by (A) and (B), less on networks managed by (C) (where move, add and changes are in charge of other teams and happens quite frequently).
Edit: added STP Priorities of (A), (B) and (C).
01-31-2019 04:14 AM
Re: Migration from MSTP to RSTP with a Transport VLAN between two Routing Switches
Maybe I can reduce the above requests to just one: how to separate a single Spanning Tree into two Spanning Tree regions each one with its STP Root (let's say two separate RSTP regions to be exact) when L3 Switches at regions bounduaries are logically interconnected with a Transit VLAN AND they are physically connected using a LACP Trunk?
I thought about BPDU Filtering but I think it can't be used on Trunks...isn't it?