
----------------------------------------------------------------------------
NOV-NLSP.DOC - 19970423 - Email thread on Novell Link State Routing Protocol
----------------------------------------------------------------------------

	Feel free to add or edit this document and then email
	it back to faq@jelyon.com




Date: Tue, 18 Oct 1994 10:13:36 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: NLSP, IPX routing info reduction
To: NOVELL@LISTSERV.SYR.EDU

>Does anyone know if/when Wellfleet will support these enhancements?

	While it would be very nice to have our WAN routers support
NLSP it is not really necessary in many cases. Think of the WAN router
as a border router, at the edge of a cloud, and it speaks RIP/SAP to
its counterpart at the other end of the wire. If the router is decent
then it will not relay everything it hears (basically bridging) but
will send one copy of the RIP/SAP tables to the other end say at worst
once per minute. Our ciscos are set to do this every few minutes.
	Meanwhile, back on the backbone, by making the local NW
servers NLSP-only, with a few speaking both NLSP and RIP/SAP, we cut
the local routing traffic by quite a bit.
	As a test case I made my NW 4.02 test server speak NLSP only.
That meant adding  rip=no sap=no nlsp=yes  on the Bind IPX line in
autoexec.ncf and I said  Load ipxrtr routing=none. This is a leaf
node with only one lan adpater, so it need not do routing. My main NW
3.12 server, netlab2, is set to be bilingual (old Bind IPX line, Load
ipxrtr routing=nlsp) and thus it is the information resource for the
NW 4 server. Works fineso far. I'll convert more as time develops to
down/up each server.
	As NLSP grows up we will find that the routing system can
support a real heirarchy of routing nodes. Version 1 supports only one
level, Version ?? will support two or more. When version 2 arrives I
hope to see the regional addressing of NLSP (one cloud or another),
and the region address I suggest be the IPX address of the wire
closest to the main backbone. This is extending the Utah NW naming and
numbering case. But version 1 has only region address 00000000.
	Joe D.

------------------------------

Date: Thu, 19 Oct 1995 01:33:24 GMT
From: Daniel Tran <dtran@UCLA.EDU>
Subject: Re: NLSP

>Is there someone who gets information (detailed) about NLSP and IPX
>RIP SAP. I am looking for information that would explain how these
>protocols work...

Pretty good explaination is in the manual.  Did you download that??.  Joe D.
did talk about NLSP a while back.  Heck, I'm free so let me do a search on
NLSP in my mailbox.... Ah, found quite a few, but I think this one will help.
Below is Joe D. message on NLSP: (note: this one dated oct 17, 94 - a year and
one day ago - newer versions of NLSP has been out since then).
Daniel Tran - dtran@ucla.edu

--- Forwarded message follows ---
Date: Mon, 17 Oct 1994 19:51:10 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: NLSP, IPX routing info reduction

	This is a note to make system managers aware that Novell Link
State Routing protocol (NLSP) is now available for NW 3.1x and 4.x
file servers.
	Files of interest are
	netwire\novlib\01:
		ipxrtr.exe (732KB)
		ipxdoc.exe (1.39MB)
	netlab2.usu.edu odi\ipx_rtr:    (also on sjf-lwp.novell.com)
		nlsp.exe (470KB)

	NLSP is a fairly modern way of dealing with large quantities of
routing information broadcast by each server every 60 seconds. Instead
of sending the huge RIP tables of all servers known and their distances
servers interchange periodic tiny "hello" msgs to see if the wire is
still working. Once in a while a full routing table is sent around, and
routing updates are issued when a link goes up or down.
	NLSP works best if a router can be designated to act as a routing
table keeper for a whole bunch of NW servers, and let the bunch interact
with the tiny hello guys. The designated router then chats with other
designated routers, United Nations style, with RIP. Thus the D.R. does
the busy work on behalf of the local servers. Network folks love drawing
pictures of fluffy cumulus clouds (never nimbus clouds mind you) labeled
"network inside" (oh, Intel has patented that too have they?). The cloud
is our local bunch, and clouds interact via the border routers (the D.R.
machines).
	In a nutshell, why tell everyone about every route we've ever
