NetWare Link Services Protocol: An Advanced Theory of Operations
Articles and Tips: article
Senior Systems Engineer
Novell, Inc.
DAVID DOERING
Senior Analyst
Network Technical Services
BARBARA HUME
Technical Communications VP
Network Technical Services
01 Nov 1995
NetWare Link Services Protocol™ (NLSP™) is a new link-state protocol for NetWare that alleviates the network traffic problems created on WANs by RIP/SAP broadcasts. This AppNote looks at the internal operations of NLSP-based routers, as well as the key databases and packet types that make up NLSP. It then presents a conceptual walk-through of how NLSP works in a sample four-server network, followed by a packet trace showing the actual data being transmitted. This advanced technical information should provide network designers, system administrators, and support personnel with a solid understanding of NLSP operations.
RELATED APPNOTES Sep 94 "Effectively Managing RIP and SAP Traffic with Filtering" May 94 "NetWare Link Services Protocol: Link-State Routing in a NetWare Environment" May 94 "Optimizing NetWare Wide Area Networks"
- Introduction
- A Brief Overview of NLSP
- NLSP in a Nutshell: Three Databases and Four Packets
- How NLSP Works
- Sample Packet Trace
- WAN Issues
- Summary
- Glossary
Introduction
Administrators of wide area networks that include several long-distance WAN or LAN-to-LAN connections are familiar with the added expense incurred by constant transmission of overhead messages. In NetWare, these messages are generated by Routing Information Protocol (RIP) and Service Advertising Protocol (SAP) broadcasts. These broadcasts consume valuable bandwidth, thereby reducing the amount available for user data and increasing the costs associated with the WAN links. RIP and SAP overhead issues have hampered the use of NetWare in many WAN scenarios.
In the past, NetWare's design depended on these RIP and SAP messages for locating routes and services on the network. Now Novell provides a new technology that alleviates the problems created by RIP/SAP administrative overhead. To satisfy the demands of WAN users, Novell has introduced the NetWare Link Services Protocol (NLSP), a new link state protocol that greatly reduces the number of administrative broadcasts.
This AppNote explores in detail the internal operations of NLSP-based routers. After a brief overview of NLSP and the benefits it provides, we'll look at the key databases and packet types that make up NLSP. We'll then embark on a conceptual walk-through of how NLSP works in a sample four-server network, followed by a sample packet trace showing the actual data being transmitted. This advanced technical information should provide network designers, system administrators, and support personnel with a solid understanding of NLSP operations.
|
Howto Get NLSP Users of NetWare 3.12 can upgradeto NLSP using the IPX Upgrade for NetWare Servers kit availablein the IPXRTRx.EXE file, where x is a number indicating the revision(IPXRTR3.EXE at the time of this writing). For NetWare 4.1, thelatest NLSP software is in 41RTRx.EXE (41RTR2.EXE at this timeof this writing.) The current NLSP specification is in NLSP1_1.EXE.These files can be downloaded from NetWire on CompuServe, fromthe NSEPro CDROM, or from the WorldWide Web on the Internet. |
This AppNote assumes the reader is familiar with the basics of RIP/SAP and NLSP routing functions in a NetWare environment. Some good sources for this background information are the AppNotes entitled "NetWare Link Services Protocol: Link-State Routing in a NetWare Environment" and "Optimizing NetWare Wide Area Networks," both appearing in the May 1994 Novell Application Notes, and "Effectively Managing RIP and SAP Traffic with Filtering" in the September 1994 issue. For ease of reference, a short glossary of terms relating to NLSP is included at the end of this AppNote.
To keep the scope of this document manageable, we'll concentrate mainly on the operations of NLSP with routers connected to LAN segments. Throughout this document, it will be noted where the protocol behaves differently on a WAN link. The WAN operations of NLSP are detailed in the Novell NetWare Link Services Protocol (NLSP) Specification Version 1.1 document available from Novell (part no. 100001708-003).
A Brief Overview of NLSP
Before we examine the internal operations of NLSP, it will be helpful to briefly summarize its external functions and benefits. This section presents a few details about RIP/SAP and NLSP that are important to our discussion. Once these are understood, we can turn our full attention to what's happening behind the scenes.
|
Distance Vector Routing vs. Link State Routing With traditional distance vector routing protocols (such as IPX RIP in the IPX/SPX suite and IPRIP in the TCP/IP suite), routers typically exchange network topologyinformation through periodic broadcasts with their immediate neighbors.Each node consolid-ates the information it receives and passesthe summarized data to other routers, servers, and end nodes.Distance (in number of hops) is part of the criteria used to determinethe best route to forward packets onto. With link state routing, routerskeep track of the status of every communication link and routerin their routing area. When a change occurs, each router floodsinformation about itself and its immediate neighbors to everyother reachable router. Each router uses this information to buildits own map of the network, rather than relying on second-handinformation as do distance vector routers. Routers use their ownmaps to determine the best path to send packets to their destination. NLSP is based on the OSI IS-IS standard, but is adapted for use with Novell's IPX protocol (reference ISO 10589). |
NLSP is a protocol for the exchange of information between IPX routers. (The term "IPX router" is used generically to refer to a NetWare 3 or 4 server or router running either the IPX RIP/SAP protocols or the NLSP protocol, or both.) NLSP provides a link state approach to network-layer routing, geared to the needs of large IPX/SPX internetworks (see the sidebar entitled "Distance Vector Routing vs. Link State Routing").
NLSP is implemented as a NetWare Loadable Module™ (NLM™) called IPXRTR.NLM. This NLM can be loaded on servers running NetWare 3.11 or later. Several Novell products, including NetWare 4.1, NetWare MultiProtocol Router 3.0, and NetWare Connect 2.0, bundle NLSP. In addition, Novell has made the NLSP specifications available to router vendors and other third-party developers so they can implement it in their products. Router vendors such as Bay Networks, Cisco, and 3Com include NLSP in the current versions of their router software.
The paragraphs that follow discuss some of the key points to understand about NLSP.
NLSP reduces RIP and SAP traffic. NLSP is a more efficient protocol for updating route and services information than RIP and SAP. A RIP-based router sends a broadcast packet every 60 seconds even if nothing has changed since the last broadcast. By contrast, NLSP transmits routing information only when a change has occurred or after a much longer time interval has elapsed. The interval between NLSP message exchanges is configurable; the default is two hours.
NLSP eliminates periodic router and server SAP broadcasts by transmitting information about network services in the form of link state packets (LSPs). As with routing information, updates are sent out only when services change or after a longer time interval has elapsed. This makes NLSP a more efficient delivery mechanism for services information.
|
Note: SAP is also used by default to advertise the existence of timeservers in a NetWare 4 network. If you want to eliminate all SAPtraffic on your network, you can create a custom configurationthat turns off this SAP function on each time server. |
By reducing the amount of administrative overhead traffic, NLSP increases available bandwidth and decreases WAN link costs. In real-world tests, NLSP has been shown to reduce IPX routing traffic over a WAN link by as much as 40-to-1.
NLSP replaces router-to-router RIP and SAP traffic. However, it does not replace client-to-router traffic. (An example of this type of traffic would be the Get Nearest Server or Get Nearest Tree requests issued during the loading of the network requester at a workstation.) In fact, the use of NLSP has no impact at all on existing network client software or protocol stacks.
NLSP maintains compatibility with RIP/SAP. Any combination of NLSP-based routers and RIP-based routers can coexist in the same internetwork. In a mixed NLSP and RIP/SAP environment, routers running NLSP become "bilingual"; that is, they speak NLSP or RIP/SAP (or both) on a network segment-by-segment basis. In a mixed environment, RIP/SAP packets are converted into NLSP for transmission across the internetwork.
This approach allows you to upgrade one network segment at a time to NLSP. Upgrading in this way may be an important consideration, since many installed NetWare-compatible devices (NetWare 2.2 and 3.1x servers, print servers, LANalyzer for Windows, and so on) support only RIP/SAP.
NLSP eliminates the need for RIP/SAP filtering. While you can use RIP/SAP filtering to reduce the amount of routing and service information flowing across the network, it's too all-inclusive for many users. NLSP eliminates the need for filtering to reduce traffic. At the same time, it retains the ability to filter packets for security reasons. (Note that RIP/SAP filtering cannot be done on an all-NLSP network, as there are no RIP or SAP packets to filter.)
Key Benefits of NLSP
Of all the benefits NLSP provides, the following are most significant for the discussion at hand:
Improved routing efficiency. Whereas RIP routers only store information about the next hop for the router, each NLSP router stores a complete map of the network. NLSP routers can therefore choose more efficient routes and more readily select alternate paths when routers go down.
Reduced overhead. NLSP routers can do more efficient "multicasts" rather than simple broadcasts to all routers. (Multicasts send packets to a specific address rather than to all devices. Only routers listening for the specified multicast packet address will accept the routing information packet)
Very low bandwidth consumption. NLSP sends only updates to each router when changes occur, as opposed to RIP/SAP's periodic broadcasts of each router's entire routes and services database. The elimination of RIP/SAP broadcast packets results in lower bandwidth usage on LAN segments and, more critically, over WAN links.
NLSP packets also save bandwidth because of a more efficient packet structure. Service entries need not meet the required 64byte length of SAP packet entries. NLSP has the ability to compute the exact length of a service name and use variable-length service advertisements, eliminating the need to pad the packet with unused data. As a result, NLSP can fit more service information into smaller packets (see Figure 1).
Figure 1: A SAP-type service advertisement packet compared with an NLSP packet carrying similar information.
NLSP in a Nutshell: Three Databases and Four Packets
It's time now to introduce the basic elements of NLSP. These include three databases and four types of packets. NLSP uses the adjacency database to know who its immediate neighbors are, the link state database to keep track of all available links and network services, and the forwarding database to know what the fastest or "least cost" route would be to destinations on the network.
There are four packets that serve to provide the information in those databases. Hello packets are used to identify the router's nearest neighbors. NLSP uses Link State Packets to identify links (routes) and services on the system. NLSP uses Complete and Partial Sequence Number Packets to determine when and what it needs to update in its list of routes and services.
Figure 2 shows the relationship of the four NLSP packet types to the three databases.
Figure 2: NLSP uses four packet types to build and maintain its three databases and to communicate between routers.
The steps NLSP goes through to accomplish routing functions within a routing area are summarized below:
NLSP uses Hello packets to talk with all of a router's neighbors on all of its LAN or WAN circuits.
From the responses to the Hello packets, NLSP creates a list of immediate neighbors, called the adjacency database.
NLSP determines which of the neighboring routers will serve as the coordinator (called the Designated Router or DR) of updates to each of the neighbors per LAN.
The neighbors begin to share LSPs which tell each other about services they provide to the network. NLSP uses these LSPs to create the link state database.
From this link state database, NLSP derives the forwarding database using a decision process known as Dijkstra's algorithm. The forwarding database tells NLSP what the cheapest-cost route will be for various destinations.
The DR uses Complete Sequence Number Packets (CSNPs) to transmit its link state database to other NLSP routers on the LAN it is the DR for.
Those other routers respond using Partial Sequence Number Packets (PSNPs) to request missing information from the DR.
These steps will be explained in more detail as we proceed through this AppNote. For now, the important point is that the adjacency, link state, and forwarding databases are the key players in NLSP. Once you understand these databases, you'll understand how NLSP works and why it is such an economical protocol. The following sections briefly define each database. Throughout the AppNote, you'll be able to see the role each database plays in NLSP operation.
For purposes of this discussion, we'll use the sample network shown in Figure 3. In this case the "routers" are four NetWare 4.1 servers named R1, R2, R3, and R4. Each server attaches to an Ethernet network to service its users.
Figure 3: A sample NetWare WAN with four servers/routers.
The Adjacency Database
The adjacency database for a router contains information about all neighboring (adjacent) routers on the same physical network(s) as that router. Adjacencies are established based on the information the router receives from Hello packets. When a circuit is enabled, the router begins a periodic transmission of these Hello messages on that circuit. Since Hello packets go only to routers on the same physical network(s), a router knows that any responses it receives are from routers located within its immediate "neighborhood."
In our sample internetwork with four NLSP-based routers, router R1 sends Hello packets out each of its two circuits (01 and 02). On circuit 01 it receives a Hello response from router R2, and on circuit 02 it receives a response from router R3. R1 therefore establishes adjacencies with routers R2 and R3, and includes an entry for each of these neighbors in its adjacency database (see Figure 4).
Figure 4: A sample adjacency database.
Each entry in a router's adjacency database lists the name of a neighboring router, the circuit on which that neighbor is located, and the neighboring router's priority on that circuit. (Router priorities will be explained later in this AppNote.)
To keep its adjacency database current, R1 continues to send Hello messages at regular intervals on each of its enabled circuits. If a previously identified neighbor stops responding, or if R1 receives a new or changed Hello packet from a neighbor, the change is reflected in R1's adjacency database.
This same process occurs on every other NLSP-based router on the internetwork. The result is that each router has its own, unique adjacency database of immediate neighbors and directly-attached links. If you were to merge these individual databases into one conglomerate database, you would have a complete picture of all routers and links within the routing area. This is essentially what you have in the link state database.
The Link State Database
The link state database for a router contains a complete map of the network with services and router information - information that can be used to form an end-to-end path for getting packets to their destination. The link state database contains entries for all routers, links, services, and external routes on the network. (External routes are routes to RIP/SAP networks or to other routing areas.)
A router creates this database from information it receives via link state packets, or LSPs. An LSP is a packet that contains information describing the sending router's links and immediate neighbors. As each router initializes, it "floods" the network with LSPs about itself and the links, services, and external routes in its link state database. Other routers use these LSPs to build their own link state databases. Eventually, all routers in the routing area replicate and synchronize their link state databases so that each one has an identical copy of the database. Figure 5 shows the logical "diagram" of the sample network that router R3 builds from the LSPs it receives.
Figure 5: From the link information contained in LSPs, routers can build a logical "diagram" of the entire network.
Once the link state database is synchronized, routers issue LSPs in only two circumstances:
When changes occur in available links, services, or external routes
When each individual LSP expires (default two hours)
This is one reason NLSP is so economical compared with RIP/SAP routers, which send out packets continually even when the routing and services information hasn't changed. NLSP routers send packets much less frequently, or only when a change occurs.
The Forwarding Database
Each router combines the relevant information about destinations from the link state database to create a calculated forwarding database. NLSP derives the forwarding database using a decision-making procedure known as Dijkstra's algorithm. The results of these calculations sum up the "costs" of the various routes listed in the forwarding database.
Determining the Cost In routing, the term cost represents an estimation of the amount of delay or time a packet could take to travel from one router to another over a particular connection. Note that cost is based on a packet exiting the router, not entering it.
In NLSP, each type of interface has a link cost associated with it. For LANs, the link cost is based on the throughput of the adapter driver. For WANs, it's based on the measured throughput of the link. The cost of each link is given as a whole number between 1 and 63. A standard 10 Mbps Ethernet connection, for example, has its cost set at 20. A WAN connection made via a 2400-baud modem has a cost of 61.
The formula for determining this default cost metric is based on throughput and is given in the NLSP specification. Below is a partial listing:
|
Media Type
|
Default Cost
|
|
FDDI/CDDI |
14 |
|
16 Mbps Token Ring |
19 |
|
10 Mbps Ethernet |
20 |
|
4 Mbps Token Ring |
25 |
|
2.5 Mbps ARCnet |
26 |
|
E1 |
26 |
|
T1 |
27 |
|
ISDN |
45 |
|
2400 bps WAN |
61 |
You can manually override these default costs as needed for your individual network. For instance, suppose you want to set up two parallel LAN routes. You can make the cost high enough on the first LAN route that NLSP will avoid sending traffic over the second LAN route (unless it has to because the first route is unavailable).
Calculating the Best Routes for Forwarding To choose the most efficient routing paths, NLSP first adds up the cost values for each link or interface along the path. The lower the total cost, the more desirable the route is. The routes are then prioritized according to total cost, using Dijkstra's algorithm, and placed in the forwarding database. The forwarding database therefore indicates the "best" routes (those with the lowest total cost).
Since there might be several routes to a destination, the Dijkstra algorithm can eliminate all but the least costly route from the forwarding database. If by chance two or more routes have the same cost, NLSP retains multiple paths in the database to allow for equal load splitting between the different paths, up to the configured limit (maximum is 8).
|
Note: Although NLSP discards higher-cost duplicate paths from the forwardingdatabase, all such paths remain in the link state database. Ifa change occurs that affects a link somewhere on the network,it is reflected in the link state database and the forwardingdatabase is recalculated accordingly. |
Figure 6 illustrates how the forwarding database is generated for router R3 in our sample network.
Figure 6: A sample forwarding database showing the first hop for each route.
As you can see from Figure 6, the forwarding database lists the destination (Dest), first hop (1st Hop), circuit number (Cir), and MAC address (MAC Addr) of the adjacent routers. In the figure, all possible destinations for packets on this network are listed in the Dest column. Some destinations have more complete information than others. For example, since R3 is the router where this forwarding database exists, it lists "Self" in the 1st Hop column and circuit number 00 (its internal circuit number) in the Cir column.
The entries for the two adjacent routers, R1 and R2, include MAC addresses so R3 can properly address packets heading through R1 and R2. Further destinations accessible through R1 and R2 simply list R1 and R2 in the 1st Hop column.
Notice that there are two paths to R1 from R3. R3 will always choose the lowest-cost path through LAN A02. If that LAN becomes unavailable, R3 can use the alternate path through R2 to get to R1.
Since LAN destination B01 is accessible both from R1 and R2 with the same cost (one router hop in either direction), the forwarding database lists both in the 1st Hop column. This allows NLSP to choose either path for balancing traffic between the two.
A request to route a packet causes NLSP to verify the packet's path from the forwarding database. The packet then proceeds to the next hop in that path. Since NLSP has already determined the best (lowest cost) route, the packet can be efficiently routed without further calculation.
Again, if administrators prefer to have a different routing path, they can use INETCFG.NLM to set the cost of one route higher than another to make the forwarding database keep one and remove the other. This forced choice allows you to customize your system for particular needs. For example, you may want packets to avoid a shorter path that goes through server/routers, instead going through dedicated routers as the preferred path.
How NLSP Works
Now let's examine NLSP activity over time and discuss in more detail the processes of establishing adjacencies, building and maintaining the link state database, and calculating the forwarding database. We'll use the same four-router network as in the previous discussion.
Establishing Adjacencies
Every NLSP router periodically sends Hello packets on all its enabled circuits (networks). Hello packets establish what routers are active on the broadcaster's various network circuits. NLSP sends out Hello packets at startup time and then every 20 seconds by default (every 10 seconds for the DR).
The rate at which NLSP routers send Hello packets is modified by the jitter algorithm. In RIP/SAP, routers could accidentally become synchronized if, by a random occurrence, two routers transmitted packets simultaneously. This undesirable synchroni-zation would prevent information from flowing accurately over the network. To keep this from happening, NLSP forces Hello packets to go out at a more random set of intervals. Instead of exactly every 20 seconds, they go out at 17, then at 19, then at 16, then at 18, then at 20, and so forth. Since each NLSP router uses this jitter algorithm, the chances of two routers transmitting at the same time are very small.
As a result, any particular interval between Hello packets may be from 14 to 20 seconds for non-DR routers.
Routers discover and maintain adjacencies between routers via Hello packets. A router builds an adjacency list that includes the neighbor routers. In our example, R1's adjacency database includes both R2 and R3. R2's adjacency database includes R3 and R4. Each router's adjacency database is unique, unless the routers are all on the same networks at the same time with all circuits enabled.
Sample Hello Packet When router R1 starts up, it sends out a Hello packet similar to that shown in Figure 7.
Figure 7: The contents of a sample Hello packet.
nlsp:============NetWare Link Services Protocol============
Protocol ID: 0x83
Fixed Length: 27
Version: 1
Reserved: 0x00
Packet Type: 15 LAN Level 1 NLSP Hello
Version: 1
Reserved: 0x00
Reserved: 0x00
No Multicast: no
Circuit Type: Level 1 Only
Source ID: 0x0200000000B1
Holding Time: 30
Packet Length: 51
Priority: 100
LAN ID: 0x0200000000B101
Area Address Mask Option:
Code: 0xC0
Length: 8
Address: 0x00000000 Mask: 0x00000000
Local Packet Size Option:
Code: 0xC5
Length: 4
Local Packet Size: 1497
Neighboring Routers Option:
Code: 0x06
Length: 6
NIC Address: 0x00001B4AFA52
This sample Hello packet includes only the relevant NLSP section, omitting the header and IPX sections. (We'll look at a complete Hello packet later in this AppNote.) The important information to undertsand at this point is bolded and explained briefly below.
Packet Type Hello packets are identified as packet type 15 in NLSP. The possible packet types are listed below:
|
Type 15 |
Hello |
|
Type 18 |
LSP |
|
Type 24 |
CSNP |
|
Type 26 |
PSNP |
No Multicast: no Notice the line in the packet labeled "No Multicast: no." The Hello packet uses this double negative to express permission to do multicasting. If the line reads "No Multicast: Yes" then NLSP doesn't do a multicast. This multicast setting applies to all packets sent by this router, not just Hello packets. If one NLSP router comes up with No Multicast set to Yes, all other NLSP routers on that same segment will revert to sending broadcasts instead of multicasts, regardless of their No Multicast settings.
Holding Time The Shortest Path First (SPF) Holding Time is the time before Dijkstra's algorithm is run after a change is received.
Priority The Hello packet also states the broadcaster's priority. In the sample packet, the priority is set to 100. (This is a user-configured priority. We'll explain priorities in the "Designated Routers and Router Priorities" section below.) The default is 64, and a router initially broadcasts at a priority of 20 less, or 44.
Hello Handshake As R1 sends out its Hello packets, the "conversation" that takes place between routers R1 and R2 is in essence:
R1: "Hello, I'm R1 and I have no neighbors." R2: "Hello, I'm R2 and I have a neighbor R1." R1: "Hello, I'm R1 and I have a neighbor R2."
This handshake/confirmed handshake process establishes an adjacency between R1 and R2. R1 repeats the same process on all enabled interfaces with all neighbors, such as R3 on R1's other LAN interface. However, R1 does not exchange Hellos with R4, which is on a different network.
If there were a third router on the LAN segment with R1 and R2, the three routers would all be responsible for building adjacencies with each other. The result is the following:
R1: "Hello, I'm R1 and I have neighbors R2 and R5." R2: "Hello, I'm R2 and I have neighbors R1 and R5." R5: "Hello, I'm R5 and I have neighbors R1 and R2."
Tracking Dead Routers and Servers
The reason NLSP routers build these adjacency databases is so they can keep track of the status of their immediate neighbors. For example, if router R2 goes down, R1 needs to know about it right away in order to rebuild its link state database and therefore its forwarding database.
Router Dead Interval NLSP routers wait for a period of time known as the Router Dead Interval before marking a router in the adjacency database as unreachable, or "dead." The Router Dead Interval identifies how long the router will wait without getting a Hello packet from the inactive router prior to marking it unreachable. The Router Dead Interval is determined by multiplying the Hello sending interval by 3. For a DR router using a 10second Hello interval, the Router Dead Interval is 30 seconds; for a non-DR router using a 20-second Hello interval, it is 60 seconds.
The Hello exchange is a continuous process. If a router doesn't receive a Hello packet from a previously identified neighbor after the Router Dead Interval has expired, it marks the router as unreachable. However, the router retains LSPs for any unreachable routers in its adjacency database, until they reach the Maximum Age (the set interval for purging such LSPs).
Saving dead-router information in the adjacency database allows for an immediate update when that inactive router returns to the network. A router doesn't need to transmit and receive all LSPs to reacquaint itself with the other router. It only has to mark the other router as reachable again, and then exchange any changed LSPs.
With RIP and SAP distance-vector technology and its periodic broadcasting, it can take as long as 4 minutes for a router to discover that a neighboring router has gone away. But NLSP lets a router know in 30 to 60 seconds whether another router has gone away (due to the Router Dead Interval). It may be even sooner if the non-responding router is still there and the circuit has gone away.
Since WAN links have a way of going up and down, a router retains each LSP only reachable through another router up to that LSP's MAX AGE (default two hours). In a normal network, the timers for these LSPs will be random, so at the time the link goes down, any unreachable LSP remain in the adjacency database anywhere from one second to the full time remaining (default two hours).
Router Priorities and the Designated Router
If a router's initial Hello packets receive no response, NLSP proceeds with determining priorities and assigning a Designated Router (DR). NLSP assigns a Designated Router to manage link state database synchronization for each LAN. The DR takes charge of sending out Complete Sequence Number Packets (CSNPs), which provide a brief summary of the link state database so that other routers can make quick comparisons. Any changes or differences invoke additional activity to update each router. The DR is the only router that issues CSNPs. Other routers request update information from just the DR.
The DR also handles the translation and propogation of RIP/SAP information from non-NLSP sources. On a RIP/SAP LAN, the NLSP router simply wins the DR election because no other NLSP routers are running on that LAN. If there is RIP/SAP activity, the DR is responsible for capturing all information from RIP/SAP (for example, information on a print server). The DR then builds link state packets from these advertisements.
There is only one Designated Router per LAN. There may or may not be a DR for a WAN. When going from NLSP to RIP/SAP, there is a DR. When going from NLSP to NLSP, there is no DR.
As a simple example of how the DR is "elected," suppose R1, R2, and R3 are all on the same LAN, with priorities of 100, 64, and 44, respectively. As the router with the highest priority, R1 becomes the designated router.
|
Note: In this example, R1's priority was manually overwritten to be 100 instead of the default of 44. You can manually set priorities on the circuit, using theINETCFG.NLM utility. |
All NLSP routers begin by default with a priority of 44. If a router sends out its Hello packet twice and receives no response (that is, no other routers are currently active on the network), it escalates its own priority to 64. The first router to come up therefore becomes the DR for that network. When new routers appear on that LAN, the first router remains the DR, since each new router has the lower default priority of 44.
What happens if (against all probability) two routers come alive on the network at precisely the same time and both have a priority of 44? In this case, the router with the higher MAC address wins the toss and becomes the Designated Router. The new DR auto-matically escalates its priority to 64 to prevent anyone else with defaults from taking on the DR role.
NLSP uses a router's adjacency database to track both the priorities of its neighbors and their MAC addresses. (The MAC address doesn't arrive in the Hello portion of the packet. Rather, it's derived from the packet's header, since all network packets include the MAC address in the header.) NLSP determines which circuit the DR designation occurs on. This enables a router to serve as the DR for one network it's on but not for another.
It's best to maintain the same router as the DR. Every time the DR function switches to another router, the new DR renames the network, the link state databases must all be resynched, and LSPs go out all over the internetwork. The simplest way to avoid this problem is to choose one router to be the DR and give it a priority of 85 or higher (85 - 20 = 65, which is greater than 64).
The Purpose of Pseudonodes
The DR also creates something known as the pseudonode. The pseudonode has several important functions. For example, suppose you have several routers on a network, as in Figure 8.
Figure 8: A network backbone with four attached routers.
When you examine this physical representation of the network, you see that each router is located on the same wire as every other router. The logical view of this same network looks like Figure 9.
Figure 9: A logical map of the four-router network.
Note that each NLSP router in Figure 9 has many adjacencies to track. You might think, then, that NLSP creates substantial traffic in coping with these many adjacencies. However, NLSP gets around the problem of so much adjacency traffic by creating what is called a pseudonode. A pseudonode is a fictitious device on a logical network invented and maintained by the DR. Each network has one and only one pseudonode; all routers on that LAN attach to that pseudonode.
The link state packet of the pseudonode contains all of the information about the non-NLSP devices on the network. You may ask, why would the pseudonode do this? How can a fictional device have an LSP, anyway? Since the LAN segment can't generate an LSP, the DR generates the pseudonode LSP.
A pseudonode forces our sample network to have a logical map, as shown in Figure 10.
Figure 10: A logical map of the network with the NLSP pseudonode.
For each router to build its adjacency database, it has only to build a link with the pseudonode. It doesn't have to build a link with each of the three other routers.
Sample Adjacency Database. Once R1 initiates its Hello packet sending process and its immediate neighbors respond, it creates an adjacency database similar to this one:
|
Router
|
Circuit Number
|
Priority
|
|
R2 |
01 |
100 |
|
R3 |
03 |
64 |
|
Note: R1 can have different priorities on circuit 01 and circuit 03. |
This database indicates that R2 is on circuit 01 with a priority of 100 and that R3 is on circuit 03 with a priority of 64. (R2 is the DR on circuit 01 as well, since it has a priority of 100.)
Building a Link State Database
Once an NLSP router establishes its adjacency database, it proceeds to build its link state database. This database is a collection of all non-duplicate link state packets on the network, put together like building blocks.
Link State Packets (LSPs). Every router sends out a link state packet describing itself. For example: "I am R1. I have circuit 01. I have network address FACB124. I have file services, a print server, and an RCONSOLE server."
All other routers receive this information. For example, R2 picks up the information, adds it to its own link state database, and resends it, unchanged. R4, though, gets R3's information directly from R3, unmodified.
Each LSP is numbered, sequenced, and synchronized. In this way, each router can determine if it has seen a particular LSP before and discard the LSP if it has. The sequence number is used to track newer versions of a packet. The checksum is used for a "bad packet" check.
The receiver does not acknowledge LSPs on a LAN, but it does on a WAN. This results in a savings in overhead.
|
Note: To view the LSPs on your NLSP network, you can use IPXCON'sundocumented /P parameter. Type the command LOADIPXCON /P when you load the utility toprovide an "NLSP Information" menu option to display the LSPs. |
Sample LSP. Figure 11 shows a typical LSP with information on several services.
Figure 11: A sample LSP.
nlsp:============NetWare Link Services Protocol============
Protocol ID: 0x83
Fixed Length: 27
Version: 1
Packet Type: 18 Level 1 Link State Packet
Lifetime: 7496
LSP ID: 0x02000000000A0000
Sequence Number: 13
Checksum: 0x3DD2
Router Type: Level 1
Management Information Option:
Internal Network Number: 0x0000000A
Internal Node Number: 0x000000000001
Server Name: JOHN
Link Option:
Default Metric: 20 (internal)
Neighbor ID: 0x02000000000B01
Packet Size: 1497
Delay: 200
Throughput: 38528
Media Type: 0x0003 Ethernet
Services Information Option:
Hop Count: 0 (internal)
Network Number: 0x0000000A
Node ID: 0x000000000001
Socket: 0x0814
Type: 0x0107
Service Name: JOHN
Services Information Option:
Socket: 0x0451
Type: 0x0004
Service Name: JOHN
Services Information Option:
Socket: 0x0005
Type: 0x026B
Service Name: JOHN_TREE @@@HJ@@@@@DPaJ
Services Information Option:
Socket: 0x4006
Type: 0x0278
Service Name: JOHN_TREE @@@HJ@@@@@DPaJ
Again, the significant portions of this LSP are bolded and explained below.
Lifetime Each LSP includes a "Lifetime" entry that indicates how long NLSP will keep a nonreachable device (non-responding via Hello packets) in the link state database before purging it. For this reason, you wouldn't want to use a dynamic protocol like NLSP for environments where devices go down for long periods of time. This condition would occur, for example, with an on-demand (dial-up) WAN connection (static route).
LSP ID Each LSP is numbered with an ID to identify its contents. The syntax is:
0x0200 SOURCE ID | xx | yy
where SOURCE ID is the broadcaster's Internal IPX Address, xx is the circuit number on which the services are available, and yy is the fragment number. The LSP ID in Figure 11's sample LSP is:
0x02000000000A0000
Being interpreted, this identifies the LSP as follows:
Internal IPX Address = 0000000A Circuit number = 00 Fragment number = 00
If the packet includes all the information on changes that the broadcaster is aware of, the fragment number (yy) is 00, as in our example. Otherwise, NLSP divides the information into categories and ships it in several numbered packets. These categories are:
|
Information Category
|
Fragment Number
|
|
Link (or "all information") |
00 |
|
Services |
01 |
|
External Routes |
02 |
|
Overflow |
03+ |
|
Note: The Novell implementation may presently work like this. However,other vendors' implementations (3Com, Bay Networks, and Cisco) don'thave to operate this way. |
Packet Size The default packet size is 512 bytes. The Max LSP Size is configurable in INETCFG.NLM. This value should never be configured larger than the smallest Maximum Transmission Unit (MTU) found in the routing area, minus the data link headers. For example, if the MTU is 1500 bytes and the data link header is 14 bytes, the Max LSP should not be set larger than 1486 bytes.
Link Options and Services Information Options LSPs are generated on all route and service information, not only changes. A specific LSP will be regenerated based on change, as described below.
Synchronizing the Link State Database
If a router changes its services (for example, if RCONSOLE is unloaded), it sends the changed LSP to notify other routers of this change. Other routers recognize the LSP as an update to the link state database, since its sequence number differs from the previous LSP with the same LSP ID the routers have received. They pick up the LSP and make the update. Routers receiving a new LSP flood it out all other interfaces so the entire internetwork receives the LSP first-hand.
If an LSP with the same LSP ID and sequence number has a checksum which is the same as a previous update, routers discard it and do not forward or flood the packet. This prevents processing time from being wasted with a duplicate packet.
Each specific LSP is sent out every two hours (by default), or whenever there is a change.
The Sequence Number Packets
After a router builds a link state database, it maintains the database by using sequence number packets (SNPs). There are two types of SNPs: complete and partial.
Complete Sequence Number Packet (CSNP) The DR generates a CSNP every 30 seconds on the network for which it is the DR. The CSNP is a brief summary of the DR's link state database. This summary includes a list of LSP numbers, sequence numbers, and checksums (one for each LSP). All routers on the LAN receive the CSNP to check the status of their link state databases.
Figure 12 shows a sample CSNP packet.
Figure 12: A sample CSNP packet.
nlsp:============NetWare Link Services Protocol============
Protocol ID: 0x83
Fixed Length: 33
Version: 1
Reserved: 0x00
Packet Type: 24 Level 1 Complete Sequence Numbers Packet
Version: 1
Reserved: 0x00
Reserved: 0x00
Packet Length: 131
Source ID: 0x0200000000000B00
Start LSP ID: 0x00000000000000
End LSP ID: 0xFFFFFFFFFFFFFFFF
LSP Entries Option:
Code: 0x09
Length: 96
---------------------
Remaining Lifetime: 7232
LSP ID: 0x02000000000A00
Sequence Number: 13
Checksum: 0x3DD2
---------------------
Remaining Lifetime: 7407
LSP ID: 0x02000000000B0000
Sequence Number: 15
Checksum: 0xC246
---------------------
.
.
.
Remaining Lifetime: 7408
LSP ID: 0x02000000000D0000
Sequence Number: 7
Checksum: 0xBDE8
We shortened this sample CSNP packet by eliminating additional LSP entry blocks. Notice, though, that the DR has included all its LSPs from its link state database in abbreviated form - giving only the LSP ID, sequence number, and checksum. Each LSP is also marked with its appropriate Remaining Lifetime (how long each router keeps this LSP until it discards it as too old).
Each receiver analyzes the CSNP for any differences between the DR's link state database and its own. Should it find any discrepencies, the receiver issues a PSNP to request updates to its database, as explained below. For those LSPs the DR is missing, the router(s) holding the LSPs multicast the missing LSPs. If not, the receiver does nothing and ignores the CSNP.
Partial Sequence Number Packet(PSNP). If R1, as the DR, sends a CSNP to R2 and information in the CSNP doesn't match R2's information - meaning, for example, that R2 has a newer, higher sequence number LSP or the checksum doesn't match - then R2 sends a partial sequence number packet, or PSNP. The PSNP acts as a request for LSPs so R2 can resynchronize the information. R1 then broadcasts (or multicasts) the requested LSPs on the circuit on which it was requested.
If R2 has a newer, higher sequence number LSP or the checksum doesn't match, then R1 broadcasts or multicasts the appropriate LSPs on the circuit.
In other words, the newer information is always sent, usually from the DR, but as needed from other routers.
The DR is the only router to issue a CSNP over the LAN, and only non-DR routers issue PSNPs. All other communication over the network is handled by LSPs (to transfer information) and Hello packets (to verify a router's continued functioning).
Figure 13 shows a typical PSNP.
Figure 13: A typical PSNP.
Packet Type: 26 Level 1 Partial Sequence Numbers Packet
Source ID: 0x0200000000000C00
LSP Entries Option:
Code: 0x09
Length: 48
---------------------
Remaining Lifetime: 4723
LSP ID: 0x02000000000D0000
Sequence Number: 19
Checksum: 0x13FD
---------------------
Remaining Lifetime: 255
LSP ID: 0x020000000000D0100
Sequence Number: 15
Checksum: 0x000
Notice that the PSNP is much smaller than any other kind of packet except the Hello packet. It has only to list the LSPs that it requires to resynchronize.
In WAN operations, routers use PSNPs to acknowledge LSPs. We'll explain more about this later in this AppNote.
Calculating the Forwarding Database
Once a router (either the DR or any other) has synchronized its link state database to the others on the network, it can begin to create its own forwarding database. It keeps this database in RAM and quickly updates it as it receives new information via LSPs from other routers.
The forwarding database shows NLSP where it should address a packet to send it on its way. Since the forwarding database provides costing for each path, the packet can continue on its way knowing that it will travel along the cheapest route, as determined by the network administrator.
NLSP is always sending and receiving new Hello packets (every 10 or 20 seconds), even while the forwarding database is being updated. The DR also continues to send CSNPs to ensure LSP database synchronization. Finally, when required due to LSP database changes, the forwarding database is recalculated.
|
Note: It may seem that with NLSP you are simply exchanging excessiveRIP/SAP traffic for almost the same amount of NLSP packet traffic.This is not the case. It is important to realize that Hello packets,CSNPs and PSNPs pertain to and stay on the local LAN segment.Each LSP is flooded to all segments, typically once every twohours, unless it changes. RIP/SAP broadcasts do not cross NLSProuters either. Their contents are absorbed into LSPs and thenflooded across the internetwork. This contrasts with RIP/SAP wherethe entire contents of the routing and service tables are broadcastevery 60 seconds on every segment. |
The next section will take us from simple theory into an packet tracing to show how NLSP actually functions in generating routing information for a four-router network.
Sample Packet Trace
To give you a better understanding of the flow of information across an NLSP-equipped network, we'll look at a series of packets sent over such a system as seen by LANalyzer for Windows (LZFW), which is connected to the first network segment. First we'll look at a system equipped with a single router. Then we'll look at two, three, and finally four routers on the system.
Single Router System
We'll start with a router/server called Router John on network ED1 with an internal net number of EDBEEF9, as seen in Figure 14.
Figure 14: Single router--Router John.
Router John is also a NetWare 4.1 time server using NDS. As a server, Router John uses IPX on its NE2000 board for net ED1. Assume that Router John is just initializing.
To begin with, Router John issues a Hello packet:
PACKET NUMBER : 1 10:00:38 AM Sent by Router JOHN
Length : 94 bytes
802.3:
Station: JOHN ----> 09-00-1B-FF-FF-FF This is a multicast address
Length: 76
802.2:
SSAP: NetWare DSAP: NetWare
Unnumbered Command: Unnumbered Information (UI)
ipx:
Checksum: 0xFFFF
Length: 73
Hop Count: 0
Packet Type: 0(Unknown)
Network: 00 00 0E D1 ---> 00 00 00 00
Node: 00-00-1B-4B-0E-3C ---> FF-FF-FF-FF-FF-FF
Socket: NLSP ---> NLSP
nlsp:
Protocol ID: 0x83 NLSP Routing Layer
Fixed Length: 27
Version: 1
Reserved: 0x00
Packet Type: 15 - LAN Level 1 NLSP Hello
Version: 1
Reserved: 0x00
Reserved: 0x00
No Multicast: no Double negative means Yes Multicast
Circuit Type: Level 1 Only Level 1, 2, or 3
Source ID: 0x02000EDBEEF9 Internal IPX Address of sending router
Holding Time: 60 In seconds, to be used for sending router
Packet Length: 43 In bytes, including NLSP header
Priority: 44 Default is 64 (44+20)
LAN ID: 0x02000EDBEEF901 Source ID of the Designated Router / Circuit #
assigned by that router (since no DR has been
established, the router will use its own)
Area Address Mask Option: Set of Manual Area Addresses of sending router
Code: 0xC0
Length: 8 Total length of value field (8,16,24 bytes)
Address: 0x00000000 Mask: 0x000000FF Address and Mask are ANDed together
Local Packet Size Option: MTU
Code: 0xC5
Length: 4
Local Packet Size: 1497 Maximum packet size (in this direction) - includes
IPX header, but not data-link header
Since no other routers exist on Router John's networks, it receives no response to its Hello packet. Router John then issues a second Hello packet:
PACKET NUMBER : 2 10:00:54 AM Sent by Router JOHN
Length : 94 bytes
Packet Type: 15 - LAN Level 1 NLSP Hello
Source ID: 0x02000EDBEEF9
LAN ID: 0x02000EDBEEF901
Router John then issues its first LSP:
PACKET NUMBER : 3 10:00:55 AM Sent by Router JOHN
Length : 280 bytes
802.3:
Station: JOHN ----> 09-00-1B-FF-FF-FF
Length: 262
802.2:
SSAP: NetWare DSAP: NetWare
Unnumbered Command: Unnumbered Information (UI)
ipx:
Checksum: 0xFFFF
Length: 259
Hop Count: 0
Packet Type: 0(Unknown)
Network: 00 00 0E D1 ---> 00 00 00 00
Node: 00-00-1B-4B-0E-3C ---> FF-FF-FF-FF-FF-FF
Socket: NLSP ---> NLSP
nlsp:
Protocol ID: 0x83
Fixed Length: 27
Version: 1
Reserved: 0x00
Packet Type: 18 - Level 1 Link State Packet Packet Type 18 = LSP; Level 1 means within one
routing area
Version: 1
Reserved: 0x00
Reserved: 0x00
Packet Length: 229
Lifetime: 7499 How much longer until this LSP expires (in seconds)
- 7499 seconds = 2 hours, 4 minutes, 59 seconds
LSP ID: 0x02000EDBEEF90000 Source ID (internal IPX address), circuit #, and
fragment # of the router that created this LSP,
interpreted as follows:
Source ID: EDBEEF9
Circuit #: 00 (to the internal LAN)
Fragment # : 00 (reserved for link information)
Sequence Number: 23
Checksum: 0xC9B9 Calculated based on values from the Source ID to
the end of the packet
Partition Repair: Not supported
Default Metric: Not supported
Delay Metric: Not supported
Expense Metric: Not supported
Error Metric: Not supported
Overload: No Tells whether or not the LSP database is overloaded
Router Type: Level 1
Area Address Mask Option:
Code: 0xC0
Length: 8
Address: 0x00000000 Mask: 0x000000FF
Management Information Option: Information about the sending router
Code: 0xC1
Length: 16
Internal Network Number: 0x0EDBEEF9
Internal Node Number: 0x000000000001
IPX Version: 1
Server Name Length: 4
Server Name: JOHN
Link Option: Information about the Link(s) and Adjacent Router(s)
Code: 0xC2
Length: 25
Default Metric: 20 (internal) The cost of this link (Ethernet = 20)
Delay Metric: (not supported)
External Metric: (not supported)
Error Metric: (not supported)
Neighbor ID: 0x02000EDBEEF901 Source ID and Circuit # for neighboring router(s)
Packet Size: 1497 MTU size
Delay: 200 Time to transmit one byte (in microseconds)
Throughput: 38528 Amount of data that can be received in one
second (in bits)
Media Type: 0x0003 - Ethernet Range 0 to 21; taken from table of network types
Services Information Option: Information about services being advertised for
use
Code: 0xC3
Length: 19
Hop Count: 0 (internal)
Network Number: 0x0EDBEEF9
Node ID: 0x000000000001
Socket: 0x0451
Type: 0x0004 File Services
Service Name: JOHN
Services Information Option:
Code: 0xC3
Length: 61
Hop Count: 0 (internal)
Network Number: 0x0EDBEEF9
Node ID: 0x000000000001
Socket: 0x0005
Type: 0x026B Time Services
Service Name: JOHN_TREE_____
Services Information Option:
Code: 0xC3
Length: 61
Hop Count: 0 (internal)
Network Number: 0x0EDBEEF9
Node ID: 0x000000000001
Socket: 0x4006
Type: 0x0278 Directory Services
Service Name: JOHN_TREE_____
Router John next sends an LSP to establish the pseudonode, since it now assumes the role of DR for this network.
PACKET NUMBER : 4 10:00:55 AM Sent by Router JOHN
Packet Type: 18 - Level 1 Link State Packet LSP for Pseudonode ED1
LSP ID: 0x02000EDBEEF90100 LSP # ..90100
Source ID: System ID of Router that created LSP
Pseudonode ID: 01=Pseudonode # (Circuit # from DR)
LSP Number: Fragment # if too large to fit in one packet
Management Information Option:
Internal Network Number: 0x00000ED1
Internal Node Number: 0x00001BFF0E3C Typically MAC address of DR on this pseudonode LAN
Link Option:
Default Metric: 0 (internal)
Neighbor ID: 0x02000EDBEEF900 (List of) Link Neighbor ID = EDBEEF900 (JOHN)
Some seconds later, Router John issues a new Hello packet with its priority raised to 64, as explained in the comments:
PACKET NUMBER : 6 10:00:55 AM Sent by Router JOHN Packet Type: 15 - LAN Level 1 NLSP Hello Source ID: 0x02000EDBEEF9 Priority: 64 Priority elevated to 64 (44+20) to be Designated Router LAN ID: 0x02000EDBEEF901 Pseudonode System ID | Pseudonode #
|
Note: In our tracing we won't show all the packets, just the ones relevant to changes in the routing.. |
Router John now issues a pseudonode LSP for the LANalyzer for Windows services on the pseudonode:
PACKET NUMBER : 10 10:01:21 AM Sent by Router JOHN
Packet Type: 18 - Level 1 Link State Packet
LSP ID: 0x02000EDBEEF90101 - Pseudonode LSP LSP for LZFW SAP
Services Information Option:
Hop Count: 1 (external) Note: Internal Hop Count = 1
Network Number: 0x00000ED1
Node ID: 0x0000FF4B0415
Socket: 0x0000
Type: 0x026A LZFW SAP
Service Name: 00001B4B041500000000
As DR, Router John issues its first CSNP to broadcast the contents of its link state database:
PACKET NUMBER : 11 10:01:21 AM Sent by Router JOHN
Packet Type: 24 - Level 1 Complete Sequence Number Packet
Source ID: 0x02000EDBEEF900
Start LSP ID: 0x0000000000000000
End LSP ID: 0xFFFFFFFFFFFFFFFF
LSP Entries Option:
Code: 0x09
Length: 176
------------------------------
Remaining Lifetime: 7679
LSP ID: 0x02000EDBEEF90000 LSP for Internal Net EDBEEF9 (JOHN)
Sequence Number: 23
Checksum: 0xC9B9
------------------------------
Remaining Lifetime: 7473
LSP ID: 0x02000EDBEEF90100 LSP for Pseudonode ED1
Sequence Number: 4
Checksum: 0x454B
------------------------------
Remaining Lifetime: 7497
LSP ID: 0x02000EDBEEF90101 LSP for LZFW SAP
Sequence Number: 3
Checksum: 0x6F0B
-----------------------------
|
Note: Remaining Lifetimes will be decrementing until a new LSP is issued. |
After this point, Router John continues to go through this cycle until it encounters another router responding to its Hello packet on the system.
Two-Router System
Router John is quite content to remain a loner in its environment. But to see what happens in a more complex network, let's introduce a new router, Router Paul, into the system, as shown in Figure 15.
Figure 15: Two routers--Router John and Router Paul.
Suppose, too, that we've manually gone into Router Paul with INETCFG.NLM and set up the priority on circuit 01 as priority 100. This setting will force Router John to relinquish its DR role to Router Paul. (In all other ways, Router Paul is the same as Router John.)
As Router Paul initializes, it sends out a Hello packet:
PACKET NUMBER : 18 10:02:08 AM Sent by Router PAUL
Packet Type: 15 - LAN Level 1 NLSP Hello
Source ID: 0x0200EDBEEF10 New Router Internal Net (PAUL)
Priority: 80 Priority = 80 (manually set to 100 on Router)
LAN ID: 0x0200EDBEEF1001 Starting the process of assuming role of DR (Pn #) by
renaming the LAN
Router John's next Hello packet after receiving Paul's shows the adjacency:
PACKET NUMBER : 19 10:02:09 AM Sent by Router JOHN
Adjacency state set to "Initializing"
Packet Type: 15 - LAN Level 1 NLSP Hello Immediate response from JOHN
Source ID: 0x02000EDBEEF9
Priority: 64
LAN ID: 0x02000EDBEEF901
Neighboring Routers Option:
NIC Address: 0x00001B4B0D0B MAC address of neighbor's LAN attachment (PAUL)
Router Paul shows the adjacency to John:
PACKET NUMBER : 20 10:02:09 AM Sent by Router PAUL
Packet Type: 15 - LAN Level 1 NLSP Hello
Source ID: 0x0200EDBEEF10
Priority: 80
LAN ID: 0x0200EDBEEF1001
Neighboring Routers Option:
NIC Address: 0x00001B4B0E3C MAC address of neighbor's LAN attachment (JOHN)
Both Router John and Router Paul have established an adjacency relationship between themselves. Since Router Paul has the higher priority, it now assumes the role of DR:
PACKET NUMBER : 22 10:02:10 AM Sent by Router JOHN
Packet Type: 18 - Level 1 Link State Packet LSP for Internal Net EDBEEF9 (JOHN)
LSP ID: 0x02000EDBEEF90000 LSP # ..90000 (Same as packet # 3, but...
Management Information Option:
Internal Network Number: 0x0EDBEEF9
Server Name: JOHN
Link Option:
Default Metric: 20 (internal)
Neighbor ID: 0x0200EDBEEF1001 ... New DR System ID | Pseudonode #)
Packet Size: 1497
Delay: 200
Throughput: 38528
Media Type: 0x0003 - Ethernet
Services Information Option:
Hop Count: 0 (internal)
Network Number: 0x0EDBEEF9
Socket: 0x0451
Type: 0x0004
Service Name: JOHN
Services Information Option:
Service Name: JOHN_TREE
Services Information Option:
Service Name: JOHN_TREE
Router John sends an LSP about the old pseudonode. The new DR, Router Paul, ignores this LSP because it has newer information.
PACKET NUMBER : 23 10:02:10 AM Sent by Router JOHN Packet Type: 18 - Level 1 Link State Packet Tear down LSP # ..90100 (old pseudonode) LSP ID: 0x02000EDBEEF90100
Router Paul now sends out a Hello packet in its new role as DR:
PACKET NUMBER : 24 10:02:10 AM Sent by Router PAUL
Packet Type: 15 - LAN Level 1 NLSP Hello Assumes role of Designated Router
Source ID: 0x0200EDBEEF10
Priority: 100 Priority elevated to 100 (80+20)
LAN ID: 0x0200EDBEEF1001
Router John continues its process of removing old information about the former pseudonode (LANAlyzer for Windows) services from its link state database:
PACKET NUMBER : 25 10:02:10 AM Sent by Router JOHN Packet Type: 18 - Level 1 Link State Packet Tear down LSP # ..90101 LZFW SAP LSP ID: 0x02000EDBEEF90101 - Pseudonode LSP
Meanwhile, Router Paul as the new DR sends out its first CSNP:
PACKET NUMBER : 26 10:02:10 AM Sent by Router PAUL
Packet Type: 24 - Level 1 Complete Sequence Number Packet
Source ID: 0x0200EDBEEF1000
Start LSP ID: 0x0000000000000000
End LSP ID: 0xFFFFFFFFFFFFFFFF
LSP Entries Option:
Code: 0x09
Length: 144
------------------------------
Remaining Lifetime: 7679
LSP ID: 0x02000EDBEEF90000 LSP for Internal Router Net EDBEEF9 (JOHN)
Sequence Number: 24
Checksum: 0x4563
------------------------------
Remaining Lifetime: 7499
LSP ID: 0x0200EDBEEF100000 LSP for Internal Router Net EDBEEF10 (PAUL)
Sequence Number: 22
Checksum: 0x2A60
------------------------------
Remaining Lifetime: 7499
LSP ID: 0x0200EDBEEF100100 LSP for Pseudonode ED1
Sequence Number: 17
Checksum: 0xA527
------------------------------
Router John has waited the 14 to 20 seconds since its last Hello packet, so it issues a new one:
Packet Number : 27 10:02:10 AM Sent by Router JOHN
Packet Type: 15 - LAN Level 1 NLSP Hello
Source ID: 0x02000EDBEEF9
Priority: 64 No longer DR, but kept priority at 64!
LAN ID: 0x0200EDBEEF1001
Neighboring Routers Option:
NIC Address: 0x00001B4B0D0B
By now Router John has interpreted the new CSNP from Router Paul and issues its response in the form of a PSNP. The PSNP indicates that most of Router John's link state database is now outdated:
PACKET NUMBER : 28 10:02:11 AM Sent by Router JOHN
Packet Type: 26 - Level 1 Partial Sequence Numbers Packet Partial- "Say What!" packet
Source ID: 0x02000EDBEEF900
LSP Entries Option:
Code: 0x09
Length: 48
------------------------------
Remaining Lifetime: 4723
LSP ID: 0x0200EDBEEF100000 I don't know about LSP # ..100000
Sequence Number: 19
Checksum: 0x13FD
------------------------------
Remaining Lifetime: 255
LSP ID: 0x0200EDBEEF100100 I don't know about LSP # ..100100
Sequence Number: 15
Checksum: 0x0000
------------------------------
Router Paul is kind enough to issue two LSPs to update Router John (this is obviously before the breakup of the Beatles):
PACKET NUMBER : 29 10:02:11 AM Sent by Router PAUL
Packet Type: 18 - Level 1 Link State Packet LSP for Internal Net EDBEEF10 (PAUL)
LSP ID: 0x0200EDBEEF100000 LSP # ..100000
Management Information Option:
Internal Network Number: 0xEDBEEF10
Server Name: PAUL
Link Option:
Default Metric: 20 (internal)
Neighbor ID: 0x0200EDBEEF1001 Link Neighbor ID = Pseudonode ED1
Packet Size: 1497
Delay: 200
Throughput: 38528
Media Type: 0x0003 - Ethernet
Services Information Option:
Service Name: PAUL
Services Information Option:
Service Name: PAUL_TREE
Services Information Option:
Service Name: PAUL_TREE
PACKET NUMBER : 30 10:02:11 AM Sent by Router PAUL
Packet Type: 18 - Level 1 Link State Packet LSP for Pseudonode ED1
LSP ID: 0x0200EDBEEF100100 LSP # ..100100
Management Information Option:
Internal Network Number: 0x00000ED1
Internal Node Number: 0x00001BFF0D0B
Link Option:
Neighbor ID: 0x0200EDBEEF1000 Link Neighbor ID = EDBEEF10 (Paul)
Link Option:
Neighbor ID: 0x02000EDBEEF900 Link Neighbor ID = EDBEEF9 (JOHN)
|
Note: The above packets demonstrate the concept of pseudo-nodes (refer to Figure 10 earlier in this AppNote). Notice that routers are neighboring pseudonodes or LANs, and pseudonodes (LANs) are neighboring routers. In other words, John and Paul are not really neighbors, but are neighbors to the pseudonode. |
Later, Router Paul issues an LSP to broadcast the availability of the pseudonode (LANalyzer for Windows) SAP services:
PACKET NUMBER : 34 10:02:20 AM Sent by Router PAUL
Packet Type: 18 - Level 1 Link State Packet LSP for LZFW SAP
LSP ID: 0x0200EDBEEF100101 - Pseudonode LSP
Services Information Option:
Network Number: 0x00000ED1
Node ID: 0x0000FF4B0415
Socket: 0x0000
Type: 0x026A
Service Name: 00001B4B041500000000
Later still, Router Paul issues its second CSNP and begins again the cycle of maintaining the system's link state databases:
PACKET NUMBER : 39 10:02:36 AM Sent by Router PAUL
Packet Type: 24 - Level 1 Complete Sequence Number Packet
Source ID: 0x0200EDBEEF1000
Start LSP ID: 0x0000000000000000
End LSP ID: 0xFFFFFFFFFFFFFFFF
LSP Entries Option:
Code: 0x09
Length: 144
------------------------------
Remaining Lifetime: 7679
LSP ID: 0x02000EDBEEF90000 LSP for Internal Router Net EDBEEF9 (JOHN)
Sequence Number: 24
Checksum: 0x4563
------------------------------
Remaining Lifetime: 7472
LSP ID: 0x0200EDBEEF100000 LSP for Internal Router Net EDBEEF10 (PAUL)
Sequence Number: 22
Checksum: 0x2A60
------------------------------
Remaining Lifetime: 7472
LSP ID: 0x0200EDBEEF100100 LSP for Pseudonode ED1
Sequence Number: 17
Checksum: 0xA527
------------------------------
Remaining Lifetime: 7481
LSP ID: 0x0200EDBEEF100101 LSP for LZFW SAP
Sequence Number: 16
Checksum: 0x2073
------------------------------
Adding a Second LAN. Suppose we now add a second LAN to our system so that it looks like Figure 16.
Figure 16: Two routers with second LAN segment.
The next time Router Paul issues its CSNP, it shows an update to its link state database a new pseudonode on ED2.
PACKET NUMBER : 56 10:03:56 AM Sent by Router PAUL
Packet Type: 24 - Level 1 Complete Sequence Number Packet
Source ID: 0x0200EDBEEF1000
Start ID: 0x0000000000000000
End ID: 0xFFFFFFFFFFFFFFFF
Entries Option:
------------------------------
Remaining Lifetime: 7423
LSP ID: 0x02000EDBEEF90000 LSP for Internal Router Net EDBEEF9 (JOHN)
Sequence Number: 24
Checksum: 0x4563
------------------------------
Remaining Lifetime: 7499
LSP ID: 0x0200EDBEEF100000 LSP for Internal Router Net EDBEEF10 (PAUL)
Sequence Number: 23
Checksum: 0x0B02
------------------------------
Remaining Lifetime: 7391
LSP ID: 0x0200EDBEEF100100 LSP for Pseudonode ED1
Sequence Number: 17
Checksum: 0xA527
------------------------------
Remaining Lifetime: 7400
LSP ID: 0x0200EDBEEF100101 LSP for LZFW SAP
Sequence Number: 16
Checksum: 0x2073
------------------------------
Remaining Lifetime: 7499
LSP ID: 0x0200EDBEEF100200 LSP for Pseudonode ED2
Sequence Number: 18
Checksum: 0x21F1
------------------------------
Router John responds by sending a PSNP to ask for an LSP about this new pseudonode:
PACKET NUMBER : 57 10:03:56 AM Sent by Router JOHN
Packet Type: 26 - Level 1 Partial Sequence Numbers Packet
Source ID: 0x02000EDBEEF900
Entries Option:
Code: 0x09
Length: 32
------------------------------
Remaining Lifetime: 7391
LSP ID: 0x0200EDBEEF100000 ... 100000 has changed
Sequence Number: 22
Checksum: 0x2A60
------------------------------
Remaining Lifetime: 255
LSP ID: 0x0200EDBEEF100200 I don't know about ...100200
Sequence Number: 17
Checksum: 0x0000
Router Paul responds with two appropriate LSPs:
PACKET NUMBER : 58 10:03:57 AM Sent by Router PAUL
Packet Type: 18 - Level 1 Link State Packet for Internal Net EDBEEF10 (PAUL)
ID: 0x0200EDBEEF100000
Management Information Option:
Internal Network Number: 0xEDBEEF10
Server Name: PAUL
Link Option:
Neighbor ID: 0x0200EDBEEF1001 Link Neighbor ID = Pseudonode ED1
(adjacent to pseudonode, not router)
Link Option:
Neighbor ID: 0x0200EDBEEF1002 Link Neighbor ID = Pseudonode ED2
Services Information Option:
Service Name: PAUL
Services Information Option:
Service Name: PAUL_TREE
Services Information Option:
Service Name: PAUL_TREE
PACKET NUMBER : 59 10:03:57 AM Sent by Router PAUL
Packet Type: 18 - Level 1 Link State Packet For Pseudonode ED2
ID: 0x0200EDBEEF100200 # ..100200
Management Information Option:
Internal Network Number: 0x00000ED2
Internal Node Number: 0x00001BFF75D7
Link Option:
Neighbor ID: 0x0200EDBEEF1000
Later, Router Paul issues a CSNP with identical informaton as in Packet Number 56, except for the Remaining Lifetime count:
PACKET NUMBER : 65 10:04:23 AM Sent by Router PAUL
Packet Type: 24 - Level 1 Complete Sequence Number Packet
Source ID: 0x0200EDBEEF1000
Start ID: 0x0000000000000000
End ID: 0xFFFFFFFFFFFFFFFF
Entries Option:
Code: 0x09
Length: 144
------------------------------
Remaining Lifetime: 7423
LSP ID: 0x02000EDBEEF90000 LSP for Internal Router Net EDBEEF9 (JOHN)
Sequence Number: 24
Checksum: 0x4563
------------------------------
Remaining Lifetime: 7472
LSP ID: 0x0200EDBEEF100000 LSP for Internal Router Net EDBEEF10 (PAUL)
Sequence Number: 23
Checksum: 0x0B02
------------------------------
Remaining Lifetime: 7364
LSP ID: 0x0200EDBEEF100100 LSP for Pseudonode ED1
Sequence Number: 17
Checksum: 0xA527
------------------------------
Remaining Lifetime: 7373
LSP ID: 0x0200EDBEEF100101 LSP for LZFW SAP
Sequence Number: 16
Checksum: 0x2073
------------------------------
Remaining Lifetime: 7472
LSP ID: 0x0200EDBEEF100200 LSP for Pseudonode ED2
Sequence Number: 18
Checksum: 0x21F1
------------------------------
Three-Router System
Once we have our two-router system running smoothly, we'll rudely interrupt its peace and tranquility by introducing a third router, Router Ringo (see Figure 17).
Figure 17: Three routers--John, Paul, and Ringo.
|
Note: You do not see Ringo's Hello packets on network ED1. They are broadcast or multicast and do not cross routers. |
The packet update sequence is quite similar to the two-router system. Router Paul is already broadcasting its Hello packets and the two have exchanged greetings.
Now Router Paul floods the LSP about the new router onto ED1:
PACKET NUMBER : 69 10:04:41 AM Sent by Router PAUL (flooded by Paul for Ringo)
Packet Type: 18 - Level 1 Link State Packet LSP for Internal Net EDBEEF11(RINGO)
LSP ID: 0x0200EDBEEF110000 # ..110000
Management Information Option:
Internal Network Number: 0xEDBEEF11
Server Name: RINGO
Link Option:
Neighbor ID: 0x0200EDBEEF1002 Link Neighbor ID = Pseudonode ED2
Services Information Option:
Service Name: RINGO
Services Information Option:
Service Name: RINGO_TREE
Services Information Option:
Service Name: RINGO_TREE
Router Paul then floods an updated LSP about its new "neighbor"-- network EDBEEF10:
PACKET NUMBER : 70 10:04:42 AM Sent by Router PAUL
Packet Type: 18 - Level 1 Link State Packet for Pseudonode ED2
LSP ID: 0x0200EDBEEF100200 # ..100200
Management Information Option:
Internal Network Number: 0x00000ED2
Internal Node Number: 0x00001BFF75D7
Link Option:
Neighbor ID: 0x0200EDBEEF1000 Link Neighbor ID = EDBEEF10 (PAUL)
Link Option:
Neighbor ID: 0x0200EDBEEF1100 Link Neighbor ID = EDBEEF11 (RINGO)
Router Paul then issues its CSNP on schedule, which Router John can read and compare:
PACKET NUMBER : 72 10:04:50 AM Sent by Router PAUL
Packet Type: 24 - Level 1 Complete Sequence Number Packet
Version: 1
Source ID: 0x0200EDBEEF1000
Start ID: 0x0000000000000000
End ID: 0xFFFFFFFFFFFFFFFF
Entries Option:
Code: 0x09
Length: 144
------------------------------
Remaining Lifetime: 7423
LSP ID: 0x02000EDBEEF90000 LSP for Internal Router Net EDBEEF9 (JOHN)
Sequence Number: 24
Checksum: 0x4563
------------------------------
Remaining Lifetime: 7445
LSP ID: 0x0200EDBEEF100000 LSP for Internal Router Net EDBEEF10 (PAUL)
Sequence Number: 23
Checksum: 0x0B02
------------------------------
Remaining Lifetime: 7337
LSP ID: 0x0200EDBEEF100100 LSP for Pseudonode ED1
Sequence Number: 17
Checksum: 0xA527
------------------------------
Remaining Lifetime: 7346
LSP ID: 0x0200EDBEEF100101 LSP for LZFW SAP
Sequence Number: 16
Checksum: 0x2073
------------------------------
Remaining Lifetime: 7490
LSP ID: 0x0200EDBEEF100200 LSP for Pseudonode ED2
Sequence Number: 19
Checksum: 0x8A77
------------------------------
Remaining Lifetime: 7490
LSP ID: 0x0200EDBEEF110000 LSP for Internal Net EDBEEF11 (RINGO)
Sequence Number: 10
Checksum: 0x8086
------------------------------
From there, Router Ringo issues PSNPs to request updates via LSPs from Router Paul.
Adding a Third Network. Suppose we complicate things still further and create a network similar to the one shown in Figure 18.
Figure 18: Adding a third network segment to the three-router system.
Router Ringo re-issues the LSP on ED2 and Paul forwards it to net ED1:
PACKET NUMBER : 87 10:05:56 AM Sent by Router PAUL (flooded by Paul for Ringo)
Packet Type: 18 - Level 1 Link State Packet for Internal Net EDBEEF11 (RINGO)
LSP ID: 0x0200EDBEEF110000 # ..110000
Management Information Option:
Internal Network Number: 0xEDBEEF11
Server Name: RINGO
Link Option:
Neighbor ID: 0x0200EDBEEF1002 Link Neighbor ID = Pseudonode ED2
Link Option:
Neighbor ID: 0x0200EDBEEF1102 Link Neighbor ID = Pseudonode ED3
Services Information Option:
Service Name: RINGO
Services Information Option:
Service Name: RINGO_TREE
Services Information Option:
Service Name: RINGO_TREE
PACKET NUMBER : 88 10:05:56 AM Sent by Router PAUL (flooded by Paul for Ringo)
Packet Type: 18 - Level 1 Link State Packet for Pseudonode ED3
LSP ID: 0x0200EDBEEF110200 # ..110200
Management Information Option:
Internal Network Number: 0x00000ED3
Internal Node Number: 0x00001BFFFB93
Link Option:
Neighbor ID: 0x0200EDBEEF1100 Link Neighbor ID = EDBEEF11 (RINGO)
When Router Paul issues its next CSNP, it looks like this:
PACKET NUMBER : 92 10:06:10 AM Sent by Router PAUL
Packet Type: 24 - Level 1 Complete Sequence Number Packet
Source ID: 0x0200EDBEEF1000
Start ID: 0x0000000000000000
End ID: 0xFFFFFFFFFFFFFFFF
Entries Option:
Code: 0x09
Length: 144
------------------------------
Remaining Lifetime: 7423
LSP ID: 0x02000EDBEEF90000 LSP for Internal Router Net EDBEEF9 (JOHN)
Sequence Number: 24
Checksum: 0x4563
------------------------------
Remaining Lifetime: 7364
LSP ID: 0x0200EDBEEF100000 LSP for Internal Router Net EDBEEF10 (PAUL)
Sequence Number: 23
Checksum: 0x0B02
------------------------------
Remaining Lifetime: 7256
LSP ID: 0x0200EDBEEF100100 LSP for Pseudonode ED1
Sequence Number: 17
Checksum: 0xA527
------------------------------
Remaining Lifetime: 7265
LSP ID: 0x0200EDBEEF100101 LSP for LZFW SAP
Sequence Number: 16
Checksum: 0x2073
------------------------------
Remaining Lifetime: 7409
LSP ID: 0x0200EDBEEF100200 LSP for Pseudonode ED2
Sequence Number: 19
Checksum: 0x8A77
------------------------------
Remaining Lifetime: 7485
LSP ID: 0x0200EDBEEF110000 LSP for Internal Net EDBEEF11 (RINGO)
Sequence Number: 11
Checksum: 0x98EF
------------------------------
Remaining Lifetime: 7486
LSP ID: 0x0200EDBEEF110200 LSP for Pseudonode ED3
Sequence Number: 4
Checksum: 0x3577
------------------------------
A Four-Router System
Finally, suppose we add a fourth router called Router George to the system, as shown in Figure 19
Figure 19: Router George is added to the system.
Once again, Router George and Router Ringo exchange greetings. George issues an LSP and Ringo and Paul flood it.
PACKET NUMBER : 99 10:06:41 AM Sent by Router PAUL (flooded by Paul for Ringo)
Packet Type: 18 - Level 1 Link State Packet LSP for Pseudonode ED3
LSP ID: 0x0200EDBEEF110200 # ..110200
Management Information Option:
Internal Network Number: 0x00000ED3
Internal Node Number: 0x00001BFFFB93
Link Option:
Neighbor ID: 0x0200EDBEEF1100 Link Neighbor ID = EDBEEF11 (RINGO)
Link Option:
Neighbor ID: 0x0200EDBEEF1200 Link Neighbor ID = EDBEEF12 (GEORGE)
Ringo and then Paul also flood an LSP for Router George so it can update its own link state database:
PACKET NUMBER : 101 10:06:48 AM Sent by Router PAUL (flooded by Paul and Ringo for George)
Packet Type: 18 - Level 1 Link State Packet LSP for Internal Net EDBEEF12 (GEORGE)
LSP ID: 0x0200EDBEEF120000 # ..120000
Management Information Option:
Internal Network Number: 0xEDBEEF12
Server Name: GEORGE
Link Option:
Neighbor ID: 0x0200EDBEEF1102 Link Neighbor ID = Pseudonode ED3
Services Information Option:
Code: 0xC3
Service Name: GEORGE
Services Information Option:
Service Name: GEORGE_TREE
Services Information Option:
Service Name: GEORGE_TREE
The next time Router Paul as the DR issues its CSNP, it looks like the following, which shows information from all the available routers:
PACKET NUMBER : 105 10:07:03 AM Sent by Router PAUL
Packet Type: 24 - Level 1 Complete Sequence Number Packet
Source ID: 0x0200EDBEEF1000
Start ID: 0x0000000000000000
End ID: 0xFFFFFFFFFFFFFFFF
Entries Option:
Code: 0x09
Length: 144
------------------------------
Remaining Lifetime: 7423
LSP ID: 0x02000EDBEEF90000 LSP for Internal Router Net EDBEEF9 (JOHN)
Sequence Number: 24
Checksum: 0x4563
------------------------------
Remaining Lifetime: 7310
LSP ID: 0x0200EDBEEF100000 LSP for Internal Router Net EDBEEF10 (PAUL)
Sequence Number: 23
Checksum: 0x0B02
------------------------------
Remaining Lifetime: 7202
LSP ID: 0x0200EDBEEF100100 LSP for Pseudonode ED1
Sequence Number: 17
Checksum: 0xA527
------------------------------
Remaining Lifetime: 7211
LSP ID: 0x0200EDBEEF100101 LSP for LZFW SAP
Sequence Number: 16
Checksum: 0x2073
------------------------------
Remaining Lifetime: 7355
LSP ID: 0x0200EDBEEF100200 LSP for Pseudonode ED2
Sequence Number: 19
Checksum: 0x8A77
------------------------------
Remaining Lifetime: 7431
LSP ID: 0x0200EDBEEF110000 LSP for Internal Net EDBEEF11 (RINGO)
Sequence Number: 11
Checksum: 0x98EF
------------------------------
Remaining Lifetime: 7476
LSP ID: 0x0200EDBEEF110200 LSP for Pseudonode ED3
Sequence Number: 5
Checksum: 0xD4C5
------------------------------
Remaining Lifetime: 7478
LSP ID: 0x0200EDBEEF120000 LSP for Internal Net EDBEEF12 (GEORGE)
Sequence Number: 8
Checksum: 0x14B1
From these LSPs, all routers can build a network diagram in RAM to calculate best routes.
WAN Issues
As mentioned earlier, on a LAN routers don't acknowledge link state packets. Instead, they rely on the CSNP/PSNP process. WAN links, however, acknowledge an LSP (or multiple LSPs) with a PSNP.
Now let's consider how NLSP benefits WANs in three different scenarios: NLSP routers at both ends of a PPP link, an NLSP and a RIP/SAP at each end of a PPP link, and an on-demand link.
NLSP Router at Both Ends of the WAN Link
Suppose you have NLSP routers at both ends of a WAN link. If you as the administrator establish the WAN link, one router sends a CSNP across the link to synchronize its database with the router on the other side of the link. The two recognize that they are part of a WAN link and adjust by using a new protocol called IPXWAN V2 to handle communications across the WAN link.
With IPXWAN V2, the two see themselves as directly-attached routers. There is no DR, pseudonode, or IPX Network number coming between them or representing the WAN link. In essence, IPXWAN V2 treats this WAN link not as a LAN but as a pipe. Network information isn't sent across this pipe unless required. LSPs are sent and acknowledged. No CSNPs are sent after the first one.
NLSP to RIP/SAP Router on the WAN Link
Suppose that one of the two routers is a RIP/SAP router. In that case, the NLSP router automatically becomes the DR and creates a pseudonode to absorb the RIP/SAP information. The link may or may not have a network number assigned to it, depending on the results of the IPXWAN negotiation.
Since RIP/SAP traffic now goes across the WAN link, it is better to have NLSP routers at the ends of all WAN links.
On-Demand Link
With an on-demand link, in which the links come and go, no NLSP data exists on the WAN link. This link may be up only a minute a day. There is no IPX network number. Routing information in this case is created by the administrator with static routes, rather than by NLSP. This static routing information is maintained in a pseudonode LSP.
Summary
The new NLSP protocol saves significant amounts of bandwidth for WAN users. In addition, it's faster and more effective than RIP/SAP in communicating network services availability across the system. NLSP has no impact on clients.
Glossary
adjacency database. A database of adjacencies which contains information about all routers on the same physical network. This database is built from information that a router receives from its Hello packets.
area. A collection of connected networks all having the same area address.
area address. The network address and mask in a routing area.
checksum. A number calculated from the values contained in a packet's fields, used to detect transmission errors and memory corruption. In NLSP, the router originating an LSP computes the checksum when the LSP is generated. The checksum is never modified by any other system as the LSP propagates.
circuit number. A number or ID that NLSP assigns to LAN or WAN links and to the internal network (not the same as a network number). The internal network's circuit number is always 00; 01 and up are dynamically assigned by the router as protocols are bound.
Complete Sequence Number Packet (CSNP). A packet issued only by the Designated Router that describes the network's synchronized link state database entries.
cost. A metric assigned to a circuit that determines the likelihood of traffic being routed over that circuit.
Designated Router (DR). A router assigned by NLSP to manage link state database synchronization for each LAN.
Dijkstra algorithm. The computational process by which a tree of shortest paths is calculated. In NLSP, this algorithm is used to generate the forwarding database.
external route. A route to an attached RIP/SAP network from an NLSP network.
forwarding database. A database of forwarding paths that is generated internally by NLSP, using the Dijkstra algorithm. The results of these calculations indicate the "costs" of various routes in the forwarding database.
fragment number. A number that NLSP assigns to a packet to identify its contents.
jitter algorithm. The built-in algorithm NLSP uses to vary the time interval at which it sends out Hello packets to prevent two routers from transmitting simultaneously and becoming falsely synchronized.
Level 1 routing. The interaction of routers with the same routing area.
Level 2 routing. Routing between areas to form a routing domain controlled by a single administrative entity within an organization.
Level 3 routing. Routing between routing domains controlled by different administrative entities between different companies.
link. An entry point on a LAN or WAN, such as a T1 connection.
link state database. A database which contains a complete map of the network, including all links, routers, services, and external routes. With this information, a router can form an end-to-end path for packets to reach their destination.
Link State Packet (LSP). A packet generated by a router in a link-state routing protocol. An LSP lists that router's neighbors and attached networks.
Maximum Transmission Unit (MTU). The maximum frame size allowable to be sent between two nodes.
multicast. A transmission method where only those devices that are listening for a specified multicast packet address accept the packet. Unlike a broadcast, in which the packet is generically addressed so that all routers read the packet, a multicast packet has the address of a selected set of routers that should read it. Other routers ignore it.
NetWare Link Services Protocol (NLSP). A new link-state protocol for IPX-based NetWare networks. IPX routers can use NLSP instead of RIP/SAP to share information about their routes with other devices on the network. NLSP replaces router-to-router RIP and SAP traffic.
on-demand link. A WAN link that is activated by user data.
Partial Sequence Number Packet (PSNP). A packet used to update a router's link state database. Each router that receives a CSNP analyzes it for any differences between the Designated Router's link state database (as shown in the CSNP) and its own. If it finds any discrepencies, the receiver issues a PSNP to request updates for its database.
pseudonode. A fictitious entity that represents the LAN as a whole in the link state database. It is used to streamline NLSP operation when many routers are attached to the same LAN. The Designated Router represents the LAN pseudonode for LSP generation.
router. A device that connects two or more networks using the same networking protocol, and which makes forwarding decisions to pass data efficiently between different network segments. Routers operate at the Network layer of the OSI model.
router dead interval. In NLSP, the time period that upon expiration a neighboring router is marked unreachable.
routing area. A subset of routers in an entire internetwork.
Routing Information Protocol (RIP). A distance-vector protocol that provides a measure of distance, or hops, from a transmitting node to a receiving node.
service. An application or function that is accessible on a network for example, file service, print service, or RCONSOLE. In non-NLSP NetWare networks, these services use SAP to advertise their availability. In NLSP, routers maintain information about available services in the link state database.
Service Advertising Protocol (SAP). A broadcast-based protocol responsible for disseminating information about available services to all nodes in an IPX network.
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.