On 01/12/2015 01:59 PM, Ben Greear wrote: > 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.
Thanks for the info. Thomas, let me know if your question was for functionality you needed or just looking through the code and were curious. -- 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 open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
