Hi
I understand that this topic has been discussed before (multiple times). Since I've not read all of the posts, I'll now throw in my take on the situation and why I think that there are scenarios where it makes sense.
In my case, as in many others I guess, and as for all the enterprise SANs I've seen so far, there is a dedicated management interface where all the Webinterface and SSH type stuff is going on. That interface is also being used for any communcation of the SAN/NAS to the rest of the world. There's your answer to the question which interface you'll use for any outgoing traffic. Of course you can create a bond and whatnot if you need redundancy for that.
As for stuff like iSCSI, multiple IPs on the same subnet are perfectly viable for IO path redundancy where the initiator uses a round robin path selection policy to choose from the available paths. There is absolutely no reason why these iSCSI interfaces can't be on the same subnet. There are configs where you have two fabrics and therefore two separated subnets but you also can put all the initiator NICs and target NICs on the same subnet while still keeping physical redundancy at the network switch level.
This configuration has the advantage that you can utilize all paths (and redundancy) of a target even if some janky initiator device only has one network interface or if one of the two NICs/paths on the initiator has already failed, because the initator can reach all the target IPs from its single IP and interface, since they're on the same subnet. You even get full redundancy up until to the point where your janky initiator is connected. What do you do if you have two subnets but only one NIC on your initiator? Which subnet do you choose? That initiator device will be down every single time you do work on your iSCSI infrastructure.
Granted, it is a rare config but imho absolutely viable and there is no point in calling it not being "proper IP networking" as I've seen in previous threads.
Regards
azzurro
I understand that this topic has been discussed before (multiple times). Since I've not read all of the posts, I'll now throw in my take on the situation and why I think that there are scenarios where it makes sense.
In my case, as in many others I guess, and as for all the enterprise SANs I've seen so far, there is a dedicated management interface where all the Webinterface and SSH type stuff is going on. That interface is also being used for any communcation of the SAN/NAS to the rest of the world. There's your answer to the question which interface you'll use for any outgoing traffic. Of course you can create a bond and whatnot if you need redundancy for that.
As for stuff like iSCSI, multiple IPs on the same subnet are perfectly viable for IO path redundancy where the initiator uses a round robin path selection policy to choose from the available paths. There is absolutely no reason why these iSCSI interfaces can't be on the same subnet. There are configs where you have two fabrics and therefore two separated subnets but you also can put all the initiator NICs and target NICs on the same subnet while still keeping physical redundancy at the network switch level.
This configuration has the advantage that you can utilize all paths (and redundancy) of a target even if some janky initiator device only has one network interface or if one of the two NICs/paths on the initiator has already failed, because the initator can reach all the target IPs from its single IP and interface, since they're on the same subnet. You even get full redundancy up until to the point where your janky initiator is connected. What do you do if you have two subnets but only one NIC on your initiator? Which subnet do you choose? That initiator device will be down every single time you do work on your iSCSI infrastructure.
Granted, it is a rare config but imho absolutely viable and there is no point in calling it not being "proper IP networking" as I've seen in previous threads.
Regards
azzurro
