> For instance, suppose we have a resolved IRE_CACHE entry for gateway G,
> and its ire_stq refers to "ce0". Now suppose someone tries to send a
> packet to host H which needs to be reached through gateway G. Suppose the
> IRE_CACHE entry that ip_newroute() creates has an ire_stq that refers to
> "ce1". Eventually, we'll reach ire_add_v4(), which will attempt to lookup
> the NCE for gateway G, here:
>
> if (ire->ire_type & IRE_CACHE) {
> ASSERT(ire->ire_stq != NULL);
> --> nce = ndp_lookup_v4(ire_to_ill(ire),
> ((ire->ire_gateway_addr != INADDR_ANY) ?
> &ire->ire_gateway_addr : &ire->ire_addr),
> B_TRUE);
> if (nce != NULL)
> mutex_enter(&nce->nce_lock);
>
> However, since `ire' is the IRE_CACHE entry for H, ire_to_ill() will
> return ce1's ill.
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.
--Sowmini
