Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

SCN Issue

Status
Not open for further replies.

MikeSide

Technical User
Jan 8, 2013
112
CA
Hi everyone,

I have a big weird problem with 2 new system on scn. I explain,

S1 : 8.1(63) + VM PRO
S2 : 8.1(65) + VM PRO

I have put the small community between the two system. Everything work fine at first shot. The second day, we make a change and need to reboot the S2. After the reboot, it impossible to make a call interSite. The link are UP each site. That ping each site. the network are a point to point with all port open.

So what i've do for that :
1 - Reboot all system
2 - Reboot the 2 routeurs
3 - Delete H323 Line and recreate
4 - Centralize the VM at S2 and S1 as the main VM

Nothing work so i put my SCN config at H450 and create shortcode 2XX/Dial/2N/18... That Work....

I have pass more then 14 hours and put 3 tech on the problem, nobody find it...

so if somebody have the miracle solution... please tell me your secret !!!

Thank
 
Impossible to say without a proper trace.
But i'll bet on routing or router blocking the SCN.


BAZINGA!

I'm not insane, my mother had me tested!

 
how the router can block the scn...

First, that working the first time i put it, just after a reboot that stop to work...
second, all the port are open on both site
and the H450 working fine...

So what can cause the problem on the router.

By trace you want to say the monitor.. if that i can start it and copy the trace here.
 
No vpn, that a point to point by fiber between the two site
 
Why do you use routers with a point to point fiber?
I would use two switches for that.
That point to point fiber is going from site to site or through some kind of provider?


BAZINGA!

I'm not insane, my mother had me tested!

 
Ok i have ask at the IT

he have a watchgard on site 1 and juniper at site 2
 
How can i see if the router drop udp packets, i dont have access at the router...
 
and for the IT the router are not the problem
 
That is what they alway say :)


BAZINGA!

I'm not insane, my mother had me tested!

 
if switching of SCN works then H323 traffic is working (ports 1719/1720 for setup & Ports 49152 upwards for speech packets)

This means it must be the SCN signaling that is getting blocked (50795)

Check my Voip Trouble shooting guide in thread
Pay special attention to step 2 :)






A Maintenance contract is essential, not a Luxury.
Do things on the cheap & it will cost you dear
 
OK, id be interested to see the policy on the watchguard.

It should be an allow rule from the optional (where the fibre terminates) to trusted and vice versa all ports (e.g any = 0)

Juniper - I wouldn't know! :)

ACSS - SME
General Geek

 
The IT send me that log


2013-06-13 11:30:46
FWAllow, Allowed, pri=4, disp=Allow, policy=FIBRE-00, protocol=1720/tcp, src_ip=192.168.2.254, src_port=4151, dst_ip=10.0.0.253, dst_port=1720, src_intf=3-Optional-2, dst_intf=1-Trusted, rc=100, pckt_len=44, ttl=95, pr_info=offset 6 S 5780 win 32
2013-06-13 11:31:02
FWAllow, Allowed, pri=4, disp=Allow, policy=FIBRE-00, protocol=1720/tcp, src_ip=192.168.2.254, src_port=4152, dst_ip=10.0.0.253, dst_port=1720, src_intf=3-Optional-2, dst_intf=1-Trusted, rc=100, pckt_len=44, ttl=95, pr_info=offset 6 S 1488 win 32
2013-06-13 11:31:14
FWAllow, Allowed, pri=4, disp=Allow, policy=FIBRE2-00, protocol=1720/tcp, src_ip=10.0.0.253, src_port=4161, dst_ip=192.168.2.254, dst_port=1720, src_intf=1-Trusted, dst_intf=3-Optional-2, rc=100, pckt_len=44, ttl=98, pr_info=offset 6 S 20515 win 32
2013-06-13 11:31:47
FWAllow, Allowed, pri=4, disp=Allow, policy=FIBRE-00, protocol=1720/tcp, src_ip=192.168.2.254, src_port=4153, dst_ip=10.0.0.253, dst_port=1720, src_intf=3-Optional-2, dst_intf=1-Trusted, rc=100, pckt_len=44, ttl=95, pr_info=offset 6 S 55423 win 32
2013-06-13 11:32:29
FWAllow, Allowed, pri=4, disp=Allow, policy=FIBRE2-00, protocol=1720/tcp, src_ip=10.0.0.253, src_port=4162, dst_ip=192.168.2.254, dst_port=1720, src_intf=1-Trusted, dst_intf=3-Optional-2, rc=100, pckt_len=44, ttl=98, pr_info=offset 6 S 20040 win 32
2013-06-13 11:32:31
FWAllow, Allowed, pri=4, disp=Allow, policy=FIBRE-00, protocol=1720/tcp, src_ip=192.168.2.254, src_port=4154, dst_ip=10.0.0.253, dst_port=1720, src_intf=3-Optional-2, dst_intf=1-Trusted, rc=100, pckt_len=44, ttl=95, pr_info=offset 6 S 43567 win 32
2013-06-13 11:33:17
FWAllow, Allowed, pri=4, disp=Allow, policy=FIBRE-00, protocol=1720/tcp, src_ip=192.168.2.254, src_port=4155, dst_ip=10.0.0.253, dst_port=1720, src_intf=3-Optional-2, dst_intf=1-Trusted, rc=100, pckt_len=44, ttl=95, pr_info=offset 6 S 31967 win 32
2013-06-13 11:33:44
FWAllow, Allowed, pri=4, disp=Allow, policy=FIBRE2-00, protocol=1720/tcp, src_ip=10.0.0.253, src_port=4163, dst_ip=192.168.2.254, dst_port=1720, src_intf=1-Trusted, dst_intf=3-Optional-2, rc=100, pckt_len=44, ttl=98, pr_info=offset 6 S 20077 win 32
2013-06-13 11:34:02
FWAllow, Allowed, pri=4, disp=Allow, policy=FIBRE-00, protocol=1720/tcp, src_ip=192.168.2.254, src_port=4156, dst_ip=10.0.0.253, dst_port=1720, src_intf=3-Optional-2, dst_intf=1-Trusted, rc=100, pckt_len=44, ttl=95, pr_info=offset 6 S 20111 win 32
2013-06-13 11:34:47
FWAllow, Allowed, pri=4, disp=Allow, policy=FIBRE-00, protocol=1720/tcp, src_ip=192.168.2.254, src_port=4157, dst_ip=10.0.0.253, dst_port=1720, src_intf=3-Optional-2, dst_intf=1-Trusted, rc=100, pckt_len=44, ttl=95, pr_info=offset 6 S 7999 win 32
2013-06-13 11:34:49
FWAllow, Allowed, pri=4, disp=Allow, policy=FIBRE-00, protocol=icmp, src_ip=192.168.2.254, dst_ip=10.0.0.253, src_intf=3-Optional-2, dst_intf=1-Trusted, rc=100, pckt_len=60, ttl=95
2013-06-13 11:34:50
FWAllow, Allowed, pri=4, disp=Allow, policy=FIBRE-00, protocol=icmp, src_ip=192.168.2.254, dst_ip=10.0.0.253, src_intf=3-Optional-2, dst_intf=1-Trusted, rc=100, pckt_len=60, ttl=95
 
