Login issue "tree or server cannot be found"
osha...@mobitellanka.lk
initial login when attempt to login to Novell 5.1 server. The problem
began appearing when the novell server was restarted when it has gone up
to 8th a bend mode. However I have noticed similar issues before certain
times but not as frequently as after the server restart.
Our network consists of windows 2000 and XP clients. And novell client
versions are 4.85, 4.9 (basically all of the versions are 4.85 or above).
And clients with all sorts of “novell client” and windows versions are
affected with the problem (it’s hard to distinguish problem clients
by “novell client” version and “windows OS”). It has come to notice that
same set of client PC are affected with the earlier mentioned problem. The
rest of the client usually does not have any problems.
But these clients with the above login problem can successfully login to
the novell server after about 15 mins or so, after login to the system
locally (with local credentials). So far this has been the solution for
problem clients.
Our network is a pure IP network. PIX firewall is in between the client
and the server. But we have opened the entire port range. No major changes
are been done to the network during the time. Client use the same set of
software and service. Multicasting is disabled on the switches.
Bottom line
• Even after 15 min or so problem clients can login to the server
• It appears to be same set of clients experience the login problem
• We have tried entering IP to the server and tree boxes of login
window, but shows the same problem
• Even the UNC path authentication is not taken place for problem
clients
• Server seems functioning properly since authentication take place
for other clients
I have tried many configuration settings of the “novell client” but no
solution could be found. Same settings are reflected in client who login
successfully and not.
I would be grateful if anyone can help with this situation.
Thanks in advance.
Oshadha Ranaweera.
Hamish
Couple of things to try:
In the client properties, advanced settings, turn off the bad server
name cache.
Add a dependancy for SRVLOC to the client start up: To set the
dependency, edit
HKLM\System\CurrentControlSet\Services\NetWareWorkstation\DependOnService,
add SRVLOC as the dependency (use regedit.exe on XP, regedit32.exe on
W2K)- or just import this .reg file:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetwareWorkstation]
"DependOnService"=hex(7):53,00,52,00,56,00,4c,00,4f,00,43,00,00,00,00,00
--
Hamish Speirs
Novell Support Forums Volunteer Sysop.
(Please, no email unless requested. Unsolicited support emails will
probably be ignored)
iosh...@mobitellanka.com
these setting on the trouble clients. I need sometime to verify all the
clients with these new settings. Few things to add to the scenario.
We have total of 3 novell version 5.0 servers running directory service
(in a forest manner) and one of the servers were installed only to
troubleshoot the problem. (lets name the servers as S1, S2, S3). The
problem clients can successfully login to the other two servers (S2 and
S3) which are also running the directory service. The problem only appears
when particular set of client login to the particular novell server (S1).
But as I mentioned, the rest of the client can successfully login to the
S1 server.
This is a quite confusing situation. I will try your settings as soon as
possible. Saturday and Sunday are off days for our org. so I will get back
to you on Monday.
I appreciate your help a lot, I’m grateful if you could help me out with
the problem further.
Oshadha.
Hamish
> We have total of 3 novell version 5.0 servers running directory service
> (in a forest manner)
What do you mean by in a "forest manner"? Are all the servers in the
same tree, or seperae trees?
> and one of the servers were installed only to
> troubleshoot the problem. (lets name the servers as S1, S2, S3). The
> problem clients can successfully login to the other two servers (S2 and
> S3) which are also running the directory service. The problem only appears
> when particular set of client login to the particular novell server (S1).
Are there any difference between the PC's that login okay, and those
that don't? OS version, client version, network segment etc ?
osha...@mobitellanaka.com
Your questions were…
• With what do you mean by in a "forest manner"? Are all the servers
in the same tree, or separate trees?
Well these are separate trees. Basically stand along servers.
• Are there any difference between the PC's that login okay, and
those that don't? OS version, client version, network segment etc?
I tried to figure out some pattern but I was unable to. These “okay
clients” uses different OSs (XP and 2000) and different “Novell Client”
versions. We have a VLAN concept here and these problem clients are from
different VLANs…
And I did try your suggested settings on considerable amount of client and
it didn’t do much good.
The problem is quite hard to isolate, since the problem occurs with
particular set of clients for S1 server. But these clients can login to S2
and S3. And “okay clients” can login to S1 as well.
I have tried SLP related issues published on Novell site as well as
multicasting issue that could rise, but none of them gave positive
solution.
Is there any clue which you can isolate?
Thank you very much,
Oshadha.
Tony Pedretti
Sounds like you have some inconsistencies in your environment between versions
of Windows, the Novell Client, and which workstations are setup to use a
particular server. Any chance you'll be addressing that in the near future?
It would help in narrowing down the issue.
Is there anything consistent (ie. hardware, drivers, software, settings, etc.)
about the "affected" clients that is not present in the "okay" ones? And vice
versa?
Is using the tree command for connecting/mapping to other trees in a login
script an option?...
How Client32 attaches to multiple trees with users during login.
http://support.novell.com/cgi-bin/search/searchtid.cgi?/10022073.htm
--
Tony Pedretti
TransUnion LLC
osha...@mobitellanka.com
Well Tony the entire network worked just fine until recently the novell
Server (S1) was restarted. During that time no changers were made to
clients or the servers. And I was unable to discover any uniqueness in
these “problem clients”.
As I mentioned before, these problem client can login to novel server (S1)
after about 15min, subsequently to the login of local machines. So I find
this is an interesting point to start the troubleshooting. And during this
15min delay (problem clients to S1 server) these clients cannot find the
novell server using the UNC path.
At the same time…It is hard to isolate the problem since these
same “problem clients” can login to other 2 servers (S2 and S3)
successfully at any given time. Just to remind… there are other “okay
clients” that can login to S1, S2 and S3 servers anytime.
And connection/mapping is not done through S1 server to any other server
during the login process… but we do map drivers from the server that the
client is login.
I will try the documents that you have mentioned Tony…
Thanks a lot… hope you will be in touch.
Thanks again,
Oshadha.
Tony Pedretti
Which is it and what SP is applied on it?
Is the version of NDS installed on three server the same? Can you verify
regular maintenance is performed and NDS is in good shape?...
NDS Health Check Procedures - Cross Platform
http://support.novell.com/cgi-bin/search/searchtid.cgi?/10060600.htm
SLP is the default and preferred method of name resolution on NetWare 5.0 and
above over IP. Do you have it configured on both NetWare and the clients to
resolve names using it?
If so masking any info. you might consider a security hazard, can you post the
contents of SLPINFO /ALL run from the command-prompt on these workstations?
Both the problem and okay ones.
Try toggling Bad Server Name Cache, IP Address costing and UNC Path Filter
driver in the client's properties...
AppNote: Novell Client 4.9 SP2 : Initialization, Login and Settings
http://www.novell.com/coolsolutions/netware/features/a_novell_client_49sp2_2_nw.html
osha...@mobitellanka.com
Sorry that I have mention 5.1. Its 5.0 with service pack 6a. All the three
servers are version 5.0 with SP 6a.
NDS version is same in all the 3 servers and NDS is in good health. Once
after any client is authenticated, the rules are applied perfectly. It’s
just the login long delay that causes the problem.
SLP in both server and client are configured to resolve the names
(settings were same as when the network was working okay). In fact I have
configured the “problem clients” to use the IP address instead of using
server name and tree name… these client did not work under these settings
either.
Tony is it possible to mail SLPINFO /ALL settings to your email? I can
then directly get a screenshot and send you. Actually the only difference
is that the “problem clients” sometimes have a multicasting IP address in
the “last addr out”. But “okay client” have the S1 server address.
Our switches does not allow multicasting. Anyhow with these switch
configurations the authentication worked perfectly.
I tried the bad server name cache = ON, IP costing = 2 and UNC path filter
= ON
These are the typical setting that the both okay and problem clients use.
Anyway all clients can login to S2 and S3 servers
I believe that the problem lies on the server side. Since no client was
modified during the time.
Thank you very much Troy, hope these info will help you.
Oshadha.
Tony Pedretti
puzzle, lets keep the exchanges out here in the forums and in text if possible.
You should able highlight the output from the command-prompt and copy/paste it
into your newsreader to post. Else pipe the output to a text file and then open
up the file to copy/paste...
slpinfo /all > slpinfo.txt
You mentioned your environment does not allow Active Discovery/Multicasting. In
that case, do you have a SLP DA setup on one of your servers so that NetWare
names can be resolved over IP?
You can then configure the clients to point to them manually, ZENworks (or
whatever workstation management method you might us) or via DHCP.
These two TIDs and the links within should give you more information to help you
out...
Configuring SLP with a SCOPED directory agent (DA)
http://support.novell.com/cgi-bin/search/searchtid.cgi?/10059981.htm
Configuring SLP for a NetWare Client
http://support.novell.com/cgi-bin/search/searchtid.cgi?/10014466.htm
You may also want to post in the NetWare forums if you continue to believe this
a server issue...
novell.support.netware.communications
osha...@mobitellanka.com
Yes, we have configured SLP DA in S1 server and configured to resolve
names. Workstations have also been configured manually to point to the
server.
I have already visited the two links you have mentioned Tony.
Well the slpinfo is as follows:
“okay client”
SLP Version: 1.0
SLP Start Time: 9:55:23am 11/2/2004
Last I/O: 10:43:12am 11/2/2004
Total Packets: Out: 447 In: 4
Total Bytes: Out: 33590 In: 450
SLP Operational Parameters Values
------------------------------- ------------
Static Scopes NO
Static Directory Agents YES
Active Discovery YES
Use Broadcast for SLP Multicast NO
Use DHCP for SLP YES
SLP Maximum Transmission Unit 1400 bytes
SLP Multicast Radius 32 hops
SLP Timers Values
------------------------------------- ------------
Give Up on Requests to SAs 15 seconds
Close Idle TCP Connections 5 minutes
Cache SLP Replies 1 minutes
SLP Default Registration Lifetime 10800 seconds
Wait Before Giving Up on DA 5 seconds
Wait Before Registering on Passive DA 1-2 seconds
Scope List Source(s)
---------------------------------------- ------------
<unscoped> DHCP,DA
DA IP Address Source(s) State Version Local
interface Interface Scope(s)
--------------- --------- ----- ------- ---------------
---------------------
192.168.2.46 CNFG NORSP ?
192.168.24.226 <unknown>
192.168.2.9 CNFG UP SLPV1
192.168.24.226 <unscoped>
Local Interface 192.168.24.189
---------------------------------
Operational State: UP
Operating Mode(s): MCAST,STATIC-DA
SA/UA Scopes: <unscoped>
Last I/O: 10:43:12am 11/2/2004
Total Packets: Out: 447 In: 4
Total Bytes: Out: 33590 In: 450
Last Addr Out: 192.168.2.9
Last Addr In: 192.168.2.9
“error client”
SLP Version: 1.0
SLP Start Time: 9:52:34am 11/2/2004
Last I/O: 10:42:42am 11/2/2004
Total Packets: Out: 288 In: 1
Total Bytes: Out: 20832 In: 55
SLP Operational Parameters Values
------------------------------- ------------
Static Scopes NO
Static Directory Agents YES
Active Discovery YES
Use Broadcast for SLP Multicast NO
Use DHCP for SLP YES
SLP Maximum Transmission Unit 1400 bytes
SLP Multicast Radius 32 hops
SLP Timers Values
------------------------------------- ------------
Give Up on Requests to SAs 15 seconds
Close Idle TCP Connections 5 minutes
Cache SLP Replies 1 minutes
SLP Default Registration Lifetime 10800 seconds
Wait Before Giving Up on DA 5 seconds
Wait Before Registering on Passive DA 1-2 seconds
Scope List Source(s)
---------------------------------------- ------------
<unscoped> DHCP
DA IP Address Source(s) State Version Local
interface Interface Scope(s)
--------------- --------- ----- ------- ---------------
---------------------
192.168.2.46 CNFG NORSP ?
192.168.24.226 <unknown>
192.168.2.9 CNFG UP SLPV1
192.168.24.226 <unscoped>
Local Interface 192.168.24.189
---------------------------------
Operational State: UP
Operating Mode(s): MCAST,STATIC-DA
SA/UA Scopes: <unscoped>
Last I/O: 10:42:42am 11/2/2004
Total Packets: Out: 228 In: 1
Total Bytes: Out: 20832 In: 55
Last Addr Out: 224.0.1.22
Last Addr In: 192.168.2.9
Hope you’ll be able to find some clue… I have tried many different setting
on client side other than the setting shown in skpinfo… but not luck.
Thanks again Tony,
Oshadha.
Tony Pedretti
Note the two fields "Last Addr Out" and "Last Addr In" in your output match your working
SLP DA on the okay client, but on the error client not only don't they match but appear to
be going out to a different network.
What service does 224.0.1.22 provide to your clients? I see DNS resolving it to
SVRLOC.MCAST.NET.
Could this be some sort of routing issue with how your clients' Windows TCP/IP is
configured?
Try disabling SLP Active Discovery in the client's properties Advanced Settings tab?
You may also want to take a look at 192.168.2.46 and see why your clients are not getting
a response from it.
Tony Pedretti
TransUnion LLC
Peter
Why "Local Interface" does not match within a client?
192.168.24.226 vs 192.168.24.189 ?
Why "okay client" and "error client" have the same Local Interface IP
addresses?
You should have only one static DA (192.168.2.9) in Service Location
setting.
Is S1 having that IP address?
<osha...@mobitellanka.com> wrote in message
news:GLFhd.8969$%e6....@prv-forum2.provo.novell.com...
> Hope you'll be able to find some clue. I have tried many different setting
> on client side other than the setting shown in skpinfo. but not luck.
>
> Thanks again Tony,
> Oshadha.
>
Peter
Disabling SLP Active Discovery in the client's properties Advanced Settings
tab will turn multicasting off.
Maybe 192.168.2.46 does not run SLPDA...?
"Tony Pedretti" <yno...@NOSPAMhotmail.com> wrote in message
news:VfRhd.295$jR3...@prv-forum2.provo.novell.com...
osha...@mobitellanka.lk
Yea, last address out is a multicasting address. Yes, I have tried turning
off the active discovery option in the clients. But that didn’t do any
good. I have basically tried unicasting for the server switching off all
the multicasting options. (but “okay clients” work with multicasting
settings enable).
I apologies… this is the same client (192.168.24.226). These settings were
taken by “print screen” option by a client and I have typed the info in a
txt. It is my typing mistake.
But as I mentioned earlier in the thread, these error clients can login to
the S1 server (192.168.2.9) after about 15 min or so. So this particular
client can login to the server after about 10 min. so I have sent u the
two states of SLPINFO / ALL of the same client when he can login and
cannot login. However all error clients display same set of information.
So the information I sent is correct.
And I have configured 192.168.2.9 (S1) as the service location IP for the
clients.
Note: client settings of the all clients can be considered similar. So I
believe that this isn’t a client side issue. I also have noted that the
issue is spreading across the clients. But there are “okay clients” in
same network segments where error clients reside. The point where I argue
is why error clients can login to server S1 after 15 mins or so. But these
error clients do login to S2 or S3 anytime.
Peter/Tony, I have tried all possible client setting combinations on both
okay and error clients. I believe that client settings don’t have much
effect on this issue. Because client settings were untouched over long
time.
But could this be any virus or network communication error? Because during
the login delay, these error clients do not connect S1 through UNC either.
I appreciate your help a lot, hope your all be in touch.
Thank you.
Oshadha.
Peter
Try to use only one DA in Service Location on Novell Client (I have seen
also "192.168.2.46 CNFG NORSP" in your report).
Now, something intermittently blocks network access to that server (S1).
That could be Novell Client itself. Without going much into detail, please
disable two "bad cache" features:
1. Bad Server Name Cache Enabled - set to Off in Advanced Settings
2. Bad Address Cache Timeout- set to zero in Advanced Settings
Reboot client and retest.
I assumed that you have used NC4.90SP2:
http://support.novell.com/cgi-bin/search/searchtid.cgi?/10095000.htm
If not, you have to apply a reghack for Bad Address Cache Timeout.
<osha...@mobitellanka.lk> wrote in message
news:cSYhd.744$jR3...@prv-forum2.provo.novell.com...
> Thanks for replying Tony, Peter
>
> Yea, last address out is a multicasting address. Yes, I have tried turning
> off the active discovery option in the clients. But that didn't do any
> good. I have basically tried unicasting for the server switching off all
> the multicasting options. (but "okay clients" work with multicasting
> settings enable).
>
> I apologies. this is the same client (192.168.24.226). These settings were
osha...@mobitellanka.com
the same delay. And I’m login to only one server (S1). I removed the other
servers from the client.
Do u expect to try a step subsequently Peter?
Thanks a lot,
Oshadha
Peter
listing:
CONFIG
DISPLAY SLPDA
DISPLAY SLP SERVICES
What happens during logon if client has Tree specified, Context specified
and Server: 192.168.2.9 in Advanced Tab? Is it still a delay?
<osha...@mobitellanka.com> wrote in message
news:H74id.894$jR3...@prv-forum2.provo.novell.com...
Allen Platt
M.I.S.
1624 West Adams
Phoenix, Arizona 85007-2631
Email: apl...@azdjc.gov
Phone: 602-542-0289
Fax: 602-542-2114
Allen Platt
Your current context is CENTRAL.PHOENIX.AZ_DYTR
User: JLindell Context: CENTRAL.PHOENIX.AZ_DYTR
Your current tree is: DYTR_NDS
You are attached to server ADJC-PHX.
YOUR PASSWORD EXPIRES IN 17 DAYS.
SUBNET: 0AC86673
YOU ARE CURRENTLY LOGGED ON IN CENTRALOFFICE
ZENSVR: ADJC-ZEN
EXECUTING SCRIPT FOR CENTRAL OFFICE STAFF....
Authenticating to server ADJC-CO1.
LOGIN-LGNWNT32.DLL-430: The following drive mapping operation could not be completed.
[INS S1:=ADJC-CO1\SYS:\LOGIN\NAV]
The error code was 886f.
LOGIN-LGNWNT32.DLL-740: This utility could not execute external program OSVER.
LOGIN-LGNWNT32.DLL-740: This utility could not execute external program \\ADJC-CO1\SYS\LOGIN\NAV\OSVER.
LOGIN-LGNWNT32.DLL-740: This utility could not execute external program VP_Log32.
LOGIN-LGNWNT32.DLL-470: The specified drive mapping is an invalid path:
(DEL S1:)
LOGIN-LGNWNT32.DLL-430: The following drive mapping operation could not be completed.
[INS S1:=ADJC-CO1/SYS:PUBLIC]
The error code was 886f.
LOGIN-LGNWNT32.DLL-430: The following drive mapping operation could not be completed.
[INS S2:=ADJC-CO1/PGM:]
The error code was 886f.
LOGIN-LGNWNT32.DLL-430: The following drive mapping operation could not be completed.
[H:=ADJC-CO1/USR:]
The error code was 886f.
LOGIN-LGNWNT32.DLL-430: The following drive mapping operation could not be completed.
[X:=ADJC-CO1/PGM:]
The error code was 886f.
LOGIN-LGNWNT32.DLL-250: This utility was unable to set the default drive to drive H:.
*****************************************************
*** Novell Client for Windows NT ***
*** Service Location Diagnostics ***
*****************************************************
SLP Start Time: 11:48:17am 11/3/2004
Last I/O: 11:50:48am 11/3/2004
Total Packets: Out: 135 In: 113
Total Bytes: Out: 14306 In: 54453
SLP Operational Parameters Values
------------------------------- ------------
Static Scopes NO
Active Discovery YES
Use Broadcast for SLP Multicast NO
Use DHCP for SLP YES
SLP Maximum Transmission Unit 1400 bytes
SLP Timers Values
------------------------------------- ------------
Give Up on Requests to SAs 15 seconds
Close Idle TCP Connections 5 minutes
Cache SLP Replies 1 minutes
SLP Default Registration Lifetime 10800 seconds
Wait Before Giving Up on DA 5 seconds
Wait Before Registering on Passive DA 1-2 seconds
Scope List Source(s)
---------------------------------------- ------------
<unscoped>
DA IP Address Source(s) State Version Local Interface Scope(s)
--------------- --------- ----- ------- --------------- ---------------
ADJC-MA
Local Interface 10.200.102.115
---------------------------------
Operational State: UP
Operating Mode(s): MCAST,STATIC-DA
Last I/O: 11:50:48am 11/3/2004
Total Packets: Out: 135 In: 113
Total Bytes: Out: 14306 In: 54453
Last Addr Out: XXX.XX.32.230
Last Addr In: XXX.XX.32.230
Peter
"Allen Platt" <APl...@dj.state.az.us> wrote in message news:3Y9id.1306$jR3...@prv-forum2.provo.novell.com...
osha...@mobitellanka.com
Well I believe what Allen Platt has is a different problem. Because in his
case he can contact the novell server, only when the login process is
executing he gets the error. This is probably something to do with the
login script error or something similar.
In my case I’m unable to even contact the server for the authentication
process. I cannot brows the S1 server using UNC path during the delay
period.
Peter I have the server side information u have requested. Hope the
information is I have is clear enough. And we currently do not have SLP
scope defined, but clients were able to login to the server with out a
scope specified, before the login problem occurs.
The info u request is as follows:
Thnaks a lot for your help.
File server name: COBRA
IPX internal network number: 0AFF1E9D
Server Up Time: 19 Hours 57 Seconds
AMD PCNTNW
Version 4.18 5 January 2000
Hardware setting: Slot 10005, I/O ports 2180h to 219Fh, Interrupt Ah
Node address: 00062939DB3B
Frame type: ETHERNET_II
Board name: PCNTNW_1_EII
LAN protocol: ARP
LAN protocol: IP Addr:192.168.2.9 Mask:255.255.255.0
Compatibility Mode Driver 28Jul2000
Version 5.21i 28 July 2000
Hardware setting: I/O Port A55h
Node address: 7E01C0A80209
Frame type: CMD
Board name: CMD Server
LAN protocol: IPX network FFFFFFFD
Tree Name: COBRA_TREE
Bindery Context(s):
COBRA:display slp da
SLP LOOPBACK ADDRESS : ACTIVE : 'UNSCOPED DA' : IANA : 0 ms
COBRA:
.COBRA_ORG
ARCserve.CA timesync.novell rconsole.novell srs.novell
nwserver.novell bin
dery.novell ndap.novell smdr.novell
sapsrv.novell
service:ARCserve.CA:///MOBCANO_NS4
service:timesync.novell://192.168.2.9
service:timesync.novell://192.168.2.2
service:rconsole.novell:///192.168.2.9:2034;cobra
service:rconsole.novell:///192.168.2.2:2034;MOBCANO_NS4
service:srs.novell://192.168.2.9:51723
service:srs.novell://192.168.2.2:51723
service:nwserver.novell:///COBRA
service:nwserver.novell:///MOBCANO_NS4
service:bindery.novell:///COBRA
service:bindery.novell:///MOBCANO_NS4
service:ndap.novell:///COBRA_TREE.
service:ndap.novell:///CANO_TREE.
service:smdr.novell://192.168.2.2:413/MOBCANO_NS4
service:smdr.novell://192.168.2.9:413/COBRA
service:sapsrv.novell:/ipx/0aff1e9d:000000000001:8059/004b/c0a80209/c0a8020
0/B
SER4.00-
7.00_0AFF1E9D0000000000010000
service:sapsrv.novell:/ipx/0aff1e9d:000000000001:0451/0004/c0a80209/c0a8020
0/C
OBRA
service:sapsrv.novell:/ipx/0aff1e9d:000000000001:90b4/8202/c0a80209/c0a8020
0/C
OBRA_BROKER
OBRA_TREE______________________J•÷pI@@@@@DàPJ
service:sapsrv.novell:/ipx/0a8d458e:000000000001:0451/0004/c0a80202/c0a8020
0/M
OBCANO_NS4
service:sapsrv.novell:/ipx/0a8d458e:000000000001:4068/08cb/c0a80202/c0a8020
0/C
HY_OFA_MLYXI-Y14XW-XH9HY-
I7@MOBCANO_NS4
service:sapsrv.novell:/ipx/0a8d458e:000000000001:0010/026b/c0a80202/c0a8020
0/C
ANO_TREE_______________________JZVfH@@@@@DàPJ
service:sapsrv.novell:/ipx/0a8d458e:000000000001:90b4/8202/c0a80202/c0a8020
0/M
OBCANO_NS4_BROKER
service:sapsrv.novell:/ipx/0a8d458e:000000000001:907b/023f/c0a80202/c0a8020
0/M
OBCANO_NS4
service:sapsrv.novell:/ipx/0a8d458e:000000000001:0000/0077/c0a80202/c0a8020
0/T
S@MOBCANO_NS4
service:sapsrv.novell:/ipx/0a8d458e:000000000001:0640/0278/c0a80202/c0a8020
0/C
ANO_TREE_______________________JZVfH@@@@@DàPJ
service:sapsrv.novell:/ipx/0aff1e9d:000000000001:907b/023f/c0a80209/c0a8020
0/C
OBRA
service:sapsrv.novell:/ipx/0aff1e9d:000000000001:0640/0278/c0a80209/c0a8020
0/C
OBRA_TREE______________________J•÷pI@@@@@DàPJ
service:sapsrv.novell:/ipx/0aff1e9d:000000000001:4023/08cb/c0a80209/c0a8020
0/C
HY_OFA_MLYXI-Y14XW-XH9HY-I7@COBRA
Peter
Compatibility Mode there.
You have two servers in two separate trees on the same network segment. What
other server (MOBCANO_NS4) shows in DISPLAY SLP SERVICES?
Is your S1 server name is COBRA? You have mentioned three servers, I can see
only two. What is the third server name and IP address and how S1, S2, S3
map to real server names?
I did not ask you to browse for S1 server after boot.
I have asked you to login directly to S1 using its IP address in the
"Server:" field (after clicking on Advanced Tab). Can you do that, please?
<osha...@mobitellanka.com> wrote in message
news:LAmid.1848$jR3...@prv-forum2.provo.novell.com...
> OBRA_TREE______________________J.÷pI@@@@@DąPJ
>
>
>
service:sapsrv.novell:/ipx/0a8d458e:000000000001:0451/0004/c0a80202/c0a8020
> 0/M
> OBCANO_NS4
>
>
>
service:sapsrv.novell:/ipx/0a8d458e:000000000001:4068/08cb/c0a80202/c0a8020
> 0/C
> HY_OFA_MLYXI-Y14XW-XH9HY-
> I7@MOBCANO_NS4
>
>
service:sapsrv.novell:/ipx/0a8d458e:000000000001:0010/026b/c0a80202/c0a8020
> 0/C
> ANO_TREE_______________________JZVfH@@@@@DąPJ
>
>
>
service:sapsrv.novell:/ipx/0a8d458e:000000000001:90b4/8202/c0a80202/c0a8020
> 0/M
> OBCANO_NS4_BROKER
>
>
>
service:sapsrv.novell:/ipx/0a8d458e:000000000001:907b/023f/c0a80202/c0a8020
> 0/M
> OBCANO_NS4
>
>
>
service:sapsrv.novell:/ipx/0a8d458e:000000000001:0000/0077/c0a80202/c0a8020
> 0/T
> S@MOBCANO_NS4
>
>
>
service:sapsrv.novell:/ipx/0a8d458e:000000000001:0640/0278/c0a80202/c0a8020
> 0/C
> ANO_TREE_______________________JZVfH@@@@@DąPJ
>
>
>
service:sapsrv.novell:/ipx/0aff1e9d:000000000001:907b/023f/c0a80209/c0a8020
> 0/C
> OBRA
>
>
>
service:sapsrv.novell:/ipx/0aff1e9d:000000000001:0640/0278/c0a80209/c0a8020
> 0/C
> OBRA_TREE______________________J.÷pI@@@@@DąPJ
Allen Platt
service:lanz.novell://10.200.100.20:161/NLAv1.30+ADJC-ZEN
service:bindery.novell:///ADJC-ZEN
service:bindery.novell:///ADJC-MAS
service:ndap.novell:///AZ_DYTR.DYTR_NDS.
service:ndap.novell:///DYTR_NDS.
service:ndap.novell:///CENTRAL.PHOENIX.AZ_DYTR.DYTR_NDS.
service:ndap.novell:///MESA.PAROLE.AZ_DYTR.DYTR_NDS.
service:ndap.novell:///SOUTH.PAROLE.AZ_DYTR.DYTR_NDS.
service:ndap.novell:///TUCSON.PAROLE.AZ_DYTR.DYTR_NDS.
service:ndap.novell:///EPS.INST.AZ_DYTR.DYTR_NDS.
service:ndap.novell:///PHX.INST.AZ_DYTR.DYTR_NDS.
service:ndap.novell:///CMS.INST.AZ_DYTR.DYTR_NDS.
service:ndap.novell:///NORTHWEST.PAROLE.AZ_DYTR.DYTR_NDS.
afp://10.200.120.11/?NAME=ADJC-PHX
afp://10.200.100.20/?NAME=ADJC-ZEN
service:nwserver.novell:///ADJC-MAS
service:nwserver.novell:///ADJC-PHX
service:nlsmeter.novell://159.87.32.230:21571/ADJC-MAS
service:nlsmeter.novell://10.200.120.11:21571/ADJC-PHX
service:nlsmeter.novell://10.200.100.20:21571/ADJC-ZEN
service:smdr.novell://10.200.120.11:413/ADJC-PHX
service:smdr.novell://XXX.XX.32.230:413/ADJC-MAS
service:portal.novell://ADJC-MAS.azdjc.gov:8008/ADJC-MAS
service:portal.novell://ADJC-PHX.azdjc.gov:8008/ADJC-PHX
service:portal.novell://ADJC-ZEN.azdjc.gov:8008/ADJC-ZEN
service:sapsrv.novell:/ipx/9f57200b:000000000001:4007/08cb/9f5720e6/9f5720e0/C
HY_OFA_LCLTI-Y14XW-CH9KX-R7@ADJC-MAS
service:sapsrv.novell:/ipx/9f571420:000000000001:8059/004b/00000000/00000000/B
SER4.00-7.00_9F5714200000000000010000
service:sapsrv.novell:/ipx/9f57200b:000000000001:0451/0004/9f5720e6/9f5720e0/A
DJC-MAS
service:sapsrv.novell:/ipx/9f57200b:000000000001:0000/027b/9f5720e6/9f5720e0/A
DJC-MAS
service:sapsrv.novell:/ipx/9f57200b:000000000001:805a/004b/9f5720e6/9f5720e0/A
DJC-MAS
service:sapsrv.novell:/ipx/9f57200b:000000000001:8059/004b/9f5720e6/9f5720e0/B
SER4.00-7.00_9F57200B0000000000010000
service:sapsrv.novell:/ipx/9f572011:000000000001:0451/0004/0ac86414/0ac86400/A
DJC-ZEN
service:sapsrv.novell:/ipx/9f572011:000000000001:8059/004b/0ac86414/0ac86400/B
SER4.00-7.00_9F5720110000000000010000
service:sapsrv.novell:/ipx/9f572011:000000000001:0000/027b/0ac86414/0ac86400/A
DJC-ZEN
service:sapsrv.novell:/ipx/9f572011:000000000001:0000/027b/0ac86414/0ac86400/A
DJC-ZEN
service:sapsrv.novell:/ipx/9f572011:000000000001:0000/023a/0ac86414/0ac86400/A
DJC-ZEN
service:sapsrv.novell:/ipx/9f571420:000000000001:0451/0004/00000000/00000000/A
DJC-PHX
service:sapsrv.novell:/ipx/9f571420:000000000001:8059/004b/00000000/00000000/B
SER4.00-7.00_000000000100000000000000
service:sapsrv.novell:/ipx/9f571420:000000000001:805a/004b/00000000/00000000/A
DJC-PHX
service:sapsrv.novell:/ipx/9f572011:000000000001:4009/08cb/0ac86414/0ac86400/C
HY_OFA_CMMXI-Y14XW-XW9MY-I7@ADJC-ZEN
service:sapsrv.novell:/ipx/9f572011:000000000001:401f/0293/0ac86414/0ac86400/A
DJC-ZEN
service:sapsrv.novell:/ipx/9f571420:000000000001:4015/08cb/00000000/00000000/C
HY_OFA_LHYXI-Y14XW-XW9MY-I7@ADJC-PHX
service:sapsrv.novell:/ipx/9f571420:000000000001:1740/0278/00000000/00000000/D
YTR_NDS________________________äö¦@B@
service:sapsrv.novell:/ipx/9f571420:000000000001:4024/0293/00000000/00000000/A
DJC-PHX
service:sapsrv.novell:/ipx/9f57200b:000000000001:4007/08cb/9f5720e6/9f5720e0/C
HY_OFA_CMMXI-Y14XW-XW9MY-I7@ADJC-MAS
service:sapsrv.novell:/ipx/9f57200b:000000000001:0f40/0278/9f5720e6/9f5720e0/D
YTR_NDS________________________äöA+@@
service:sapsrv.novell:/ipx/9f57200b:000000000001:0f40/0278/9f5720e6/9f5720e0/D
YTR_NDS________________________äöA+@@
service:sapsrv.novell:/ipx/9f57200b:000000000001:4011/0293/9f5720e6/9f5720e0/A
DJC-MAS
Displayed 47 of 47 Total URL's for:
"(All)/(default)/(Not specified)"
ADJC-CO1 SLP Info:
Searching Network . . .
service:bindery.novell:///ADJC-CO1
service:bindery.novell:///ADJC-EML
service:bindery.novell:///ADJC-TP2
service:bindery.novell:///ADJC-ZEN
service:bindery.novell:///ADJC-MAS
service:bindery.novell:///ADJC-WML
service:ndap.novell:///CENTRAL.PHOENIX.AZ_DYTR.DYTR_NDS.
service:ndap.novell:///MESA.PAROLE.AZ_DYTR.DYTR_NDS.
service:ndap.novell:///SOUTH.PAROLE.AZ_DYTR.DYTR_NDS.
service:ndap.novell:///TUCSON.PAROLE.AZ_DYTR.DYTR_NDS.
service:ndap.novell:///EPS.INST.AZ_DYTR.DYTR_NDS.
service:ndap.novell:///PHX.INST.AZ_DYTR.DYTR_NDS.
service:ndap.novell:///CMS.INST.AZ_DYTR.DYTR_NDS.
service:ndap.novell:///NORTHWEST.PAROLE.AZ_DYTR.DYTR_NDS.
service:ndap.novell:///AZ_DYTR.DYTR_NDS.
service:ndap.novell:///DYTR_NDS.
service:portal.novell://ADJC-EML.azdjc.gov:8008/ADJC-EML
service:portal.novell://ADJC-CO1.azdjc.gov:8008/ADJC-CO1
service:portal.novell://ADJC-MAS.azdjc.gov:8008/ADJC-MAS
service:portal.novell://ADJC-PHX.azdjc.gov:8008/ADJC-PHX
service:portal.novell://ADJC-ZEN.azdjc.gov:8008/ADJC-ZEN
service:portal.novell://ADJC-WML.azdjc.gov:8008/ADJC-WML
service:smdr.novell://10.200.100.13:413/ADJC-CO1
service:smdr.novell://10.200.100.21:413/ADJC-TP2
service:smdr.novell://10.200.120.11:413/ADJC-PHX
service:smdr.novell://XXX.XX.32.230:413/ADJC-MAS
service:smdr.novell://192.168.234.235:413/ADJC-WML
service:rconsole.novell:///10.200.100.13:1064;ADJC-CO1.azdjc.gov
service:rconsole.novell:///10.200.100.21:2034;ADJC-TP2.DJ.STATE.AZ.US
service:nlsmeter.novell://10.200.100.13:21571/ADJC-CO1
service:nlsmeter.novell://10.200.100.14:21571/ADJC-EML
service:nlsmeter.novell://XXX.XX.32.250:21571/ADJC-WML
service:nlsmeter.novell://XXX.XX.32.230:21571/ADJC-MAS
service:nlsmeter.novell://10.200.120.11:21571/ADJC-PHX
service:nlsmeter.novell://10.200.100.20:21571/ADJC-ZEN
service:sapsrv.novell:/ipx/9f572080:000000000001:0451/0004/00000000/00000000/A
DJC-EML
service:sapsrv.novell:/ipx/9f572080:000000000001:4009/08cb/00000000/00000000/C
HY_OFA_LHYXI-Y14XW-XW9MY-I7@ADJC-EML
service:sapsrv.novell:/ipx/9f572080:000000000001:8059/004b/00000000/00000000/B
SER4.00-7.00_9F5720800000000000010000
service:sapsrv.novell:/ipx/9f572080:000000000001:805a/004b/00000000/00000000/A
DJC-EML
service:sapsrv.novell:/ipx/9f572080:000000000001:4013/0293/00000000/00000000/A
DJC-EML
service:sapsrv.novell:/ipx/04902810:000000000001:0451/0004/9f5720f8/9f5720e0/A
DJC-WML
service:sapsrv.novell:/ipx/04902810:000000000001:4009/08cb/9f5720f8/9f5720e0/C
HY_OFA_LHYXI-Y14XW-XW9MY-I7@ADJC-WML
service:sapsrv.novell:/ipx/04902810:000000000001:8059/004b/9f5720f8/9f5720e0/B
SER4.00-7.00_000000000100000000000000
service:sapsrv.novell:/ipx/04902810:000000000001:805a/004b/9f5720f8/9f5720e0/A
DJC-WML
service:sapsrv.novell:/ipx/04902810:000000000001:4018/0293/9f5720f8/9f5720e0/A
DJC-WML
service:sapsrv.novell:/ipx/9f57200b:000000000001:4007/08cb/9f5720e6/9f5720e0/C
HY_OFA_LCLTI-Y14XW-CH9KX-R7@ADJC-MAS
service:sapsrv.novell:/ipx/9f571420:000000000001:8059/004b/00000000/00000000/B
SER4.00-7.00_9F5714200000000000010000
service:sapsrv.novell:/ipx/9f57200b:000000000001:0451/0004/9f5720e6/9f5720e0/A
DJC-MAS
service:sapsrv.novell:/ipx/9f57200b:000000000001:0000/027b/9f5720e6/9f5720e0/A
DJC-MAS
service:sapsrv.novell:/ipx/9f57200b:000000000001:805a/004b/9f5720e6/9f5720e0/A
DJC-MAS
service:sapsrv.novell:/ipx/9f57200b:000000000001:8059/004b/9f5720e6/9f5720e0/B
SER4.00-7.00_9F57200B0000000000010000
service:sapsrv.novell:/ipx/9f572011:000000000001:0451/0004/0ac86414/0ac86400/A
DJC-ZEN
service:sapsrv.novell:/ipx/9f572011:000000000001:805a/004b/0ac86414/0ac86400/A
DJC-ZEN
service:sapsrv.novell:/ipx/9f572011:000000000001:8059/004b/0ac86414/0ac86400/B
SER4.00-7.00_9F5720110000000000010000
service:sapsrv.novell:/ipx/9f572011:000000000001:0000/027b/0ac86414/0ac86400/A
DJC-ZEN
service:sapsrv.novell:/ipx/9f572011:000000000001:0000/023a/0ac86414/0ac86400/A
DJC-ZEN
service:sapsrv.novell:/ipx/9f571420:000000000001:0451/0004/00000000/00000000/A
DJC-PHX
service:sapsrv.novell:/ipx/9f571420:000000000001:8059/004b/00000000/00000000/B
SER4.00-7.00_000000000100000000000000
service:sapsrv.novell:/ipx/9f571420:000000000001:805a/004b/00000000/00000000/A
DJC-PHX
service:sapsrv.novell:/ipx/9f572011:000000000001:4009/08cb/0ac86414/0ac86400/C
HY_OFA_CMMXI-Y14XW-XW9MY-I7@ADJC-ZEN
service:sapsrv.novell:/ipx/9f572011:000000000001:401f/0293/0ac86414/0ac86400/A
DJC-ZEN
service:sapsrv.novell:/ipx/9f571420:000000000001:4015/08cb/00000000/00000000/C
HY_OFA_LHYXI-Y14XW-XW9MY-I7@ADJC-PHX
service:sapsrv.novell:/ipx/9f571420:000000000001:1740/0278/00000000/00000000/D
YTR_NDS________________________äö¦@B@
service:sapsrv.novell:/ipx/9f571420:000000000001:4024/0293/00000000/00000000/A
DJC-PHX
service:sapsrv.novell:/ipx/9f57200b:000000000001:4007/08cb/9f5720e6/9f5720e0/C
HY_OFA_CMMXI-Y14XW-XW9MY-I7@ADJC-MAS
service:sapsrv.novell:/ipx/9f57200b:000000000001:0f40/0278/9f5720e6/9f5720e0/D
YTR_NDS________________________äöA+@@
service:sapsrv.novell:/ipx/9f57200b:000000000001:4011/0293/9f5720e6/9f5720e0/A
DJC-MAS
service:nwserver.novell:///ADJC-EML
service:nwserver.novell:///ADJC-TP2
service:nwserver.novell:///ADJC-MAS
service:nwserver.novell:///ADJC-PHX
service:nwserver.novell:///ADJC-WML
service:lanz.novell://10.200.100.20:161/NLAv1.30+ADJC-ZEN
afp://10.200.120.11/?NAME=ADJC-PHX
afp://10.200.100.20/?NAME=ADJC-ZEN
service:ndap.novell:///ADJC-EDU.
Displayed 76 of 76 Total URL's for:
"(All)/(default)/(Not specified)"
Allen Platt
> "Bad Name Cache Enabled" to 0
> "BadAddressCacheTimeout" to 0
> "Bad Name Cache Timeout" to 0
>
> with a reg file like this
>
> REGEDIT4
>
> [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetwareWorkstation\Parameters]
>
> "Bad Name Cache Enabled"=dword:00000000
> "BadAddressCacheTimeout"=dword:00000000
> "Bad Name Cache Timeout"=dword:00000000
>
>
>
> these keys solve the problem in all cases
Peter
"Allen Platt" <APl...@dj.state.az.us> wrote in message news:6usid.2122$jR3....@prv-forum2.provo.novell.com...
osha...@mobitellanka.com
We used IPX previously, then for IP compatibility we used the compatible
mode. But now we do not use IPX at all. Even the clients are now
configured to use IP only option. Even the new firewall (PIX) between the
novell servers and clients does not allow IPX. Peter, will there be any
effect removing compatible mode from the server?
Note: presently okay clients work with current configurations.
We currently have only 2 servers in the 192.168.2.xxx segment. S1
(192.168.2.9) = cobra / S2 (192.168.2.2) = cano. S3 I mentioned is setup
for testing purposes just because of this issue. Now we have removed that
server.
I have tried login many times in different machines with the IP address in
the server box in the login window. For problem client it didn’t work
either.
Here is the cano server DISPLAY SLP SERVICES
Thanks Peter,
MOBCANO_NS4:display slp das
192.168.2.9 : ACTIVE : 'UNSCOPED DA' : STATIC : 36 ms
MOBCANO_NS4:display slp services
OBRA_TREE______________________J•÷pI@@@@@DàPJ
service:sapsrv.novell:/ipx/0a8d458e:000000000001:0451/0004/c0a80202/c0a8020
0/M
OBCANO_NS4
service:sapsrv.novell:/ipx/0a8d458e:000000000001:4068/08cb/c0a80202/c0a8020
0/C
HY_OFA_MLYXI-Y14XW-XH9HY-
I7@MOBCANO_NS4
service:sapsrv.novell:/ipx/0a8d458e:000000000001:0010/026b/c0a80202/c0a8020
0/C
ANO_TREE_______________________JZVfH@@@@@DàPJ
service:sapsrv.novell:/ipx/0a8d458e:000000000001:90b4/8202/c0a80202/c0a8020
0/M
OBCANO_NS4_BROKER
service:sapsrv.novell:/ipx/0a8d458e:000000000001:907b/023f/c0a80202/c0a8020
0/M
OBCANO_NS4
service:sapsrv.novell:/ipx/0a8d458e:000000000001:0000/0077/c0a80202/c0a8020
0/T
S@MOBCANO_NS4
service:sapsrv.novell:/ipx/0a8d458e:000000000001:0640/0278/c0a80202/c0a8020
0/C
ANO_TREE_______________________JZVfH@@@@@DàPJ
service:sapsrv.novell:/ipx/0aff1e9d:000000000001:907b/023f/c0a80209/c0a8020
0/C
OBRA
service:sapsrv.novell:/ipx/0aff1e9d:000000000001:0640/0278/c0a80209/c0a8020
0/C
OBRA_TREE______________________J•÷pI@@@@@DàPJ
service:sapsrv.novell:/ipx/0aff1e9d:000000000001:4023/08cb/c0a80209/c0a8020
0/C
HY_OFA_MLYXI-Y14XW-XH9HY-
I7@COBRA
Displayed 30 URL's.
Peter
Your servers are fine.
Well, if you have tried already without success:
1. Bad Server Name Cache Enabled - set to Off in Advanced Settings
2. Bad Address Cache Timeout- set to zero in Advanced Settings
Do your clients have ZfD agents installed?
<osha...@mobitellanka.com> wrote in message
news:GICid.2753$jR3....@prv-forum2.provo.novell.com...
> OBRA_TREE______________________J.÷pI@@@@@DàPJ
> OBRA_TREE______________________J.÷pI@@@@@DàPJ
Peter
Is the "okay client" and "error client" connecting from the same subnet? Can
you send again a recent copy of a SLPINFO /A output from "okay" and "error"
clients (they were some typo's last time you did that)?
<osha...@mobitellanka.com> wrote in message
news:wvBjd.3992$jR3....@prv-forum2.provo.novell.com...
> Thanks for your reply Peter,
> Sorry for long delay in replying. Peter I cannot find a clue for this
> login issue either. I have tried almost everything that I could think of.
> Bypassing PIX is not a solution because there are identical clients who
> can login to the server with out a problem.
> What is ZfD agent?
> Thanks a lot Peter,
> Oshadha.
>
>
Peter
Are both client desktops (okay and error) wired to the same network switch?
You may check for maximum MTU size from each of the clients.
<osha...@mobitellanka.com> wrote in message
news:igEjd.4024$jR3....@prv-forum2.provo.novell.com...
> Thank for that fast reply Peter,
>
> Yes, both error and okay clients connect from same subnets. SLPINFO/A is
> shown below for both okay and error client. (This time I have taken the
> information the standard way).
>
> Thanks a lot peter. I appreciate your concern on this matter.
>
> Error client
> --------------------------------------------------------------------------
-
>
>
> SLP Version: 1.0
> SLP Start Time: 11:51:57am 11/8/2004
> Last I/O: 11:54:45am 11/8/2004
> Total Packets: Out: 21 In: 3
> Total Bytes: Out: 1214 In: 401
>
>
> SLP Operational Parameters Values
> ------------------------------- ------------
> Static Scopes NO
> Static Directory Agents YES
> Active Discovery NO
> Use Broadcast for SLP Multicast NO
> Use DHCP for SLP NO
> SLP Maximum Transmission Unit 1400 bytes
> SLP Multicast Radius 32 hops
>
>
> SLP Timers Values
> ------------------------------------- ------------
> Give Up on Requests to SAs 15 seconds
> Close Idle TCP Connections 5 minutes
> Cache SLP Replies 1 minutes
> SLP Default Registration Lifetime 10800 seconds
> Wait Before Giving Up on DA 100 seconds
> Wait Before Registering on Passive DA 1-50 seconds
>
>
> Scope List Source(s)
> ---------------------------------------- ------------
> <unscoped> DHCP,DA
>
>
> DA IP Address Source(s) State Version Local Interface Scope(s)
> --------------- --------- ----- ------- --------------- ---------
-
> -----
> 192.168.2.9 CNFG UP SLPV1 192.168.24.198
> <unscoped>
>
>
> Local Interface 192.168.24.198
> ---------------------------------
> Operational State: UP
> Operating Mode(s): STATIC-DA,NO-ACTIVE-DISCOVERY
> SA/UA Scopes: <unscoped>
> Last I/O: 11:54:45am 11/8/2004
> Total Packets: Out: 21 In: 3
> Total Bytes: Out: 1214 In: 401
> Last Addr Out: 192.168.2.9
> Last Addr In: 192.168.2.9
>
>
>
>
> Okey client
> -------------------------------------------------------------------------
>
>
> SLP Version: 1.0
> SLP Start Time: 8:06:24am 11/8/2004
> Last I/O: 9:11:45am 11/8/2004
> Total Packets: Out: 25 In: 8
> Total Bytes: Out: 1766 In: 475
>
>
> SLP Operational Parameters Values
> ------------------------------- ------------
> Static Scopes NO
> Static Directory Agents NO
> Active Discovery YES
> Use Broadcast for SLP Multicast NO
> Use DHCP for SLP YES
> SLP Maximum Transmission Unit 1400 bytes
> SLP Multicast Radius 32 hops
>
>
> SLP Timers Values
> ------------------------------------- ------------
> Give Up on Requests to SAs 15 seconds
> Close Idle TCP Connections 5 minutes
> Cache SLP Replies 1 minutes
> SLP Default Registration Lifetime 10800 seconds
> Wait Before Giving Up on DA 5 seconds
> Wait Before Registering on Passive DA 1-2 seconds
>
>
> Scope List Source(s)
> ---------------------------------------- ------------
> <unscoped> DA
>
>
> DA IP Address Source(s) State Local Interface Scope(s)
> --------------- --------- ----- --------------- ------------------
-
> ----
> 192.168.2.9 CNFG UP 192.168.24.155
> <unscoped>
>
>
> Local Interface 192.168.24.155
> ---------------------------------
> Operational State: UP
> Operating Mode(s): MCAST
> SA/UA Scopes: <unscoped>
> Last I/O: 9:11:45am 11/8/2004
> Total Packets: Out: 25 In: 8
> Total Bytes: Out: 1766 In: 475
Peter
located? Does problem occur for a connection to MOBCANO_NS4 or COBRA server?
Can you post results of CONFIG from MOBCANO_NS4 server?
<osha...@mobitellanka.com> wrote in message
news:kmfkd.1477$aj3...@prv-forum2.provo.novell.com...
> Thanks for replying Peter.
> Yes both the clients are wired to the same switch. And MTU size is default
> for both the clients.
> Peter, a fellow system admin here has started a new thread "Login delay
> with "internal error 0x00008801"". He has specified a windows login error
> there. In fact you have replied that thread. Hope you'll find a clue
there.
> Thanks again for your help.
> Oshadha.
>
Peter
there). Your network description looks a bit incomplete to me. Lets
summarize:
1. Server segment 192.168.2.0. Are all servers on the same switch?
2. Is one of the PIX interfaces plugged directly into server segment switch?
3. PIX itself (it would be interesting to see its configuration)
4. How client network segments are attached to PIX? Is each client network
having a separate interface in a PIX box, or there is a router (or layer 3
switch) between PIX client network interface and client network segments?
5. Each client network segment on a separate switch (or VLAN)
When was the last time PIX box (and other network switches/routers) was
shutdown and restarted?
Thanks.
<osha...@mobitellanka.com> wrote in message
news:Qtlkd.1625$aj3...@prv-forum2.provo.novell.com...
> Thank you for replying Peter,
>
> Well, clients ranges are 192.168.24.xxx, 192.168.25.xxx, 192.168.26.xxx,
> 192.168.27.xxx, 192.168.28.xxx and the server side is 192.168.2.xxx and
> COBRA (S1) 192.168.2.19 and MOBCANO_NS4 (S2) 192.168.2.2
> PIX reside between the client range 24, 25, 26, 27, 28 and 192.168.2.xxx
> rang which is a high security zone.
> Both error and okay clients are spread all over the client range.
> Following is the cofig of MOBCANNO_NS4.
>
> Thanks Peter.
> Oshadha.
>
> File server name:
> MOBCANO_NS4
> IPX internal network number:
> 0A8D458E
> Server Up Time: 13 Days 23 Hours 6 Minutes 35
> Seconds
>
>
> Broadcom NetXtreme Gigabit Ethernet
> Driver
> Version 2.32 May 7,
> 2002
> Hardware setting: Slot 10, Memory F6000000h to F600FFFFh, Interrupt
> Bh
> Node address:
> 000C7620A60C
> Frame type:
> ETHERNET_II
> Board name:
> B57_1_EII_EII
> LAN protocol:
> ARP
> LAN protocol: IP Addr:192.168.2.2
> Mask:255.255.255.0
>
> Compatibility Mode Driver 28Jul2000
> Version 5.21i July 28, 2000
> Hardware setting: I/O Port A55h
> Node address: 7E01C0A80202
> Frame type: CMD
> Board name: CMD Server
> LAN protocol: IPX network FFFFFFFD
>
> Tree Name: CANO_TREE
> Bindery Context(s):
> .CANO
>
Peter
Is the client still having problems for exactly 15 minutes after reboot?
How client gets its IP address (DHCP or static)?
If DHCP, does IP changes after reboot or cold start?
If you restart problem PC after 15 minutes and successfull login, does
problem returns or requires a cold start to occur again?
If you choose to login first to workstation only and then perform Novell
Client login, does problem exist also?
<osha...@mobitellanka.com> wrote in message
news:1l_ld.1799$T85...@prv-forum2.provo.novell.com...
> Thanks for replying Peter,
>
> 1. Yes, all server are connected to a single summit 48i switch (layer
> 3 functionality enable) which has 2 VLANs
>
> 2. Yes, the switch is directly connected to one of the PIX interfaces
>
> 3. PIX configuration is nearly 20 pages. Is it possible to display
> the config in the forum?
>
> 4. Each client segment is connected via a layer 3 (function as layer
> 2) summit 48i switch. And these switches connect to single layer 3
> functioning summit 5i switch. This switch connects to one of the PIX
> interfaces.
>
> 5. Each client segment is in different switch, which is also a
> different VLAN. (summit 5i defines the VLANs)
>
> 6. Any switch or the PIX is not shutdown for nearly 4 months.
>
> Thank you for still helping me out with the problem.
> Oshadha.
>
Peter
> yours.
>
My e-mail address is in the header.
peterf...@yahoo.ca
Peter
1. Cold start "problem PC"
2. Login as workstation only, Start -> run -> cmd
3. Ping your server 192.168.2.9, it should respond
4. telnet 192.168.2.9 524
Yes, there is a space before 524.
See what happens. Does it present a blank screen with a flashing cursor? Hit
enter key. Does it respond with "Connection to host lost." message? That is
a symptom A.
Or it says "Connecting To 192.168.2.9..." for 15 seconds or so, and "Could
not open a connection to host on port 524 : connection failed"? That is a
symptom B.
5. Start -> run -> \\192.168.2.9
Does it display "\\192.168.2.9 The network name cannot be found. "
immediately? That is a symptom C.
Or it displays the same message but with one minute delay? That is a symptom
D.
If you have observed symptoms A and C, you have a bad address cache problem
(or a bad server name problem). Novell Client setting will resolve that.
If you have observed symptoms B and D, that is a network/firewall issue.
<osha...@mobitellanka.com> wrote in message
news:Xgimd.2768$T85....@prv-forum2.provo.novell.com...
> Thanks for replying,
> . I can email the configuration. Can you please specify the email of
> yours.
>
> . Not exactly 15min, to be honest I really haven't measure the time
> gap precisely. But I'm sure it not a fix time.
>
> . Client IPs are static.
>
> . The problem occurs usually when a cold start is performed. But
> certain times when a problem machine is logoff and when trying to login
> (with out a restart) the problem appears back.
>
> . Yes. Even after locally logged in (workstation only), the problem
> appears for about 10min or so before successfully login to the novell
> Server. This has been the solution for most of the problem client so far.
> During this 10min duration UNC path access for novell server does not work
> either.
>
> Thanks you peter.
>
Peter
192.168.2.9) servers should work. You have a problem with 192.168.2.9 only,
right?
Any word on results of suggested tests?
<osha...@mobitellanka.com> wrote in message
news:JWFmd.4063$T85....@prv-forum2.provo.novell.com...
> Thanks for the step you have specified Peter,
> I need sometime to check these on several clients and make sure that the
> troubleshooting steps are performed within the delay period. I'll reply
> you soon with the info.
> And I have mailed you the PIX configuration to mail address specified.
> Thanks a lot again,
> Oshadha.
>
Peter
situation. I think I have made it clear. No wonder they did not work.
I would start testing your network/firewall infrastructure.
Start from making PIX settings for both servers identical (they were not in
your config).
Schedule power off/on for all your network gear in the path between clients
and servers.
Analyze Level 3 router settings.
Perform and analyze network traces from good and bad clients.
Enough work?
<osha...@mobitellanka.com> wrote in message
news:t4knd.6550$T85....@prv-forum2.provo.novell.com...
> Thanks for the reply,
> Yes, only 192.168.2.9 has the problem. 192.168.2.2 works fine.
>
> I performed your steps specified in few problem machines. It appears the
> result is B and D witch is network/firewall problem. I figured out what
> you need to diagnose. And I tried fixing problem clients with the bad
> cache functionalities but still I get B and D.
>
> So peter what would you suggest? What troubleshooting steps are to be
> performed further?
>
> Thanks a lot,
> Oshadha.
>
Peter
<osha...@mobitellanka.com> wrote in message
news:awdod.8338$T85...@prv-forum2.provo.novell.com...
> Thanks for replying Peter,
>
> Well, the difference of PIX setting for 192.168.2.2 (ok server) and
> 192.168.2.9 (problem server) is that for 2.2 we have open only the
> required ports and for 2.9 we have open the entire IP port stack. On the
> other hand few clients are affected with this problem in same network
> segments, so my guess is PIX config does not require any changes. Do you
> have any reason to perform this step?
My suggestions were based on common sense to reduce a chance for a different
handling of firewall statements by PIX. I'm not saying that opening whole IP
range is wrong...
>
> And peter, since all clients in same segments can connect to the server
> sooner or later (some do connect normally) do you think layer 3 switch has
> to do anything at this point?
Yeah, but you do not want clients to connect "later". It might have
something to do with the router or just switch port settings, I just
speculate.
By the way, did you try to swap clients on the switch, to see if problem
sticks to the client PC or to a switch port?
>
> I will try to arrange a restart procedure for all network equipments as
> well as perform traces for both user types.
Don't perform traces with Novell activities, just basic tests A, B, C and D.
Peter
performed successfully" or "step X results are as expected".
A, B, C and D are the typical observations in situations where your Novell
network connectivity failed.
There were no A, B, C or D tests to perform. I think you are mixing results
with actions.
There were only two tests to be performed:
"First" test:
1. Cold start "problem PC"
2. Login as workstation only, Start -> run -> cmd
3. Ping your server 192.168.2.9, it should respond
4. telnet 192.168.2.9 524
and "Second" test:
1. Cold start "problem PC"
2. Login as workstation only, Start -> run -> cmd
3. Ping your server 192.168.2.9, it should respond
5. Start -> run -> \\192.168.2.9
Timing is critical. You should perform last line in each of the tests in
less than 5 minutes after cold start, otherwise you are not duplicating user
situation.
For the "Second" test there is also another observation, when Novell network
connectivity comes back to normal. You should get a Novell logon prompt.
That would be a symptom E.
Can you please repeat your results in a bit more organized way?
For example like this:
---------------------------
I have performed tests 10 times.
In 8 cases results were:
"First test" - observed B
"Second test" - observed D
In 2 cases results were:
"First test" - observed B
"Second test" - observed E
---------------------------
Thanks.
Now back to your reported results.
Are you then saying that after performing a cold boot, and exercising tests
in less than 5 minutes after boot, you sometimes(?%) you have got:
"First test" - observed A symptom (machine answers requests at port level)
"Second test" - observed C symptom (machine quickly fails UNC path requests)
and sometimes (?%) you have got:
"First test" - observed A symptom (machine answers requests at port level)
"Second test" - observed E symptom (machine displays Novell Login)
Please clarify.
What about other suggestions I have sent to you before?
(a) Start from making PIX settings for both servers identical (they were not
in
your config).
(b) Schedule power off/on for all your network gear in the path between
clients
and servers.
(c) Analyze Level 3 router settings.
(d) Perform and analyze network traces from good and bad clients.
(e) By the way, did you try to swap clients on the switch, to see if problem
sticks to the client PC or to a switch port?
<osha...@mobitellanka.com> wrote in message
news:oCyod.9459$T85....@prv-forum2.provo.novell.com...
> Thanks for replying,
> Ok. I'll try performing the steps you have specified as possible.
> Peter, in certain problem clients I notice while they connect to port 524
> (step B), they do not connect using the UNC path (step D). Meaning B
> happens but not D. This is a random effect. Sometimes B and D results are
> as expected.
> Certain times when both B and D steps are performed successfully (after
> connecting port 524 and UNC path), when you retry B and D the connection
> delays appears as it was initially (my guess is it shouldn't occur again
> once it is connected).
> I'm confused with the result. Because while the machine answers the
> requests at port level it does not answer for the UNC path requests (does
> UNC also works at the application level?).
> Could this provide an important clue?
> Thanks a lot peter,
>
Peter
Thanks for posting results.
First, a clarification questions:
What did you observe in the first test, to allow you to say: "successful
operation"?
Did you perform all your tests within 5 minutes after the cold start of PC?
What is troubling, is the fact that some "good" clients become "bad" ones.
At the same time "problem" clients can connect occasionaly. There sems to be
no consistency.
By moving "problem" clients to 192.168.2.x network you are not only
bypassing PIX, but also avoiding other VLANs and bypassing layer 3 router.
Plus, now your clients are in the same broadcast domain as servers too. As
you have learned, that helped a lot.
I think you need to perform basic network traces, to see where the
communication starts to break.
Peter
locate COBRA server, in comparison to traces showing location process for
CANO server.
What hardware does COBRA run on?
Did you look at network statistics in COBRA console monitor? How do they
compare to CANO statistics? But local (same LAN segment) clients can locate
COBRA without a problem...
Is SCMD loaded an both servers in exactly the same way?
I still suggest to remove SCMD IPX from servers, at least as a
troubleshooting step.
<osha...@mobitellanka.com> wrote in message
news:QVatd.556$Hw3...@prv-forum2.provo.novell.com...
> Thanks for replying peter,
>
> First question - we were testing A, B, C, D tests against timing factor,
> what I meant by successful operations is that these attempts gave out
> result without a delay as if the client was a okay client.
>
> Second question - yes, I performed these test within 5 min range.
>
> . Peter the way I see the problem is that, CANO (192.168.2.2)
> responses clients very well. So if any network switches (layer 3) posing
> the problem, CANO should affect as well. But this is COBRA only. Meaning
> probably PIX interrupts COBRA operations? Peter, does the CANO and COBRA
> history provide an important clue? Cloud any NIC driver corruption or
> probable miss-configuration of IPX in COBRA allows PIX to drop packets?
>
> . When the "tests" were carried out I realized an important fact.
> Windows clients basically cannot see COBRA. I performed several extra
> tests by searching (computer search) COBRA in widows but it was unable to
> do so. But it finds CANO server. My guess is that this is the root cause
> of the problem not an authentication based problem.
>
> Meantime I'll try isolating the problem by moving the clients to different
> network segments and other tests you specified earlier and traces.
>
> Thanks Peter,
> Oshadha.
>