Login
| Title | Size | Downloads |
|---|---|---|
| H3C VCFC-DC Troubleshooting Guide-E31xx-5W100-book.pdf | 727.92 KB |
- Table of Contents
- Related Documents
-
Collecting diagnostic log messages· 1
Contacting technical support 2
Troubleshooting VCFC-DC controller installation· 1
Failure to install the VCFC-DC controller because the console is disconnected from the server 1
Troubleshooting product licensing· 3
Failure of a team to establish a connection to the license server 3
Troubleshooting team creation failures· 4
Failure to create a team because of incorrect NICs· 4
Failure to create a team because of inconsistent team tokens· 5
Team setup failure caused by controller role error 5
Failure to clear team configuration on member controllers· 6
Failure to add a member controller to a team·· 6
Team IP address unreachable· 7
Inconsistent master controller role on the OpenFlow instance and a controller 9
Controller configuration failure in region creation or modification· 9
Troubleshooting diagnostic information· 11
Diagnostic information exporting failure on the active leader 11
OpenFlow connection failure· 12
Unstable OpenFlow connection· 13
Flow entry deployment failure· 13
NETCONF communication failure· 15
Troubleshooting carrier networks· 16
Physical device activation failure· 16
VNF device activation failure· 16
Automatic region configuration failure· 17
Failure to obtain VNF resources from the VNF manager 18
MAC address learning failure on the host connected to an access device· 19
Failure to learn information about the host connected to an access device· 19
Troubleshooting virtual networks· 20
Communication failure between VMs· 20
Communication failure between host and VSR gateway in underlay network· 20
Communication failure between host and TOR gateway in underlay network· 21
A gateway firewall is not in Active status· 22
A gateway firewall in Active status does not take effect 22
A service chain firewall is not in Active status· 23
A service chain firewall in Active status does not take effect 24
A policy or rule does not take effect 24
Troubleshooting load balancing· 25
Service gateway-type load balancer state is not active· 25
Server pool state is not active· 25
Virtual server state is not active· 26
Member state is not active· 26
Health monitor state is not active· 27
Gateway-type load balancer is active but does not take effect 27
Troubleshooting service chains· 29
Service chain state is not active· 29
A service chain is active but does not take effect 29
Troubleshooting security policies· 30
OpenFlow entry deployment failure for a host 30
OpenFlow entry deployment failure for a network interface· 30
Troubleshooting bare metal servers· 31
Failure to update the inspection network mapping table for bare metal servers· 31
Troubleshooting hierarchical ports· 32
Failure of a VM created in OpenStack to come online on the controller 32
Troubleshooting data center interconnect 33
Layer 3 traffic forwarding failure between data centers· 33
Introduction
This document provides information about troubleshooting common software and hardware problems with H3C VCFC-DC controllers.
General guidelines
To help identify the cause of the problem, collect system and configuration information, including:
· Controller version and Linux operation system version.
· Symptom, time of failure, and configuration.
· Network topology information, including the network diagram, port connections, and points of failure.
· Log messages and diagnostic information. For more information, see "Collecting diagnostic log messages."
· Steps you have taken and their effects.
Collecting diagnostic log messages
1. Enter the URL of the controller in the address bar of a browser (for example, Chrome) to enter the controller login page.
The URL is in the format of https://controller_ip_address:8443/sdn/ui/. If HTTPS is not available due to policy limitations, you can enter the URL in the format of http://controller_ip_address/sdn/ui/ or http://controller_ip_address:8080/sdn/ui/ to log in to the controller through HTTP.
2. On the login page, enter the username and password, and click Login.
3. On the top navigation bar, click Assurance.
4. From the navigation pane, select Logs. Click the Diagnostic Logs tab.
Figure 1 Diagnostic Logs page
The Export Diagnostic Logs dialog box appears.
6. Select one or more controllers and click Export.
The exported diagnostic logs for the controllers are saved to a local file. To export a controller's diagnostic logs for the second time, close the dialog box, and then click Export on the diagnostic logs page again.
Figure 2 Export Diagnostic Logs dialog box
| NOTE: In a team, the active leader can export diagnostic logs for all controllers in active state, and a member can only export its own diagnostic logs. |
Contacting technical support
If you cannot resolve a problem after using the troubleshooting procedures in this document, contact H3C Support.
The following is the contact information for H3C Support:
· Telephone number—400-810-0504.
· E-mail—[email protected].
Troubleshooting VCFC-DC controller installation
This section provides troubleshooting information for common problems with VCFC-DC controller installation.
Before you install a VCFC-DC controller, determine an IP address for it. Make sure the IP address does not conflict with that of another device.
Dependencies check failure
Symptom
The system displays the error message "pre-dependency problem - not installing vcf-controller" during VCFC-DC controller installation, as shown in Figure 3.
Figure 3 Dependencies check failure
Solution
To resolve the problem:
1. Access the Internet and reinstall the software dependencies. For information about installing the software dependencies, see H3C VCFC-DC Installation Guide.
2. If the problem persists, contact H3C Support.
Failure to install the VCFC-DC controller because the console is disconnected from the server
Symptom
You establish an SSH connection to a server and begin to install the VCFC-DC controller on the server. The installation fails because the SSH connection breaks during the installation procedure.
Solution
To resolve the problem:
1. Terminate the VCFC-DC controller processes after you recover the SSH connection.
[root@localhost ~]# systemctl stop sdnc
[root@localhost ~]# systemctl stop sdna
[root@localhost ~]# systemctl stop handshake
If your system does not support the systemctl commands, use the following commands.
[root@localhost ~]# service sdnc stop
[root@localhost ~]# service sdna stop
[root@localhost ~]# service handshake stop
2. Use one of the following methods to uninstall the VCFC-DC controller:
¡ Uninstall the VCFC-DC controller without retaining the configuration data.
[root@localhost ~]# rpm -e vcf-controller
Do you want to purge the package? [Y/N]:Y
¡ Uninstall the VCFC-DC controller with the configuration data retained.
[root@localhost ~]# rpm -e --nopreun vcf-controller
Do you want to purge the package? [Y/N]:N
3. Install the VCFC-DC controller again. For more information about the installation procedure, see H3C VCFC-DC Installation Guide.
4. If the problem persists, contact H3C Support.
Failure to access the GUI after the server where the VCFC-DC controller is installed is power cycled
Symptom
After the server where the VCFC-DC controller is installed is power cycled, you cannot access the GUI of the controller.
Solution
To resolve the problem:
1. Log in to the operating system of the server where the controller is installed.
2. Verify that the controller startup file ext.index in directory /opt/sdn/virgo/work is not damaged during the power cycle. If the size of the file is 0, the startup file is damaged. Delete the file and reboot the server.
3. If the problem persists, contact H3C Support.
Troubleshooting product licensing
This section provides troubleshooting information for common product licensing problems.
Failure of a team to establish a connection to the license server
Symptom
The controller team fails to establish a connection to the license server.
Solution
To resolve the problem:
1. Verify that the network between the controller and license server is operating properly.
2. Log in to the license server. On the Configuration > Client page, identify whether the client information is set up. If the client information has been set up, verify that the client user password is correct.
3. If the problem persists, contact H3C Support.
Troubleshooting teams
This section provides troubleshooting information for common team problems.
Troubleshooting team creation failures
Failure to create a team because of incorrect NICs
Symptom
The system displays the error message "Failed to create the team. Please correct the NIC configuration" when you create a team.
Solution
1. Check the associated NIC of the server or VM for each leader controller:
¡ If the NIC for a leader controller is disabled, use the ifconfig command to enable the NIC.
¡ If the NIC for a leader controller has hardware problems, replace the NIC.
¡ If a leader controller is assigned an incorrect NIC, remove the controller from the controller list on the Add Controller page. Then, add the controller again and select a correct NIC for the controller.
2. If the NIC list of remote leader controllers is not available for a leader controller, check the network connectivity.
3. Verify that the leader controllers use the same team token.
To view the team token of a controller:
a. Log in to the controller.
b. From the top navigation bar, select System >Controller. Click Standalone Controller Configuration.
The Team Token field displays the team token.
4. If the team tokens are different, use one of the following methods to modify the tokens to the same one:
Method 1:
a. From the top navigation bar, select System > Controller. Click Standalone Controller Configuration.
b. Configure the Team Token field:
- If the token is not created, enter a value in the field and click Create. Then, click OK in the confirmation dialog box.
- If the token has been created, delete the token and re-create a new one. To delete a token, click Delete next to the Team Token field and click OK in the confirmation dialog box. Then, enter a value in this field, click Create, and then click OK in the confirmation dialog box.
Method 2:
a. Uninstall the leader controllers whose team tokens need to be modified, and then reinstall the controllers. For information about controller uninstallation and installation, see H3C VCFC-DC Installation Guide.
b. Enter the same team token for the leader controllers.
5. Use the controllers to create a team.
6. If the problem persists, contact H3C Support.
Failure to create a team because of inconsistent team tokens
Symptom
The system displays the error message "Operation failed. The team tokens of all controllers in the team must be the same" when you create a team.
Solution
To resolve the problem:
1. Check the team token of each leader controller:
a. Log in to a controller.
b. From the top navigation bar, select System > Controller.
c. Click Standalone Controller Configuration.
The Team Token field displays the team token.
2. Use one of the following methods to modify the team token of a controller to a value the same as the token of other controllers in the team:
Method 1:
a. From the top navigation bar, select System > Controller. Click Standalone Controller Configuration.
b. Configure the Team Token field:
- If the team token is not created, enter a value in the field and click Create. Then, click OK in the confirmation dialog box.
- If the team token has been created, delete the token and re-create a new one. To delete a token, click Delete next to the Team Token field and click OK in the confirmation dialog box. Then, enter a value in this field, click Create, and then click OK in the confirmation dialog box.
Method 2:
a. Uninstall the controller, and then reinstall the controller.
For information about controller uninstallation and installation, see H3C VCFC-DC Installation Guide.
b. Enter a team token the same as the team token of other controllers in the team.
3. Use the controllers to create a team.
4. If the problem persists, contact H3C Support.
Team setup failure caused by controller role error
Symptom
The system displays the error message "You can't create a team on a member controller" when you create a team on a controller.
Solution
To resolve the problem:
1. Change the role of the controller to leader, or log in to a leader controller to create the team.
2. If the problem persists, contact H3C Support.
Failure to clear team configuration on member controllers
Symptom
When you delete a team, the team configuration cannot be cleared from some member controllers. The reasons including:
· The active leader controller cannot communicate with the member controllers due to network connectivity problems.
· The member controllers are offline when the team is deleted. The team configuration on the member controllers is not cleared synchronously.
Solution
To resolve the problem:
1. If the team is not deleted, repair the links and make sure the active leader controller can reach the member controllers, and then delete the team.
2. If the team has been deleted, clear the team configuration by removing the member controllers from the team:
a. Log in to a member controller.
b. From the top navigation bar, select System > Controller.
c. Click the 
icon for the member controller.
d. Click OK in the confirmation dialog box.
e. Repeat steps a to d to remove all the member controllers from the team.
3. If the problem persists, contact H3C Support.
Failure to add a member controller to a team
Symptom
A member controller cannot dynamically join a team.
Solution
To resolve the problem:
1. Check the HTTPS connection between the member controller and the active leader controller. Verify that the team IP address can be pinged from the member controller. If the ping operation fails, use the methods described in "Team IP address unreachable" to resolve the problem.
2. Check the configuration on the member controller for any mistakes, and modify the incorrect settings. For example, conflict IP address or name.
3. Verify that the number of controllers does not exceed the upper limit in the team.
If the upper limit has been reached, you must first remove another controller from the team before you add the controller to the team.
4. Verify that the team token of the controller is the same as the team token of the active leader controller in the team. To modify the team token:
Method 1:
a. Log in to the controller, select System > Controller from the navigation bar, and click Standalone Controller Configuration.
b. If the team token is not created, enter the team token of the active leader controller in the Team Token field and click Create.
c. If the team token has been created, click Delete next to the Team Token field and re-create a new team token.
Method 2:
a. Uninstall the controller, and then reinstall it.
For information about controller uninstallation and installation, see H3C VCFC-DC Installation Guide.
b. Enter the team token of the active leader controller during the installation.
5. Add the controller to the team.
6. If the problem persists, contact H3C Support.
Team IP address unreachable
Symptom
A user cannot log in to the team through the team IP address, or cannot ping the team IP address.
Solution
To resolve the problem:
1. Ping the IP address of the active leader controller from a PC. If the ping operation fails, check the network connectivity between the PC and the leader controller.
2. Verify that the active leader controller has a team IP address:
a. From the top navigation bar, select Assurance > Controller Information.
b. If no team IP address exists, select System > Controller and click Team.
c. Click Edit Team.
d. On the dialog box, enter the team IP address and the network mask.
e. Click Apply.
3. Log in to the server or VM where the active leader controller software is installed. Use the ifconfig command to view whether the team IP address exists on the associated NIC. If no team IP address is available, verify that the NIC is not disabled. If the NIC is disabled, use the ifconfig command to enable the NIC.
4. Verify that no team IP address conflicts exist on the network. If conflicts exist, log in to the active leader controller and change the team IP address to be unique.
5. On the host from where you log in to the controller, view the ARP entry of the team IP address. Verify that the MAC address in the entry is the MAC address of the NIC that has the team IP address. If the MAC addresses are different, the ARP entry is incorrect. You must delete the ARP entry, and then ping the team IP address again.
6. If the problem persists, contact H3C Support.
Member controller down
Symptom
The state of a member controller is down.
Solution
To resolve the problem:
1. In the Controller Info area, check the Remarks field.
2. If the field displays The controller IP is unreachable or Connection timed out, verify that the controller is down or the network is disconnected. To remove the issue, power cycle the controller or reinstall the controller software, or repair the failed links to ensure network connectivity.
3. If the field displays The controller already assigned to a team, remove the controller from the new team or the previous team.
4. If the field displays Team token authentication failed, perform the following tasks to resolve the problem:
a. Log in to the member controller.
b. From the top navigation bar, select System >Controller.
c. Click Standalone Controller Configuration.
The Team Token field displays the team token.
d. If the team token is different from the team token of other controllers in the team, use one of the following methods to configure the team token:
- Enter a value in the Team Token field and click Create. If a team token has been created, delete the token and create a new token.
- Uninstall the controller, and then reinstall the controller. Enter the team token of other controllers in the team during the installation. For information about controller uninstallation and installation, see H3C VCFC-DC Installation Guide.
e. Re-create the team or add the controller to the original team.
Troubleshooting regions
This section provides troubleshooting information for common region problems.
Inconsistent master controller role on the OpenFlow instance and a controller
Symptom
When an OpenFlow instance is connected to multiple controllers in different regions, the master controller role is inconsistent on the OpenFlow instance and a controller.
Solution
To resolve the problem:
1. Verify that an OpenFlow instance is connected to only two controllers in a region.
When the OpenFlow instance is connected to a controller in a region, the controller issues its configured role (master or subordinate) to the OpenFlow instance. If the OpenFlow instance is then connected to the controllers in another region, the original master controller on the OpenFlow instance will be overwritten. For example, an OpenFlow instance is connected to controller A (master) and controller B (subordinate) in Region A. Then the OpenFlow instance is connected controller C (master) and Controller D (subordinate) in Region B. On the OpenFlow instance, controller C is the master and the other three are subordinates. However, controller A still determines that it is the master for the OpenFlow instance.
If the OpenFlow instance is connected to multiple controllers, delete unnecessary controllers specified on the OpenFlow instance. If the remaining two controllers are in different regions, you can modify the region configuration to assign the two controllers to the same region.
2. If the problem persists, contact H3C Support.
Controller configuration failure in region creation or modification
Symptom
The system prompts a controller configuration failure during region creation or modification.
Solution
To resolve the problem:
1. Verify that the controller is up and the network is connected.
a. Examine the Remarks field on the controller information page.
- If the field displays The controller IP is unreachable, the controller is down or the network is disconnected. Then go to step b.
- If the field does not display The controller IP is unreachable, go to step 2.
b. Power on or reinstall the controller, or troubleshoot the network failure.
2. Verify that the team token authentication for the controller is successful.
a. Examine the Remarks field on the controller information page.
- If the field displays Team token authentication failed, go to step b.
- If the field does not display Team token authentication failed, go to step 3.
b. Verify that the controller's team token is the same as the token of other controllers in the team.
You can modify the controller's team token by using one of the following methods:
(Method 1) Log in to the controller's GUI, select System >Controller, and click Standalone Controller Configuration.
- If the team token is not created, enter the correct value in the Team Token field and click Create.
- If the team token has already been created, click Delete to delete the team token. Then enter the correct value in the Team Token field and click Create.
(Method 2) Remove the controller and reinstall it. Enter the same team token as that of the leader controllers during the installation. For information about installing and removing a controller, see H3C VCFC-DC controller installation guide.
c. Re-create the team or add the controller to the team again.
3. If the problem persists, contact H3C Support.
Troubleshooting diagnostic information
This section provides troubleshooting information for common diagnostic information problems.
Diagnostic information exporting failure on the active leader
Symptom
Diagnostic information for some active controllers fails to be exported, or the exported file cannot be decompressed.
Solution
To resolve the problem, try to export diagnostic information for the target controllers by using the following methods:
· Export diagnostic information for the controllers a second time on the active leader:
a. On the diagnostic information page of the active leader, click Export.
b. On the dialog box that appears, select the target controllers and click Export.
· Export diagnostic information for a target controller on the controller itself:
a. Log in to the Web interface of a target controller.
b. Export diagnostic information for the current controller.
· Obtain the diagnostic information of a controller from the host server or VM of the controller:
a. Log in to the host server or VM of the controller through SSH.
b. Use a file transfer application (such as FTP) to download the diagnostic log file from the /opt/sdn/virgo/serviceability/logs directory.
Troubleshooting OpenFlow
This section provides troubleshooting information for common OpenFlow problems.
OpenFlow connection failure
Symptom
No device information is displayed for a correctly configured OpenFlow device after you select Assurance > OpenFlow Devices > Device Information on the controller's GUI.
Solution
To resolve the problem:
1. Log in to the OpenFlow device and verify that the controller IP address specified for the OpenFlow device is correct. If the controller IP address is incorrect, specify the correct controller IP address on the OpenFlow device as shown in Figure 4.
Figure 4 Specifying the controller IP address
2. Verify that the controller IP address is reachable. If the controller IP address is reachable, troubleshoot the network.
3. Verify that the OpenFlow device has established a connection to the controller by using the display openflow summary command.
Figure 5 Displaying OpenFlow connection channel state.
If channel status is not Connected, verify that the total number of OpenFlow connections established by the controller is not larger than the total number of nodes supported by the remote and local licenses. If the total number of OpenFlow connections established by the controller is larger than the total number of nodes supported by the remote and local licenses, update the remote or local license.
To view the total number of OpenFlow connections established by the controller, select Assurance > Controller Information on the controller's GUI.
To view the maximum number of nodes supported by the remote or local license, select System > License on the controller's GUI.
4. If the problem persists, contact H3C Support.
Unstable OpenFlow connection
Symptom
The OpenFlow connection established between the controller and the OpenFlow device is unstable.
Solution
To resolve the problem:
1. Verify that the network is connected. If the network is disconnected, troubleshoot the network.
2. Verify that traffic congestion does not occur in the region.
If traffic congestion occurs in the region, OpenFlow echo messages cannot be exchanged correctly. Execute the netstat -anp | grep 6633 command as a root user to identify whether the TCP channel for the OpenFlow connection is occupied. As shown in Figure 6, if the values for the first and the second columns are in the range of 200000 to 250000, the traffic in the region is heavy. You can disconnect OpenFlow connections for some OpenFlow devices and then connect these devices to controllers in other regions.
3. If the problem persists, contact H3C Support.
Flow entry deployment failure
Symptom
OpenFlow entries cannot be displayed on the OpenFlow device after the controller deploys flow entries to the OpenFlow device through REST API or the triggering of service packets.
Solution
To resolve the problem:
1. Verify that the capability set of the OpenFlow device supports the flow entries deployed by the controller. If the OpenFlow device does not support the flow entries, update the device or change a device.
You can view the capability set of the OpenFlow device through getting /sdn/v2.0/of/datapaths/{dpid}/features/match on REST API.
2. Verify that the OpenFlow device supports identifying Experimenter extensions if the flow entries contain Experimenter extensions. If the OpenFlow device cannot identify Experimenter extensions, update the device or change a device.
3. Enable OpenFlow debugging by using the debugging openflow all command to verify that the OpenFlow device can receive FlowMod messages.
¡ If the device cannot receive FlowMod messages from the controller, verify that the connection between the OpenFlow device and the controller is Connected. For more information, see "Unstable OpenFlow connection."
¡ If the device can receive FlowMod messages from the controller, go to step 4.
4. If the problem persists, contact H3C Support.
Troubleshooting NETCONF
This section provides troubleshooting information for common NETCONF problems.
NETCONF communication failure
Symptom
The controller fails to use SOAP to issue NETCONF configuration. For example, after a device is added, its state is inactive and the system displays either of the following error messages:
· OpenFlow connection is down.
· NETCONF connection fails due to network congestion.
Solution
To resolve the problem:
1. Verify that the network device and the controller are physically connected:
a. Log in to the controller, and examine the cable connection status and link status.
b. Log in to the network device, and examine the cable connection status and link status.
2. Verify that the NETCONF settings are consistent on the network device and the controller:
a. Make sure NETCONF over SOAP over HTTPS is enabled on the network device.
b. Make sure the network device and the controller are configured with the same username and password.
If any inconsistency occurs, modify the NETCONF settings on the network device or the controller.
3. Verify that a NETCONF session can be established between the network device and the controller.
There is a limit on the number of NETCONF sessions that can be established on the network device. If the upper limit has been reached, the network device cannot establish a NETCONF session with the controller. In this case, delete the existing NETCONF sessions or increase the NETCONF session limit to ensure that a NETCONF session can be established between network device and the controller.
4. If the problem persists, contact H3C Support.
Troubleshooting carrier networks
This section provides troubleshooting information for common carrier network problems.
Physical device activation failure
Symptom
A physical device remains in inactive state after it is created.
Solution
To resolve the problem:
1. Verify the number of OpenFlow nodes and Overlay physical devices. If the number exceeds the limit allowed by the licenses, purchase new licenses.
2. Verify that the physical device and the controller can ping each other by using the management IP of the physical device. If the ping operation fails, troubleshoot the network connection problem.
3. If the physical device type is gateway, verify that the physical device has joined a gateway group.
4. Verify that NETCONF communication between the physical device and the controller succeeds. If NETCONF communication fails, troubleshoot NETCONF. For more information, see "Troubleshooting NETCONF."
5. Verify that a region is automatically selected for the physical device if the controller operates in team mode:
a. Select Provision > Inventory > Devices > Physical Devices.
b. View the status of the device.
- If the status is Inactive and the system prompts that the region is not activated or does not exist, troubleshoot automatic region configuration failure. For more information, see "Automatic region configuration failure."
- If other information is displayed, a region has been selected for the physical device. Go to the next step.
6. Verify that an IP address is configured for the controller when the controller operates in standalone mode:
a. Select System >Controller on the top navigation bar, and click Standalone Controller Configuration.
b. View the Controller IP field. If no IP address is configured, configure an IP address for the controller.
7. If the problem persists, contact H3C Support.
VNF device activation failure
Symptom
A VNF device remains in inactive state after it is created.
Solution
To resolve the problem:
1. Verify the number of OpenFlow nodes. If the number exceeds the limit allowed by the license, purchase a new license.
2. Verify that the VNF device and the controller can ping each other by using the management IP of the VNF device. If the ping operation fails, troubleshoot the network connection problem.
3. Verify that a region is automatically selected for the VNF device if the controller operates in team mode:
a. Navigate to the Provision > Inventory > Devices > Virtual Devices page.
b. View the status of the device.
- If the status is Inactive and the system prompts that the region is not activated or does not exist, troubleshoot automatic region configuration failure. For more information, see "Automatic region configuration failure."
- If other information is displayed, a region has been selected for the physical device. Go to the next step.
4. Verify that an IP address is configured for the controller if the controller operates in standalone mode:
a. Select System >Controller on the top navigation bar, and click Standalone Controller Configuration.
b. View the Controller IP field. If no IP address is configured, configure an IP address for the controller.
5. If the problem persists, contact H3C Support.
Automatic region configuration failure
Symptom
A device fails to automatically select a region when the controller operates in team mode.
Solution
To resolve the problem:
1. Verify that a region is configured for the team:
a. Select System > Controller on the top navigation bar.
b. Click Region. If no region is configured, configure a region for the team.
2. Verify that the management IP address of the device belongs to the managed node subnets of the configured region:
a. Select System > Controller on the top navigation bar.
b. Click Region.
c. Check the Managed Node Subnets field.
If the management IP address does not belong to the managed node subnets, create a new region without any managed node subnets, or perform the following tasks:
- Select System > Controller on the top navigation bar, and click Edit Region.
- In the Managed Node Subnets field, add the network segment of the management IP address.
3. If the problem persists, contact H3C Support.
Failure to obtain VNF resources from the VNF manager
Symptom
The system displays Failed to get resources from the VNFM when the controller requests resources from the VNF manager.
Solution
To resolve the problem:
1. Verify that no VNF resource with the same name as the requested resource exists on the VNF manager. If a VNF resource with the same name exists, obtain another VNF resource or delete the VNF resource with the same name.
A VNF resource can be deleted only when it is not used.
2. Verify that the VNFM information in the VNFM info area is correct. If the VNFM information is incorrect, modify the configuration.
3. Verify that the controller and the VNF manager can ping each other. If the ping operation fails, troubleshoot the network connection problem.
4. Log in to the VNF manager to verify that the VNF manager has a template corresponding to the VNF resource that the controller requests. If the template does not exist, create a template for the VNF resource.
5. On the VNF manager, verify that the number of VNF resources does not reach the upper limit, as shown in Figure 7. If the upper limit is reached, expand the capacity as required.
6. If the problem persists, contact H3C Support.
Troubleshooting ARP
This section provides troubleshooting information for common ARP problems.
MAC address learning failure on the host connected to an access device
Symptom
When you perform a ping operation from a host connected to an access device, the host cannot learn the MAC address of the ping destination.
Solution
To resolve the problem:
1. Verify that the OpenFlow connections for the following pairs of devices have been successfully established:
¡ The controller and the access device that is connected to the source host.
¡ The controller and the access device that is connected to the ping destination.
2. Verify that the vPort information for both the source host and the ping destination is correctly configured on the controller. The vPort information includes IP address, MAC address, and the VLAN or VXLAN to which the source host or the ping destination belongs.
3. If the problem persists, contact H3C Support.
Failure to learn information about the host connected to an access device
Symptom
The host information cannot be obtained by the ARP module through REST API after the host that is connected to the access device starts.
Solution
To resolve the problem:
1. Verify that the physical device for the access device that is connected to the host is correctly configured on the controller.
2. Verify that the physical device is activated. If it is not activated, verify that the username and password for the physical device are correctly configured.
3. Verify that the physical device has flow entries to forward ARP packets to the controller. If the flow entries exist, perform a ping operation from the host to make the controller learn the host information.
4. If the problem persists, contact H3C Support.
Troubleshooting virtual networks
This section provides troubleshooting information for common virtual network problems.
Communication failure between VMs
Symptom
Two VMs cannot communicate with each other.
Solution
To resolve the problem:
1. Verify that the vPorts and the uplink interfaces of both VMs are in up state, and the networks to which the two VMs belong are of the same type.
2. Verify that the subnets to which the two VMs belong are bound to the same vRouter.
3. Verify that the VMs have relevant ARP entries. If the VMs do not have relevant ARP entries, verify that the hosts of the VMs have connected to the controller.
4. Verify that the ARP entries are correct. If the ARP entries are incorrect, delete the incorrect ARP entries.
5. If the problem persists, perform either task:
¡ If the two VMs belong to the same host, contact H3C Support.
¡ If the two VMs belong to different hosts, go to step 6.
6. Verify that the hosts of the two VMs can ping the VTEP IP address of each other. If the hosts of the two VMs cannot ping the VTEP IP address of each other, delete the host and then add the host on the controller.
7. If the problem persists, contact H3C Support.
Communication failure between host and VSR gateway in underlay network
Symptom
The host cannot use the VTEP IP address to communicate with the VSR gateway in the underlay network.
Solution
To resolve the problem:
1. Verify that the VTEP IP address and the IP address of the VSR gateway belong to different networks.
If they belong to the same network, perform either task:
¡ For a vCenter domain, configure the VTEP IP address on the VMkernel interface to make sure it does not belong to the same network as the IP address of the VSR gateway.
¡ For a KVM domain, configure the VTEP IP address on the compute node to make sure it does not belong to the same network as the IP address of the VSR gateway.
2. If the problem persists, contact H3C Support.
Communication failure between host and TOR gateway in underlay network
Symptom
The host cannot use the VTEP IP address to communicate with the TOR gateway in the underlay network.
Solution
To resolve the problem:
1. Verify that the next hop of the default route is the IP address of the TOR gateway. If the next hop of the default route is not the IP address of the TOR gateway, configure the IP address of the TOR gateway as the next hop of the default route.
2. If the problem persists, contact H3C Support.
Troubleshooting firewalls
This section provides troubleshooting information for common firewall problems.
A gateway firewall is not in Active status
Symptom
A gateway firewall is not in Active status after it is successfully created.
Solution
To resolve the problem:
1. Verify that the firewall is bound to a vRouter.
Navigate to the Tenants > Services > Firewall > Firewall page. Identify whether the firewall is bound to a vRouter.
¡ If the firewall is not bound to a vRouter, modify the firewall configuration and bind it to a vRouter.
¡ If the firewall is bound to a vRouter, go to the next step.
2. If the problem persists, contact H3C Support.
A gateway firewall in Active status does not take effect
Symptom
A gateway firewall is in Active status but does not take effect after it is successfully created.
Solution
To resolve the problem:
1. Verify that an external network is bound to the vRouter.
Navigate to the Tenants > Your Network > Virtual Router page. Identify whether the External Network column for the vRouter displays None. If yes, you must create an external network and bind it to the vRouter. To create an external network, navigate to the Tenants > Common Network Settings > External Networks page.
2. Verify that the external network contains a subnet.
Navigate to the Tenants > Common Network Settings > External Networks page. Identify whether Subnets (0) is displayed in the Subnet Information column for the external network.
¡ If yes, create a subnet.
¡ If not, go to the next step.
3. Verify that the vRouter is bound to a gateway.
Navigate to the Tenants > Your Network > Virtual Router page. Click 
for the Gateway Resources field. Identify whether the vRouter is bound to a gateway.
¡ If not, modify the vRouter configuration and bind it to a gateway.
¡ If yes, go to the next step.
4. Verify that an internal subnet is bound to the vRouter.
Navigate to the Tenants > Your Network > Virtual Router page. Identify whether Interfaces (0) is displayed in the Interfaces/Subnets column for the vRouter.
¡ If yes, modify the vRouter configuration and add interfaces to the vRouter.
¡ If not, go to the next step.
5. Verify that an OpenFlow connection is established between the gateway and the controller.
If no OpenFlow connection is established, see "OpenFlow connection failure." If an OpenFlow connection is established, perform the following tasks:
a. Navigate to the Tenants > Common Network Settings > Gateway page. Query the device group to which the gateway member of the vRouter's tenant belongs.
b. Navigate to the Provision > Inventory > Devices > Border Device Groups page. Query member devices in the device group.
c. Navigate to the Provision > Inventory > Devices > Physical Devices page. Identify whether OpenFlow connections are established between the controller and the group member devices.
6. Verify that the gateway exists in a region.
Navigate to the Assurance > Controller Information page. Click the region in the Controller Info area to view the region details and verify that the gateway belongs to a region. If the gateway does not belong to a region, verify that a region has been created.
¡ If no region is created, create a region first.
¡ If a region has been created, go to the next step.
7. If the problem persists, contact H3C support.
A service chain firewall is not in Active status
Symptom
A service chain firewall is not in Active status after it is successfully created.
Solution
To resolve the problem:
1. Verify that the firewall is bound to a vFW resource.
Navigate to the Tenants > Services > Firewall > Firewall page. Identify whether Resources (0) is displayed in the Security Zones/Resources column. If yes, create a resource and bind the firewall to the resource.
2. Verify that the firewall is being used by a service chain.
Navigate to the Tenants > Services > Service Chain > Service Chain page. Click the Edit icon in the Actions column to identify whether the service chain is using the firewall. If no service chain is using the firewall, modify the service chain configuration and drag the corresponding firewall service instance to the service chain, and click Apply.
3. If the problem persists, contact H3C Support.
A service chain firewall in Active status does not take effect
Symptom
A service chain firewall is in Active status but does not take effect after it is successfully created.
Solution
To resolve the problem:
1. Verify that an OpenFlow connection is established between the vFW resource and the controller.
If no OpenFlow connection is established, see "OpenFlow connection failure." If an OpenFlow connection is established, perform the following tasks:
a. Navigate to the Tenants > Services > Firewall > Firewall page. Click the Resources link in the Security Zone/Resource area. Query the vFW resource bound to the service chain firewall.
b. Navigate to the Provision > Inventory > Devices > Virtual Devices page. Identify whether the vFW resource is active. If yes, an OpenFlow connection has been established between the vFW and the controller.
2. If the problem persists, contact H3C support.
A policy or rule does not take effect
Symptom
A policy or rule is added or modified for a firewall. However, the policy or rule does not take effect.
Solution
To resolve the policy failure:
1. Verify that the Audit option is selected for the policy.
Navigate to the Tenants > Services > Firewall > Security Policy page and click the Policy tab. Identify whether the Audit Status column for the policy displays green. If not, modify the policy and select the Audit option.
2. If the problem persists, contact H3C Support.
To resolve the rule failure:
1. Verify that the Enable option is selected for the rule.
Navigate to the Tenants > Services > Firewall > Security Policy page and click the Rule tab. If the Enable Status column for the rule displays False, modify the rule and select the Enable option.
2. If the problem persists, contact H3C Support.
Troubleshooting load balancing
This section provides troubleshooting information for common load balancing problems.
Service gateway-type load balancer state is not active
Symptom
A service gateway-type load balancer remains in inactive state after it is created.
Solution
To resolve the problem:
1. On the Tenants > Services > Load Balancing > Load Balancer page, verify that the load balancer has referenced a listener. If no listener is referenced, modify the load balancer configuration to specify a listener for the load balancer.
2. On the Assurance > Controller Information page, click a region in the Controller Info area to enter the region details page. Identify whether the gateway belongs to a region.
¡ If yes, see "Virtual server state is not active."
¡ If not, go to the next step.
3. If the problem persists, contact H3C Support.
Server pool state is not active
Symptom
A server pool remains in inactive state after it is created.
Solution
To resolve the problem:
1. On the Tenants > Services > Load Balancing page, verify that the server pool has been referenced by a load balancer. If the server pool is not referenced by a load balancer, specify a load balancer for the server pool.
2. Verify that the load balancer that references the server pool is in active state. If the load balancer is not in active state, see "Service gateway-type load balancer state is not active" to resolve the problem.
3. If the problem persists, contact H3C Support.
Virtual server state is not active
Symptom
A virtual server remains in inactive state after it is created.
Solution
To resolve the problem:
1. On the Tenants > Your Network > Virtual Router page, verify that the virtual subnet bound to the server pool has been added to a vRouter. If the virtual subnet is not added to a vRouter, add the virtual subnet to a vRouter.
2. On the Tenants > Your Network > Virtual Router page, click the Details icon on the Gateway Resources tab to identify whether the vRouter has been bound to a gateway. If not, bind a gateway to the vRouter. If yes, go to the next step.
3. On the Tenants > Your Network > Virtual Router page, click the External Networks tab to identify whether the vRouter has been bound to any external network. If not, bind an external network to the vRouter.
4. If the problem persists, contact H3C Support.
Empty member list
Symptom
The member list is empty when a member is added.
Solution
To resolve the problem:
1. Verify that a vSubnet has been bound to the selected server pool:
a. On the Tenants > Services > Load Balancing page, click the Pool tab.
b. If the server pool does not have any vSubnet bound to it, modify the server pool configuration to bind a vSubnet to the server pool.
2. On the Tenants > Your Network > Virtual Port page, verify that a vSwitch-type vPort exists in the vSubnet. If no such a vPort exists, bring online a vSwitch-type vPort.
3. If the problem persists, contact H3C Support.
Member state is not active
Symptom
A member remains in inactive state after it is created.
Solution
To resolve the problem:
1. Access the Tenants > Services > Load Balancing > Pool page. In the Pool Member area verify that the member has been associated with a server pool. If no server pool is associated, modify the member configuration to associate the member with a server pool.
2. Click the Pool tab to verify that the server pool associated with the member is in active state. If the server pool is not active, see "Server pool state is not active" to resolve the problem.
3. If the problem persists, contact H3C Support.
Health monitor state is not active
Symptom
A health monitor remains in inactive state after it is created.
Solution
To resolve the problem:
1. Access the Tenants > Services > Load Balancing > Pool page. In the Health Monitor area, verify that the health monitor has been referenced by a server pool. If the health monitor is not referenced by a server pool, specify a server pool for the health monitor.
2. Verify that the server pool that has referenced the health monitor is in active state. If the server pool is not active, see "Server pool state is not active" to resolve the problem.
3. If the problem persists, contact H3C Support.
Gateway-type load balancer is active but does not take effect
Symptom
The gateway-type load balancer is active but does not take effect.
Solution
To resolve the problem:
1. Verify that an OpenFlow connection is established between the gateway and the controller.
If no OpenFlow connection is established, see "OpenFlow connection failure." If an OpenFlow connection is established, perform the following tasks:
a. Navigate to the Tenants > Common Network Settings > Gateway page. Query the device group to which the gateway member of the vRouter's tenant belongs.
b. Navigate to the Provision > Inventory > Devices > Border Device Groups page. Query member devices in the device group.
c. Navigate to the Provision > Inventory > Devices > Physical Devices page. Identify whether OpenFlow connections are established between the controller and the group member devices.
2. Verify that the gateway exists in a region.
Navigate to the Assurance > Controller Information page. Click the region in the Controller Info area to view the region details and verify that the gateway belongs to a region. If the gateway does not belong to a region, verify that a region has been created.
¡ If no region is created, create a region first.
¡ If a region has been created, go to the next step.
3. If the problem persists, contact H3C Support.
Troubleshooting service chains
This section provides troubleshooting information for common service chain problems.
Service chain state is not active
Symptom
After a service chain is created, its state is not Active.
Solution
To resolve the problem:
1. Verify that all service instances for the service chain are bound to resources. If any service instance is not bound to a resource, modify the service instance configuration.
2. If the problem persists, contact H3C Support.
A service chain is active but does not take effect
Symptom
A service chain is active but does not take effect.
Solution
To resolve the problem:
1. Verify that the source and destination contexts of the service chain match the source and destination addresses of the traffic. If they do not match, modify the source and destination contexts of the service chain.
2. Verify that the service instances of the service chain operate correctly. If they do not operate correctly, see the service instance troubleshooting guide.
3. Verify that the flow tables of each device on the service chain path are correct. If any incorrect flow table is found, see "Flow entry deployment failure."
4. If the problem persists, contact H3C Support.
Troubleshooting security policies
This section provides troubleshooting information for common security policy problems.
OpenFlow entry deployment failure for a host
Symptom
The controller cannot deploy a security policy OpenFlow entry for a host after the host comes online.
Solution
To resolve the problem:
1. Verify that an OpenFlow connection is established between the OpenFlow device that the host is connected to and the controller. If no OpenFlow connection exists, see "OpenFlow connection failure."
2. Verify that the ARP application is loaded. If the ARP application does not exist, load the ARP application.
3. Verify that the Carrier Network application and the vNetwork application are unloaded. If the Carrier Network application and the vNetwork application exist, unload them.
4. Verify that the user group and security policy are correctly configured. If the configuration is incorrect, modify the configuration.
5. If the problem persists, contact the H3C Support.
OpenFlow entry deployment failure for a network interface
Symptom
The network interfaces between OpenFlow devices are in up state, but the controller cannot deploy network interface OpenFlow entries.
| NOTE: The network interface OpenFlow entries ensure that the packets that trigger host learning, such as ARP learning, are not forwarded to the controller. |
Solution
To resolve the problem:
1. Verify that an OpenFlow connection is established between the OpenFlow device that hosts are connected to and the controller. If no OpenFlow connection exists, see "OpenFlow connection failure."
2. Verify that the OpenFlow device is correctly configured. If the configuration is incorrect, modify the configuration.
3. If the problem persists, contact the H3C Support.
Troubleshooting bare metal servers
This section provides troubleshooting information for common bare metal server problems.
Failure to update the inspection network mapping table for bare metal servers
Symptom
When an interface is bound to or unbound from the inspection network mapping table of a bare metal server, the operation fails and the system prompts an internal error. In the operation log, the failure cause is "Internal server error."
Solution
To resolve the problem:
1. Navigate to the Provision > Network Design > BM Server page, and click the Access Network tab. Click the Edit icon in the Apply to Interfaces area for the inspection network mapping table, and record all devices and interfaces bound to the inspection network mapping table. Navigate to the Provision > Inventory > VNID Pools > VLAN-VXLAN Mappings page, and click the Interfaces link in the Apply to Interfaces area for the inspection network mapping table, and record all devices and interfaces bound to the inspection network mapping table.
2. Compare the records on the two pages. Record the interfaces that exist on the BM Server page but do not exist on the VLAN-VXLAN Mappings page, and remove these interfaces on the BM Server page.
3. Log in to the device. Execute the vtep access port command on the removed interfaces. (If an interface has been assigned to an aggregate interface, first remove the interface from the aggregate interface and then execute the vtep access port command.) Then, bind the interfaces to the inspection network mapping table on the BM Server page.
4. Verify that interfaces on the BM Server page are the same as interfaces on the VLAN-VXLAN Mappings page.
5. If the problem persists, contact the H3C Support.
Troubleshooting hierarchical ports
This section provides troubleshooting information for common hierarchical port problems.
Failure of a VM created in OpenStack to come online on the controller
Symptom
In the hierarchical port binding scenario, a VM created in OpenStack fails to obtain an IP address, and fails to come online on the controller.
Solution
To resolve the problem:
1. On the compute node, capture packets of the interface connected to the S6800 switch. Identify whether the interface can properly send LLDP packets. If not, enable LLDP or re-enable LLDP on the compute node. If not, go to the next step.
2. Log in to the controller. Navigate to the Tenants > Your Network > Virtual Network page. Identify whether sending LLDP packets to the controller and sending DHCP packets to the controller are enabled for the virtual network used for connecting the controller to OpenStack. If not, enable these functions. If yes, go to the next step.
3. Log in to OpenStack. Navigate to the Project > Compute > Access & Security page. Click Manage Rules for the specified security group. Identify whether the security group bound to the VM is configured with the rule to permit the gateway IP in the ingress direction. If not, set the rule. If yes, go to the next step.
4. If the problem persists, contact the H3C Support.
Troubleshooting data center interconnect
This section provides troubleshooting information for data center interconnect problems.
Layer 3 traffic forwarding failure between data centers
Symptom
A Layer 3 data center interconnect has already between created between data centers, but Layer 3 traffic cannot be forwarded between these data centers.
Solution
To resolve the problem:
1. Identify whether the border devices support L3VNI matching and modification in PBR. If not, replace the devices.
2. Verify that the Layer 3 data center interconnects configured on controllers in these data centers are mapped to the same segment ID.
3. Verify that the import RTs and export RTs of the Layer 3 data center interconnects configured on controllers in these centers match.
4. If the problem persists, contact the H3C Support.
Troubleshooting M-LAG
This section provides troubleshooting information for common M-LAG problems.
VMs on the local DR interface come online and are assigned configuration, but VMs on the peer DR interface are not assigned backup configuration
Symptom
Two devices in the same DR system have been activated. VMs on the DR interface of one device come online and are assigned the VSI and AC configuration. However, the VMs on the DR interface of the peer device in the same DR system are not assigned the corresponding VSI and AC configuration.
Solution
To resolve the problem:
1. Verify that the DR interfaces in the same DR system are bound to the same VLAN-VXLAN mapping table.
2. Verify that the vtep access port command is executed on the peer DR interface.
3. If the problem persists, contact the H3C Support.
