Calculating NetWare Router Table Sizes

 Paul Turner
 Consultant
 Systems Engineering Division

Abstract:

This AppNote provides information on how to calculate the memory
requirements of the Routing and Server Information tables maintained by
286-based NetWare, 386 NetWare, and Portable NetWare routers. Rules for
internetworks with loops as opposed to flat networks are also considered.
Memory allocation methods and monitoring techniques for each operating
system environment  are examined and several conclusions drawn.

Disclaimer

Novell, Inc. makes no representations or warranties with respect to the
contents or use of these AppNotes (AppNotes) or of any of the third-party
products discussed in the AppNotes. Novell reserves the right to revise
these AppNotes and to make changes in their content at any time, without
obligation to notify any person or entity of such revisions or changes.
These AppNotes do not constitute an endorsement of the third-party product
or products that were tested. Configuration(s) tested or described may or
may not be the only available solution. Any test is not a determination of
product quality or correctness, nor does it ensure compliance with any
federal, state or local requirements. Novell does not warranty products
except as stated in applicable Novell product warranties or license
agreements.

Copyright { 1990 by Novell, Inc., Provo, Utah. All rights reserved.

As a means of promoting NetWare AppNotes, Novell grants you without charge
the right to reproduce, distribute and use copies of the AppNotes, provided
you do not receive any payment, commercial benefit or other consideration
for the reproduction or distribution, or change any copyright notices
appearing on or in the document.

Introduction

Calculating Router Table Sizes

This AppNote will be most valuable to individuals managing large NetWare
internetworks containing numerous network numbers and servers and NetWare
v2.x routers. NetWare v2.x routers have limited memory to store their
Routing and Server Information tables. If this memory is filled up, some
network number and servers will be unreachable through that router.

An understanding of the information presented in the NetWare Communications
Processes document (in the September issue of the NetWare Applications
Notes) is necessary to fully understand the information presented here.

Background

NetWare routers are processes that exist in NetWare file servers and
external routers (also referred to as external bridges). The primary
function of a NetWare router is to forward packets from one network segment
to another. But NetWare routers also perform the task of distributing
routing and server information throughout an internetwork. To do this every
NetWare router maintains two tables, a Routing Information table and a
Server Information table.

The Routing Information table holds information about each of the network
numbers on the internetwork that the router is connected to. (These are the
same network numbers that are assigned within NETGEN for NetWare v2.x and
at the installation of NetWare 386 and Portable NetWare.) The router uses
the information held within this table when determining how to best forward
packets that it receives for routing. The router also shares the
information gathered in this table with other NetWare routers to ensure
that all routers on the internetwork are aware of the current internetwork
configuration.

As its name implies, the Server Information table holds information about
all of the servers on the internetwork. These servers include servers that
advertise their presence with Novell's service advertising protocol (SAP).
The Server Information table is managed by a process within the NetWare
router called the SAP agent. The information in this table is used to find
the address of specific network servers. Much like the Routing Information
table, the information in the Server Information table is shared with other
SAP agents on the internetwork.

To share information on the internetwork, NetWare routers and the SAP agent
periodically (every 60 seconds) broadcast information contained in their
tables. (See Figure XX.) The router and SAP agent do not broadcast every
entry in their tables, but use a special algorithm, called the Best
Information Algorithm, to determine which information should be broadcast
on each of their directly connected segments.

Figure 1: Routing and Server Information Tables

The Best Information Algorithm specifies that a router or SAP agent should
not broadcast information on one of its connections about a specific
network number or server if there is a source of information on that
segment (a router or SAP agent with a shorter route to the network number
or server). For instance, router A in Figure XX would not broadcast
information about network number 3 on network number 1 because router B has
a better route. The same applies for file server 1. The Best Information
Algorithm is important in the calculation of Routing and Server Information
table sizes because it determines what information a router or a SAP agent
will receive.

Figure 2: Example of Best Information Algorithm

There is one exception to the Best Information Algorithm. When a 286-based
file server and a router are connected to the same two segments, the router
will advertise the file server on the segment opposite the server's
address, even though it doesn't have the best information about the server
on that segment.

Figure XX shows that FS1 and router 2 are both connected to network 1 and
network 2. File Server 1's NIC A, and therefore its address is connected to
network 1. File Server 1's NIC B is connected to network 2. The SAP agent
FS1 periodically broadcasts FS1's server information (in a SAP broadcast)
onto both networks 1 and 2. Because of this exception in the Best
Information Algorithm, router 2 also broadcasts server information about
FS1 onto network 2. These broadcasts by router 2 take place even though
router 2 does not have the best information about FS1 on network 2.
Consider this exception to the Best Information Algorithm when calculating
the size of the Server Information table because it can significantly
effect the size of this table.

Figure 3: FS1 and Router 2 Connect to Network 1

Routing and Server Information Table Structures

The Routing and Server Information tables are two-dimensional structures.
The Routing Information table contains a block for each of the network
numbers that the router has heard about on the internetwork. Connected to
each of these network number blocks are one or more route blocks detailing
each of the possible routes to the network number in question. (See Figure
XX.)

Figure 4: Structure of Routing Information Table

Every network block in a Routing Information table is accompanied by at
least one route block. If multiple routes exist to a network number the
router may attach more than one route block to the network number's network
block. The criteria that the router uses in determining which additional
routes it will record depends on the version of NetWare being used. NetWare
routers used with NetWare v2.15c and below will record all additional
routes that they become aware of. The Best Information Algorithm determines
which routes the router be aware of for these early version routers.
NetWare routers with versions of v3.0 or after (including Portable NetWare)
only record additional routes that are equal to (measured in time) their
best route.

The memory required for the network number and route blocks varies for
different versions of NetWare. (See Figure XX.)

Figure 5: Memory Requirements for Routing Information Table

The Server Information table contains a block for each server that the SAP
agent has heard about on the internetwork. Like the Routing Information
table, each server block in the Server Information table is accompanied by
at least one SAP agent block. If multiple paths to the server exist, the
SAP agent will only record those equal to (measured by the number of
routers, or hops, in the path) its best path. (See Figure XX.)

Figure 6: Structure of Server Information Table

The amount of memory required for the server and SAP agent blocks in the
Server Information table varies for different versions of NetWare. (See
Figure XX.)

Figure 7: Memory Requirements for Server Information Table

Size Calculations for Flat Internetworks

For flat internetworks (internetworks with no loops), the calculation of
the Routing Information table memory size is quite simple. The size is
equal to the number of network numbers multiplied by the size allocated by
the operating system for a network block and route block. (See Figure XX.)
Note: Be sure to include the internal network numbers assigned to NetWare
386 servers.

Figure 8: Routing Information Table Size Equations for Flat Network

The calculation of the Server Information table memory size on a flat
network is also simple. The memory size is equal to the number of
advertising servers (file servers, print servers, gateway servers and so
on.) multiplied by the memory size allocated by the operating system for a
server block and SAP agent block. (See Figure XX.)

Figure 9: Server Information Table Size Equations for a Flat Network

In the calculation of table sizes for a flat internetwork, all of the
routers and SAP agents on the internetwork will have the same number of
entries in their tables. Therefore, once the total number of network
numbers and servers on a flat internetwork is determined, the table sizes
for every router and SAP agent on the internetwork can be calculated using
the equations in Figure XX and Figure XX.

For example, Figure XX illustrates a flat internetwork containing six
servers and seven network numbers. Each of the 286-based routers will
require 238 bytes (7 * 34 bytes) to store its Routing Information table,
the 386-based routers will require 476 bytes (7 * 68 bytes). Each of the
286-based SAP agents will require 516 bytes (6 * 86 bytes) to store its
Server Information table, the 386-based SAP agents will require 744 bytes
(6 * 124 bytes).

Figure 10: Flat Interconnection Between Six Servers and Seven Networks

Size Calculations for Internetworks Containing Loops

When there is more than one path to a network number or server on an
internetwork, a loop exists in that internetwork. Loops complicate the
process of calculating Routing and Server Information table sizes on a
NetWare internetwork because they require more factors to be taken into
account. They also require that each router and SAP agent be examined
separately for their table sizes. Any attempt to do table size calculations
on an internetwork that contains loops requires that an accurate blueprint
be available.

The first factor to take into account when examining an internetwork with
loops (loops will also be referred to as alternate routes) is the Best
Information Algorithm. The one exception to the Best Information Algorithm
that was discribed earlier must also be taken into account. There are
several other rules that must be considered when calculating the table
sizes on an internetwork containing loops. These are the rules the routers
and SAP agents follow:

1)     286- and 386-based SAP agents will only maintain one path to a
server if they connect to the same network number the server uses for its
address.

