🚀 go-pugleaf

   I'm having a couple of problems getting TCP/IP on a NetWare 4.10
server to cooperate with my plans ... and the manuals are really not
very good on this stuff.

   We connected to the Internet several months ago and were assigned
one class C address.  As most of our network is connected with
pre-4.10 NetWare servers, some parts of it can't use variable
length subnet masks at all.  At that time, our network looked
like:

Internet <------ Cisco Router
                      |
                      | net 205.206.187.64/255.255.255.224
                      | (with about 30 machines)
                      |
                 NetWare 4.02
                      |
                      | net 205.206.187.160/255.255.255.224
                      | (point-to-point link)
                      |
                 NetWare 3.12---------net 205.206.187.32/255.255.255.224
                   |      |           (with about 10 machines)
                   |      |
                   |      +-----------net 205.206.187.128/255.255.255.224
                   |                  (with about 25 machines)
                   |
                   +------------------net 205.206.187.192/255.255.255.224
                                      (with about 20 machines)

   All netmasks had to be the same, due to NetWare's inability to
handle VLSM, and so everything from a 2-node network on up to
the 30-node network had to be given a 30-node network mask.

   We upgraded the NetWare 4.02 machine to 4.10, partly because we
needed to grow beyond 30 machines on 205.206.187.64.  We had
reserved what would otherwise be 205.206.187.96 for growth on the .64
network, and so we changed the netmask on 205.206.187.64 to
255.255.255.192 and that network can now handle up to 62 machines.
So far, so good; we have two different netmasks on the 4.10 machine.
Since that worked, we also changed the netmask on .160 to
255.255.255.252, and eventually we'll upgrade the 3.12 box and
it, too, will be able to support VLSM.  The plan is to renumber
that network to .244 at that time, freeing up the .160 network
to be merged with .128 to allow growth similar to that of the
.64 network.

   I should note that the point-to-point link between the two
NetWare servers is implemented using Digi's PC IMAC ISDN cards.
I should also note that we have explicitly disabled RIP:

LOAD TCPIP FORWARD=YES RIP=NO

   The .64 network is bound with

BIND IP TO NE2000 ADDR=205.206.187.64 MASK=255.255.255.192 GATE=205.206.187.75
(the latter is the Cisco router)

   The .160 network is bound automatically by the PCIMAC driver;
the equivalent BIND line is

BIND IP TO PCIMAC ADDR=205.206.187.160 MASK=255.255.255.252

   Static routes are used on the NetWare 4 server so that it knows
the location of all subnets.

   We recently were assigned a second class C address and have
another network to hook up.  This will require another point-to-point
link from the 4.10 server, plus a populated network of about 10
nodes on the other side of that link.  I wanted to make the
point-to-point link 205.206.187.240/255.255.255.252 (note that
it's using the same netmask as the .160 network).  However,
the 4.10 box refused, claiming that the netmask was incompatible
with the netmask on an existing interface - the .64/.192 network,
in this case.  Whatever order I use to list the networks in
the AUTOEXEC.NCF, the first two always bind, and the third one
always complains that the netmask is incompatible with the first
one bound.  So I've had to renumber some of the networks and
can get by for now, but I'm not happy with the changes I've been
forced to make.

   I have several questions:

1.  Am I really trying to do something illegal, or is something
broken in NetWare 4.10's TCP/IP?  I'm using TCPIP.NLM 3.00b; I'm
not sure if this is current or not and I don't have any
opportunities in the near future to upgrade if it's not, but
if a newer TCPIP.NLM will fix my problem, please tell me so.

   If I am doing something illegal, then I don't understand why I can
have one interface using .192 and one using .252 but not one using
.192 and two using .252, so please explain why it isn't allowed.  The
manual is very poor at this; basically, its explanation of the error
message is "Don't do that" but it offers no reason why I can't and no
text describing what rules TCPIP.NLM follows to determine whether
you're doing something legal or not.  As far as I know, VLSM is
supposed to let you use whatever subnet masks you want on whatever
portions of your IP address space you want, provided that each
individual subnet is legal on its own grounds (e.g. no all-ones
subnets).  If .252 is illegal on my third subnet, why is it
legal for the second subnet of the same IP address?  None of my
subnets overlap, and since RIP can't handle VLSM, I've disabled
it.

2.  Is there any actual documentation on the command-line switches
to TCPIP.NLM and the BIND IP command in 4.10?  This used to be in the
4.0 and earlier manuals, alongside a note saying that using INETCFG
was the better way, but they appear to have entirely excised the
manual method from the 4.10 documentation.  See #3 for more detail
on why I want information on the old-fashioned LOAD and BIND method.

3.  INETCFG.NLM does not understand Digi's PCIMAC driver.  It
was unable to import the LOAD command for this driver, and since
the PCIMAC driver issues its own BIND commands in most cases,
it was also unable to import the BIND commands.  PCIMAC isn't
perfect; usually it doesn't manage to bind one or two of the
protocols so I've taken to putting the BIND commands in the
AUTOEXEC.NCF as well as telling PCIMAC to bind automatically.
INETCFG couldn't import those as it couldn't find the NIC driver
to which they are to be bound.

   This is with the PCIMAC driver disk 1.4.0, downloaded from
Digi's site about a month ago.  For those with experience
with PCIMAC, is there a better way of loading the driver
or any other advice?  I don't much care whether I have to
do this manually, automatically, or through INETCFG; I just
want it to work properly.
-- 
Stephen M. Dunn (SD313)                                    steved@ussinc.com
----------------------------------------------------------------------------
CNE, ACE, Senior Systems Analyst                United System Solutions Inc.
104 Carnforth Road, Toronto, ON, Canada M4A 2K7          (416) 750-7946 x251