Thanks Ben for this review....

Things to keep in mind here are that some manufactures will "trim"
their IP stack to not calculate networks smaller than a 24 bit (25-32)
and I have worked with devices in the past and present that will only
do the "big 3" (8, 16, 24) network masks.  For those that have never
used one, small networks like 30bit are used in routing and serial IP
addresses for effective bridging of a WAN network.  They are normally
transparent to the end user but common day to network administrators.
For example a 30 bit network could commonly be used in a VPN/VPE
situation to establish a small network for the user in more secure
business settings.

On a side note... I talked to a friend that while working with a large
network device manufacturer found a networked printer that had a poor
IP stack that was blocking DHCP responses, thus it was broadcasting
continuously for an address and never accepting the response.  The
large networking provider bought the printer from my friends business
to put it in there labs as it was no longer on sale or supported
(vinyl printer used for packaging...).

Another angle to look at is the static addressing via DHCP.  On most
of my networks I actually put static leases in for systems that are
also set statically so that I have a note of where and what they are.
This shows up when working with DHCP so that spur of the moment static
addresses do not over lap.




On Mon, Nov 24, 2008 at 10:32 AM, Ben Dailey <[EMAIL PROTECTED]> wrote:
> Message trimmed for brevity comments are added inline.
>
> On Sun, 2008-11-23 at 15:33 -0500, Simón Ruiz wrote:
>> Hm. Most consumer routers I've seen are set up for the 192.168.1.0/24
>> subnet, IIRC. Another non-spec standard?
>>
>> > Imagine a public school that has a simple network of 172.16.0.0/20 and
>> > they need to integrate into a statewide network.  I am sure you can
>> > write the routing information for that on a piece of paper.  A well
>> > defined network is easy to route, manage, and understand.
>>
>> Our network is well-defined, it's just well-defined outside of RFC
>> spec, apparently, because we use the 10.0.0.0/8 range and it's not all
>> crammed together in one humongous subnet.
>>
> You network sounds like it should be setup correctly lets not get our
> RFCs confused. If you were operating a classful network then yes you
> would be having issues but you probably aren't. Your probably using a
> classless (CIDR) network which is "right" in todays network. In my
> professional opinion if you have equipment that is not capable of being
> classless then I build a walled garden around that piece of equipment to
> get it to talk to the rest of the  network as opposed to design an
> archaic network structure around a single or limited devices. Snip from
> RFC 1918:
> <snip>
>        3. Private Address Space
>
>   The Internet Assigned Numbers Authority (IANA) has reserved the
>   following three blocks of the IP address space for private internets:
>
>     10.0.0.0        -   10.255.255.255  (10/8 prefix)
>     172.16.0.0      -   172.31.255.255  (172.16/12 prefix)
>     192.168.0.0     -   192.168.255.255 (192.168/16 prefix)
>
>   We will refer to the first block as "24-bit block", the second as
>   "20-bit block", and to the third as "16-bit" block. Note that (in
>   pre-CIDR notation) the first block is nothing but a single class A
>   network number, while the second block is a set of 16 contiguous
>   class B network numbers, and third block is a set of 256 contiguous
>   class C network numbers.
> </snip>
> So lets understand that these are just reservations in the IP address space 
> and are not in any way tied to classes other than the fact that the 10.0.0.0 
> reservation happens to line up with a complete Class A Network.
>
> So prior to CIDR you netmask, network address and broadcast address were 
> determined by the first octet of you ip address from the following table:
>   Class
> Leading bits
>   Start
>    End
>    CIDR
>   prefix
>  Default
> subnet mask
> Class A
>    0
>    0.0.0.0
> 127.255.255.255
>   /8
> 255.0.0.0
> Class B
>    10
> 128.0.0.0
> 191.255.255.255
>   /16
> 255.255.0.0
> Class C
>    110
> 192.0.0.0
> 223.255.255.255
>   /24
> 255.255.255.0
> Class D
> (multicast)
>    1110
> 224.0.0.0
> 239.255.255.255
>   /4
> not defined
> Class E
> (reserved)
>    1111
> 240.0.0.0
> 255.255.255.255
>   /4
> not defined
>
> Let me state again this should be obsoleted by RFC 1518 & RFC 1519 and
> hopeful no one who has a choice is running their network based on this
> table.
>>
>> I thought you said the 172.16-32.*.* range was meant for 12 bit subnets, 
>> though.
>>
>> I'm a little confused, now; how would splitting that range into 20 bit
>> subnets be any different than us splitting the 10.0.0.0/8 range into a
>> bunch of smaller 16 and 24 bit subnets?
>>
> Lets be careful here and make sure we are not getting host mask and net
> mask confused the RFC snippet above is talking about 24bit host mask for
> the 10.0.0.0 reservation leaving an 8bit net mask remember this is just
> for the reservation of space and should not limit the net mask used in
> operation you in theory could use a 10.0.0.0/30 network in the
> reservation fine. (Though I have found some consumer device that
> seemingly cannot handle any network smaller than a /24 network. Again
> return this equipment, open a ticket, or replace it because as far as I
> am concerned it is broken.)
>> Not likely in the least. As little as possible; I try to assign
>> "static" IPs via DHCP as much as possible. There's one in each subnet
>> that has workstations. Because I've never heard of it.
>
> Great to hear that you are using DHCP for static assignments this will
> greatly ease any transition where you network needs to grow or be
> incorporated in to a larger network.
>
> Well hopefully I have not added any more mud to the water and things are
> little clearer now. The next big hurdle in most network designs is
> routing and routing protocols. :)
>
> HTH,
> Ben
>
>
> _______________________________________________
> Fwlug mailing list
> [email protected]
> http://fortwaynelug.org/mailman/listinfo/fwlug_fortwaynelug.org
>



-- 
Andrew "lathama" Latham

TuxTone Inc.
http://TuxTone.com
[EMAIL PROTECTED]
_______________________________________________
Fwlug mailing list
[email protected]
http://fortwaynelug.org/mailman/listinfo/fwlug_fortwaynelug.org

Reply via email to