[comp.sys.apollo] Apollo ethernet routing

benu@bnlux0 (David Hassel) (10/17/89)

	We have several Apollos connected via a token ring and one gateway
with an AT ethernet board from Apollo.  The nodes on the token ring all have
an address of 134.88.14.x including the TR side of the gateway.  The
gateways ethernet side has an address of 134.88.1.14.  We are only able to
talk to hosts with an address of 134.88.1.x on the ethernet from the
gateway.  The other machines on the TR can't access theses hosts.  How
do I convince the gatway nodes routed that it is a geatway to 134.88.1?
Here is our present setup on the gateway osiris:
(rc.local)
        /etc/ifconfig lo0  localhost
        /etc/ifconfig dr0  134.88.14.1 netmask 255.255.255.0 broadcast\
              134.88.255.255 
        /etc/ifconfig eth0 134.88.1.14 -trailers netmask \
              255.255.255.0 broadcast 134.88.255.0 
(networks)
	loopback        127
	physx		134.88.26
	cis-apollo      134.88.14
	ccs-gate        134.88.1
	semassu         134.88
(hosts)
	127.0.0.1       localhost
	134.88.14.1     osiris-tr       osiris
	134.88.14.2     tyr
	.
	.
	.
	134.88.14.53    dl_anubis
	134.88.1.14     osiris-gw
	134.88.1.1      IPGATE          ipgate  ipgate::
	134.88.26.1	SMUNIX		smunix	smunix::

	Smunix and ipgate have no troubles talking with each other and
when I change smunix's address to 134.88.1.26, it can talk to the apollo
gateway.  What are we going wrong?

					Thanks,

					Dave Hassel
PS:  We have also tried a netmask of 255.255.0.0 but then the gateway
can't even talk to 134.88.1.1

<hassel@bnlcl6.bnl.gov>
<benu@bnlux0.bnl.gov>
<ph_hassel@semassu.bitnet>

hanche@imf.unit.no (Harald Hanche-Olsen) (10/17/89)

The problems of David Hassel <benu@bnlux0.bnl.gov> are having remind
me of a similar problem of our own.  What we have discovered is that,
apparently, a bug in the Apollo networking software (tcpd?) does not
allow you to communicate with a directly attached subnet.  I don't
know if the network at Brookhaven uses directly attached subnets, but
ours does.  We have a class B network (129.241.0.0) on which netmask
255.255.255.0 is used, so that host 129.241.x.y is on subnet x.  Some
subnets are directly attached to one big ethernet, while others are
connected via gateways.  To get to a directly attached host
129.241.x.y from another, 129.241.u.v, say, the standard trick is the
following invocation, from the latter machine:

	route add 129.241.x.y 129.241.u.v 0

The magic is in the metric of 0, which announces that the machine is
directly available.  However, on our Apollos the above command causes
the route to be added with a metric of 1, rendering this trick useless.
In our case, the solution is to use netmask 255.255.0.0 and rely upon
ugly tricks like proxy ARP (a service kindly provided to us by the
local network management) to reach non-directly attached subnets.

Maybe Hassel is running into the same kind of problem?  As to his PS
remark, I think I can explain why netmask 255.255.0.0 does not work
for him:  Then the sequence

        /etc/ifconfig dr0  134.88.14.1 ...
        /etc/ifconfig eth0 134.88.1.14 ...

means that both interfaces are on the same network, which the
networking software will (correctly) reject.  Most likely, eth0 will
be marked down as a result of these commands(?).  If I have understood
the problem correctly, there is only one solution, and that is to
obtain a new network number (say, a class C one) to be used on the
token ring, and then use netmask 255.255.0.0 on the ethernet side.
Or, you can try to make Apollo fix the bug.  Good luck...  :-)

PS.  If there is no bug at all, I would be delighted to hear about it
and how to add a route with metric 0.  Or if there is a bug, maybe
there is a fix for it?  I am all ears...

- Harald Hanche-Olsen <hanche@imf.unit.no>
  The Norwegian Institute of Technology

vince@bcsaic.UUCP (Vince Skahan) (10/24/89)

we have over 15 subnets with various hosts either directly connected or
gatewayed in (on Apollos or other unixy token rings) and have no such
problem with essentially having to hard-route to find the subnet yyou're
connected to. If you run the /etc/routed everywhere, it should
plug-and-play (at sr9 or sr10).


-- 
     Vince Skahan            Boeing Computer Services - Phila.
    (215) 591-4116           ARPA:  vince@atc.boeing.com
                             UUCP:  bcsaic!vince
Note: the opinions expressed above are mine and have no connection to Boeing...