> >> - 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.
>
> 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.
I'm unclear why the added NCE would usually be in the unresolved state;
ire_nce_init() does:
if (ire_ill->ill_net_type == IRE_IF_NORESOLVER) {
nce_state = ND_REACHABLE;
nce_flags = NCE_F_PERMANENT;
} else {
if (fp_mp != NULL)
--> nce_state = ND_REACHABLE;
else
nce_state = ND_INITIAL;
nce_flags = 0;
}
err = ndp_lookup_then_add(ire_ill, NULL,
&addr4, &mask4, NULL, 0, nce_flags, nce_state, &arpce,
fp_mp, res_mp);
In the case where you're adding an NCE for H and there was already an NCE
for G, fp_mp will be G's fp_mp, so we should create H as an ND_REACHABLE
NCE -- even if G is on a different ill. Or am I missing something here?
The problem that I see with the above is that if the NCE already exists
but is not ND_REACHABLE, then we will not replace it with an ND_REACHABLE
NCE -- even though we could. I think this is the case I am hitting in my
testing, but I'm not sure why I'm hitting it and Nevada isn't.
Or I could be missing something else; more clues welcome.
--
meem
