TB responds with"UNREACHABLE" to this GW

voretl
Posts: 40
Member Since:
2006-07-04

Hi,,,
Not sure if this is a common problem or not but it is the first time I have seen it on a GW.

I recently had to change out router that feeds the TB. I then noticed that the GW showed up as UNREACHABLE, bbuutt, I can ping the GW from root login and it responds in .5 to 1ms. Different networks but same router and this router is also the GW. This is the ONLY device and trunk, that is failing. The TB Network also feeds several local phones, which work fine. The TB Network originates from a VLAN interface tied to a fastethernet physical interface, unlike the first router which was a physical interface, no VLAN interface..Here is the logfile::

[Sep 26 09:42:00] VERBOSE[14764] logger.c: -- Called Cebu-GW/324163150
[Sep 26 09:42:32] NOTICE[2932] chan_sip.c: Auto-congesting SIP/Cebu-GW-b7c68790
[Sep 26 09:42:32] VERBOSE[14764] logger.c: -- SIP/Cebu-GW-b7c68790 is circuit-busy
[Sep 26 09:42:32] VERBOSE[14764] logger.c: == Everyone is busy/congested at this time (1:0/1/0)
[Sep 26 09:42:32] VERBOSE[14764] logger.c: -- Executing [s@macro-dialout-trunk:20] [1;36;40mGoto[0;37;40m("[1;35;40mSIP/6451-b7226178[0;37;40m", "[1;35;40ms-CONGESTION,1[0;37;40m") in new stack
[Sep 26 09:42:32] VERBOSE[14764] logger.c: -- Goto (macro-dialout-trunk,s-CONGESTION,1)
[Sep 26 09:42:32] VERBOSE[14764] logger.c: -- Executing [s-CONGESTION@macro-dialout-trunk:1] [1;36;40mGotoIf[0;37;40m("[1;35;40mSIP/6451-b7226178[0;37;40m", "[1;35;40m1?noreport[0;37;40m") in new stack
[Sep 26 09:42:32] VERBOSE[14764] logger.c: -- Goto (macro-dialout-trunk,s-CONGESTION,3)
[Sep 26 09:42:32] VERBOSE[14764] logger.c: -- Executing [s-CONGESTION@macro-dialout-trunk:3] [1;36;40mNoOp[0;37;40m("[1;35;40mSIP/6451-b7226178[0;37;40m", "[1;35;40mTRUNK Dial failed due to CONGESTION - failing through to other trunks[0;37;40m") in new stack
[Sep 26 09:42:32] VERBOSE[14764] logger.c: -- Executing [324163150@from-internal:5] [1;36;40mMacro[0;37;40m("[1;35;40mSIP/6451-b7226178[0;37;40m", "[1;35;40moutisbusy,[0;37;40m") in new stack
[Sep 26 09:42:32] VERBOSE[14764] logger.c: -- Executing [s@macro-outisbusy:1] [1;36;40mPlayback[0;37;40m("[1;35;40mSIP/6451-b7226178[0;37;40m", "[1;35;40mall-circuits-busy-now,noanswer[0;37;40m") in new stack
[Sep 26 09:42:32] VERBOSE[14764] logger.c: -- Playing 'all-circuits-busy-now.ulaw' (language 'en')
[Sep 26 09:42:34] VERBOSE[14764] logger.c: -- g729 frames
[Sep 26 09:42:34] VERBOSE[14764] logger.c: -- length: count
[Sep 26 09:42:34] VERBOSE[14764] logger.c: -- Executing [s@macro-outisbusy:2] [1;36;40mPlayback[0;37;40m("[1;35;40mSIP/6451-b7226178[0;37;40m", "[1;35;40mpls-try-call-later,noanswer[0;37;40m") in new stack
[Sep 26 09:42:34] VERBOSE[14764] logger.c: -- Playing 'pls-try-call-later.ulaw' (language 'en')
[Sep 26 09:42:36] VERBOSE[14764] logger.c: -- g729 frames
[Sep 26 09:42:36] VERBOSE[14764] logger.c: -- length: count
[Sep 26 09:42:36] VERBOSE[14764] logger.c: -- Executing [s@macro-outisbusy:3] [1;36;40mMacro[0;37;40m("[1;35;40mSIP/6451-b7226178[0;37;40m", "[1;35;40mhangupcall[0;37;40m") in new stack
[Sep 26 09:42:36] VERBOSE[14764] logger.c: -- Executing [s@macro-hangupcall:1] [1;36;40mGotoIf[0;37;40m("[1;35;40mSIP/6451-b7226178[0;37;40m", "[1;35;40m1?skiprg[0;37;40m") in new stack
[Sep 26 09:42:36] VERBOSE[14764] logger.c: -- Goto (macro-hangupcall,s,4)
[Sep 26 09:42:36] VERBOSE[14764] logger.c: -- Executing [s@macro-hangupcall:4] [1;36;40mGotoIf[0;37;40m("[1;35;40mSIP/6451-b7226178[0;37;40m", "[1;35;40m1?skipblkvm[0;37;40m") in new stack
[Sep 26 09:42:36] VERBOSE[14764] logger.c: -- Goto (macro-hangupcall,s,7)
[Sep 26 09:42:36] VERBOSE[14764] logger.c: -- Executing [s@macro-hangupcall:7] [1;36;40mGotoIf[0;37;40m("[1;35;40mSIP/6451-b7226178[0;37;40m", "[1;35;40m1?theend[0;37;40m") in new stack
[Sep 26 09:42:36] VERBOSE[14764] logger.c: -- Goto (macro-hangupcall,s,9)
[Sep 26 09:42:36] VERBOSE[14764] logger.c: -- Executing [s@macro-hangupcall:9] [1;36;40mHangup[0;37;40m("[1;35;40mSIP/6451-b7226178[0;37;40m", "[1;35;40m[0;37;40m") in new stack
[Sep 26 09:42:36] VERBOSE[14764] logger.c: == Spawn extension (macro-hangupcall, s, 9) exited non-zero on 'SIP/6451-b7226178' in macro 'hangupcall'
[Sep 26 09:42:36] VERBOSE[14764] logger.c: == Spawn extension (macro-outisbusy, s, 3) exited non-zero on 'SIP/6451-b7226178' in macro 'outisbusy'
[Sep 26 09:42:36] VERBOSE[14764] logger.c: == Spawn extension (from-internal, 324163150, 5) exited non-zero on 'SIP/6451-b7226178'
[Sep 26 09:42:36] VERBOSE[14764] logger.c: -- Executing [h@from-internal:1] [1;36;40mMacro[0;37;40m("[1;35;40mSIP/6451-b7226178[0;37;40m", "[1;35;40mhangupcall[0;37;40m") in new stack
[Sep 26 09:42:36] VERBOSE[14764] logger.c: -- Executing [s@macro-hangupcall:1] [1;36;40mGotoIf[0;37;40m("[1;35;40mSIP/6451-b7226178[0;37;40m", "[1;35;40m1?skiprg[0;37;40m") in new stack
[Sep 26 09:42:36] VERBOSE[14764] logger.c: -- Goto (macro-hangupcall,s,4)
[Sep 26 09:42:36] VERBOSE[14764] logger.c: -- Executing [s@macro-hangupcall:4] [1;36;40mGotoIf[0;37;40m("[1;35;40mSIP/6451-b7226178[0;37;40m", "[1;35;40m1?skipblkvm[0;37;40m") in new stack
[Sep 26 09:42:36] VERBOSE[14764] logger.c: -- Goto (macro-hangupcall,s,7)
[Sep 26 09:42:36] VERBOSE[14764] logger.c: -- Executing [s@macro-hangupcall:7] [1;36;40mGotoIf[0;37;40m("[1;35;40mSIP/6451-b7226178[0;37;40m", "[1;35;40m1?theend[0;37;40m") in new stack
[Sep 26 09:42:36] VERBOSE[14764] logger.c: -- Goto (macro-hangupcall,s,9)
[Sep 26 09:42:36] VERBOSE[14764] logger.c: -- Executing [s@macro-hangupcall:9] [1;36;40mHangup[0;37;40m("[1;35;40mSIP/6451-b7226178[0;37;40m", "[1;35;40m[0;37;40m") in new stack
[Sep 26 09:42:36] VERBOSE[14764] logger.c: == Spawn extension (macro-hangupcall, s, 9) exited non-zero on 'SIP/6451-b7226178' in macro 'hangupcall'
[Sep 26 09:42:36] VERBOSE[14764] logger.c: == Spawn extension (from-internal, h, 1) exited non-zero on 'SIP/6451-b7226178'
[Sep 26 09:42:36] WARNING[2795] pbx.c: FONALITY: This thread has already held the conlock, skip locking
[Sep 26 09:42:40] VERBOSE[14768] logger.c: == Manager 'admin' logged on from 127.0.0.1

Any thoughts or suggestions would be helpful. My last option would be to add another FE to the chassis and I'm willing to do that if no other option is available

Any one had a similar experience???????????

Thanks
Terry



Atcom Alberta
Posts: 220
Member Since:
2008-07-14
What happens if you remove

What happens if you remove your "LOCALNET" settings from sip_nat.conf?



voretl
Posts: 40
Member Since:
2006-07-04
TB & GW

Thank you for your response...

Actually, I did not have any entries for the localnet, just the NAT piece.. I added the LOCALNET and the audio stopped working on several remotes phones, so I removed it and the audio restored. Either way it made no difference on the GW, it remained "unreachable"



voretl
Posts: 40
Member Since:
2006-07-04
TB & GW

OK,,,

Did more digging and found the solution.. I needed to add the bind media and control message statements to the virtual interface and not the interface that frontends the Inet. Hair pulling is done , I don't have much to spare..

Thank You



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.