Chapter 13 - Topology Information
This chapter tells you how to access and interpret topology information from a server. Topology information shows you the current network topology as viewed by each server. VNSM shows you the server's routing tables and provides a VINES route trace feature that allows you to learn the details of a route between two servers in the network.
The topology information function of VNSM allows you to view the following types of topology information from servers:
VINES Neighbors VINES Routes TCP/IP Routes AppleTalk Routes
In addition to these topology information types, VNSM also allows you to trace a single route between two VINES servers.
To view topology information, choose SHOW topology information from the VINES Network Summary menu. The Topology Information menu appears, as follows.
This menu allows you to access the available types of topology information on the server. The menu always displays VINES neighbors and VINES routes. The menu displays TCP/IP routes if the server is equipped with the TCP/IP Routing option or the TCP/IP Server-to-Server option. The menu displays AppleTalk routes if AppleTalk is configured on the server and the appropriate option is installed.
To display topology information, choose one of the available information types from the Topology Information menu.
To trace a VINES route, choose TRACE a route from the VINES Network Summary menu.
The sections that follow describe the types of topology information that you can view, and how to trace a VINES route. Remember that you can press F10 to request an immediate update while viewing this information. Keep in mind that with the exception of timers and status flags, this information changes infrequently.
If you choose VINES neighbors from the topology information menu, the screen that appears displays the Table of Neighbors, which contains entries for each neighbor server and each neighbor DOS, Windows, or OS/2 workstation that runs VINES.
Since Macintosh workstations use AppleTalk protocols to communicate with VINES servers, the Table of Neighbors does not have entries for Macintosh workstations. The server uses AARP cache entries to address neighboring Macintosh workstations. See Appendix A for more information on AARP cache entries.
From the perspective of the server that you are monitoring, a neighbor server is directly connected to it in one of the following ways:
A LAN A point-to-point connection, which includes HDLC and asynchronous lines, X.25 virtual circuits, T1 LAPD connections, and ISDN B channels A TCP/IP network or an SNA network
A neighbor VINES workstation is directly connected by LANs, serial lines, or X.25 virtual circuits.
Figure 13-2 shows a server, JPTOK001, that has two neighbor DOS workstations and a neighbor server on a Token-Ring LAN, and a neighbor server that is reached through a T1 LAPD connection.
To view VINES neighbors, select VINES neighbors from the Topology Information menu. The Neighbors screen appears, as follows.
The server's name and serial number are displayed in the Server and NetId fields. The total number of neighbors is displayed in the upper right corner.
Note: The Neighbors screen shows workstations that run VINES workstation software only. It does not show workstations that run AppleTalk.
Interfaces
Information is displayed for each interface on the server, including any servers or workstations currently running VINES software that connect to the server through that interface. An interface can be either a LAN card, a point-to-point connection, a TCP/IP Server-to-Server connection, or an SNA Server-to-Server connection.
For each LAN interface displayed, the screen shows you the slot number and LAN address of the card. A LAN address is the physical address, such as an Ethernet address, of a server or workstation on a LAN.
For example, in Figure 13-1 the LAN address of server JPTOK001 on the Token-Ring LAN is:
10 00 5a 74 85 fa
JPTOK001's LAN address on the Ethernet LAN is:
02 60 8c 89 21 74
For each HDLC or asynchronous line, VNSM shows you the slot number/line number combination of the line. For HDLC lines only, VNSM tells you the role (DCE or DTE) of the server that you are monitoring and the role of its neighbor on the line. For asynchronous lines only, VNSM displays an internal identifier that the server you are monitoring assigns to the line.
You also can use the Neighbors screen to identify which X.25 VC you should clear. The local session number for the VC used to connect to a remote site appears directly above the remote server's network ID, as well as to the left of the network ID.
Connections other than LANs, HDLC or asynchronous lines, or X.25 VCs are identified as follows:
Ignore the slot numbers and link addresses for T1 LAPD connections and ISDN B channels. The slot number displayed is really an internal unit number that the server uses to keep track of LAPD connections and ISDN B channels. The link addresses are meaningless.
Neighbor Servers
The Neighbors screen contains an entry for each neighbor server. Each entry contains the server's network ID and the server's name. A network ID identifies a VINES logical network. Each server forms a logical network. DOS, Windows, and OS/2 workstations reside within the network. The network is logical because it does not map to a specific LAN or serial line, but can span all the LANs and serial lines that are connected to the server.
A server's network ID is its serial number.
VINES 5.50 Considerations
When neighbor VINES 5.50 servers cannot communicate, they always remove one another's routing table entries.
The server considers the following connection types to be WANs:
HDLC or block asynchronous serial line T1 LAPD ISDN B channel X.25 network TCP/IP network SNA network
Neighbor Users and Workstations
If a user is logged in from a workstation, the user's StreetTalk name appears on the Neighbors screen under the interface that connects the workstation to the server that you are monitoring. For example, Isoroku Fujiyoshi is logged in over the Token-Ring LAN. If no one is logged in, but VINES workstation software is loaded, no user name is displayed. Inactive nodes, such as powered-down workstations, do not appear.
The StreetTalk name of a neighbor user who is logged in over a LAN appears next to the LAN address of the LAN card in the user's workstation. When a user is logged in over a PC Dial-in line, the user's StreetTalk name appears under the slot number/line number combination that identifies the line. When the user is logged in over an X.25 VC, the user's name appears under the X.25 VC. If the VC is connected to an X.25 or ISDN switch, the port number of the switch is displayed.
For each neighbor workstation, VNSM also displays the network ID (netid) of the workstation. A workstation's network ID matches the network ID of its routing server. A routing server assigns a workstation with its VINES internet address, which consists of a network ID and a unique ID within the network called a subnetwork ID, when the workstation connects to the network. When VINES workstation software is loaded, the workstation sends out ARP queries for a network ID on the LAN or serial line to which it is connected and a server eventually responds. The first server that responds becomes the workstation's routing server. In most cases, the server on the LAN with the fastest processor responds first.
For example, the network IDs of the workstations shown in Figure 14-1 are 02000512 and 02403840. These network IDs correspond to the network IDs of server JPTOK001 and server JPTOK002. This means that all the workstations shown on the menu are getting their network IDs from either JPTOK001 or JPTOK002. One workstation is in JPTOK001's logical network and the other is in JPTOK002's logical network.
The workstation does not always get its network ID from the same server each time VINES workstation software is loaded, or from the same server from which it gets its VINES Files service.
When the workstation reboots, it may have two entries on the Neighbors screen. The old entry is aged out of the server's routing table after 6 minutes and the more recent one is used.
Note: The VINES 5.00 routing implementation is the same as the VINES 4.xx routing implementation.
For VINES 4.xx and VINES 5.00 workstations, routing servers provide routing information when the workstation needs to communicate off the LAN. The routing server also acts as a reference for network nodes off the LAN that want to communicate with the workstation. If the routing server goes down, these nodes cannot send data to the workstation once the entry for the routing server is removed from their table of networks. The workstation can still communicate with neighbors with which it has established an SPP connection.
See the next section, "VINES Route Information," for more information on the table of networks.
A VINES 4.xx or VINES 5.00 workstation does not always use its routing server to route off-LAN traffic. Any neighbor server may route off-LAN traffic from the workstation if it is the least costly route.
For VINES 5.50 workstations, routing servers provide routing information whenever the workstation needs to communicate outside its routing server's logical network. Unlike a VINES 4.xx or VINES 5.00 workstation, a VINES 5.50 workstation keeps routing table entries only for its routing server's logical network and for the logical networks for the servers and workstations with which it currently communicates.
For VINES 4.xx, VINES 5.00, and VINES 5.50 workstations, if the routing server becomes unavailable, all the workstations that received VINES internet addresses from the server become orphan workstations. An orphan workstation is one that loses its routing server. Keep in mind that a server can still act as a routing server as long as the kernel is running (for example, in a case where someone shuts down server software but does not power off the server). The user must reboot the workstation and load BAN again to pick up another routing server, if one is available.
For example, suppose that JPTOK002 suddenly became unavailable as the result of a LAN card failure, and all the workstations on JPTOK002's LAN ran VINES 5.50. The workstation that got its VINES internet address from JPTOK002 would become an orphan, and Isoroku Fujiyoshi would not be able to communicate with any other server or workstation in the network except for neighbors on the same LAN cable with which Isoroku's workstation established SPP connections prior to the loss of the routing server.
The following sample screen shows what the Neighbor's screen would look like if JPTOK002 suddenly became unavailable:
Notice that Isoroku's workstation still has JPTOK002's network ID, even though JPTOK002 is no longer on the network. Isoroku would have to reboot his workstation to pick up JPTOK001 as his routing server.
If the workstation does not reboot, the workstation can still use the routing server when it returns to the network. For example, if JPTOK002 goes off the network and then quickly returns, Isoroku does not have to reboot. A short period of time should be allowed to elapse so that the server can send out routing update packets to the workstations. These packets tell the workstations that the routing server is on the network.
When you choose VINES routes from the Topology Information menu, the VINES Routes screen appears. A sample screen follows.
The top part of the screen displays the name of the server that you are currently monitoring, its network ID, and the number of routes in the routing table. For example, the sample VINES Routes screen tells you that JPTOK001 is the server you are monitoring, the server's network ID is 02000512, and 24 routes are in its routing table.
The rest of the screen displays the contents of the Table of Networks. Each server keeps a Table of Networks, which acts as a routing table. The routing table contains an entry for each VINES route to another server in a network.
What Is a VINES Route?
A VINES route consists of a chain of interconnected servers in a network. The servers are connected by physical media, such as Ethernet and Token-Ring LANs, HDLC lines, T1 LAPD connections, or X.25 networks.
For example, the route between the server
JPTOK001 and the server USCHI002 appears to server JPTOK001 in
its Table of Networks as follows:
Figure 13-6 illustrates this route.
Notice that the route between JPTOK001 and USCHI002 is through one intermediate server, USCHI001. An intermediate server in a route is called a hop. A route can go through one or more hops, or no hops at all. Routes that have no hops connect servers on the same physical medium. For example, the route between USCHI001 and USCHI002 has no hops because both servers are directly connected by a Token-Ring LAN.
Each route entry in the routing table contains several fields that provide VINES routing software with information that it needs to perform the following actions:
To make correct routing decisions when routing packets to their destinations. To manage the routes. The routing software needs to know information such as which routes can be used, which routes cannot be used, and which route entries should be deleted from the routing table.
The fields for each routing table entry are as follows:
Destination Gate Metric TTL Flags
These fields are described in the following sections.
This field displays the name and network ID of the route's destination server. The network ID is the serial number of the server.
This field always displays the network ID, but does not always display the server name. Some typical reasons why the name does not appear are described below:
A restricted link is configured somewhere along the route. Restricted links prevent StreetTalk information, such as server names, from being broadcast through the network. The server's kernel is running, but the StreetTalk service on the server is not. This means that the server can still broadcast routing updates, which contain the server's network ID, but not StreetTalk updates, which contain the server's name.
This field displays the name and the network ID of the server that acts as the first hop from the server that you are monitoring to the destination server. The first hop is a router that shares a common physical medium, such as a LAN or HDLC line, with the server that you are monitoring. Note that the terms router and gateway are often used interchangeably.
For example, in the sample network in Figure 14-2, the server USCHI001 acts as the first hop for network traffic that is sent from JPTOK001 to USCHI002.
If the destination in the route entry is a neighbor of the server that you are monitoring, the server name and network ID of the destination will also appear in the gate field of the route entry.
This field displays the metric for the route in decimal. A routing metric is an estimated, round-trip delay time associated with the route that maximum-sized VINES IP packets will take to the destination server. The routing metric value is specified in 200-millisecond intervals called ticks.
Routing metrics are used by VINES IP to select the least-cost route to a destination. VINES IP selects the route with the lowest routing metric.
A routing metric value of 65535 indicates that the specified server is unreachable. Servers become unreachable because of any number of problems, ranging from serial line breaks to a server failure.
The exact metric value for a routing table entry depends on the number of hops to a destination and the type of intermediate data links.
Some metrics for popular data links are as follows:
For example, the metric for the route between JPTOK001 (in Tokyo) and USCHI002 (in Chicago) in Figure 13-2 is 4. The routing software on JPTOK001 adds the metric for the Ethernet-to-T1 link (2) to the metric for the 16-Mbps Token-Ring link (2).
Notice that the Ethernet-to-T1 link has a metric of 2. The Ethernet-to-T1 bridge makes the link appear as an Ethernet LAN to JPTOK001 and USCHI001. As a result of this appearance, the two servers assign a metric of 2 to the link instead of a full T1 or fractional T1 metric.
In another example, the route to AUSYD001 (in Sydney) in the sample VINES Routes screen has a metric of 92. The routing software on JPTOK001 adds the metric for the Ethernet-to-T1 link (2) to the metric for the 9600-bps link (90) that connects AUSYD001 to USCHI001.
T1 LAPD Metric
The routing metric for T1 LAPD connections is based on the number of DS0s used. A DS0 is a communications circuit. The formula for calculating metrics for T1 LAPD connections is as follows:
46 - (number of DS0s)
For example, if two servers use 6 DS0s to communicate, the metric is 40.
ICAplus FT1 Metric
The routing metrics for fractional T1 LAPB communications with the ICAplus card depend on the line speed specified when the HDLC line is assigned. Some sample metrics are as follows:
TCP/IP Metric
The routing metric for a TCP/IP Server-to-Server connection defaults to 25 on all servers and is configurable on VINES 5.50 servers. For example, assuming that a metric of 30 is configured, the cost for reaching a destination that is one hop away, using an Ethernet LAN and a TCP/IP Server-to-Server connection, is calculated as follows:
30 + 2 = 32
Figure 13-7 illustrates this example.
See the Banyan TCP/IP Guide for more information on configuring TCP/IP.
SLR Metric
The default routing metric for reaching destinations using the source-level routing protocol is calculated as follows:
(number of intermediate bridges * 5) + local interface metric
For example, if two servers communicate with each other through two IBM Token-Ring bridges, and both servers use 4-Mbps Token-Ring cards to communicate, the routing metric is calculated as follows:
(2 * 5) + 4 = 14 ticks
Figure 13-8 illustrates this example.
If USCHI021 were on a 16-Mbps Token-Ring LAN, the metric it would use to reach USCHI002 would be 12. In contrast, the metric that USCHI002 would use to reach USCHI021 would be 14.
On VINES 5.50 servers, the metric for source-level routing is configurable. See Managing Communications for more information.
This field displays the time-to-live (TTL) timer for the route's entry in hexadecimal. This timer is the amount of time before the entry is removed from the called server's routing table. The value is returned in 90-second units. For example, a value of 1 indicates 90 seconds.
The next section discusses the TTL implementation in VINES 5.50.
VINES 5.50 TTL Implementation
When you monitor VINES 5.50 servers, the TTL timer is 0xffff in most cases. VINES 5.50 servers regard a routing table entry as permanent until they receive explicit notification that the entry's gateway to the destination network, or the destination network itself, is not reachable.
The TTL timer has a value other than 0xffff only in the following situations:
Destination servers have encountered a network event, such as a metric change or a new server coming online, and the server that you are monitoring has an X.25, TCP/IP, or SNA network. Destination servers are no longer reachable.
Routing table entries have flags that provide internal routing software with descriptive information about the entry, such as whether the destination network is reachable. A flag is a bit that is set to either 1 or 0.
Each routing table entry has a 16-bit field that is used for setting flags. The value of this field is displayed in hexadecimal. The value depends on the specific bits that are set. For example, if bits 0 and 1 are set the value of the field is 0x3.
The individual bits and their meanings when they are set are listed below. A bit is set when its value is 1. Note that the hexadecimal values in parentheses assume that just the specified bit is set. Keep in mind that multiple bits can be set.
Bit 0 (0x1)
The route can be used.
Bit 1 (0x2)
The destination is a server.
Bit 2 (0x4)
The entry is for a neighbor. This bit is set for entries in the Table of Neighbors only. It is never set for entries in the Table of Networks.
Bit 3 (0x8)
This routing entry should be deleted.
Bit 4 (0x10)
This flag applies to DOS, Windows, and OS/2 workstations only. It will not be set in the server's routing tables.
Bit 5 (0x20)
This flag is set in the Table of Neighbors only. It is not visible through VNSM.
Bit 6 (0x40)
This flag is set in a routing table entry on an ENS for UNIX, VINES 4.xx, VINES 5.00, or ENS 1.0 server to indicate that the entry was modified. For example, the cost for reaching the destination may have changed or the destination server may have become unreachable.
On ENS for UNIX, VINES 4.xx, VINES 5.00, and ENS 1.0 servers, the VINES RouTing Update Protocol (RTP) also uses this flag to determine whether the entry should be included in a routing update packet that is sent across a WAN connection, such as a leased line or TCP/IP network, to a neighbor ENS for UNIX, VINES 4.xx, VINES 5.00, or ENS 1.0 server. When the line, PVC, TCP/IP Server-to-Server, or SNA Server-to-Server connection first initializes, the servers on both ends exchange full routing update packets, which include the servers' full knowledge of the network.
After the initial routing update packet exchange, these servers include only new entries and changed entries from their routing tables in routing update packets. Thus, new routing entries, entries marked for deletion, and changed entries have 0x40 associated with them.
This flag is set in a routing table entry on a VINES 5.50 server only if the following conditions are met:
The server has ENS for UNIX, VINES 4.xx, VINES 5.00, or ENS 1.0 neighbor servers on a WAN, such as an HDLC line or a TCP/IP network. The entry has been modified because of a network event, such as a new server coming onto the network.
By setting this flag, the VINES 5.50 server guarantees that the updated entry is included in the next update sent to ENS for UNIX, VINES 4.xx, VINES 5.00, or ENS 1.0 WAN neighbors.
Bit 7 (0x80)
This flag applies to DOS, Windows, and OS/2 workstations only. It never shows up in server routing tables.
Bit 8 (0x100)
This flag indicates that the neighbor associated with this entry is reached through a TCP/IP or an SNA network. Servers that communicate using the TCP/IP Server-to-Server option are neighbors on the TCP/IP network that connects them.
Bit 9 (0x200)
This flag indicates that the entry was created by an RTP redirect packet. An RTP redirect packet tells a server about a better route to a destination than one that the server chose to use previously. DOS, Windows, and OS/2 workstations also receive redirect packets.
This flag is set in the routing tables of VINES 4.xx, VINES 5.00, ENS for UNIX, and ENS 1.0 servers only. The flag indicates that the metric in the routing entry is in the first suppression period. The first suppression period takes one minute and serves as the first check to make sure that an updated routing metric is reliable. A routing entry is suppressed when one of the following events occurs:
Unreachable, Non-Neighbor Server
The local server has a routing table entry for a remote server that is not a neighbor and the metric for reaching that server is 65535, which indicated that the remote server was unreachable. Then, a new metric for the remote server was received, indicating that the remote server is reachable. For one minute, the local server "advertises" that the remote server is unreachable, even though the local server has received a new metric. The local server performs the advertisement through broadcasts of routing update packets every 90 seconds.
The local server advertises that the remote server is unreachable to prevent the formation of circular routes in the network. When the one minute period is over, the second suppression period begins. (See the description of the 0x800 flag for more information on the second suppression period.)
For example, if Server A is the local server and Server B is a remote server that is marked as unreachable in Server A's routing table. Server A receives a routing update packet that indicates that Server B is reachable. Server A copies the new metric from the packet into its routing table, but for a period of one minute Server A includes the original metric (65535) in the routing update packets that it broadcasts. If the new metric does not change for the one minute period, Server A can be sure that the new metric is reliable. A second suppression period of one minute begins to make sure that the metric is reliable.
During the second suppression period, the local server still advertises that the remote server is unreachable. (See the description of the 0x800 flag for more information on the second suppression period.)
Reachable, Neighbor Server
The local server's routing entry was for a remote server that is a neighbor and the local server received a better metric for reaching that server. In contrast to the event described previously, the remote server does not have to be unreachable - a better metric can trigger the first suppression period. For one minute, the local server advertises that the remote server is unreachable (the local server does not advertise the original metric for reaching the neighbor). When the one minute period is over, the second suppression period begins. (See the description of the 0x800 flag for more information on the second suppression period.)
This flag indicates that the routing entry is in the second suppression period, which takes up to two minutes on VINES 5.50 servers. This period serves as a second check to make sure that updated routing metrics are reliable. When the second suppression period is over and the updated routing metric has not changed, the local server can include the updated metric in routing update packets that it broadcasts to neighbor servers and workstations. (See the description of the 0x400 flag for more information on suppression periods.)
Keep in mind that the first suppression period does not apply to VINES 5.50 servers. RTP on VINES 5.50 servers goes straight to the second suppression period.
Note: Bits 12, 13, 14, and 15 appear in the routing tables of VINES 5.50 servers only.
Bit 12 (0x1000)
This flag indicates that the connection between the last hop to the destination server and the destination server itself is a point-to-point connection, which includes HDLC and asynchronous lines, X.25 VCs, T1 LAPD connections, and ISDN B channels. The last hop is the final gateway along a route to a destination. Neighbor servers act as last hops to each other.
Bit 13 (0x2000)
This flag indicates that the connection between the last hop and the destination is a LAN.
Bit 14 (0x4000)
This flag indicates that the routing table entry has been modified by an RTP redirect packet.
Bit 15 (0x8000)
If this flag is set, and either the 0x1000 or 0x2000 flag is also set, all the gateways along the route to the destination are VINES 5.50 servers.
If the 0x1000 flag is set, a WAN, such as an HDLC line or TCP/IP network, connects the last hop and the destination. If the 0x2000 flag is set, a LAN connects the last hop and the destination.
If the 0x8000 flag is set and either the 0x1000 or 0x2000 flag is not set, one of the gateways along the route to the destination is an ENS for UNIX, VINES 4.xx, VINES 5.00, or ENS 1.0 server.
Common Flags Field Values for VINES 5.50 Servers
Common flags field values in the routing tables of VINES 5.50 servers are as follows:
0x3
This flag indicates that the destination is a VINES 4.xx, ENS for UNIX, VINES 5.00, or ENS 1.0 server that is not a neighbor, and the route is usable.
0x1003
This flag indicates the following conditions:
The destination is reachable. The destination is a VINES 5.50 server. The last hop to the destination is a VINES 5.50 server. The last hop and the destination are connected by a point-to-point link, such as an HDLC line, a T1 LAPD connection, or an X.25 virtual circuit.
0x1103
This flag indicates the following conditions:
The destination is reachable. The destination is a VINES 5.50 server. The last hop to the destination is a VINES 5.50 server. The last hop and the destination are connected by a TCP/IP or SNA network.
0x8003
This flag indicates the following conditions:
The destination is reachable. An ENS for UNIX, VINES 4.xx, VINES 5.00, or ENS 1.0 server is somewhere along the route.
0xa003
This flag indicates the following conditions:
The destination is reachable. The last hop to the destination is a VINES 5.50 server. The destination is a VINES 4.xx, VINES 5.00, ENS for UNIX, or ENS 1.0 server. A LAN connects the last hop and the destination server.
0x2003
This flag indicates the following conditions:
The destination is reachable. The last hop to the destination is a VINES 5.50 server. The destination is a VINES 5.50 server. A LAN connects the last hop and the destination server. The server that you are monitoring has ENS for UNIX, VINES 4.xx, VINES 5.00, or ENS 1.0 neighbors on a WAN.
The TRACE a route function lets you perform a VINES route trace between two VINES servers. A route trace provides details about the intermediate data links and hops between these servers.
When you perform a route trace, you can specify either the names or serial numbers of the two VINES servers. You do not have to specify both. You could also specify the name of one server and the serial number of the other server.
To trace a route, perform the following steps:
1. Choose TRACE a route from the VINES Network Summary Menu.
2. At the Trace a route menu, type the server names or serial numbers. One server must be designated as the source server, and another server must be designated as the destination server.
3. Press F10 to start the trace.
When the trace is completed, the VINES Trace Results screen appears. A sample screen that shows the route between two servers, JPTOK002 and USCHI002, is shown as follows.
To determine the route from the source server to the destination server, read each line from left to right. The name and serial number of the source server appears in the server field on the first line. The name and serial number of the destination server appears in the gate field on the last line. All the servers in between are intermediate hops between the source and destination.
If the source and destination servers are neighbors, just one line of information appears on the screen.
In the sample VINES Trace Results screen, the route between JPTOK002 and USCHI002 goes through two hops, JPTOK001 and USCHI001. The route between JPTOK002 and USCHI002 is shown in Figure 13-11.
If there are multiple routes between the two servers, the VINES Trace Results screen displays just one route - the one that was used for this particular trace.
If you attempt to trace a route that traverses many hops and slow-speed links, the trace may time out, depending on network throughput at the time. A message that tells you of the timeout appears on the Trace Results screen. The screen displays as much information about the route that VNSM could retrieve prior to the timeout.
A trace always times out if the destination or a gateway or link along the traced route is not functioning or a third-party VINES router is in the path of the trace. If a third-party VINES router is in the path of the trace, the trace fails at the router. The screen displays as much information about the route that VNSM could retrieve prior to the timeout.
If a trace traverses a restricted link, the trace succeeds, but only the network IDs of servers on the other side of the restricted link appear in the trace results. The names do not appear. Both the names and network IDs of servers on the side of the restricted link of the server that you are monitoring appear. This is done to allow you to trace routes and maintain security at the same time.
The name and serial number of each intermediate hop appears twice: once in the gate field and the other in the server field on the next line. The hop's appearance in the gate field indicates that it is acting as a gateway, or next hop, for the server in the server field on the same line. The hop's appearance in the server field indicates that it uses the server in the gate field as the gateway to the destination server.
The metric field shows the total metric from the server in the server field to the destination. For example, the total cost of the route from JPTOK002 to USCHI002 is 8. The total cost of the route from JPTOK001 to USCHI002 is 4, and so on. These values are displayed in decimal. See the section, "VINES Route Information," for more information on metrics.
The metric field on the first line shows the total metric for the route between the source server and the destination server. The metric fields on the subsequent lines show the total metric between each succeeding intermediate hop and the destination server.
The media field displays the type of connection between the servers in the server and gate fields. For example, in Figure 13-6, the connection between JPTOK002 and JPTOK001 is Token-Ring.
The following connection identifiers can appear in the media field:
Ether - Ethernet LAN
TokRng - Token-Ring LAN or multiple LANs linked by Token-Ring bridges
ProNet - ProNET-10
Hdlc - HDLC line
Async - Asynchronous line
X25 - X.25 network
IP or SvrIP - TCP/IP network
LAPD - T1 LAPD
91 - ISDN B channel
Arc - ARCNET
Ntls - NT LANSTAR
Ltalk - LocalTalk
Omni - Omninet
The address field displays the physical address of the server specified in the server field. The address identifies the interface that connects this server to the server specified in the gate field. In most cases, a LAN address appears. For example, JPTOK002's address on the Token-Ring LAN that connects it to JPTOK001 is 10 00 5a 74 ea e1.
If the server specified in the server field is connected to the server specified in the gate field by an HDLC or asynchronous line, the address field displays an internal identifier that servers use to keep track of HDLC and asynchronous lines. If a TCP/IP network connects the servers, no address is returned in the address field.
If the server specified in the server field is connected to the server specified in the gate field by an X.25 virtual circuit, the address field displays nothing.
Ignore the address field for T1 LAPD and ISDN B channel media types.
From the Trace Results screen, you can press F9 to perform a reverse trace. Whereas the initial trace displays the details of the route between the source server and the destination server, the reverse trace displays the details of the route from the destination server to the source server. The results of the reverse trace appear in the same format as the results of the initial trace; however, the order of the entries is reversed.
When you choose TCP/IP routes from the Topology Information menu, the TCP/IP Routes screen appears. A sample screen is shown as follows.
This screen displays the entries in the server's TCP/IP routing table. Each VINES server equipped with the TCP/IP Routing option or the TCP/IP Server-to-Server option keeps a TCP/IP routing table. This table contains entries for each TCP/IP route to TCP/IP destination networks, subnetworks, and hosts.
The top part of the screen displays the name of the server that you are currently monitoring, its network ID, and the number of routes in the routing table. For example, the sample TCP/IP Routes screen tells you that AUSYD003 is the server you are monitoring, the server's network ID is 02000614, and 6 routes are in its routing table.
What is a TCP/IP Route?
The body of the TCP/IP Routes screen displays the contents of the routing table itself. The table contains an entry for each TCP/IP route to a TCP/IP destination network, subnetwork and host in a TCP/IP network. These destinations are identified by an address in dot notation, such as the one below:
131.100.103.0
A TCP/IP route consists of a chain of interconnected TCP/IP nodes in a network. The nodes are connected by physical media, such as Ethernet and Token-Ring LANs. See the Banyan TCP/IP Guide for more information on TCP/IP routes.
For example, the route between AUSYD003
and the destination TCP/IP subnetwork, 131.100.103.0, appears
in AUSYD003's TCP/IP routing table as follows:
Figure 13-13 illustrates this route.
Notice that the entry for the route shows that AUSYD003 routes traffic destined for 131.100.103 over the LAN segment connected to the Ethernet card in slot 2.
The fields in TCP/IP route entries report the following information:
Destination. Gateway for reaching the destination. Slot associated with the interface for reaching the gateway. Number of IP packets forwarded across the route.
These fields are described in the sections that follow.
Destination
This field displays the TCP/IP address of the destination. The address can identify either a TCP/IP network, a TCP/IP subnetwork, or a TCP/IP host.
A destination of Default indicates that the route entry is for the default gateway. The server selects this gateway when it cannot find a specific route to a host, subnetwork, or network.
Gate
This field displays the IP address of the TCP/IP host that acts as the gateway to the destination network. If the destination (other than the default gateway) is directly connected to the server, this field displays the IP address of the interface that the server uses to reach the destination.
If the destination is the default gateway, the gateway's IP address appears in the Gate field.
If the server that you are monitoring uses VINES to route TCP/IP traffic, this field displays one of the following items:
For route entries that are used to tunnel TCP/IP traffic through a VINES network to another server, the field displays the name and serial number of the other server. If just the serial number appears, either the StreetTalk service on the server is not running or a restricted link exists somewhere along the VINES route to the server. For route entries that are used to tunnel TCP/IP traffic through a VINES network to DOS workstations that run PC/TCP, this field displays the IP address assigned to the VINES interface on the server.
Slot
This field displays the interface that is used to reach the destination. If the interface is a LAN card, this field displays the slot number in which the LAN card is installed. If the interface is VINES, this field displays "VINES." Keep in mind that the VINES interface is used to tunnel TCP/IP traffic through a VINES network to other servers or to DOS workstations that run PC/TCP.
Two routes through VINES networks are shown below. These routes appear in the sample TCP/IP Routes screen.
Figure 13-14 illustrates these routes.
Note that a TCP/IP subnetwork with a subnetwork address of 131.100.105 consists of DOS workstations running the PC/TCP VINES Transport version and the server they use to route data to TCP/IP destinations.
Forwarded
This field displays the number of TCP/IP packets that the server has forwarded along the route.
When you choose AppleTalk routes from the Topology Information menu, the AppleTalk Routes screen appears. A sample screen is shown as follows.
This screen displays the entries in the server's AppleTalk routing table. Each VINES server that has AppleTalk configured keeps an AppleTalk routing table. This table contains entries for each AppleTalk route to destination AppleTalk networks.
The server maintains one route per destination in its AppleTalk routing table, even if multiple physical routes to a destination network exist. The server keeps the shortest route to the destination. The distance to an AppleTalk destination is measured in hops.
The top part of the screen displays the name of the server that you are currently monitoring, its network ID, and the number of routes in the routing table. For example, the sample AppleTalk Route Information screen tells you that USCHI001 is the server you are monitoring, the server's network ID is 02000512, and nine routes are in its routing table.
The body of the AppleTalk Routes screen displays the contents of the routing table itself. The table contains an entry for each AppleTalk route to an AppleTalk destination network. An AppleTalk network is identified by a single decimal number or a range of numbers.
An AppleTalk route consists of a chain of interconnected AppleTalk nodes in a network. The nodes are connected by physical media, such as Ethernet and Token-Ring LANs. See Managing AppleTalk for more information on AppleTalk routes.
For example, the route between USCHI001
and the destination AppleTalk network with a network number range
of 6 to 7 appears in USCHI001's AppleTalk routing table as follows:
Figure 13-16 illustrates this route.
Notice that the entry for the route shows that USCHI001 routes traffic destined for network range 6-7 through the AppleTalk router with a network number of 12 and a node ID of 128.
The fields in an AppleTalk routing table entry are described in the sections that follow.
This field displays the first network number in the range of network numbers for the destination network. For example, if the network number range for the entry is 6-7, this field would display 6.
Keep in mind that if the destination network has only one network number, or if the server is running AppleTalk Phase 1, this field and the RngEnd field will display the same number.
This field displays the last network number in the range of network numbers for the destination network. For example, if the network number range for the entry is 6-7, this field would display 7.
Keep in mind that if the destination network has only one network number, or if the server is running AppleTalk Phase 1, this field and the RngBgn field will display the same number.
This field displays the slot number of the port, or interface, that the server uses to reach the destination network. If the interface is a LAN card, this field displays the slot number in which the LAN card is installed. If the interface is VINES, this field displays "VINES." Keep in mind that the VINES interface is used to tunnel AppleTalk traffic through a VINES network.
An AppleTalk route through a VINES network
is shown below. This route appears in the sample AppleTalk Routes
screen.
Figure 13-17 illustrates this route.
TTL
This field displays the current time-to-live (TTL) timer, in 2-second units, for this routing table entry. This timer is used to remove routing table entries for networks that are unreachable or are no longer in existence.
Each time a Routing Table Maintenance Protocol (RTMP) update that contains the network number(s) of the destination network is received, the entry is validated and the TTL timer is set to 10 (20 seconds). (This assumes that the update is received from an AppleTalk router that acts as the preferred router for reaching the destination). The update indicates that the network is reachable.
The server gives routing entries several chances to be validated before deleting them. If the server does not receive an update within 20 seconds, the server's RTMP software marks the entry as "suspect" and resets the timer to 10. If the timer expires and no update is received, the server marks the entry as "bad" and again resets the timer to 10. Finally, if the server does not receive a routing update within this period of time, the server deletes the entry if it runs AppleTalk Phase 1. If the server runs AppleTalk Phase 2, the server gives the entry one more 20-second chance to be validated before deleting it.
This field indicates which flags are set for the routing table entry. These flags provide internal routing software with descriptive information about the entry, such as whether the destination network is reachable.
Each routing table entry has an 8-bit field that is used for setting flags. The value of this field depends on the specific bits that are set. For example, if bits 3 and 0 are set:
7 6 5 4 3 2 1 0
0 0 0 0 1 0 0 1
the value that VNSM displays is 9. VNSM displays values in hexadecimal.
The individual bits and their meanings are listed below. A bit is set when its value is 1. Note that the hexadecimal values in parentheses assume that just the specified bit is set. Keep in mind that multiple bits can be set.
Bit 0 (0x1)
This flag indicates that the entry is reliable and can be used.
Bit 1 (0x2)
This flag indicates that the entry can be used, but has aged. The entry may not be reliable.
Bit 2 (0x4)
The entry is not usable. It is about to be deleted from the routing table.
Bit 3 (0x8)
The entry is for an AppleTalk extended network. Extended networks can have more than one network number. Extended networks apply to AppleTalk Phase 2 only.
If the destination is an extended network that has only one network number, this bit is still set.
Bit 4 (0x10)
The entry is for an AppleTalk non-extended network. Non-extended networks can have only one network number. Non-extended networks apply to AppleTalk Phase 1 only.
Bit 5 (0x20)
The server does not know the zone names for the destination network in the entry.
Bit 6 (0x40)
The destination network in this entry will undergo a Zone Information protocol (ZIP) takedown. The network undergoes a ZIP takedown when the name of a zone to which the network belongs is changed. During a takedown, the network is unavailable. It is brought up by a ZIP bringup, which is a packet containing the name of the new zone.
Bit 7 (0x80)
This flag indicates that the gateway to the destination network is a VINES server. AppleTalk packets that are forwarded along this route are tunneled through a VINES network, which means that they are encapsulated in VINES Internet Protocol (VINES IP) headers.
Common Flags Field Values
Some common Flags field values are as follows:
0x9 -Indicates that the route is reliable and the destination network is an extended network.
0x11 - Indicates that the route is reliable, and the destination network is a non-extended network.
0x2c - Indicates that the route entry is about to be removed from the routing table, the destination in the entry is an AppleTalk extended network, and the server does not know the zone names associated with the destination network.
0x29 - Indicates that the route is reliable, the destination network is an extended network, and the server does not know the zone names associated with the destination network. The server does not make these routes known to other AppleTalk nodes until it learns the zone names.
0x31 - Indicates that the route is reliable, the destination network is a non-extended network, and the server does not know the zone names associated with the destination network. The server does not make these routes known to other AppleTalk nodes until it learns zone names.
0x32 - Indicates that the route is not reliable, the destination in the entry is for an AppleTalk non-extended network, and the server does not know the zone names associated with the destination network.
0x34 - Indicates that the route entry is marked for deletion from the routing table, the destination in the entry is an AppleTalk non-extended network, and the server does not know the zone names associated with the destination network.
0x89 - Indicates that the route entry is reliable, the destination is an AppleTalk extended network, and the gateway to the destination is a VINES server that will tunnel traffic to the destination through a VINES network.
0x91 - Indicates that the route entry is reliable, the destination is an AppleTalk non-extended network, and the gateway to the destination is a VINES server that will tunnel traffic to the destination through a VINES network.
This field displays the network number in the AppleTalk internet address of the router that is used to reach the destination network. Each AppleTalk internet address contains a network number and a node ID. The network number identifies the network to which the node belongs. The node ID uniquely identifies the node within the network.
If the destination network is on the same LAN segment as the server that you are monitoring, this field displays the server's own network number for that network.
This field displays the node ID in the AppleTalk internet address of the router that is used to reach the destination network. If the destination network is on the same LAN segment as the server that you are monitoring, this field displays the server's node ID for that network.
This field displays the number of hops to the destination network. Each intermediate router counts as one hop. If the destination network is on the same LAN segment as the server that you are monitoring, this field displays 0 hops.
The number of AppleTalk zones to which the destination network belongs. Each AppleTalk network has a zone list, which contains the names of the zones in the network. This field displays the number of entries in the network's zone list.
AppleTalk Phase 1 networks have one zone name only. AppleTalk Phase 2 networks can have more than one zone name.
If the route supports tunneling through a VINES network, this field displays the network ID of the server that acts as the router somewhere in the internetwork. Otherwise, this field displays 0.
If the route supports tunneling through a VINES network, this field also displays the name of the server that acts as the router in the VINES network. Otherwise, no name is displayed.
