network@zeus.unomaha.edu (10/19/90)
We have multiple Novell file servers on the campus, nearly all v2.15 and all individualy bridged from our Ethernet backbone. I did some packet tracing with our network analyzer and found that when a station on one bridged network logged in to a server on another bridged Novell network, that they would pass ALL of their IPX traffic via a third file server which is also bridged from the backbone. It would be a different 'third' file server at different times. The packets had their final destination within the packet, but their destination address in the packet header was allways the 'third' file server. Of course this is bad. Traffic goes all over the place to get to it's destination. Other traffic is bridging fine. We use Cabletron bridges. Is there something with Netware IPX that causes this? Has anyone else seen this problem? Don't you wish Novell had decent support ;-) Steven Lendt Network Manager University of Nebraska at Omaha Internet: NETWORK@ZEUS.UNOMAHA.EDU Bitnet: NETWORK@UNOMA1
backman@vaxeline.COM (Larry Backman) (10/22/90)
In article <2868.271e3313@zeus.unomaha.edu> network@zeus.unomaha.edu writes: > > We have multiple Novell file servers on the campus, nearly all v2.15 >and all individualy bridged from our Ethernet backbone. > I did some packet tracing with our network analyzer and found that when >a station on one bridged network logged in to a server on another bridged >Novell network, that they would pass ALL of their IPX traffic via a third >file server which is also bridged from the backbone. It would be a different >'third' file server at different times. > The packets had their final destination within the packet, but their >destination address in the packet header was allways the 'third' file server. > You are running into the dreaded Novell RIP protocol. All Netware servers can also be Netware routeres as they have RIP (XNS derived) protocol embedded within them. When a workstation comes up it issues a GET_NEAREST_SERVER NCP (netware Core Protocol) packet. This is a broadcast query which *ALL* Netware servers reply to. The worksdtation picks the first reply (Fastest or nearest) server as its default server. Now the user tries to log onto another server. The login program comes fromt he inital server, and if the target server does not have the same Novell network number as the initial server, RIP protocol determines a rouet (read two hops!) to the target server. I believe that this is the behavior that you are seeing. Suggestion: if your network is really bridged rather than routed, make sure all Netware servers that are bridged to thwe backbone have the same network number. This should alleviate the two hop syndrome. If you have different media, Netware subnets, etc. put two cards in the server, the first (Net A!!!!) should be connected to your backbone ethernet, and the second (Net B) is connected to the workgroup's media. Remember that all servers on the ethernet should have the same network address. Larry Backman backman@ftp.com .
pasek@npdiss1.StPaul.NCR.COM (Michael A. Pasek) (10/24/90)
In article <2868.271e3313@zeus.unomaha.edu> network@zeus.unomaha.edu writes: >[configuration info deleted] > I did some packet tracing with our network analyzer and found that when >a station on one bridged network logged in to a server on another bridged >Novell network, that they would pass ALL of their IPX traffic via a third >file server which is also bridged from the backbone. It would be a different >'third' file server at different times. > The packets had their final destination within the packet, but their >destination address in the packet header was allways the 'third' file server. > Of course this is bad. Traffic goes all over the place to get to >it's destination. Other traffic is bridging fine. We use Cabletron >bridges. Is there something with Netware IPX that causes this? >Has anyone else seen this problem? Don't you wish Novell had >decent support ;-) I am not sure if it's something with Netware IPX that causes this, but I would guess so. It appears that the following occurs (in the trace I have): 1) Client sends out "Nearest Service" query 2) Gets response from server or "bridge" (in the Novell sense of the word) 3) Sends XNS RIP request to determine the route to get to the network that the server is on. 4) Whichever node responds FIRST to the XNS RIP request will be the node that the client sends ALL its traffic to that is intended for the server. This is true in my trace EVEN THOUGH the first responder had a hop count of 2 to get to the server, and the second responder had a hop count of 1. As the "Summary" line says -- yes, I've seen this. I can't comment on Novell support, I'm only an observer of Netware traffic. M. A. Pasek Software Development NCR Comten, Inc. (612) 638-7668 MNI Development 2700 N. Snelling Ave. pasek@c10sd3.StPaul.NCR.COM Roseville, MN 55113