I wrote:
>	34060-34063 == 0x850c - 0x850f  mask 0xfffc
>	34064-34067 == 0x8510 - 0x8513  mask 0xfffc
>	34068-34069 == 0x8514 - 0x8515  mask 0xfffe
>

And Bill Studenmund wrote: 
> As I understand it, that's how our routing table works. It uses a binary
> tre method, so needs this. :-)

And Chris Badura wrote:
> Our routing table code is perfectly able to handle the first two
> entries with a single routing table entry.  At least for the IP case,
> but I don't see why Atalk should be different in this case.

I don't think so!  Even though it looks like a contiguous block of 8
network numbers, they don't all share the same high-order bits.  In
particular, (if you count bit 0 at the high-order end) they differ in
bit #11(decimal).  And you can't shorten the mask to 0xffe0 (which you
would need to do if you wanted to include bit #11 in the "don't-care"
stuff), because then you'd end up matching all 32 networks from 0x8500
through 0x851f (or, in decimal, 34048 through 34080).


--------------------------------------------------------------------------
| Paul Goyette      | PGP DSS Key fingerprint:   | E-mail addresses:     |
| Network Engineer  |   BCD7 5301 9513 58A6 0DBC |  paul@whooppee.com    |
| and kernel hacker |   91EB ADB1 A280 3B79 9221 |  pgoyette@juniper.net |
--------------------------------------------------------------------------