heard of every 60 sec when things just don't change that rapidly. Futher,
why not just relay info about the wires connected to this server rather
than all those way the heck and gone.
	Anyway, the idea is to cut way down on the net.admin RIP packets
that clutter our busy networks. The full manual, nlsp.exe, is a Postscript
doc which is very well written and illustrated to walk us through the
concepts and actions. Recommended reading.
	The current NLSP issue is v1.0 (yeah, but I've inflicted it upon
my servers tonight and they have survived at least 20 minutes now, so it
can't be all bad). The netwire\novlib\01 files cited above have a very
thin installation manual and the sundry NLMs. It's a Product Install
option via floppies or Rconsole, and it is simple indeed.
	This issue has NLMs automatically supporting both NLSP and regular
RIP so there is no loss of functionality as servers are upgraded to NLSP.
Clients are not affected; they work as before, no changes whatsoever.
	I suspect there will be a long period of discussion as people
bring up NLSP support and begin to look into turning off RIP on most
servers around the site in favor of NLSP on most and RIP on very few.

	There are load balancing tools with this issue too to deal with
multiple lan adapters hooked to the same IPX network. And IPX routing
can be turned off altogether.
	Joe D.

------------------------------

Date: Wed, 22 Nov 1995 09:18:45 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: NLSP Configuration on a 3.xx network

<big snip>

>You might want to consult www.Novell.COM and browse for NLSP info and
>the some e-pub documentation on the subject.
>I believe there are also postcript files on the subject.
----------
	Both regular and NLSP routing of IPX have voluminous documentation
(Postscript) and the files are available from directory ODI\IPX_RTR on
netlab2.usu.edu. File ipxrtr.exe discusses regular IPX routing, nlsp.exe
discusses NLSP routing.
	Joe D.

------------------------------

Date: Thu, 30 Nov 1995 14:31:36 GMT
From: Phil Randal <philr@HWCCES.DEMON.CO.UK>
Subject: Re: Any reason to use NLSP

>I have two site with Netware 3.12 server & Ethernet  at each side .
>I'm in process to install a Welfleet router to connect between the sites
>(WAN connection over dedicated 64K line) .
>My router software include support to NLSP (ver 9.0).
>
>Is there any reason to install NLSP as NLM on my servers in addition to
>the router NLSP  ?

Probably...

ftp://ftp.novell.com/pub/updates/nwos/nw312/ipxrt3.exe is the file you
want.

We have a busy NW 3.12 server sharing a backbone with over 40 other
Netware servers.  We found that collisions on our local thin Ethernet
segments halved after installing ipxrt3 and setting routing=nlsp.

Phil Randal

------------------------------

Date: Wed, 6 Dec 1995 14:59:49 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Re[2]: Balance NLM

>Before this thread closes, has anyone tried the NSI or NLSP NLMs
>to load balance between a 10 Mb and a 100 Mb Ethernet card?  I
>talked to cisco tech support about doing this and they thought it
>should work but expressed some concerns about <blah>
----------
	One does NOT want to "load balance" to the same destination wire.
A regular Ethernet board is able to fill a 10Mb/s Ethernet wire, so there
is nothing good to say about schemes trying to use two or three Ethernet
boards in a server attacking the same wire.
	Again, load balancing is effective if the server is feeding
different wires, one per board, and for some peculiar reason one wishes to
not place a router between the wires. That means an Etherswitch is the
common way of multiplexing wires to server boards. An Etherswitch is a
bunch of bridges, and as we all recall bridges forward or not based on MAC
addresses on "this side" and "the other side" (it learns by observing, and
until it learns it leaks worse than the Pentagon and White House combined).
	If there is no traffic from one wire to the other then an
Etherswitch is an expensive room heater. The only advantage of one in this
case is bypassing IP subnetting. Proxy ARPing is the cheap way of achieving
much the same goal, but in software.
	Pictures for those who like them:

	| lan A         | lan B         | lan C      | lan D
	|               |               |            |
	|               |               |            |
	\               \               /            /
	 \               \             /            /
	  \               |           |            /
	-----------------------------------------------
	|   Etherswitch, forms cross over              |     A single
	|   connections between [A..D] set             |     IP/IPX
	|   and [a..d] set, and between                |     network,
	|   [A..D] to [A..D].                          |     no subnet,
	------------------------------------------------     and A..D
	   | a          | b             | c          | d     can talk to
	   |            |               |            |       A..D. If no
	-------------------------------------------------    A..D to A..D
	|                                               |    traffic then
	|    NW server with 4 lan adapters, a..d.       |    forget about
	|    Each can fill a whole wire.                |    Etherswitch.
	-------------------------------------------------

	Joe D.

------------------------------

Date: Thu, 7 Dec 1995 10:49:38 GMT
From: Phil Randal <philr@HWCCES.DEMON.CO.UK>
Subject: Re: IPX SAP filtering

>I am wondering what other institutions with large networks
>( more than 150 file server and several hundred printers )
>are doing to filter out some of the SAP traffic which is
>broadcast by all of these devices.  I'm vaguely familiar
>NLSP but I'm not sure it is a viable option for a University
>setting.  It seems that NLSP will not be very useful for a
>few years until devices such as print servers and gateways
>support it.

We have 45 servers visible on our backbone, with an awful lot of
RIP/SAP traffic.  NLSP does improve things considerably here, inasmuch
as it dramatically reduces RIP/SAP on the ethernet segments local to
our server, virtually halving the collisions on these segments.

So I don't understand your 'not viable' comment.

>Our environment is a large University campus with an FDDI backbone
>made up of 10+ Cisco routers.  Is anyone else concerned with the
>once-a-minute-blast of RIP/SAP info that the Cisco's pump out.

Hasn't Cisco come up with an NLSP firmware upgrade for their routers?

>What I'm really interested in is schemes that have been adopted to
>reduce SAP/RIP traffic.

Phil Randal

------------------------------

Date: Fri, 8 Dec 1995 11:07:52 +0100
From: Henno Keers <Mailbox@ICE.NL>
Subject: Re: IPX SAP filtering

>>Our environment is a large University campus with an FDDI backbone
>>made up of 10+ Cisco routers.  Is anyone else concerned with the
>>once-a-minute-blast of RIP/SAP info that the Cisco's pump out.
>
>Hasn't Cisco come up with an NLSP firmware upgrade for their routers?

It is available in IOS 11.x, check out www.Cisco.COM.

------------------------------

Date: Tue, 23 Jan 1996 15:30:18 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: IPX Upgrade problem

>I hope someone can give me a input for this problem,  we have over 2500
>Novell file servers on our WAN, which is include Netware 4.x & 3.x. On
>the Netware 3.x server console, when you type DISPLAY SERVERS, you
>will see over 4000 servers, however I only see 3200 servers on the
>Netware 4.x server.
>
>I don't know is something do with IPXRTR.NLM, because this is a
>standard from Netware 4.x, also we are not using NLSP for all Netware
>4.x servers yet. But if I put two NCI instead of one, I would able to
>see over 4000 servers, Is this has a limitation on one NIC only or not
>enough bandwidth for that complex environment??
----------
	Certainly looks like inadequate time on the wire to get all the
SAP and RIP traffic across before the cycle repeats. You really should
partition your networks for less junque traffic and also fully deploy
NLSP. If you use real routers then all outside RIP/SAP traffic can be
condensed into one burst each on the other side of the router, thus
saving a very large amount of redudant traffic. Keep in mind that the
recommended spacing between RIP and SAP packets is about 50ms, so the
stream would be spaced out over a rather long time interval. Without
spacing weaker lan adapters get steamrollered flat.
	If adding a second lan adapter helps then your network is in
terrible shape and needs redesign to carry real traffic adequately.
The above items are steps in that direction. Intelligent use of a
wire monitor, say Novell's Lanalyzer/Windows or a NG Sniffer, will
tell a lot about the state of the net.
	Joe D.

------------------------------

Date: Tue, 19 Mar 1996 10:41:05 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: WAN PERFORMANCE -Reply

>This may seem silly, but does NLSP run on 3.x? I thought it was a built-in
>enhancement for 4.x. Is it actually a product that lays on top of the OS?
>Are there any gotchas about this product? I presume that Cisco routers
>figured out SAP optimization a long time ago. Wouldn't installing NLSP on
>top of that be like wearing suspenders and a belt?

	Jerry, give it a try. Please visit the ftp.novell.com and mirror
archives, get the NLSP material from the IPXRT<digit>.EXE package, go
to directory odi\ipx_rtr on netlab2.usu.edu (or /pub/mirror/odi/ipx_rtr on
netlab1.usu.edu) and obtain the protocol spec manual NLSP.EXE (Postscript).
	Please do not be brainwashed by marketing attempts to push NW 4
via bundling and handing out two user gumdrops.
	To really "read more about it" here are two other pieces of homework
(sic) for you, if you become interested enough to pursue modern routing
techniques. First is the small set of RFC's on OSPF (open, shortest path
first) routing, which is the IP equivalent of NLSP. You might notice that
Novell's MultiProtocol Router (and its cutdown companion in NW 4) supports
OSPF. Second is the book "Bridges and Routers" by Radia Perlman who is now
with Novell. She's been involved with OSPF and NLSP since the beginning;
an interesting and amusing book.
	If my grad networking class can dissect OSPF/NLSP as 10% of their
