Hi, dear!
Good day to you!
This article describes a public and private network call problem. Please see below.
Issue description
A customer stated that he cannot perform a call between an endpoint in his private network and another endpoint in the public network. In his VC infrastructure, the customer has an SMC, SC, and a few RP200. The SMC is in the same network with the endpoints. The SC has two network adapters configured on DMZ, and LAN1 connects to the SMC and endpoints network and the LAN2 connects to the internet.
SMC: 172.**.**.10/24 GW 172.**.**.253, endpoint 172.**.**.22/24 GW 172.**.**.253
SC: Lan1 192.**.**.31/24 GW 192.**.**.1, LAN2 192.**.**.31 GW 192.**.**.131
He configured some static routes on the SC for his SMC and endpoints to be able to communicate with the SC LAN1 and the default route on LAN2.
His endpoints are registered on the SMC and SC. When he attempted a point-to-point call, everything works, however when he tried to make a Business to Business call it seemed the call did not go to LAN2 and so the call failed.
Handling Process
In order to further troubleshoot the reported issue, we have requested the following information from the customer:
Signaling diagnostics (start the signaling capture, reproduce the issue and afterwards end the trace and export it) retrieved from the SC as per below procedure:
Web captures extraction
Connect to the web interface of the device with admin credentials.
From the SMC2.0 home page， go to Devices > Switch Centers and check the SC that you need.
Capture the web page from the Registered Nodes tab to see the list of registered devices and information: IP, what access zone the node belongs to, and other information.
At the Logs tab, check the Device logs and click on the Export button.
At the Signaling Diagnosis tab, click the Start Diagnosis and then replicate the issue.
After the test call exports the signaling diagnosis file.
Log Operations
On the SMC2.0 web interface, the authorized users can view and sort logs and export logs that generated in a specified period.
The SMC2.0 also allows system administrators and authorizes users to export debug logs for problem location and analysis. This is an important means for troubleshooting. In debug logs, the different levels and usage are as follows: Logs of debug level are used for debug information, trace level for detailed running information, warn level for warning information, error level for system running error information, and fatal level for information that causes system running environment damage and function disablement. During log analysis, pay attention to logs of the warn, error, and fatal levels. Certain keywords and error codes in logs also help you quickly locate problems.
The following describes how to view and export logs on the SMC2.0 web interface.
Viewing logs
Log in to SMC2.0 web interface.
Choose System > Logs.
All logs are displayed.
Exporting logs
Log in to the SMC2.0 web interface.
Choose System > Logs.
Click a tab and then Export. In the Export dialog box that is displayed, set start date and End date and click Export.
Logs that are generated in the specified time range are exported.
Test exact call flow while the issue is being reproduced so we can check the logs (calling party, called party, type of endpoints involved, date, and time)
We have analyzed the Wireshark capture provided and we can see that the Switch Centre rejects the call with the below reason:
As you can see from the screenshot below and Wireshark capture above the service address for the SC configured is 192.**.**.31 even if the LAN2 port is used for communication with the public internet and used as a default route
Under the service address in the details part, you should have both IP addresses for LAN1 and LAN2 but we can notice that the LAN 2 port has not been configured as per our product documentation. As such we suggest to follow the SMC2.0 product documentation and check the part traversal between public and private networks with a standalone SC, chapter Deploying a Single SC in the DMZ (Dual Network Adapters):
Since the customer does not have both service IP addresses configured we recommend checking again and configure also LAN2 IP address 192.**.**.31 by using the command:
system-view sys-config security-config service-ip add ip 192.**.**.131
Check the service IP address of the SC and ensure that the IP addresses of the lan1 and lan2 ports are both set to the service IP address.
display service-ip
172.16.100.96
172.17.100.96
TotalItemNum:2
If the SC does not identify the two IP addresses as the service IP address, run the following command to add the missing IP address:
system-view sys-config security-config service-ip add ip 172.**.**.96
Configure the lan2 port as the default route port.
system-view sys-config network-config default-route lan lan2
Configure a static route from the lan1 port to the Trust zone.
system-view static-route add dest-address 192.168.0.0 mask-or-prefix 255.255.0.0 network-port lan1
NOTE:
If multiple network segments are planned in the Trust zone, configure static routes from the lan1 port to the planned network segments one by one.
Configure static NAT mapping from the lan2 port to the Untrust zone.
system-view sys-config network-config lan2 ipv4-nat enable true address 1.2.100.96
Run the reboot command to restart the SC for the settings to take effect.
Root cause
The LAN2 IP address of the secondary network port of SC was not added as a Service Address.
Solution
We have added it using the command :
system-viewsys-config security-config service-ip add ip 192..**.**.131
Thanks for reading!
