CSM problem with Adapter Teaming

[yves.haemmerli]

Hi,

A CSM has been configured with a TCL scripted keepalive to retrieve a dynamic page from each server in the serverfarm. The script reads the data returned by the server and detects a specific string in the page.

The servers are dual-attached with two Broadcom NetXtreme Gigabit adatpers, configured with BASP Teaming (Smart load balancing with failover). This mode of operation allows outbound and inbound load balancing. Each adapter has its own MAC address.

Symptom :

We observe that the servers status swing between OPERATIONAL and PROBE_FAILED at random intervals. We suspect that the problem comes from the adapter teaming mode of operation. We see the CSM ARP table swinging between the two adapter MAC addresses for a specific IP address. I conclude that the CSM updates its ARP table for unicast packets as well.

When the ARP table points to the primary interface, the server status is OPERATIONAL, when the CSM ARP table points to the second adapter, the server status go to PROBE_FAILED.

Is is a know issue ? Is the CSM incompatble with adapter teaming ? We also have CSS devices probing the same servers at the same time, but without problems

Thank you for any advice

Yves Haemmerli

[aghaznavi]

Use the command 'failaction purge'

[bayoucisco]

It is not a CSM trouble but more a teaming trouble.

If you connect trought the console management instead of telnet you may see message like this one:

xdxh: %CSM_SLB-6-RSERVERSTATE: Module x server state changed: SLB-NETMGT: Got different MAC address from server x.x.x.x in response to ARP

If you have that kind of message it meens that the server is using both interfaces for the same IP address.

If it is the case you should have a look to your teaming configuration.

[tporembski]

Did you ever get this issue resolved with Broadcom SLB and if so what was the root cause. I am running into the exact same issue and the server admins are of no help. They say the teaming is configured properly and I have no way of verifing.