project work for the term then I think other interested parties can wade
through the original docs. Just think of it as OJT for networking
professionals.
	Joe D.

------------------------------

Date: Wed, 22 May 1996 18:30:06 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: NLSP on 3.12 servers (IPXRT3)

>Well I took the plunge and installed NLSP on one of my servers. The
>install is fairly simple, and IPXCON is a nifty utility. I guess you have
>to have 4.1 to have INETCFG, so I don't know what's available there.
>Barring any complications, I'll be rolling it out to the rest of the system
>shortly.  Question: Is there much available in the way of tuning these
>NLMs? It seems the only things you can do are enable or disable
>SAP/RIP, disable routing altogether, filter Netbios packets, and do load
>balancing. How can you assign priority to various paths, or do SAP
>filtering, or do various other tweaks? The docs are pretty weak.
---------
	NetWare 3.x? Then that's it. To read more about it, unquote, you
can get the formal specs, file odi\ipx_rtr\nlsp.exe, which unpacks to a
Postscript document, on netlab2.usu.edu (or pub/mirror/odi... on netlab1).
	Joe D.

------------------------------

Date: Thu, 23 May 1996 14:23:31 +0100
From: Phil Randal <philr@HWCCES.DEMON.CO.UK>
Subject: Re: Novell 3.12 and IP

