Network Information Library

Virtual Connections

Shivaź devices support both Personal Computer (PC) single-user dial-in and LAN-to-LAN virtual connections. Virtual connections reduce Integrated Services Digital Network (ISDN) connect-time costs and increase ease-of-use and management. Virtual connections are supported for both Internet Protocol (IP) and Internetwork Packet Exchange (IPX) protocols over Point-to-Point Protocol (PPP) connections.

Note: Currently, there is no Macintosh* client software available that supports Virtual Connections. Virtual Connections only work for PCs that can run ShivaRemote 4.0 or higher.

For more information, see the following topics.

What are Virtual Connections?

Spoofing

Floating Virtual Connections

Over-Booking Virtual Connections

Analog and Digital Line Support

Timeout of Suspended Virtual Connections

When Not to use Virtual Connections


What are Virtual Connections?

A virtual connection is an enhanced PPP connection that suspends and resumes the physical (telephone) connection in a manner that is transparent to applications. The physical connection is suspended when there is no "meaningful" data transferred during a specified period of time. The physical connection resumes again when there is meaningful data.

Meaningful data includes specific requests to access or transmit information through the connection, such as reads or writes to a file server, database access, mail, and keystrokes on a virtual terminal protocol.

Non-meaningful data includes routine network maintenance packets. This includes the chatter of the network protocols and packets sent solely to determine that application connections are up.

A virtual connection can be in one of two states:

Up

A virtual connection is up when the physical connection is established and data is being passed across a connection.

Suspended

A virtual connection is suspended when the physical connection is down but the Shiva devices (and ShivaRemote) on either end of the connection are maintaining the connection information. A virtual connection resumes the up state when data is received that must be sent over the connection.

Spoofing

Spoofing enables Shiva devices on either end of a connection to view all of the available devices, user connections, and network resources (such as other Shiva devices and hosts), without opening the physical connection. This reduces network costs. A virtual connection can stay suspended for long periods without any disruption to the network or applications.

Spoofing is done at two levels:

At the network protocol level (IP and IPX) to tell all the routing and information protocols that the connection is up, when it is really suspended.

At the application level to allow each end of any connections (file server mounts, virtual terminal sessions, and so on) to answer any connection test probe packets so that they will think the other end is still physically connected.

The network level spoofing involves making the routing protocols (RIP for IP, RIP and SAP for IPX*) believe that the suspended connection remains up, even when periodic update packets are not being received over the suspended connection.

For application spoofing, the Shiva device examines each packet it receives. If the packet is one of several types of application "keep-alive" packets, the local Shiva device pretends (spoofs) that it is the remote end of the application connection, and sends an appropriate response packet back. This allows the endpoints of the connection to think that they remain connected, without having to resume the physical connection to send the packet. Since many protocols send these "keep-alive" packets as often as once a minute, spoofing is necessary to allow the virtual connection to be suspended for any substantial period of time.

Application spoofing only takes place after the Shiva device determines the contents of the packet. If the packet contains application data, the physical connection is brought up (resumed) and the application data is sent. If the packet contains only connection maintenance information, spoofing continues.

Floating Virtual Connections

A virtual connection may resume its connection on a line other than the line where the original connection was made; this is called a floating virtual connection. However, the connection must resume on the same Shiva device. The "floating" feature eliminates the need to dedicate any particular resources to each virtual connection.

Over-Booking Virtual Connections

The use of floating virtual connections allows the network administrator to configure a Shiva device for more virtual connections (over-booking) than the number of available physical connections.

Note: The default Shiva device configuration does not allow for over-booking of virtual connections. It may be configured for up to 200 virtual and physical connections.

There are hazards to over-booking. If too many suspended connections resume at once, they can exceed the available resources. In this case, any virtual connection that attempts to resume and cannot get resources will be completely dropped. This will cause the cessation of spoofing for that specific session, and all application connections over that virtual circuit are likely to be lost.

Therefore, do not configure the Shiva device for over-booking unless you are certain that not many connections will resume at once.

Analog and Digital Line Support

Virtual connections are ideal for ISDN connections that have quick connection times. With ISDN, resuming a suspended virtual connection is so fast, it is nearly transparent to the user.

Analog dial-up connections may take up to 30 seconds to resume suspended virtual connections, due to modem connection times. Therefore, dial-in virtual connections will experience a delay in resuming suspended connections. This delay may exceed the time-out period for certain applications that are running over the connection.
To avoid application time-outs, the user initiating the dial-in connection must increase the application time-out value to exceed the amount of time it takes to resume the virtual connection.

In addition, for virtual connections to operate most effectively, where possible, disable any auto update or probe features in the applications used by dial-in and other users who will access data through a virtual connection.

Timeout of Suspended Virtual Connections

By default, the management tools are configured to disconnect suspended virtual connections that have exceeded the maximum suspend time of 72 hours. You can change the maximum suspend time value using shell commands or manually disconnect the user. If you set the maximum suspend time to zero, the management tools never automatically disconnect a suspended virtual connection.

As an example of why this is important, consider a dial-in user workstation connection to a Novell* file server. The workstation's virtual connection suspends, and then the workstation is powered down. The spoofing function in the Shiva device will make the file server think that the user is still there. This will cause the file server to maintain a "slot" for that user and workstation. Since Novell file servers are licensed by the number of slots, this may keep other users from accessing the file server if there are few spare slots.

When Not to use Virtual Connections

There are cases where virtual connections may not be beneficial:

With extremely dynamic LAN-to-LAN configurations. If there are frequent routing changes, or service changes in IPX, and you need to have the latest information on these changes, do not use virtual connections.

When network layer routing protocols freeze the information available over a LAN-to-LAN link. You do not learn about changes in this information until there is meaningful data that brings up the LAN-to-LAN link

When interactive response time is important. Even over ISDN, the call setup time is more than a user generally wants for an interactive response time to typing. If you are using an application with long pauses that needs high response time, do not use virtual connections.