Fault Tolerance not working between CSMs

Unanswered Question

I have two CSM modules in two differnt switches (Bridge mode) configured for high availability. After noticing one of the CSM modules was in failed mode, I reset the module. While the module reboots I get the following messages: %CSM_SLB-4-REDUNDANCY_WARN: Module 3 FT warning: LRP: no ACK from standby.. standby may be down

%CSM_SLB-4-TOPOLOGY: Module 3 warning: IP address conflict: ARP frame from 170.41.228.10 with MAC 00:01:64:f9:

1a:07 received on VLAN 2.

With both online a "show mod csm 3 ft" shows both modules active.

I can no longer access the real servers.

When I remove the module that I reset (Primary) I can access the servers using the backup CSM.

Whe I remove the backup CSM and insert the Primary, I cannot acces the servers once again.

The FT vlan is VLAN 7 configured on both switches and is the only allowed VLAN on the trunk.

The config for the Primary CSM is:redundancy

mode sso

main-cpu

auto-sync running-config

spanning-tree mode pvst

module ContentSwitchingModule 3

ft group 7 vlan 7

priority 30

preempt

!

vlan 2 client

ip address 170.41.228.20 255.255.255.192

gateway 170.41.228.1

!

vlan 8 server

ip address 170.41.228.20 255.255.255.192

!

probe CARMENWEBPROBE tcp

interval 10

failed 100

!

probe HTTPS tcp

interval 10

failed 100

port 443

!

serverfarm CARMENWEBFARM

nat server

no nat client

real 170.41.228.15

inservice

real 170.41.228.16

inservice

probe HTTPS

!

vserver CARMENVSERVER

virtual 170.41.228.10 tcp 0

serverfarm CARMENWEBFARM

persistent rebalance

inservice

Trunk for VLAN 7 config :

interface GigabitEthernet4/2

switchport

switchport trunk encapsulation isl

switchport trunk allowed vlan 7

switchport mode trunk

no ip address

logging event link-status

logging event spanning-tree status

logging event trunk-status

Has anyone had this problem?

Thanks, Donald

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Gilles Dufour Tue, 04/08/2008 - 06:53

have you tried to swap cards ?

Take the working standby and move it to the chassis of the not-working active.

See if the problem stick to the card or the chassis.

Then try to use one CSM at a time and use sniffer trace to see if a ping from csm to server get out of the blade.

Gilles.

The plan is to take a working CSM from a DR site with the same config to try in place of the not working active. I did not want to risk taking the working stanby and moving it and possibly having an outage at this time since this is a production switch being heavily utilized at the moment. I wanted to verify there was not something in the config that was not configured properly.

Actions

This Discussion