---------------------------------------------------------------------------- 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 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 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 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 Subject: Re: NLSP Configuration on a 3.xx network >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 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 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 ---------- 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 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 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 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 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.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 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 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 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" 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 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 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 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 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 To: "NetWare 4 list" 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 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 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. ------------------------------