>NetWare/IP will help you cut your SAP and RIP traffic down to almost
>nothing which would be a big benefit to you in this kind of highly
>meshed topology. You'd probably notice a 10-15% improvement over raw
>IPX on the WAN.

NLSP (from ftp://ftp.novell.com/pub/updates/nwos/nw312/ipxrt3.exe)
will also do a lot to cut RIP/SAP traffic.  Make sure your routers
can handle it, though.

------------------------------

Date: Mon, 8 Jul 1996 12:44:05 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: IPXRTR Cannot Load Public Symbols

>This is really baffling me. I have setup our server to load balance
>between two NIC's and had it working successfully. Then when I downed the
>server and brought it back up again I get an error saying that IPXRTR.NLM
>cannot be loaded due to an error in the configuration and then it says
>that it is unable to load some public symbols. Does anyone here know what
>to do about this?
>
>In my autoexec.ncf I have this:
>:
>load ipxstack
>load ipxrtr routing=nlsp
>load ipxrtrnm
>:
>:
>load and bind NIC's
>
>Remember that it did work so i don't think there is anything wrong with
>my auto and startup files. I've also applied the latest patches and file
>updates to our NW3.12 server.
-------------
	There are patches and there are updates, if one wishes to be picky
about changed files. While you may have the patches (FX stuff) most likely
your CLIB is behind the times (updates material). Please visit again
ftp.novell.com or official mirrors, updates\nwos\nw312 directory, and do a
"raid&plunder".

	While NLSP works ok here on NW 3.12 and 4.10, we are almost ready
to discard it. The reason is one can't filter networks and selected service
objects to be either imported or exported across a Cisco router path,
yet we must do that for a large network. NLSP simply does not permit that
kind of filtering, yet Cisco is able to do it with IPX RIP/SAP. So far we
see a net loss with NLSP: much useless physical layer broadcasts from
remote regions, no isolation of one region from another leading to an
almost unmanageable and distinctly unwanted merging of information from
all regions. Very disappointing, and I've started a dialog about it with
the major players involved.
	Joe D.

---------

Date: Mon, 8 Jul 1996 16:56:24 -0400
From: "David P. Moon" <DavidPMoon@WPNENGR.IH.NAVY.MIL>
Subject: Re: IPXRTR Cannot Load Public Symbols

[Floyd: above msg], Joe Doupnik wrote:

NOV-NLSP.DOC needs updating.  Looks like NLSP benefits are
dependent on the LAN/WAN size.  The network has to be large
enough to benefit from the reduced RIP traffic NLSP
provides, but small enough that you don't need to filter
networks and selected service objects.

---------

Date: Mon, 8 Jul 1996 15:27:55 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: IPXRTR Cannot Load Public Symbols

In [Floyd: the above msg], David P. Moon wrote:
	Not just the doc, the protocol itself.
	Let's look at RIP/SAP for a moment. Tiny boxes emit them to
announce their presence; fine. NW servers put that information into their
local routing tables (bindery, directory services). NLSP says, if a wire is
found to have RIP/SAP traffic on it then put RIP/SAP traffic on it, unless
told to put only NLSP there. "Auto" mode, the default, says speak if heard.
Now most wires carry double the traffic for the same information.
	NLSP further behaves that everything learned from one place is
spread to every other NLSP place, with no hope of filtering. Uh oh. NLSP
has both routing (link state style, but routes to places) as well as lists
of services (and how far away too).
	Imagine a slow WAN link. The NLSP collector pours everything from
one side to the other, tiny printer boxes, UPS', rconsole's, managed hubs,
and all else under the sun. That makes little sense and worse networking.
With raw RIP/SAP we can often (Cisco does) filter RIP/SAP so that only
selected items cross the WAN wire in either direction. My WAN wires cover
education in the whole state.
	Imagine a fully wired student housing complex on a campus, with
goodness knows what being plugged into the wires. Would you risk your site
to whatever anyone puts on the wires being believed and relayed all round?
That's worse than IP RIP small white lies. With NLSP that's what happens.
	NLSP can be slowed down to update less often than 60 sec RIP/SAPs,
but by default it doesn't and generates more traffic than RIP/SAP alone.
Hmmmm. Automode re-emission of info by RIP/SAP from NLSP is also not a
swift choice: listening and learning is ok, but control is needed on
speaking too.
	We need NLSP-like routing to reduce the traffic as networks grow.
RIP/SAP scales poorly with network size. But the non-filtering aspect of
NLSP makes growth just as painful if not worse.
	The lack of filtering is the blunder here, and it's a fatal one as
far as my area is concerned. To change the protocol behavior means changing
the protocol, not just route aggregation (NLSP 1.1, in Ciscos, not in
NetWare software that we can touch) and other clever schemes in the making,
but to rethink the matter from the beginning and keep one foot firmly on
the ground (in the trenches) at the same time.
	Joe D.

------------------------------

Date: Thu, 15 Aug 1996 10:33:50 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Server Documentation (was: AUTOEXEC.NCF commands)

>Thanks!  NLSP a risk?  Haven't looked into it, but would love some short
>commentary on current state as it's supposed to be a future direction here...
--------
	Short form: it is fatally misdesigned, forget it.
	NLSP permits no filtering of information coming in and going out.
Filtering is necessary for any medium sized and larger network. That is
a fatal misdesign. This is not so much a security issue as it is a traffic
volume issue. NLSP does not live up to its advertising of reducing network
traffic; in practice it makes traffic intensity worse.
	NLSP will speak RIP/SAP if it is allowed to listen to RIP/SAP and
it hears info that way. Wrong! Speaking doubles traffic on the wire, for no
useful purpose.
	I am in the middle of a big discussion on the matter with the
designers of the protocol. My attitude is negative: it is broken, either
fix it or withdraw it.
	Lesson for the group: do not trust experts for they develop tunnel
vision. The NLSP folks are very bright and capable, they just forgot the
essentials while concentrating on playing with the toys.
	Joe D.

------------------------------

Date: Tue, 3 Sep 1996 16:04:51 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: NLSP  experience ? -Reply

>Well, Joe D is down on NLSP, and I'm sure for good reasons. He's a
>protocol and routing expert, knows how to read packet debugs, and
>knows how this stuff is "supposed" to work. If Joe says that NLSP is
>weak and should be ripped out or avoided, that opinion should be heavily
>weighted.
>
>On the other hand, I run NLSP in my 3.x environment. 14 servers
>connected on 56k frame relay links. Lots of printers, which are SAP
>machines. While we were in the implementation phase of our WAN, the
>links were frequently saturated by SAP traffic. When we installed NLSP,
>the link saturation went away. Granted, the problem could have probably
>been fixed by other means. But NLSP was the first thing we tried, and it
>worked great. We are still using NLSP, our network is stable, and we've
>seen no problems.
------------
	I think I had better expand my comments a little so there is
sufficient context for others to accept or reject the conclusions.
	NLSP itself creates less traffic than regular RIP/SAP, or so
we are told. Yes and no is the answer in practice. If there are a number
of server objects on a wire speaking RIP/SAP (one or the other or both)
then each contributes a SAP for itself and for networks on their hidden
sides. Putting all these across a WAN link does indeed use lotsa bandwidth.
NW servers emit longer RIP/SAP lists which include all they've heard, which
is more bandwidth consumed.
	NLSP condenses such information into less frequent messages. There
are small Hello packets between adacent connections to verify that the links
are still up, and periodic full scale update messages to all and sundry.
	A NW server can be told to use NLSP-only, or RIP/SAP-only, or to
be automatic and speak/listen to both if RIP/SAP is heard from the outside.
Since there are extremely few tiny boxes speaking NLSP these days they speak
RIP/SAP. We may therefore conclude such boxes will be ignored if the wire
does NLSP-only. That means we end up speaking both NLSP and RIP/SAP, for
more traffic than RIP/SAP alone on that particular wire.
	A bilingual NetWare server (RIP/SAP and NLSP) hears RIP/SAP msgs
and incorporates their information into the NLSP database. It then reemits
that information in NLSP traffic. The problem, and it can be a show stopper,
is there is currently no way of filtering out certain RIP/SAP items from
either NLSP updates sent from the NW server nor from NLSP updates sent to
the server.
	A consequence of no filtering is NLSP carries everything ever heard
from one place to every other NLSP place, willy nilly, and we can't prevent
it. At my site this has proven to be a catastrophe of the first magnitude.
We filter RIP/SAP at our Cisco routers to a) heavily reduce the information
seen outside a neighborhood, b) and thus heavily reduce the amount of
traffic seen on any wire, and c) prevent/block certain areas (say, student
dorms with their 2-user NW 4.10 gumdrops) from contacting anything off their
wire.
	It so happens that my neighborhood for IPX work is the educational
