Network Address getting assigned to client and ping not working (ver 4.2.2)

[Peter Rathlev]

On Tue, 2012-04-24 at 20:01 +0530, Mukund Deshpande wrote:
> If my subnet is say 7.7.0.0/16
> and in range if i specify 
> range 7.7.0.1 7.7.77.77;
>
> Then 7.7.1.0 , 7.7.2.0 , 7.7.3.0 7.7.77.0 or 7.7.5.255 are part of
> this range. Will have to explicitly exclude all the addresses from
> this range ? That would be so many addresses to exclude.
>
> And if we were to exclude the .0 's and .255's it would be many ranges
> we would end up specifying.

You don't have to exclude those addresses. We have many networks larger
than /24 (typically /22) and we have had no problems with hosts being
assigned .0 og .255. These hosts include Avaya 1220 and 1140E phones and
Windows XP clients. The DHCP server will not automatically exclude those
addresses, at least not the ISC DHCPd.

If there ever was a problem with using .0 og .255 it would have been
within supernets of the "class C" range, i.e. 192.0.0.0-223.255.255.255.
Subnets of class A or class B addresses (e.g. 10.2.16.0/22 or
172.26.0.0/23) 

Keep in mind that the original[*] IPv4 specification described classful
addressing where class A (0.0.0.0-127.255.255.255) and class B
(128.0.0.0-191.255.255.255) networks were always supposed to allow for
the last eight bits to be all 0's or all 1's. The host part could of
course never be all 0's or all 1's, but in e.g. a class B network you
would have 255 valid host addresses with the last octet equal to 0 and
similarly 255 valid host addresses with the last octet equal to 255.

I cannot rule out that certain less-than-optimal implementations of the
IP stack would break when using those (valid) addresses, but I'm faily
certain that at least Windows XP does not have these problems today.

[*]: Per RFC791. There was an even earlier version of the protocol where
all networks were what we call /8 today.

-- 
Peter