sowmini.varadhan at Sun.COM wrote: >> >> - 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 ? Without triggering arp resolution, the nce added will be in the initial state, and ire_add_v4 will fail the ire add in most cases (the forwarding case is the exception) since the nce is unresolved. Normally you would not hit this case, since without IPMP, the nce for the gateway will be used directly, only in the IPMP case, you will try to create another nce, since the new ill is different from the ill of the gateway nce.
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). on10 code creates a new ire cache for the offlink dest going through a different ill (for load spreading) based on the gateway ire cache though the gateway ire cache's ill is different. It uses the same dlureq_mp. This may not be strictly correct. See the on10 ip_newroute IRE_CACHE case comments. 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. thirumalai
