From owner-freebsd-questions  Thu Aug  3 10:35:04 1995
Return-Path: questions-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.11/8.6.6) id KAA06927
          for questions-outgoing; Thu, 3 Aug 1995 10:35:04 -0700
Received: from lupine.nsi.nasa.gov (lupine.nsi.nasa.gov [198.116.2.100])
          by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id KAA06921
          for <freebsd-questions@freefall.cdrom.com>; Thu, 3 Aug 1995 10:35:02 -0700
Received: (from mnewell@localhost) by lupine.nsi.nasa.gov (8.6.12/8.6.12) id NAA09733; Thu, 3 Aug 1995 13:32:47 -0400
Date: Thu, 3 Aug 1995 13:32:47 -0400 (EDT)
From: "Michael C. Newell" <mnewell@lupine.nsi.nasa.gov>
To: Garrett Wollman <wollman@halloran-eldar.lcs.mit.edu>
cc: aarone@homer.prahran.swin.edu.au, freebsd-questions@freefall.cdrom.com
Subject: Re: SLIP routing on internet.... (LONG reply)
In-Reply-To: <9508031729.AA20355@halloran-eldar.lcs.mit.edu>
Message-ID: <Pine.SUN.3.91.950803133158.9223N-100000@lupine.nsi.nasa.gov>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: questions-owner@FreeBSD.org
Precedence: bulk

On Thu, 3 Aug 1995, Garrett Wollman wrote:

> > 2. You can fool around with ARP tables and routes to get this to work (that's
> > what I did originally), but it's messy and doesn't scale.  What you can do
> > is put in an ARP and a route in slip server's tables for each address you're
> > going to use on subnet.  On target host you'll need arp entries and 
> > routes for each address you use on ethernet.  Again, both slip server and 
> > target host have to be set up with routing enabled.  You wouldn't 
> > actually subnet - that is, for a class C network number you'd use the 
> > default mask of 0xffffff00, for class B use 0xffff0000, etc.  It works, 
> > but everything's manual...
> 
> Actually, no it isn't.  We had precisely this problem, and the code to
> fix it is enabled by adding:
> 
> 	options		ARP_PROXYALL
> 
> to your kernel configuration file.  This is very useful when you don't
> have control over the main router on your super-subnet.  Of course, in
> this case, you would still need to subnet your network; all this
> technique allows you to do is avoid reconfiguring a hundred machines
> over which you may not have any control.  In our environment, this
> code is used to connect the 18.26.64 and 18.26.128 subsubnets to the
> 18.26.0 subsubnet.  (That machine is also a multicast router.)

Way cool!!  Thanks for the pointer... :-)

Thanks,

Mike

+--------------------------------------+------------------------------------+
|Mike Newell                           | The opinions expressed herein are  |
|NASA Science Internet Network Systems | my own, and do not necessarily     |
|Sterling Software, Inc.               | reflect those of the NSI program,  |
|MNewell@nsipo.nasa.gov                | Sterling Software, NASA, or anyone |
|+1-202-434-8954                       | else.                              |
+--------------------------------------+------------------------------------+
|                  work: http://www.eco.nsi.nasa.gov/~mnewell               |
|                    home: http://www.newell.arlington.va.us                |
+---------------------------------------------------------------------------+