Use the raw table of iptables to solve ip_conntrack: Table full and dropping packet problems.

1) What is a raw table? What is it?

Iptables has five links: prerouting, input, forward, output, postrouting, and four tables: filter, Nat, mangle, raw.

The priority of the four tables ranges from high to low: raw --> mangle --> Nat --> Filter

For example, if there is a mangle table or NAT table on the prrouting chain, mangle will process the table first and then the NAT table will process it.

Raw tables are only used in the prerouting chain and output chain. Because of the highest priority, the received data packets can be processed before connection tracking. 1. If a raw table is used, the NAT table and ip_conntrack will be skipped after the raw table is processed on a chain. That is, address translation and packet Link Tracking will no longer be performed.

Raw tables can be used to improve performance without requiring Nat. For example, if a large number of web servers are accessed, port 80 can no longer enable iptables to track the links of data packets to improve the user's access speed.

2) What is the process of iptables data packets?

(Process introduction Source: http://selboo.com.cn/post/721)
How does a data packet pass through each chain and table in sequence when it arrives (figure ).

The basic steps are as follows:
1. Data Packets arrive at network interfaces, such as eth0.
2. Enter the prerouting chain of the raw table. This chain is used to process data packets before Connection Tracing.
3. If Connection Tracing is performed, process it here.
4. Enter the prerouting chain of the mangle table, where you can modify data packets, such as tos.
5. Enter the prerouting chain of the NAT table. DNAT can be performed here, but not filtered.
6. Decide whether to send the route to the local host or forward it to another host.

Here we will discuss two different situations. One is that data packets are forwarded to other hosts. At this time, it will go through the following steps:
7. Enter the forward chain of the mangle table. This is also special. After the first route decision, we can still make some modifications to the data packet before making the final route decision.
8. Enter the forward chain of the filter table. Here we can filter all forwarded packets. It should be noted that the packets forwarded here are bidirectional.
9. Enter the postrouting chain of the mangle table. All route decisions have been completed here, but the data packets are still on the local host. We can make some modifications.
10. Enter the postrouting chain of the NAT table, which is generally used for SNAT. Do not filter it here.
11. Enter the outbound network interface. Complete.

In another case, the data packet is sent to the local host, and then it passes through:
7. Enter the input chain of the mangle table. Here we can make some modifications after the route is handed over to the local host.
8. Enter the input chain of the filter table. Here we can filter all incoming data packets, no matter which network interface it comes from.
9. submit the application to the local host for processing.
10. After the processing is complete, make the route decision. Check where to issue the route.
11. Enter the output chain of the raw table, which is before the connection trace processes the local data packets.
12. Connection Tracing processes local data packets.
13. Enter the output chain of the mangle table. Here we can modify data packets, but do not filter data packets.
14. Enter the output chain of the NAT table to perform nat on the data sent by the firewall.
15. Make the route decision again.
16. Enter the output chain of the filter table to filter the local data packets.
17. Enter the postrouting chain of the mangle table, which is the same as step 1 in the previous case. Note that not only the data packets passing through the firewall are processed, but also the data packets generated by the firewall.

18. Enter the postrouting chain of the NAT table, which is the same as step 1 in the previous situation.
19. Enter the outbound network interface. Complete.

3) Use of iptables raw table

Add raw tables. Before processing other tables,-J notrack skips other tables.
In addition to the previous four states, an untracked is added.

For example:
You can use "notrack" target to allow packets with port 80 specified by rules not to enter the link trace/NAT subsystem.

Iptables-t Raw-A prerouting-D 1.2.3.4-p tcp -- dport 80-J notrack
Iptables-t Raw-A prerouting-s 1.2.3.4-p tcp -- Sport 80-J notrack
Iptables-a forward-M state -- state untracked-J accept

4) Solve ip_conntrack: Table full, dropping packet Problems

When the iptables web server is enabled, the following errors often occur when traffic is high:

Ip_conntrack: Table full, dropping Packet

This problem occurs because the Web server receives a large number of connections. When iptables is enabled, iptables will track all connections, in this way, iptables will have a link tracking table. When the table is full, the above error will occur.

The maximum capacity of the iptables Link Tracking table is/proc/sys/NET/IPv4/ip_conntrack_max. After the link times out in various States, it will be deleted from the table.

Therefore, there are two solutions:

(1) Increase the value of ip_conntrack_max.

VI/etc/sysctl. conf

Net. ipv4.ip _ conntrack_max = 393216
Net. ipv4.netfilter. ip_conntrack_max = 393216

(2): reduce ip_conntrack timeout time

VI/etc/sysctl. conf

Net. ipv4.netfilter. ip_conntrack_tcp_timeout_established = 300
Net. ipv4.netfilter. ip_conntrack_tcp_timeout_time_wait = 120
Net. ipv4.netfilter. ip_conntrack_tcp_timeout_close_wait = 60
Net. ipv4.netfilter. ip_conntrack_tcp_timeout_fin_wait = 120

The above two methods are used as a metaphor to change the pot when boiling water. In general, the problem can be solved, but in extreme cases, it is still not enough. What should I do?

In this way, you have to do the opposite, and use a pay-as-you-go method. The raw table of iptables does not process the links of data packets. we add the links with a very large number of connections to the iptables raw table.

For example, a Web server can:

