| Walenta, Phil 2005-09-15, 2:45 am |
| Just curious here, in your CallManager H.323 gateway definition, does the IP address show up in a state of "unregistered"? If so, try issuing a reset from that CallManager page.
________________________________
From: cisco-voip-bounces@puck.nether.net on behalf of Trey Howland
Sent: Wed 9/14/2005 8:59 PM
To: Kevin Thorngren
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] H323 and Callmanager Issues
After some more digging, it seems to be a VRF issue. Below is the
output of debug ip packet and debug h225 events. I see some packets
sent out the wrong interface. G0/1960 is in the global routing table.
Trey
002337: *Sep 15 01:45:04.880 UTC: Changing to new event: CONNECT
h323chan_chn_connect: connecting to 10.10.10.1:1720
002338: *Sep 15 01:45:04.880 UTC: h323chan_gw_conn: Created socket fd=4
002339: *Sep 15 01:45:04.880 UTC: IP: tableid=0, s=10.4.1.2 (local),
d=10.10.10.1 (GigabitEthernet0/0.1960), routed via FIB
002340: *Sep 15 01:45:04.880 UTC: h323chan_gw_conn: connect in progress
on fd=4h323chan_chn_connect: using fd=4, owner_data(ccb) 0x459C4798
changing from NONE state to CONNECTING state
002341: *Sep 15 01:45:04.884 UTC: IP: tableid=1, s=10.10.10.1
(GigabitEthernet0/0.1760), d=10.4.1.2 (GigabitEthernet0/0.1760), routed
via RIB
002342: *Sep 15 01:45:04.884 UTC: IP: s=10.10.10.1
(GigabitEthernet0/0.1760), d=10.4.1.2 (GigabitEthernet0/0.1760), len
44, rcvd 3
002343: *Sep 15 01:45:04.884 UTC: IP: tableid=1, s=10.4.1.2 (local),
d=10.10.10.1 (GigabitEthernet0/0.1760), routed via FIB
002344: *Sep 15 01:45:04.884 UTC: IP: s=10.4.1.2 (local), d=10.10.10.1
(GigabitEthernet0/0.1760), len 40, sending
002345: *Sep 15 01:45:06.880 UTC: IP: tableid=0, s=10.4.1.2 (local),
d=10.10.10.1 (GigabitEthernet0/0.1960), routed via FIB
002346: *Sep 15 01:45:06.880 UTC: IP: tableid=1, s=10.10.10.1
(GigabitEthernet0/0.1760), d=10.4.1.2 (GigabitEthernet0/0.1760), routed
via RIB
002347: *Sep 15 01:45:06.880 UTC: IP: s=10.10.10.1
(GigabitEthernet0/0.1760), d=10.4.1.2 (GigabitEthernet0/0.1760), len
44, rcvd 3
002348: *Sep 15 01:45:06.880 UTC: IP: tableid=1, s=10.4.1.2 (local),
d=10.10.10.1 (GigabitEthernet0/0.1760), routed via FIB
002349: *Sep 15 01:45:06.880 UTC: IP: s=10.4.1.2 (local), d=10.10.10.1
(GigabitEthernet0/0.1760), len 40, sending
002350: *Sep 15 01:45:07.880 UTC: h323chan_close: TCP connection from
fd=4 closed
002351: *Sep 15 01:45:07.880 UTC: Changing to new event: CONNECT
h323chan_chn_connect: connecting to 10.10.10.2:1720
002352: *Sep 15 01:45:07.880 UTC: h323chan_gw_conn: Created socket fd=4
002353: *Sep 15 01:45:07.880 UTC: IP: tableid=0, s=10.4.1.2 (local),
d=10.10.10.2 (GigabitEthernet0/0.1960), routed via FIB
002354: *Sep 15 01:45:07.884 UTC: h323chan_gw_conn: connect in progress
on fd=4h323chan_chn_connect: using fd=4, owner_data(ccb) 0x459C4798
changing from NONE state to CONNECTING state
002355: *Sep 15 01:45:07.884 UTC: IP: tableid=1, s=10.10.10.2
(GigabitEthernet0/0.1760), d=10.4.1.2 (GigabitEthernet0/0.1760), routed
via RIB
002356: *Sep 15 01:45:07.884 UTC: IP: s=10.10.10.2
(GigabitEthernet0/0.1760), d=10.4.1.2 (GigabitEthernet0/0.1760), len
44, rcvd 3
002357: *Sep 15 01:45:07.884 UTC: IP: tableid=1, s=10.4.1.2 (local),
d=10.10.10.2 (GigabitEthernet0/0.1760), routed via FIB
002358: *Sep 15 01:45:07.884 UTC: IP: s=10.4.1.2 (local), d=10.10.10.2
(GigabitEthernet0/0.1760), len 40, sending
002359: *Sep 15 01:45:09.884 UTC: IP: tableid=0, s=10.4.1.2 (local),
d=10.10.10.2 (GigabitEthernet0/0.1960), routed via FIB
002360: *Sep 15 01:45:09.884 UTC: IP: tableid=1, s=10.10.10.2
(GigabitEthernet0/0.1760), d=10.4.1.2 (GigabitEthernet0/0.1760), routed
via RIB
002361: *Sep 15 01:45:09.884 UTC: IP: s=10.10.10.2
(GigabitEthernet0/0.1760), d=10.4.1.2 (GigabitEthernet0/0.1760), len
44, rcvd 3
002362: *Sep 15 01:45:09.884 UTC: IP: tableid=1, s=10.4.1.2 (local),
d=10.10.10.2 (GigabitEthernet0/0.1760), routed via FIB
002363: *Sep 15 01:45:09.884 UTC: IP: s=10.4.1.2 (local), d=10.10.10.2
(GigabitEthernet0/0.1760), len 40, sending
002364: *Sep 15 01:45:10.884 UTC: h323chan_close: TCP connection from
fd=4 closed
On Sep 14, 2005, at 9:19 PM, Kevin Thorngren wrote:
> Not sure if being in a VRF would be an issue or not. I have not
> configured this myself. If the CCM has connectivity to 10.4.1.2 then
> I suspect it should work. A packet capture of the GW might help
> determine if there is a TCP connectivity problem. You might not see
> anything useful in the CCM trace if the problem is with creating the
> TCP connection.
>
> Not sure which version of CCM 4.1 you are running but if it is 4.1(3)
> then you might be running into a known issue with change notification.
> If the nodes being pointed to by the dial peers don't receive change
> notification for the new CCMAdmin config changes then they won't know
> about the H.323 GW and will reject the TCP connection. Restarting
> the CCM service is the workaround for this issue and the issue is
> resolved in 4.1(3)sr1.
>
> Kevin
> On Sep 14, 2005, at 8:17 PM, Trey Howland wrote:
>
>
>
Georgia Institute of Technology Atlanta, Georgia
Georgia Tech Research Institute Voice (404)894-7134
Electronic Systems Laboratory Fax (404)894-7080
Public Key ID: 0x894F4419
[7338 D848 8BEE FF6D 23D1 4355 2F6C DE0C 894F 4419]
________________________________________
_______
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
|