> The target host is multihomed, so I'm not surprised to see two entries, > one for each NIC, but why the 0.0.0.0 entries?
I have seen a similiar issue about 2-3 years ago with an ATTO bridge. I think Sun has an initiator bug open to have it ignore 0.0.0.0 addresses. At the time it was causing problems similiar to what your seeing and the workaround was to use static configuration. In the case of ATTO I couldn't convince them not to return the bogus 0.0.0.0 addresses. They were using this information as a place holder in the management software. Maybe the multi-homing is confusing the solaris target, causing it to return 0.0.0.0 addresses. Rick or the code might have a better idea on that one? The current iSCSI initiator will only use the last (due to backward sort order) SendTargets address unless you get into the -c options, although I don't think you want to do that in this case. There is an open RFE for the iSCSI initiator to implement a feature Microsoft coined as Portal Hopping. If the initiator can't open a SendTargets address it should "hop" to the next address in the list and open that address. This would workaround the 0.0.0.0 address in a more useful fashion. (I will add the SendTargets ordering of connect to my debug notes.) This message posted from opensolaris.org _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
