lkml.org 
[lkml]   [1999]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRE: howto disable auto route setup?
On Tue, 2 Feb 1999, Fred Reimer wrote:

>
>
> > -----Original Message-----
> > From: owner-linux-kernel@vger.rutgers.edu
> > [mailto:owner-linux-kernel@vger.rutgers.edu]On Behalf Of Richard B.
> > Johnson
> > Sent: Tuesday, February 02, 1999 10:50 AM
> > To: Neil Conway
> > Cc: Mike Jagdis; Sam Mortimer; linux-kernel@vger.rutgers.edu
> > Subject: Re: howto disable auto route setup?
> >
> >
> > [SNIPPED (most all)]
> > >
> > > Vaguely on this topic, I've been wondering if it's
> > legal/advisable/safe
> > > to have a netmask like 255.255.254.0 ?
> > >
> >
> > Yes. My netmask is 255.255.248.0
> > My network runs from 204.178.40.1 -> 204.178.47.255
> > 204.178.40.0 is the "network" address, 204.178.47.255 is the
> > "broadcast" address. Because of some defective software in some
> > machines, we don't use 204.178.40.255, 41.255, 42.255, 43.255,
> > 44.255, 45.255, or 46.255 because some machines think that these
> > are broadcast addresses. The machines that abuse these addresses are
> > M$garbage machines.
>
> Show me the RFC where it says this is legal all of a sudden.
>

Reverse request. It has always been legal and the width of the
network assignment has always been defined by the netmask.

> > The idea of class A->C networks has come and gone because of the
> > lack of suitable continuous addresses defined by the original
> > standard. It is now common to make large networks using contiguous
> > small networks. The netmask is the thing that defines the "network".
> > Stuff that doesn't fit through the mask is sent/received through
> > the "default" route. Once this is understood, configuring a network
> > is simple.
>
> I don't remember the RFC that says this either. Try to configure a Bay
> router with a subnet mask less than the class of network for the IP. Can't
> do it. I'd try on a cisco router, but I don't have one available at the
> moment. I doubt it would let you setup an >interface< with an illegal
> netmask either. If it does, then it's a bug.

No. Classes of networks, defined by specific IP addresses do not
exist anymore. Note that RFC means "[R]equest [F]or [C]omments". They
became defacto standards before anyone thought that there would
be the requirement for as many networks as exists today.

>
> > > Anyone? The HOWTO is rather ambiguous about it. I think
> > it's legal,
> > > but am not entirely sure. This also seems to imply a
> > broadcast addr. of
> > > something like 194.111.1.255 for a network address of 194.111.0.0,
> > > presumably that's OK too?
> >
> > The broadcast address is the IP number that will be put into packets
> > that have a hardware destination of ff:ff:ff:ff:ff:ff (did I put in
> > enough). These packets are received by everyone on the LAN. They
> > will be received regardless of the IP number contained therein. For
> > compatibility, its a good idea that the address be within the LAN
> > range, and contain .255 as its last number. However, some OS don't
> > care because they never check. Stuff that goes out in the Internet
> > is changed and cleaned up by the router. Ethernet hardware addresses
> > are not used on a WAN (like the Internet).
>
> Just because we can make it work with Linux does not mean it is the right
> thing to do. If we ever want Linux to be accepted for mission critical
> tasks in the big glass house then it must interoperate with all other
> devices that follow standards. We can't make up our own as we see fit.
> Does Windows support this? What about HP-UX? Solaris? AIX? Digital
> (Tru64) Unix? DG-UX? Irix? VMS? Novell Netware? Cisco routers? Bay
> (Nortel) routers? 3Com routers? OS/2? BeOs? *BSD?
> Name-your-vendor-upon-which-mission-critical-apps-run?
>

VMS doesn't run TCP/IP, you need to get third-party software. We
use TCP_ware and it does support the netmask required.

SunOs also supports the netmask required, as does BSD, Digital Alpha, and
even M$Windows. Everything on this site allows the netmask to be set
correctly. If all netmasks were 255.255.255.0, you would not need one
at all. It would be hard-coded into the software IP layer.

> If it is not specifically specified in an RFC or other standards document
> that it is now acceptable to "reverse subnet" IP addresses then the answer
> to all of the questions above must be yes for this to be right. If there is
> lack of an official standard, then there must be an "Industry" standard for
> it to be standard. I don't think even a majority of the vendors listed
> above support this, let alone a super majority that would constitute an
> Industry standard.

Reverse-subnet, as you state, is the name of the game now-days.

>
> Some questions.
>
> What is your default router? Wouldn't happen to be something like
> 204.178.40.1 is it?

The default router (a Cisco) looks at 40.1 -> 47.1 so that even
broken machines can address it. The normal default route is
40.1.

Do you multinet on your router, where you specify the
> "correct" subnet mask of at least 255.255.255.0? May be so that those
> stupid Windows boxen can talk to each other? If so, have you actually
> looked at the traffic on your network? You might be sending everything
> through the router and duplicating traffic on your network.

No. That't the purpose of the netmask. Nothing gets routed by the
Cisco except stuff outside our domain. Again, the purpose of the
netmask is to let software know whether network I/O is to be sent
to a specific local hardware address (the physical endpoint) or if
it is to be sent to the hardware address of the machine handling IP
addresses outside the LAN. Look up ARP and see how that works. If
the IP address is outside the range allowed by the netmask, an
initial ARP is sent to the default-router. From then on, any
communications outside the netmask goes to the hardware address
(returned by the ARP protocol) of the default router. If the
IP address is within the netmask window, the initial ARP request
is broadcast on the LAN. The machine with the requested IP address
replies with its hardware address and all further communications
with that machine occurs using that hardware address. Until
the ARP table expires, LAN communications occurs hardware-address-to
hardware-address.

The only time we have duplicate packets on the LAN is when someone
runs the 'routed` daemon. This is because the daemon advertises
that it has a 'route' for whatever, and the Sun Boxes automatically
route packets. This means that some Sun will advertise a route on
the same wire (stupid) and other Sun Boxes with believe it (also
dumb). We chase down these magic routers and rename the routed
daemon to something equally dumb.


At least the
> Windows boxen would send any replies through the router if you were not in
> the same Class C network. 255.255.248.0 may be the subnet mask for your
> "network" as viewed from the Internet, which supports CIDR and aggregation
> of routes, but don't confuse routing protocols with IP interfaces. Failure
> to properly configure a network on your part does not constitute acceptance
> of a supposed industry standard on my part.

This is a properly configured network and I am not defending my work.

I didn't set it up. We have 8 co-existing Network Administrators in
this site. Since this is an Engineering environment, there is the
possibility of some strange new machine coming on the wire at any
instant. Therefore, we have some considerable funds spent on continuous
monitoring equipment to keep things un-broken. FYI, most of the
system is now fiber with local hubs to connect stuff in labs and
offices. I have 100-baseT to a 3COM switch, which connects to
a fiber "backbone". Raw IP runs around the whole facility (not the
most efficient, but the most controllable).

We have one T1 link to uu.net via a Cisco, to round out the facility.

Cheers,
Dick Johnson
***** FILE SYSTEM WAS MODIFIED *****
Penguin : Linux version 2.2.1 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
Wisdom : It's not a Y2K problem. It's a Y2Day problem.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.078 / U:0.756 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site