Anonymous_User Absent Member.
Absent Member.
1928 views

Client TCPIP vs IPX issues

My Environement.
2 Netware servers
- Server1= Netware 6SP4 (IP and IPX, DNS and DHCP, DHCP gives value 78)
- Server2= Netware 65SP7 (IP only, SLPDA)
Single tree, single context.
Clients = Windows XP SP2 with Novell Client 4.91SP4. (test pcs have not antivirus on them)
Switches are 3Com series 4000 switches (We had to disable STP and Multicast filtering to get IP to display tree info, otherwise no tree found)
Switches are running latest firmware dated of 11 months ago.
Single subnet, no VLANs no routers.
Cabling is good.

Problem.
When in IPX login screen give tree info within a second.
When in TCPIP login screen takes nearly 30 seconds to reveal server info.
Data transfer rates, 400MB transfers in 65 seconds in TCPIP and transfers in 45 seconds in IPX.

What we have tried.
As stated before, we disabled SpanningTreeProtocol on and IGMP multicast filtering on switches, this helped some but not enough.
Server
We have disabled AV software on servers, no difference in performance.
We configured an SLPDA although and added value to DHCP options, no improvements.

What we think the problem is.
We think the managed switches are blocking SLP or something and causing authentication issues. We just don't understand why IPX is faster than IP on these servers...

Any suggestions or comments would be greatly appreciated.

Thanks.
Labels (1)
0 Likes
11 Replies
Knowledge Partner
Knowledge Partner

Re: Client TCPIP vs IPX issues

Hi,

rmyers1968 wrote:
>
> Problem.
> When in IPX login screen give tree info within a second.
> When in TCPIP login screen takes nearly 30 seconds to reveal server
> info.


On this issue, take a LAN trace. It is almost certainly a name
resolution problem.

> Data transfer rates, 400MB transfers in 65 seconds in TCPIP and
> transfers in 45 seconds in IPX.

....
> We just don't understand why IPX is faster than
> IP on these servers...


IPX *is* faster than TCP(IP), mostly because it's stateless (like UDP in
the TCP/IP suite), whereas the Novell Client in TCP/IP uses TCP
(staeful), which compares to SPX in the IPX protocol suite. Your
performance difference seems a bit hefty, but may still be perfectly
normal depending on your network infrastructure. In the end, IPX will
always outperform TCP for file transfers in a LAN, no matter what you
do.

CU,
--
Massimo Rosen
Novell Product Support Forum Sysop
No emails please!
http://www.cfc-it.de
CU,
--
Massimo Rosen
Micro Focus Knowledge Partner
No emails please!
http://www.cfc-it.de
0 Likes
peterkuo Absent Member.
Absent Member.

Re: Client TCPIP vs IPX issues

Massimo Rosen wrote:

> In the end, IPX will
> always outperform TCP for file transfers in a LAN, no matter what you
> do.


Partly due to both uses NCP which adds overhead of (some) "acks", and this
becomes a "double ack" when TCP is in use ...


--


Peter
eDirectory Rules!
http://www.DreamLAN.com

Get Gadgetized: http://www.DreamLAN.com/ldapgadget.html

-- eDirectory Rules! Peter www.DreamLAN.com
0 Likes
peterkuo Absent Member.
Absent Member.

Re: Client TCPIP vs IPX issues

If you can, stick in a 'dumb' switch and run a few devices off it and see
if you can see any difference ...


--


Peter
eDirectory Rules!
http://www.DreamLAN.com

Get Gadgetized: http://www.DreamLAN.com/ldapgadget.html

-- eDirectory Rules! Peter www.DreamLAN.com
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Client TCPIP vs IPX issues

You may want to take a trace to see if you are getting lost packets.
I've found that IPX handles network errors much better than IP on NetWare.
While IPX will always be slower, the large percentage difference makes me
wonder if you are losing packets.

The most common cause of network trouble our Duplex Mismatch issues.

--
Craig Wilson - MCNE, MCSE, CCNA
Novell Support Forums Volunteer Sysop

Novell does not officially monitor these forums.

Suggestions/Opinions/Statements made by me are solely my own.
These thoughts may not be shared by either Novell or any rational human.

