[EMAIL PROTECTED] wrote:
# route add 192.168.81.0/26 192.168.81.1
# route add 192.168.81.0/24 192.168.81.1
The leaf node for 192.168.81.0/26 has its rn_dupedkey pointing to the
radix node for 192.168.81.0/24. (Fig thiru-27)
Now we try
# route delete 192.168.81.0/24 192.168.81.1
Thiru,
the catch is that when we call rn_match_args, we do not pass a netmask
(we only pass a key) so that it will return the top node in the duped key
ire_ftable_lookup -> rn_match_args passes 'margs' which contains the
matching parameters to ire_match_args. Note that rn_match_args()
simply does not terminate or start backtracking if the top node matches
on the key, but fails in the call to RN_MATCHF, instead rn_match_args()
iterates through the dupedkey list calling RN_MATCHF for each node in
that list. If the caller of ire_ftable_lookup() requires a match on the
netmask,
it would pass in MATCH_IRE_MASK, and the mask, and the matching is done
by ire_match_args. This is the case when ip_rt_delete -> ire_ftable_lookup
during route deletion.
If the caller of ire_ftable_lookup() did not specify any matching, then
it is just the radix tree lookup for the simple best match.
list. note how rn_lookup parses the duped_key list separately.
Yes, rn_match() always returns the best match, so if an explicit match
on netmask
has to be done, the caller of rn_match i.e. rn_lookup() needs to iterate
over the
dupedkey list. But in our case, rn_match() is insufficient and we had to
invent
rn_match_args() which iterates internally over the dupedkey list calling
the matching
function for each node in that list, so the caller of rn_match_args()
does not need to
iterate over the dupedkey list.
Essentially the BSD code matches only on address and netmask, and
rn_lookup() was
sufficient. But our matching is more complex, and it happens via
rn_match_args -> ire_match_args
and the iteration is internal to rn_match_args.
Thirumalai
_______________________________________________
networking-discuss mailing list
[email protected]
