Jenny.... we too experienced this MAJOR bug....
what we did to fix it, rather than backrev code, we switched to 802.2.
(the reason we didn't back rev was because when we originally told them
about the problem we were on the 1st release of msfc2 code and 1st release
of sup1a code and they would not help us untill we upgraded! SOO..We did and
the friggin bug was STILL there! apparently it had been fixed in the
previous 12.1 code, and re-broke in the latest) the router will not reply to
GNS regardless of whether a server is on the local segment or not with this
broke code.
the move to 802.2 was a BEAR... we had to hit close to 5,000 machines and
1500 printers! luckily we use zen/nal and could push 802.2 to the desktop of
70% of those who stayed logged in when this bug reared it's ugly head!
I found that 802.2 worked PURELY on accident... I had been workign on this
junk for 22 hours with NO LUCK. about 5am THE NEXT DAY I said screw it,
since the local segment I was on was also not working I switched it to
802.2, changed a few workstations and whamo, love was in the air! (the cisco
rep was shocked (this was the 3rd as we changed time zones 3 times!) heh!
anyway, as long as your servers are on a different segment, you can leave
them at 802.3 if that is what they are on, and change your user segments to
802.2. (gns is irrelavent on an all server segment) And the 6509 will
convert 802.3 to 802.2 as it passes through the switch.
(You'll also notice that you can log in even though you don't get the login
box on boot) (the login box only comes up if a gns response is seen)
browsing through network neighborhood still shows all servers, ip/ipx and
you can log into any of them.
If need be, you can also assign a secondary ipx network to the segment that
is currently broken. (use same netnumber but change the primary to 802.2 and
the secondary to 802.3) that way you can migrate a little more slowly and
not be so rushed.
ok, that's my $.02 for the day! :)
-Patrick
>>> "[EMAIL PROTECTED]" 10/29/01 09:11PM >>>
My mail server is spitting the dummy (I am NOT having a good week so far),
so excuse me if this appears twice.
Cisco has admitted that yes, there is a bug with IPX in 12.1. They
suggested that we upgrade to a scarily recent version of IOS - we will back
out to 11.2 and test the new version first rather than bunging it straight
into a production core router!
In response to Priscilla's suggestions - yes, we did check the update
interval. Just for fun we explicitly set it (to 59 seconds instead of the
default 60), but that made no difference. Turning on debug ipx on these
routers would crash them, but we did check that last week when a similar
problem showed up in a test lab. debug ipx rip act showed one router
sending the (correct) updates, but the other router giving no indication
that it was seeing them - no errors, and no debug output.
Oh, and if anyone has anything interesting to say about tuning the
frame-relay broadcast-queue command, I'd love to hear your thoughts :-) (I
told you I was having a bad week...)
JMcL
----- Forwarded by Jenny Mcleod/NSO/CSDA on 30/10/2001 01:05 pm -----
"Priscilla
Oppenheimer" To:
[EMAIL PROTECTED]
Subject: Re: OT - IPX routes
[7:24456]
Sent
by:
nobody@groups
tudy.com
30/10/2001
06:14
am
Please
respond
to
"Priscilla
Oppenheimer"
IPX is still in CIT, CID, and CCIE. So I would say it is on topic! ;-)
Please let us know what you find out. It sounds like a bug...
Have you made sure nobody configured this command on the interface (or that
the new version didn't default to it?)
Router(config-if)#ipx update interval {rip | sap} {value | changes-only}
Can you turn on debug ipx routing or would that be too risky on your
network?
Priscilla
At 10:19 PM 10/28/01, [EMAIL PROTECTED] wrote:
>Hi all,
>This is off-topic because it's not cert-related, although I could argue
>that it's good CIT practice!
>
>Is anyone (else) out there using IPX with IOS 12.1?
>We had a problem crop up this morning on 7500 routers that have been
>running 12.1(10) for about a week. IPX RIP updates are not being seen by
>the routers across a fast ethernet link, although updates are seen across
>other links. And just to make it really weird - if the IPX routes are
>cleared, the next update is seen. But none after that, so the routes time
>out again.
>We also came across a similar or identical bug late last week immediately
>after upgrading a couple of other 7500s to 12.1(10).
>We are escalating this to the TAC, and have found a few possibly-related
>bugs on the CCO bug watcher, but has anyone else struck this bug? The
more
>information I can get about symptoms, what's been tried etc, the better.
>I'm happy to take this off-line.
>(Our IPX network is temporarily held together with metaphorical string and
>stickytape - namely a script has been hastily written to periodically
clear
>the IPX routes on the affected routers. Very ugly, but so far effective).
>
>Thanks,
>JMcL
________________________
Priscilla Oppenheimer
http://www.priscilla.com
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=24603&t=24456
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