Iptables-t Raw-A prerouting-D 1.2.3.4-p tcp -- dport 80-J notrack
Iptables-a forward-M state -- state untracked-J accept

5) iptables raw Table Performance Test

We did a test on a Web server. First, we did not use raw tables to observe the size of the Link Tracking table (/proc/NET/ip_conntrack:

Take a look at the iptables configuration:
CAT/etc/sysconfig/iptables

# Generated by iptables-save v1.3.5 on Wed Aug 18 10:10:52 2010
* Filter
: Input accept [0: 0]
: Forward accept [0: 0]
: Output accept [104076: 12500201]
: RH-Firewall-1-INPUT-[0: 0]
-A input-J RH-Firewall-1-INPUT
-A forward-J RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT-I lo-J accept
-A RH-Firewall-1-INPUT-p icmp-m icmp -- ICMP-type any-J accept
-A RH-Firewall-1-INPUT-p esp-J accept
-A RH-Firewall-1-INPUT-P Ah-J accept
-A RH-Firewall-1-INPUT-D 224.0.0.20.- p udp-m udp -- dport 5353-J accept
-A RH-Firewall-1-INPUT-p udp-m udp -- dport 631-J accept
-A RH-Firewall-1-INPUT-p tcp-m tcp -- dport 631-J accept
-A RH-Firewall-1-INPUT-M state -- state related, established-J accept
-A RH-Firewall-1-INPUT-p tcp-M state -- state new-m tcp -- dport 22-J accept
-A RH-Firewall-1-INPUT-p tcp-M state -- state new-m tcp -- dport 80-J accept
-A RH-Firewall-1-INPUT-J reject -- reject-with ICMP-host-prohibited
Commit
# Completed on Wed Aug 18 10:10:52 2010

Test with AB on another machine:

AB-C 1000-N 5000 http: // 192.168.20.26/index.html

View the size of the link trace table (/proc/NET/ip_conntrack) on the web server:

[Root @ Mongo HTML] # WC-L/proc/NET/ip_conntrack
5153/proc/NET/ip_conntrack

We can see that there are 5153 links in the tracking table, and the ip_conntrack: Table full, dropping packet error may be reported if the pressure is higher.

Below we enable raw tables:

Update iptables first:

[Root @ Mongo HTML] # Cat/etc/sysconfig/iptables
# Generated by iptables-save v1.3.5 on Wed Aug 18 10:10:52 2010
* Filter
: Input accept [0: 0]
: Forward accept [0: 0]
: Output accept [104076: 12500201]
: RH-Firewall-1-INPUT-[0: 0]
-A input-J RH-Firewall-1-INPUT
-A forward-J RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT-I lo-J accept
-A RH-Firewall-1-INPUT-p icmp-m icmp -- ICMP-type any-J accept
-A RH-Firewall-1-INPUT-p esp-J accept
-A RH-Firewall-1-INPUT-P Ah-J accept
-A RH-Firewall-1-INPUT-D 224.0.0.20.- p udp-m udp -- dport 5353-J accept
-A RH-Firewall-1-INPUT-p udp-m udp -- dport 631-J accept
-A RH-Firewall-1-INPUT-p tcp-m tcp -- dport 631-J accept
-A RH-Firewall-1-INPUT-M state -- state related, established, untracked-J accept
-A RH-Firewall-1-INPUT-p tcp-M state -- state new-m tcp -- dport 22-J accept
-A RH-Firewall-1-INPUT-p tcp-M state -- state new-m tcp -- dport 80-J accept
-A RH-Firewall-1-INPUT-J reject -- reject-with ICMP-host-prohibited
Commit
# Completed on Wed Aug 18 10:10:52 2010
# Generated by iptables-save v1.3.5 on Wed Aug 18 10:10:52 2010
* Raw
: Prerouting accept [116163: 9327716]
: Output accept [104076: 12500201]
-A prerouting-p tcp-m tcp -- dport 80-J notrack
-A output-p tcp-m tcp -- Sport 80-J notrack
Commit
# Completed on Wed Aug 18 10:10:52 2010

The red part is added.

Restart iptables:

Service iptables restart

You can run the iptables command to check whether it is enabled successfully:

[Root @ Mongo HTML] # iptables-t Raw-l-N
Chain prerouting (Policy accept)
Target prot opt source destination
Notrack TCP -- 0.0.0.0/0 0.0.0.0/0 tcp dpt: 80

Chain output (Policy accept)
Target prot opt source destination
Notrack TCP -- 0.0.0.0/0 0.0.0.0/0 tcp spt: 80

Then test with AB:

AB-C 1000-N 5000 http: // 192.168.20.26/index.html

View the size of the link trace table (/proc/NET/ip_conntrack:

[Root @ Mongo HTML] # WC-L/proc/NET/ip_conntrack
1/proc/NET/ip_conntrack

Only one link is tracked in the tracking table.

[Root @ Mongo HTML] # Cat/proc/NET/ip_conntrack
TCP 6 431999 established src = 192.168.20.26 DST = 192.168.20.10 sport = 22 dport = 50088 packets = 85 bytes = 10200 src = 192.168.20.10 DST = 192.168.20.26 sport = 50088 dport = 22 packets = 92 bytes = 6832 [assured] Mark = 0 secmark = 0 use = 1

You can see that iptables does not track the connection to port 80. Test results show that iptables raw tables can perfectly solve ip_conntrack: Table full, dropping packet problems.