Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community

At 20 JUL 2009 06:09:19PM Victor Engel wrote:

There is an option on the Netware client properties tab labeled "Advanced Settings" called "Limit SAP Broadcast Queries".

When I had trouble connecting to a file server using IPX (could get an IP connection), I tried changing the value of this option from On (default) to Off. On my next attempt, I got an IPX connection. This would seem to indicate that the setting made a difference, but it could also have been coincidence. That LAN was bandwidth limited at the time, so I might have just happened to get a word in edgewise.

Anyway, getting to my point, searching the net for references to this setting, the various explanations seem to be opposite of each other. The description when I have it highlighted says, "Use this setting to limit SAP so that it locates servers only on connections where the bindery is present. Disable this parameter if you want SAP to find servers if the bindery query fails."

I figured I might have been failing my IPX connection because the bindery query was failing, so turning this option off might be a good idea. But in googling the setting, I see descriptions that indicate it does a double query with it set to the on position.

Which is it? I'm leaving my setting to Off for the moment, because that seems to be working better (until it stops working, I guess)


At 22 JUL 2009 09:57PM Eric wrote:

One setting blends IP and IPX and the other enables IPX exclusively.

See

http://support.novell.com/techcenter/articles/ana19950404.html


At 23 JUL 2009 05:45PM Victor Engel wrote:

Which is which?


At 23 JUL 2009 08:46PM Eric wrote:

I think the SAP queries go through as IP, whereas the bindery stuff goes through on IPX.

You said "because the bindery query was failing," which either suggests that the network IP traffic is so high that something is rejecting or queuing and delaying IPX based requests, or else there is some compatibility issue with older style IPX calls (using int 21h) as opposed to the later ones (using int 2f).

The other aspect to consider is hardware - because IPX packets are different in size to IP ones, is may be some setting inhibiting IPX packet support which is occurring. Remember network cards and routers all expect IP by default nowadays, and the IP optimizations (packet size / retries etc) may not be ideal for data bundled over IPX.

I agree that it shouldn't make a difference at the hardware layer, because it should be purely protocol based. But I've seen some funny behaviours over the years with networks carrying IP and IPX together.


At 24 JUL 2009 12:12PM Victor Engel wrote:

But it's just the original connection that was unable to be made with the original setting. After I made the change, I got an IPX connection and then subsequent IPX connectivity was not a problem. That would seem to contradict your idea that IP bandwidth was throttling IPX bandwidth.

Anyway, I'm pretty sure that on our WAN, IPX traffic is carried in IP packets. How that all works, though, is over my head.


At 29 JUL 2009 09:25AM Warren Auyong wrote:

Before my client got rid of Novell they were using IP tunneling for their WAN over a T1 line. Basically IPX packets encapsulated in IP. At some point the service provider didn't want to make any changes as they no longer had any techs with any knowledge of IP tunneling.

Novell's first LAN implementation of TCP/IP encapsulated IP in IPX! It wasn't until one of the version 5.x (or it could have been 6.0 I don't exactly recall) that Novell implemented true IP.

http://support.novell.com/techcenter/articles/ana19950904.html

View this thread on the forum...

  • third_party_content/community/commentary/forums_nonworks/a2e3cc1a360e3ae6852575f90079b415.txt
  • Last modified: 2023/12/28 07:39
  • by 127.0.0.1