Roman Naumenko wrote:
Roman,
The COMSTAR iSCSI target starts up an IP listener
socket any time an iSCSI target comes online that needs to listen on a
new TCP port number. As currently implemented, these TCP listeners listen on ALL
interfaces rather than being restricted to just the interfaces that are
mentioned in the TPGs that are online. Access control
is applied later, when a connection attempt is made. If a connection
arrives for target T via an interface and port number that is not used by
target T, then the connection is rejected.
For example, suppose there are three targets, as
follows:
Suppose the box has two IP addresses 10.0.0.1 and
10.0.0.2
itadm create-target ===> target A (will listen on all interfaces for
port 3260)
itadm create-tpg TPG3260 10.0.0.1:3260
itadm create-target -t TPG3260 ===> target B (will
listen on one interface for port 3260)
itadm create-tpg TPG50001 10.0.0.2:50001
itadm create-target -t TPG50001 ===> target C (will
listen on the other interface for port 50001)
If target A is online, there will be a listener created on all interfaces for
port 3260. Connections arriving from any interface on port 3260 for target A
will be accepted.
If target B is online, it will use the same listener on all interfaces for port
3260. Connections arriving from interface 10.0.0.1 on port 3260 for target B
will be accepted. Connections arriving from any other interface for target B
will be rejected.
If target C is online, there will be a listener
created on all interfaces for port 50001. Connections arriving from
interface 10.0.0.2 on port 50001 for target C will be accepted.
Connections arriving from ther interfaces will be rejected. Similarly,
connections arriving for other targets on port 50001 will be rejected.
The "Send Targets" discovery service depends on the
existence of ANY target that uses the default port of 3260. If either
target A or target B is online, then the SendTargets discovery service
will be available.
For example, the SendTargets service will be
available on all interfaces even if only target B is online.
Does the behavior that you are observing match the
above description? I have not seen the above behavior documented anywhere.
If this behavior causes significant issues, let us know.
Peter C
Ok, I see what you mean. Thank you for the explanation, that's confirms I saw on servers.
And I'd like to let you know that causes a lot of troubles and annoyance.
Firstable - what the whole reason using tpg when target service continues to
listen on all interfaces? This is from the sun wiki:
[i]Creating Target Portal Groups
You can create a Target Portal Group (TPG) to manage the discovery of multiple
iSCSI and iSER targets. A TPG is a list of IP addresses that determines[b]
which interfaces a specific iSCSI target will listen to[/b].[/i] But what we
get is all targets listens on all interfaces, tpg just restricts access.
In this respect COMSTAR behaves identically to iscsitgtd -- they both
listen for connections on all interfaces (see port_watcher() in the
iscsitgtd code).
The second annoyance - that's what happens in real life when you start to
create targets and connect servers to SAN network. Administrators immediately
start complain about seeing ALL targets when connecting their servers to SAN
network.
You know what they tell me: "Roman, what the hell? Why I see sql target on DC controller? Why this doesn't happen on our Linux storage?" and so on. And they are right, it's very disappointing since it _looks like_ you can login to any target, from any server. Now I have to explain in details how Comstar works in details, rather than provide target per server as they are requesting.
Interesting. I don't think changing the way we accept connections would
address this. We would need a mechanism for filtering the SendTargets
output on a per-initiator basis.
It would be a great improvement if you correct tpg behavior and make it listen
on defined interface. Actually, all documentation that I could find regarding
Comstar implies this.
It sounds like in your environment you have multiple targets defined
with portals on separate disconnected networks. And so when you use
SendTargets discovery your initiators attempt to connect to targets that
are not reachable? If so then iSNS discovery domains would work well in
that environment.
-Peter
_______________________________________________
storage-discuss mailing list
storage-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