"rmyers1968" <rmyers1968@no-mx.forums.novell.com> wrote in message
news:rmyers1968.390unb@no-mx.forums.novell.com...
>
> My Environement.
> 2 Netware servers
> - Server1= Netware 6SP4 (IP and IPX, DNS and DHCP, DHCP gives value
> 78)
> - Server2= Netware 65SP7 (IP only, SLPDA)
> Single tree, single context.
> Clients = Windows XP SP2 with Novell Client 4.91SP4. (test pcs have not
> antivirus on them)
> Switches are 3Com series 4000 switches (We had to disable STP and
> Multicast filtering to get IP to display tree info, otherwise no tree
> found)
> Switches are running latest firmware dated of 11 months ago.
> Single subnet, no VLANs no routers.
> Cabling is good.
>
> Problem.
> When in IPX login screen give tree info within a second.
> When in TCPIP login screen takes nearly 30 seconds to reveal server
> info.
> Data transfer rates, 400MB transfers in 65 seconds in TCPIP and
> transfers in 45 seconds in IPX.
>
> What we have tried.
> As stated before, we disabled SpanningTreeProtocol on and IGMP
> multicast filtering on switches, this helped some but not enough.
> Server
> We have disabled AV software on servers, no difference in performance.
> We configured an SLPDA although and added value to DHCP options, no
> improvements.
>
> What we think the problem is.
> We think the managed switches are blocking SLP or something and causing
> authentication issues. We just don't understand why IPX is faster than
> IP on these servers...
>
> Any suggestions or comments would be greatly appreciated.
>
> Thanks.
>
>
> --
> rmyers1968
> ------------------------------------------------------------------------
> rmyers1968's Profile: http://forums.novell.com/member.php?userid=4275
> View this thread: http://forums.novell.com/showthread.php?t=326896
>



0 Likes
Knowledge Partner
Knowledge Partner

Re: Client TCPIP vs IPX issues

Craig,

Craig Wilson wrote:
>
> You may want to take a trace to see if you are getting lost packets.
> I've found that IPX handles network errors much better than IP on NetWare.


That's another advantage of IPX over IP. It's been designed for
comparably fast and error-free local networks, whereas IP was designed
for slow and erroneous WANs.

> While IPX will always be slower,


You mean IP, I think? <g>

> the large percentage difference makes me
> wonder if you are losing packets.


Well, for that I think it's way too fast overall. Close to 9MB/s is
perfect speed for IPX, and 6,5MB/s is well within the normal range of IP
speed on a 100MBit net. You can reach 8 to 8,5MB/s with IP, but that's
about it, and needs absolutely perfect surroundings. One additional
switch between WS and Server will make such speed impossible already.

> The most common cause of network trouble our Duplex Mismatch issues.


True, but for duplex mismatches his speed (for both IPX and IP) is *far*
to good.

CU,
--
Massimo Rosen
Novell Product Support Forum Sysop
No emails please!
http://www.cfc-it.de
CU,
--
Massimo Rosen
Micro Focus Knowledge Partner
No emails please!
http://www.cfc-it.de
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Client TCPIP vs IPX issues

Yeah, I meant that "IPX" will always be faster.

Well, It is kind of good for having "Duplex" issues, but I've seen the
difference vary.
A 50% speed difference is quite a bit and usually the difference is in the
low single digits when I have tested.

There are a number of settings that can effect how bad things get with
Duplex Mismatch errors.
That may not be the exact issue, but I would be surprised if he was not
having some type of network problem involving lost or corrupt packets.


--
Craig Wilson - MCNE, MCSE, CCNA
Novell Support Forums Volunteer Sysop

Novell does not officially monitor these forums.

Suggestions/Opinions/Statements made by me are solely my own.
These thoughts may not be shared by either Novell or any rational human.

"Massimo Rosen" <mrosenno@spamcfc-it.de> wrote in message
news:4821A8D6.350A771@spamcfc-it.de...
> Craig,
>
> Craig Wilson wrote:
>>
>> You may want to take a trace to see if you are getting lost packets.
>> I've found that IPX handles network errors much better than IP on
>> NetWare.

