Re: [PATCH 0/2][RFC] Network Event Notifier Mechanism

[Steve Wise <swise@opengridcomputing.com>]

On Sat, 2006-06-24 at 10:30 -0400, jamal wrote:
> On Fri, 2006-23-06 at 08:24 -0500, Steve Wise wrote:
> 
> > 
> > > PS:- I do think what they need is to hear route cache generation
> > > as opposed to ARP+FIB updates; but lets wait and see how clever 
> > > the patches would look.
> > > 
> 
> > Can you expand on your statement above?  If hooking route cache
> > generation gets all the events I described, then I'd like to use that.
> > I'm still learning the Linux routing subsystem.  Any help would be
> > GREAT!
> > 
> 
> If my understanding is correct of what you are trying to do is:
> for a destination IP you are going to figure the source and destination
> MAC address. Most of that info is available at the route + hh cache. 
> There can be only one destination mac per device and so you only need to
> watch the device changes for that. The dst MAC per IP and any changes
> you can glean from the route cache created.
> But this is based on my understanding of what you are trying to do and
> so far i cant say i am 100% clear.

The route/hh cache insertions might work for the initial dst MAC per
next-hop IP.  But this dst MAC can _change_ for various reasons (even
though the next-hop IP remains the same).   Such a change, I think,
doesn't generate a new route + hh cache insertion, just a change to the
hh entry.

Also, I think the route cache entry is created _before_ the MAC addr is
known. So we really need to know when the neighbour entry is updated
with the MAC address as a result of ARP/ND.  Hooking the correct spot in
the neighbour code where the mac address gets stored also gets us the
change event I described above.

Does this make sense?

Steve.