Web and Unmanaged
1748265 Members
4025 Online
108760 Solutions
New Discussion юеВ

Re: HP 1800-24G Trunking, vLANs and iSCSI

 
Stuart Smith_4
Occasional Advisor

HP 1800-24G Trunking, vLANs and iSCSI

Sorry if this is re-inventing a simple axle-based circular object...

We have a client running a small iSCSI setup on a single 1800-24G. To make it a little bit more resilient, a second 1800-24G will be added to the configuration using a trunk of 2 (or maybe 4) ports. As I understand it the current config is pretty simple in that all the iSCSI host/target ports are in one VLAN with the MGT port in another. Using the GBic is not (currently) an option.

I believe an attempt was made at this in the past by someone else and when they created the trunk, it seemingly created some sort of broadcast storm taking out the first live switch (and thus the iSCSI connected servers)!

Now obviously, having been 'volunteered' to 'sort this out' I'd rather like to avoid emulating the previous lamb but understand that without a copy of the current configuration and the somewhat hazy secondhand information, thats not exactly straightforward!

The client has informed me that there has been one change since that first attempt - flow control was on for all ports but is now switched off for all ports (as it was causing intermittent iSCSI performance dropouts).

If anyone can either suggest:

a) why/how the trunk (could) cause the original problem

or

b) a suggested config for the trunk,vlans etc that wont cause a similar issue! :)

..then it would be much appreciated
..as I am due on site in a few days to add a second iSCSI SAN controller with half of its (4) ports on switch-A and half to switch-B; plus the same for the original iSCSI SAN controller too.. ?

Cheers,
"larry the lamb"
7 REPLIES 7
gesadmin
Advisor

Re: HP 1800-24G Trunking, vLANs and iSCSI

You need to be sure that you have the trunk configured on both switches before you plug the cables. I always employ spanning-tree on my switches so if it's not turned on, then turn it on. I do it just as a CYA. Of course if you do enable spanning-tree be sure to configure the ports connecting the iSCSI hosts as well as any other PCs as edge ports so as to not have any spanning-tree convergence issues if/when the toplogy changes. As for the flow control, you need to be sure that the storage device supports flow control before you turn it on. Good luck.
DaGuru
Trusted Contributor

Re: HP 1800-24G Trunking, vLANs and iSCSI

The 1800 doesn't support Spanning Tree itself, however, with a newer firmware it will bridge the BPDUs, but that won't help much in a single switch environment.

There isn't enough info here to get a good enough idea of your overall design is to offer much advice. A network diagram would be helpful along with a more detailed explanation of what you├в re trying to do.
---------------------------------------------
I work for HP, but my posts and replies are my own.
Stuart Smith_4
Occasional Advisor

Re: HP 1800-24G Trunking, vLANs and iSCSI

Hi guys thanks for the replies. I'll bear in mind the comments about leaving cables unplugged when initially creating the trunk!

Also attached is a quick Rolf Harris sketch of proposed config for clarity :)
Stuart Smith_4
Occasional Advisor

Re: HP 1800-24G Trunking, vLANs and iSCSI

Just occurred to me - the port to port connections in the diagram are not significant, they appear that way for clarity of viewing :)
DaGuru
Trusted Contributor

Re: HP 1800-24G Trunking, vLANs and iSCSI

The switch-to-switch trunk can be done with either LACP or Trunk mode on these switches. Because your planning on splitting the trunks between switches take a close look at the type of trunk your created on the server and iSCSI Array side. These switches don't support SMLT (Split Multi-Link Trunking), which is a proprietary extension to the IEEE 802.3ad standard. So, the connection from the server really isn't a trunk or else, from this drawing depending on how the trunks were configured opposite the switches, I can see why everything came down in a broadcast storm.

For the server, you'll want to create the "team" so that you have one primary and one failover link, not a trunk that would act as a single logical link.

For the iSCSI Arrays, you could create separate logical links for the connections that go to each switch, but then one of those connections would need to be primary with the other one configured as a failover link.

The reason for this is that you cannot spread an 802.3ad link across switches. If the switches supported spanning tree, you'd need to make sure your server and array configurations supported this type of operation, otherwise it isn't necessary to even consider.

What make/model of server and arrays are these?
---------------------------------------------
I work for HP, but my posts and replies are my own.
VirtualDisaster
New Member

Re: HP 1800-24G Trunking, vLANs and iSCSI

Howdy,
I'm actually attempting to do the same thing but its for my esx environment. If you have found a solution please post it.

(My Issue for those interested)
3 IBM x3550 Servers
2 Procurve 1800-24 Switches
1 IBM DS3300 SAN

I'm completely confused by vlans and trunking but know that I need them in my environment. Google provides not much and the product manuals aren't very detailed, especially for a new user. Anyways hope to hear the solution.
Stuart Smith_4
Occasional Advisor

Re: HP 1800-24G Trunking, vLANs and iSCSI

Sorry for the delay in replying but I was onsite end of last week!

FYI, the arrays in question are Infortrend A16-G2130-4 (single controller(!), 4 x iSCSI channels). The intel servers are Dell 1900/1950's using either QLA405xC or MS iSCSI via internal NIC/TOE.

The connections between server and switch/array and switch are NOT grouped/trunked at this stage.

The only trunk being considered is/was for intra-switch bandwidth/failover.
-------------------------------------
To further confuse things? (sorry!)

What is/was strange is that even without any trunking enabled i.e. just a single cable connection between the two 1800s - inexplicable connectivity issues were occuring.

The only thing that I can imagine causing this are 'strange/undocumented' settings on their 'core' L3 switches. There is a connection to one of these via port 24 on the original switch #1 ..port 24 is in MGMT vLAN only.

What doesnt help here is the fact the customer doesnt know how/what is set on these 'core' switches - they're not HP's they are NetGear PROsafes I believe :(

Thus, unfortunately, as it stands at the moment the customer has taken the decision to keep the switches separate as (at present anyway) the SAN's are in effect islands :/

Some points dished out for assistance so far.. thanx folks :)