> 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. 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. 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. -- Roman -- This message posted from opensolaris.org _______________________________________________ storage-discuss mailing list storage-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/storage-discuss
