CentOS Dropped配置錯誤

Common Causes of “Dropped” Configuration Errors in CentOS
“Dropped” issues in CentOS typically refer to network packets being discarded during transmission, often due to misconfigurations. Below are the most frequent causes and targeted solutions:

1. Network Interface Misconfiguration

Incorrect network interface settings (e.g., IP address, subnet mask, gateway) are a leading cause of dropped packets. For example, an invalid subnet mask can prevent proper communication with the local network, while a wrong gateway can block access to external networks.
Solution: Verify interface configurations in /etc/sysconfig/network-scripts/ifcfg-<interface> (e.g., ifcfg-eth0). Use ip addr or ifconfig to confirm the settings match your network requirements. Restart the network service with sudo systemctl restart network (CentOS 7/8) or sudo service network restart (older versions) to apply changes.

2. Firewall (iptables/nftables) Rule Errors

Misconfigured firewall rules can inadvertently block legitimate traffic. Common issues include:

• Default Policy: An overly restrictive default policy (e.g., INPUT DROP) without explicit ACCEPT rules for required services (SSH, HTTP).
• Conflicting Rules: Rules that overlap or contradict each other (e.g., allowing port 22 but later dropping all SSH traffic).
• Rule Syntax: Typos in IP addresses, ports, or protocols (e.g., iptables -A INPUT -p tcp --dport 22 -j DROP instead of ACCEPT).
  Solution:
• View current rules with sudo iptables -L -n -v --line-numbers to identify conflicts or incorrect targets.
• Temporarily set the default policy to ACCEPT (sudo iptables -P INPUT ACCEPT) to test connectivity, then refine rules.
• Save valid configurations to /etc/iptables/rules.v4 using sudo iptables-save > /etc/iptables/rules.v4 for persistence across reboots.

3. Kernel Connection Tracking Table Full

The ip_conntrack table tracks active connections. If it reaches its maximum size (ip_conntrack_max), the kernel drops new packets to prevent resource exhaustion. This is common under high-traffic loads (e.g., web servers, databases).
Solution:

• Check current connections and max limit:

  cat /proc/net/ip_conntrack | wc -l  # Current connections
  cat /proc/sys/net/ipv4/ip_conntrack_max  # Max limit
  

• Increase the limit temporarily: echo 100000 > /proc/sys/net/ipv4/ip_conntrack_max.
• Make the change permanent by adding net.ipv4.ip_conntrack_max = 100000 to /etc/sysctl.conf, then run sudo sysctl -p to apply.

4. Incorrect Routing Configuration

Faulty routing tables can send packets to the wrong destination or none at all. Common problems include:

• Missing Default Gateway: No route to external networks (e.g., ip route show shows no default via <gateway> entry).
• Incorrect Static Routes: Manual routes that don’t match the network topology (e.g., a route to a subnet not connected to the current interface).
  Solution:
• Verify the routing table with ip route show or route -n. Ensure there’s a valid default gateway pointing to your router.
• Delete incorrect static routes with ip route del <destination> via <gateway> dev <interface>, then add correct ones using ip route add <destination> via <gateway> dev <interface>.

5. SELinux Blocking Legitimate Traffic

SELinux (Security-Enhanced Linux) enforces mandatory access controls and may deny network traffic if policies are too strict. For example, it might block a web server from binding to a non-standard port (e.g., port 8080).
Solution:

• Check SELinux status with getenforce (returns Enforcing if active).
• Temporarily set SELinux to Permissive mode (sudo setenforce 0) to see if it resolves the issue. If so, adjust policies permanently:
  • Allow a specific port: sudo semanage port -a -t http_port_t -p tcp 8080.
  • Modify boolean values for network services: sudo setsebool -P httpd_can_network_connect 1.

6. Hardware Issues (Network Interface Card - NIC)

Hardware faults in the NIC or network cable can cause packet loss. Symptoms include:

• Ring Buffer Full: The NIC’s receive buffer overflows when the CPU can’t process packets fast enough (visible via ethtool).
• Physical Damage: Cracked cables, loose connectors, or faulty NIC ports.
  Solution:
• Use ethtool <interface> (e.g., ethtool eth0) to check for errors like rx_errors, dropped counters, or rx_no_buffer_count.
• Replace damaged cables or try a different NIC/port on the switch/router.
• Adjust Ring Buffer size (if supported) with ethtool -G eth0 rx 4096 tx 4096 (values vary by hardware).

7. System Resource Exhaustion

Insufficient system resources (memory, CPU) can prevent the kernel from processing packets, leading to drops. For example, low memory forces the system to swap, slowing down network processing.
Solution:

• Monitor resource usage with top or htop. Look for high CPU/memory consumption by processes.
• Free up memory by killing unnecessary processes or increasing swap space:

  sudo fallocate -l 2G /swapfile  # Create 2GB swap file
  sudo chmod 600 /swapfile
  sudo mkswap /swapfile
  sudo swapon /swapfile
  echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab  # Make permanent
  

• Upgrade hardware if resource usage is consistently high.

General Troubleshooting Steps

Regardless of the cause, follow these steps to isolate the issue:

1. Test Connectivity: Use ping <destination> to check basic connectivity.
2. Check Logs: Review system logs (/var/log/messages, /var/log/syslog, or journalctl -u network) for error messages related to dropped packets.
3. Isolate Traffic: Use tcpdump to capture traffic on the affected interface and identify patterns (e.g., sudo tcpdump -i eth0 icmp to check ICMP traffic).
4. Compare Configurations: If the issue started recently, compare current configurations (network files, firewall rules) with backups to identify changes.