no sniffer? Ethereal is free... So is Linux! : ) How about some tcpdump?
>>> "Priscilla Oppenheimer" 01/24/02 04:09PM >>> I wondered about type-20 propagation also, but that's only to get NetBIOS through an IPX network. It's so that Windoze networking will work over an IPX internetwork. I don't think that's relevant. You said that the routers aren't using internal network numbers, but I'm more concerned about the servers' internal network numbers. They can't be the same as any other numbers, real or internal. You are experienced with NetWare and know this but your client might not! ;-) No sniffer? Argh! ;-) How about some show and debug statements on the router then? Show IPX traffic might help with an encap issue. It displays the number of format errors. If the router receives an IPX packet encapsulated with a frame type that the router has not been configured to support, it increments the format errors count and drops the packet. Debug IPX SAP might help. Have a client login so that you can see the Get Nearest Server SAP broadcast from the client. There's also debug ipx packet to see packets forwarded, but that only works if you disable fast switching with no ipx route-cache. I wish I could help more with the VPN aspect. I suspect that's where the weirdness lies. Good luck with this. Keep us posted. Thanks. Priscilla At 12:35 PM 1/24/02, Chuck Larrieu wrote: >thanks for taking the time to read through this, Cil. The problem continues >to be a source of frustration for my client and for me. > >some comments / responses below: > > >""Priscilla Oppenheimer"" wrote in message >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > What version of NetWare are the clients using? Some of this may only apply > > to older versions..... > >CL: the server is a 4.x box, the PC clients use the Novell Client32. > > > > > Encapsulation issues are definitely a good place to start. You say that >the > > router is using sap (802.2) but the client is using Windows 95, which > > probably did not default to 802.2. It probably defaulted to novell-ether. > >CL: I have worked with the client to try to determine this. I will revisit >the issue. This is one of the things that I am not confident about. > > > > > Where is the login server? Local or remote? Who answers the client's Get > > Nearest Server (GNS) request? Could it be the router? Could the router be > > telling the client about some server that can't actually provide login > > services? > > > >CL: All client PC's in the network log on to a central server. This is the >first location where there is a problem. I dislike introducing wildcards >into the discussion, but this is also the only location where there is an >827 router and a VPN involved. I am looking away from the router if only >because the router is seeing all network devices - central server and print >servers. So far as I can tell, the router in question is configured no >differently than any other router in the WAN. > >CL: There is no internal network number configurered on any router in the >network. > >CL: this would be a great place for sniffer capability, to really decode >what is hapening. unfortunately, that is not an option. > > > Routers have also been known to answer the GNS with the address of a >server > > that the client can't actually reach, due to IPX access lists on the >router. > >CL: no ipx access-lists on any router anywhere in the LAN > >CL: other folks have offered that ther might be a type-20 propogation issue. >I re-read the Cisco documentation on this, and also checked back to my >reference configurations from the IPX network I used to manage at the >brokerage firm. I don't see type-20 as an issue, really. Perhaps I am >misunderstanding, but type-20 is relevant only when using Micorsoft >netowrking over IPX. None of my routers at the brokerage firm ever had >type-20 propogation enabled. It was a strictly Novell / IPX network, and >there were never any reachability issues. > > > > > > Check network numbers, both internal numbers (on the servers) and "actual" > > numbers on WANs and LANs. Make sure there are no duplicates. The symptoms > > sound mildly similar to a situation I ran into where the internal network > > number on a server was the same as a number used on the new WAN. > >CL: good idea, and one that normally would not occur to me. A colleague of >mine also sugessted sending a print job to the local office printer from >some other office, the theory being that if the WAN print job went through, >we could eliminate the WAN as a problem. > > > > > I assume you have checked this Cisco document on troubleshooting NetWare: > > > > http://www.cisco.com/univercd/cc/td/doc/cisintwk/itg_v1/tr1908.htm > > > > Good luck. Let us know what you discover! Thanks. > > > > Priscilla > > > > At 01:32 AM 1/23/02, Chuck Larrieu wrote: > > >I'm resurrecting this one because I have a client..... > > > > > >In fact, I was thinking about posing this as a Friday Folly of sorts. The > > >situation is this: > > > > > >We install a VPN from one client location to another. We have done frame > > >relay for this client, but frame was way too expensive for the particular > > >new office location, and VPN is so generic these days... > > > > > >Customer is an IPX shop. 827 routers at both ends of the internet > > >connection. GRE tunnel for the IPX. Al routers see all IPX devices on the > > >network. However, the new workstation not only refuses to see the login > > >server, but most of the time plain old crashes / locks up when booting. > > > > > >Remove the router from the hub, and the PC comes up just fine. During >this > > >period, the PC can also print to an IPX printer connected to the local >hub. > > > > > >My employer's policy is that we have no responsibility for anything >beyond > > >the router, but I happen to like this client, and I happen to have a >sense > > >of responsibility in terms of recommending workable solutions to clients. >So > > >I continue to help. > > > > > >Suffice it to say that the client is clueless in anything beyond simple >PC > > >and server configuration. No troubleshooting skills. No sniffers, no > > >advanced education in networking. So it can be painful trying to > > >troubleshoot by telephone. > > > > > >So now I have the mystery of the week in front of me. The ethernet > > >encapsulation is SAP ( Novell 802.2 ) The PC client is Windoze 95. Client > > >tells me he has "ghosted" a Windows 98 image to the PC and experienced >the > > >same problem. Client also tells me he is seeing 802.2 and 802.3 frames on > > >the local LAN, but I believe what he is "seeing" is a printout from the > > >print server ( HP Jet Direct ) indicating that both frame types are > > >configured on the print server. > > > > > >Quick looks on TAC reveal nothing about PC issues ( not surprising, if >only > > >because the router is working the way I would expect, the proof being all > > >IPX devices are visible to the router ) > > > > > >In any case, I have re-read all the posts in this thread, and I will go >back > > >to the client with some things to look at, including updating the NIC > > >drivers ( and not just relying on what's in the "ghost" reference image ) > > >and removing the 802.3 frame type from the print server configuration. If > > >this doesn't work, I will recommend that we dispatch our installation >people > > >to load a newer image onto the 827. > > > > > >I guess I am posting this situation just because I continue to be humbled >by > > >the kinds of problems that can occur, with no reasonable explanation. > > > > > >Chuck > > > > > > > > >""John Neiberger"" wrote in message > > >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > > We're having an interesting issue that just appeared recently. We >have > > > > some Dell PCs running Netware 6 and new client software. We're not >sure > > > > why, but if one of these machines is connected to a 2924XL switch, it > > > > regularly experiences a blue screen of death either at login or within >5 > > > > minutes of login. > > > > > > > > We have identical machines that operate fine if they're connected to > > > > our Bay switches or Cisco 1900 switches. > > > > > > > > Have any of you seen anything like this?? That makes no sense to me. > > > > The only difference I've been able to determine is that Spanning Tree >is > > > > turned off on those particular Bay switches and 1900 switches, yet it >is > > > > turned on on the 2924XL switches. So, perhaps these PCs are reacting > > > > badly to STP BPDU. > > > > > > > > Any thoughts? Our LAN people are doing some testing with different >NIC > > > > software and Novell client software and I'll post back to the list if >we > > > > determine the actual cause of the issue. But can you think of why it > > > > would only happen if they're connect to a 2924? > > > > > > > > Thanks, > > > > John > > ________________________ > > > > Priscilla Oppenheimer > > http://www.priscilla.com ________________________ Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=33123&t=32536 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
