MSTP Traffic Isolation - Small Business

[JulianBlu]

Hi to all,

I would like to implement traffic isolation using MSTP in a very small installation, with two Procurve 2530 switches called swA and swB plus one RSTP-only switch for clients.

In the attached image, ports 19-22 on both swA and swB will be dedicated to iSCSI traffic VLAN20, first three untagged and port 22 tagged.

The two 2530s are also connected with a static non-protocol trunk which should carry all other traffic.

I would like that iSCSI traffic between swA and swB use only port 22, by putting VLAN 20 in MSTP Instance 1.

With the current configuration (see below), port 22 on swB goes in blocking state and VLAN 20 traffic does not pass between switches.

Q: Are there one or more errors in the config or is not possible to implement this design with MSTP?

Switch A

hostname "swA"
trunk 1-2 Trk1 trunk
vlan 1
name "DEFAULT_VLAN"
no untagged 19-22
untagged 3-18,23-28,Trk1
ip address 192.168.2.1 255.255.255.0
exit
vlan 20
name "iscsi"
untagged 19-21
tagged 22
no ip address
exit
spanning-tree
#following line is aggregated
spanning-tree 3-21 admin-edge-port
spanning-tree Trk1 priority 4
spanning-tree config-name "myconfig"
spanning-tree config-revision 1
spanning-tree instance 1 vlan 20
spanning-tree instance 1 22 priority 0
spanning-tree instance 1 Trk1 priority 4
spanning-tree priority 0

Switch B

hostname "swB"
trunk 1-2 Trk1 trunk
vlan 1
name "DEFAULT_VLAN"
no untagged 19-22
untagged 3-18,23-28,Trk1
ip address 192.168.2.2 255.255.255.0
exit
vlan 20
name "iscsi"
untagged 19-21
tagged 22
no ip address
exit
spanning-tree
#following line is aggregated
spanning-tree 3-21 admin-edge-port
spanning-tree Trk1 priority 4
spanning-tree config-name "myconfig"
spanning-tree config-revision 1
spanning-tree instance 1 vlan 20
spanning-tree instance 1 22 priority 1
spanning-tree priority 1

[16again]

You try changing the spanning tree logic by assigning different priority to Trk port and Port22
My guess is that priority is only used as tie-breaker on ports with equal cost. But costs aren't equal to begin with !
Trk has is bundled interface having higher bandwidth and lower STP cost.

So start playing around with interface cost,  or turn the iSCSI link also in a trunk

[Michael Patmon]

Hello.  Trunk or individual port, if they are the same link-speed, have the same path-cost.  The priority is used as a tie breaker.  When you configure a trunk the priority is lowered so as to prefer it over a single link of the same speed.

Assuming SwitchA is the root for instance 1 and the link-speeds for Trk1 and port 22 are the same your config looks correct.  SwitchB should prefer port 22 because it has a lower priority than Trk1.  Currently you have forced SwitchA as the root for the CST instance by setting the priority to 0.  Instance 1 will elect based on switch MAC address.

Can you check the output of "show span instance 1"?  Also, "show span mst-config" just to make sure the digest matches on both switches.  That looks fine based on the config.  If priority isn't working as expected you can lower the path-cost of port 22 in instance 1 to something lower than Trk1.  That should definitely force the path to port 22.

[16again]

Michael Patmon wrote: "Trunk or individual port, if they are the same link-speed, have the same path-cost."

But trunk has multiple links, and uses aggregated link-speed for cost calculation.

http://www.hojmark.net/stp-port-cost.html

[Vince-Whirlwind · Accepted solution]

I must be missing something because I don't understand why priority is relevant - it seems to me the intention is to have *two* inter-switch links up and running simultaneously: one link with VLAN1, and another with VLAN20.

(Personally, I would just aggregate all inter-switch links together and put all VLANs on the trunk).

Currently 22 is blocked because STP detects a loop.

To get TRK1 and port 22 unblocked at the same time, you should put VLAN1 in a new MSTP instance (say, instance 2).

[16again]

Vince-Whirlwind wrote: "it seems to me the intention is to have *two* inter-switch links up and running simultaneously: one link with VLAN1, and another with VLAN20"
That's only half of TopicStarters aim.  He also wants redundancy:  If the VLAN20 link fails, VLAN20 falls back to connection using the VLAN1 link.

Vince-Whirlwind wrote: "Personally, I would just aggregate all inter-switch links together and put all VLANs on the trunk"
All traffic from a single traffic stream (MAC1<->MAC2  or IP1<->IP2) will only use a single link from the trunk.  A heavy VLAN1 data transfer might end up on the same link as it's iSCSI  VLAN20 disk traffic, effectively halving the speed.

There are already 2 MST instances, default all VLANs are in instance 0,  TS created instance 1 for vlan20

[JulianBlu]

Thanks to everyone, especially Vince-Whirlwind and 16again.

Yes, I want BOTH Inter Switch Links (ISL) forwarding at the same time, so that iSCSI traffic never use the same links as other vlans.

I don't need that iSCSI traffic does failover to Trk1. I will change the iSCSI-VLAN20 link into a 2-port trunk too (Trk2), so the switch will create similar automatic priority rules for both trunks.

The thing I don't understand is why MSTP blocks the ISL for VLAN20 which is defined in its own Instance.

Maybe the IST instance includes all ISL and there is no way to make this scenario work ?

Do you think that this Cisco docs applies to Procurve too ?
IST Instance is Active on All Ports, Whether Trunk or Acces

[JulianBlu]

I've had the time to implement Cisco's solution: "avoid mapping VLANs to the IST instance", because IST BPDU travel on all inter-switch links and block the one I need.

That's the explanation behind Vince-Whirlwind suggestion:
"To get TRK1 and port 22 unblocked at the same time, you should put VLAN1 in a new MSTP instance (say, instance 2)."

I've created 2 MSTP Instance, the first instance including all VLANs, the second instance with only VLAN for iSCSI.
The output of "show spanning-tree" now shows no vlan mapped to the Internal Spanning Tree:
IST Mapped VLANs : <BLANK!>

Each VLAN has its "own" aggregation trunk (2 links, non-protocol), so that iSCSI (RED) traffic is confined in a portion of swA and swB.

The configuration now works as intended, and is shown in the attached image.

Thanks to everyone for putting me onto the right track.