[c-nsp] upgrade firmware on Cat6k / CatOS modules?

[Gert Doering]

Hi,

a colleague ran across an interesting problem today.  We were trying to
build a 2x100 Mbit etherchannel between a Cat6k (Sup1a, CatOS 7.6(14))
and a Cat2950-24 (various recent IOS versions), and the channel refused 
to come up - always one port on the Cat6k side went into "errdisable"
(the first port to be enabled worked, the second port went to errdisable,
but it didn't matter *which* port was enabled first, and which port
second).

Today, we tried ports on different modules, and interesting enough,
as soon as module 7 isn't involved, the channeling "just works".

This is what we have:

3   48   WS-X6348-RJ-45      SAD04250LZ3 Hw : 1.1
                                         Fw : 5.3(1)
                                         Sw : 7.6(14)
5   48   WS-X6248-RJ-45      SAD04150EK1 Hw : 1.2
                                         Fw : 5.1(1)CSX
                                         Sw : 7.6(14)
7   48   WS-X6248-RJ-45      SAD035101TR Hw : 1.1
                                         Fw : 4.2(0.24)VAI78
                                         Sw : 7.6(14)

The combination 5/31+7/31 does not work (second port to come up goes
to errdisable).

The combinations 5/31+5/16 and 5/31+3/34 both work "as designed" - come
up as channel + trunk, and do what we want them to.

Now - the only difference we can see is "Fw" on the 6248 in Slot 7.  Which
might be relevant or not.

--> questions to the audience:

  - is "Fw:" relevant in any way after the switch has booted (available
    documentation seems to suggest that this is only boot code)

  - *if* the "Fw:" is relevant: is there a way to upgrade it?

At this point we're not actually trying to get the channel on 5/31+7/31
to work (we're happy with 5/31+3/34), we're just trying to understand 
the issues involved, and what might cause a difference between 
modules 5 and 7.

For documentation, in case someone wants to ask for it: both sides of the 
channel have been set to "unconditionally on" (set port channel ... on, 
set trunk ... on dot1q), and VTP is not involved (both switches set to 
VTP transparent, with different VTP domains).

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de