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

Thu Dec 28 17:40:00 EST 2006

Hi,

On Thu, Dec 28, 2006 at 09:21:11AM -0800, Sukumar Subburayan wrote:
> > - 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.

Thanks.  So the module might just be funny.  (Which is not a big problem,
as we don't *have* to use it for channels, if it doesn't like them).

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

Well, it's always good to understand *why* things are happening :)

> Was the errdisable due to channel misconfig? 

I don't think so.  CatOS (7.x) doesn't permit grouping ports to a channel 
that are not configured identically anyway.  To be sure, I explicitely 
checked both ports (trunk, duplex/speed, native vlan, allowed vlan, etc.) 
and couldn't see any differences. 

> Was there any other syslogs printed? 

CatOS printed things similar to this:

switch(enable)> set port enable 7/31
2006 Dec 22 23:32:13 UTC +00:00 %DTP-5-TRUNKPORTON:Port 7/31 has become dot1q trunk
2006 Dec 22 23:32:15 UTC +00:00 %DTP-5-NONTRUNKPORTON:Port 7/31 has become non-trunk

"and that's it".  Port goes up, port goes down, back to errdisable.

IOS printed something about DTP and VTP (clock not synced), before seeing
the port go up and down again:

05:04:30: %DTP-5-DOMAINMISMATCH: Unable to perform trunk negotiation on port Fa0/24 because of VTP domain mismatch.
05:04:31: %LINK-3-UPDOWN: Interface FastEthernet0/24, changed state to up
05:04:33: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/24, changed state to up
05:04:36: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/24, changed state to down
05:04:37: %LINK-3-UPDOWN: Interface FastEthernet0/24, changed state to down

[The VTP mismatch could be the cause of the problem, but it could as well
be a red herring... both switches are set to VTP transparent, VTP pruning
is disabled.  The VTP message went away when the port was set to 
"switchport nonegotiate", but the channel still refused to come up]

When trying to enable the ports "7/31 first, 5/31 second", this is what
happened:

2006 Dec 22 23:36:22 UTC +00:00 %DTP-5-TRUNKPORTON:Port 7/31 has become dot1q trunk
2006 Dec 22 23:36:25 UTC +00:00 %SPANTREE-6-PORTLISTEN: Port 5/31,7/31 (agPort 13/16) state in VLAN 83 changed to listening
2006 Dec 22 23:36:25 UTC +00:00 %SPANTREE-6-PORTLISTEN: Port 5/31,7/31 (agPort 13/16) state in VLAN 94 changed to listening
2006 Dec 22 23:36:27 UTC +00:00 %SPANTREE-6-PORTFWD: Port 5/31,7/31 (agPort 13/16) state in VLAN 94 changed to forwarding
2006 Dec 22 23:36:28 UTC +00:00 %SPANTREE-6-PORTFWD: Port 5/31,7/31 (agPort 13/16) state in VLAN 83 changed to forwarding
2006 Dec 22 23:36:35 UTC +00:00 %SYS-6-CFG_CHG:Module 5 block changed by telnet/195.30.1.100/gert
2006 Dec 22 23:36:40 UTC +00:00 %DTP-5-TRUNKPORTON:Port 5/31 has become dot1q trunk
2006 Dec 22 23:36:42 UTC +00:00 %DTP-5-NONTRUNKPORTON:Port 5/31 has become non-trunk

(IOS side looks similar)

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

This is what "show trunk" says:

asc0> sh trunk 5/31
* - indicates vtp domain mismatch
# - indicates dot1q-all-tagged enabled on the port
Port      Mode         Encapsulation  Status        Native vlan
--------  -----------  -------------  ------------  -----------
 5/31     nonegotiate  dot1q          trunking      94

Port      Vlans allowed on trunk
--------  ---------------------------------------------------------------------
 5/31     83,94

Port      Vlans allowed and active in management domain 
--------  ---------------------------------------------------------------------
 5/31     83,94

Port      Vlans in spanning tree forwarding state and not pruned
--------  ---------------------------------------------------------------------
 5/31     83,94

- we never tried with "all VLANs active".

IOS side looks like this:

interface FastEthernet0/23
 switchport trunk native vlan 94
 switchport trunk allowed vlan 83,94
 switchport mode trunk
 switchport nonegotiate
 channel-group 1 mode on
interface FastEthernet0/24
 switchport trunk native vlan 94
 switchport trunk allowed vlan 83,94
 switchport mode trunk
 switchport nonegotiate
 channel-group 1 mode on
interface Port-channel1
 switchport trunk native vlan 94
 switchport trunk allowed vlan 83,94
 switchport mode trunk
 switchport nonegotiate
end

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

The channel in question is in production now, so we can't fiddle with
it right now.  Checking "show agc 5/31" and "7/31" right now (ports *not*
configured into the same channel!) gives differences in admin_group and
vlan_num, and port_speed:

5/31: 
 admin_group  = 61
 vlan_num     = 94
 port_speed   = 2
7/31:
 admin_group  = 60
 vlan_num     = 731
 port_speed   = 1

- admin_group and vlan_num are to be expected, port_speed is a bit 
confusing (both ports set to auto/auto), but that could be a consequence
of "one port has a link and one hasn't".

We'll (try to) recreate this tomorrow with a lab 2950 and different 
ports on the 6509, module 5 and 7, so we can run more experiments.

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