system for the entire state of Utah, K12..Univ's. Can you imagine the amount
of traffic if every IPX advertizing object were announced, and I mean
*every*, from all sites to every wire? The wires would melt, servers would
die, clients would be overwhelmed, SLIST/NLIST would produce listings
thousands of items long. Try DISPLAY SERVERS/NETWORKS on your server to see
what your site is like. That's what NLSP does. Not a good situation.

	Major failing number one is NLSP can't be filtered as it stands now.
Failing number two is NLSP compliant stations are obliged to speak RIP/SAP
if they are able to listen to RIP/SAP, for reasons I can't fathom. They
might need to listen but have no need to speak, but that's not allowed. On
my wires we saw both RIP/SAP and NLSP, redundant traffic. NLSP dumped
information on everything onto the local wire. The routing traffic about
doubled, the useless information quantity went through the ceiling.
	Ok, with me so far? NLSP is an indiscriminant sponge but an
efficient transporter, and it encourages background chatter by RIP/SAP
participants.

	Now let's take a WAN situation. Suppose we have a decent router
box on each end of the WAN link, and servers + clients on each side too.
If the router does RIP/SAP only on the sites, filters stuff there, and
does NLSP-only on the WAN link, then we reduce the junque traffic on the
WAN link. Reduction is achieved by eliminating redudant msgs, by less
frequent updates, by more compact representation; all good things. On
the other hand what needs to be said will increase if filtering is not
done.
	The advantage is achieved only if filtering can be done before
