IP addresses are not selected at random, they are assigned by certain administrators within your organization. However, the ultimate authority on IP addresses comes from the Network Information Center (NIC), which arbitrates the whole Internet.
The IP address for a PPP-client is determined by the IP network to which the PPP-server is connected. There are 3 general cases to consider, and one special case (also referred to as a "borderline" case).
The first cases deal with stand-alone or isolated machines. There is a fuzzy dividing line between "a few" and "a lot" of standalone hosts wanting to be PPP-connected to one network. 1-5 hosts is definitely "a few", 50 is definitely "a lot". The difference is that "a few" puts the clients on the same IP network as the server(s). Conversely, "a lot" puts all the clients on their own "ppp-net", using another IP network number. IP network numbers are in limited supply, so it makes sense to not "waste" them.
In this case, the easiest solution is to use an IP address on the network of the server. The client sets up a default route through the PPP interface, and the server does a "proxy arp" for the client. This makes the least demands on routing. On the client, the rest of the world is accessed via the PPP interface and the server acts in proxy for the client for packets going the other way. The client has it's Ethernet interface disabled, using one of the following techniques:
For example, let's connect an Indigo via PPP to an Internet site. We can
understand the process by following a packet during the operation
`ping sgigate.sgi.com`.
204.94.209.1.
204.94.209.0 network. The only one that matches is
"default" and points to the PPP interface.
route add net default server 1
Note: For IRIX-5.1 and later this can be done automatically by the slip or ppp process, see the man pages.
arp -s client `netstat -ian | grep :` pubThe part of the command `netstat -ian | grep :` returns the active ethernet address of the server. The ethernet address is changed by DecNet (4DDN) software, among others. Note that this command will fail if the server has multiple hardware interfaces, or has the Appleshare software installed, and you will have to determine the correct ethernet MAC address by a different mechanism, and hard-code it in the script. See the man page on
arp.
It has been reported that some networks require the trail
keyword (see the arp man page), I don't know what
circumstances would require it.
proxy_arp=ifname
Where ifname is the name of the interface that the
client IP address is part of.
Each client gets an IP address on the ppp-net. The client needs to setup a default route such as the one described above. The server can use the standard Irix routed configuration (although adding the "-F ppp-net" option to the router increases the available bandwidth). The client does not need to disable the Ethernet port unless it needs to communicate with other hosts on the ppp-net. In this case, both hosts need to disable the default network interface (above). You could, in fact, set up a small remote LAN using the ppp-net, but you would forever give up the ability to communicate with other, non-local, hosts on the ppp-net. In addition, routing to let the other machines communicate would be very tricky.
You can use the ppp-net with servers on multiple nets provided the routers on ALL possible routes between the networks pass host routes correctly. Currently, IRIS routers do this, but Cisco routers do not in older software releases, though they can be configured to not break things too badly. I don't know about other routers. This is the most "hands-off" mechanism, but is usually not justifiable for small numbers of PPP hosts.
localhost=0,0
The advantage to the server is obvious -- minimum usage of IP addresses. The disadvantages are not so obvious: security is slightly weaker (one less bit of information a cracker needs), and the client can't use dynamic dialing mode ("quiet" mode for IRIX PPP) since the route can't be defined before the connection starts and the addresses have been negotiated. In addition, all existing TCP connections would fail if you got a different IP address when you reconnected.
The PPP-client has a static default route to the PPP interface as in the
previous case. However, because it runs gated, it advertises
the default route to the other machines on the LAN.
If the server is running IRIX-4.x, then it will need to run
gated (5.x and later routed seems to do the correct thing) to
advertise the network route via the PPP link to the remote LAN. In
addition, the next level router(s) may have to have it's (their)
configuration modified to know about the additional IP network for which
it must route. Since gated is difficult to configure, other
approaches include setting up a static route on each of the client-side
hosts, or have another machine, such as a router advertise the route.
Note: Click here for sample /usr/etc/gated.conf files. These configurations have been known to work in some cases, but I am definitely not a gated expert!.
If the server is running IRIX-5.2 or later, then routed and ppp seem to do the correct thing in most environments.
All the hosts are assigned IP addresses from the IP network of the PPP-server. The server performs a proxy-ARP for all of the remote hosts. In addition, the PPP-client needs to ARP for each of the hosts on the other side for which they want a connection. At a minimum, this is the nearest router, the mail relay (if any), and any server machines. In addition, the client has a static default route pointing to the PPP interface and each of the other machines needs a static default route pointing to the PPP-client. The gory details, based upon an actual case, can be seen here.
Because of the need to maintain the ARP tables up-to-date, moving machines around can cause mysterious failures of the network. Note: Because of ARP caches, changes to the ARP tables via the ARP command may not take affect immediately. This can cause routing problems until the cache expires after the ARP mapping is explicitly deleted (via `arp -d` on IRISes, or removing the host), or times out. The ARP cache timeout is 20 minutes on IRISes and defaults to 4 hours on Cisco routers, and is very vendor dependent.
arp -s client `netstat -ian | grep :` pub ppp -r client arp -d clientIf problems persist, it is probably best to assign a different IP address for remote operation, even though they are on the same network.
While the principles are the same as above, one factor makes it much more difficult: you have no control over routing on your ISP's end of the connection!. It doesn't matter that you've done everything needed on your end to route packets from your other machines to the machine with the modem (or ISDN, etc) connection, and you can get your connected machine to route packets back to your other hosts, if the ISP doesn't route packets from the Internet back to your network, you're out of luck.
There are 3 main methods to connect a network of hosts to the Internet. In all following descriptions, I will refer to the host with the Internet connection as a gateway:
All the mechanisms require that all your hosts be able to get nameservice. If your gateway is a proxy, then your gateway must run a nameserver or at least nameserver forwarding code. The first and third mechanism require that all your hosts have a default route to your gateway machine, and they can use that as a route to your ISPs nameserver. If the link will not be up permanently, then some mechanism of seperating your local nameservice from the Internet nameservice is required.
Nameservice for the local machine is handled by the /etc/resolv.conf configuration file (in addition to /etc/nsswitch.conf for IRIX-6.4 and later). To supply nameservice for your network, and to forward requests to your ISP's nameserver, you need to run named on your gateway machine.
The theory of the various routing mechanisms is described above. How do you go about finding and fixing routing problems? You always start close and work your way away. I recommend installing the optional subsystem eoe2.sw.ipgate, which contains a few useful tools, the most important being /usr/etc/traceroute.
First, check to see that you have a route to your destination. For most stand-alone clients, this usually means a default route. You check the status of networking stuff using the /etc/etc/netstat command. For example, to get the status of your network interfaces:
% netstat -in Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll ec0* 1500 192.0.2 192.0.2.1 0 0 0 0 0 lo0 8304 127 127.0.0.1 49150 0 49150 0 0 ppp0 1500 192.132.120 192.132.120.14 321347 0 246809 0 0And to get the available routes:
% netstat -rn Routing tables Destination Gateway Flags MTU RTT RTTvar Use Interface 127.0.0.1 127.0.0.1 UH 0 0 0 47763 lo0 192.132.120.14 127.0.0.1 UH 0 0 0 1247 lo0 default 192.132.120.1 UG 0 0 0 245797 ppp0 224.0.0.0 192.132.120.14 U 0 0 0 2397 lo0The key here is the existence of the default route. A routing table like this is sufficient to get anywhere that routing on the server side allows.
The first test is make sure that you can ping your server, in this example 192.132.120.1:
% /usr/etc/ping 192.132.120.1 PING 192.132.120.1 (192.132.120.1): 56 data bytes 64 bytes from 192.132.120.1: icmp_seq=0 ttl=64 time=248 ms 64 bytes from 192.132.120.1: icmp_seq=1 ttl=64 time=249 ms 64 bytes from 192.132.120.1: icmp_seq=2 ttl=64 time=248 ms ----192.132.120.1 PING Statistics---- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 248/248/249 msAt least your PPP link is working! Now try to get somewhere else. Let's try (note that traceroute needs to run as root):
# /usr/etc/traceroute -n www.sgi.com traceroute to www.sgi.com (192.82.208.8), 30 hops max, 40 byte packets 1 192.132.120.1 239 ms (ttl=64!) 240 ms (ttl=64!) 239 ms (ttl=64!) 2 192.82.184.1 240 ms 241 ms 241 ms 3 192.82.184.1 241 ms (ttl=254!) !H * 241 ms (ttl=254!) !HThis shows that packets can get to 192.82.184.1, but it doesn't know how to get to www.sgi.com (192.82.208.8). Therefore, your routing is fine, it is your ISP (or your server network) that is having routing problems. In this case, you can't do anything except call Your support contact for help.
traceroute is a way of determining the path that packets take on their way from the source location to the destination location. traceroute is a potentially dangerous command, since it picks "random" ports to probe to determine a path, unlike /usr/etc/ping, which uses pre-defined ports. ping can do a lot of tracing, but it isn't as powerful for complex problems as traceroute.
I hope and intend that this documentation can help you with your PPP connection problems. My other commitments (like work) permitting, I will attempt to help you on issues not covered, or that you are unclear on. Please make sure that you provide me a valid return email address! (I won't try to fix it).
Scott Henry <scotth@sgi.com>
Last modified: Sun Feb 1 13:52:11 1998