> Ok. So I guess there are no tests in the ipmp test suite to trigger this > particular case. > > > Is it possible that: > > 6508701 ire_add_v4() often adds unresolved IREs even when told not to > > ... is playing a role here? Specifically, before that fix, ire_add_v4() > > will add unresolved IREs regardless of the allow_unresolved flag. So > > nope. the root-cause is different. even if you add the ire, unless > someone kicked off arp, the packets would never get sent.
I thought that ip_xmit_v4() would kick that off via ire_arpresolve() the next time someone sends a packet through that IRE. > > wouldn't that mask this bug? If so, seems like IPMP should be pretty > > broken in Nevada right now. > > I believe this case might not easily encountered, even with ipmp, > which is why we have not seen it... Well, it's trivially easy to encounter on my test machine with my bits -- in fact, so much so that I would not release my bits for early access without a fix. That said, there may well be something unusual in my bits that makes this case more common. > does the ipmp test suite actually trigger a case where we send packets > to an offlink dst through various interfaces in an ipmp group, and > there is only 1 gateway on the lan? I don't think it does. -- meem