>
> That's another advantage of IPX over IP. It's been designed for
> comparably fast and error-free local networks, whereas IP was designed
> for slow and erroneous WANs.
>
>> While IPX will always be slower,

>
> You mean IP, I think? <g>
>
>> the large percentage difference makes me
>> wonder if you are losing packets.

>
> Well, for that I think it's way too fast overall. Close to 9MB/s is
> perfect speed for IPX, and 6,5MB/s is well within the normal range of IP
> speed on a 100MBit net. You can reach 8 to 8,5MB/s with IP, but that's
> about it, and needs absolutely perfect surroundings. One additional
> switch between WS and Server will make such speed impossible already.
>
>> The most common cause of network trouble our Duplex Mismatch issues.

>
> True, but for duplex mismatches his speed (for both IPX and IP) is *far*
> to good.
>
> CU,
> --
> Massimo Rosen
> Novell Product Support Forum Sysop
> No emails please!
> http://www.cfc-it.de



0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Client TCPIP vs IPX issues

And I mean a low single digit performance difference on a LAN w/o issues.

--
Craig Wilson - MCNE, MCSE, CCNA
Novell Support Forums Volunteer Sysop

Novell does not officially monitor these forums.

Suggestions/Opinions/Statements made by me are solely my own.
These thoughts may not be shared by either Novell or any rational human.

"Craig Wilson" <craig_d_wilson@yahoo.com> wrote in message
news:uUhUj.10544$Dh4.5791@kovat.provo.novell.com...
> Yeah, I meant that "IPX" will always be faster.
>
> Well, It is kind of good for having "Duplex" issues, but I've seen the
> difference vary.
> A 50% speed difference is quite a bit and usually the difference is in the
> low single digits when I have tested.
>
> There are a number of settings that can effect how bad things get with
> Duplex Mismatch errors.
> That may not be the exact issue, but I would be surprised if he was not
> having some type of network problem involving lost or corrupt packets.
>
>
> --
> Craig Wilson - MCNE, MCSE, CCNA
> Novell Support Forums Volunteer Sysop
>
> Novell does not officially monitor these forums.
>
> Suggestions/Opinions/Statements made by me are solely my own.
> These thoughts may not be shared by either Novell or any rational human.
>
> "Massimo Rosen" <mrosenno@spamcfc-it.de> wrote in message
> news:4821A8D6.350A771@spamcfc-it.de...
>> Craig,
>>
>> Craig Wilson wrote:
>>>
>>> You may want to take a trace to see if you are getting lost packets.
>>> I've found that IPX handles network errors much better than IP on
>>> NetWare.

>>
>> That's another advantage of IPX over IP. It's been designed for
>> comparably fast and error-free local networks, whereas IP was designed
>> for slow and erroneous WANs.
>>
>>> While IPX will always be slower,

>>
>> You mean IP, I think? <g>
>>
>>> the large percentage difference makes me
>>> wonder if you are losing packets.

>>
>> Well, for that I think it's way too fast overall. Close to 9MB/s is
>> perfect speed for IPX, and 6,5MB/s is well within the normal range of IP
>> speed on a 100MBit net. You can reach 8 to 8,5MB/s with IP, but that's
>> about it, and needs absolutely perfect surroundings. One additional
>> switch between WS and Server will make such speed impossible already.
>>
>>> The most common cause of network trouble our Duplex Mismatch issues.

>>
>> True, but for duplex mismatches his speed (for both IPX and IP) is *far*
>> to good.
>>
>> CU,
>> --
>> Massimo Rosen
>> Novell Product Support Forum Sysop
>> No emails please!
>> http://www.cfc-it.de

>
>



0 Likes
Knowledge Partner
Knowledge Partner

Re: Client TCPIP vs IPX issues

Craig,

Craig Wilson wrote:
>
> Yeah, I meant that "IPX" will always be faster.
>
> Well, It is kind of good for having "Duplex" issues


That's what I meant, I agree, it could be intermittent packet loss of
sorts.