2)     With the exception of rule 1, if a 286- and 386-based SAP agent
registers its best path to a server through one of its NICs then receives
information about an alternate path through another one of its NICs, it
will record the alternate path only if it is equal to its best path.

3)   If a 286- or 386-based SAP agent registers a path to a server through
     one of its NICs, it will record all alternate paths that it sees
     through that same NIC to that server , whether those alternate paths
     are equal to or less than the best path.

4)   A 286- or 386-based NetWare router will disregard all alternate routes
     to a network number it is directly connected to.

5)   With the exception of rule 4, a 286-based router will record all
     alternate routes it hears about to each network number in its Routing
     Information table.

6)   386-based routers will only store alternate routes if they are equal
     to the best route the router knows of for each network number in their
     Routing Information table.

These rules may be best understood through a series of examples:

Rule 1: In Figure XX, FS2 will only register the path through Network 1 to
FS1.

Rule 2: FS2 will register both the path through Network 1 and Network 2 to
FS3.

Rule 4: FS1 and FS2 both broadcast about Network 1 onto Network 2. FS3
disregards these broadcasts since it is directly connected to Network 1.

Figure 11: Path for Three File Servers and Four Networks

Rule 3: Staying within the constraints of the one exception to the Best
Information Algorithm (discussed earlier), FS2 in Figure XX will advertise
FS1 on Network 2. In recording paths to FS1, FS3 will record both the path
through FS1's NIC B and the path through FS2 to FS1.

