| |
In addition to using the optimization tools available for all WAN connection types, you can further optimize on-demand connections by minimizing how frequently the link is demanded by nonuser data.
Many items can demand the on-demand call. Because the primary benefit of an on-demand connection is that the connection is terminated when there is no more data to send to a remote LAN---thereby reducing line costs---it is in your best interest to keep the on-demand connection idle as often as possible. In some network topologies, routers must be configured very carefully to reduce the constant demand for connection, because such demand eliminates the cost benefit of on-demand connectivity.
If an on-demand connection is up too often, you can use PPPTRACE or X25TRACE in conjunction with LANalyzer® for Windows* software to determine what type of traffic is causing the problem.
An on-demand connection can be kept up by two kinds of potentially undesirable traffic: maintenance traffic and application traffic.
This topic contains the following sections:
An on-demand connection can be kept open constantly by several types of maintenance traffic. Common examples of this kind of traffic are Directory Services Synchronization, Time Synchronization, SPX keep-alive packets, and NCP watchdog packets.
NetWare 4 servers attempt to keep their databases synchronized across the network. The servers attempt to synchronize both the NDS database and the servers' times. This synchronization activity results in packets being exchanged frequently between the various NetWare 4 servers. Although this behavior is desirable on a LAN, it is not advisable when on-demand WAN links are being used. The result is that an on-demand connection will be in use all the time because of this background synchronization traffic.
Updates exist to correct the problems that these synchronizations can cause to on-demand connections.
If you are running applications that use SPX, such as NetWare for SAA*, SPX keep-alive packets can keep your on-demand connections up. If the link is open but idle, SPX sends keep-alive packets periodically.
If you are running applications that use OSPF or ICMP, their redirect packets can also keep your on-demand connections up.
WARNING: Be careful not to bind OSPF over on-demand links. OSPF redirect packets will keep your on-demand connection up, causing significant line costs.
An on-demand connection can be kept open constantly by several types of application traffic. These include NetBIOS traffic, NetExplorerTM discovery packets, and NetWare Management AgentTM traps.
Applications using NetBIOS send broadcasts that bring up on-demand connections. To eliminate NetBIOS traffic on IPX links, you can also configure NetBIOS filters. For more information, refer to Setting Up in the IPX documentation.
IMPORTANT: NetBIOS packets are not forwarded over IPX on-demand connections.
NetExplorer software in ManageWise includes a feature that discovers IPX and IP devices on the network by sending periodic discovery packets. The best way to minimize such traffic is to configure scoping ---a mechanism (available in ManageWise) that limits how much of the network is visible. You can configure the scoping to keep NetExplorer from sending discovery packets across the on-demand connection.
Traps generated by NetWare Management Agent also activate an on-demand connection if the traps must cross the connection to reach the ManageWise console. By configuring NWTRAP.CFG, the NWTRAP.NLM configuration file provided with NetWare Management Agent software, you can control the frequency and severity of traps reported to the console or prevent the agent from generating specific traps altogether. If you plan to use ManageWise to manage servers or routers over on-demand connections, refer to the Setup Guide for ManageWise 2.1 (or 2.0) for information about configuring NWTRAP.CFG.
The Novell Internet Access Server 4.1 routing software also provides packet filtering that can eliminate the traffic sent by a particular application, network, or node on a network. Packet filtering is available for IPX and IP routers. For information about configuring packet filtering, refer to Setting Up in the Filters documentation.
In a NetWare 4.11 or later environment, NDS is distributed across the network. When users or objects are added to the directory, they are added to the local copy of the database and then propagated throughout the network to other copies (replicas) of the database. If the same object is modified in two different replicas, the order of the modifications must be preserved to correctly propagate the changes. One way to ensure the correct ordering of directory events is to time stamp them. However, without a common time source, each NDS server can have a different reference time. Time synchronization solves this problem by synchronizing the time among NDS servers in the network.
In NetWare 4.11 and later implementations of TIMESYNC, the frequency of Time Synchronization packets is determined by the value of the Timesync Polling Interval parameter. The Timesync implementation in NetWare 4 versions prior to NetWare 4.1 (NetWare 4.0, NetWare 4.01, and NetWare 4.02) contained an error that caused Time Synchronization packets to be sent more frequently than specified by the Timesync Polling Interval parameter.
In NetWare 4.11 and later versions, the NDS synchronization logic checks regularly with each server in its replica list to determine whether any changes have occurred. In addition, NDS generates periodic update traffic, which propagates changes in the directory to each replica.
Frequent maintenance exchanges, such as Time Synchronization polling and NDS updates, can generate enough network traffic to keep Novell Internet Access Server routing software on-demand WAN connections active constantly. This can result in excessive costs for switched circuits supplied by outside service providers such as the local telephone carrier.
To resolve this problem, Time Synchronization and NDS NLM updates have been provided that allow improved user control over, and reduction of, maintenance traffic exchanges. This section provides information about installing and configuring these updates to minimize maintenance traffic over on-demand WAN connections.
There are four types of time servers: primary, secondary, reference, and single reference. Because primary, reference, and single reference time servers all provide time to other servers, they are frequently called by the general term time source servers.
Primary Time Servers---Synchronize network time with at least one other primary or reference time server and provide time to secondary time servers and clients. A primary time server gets time from the reference time server, polls other primary time servers on the network, and determines the correct network time.
Secondary Time Servers---Receive time from the time source server (primary or reference timeserver) and provide time to clients. A secondary time server gets time from one time source server and remains synchronized with that time source at all times. You can have multiple secondary time servers on your network.
Reference Time Servers---Provide time to which all other time servers and clients synchronize. The reference time server gets time from its hardware clock and provides time to primary and secondary time servers. It is recommended that you have only one reference time server per network.
Single Reference Time Servers---Provide time to secondary time servers and clients. A single reference time server gets time from its hardware clock and provides time to secondary time servers (if any exist on the network). Single reference time servers are primarily intended to be used on networks that have only one server and cannot coexist on the same network with primary or reference timeservers.
To reduce the frequency with which time synchronization packets are sent across an on-demand link, configure the network so that a minimum number of servers need to synchronize time across the on-demand link.
You can reduce the amount of time synchronization traffic sent across an on-demand link by configuring the time servers in a manner similar to that shown in Figure 2.
Figure 2
Time Server Configuration for On-Demand Link
In the network diagrammed in, only Servers B and D exchange time synchronization packets over the on-demand link. Time synchronization occurs as follows:
Server D (a primary time server).
SET DEFAULT TIME SERVER TYPE = <PRIMARY, SECONDARY, OR REFERENCE> NOTE: Server A is a NetWare 3.12 server. It has NetWare MultiProtocol Router 3.1 loaded and has been configured with an on-demand link.
The time server type for each server in a Directory tree is assigned by the system administrator at the time you create a Directory tree using the Directory option in INSTALL. Configure the WAN link between servers A and D as permanent and connected before setting up the Directory tree. The WAN link can be reconfigured as an on-demand link after the directory tree is created successfully and the time on all the servers in the tree is synchronized.
For more information about time synchronization, refer to Time Synchronization in Getting Started, Managing Network Time Synchronization in Supervising the Network, and Time Synchronization in NetWare 4 Concepts.
On a NetWare 4.1x server, complete the following steps to update the Timesync Polling Interval:
Reset the value of the Timesync Polling Interval using the SERVMAN utility.
Load SERVMAN.
Select Server Parameters, then select Time.
Change the Timesync Polling Interval to a value (in seconds) based on how frequently you want time synchronization information to traverse the on-demand link.
For example, 86,400 = 1 time every 24 hours.
Press Esc twice to exit SERVMAN.
The Update Options menu appears.
Select Update TIMESYNC.CFG Now.
This causes the changes to take effect now and to be in effect when the server is restarted.
Press Esc twice to exit SERVMAN.
At the NetWare console prompt, enter
SET TIMESYNC RESTART FLAG=ON
This forces TIMESYNC to begin polling for synchronization immediately, and the value of the TIMESYNC POLLING INTERVAL is updated.
IMPORTANT: Do not use the console SET command to change the TIMESYNC POLLING INTERVAL parameter. The console SET command does not write the change to the TIMESYNC.CFG file, and the parameter's old value will be read when TIMESYNC restarts.
Two NLM files are used to reduce the number of NDS synchronization packets. DSFILTER.NLM is a configuration utility used to set up the time windows controlling when NDS traffic is allowed to traverse the link. This utility requires that you enter the internal network address of each remote NetWare 4 server that exists in the replica ring. Make sure that each server lists the servers that are on the opposite side of the on-demand WAN link. The PINGFILT.NLM utility uses these addresses to determine what NDS traffic to filter. PINGFILT.NLM should run whenever NDS is running over an on-demand WAN connection. In Figure 3, PINGFILT.NLM should be run on Servers B, C, D, E, and F.
Figure 3 shows two LANs connected by way of Routers A and D.
Figure 3
NDS Tree Configuration
The network is configured as follows:
NOTE: In Figure 3, Server A is a NetWare 3.12 server and is not running NDS.
Every NetWare 4 server running NDS should be updated with the NDS filter NLM files (DSFILTER.NLM and PINGFILT.NLM) and configured to load the active filter module (PINGFILT.NLM).
Additionally, the DSFILTER.DAT configuration file must be present on each NetWare 4 server that attempts NDS synchronization over an on-demand WAN link. The DSFILTER.NLM utility can be used to create the configuration file on each server within the network.
Alternatively, the DSFILTER.NLM utility can be used to create a single configuration file for each side of the on-demand WAN link, and that file can be copied to all other servers residing on the same side of the WAN link. This reduces the configuration effort on each side of the WAN link.
Copy the following files to the SYS:SYSTEM directory of all servers in the Directory tree:
Configure the NDS filters on at least one server on each side of the on-demand WAN link. To configure the filters, complete the following steps:
Load the DSFILTER configuration utility from the NetWare command line.
The DSFilter Utility menu is displayed.
Select Filter Pass Through Times.
A screen appears displaying a grid of the days of the week and the hours in a day. The times are displayed and entered in UTC---Universal Time Coordinated (Greenwich mean time). For example, if you are in the Pacific Standard time zone, you are 8 hours behind UTC. Therefore, if you do not want to filter NDS packets at 10:00 p.m. on Tuesday local time, enter an X in the 06:00 a.m. Wednesday field.
To determine the difference between UTC and your time zone, enter the TIME command at the server console prompt. The last two lines of the output show the current time in UTC and local time. Subtract the UTC time from the local time (for example, 1600 - 2400 = -8 hours). If the result is positive, local time is that many hours ahead of UTC. If the result is negative, local time is that many hours behind UTC.
Mark with an X the times of the day you want to allow NDS synchronization packets.
Press Esc to save the changes.
From the DSFilter Utility menu, select List Filter Addresses.
Press Insert to add a server to the list.
The prompt Enter the Network Address appears.
Press Insert to display a list of servers on the network.
Use the arrow keys to select a server, then press Enter to add it to the list. If the server you want is not on the list, enter it at the Enter the Network Address prompt.
NOTE: DSFILTER is a configuration tool and need not be loaded by the AUTOEXEC.NCF file.
Press Esc to save your changes.
Instead of manually configuring the NDS filters for each server, you can copy the files from the first server installed on one side of the WAN link to all other servers on the same side of the WAN link.
Copy the DSFILTER.DAT file from the SYSTEM directory of the originally configured server to all the NetWare 4.x servers located on the same side of the WAN link.
The DSFILTER.DAT file is created in the SYSTEM directory by the DSFILTER utility.
Load PINGFILT.NLM on all NetWare servers that are in the same Directory tree.
To ensure that all NDS databases are synchronized, load the PINGFILT.NLM with the -dnnn parameter. This option allows PINGFILT to delay its operation nnn minutes after loading. The number of minutes to delay depends on the size of the NDS tree.
WARNING: Make sure PINGFILT is loaded after DS is loaded and fully initialized.
The load line (LOAD PINGFILT -dnnn) can be added to the AUTOEXEC.NCF file to achieve autoloading of the PINGFILT.NLM utility whenever these servers start up.
| |