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"
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"