Issue/Introduction
An abnormal VPC network can have multiple symptoms and causes. Use the corresponding resolution to troubleshoot each scenario.
Environment
- Product: ZCF
- Component: Cloud
- Version: 3.x-5.5.30
Symptoms
An abnormal VPC network generally has one of the following three symptoms:
- Symptom 1: After a host bond is changed, the VPC network used by a VM instance cannot communicate normally.
- Symptom 2: VM instances created on the same VPC network cannot communicate with each other.
- Symptom 3: VM instance networks under different VPC vRouters cannot communicate.
Possible causes
Cause 1
Symptom 1 might occur because the service NIC bridge on the host is deleted while the bond is being changed, preventing the VM instance VPC network from communicating normally.
Cause 2
Symptom 2 might occur because of the VM instance security group configuration.
Cause 3
Symptom 3 might occur because the VPC vRouter does not have a route table attached.
Resolution
Resolution for cause 1
- Restart the affected VM instances and VPC vRouter. This operation creates the bridge automatically.
- Live migrate the affected VM instances and VPC vRouter. This operation creates the bridge automatically, and communication recovers after VM instance live migration.
Plan a maintenance window before restarting or live migrating a VPC vRouter to avoid affecting workloads by operating on the wrong VPC vRouter.
Resolution for cause 2
- Check the security group rules attached to the VM instances. After confirming that the ingress and egress rules are correct, test again.
If you are unsure whether the security group configuration causes the issue, you can temporarily detach the security group from the VM instances within a controlled test window, and reattach it promptly after the test.
Resolution for cause 3
- To enable VPC subnets under two different VPC vRouters to communicate, attach route tables to both vRouters and configure route rules that connect the networks.
Before attaching a route table, confirm that its entries are correct to avoid affecting normal workload networks.
