CSM/GSS kalap & CSM redirection

gerard_saunders · ‎07-27-2008

Hi,

We are using kalap by tag to monitor CSM vips from our GSS's.

In general this is working well.

An ssl redirection serverfarm was setup to force ssl on particular URL's on the CSM.

When we activate this we have found that kalap communication is not accurate. Basically the CSM seems to be reporting that the VIP that is being monitored is constantly online - even when the backend servers that are load balanced are offline.

Any ideas why?

Examples:

Redirection serverfarm (currently disabled):

serverfarm F-E-SERVICES-R

nat server

no nat client

redirect-vserver F-E-SERVICES-R

webhost relocation https://xxx.xxx.xxx.xxx.xx%p 301

no inservice

Which would be linked into the following with an slb-policy F-E-SERVICES-R

vserver F-E-SERVICES

virtual xxx.xxx.xxx.xxx tcp www

vlan 167

status-tracking F-E-SERVICES

replicate csrp sticky

replicate csrp connection

persistent rebalance

slb-policy F-E-SERVICES

domain F-E-SERVICES

inservice

sachinga.hcl · ‎07-31-2008

HI Gerard,

Can you send me the output of the following command:

config-gslb)# show gslb-config answer

you can also use the other options of this command as follows:

To display the property settings based on IP address and answer type, enter:

gssm1.hcl.com(config-gslb)# show gslb-config answer 172.16.27.6 vip

To display the property settings based on an answer name, enter:

gssm1.example.com(config-gslb)# show gslb-config answer ansvip2

The GSS supports a maximum of 128 primary and 128 secondary KAL-AP(Keep ALive -Answering Protocol) keepalives when using the standard detection method and a maximum of 40 primary and 40 secondary KAL-AP keepalives when using the fast detection method.

KAL-AP sends a detailed query to the Cisco CSS or CSM at the address specified for the VIP answer to extract load and availability. The GSS determines the online status when the SLBs respond with information about a hosted domain name, host VIP address, or a configured tag on a content rule.

The Content and Application Peering Protocol (CAPP) may not recognize dropped fragments when a KAL-AP keepalive spans multiple datagrams due to large payloads. When the KAL-AP keepalive spans multiple datagrams and one of the spanned packets is dropped, the GSS does not retry the request. Instead, the GSS waits until the next period and sends the packets again. This results in the dropped datagram not getting updated load values on the VIPs that expect them. This behavior typically occurs in situations where the GSS consumes the full datagram (roughly 1.4 K) with tag names or VIP addresses. Otherwise, all data fits perfectly in a single datagram.

To resolve this behavior, use the VIP format for KAL-AP when you need the GSS to send a detailed query on load for hundreds of VIPs configured to a single primary or optional secondary (backup) IP address. Another solution is to use the tag format for KAL-AP, but to limit the length of the tag name to ensure that the packets do not exceed 1.4K.

here is the link for details reg

arding this

http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/gss4400series/v1.3/configuration/cli/gslb/guide/Answers.html

gerard_saunders · ‎07-31-2008

Note:

- without the redirection farm this is working fine

answer vip xxx.xxx.xxx.xxx name A-F-EXCH_PROD-VIP-CSM-SERVICES location Waterfront_DC activate

keepalive type kalap tag xxx.xxx.xxx.xxx F-E-SERVICES

And the shared kalap keepalive:

shared-keepalive kalap xxx.xxx.xxx.xxx secondary xxx.xxx.xxx.xxx