> >> > >> - 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. > >> > >>--Sowmini > >> > >> > So far so good, but where is the arp resolution being triggered ?
Question for meem (can be answered by using dtrace probes): is the ire_nce_init call for H being passed an fp_mp? I think Meem mentioned that this is not reproducible with onnv.. I'm trying to figure out what the difference is... it may possibly be a difference in timing that has not been observed in onnv. > Multiple possible solutions. > > 1. A simple thing is to create a resolved nce based on the gateway's nce > (though on a different ill, > but in the same IPMP group). right... this is what I was going to suggest, if dtrace probes confirm that the crux of the problem is that we don't set the REACHABLE bit on the nce created for H. This would preserve the on10 behavior.. > 2. Trigger the arp resolution in ip_newroute for this case, and add the > ire only when arp resolution > is complete > > 3. Allow adding incomplete ires similar to forwarding case and finish > the unfinished work of Surya, > Arp resolution is triggered only by ip_xmit_v4, when packet needs to go out. #3 is probably the ideal solution, since #2 will add more band-aids. into ip_newroute/ire_ftable_lookup. --Sowmini
