Issues with CSM 4.2.1

[shamilton-wilkes]

Upgraded from 4.1.2 on Saturday 19th, things were fine for a week. Changed the config to reflect the new alt keywork in IP addresses and FT priority.

On Saturday 26th, connections started dropping every 70 minutes, all connections through the CSM, but only for a few seconds, not all TCP sessions timed out.

Finally back revved to 4.1.4 yesterday AM. Issue is resolved, and I was surprised that 4.1.4 is quite OK with the 'alt' commands still in the configs.

I suspect it was an issue with the redundancy, as occasionally these were concurrent with the connection drops:

%CSM_SLB-4-REDUNDANCY_WARN: Module 11 FT warning: LRP: no ACK from standby.. standby may be down

Just a heads-up.

Simon

PS the TAC case was 600990267

[shamilton-wilkes]

OK, it wasn't 4.2.1. After 48 hours without incident it's started happening again on 4.1.4, with these going into the logs when it occurs as before:

%CSM_SLB-4-REDUNDANCY_WARN: Module 10 FT warning: LRP: no ACK from standby.. standby may be down

Any ideas?

I'm going to reboot the switch on Sunday night (our maintenance window) to take us to 12.2(18)SXD3, traffic is a fairly constant 300 meg, 3500 connections, so not high.

[jfoerster]

Hi,

if you want to use the new CSM 4.2 commands you need to upgrade to IOS you mentioned.

Have you checked that there is no Layer2 issue hitting you or that the standby module is having some problem?

Btw what happend if you remove the alt command running CSm version 4.1.4?

Kind regards,

Joerg

[Gilles Dufour]

Looks like you are using a trunk to exchange to transport the FT vlan and you are also doing connection replication.

It is recommended to use a dedicated link for the FT vlan to avoid other traffic to cause latency or packet drops on the FT vlan.

Could you try to use another interface for the ft vlan ?

You also mentioned that the CSM is sometimes slow to respond to show commands.

Is that still the case ?

If so, could you attach a cable to the CSM console and capture a 'core_trace_all' after typing the command 'venus'.

Regards,

Gilles.

[shamilton-wilkes]

What makes it a trunk rather than a dedicated VLAN? The VLAN is not being used for anything else, its only used on the 2 CSM blades in this chassis.

The config guide has a step 10:

Router(config-module-csm)# vlan 9, which in my case throws be back to global VLAN configuration mode. Am I supposed to have the FT VLAN defined on the CSMs in any way other than in the ft group command?

Can you give me a configuration example?

Thanks

Simon

[shamilton-wilkes]

I've attached a core_trace_all to the ticket.

Simon

[Gilles Dufour]

Vlan 9 is only used by the CSM.

But to transport vlan9 traffic from 1 switch to the other you are using a trunk [a group of vlan].

I believe it was gig2/15.

What you need to do is use an interface with a single vlan 9 associated to it.

ie:

gig 1/1

switchport

switchport mode access

switchport access vlan 9

no shut

On your trunk interface you then need to disable vlan9.

ie:

gig 2/15

switchport trunk allowed vlan remove 9

This guarantees that the full bandwidth of the interface is used for the CSM FT vlan only.

Regarding the config, you only need to configure the ft group/vlan.

Regards,

Gilles.

[shamilton-wilkes]

Changing the VLAN made no difference.

Either upgrading to SXD3 or resetting the supervisors did as the issue is now resolved.

Thanks

Simon

[shamilton-wilkes]

I spoke too soon. It it happening again, still the same regular 65 minute occurences, and the same very slow CSM command line.