Knowledgebase

Issue:

IP Dial-out link fails shortly after connecting with an ISP or other remote IP network.

Cause:

This problem occurs when the path from the client PC to the 833 involves going through an IP router. All TCP/IP computers rely on a routing scheme called default gateway routing. This mechanism is simple: to reach any computer not on the local network, and not specified by any other routing table entries, forward the traffic to a specified default gateway router. The gateway router generally knows how to forward the traffic correctly.

This approach has the disadvantage that it assumes that there is only a single connection to all of the external networks it may wish to reach. As will be seen, the above scenario does not fit into that category.

The default gateway concept works particularly well for a stand-alone PC that is dialing into a remote network. When a dial-up connection is established, a default gateway is assigned to route traffic through that connection.

The concept breaks down when your PC already has a default gateway (such as through a local LAN network), and a second default gateway is assigned by Dial-Up networking to reach a new network.

In our scenario, the client PC has a default router for its local LAN. When the ISP connection is made using Dialout, an additional connection is made into a remote network. The client PC is now connected to two different IP networks. This in itself is not a problem. Unfortunately, when the second connection is established, the first gateway (for the local LAN) is replaced by the more recent gateway (for the ISP) and computers which were reachable through the first gateway will no longer be visible.

Windows will change the metric for both the configured Default Gateway and the Local route to 2. The PPP connection will created as another Default Gateway route with a metric of 1.

This causes a problem when the 833 which was being accessed through the local router, is not longer reachable. In other words, when the client PC tries to access the 833, its message gets routed to the default gateway at the ISP (metric = 1) which has no knowledge of the local LAN network. Note that a DNS or WINS name server may also be one of the computers that is hidden thereby resulting in the inability to resolve computer names on the local LAN network.

Also note that devices on the local LAN network that are accessed without going through a router are still accessible. Hence if the 833 is local to the client PC this problem does not occur.

Again, as per the Microsoft TechNet CD, the destination server is located by checking the routing table and using the following process:

- If the destination IP address indicates that it is on the same IP subnet as the workstation's LAN adapter, then data is sent using the LAN adapter.

- If the destination IP address indicates that it is not on the same subnet as the workstation's LAN adapter, then data is sent to the default gateway. The default gateway then locates the destination route on behalf of the remote workstation.

In summary, TCP/IP default gateway routing is designed to work with computers that connect to a single network. A Dial-Up connection from a LAN-based PC results in two network connections. In this case, the default route will point to the most recent connection. When the Dial-Up connection is released, all connectivity to the first network will be restored.

Solution:

Basically, the TCP/IP stack on the client PC needs to know how to get to the 833 without using the default gateway.

As provided by Microsoft,
- If the default gateway IP address was previously configured for the LAN adapter, it is ignored by default. If required, the remote workstation can be configured so that the default gateway on the LAN adapter is used instead of the default gateway on the remote connection.

The workaround is to add a route entry to a destination network or computer by using the route command from a DOS prompt. For matching traffic, TCP/IP will use this route rather than the default gateway. The Windows host will create this static entry with a Metric = 1.

In our scenario, we need to specify the IP address of a local LAN router to be used to route traffic to the IP address of the 833. In this way, the TCP/IP stack will not send messages destined for the 833 to the default gateway.

Unfortunately, the effects of the route command are not permanent under Windows 95 and therefore must be re-entered upon restarting the client PC. This can be automated somewhat by creating a batch file and running it from the Startup group.

The following describes the use of the route command. An example of using the command follows the description.

Defining Static Routes in Windows
The route utility is provided with Windows when Microsoft TCP/IP is installed. The syntax for the route command is the following:
route [-f] [command [destination] [MASK netmask] [gateway]]

Note: persistant route entries are not supported on Windows with the exception of 2000 and XP. The -p option will enable the route to be persistant across reboots.

Example of using the route command

In our scenario, let us assume the 833 has an IP address of 192.48.132.17, the IP address of the client PC is 192.48.140.12 and traffic is routed from the client PC's local segment via a router at 192.48.140.3. This router is the default gateway for this segment. In order to ensure the client PC can still reach the 833 via the router after it establishes a connection with another external IP network one of the following route commands can be specified.
route add 192.48.132.17 192.48.140.3

- This command will add an entry to the routing table to only route traffic destined to the 833 via the router. In this case the default mask of 255.255.255.255 is used.
route add 192.48.132.0 MASK 255.255.255.0 192.48.140.3

- This command will add an entry to the routing table to route all traffic destined to the Class C subnet 192.48.132.0 via the router. Since the 833 is in this subnet traffic for it will also be routed.

Note: if the network can utilize the IPX protocol then the Dialout Client can be configured to communicate to the Perle 833 server using this protocol method. The dialout client will not be affected by IP route changes in it's communication link with the Perle server.