On 01/12/2015 11:48 AM, Mike Christie wrote: > On 1/12/15, 1:29 PM, Ben Greear wrote: >> On 01/12/2015 11:22 AM, Mike Christie wrote: >>> On 1/9/15, 8:28 PM, Thomas Dwyer III wrote: >>>> Hi folks, >>>> >>>> I spent some time browsing through this forum but I was unable to find an >>>> explanation for this comment referring to the disabled >>>> bind_src_by_address() >>>> function in io.c: >>>> >>>> *This is not supported for now, because it is not exactly what we want.* >>>> *It also turns out that targets will send packets to other interfaces* >>>> *causing all types of weird things to happen.* >>>> >>>> I found several posts from people referring to this specific comment but I >>>> did not find an explanation. Is it possible that the author of this comment >>>> was referring to the ARP flux issue, which may cause a target to associate >>>> the bound IP address with the MAC address from an interface other than the >>>> one specified with SO_BINDTODEVICE? If so, I don't see how avoiding the >>>> call to bind() solves this problem. I would appreciate a reply from anyone >>>> who might know what "weird things" means in this context. >>>> >>> >>> bind_src_by_address() only did a bind() and was expecting all traffic to >>> flow through the interface with the specified ip address. If you have >>> multiple >>> interfaces on the same subnet, the network layer would send/recv on any of >>> them. This ended up causing issues with packets not getting sent/received >>> or received >>> in incorrect orders to the iscsi layers on the initiator/target side. >> >> If you add additional routing logic based on source-addresses, then this >> method will indeed >> bind to a particular interface, so please leave that logic in place. > > The basic problem, people wanted to solved was the case where they have > multiple interfaces on the same subnet. They then wanted to be able to create > iscsi > connections/sessions through all those interfaces and have the multipath > layer round robin over them. If you just tried to do bind() the network layer > would > send/recv over any of the interfaces on the same subnet. > > What additional logic can you add to make this work on a per connection > basis? I have seen where you can manually manipulate the routing table to > send all > traffic through specific nics, but not where I can control it on per > connection level.
We use arp-filtering, and source-based routing using multiple routing tables. So, for instance, any pkt from 1.2.3.4 will route through eth7 based on routing table rules. Then, if application binds to 1.2.3.4 for sending, it will automatically route out of eth7 regardless of any other interfaces or IP address configuration. arp-filtering will make sure only eth7's MAC will be used as ARP response for 1.2.3.4. >> BINDTODEVICE is also very useful, of course, but it will not be so useful if >> you have >> multiple IPs on the same interface. > > Did you mean subnet or interface? For subnet, we are currently using > BINDTODEVICE (no bind() or other calls) when we have multiple IPs on the same > subnet for > the multipath case I described above. I mean on same interface. I think you need support for both BINDTODEVICE and bind() support to make this work properly. Don't necessarily enable both automatically or by default, but at least let users configure them as needed. I don't know a lot about iscsi or it's implementation, but if nothing else, you should be able to set up a bunch of mac-vlans and use a combination of bind() and bind-to-device to create multiple streams. This is how we use iscsi as a load-test tool against iscsi file servers. Thanks, Ben -- Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
