Re: Call fails on the CUBE2 after CUBE HA failovers - Page 2

Yangjp715 · ‎01-11-2021

Hi all,

I have configured CUBE box-box redundancy recently. It is all good when the CUBE1 is active. However, calls fail for both incoming&outgoing when CUBE failovers. Both CUBEs has the same configuration except the IP addresses of the interfaces.

Any help would be appreciated.

CUBE WAN VIP: 10.38.0.99 DMZ on the firewall --> mapped to 207.195.52.111, which is pointing to ITSP 208.68.17.52 (One SIP Trunk)

CUBE LAN VIP: 10.20.140.99

CUCM IP: 10.41.40.10, 10.41.40.20, 10.121.121.7

CUBE1:

voice service voip
ip address trusted list
ipv4 10.41.40.10 255.255.255.255
ipv4 10.41.40.20 255.255.255.255
ipv4 10.121.121.7 255.255.255.255
ipv4 208.68.17.52 255.255.255.255
ipv4 10.38.0.99 255.255.255.255
ipv4 207.195.52.111 255.255.255.255
ipv4 10.20.140.99 255.255.255.255
address-hiding
mode border-element license capacity 200
media anti-trombone
allow-connections sip to sip
redundancy-group 1
redirect ip2ip
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback pass-through g711ulaw
modem passthrough nse codec g711ulaw
sip
rel1xx disable
header-passing
error-passthru
referto-passing
asserted-id pai
asymmetric payload dtmf
early-offer forced
midcall-signaling passthru
privacy-policy passthru
g729 annexb-all
pass-thru content sdp

interface Port-channel1.105
description DMZ SIP inbound
encapsulation dot1Q 105
ip address 10.38.0.100 255.255.255.0
bfd interval 3000 min_rx 3000 multiplier 3
redundancy rii 2
redundancy group 1 ip 10.38.0.99 exclusive
!
interface Port-channel1.140
description Uplink to 9504 Core
encapsulation dot1Q 140
ip address 10.20.140.100 255.255.255.0
bfd interval 3000 min_rx 3000 multiplier 3
redundancy rii 1
redundancy group 1 ip 10.20.140.99 exclusive
!
interface Port-channel1.3001
description CUBE-HA Heartbeat
encapsulation dot1Q 3001
ip address 172.28.140.100 255.255.255.248

redundancy
mode none
application redundancy
group 1
name CUBE-HA
priority 150 failover threshold 75
timers delay 30 reload 60
control Port-channel1.3001 protocol 1
data Port-channel1.3001
track 1 shutdown
track 2 shutdown
!
!
!
track 1 interface Port-channel1.140 line-protocol
!
track 2 interface Port-channel1.105 line-protocol

dial-peer voice 100 voip
description Incoming call from CUCM to CUBE
session protocol sipv2
incoming uri from 1
voice-class codec 1
voice-class sip bind control source-interface Port-channel1.140
voice-class sip bind media source-interface Port-channel1.140
dtmf-relay rtp-nte
no vad
!
dial-peer voice 200 voip
description Incoming Calls from ThinkTel to CUBE
call-block translation-profile incoming PSTN-CALLING-BLOCK
call-block disconnect-cause incoming call-reject
session protocol sipv2
incoming called e164-pattern-map 2
voice-class codec 1
voice-class sip bind control source-interface Port-channel1.105
voice-class sip bind media source-interface Port-channel1.105
dtmf-relay rtp-nte
no vad
!
dial-peer voice 101 voip
description Incoming Call from CUBE to CUCM
session protocol sipv2
session server-group 1
destination e164-pattern-map 2
voice-class codec 1
voice-class sip bind control source-interface Port-channel1.140
voice-class sip bind media source-interface Port-channel1.140
dtmf-relay rtp-nte
no vad
!
dial-peer voice 201 voip
description Outgoing Call from CUBE to ThinkTel
session protocol sipv2
session server-group 2
destination e164-pattern-map 1
voice-class codec 1
voice-class sip bind control source-interface Port-channel1.105
voice-class sip bind media source-interface Port-channel1.105
dtmf-relay rtp-nte
no vad

CUB2:

redundancy
mode none
application redundancy
group 1
name CUBE-HA
priority 100 failover threshold 75
timers delay 30 reload 60
control Port-channel1.3001 protocol 1
data Port-channel1.3001
track 1 shutdown
track 2 shutdown
!
!
!
track 1 interface Port-channel1.140 line-protocol
!
track 2 interface Port-channel1.105 line-protocol

interface Port-channel1.105
description DMZ SIP inbound
encapsulation dot1Q 105
ip address 10.38.0.101 255.255.255.0
bfd interval 3000 min_rx 3000 multiplier 3
redundancy rii 2
redundancy group 1 ip 10.38.0.99 exclusive
!
interface Port-channel1.140
description Uplink to 9504 Core
encapsulation dot1Q 140
ip address 10.20.140.101 255.255.255.0
bfd interval 3000 min_rx 3000 multiplier 3
redundancy rii 1
redundancy group 1 ip 10.20.140.99 exclusive
!
interface Port-channel1.3001
description CUBE-HA Heartbeat
encapsulation dot1Q 3001
ip address 172.28.140.101 255.255.255.248
!

SIP trunk in CUCM is in full service and pointing to the CUBE LAN VIP.

Re-post this discussion since the old post is missing.

Thanks

Yangjp715 · ‎01-12-2021

Still the same. Actually, session target and server-group 2 point to the same IP.

Scott Leport · ‎01-12-2021

Yeah I did see that.

Did you check with your ITSP on whether or not they're receiving the INVITE messages when it's failed onto CUBE2?

Yangjp715 · ‎01-12-2021

They have not received the INVITE and SIP option message when the CUBE2 is active. I am thinking if it is license issue, as i can see from Cisco Smart license portal, CUBE1 is active, CSSM does not switch the license reservation to the new active CUBE.

Also, for CUBE HA configuration, not sure if i need to apply the command "mode border-element license capacity xxx" on the second CUBE. As you can see, only the command "mode border-element" on the CUBE2.

Roger Kallberg · ‎01-12-2021

I would not think that this would be the problem. You would need to check where traffic from your SBC does stop if it newer reaches the SP. Would it be possible for you to do a packet capture of the traffic as it leaves the router and also check in the entity that you have that does the address translation you mentioned earlier if it “sees” the traffic from SBC2?

Scott Leport · ‎01-13-2021

I agree with this. While you will obviously want to get your licensing issues sorted and your configuration across both CUBEs fully standardized, I don't believe this is the root cause of your issue here. There are plenty of single deployment CUBEs out there which don't even have the border element configuration in place and they work just fine. Someone actually asked the question a few years ago about whether or not this is really required, so worth checking out this thread if you haven't seen it already:

https://community.cisco.com/t5/ip-telephony-and-phones/quot-mode-border-element-license-capacity-quot-command/td-p/2615948

In the meantime, yes please check the devices upstream of your CUBE because its very likely to be where the issue lies now that we know the ITSP aren't receiving anything from CUBE2.

Roger Kallberg · ‎01-11-2021

This is a great question. Afraid that I’m not an expert in licensing questions. You better reach out to the licensing team or your account team about this.

Yangjp715 · ‎01-13-2021

Thanks Scott and Roger for your help. The issue is finally get fixed! There is a misconfiguration from ITSP and the communication from WAN VIP to the ITSP was using different UDP port for the same session, which was fixed by applying the command connection-reuse under sip-ua.