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

[Sukumar Subburayan]

comments inline..

sukumar




On Thu, 28 Dec 2006, Gert Doering wrote:

> 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)
>

No, the 'Fw:' is not relevant after the switch is booted.

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

also, the 'Fw:' for the linecard cannot be upgraded. The linecard SW 'Sw:' 
is bunded with CatOS and that is the one which can be upgraded.

> 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.
>

OK, since you are not trying to get channeling work between 5/31 & 7/31, 
this may not interest you. But, if you want to go further here are some 
suggestions.

Was the errdisable due to channel misconfig? Was there any other syslogs 
printed? If you just had allowed vlan list to say vlan 1-10 (instead of 
the entire 1K vlan) on both sides and then try channeling does it work?

To me the problem seem to be some parameters between slot 7 and other slot 
ports din't agree.

If the problem can be recreated we can look at 'show agc mod/port..' for 
both the ports and see what the etherchannel internal port datastructure 
is.

> 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
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>