Welcome to the cavernous room of Krazy Dan's cave dedicated to routing. Routing refers to the way TCP/IP networking moves packets from their source to their destination. Each packet has a source and destination address. To deal effectively with routing, the first thing you need to know is what these ip addresses correspond to. If you think that each computer on the net has an ip address, you've got it WRONG and you need to go study that wall of the cave labelled TCP/IP Interfaces.
Once you have deciphered the ancient symbols on the interface wall, the next step toward victory over routing problems is to memorize the TCP/IP routing mantra. This provides the basic steps that TCP/IP goes through to route a packet. We call this a mantra because every time we encounter a routing problem, or explain how routing works, we are going to repeat these rules.
To introduce you to the way routing is set up and subsequently works, let's consider what happens on a functioning TSX-Online system which is connected to the net via a serial modem. Phonenet is in use and the connection between the modem and the provider is established through the SERVICE PROVIDER block in SY:SERVICES.PTY. This means that the TCP/IP interface is going to be PTA1:. Somehow, through the magic of Phonenet, that gets connected to a physical line with a modem but as far as TCP/IP knows, the serial device is PTA1:. Let us further assume that the IP address of the PTA1: interface is 200.5.5.5.5, and that a user on this system is attempting to connect to S&H, 204.181.142.11. Let's recite our mantra:
What happened here is that TCP/IP decided to send a packet to S&H through the PTA1: interface because there was a routing entry for 0.0.0.0 which tells the system that PTA1: is the gateway to the world. How did this entry get inserted into the routing tables, anyway? The short answer to the question is, "The PTYMAKE program did that because it saw the SERVICE PROVIDER block and realized that this TSX system was going to frustrate folks unless it made that routing entry for them. In the olden days, we would have required you to make your own routing entries by putting SET NETROUTE commands in your SY:NETLOGON.CMD file, but we try to make things a little more automatic these days.
So if the wildcard routing entry is created automatically, and the packets go out to the net, what's the problem? Why would we devote so much effort to explain something that works, perfectly and automatically, every time? The answer is that more complex configurations have more complex routing problems and may require manual intervention by you. Let's consider some of these topics now.
What happened here, in our routing mantra, is a snag caused by trying to carve up a block of IP addresses between ethernet and serial interfaces. One can well imagine that the designers of the mantra figured people would be using one or the other, but not both in the same address block. Since no ethernet card responded to the ARP request, no ARP entry got created, and the packet went nowhere. Yet TSX-Online does work in this configuration, so how? Once again, it's that sneaky PTYMAKE program. Upon seeing that you were creating a PASSTHRU type PTY in conjunction with the DEVICE ENA0: you specified in the SERVICE PROVIDER block, he created an ARP entry for you. Since the ARP entry directing TCP/IP where to send packets for 200.200.200.20 already existed, no ARP broadcast and wait for response was needed. The ARP entry was already there, and it told TCP/IP to send the packet... you guessed it... out PTA5:, the PTY line being used by our hero, your customer.
Before we proceed with more configurations and their routing implications, let's review three very useful ways to get information related to routing:
As we have said, TCP/IP assumes that IP addresses in the same "block of addresses" are in the same "network". This means that if you have an ethernet card which has a.b.c.2, and routing wants to get to a.b.c.81, it's going to ASSUME that it gets there through the ethernet card, and broadcast an ARP request and wait for an answer. Now, suppose you start out with a TSX system that is connected to the internet through an ethernet card to a router, and you decide that you want to have a downstream customer using 5 of your ip addresses connected through a serial line. What's going to happen when your system tries to route a packet to your customer, who is patiently waiting on the other end of the serial line to receive it? The answer is, NOTHING, unless you establish routing rules to override this network oriented search behavior and force the packets out the serial line. The complete picture:
REMOTE USER REMOTE ISP TSX YOUR TSX SYSTEM SANDH IN BELIZE SYSTEM IN MEXICO IN TEXAS a.b.c.44 a.b.c.45 a.b.c.46 a.b.c.47 a.b.c.2 204.181.142.11