Re: subnet calculations

[Dennis Ferguson <dennis.c.ferguson%gmail.com@localhost>]

On 10 Aug, 2013, at 12:33 , Emmanuel Dreyfus <manu%netbsd.org@localhost> wrote:
> Dennis Ferguson <dennis.c.ferguson%gmail.com@localhost> wrote:
> 
>> I'm assuming that "CIDR mask" means an address prefix length.  When
>> doing this in a route lookup you can generally get a good result by
>> dealing with prefix lengths and using clz()
> 
> What does it do? There is no man page for it.

It determines the highest order bit set in a word.  The 32 bit variant
(the way gcc defines it) returns 0 if the high order bit is set and 31
if the 32 bit value is 1.  It is common for machines to have an instruction
to do this since the operation is needed for divide normalization.

>> IP route tables which include multicast routes (and I think it is best
>> done if unicast and multicast routes are all stored in the same table,
>> rather than treating multicast as a bag-on-the-side wart) can have route
>> prefixes as long as /64 for IPv4 and /256 for IPv6
> 
> Um, I feel rather ignorant: what does a CIDR greater than the address
> length means?

Unicast forwarding (usually) depends only on the destination address
in the packet, so IPv4 unicast routes are address prefixes <= 32 bits
long.  Multicast forwarding, however, depends on both the destination and the
source address in the packet, with IPv4 multicast forwarding routes being
prefixes of a concatenated 64 bit <destination_address><source_address>
lookup key.  When doing a forwarding lookup in a route table with both
multicast and unicast routes you generally just pick both addresses out
of the packet, concatenate them into the right order and offer the
resulting 2xaddress_length key to the route lookup which will match the
number of bits it needs to.

Clearly interface addresses are always unicast and generate unicast route
prefixes, so for your purpose you could take advantage of the fact that
those prefixes will be no longer than a single address.  My brain was thinking
in terms of more general route lookups when I wrote the above, sorry about that.

Dennis Ferguson