Maybe downgrade the both system at another firmware fix the problem ?
 
This looks like H225 call setup Re-Enable SCN on both sides then ask them to filter for UPD traffic on port 50795.

Even if the SCN is up, that is not a guarantee, that calls will traverse the network. We have an ongoing issue, and an open ticket with Checkpoint re exactly this. Three of our remote sites have H450 -type h323 trunks, because although the SCN comes up at the remotes, and AVRIP traffic passes each way, the call setup requests are being received and dropped, by the Checkpoint UTM at the central site. No rules in place that cause this.

Version 8.165 + VM Pro has issues with unrecognized dmtf over SCN trunk so I wouldn't use it at all. Also only one VM pro supported in an SCN unless it is a distributed or backup VM server.
 
2013-06-12 17:27:29
FWAllow, Allowed, pri=4, disp=Allow, policy=FIBRE2-00, protocol=50795/udp, src_ip=10.0.0.253, src_port=50795, dst_ip=192.168.2.254, dst_port=50795, src_intf=1-Trusted, dst_intf=3-Optional-2, rc=100, pckt_len=43, ttl=98
2013-06-13 17:46:23
FWAllow, Allowed, pri=4, disp=Allow, policy=FIBRE2-00, protocol=50795/udp, src_ip=10.0.0.253, src_port=50795, dst_ip=192.168.2.254, dst_port=50795, src_intf=1-Trusted, dst_intf=3-Optional-2, rc=100, pckt_len=43, ttl=98
2013-06-13 17:46:33
FWAllow, Allowed, pri=4, disp=Allow, policy=FIBRE2-00, protocol=50795/udp, src_ip=10.0.0.253, src_port=50795, dst_ip=192.168.2.254, dst_port=50795, src_intf=1-Trusted, dst_intf=3-Optional-2, rc=100, pckt_len=43, ttl=98
2013-06-14 05:46:59
FWAllow, Allowed, pri=4, disp=Allow, policy=FIBRE-00, protocol=50795/udp, src_ip=192.168.2.254, src_port=50795, dst_ip=10.0.0.253, dst_port=50795, src_intf=3-Optional-2, dst_intf=1-Trusted, rc=100, pckt_len=43, ttl=95
2013-06-14 05:47:08
FWAllow, Allowed, pri=4, disp=Allow, policy=FIBRE-00, protocol=50795/udp, src_ip=192.168.2.254, src_port=50795, dst_ip=10.0.0.253, dst_port=50795, src_intf=3-Optional-2, dst_intf=1-Trusted, rc=100, pckt_len=43, ttl=95
 
that all from the wachwgard...

For the Jupiner.. No syslog server on the router...
 
on the jupiner we have found a

H323 and sip check on application layer gateway, that what you talking about ?
 
we have found something else

H323 Menu -- Check enable

Application screen :
Nat mode (unchek)
Route mode (uncheck)
Get source port any (uncheck)
Message flood (uncheck)
 
Easiest way to point the finger at the right person/device is to take one of the systems to the other and connect them locally, I would wager it works fine. SCN stopping after a period is typical of a router causing it, the system reboot clearing it is a red herring as it just stops the traffic it's blocking for enough time that it then allows it once its back up...at least that's what I've seen in the past :)



"No problem monkey socks
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top