Hoot, Joseph wrote: > more INLINE below... > > On Nov 17, 2009, at 7:27 PM, Mike Christie wrote: > >> Pasi Kärkkäinen wrote: >>> On Mon, Nov 16, 2009 at 09:39:00PM -0500, Hoot, Joseph wrote: >>>> On Nov 16, 2009, at 8:19 PM, Hoot, Joseph wrote: >>>> >>>>> thanks. That helps. So I know that with the EqualLogic targets, there >>>>> is a "Group IP" which, I believe, responds with an iscsi login_redirect. >>>>> >>>>> 1) Could the "Login authentication failed" message be the response >>>>> because of a login redirect messages from the EQL redirect? >>>>> >>>>> and then my next question is more for curiosity sake: >>>>> >>>>> 2) Are there plans in the future to have more than one connection per >>>>> session? and I guess in addition to that, would that mean multiple >>>>> connections to a single volume over the same nic? >>>>> >>>>> >>>> Also Mike, I'm seeing one or two of these every 30-40 minutes if I slam >>>> our EqualLogic with roughly 7-15k IOPS (reads and writes) non stop on 3 >>>> volumes. In this type of scenario, would you expect to see timeouts like >>>> this once in awhile? If so, do you think increasing my NOOP timeouts >>>> would assist so we don't get these? maybe set it to 15 seconds instead of >>>> 10? >>>> >>> Equallogic does active loadbalancing (redirects) during operation.. >>> dunno about the errors though. >>> >> Oh yeah, forgot about that. Thanks Pasi! >> >> Joseph, look in the EQL target logs for something about the EQL box >> doing load balancing. I think normally we handle the load balancing more >> gracefully, but we might be messing up. I think if EQL was load >> balancing in the open-iscsi logs we would see something about getting a >> async iscsi pdu from the target that asks us to logout. Then when we >> relogin the target would redirect us to the optimal path. > > > There are two things that the EQL does, I believe-- one thing is async > logout, the other is login_redirect. Unfortunately, from the EQL syslog > side we don't see any errors related to this. It's my understanding, > however, that when a login is initially attempted to the EQL, it hits the > "group ip" or an alias'd IP sitting on a real nic. The group IP looks at all > the interfaces on the EQL and decides, based on some algorithm, which EQL nic > the session should connect to. It then sends the initiator that made the > request a login_redirect, which I thought is basically a "logout and > reconnect" pdu. It would say, for example, "you're can't log into the group > IP, however, you can log into this IP (a real nic) that it would prefer you > be logged into." > > I'm thinking that the "failed login" is actually the result of that attempt > to log into the group IP and it sending a login redirect pdu back to it. >
If the target was load balancing us it would: - Send a async logout pdu. - We then send a logout pdu. - When we get the logout response pdu we kill the tcp ip connection - We then create a new tcp connection - We then log in to the portal that was passed into iscsiadm/iscsid (the one in the DB that you see when you run iscsiadm -m node, which is probably what you call the group IP). For this process we send a login pdu. It then sends a login response pdu with the login redirect response. In this response we also get the new IP to log into. - We see that response and kill the tcp connection, and create a new tcp connection to the portal we are being redirected to. - We then log into the portal we were redirected to. We again do this by sending a login pdu. This time the login response pdu should be ok and we are done. We do not know which login pdu failed, right now. You would need a wireshark trace or iscsid debugging. iscsid could hit the "Login authentication failed" path for either of the login pdus sent. You should not see that message normally even when we are being redirected. We do the login redirect login when we initially log into the target (like when you do iscsiadm -m node -l or service iscsi start), and if you look in your logs you should not see a login failed message for that. If you do it might be a clue. -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=.