---------------------------------------------------------------------- ROUTERS1.DOC -- 19970816 -- Email thread on Routers and NetWare routing ---------------------------------------------------------------------- Feel free to add or edit this document and then email it back to faq@jelyon.com Date: Thu, 23 Jun 1994 11:55:33 -0600 From: Joe Doupnik Subject: Re: Need info on SPX/IPX internals & details For IPX routing please get Postscript document file IPXRTR.ZIP in directory ODI\IPX_RTR on netlab2.usu.edu; see what really happens, in detail. Joe D. ------------------------------ Date: Thu, 16 Mar 1995 11:23:52 -0600 From: Joe Doupnik Subject: Re: 3.12 routing IP with a variable length subnet mask >>I don't think so "TIM" :) If you have a 2 bit mask, you can ONLY use >>"01" and "10" for subnets. "00" and/or "11" you can forget about. So, >>you're left with networks x.x.x.64 & x.x.x.128. > >I hope my router hadn't heared this, because I'm using the subnet where all >masked bits are 0. But I'm not using my Novell server as router, but PCROUTE. -------------- Time to remind people to once again acquire and read RFC1122.TXT wherein the issue of legal subnet masks etc are presented formally. In executive summary form the rules are that none of the three fields of an IP address: network, subnetwork, host, may have all zero bits nor all one bits. Full stop. If your local software breaks those rules then expect no interoperability with other equipment. Deduction: subnet fields must be at least two bits wide since one bit alone would violate the rules; RFC1122 says this too. Joe D. ------------------------------ Date: Thu, 16 Mar 1995 14:11:23 -0600 From: Joe Doupnik Subject: Re: Netmasks again >Joe D. writes: >>it. OSPF, coming on the Novell horizon, and RIP-II do carry subnet information >I haven't heard anything about this--where is OSPF on the Novell horizon? Any >idea if it will be an addon product, MPR-only, standard tcpip for 3.x, ... ------------ File sys:etc\tcpip.cfg for NW 4.10 on one of my machines. Read carefully for RIP(1/2) and OSPF selections. Joe D. AutonomousSystem 0 Protocol rip off { Interface { Address 129.123.1.46 Port BBONE_EII Status off Cost 1 Poison off OriginateDefault off Mode ripI Neighbor { } } } Protocol egp off { } Protocol ospf off { Interface { Address 129.123.1.46 Port BBONE_EII Status on Cost 1 AreaId 0.0.0.0 Priority 1 RetransmissionInterval 5 TransitDelay 1 HelloInterval 10 RouterDeadInterval 40 Nbma { PollInterval 120 Neighbor { } } } } Interface { Address 129.123.1.46 Port BBONE_EII Type lan RouterDiscovery no SolicitationAddress multicast } ------------------------------ The answers reside in the Novell Red Manual on TCP/IP for your NW file server; please read carefully. Also see standard easy to read reference "Introduction to TCP/IP", volume 1, by Douglas Comer, in decent bookshops world wide. Some hints as you go. NW severs Route IP and IPX, they do not bridge. Routers talk to separate "networks", each wire being a separate network. Thus one needs to create IP networks for each wire, and the usual method is to introduce subnet masks. A NW server uses only ONE subnet mask (unless you use Novell product MultiProtocol Router). This list is not the appropriate place to ask about all kinds of TCP/IP communications problems, so please use NEWS or your local organizations plus visit the booksellers plus talk to your Internet Service Provider (whom you are paying for assistance). Joe D. ------------------------------ Date: Thu, 17 Aug 1995 10:44:40 CETDST From: David Hanson Subject: Re: routing re(re)visited >>>What I currently have, is a system whereby all inet traffic is routed >>>to one of the workstation cards, which gives telnet, ftp, www etc to >>>all stations on that segment. I only have 32 IP numbers available to >>>me at the moment, and the first is lost as a gateway number. What I >>>really _want_ to do is to route ALL traffic from the internet card, >>>to BOTH of the workstation cards, even if this means losing another >>>number as a second gateway. >> >> You could set up an IP-only bridge between your workstation segments. From the holy DynaText: Bridge: A device that retransmits packets from one segment of the network to another segment. A router, on the other hand, is a device that receives instructions for forwarding packets between topologies and determines the most efficient path. OK., you have two NICs in the server, each feeding a network segment. You are running IPX on each segment and the server is acting as a router between those IPX segments. This is a common (cheap) strategy for reducing traffic on an individual segment, which I assume is the reason you are doing this. Fine. But for IP, you have a different priority. You want IP to see those two segments as one network. The reason is that you only have a given range of addresses, all of which are on the same subnet, and you don't wish to subnet further. So you install a bridge between the two segments that only passes IP, remove all references to TCP/IP from your NetWare server, and you connect the router that is providing you with Internet access to one of the two segments. +*-----------------+ | Novell 312 Server| | | +-*------------*---+ | | Segment A | | Segment B | +--------+ | *-*IP-Only *-* | | Bridge | | +---------+ | +--------+ | |Router to*---------* | | Internet| | | +---------+ (Workstations) (Workstations) Now IPX sees two networks, one on each segment, and IP sees both segments as the same network. Clear? David Hanson -------- From: Markus Muehlbauer >Referring to Hanson's above... > >Hmm.. Isn't an IP-only bridge by definition a router? A bridge >cares not for protocol. I'd think a fair amount of confusion would >result in the above solution as the ipx router in the server and the >bridge would see the same source addresses (at their respective hw/sw >levels) showing up on both ethernet segments. You are wrong! A bridge is passing ethernet packets only based on the hardware address of the network card. This means the bridge learns which host are on which side of the bridge and passes forwards only packets where destination and source are on different sides of the bridge (and if the destination is unknown). There are bridges out with more elaborate filter options, so one choose if the brigde should pass ipx, IP or waht ever. But the brigde never does any routing (in the sense of a router). This means one IP-subnet can spawn many network segments by use of bridges and you can change the media type with help of a brige (even from 10Base2 to TokenRing). If you activate the advanced filter options to restrict on IP bridging only, then the bridge isn't transparent at all for ipx - exact what Peter mentioned above. ------------------------------ From: Virendra Kumar Rode > Referencing all of the above... Routers, Brouters and Bridges explained Thats absolutely correct. Let me give you my version of explanation regarding bridges vs routers and how do they operate. ROUTERS: * Operate at the Network Layer of the OSI. -------- * Provides functionality of a bridge and repeater. * Transfers data across internetwork independent of media * Is protocol dependent. In WAN terminology this is reffered as a switch. Routers transfers data based on a address called software or network address. This address is present in network layer header and is represented as logical network and device address. Routers are protocol dependent which means routers needs to understand the network layer protocol of the network layer header. Software address are hierarchical as apposed to hardware address which are flat. Routers maintain the database what is called a route table. This router table tell the routers about the routes, on which internetwork they are and what there positions are. Maintaining and building of these routes are handled by upper-layer route management. This route management decide based on the routing protocols. Routers also provide two routing services: * Connection oriented services - eg: x.25 * Connectionless-Oriented services - virtual connection Routing Protocols Algorithms: Routing protocols are used to communicate between two routers over directly connected networks.They provide * Determine the routes * Determine whether the route information is current * Alert the other about failed and congested routes. * Advertise the best route for each route. Routers also rely based on one of these two routing algorithms: * Distance-vector routing - Calculates the routes based on second hand information - Recalculates the route table after forwarding the rote changes - Converges slowly after route changes - Uses cost metric to determine best route - Uses current information * Link-State protocol - Calculates the rotes based on first hand information - Recalculates the route table after forwarding the route changes. - Converges quickly after route changes - Uses cist metric to determine best route - Uses current information Brouter: Are intermediate devices which consist of transparent bridges and routers. Brouters are useful when a protocol can't be routed as they will drop it down to layer 2 and bridge it instead. Bridges: They operate at the data-link layer of the OSI model. Which means the raw bits are gathered into what is called mac layer address and put into a single connection. This single connection synchronizes the NIC, error-control and media access management. They act as transition interface between upper-layer and hardware address. Bridges find their destination based on the hardware address which does not provide the geographic information that routers do. Bridges are plug-n-pray (ooops well I mean PLAY), routers need some configuration. Bridges are cost effetive in terms of the filter and forwarding rate whereas routers sense every packet. Bridges are upper-layer protocol independent whereas as Routers are protocol dependent. Bridges work in a limited topology where they only know about the routes they are directly connected to and from where they receive frames whereas Routers have the knowledge about the geographic information. Bridged networks reconfigure much slower than routed networks so when a link is down the bridges will stop forwarding frames for a specified time set by the root bridge whereas routers will alert others about the failed and congested routes. Bridges must discard packets too large to forward accross the network, whereas Routers will fragment and reasemble the packets in order to route it across the network. Bridges connot notify other about the congested routes whereas routers will alert others about broken links. For example, IP routers use ICMP packets for this purpose. Bridges have no way to protect against broadcast storms whereas Routers were desgined to provide this protection. ----------------------------- Date: Fri, 13 Oct 1995 14:19:01 -0600 From: Joe Doupnik Subject: Re: Routing >Joe D. - stop reading now. Take a coffee break ;) Nah, this is too much fun to pass up. I'll be kind. >I'm still up the wall with my routing problem, and despite best efforts >I need to risk a severe flaming here again from Joe (2nd degree burns >last time ;) > >Scenario >-------- >I have a 3.11 server with three NE2000's in. One talks to the Internet, the >other two talk to my workstations (2 IPX segments). I have a range of 64 >consecutive IP numbers. > >Ideally, I'd like all 64 numbers to be seen by both segments but I understand >this isn't possible. So... how can I route either 32 each way, or 16 one >way, 48 the other. Let's make an inference in lieu of hard numbers. You have been given a piece of a Class B or C IP address. As given you have only the lower 6 bits for hosts. That means the Class B/C is already subnetted before it gets to you. Classes are identified by the leading few bits of the IP number and there is not a thing we can do about it. Class A starts at 1.0.0.0, Class B at 128.0.0.0, and Class C at 192.0.0.0, with the host fields being the last three, two and one octets, resp. The rules say (refresher, feel free to skip ahead) the "network" portion (the Class A/B/C part), and the subnet portion, and the host portion may not be all 1's nor all 0's individually. So, may we assume that the given subnetting obeys those rules down to your system? If so you steal host bits to create networks AND you can use Your Bits as all 0's and 1's because the other part of the subnet mask does not have all 0's or 1's. The next and last step is to realize subnetting is by bit, and hence divides regions by halves. It's not by value, but by binary bit. Ok, now let's look at a real example lifted from one of my servers. The site has a Class B address, 129.123.0.0. By the time I get a slice of it the given address is 129.123.30.0. That is still a Class B address; recall the top few bits determine Class. The given subnet uses up the third octet and, being value 30, it's neither all 0's nor all 1's. I use four boards in that server: one NE-2000 to the backbone and three NE-3200's to the lab. 129.123.30.0 is the lab side of things. ELfoobar are lab room numbers. file server name EDU-USU-ENGRLAB ipx internal net 817b0421 ... load ne3200 slot=1 frame=Ethernet_II name=EL105F load ne3200 slot=2 frame=Ethernet_II name=EL105B load ne3200 slot=6 frame=Ethernet_II name=EL103 load ipxstack load ipxrtr routing=nlsp mcast=yes bind ipx EL105F net=817b1e00 bind ipx EL105B net=817b1e40 bind ipx EL103 net=817b1e80 rem NE2000 to the world load ne2000 int=2 port=360 frame=Ethernet_II name=bbone bind ipx bbone net=817b0400 ... rem load TCP/IP routing material rem Backbone board BBONE is 129.123.4.33 rem Net 129.123.30.0 is sub-subnetted 2 bits to 255.255.255.192 rem Lab board EL105F is 129.123.30.62 and is the front half of the room rem Lab board EL105B is 129.123.30.126 and is the back half of the room rem Lab board EL103 is 129.123.30.190 and is the whole room rem EL105 front half uses 129.123.30.1-62, (gate=.62, sub-subnet bits 00) rem EL105 back half uses 129.123.30.65-126, (gate=.126, sub-subnet bits 01) rem EL103 whole room uses 129.123.30.129-190, (gate=.190, sub-subnet bits 10) load snmp ControlCommunity=password TrapCommunity=password load tcpip forward=yes rip=no bind ip BBONE ad=129.123.4.33 mask=255.255.255.192 ga=129.123.4.254 bind ip EL105F addr=129.123.30.62 bind ip EL105B addr=129.123.30.126 bind ip EL103 addr=129.123.30.190 My additional subnet bits are just two, taken from the fourth octet. They can be all 0's, and are in one case, without making the total subnet field being that way (the other part given in the third octet). I labeled my two as "sub-subnet" bits to fit the screen above. Host's can't be identified with all 0 nor all 1 bits. That means I lose two host addresses per sub-subnet. The all 0's case means "this network", and the all 1's case means to all machines on this network. If the need were present I could add another lab board on sub-subnet 11, address range 129.123.30.193-254 for hosts. As it is, I took the last octet and created currently three wires of 62 hosts each, with one more like that to spare inside the lab. Astute readers will note the IPX network addresses are exactly the same as the IP network (not host) addresses. The machine's internal IPX address is the same as the entire IP address of the board closest to the campus backbone, IP 129.123.4.33, IPX 817b0421. That's the Utah Standard (often cited doc UTAHSTD.TXT in directory misc on netlab2.usu.edu) Now that does deserve a coffee break. Thanks Roy for suggesting it. Say, I have a really good lecture prepared on RIP; just ask. Joe D. -------------- >Roy Coates --------- Date: Thu, 27 Mar 1997 17:38:54 -0600 From: Joe Doupnik Subject: Re: Another TCP/IP question; default ga = local subnet, right? >I'll try to make this quick. I was rummaging through routers.doc from >the FAQ and came across this, and I'm not sure what I'm missing. In the >"bind ip BBONE" line, BBONE's address and the gateway's address are >not in the same subnet. Doesn't the default router have to be on the same >subnet for BBONE to find it? > >(I cut a lot of information for the sake of brevity) >>file server name EDU-USU-ENGRLAB > >>load tcpip forward=yes rip=no >>bind ip BBONE ad=129.123.4.33 mask=255.255.255.192 ga=129.123.4.254 >>bind ip EL105F addr=129.123.30.62 >>bind ip EL105B addr=129.123.30.126 >>bind ip EL103 addr=129.123.30.190 > >Yeah, you guessed it - I'm new at TCP/IP. I don't mind flames; it's been >that kind of day. > >Paul Rhoads ----------- Give that man a cigar/banana/whatever. What sharp eyes you have Paul. Yes, the gateway must be on the same network because, by definition, it is the way off the local net. The case cited above is real. The version of TCP/IP material permitted different subnet masks on different wires, sort of and maybe. Above did work, but with a minor complaint about the not-on-this-network. Since then I placated the server by moving the server's IP address to be in the same apparent subnet as the gateway and leaving the mask as shown. The fine details quickly became hidden behind the morasse of sys:etc\initsys.ncf verbage. The 129.123.4.0 network wire actually uses a subnet mask of 255.255.255.0, so both 4.33 and 4.254 were on the same subnet (else traffic destined for the server would not arrive from afar). The interior wiring on net 129.123.30.0 is split by a different subnet mask, of 255.255.255.192 (for four networks). Thus while the server complained it did go ahead and communicate on the 129.123.4.0 network as desired. As a general rule, consider NW to be limited to one subnet mask for all ports, until we get reliable reports to the contrary. Is this a muddle? You bet it is. Can NW 4 support multiple subnet masks? Probably, but I have become gun-shy trying. Can NW 4 keep intact the IP default route? I am losing faith. Joe D. ------------------------------ From: "Daryl Banttari" Date: Tue, 24 Oct 1995 23:19:16 +0000 Subject: FYI: Most "router configuration" problems Most persistent "router configuration errors" that occur after changing a segment's IPX network number are generated by HP printers with JetDirect cards (in my experience.) The problem is, they sniff the IPX network number off the wire when they're fired up, and won't forget it until they are restarted. How do you know if it's an HP Jetdirect? Easy! Look at the MAC address of the offending station: "1.1.112 Router configuration error detected. Router at node 080007047092 claims network AAAAAAAA should be BBBBBBBB" It's a not-real-well-known fact the the first six digits of a MAC address is the vendor ID of the manufacturer of the Ethernet card! Almost without fail, the offending address starts with 080007..., which is HP's "domain" of Ethernet hardware addresses. How do you fix it? Easy! A quick power cycle does the trick. Not working? You haven't found the right printer yet. Check the company president's office (I once used a circuit breaker to restart an offending printer because it was behind a locked door, after hours, and the beeping was annoying me to death.) It IS possible to override a given network card's MAC address, but you typically only see that in large Token Ring environments with extremely zealous network administrators. Incidentally... the rest of them are usually the SNA Gateway, or the Network Connect server, or whatever, on the same segment; or perhaps your internetwork router (cisco or whatever) that hasn't been reconfigured to match the new server yet. I THINK Cisco starts with 000030... (someone check me on that, I dont have one handy.) Does anyone know where a table can be found of MAC address domains? 000030 Cisco..? 0000C0 SMC 080007 Hewlett-Packard ------------------------------ Date: Mon, 6 Nov 1995 10:34:52 GMT From: Wolfgang Roehl Subject: tcpip + bootp forward: Thanx + solution TCP/IP forwarding including Bootp: Now it works I lately ask for assistence with the problem of forwarding TCP/IP- packets and Bootp-requests from one cable segment to another on a 3.12 - server. Now it works! Thanks to all the help you gave me. As I had the impression that I am not the only one with this problem, here is the solution that works (at least within our network). Our net looks like this: 3.12 server Router ----134.100.136 --- card 1 (134.100.136.4) (134.100.136.254) card 2 (134.100.137.254)--134.100.137 --T 1. I now use the TCP/IP.NLM 2.75. It is availible at ftp://ftp.novell.com/pub/updates/unixconn/tcpip3x/tcp31a.exe and comes with a new module bootpfwd.nlm that forwards bootp-requests! 2. In the autoexec.ncf, I have the following lines: load tcpip forward=yes rip=no load 3C509 port=300 int=A frame=ETHERNET_II name=ipnetz1 load 3C509 port=350 int=C frame=ETHERNET_II name=ipnetz2 bind IP to ipnetz1 addr=134.100.136.4 mask=255.255.255.0 gate=134.100.136.254 bind IP to ipnetz2 addr=134.100.137.254 mask=255.255.255.0 load bootpfwd server=134.100.33.240 There is only one gateway information for the first network card. The gateway adress 134.100.136.254 is the address of the router. Bootpfwd is loaded with the address of the bootp-server. 3. The router has an additional routing information for subnet 134.100.137, routing packets for this subnet via 136.100.136.4 (i.e. the netware 3.12 server, first card). 4. The bootp-server gives back the information that the gateway for any 134.100.137-adress is 134.100.137.254 (i.e. the novell 3.12 server, second card). This adress has also to be given as gateway if telnet (or any other program) is configured manually. ------------------------------ Date: Wed, 6 Sep 1995 09:10:59 -0600 From: Joe Doupnik Subject: Re: IPX routing and NLSP >We have 100+ FileServers, each of which have IPX bound to 802.2 AND 802.3, >during the upgrade of 4500 clients to VLM and 802.2. > >IPXRTR ROUTING=NONE was loaded, to cut SAP and RIP traffic (worked). But >today a number of 3COM routers had IPX routing switched on. The only problem >has been some D-link printserver boxes in a department which, for various >reasons >is on 2 sub-networks. Well the D-link boxes on the 'other' sub-net from the >fileserver went away. > >What I wish to know is if I load IPXRTR ROUTING=NLSP on ALL my FileServers, >will they go back to routing 802.2->802.3 etc.? If so what is the best approach >to >solve my problem? ----------- The original issue of NLSP put the following blurb in autoexec.ncf: ; Uncomment the following line for ipxrtr to function on NetWare 3: ; load ipxstack ; ipxrtr may be loaded in any of the following three ways: ; (1) Uncomment the following line for NLSP with RIP/SAP compatibility: ; load ipxrtr routing=nlsp ; (2) Uncomment the following line for RIP/SAP routing: ; load ipxrtr routing=ripsap ; (3) Uncomment the following line to disable routing: ; load ipxrtr routing=none ; Uncomment the following line activate the IPX SNMP instrumentation: ; load ipxrtrnm The docs went on to say that if routing=none is employed then IPX routing will not occur, and there were diagrams to amplify the notion. If you use routing=nlsp then servers preferentially exchange IPX routing information via NLSP packets rather than RIP/SAP. However, they will listen to RIP/SAP and if discovered they will emit SAPs for their own services. Your server regards IPX on different frames as being on different IPX networks. Thus to cross over from one kind to another routing is involved, and the paragraph above applies. The selection of choice this year is routing=nlsp, which does cut RIP/SAP traffic from server to server and yet retains communications with our tiny-boxes. The next step up is to introduce NLSP on your mainline routers (cisco etc). After that we are expected to make noises to Novell asking for NLSP level 2 so that routes can be aggregrated: fancy-speak for network clouds with designated points joining cloud to cloud. The delivery date for level 2 seems to be "a year or so from now" whenever the subject comes up. The SAP problem continues to be more difficult as Ethernet hubs come on line with management properties. Some insist upon telling everyone of their presence every minute, and the darned things can gang up on us to yell in unison (a huge wave of back to back packets, every minute). Filtering in real routers seems to be the cure for now. Basically, periodic spontaneous advertizing schemes don't scale well, but alternatives aren't so convenient. As a side note, you might be interested in reading a tiny piece of the excellent FAQ which discusses how my site (20K students, plus staff) went about changing NetWare items in a massive and very rapid fashion (three times as it turned out). Joe D. ------------------------------ Date: Thu, 16 Nov 1995 14:06:26 -0600 From: Joe Doupnik Subject: Re: RIP=NO ? >I was reading through the FAQ and not for the first time found myself >puzzling about why the FAQ recommends > > LOAD TCPIP RIP=NO FORWARD=_WHATEVER_IS_REQUIRED_ > >Am I correct in thinking that if IP is bound with a gateway that >RIP=YES is unnecessary? > >Our current TCPIP setup is: > > LOAD TCPIP RIP=YES FORWARD=YES > BIND IP TO IP_BACKBONE AD=156.62.8.4 ma=ff.ff.ff.0 ga=156.62.8.9 > BIND IP TO IP_STAFF AD=156.62.240.1 ma=ff.ff.ff.0 > >Hence, does this mean that I can use: > > LOAD TCPIP RIP=NO FORWARD=YES > BIND IP TO IP_BACKBONE AD=156.62.8.4 ma=ff.ff.ff.0 ga=156.62.8.9 > BIND IP TO IP_STAFF AD=156.62.240.1 ma=ff.ff.ff.0 ga=156.62.8.4 > >and use GA=156.62.8.4 for each successive IP subnet on this server? >The intent being to allow all subnets the ability to access Unix >hosts etc on backbone segments. >All the backbone segments we have are connected to an SMC ES1 >EtherSwitch. How will RIP=NO affect routing? - the switch allows RIP >to be disabled on it. > >Thanks in advance for clarifying my understanding. ---------- RIP is evil small-talk: RIP is a distance vector information conveying protocol of the simplest sort. The definition is RFC1058.TXT, an interesting document, a tiny piece of which is below: ------- RFC 1058 Routing Information Protocol June 1988 The packet format is shown in Figure 1. Format of datagrams containing network information. Field sizes are given in octets. Unless otherwise specified, fields contain binary integers, in normal Internet order with the most-significant octet first. Each tick mark represents one bit. 0 1 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | command (1) | version (1) | must be zero (2) | +---------------+---------------+-------------------------------+ | address family identifier (2) | must be zero (2) | +-------------------------------+-------------------------------+ | IP address (4) | +---------------------------------------------------------------+ | must be zero (4) | +---------------------------------------------------------------+ | must be zero (4) | +---------------------------------------------------------------+ | metric (4) | +---------------------------------------------------------------+ The portion of the datagram from address family identifier through metric may appear up to 25 times. IP address is the usual 4-octet Internet address, in network order. Figure 1. Packet format ------- We see something here, or the lack of something if you have sharp eyes. There are IP addresses and distance vectors (hop count is such a vector). What's missing are subnets so that receivers can distinguish network and host fields of an IP address, as well as know the range of IP numbers represented by one IP entry above. This is not a problem if every machine uses an identical subnet mask everywhere. We notice something else. Any machine can create 30 sec RIP broadcasts, and they don't have to tell the truth. Mistakes lead to big outages, as happens all too often. Novell IP routing software uses only ONE gateway. The GATEWAY= phrase is a "default route" to the world, and it's a static route. Default means if the router does not know a path to the destination then send the packet to the default router for handling. Use the phrase once-only per server, and say RIP=NO too. This works well and is robust. Carrying the concept forward one more step with your real router box we can create multiple IP networks on the same wire, at the cost of some packets traveling the wire twice (to the router, back out again to the station on the same wire). We do such political multiplexing a lot here while waiting for money to put each IP net on its own wiring. If your router believes RIP then it is at the mercy of the other machines on the net, as well as probably being confused by mixed subnet masks here and there. Etherswitches are bridges, multiport bridges, and not routers. They understand only MAC layer destination and source hardware addresses and know nothing of protocols. Joe D. ------------------------------ Date: Sun, 19 Nov 1995 10:06:00 -0500 From: Ivo Spigel Subject: Re: Dial up router on Novell? >>I am looking for a dial up router that will connect my 4.1 network >>to my ISP to allow multiple users to have access to the internet. >For a cost effective but flexible solution you may look at Cisco >Systems's 1000 or 2500 series routers with ISDN interface. Contact >your local shop or www.Cisco.COM. You might want to take a look at an interesting solution from Internet technologies. It is a software TCP/IP router that installs on a PC called the Mach2 TCP/IP router. Costs $599! There is also an optional DNS module. Look it up at http://www.ihub.com Ivo Spigel ispigel@open.hr ------------------------------ Date: Sun, 19 Nov 1995 18:51:40 -0600 From: Joe Doupnik Subject: TCP31A.EXE archive file Today Daniel Tran asked me what's the word on archive file tcp31a.exe, found in updates\nwos\several. It looked to me as if it were a fix for Multi Protocol Router (MPR) rather than straight NetWare servers. The interior says -------- NOVELL TECHNICAL INFORMATION DOCUMENT TITLE: TCP31A: TCPIP 2.75 suite update README FOR: TCP31A.EXE NOVELL PRODUCTS and VERSIONS: NetWare MultiProtocol Router 2.11 NetWare MultiProtocol Router 2.0 TCP/IP 2.x NetWare MultiProtocol Router 2.1 ABSTRACT: This release contains several updates to numerous NLM files in the TCP/IP and SNMP suite. It includes TCPIP.NLM version 2.75 and SNMP.NLM version 3.02a. Supports both NetWare 3.12 and MPR 2.x on NetWare 3.12. --------- I installed it on a NW 3.12 file server (no MPR on it) and it works, mostly. The TCPIP.NLM is twice as large as previously (2.02m) and has a lot of support for new routing material: OSPF, serial links, RIP II, etc. However, Load TCPCFG.NLM fails with "can't find Mprblahblah" symbols. Also, Load TCPCON does its usual pig act of grabbing cache buffers and slapping them into the alloc memory pool (out of reach for cache buffering); that happens probably while reading \etc\hosts when the NLM starts up. Hint to users: never load tcpcon; to Novell: please don't do that, thanks. Statistics are laid out nicer. TCPIP.NLM still works. There is a new BOOTPFWD.NLM too. Here is the another problem (from conlog): can't write properly - Loading module SNMP.NLM SNMP Agent Version 3.02a September 14, 1995 Copyright 1992-1994 Novell, Inc. All rights reserved. Loading module TCPIP.NLM Novell TCP/IP Module Version 2.75 September 13, 1995 Copyright (C) 1991-1994 Novell, Inc. All Rights Reserved TCPIP-2.75-42: Will NOT act as a router. TCPIP-2.75-27: RIP is disabled. TCPIP-2.7 5-66: Will use 129.123.1.254 as a default gateway. TCPIP-2.75-112: Bound to board 1 with IP address 129.123.1.44 and mask FF.FF.FF.0. IP LAN protocol bound to No vell NE3200 Since tcp31a.exe has not appeared in the netwire heirarchy I wonder if this is still pre-release in some way and not ready for prime time. The above problems suggest it's not ready. Joe D. ------------------------------ Date: Mon, 20 Nov 1995 19:15:33 GMT From: Daniel Tran Subject: Re: TCP31A.EXE archive file - follow up In article <01HXU5M71M3Q9ANIQE@cc.usu.edu> Joe Doupnik writes: > Today Daniel Tran asked me what's the word on archive file tcp31a.exe, >found in updates\nwos\several. It looked to me as if it were a fix for Multi >Protocol Router (MPR) rather than straight NetWare servers. The interior says >-------- >NOVELL TECHNICAL INFORMATION DOCUMENT >TITLE: TCP31A: TCPIP 2.75 suite update >README FOR: TCP31A.EXE >NOVELL PRODUCTS and VERSIONS: >NetWare MultiProtocol Router 2.11 >NetWare MultiProtocol Router 2.0 >TCP/IP 2.x >NetWare MultiProtocol Router 2.1 >ABSTRACT: >This release contains several updates to numerous NLM files in >the TCP/IP and SNMP suite. It includes TCPIP.NLM version 2.75 >and SNMP.NLM version 3.02a. Supports both NetWare 3.12 and MPR >2.x on NetWare 3.12. >--------- > I installed it on a NW 3.12 file server (no MPR on it) and it >works, mostly. The TCPIP.NLM is twice as large as previously (2.02m) >and has a lot of support for new routing material: OSPF, serial links, >RIP II, etc. > However, Load TCPCFG.NLM fails with "can't find Mprblahblah" >symbols. Also, Load TCPCON does its usual pig act of grabbing cache >buffers and slapping them into the alloc memory pool (out of reach for >cache buffering); that happens probably while reading \etc\hosts when >the NLM starts up. Hint to users: never load tcpcon; to Novell: please >don't do that, thanks. > Statistics are laid out nicer. TCPIP.NLM still works. There is >a new BOOTPFWD.NLM too. > Here is the another problem (from conlog): can't write properly - >Loading module SNMP.NLM > SNMP Agent > Version 3.02a September 14, 1995 > Copyright 1992-1994 Novell, Inc. All rights reserved. >Loading module TCPIP.NLM > Novell TCP/IP Module > Version 2.75 September 13, 1995 > Copyright (C) 1991-1994 Novell, Inc. All Rights Reserved >TCPIP-2.75-42: Will NOT act as a router. > TCPIP-2.75-27: RIP is disabled. >TCPIP-2.7 >5-66: Will use 129.123.1.254 as a default gateway. > TCPIP-2.75-112: Bound to >board > 1 with IP address 129.123.1.44 and mask > FF.FF.FF.0. > IP LAN protocol bound to >No >vell NE3200 > Since tcp31a.exe has not appeared in the netwire heirarchy I wonder >if this is still pre-release in some way and not ready for prime time. >The above problems suggest it's not ready. > Joe D. Here are what I found: - load TCPCFG.NLM fails as describe by Joe D. I guess it's looking for some of the MPR components. - load TCPCON.NLM does steal cache buffers and slab them into the alloc memory pool as Joe D. described. TCPCON reveals nice statistics. - I did not encounter the problem with CONLOG.NLM cannot write properly. Here's part of my /etc/console.log Loading module TCPIP.NLM Novell TCP/IP Module Version 2.75 September 13, 1995 Copyright (C) 1991-1994 Novell, Inc. All Rights Reserved TCPIP-2.75-26: Will act as a router. TCPIP-2.75-27: RIP is disabled. TCPIP-2.75-66: Will use 128.97.175.1 as a default gateway. TCPIP-2.75-112: Bound to board 1 with IP address 128.97.175.2 and mask FF.FF.FF.0. IP LAN protocol bound to Digital DC21040 Ethernet EISA/PCI driver v1.00 (940926) TCPIP-2.75-112: Bound to board 3 with IP address 128.97.151.1 and mask FF.FF.FF.0. IP LAN protocol bound to Digital DC21040 Ethernet EISA/PCI driver v1.00 (940926) Loading module IPCONFIG.NLM IP Static Route Configuration Utility Version 3.00b September 13, 1995 Copyright (C) 1991-1994 Novell, Inc. All Rights Reserved While Joe D. loaded TCP31A.EXE package on his Netware 3.12 server, I installed it on my NW 3.11 server since the TCP31A.TXT mentions it's an update to TCP/IP 2.x (I was using version 2.02m). So far it's still runing on my server. So there you have it, running on both 3.12 and 3.11. I don't know if this package is appropriate for everyone running 3.12 or 3.11. I want to thank Joe for taking his time looking into this package. ------------------------------ 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: Mon, 27 Nov 1995 04:26:02 GMT From: "Stephen M. Dunn" Subject: Re: RIP=NO ? $I was reading through the FAQ and not for the first time found myself $puzzling about why the FAQ recommends $ $ LOAD TCPIP RIP=NO FORWARD=_WHATEVER_IS_REQUIRED_ RIP is not terribly well designed. Its biggest problem in this age of subnetted networks is that it has no facility to handle subnet information. The usual workaround is to have a machine running RIP assume that all subnets of what would, without the subnet mask, be the same network use the same subnet mask. This is not necessarily true. RIP II cures this, as does OSPF. NetWare 4.1 supports both in addition to RIP; earlier NetWare versions support only RIP. $Am I correct in thinking that if IP is bound with a gateway that $RIP=YES is unnecessary? If your routing requirements can be satisfied by the server knowing only about the networks to which it directly connects, plus one default route used to reach all other networks, then you need neither RIP nor explicit static routes; use GATEWAY= to set your default gateway and you're up and running. If your routing requirements can be satisfied by the above, plus one or more static routes, then you can use RIP=NO and some static routes and again you'll be fine. ------------------------------ Date: Mon, 4 Dec 1995 10:56:27 -0600 From: Joe Doupnik Subject: Re: disabling IPX routing >In 3.1x and 4.x, I need to turn off IPX routing (obviously using multiple >LAN cards) for a test. I know there's an NLM for 3.x and there's a >parameter in 4.x that let's me do it. Does anyone have specifics on >where that NLM for 3.x is, and the appropriate 4.x syntax? --- To turn off IPX routing either don't bind IPX to multiple boards or install Novell's NLSP material (it's free, see netwire\novlib\01\ipxrt3.exe on ftp.novell.com and mirrors). Joe D. --------- Subject: FAQ suggestion Date: Mon Dec 4 22:23:15 1995 Sender: "Stephen M. Dunn" >$Can anyone tell me if there is a way to prevent a NetWare 3.x or 4.x file >$server with two (or more) NICs connected to different LANs (with different >$IPX network numbers) from acting as a router between these two LANs? >$ >$Can the same be done for a NetWare IPX server? Either for normal RIP or >$with IPXRTR for NLSP? IPXRTR provides this ability. ------------------------------ Date: Fri, 8 Dec 1995 09:03:33 +0100 From: Henno Keers Subject: Re: Bridging with NetWare 4.1 >Yeah, after I thought about it I realized that it isn't a bridge since the >cards end up on the same physical segment and therefore in the same >collision domain. What is the solution for segmenting traffic but keeping >the workstations on the same logical network... or is there no benefit >with ipx in bridging (instead of routing) since you don't need to assign >an address to each node as you do with ip. Some switch vendors use so called Virtul Lan's, which are grouped bridges with associated MAC addresses, but these are (still) propriatry solutions. >Do most people just choose to route instead of bridge? Also, what benefit >is there to load balancing between the cards... can you really move more >data in or out of the server on an ethernet network (which can't broadcast >at the same time anyway). No. Switching/Bridging should be used for a fast channel between servers and clients. Routing should be used to connect networks (LANS and WAN's) and to provide filtering for keeping traffic low and security high. Both strategies have their unique Pro's and Con's and merits. It is matter of choosing the right one at the right place. The need for balancing comes up when the servers bus and CPU is relatively lightly used and you have a couple of switches (fast bridges) with high speed interfaces that need to be fed with a large bandwith on the same network. >Is it just a matter of allowing the server to >"work" on more data from the network at once? Indeed. ------------------------------ Date: Fri, 5 Jan 1996 02:22:07 GMT From: Buddy Shipley Subject: Re: Switching HUB >Has anybody experience with switching HUBs and Shared HUBs? What do you >think of 3COM products? What will be the best upgrade path to NW 3.11, >486-dx/33,with 3 segments, 45 users? We want faster transfer...at the >moment it's about 0.5MB/sec From the terms you used I presume you are referring to Ethernet. Shared hubs are merely multiport repeaters. Switched hubs are usually multiport bridges. Switches can be an excellent investment if implemented correctly. 3Com is an excellent company with an excellent track record. Novell can be an excellent company again if.... Most switches employ full the IEEE 802.1D MAC Bridge standard. This is also referred to as Store & Forward. Each frame is stored, CRC is validated, then the frame may be forwarded. Some use cut-though or fast forward where the frame is forwarded as soon as the destination address is read & compared to the forwarding table. Pro: somewhat lower latency, Con: potential error forwarding. Some use cut-though with fragment free which buffers the first 64 bytes of each frame to ensure that the frame is intact -- but it still does not perform the 802.1D standard CRC. Some switches also support multiporotocol routing -- at least one or two protocols, maybe three will be supported. While these devices are fine & fast, they may not be as powerful, flexible, and robust as a router that is purpose-built for the task. ------------------------------ Date: Thu, 7 Mar 1996 10:04:43 -0600 From: Joe Doupnik Subject: Re: Request for input for campus-wide IPX routing plan >We have a client with the following network: >- Star configuration Campus fiber backbone >- Cisco AGS+ and IGS routers, to be replaced with 7000 and 4500 > boxes. >- 8 NetWare 4.1 servers, 2 NetWare 3.12 servers, with about 750 > users. >- IP connecivity in place, B class IP address to the Internet > >Currently they are _bridging_ IPX and routing IP. That's correct. >I made a proposal to route IPX instead of bridging it, the following >other options where returned; >- Don't route IPX but only IP and run IP on everything >- Tunnel IPX in IP I would disagree with both suggestions. There are only 10 NW servers on the wires, and by my standards that's tiny. They generate little traffic on their own. Bridging (MAC, physical level) works just fine keeping local traffic local. Recall that 99+% of the packets are neither physical broadcast nor physical multicast, the kinds which go right through MAC bridges. Each bridge, though, adds one packet delay and that will be noticable. Admin cost is precisely zero. Routing creates admin problems up the wazoo, and in this case for essentially no gain. Routing is able to look at packet interiors and make decisions based on what a particular protocol is saying. At best we can filter printer boxes to be invisible across a router, and things of that nature. Routers can aggregrate RIP/SAP information to behave as one server rather than a bunch of individual servers, but with only 10 servers in toto aggregation is plainly not worth the effort and cost. Just use NLSP. Each router adds one packet delay too. The cost of routers is high, the admin cost is high. My domain has a total collection of around 1K NW servers, that's across the state IPX network. We use Cisco routers to isolate each site down to the list of approved externally-visible objects. Within each site we bridge IPX traffic, even though we may have a bunch of Ciscos. My campus has about 80 odd NW servers, all IPX bridged, most using NLSP. Ciscos on campus aggregate RIP/SAP traffic, but they bridge not route IPX. Tunneling IPX is the very last choice of moving material. It is next to impossible to diagnose packets, there is extra considerable overhead at both ends, there is no benefit that I can see in your case. NW/IP is, frankly, a pain in the butt. It is most often not needed at all. Religious persons may feel otherwise, but then we had better not meet in a dark alley some rainy night. There is absolutely nothing wrong running IPX and IP together across organization networks, and there is a lot of benefit doing just that. So far there is no problem at all adding a few bridges here and there, the fewer the better and placed strategically to solve particular traffic isolation problems. I see no technical benefit to routing IPX, and none to tunneling. I see very little to no technical discussion of "what is the problem, anyway", but I do sense the usual customer FUD. Joe D. >I would like to have some independent input to convince my client on >routing IPX, and give some opinion's of others on the subject. I kept >some messages from an earlier discussion, so I have a start, I like to >know: > >- Give me some technical/administrative pro's on routing IPX versus > the all IP and tunneling scenario's. >- Could all users of cisco routers that route IPX and IP on a large > WAN/LAN give me a copy of their configuration, so that I can > show them that it ain't that difficult. > >Henno Keers ------------------------------ Date: Wed, 27 Mar 1996 09:54:17 -0800 From: Randy Grein To: "NetWare 4 list" Subject: Re: External Router >In the NetWare 3.12 Menual "Concept", it says there are internal >routers, and external routers. An internal router is a router running >on a server, while an external router is a router running on a >workstation. External routers can be further categorized into >dedicated and non-dedicated external routers. > >It mentions ROUTE.NLM for internal, and ROUTER.EXE for external. But I >can find nowhere to see anything called ROUTER.EXE, not ever since. >Not in any 3.12 documentation, nor in any 4.10 documentation. OK, guys, a little history: Novell used to call IPX routers bridges; this is a misnomer and was finally corrected. They were always routers (ie, worked at the network layer, were protocol dependent, etc.), just misnamed. Novell also used to provide an external router that was linked much like the 2.x servers; they dropped the product because it was slow, didn't use ODI and had limited protocol support. A couple of years ago they started putting it up on Compuserve and the ftp sites because of continuing user requests; seems a few people still want to use it. Now just like the 2.x servers this product could be configured in a dedicated or nondedicated mode; in nondedicated mode it's pretty useless by todays standards. You can't use it with Windows, for example, and even loading it above 1 meg the base RAM requirements are excessive. Novell's current product to provide this functionality and much more is the Multi Protocol Router; it can be used on a licensed server or runtime if you don't need to provide login/file/print services; although if you're just doing basic routing all you need is the standard server. The router.nlm you are seeing is to provide token ring source routing. ALL novell servers provide routing, but someone else made a comment regarding routing: >Furthermore, you dont need to worry about routing IPX per say, rather >think of it as routing 802.3 (or 802.2 or whatever) packets. This is NOT correct at all. Routing is handled at a protocol level rather than a frame level; many protocols can be bound to different frame types, but unless your router understands them they will NOT be forwarded. This is the big problem with Netbios - it's not routable, although many routers can detect and forward netbios packets if necessary, giving your router bridging capabilities (a brouter). ------------------------------ Date: Fri, 24 May 1996 09:41:47 +1200 From: "Baird, John" Subject: Re: Reply to Get Nearest Server Problem >>I have noticed this "feature" (bug) of netware 4.1. Someone told me >>that it appears to depend on the order the servers attach to the >>network, but I have not tested this theory. I also have found three > >I don't see how this would be true. No IPX router or NW server is >keeping track of *when* servers come on line. A router could be doing this unintentionally if the entries in the routing tables were not sorted and simply appeared in the order in which SAPs for the various servers were received. I don't think [the IPX routing spec] defines how a router should respond when it knows of more than one server which are equidistant and closest. Our 3com routers will respond to a "Get Nearest Server" (GNS) request with the name of the server which appears first when the closest servers are sorted alphabetically, but other routers could return the closest server which appears first in the routing table. BTW, the routing spec does state that a router should not respond to a GNS request when it knows that there are servers on the network from which the GNS request was sent. This has got us into trouble serveral times when a test server has been fired up on a network segment without other servers and replying to GNS has been turned off on the test server to prevent users attaching to it. The result is that on that segment nothing responds to GNS. ------------------------------ Date: Tue, 4 Jun 1996 10:55:22 -0600 From: Joe Doupnik Subject: Re: a DNS/UDP problem? TCP/IP forwarding looks ok >But of course, his Netscape won't work. His FTP/Telnet *do* work. Now >IIRC, they're TCP-based; Netscape requires DNS also (UDP-based, right?). >Obviously the NW servers stand in the path; I've tried the simple RESOLV >from Hellsoft and pointed it at the same DNS we've used for Netscape and >Winsock apps (192.33.4.10). No joy. > >From TCPCON it appears UDP is being passed (only basing this on >transmit/receive counters going ever up). >larry ---------- Cutting through all the details, the fundamental problem seems to be bootp. That is a very well known problem: how does a bootp response get to the requesting client (which at that point lacks an IP address). The last router in the chain must have a bootp helper to recognize the situation and send the response to the particular client. Novell has two of them: bootpfd and bootpfwd (I believe the latter is the later). The answer to the problem, if you are interested, is either broadcast the reply (nasty) or pick out the client MAC address from the response (nice) and send it directly. The trick is recognizing this router is the last one in the chain, and that is a very simple thing to do. Yes, bootp uses UDP/IP packets. See the Novell archive and if necessary see directory misc and drivers on netlab2.usu.edu. Joe D. ------------------------------ Date: Sat, 22 Jun 1996 12:08:14 -0400 From: "J. Darren Lofthouse" Subject: Re: Connecting 2 hubs together >I just installed a 3com linkswith 1000 hub running just IPX. I did not >have to do any special to configure the hub. The problem that I had was >that I was connect to 5 3com LinkBuilder FMS II Hubs. No were in the >manual did it tell you what to do. Any way, to get them to work I had >to plug the patch cable from the linkswitch to the last port on the >HUB. Also their is a switch on the front of the hub that says MDI or >MDIX. It has to be correct. I can not recall not which postion it has >to be in, but I think it is MDI. If you do not this the switch will not >work. >I was very unhappy with the customer service 3com provides. No where in >the manual did it tell you that you had to set up the hubs that way. I >called 3com and they would not help, with out paying. I had just bought >thousands of dollars of brand new equipment that did not work and they >were not going to help me. It would have been one thing if the manuals >were good, and I just did not read them, or this was old equipment. >3com make a great produect, but they must improve customer services. This is pretty standard when connecting 2 hubs together. Any time you have one hub connected to another you need to switch Tx and Rx either with the cable or at the hub. Thats what the MDI/MDIx switch does. All of the ports are crossed (x) automatically (or uncrossed, can't remember which) except the first port which has a switch to allow you to cross or uncross. Hope this helps your understanding of what was going on between the switch and hub. ------------------------------ Date: Mon, 28 Oct 1996 15:34:32 -0600 From: Joe Doupnik Subject: Re: Turning of IPX Routing >We are preparing to move to an ATM based backbone, with >switched V-Lan segments. My final bone is: > >I would still like to have a dedicated servers only segment for >server to server traffic. > >I would like to accomplish this with multiple cards in servers. >No problem, except, how can I turn OFF IPX routing? Or are the >servers smart enough to realize duplicate paths (i.e. Spanning Tree...). > >I know how to turn off IP routing, just forward=no on the load line. --------- Quick answers. Spanning tree is not a good analogy. It concerns how packets flow or route, not about what's advertized on the wires (spanning tree pkts get on all the wires, surprize, just like IPX RIP/SAP). To "learn more about it" may I suggest the excellent book "Interconnections, Bridges and Routes" by Radia Perlman, Addison-Wesley publishers. This is also a good intro to link state protocols. It's fun to read (if you are a protocol guru). Radia also works for Novell these days (NLSP behind the scenery person). General solution: MultiProtocol Router product from Novell, including the subset shipped with NW 4.11. It allows one to turn off generation of IPX RIP/SAP packets from the server on a per logical interface basis. I use the NW 4.11 flavor to quiet the server on local wires holding NW clients alone (no printer boxes, no subsequent routing deeper down, etc). Not-so-good-solution: NLSP, turn off RIP/SAP per board. This is not in the same league as MPR. NLSP is something which I have commented upon several times as being a non-solution to routing traffic on most networks. NW servers already compute shortest paths for routing, using the classical Bellman-Ford distance vector method. It works, period, even though the convergence time after changes is longer than with say link state methods. Thus NW servers work fine in the presence of multiple paths to the same points. To "read more about it" (it being classical IPX routing) please snag binary file odi\ipx_rtr\ipxrtr.exe from netlab2.usu.edu; it's a Postscript doc with pictures and all. [So how many routing changes per minute/hour do we have on most nets? Very few. End of worrying about convergence times.] Joe D. ------------------------------ Date: Tue, 12 Nov 1996 09:20:39 +1000 From: Mark Cramer Subject: Re: How to kill a phantom(sic) server? >>>I started a 4.1 server without the startup.ncf, because I did not >>>feel like waiting for sys to mount, since I wanted to run vrepair on >>>it. When prompted for the server name, I foolishly typed BOB. Bob >>>is still there when I do "nlist servers /b". No other server sees >>>bob. Is there a way to get rid of bob, short of an exercist? >> >>I had just exactly the same phenomenon and it went away after two >>subsequent reboots of the server. Now I'm looking up internal ip >>EACH time before I attempt such a thing :-) > >Would > reset router >help? I think it's more likely that reseting your routers might help, as in the real kind (cisco's etc) Do you have a wan link with rip/sap filtering in place and a router that will cache, filter and forward saps ? Your real router may be holding on to details of your NW boxes long after they've gone away ------------------------------ Date: Tue, 3 Dec 1996 01:18:51 +0100 From: "Arthur B." Subject: Tip: Cisco routers and ISDN backup lines and dynamic RIP Following is not a problem. Just some info in case you may have need for it someday. Doesn't seem to be in the books. Situation: Cisco routernetwork build up on 64Kb lines. IOS 11.1. Each 64Kb line has an ISDN backup line in case the 64Kb fails WAN is PPP. Encapsulation ARPA. Networks are IPX. WAN applications are configured for SPX connections. Problem: All networks must receive partial dynamic RIP, SAP and broadcasts from the 'master' network 24 hours a day. However. Standard ISDN configuration will not provide this. Thus clients loose connection and can't reconnect when ISDN goes active. Because they don't receive the dynamic socket numbers contained in the RIP packets. And 'connection tables' fill up because ISDN routes spoof SPX so connection isn't lost in the eyes of the offending NLM. Solution: Create static ip and floating static ipx routes for the main routes only pointing to the ip address of the receiving BRI interface on every router. Each 'dialer map' in the BRI sections must have a 'broadcast' parameter. Permit full ip and ipx over the ISDN lines. Make use of CHAP. The sending BRI must be made a 'dedicated backup interface'. The 'dialer map' of the receiving BRI normally contains a phone number at the end of it. Backspace that. Result Happy customer for one. When a 64Kb line fails (or several) the ISDN backup line usually establishes a new route within a few seconds. Complete with everything that normally travels over the 64Kb lines (RIP, SAP, broadcasts). When all 64Kb are up the BRI's don't try to dial out every time a broadcast comes along which fails because the receiving side is in standby mode. Future Make WAN applications aware of TCP/IP only. LAN applications may ride on IPX if need be. Or will be replaced. Maybe trade RIP in for OSPF. ------------------------------ Date: Tue, 3 Dec 1996 10:55:48 -0600 From: Joe Doupnik Subject: Re: Pburst at 64kbps >I have been testing a 64kbps WAN link by copying several files from a >workstation on one end of the link to a server on the other end. > >I noticed that pburst did not fare well in this situation (many >missing pieces that had to be resent). In fact, at one point, it got >into a loop where one missing piece was being continually re-requested >and dropped, hanging the copy operation. > >When I disable pburst, the files appear to copy fine, albiet slowly. > >Why does pburst do so poorly over this link while a non-burst copy >(apparently) does fine? ----------- I should bring this one to class. It is a classical situation of inadequate end to end flow control, with a limited WAN link in the middle, and the inherent difficulty of end nodes negotiating a suitably small burst length because they have no direct knowlege of the weak link in the middle. If your WAN link is a couple of comms black boxes plus Telco wire then look at the manuals on those boxes and find their buffer capacity. Set Pburst to stay within that buffer capacity (after allowance for competing traffic). The controls are lines Pburst read window= and Pburst write window= in net.cfg. The number is garbled in Novell docs and I interpret it to be the number of full length frames (576 bytes each when crossing an IPX router), though it can also be interpreted as the number of kilobytes in a burst. There is a third parameter in net.cfg, lip start size= which tells Pburst the longest frame length to try across the link; units is bytes. I might add that TCP does handle this situation by design. It's called congestion control and avoidance, and congestion here is too many packets queued for transmission across the slow link. It observes the link by testing it and then adapting to the link capacity dynamically as traffic load changes; there is no negotiation between clueless end nodes. Were I designing the comms black boxes I'd provide "back pressure" on local senders when the transmission buffer fills, by causing a fake collision or a full duplex Ethernet busy signal (preamble bits going on and on as per Richard Steven's suggestion). Etherswitches have exactly the same problem, but at higher speeds, when many inputs compete for time on the same output port. All in all, some very basic networking concepts are involved here. We will see them again on the final, so now is a good time to ask questions... Joe D. ------------------------------ Date: Wed, 4 Dec 1996 16:11:43 -0600 From: Joe Doupnik Subject: Re: IP Subnet Error >>SubNet 1: 206.96.111.33 to 206.96.111.63 >>SubNet 2: 206.96.111.65 to 206.96.111.95 >>SubNet 3: 206.96.111.97 to 206.96.111.127 >>SubNet 4: 206.96.111.129 to 206.96.111.159 > >please expand on this, what addresses get assigned to router ports? (NICs) > >do you use 32, 64, 96 and 128? > >and what is the gateway? 206.96.111.1? > >bind ip to nic1 addr=206.96.111.32 subnet=255.255.255.224 ga=??? >bind ip to nic2 addr=206.96.111.64 subnet=255.255.255.224 ga=??? >etc... The list's fine FAQ has many discussions of subnetting and related material. May I suggest reviewing that resource plus reading up on the basics, if needs be, and then bring up the subject again if troubles persist? Something not in the Red Books is how Novell's TCP stack regards multiple subnet masks (so-called variable subnet masks) and multiple GATE= parameters. We see that routing can be more complicated than can be expressed on a single command line, hence inetcfg and sundry files. The quick answers, by the way, are generally one subnet mask applies to all NW server ports, and GATEWAY= is the single static default route (meaning the known place to send packets when you don't know where else to send them). But "it all depends" applies here too, should be called Ray Noorda's Law, and later issue TCP stacks + MultiProtocol Router try to deal with variable subnet masking, proxy arp, and so on. INW/NW 4.11 has a cut down version of MPR to help. Joe D. ------------------------------ Date: Wed, 11 Dec 1996 10:35:20 -0600 From: Joe Doupnik Subject: Re: Hub cascading >Joe D's message from earlier about the # of repeaters rule made me think >about a project I'm working on. We are gradually installing building-wide >networks in all of our schools and consequently are dealing with some older >devices. I know the rule about going 4 hubs away when cascading hubs via >UTP. Does this also apply if the hubs are connected to thick or thin >ethernet backbones? One school will be like this: > >3 Hubs in one closet all connected via Thinnet with one hub connecting to >our WAN via fiber (into a switch). Two thinnet to fiber media converters >will be attached to fiber going to the next two closets, each with two hubs >also connected together via thinnet uplinks. The media converters make all >the hubs to appear to be on the same thinnet segment (7 hubs total on one >thinnet segment), is this "legal"? > >Is this a workable topology? I would like to use FDDI to connect all the >closets, but it isn't possible with our budget restraints. ------------ The practical rule is two hubs/repeaters in series. These are bit level devices. Ethernet preamble bits are lost as each hub synchronizes on the stream, bit transitions (up/down) are skewed slightly going through the hub so the clock rate has jitter. Systems tolerate only so much loss of preamble and increasing jitter. Stretching the practical rule results in flakey networks. A bridge or router takes in a whole Ethernet frame, stores it as a sequence of bytes, and then regenerates a clean output when retransmitting it. Such items can be cascaded forever. Some media converters are basically repeaters, so the rule includes them. These concepts apply to coax, twisted pair, fiber, carrier pigeons. Joe D. --------- Date: Wed, 11 Dec 1996 11:12:26 -0700 From: George Taylor Subject: Re: Hub cascading Actually any machine connected to one of the seven hubs is only on repeater away from your backbone, which is what the cheapnet/fiber trunk that you described is. So if your servers or routers are off one of the hubs your within the 5-4 rule. I made a few calls after getting Joe's message and the converters we have here (LanArt and Transitions) do not act like a repeater, more like a transciever, so they don't show up in the equation. If you look at yours being the same, the farthest two machines could be from each other is 3 links and 2 repeaters. We're in the same boat here, need the fast manageable stuff, but don't have the funds to do everything at once. The switching stuff certainly seems to be the way to go, it's working very well for us to have a switched network with the fast server farm. ------------------------------ Date: Wed, 15 Jan 1997 16:14:43 -0600 From: Joe Doupnik Subject: Re: IP routing, again >> I'm just facing a strange problem and need help. I tried to >>connect my Novell 3.12 to internet, here is a drawing about the >>configuration. >> >> (Novell 3.12 Server) >> __________________ >> | 100.1.1.1 | 100.1.1.2 >> | (adapter 1) | (Novell client) >> |-------------------------------------- >> 202.120.244.1 | 202.120.244.12 | | >> (internet router)|---| | (adapter 2) | | >> ------------|Hub|------|----------------| | >> |___| | | | 100.1.1.3 >> | | | |----------- >> | |________________| >> | >> | >> |---------------------- 202.120.244.6 >> (other internet user in 244.xxx) >> >>Theoretically, if "load tcpip forward=yes" has been included in autoexec.ncf, >>the two subnets 100.1.1.xxx and 202.120.244.xxx should be visible to each >>other. However, I "ping 202.120.244.12" from 100.1.1.2 get replies while >>"ping 202.120.244.6" get nothing. But when I type "load ping ..." on the >>Novell server, I can "ping" 244.1, 244.6 and even ping 224.1 will get replies. >>I never tried to connect my novell network with tcp/ip network before, so >>can anyone be so kind to tell me what's wrong? Here is my autoexec.ncf file, >> file server name MY_SVR >> ipx internal net 961208 >> register memory 1000000 1000000 >> load NE2000 port=320 int=3 frame=ETHERNET_802.2 name=IPX1 >> load NE2000 port=320 int=3 frame=ETHERNET_802.3 name=IPX2 >> load NE2000 port=320 int=3 frame=ETHERNET_II name=IP1 >> load NE2000 port=340 int=2 frame=ETHERNET_II name=INTERNET >> load tcpip forward=yes >> bind IPX to IPX1 net=19970102 >> bind IPX to IPX2 net=19970101 >> bind IP to IP1 address=100.1.1.1 mask=255.255.255.0 >> bind IP to INTERNET address=202.120.244.12 gateway=202.120.244.1 >> load cdrom >> mount all >> load pserver.nlm FDCAT_PRN >> load monitor >>and the F:\ETC\gateways file is empty. >> Thanks, if you can give me some suggestion. I do not care if I can >>"ping 202.120.100.1" or other IPs, I just wonder why I can't see >>202.120.244.6 from my Novell client. Bye the way, I'm using Trumpet Winsock >>on Novell clients, in tcpman.exe, default gateway is set to 100.1.1.1. > >Nope, ain't going to work. > >Why. Well, it has to do with classless addressing. Unless you have >valid class C ip addresses, the forwarding router for netware 3.11 is >not going to work. It just isn't smart enough. > >It also has to do with mixing and matching class C B A addresses with >similair network masks....like 255.255.255.0. > >That won't work either. > >Nope, it has to be a class C address routing space with a netmask of >255.255.255.0. For example...you could use the IP addresses >198.150.28.x and 198.150.30.x. Those would work dandy because they >are class C addresses. But too bad you don't own them eh? > >Get Netware 4.1 Multi-Protocol product, that will work. > >DO NOT get the 3.1 Multi-protocol router product, that suffers from the >same problem. > >Plus, you don't have to load IP on your file server if you don't want >to. (One less NLM to crash it!) ------------- Normally I'd let others handle this problem, but the response above is so far from being correct that something needs to be said now. Please disregard Greg's message because he doesn't understand the matter. Put the GATE= and MASK= on the same Load line, together rather than split over boards. It's a matter of finessing the drivers to see things your way. Also turn off RIP so outside broadcasts do not (mis)inform your server. Otherwise your NW commands look ok but sadly defficient in needed components of autoexec.ncf. Did you realize your server is totally open to outsiders looking at your TCP/IP stack stats? Yup, it is because SNMP is autoloaded and comes up with PUBLIC access. Never let that happen. Always load it manually with a command line holding your site's passwords for snmp access. Believe me, the bad guys are using snmp as a way of snooping on your site; I log such probes here. Please read the list's FAQ for suggested autoexec.ncf layout. Once the NW server is in good shape please attend to the other boxes so they talk correctly too. They need the same subnet mask, as openers. Joe D. ------------------------------ Date: Thu, 16 Jan 1997 15:38:21 -0600 From: Joe Doupnik Subject: Re: Another TCP/IP problem >Compaq file server, six network cards, NetWare 4.1 > >Enet_II bound to all cards. IP addresses of: >202.150.100.50 >203.150.100.50 >204.150.100.50 >205.150.100.50 >206.150.100.50 >207.150.100.50 > >All have a mask of FF.FF.FF.0. Rip=Yes Forward=Yes > >There is a SCO server on one of the networks (202 network) with a >node address of 51. There are terminal servers and PC\s running >LanWorkplace on each of the other legs. All terminals and all PC's >can TELNET into the SCO server. > >The problem is that I cannot ping any device from a PC or Terminal >unless the device is on the same segment. I can ping any device from >the PING.NLM. -------------- Look, comms of this kind have data flowing both ways. If the outgoing part works the incoming part may not. That means the entire network must be working properly, not just one piece. I say this repeatedly, but here it is again. TURN OFF RIP, OUT OUT DAMN SPOT (tm W.Sh.). RIP can tell lies, often does. RIP can carry a "default route" message, one which is false or inappropriate etc. Never use RIP. Then, please put a packet monitor on the wire and look at the darned thing. The batteries in our crystal balls are the old NiCad variety and they lack the range of imagination to see what folks did NOT do and/or forgot to mention. Put a GATEWAY= or equivalently a default route on the server. Go around and check the other machines for IP coherence. Put a packet monitor on the wire. Oh, did I mention that? Cisco server? I suspect you mean Cisco router. If not then what is it serving? As you can see, there is a full system involved here, not just a tiny piece, and asking us to guess the entire from the piece is a low accuracy occupation. Now please hookup that monitor... Tnx. Clever managers know to look in the ARP cache of machines to see who's knocked on the door. Joe D. ------------------------------ Date: Thu, 13 Feb 1997 15:15:45 -0600 From: Joe Doupnik Subject: Re: Modem Routers >Thanks for all the great info on ISDN routers but that's not the question >I'm asking. I'm talking about Analog Modems not ISDN. Is there such a >thing as an Analog modem router. I don't need the speed I just need a >cheap connection. ----------- There's a major confusion factor in your msgs. You want to see a remote server by name, but not actually communicate with it (exchange packets) until some high level operation requires it. That's nothing to do with analog or whatever modems as such and everything to do with design of the networking operating system. Were you running Appletalk routing then such routers forget nothing, ever. But NW is far more rational and constantly verifies connectivity to other routers, when they go away then do does their presence in say rconsole and so on. Novell Directory Services has the provision to reveal names of remote objects without those objects being touched at that moment. But there is a whole new set of problems involving NDS requiring background contact between regions periodically or the network suffers. All in all, networks of this kind are interactive even with no users, and thus dial up connections are difficult. IntranetWare attempts to come to grips with dialup lines and keeping the phone on hook as long as possible. Please visit your NetWare supplier for a test copy of INW 4.11 and look at the NIAS component (dealing with dialups etc as I recall). I'd say more but dialup networking has almost no use at my place and thus I remain blissfully ignorant of most details. You may also click away on Novell's web page, www.novell.com, for white papers and the like on the matter. Joe D. --------- Date: Fri, 14 Feb 1997 09:45:26 CST From: Gustin Kiffney <"Gustin_Kiffney_at_~4FD-MD-Baltimore"@CCMAIL.WORLDCOM.COM> Subject: Re: Modem Routers It's easy to find routers for IP that will work with analog modems. The shareware IPROUTE by David Mischler (look on Jumbo or oak.oakland.edu) runs on a 286 or better and does an excellent job of dial-on-demand routing between ethernet and serial ports using slip, ppp, even encrypted data tunneling. But it just does IP. To make it do IPX, you could load TCPIP and IPTUNNEL on 3.1x Netware servers (and PBURST, on 3.11 servers, which will crank up the speed a bit). Just make sure the network address bound to IPTUNNEL is the same on both servers - it took me a while to realize my mistake when I didn't do this. Or if you have 4.1, you could run nwip and that would work by itself, I suppose, but I don't have it and don't know for sure. I use it here to link two 3.11 networks during the day. It's slow, but with 28.8 kbaud modems using compression it does the job for our purposes. The registered version apparently does load balancing so you could use two modems and phone lines for an effective 56k-baud connection. I've been testing IPROUTE for a month and am about to register it - it does network address translation too if you want to have a route to an internet service provider. Or you could set up a Linux box with ip-forwarding and PPP and diald (a dial-on-demand demon). Since Linux can route IPX these days you might be able to coerce it to do IPX-dial-on-demand. ------------------------------ Date: Mon, 3 Mar 1997 17:39:56 -0600 From: Joe Doupnik Subject: Re: NW 4.11 as a router? >Does anyone have any information on the forwarding rate (in terms of >packets/sec) possible with Novell 4.11 acting almost purely as a >router? (Routing IP, IPX and Appletalk). I am certain the NIC and >CPU make a large difference. Right now, I am considering a couple >Cogent quartet cards (four 100mbs ports per card), but would consider >recommendations for anything that would be faster... > >Alternately, is there any freely available benchmarks that can be >setup to measure something like this... ----------- You'll need to run those benchmarks. NW is a software IP router, which means routing takes signficant cpu cycles. But since you asked I can give you a measurement done here. 486-33 EISA bus server, NE-3200 EISA lan adapters. Send tinygrams as fast as a Pentium-90 can generate them, almost, from one subnet to another on the same server. At 3000 packets/sec the server was nearly unable to anything else. But it kept running and running; INW 4.11 is strong. That's 3000 in one port and 3000 out the other, per second, continuously. That is a big number. The packet generator was one you can use without any trouble: MS-DOS Kermit. Tell Kermit SET TCP MSS 20, SET SEND PACK 2000, SET REC PACKET 2000, SET WINDOW 4, make a connection to another MSK acting in server mode with the same SET's, move a big file one way or the other. MSK's TCP/IP stack is fast, and the limiting factor here was the NE-2000 ODI driver in each client. Best to use MSK 3.15 beta 18 because it has dead-lan-driver recovery code stronger than in v3.14; see today's list for pointer. As can be guessed, setting the TCP Max Seg Size to be say 20 bytes creates an enormous number of minimal length IP datagrams (64 bytes, natch) and the long Kermit packet window can keep the wire busy solidly. Put the file source and destination to a RAM drive for throughput, or on the file server for max server stress. Note this is 10Mbps Ethernet. What is difficult to predict is performance on 100Mbps Ethernet, because the quality of drivers varies a lot as well as native efficiency of boards. I'm teaching a lan driver design class, ODI drivers this year, and we make measurments. The very few benchmarks I have of Intel EtherExpress Pro/100 boards (no letter, older units) is we gain a factor of 2-3 over 10Mbps Ethernet, and that of course is much less that one hopes for. Over the past year this has become an EE course, with the active help of Novell for $oftware and the donations of the Intel boards from two Novell list members. (Thanks to all for making this happen). I don't have any other 100Mbps gear at this time. The Intel boards are pretty efficient, a great deal more so than NE-2000 boards at the same speed Ethernet. To check IPX routing (a different pathway through the server) use program iozone (see netlab2.usu.edu, directory apps). It is a clear simple file writer/reader with source code, so there is nothing hidden. For your purposes here is such a test (desktop to INW 4.11 server): (Disk read after writing turned off. Intel EtherExpress Pro/100 PCI on Pentium 100 client, Intel EtherExpress Pro/100 EISA on 486-66 DX/2 server) IOZONE: Performance Test of Sequential File I/O -- V1.15 (5/1/92) By Bill Norcott Operating System: MS-DOS IOZONE: auto-test mode MB reclen bytes/sec written bytes/sec read 1 512 733269 733269 1 1024 1191563 1115506 1 2048 1588751 1476867 1 4096 2139951 1906501 1 8192 2383127 2097151 2 512 647269 683111 2 1024 1271001 1158647 2 2048 1530767 1416994 2 4096 2231012 1823610 2 8192 2526689 2139951 4 512 700217 694421 4 1024 1252031 1106676 4 2048 1625699 1441341 4 4096 2184533 1864135 4 8192 2542002 2016492 8 512 678689 710297 8 1024 1201806 1106676 8 2048 1591766 1388842 8 4096 1441341 1796275 8 8192 2629657 2066159 16 512 712105 651289 16 1024 1179003 799676 <<< Note running out of 16 2048 1519675 821204 cache buffers for blocks 16 4096 1542023 612083 queued to disk, reads hit 16 8192 1754938 846052 slow disk drive heavily Completed series of tests Joe D. ------------------------------ Date: Wed, 19 Mar 1997 16:48:19 -0500 From: Robert MacDonald To: netw4-l@bgu.edu, novell@listserv.syr.edu Subject: Now you see it, now you don't. We have a Netware 4.1 file server(PTN3) that cannot communicate(NDS & SPX?) properly with any servers at our Corporate site. This file server had been communicating fine until approximately three/four weeks ago. We know that NDS is having troubles (via dstrace screen. and from partition manager, which claims that PTN3 has not been updated since 03-17-97 at 2:08pm, the last time we reset the server.) Up to this time, we had noticed that one of our 3.12 servers(PTN1), attached to the ring 2b, would not allow us to rconsole in from the Corporate site. It would show in the available server list, but after you supplied the password, rconsole would complain that the server was down or no longer available. A simple reboot would cure the problem. This problem occurred every few weeks or so. The local admin could rconsole to any server - local or Corporate from any of the PTNx servers. Then this starting happening more frequently, to the point of approximately 10 minutes after rebooting, the server would become 'unavailable' to anyone at the Corporate site. We moved PTN1 from ring 2b to ring 2a and the problem went away for PTN1, but not PTN3. Since that time(1 week ago), we have been having similar troubles with PTN3. We have reset the bridges, servers, routers and hubs to now avail. All of Corporate can communicate with Remote location up to the Andrew bridge and vice-versa, but cannot communicate with PTN3. PTN2 can communicate with all of the servers, both at corporate and over the bridge(s). PTN3 cannot communicate with Corporate, but can communicate with all of the rest of Remote. All TCP/IP traffic was and still is un-effected by this. We have about 90 users on PTN3, using Rumba to communicate with our AS/400's at the Corporate site without any problems. Traceroute shows correct paths and response times(w/in reason) for IP traffic. Checking the SAP tables on both Rt1 & Rt2 show all the servers from all locations correctly. We also ran "reset routers" on Netware servers to no avail. (*) As of this past Monday, we have removed PTN1 from service. CORPORATE(Michigan) REMOTE(Tennessee) ------------------- ----------------- LPC2(4.1) PTN2(4.1) _|_ Frame _|_ |<-1 mile->| ___ / \ ___ Relay ___ / \ ___ T1 ___ / \ LPC3-( 1 )--|Rt1|-------|Rt2|--( 2a )--|_B_|---|_B_|--( 2b )-PTN3(4.1) (4.1) \___/ --- --- \___/ \___/ | | LPC1(4.11) PTN1(3.12)* Rtx = ACT Presticom Frame Relay Routers B = Andrew 74xx Bridges (bridge half) x = Token Ring reference #'s --------- Date: Wed, 19 Mar 1997 21:51:35 +0000 From: Philip Chase Subject: Re: Now you see it, now you don't. >Up to this time, we had noticed that one of our 3.12 >servers(PTN1), attached to the ring 2b, would not allow us to >rconsole in from the Corporate site. It would show in the available >server list, but after you supplied the password, rconsole would >complain that the server was down or no longer available. This means you can see the service in the SAP tables of the router you are talking to. The route between corporate and PTN1 is messed up. >A simple reboot would cure the problem. A reboot of what? client or server or bridge or router? >This problem occurred every few weeks or so. The local admin could >rconsole to any server - local or Corporate from any of the PTNx >servers. It sounds like this guy is receiving good routing info. However, one does not rconsole "from" a server. One rconsoles from a client. There is one problem I noticed with rconsole when my previous site moved to NetWare 4.1. Rconsole would get a list of rconsole SAP types (104) apparently from a NW 4.1 server. Enter the password, press enter and say bye bye. rconsole would hang without ever connecting. We never fully diagnosed the problem and instead coded around it with a perl script that would look up the server address and rconsoled to the address like this: rconsole -a 80e3a701 for a server VPHA whose internal network address is 80e3a701. this may remove some noise from your diagnoses. realy though, you need to attach a protocol analyzer to the cable and see what the dialogs are. --------- Date: Wed, 19 Mar 97 22:22:55 -0800 From: Randy Grein To: Subject: Re: Now you see it, now you don't. >We have a Netware 4.1 file server(PTN3) that cannot communicate(NDS & SPX?) >properly with any servers at our Corporate site. This file server had been >communicating fine until approximately three/four weeks ago. We know that >NDS is having troubles (via dstrace screen. and from partition manager, >which claims that PTN3 has not been updated since 03-17-97 at 2:08pm, the >last time we reset the server.) > >Up to this time, we had noticed that one of our 3.12 servers(PTN1), >attached to the ring 2b, would not allow us to rconsole in from the >Corporate site. I'll jump in with a couple of questions and possibilities: 1. What is the base rate and CIR of the frame relay? What is the utilization on the link? We've seen some problems with FR implementations throwing packets away under heavy load unless all of it's features are carefully implemented. 2. What is the line rate of the bridge to PTN3? 3. IPX and SPX have configurable timeouts. Have the defaults been adjusted? 4. Have you implemented IPX checksums? These can be critical for solving some NDS problems on WANs, although I doubt that is an issue here. 5. Has there been an increase in traffic, especially between sites? I suspect that the frame has simply become bogged down, and either the packets are being tossed out in the frame cloud or congestion is causing enough delay that connections time out. In any case, this is an issue that almost requires both a LAN and a WAN analyzer, something that few companies posess. Ours happens to, but you should be able to find someone closer in. --------- Date: Thu, 20 Mar 1997 22:42:54 +0100 From: "Arthur B." Subject: Re: Now you see it, now you don't. >We have a Netware 4.1 file server(PTN3) that cannot communicate(NDS & SPX?) >properly with any servers at our Corporate site. This file server had been >communicating fine until approximately three/four weeks ago. We know that >NDS is having troubles (via dstrace screen. and from partition manager, >which claims that PTN3 has not been updated since 03-17-97 at 2:08pm, the >last time we reset the server.) > >Up to this time, we had noticed that one of our 3.12 servers(PTN1), >attached to the ring 2b, would not allow us to rconsole in from the >Corporate site. It would show in the available server list, but after you >supplied the password, rconsole would complain that the server was down or >no longer available. A simple reboot would cure the problem. This problem >occurred every few weeks or so. The local admin could rconsole to any >server - local or Corporate from any of the PTNx servers. Are their any SAP-type filters in place? Like: Rt1 doesn't filter outgoing SAP-types but Rt2 does. >Then this starting happening more frequently, to the point of approximately >10 minutes after rebooting, the server would become 'unavailable' to anyone >at the Corporate site. We moved PTN1 from ring 2b to ring 2a and the >problem went away for PTN1, but not PTN3. Since that time(1 week ago), we >have been having similar troubles with PTN3. We have reset the bridges, >servers, routers and hubs to now avail. Where their any changes made to the SAP update interval somewhere? Like: from 1 minute to 3 minutes or so? Are all SAP names still unique? Did you check the configuration and or any other data that is stored to prevent loss after power-down on those devices? Is resetting the bridges enough to clear its internal tables? >All of Corporate can communicate with Remote location up to the Andrew >bridge and vice-versa, but cannot communicate with PTN3. PTN2 can >communicate with all of the servers, both at corporate and over the >bridge(s). PTN3 cannot communicate with Corporate, but can communicate with >all of the rest of Remote. Did you check the configuration of Rt2? Look for anything that was added to increase performance at first. >All TCP/IP traffic was and still is un-effected by this. We have about 90 >users on PTN3, using Rumba to communicate with our AS/400's at the >Corporate site without any problems. Traceroute shows correct paths and >response times(w/in reason) for IP traffic. What does a trace route for IPX show? >Checking the SAP tables on both Rt1 & Rt2 show all the servers from all >locations correctly. We also ran "reset routers" on Netware servers to no >avail. > >(*) As of this past Monday, we have removed PTN1 from service. Did this help? ------------------------------ Date: Wed, 14 May 1997 08:55:15 -0600 From: Joe Doupnik Subject: Re: Re[2]: Loading the TCP/IP stack on a Novell 4.1 server >Joe, > >Can you point me to info regarding your assertion to > >...Fifth, say RIP=NO to turn off IP RIP. It's bad news... > >My boss wants to go "IP only" company-wide and I want to be sure that >we are not making a mistake. --------------- File RFC1058.TXT, in any RFC archive site, is the definition. After reading and reflection discover that RIP participants believe what they hear, and advertize whatever they wish. Alas, mistakes and blunders happen all the time, and any machine can say whatever it wishes. Guess what that does to the RIP participant's ability to connect off the local wire? RIP also requires all participants to agree on an identical subnet mask, because RIP carries no subnet mask information. There is RIP-2 which does carry subnet mask information, but it is sparsely deployed. It still suffers from the gullibility factor. Arguments on "IP only" or "IPX only" boil down to emotional factors, termed religious issues, in almost all cases and I leave those sites to their fate. Joe D. --------- Date: Thu, 15 May 1997 09:43:16 +0100 From: "David W. Hanson" Subject: Re: Re[2]: Loading the TCP/IP stack on a Novell 4.1 server >Can you point me to info regarding your assertion to > >...Fifth, say RIP=NO to turn off IP RIP. It's bad news... > >My boss wants to go "IP only" company-wide and I want to be sure that >we are not making a mistake. Adding another $.02, you can't go wrong with static routes (once you get them right ). Unless your networks are -constantly- being reconfigured, there is no need to put up with the overhead (and as Joe mentioned, the chance of dodgy RIP info being propagated), when you can just set up static routes and be done with it, amen. RIP is a crutch for those who can't be bothered setting up and maintaining static routes. "IP only" is a preference, separate from the question of "To RIP or not to RIP". ------------------------------ Date: Tue, 15 Jul 1997 08:59:10 -0500 From: Dave Kearns Subject: Re: Second NIC in Novell server There's no way to "force" the use of a particular segment. NetWare will route based on number of hops. If the number of hops is equal, then it will use the segment with the lowest hex net number. ------------------------------ Date: Sat, 16 Aug 1997 12:29:27 +1200 From: "Baird, John" Subject: Re: Set Reply Not Really Working - Netware 4.11 >Some routers respond to a get nearest server on behalf of a server. I'm >just wondering whether this is where your GNS is coming from - which would >explain your results. Do you have routers on your network? Does the >Kalpana switch do this? This is certainly possible, but if the router is conforming to the IPX routing spec, it wont. The spec says that a router should not respond to GNS when it knows there is a server on the network from which the GNS request originated. When there is a single server on a network with responses to GNS turned off, and the router is behaving correctly, no workstation on that network should be able to connect to a server. ------------------------------