
----------------------------------------------------------------------
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 <JRD@USU.BITNET>
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 <JRD@CC.USU.EDU>
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 <JRD@CC.USU.EDU>
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 <afrc-mis@EMAIL.AUGSBURG.ARMY.MIL>
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 <JRD@CC.USU.EDU>
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 <JRD@CC.USU.EDU>
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
><snip>
>>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" <banttari@ix.netcom.com>
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 <ROEHL@ERZICIP.ERZWISS.UNI-HAMBURG.DE>
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 <JRD@CC.USU.EDU>
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 <JRD@CC.USU.EDU>
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 <ispigel@open.hr>
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 <JRD@CC.USU.EDU>
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 <dtran@UCLA.EDU>
Subject: Re: TCP31A.EXE archive file - follow up

In article <01HXU5M71M3Q9ANIQE@cc.usu.edu> Joe Doupnik <JRD@CC.USU.EDU> 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 <JRD@CC.USU.EDU>
Subject: Re: NLSP Configuration on a 3.xx network

<big snip>

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

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

Date: Mon, 27 Nov 1995 04:26:02 GMT
From: "Stephen M. Dunn" <stephen@BOKONON.USSINC.COM>
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 <JRD@CC.USU.EDU>
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" <stephen@bokonon.ussinc.com>

>$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 <Mailbox@ICE.NL>
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 <buddy@VAIL.NET>
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 <JRD@CC.USU.EDU>
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 <rgrein@halcyon.com>
To: "NetWare 4 list" <netw4-l@bgu.edu>
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" <BAIRD2@WHIO.LINCOLN.AC.NZ>
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 <JRD@CC.USU.EDU>
Subject: Re: a DNS/UDP problem?  TCP/IP forwarding looks ok

	<omitting lots>
>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).
	<omitting even more>
>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" <DarrenMail@AOL.COM>
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 <JRD@CC.USU.EDU>
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 <m.cramer@QUT.EDU.AU>
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." <arthur-b@ZEELANDNET.NL>
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 <JRD@CC.USU.EDU>
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 <JRD@CC.USU.EDU>
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 <JRD@CC.USU.EDU>
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 <taylor@EWCWEB.EWC.WHECN.EDU>
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 <JRD@CC.USU.EDU>
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 <JRD@CC.USU.EDU>
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 <JRD@CC.USU.EDU>
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 <JRD@CC.USU.EDU>
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 <RMACDONALD@perrigo.com>
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 <pbc@VPHA.HEALTH.UFL.EDU>
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 <rgrein@halcyon.com>
To: <netw4-l@ecnet.net>
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." <arthur-b@ZEELANDNET.NL>
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 <JRD@CC.USU.EDU>
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" <hansond@AFRC.GARMISCH.ARMY.MIL>
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 <grin>).  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 <dkearns@VQUILL.COM>
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" <BAIRD2@WHIO.LINCOLN.AC.NZ>
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.

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

