I agree that the statement that you quoted (Configured with an IP address and netmask (at least one network interface on a member must be on the same subnet as the group IP address), can be a bit confusing. This statement is for the initial setup of the group and/or member in the group. It merely states that each member must have at least one eth interface configured (on the same subnet as the group IP) as the minimum network configuration which is considered a single-point-of-failure configuration.
So, in order to provide high availability, you should configure additional interfaces, but they must be on the same subnet as the group IP (except for a dedicated out-of-band management interface). This is what the second quote that you mentioned is saying (In a multi-subnet group, each configured network interface should have access to the subnet on which the group IP address resides).
The Group IP is a virtual address, so when the iSCSI initiator asks to login (directed to the group IP), the connection request is redirected by the firmware to a physical eth port address. The only way such a configuration can be supported is with full routing between the subnets. However, this seems to defeat the purpose of having a separate iSCSI network. Also, with only one eth interface on the "main" network there's no redundancy.
I think the confusion lies with the phrasing "access to the subnet on which the group IP address resides". Does this mean that the group IP address must be reachable by the group members using IP, or that the interfaces must be in the same Ethernet broadcast domain?
Is it possible to deploy a group where the group IP address and some or all member interfaces are in different Ethernet broadcast domains, but reachable among each other using IP, i.e. without bridging?
Followup question: how does the VIP mechanism work? Is it like VRRP/HSRP, where a member will reply with its own MAC address to an ARP request for the VIP?
The recommendations is to construct a “flat” subnet (i.e., all group member(s) eth interfaces are in the same subnet (broadcast domain), and reachable via IP). Using bridging or routing creates unnecessary latency, and could impact performance and adversly effect the mesh communication between members . The configuration guide (section: 4.2 General Requirements and Recommendations), discusses this in greater detail. (en.community.dell.com/.../2639.equallogic-configuration-guide.aspx)
Q: “Is it possible to deploy a group where the group IP address and some or all member interfaces are in different Ethernet broadcast domains, but reachable among each other using IP, i.e. without bridging?”
A: Not that I am aware of.
Q: "Followup question: how does the VIP mechanism work? Is it like VRRP/HSRP, where a member will reply with its own MAC address to an ARP request for the VIP?"
A: We use the iSCSI spec’s which is ARP redirection.
For some background: the switching infrastructure we use does IP routing table lookups at wire speed so there is no performance impact, and the plan is to deploy an ECMP topology that precludes the use of broadcast. Looks like we will have to think about a workaround...
Joe S586
7 Technologist
•
729 Posts
0
October 3rd, 2012 06:00
I agree that the statement that you quoted (Configured with an IP address and netmask (at least one network interface on a member must be on the same subnet as the group IP address), can be a bit confusing. This statement is for the initial setup of the group and/or member in the group. It merely states that each member must have at least one eth interface configured (on the same subnet as the group IP) as the minimum network configuration which is considered a single-point-of-failure configuration.
So, in order to provide high availability, you should configure additional interfaces, but they must be on the same subnet as the group IP (except for a dedicated out-of-band management interface). This is what the second quote that you mentioned is saying (In a multi-subnet group, each configured network interface should have access to the subnet on which the group IP address resides).
The Group IP is a virtual address, so when the iSCSI initiator asks to login (directed to the group IP), the connection request is redirected by the firmware to a physical eth port address. The only way such a configuration can be supported is with full routing between the subnets. However, this seems to defeat the purpose of having a separate iSCSI network. Also, with only one eth interface on the "main" network there's no redundancy.
-joe
tsmo
2 Posts
0
October 3rd, 2012 08:00
I think the confusion lies with the phrasing "access to the subnet on which the group IP address resides". Does this mean that the group IP address must be reachable by the group members using IP, or that the interfaces must be in the same Ethernet broadcast domain?
Is it possible to deploy a group where the group IP address and some or all member interfaces are in different Ethernet broadcast domains, but reachable among each other using IP, i.e. without bridging?
Followup question: how does the VIP mechanism work? Is it like VRRP/HSRP, where a member will reply with its own MAC address to an ARP request for the VIP?
Joe S586
7 Technologist
•
729 Posts
0
October 3rd, 2012 09:00
The recommendations is to construct a “flat” subnet (i.e., all group member(s) eth interfaces are in the same subnet (broadcast domain), and reachable via IP). Using bridging or routing creates unnecessary latency, and could impact performance and adversly effect the mesh communication between members . The configuration guide (section: 4.2 General Requirements and Recommendations), discusses this in greater detail. (en.community.dell.com/.../2639.equallogic-configuration-guide.aspx)
Also see the Rapid Configuration Portal: en.community.dell.com/.../3615.rapid-equallogic-configuration-portal-by-sis.aspx
Q: “Is it possible to deploy a group where the group IP address and some or all member interfaces are in different Ethernet broadcast domains, but reachable among each other using IP, i.e. without bridging?”
A: Not that I am aware of.
Q: "Followup question: how does the VIP mechanism work? Is it like VRRP/HSRP, where a member will reply with its own MAC address to an ARP request for the VIP?"
A: We use the iSCSI spec’s which is ARP redirection.
-joe
tsmo
2 Posts
0
October 4th, 2012 07:00
Thanks for the answer Joe!
For some background: the switching infrastructure we use does IP routing table lookups at wire speed so there is no performance impact, and the plan is to deploy an ECMP topology that precludes the use of broadcast. Looks like we will have to think about a workaround...