[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Date: Thu, 10 Dec 87 11:47:49 +0100
I have run this problem by the German Lispm users group, and the
comp.protocols.tcp-ip newsgroup on uucp, with no response. I have
also asked my Symbolics rep. Please help if you can.
Someone from International Customer Support should be contacting you or
your rep very soon to help you get things straight. In the meantime, I
can try to answer some of your problems for the list.
Problem: Even though I believe I have set up the namespaces right, I
cannot get the Symbolics to route to machines not directly on the
Ethernet to which it is connected. I can try to establish a
connection from the other direction, and this gets routed to the
Symbolics, but since the Symbolics doesn't somehow find the host
acceptable, the connection gets refused.
How I set it up:
1. There is a separate (namespace,site,network) triple for each
individual physical network. [This was my Symbolics' reps advice
to me, and indeed there are variables in the IP-TCP code with names like
"network-and-site-name" or some such which imply that whoever wrote
it planned for it to be that way. It didn't work any better when all
the hosts were in one namespace, the way I set it up initially.]
The way you set it up in the first place is correct. All the hosts in
your physical site should be in the same namespace, site, and on the
same network of type INTERNET in order for Symbolics machines to
communicate with them over IP-TCP.
2. Each gateway host has an entry for both networks, and the services
- gateway ip internet-gateway
- gateway ip internet-gateway-prime
This is the same service list configuration that a German university
is using with an external gateway, but their configuration is somehow
different, and all of a sudden they don't want to give out more details.
The Lispm doesn't care about GATEWAY IP INTERNET-GATEWAY-PRIME but that
doesn't matter. The gateways must have addresses on the same network as
the lispms (same in the namespace sense).
3. Hosts on the same network can establish connections with each other with
no problem, so they have all the end user right services.
Yet when I try to connect to a host on the other network, I get an
error message stating that the connection service I am requesting is
not supported by the remote host, followed by a lists of the services
supported by the local and remote hosts (both of which contain the
This is because the network that the other host is on is not the same
network (in the namespace) as the network the lispm is on.
Has anyone succeeded in getting a non--trivial network configuration
to work with the Symbolics software? Even Symbolics? The "ARPAnet"
interface software they deliver seems to be "hardwired" for a single
network of Symbolics on a Chaosnet interface to the big monolithic
ARPAnet via a Symbolics machine serving as a Chaosnet-to-TCP-net
gateway. That is just not the case here. I hacked it around to fit
our situation, but I seem to be missing the proper incantation.
I believe you are talking about the TCP-GATEWAY service that some hosts
offer that allows a host to talk chaos to the gateway which encapsulates
the chaos packets into IP packets and transmits them onto the
destination host. This is a secondary protocol that is used when direct
TCP service is not available. The gateway server code is part of IP-TCP
in 7.2 but it does not offer the kind of service that direct TCP
At Symbolics we use IP-TCP constantly, locally and to the ARPA-Internet.
We have gateways that connect us to the Internet and to other networks
What's the secret? Tracing through the code, it seems that a new
network protocol is needed, (when I substitute the TCP/Chaos protocol
in, it does the routing ok, and then crashes because the streams don't
have the right properties), however certain TCP hackers (who only know
Unix) around here tell me this is nonsense --- that routing takes
place in the IP layer, and I should never see it.
Please read the installation information for IP-TCP and the information
in book 9 very carefully. You might not have your services configured
correctly or you might not have an appropriate subnet mask set up.
There could be other things that are not set up right. You should be
able to work this out with the support people. In any event having each
physical network in its own namespace is very wrong.