06-28-2007 12:39 PM
I have installed a long time ago two 1750 routers and one 2610, that had serial connections. Then, my costumer started evolving his network and wanted to put up VoIP. At the time, the available IOS was 12.0(7)T and the config was based on multilink interfaces.
Meanwhile, the same costumer became interested in V3PN, but realized that the existing routers, though old and now unsupported, fitted his purposes with VoIP over IPSec over ADSL. After recommending the routers replacement and being ignored, I started the tortuous process of implementing a WIC-1ADSL on the 1750 routers and implementing IPSec. The tunnels are up and running and the data packets flow without problems. As anyone can imagine, it was a headache to find an appropriate IOS - 12.2(8)TPC10b - the latest one available to the 1750 routers.
After the implementation of IPSec and data flow, I removed the serial interfaces and it was time to put the voice up to work with the IPSec tunnels, because it was already working with the serial interface before, which was merely (I thought, after being surprised the ADSL an IPSec worked fine) a question of sending voice packets over the IPSec, with the best QoS possible.
From the way from the 2610 router to the 1750 routers, I can establish a h.323 voice session and talk normally. From the 1750 #1 to the 1750 #2 and from these to the 2610, I can't even connect a session, it fails, I believe on the Hook Up event, or at least on the number dial. The 2610 has an ASA5510 making the Internet border, but the data flow is ok, and the ACLs that define the encrypted traffic are working nicelly.
I really can't see what the problem is.
TIA.
Cheers,
Nelson Neves
06-28-2007 12:43 PM
I'll try to post up the configs and the debugs I made, but the server keeps returning me servlet errors, can't promisse I can make this.
Cheers,
Nelson Neves
06-28-2007 02:07 PM
Hi, excuse the basic question, do you have connectivity between the 1750's, check via ping to the h323 bind interface, source from the h323 bind interface.
06-29-2007 02:22 AM
Hi, yes, I have connectivity between all the involved IP Addresses. The data packets flow nicely over the IPSec. The voice calls never come out of the router.
The logic diagram (ascii) is like this:
-2610
192.168.10.254 - eth0
192.168.254.254 - lo0
3.. - dial-peer
- 1750 #1
192.168.30.254 - eth0
192.168.254.252 - lo0
4.. - dial-peer
- 1750 #2
192.168.20.254 - eth0
192.168.254.253 - lo0
5.. - dial-peer
2610 --- AS5510 --- Internet --- 1750 #1 and #2
Cheers,
Nelson Neves
06-29-2007 02:31 AM
Below is one of the debugs I made from a call being csimed from router 1750 #2 to 2610.
Debug VOIP CCAPI INOUT (1750 #2 to 2610) - doesn't work
-----------------------------------------
RP1#csim start 309
csim err:csim_do_test invalid major major(16) minor(0)
RP1#
1d02h: csim: called number = 309, loop count = 1 ping count = 0
1d02h: ccAppInitialize (name=CSIM , appHandle=0x82136680)
1d02h: csimSetupPeer peer type(2), destPat(309), matched(1), target()
1d02h: ccCallSetupRequest (Inbound call = 0xFFFFFFFF, outbound peer =3, dest=, params=0x82135BF0 mode=0, *callID=0x82136020, prog_ind = 0) callingIE_present 0
1d02h: ccCallSetupRequest numbering_type 0x0
1d02h: ccCallSetupRequest encapType 2 clid_restrict_disable 1 null_orig_clg 0 clid_transparent 0 callingNumber
1d02h: dest pattern 3.., called 309, digit_strip 0
1d02h: callingNumber=, calledNumber=309, redirectNumber= display_info= calling_oct3a=0
1d02h: accountNumber=, finalDestFlag=0,
guid=0000.0000.0000.0000.0000.0000.0000.0000
1d02h: peer_tag=3
1d02h: ccIFCallSetupRequestPrivate: (vdbPtr=0x81DC862C, dest=, callParams={called=309,called_oct3=0x0, calling=,calling_oct3=0x0, calling_xlated=false, subscriber_type_str=, fdest=0, voice_peer_tag=3},mode=0x0) vdbPtr type = 1
1d02h: ccIFCallSetupRequestPrivate: (vdbPtr=0x81DC862C, dest=, callParams={called=309, called_oct3 0x0, calling=,calling_oct3 0x0, calling_xlated=false, fdest=0, voice_peer_tag=3}, mode=0x0, xltrc=-5)
1d02h: cc_insert_call_entry: not incoming entry
1d02h: cc_insert_call_entry: entry's incoming FALSE. is_incoming is FALSE
1d02h: ccCallSetContext (callID=0x14, context=0x81D67704)
1d02h: cc_api_supported_data data_mode=0x10002
1d02h: cc_incr_if_call_volume: remote IP is 192.168.254.254
1d02h: cc_incr_if_call_volume: hwidb is Dialer1
1d02h: cc_incr_if_call_volume: create entry in list: 1
1d02h: csim: loop = 1, failed = 0
1d02h: csim: call attempted = 1, setup failed = 0, tone failed = 0
1d02h: ccCallDisconnect (callID=0x14, cause=0x2F tag=0x0)
1d02h: cc_api_get_transfer_info: (callID=0x14)
1d02h: cc_api_icpif: expect factor = 0
1d02h: cc_decr_if_call_volume: the remote IP is 192.168.254.254
1d02h: cc_decr_if_call_volume: hwidb is Dialer1
1d02h: cc_decr_if_call_volume: reduce callnum of entry: 0, voip: 0, mmoip: 0
1d02h: cc_decr_if_call_volume: remove an entry
1d02h: cc_api_call_disconnect_done(vdbPtr=0x81DC862C, callID=0x14, disp=0, tag=0x0)
1d02h: cc_delete_call_entry: not incoming entry
1d02h: cc_delete_call_entry: entry's incoming FALSE. is_incoming is FALSE
Cheers,
Nelson Neves
06-29-2007 03:31 AM
Hello,
not to insist, but I'm afraid the call can start with the wrong source address.
Do you have h323 bind statements to the loopback interfaces ?
07-02-2007 01:45 AM
Hi,
No problem about insisting :) I really am startled with this situation, so any sugestion is a good one. Nonetheless, I'm affraid that posting an attach in the forum returns errors to me, so I'll post the necessary.
Here's the main loopback configuration:
interface Loopback0
ip address 192.168.254.253 255.255.255.255
h323-gateway voip interface
h323-gateway voip bind srcaddr 192.168.254.253
The configuration is the same on 1750 #1 and #2. The 2610 IOS doesn't have the necessary commands, so the connection always comes from the ethernet interface.
Cheers,
Nelson Neves
07-02-2007 07:58 AM
This is surprising. The 2610 is probably starting the call with the wrong interface and succeeds, while the ones that do have loopback binded to H.323 can't.
Anyway, do you have the looback interfaces / 2610 in the access-list applied to the crypto map, and viceversa at the hub ? Or perhaps you have an IPsec tunnel straight betwwen spokes.
If no real need for encryption, would you consider running this over GRE tunnels instead for a smaller overhead and easier life ?
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: