Good afternoon,
I would appreciate if someone could help me understand how voice-class sip options-keepalive on a dial-peer behaves on a standby cube of a HA Cube setup. I was unable to find documentation that explained the behavior of both used together.
I have two HA cubes setup (four cubes in all), in two different sites, and they both behave differently in regards to the sip options-keepalive messages.
On SITE A:
The standby CUBE puts all his dial-peer in busy out mode. Its SIP OPTION messages are sent to the SIP trunk provider using the HSRP ip address instead of local interface ip address (both on LAN toward cucm and WAN toward ISP) consequently the reply 200 ok comes back to the active CUBE instead of the standby. Or should I say, I see the OPTION leaving the WAN side interface with the HSRP address, and nothing comes back on the WAN side standby cube. (Network Trace)
On SITE B:
The standby CUBE does not send any SIP OPTION messages, until he becomes the active cube . The keep alive field of the "show dial-peer voice summary" command shows no status while being the HSRP standby.
Wich way should be the designed way to behave ?If SIte A is correct, can I force the keepalives to be sent using the interface ip address instead of the HSRP address?
They are all running the same IOS. Both ISP providers are the same for both HA cubes. All connected to the same CUCM cluster on the LAN side.
The behavior of SITE B makes more sense according to me. In case of a cube fallback on SITE A, I would anticipate some delay before the option-keepalive changes the status of the dial-peer from busyout to active after he becomes primary cube and gets answers to his SIP OPTION messages, and that just smells bad.
Thanks,
