Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 27 Jan 1996 07:18:16 +0200 (SAT)
From:      John Hay <jhay@mikom.csir.co.za>
To:        terry@lambert.org (Terry Lambert)
Cc:        hackers@FreeBSD.ORG (FreeBSD-hackers)
Subject:   Re: NetBUI and/or IPX routing?
Message-ID:  <199601270518.HAA09078@zibbi.mikom.csir.co.za>
In-Reply-To: <199601262014.NAA05110@phaeton.artisoft.com> from "Terry Lambert" at Jan 26, 96 01:14:45 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> 
> > I think you are a bit sidetracked. The original question was if it is
> > possible to have a Netware server on one side of a router and only IPX
> > clients on the other side. (No Netware server on that side)
> > 
> >    ------------           -----------         ----------
> >    | Netware  |  Net A    | FreeBSD |  Net B  |  IPX   |
> >    |          |-----------|         |---------|        |
> >    | Server   |           | Router  |         | Client |
> >    ------------           -----------         ----------
> > 
> > This is possible with Netware 3.11 and DOS and Windose clients. We are
> > using it here. I don't have a Netware 4.xx server so I don't know if that
> > will work.
> > 
> > What happens is that the FBSD router will gather the IPX RIP and SAP
> > information that is broadcast by the server (and others if there are more
> > than one). When you start a IPX client it will do a SAP GetNearestServer
> > request (broadcast) which the router will answer. This packet contains the
> > name and address of the Netware Server. The client will then do a RIP
> > request to find a router that will route packets to the server address that
> > it just received. The router will answer it because it will see that it
> > is the cheapest (only) route to the server. Only then the client will send
> > a NCP connection request to allocate a connection slot. This is send to
> > the server. So the router does not have to answer any NCP requests.
> 
> Not all clients will RIP.  Not all clients use the internal field
> rather than the source address on the Nearest Server response (ie:
> GetNearestServer can not be routed for these clients without the
> router lying about its IPX network number in the IPX header).

This may be true, but I haven't seen any that doesn't. All the versions
of netx and the vlm's from Novell do it.

> 
> I'm glad that the Nearest Server response is properly proxied, but this
> will not fix all clients (especially 'remote reset' clients).  To do
> that, you will have to fake source address in the IPX header as well
> as setting server address for the "nearest server" in the response.

Maybe I don't understand your use of the term proxy, but I don't see the
response to a SAP GetNearestServer request as proxy, because it is the
job of a IPX router to be able to respond to SAP GetNearestServer and RIP
requests.

> 
> Like sliding windows in SPX, there is a major discrepancy between
> specification and implementation.
> 
> In addition, I would caution that a delay is necessary on router proxy
> response to a GetNearestServer.  Consider the case of:
> 
> 
>    ------------         -----------    o    ----------
>    | Netware  |  Net A  | FreeBSD |    x----|  IPX   |
>    |          |---------|         |    |    |        |
>    | Server1  |         | Router  |----x N  | Client |
>    ------------         -----------    | e  ----------
> 				       | t
> 				       |    ------------
> 				       | B  | NetWare  |
> 				       x----|          |
> 				       |    | Server2  |
> 				       o    ------------
> 
> A "GetNearestServer" from "IPX client" will elicit a response both
> from "FreeBSD Router" and "NetWare Server2".

No it should not. Server1 isn't the nearest anymore, so the router should
not respond to a GetNearestServer SAP request from the IPX client.

> 
> You want the client to get the "NetWare Server2" response first; the
> way to do this is to delay the response from "FreeBSD Router".  There
> is *not* a hop-count based "election" on nearest server preference;
> it's whoever answers first.  The Native NetWare server and the NWU
> NetWare server both parameterize the ability to delay response.
> 
> A local server is preferaable to a routed serve because of negotiated
> packet sizes through routers dropping to 512.

A bigger problem (performance wise) is the extra hop that is incurred for
NCP. Burst mode isn't the whole answer to that.

John
-- 
John Hay -- John.Hay@csir.co.za



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601270518.HAA09078>