CU,
--
Massimo Rosen
Novell Product Support Forum Sysop
No emails please!
http://www.cfc-it.de
CU,
--
Massimo Rosen
Micro Focus Knowledge Partner
No emails please!
http://www.cfc-it.de
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Client TCPIP vs IPX issues

First off, a big thank you for all the great info. Less than 24 hours and 7 very insightful/helpful replies.

Really appreciate the time you are taking. I have bolded the questions I have, so if you do not have time to read my lengthy post, you can hopefully give me a few answers to some questions, thanks in advance.

As far as duplex mismatch, I think that Massimo's post makes sense, it would equally affect both protocols, so pretty sure I can rule that out.

As far as dropped packets, or comm issues, on the switches I see 0 dropped packets, 0 collisions and 0 errors on the switches. But I guess I should run a protocol analyzer on the PC, in case the switch is blocking things because of multicast filters, STP, or other.

I am betting the switches are messing up things. I plan to place some dumb unmanaged switches to see if this makes a diff., that sounds like a worthwhile test.

Q1: If the servers remain on a managed switch and I add a dumb switch will that be enough, or should I place one or more servers on the dumb switch with that PC?

As far name resolution issues, as far as server configs, given my environment of single subnet, no routers, no bridges, etc.

Q2: Is there anything I have to configure on the server side for names resolution, given my simple environment, assuming switches are not messing things up?

We had setup a SLPDA on one server and modified the SLP.CFG on the other server to refer to the SLPDA. We added entry 78 to DHCP to provide SLPDA info to DHCP clients.

Q3: Is there any useful info I should look at in SLPINFO.EXE /a that might clue me in on anything wrong?

Q4: Using a protocol analyzer, should I be filtering for some specific packets, if so which ones are of greater interest for my IP name resolution issues?

Thanks again guys, really appreciate all the help.
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Client TCPIP vs IPX issues

Massimo was not saying the Duplex Mismatch would effect both protocols the
same.
He was saying it should effect IP even MORE than what you are seeing.
In general this is true, but certain settings may lessen the impact.
(A very simplistic explanation is that IPX will retry lost packets much
sooner since it assumes a LAN and not a global network where packets can
arrive much slower.)

The main thing to concentrate on at this point is your transfer speed over
IP.
Clearly something is amiss here due to the large difference with IPX.
Once the speed is up to par so that the difference is minimal compared to
IP, then we can examine other delays if they still exist.

