Solved: H323 GW IP Address in an Unknown State

cristian.munoz · ‎05-22-2012

Hi Guys

I searched into the forum but I could not find the answer. For some reason, the GW loses the H323 connection with the CUCM. For workaround I performed a reset of Publisher.

- CUCM ver. 8.6

- IOS 151-4.M2

- debug ip tcp transactions

May 23 00:18:18.735: TCB30C283F0 created

May 23 00:18:18.735: TCB30C283F0 setting property TCP_NO_DELAY (0) 31C14124

May 23 00:18:18.735: TCB30C283F0 setting property TCP_TOS (11) 31C1416C

May 23 00:18:18.735: TCB30C283F0 setting property TCP_NONBLOCKING_WRITE (10) 31C141B0

May 23 00:18:18.735: TCB30C283F0 setting property TCP_NONBLOCKING_READ (14) 31C141B0

May 23 00:18:18.735: TCB30C283F0 setting property TCP keepalive timeout (17) 31C141B0

May 23 00:18:18.735: TCB30C283F0 setting property TCP_VRFTABLEID (20) 31EB9E90

May 23 00:18:18.735: TCB30C283F0 setting property TCP_NO_DELAY (0) 31C1416C

May 23 00:18:18.735: TCB30C283F0 setting property TCP_ALWAYSPUSH (15) 31C1416C

May 23 00:18:18.735: TCP: Random local port generated 19147, network 1

May 23 00:18:18.735: Reserved port 19147 in Transport Port Agent for TCP IP type 1

May 23 00:18:18.735: TCP: sending SYN, seq 550628966, ack 0

May 23 00:18:18.735: TCP0: Connection to 10.113.227.11:1720, advertising MSS 536

May 23 00:18:18.735: TCP0: state was CLOSED -> SYNSENT [19147 -> 10.113.227.11(1720)]

May 23 00:18:18.735: Released port 19147 in Transport Port Agent for TCP IP type 1 delay 240000

May 23 00:18:18.735: TCP0: state was SYNSENT -> CLOSED [19147 -> 10.113.227.11(1720)]

May 23 00:18:18.735: TCP0: bad seg from 10.113.227.11 -- closing connection: port 19147 seq 0 ack 550628967 rcvnxt 0 rcvwnd 0 len 0

May 23 00:18:18.735: TCP0: connection closed - remote sent RST

May 23 00:18:18.735: TCB 0x30C283F0 destroyed

May 23 00:18:18.739: TCB30C2B094 created

May 23 00:18:18.739: TCB30C2B094 setting property TCP_NO_DELAY (0) 31C14124

May 23 00:18:18.739: TCB30C2B094 setting property TCP_TOS (11) 31C1416C

May 23 00:18:18.739: TCB30C2B094 setting property TCP_NONBLOCKING_WRITE (10) 31C141B0

May 23 00:18:18.739: TCB30C2B094 setting property TCP_NONBLOCKING_READ (14) 31C141B0

May 23 00:18:18.739: TCB30C2B094 setting property TCP keepalive timeout (17) 31C141B0

May 23 00:18:18.739: TCB30C2B094 setting property TCP_VRFTABLEID (20) 31EB8F9C

May 23 00:18:18.739: TCB30C2B094 setting property TCP_NO_DELAY (0) 31C1416C

May 23 00:18:18.739: TCB30C2B094 setting property TCP_ALWAYSPUSH (15) 31C1416C

May 23 00:18:18.739: TCP: Random local port generated 25232, network 1

May 23 00:18:18.739: Reserved port 25232 in Transport Port Agent for TCP IP type 1

May 23 00:18:18.739: TCP: sending SYN, seq 1394113485, ack 0

May 23 00:18:18.739: TCP0: Connection to 10.113.127.11:1720, advertising MSS 1460

May 23 00:18:18.739: TCP0: state was CLOSED -> SYNSENT [25232 -> 10.113.127.11(1720)]

May 23 00:18:18.739: TCP0: state was SYNSENT -> ESTAB [25232 -> 10.113.127.11(1720)]

May 23 00:18:18.739: TCP: tcb 30C2B094 connection to 10.113.127.11:1720, peer MSS 1460, MSS is 1460

May 23 00:18:30.599: TCP0: state was ESTAB -> FINWAIT1 [25232 -> 10.113.127.11(1720)]

May 23 00:18:30.599: TCP0: sending FIN

May 23 00:18:30.599: TCP0: state was FINWAIT1 -> FINWAIT2 [25232 -> 10.113.127.11(1720)]

May 23 00:18:30.599: TCP0: FIN processed

May 23 00:18:30.599: TCP0: state was FINWAIT2 -> TIMEWAIT [25232 -> 10.113.127.11(1720)]

-debug h323 h245 event

May 22 20:28:58.313: Changing to new event: CONNECT

h323chan_chn_connect: connecting to 10.113.127.11:1720

May 22 20:28:58.313: h323chan_gw_conn: Created socket fd=2

May 22 20:28:58.313: h323chan_gw_conn: connect in progress on fd=2h323chan_chn_connect: using fd=2, owner_data(ccb) 0x2BB3DE10

changing from NONE state to CONNECTING state

May 22 20:28:58.317: h323chan_chn_process_read_socket: fd=2 of type CONNECT_PENDING has data

May 22 20:28:58.317: Changing to new event: CONNECTED

changing from CONNECTING state to CONNECTED state

May 22 20:28:58.317: h245_encode_faststart

May 22 20:28:58.317: h323chan_chn_process_read_socket: fd=2 of type CONNECTED has data

May 22 20:28:58.317: h323chan_recvdata: No Data on fd=2

PROCESS_READ: FAILED/NOT COMPLETE,rc 10, fd=2

