Is your WAN on the wane? LAN spoofing may help solve some of your woes.
Jeffrey Fritz
Network protocols love to talk. They are constantly sending packets to and fro filled with all kinds of information. Not all the chatter contains user data, however. Although most users aren't aware of it, a significant amount of behind-the-scene LAN traffic is dedicated to the protocol's management functions.
Nearly all network protocols spend time sending and receiving packets for management purposes. The nature of the packets varies from protocol to protocol. Many protocols send out keep-alive messages to various network devices, which ensure that all devices are present and accounted for. Network protocols also keep track of topologies, maintaining information abo
ut where devices are located and how they can be reached. This information is shared by exchanging routing tables across the network and by updating them on a regular basis.
How often keep-alive messages and routing updates are sent across a network depends on the LAN protocol. Some protocols send updates infrequently, every few minutes or several times an hour. Others are much more aggressive, sending out updates every few seconds. For example, the AppleTalk NOS (network operating system) sends out RTMP (Routing Table Maintenance Protocol) updates every 10 to 15 seconds. Users tend to see this traffic as overhead; network engineers see it as essential. Either way, management packets are busy running the network, representing traffic that an end user never sees but depends on for reliable connectivity.
When running on a LAN, protocol management packets simply place more traffic on the network. LAN bandwidths are wide enough that the extra management packets are seldom noticed. WANs, however, are
an entirely different matter. When protocol overhead is added to normal user traffic, it can contribute to link saturation and slow-downs, particularly for slower speed WAN links.
However, there is an even worse culprit. Unlike LANs, which operate on a connectionless service, WAN links are, more often than not, connection-oriented services. Connections are physically made and, for switched digital services, charged on a usage basis. Because of this, WAN links are often configured to bring up the connection only when there is traffic destined for the remote network. They drop the connection when there is no traffic passing over the link.
The Theory
In theory, traffic-based switched WAN connections save money because the connection is not billed unless user traffic is present. The savings can be significant. In the case of a user who has taken a break from a workstation or PC, dead time can be from minutes to hours. Because there is no user traffic, the connection can be kept down during that
time and the billing reduced to zero. In reality, the protocol makes a call every time it sends out network routing updates or keep-alive messages, and it incurs charges, even though no user is involved. WAN devices add to the traffic and the expense by regularly exchanging their own internal routing or bridging tables.
A potential solution to this problem is a process called LAN spoofing, and spoofing aptly describes the technology. According to Webster's, the term spoof means ``to delude by underhanded methods.'' LAN spoofing places the WAN in a stealth mode, where the WAN network devices, such as bridges or routers, answer for the remote devices.
For instance, if a Novell file server sends out a SAP (service advertising protocol) packet, the enterprise-side WAN device will not place a call to the remote side to pass the SAP (see the figure ``Spoofing Reduces WAN Traffic.''). Instead, it will acknowledge the SAP for the remote LAN. This fools the server into believing that the remote LAN is st
ill connected, although the connection is down and the user is disconnected.
A Hot Topic
Implementing LAN spoofing is a hot topic among WAN vendors. Although it is a recent concept for WAN networking, it is not new to other services. A form of spoofing has been in use for some time with IBM's SNA (Systems Network Architecture). The SNA protocol is used primarily for communications between IBM mainframes and remote synchronous terminals.
One of SNA's characteristics is a continuous handshaking between devices. On dedicated or switched lines, a master/slave relationship exists between the communications controller and the remote unit, resulting in constant polling between devices. Some vendors took this into account in designing their SNA communications devices.
To spoof SNA, the controller-side device automatically answers the status inquiries (polls) intended for the terminal. Simi-larly, the remote-side communications device answers for the controller. Both sides are happy, even thoug
h there is no actual response from the far side. Also, traffic over the serial connection is minimized, giving improved throughput to user data.
Interestingly, SNA uses a different tactic over LANs. It sends out a keep-alive or an ``are you still there'' message every 5 or 10 seconds. Therefore, it qualifies for the same treatment as other LAN protocols.
It's Not Nice to Fool Mother Nature
Spoofing attempts to fool a network into thinking that disconnected remote devices are really connected. Therefore, the technique defeats a network's native ability to assure itself that everything is as it should be. A NOS is designed this way for good reason. Vendors need to learn how to accomplish spoofing without causing serious grief to a user or a network. A network can be spoofed for only so long before management traffic must be allowed to pass. This may be a maximum of a few minutes, or it could be 24 hours. No one is sure just how long the spoofing time should last.
There are other serious
spoofing issues. Network protocols send out keep-alive messages to validate that devices are present and accounted for. What if something really happens to a remote device while the connection is down? The device may crash, be rebooted, power off, or hang. Whatever the case, it is likely to come up in a different state than it was in. However, the spoofed network doesn't realize that the workstation was down. The fact that it has reconnected in a different manner than the network expects leads to a myriad of potential problems, particularly for file servers where reconnected users may wind up being logged in multiple times.
Another frightening possibility could occur when two LANs are remotely connected but not currently on-line with each other. During the time when user traffic is not present and the link is down, the topology of one of the LANs may change. Perhaps a user will turn off a workstation or move a device from one LAN segment to another. The LAN being spoofed is unaware of these changes. It
s routing table still contains entries for old topology.
Now suppose user data causes the remote LAN to reconnect. During the next routing-table update, the two networks suddenly realize that their routing tables are different. The network has a decision to make: Which routing table reflects the real network topology, and which is out of date?
Rewriting NOS
Instead of spoofing, some LAN NOS vendors are reevaluating how they handle keep-alive messages and routing updates. Most LAN protocols were written when interconnections of LANs were relatively rare. The designers could count on all the devices on a network being attached to the same physical wire. About the worst thing they had to worry about was repeater delays.
Today, WAN connections are much more prevalent. It may be time for major rewrites of LAN protocols into WAN protocols, taking into account switched digital connections. Although this is easier said than done, there has been some recent activity in this area. Apple, Novell,
Microsoft, and other companies have been working to integrate WAN technologies into their network protocols. However, this complex process is going to take some time. A start has been made, but much more work still needs to be done.
ISDN D-Packet Solution
There may be another way to solve the management problem. ISDN D-packet connections may be well suited to handle management functions. The D channel is an ISDN packet service that provides 9600-bps bandwidth in addition to the 64-Kbps circuit-switched B channels. ISDN network devices can take advantage of the D channel for control and management of WAN devices.
Using the D channel, it would no longer be necessary to bring up a circuit-switched call just to transmit a keep-alive message or to update a routing table. Because D packet is a connectionless service, packets are routed through the packet handlers in the central office switch and sent out to their destinations, with no circuit-switched connection to bring up.
Interestingly,
the D channel's primary function is control and management of ISDN devices and connections. It was designed from the ground up for exactly this purpose. Therefore, it lends itself well to control and management of ISDN WAN devices. Users are charged on a per-kilopacket basis for D-channel connections. Because management packet size tends to be small compared with user data packets, these charges should be nominal and reasonable.
Unfortunately, the down side to D packet is that it's not widely deployed in North America. A number of ISDN exchanges offer no D-packet service, and D channels are not always connected to the national PDNs (public data networks). When D-packet service is available, it is often restricted to connections within the local switch, making it difficult, if not impossible, for vendors to implement across-the-board D-channel management. Users could access the D channel for local device management but not for devices outside the local switch.
Despite this limitation, many vendor
s believe that D-channel management is viable, and they plan to implement it once telephone service providers support it. Unfortunately, the carriers do not seem to be in any hurry to improve deployment of D-packet service.
The ultimate solution for dealing with management protocol traffic is still somewhat elusive, with many options to choose from. One thing is sure: With the ever-increasing number of telecommuters and remote-office WAN connections, it won't be long before users have a solution that is both efficient and cost effective.
Figure: Spoofing Reduces WAN Traffic
The enterprise bridge responds to the keep-alive message rather than sending it to the actual device, reducing WAN traffic.
Jeffrey Fritz is a telecommunications engineer for West Virginia University. He is the author of Sensible ISDN Data Applications (WVU Press, 1992). He can be reached on the Internet at
jfritz@wvnvm.wvnet.edu
or on BIX c/o ``editors.
''
Network Spoofing
