Getting help and support

If you experience an issue or have questions when using IBM Cloud Gateway Appliances (vFSA, VRA or vSRX), you can use the following resources before you open a support case.

Review vFSA known limitations
Review the FAQs for VRA in the product documentation.
Review vSRX known limitations.
Check the status of the IBM Cloud platform and resources by going to the Status page.

If you still can't resolve the problem, you can open a support case. For more information, see Creating support cases.

Providing support case details for vFSA

To ensure a timely resolution to your issue, include the following information in your support case for issues with your vFSA:

The IP address (10 network or public network) or hostname of your Fortinet vFSA as well as its version.
To track down where issues are occurring across a network connection, provide the source IP address, destination IP address, the destination port and protocol, as well as any relevant output from network tools, such as ping, traceroute, mtr, or nmap/netcat.
For more complicated issues, a basic explanation of the expected network path of the connection or a network topology diagram is necessary.
Other useful information includes the security policy name that contains the expected allow or block.

Providing support case details for Virtual Router Appliance

To ensure a timely resolution to your issue, include the following information in your support case for issues with Vyatta:

The IP address (10 network or public network) or hostname of your VRA, as well as its NOS version.
To track down where issues are occuring across a network connection, provide the source IP address, destination IP address, the destination port and protocol, as well as any relevant output from network tools, such as ping, traceroute, mtr, or nmap/netcat.
For more complicated issues, a basic explanation of the expected network path of the connection or a network topology diagram is necessary.
Other useful troubleshooting information includes the firewall ruleset name and rule number of the expected rule for allowing or blocking traffic, including the output of show firewall. You can also enable logging to illustrate whether traffic is being allowed or not. In addition, you can use the monitor, tshark, and tcpdump (packet capturing) commands to show traffic on the ingress and egress interfaces. You can also use these commands to illustrate if traffice shows on one expected interface and not another. This can help prove a blocking or routing issue.
Gather any logs that are relevant to the issue. To do so, use journlctl -a, view the syslog entries, or use the show log commands.

Providing support case details for vSRX

To ensure a timely resolution to your issue, include the following information in your support case for issues with your vSRX:

The IP address (10 network or public network) or hostname of your Juniper vSRX as well as its version. As a reminder, versions 19.4R2-S3 and older have consistent cluster and crashing issues. If you are on any of those versions, please reboot to temporarily fix any clustering issues. You should also update to the latest version as soon as possible.
To track down where issues are occurring across a network connection, provide the source IP address, destination IP address, the destination port and protocol, as well as any relevant output from network tools, such as ping, traceroute, mtr, or nmap/netcat.
For more complicated issues, a basic explanation of the expected network path of the connection or a network topology diagram is necessary.
Other useful information includes the security policy name that contains the expected allow or block. You can also illustrate that traffic is being allowed or not using show security match-policies (tab-complete to finish the rest of the command). In addition, the show security flow session command shows the forward and response traffic on the ingress interfaces, as well as if packets are incrementing in one expected direction or not. You can also use traceoptions to receive Debug level output for the specified traffic.
For local sourced and destined traffic, please determine if the PROTECT-IN policy contains the proper allow settings, as this is used for control plane policing.
You should also generate RSI and log files. The RSI contains information on the state of the system, and the logs capture historical information that might be present.

For a standalone device, you would do this ony once per node. For an HA pair, you should capture the RSI and logs for both. To do so, SSH to the gateway IP and login. The following example assumes you are logged into node 1:
```
cli
request support information | save /var/log/rsi-node1
file archive compress source /var/log/* destination /var/tmp/node1.tgz
```
This generates the RSI and logs for node 1. Next, move to the other node:
```
request routing-engine login node 0
cli
request support information | save /var/log/rsi-node0
file archive compress source /var/log/* destination /var/tmp/node0.tgz
file copy /var/tmp/node0.tgz node1:/var/tmp/
```
The same files are generated on node 0, and the resulting zip file is copied to node 1. You can use SCP or other tools to download thse files from the /var/tmp directory.