In order for the management VLAN to traverse over your port channel you will need to set the switchport mode to general instead of trunk. On the PowerConnect 62xx series switches, you must use General mode if you want to allow management traffic onto the switch over the PVID. If you use Trunk mode, you will not have the default VLAN on those ports. The ports will only allow tagged traffic.
console(config)# interface port=channel 1
console(config-if)# switchport mode general
console(config-if)# switchport general allowed vlan add 2 tagged
console(config-if)# switchport general pvid 1
As far as any up to date information on the MPIO functionality with your storage you may direct that to the storage group or we could move the Post to the storage forum. Let us know if this something that you desire.
One more thing I forgot, the connections between PS4000 and servers are working, if I disable the NIC that has currently active connections to PS4000 then the other adapter takes over and it's seen on the PS4000 management that now connections come from different IP.
I did all this, but it seems that this did not solve my problem, MPIO is still not working.
I know that the servers are not the problem, because they worked with MPIO with older PC6224's, where I did not use VLAN to separate iSCSI traffic. The old PC6224's had also a LAG set up and all ports where then available for iSCSI. Now that we neede new switches to expand our network I decided to swap 6224's from the SAN to put newer ones there and by the stuff I have learned since my first SAN setup I decided to speratae the iSCSI traffic.
Also one curious thing about the commands You posted, if I look at the running config then there is no console(config-if)# switchport general pvid 1 in there, but when I check thru the web console it show's that ch1 has PVID 1
Look at your mac address table on both switches, you should see ALL the array interfaces (eth0, 1,2, etc. and your host iSCS interfaces i.e., whatever you have wired to both switches) listed.
Telnet into a switch, and try pinging/traceroute from one switch to a iSCSI interface connected to the other switch.
Telnet/SSH into each of your array member(s), use one of the eth IP address, not the group IP
ping "-I "
(that is a –I as in Capital letter “eye”, ensure you use the quotes after the command and at the end of the destIP). Use CTRL-C to quit.
The “source_ETH_IP” is one of the eth interfaces of the member you connected to (eth0, eth1, etc.)
The “dest_IP” is each of the eth interfaces of the other member(s)
Test all combinations, to other members, to host iSCSI interfaces.
To Traceroute:
Telnet/SSH in to the member use one of the ETH interface ip’s not the group IP), then traceroute out of each specific ETH port,
GrpName>support
GrpName(support)>traceroute “-s [ETH port source IP] [destinationIP]”
Also note the quotes after the command and at the end of the destinationIP.
“ETH port Soruce IP” is the member you connected to
The “destinationIP” is the other member test each eth combination (all members eth interfaces, and host iSCSI interfaces).
If you don’t see all the mac address, or any of pings fail, you may need to enable spanning tree on the lag ports so that they can learn the mac address from the other switch. This would be enabled on both sides of the lags, for each interface you configured (19-24)
Tried also swichpoer general allowed vlan add 2 tagged, no joy.
Pinging from the array member just confirms what we already know, that EHT0 doesn't see the traffic from ETH1 because the LAG is not configured correctly.
Regarding the orginal MPIO issue, just to confirm, that you tested (the switches in question), by connecting the hosts and array iSCSI interfaces on only one switch to verify the server connects to a target volume on the array with the number of interfaces you specified with MPIO on the host? Do this for the second switch as well.
Also, are you using the IP address or the .iqn name of the host iSCSI initiator for the Access Control List on the Array? The iqn name of the iSCSI initiator is preferred for MPIO.
With that said, the next step would be to reconfigure the LACP/LAG from scratch again:
Note: it is recommended that you physically disconnect the ports to be aggregated at one of the switches during configuration, until both are configured. It is suggested to do this during a maintenance period if the arrays are in production.
So the standard configuration is as follows:
(config)# interface range ethernet 1/g19-1/g24
(config-if)# channel-group 1 mode auto
For a more detailed configuration try this:
Enter configuration mode
Select all port-channel interfaces
console#interface range port-channel all
To Protect from bringing down a switch or subnet, make sure the LAG is off before configuring
console(config-if)# shutdown
Select the ports that you are going to use in the LAG
console(config-if)# interface range ethernet 1/g19-1/g24
Add those ports to LAG 1, and use the LACP protocol to configure the LAG
console(config-if)# channel-group 1 mode auto
(adds those ports to LAG 1, and use the LACP protocol to configure the LAG)
Select the port-channel interface you just created
console(config-if)# int range port-channel 1
Enable spanning-tree
console(config-if)# no spanning-tree disable
Enable Flow Control, which is required for iSCSI
console(config-if)# flowcontrol on
Keep this config open on the first switch, then open a new telnet and repeat the above on the partner switch and the LAG ports
Then go back to the first switch and with port-channel 1 interface as the active interface, to bring up the LAG.
console(config-if)# no shutdown
Do the same command with port-channel 1 interface as the active interface, on the second switch to bring up the LAG
console(config-if)# no shutdown
console(config-if)#exit
I would keep the swtichport mode trunk as you had in the original config:
show interfaces port-channel [port-channel number]
Alternetelly you can try to set the hashing mode to the default (3) to see if the behavior is the same
console(config)#interface port-channel l
console(config-if-ch1)#no hashing-mode
Beyond this, if you are still having issues (and you confirmed both switches work independently for MPIO), I would suggest that you contact the PowerConnect support team to ensure that the LACP/LAG is configured properly.
If I disable currently active NIC the system fails over to 2nd NIC and communication with EQL restores quickly, but it won't connect to EQL using MPIO (seeing only one of the NICs on the EQL and on the HIT)
DELL-Willy M
802 Posts
1717
0
Posted November 5th, 2012 09:00
In order for the management VLAN to traverse over your port channel you will need to set the switchport mode to general instead of trunk. On the PowerConnect 62xx series switches, you must use General mode if you want to allow management traffic onto the switch over the PVID. If you use Trunk mode, you will not have the default VLAN on those ports. The ports will only allow tagged traffic.
console(config)# interface port=channel 1
console(config-if)# switchport mode general
console(config-if)# switchport general allowed vlan add 2 tagged
console(config-if)# switchport general pvid 1
As far as any up to date information on the MPIO functionality with your storage you may direct that to the storage group or we could move the Post to the storage forum. Let us know if this something that you desire.