data gets into the NLSP database. Otherwise you are better off filtering
RIP/SAP and sending compendium RIP/SAP msgs across the WAN link every
several minutes (which is exactly what we have been doing for years in
Utah). Which is the better depends on your routers and local conditions,
so please give it some thought and perhaps an experiment or two.

	I've mentioned to people a little phrase, "be wary of experts
for they develop tunnel vision." It applies here particularly, and that
includes myself. The NLSP/OSPF (basically the same thing from basically
the same people) folks are very sharp indeed. They missed the big picture
of reducing the traffic. Please put on your think cap, consider matters,
warm up the packet monitor and see if thinking and practice agree.
	Joe D.

---------

Date: Wed, 4 Sep 1996 14:29:06 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: NLSP  experience ? -Reply -Reply

>Let me see if I understand this. The main problem is that NLSP doesn't
>allow filtering of RIP/SAP. It will rebroadcast that protocol to all its NLSP
>neighbors, ensuring that all routers in the network are aware of all RIPs
>and SAPs in the network. Since the other RIP/SAP devices are busy
>broadcasting themselves anyway, this causes duplicate traffic. Another
>problem is that you can't block network A from knowing about networks
>B through Z, even though that knowledge is undesired.
>
>So why did my WAN traffic decrease? Was all the RIP/SAP encapsulated
>in NLSP on the WAN link, and none of the native RIP/SAP hit the wide
>area?
>
>My network isn't nearly as large as yours, we only have 142 services
>advertising, and 43 networks. I actually want everyone to see
>everything. Is it OK for me to stick with NLSP?
-----------
	What are your routers routing/bridging? I can't answer that but
