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. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
