Your diagram is correct as far as connections go. Most of the Novell
servers are connected to the 5513, but all are in VLAN 1. The 5513 RSM does
all IPX routing for all VLANs. All VLANs are trunked between all switches.
There aren't any IPX routes on either of the 6509s as IPX routing isn't
configured?
-Original Message-
From: Michael L. Williams [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 02, 2002 5:33 PM
To: [EMAIL PROTECTED]
Subject: Re: Strange 6500/IPX Issue!! HELP!! [7:47951]
Wes,
Thanks for your reply. As you can imagine I've been through
the ringer so
far
At 06:20 PM 7/2/02, Michael Williams wrote:
The two PCs I'm experienting with are using hard-coded IPs, however the
results are the same with a DHCP machine. Portfast is indeed enabled (A
while ago, I learned the hard way about spanning-tree and DHCP/Novell).
Well, and I find myself trying to
Priscilla,
Thanks for your input. When I do a 'show ipx servers' it indeed shows the
gamut of 1500+ IPX entries (which is normal).
As far as putting a sniffer on the other side of the 5513 where the
servers reside, that was also a request by the TAC engr, but unfortunately,
the 5513 *is* the
Mike
Just a thought, but have you tried setting a gns-response-delay on your
router. From what I remember reading in my support exam study (I have NO
ipx experience), this can be used to compensate for the slow CPU or
network adapter card of the client, which would otherwise miss a quicker
6509 A
|
|
|
|
6509B - 5513 NOVELL SERVERS
So anything connected to 5513 can see the Novell Servers?
So anything connected to 6509B can see Novell Servers?
Can anything see the Novell Servers from the 6509A?
Where does the VLAN's come into this?
You say the 5513 has an RSM? I
Did you enable portfast or use the 'host' macro to set the user ports on
this switch? I have seen this, but it was in a situation where the user
machines had there IPX frame type set to auto. In that case the users
machine would boot up, try and autodetect the IPX frame type in use on the
Cisco Breaker wrote:
Did you disable spanning tree or used portfast on the ports
which are connected to clients.
Yes. In my original post, I tried to be as informative as possible, there's
always something that gets left out. Being a Novell shop (but not much
longer!) we put portfast on all
The two PCs I'm experienting with are using hard-coded IPs, however the
results are the same with a DHCP machine. Portfast is indeed enabled (A
while ago, I learned the hard way about spanning-tree and DHCP/Novell).
Well, and I find myself trying to get more into the Novell process to
I found I was mis-typing a MAC address portion of the IPX address. So, I
have a PC in VLAN1 that can't communicate with Novell, but it can send *and*
receive pings with the SPXping utility.
My bad.
Mike W.
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7i=47963t=47951
Did you disable spanning tree or used portfast on the ports which are
connected to clients. We have a customer that had the same issue and we
changed the client ports on the 6500's to portfast.
Here is the link.
http://www.cisco.com/warp/public/473/12.html
Best regards,
Cisco Breaker
Michael
Michael,
Shot in the dark - I've seen very strange issues like this with trunk
mismatches. You've probably got a trunk between the two switches. Make
sure your native VLANs match, make sure that every VLAN permitted on the
trunk is permitted on both sides. On a similar vein, all trunk ports
Wes,
Thanks for your reply. As you can imagine I've been through the ringer so
far with this one =)
We checked all of the trunks for native VLAN, speed, duplex, etc... All
checks out. This is also supported by the fact that IP works fine (all IP
routing for VLAN1 is handled by the RSM in
13 matches
Mail list logo