you should be able to do so. That's the key.

	Let me give another example, the way we do things at my place.
Cisco routers couple major chunks of the local network plus site to site.
They route IPX. They are told to repeat RIP/SAP information onto the
backbones every three minutes, and on the local segments they play the
every-minute game of normal IPX devices (they replay the RIP/SAP
information every minute).
	That means a Cisco accumulates all the RIP/SAP traffic heard on a
local segment into one pile without duplication. That pile is sent outward
every three minutes. Similarly, outside information comes to that Cisco and
is put into a pile for repetition onto the local wire. There is no
duplication, there is less repetition.
	Without filtering every place would hear every IPX thing about every
other place; that's not a good idea. But we filter. There is no need for
Janet on the east edge of things to hear about John's UPS on the west edge
of things. We chop out IPX traffic from student dorms, and that includes
their NW 4.10 two user toys. From site to site we advertize only several
selected NW servers, no printers, no UPS', no junk. Each such server has
a complementary Guest login for folks to jump to from abroad. We filter
what comes in so less-than-astute managers outside cannot clobber our site,
and that is *vital*. Filtering is the way to control traffic in a large
network; large networks don't survive being large without filtering.
	When we turned on NLSP support in our Ciscos the routing traffic
went way up on each local wire. We lost all filtering ability. NLSP was
doing nothing positive at all for us, yet making life miserable at the same
time.

	So, to get any benefit from NLSP one needs to have a wire carrying
