> 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).
H-mm, how did I make it?? Just couple of days ago, before I upgraded to 121, initiators didn't see all targets while accessing over the same tp. > > 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? They don't connect on this stage, if I understand correctly how MS iscsi initiator works. > If so then iSNS discovery domains > would work well in that environment. Might be, but it's additional service to take care of. Comstar itself is a fun to configure already... I wouldn't like to setup iSNS for our relatively simple configurations. -- Roman -- This message posted from opensolaris.org _______________________________________________ storage-discuss mailing list storage-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/storage-discuss