May 22 20:29:13.317: h323chan_close: TCP connection from fd=2 closed

TIA

Cristian.

Nizar Abuseni · ‎05-29-2012

Hello Cristian,

This is realy strange behaviour, but there is suspected bug that might be the cause. Bug ID: CSCtw80016 , it would be better if you open TAC case and to check the CUCM traces to be sure if this bug is the one you are facing.

Regards,

Nizar

View solution in original post

Jaime Valencia · ‎05-23-2012

Was this working before?

Have you looked into routing/firewall/acl issues?

Are you binding the H323 signaling to the right interface/IP?

HTH

java

if this helps, please rate

www.cisco.com/go/pdihelpdesk

HTH

java

if this helps, please rate

cristian.munoz · ‎05-23-2012

Hi Java

Thanks for your answer.

Was this working before?

- Yes. It was in operation. I thought the same thing in a new installation (another client) and I had to performed a restart in the Publisher.

Have you looked into routing/firewall/acl issues?

- No, this is confirmed. Adding the GW IP address is in the same network than CUCM.

Are you binding the H323 signaling to the right interface/IP?

- Not required if you are on the same network.

TIA

Cristian.

cristian.munoz · ‎05-25-2012

Hi Guys

Same thing happened again. I configured a router pattern pointing to GW h323 , then I performed a call and receive congestion. Now the IP Address Status is Unknown.

Any Idea?

mparra.fusionet · ‎05-25-2012

As java said, make sure that the IOS GW has the proper interface binded for the H323 traffic, even if the server is in the same LAN, there is a good chance that this router does not have only one active IP interface, without the binding the IOS GW selects the interface to source the H323 dinamically and if the IP selected does not match what you have in CUCM it could be a problem.

If the interface is binded and this problem happens randomly I would feel this is somehow a CUCM software issue - can't garantee it- just a question, did resetting the GW in CUCM GUI does any good?

Also out of curiosity, could you please change the CCM-Group of that GW (Hence the DevicePool) to contain a different CUCM node than the current ones, just make sure that CUCM node has the CCM service running.

Hope this helps.

cristian.munoz · ‎05-28-2012

Dear MParra

My answers:

1.- Don´t have Loopback Interface.

interface GigabitEthernet0/0

description LAN-TIP-SW

ip address 10.113.127.17 255.255.255.0

duplex full

speed 1000

!

interface GigabitEthernet0/1

no ip address

shutdown

duplex auto

speed auto

!

interface GigabitEthernet0/2

no ip address

shutdown

duplex auto

speed auto

GW_PBX#sh interfaces gigabitEthernet 0/0

GigabitEthernet0/0 is up, line protocol is up

Hardware is CN Gigabit Ethernet, address is 24b6.5752.d740 (bia 24b6.5752.d740)

Description: LAN-TIP-SW

Internet address is 10.113.127.17/24

MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Full Duplex, 1Gbps, media type is RJ45

output flow-control is XON, input flow-control is XON

ARP type: ARPA, ARP Timeout 04:00:00

Last input 00:00:00, output 00:00:05, output hang never

Last clearing of "show interface" counters never

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue: 0/40 (size/max)

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

220625 packets input, 48379707 bytes, 0 no buffer

Received 9571 broadcasts (0 IP multicasts)

0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

0 watchdog, 8421 multicast, 0 pause input

274868 packets output, 51939715 bytes, 0 underruns

0 output errors, 0 collisions, 2 interface resets

0 unknown protocol drops

0 babbles, 0 late collision, 0 deferred

1 lost carrier, 0 no carrier, 0 pause output

0 output buffer failures, 0 output buffers swapped out

2.- After of Publisher restart, the GW go normal, but when I configure a route pattern and I performed a call, I receive fast busy and the GW lost the IP Status. Resetting the GW by CUCM GUI no change the IP Status Unknown.

3.- I performed this test and there no changes. I have another GW conected to PSTN while are working.

TIA

Cristian

Emmanuel Valdez · ‎05-27-2012

Hi,

The state of unknown of H323 gateway on CUCM is normal due to the nature of H323, is a point to point protocol, If you setup an MGCP gateway you will see the status for it on CUCM because it is a server-client protocol.

Bind your H323 interface on you Gateway and check full connectivity between CUCM and Gateway maybe is a problem on the LAN, for example switch port, speed, duplex, patch cord etc, If all is ok maybe is software bug.

Regards.

Sent from Cisco Technical Support iPhone App

cristian.munoz · ‎05-28-2012

Dear ef-molina

I refer to when you add a new H323 GW , after the reset, the CUCM must see the IP Addres, like this:

I see no error in the interface.

TIA

Cristian.

Nizar Abuseni · ‎05-28-2012

Hello Cristian,

Try to the following command on the router interface:

h323-gateway voip interface

This command enables VoIP GW functions on the interface.

Regards,

Nizar

cristian.munoz · ‎05-29-2012

Dear Nizar

I added the command, I performed a reset of the GW from CUCM and there no changes.

I've already done before

TIA
Cristian .

Nizar Abuseni · ‎05-29-2012

Hello Cristian,

This is realy strange behaviour, but there is suspected bug that might be the cause. Bug ID: CSCtw80016 , it would be better if you open TAC case and to check the CUCM traces to be sure if this bug is the one you are facing.

Regards,

Nizar

cristian.munoz · ‎06-05-2012

Dear Nizar

Thank you for your information. I performed a upgrade of CUCM and I will show you the result.

TIA

Cristian.

cristian.munoz · ‎06-07-2012

Dear Nizar

I performed the update to CUCM version 8.6.2.21900-5 and the problem is solved.

Thank you again.

Regards

Cristian Munoz