I see traffic from this last IP address octet all the time from prefixes of length less than /24. Use of these host id’s when the prefix length is greater than or equal to /24 is illegal. So if that’s your case, I’d suggest not doing it.
If that’s not the case, look for over-zealous or incorrect filters in the path. I saw this situation once before. There was a border ingress filter with a typo in it…
Chris
I see traffic from this last IP address octet all the time from
prefixes of length less than /24. Use of these host id's when the
prefix length is greater than or equal to /24 is illegal. So if
that's your case, I'd suggest not doing it.
It's from a /24 assignment, but is actually being used for tunnel
endpoints, so there seemed to be no reason not to use the .0 address.
If that's not the case, look for over-zealous or incorrect filters in
the path. I saw this situation once before. There was a border
ingress filter with a typo in it...
I spent a long time looking for each filters, and watching traffic leave
our network but not receiving any replies, while traceroutes would work
just fine.
As Peter points out, it's from what would have been Class C space, so it
looks like I'm getting bitten by the Windows stuff. All 3 sites I
mentioned as not being accessible are running under Windows according to
Netcraft.
J.
While it is often great sport to poke at MS, did you consider that this
might have nothing to do with classfullness or CIDR? I believe you will find
that 0 & -1 are invalid for whatever netmask the windows stack is given. You
might also find that some 'features' are mitigation for exploits that
existed at one time (possibly long before some of the thread participants
were in high school). The fact that other OS's support an inverted state is
not necessarily a reason to change the Windows behavior. Be very aware that
it is much easier to sit in judgment than it is to actually provide support
for the technically clueless masses. Also be aware that exploits are
targeted where they will have the most impact, so the fact that someone is
not taking advantage of a niche OS is a point in time phenomena. Long before
Windows shipped, the target of that period was the various flavors of Unix.
Tony
So you're saying that with 10.200.200.0/22, that 10.200.201.0,
10.200.202.0 and 10.200.203.0 are invalid host addresses? Setting up
DHCP scopes for this space must be painful.
Not to mention use of /32 addressing for loopbacks. I could almost
forgive not handling /31 given that RFC3021 was onlyu published in
12/2000.
Bob
While it is often great sport to poke at MS, did you consider that
this might have nothing to do with classfullness or CIDR? I believe
you will find that 0 & -1 are invalid for whatever netmask the
windows stack is given.
I think you may be confused about the problem. Let's not mask the IP
addresses that I spotted this problem, but get them out into the open.
(BTW, don't bother probing these addresses to retrace my steps, some
hosts are now down, firewalled, or roaming the aisles of Gotts Road in
ghostly torment.)
On the one end of the connection, we have a Windows 2000 box with the
IP address 217.169.21.28 and a Linux box with the adjacent IP address
217.169.21.29. These are on a LAN with a 255.255.255.240 netmask. In
classful parlance, it is a Class C that has been subnetted. I also
have a packet sniffer on the network.
On the other end of the connection, we have a Linux box with the IP
address 195.92.249.0. I forget the exact netmask, but it was around
the /19 or /20 mark. In classful parlance, it is a Class C that has
been supernetted.
From the Windows box, I can ping 195.92.249.0 fine. I can't seem to
ssh to that IP though. Break out the packet sniffer.
I ping, and the packet sniffer shows packets leaving, and coming back
~25ms later. Good. I fire up telnet and point it at port 22.
"Connection refused". Packet sniffer shows no traffic. Double-checking
from the Linux box, I can ping and telnet to port 22, and I get
packets flowing just fine.
By the way, the Windows 2000 box is stock install, with no service
packs, "personal firewall" software, antivirus stuff, etc, etc. In
other words a sitting duck 
but it does mean that the problems
aren't caused by third-party software.
You will note that 195.92.249.0 is not all-bits-zero or all-bits-set
("0 & -1") on 217.169.21.16/28. Therefore it is a perfectly valid IP
address. Windows has *no* business interpreting IP addresses outside
its limited view of the world.
You might also find that some 'features' are mitigation for exploits
that existed at one time
Exactly what exploits are mitigated by blocking TCP connections, but
letting ICMP through just fine? It's not as if worms can't create raw
sockets and create packets (with or without the evil bit) as
appropriate.
(possibly long before some of the thread participants were in high
school).
I'm older than TCP/IP and the Internet. I'd left school well before
Windows had heard of the Internet. Haven't got the Unix hacker beard
yet though
> While it is often great sport to poke at MS, did you consider that
> this might have nothing to do with classfullness or CIDR? I believe
> you will find that 0 & -1 are invalid for whatever netmask the
> windows stack is given.I think you may be confused about the problem. Let's not mask the IP
addresses that I spotted this problem, but get them out into the open.
(BTW, don't bother probing these addresses to retrace my steps, some
hosts are now down, firewalled, or roaming the aisles of Gotts Road in
ghostly torment.)
Step back..
The windows box does not have the problem IP directly connected nor does it have
it specifically in its routing table, it is also not in the same classful
network as the problem IP. Therefore netmasks are not involved, therefore it
should not do anything other than forward it to the default.
Afaik this is true of both classful and classless networking.
Steve