Why Are Lots of source ip_type Logs Generated on the VNC?
Scenario
Cluster version: v1.15.6-r1
Cluster type: CCE cluster
Network model: VPC network
Node operating system: CentOS 7.6
When containers on the preceding nodes communicate with each other, the container networking component reports a large number of source ip_types or "not ipvlan but in own host logs" on the VNC. As a result, the VNC page on the node and the container networking performance in high-load scenarios are affected. Symptoms of this problem are as follows:
Fault Locating
1. Quick Check
This method applies to pay-per-use nodes. Check the node creation time on the CCE console. CentOS 7.6 nodes created on or after February 24, 2021 do not have this problem.
2. Accurate Check (General)
You can perform the following steps to check whether a node is affected:
- Log in to each CCE node as user root.
- Run the following command to check whether the node is risky:
ETH0_IP=$(ip addr show eth0 | grep "inet " | head -n 1 | awk '{print $2}' | awk -F '/' '{print $1}') ;arping -w 0.2 -c 1 -I gw_11cbf51a 1.1.1.1 >/dev/null 2>&1 ; echo ;dmesg -T | grep -E "==not ipvlan but in own host|==source ip_type" 1>/dev/null 2>&1 ; if [[ "$?" == "0" ]];then echo "WARNING, node ${ETH0_IP} is affected"; else echo "node ${ETH0_IP} works well"; fi;
In this command, 1.1.1.1 is an example IP address, which is used only to trigger ARP packet sending. You can use it or replace it with a valid IP address.
- If the following information is displayed, the node has potential risks. 10.2.0.35 is the IP address of the eth0 NIC on the node. The actual IP address will be displayed in your practice.
WARNING, node 10.2.0.35 is affected
If the following information is displayed, the node does not have this problem:
node 10.2.0.35 works well
Procedure
If you still want to use the node, reset the CentOS 7.6 nodes in the cluster to upgrade the networking components to the latest version. For details, see Resetting a Node.
If you want to delete the risky node and purchase a new one, see Deleting a Node and Buying a Node.
Network Fault FAQs
- How Do I Locate a Workload Networking Fault?
- Why the ELB Address Cannot Be used to Access Workloads in a Cluster?
- Why the Ingress Cannot Be Accessed Outside the Cluster?
- Why Does the Browser Return Error Code 404 When I Access a Deployed Application?
- What Should I Do If a Container Fails to Access the Internet?
- What Can I Do If a VPC Subnet Cannot Be Deleted?
- How Do I Restore a Faulty Container NIC?
- What Should I Do If a Node Fails to Connect to the Internet (Public Network)?
- How Do I Resolve a Conflict Between the VPC CIDR Block and the Container CIDR Block?
- What Should I Do If the Java Error "Connection reset by peer" Is Reported During Layer-4 ELB Health Check
- How Do I Locate the Service Event Indicating That No Node Is Available for Binding?
- Why Does "Dead loop on virtual device gw_11cbf51a, fix it urgently" Intermittently Occur When I Log In to a VM using VNC?
- Why Does a Panic Occasionally Occur When I Use Network Policies on a Cluster Node?
- Why Are Lots of source ip_type Logs Generated on the VNC?
- What Should I Do If Status Code 308 Is Displayed When the Nginx Ingress Controller Is Accessed Using the Internet Explorer?
- What Should I Do If an Nginx Ingress Access in the Cluster Is Abnormal After the Add-on Is Upgraded?
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbotmore