> Not sure exactly what changes you have made, but as I recall it, > the onnv code goes like this (thirumalai, could you please correct me > if I got something wrong, esp. in the ipmp code path): > > - get to ip_newroute() to add IRE_CACHE entry for H (with intf ce1, say). > Find the IRE_CACHE entry for G (with "ce0") in REACHABLE state. > > - go to do ire_add_then_send(). Now we will try to do > ire_create -> ... -> ire_nce_init, but we will be passing in the > res_mp from G's nce, but ire_nce_init() will call ndp_lookup_then_add > with ire_ill set to ce1. So the ndp code should correctly end up > adding another nce with the ill set to ce0. > > - later when the ip_newroute() code does ire_add_then_send, the > ndp_lookup_v4 call should find the nce corresponding to ce1.
Seems like that code relies on there never being an NCEs sitting around in other states when ndp_lookup_then_add() is called. For instance, if ce1 has an NCE for H, but it is in the ND_INITIAL state (perhaps because nce_reinit() got called?), then it will get left in the ND_INITIAL state -- and ire_add_v4() will find it != ND_REACHABLE and discard. Is there something that prevents this case from happening in Nevada? (FWIW, this is actually the case I've been hitting during testing.) -- meem
