James Carlson wrote: > Jim Moore writes: > >> On 09/23/08 13:13, James Carlson wrote: >> >>> Better still, just lose that code. I see no obvious reason to be >>> trying to skip over the loopback interface. >>> >>> >>> >> Okay, I'll look at the other attributes. We need to filter loopback >> addresses because >> we are going to supply them to the iSCSI initiator via an iSCSI inquiry >> or iSNS registration. >> > > Now's probably not the time to get too deep into design issues, but > that explanation sounds fishy to me. >
The iSCSI SendTargets request and the iSNS protocol both require the target to compile a list of portals (IP address/port pairs) that can be used to access the target.report the available "portals" for iSCSI target. If all the targets are configured with an explicit list of portals then this is pretty easy. We don't require users to configure portals though -- if no protocols are configured then we allow connections from any address. I believe this is the behavior administrators expect by default. This keeps things simple for the administrator but it makes it difficult to provide SendTargets and iSNS data. The only apparent way to provide the required portal data was to get the list of IP addresses and use those to derive the portal list on the fly. > If iSNS really needs multiple addresses at the same time for a single > system, it ought to use transports that support that (such as SCTP) > and naming services that can allow the administrator to group the > addresses as needed (e.g., multiple DNS A records) rather than just > "guessing." > Administrators can configure discovery domains within iSNS to define which initiators can register with which targets. The target is merely responsible for registering it's info which we are doing. -Peter _______________________________________________ networking-discuss mailing list [email protected]
