StreetTalk for Windows NT Administrator's Guide
Chapter 1 - Server-to-Server UDP
Using the Server-to-Server UDP (S-to-S UDP) software, StreetTalk for Windows NT servers route VINES packets to other Banyan networks, and route VINES packets from other Banyan networks to destinations in their own networks. VINES packets contain data that originates from StreetTalk for Windows NT programs, such as Intelligent Messaging and the StreetTalk Naming service.
StreetTalk applications on servers that are not equipped with the S-to-S UDP software can transparently route data through IP networks. This is accomplished by first routing data to a server equipped with the S-to-S UDP option.
Figure 1-1 shows StreetTalk for Windows NT server A routing data to StreetTalk for Windows NT server B, which, in turn, routes data through an IP network to StreetTalk for Windows NT server C running the S-to-S UDP software.
Server A, which does not have the S-to-S UDP software installed, can route data to Server B for transmission through the IP network. This occurs automatically and does not require any special action on the part of users or administrators.
When a server sends a VINES packet, it contains the VINES IP address (the server's VINES serial number) of its destination. If that destination can only be reached through IP networks, a server equipped with S-to-S UDP software must map the VINES IP address of the destination to an IP address. This IP address is placed in the IP header that encapsulates the VINES packet, and is used to route the packet through the IP network.
The IP address can identify one of the following:
![]()
The destination server if it runs S-to-S UDP software. or
![]()
A gateway server that runs S-to-S UDP software. When a destination server does not run S-to-S UDP software, it does not have an IP address that has significance for VINES packets. (The server can be running TCP/IP and have an IP address.) Thus, the IP address that is placed in the packet must identify a gateway server that has a StreetTalk for Windows NT route to the destination. Once the packet reaches that gateway server, it can be forwarded to the destination using VINES IP.
Figure 1-2 shows how servers equipped with S-to-S UDP route a VINES packet from a source StreetTalk for Windows NT server to a destination StreetTalk for Windows NT server.
When VINES packets leave Server A destined for Server D, they contain Server D's VINES IP address as a destination in the VINES IP header. (The header has both A's address and D's address but only D's address is relevant.) Using VINES IP, Server A looks at this address and routes the packet to Server B.
When Server B looks at the VINES IP address, it also looks at its routing table. Based on information in the routing table, Server B knows the following:
![]()
The only way it can reach Server D is through Server C. ![]()
Server C can be reached only through an IP network. ![]()
Server C's IP address and serial number (VINES IP address).
Server B encapsulates the packet in a UDP packet and then an IP packet. The IP packet contains Server C`s IP address and information that indicates the packet has VINES data. The packet is routed through the IP network to Server C.
In Server B's routing table, Server C's IP address (160.234.1.2) is mapped to Server C's serial number (1146796).
Based on information in the IP header, Server C knows the following:
![]()
The IP packets contains a VINES IP packet. ![]()
The packet is to be unencapsulated ![]()
Based on its VINES IP header, it is destined for Server D.
Server C then unencapsulates the packet - removes the IP and UDP headers - and routes it to Server D using VINES IP.
When a VINES packet is routed through an IP network, it must be encapsulated in a UDP packet and transmitted as an IP packet because IP networks transmit IP packets, not VINES IP packets.
The S-to-S UDP software performs encapsulation. When a server equipped with the S-to-S UDP software has to route VINES packets through an IP network, VINES IP software must pass the packets to UDP and IP software. The reverse process happens when VINES packets are routed directly to the server from an IP network as shown in Figure 1-3.
Packets that originate from StreetTalk for Windows NT servers start out as VINES packets. They remain VINES packets for their entire trip through the network as long as they do not have to pass through IP networks. A sample VINES IP packet is shown in Figure 1-4.
However, if the VINES packet must travel through an IP network on its way to a destination, a Banyan server with the S-to-S UDP software installed must encapsulate the VINES packet within a UDP packet and then within an IP packet.
For example, assume that Server A in Figure 1-2 has mail to send to Server C. The packets containing the mail remain VINES packets until they get to Server B. Server B knows that the packets must pass through the IP network before they reach Server C. Server B encapsulates the VINES packets within UDP packets and then IP packets. The packets look like the one in Figure 1-5.
The packets are routed through the network to Server C. Server C then unencapsulates the VINES packet.
Server Configuration for Server-to-Server UDP
The next sections describe how to configure StreetTalk S-to-S UDP software.
You can configure S-to-S UDP support on servers on directly connected networks and on servers on remote networks.
A directly connected network is a physical network segment connected directly to the StreetTalk for Windows NT server by the server's network adapter. A remote network is a segment not directly connected to the StreetTalk for Windows NT server but reachable through an IP network.
When a StreetTalk for Windows NT server is connected to another StreetTalk for Windows NT server located on another network, a packet from the first server might take more time to reach the remote server than a packet from a server connected to the same network as the first server.
For example, in Figure 1-6, StreetTalk for Windows NT Server 1 is located on the same network as the StreetTalk for Windows NT Server 2. To connect to Server 2, Server 1 sends the server a packet directly over Ethernet. Server 1 also connects to Server 3 and Server 4 on another network. To connect to Server 4, Server 1 must send a packet over Ethernet, then through the IP network, and finally over a Token-Ring network.
Routing Metric
When a server sends a packet and too much time elapses before receiving a response, the sender assumes the packet did not reach the destination and retransmits the packet. This is referred to as timing out. To avoid packets timing out during transmission, you can modify the routing metric.
A routing metric is an approximation of the amount of time (in 200-millisecond increments) required by the network to move a packet from one server to another server and back again to the first server. The value of the metric for a given link reflects the relative transmission speed for the medium. The slower the medium, the higher the metric. What metric you assign depends on whether the servers are on directly connected networks or remote networks.
VINES Sequenced Packet Protocol (SPP) and VINES Interprocess Communications Protocol (IPC) use the metric to set time-outs for connections with a remote server or to other servers that use this remote server as a gateway.
Metrics for Directly Connected Networks
StreetTalk for Windows NT communications can set the metric for each network based on the type of adapter in the StreetTalk for Windows NT server. For adapters StreetTalk communications recognizes automatically, the metric is the default metric used for VINES IP without encapsulating in UDP plus a configurable metric increment. This increment compensates for the extra overhead of encapsulating the VINES IP packet in UDP.
Note: If the speed of a network is not known (for example, is the network a 4 Mbps or 16 Mbps Token-Ring?), the metric for the slowest network of that type is used.
The range of the metric increment is 0 to 500. The default is 2. In most cases, the default increment is sufficient.
If StreetTalk communications cannot recognize the adapter in the local Windows NT server, the total metric is configurable. All networks connected by unrecognized network types then use the same metric.
The default metric for unrecognized network types is 10 and the range is 1 to 500.
Use the largest metric applicable to your network when there are multiple unrecognized adapters.
The types of network adapters that StreetTalk communications can recognize in the StreetTalk for Windows NT server and their metrics before an increment is added are shown in Table 1-1. Table 1-2 lists the types of networks and the metrics that can be assigned.
Network Adapter |
|
FDDI (Fiber Distributed Data Interface) |
|
Ethernet |
|
Token-Ring |
|
ARCNET |
|
Type of Media | Routing Metric |
Fiber Distributed Data Interface (FDDI) |
|
10 Mbps Ethernet/16 Mbps Token-Ring |
|
10 Mbps ProNET-10 |
|
4 Mbps Token-Ring |
|
2.5 Mbps ARCNET |
|
1 Mbps StarLAN, Omninet, and LANSTAR |
|
2 Mbps PC-NET |
|
Serial Line 56000 baud |
|
Serial Line 9600 baud |
|
Serial Line 4800 baud |
|
Serial Line 1200 baud |
|
Fractional T1 1536 Kbps |
|
Fractional T1 1024 Kbps |
|
Fractional T1 768 Kbps |
|
Fractional T1 512 Kbps |
|
Fractional T1 384 Kbps |
|
Fractional T1 256 Kbps |
|
Fractional T1 128 Kbps |
|
Fractional T1 64 Kbps |
|
Metrics for Remote Networks
Only the total metric is configurable for remote networks that are automatically connected.
The default metric for these networks is 10 and the range is 1 to 500. All remote networks use the same metric, either the default or one that you configure.
When remote servers are on more than one remote network, use the largest metric. For example, if some servers are on FDDI (metric=1) and other servers are on 4 Mbps Token-Ring (metric=4), the metric for these servers is 4.
If you want to manually configure servers to connect to, you need the hostnames or IP addresses, and serial numbers of all the servers outside your StreetTalk for Windows NT network that have S-to-S UDP software and that you want to communicate with. If you have the IP address, you do not need the hostname.
Caution: Only one server in a StreetTalk for Windows NT local network should run S-to-S UDP and act as a gateway to the same IP network; do not have redundant links. If two servers act as gateways between two StreetTalk for Windows NT networks, both running S-to-S UDP, and one server fails, that server may have incorrect routing information when it reboots. This is because S-to-S UDP is dependent on other services and takes time to start, thus the routing table is established before S-to-S UDP is ready. You can have multiple S-to-S UDP servers in one network as long as they do not each create a path to the same remote networks.
Names and Serial Numbers
The serial number of a StreetTalk for Windows NT server is displayed on the Network Communications dialog box after StreetTalk for Windows NT software is installed.
Once servers are able to communicate, they exchange their names and serial numbers using VINES protocols. Typically, these servers reside on the same network.
Selecting an IP Address
Servers may have a single IP address or multiple IP addresses.
For servers that have only one IP address, associate that address with the name or serial number of the server. Typically, end nodes have only one IP address.
For servers with multiple IP addresses, you should use the address that corresponds to the IP network that the two servers will use to communicate. Other addresses may also work, but performance may be degraded because the packets will be routed through a longer path between the servers.
Note: The S-to-S UDP configuration program attempts to look up the IP address associated with the hostname. You may not need to know the IP address if you know the hostname.
Subnetwork Mask
The subnetwork mask allows the server to send subnetwork-directed broadcasts rather than sending separate broadcast packets to each server on every configured S-to-S UDP connection. No subnetwork broadcasts are made to pre-StreetTalk for Windows NT 8.6 servers.
Specific Values for Subnetwork Masks
There are many valid values for subnetwork masks, depending on the length of the subnetwork ID, but field lengths of 0 (no subnetwork), 4, and 8 bits are commonly used. Table 1-3 provides the decimal dot values for these subnetwork masks for the three address classes supported by VINES.
IP Address Class | No Subnetwork Field | 4-bit Subnetwork Field | 8-bit Subnetwork Field |
Class A | 255.0.0.0 | 255.240.0.0 | 255.255.0.0 |
Class B | 255.255.0.0 | 255.255.240.0 | 255.255.255.0 |
Class C | 255.255.255.0 | 255.255.255.240 | Not supported |
See the Banyan TCP/IP Guide for a discussion of subnetworks, subnetwork masks, subnetwork mask values, and IP address classes.
Metric Values
You can specify the routing metric for the StreetTalk for Windows NT server that you add as a remote destination. The metric is an estimated round-trip delay time associated with a route in 200-millisecond units called ticks.
The routing metric that you enter should be the sum of the metrics of all links between the server that you are configuring and the remote server plus an increment for overhead associated with encapsulation. Use Table 1-2 as a guide. If a particular data link that you use is not in the table, substitute the value for a similar type of link. You should configure the same metric on both servers connected by S-to-S UDP software.
If the routing metric on your server or on the server to which your server is connected is too low, a time-out problem may occur when you attempt to run StreetTalk services across the link. If there is a time-out problem, you may see the message "Appropriate StreetTalk is unavailable."
As an example, suppose you want to determine the routing metric for the connection illustrated in Figure 1-7.
The routing metric for a server-to-server connection between Server 1 and Server 2 in Figure 1-7 is the sum of the metrics of the intervening links plus an increment of 2 for overhead. The routing metric you should specify is 53, which is the total of the three links plus the increment:
Metric = 2 + 45 + 4 + 2 = 53
The total metric should be large enough to accurately represent all the links between your server and the remote server. A metric that is greater than it needs to be falsely associates a higher "cost" (delay) with that server-to-server link. This could cause packets to be routed over another path that has a smaller metric but which is really more "costly" (slower).
Specify the routing metric when you add a remote server. After you add the metric, the change takes effect immediately if S-to-S UDP is enabled and running when you make the change.
Automatic connectivity allows your server to establish connections and routes with many other servers without manually specifying each server's serial number or hostname, and IP address. However, you must configure one side of each connection manually.
If you have a mixed network with VINES and StreetTalk for Windows NT servers, you should enable automatic connectivity for only one VINES server or enable automatic connectivity on directly connected subnetworks for only one StreetTalk for Windows NT server on a particular subnetwork. That is, you should enable automatic connectivity on only one server on a directly connected subnetwork in a mixed environment. You can have automatic connectivity on remote subnetworks enabled on multiple StreetTalk for Windows NT servers.
Changing the Server-to-Server UDP Configuration
After you enable S-to-S UDP support, you can perform the following tasks:
![]()
Enable or disable automatic connectivity of servers on directly connected or remotely connected networks. ![]()
Change metric values and enable or disable broadcasts to remote subnetworks for manually and automatically connected servers. ![]()
Add, modify, or delete manually configured connections. ![]()
Enter the subnetwork mask when configuring manual connections. ![]()
Enable or disable remote subnetwork-directed broadcasts. Note: Do not enable S-to-S UDP software unless your server requires it. Enabling S-to-S UDP support consumes server resources and causes the StreetTalk Naming service to broadcast additional packets on your network that can impair its performance.
To perform these tasks, display the Configure S-to-S UDP Communications dialog box (from Programs, StreetTalk for Windows NT, StreetTalk Server Configuration, Network, Network Communications, Enable server-to-server UDP support, Configure). Figure 1-8 shows the dialog box with server entries.
Click the Enable automatic connectivity checkboxes to enable or disable connectivity on directly connected or remotely connected networks. The change takes effect immediately if S-to-S UDP software was enabled since the last reboot. Disabling automatic connectivity removes any automatically configured server entries immediately.
To change a manual connectivity configuration for a server, select the server entry, enter new values for hostname, IP address, metric, or enabled status, and click Modify. The changes take effect immediately if S-to-S UDP software was enabled since the last reboot. You cannot modify a server serial number. The connection must be deleted and a new entry added with a new serial number.
If you add a server entry, enter the serial number, hostname or host IP address, and click Add. The server entry is dynamically added and your server is connected to the remote server if Enabled is checked.
Note: It is recommended that you always enable any connection that you add.
Click Delete to delete the currently selected connection. The configuration program checks that the server serial number is valid and then deletes the connection immediately.
Connections are either Enabled or Disabled. If you change the status of a manual connection and S-to-S UDP software has been disabled since the last reboot, the status reflects the configured status, not its operational status. The connection is enabled only when the server is rebooted and S-to-S UDP software is enabled.
Click Default to display the default metric settings associated with automatic connections if you changed those settings. If you change the metrics for servers automatically connected, you must reboot your server for the changes to take effect.
Click Cancel to exit the S-to-S UDP configuration program. The original default metrics associated with automatic connections are restored. The metric for a manual connection is restored if you did not select Add, Delete, or Modify. If you entered new values and selected Add, Delete, or Modify, you exit the program but the new values are preserved. Cancel does not affect enabled or disabled automatic connections.
Click OK to save your changes and to exit. The Network Communications dialog box is displayed.
When you exit the configuration program, the Bindings dialog box displays bindings messages as network protocol and the network adapter bindings are checked for changes.
Reboot your server if you changed any metrics associated with automatic connections.
Reboot your sever if you changed any settings on the Network Communications dialog box. For example, if you enable or disable S-to-S UDP or UDP Client support, you must reboot your server.
You do not have to reboot your server if S-to-S UDP software was enabled when the server was last booted and you make changes to manually configured connections.
Table 1-4 summarizes how the configuration changes are activated. S-S Enabled means that S-to-S UDP software was enabled when the server was last booted. Dynamic means that the changes occur immediately, and Reboot means that the server must be rebooted for the changes to take effect.
|
|
|
||||
Enable/Disable | Metric | Enable/Disable | Metric | Enable/Disable | Metric | |
S-S Enabled | Dynamic | Reboot | Dynamic | Reboot | Dynamic | Dynamic |
S-S Disabled | Reboot | Reboot | Reboot | Reboot | Reboot | Reboot |
Troubleshooting Server-to-Server UDP
If the S-to-S UDP option does not operate properly, perform one or more of the following operations as described below:
![]()
Check TCP/IP. ![]()
Check the interface. ![]()
Check Security Settings. ![]()
Display network neighbors.
The S-to-S UDP option is used between two servers so it is important to troubleshoot both servers.
Run the PING command from the system prompt to verify that a TCP/IP route has been configured to the remote host. If you cannot ping the remote host, the S-to-S UDP connection will not be established.
To confirm that S-to-S UDP is being used as an interface by the StreetTalk for Windows NT communications software when your server has more than one LAN interface, follow these steps:
1. Physically disable the interface over which VINES IP traffic runs.
2. Check StreetTalk for Windows NT statistics in Performance Monitor to confirm that encapsulated VINES IP packets are still being received and sent over the IP interface. For example, if no VIP packets are shown as being received or sent over the IP interface, assume that S-to-S UDP software or the interface is not working.
Check the security settings for the S-to-S UDP link. Make sure that the security is set the same for both servers on the link.
Managing VINES Security describes how to manage internet security.
Display Servers Connected by S-to-S UDP
Sometimes you cannot display all servers connected to each other only by a S-to-S UDP link when you run a program that lists servers. This problem may occur after services are stopped and the server's StreetTalk database is not updated. Run the network management program described in the next section to check the servers connected to your server.
When using Server-to-Server UDP, you get better performance by configuring a tunnel directly to a destination server rather than going through a series of intermediate tunnels. When two servers communicate frequently for long periods of time, configure a Server-to-Server UDP tunnel.
In some cases, servers may need to communicate infrequently for short periods of time (for example, a user may want to access a little-used file service), and this may result in a series of Server-to-Server UDP hops. In Figure 1-9, all packets from Server A to Server C must be forwarded through Server B, increasing the delay and adding to the load on Server B, Server C, and the network.
To allow Server A to communicate directly with Server C without having to explicitly configure a tunnel, VINES and StreetTalk for Windows NT can:
![]()
Generate redirects over S-S UDP tunnels ![]()
Receive and process the redirects
In Figure 1-9, Server B sends a redirect to Server A telling Server A to go directly to Server C. Server A processes this redirect, creates one end of a redirect tunnel to Server C, updates its routing tables, and starts sending packets directly to Server C. Server C then creates the other end of the redirect tunnel so it can receive packets directly from Server A. Server C does not change its routing tables to send back directly to Server A until Server C sends a packet to Server A through Server B and Server B redirects Server C. Similarly, Server C can redirect Server A and Server D if there are other servers on the network.
Server A can also send a packet to a UDP client through Server B, and Server B can then send a redirect to Server A telling it to communicate directly with the client. Server A updates its routing tables to communicate directly with the client but does not create a redirect tunnel.
Redirect tunnels are created between servers running VINES or StreetTalk for Windows NT 8.6 or greater only. If a manual or automatic connection already exists, a redirect tunnel is not created.
When a redirect tunnel is created, its metric is the same as the current multi-hop route to the server. After the first redirect in the above example, Server A can reach Server C directly. Server A's routing table network entry is updated with the new preferred gateway information (the network entry for Server C now has a gateway of Server C), the network metric remains unchanged, and the new gateway is added as a neighbor in Server A's neighbor table.
Redirect tunnel establishment is the same as configuring a manual or automatic connection. That is, the access level is negotiated using each server's Internet Access list. Redirect tunnel establishment does not compromise Internet Access Security. For example, if both servers have restricted access, the redirect tunnel is not created as unrestricted. As with configured connections, if Server A has a restricted tunnel to Server B, and Server B has a restricted tunnel to Server C, but the Internet Access lists on both sides do not prevent it, an unrestricted tunnel between Server A and Server C results.
A redirect tunnel that is idle and its associated routes dissipate after the neighbor table entry for the server at the other end of the tunnel ages out (even though the server is still up). The age-out period is 6 minutes. Idle means that no packets are received over the tunnel. Every time a packet is received, the idle timer for the neighbor entry is reset. As long as packets are received, the neighbor does not age out, and the tunnel and routes remain. If you set a drive and a redirect tunnel is created as a result, the tunnel is not considered idle because packets are sent to maintain the connection even if you do not use the drive. When you unmap the drive, the timer starts counting down. When the neighbor times out, the neighbor table entry for the server is removed, the tunnel is removed, and any routes through that server are no longer valid. Other routes are found to contact that server.