Chapter 4 - VINES Non-Sequenced Routing Update Protocol
Non-sequenced RTP was the only VINES RTP implementation until VINES 5.5, and is the current (and only) RTP implementation on ENS 1.0 and ENS for UNIX 1.0.
Note: This chapter discusses non-sequenced RTP only. This chapter does not discuss compatibility with sequenced RTP. Compatibility information appears in Chapter 5.
Assume that the client nodes and routers that appear in the examples in this chapter run product versions that support non-sequenced RTP, such as VINES 4.11.
VINES Non-Sequenced RTP Specification
The following sections describe the non-sequenced RTP packet format and the types of RTP packets.
Non-Sequenced RTP Packet Format
RTP packets have a 4-byte header that follows the VINES IP header. In some RTP packet types, the RTP header is followed by other RTP information, such as tuples.
RTP packets are always sent with the destination VINES IP address set to the broadcast address. In most cases, the destination data link address identifies a specific node, such as a routing server or client. Routing update packets use a broadcast data link address on LANs and are sent directly on WAN connections.
Figure 4-1 shows the non-sequenced RTP packet format.
The fields in the non-sequenced RTP header are as follows.
Operation Type Field The operation type field indicates whether the packet is a routing request packet, a routing update packet, a routing response packet or a routing redirect packet. The field contains one of the values described in Table 4-1.
The four non-sequenced RTP packet types are described in "Routing Request Packets," "Routing Response Packets," "Routing Redirect Packets," and "Routing Update Packets" later in this chapter.
Node Type Field The node type field indicates the type of node where the RTP packet originated. The field contains one of the values described in Table 4-2.
Controller Type Field The controller type field indicates the type of LAN card that transmits the RTP packet. The type can be either single buffer or multibuffer. Nodes on the same LAN need to exchange this information to avoid pacing problems at the data link level. For example, if one node has a multibuffered card and knows that other nodes on the same LAN have single-buffer cards, the node with the multibuffer card can adjust pacing so that it does not overrun the other nodes.
The controller type field can contain one of the values described in Table 4-3.
Note: The 0x0 and 0x1 values specify how non-sequenced RTP treats LAN cards, and do not really reflect whether the card is single buffer or multibuffer. For example, non-sequenced RTP treats some multibuffer cards as single buffer cards, and as a result, uses 0x0 in the controller type field.
When VINES 5.5 (or greater) client nodes implement non-sequenced RTP, the controller type is always 0x1.
Machine Type Field The machine type field indicates the type of processor that sent the RTP packet. The type can be either fast bus (Intel® 80286 or greater) or slow bus (Intel 8088).
The field also indicates whether the router that sent the packet is a VINES or ENS server that supports the TCP/IP Server-to-Server option, and whether the router that sent the packet also supports sequenced RTP.
When two processors that are not equal in throughput capacity communicate directly over a LAN, the more powerful processor overruns the less powerful one. The machine type field enables directly connected processors to learn each other's processor type so that they can adjust pacing, if necessary.
The machine type field can contain one of the values described in Table 4-4.
Client nodes send a routing request packet to their routing server when they communicate with other servers not on their LAN. This packet requests the routing server to reply with a routing response packet, which contains routing information that the client node needs to communicate off its LAN.
In the non-sequenced RTP implementation, client nodes on LANs have full knowledge of neighbor servers, in addition to knowledge of their routing server and the servers and client nodes with which they currently communicate.
In the non-sequenced RTP implementation, client nodes that dial in to networks send routing request packets to communicate with servers and client nodes outside the logical network of their routing server, which is the server that they dial in to. Client nodes that dial in just keep an entry for the routing server in their neighbor table.
Routers also request routing table information from other routers when they establish a communication link across a WAN.
Figure 4-2 shows a sample routing request packet that is sent from a client node to a router.
Routing response packets contain tuples, which define the network topology as known by routers. Routers send these packets in response to routing request packets. Client nodes do not send these packets.
Tuples follow the RTP header in routing response packets. Each tuple is 6 bytes and contains information from the router's network table. A tuple is divided into two fields.
Network ID Field A 4-byte network ID field, which contains the 32-bit number of a VINES logical network.
Metric Field A 2-byte routing metric, which is a rough, round-trip delay time estimate of the route that maximum-sized VINES IP packets take to the logical network's router. A metric that is advertised in the tuple is relative to the router that advertises it.
Figure 4-3 shows a sample routing response packet with an RTP header and with two tuples. The packet is sent from a router in response to a routing request packet from a client node.
Routers transmit redirect packets to client nodes and other routers to inform them of the best routes. These packets contain topological entries that allow nodes to select the best routes to destinations. When a router determines that it should not be forwarding a packet between two nodes, it sends a redirect packet to the originator of the forwarded packet, called the last forwarding node. The best route is through a preferred gateway, which is the appropriate gateway to be used for communications between the destination and the last forwarding node.
Routers generate redirect packets when they forward non-broadcast packets on the same interface on which they were received. Routers send redirect packets directly to the last forwarding node, which can be the source of the packet or a router of the packet.
The destination and the preferred gateway can be the same node. This occurs when two neighbor nodes attempt to communicate with each other through a third neighbor node.
Figure 4-4 shows the format of a sample routing redirect packet.
The redirect message contains several fields of information. Figure 4-5 shows the format of a sample redirect message.
Figure 4-6 shows the network environment where the redirect message in Figure 4-5 is sent. In Figure 4-6, a client node initially attempts to communicate with a server, Server B, through another server, Server A. The client node is the last forwarding node. Server A informs the client node that it can communicate directly with Server B. Server B is both the destination and the preferred gateway.
Table 4-5 describes the fields in the redirect message and the notation in Figure 4-6.
Rules for Generating and Processing Routing Redirect Packets
Routers generate a redirect packet only if both of these conditions are true:
![]()
The router must forward a non-broadcast packet on the same interface where it was received from the last forwarding node. ![]()
The second high-order bit of the transport control field in the VINES IP header of the non-broadcast packet is set, giving this field a value of 0x40. This setting indicates that the last forwarding node supports redirects.
A router includes source routing information in a redirect packet only if the last forwarding node must use a source route to reach the preferred gateway.
A router does not generate a redirect packet in a source routing environment if one of these conditions is met:
![]()
The router uses different source routes to reach both the last forwarding node and the preferred gateway. This means that the last forwarding node, the router that sends the redirect, and the preferred gateway are all on different rings. ![]()
The source routes do not traverse the same rings or bridges.
Figure 4-7 illustrates this situation.
Processing Redirect Packets that Contain Source Routes
The last forwarding node processes received redirect packets that contain source routes as follows:
1. The last forwarding node checks the redirect packet to see if source routing information is included.
2. If source routing information is included in the redirect packet, the last forwarding node takes the following actions:
- If the last forwarding node uses a source route to reach the router that sent the redirect packet, the last forwarding node assumes the preferred gateway is on the same ring as itself and ignores the source routing information in the redirect packet.
- If the last forwarding node does not need the received source route to reach the server that sent the redirect packet, the last forwarding node saves the source routing information in the neighbor path entry for the preferred gateway.
3. If no source route is included in the received redirect packet, the last forwarding node does one of the following actions, depending on whether a source route is needed to reach the router that sent the redirect packet:
- If a source route is needed to reach the router that sent the redirect packet (that is, the packet was received over Token-Ring bridges), the last forwarding node concludes that the preferred gateway and the router sending the redirect are on the same ring. The last forwarding node copies the source route that it uses to reach the router that sent the redirect packet into the neighbor path entry for the preferred gateway.
- If a source route is not needed to reach the router that sent the redirect packet, the last forwarding node assumes that the preferred gateway and the router sending the redirect packet are on the same ring as the last forwarding node.
Example Redirect Packets in a Source Routing Environment
In Figure 4-8, the last forwarding node and the router that sends the redirect packet are on the same ring.
In Figure 4-8, the router sending the redirect packet includes the following source routing information:
![]()
Length of the source route that it uses to reach the preferred gateway ![]()
Source route that it uses to reach the preferred gateway
The last forwarding node processes the redirect packet, as follows:
![]()
Verifies that the router that sends the redirect is on the same ring (that is, no source route needed to reach this router) ![]()
Copies the source route and its length in the redirect packet into the neighbor path entry of the preferred gateway
Example Redirect Packets in a Source Routing Environment
In Figure 4-9, the last forwarding node and the router sending the redirect packet are on different rings, and the last forwarding node and the preferred gateway are on the same ring.
In Figure 4-9, the router that sends the redirect packet includes the following source routing information:
![]()
Length of the source route that it uses to reach the preferred gateway ![]()
Source route that it uses to reach the preferred gateway
The last forwarding node processes the redirect packet, as follows:
![]()
Verifies that the router sending the redirect is on another ring (that is, a source route is needed to reach this router) ![]()
Ignores the source routing information in the redirect packet because it knows that the preferred gateway is on the same ring
Example Redirect Packets in a Source Routing Environment
In Figure 4-10, the last forwarding node resides on one ring, and the router sending the redirect packet and the preferred gateway are on another ring.
In Figure 4-10, the last forwarding node does not receive any source routing information in the redirect packet. It takes the following actions:
![]()
Verifies that the router sending the redirect is on another ring (that is, a source route is needed to reach this router) ![]()
Concludes that the preferred gateway and the router sending the redirect are on the same ring ![]()
Assumes that the same source route that it uses to reach the router sending the redirect packet can also be used to reach the preferred gateway ![]()
Copies the source route used to reach the router that sends the redirect into the neighbor path entry of the preferred gateway
Routers and client nodes that are neighbors on LANs broadcast routing update packets to each other every 90 seconds. Routing update packets serve two important purposes:
![]()
They inform neighbors that the client or router transmitting the packet is still on the network. If a neighbor on a LAN is not "heard from" for 6 minutes, the remaining client and routers on the LAN remove the neighbor from their routing tables. ![]()
They propagate news of network changes through the network. When neighbors that act as routers receive RTP update packets containing news of network changes, they propagate the news to their neighbors on all of their interfaces (including the interface on which they received the news). This process continues, from router to router, until the news reaches all the routers in the network.
The routing update packets that routers broadcast are full update packets, containing the router's entire routing table.
The client node broadcasts null routing update packets only. These packets contain the RTP header only.
Once the connection is established, routers that are neighbors of each other on wide-area data links (for example, block asynchronous, HDLC, X.25, TCP/IP Server-to-Server) broadcast routing update packets only when changes in the network take place, such as when a new server comes on line or a data link fails.
Every time a client node establishes a dial-in connection (that is, when a user logs in), a client node receives a routing request from its routing server and sends a null update. While connected to the network, client nodes do not send null updates.
Routers follow an RTP header in routing update packets with tuples that define the network topology known by the router. Each tuple is 6 bytes and contains information from the router's network table. A tuple is divided into two fields.
Network ID Field A 4-byte network ID field, which contains the 32-bit number of a VINES logical network.
Metric Field A 2-byte routing metric, which is a rough, round-trip delay time estimate of the route that maximum-sized VINES IP packets take to the logical network's router.
Figure 4-11 shows a sample routing update packet with an RTP header and with two tuples. The packet is broadcast from a router to its neighbors.
VINES Non-Sequenced RTP Implementation Notes
This section provides implementation notes on the following RTP subjects:
![]()
Neighbor table ![]()
Network table ![]()
Routing metrics ![]()
Routing table flags ![]()
Routing table timers ![]()
Information exchange algorithms
Every RTP entity maintains two tables containing routing information. The neighbor table contains path information about neighbors. The network table contains route information about known networks. See "Network Table Implementation" later in this chapter for more information about the network table.
Neighbors are nodes that are directly connected. In VINES, neighbors are considered to be directly connected by the following topologies:
![]()
A LAN, which can consist of a single segment or multiple segments linked by bridges. These bridges can either link segments directly, or over some other medium, such as serial lines. For example, all VINES nodes on Token-Ring LANs connected by Token-Ring bridges, are neighbors. As another example, all VINES nodes on a Token-Ring LAN that consists of local and remote IBM Token-Ring bridges are neighbors.
![]()
A point-to-point connection, which includes X.25 virtual circuits, HDLC or block asynchronous lines, ISDN B-Channels, and T1 LAPD connections. ![]()
A non-VINES network, such as a NetWare, TCP/IP, or SNA network.
The neighbor table consists of entries, each of which stores information about a neighbor. There is one entry per neighbor, uniquely identified by the neighbor's network ID and subnetwork ID. The fields in the entry are described in Table 4-6.
Each neighbor entry contains a list of available paths to reach the neighbor. Each neighbor path is itself an entry that is chained to the nbhlist field in the neighbor entry.
Each neighbor entry has at least one route. If an existing neighbor is reachable through multiple interfaces, a neighbor path is created for each interface and inserted at the beginning of the corresponding route list. Each neighbor path is uniquely identified by its interface, such as an Ethernet card or X.25 virtual circuit.
Routers can have multiple neighbor path entries per neighbor entry. Since client nodes can have only one route to a neighbor, only one neighbor path entry can exist per neighbor entry.
The route entry is specified by the rthentry structure, whose fields are described in Table 4-7.
The controller type is discussed in "Non-Sequenced RTP Packet Format" earlier in this chapter.
Table 4-8 describes interface metrics. Some of the interfaces in the table are not supported under some product versions.
Some interfaces, such as interfaces to NetWare networks, use formulas to calculate the routing metric instead of fixed values. These formulas are described in the following sections.
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.
Source Route 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 4-12 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 some routers, such as VINES 5.5 servers, the metric for source routing is configurable.
NetWare Metric
The VINES routing metric for VINES tunnels through NetWare networks is calculated as follows:
2 * IPX/SPX metric
For example, suppose that two servers are neighbors on a NetWare network. The IPX/SPX metric for the NetWare network is 6. The interface metric would be calculated as follows:
2 * 6 = 12
Figure 4-13 illustrates this example.
See the NetWare documentation for more information on IPX/SPX metrics.
The network table consists of network entries, each of which stores information about a route to a logical network. The entry is identified by the network's number. There is one entry per route. The fields in the entry are described in Table 4-9.
Selecting Neighbor Paths and Routes
When multiple routes of unequal cost to a destination exist, only the best route is stored in the network table. The best route is the one with the least cost (that is, the route with the lowest routing metric).
While one route to a neighbor destination is stored in the network table, multiple neighbor path entries can be stored in the neighbor table for the same destination. As a result, the following is possible:
![]()
One route to a neighbor destination stored in the network table ![]()
Multiple neighbor path entries to the same destination stored in the neighbor table
Before VINES 5.5, routers would in some cases favor a neighbor path over a multihop route, even if the multihop route had a lower metric. With VINES 5.5, VINES IP always uses the cheapest route to a destination, even if this route is multihop and a neighbor path to a destination exists.
Routers store all neighbor paths to reach a neighbor destination, and can use multiple equal cost neighbor paths to reach a neighbor destination. Client nodes can use only one neighbor path.
When VINES IP on the router forwards a packet to the destination, the VINES IP entity follows these rules to choose the route when all routes are of equal cost:
![]()
If the router supports non-sequenced RTP only, the router favors any VINES route over any route that uses a non-VINES protocol, such as a route with a TCP/IP server-to-server link. ![]()
If the router supports sequenced RTP, the router chooses equal-cost routes at random, regardless of whether non-VINES protocol stacks are involved. ![]()
The router chooses the route at random if all routes to the destination have equal cost and are VINES-only (that is, no other protocol stacks such as TCP/IP are involved).
When VINES IPC or VINES SPP transmits a packet, VINES IPC or VINES SPP is responsible for selecting the route - not VINES IP. If the destination is a neighbor, VINES IPC and VINES SPP are also responsible for selecting the neighbor path.
Routing table entries have flags that provide internal routing software with descriptive information about the entry, such as if the destination network is reachable. A flag is a bit set to either 1 or 0.
Each routing table entry has a 16-bit field that RTP uses for setting flags. For example, bits 0 and 1 can be set:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1
In this case, the route's destination is reachable, and the destination is a router.
The individual bits and their settings are discussed in this section. A bit is set when its value is 1. The hexadecimal values in parentheses assume that just the specified bit is set.
Unless otherwise noted, the flags are used by both client nodes and routers, and they can be applied to both neighbor path and network entries.
RTF_UP (0x1) The route is usable.
RTF_GATEWAY (0x2) The destination is a router.
RTF_HOST (0x4) If this flag is set, the entry is a neighbor path entry. Otherwise, it is a network entry in the network table.
RTF_KILL (0x8) The network entry can be removed. This flag applies to network entries only. The flag is set when all network entries must be removed.
RTF_TRANSIENT (0x10) The network entry is transient. This flag applies to network entries on client nodes only. When a client node attempts to communicate with an unknown logical network, the client creates a temporary network entry with the RTF_TRANSIENT and the RTF_METRIC flags set. The client then sends a request to its routing server, which responds with a routing response packet that includes an entry with the correct metric for reaching the logical network. The correct metric replaces the temporary one.
RTF_PERMANENT (0x20) The entry is permanent, and cannot be aged out. This flag applies to neighbor path entries only. It indicates that a permanent route to the neighbor exists. A permanent route is a WAN connection, such as serial lines, X.25 virtual circuits, ISDN B-Channels, TCP/IP networks, NetWare networks, and SNA networks.
RTF_CHANGE (0x40) The network entry has been updated due to a change in the network, such as a new router coming on line. This flag is set only when a router has permanent routes to neighbors on WAN connections. This flag identifies the entry as one that must be included in the routing update packet that is sent across the WAN. When changes in the network take place, routers send only modified network entries on WAN connections. The entries are contained in routing update packets.
RTF_METRIC (0x80) The metric in this entry must be updated with the correct one, which is received in a routing response packet from the clientÕs routing server. This flag applies to transient network entries on client nodes only.
RTF_IP (0x100) A neighbor is reached over a TCP/IP network. This flag applies to neighbor path entries on routers only.
RTF_REDIRECT (0x200) The neighbor path entry was created when processing a redirect packet. This flag applies to neighbor path entries only.
RTF_SUPPRESS1 (0x400) This flag is set in the routing tables of routers 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 ensure a reliable updated routing metric. See "First Route Suppression Period" later in this chapter for more information.
RTF_SUPPRESS2 (0x800) This flag indicates that the routing entry is in the second suppression period, which takes one minute on routers that support non-sequenced RTP, such as VINES 5.0 servers, and and up to two minutes on routers that support sequenced RTP, such as VINES 5.5 servers. See "Second Route Suppression Period" later in this chapter for more information.
First Route Suppression Period
The first suppression period lasts one minute and occurs when a previously unreachable non-neighbor router becomes reachable, or the metric for the route to a reachable, neighbor router changes. A metric change for a reachable non-neighbor router does not trigger the first suppression period.
Unreachable, Non-Neighbor Router - The local router has a routing table entry for a remote router that is not a neighbor and the metric for reaching the remote router is 0xFFFF, indicating the remote router is unreachable. Then, a new metric for the remote router is received, indicating that the remote router is reachable. For one minute, the local router "advertises" that the remote router is unreachable, even though the local router received a new metric. The local router advertises by broadcasting routing update packets every 90 seconds.
The local router advertises that the remote router is unreachable to prevent the formation of circular routes in the network. When the one minute period is over, the second suppression period begins.
Example Unreachable, Non-Neighbor or Router
Server A is the local router and Server B is a remote router that is marked as unreachable in Server A's routing table. Server A receives a routing update packet, indicating Server B is reachable. Server A copies the new metric from the packet into its routing table, but for one minute, Server A includes the original metric (0xFFFF) in the routing update packets that it broadcasts. If the new metric does not change for one minute, Server A can be sure that the new metric is reliable.
During the second suppression period, the local router still advertises that the remote router is unreachable.
Reachable, Neighbor Router - The local router's routing entry was for a remote router that is a neighbor and the local router received a better metric for reaching that router. Unlike the previous example, the remote neighbor does not have to be unreachable - a better metric can trigger the first suppression period.
For one minute, the local router advertises that the remote router is unreachable (the local router does not advertise the original metric for reaching the neighbor). When the one minute period is over, the second suppression period begins.
Second Route Suppression Period
The second suppression period serves as a second check to ensure reliable updated routing metrics. It lasts one minute on routers that support non-sequenced RTP, such as VINES 5.0 servers, and up to two minutes on routers that support sequenced RTP, such as VINES 5.5 servers. When the second suppression period is over and the updated routing metric has not changed, the local router can include the updated metric in routing update packets that it broadcasts to neighbor routers and workstations.
VINES routing software in the non-sequenced RTP implementation uses timers for a variety of purposes, such as to remove neighbor path and network entries for unreachable or nonexistent destinations. Timers are measured in, approximately, 90-second units of time. For example, a timer of 4 is 6 minutes to 71/2 minutes.
Table 4-10 describes timers in both neighbor path entries and network entries he following examples illustrate how some of these timers are used.
Example RTS_AGE Timer
If the RTS_AGE timer expires before an RTP update, containing the network ID of the network, is received, the network entry is removed. If the network is associated with a neighbor router, the neighbor path entry for the router is also removed. Each time an update is received and indicates that the network is reachable or still exists, the timer is reset to one of these values:
4 (6 minutes to 71/2 minutes) - The destination is a neighbor on a LAN or is reached by way of a gateway that is a LAN neighbor.
0xFFFF (-1) - The destination is a neighbor on a WAN or is reached by way of a gateway that is a WAN neighbor.
To remain in a routing table, an entry must be refreshed. An entry is refreshed when its RTS_AGE timer is set. This timer is set to a time period between 6 minutes and 71/2 minutes whenever a routing update packet is received and information in the packet is still valid. At 270 seconds, the timer is set to 3, unless it is refreshed. At 180 seconds, the timer is set to 2 unless it is refreshed, and so on. If the 6 minute to 71/2 minute period elapses and the entry is not refreshed, the router assumes that the destination is unreachable or no longer exists and removes the entry from the routing table.
When a routing update packet is received from a router on a LAN and metric information in the packet indicates that the router can act as a better route to a destination than one used previously, the RTS_AGE timer for the entry associated with the better route is set to 4 (6 minutes to 71/2 minutes).
Example RTS_CAGE Timer
If a router has WAN neighbors, the router sets the RTS_CAGE timer to 5 (71/2 minutes to 9 minutes) in each network entry that is changed for any reason, and sets the RTF_CHANGE flag. The RTS_CAGE timer setting ensures that the router attempts to send the change, such as a metric change, to the WAN neighbors at least five times. When the timer expires, the router removes the changed entry if its destination network is unreachable. Otherwise, the router sets the RTS_AGE timer to 4 or allows the timer to reach 0xFFFF (-1).
How Routing Tables Are Maintained by Non-Sequenced RTP
This section describes several scenarios to illustrate how routing tables on client nodes and routers are maintained. The scenarios are as follows:
When No Network Changes Take Place
This section describes the actions that routers and client nodes perform when no network changes take place.
On LANs, routers and client nodes broadcast routing update packets every 90 seconds, regardless of whether any changes in the network occur. This broadcast allows LAN neighbors to inform each other that they are still on the network. Routers broadcast the entire contents of their network table in routing update packets. Client nodes send a null routing update packet, which is a routing update packet with an RTP header only and no tuples.
When a node receives a routing update packet, it compares the tuples in this packet to the entries in its network table. When no changes in the network have taken place, a match occurs and the receiving node's network table is not updated.
On WANs, neighbors broadcast routing update packets only when network changes take place.
Routing update packets that are sent by routers contain 6 bytes of data for each router in the network: 4 bytes for the router's network ID and 2 bytes for the metric used for reaching the router. Thus, routing update packets increase in size as the number of routers in the network increases. For example, if a server knows about 50 routers, it includes 300 bytes of topological data in the routing update packet.
To build routing update packets, routers that are VINES, ENS, and ENS for UNIX servers allocate a 1200-byte buffer. When a network reaches the 200 router plateau, routing update packets can contain as much as 1200 bytes of topological data, filling the buffer to capacity. When the network grows to 201 routers, a router that generates a routing update packet must allocate another buffer, and transmits two routing update packets, one with 1200 bytes of topological data and the other with 6 bytes of topological data. Each packet contains identical RTP and VINES IP headers, except for the checksum field in the VINES IP header. See Chapter 3 for a description of the VINES IP header.
Note: Third-party routers may allocate a buffer that exceeds 1200 bytes. In this case, VINES, ENS, and ENS for UNIX servers will be able to receive topological data that exceeds 1200 bytes, but will not transmit topological data in excess of 1200 bytes.
When the network reaches the 400 router plateau, both 1200-byte buffers are filled to capacity. When the network reaches 401 routers, a server allocates 3 buffers, and generates 2 packets with 1200 bytes of topological data and 1 packet with 6 bytes of topological data. All three packets have identical VINES IP and RTP headers, except for the checksum field in the VINES IP header.
In the non-sequenced RTP implementation, missing or dropped RTP packets cannot be detected. For example, if a routing update spans three routing update packets and one of those packets is lost, the lost packet is not detected. The sequenced RTP implementation addresses this problem. See Chapter 5 for more information.
When a router comes on to the network, the following packet exchange takes place between the router and its neighbors:
1. The new router announces its arrival by broadcasting routing update packets to neighbors.
2. Neighbor client nodes and routers perform the algorithm for processing received routing update packets and add this router to their neighbor tables. Routers also add this router to the network table.
Neighbors use the source address in the VINES IP header and the metric for the interface where the routing update packet was received to create the table entries.
3. The routing update packets from neighbor routers and client nodes "build" the new router's routing tables.
Routing update packets from neighbor routers contain the network ID of each router in the network and metrics for reaching them. The routing update packets increase in size as the number of routers in the network increases.
Routing update packets from client nodes just contain the RTP header.
4. News of the new router's arrival is propagated through the network. Neighbors of the new router broadcast routing updates to their neighbors, which in turn broadcast updates to their neighbors, and so on.
When neighbors that act as routers receive RTP update packets that contain news of network changes, they propagate the news to their neighbors on all of their interfaces (including the interface that they received the news on). This process continues, from router to router, until the news reaches all the servers in the network. See "Propagation of Network Topology Changes" in Chapter 3 for more information.
The algorithm that routers and client nodes perform when they receive news of a new router depends on whether they are:
![]()
Neighbors of the new router ![]()
Non-neighbors of the new router
Neighbors of the New Router - When processing a received routing update packet from a new router, neighbors follow this basic algorithm:
1 . The neighbor checks the neighbor table to see if an entry exists for the new router.
2. Because no entry for the new router exists, the neighbor must create one. The neighbor extracts the LAN address (if applicable) from the data link header and the source VINES internet address from the VINES IP header.
3. The neighbor uses the LAN address, VINES internet address, and metric for the interface where the routing update packet was received to create an entry for the new router in the neighbor table, and a corresponding neighbor path entry. The router sets these entry elements:
- The RTS_AGE timer in the neighbor path entry for the new router
- NBFLAGS in the neighbor path entry to indicate that the new node is a router
- NBMTYPE and NBCTYPE in the neighbor path entry to 0x1 to indicate fast processor and multibuffer controller respectively
4. Routers also use the VINES internet address and interface metric to create an entry for the new router in the network table.
The router initializes the NETGATE pointer to point to the entry for the new router in the neighbor table.
If the neighbor has no WAN neighbors, the neighbor sets the RTS_AGE timer and the RTF_UP and RTF_GATEWAY flags.
If the neighbor has WAN neighbors, the neighbor sets the RTS_CAGE timer and the RTF_UP, RTF_GATEWAY and RTF_CHANGE flags.
On WAN interfaces, the router broadcasts as soon as it receives news of the change. The router broadcasts routing update packets that contain only the changed tuples from the network table. The router broadcasts routing update packets that contain news of the change five times on WAN interfaces, after which the RTF_CHANGE flag is turned off.
5. Routers include the VINES internet address and metric for the new router in a tuple in the next routing update broadcast. Routers that act as routers broadcast on all interfaces, propagating news of the network change.
Example Neighbor of a New Router
Figure 4-14 shows a new router announcing itself to a neighbor on an Ethernet LAN. Subsets of the fields in the neighbor, neighbor path, and network entries on the router that receives the routing update packet are also shown.
Non-Neighbors of the New Router - As news of the new router spreads throughout the network, routers that are not neighbors of the new router process routing update packets according to this algorithm:
1. The router checks the neighbor table and the network table to see if the appropriate entries exist for the router where the routing update packet is received.
2. The router compares the tuples in the received routing update packet to the corresponding entries in its network table. The router sees that a tuple exists in the routing update packet that does not have a corresponding entry in the network table.
3. The router uses the VINES internet address and metric in the new tuple to create an entry for the new router in the network table.
The VINES internet address becomes the destination address.
To calculate the total metric to the destination, the router adds the metric in the tuple to the metric for the interface where it received the routing update packet. If the router has multiple interfaces to the router that sent the tuple, the router adds the metric for the fastest interface. For example, if a router receives a tuple from another router, and the two routers are connected by both a 4-Mbps Token-Ring LAN and an Ethernet LAN, the router receiving the tuple adds the metric for the Ethernet LAN.
The router initializes the netgate pointer to point to the entry in the neighbor table for the router that sent the routing update packet. This means that the router sending the routing update packet becomes the gateway to the new router.
If the neighbor has no WAN neighbors, the neighbor sets the RTS_AGE timer and the RTF_UP and RTF_GATEWAY flags.
If the neighbor has WAN neighbors, the neighbor sets the RTS_CAGE timer and the RTF_UP, RTF_GATEWAY and RTF_CHANGE flags.
4. Routers include the VINES internet address and metric for the new router in a tuple in the next routing update broadcast. Routers broadcast on all interfaces, propagating news of the network change. When they receive news of a network change, routers broadcast news of the change immediately on all LAN and WAN interfaces.
On LAN interfaces, routers broadcast full routing updates.
On WAN interfaces, the router broadcasts routing update packets that contain only the changed tuples from the network table. The router broadcasts routing update packets that contain news of the change five times on WAN interfaces, after which the RTF_CHANGE flag is turned off.
Routers that receive the changed tuples on WAN interfaces turn the RTF_PERMANENT flag on for the network entries that are created from these tuples.
Example Non-Neighbor of a New Router
Figure 4-15 shows a router receiving news of a new router that is not a neighbor. Subsets of the fields in the neighbor, neighbor path, and network entries on the router that receives the routing update packet are also shown.
If a router goes off the network, neighbor client nodes simply remove it from the neighbor table.
The time it takes for routers to remove the network entry for an unreachable router from the network table depends on whether they have WAN interfaces. Routers that have WAN interfaces wait 71/2 minutes to 9 minutes to remove an entry after marking it as unreachable with the 0xFFFF metric. This ensures that the change is advertised at least five times over WAN interfaces. As soon as the change has been advertised five times, the entry is removed.
If the router has LAN interfaces only, the entry in the network table is kept for at least 90 seconds before it is removed.
How neighbor routers remove these routes depend on whether they are:
![]()
LAN neighbors ![]()
WAN neighbors
LAN Neighbors - Neighbor routers on LANs perform the following actions:
1. When a routing update packet is not received from another router on a LAN interface for six minutes (RTS_AGE expires), the neighbor routers turn off the RTF_UP flag and sets the metric to 0xFFFF in the network entries for the following nodes:
- The router that left the network
- All destinations for which the router acted as a gateway
The neighbor routers also delete the entry for the router that left the network from the neighbor table.
If the neighbor router has WAN interfaces, the router sets the RTF_CHANGE flag in the changed network entries.
2. The router immediately broadcasts news of the change to all of its remaining neighbors. The router includes a tuple in the routing update packet for the router that left the network and destinations reached through it. Each tuple contains a VINES internet address and a metric of 0xFFFF.
On LAN interfaces, the router broadcasts full routing updates with tuples for both unreachable routers and reachable routers.
On WAN interfaces, the router broadcasts routing update packets with only the tuples for the router that left the network and destinations reached through it.
WAN Neighbors - The actions that routers perform when a WAN neighbor leaves the network depend on the kind of WAN connection between them.
If the router that left the network was reached over an HDLC or block asynchronous line, the neighbor can detect that carrier has dropped and begins the process of removing the routing table entries automatically.
However, if the router that left the network was reached over a TCP/IP network, an administrator must delete the entries manually to initiate the removal process.
Once the removal process begins, the neighbor router performs the following actions:
1. The neighbor routers turn off the RTF_UP flag and set the metric to 0xFFFF in the network entries for:
- The router that left the network
- All destinations for which the router that left the network acted as a gateway
2. The router sets the RTF_CHANGE flag in the changed network entries. The router also deletes the entry for the neighbor that left the network from the neighbor table.
3. The router immediately broadcasts news of the change to all of its remaining neighbors. For the router that left the network and for each destination for which it previously acted as a gateway, neighbor routers include a tuple in the routing update packet. The tuple contains the VINES internet address and a metric of 0xFFFF. This metric tells other nodes that the router has left the network and destinations reached by way of it are now unreachable.
On LAN interfaces, the neighbor broadcasts full updates that contain news of the change.
On WAN interfaces, the router broadcasts routing update packets that contain only the changed tuples from the network table.
When a Client Node Comes On Line
When a client node receives its VINES internet address, it uses information in the ARP assignment response packet to create a neighbor entry and a neighbor path entry for its routing server in the neighbor table. The client uses the following information from this packet to create the entries:
![]()
The routing server's data link address in the data link header ![]()
The routing server's source VINES internet address in the VINES IP header ![]()
The interface metric of the interface on which the assignment response packet was received
See Chapter 3 for more information on the address assignment process.
After receiving a VINES internet address, the client node performs an algorithm that depends on whether the client node is connected to:
![]()
A LAN ![]()
A dial-in line
Client Node Is Connected to a LAN - The client node performs the following algorithm:
1. The client node broadcasts a routing update to all neighbor client nodes and routers on the LAN. The broadcast packets contain an RTP header only and no tuples. If the client node has source routing enabled, it only sends updates directly to the routing server.
The neighbor client nodes and routers use the following information in the incoming routing update packets to add the new client node to their neighbor table:
- The client node's data link address in the data link header
- The client node's source VINES internet address in the VINES IP header
- The client node's machine type, node type and controller type in the VINES RTP header
- The interface metric of the interface on which the routing update packet was received
2. All neighbors respond with routing update packets, which build the new client node's neighbor table.
Client Node Is Connected to a Dial-in Line - The client node sends a routing update packet with no tuples and a routing request packet directly to its routing server across the WAN interface every time it dials in. The routing server responds with a full routing update to build the client node's network table.
If the client node has not been assigned a VINES internet address, it sends the routing update packet and routing request packet after it is assigned the address by the routing server. When a client node dials in and has an address stored in memory from a previous assignment, it just sends the routing update packet and the routing request packet.
When a Client Node Goes Off Line
When a client node goes off the network, LAN neighbors remove the entry for the node from their neighbor table if they do not receive an RTP update packet from it for 6 minutes. If the client node dials in to the network, the client node's routing server removes the entry for the node from its neighbor table when the dial-in connection terminates.
When a Client Node Communicates Outside Its Logical Network
Since a client node only keeps track of neighbor networks and the networks with which it is currently communicating, the client node must be able to quickly learn how to reach new networks with which the client node wishes to communicate. To do this, the client node performs the following algorithm:
1. The client node finds out the destination VINES internet address of the router through StreetTalk and creates a transient entry in the network table.
2. The client node sets the RTF_TRANSIENT flag and the RTF_METRIC flag to indicate that the entry needs a better metric.
The routing server is used as the temporary router.
A temporary, "best guess" metric is used to reach the destination. See "Client Node Request for Routes" in Chapter 3 for more information on the "best guess" metric.
3. After 200 milliseconds, the client node sends a routing request packet to the routing server. If the client node does not receive a response, it continues to send a routing request packet every 5 seconds.
4. Routing server replies with a routing response packet that contains a full routing update. The client node just uses the entry for reaching the destination it wants to communicate with, and discards the rest.
The client node replaces the "best guess" metric with the correct metric for reaching the destination. The client node disables the RTF_METRIC flag for the entry.
If the routing server does not respond initially, the client node continues to send a routing request packet every 5 seconds until a routing response packet containing the correct metric is received. The timer that controls the transmission of the routing request packet is called the mtimer.
5. If there is a better route for reaching the destination, the routing server will send a redirect packet to the client node, telling the workstation about the better route.
Transient entries are aged out of the network table based on the RTS_TAGE timer. If the entry is not used before this timer expires, the entry is removed from the network table.
When Routers Initialize WAN Connections
On HDLC and block asynchronous serial lines and X.25 virtual circuits, routers send three full routing updates during the initial establishment of the connection. This ensures against the possibility of losing packets.
Additional insurance measures are also taken on HDLC, block asynchronous, and X.25 connections:
![]()
On HDLC serial lines and X.25 virtual circuits, the router that initiates the connection sends a routing request packet every 30 seconds until the router on the other end responds with a routing response or update packet. ![]()
On permanent X.25 virtual circuits only, the router that initiates the connection must send a routing request packet to force the router on the other end of the connection to send a routing update packet. This insurance measure is designed for situations in which the router on the other end of the connection was already up from a previous instance of this circuit. ![]()
On block asynchronous serial lines, the routers on each end of the line send a routing request packet every 20 seconds until a response or update packet is received.
When connections over TCP/IP and NetWare networks initialize, a router sends a routing request packet every 10 minutes to each neighbor router for which it has tunnels defined in its TCP/IP or IPX/SPX configuration. Once the neighbor responds with a routing response packet, the request packets are no longer sent to that neighbor.
When the "Help Thy Neighbor" Scenario Takes Place
When a topology change takes place that makes networks unreachable, a router forces a routing update to "help its neighbors," if all of the following conditions are met:
![]()
A WAN neighbor advertises that a network is unreachable. ![]()
The router can reach the advertised network through another gateway. If the router reaches the advertised network through the WAN neighbor that advertises it as unreachable, the router does not help its neighbor. ![]()
The change in the network topology did not alter the routerÕs view of the network that became unreachable to its WAN neighbor. ![]()
The router can provide an alternate route to the network that its WAN neighbor can no longer reach.
When a router determines that it can help its neighbor, it performs the following actions:
1. Marks the network entries that are advertised as unreachable with the RTF_CHANGE flag
2. Includes these entries in the "changes only" routing update that is sent to the WAN neighbor
3. Advertises these entries in the next scheduled routing update
Figure 4-16 illustrates the "help thy neighbor" scenario.
In Figure 4-16, Router C's Ethernet connection is broken, but its HDLC connection is still active. Router C previously used its Ethernet connection to reach Router A, but now it thinks that Router A is unreachable. Router C does not know that it can use its HDLC connection to reach Router A.
When Router C advertises that Router A is unreachable, Router B forces a routing update to Router C. The update tells Router C that it can reach Router A over the HDLC connection and through Router B.
RTP adjusts to changes in the cost of reaching a destination. The routers that initially detect the changed metric base their actions on whether the metric indicates:
![]()
A cheaper cost (that is, the metric is less than the one used previously) ![]()
A greater cost
When the Metric Indicates a Cheaper Cost - When metric information in a received tuple indicates that the metric for reaching a neighbor is less than the previous metric, a router performs the following actions:
![]()
Sets the RTF_SUPPRESS1 flag to begin the first suppression period, followed 1 minute later by the setting of the RTF_SUPPRESS2 flag ![]()
Sets the metric for reaching the destination to 0xFFFF ![]()
Sets the RTF_CHANGE flag if it has WAN neighbors
Although the destination may be reachable, the router advertises that the destination is unreachable for two minutes - the 1-minute first suppression period and the 1-minute second suppression period.
As news of the metric change propagates through the network, other routers perform the same actions as the routers that initially detect the change.
After two minutes, the routers that initially detect the metric change turn off the RTF_SUPPRESS2 flag and advertise the correct metric for reaching the destination. The correct metric propagates through the network so that other routers can reach the destination.
This procedure eliminates the possibility of circular paths and re-adjusts network path selection as quickly as possible. When a router either adjusts a routing metric in a network entry or creates a new entry, the router broadcasts a new routing update packet. This lets RTP update the entire network rapidly when a new router appears or a new communications line is enabled. hen metric information in a received tuple indicates that the metric for reaching a non-neighbor is less than the previous metric, a router simply accepts it. If the tuple containing the metric is received from a new gateway to the destination, the router also accepts it.
When the Metric Indicates a Greater Cost - A router accepts a greater metric only if the neighbor router that advertises it is the original router for reaching the destination. If the metric is not -1 (0xFFFF), a router takes the following actions:
![]()
Sets the destination to unreachable (-1) ![]()
Sets the RTF_CHANGE flag if it has WAN neighbors
The router advertises that the destination is unreachable before it removes the entry.
If the new metric indicates that the destination is unreachable (-1), routers advertise it immediately.
When an Equal Cost Metric Is Received from a New Gateway
When a new gateway for reaching a destination becomes available and advertises the same metric for reaching the destination as the one used previously, the metric is accepted and the new gateway is stored in the network entry for the destination. The old gateway is no longer stored.