NLSP but no RIP/SAP traffic. Clearly, that wire won't hear tiny boxes, only
compliant NW servers and that real router. Let one simple SAP appear on the
wire and suddenly you have RIP/SAP plus NLSP, or that SAP is ignored by
the NW server(s) and the real router.
	Ordinary local wires, with sundry boxes and servers, don't benefit
by having NLSP present; they are hurt by it. That much should now be clear.
	If your particular router boxes can deal with IPX RIP/SAP on one
(local) port, filter them, and speak NLSP on the WAN port, then you can
be gaining benefits. Please do recall that "real routers" often have their
own protocols for WAN links which are efficient compressors of information
and hence make NLSP unnecessary; Ciscos are in that situation with EIGRP.
Filtering alone reduces unnecessary traffic. The protocol used on the
isolated (WAN, whatever) wire can be NLSP or other efficient protocol to
compress what's said and reduce the frequency of saying things.
	Joe D.

------------------------------

Date: Fri, 15 Nov 96 01:55:52 -0800
From: Randy Grein <rgrein@halcyon.com>
To: "NetWare 4 list" <netw4-l@bgu.edu>
Subject: Re: IPXRTR

>Would someone briefly explain to me what the IPX NLSP Router (IPXRTR.nlm)
>does in IntranetWare? Do you _need_ it or is it just used for advanced
>routing? Also, what's the equivalent of this in a 3.x environment? Did it
>also exist in 4.1 or is it new to 4.11? Thanks again!

Novell is migrating from the old RIP (routing internet protocol) to NLSP.
The NLSP.nlm provides some of this functionality; I believe that if you
were to use inetcfg to turn of NLSP this module would no longer load.
There's an equivilent for 3.x, but only if you add the router updates -
3.12 even predates NLSP. The functionality was always in 4.1, but if I
remember correctly the module itself came with the router updates.

------------------------------

Date: Wed, 23 Apr 1997 09:11:59 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: IPXRTR ( was Re: TCPN03.EXE)

>H'mmm; No reference to ipxrtr shown, or is that part of 'etc'?
>The autoexec.ncf carried in the FAQ does show ipxrtr in use, has
>ipxrtr fallen out of favor?
>
>As I segue into a new thread, I intend to use ipxrtr to reduce
>broadcasts on the LAN here, 5 NW312 servers, Lanalyzer is our primary
>tool, monitoring NetWare protocol to Broadcast on a single server.
>I note peak packets/s on that server is actually for higher for load
>ipxrtr routing=nlsp than for 'routing=ripsap'. 76 for NLSP and 30 for
>RIPSAP. Am I off base?; NLSP broadcasts services for all devices in
>it's route table only when a path to a service changes, as opposed to
>RIPSAP which does it every 30 seconds. A moot point for me anyway as I
>plan to use 'routing=none', so that a server only broadcasts it's own
>services.
------
	There is indeed no NLSP support at all on my NW 3.12 server netlab2.
As I explain about every six months, NLSP is a bad choice on any link save
those which have no RIP/SAP emitters on it. Look at your wire monitor
closely, discover:
	a) Servers must listen to RIP/SAP for the tiny boxes out there, and
NLSP rules compel them to also speak RIP/SAP. Guess what happens to routing
traffic. Yup, doubled: one set in NLSP and a copy in RIP/SAP. There is no
way of being an NLSP listener without being a NLSP talker, etc.
	b) There is no, none, zero, ability to filter what NLSP carries.
Yet large sites must filter many kinds of RIP and SAP items to protect the
rest of the site from junque overload or security invitations. We can filter
RIP/SAP but not NLSP, so NLSP becomes the <too> efficient conveyor of all
routing/advert stuff to all wires. Should my place really relay everything
that is transmitted from student housing? That is no way to run a large
network.
	We tried NLSP in a serious way at my site and were appalled. It
was quickly removed and discarded.
	If you have a WAN link with only a router at each end then you can
use NLSP across that wire. If those routers are Cisco units then Cisco has
their own routing protocol doing the same or better job than a file server
with NLSP. In short, NLSP (and OSPF) is a nifty protocol looking for a
proper environment in which to prosper, and one needs to do a lot of looking
to find such a spot.
	Joe D.

------------------------------

