My understanding is that the function 'rtflushclone'  is used to
  delete any entry in the routing table that were cloned from the
  'rtentry' received in arguments.  Is that right?
  If so, why is 'rtfluchclone' called in rtrequest1 when a new route is
  added?  How could that new route already have clones?

My view is that in all cases of caching routing information, the
correct behavior is to behave the same way (just faster) as if there
were no caching.  A cloned route serves two purposes: a) it stores the
mac address and b) it is a cache entry which hits on ipaddr/32 and
points to an interface.  This second purpose is really a cache.
Consider a route 10.1.0.0/16 on an interface.  Then consider adding
10.1.2.0/24 on a second interface.  Had there been any arp in entries
in the second prefix on the first interface, it would be incorrect for
them to remain.   So when adding a route, all cloned routes which lie
within the new prefix must be removed.

Yes, it's twisted to have setups like this.  But still cache
consistency shouldn't be an issue.

-- 
        Greg Troxel <gdt@ir.bbn.com>