What you want to do is install Wireshark (http://www.wireshark.org) onto a
PC.
Ensure the Novell Client is installed as IP only so we are ensuring an IP
connection to your server.

Then Start a Trace.
Copy the 400MB file to the Server.
Stop the Trace.
From the Menu, select Analyze->Expert Composite Info.
Examine the errors returned. (Note: Checksum Errors alone do not indicate
an problem. This can be caused by many NICs that offload Checksum work. As
a result its a false positive.)


--
Craig Wilson - MCNE, MCSE, CCNA
Novell Support Forums Volunteer Sysop

Novell does not officially monitor these forums.

Suggestions/Opinions/Statements made by me are solely my own.
These thoughts may not be shared by either Novell or any rational human.

"rmyers1968" <rmyers1968@no-mx.forums.novell.com> wrote in message
news:rmyers1968.391xjb@no-mx.forums.novell.com...
>
> First off, a big thank you for all the great info. Less than 24 hours
> and 7 very insightful/helpful replies.
>
> Really appreciate the time you are taking. I have bolded the questions
> I have, so if you do not have time to read my lengthy post, you can
> hopefully give me a few answers to some questions, thanks in advance.
>
> As far as duplex mismatch, I think that Massimo's post makes sense, it
> would equally affect both protocols, so pretty sure I can rule that
> out.
>
> As far as dropped packets, or comm issues, on the switches I see 0
> dropped packets, 0 collisions and 0 errors on the switches. But I guess
> I should run a protocol analyzer on the PC, in case the switch is
> blocking things because of multicast filters, STP, or other.
>
> I am betting the switches are messing up things. I plan to place some
> dumb unmanaged switches to see if this makes a diff., that sounds like
> a worthwhile test.
>
> Q1: IF THE SERVERS REMAIN ON A MANAGED SWITCH AND I ADD A DUMB SWITCH
> WILL THAT BE ENOUGH, OR SHOULD I PLACE ONE OR MORE SERVERS ON THE DUMB
> SWITCH WITH THAT PC?
>
> As far name resolution issues, as far as server configs, given my
> environment of single subnet, no routers, no bridges, etc.
>
> Q2: IS THERE ANYTHING I HAVE TO CONFIGURE ON THE SERVER SIDE FOR NAMES
> RESOLUTION, GIVEN MY SIMPLE ENVIRONMENT, ASSUMING SWITCHES ARE NOT
> MESSING THINGS UP?
>
> We had setup a SLPDA on one server and modified the SLP.CFG on the
> other server to refer to the SLPDA. We added entry 78 to DHCP to
> provide SLPDA info to DHCP clients.
>
> Q3: IS THERE ANY USEFUL INFO I SHOULD LOOK AT IN SLPINFO.EXE /A THAT
> MIGHT CLUE ME IN ON ANYTHING WRONG?
>
> Q4: USING A PROTOCOL ANALYZER, SHOULD I BE FILTERING FOR SOME SPECIFIC
> PACKETS, IF SO WHICH ONES ARE OF GREATER INTEREST FOR MY IP NAME
> RESOLUTION ISSUES?
>
> Thanks again guys, really appreciate all the help.
>
>
> --
> rmyers1968
> ------------------------------------------------------------------------
> rmyers1968's Profile: http://forums.novell.com/member.php?userid=4275
> View this thread: http://forums.novell.com/showthread.php?t=326896
>



0 Likes
Knowledge Partner
Knowledge Partner

Re: Client TCPIP vs IPX issues

Hi,

rmyers1968 wrote:
> As far as duplex mismatch, I think that Massimo's post makes sense, it
> would equally affect both protocols, so pretty sure I can rule that
> out.


Actually, that isn't correct. TCP/IP is *much* more sensiive to Duplex
Mismatches for several reasons. First, it's timeouts and retries are
*much* slower by default, and on top it much more often sends and
receives "simultaneously" during file transfers, which means it has a
much higher potential to cause data loss on the wire) (which in a duplex
mismatch scenario happens only when both send and receive channek
transfer at the same time)

> As far as dropped packets, or comm issues, on the switches I see 0
> dropped packets, 0 collisions and 0 errors on the switches. But I guess
> I should run a protocol analyzer on the PC, in case the switch is
> blocking things because of multicast filters, STP, or other.


Probably. Packet loss can happen for a wide variaty of reasons, outside
of the switch.

> I am betting the switches are messing up things.


I wouldn't bet on it. There is a very high chance that you won't find a
problem at all.

> I plan to place some
> dumb unmanaged switches to see if this makes a diff., that sounds like
> a worthwhile test.


Can't hurt.

> Q1: IF THE SERVERS REMAIN ON A MANAGED SWITCH AND I ADD A DUMB SWITCH
> WILL THAT BE ENOUGH, OR SHOULD I PLACE ONE OR MORE SERVERS ON THE DUMB
> SWITCH WITH THAT PC?


The latter. *Adding* a switch will, if any, make the problem worse. To
find somethingm you need to replace the current one.


> We had setup a SLPDA on one server and modified the SLP.CFG on the
> other server to refer to the SLPDA. We added entry 78 to DHCP to
> provide SLPDA info to DHCP clients.


That should be enough, *if* it works properly. What does display slp da
on both servers, and slpinfo /d on the client show?

> Q4: USING A PROTOCOL ANALYZER, SHOULD I BE FILTERING FOR SOME SPECIFIC
> PACKETS, IF SO WHICH ONES ARE OF GREATER INTEREST FOR MY IP NAME
> RESOLUTION ISSUES?


Don't filter anything. Try to get a LAN trace from bootup until
succesfully completed login.

CU,
--
Massimo Rosen
Novell Product Support Forum Sysop
No emails please!
http://www.cfc-it.de
CU,
--
Massimo Rosen
Micro Focus Knowledge Partner
No emails please!
http://www.cfc-it.de
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.