Rule 5: FS3 will broadcast about Net 4 (its internal network number) onto
Network 2. FS2 will broadcast about Network 4 onto Network 1. FS1 will
record both of these routes. Note that the route through FS2 is longer than
the route directly to FS3.

Rule 6: Both FS1 and FS2 will broadcast about Network 1 onto Network 2. FS3
will record both of these routes to Network 1.

Figure 12: Paths for Three File Severs and Four Networks (Exception)

Memory Allocation Methods

286-based NetWare, NetWare 386 and Portable NetWare each allocate memory
differently for their Routing and Server Information tables.

286-Based NetWare

In NetWare versions 2.10 to 2.15c, the Routing and Server Information
tables share a common pool of memory within a memory segment called Dynamic
Memory Pool 3 (DMP3). This memory pool is restricted to a fixed size by the
operating system. Statistics for this memory pool can be view in the
FCONSOLE->STATISTICS->SUMMARY screen. However, these numbers can be
deceiving. Along with the Routing and Server Information tables, usage of a
separate temporary buffer pool is included in the FCONSOLE DMP3 statistics.
This makes it difficult to determine exactly how much memory has been used
up  and how much is available for the Routing and Server Information
tables. The maximum available memory for the separate parts of DMP3 is
shown in Figure XX.

Figure 13: Dynamic Memory Pool 3 Maximums

                              Routing and        Temporary          Total
                              Server Tables      Buffers

v2.10, v2.11, v2.12, v2.15    32,768 bytes       4,864 bytes        37,632

v2.15c                        40,960 bytes       6,144 bytes        47,104

The restrictions shown in Figure XX cause problems to administrators of
internetworks that contain large numbers of servers and network numbers.
Once the 40,960 byte memory pool is used up within a v2.15c server,
workstations may experience problems reaching servers on different segments
of the internetwork. An administrator who had calculated the memory
requirements for the Routing and Server Information tables on paper with a
blueprint of the internetwork would add the memory requirements of the two
tables together, then compare the sum with the 40,960 byte limit (for
v2.15c).

NetWare 386

Of the three operating system platforms, NetWare 386 employs the most
flexible memory allocation scheme. It also provides the best tracking of
the three. The Routing and Server Information tables are held independent
of each other in the Alloc Short Term Memory pool. As these tables expand
and contract, memory is allocated and deallocated from the Alloc Memory
pool to accomodate their size.

The size of the Routing and Server Information tables can be monitored from
within the NetWare 386 MONITOR console utility under RESOURCE
TRACKING->ALLOC SHORT TERM MEMORY->SERVER.EXE: ROUTER NETWORK TRACKING
TABLES and SERVER.EXE: ROUTER SERVER TRACKING TABLES, respectively.

Portable NetWare

Of the three platforms, Portable NetWare is the only one that requires
management within the memory environment of another operating system. The
exact implementation of the tables may vary depending on the vendor
providing the Portable NetWare operating system.

Under the UNIX operating sytem, Portable NetWare separates memory areas.
The Routing Information tables are held in the Kernel Streams Buffers.
These are 4KB blocks of memory which must be allocated when the kernel is
generated. Each of these 4KB blocks can hold about 200 network and/or route
blocks (these blocks are defined in the section of this document titled
Routing and Server Information Table Structures) combined. There are
normally three or four of the 4KB blocks allocated as a default in the
Portable NetWare system. As the first 4KB block is filled up, the second
will be employed and so on.

The Server Information table is held within Portable NetWare's process
address space. This is a memory pool that can be as large as 4GB. The
management of the Server Information table is similar to its management in
NetWare 386. Memory is allocated and deallocated as needed. For specific
information about your Portable NetWare implementation, contact your
Portable NetWare vendor.

Conclusions

The Routing and Server Information tables play a crucial part in the
operation of client-server and peer-to-peer communications on a NetWare
network. Within the NetWare 386 and Portable NetWare operating systems,
where a significant amount of memory is available for their expansion, the
management of the size of these tables is not as critical as it is in the
286-based arena.

Due to design considerations with the Intel 80286 processor platform, the
NetWare 286-based operating system has placed the Routing and Server
Information tables in a segment of limited size. If the memory requirements
of these two tables exceed the DMP3 segment's size, problems may occur
locating and communicating with other nodes, most notably servers, on the
internetwork. When problems of this sort occur, reducing the number of
alternate routes in the internetwork is advisable. This requires an
accurate blueprint of the entire internetwork and an understanding of the
principles presented in this document. Terminology or concepts used in this
AppNote are further explained in the NetWare Communications Processes,
September Edition AppNote.

