3.1.1. ip_autoconfig

3.1.2. ip_default_ttl

The ip_default_ttl variable tells the kernel what Time To Live to set as default on packets that leaves this host. This tells how long the packets may live on the internet before they are dropped. Each time the packet passes a router, firewall, computer, etcetera, the TTL is decremented with one step.

The default value for ip_default_ttl is 64, which is a fairly good TTL which will not cause too much trouble. It is very unlikely to time out in transit to the host in question. This variable takes an unsigned integer, but the actual TTL field is only 8 bit long. The value may in other words be as high as 255 and as low as 0, however 255 could be considered rude and 0 wouldn't leave your computer at all. 64 is a good value, unless you are trying to connect to computers extremely far away counted in hops or jumps. These would then time out. As it looks today, I have pretty much never seen a host that lives more than 30 hops away on the internet, so I don't think there is any need to make this value higher than the default value for now.

Setting the TTL to 255 would be considered rude since this would make a packet live an extremely long time on the internet. If there would be a glitch in 2 routers, this packet could bounce back and forth for a huge amount of time, eating away on the bandwidth without any reason at all. Normally, don't set this value higher than 100 or something alike.

3.1.3. ip_dynaddr

The ip_dynaddr variable is used to allow a few problems with dynamic addressing to be fixed. This allows diald oneshot connections to get established by dynamically changing packet source address, and sockets if local processes. This option was implemented for TCP diald-box connections and Masquerading connections. Masquerading will in other words work 100% with this option, letting Masquerading switch source adress of packets if the boxes own address change.

This option takes an integer, but only makes use of 3 possible states, 0, 1 or 2.

• 0 means that this option is turned off, which is also the default behaviour.

• 1 means that the option is enabled and running.

• Any non 0 or 1 values means that we have turned on verbose mode, which in turn will add extra debugging messages that you may use to get things to work properly.

If this variable is turned on and forwarding interface changes, this is what may happen

• Socket and packet source address is rewritten on retransmissions while in SYN_SENT state. This is the diald-box processes.

• Outbound masqueraded source address changes on output, when internal host does retransmission, until a packet from the outside is received by the tunnel.

This is especially helpful for auto-dialup links (diald), where the actual outgoing address is unknown at the moment the link is going up. This enables the same, local and masqueraded, connection requests that brought the link up to actually establish their connections. This means that we will not have to first issue an connection request just to bring the connection up, and then have to issue the "real" connection request when we have actually established the connection.

3.1.4. ip_forward

The ip_forward variable is used to turn IP forwarding on or off. This means that we can turn off the functions for forwarding packets between interfaces, which lets the computer act as a firewall, or router. Note that this is an extremely important variable for Network Address Translation, firewalling, routing, masquerading, and all other things where we actually let packets through the box to another network, as you can understand.

This is an boolean variable. In other words, it will take a 1 or a 0. The default value for this variable is 0, or disabled. As you can understand, 0 means disabled and 1 means enabled.

Note that this is an very special variable since it will reset all configuration parameters to their default states if it is changed. For a complete list of the exact states, look closer at RFC1122 for hosts and RFC1812 for routers.

3.1.5. ip_local_port_range

The ip_local_port_range variable consists of two integers which tells the kernel which ports to use for client connections. This means, all connections going from our box to some other box and where we are the client. The first port is the lower bound and the second one is the upper bound.

The default value in this variable depends on how much memory you have. If you have more than 128 megabytes of physical memory, the lower bound will be 32768 and the upper bound will be 61000. If the computer has less than 128 megabytes of physical memory, the lower bound will be 1024 and the upper bound will be 4999, or even less.

This number defines the possible active connections which this system can issue simultaneously (ie, at the same time) to other systems that does not support the TCP extension timestamps.

If you have tcp_tw_recycle enabled (the default behaviour) range 1024-4999 is enough to issue up to 2000 connections per second to systems supporting timestamps. In other words, this should be more than enough for most of us.

3.1.6. ip_no_pmtu_disc

The ip_no_pmtu_disc disables PMTU (Path Maximum Transfer Unit) discovery if enabled. In most cases this is good, so it is per default set to FALSE (ie, Path Maximum Transfer Unit is used). However, in some cases this is bad and may lead to broken connectivity. If you are experiencing problems like this, you should turn this option off and set your MTU to a reasonable value yourself.

Do note that MTU and PMTU are two different things. MTU tells the kernel the maximum transfer unit for our connection, but not over the whole connection to the other end. PMTU discovery tries to discover the maximum transfer unit to specific hosts, including all the intermediate hops on the way there.

The default value is that the ip_no_pmtu_disc is FALSE, as already stated. If this is set to TRUE, PMTU discovery is turned off. The ip_no_pmtu_disc takes a boolean value, in other words either an 1 or a 0, where 1 is on and 0 is off.

3.1.7. ip_nonlocal_bind

The ip_nonlocal_bind variable allows us to set if local processes should be able to bind to non-local IP addresses. This could be quite useful, in such cases where we want specific programs or applications to be able to listen to non-local IP adresses, such as sniffing for traffic to a specific host which may commit bad things, etcetera. The variable may, however, break some applications and they will no longer work.

The ip_nonlocal_bind variable takes a boolean value which can be set to 1 or 0. If the variable is set to 0, this option is turned off and if it is set to 1 it is turned on. The default value is to turn this option off, or 0 in other words.

3.1.8. ipfrag_high_thresh

The ipfrag_high_thresh tells the kernel the maximum amount of memory to use to reassemble IP fragments. When and if the high threshold is reached, the fragment handler will toss all packets until the memory usage reaches ipfrag_low_thresh instead. This means that all fragments that reached us during this time will have to be retransmitted.

Packets are fragmented if they are too large to pass through a certain pipe. If they are to large, the box that is trying to transmit them breaks them down into smaller pieces and send each piece one by one. When these fragments reaches their destination, they need to be defragmented (ie, put together again) to be read properly. Note that IP Fragmentation are in general a good thing, but there are a lot of people that do bad things with them since fragments are inherently a security problem.

The ipfrag_high_thresh variable takes an integer value, which would mean 0 through 2147483647 bytes can be assigned to be the upper limit of this function. The default value is 262144 bytes, or 256 kilobytes, which should work well in even the most extreme cases.

3.1.9. ipfrag_low_thresh

This option has a lot to do with the ipfrag_high_thresh option. The ipfrag_low_thresh is the lower limit at which packets should start being assembled again. What this means, all in all, is that our fragmentation handler has an queue that grows larger the more packets are waiting in the queue to be defragmentized, when this queue grows to ipfrag_high_thresh byte size, the fragmentation handler queue will stop queueing any further fragments until we reach the ipfrag_low_thresh again. This stops our system from being overloaded with fragmentized packets and may stop certain Denial of Service attacks.

This variable takes an integer value between 0 and 2147483647, and refers to the amount of bytes used at which the fragmentation handler should resume the receiving of IP fragments again. Per default it is set to 196608 bytes, or 192 kilobytes which should be a reasonable amount of memory set aside for this task even in the hardest of attacks. This value should be lower than ipfrag_high_thresh, or else it will be invalid.

3.1.10. ipfrag_time

The ipfrag_time variable tells the IP fragmentation handler how long to keep an IP fragment in memory, counted in seconds. This only refers to fragments that has been impossible to reassemble since fragments that has been assembled most probably has already been sent on to either the next layer, or to the next host.

The ipfrag_time variable takes an integer as its input and the value is counted as seconds. In other words, if you input 5 to this variable, it counts as 5 seconds.

3.2.1. inet_peer_gc_maxtime

The inet_peer_gc_maxtime variable tells the garbage collector how often to pass over the inet peer storage memory pool during low, or absent, memory pressure. This value is in effect under the reversed conditions of the inet_peer_gc_mintime in other words. It works exactly the same as the inet_peer_gc_mintime, except for the fact that it will be in effect under different system loads. This variable is also measured in jiffies, which is explained closer in appendix A.

The inet_peer_gc_maxtime variable takes an integer value and has a default value of 120 jiffies. 120 jiffies should be a good value for most workstations and servers.

3.2.2. inet_peer_gc_mintime

The inet_peer_gc_mintime variable sets the minimum time between garbage collections (gc) passes in the inet peer storage under heavy memory pressure. If the system is under heavy utilization and there is a lot of constraints on the memory pool, this timer is used to tell the garbage collector how often to pass over the memory pool used by the inet peer storage, in jiffies. For a complete explanation of jiffies, see appendix A.

The inet_peer_gc_mintime variable takes an integer value and has a default value of 10 jiffies. This should be a fairly good value for most users and servers.

3.2.3. inet_peer_maxttl

This is the maximum time to live for the inet peer entries. Unused entries will expire after this period of time if there is no memory pressure on the pool. This would in other words mean when the number of entries in the pool is very small, and likely situations.

The inet_peer_maxttl variable takes an integer value, and is measured in jiffies. For a complete explanation of jiffies, see appendix A.

3.2.4. inet_peer_minttl

This is the minimum time to live for inet peer entries. This should be set to an high enough value to cover fragment time to live in the reassembling side of fragmented packets. The minimum time to live is guaranteed if the pool size is less than inet_peer_threshold.

The inet_peer_minttl variable takes an integer value, and is measured in jiffies. For a complete explanation of jiffies, see appendix A.

3.2.5. inet_peer_threshold

The inet_peer_threshold variable tells the approximate size of the inet peer storage. When this limit is reached, peer entries will be thrown away agressively, using the inet_peer_gc_mintime timeout. This threshold will also determine how long an entry may "live" in the peer storage, in other word it is one of the parts which decides the entries time to live. To put it simple, the higher this value is, the longer the time to live within your system.

This variable takes an integer and defaults to the value 65664 bytes.

3.3.1. tcp_abort_on_overflow

The tcp_abort_on_overflow variable tells the kernel to reset new connections if the system is currently overflowed with new connection attempts that the daemon(s) can not handle. What this means, is that if the system is overflowed with 1000 large requests in a burst, connections may be reset since we can not handle them if this variable is turned on. If it is not set, the system will try to recover and handle all requests.

This variable takes an boolean value (ie, 1 or 0) and is per default set to 0 or FALSE. Avoid enabling this option except as a last resort since it most definitely harm your clients. Before considering using this variable you should try to tune up your daemons to accept connections faster.

3.3.2. tcp_adv_win_scale

This variable is used to tell the kernel how much of the socket buffer space should be used for TCP window size, and how much to save for an application buffer. If tcp_adv_win_scale is negative, the following equation is used to calculate the buffer overhead for window scaling:

Where bytes are the amount of bytes in the window. If the tcp_adv_win_scale value is positive, the following equation is used to calculate the buffer overhead:

The tcp_adv_win_scale variable takes an integer value and is per default set to 2. This in turn means that the application buffer is 1/4th of the total buffer space specified in the tcp_rmem variable.

3.3.3. tcp_app_win

This variable tells the kernel how many bytes to reserve for a specific TCP window in the TCP sockets memory buffer where the specific TCP window is transfered in. This value is used in a calculation that specifies how much of the buffer space to reserve that looks as the following:

As you may understand from the above calculation, the larger this value gets, the smaller will the buffer space be for the specific window. The only exception to this calculation is 0, which tells the kernel to reserve no space for this specific connection. The default value for this variable is 31 and should in general be a good value. Do not change this value unless you know what you are doing.

3.3.4. tcp_dsack

This option is required to send duplicate SACKs which was briefly described in the tcp_sack variable explanation. This is described in detail within the RFC 2883. This RFC document explains in detail how to handle situations where a packet is received twice or out of order. D-SACK is an extension to standard SACK and is used to tell the sender when a packet was received twice (ie, it was duplicated). The D-SACK data can then be used by the transmitter to improve network settings and so on. This should be 100% backwards compatible with older implementations as long as the previous implementors have not tried to implement this into the old SACK option in their own fashion. This is extremely rare and should not be a problem for anyone.

The tcp_dsack variable uses a boolean value and is per default set to 1, or turned on. Of course, this behaviour is only used if tcp_sack is turned on since tcp_dsack is heavily dependant upon tcp_sack. In almost all cases this should be a good idea to have turned on.

3.3.5. tcp_ecn

The tcp_ecn variable turns on Explicit Congestion Notification in TCP connections. This is used to automatically tell the host when there are congestions in a route to a specific host or a network. This can be used to throttle the transmitters to send packets in a slower rate over that specific router or firewall. Explicit Congestion Notification (ECN) is explained in detail in the RFC 3168 - The Addition of Explicit Congestion Notification (ECN) to IP document and there is also a performance evaluation of the addition of ECN available in the RFC 2884 - Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks document.

Briefly, this document details how we could notify other hosts when we are congested or not, which in turn will make us able to choose other routes in preference over the currently used route, or to simply send less data until we no longer receive congestion messages.

There are still some old firewalls and routers out on the Internet that will filter away all IP packets that has the ECN bits set. They are fairly uncommon these days, but if you are unlucky, you may run into them. If you do experience connection problems to specific hosts, try turning ECN off and see how things go. If you find the actual host blocking the ECN packets, try getting in touch with the administrators and warn them about this. A deeper explanation of the problem, as well as a list of the most common hardware that causes this trouble is available, and can be found in the Other resources appendix, under the ECN-under-Linux Unofficial Vendor Support Page heading.

The tcp_ecn variable takes a boolean value and is per default set to 0, or turned off. If you want to turn this on in your kernel, you should set this variable to 1.

3.3.6. tcp_fack

The tcp_fack variable enables the Forward Acknowledgement system in Linux. Forward Acknowledgement is a special algorithm that works on top of the SACK options, and is geared at congestion controlling.

The main idea of FACK algorithm is to consider the most forward selective acknowledgement sequence number as a sign that all the previous un(selectively) acknowledged segments were lost. This observation allows to improve recovery of losses singificantly. This assumption breaks in presence of packet reordering, in which case the FACK algorithm is automatically turned off for that specific connection.

This algorithm was originally created by Matthew Mathis and co-authors. You can find the papers describing the algorithm more closely over at http://www.psc.edu/~mathis/.

The tcp_fack variable takes a boolean value, and is per default set to 1, or turned on. This behaviour is not used if tcp_sack is turned off since it is heavily dependant upon tcp_sack.

3.3.7. tcp_fin_timeout

The tcp_fin_timeout variable tells kernel how long to keep sockets in the state FIN-WAIT-2 if you were the one closing the socket. This is used if the other peer is broken for some reason and don't close its side, or the other peer may even crash unexpectedly. Each socket left in memory takes approximately 1.5Kb of memory, and hence this may eat a lot of memory if you have a moderate webserver or something alike.

This value takes an integer value which is per default set to 60 seconds. This used to be 180 seconds in 2.2 kernels, but was reduced due to the problems mentioned above with webservers and problems that arose from getting huge amounts of connections.

Also see the tcp_max_orphans and tcp_orphan_retries variables for more information.

3.3.8. tcp_keepalive_intvl

The tcp_keepalive_intvl variable tells the kernel how long to wait for a reply on each keepalive probe. This value is in other words extremely important when you try to calculate how long time will go before your connection will die a keepalive death.

The variable takes an integer value and the default value is 75 seconds. This is in the higher regions and should be concidered the higher threshold on what values should be concidered normal to use. The default values of the tcp_keepalive_probes and tcp_keepalive_intvl can be used to get the default time it will take before the connection is timed out because of keepalive.

With the default values of sending 9 probes with 75 seconds for each, it would take approximately 11 minutes before the connection is timed out, counting from when we start the probing which in turn will happen 2 hours from the time we last saw any traffic on the connection.

3.3.9. tcp_keepalive_probes

The tcp_keepalive_probes variable tells the kernel how many TCP keepalive probes to send out before it decides a specific connection is broken.

This variable takes an integer value, which should generally not be set higher than 50 depending on your tcp_keepalive_time value and the tcp_keepalive_interval. The default value is to send out 9 probes before telling the application that the connection is broken.

3.3.10. tcp_keepalive_time

The tcp_keepalive_time variable tells the TCP/IP stack how often to send TCP keepalive packets to keep an connection alive if it is currently unused. This value is only used when keepalive is enabled.

The tcp_keepalive_time variable takes an integer value which is counted in seconds. The default value is 7200 seconds, or 2 hours. This should be a good value for most hosts and will not take too much network resources from you. Do not set this value to low since it will then use up your network resources with unnecessary traffic.

3.3.11. tcp_max_orphans

The tcp_max_orphans variable tells the kernel how many TCP sockets that are not attached to any user file handle to maintain. In case this number is exceeded, orphaned connections are immediately reset and a warning is printed.

The only reason for this limit to exist is to prevent some simple DoS attacks. Generally you should not rely on this limit, nor should you lower it artificially. If need be, you should instead increase this limit if your network environment requires such an update. Increasing this limit may require that you get more memory installed to your system. If you hit this limit, you may also tune your network services a little bit to linger and kill sockets in this state more aggressively.

This variable takes an integer value and is per default set to 8192, but heavily depends upon how much memory you have. Each orphan that currently lives eats up 64Kb of unswappable memory, which means that one hell of a lot of data will be used up if problems arise.

If you run into this limit, you will get an error message via the syslog facility kern.info that looks something like this: TCP: too many of orphaned sockets If this shows up, either upgrade the box in question or look closer at the tcp_fin_timeout or tcp_orphans_retries which should give you some help with getting rid of huge amounts of orphaned sockets.

3.3.12. tcp_max_syn_backlog

The tcp_max_syn_backlog variable tells your box how many SYN requests to keep in memory that we have yet to get the third packet in a 3-way handshake from. The tcp_max_syn_backlog variable is overridden by the tcp_syncookies variable, which needs to be turned on for this variable to have any effect. If the server suffers from overloads at peak times, you may want to increase this value a little bit.

This variable takes an integer value and is per default set to different values depending on how much memory you have. If you have less than 128 Mb of RAM, it is set to a maximum of 128 SYN backlog requests. If you have more than 128 Mb of RAM, it is set to 1024 SYN backlog requests.

If this value is raised to a larger value than 1024 it would most probably be better to change the TCP_SYNQ_HSIZE value and recompile your kernel. The TCP_SYNQ_HSIZE variable is set in linux/include/tcp.h. This value should be set so to keep this formula true: TCP_SYNQ_HSIZE*16<=tcp_max_syn_backlog In other words, TCP_SYNQ_HSIZE times 16 should be smaller than or equal to tcp_max_syn_backlog.

3.3.13. tcp_max_tw_buckets

The tcp_max_tw_buckets variable tells the system the maximum number of sockets in TIME-WAIT to be held simultaneously. If this number is exceeded, the exceeding sockets are destroyed and a warning message is printed to you. The reason for this limit to exist is to get rid of really simple DoS attacks.

The tcp_max_tw_buckets variable takes an integer value which tells the system at which point to start destroying timewait sockets. The default value is set to 180000. This may sound much, but it is not. If anything, you should possibly need to increase this value if you start receiving errors due to this setting.

You should not lower this limit artificially. If you start receiving errors indicating this problem in normal operation, you should instead increase this value if your network requires so. This may lead to the requirement of more memory installed in the machine in question.

3.3.14. tcp_mem

The tcp_mem variable defines how the TCP stack should behave when it comes to memory usage. It consists of three values, just as the tcp_wmem and tcp_rmem variables. The values are measured in memory pages (in short, pages). The size of each memory page differs depending on hardware and configuration options in the kernel, but on standard i386 computers, this is 4 kilobyte or 4096 bytes. On some newer hardware, this is set to 16, 32 or even 64 kilobytes. All of these values have no real default value since it is calculated at boottime by the kernel, and should in most cases be good for you and most usages you may encounter.

The first value specified in the tcp_mem variable tells the kernel the low threshold. Below this point, the TCP stack do not bother at all about putting any pressure on the memory usage by different TCP sockets.

The second value tells the kernel at which point to start pressuring memory usage down. This so called memory pressure mode is continued until the memory usage enters the lower threshold again, and at which point it enters the default behaviour of the low threshold again. The memory pressure mode presses down the TCP receive and send buffers for all the sockets as much as possible, until the low mark is reached again.

The final value tells the kernel how many memory pages it may use maximally. If this value is reached, TCP streams and packets start getting dropped until we reach a lower memory usage again. This value includes all TCP sockets currently in use.

This variable may give tremenduous increase in throughput on high bandwidth networks, if used properly together with the tcp_rmem and tcp_wmem variable. The tcp_rmem variable doesn't need too much manual tuning however, since the Linux 2.4 kernels has very good autotuning handlings on this aspect, but the other two may be worth looking at. For more information about this, look at the TCP Tuning Guide.

3.3.15. tcp_orphan_retries

The tcp_orphan_retries variable tells the TCP/IP stack how many times to retry to kill connections on the other side before killing it on our own side. If your machine runs as a highly loaded http server it may be worth thinking about lowering this value. http sockets will consume large amounts of resources if not checked.

This variable takes an integer value. The default value for this variable is 7, which would approximately correspond to 50 seconds through 16 minutes depending on the Retransmission Timeout (RTO). For a complete explanation of the RTO, read the "3.7. Data Communication" section in RFC 793 - Transmission Control Protocol.

Also see the tcp_max_orphans variable for more information.

3.3.16. tcp_reordering

The tcp_reordering variable tells the kernel how much a TCP packet may be reordered in a stream without assuming that the packet was lost somewhere on the way. If the packet is assumed lost, the TCP stack will automatically go back into a slow start since it believes packets may have been lost due to congestion somewhere. The TCP stack will also fall back from using the FACK algorithm for this specific host in the future.

This variable takes an integer variable and is per default set to 3. This should in general be a good value and you should not touch it. If this value is lowered, it may result in bad network performance, especially if packets often get reordered in connections.

This variable is overridden by the reordering option in the ip route command starting with kernels 2.3.15 and higher. If reordering is not given to the ip route command, the default is taken from the sysctl tcp_reordering.

3.3.17. tcp_retrans_collapse

This variable implements a bug in the TCP protocol so it will be able to talk to certain other buggy TCP stacks. Without implementing this bug in the TCP stack, we would be unable to talk to certain printers that has this bug built in. This bug makes the TCP stack try to send bigger packets on retransmission of packets to work around bugs in those printers and other hardware implementations.

This variable takes a boolean value and is normally set to 1, or on. Implementing this bug workaround will not break compatibility from our host to others, but it will make it possible to speak to those printers. In general, it should not be a dangerous workaround, but you may turn it off if you receive weird error messages.

3.3.18. tcp_retries1

The tcp_retries1 variable tells the kernel how many times it should retry to get to a host before reaching a decision that something is wrong and that it should report the suspected problem to the network layer. The minimal value here specified by RFC ???? is 3, which is also the default. This corresponds to 3 seconds through 8 minutes depending on your Retransmission timeout (RTO). For a good explanation of the Retransmission timeout, read the "3.7. Data Communication" section in RFC 793 - Transmission Control Protocol.

This variable takes an integer, which is per default set to 3 as explained above. The lower limit is 3 if you want to follow standards, and the upper bound should be lower than 100 or so since timeouts could be worse than horrible if this high.

3.3.19. tcp_retries2

The tcp_retries2 value tells the kernel how many times to retry before killing an alive TCP connection. This limit is specified to a minimum of 100 seconds in RFC 1122, but is normally way to short.

The variable takes an integer value and is set to 15 per default. This value corresponds to 13-30 minutes depending on the Retransmission timeout (RTO). Generally this should be a good timeout, you may bring it down but not necessarily.

3.3.20. tcp_rfc1337

The tcp_rfc1337 variable implements the solution found in RFC 1337 - TIME-WAIT Assassination Hazards in TCP to TIME-WAIT Assassination. In short, the problem is that old duplicate packets may interfer with new connections, and lead to three different problems. The first one is that old duplicate data may be accepted erroneously in new connections, leading to the sent data becoming corrupt. The second problem is that connections may become desynchronized and get into an ACK loop because of old duplicate packets entering new connections, which will become desynchronized. The third and last problem is that old duplicate packets may enter newly established connections erroneously and kill the new connection.

There are three possible solutions to this according to the mentioned RFC, however, one solution is only partial and not a long term solution, while the last requires heavy modifications of the TCP protocol, and is hence not a viable option.

The final solution that the linux kernel implements with this option, is to simply ignore RST packets sent to a socket while it is in the TIME-WAIT state. In use together with 2 minute Maximum Segment Life (MSL), this should eliminate all three problems discussed in RFC 1337.

3.3.21. tcp_rmem

The tcp_rmem variable is pretty much the same as the tcp_wmem, except in one large area. It tells the kernel the TCP receive memory buffers instead of the transmit buffer which is defined in tcp_wmem. This variable takes 3 different values, just the same as the tcp_wmem variable.

The first value tells the kernel the minimum receive buffer for each TCP connection, and this buffer is always allocated to a TCP socket, even under high pressure on the system. This value is set to 4096 bytes, or 4 kilobytes, in newer kernels, but was in previous kernels set to 8192 bytes or 8 kilobytes. This should generally be a good value, and you should avoid raising this value if you are sporadically experiencing large bursts and high network loads since the system may get into even worse problems then.

The second value specified tells the kernel the default receive buffer allocated for each TCP socket. This value overrides the /proc/sys/net/core/rmem_default value used by other protocols. The default value here is 87380 bytes, or 85 kilobytes. This value is used together with tcp_adv_win_scale and tcp_app_win to calculate the TCP window size, which is discussed within the explanations of those variables. This value should under normal circumstances not be touched either since it may result in similar problems as with the first value in this variable.

This variable may give tremenduous increase in throughput on high bandwidth networks, if used properly together with the tcp_mem and tcp_wmem variable. The tcp_rmem variable doesn't need too much manual tuning however, since the Linux 2.4 kernels has very good autotuning handlings on this aspect, but the other two may be worth looking at. For more information about this, look at the TCP Tuning Guide.

The third and last value specified in this variable specifies the maximum receive buffer that can be allocated for a TCP socket. This value is overridden by the /proc/sys/net/core/rmem_max if the ipv4 value is larger than the core value. You need to look at the core value before you do any changes to the ipv4 value in other words. The default value here is a double up of the second value specified. In other words, 87380 * 2 bytes, or 174760 bytes (170 kilobytes). Generally this should be a good value and should not need to be changed.

3.3.22. tcp_sack

The tcp_sack variable enables Selective Acknowledgements (SACK) as they are defined in RFC 2883 - An Extension to Selective Acknowledgement (SACK) Option for TCP and RFC 2883 - An Extension to Selective Acknowledgement (SACK) Option for TCP. These RFC documents contain information on an TCP option that was especially developed to handle lossy connections.

If this variable is turned on, our host will set the SACK option in the TCP option field in the TCP header when it sends out a SYN packet. This tells the server we are connecting to that we are able to handle SACK. In the future, if the server knows how to handle SACK, it will then send ACK packets with the SACK option turned on. This option selectively acknowledges each segment in a TCP window. This is especially good on very lossy connections (connections that loose a lot of data in the transfer) since this makes it possible to only retransmit specific parts of the TCP window which lost data and not the whole TCP window as the old standards told us to do. This means that if a certain segment of a TCP window is not received, the receiver will not return a SACK for that segment. The sender will then know which packets where not received by the receiver, and will hence retransmit that packet. For redundancy, this option will fill up all space possibly within the option space, 40 bytes per segment. Each SACK'ed packet takes up 2 32-bit unsigned integers and hence the option space can contain 4 SACK'ed segments. However, normally the timestamp option is used in conjunction with this option. The timestamp option takes up 10 bytes of data, and hence only 3 segments may be SACK'ed in each packet in normal operation.

If you know that you will be sending data over an extremely lossy connection such as a bad internet connection at one point or another, this variable is recommended to turn on. However, if you will only send data over an internal network consisting of a perfect condition 2 feet cat-5 cable and both machines being able to keep up with maximum speed without any problems, you should not need it. This option is not required, but it is definitely a good idea to have it turned on. Note that the SACK option is 100% backwards compatible, so you should not run into any problems talking to any other hosts on the internet who do not support it.

The tcp_sack option takes a boolean value. This is per default set to 1, or turned on. This is generally a good idea and should cause no problems.

3.3.23. tcp_stdurg

This variable enables or disables RFC 1122 compliance. The default behaviour is to be BSD 4.2 compliant, which follows the RFC 793 explanation of the URG flag. If this variable is turned on, we may be unable to communicate properly with certain hosts on the internet, or more specifically, those hosts on the internet that are BSD 4.2 compliant. For more information on the changes, read the RFC 1122 - Requirements for Internet Hosts -- Communication Layers under the section "4.2.2.4 Urgent Pointer: RFC 793 Section 3.1 explanation" which refers back to RFC 793 - Transmission Control Protocol as can be seen in the name of the section mentioned.

The tcp_stdurg variable takes a boolean value and is per default set to 0, or FALSE. If this is turned on, your box may be unable to talk to certain hosts as described above.

3.3.24. tcp_syn_retries

The tcp_syn_retries variable tells the kernel how many times to try to retransmit the initial SYN packet for an active TCP connection attempt.

This variable takes an integer value, but should not be set higher than 255 since each retransmission will consume huge amounts of time as well as some amounts of bandwidth. Each connection retransmission takes aproximately 30-40 seconds. The default setting is 5, which would lead to an aproximate of 180 seconds delay before the connection times out.

3.3.25. tcp_synack_retries

The tcp_synack_retries setting tells the kernel how many times to retransmit the SYN,ACK reply to an SYN request. In other words, this tells the system how many times to try to establish a passive TCP connection that was started by another host.

This variable takes an integer value, but should under no circumstances be larger than 255 for the same reasons as for the tcp_syn_retries variable. Each retransmission will take aproximately 30-40 seconds. The default value of the tcp_synack_retries variable is 5, and hence the default timeout of passive TCP connections is aproximately 180 seconds.

3.3.26. tcp_syncookies

The tcp_syncookies variable is used to send out so called syncookies to hosts when the kernels syn backlog queue for a specific socket is overflowed. This means that if our host is flooded with several SYN packets from different hosts, the syn backlog queue may overflow, and hence this function starts sending out cookies to see if the SYN packets are really legit.

This variable is used to prevent an extremely common attack that is called a "syn flood attack". The tcp_syncookies variable takes an boolean value which can either be set to 0 or 1, where 0 means off. The default setting is to turn this function off.

There has been a lot of discussions about the problems and flaws with syncookies in the past. Personally, I choose to look on SYN cookies as something fairly usefull, and since it is not causing any strangeness under normal operation, it should not be very dangerous. However, it may be dangerous, and you may want to see below. The tcp_syncookies option means that under high load the system will make new connections without advanced features like ECN or SACK being used. If syncookies are being triggered during normal load rather than an attack you should tune the tcp queue length and the servers handling the load. You must not use this facility to help a highly loaded server to stand down from legal connections. If you start to see syn flood warnings in your logs, and they show out to be legit connections, you may tune the tcp_max_syn_backlog, tcp_synack_retries and tcp_abort_on_overflow variables.

3.3.27. tcp_timestamps

The tcp_timestamps variable tells the kernel to use timestamps as defined in RFC 1323. In short, this is an TCP option that can be used to calculate the Round Trip Measurement in a better way than the retransmission timeout method can. This should be backwards compatible in almost all circumstances so you could very well turn this on if your host lives on a high speed network. If you only use up to an 10mbps connection of some sort(LAN or Internet or anything for that matter), you should manage fairly well without this option, and at really low speeds, you may even be better off with this variable turned off.

This variable takes a boolean value and is per default set to 1, or enabled. Generally this should be a good idea to have turned on. The only exception would be if you live on an extremely slow connection such as a 56 kbps modem connection to the Internet.

For more technical information about this option read section 4 of the RFC 1323 - TCP Extensions for High Performance. This document discusses the technical and theoretical introduction of these options and how it should work.

3.3.28. tcp_tw_recycle

This variable enables the fast recycling function of TIME-WAIT sockets. Unless you know what you are doing you should not touch this function at all.

The tcp_tw_recycle variable takes an integer value and the default value is 0 from my experience and my understanding of the source code of linux. In other words, the statement in the linux/Documentation/ip-sysctl.txt file is wrong unless I am mistaken.

Do not reset this from its default value unless you know what you are doing and/or have gotten the advice or request from an technical expert or kernel coder.

3.3.29. tcp_window_scaling

The tcp_window_scaling variable enables window scaling as it is defined in RFC 1323. This RFC specifies how we can scale TCP windows if we are sending them over Large Fat Pipes (LFP). When sending TCP packets over these large pipes, we experience heavy bandwidth loss due to the channels not being fully filled while waiting for ACK's for our previous TCP windows. The main problem is that a TCP Window can not be larger than 2**16 bytes, or 65Kb large. Enabling tcp_window_scaling enables a special TCP option which makes it possible to scale these windows to a larger size, and hence reduces bandwidth losses due to not utilizing the whole connection.

This variable takes a boolean value and is per default set to 1, or true. If you want to turn this off, set it to 0.

For more information about TCP window scaling, read the RFC 1323 - TCP Extensions for High Performance.

3.3.30. tcp_wmem

This variable takes 3 different values which holds information on how much TCP sendbuffer memory space each TCP socket has to use. Every TCP socket has this much buffer space to use before the buffer is filled up. Each of the three values are used under different conditions.

The first value in this variable tells the minimum TCP send buffer space available for a single TCP socket. This space is always allocated for a specific TCP socket opened by a program as soon as it is opened. This value is normally set to 4096 bytes, or 4 kilobytes.

The second value in the variable tells us the default buffer space allowed for a single TCP socket to use. If the buffer tries to grow larger than this, it may get hampered if the system is currently under heavy load and don't have a lot of memory space available. It may even have to drop packets if the system is so heavily loaded that it can not give more memory than this limit. The default value set here is 16384 bytes, or 16 kilobytes of memory. It is not very wise to raise this value since the system is most probably already under heavy memory load and usage, and this would hence lead to even more problems for the rest of the system. This value overrides the /proc/sys/net/core/wmem_default value that is used by other protocols, and is usually set to a lower value than the core value.

The third value tells the kernel the maximum TCP send buffer space. This defines the maximum amount of memory a single TCP socket may use. Per default this value is set to 131072, or 128 kilobytes. This should be a reasonable value for most circumstances, and you will most probably never need to change these values. However, if you ever do need to change it, you should keep in mind that the /proc/sys/net/core/wmem_max value overrides this value, and hence this value should always be smaller than that value.

This variable may give tremenduous increase in throughput on high bandwidth networks, if used properly together with the tcp_mem and tcp_rmem variable. The tcp_wmem variable is the variable of the three which may give the most gain from this kind of tweaking. Do note that you will see almost no gain on slower networks than giga ethernet networks. For more information about this, look at the TCP Tuning Guide.

3.4.1. icmp_echo_ignore_all

If this value is set to 1, in other words on or true, the kernel chooses to totally ignore all ICMP Echo requests. This variable takes a boolean value and is per default set to false, or off. If this is variable is turned on, you and others will be unable to ping the machine in question which is generally a bad thing. Of course, everyone has different opinions about this, some say it is good because people will be unable to ping you and hence know you are there, some say it is bad because you want people to know you are available on the internet. A lot of tools and applications rely upon ICMP Echo requests, some good, some bad as always.

3.4.2. icmp_echo_ignore_broadcasts

This variable works precisely the same as icmp_echo_ignore_all except that it will only ignore those ICMP messages sent to broadcast or multicast addresses. It should be quite obvious why this is good, it would among other things stop this specific host from being part of smurf attacks and likely problems. Broadcast pings are generally bad unless you are using this to find out how many hosts on your network(s) are up or not.

The icmp_echo_ignore_broadcasts variable takes a boolean value and is per default turned off. If you want to turn this value on, you should do so since there is relatively few bad sides to not replying to broadcast pings.

3.4.3. icmp_ignore_bogus_error_responses

There are some routers on the internet and in other places that ignore the standards drawn up in RFC 1122 and sends out bogus responses to broadcast frames. Normally, these violations are logged via the kernel logging facilities, but if we do not want to see these error messages in our logs we may turn this variable on, which will lead to all such error messages being ignored totally. If you live close to such a router, you will save much harddrive space in not logging these messages.

This variable takes a boolean value as you may understand, and is per default set to 0 or off. If you need or want this option and want to get rid of some annoying error messages in your logs, you may turn this on.

3.4.4. icmp_ratelimit

icmp_ratelimit is the maximum rate at which the kernel generates icmp messages of the types specified by icmp_ratemask (see icmp_ratemask). The value is the number of jiffies the kernel has to wait between sending two such messages. Therefore zero means no limit. Typically 1 jiffy = 1/100 sec, so a value of 1 means no more than 100/sec, a value of 100 means no more than 1/sec.

Per default, this variable is set to 100, which means 1 ICMP packet may be sent in 100 jiffies. If we set it to 1, we allow 100 ICMP packets per second, and 0 means unlimited ICMP sendings.

3.4.5. icmp_ratemask

The icmp_ratemask variable sets the mask of which ICMP types should be ratelimited with the icmp_ratelimit variable. The types are put together in the mask by setting specific bits in this variable.

icmp_ratemask is the sum of 2^n for each icmp type you wish to ratelimit, and where n is each ICMP type as specified in the header files of the kernel. This ensures that each bit has a specific meaning. All of the different ICMP names and their corresponding values are available in the include file netinet/ip_icmp.h (generally /usr/include/netinet/ip_icmp.h on most systems). For more information about the different ICMP values and their meaning, see RFC 792 - Internet Control Message Protocol. This would be the complete mathematical formula for the expression:

For all ICMP types n to be rate limited.

For example, if you want to include the ICMP Destination unreachable type in the ratemask, we would notice that this has the value 3 in the header files. To do the conversion then, we would calculate 2^3, which turns out to be 8. Finally, you would or this to the bitmask that you already have. So, if your mask already is 6160, you would go 6160+8 which should do the trick. To or two values means to only add the new entry, in case it was not added previously, in a binary way.

Make absolutely sure that the ratemask does not contain the bitmask that you want to add. If you fail to notice such a problem, your ratemask will become totally wrong. If you have 256 set already, and then try to set 256 again according to this description, you will wind up with ICMP Echo Request unset, and ICMP type 9 set. ICMP type 9 does not exist.

The default value of this variable is 6168, which means that ICMP Destination Unreachable, ICMP Source Quench, ICMP Time Exceeded and ICMP Parameter Problem is in the mask. ICMP Destination Unreachable equals 3, ICMP Source Quench equals 4, ICMP Time Exceeded equals 11 and ICMP Parameter Problem equals 12. Hence, the default value is calculated like this:

An attacker could cause a correctly operating host or router to flood a victim with ICMP replies by sending it packets that generate replies back to the (forged) source address of the victim. It is important in some cases to send such replies, but hardly ever important to generate them at a very high rate.

There is a small program to output the proper ICMP ratemask called ratemask, which is available at http://www.frozentux.net. It may be of some help when creating icmp_ratemasks, or if you want to find out what the current value means.

3.4.6. igmp_max_memberships

This variable changes the maximum amounts of multicast groups we may subscribe to per socket. This is per default set to 20 and may be changed as needed.

Fixme: NEED MORE DETAILS!!!

3.5.1. conf/DEV/, conf/all/ and conf/default/ differences

The /conf/DEV/ directory, where DEV stands for some device or another, will only change the behaviour of the specific device in question. Now, conf/all/ on the other hand will change the behaviour of all the other interfaces if changed.

The final directory named conf/default/ will change the default values. This doesn't change the values in the already set up devices, but it will change the default values used for all the interfaces that may be brought up in the future. One usage would be if we set up a new interface eth0, change the conf/eth0 variables for it, and finally set the defaults used. If we would then load five modems on ppp+, these variables would change since the default variables have changed.

3.5.2. accept_redirects

This variable tells your system whether it should accept ICMP redirects or not. ICMP redirects are normally used to tell a router, or sometimes hosts, that there is a better way to send the packets to specific hosts or networks, which is faster or is less congested.

This value takes a boolean value, and is turned off if it is set to 0 and turned on if it is set to 1. Per default, Linux does accept redirects, but I suggest you turn it off since it is generally considered as a security risk. Most machines should never have any specific requirements to accept being redirected, and hence you should mostly keep this setting off, unless you know that you will seriously need redirects once in a while.

3.5.3. accept_source_route

This variable tells the kernel if it should allow source routed packets or not. Source routed packets are generally looked upon as a security risk, and generally bad. For more information about source routing, see the ip-param.txt document.

This variable is per default turned on in all kernels. Of course, it takes a boolean value, and may be turned on (1) or off (0).

3.5.4. arp_filter

The arp_filter variable tells the kernel whether the IP address should be bound to a specific ARP address or not. The kernel decides to answer a specific packet incoming on a specific interface, if it decides that it would also send the reply back out through the same interface. This is what happens if you turn this option on. In general, it is a good idea to answer on an IP address bound to this computer be answered from whichever interface the packet was received on. However, in some cases, this may cause troubles.

In general, we should only turn this variable on if we are doing load-balancing, otherwise it should be turned off. Per default, this variable is turned off, since it is somewhat breaking the new thoughts about IP addresses. Previously, IP addresses where looked upon as a way of reaching a specific device on a piece of hardware, today, it is looked upon as a separate service in a way, which means that we should (and generally are) answering requests for a specific IP address, not depending on where we received it.

For more information about ARP fluxing, I suggest that you read the information available in the Guide to IP Layer Network Administration with Linux document.

3.5.5. bootp_relay

The bootp_relay variable is supposed to accept packets with source address of 0.b.c.d destined not to this host as local packets. The BOOTP relay daemon will then catch these packets and forward them to the correct destination.

The bootp_relay variable takes a boolean value, and is per default turned off. It can either be turned on (1), or off (0). See the caution admonition before turning it on.

The bootp_relay variable is not implemented yet, hence this very short description. If you have needs of this, you should be welcome to implement it properly. If you want to implement this, you should get in touch with the netdev mailinglist to find out more specific information.

3.5.6. forwarding

This variable tells us if IP forwarding is turned on for a specific device. This could be used to turn on only forwarding between 2 devices, while the third is turned off. Hence, we limit which subnets has access to what. The value in this variable defaults to the same value as ipv4/ip_forward, so if you turn on ip_forward, all of these variables will change to 1 (on), and if you turn ip_forward off, all of the variables will be switched to 0 (off).

3.5.7. log_martians

This variable tells the kernel to log all packets that contains impossible addresses to the kernel logging facility. An impossible IP address may mean an IP address that we do not know how to contact, since the IP address is not contained in the routing tables.

The log_martians will increase verbosity under specific circumstances, but you should be aware that it is not as verbose as one may think. The main problems getting logged by this option are impossible redirects, bad classes, limited broadcasts or otherwise invalid according to the Forwarding Information Base (FIB). This may sound much, but the sircumstances are rather restrictive before anything gets logged.

Martian logging takes a boolean value, where 1 turns it on and 0 turns it off. Per default it is turned off.

3.5.8. mc_forwarding

This option turns on multicast routing for the specific device that we are configuring. To do this, the kernel must be configured and compiled with CONFIG_MROUTE. Additionally, you need a routing daemon that is available at AT&T Research FTP site.. This is a Multicast routing daemon that implements DVMRP. Another Multicast routing daemon that is available is the PIMd. PIMd implements the PIM (Protocol Independent Multicast) multicast routing protocol, in sparse mode. There are also links to other PIM-DM (Protocol Independent Multicast--Dense Mode) and PIM-SM (Protocol Independant Multicast--Sparse Mode) implementations from the last site. If you need more information about Multicasting under Linux, I suggest you read the Multicast HOWTO which contains tons of information about multicasting.

Briefly, The main usage of multicast is to send packets to several different hosts, on different networks. For example, a webpage is OK to send once to everyone who wants to see it, but if we want to have a video conference or video stream to several hundreds of users at once, we have two options of doing this. Either we send the packets once to every host, which means we will have to send hundreds of packets at the same time, and thus draining our bandwidth. The other solution is to use Multicast, in which case we only send one packet, and the packet will then be multiplexed along the road so that everyone who wants to receive the specific stream will get it.

This option takes a boolean value, and is per default turned off. Note that you do not need to turn it on, if you want your host to just listen to multicast packets. This is only needed if you want to forward multicast over the box.

3.5.9. proxy_arp

This variable sets Proxy ARP on or off in kernel for specific devices. Proxy ARP is a system of automatically answering ARP queries for other hosts, that may for example be located on other network segments that we have contact with. This may be necessary under certain circumstances, where other routers do not know how to reach specific networks or hosts. The Linux firewall/router may then answer the ARP queries on behalf of the hosts that we want to Proxy ARP for.

Proxy ARP is turned on for the network segment that we want to answer ARP queries for. We will then answer all ARP queries for that specific network or host, hence receiving the packets destined for the specific host, and we can then send them onwards to the real host.

The proxy_arp variables takes a boolean value. Per default, it is turned off, and may be turned on (1) or off (2) at will. If you want more information about Proxy ARP, read the Proxy-ARP mini HOWTO.

3.5.10. rp_filter

The rp_filter variable sets up a reverse patch (rp) filter on the specific interface. What this means, is quite simple. All it does, is to validate that the actual source address used by packets correlates properly with our routing table, and that packets with this specific source IP address are supposed to get their replies back through that interface again.

If you are using policy routing, or advanced routing, in one way or another, you are seriously suggested to turn the rp_filter variable off, since it may cause packets to be dropped. For example, if you have set up your routers to receive packets through one of them, and send outgoing packets through the other one. Now, if your webserver is connected through one interface to the incoming router, and one to the outgoing router, and the rp_filter variable is turned on, it will simply drop all incoming packets since the packets are not coming in to the webserver through the propriate interface in accordance to the routing table.

The variable takes a boolean value, and is per default turned off. However, a lot of Linux distributions turns on rp_filter through their startup scripts. Hence, if rp_filter is turned on, on your distribution and you want it turned off, start by looking at the rc.d scripts. The variable can either be turned off (0), or on (1).

The behaviour of the rp_filter variable is specified in RFC 1812 - Requirements for IP Version 4 Routers on pages 46-49 (section 4.2.2.11), page 55 (section 4.3.2.7) and page 90 (section 5.3.3.3). If you are doing serious routing, you should carefully read this document anyways.

3.5.11. secure_redirects

This variable turns on secure redirects. If it is turned off, the Linux kernel will accept ICMP redirects from any host, anywhere. However, if it is turned on, ICMP redirects will only be accepted from gateways listed in the default gateway list. This way we can get rid of most illegal redirects that can be used to log your traffic and grab sensitive data, such as passwords etcetera.

The secure_redirects variable takes a boolean value and is per default turned on. It may both be turned on or turned off. Note that this variable is overridden by the shared_media variable, so to turn this one on, you must turn on shared_media as well.

3.5.12. send_redirects

The send_redirects option tells the Linux kernel to send out ICMP redirects to other hosts. This should only be turned on, if the computer acts as a router of some sort. The ICMP redirects are mainly sent out to hosts, if we for example know that the other router/host should instead contact another server on their same subnet as the one we are receiving the packets on.

The send_redirects variable takes a boolean value and is per default turned on. It can take the values 0 (off) and 1 (on). In most cases where the computer is not running as a router of some kind, we could safely turn it off.

3.5.13. shared_media

The shared_media setting tells the kernel if the physical network connected to a specific network card is a shared media or not. For example, if several different IP networks with different netmasks operate over the same physical media or not. The main effect that this variable makes, is to tell the kernel whether it should send ICMP redirects to specific networks or not.

Per default this variable is turned on. It takes a boolean value, and may hence be turned on or off. Note that this variable overrides secure_redirects below.

3.7.1. ip_ct_generic_timeout

This variable is used to tell the connection tracking code of netfilter the generic timeout in case we can not determine the protocol used and use more specific values. Any stream or packet that enters the firewall that can not be fully identified as any of the other protocol types in this section will get a generic timeout set to it.

The ip_ct_generic_timeout variable takes an integer value and is per default set to 600 seconds, or 10 minutes. If this is not enough for your applications, you should raise it until connections do not crash any longer or to an appropriate value.

3.7.2. ip_ct_icmp_timeout

The ip_ct_icmp_timeout variable is used to set the timeout for ICMP packets that will result in return traffic. This should in other words include Echo request and reply, Timestamp request and reply, Information request and reply and finally Address mask request and reply. Once we see one of the requests, we expect to see a return packet, and this is when the ICMP timeout comes into the picture.

As we would expect an ICMP reply to be quite quick, we expect the reply to have returned to, or through, the firewall within a couple of seconds. The ip_ct_icmp_timeout value is in other words rather low, approximately 30 seconds. This should generally be a good value, unless you live on an extremely bad connection.

3.7.3. ip_ct_tcp_be_liberal

This variable changes the behaviour in the state machine regarding TCP out of window packets. If this variable is turned off, all of the out of window packets are regarded as INVALID in the state machine. If it is turned on, the behaviour is much more liberal and only considers out of window RST packets as INVALID. It should generally be a good thing to go with this variable turned off, and should only be required to turn off during special occasions.

The ip_ct_tcp_be_liberal variable takes a boolean value and is per default set to 0, or turned off. All out of window packets are in other words considered as INVALID. As already stated, this should in most cases be the wanted behaviour.

3.7.4. ip_ct_tcp_log_invalid_scale

The ip_ct_tcp_log_invalid_scale variable is used to tell netfilter to log all invalid window scales used in a TCP packets. Window scaling is a specific TCP option used in most modern TCP implementations and is described in detail within the RFC 1323 - TCP Extensions for High Performance. If these scales are invalid for some reason, this variable tells netfilter to log the packet in question.

This variable takes a boolean value and is per default turned on, or set to 1 in other words. This should generally be a good thing, but if you notice that you get a lot of these log entries from some old host or other likely culprit you may as well turn this option off.

3.7.5. ip_ct_tcp_log_out_of_window

The ip_ct_tcp_log_out_of_window variable tells netfilter to log all packets that are considered as out of window. Generally, this is used in conjunction with the previously described ip_ct_tcp_be_liberal variable. All of the packets that are defined as out of window, depending on the setting of the ip_ct_tcp_be_liberal variable, will be logged if this variable is turned on.

The ip_ct_tcp_log_out_of_window variable takes a boolean value and is per default turned on, or set to 1. This should generally be a good idea, but if you do receive a lot of error messages due to errors that you can either not fix, or that is beyond your reach, you may as well turn this variable off.

3.7.6. ip_ct_tcp_timeout_close

This variable sets the timeout of the CLOSE state as defined in RFC 793. Briefly, the CLOSE state is entered if the client sends a FIN and then receive a FIN from the server, and replies with a FIN/ACK to the FIN sent from the server. The CLOSE state is then maintained until we receive a FIN/ACK replying the clients original FIN. When the final FIN/ACK arrives we enter the TIME-WAIT state.

The default timeout of this variable is set to 1000 jiffies, or 10 seconds. Generally, this should be a good value, but if you start noticing that a lot of clients gets hung in the CLOSE state, you should raise this value until the CLOSE state problem is no longer observed on the clients.

3.7.7. ip_ct_tcp_timeout_close_wait

This variable tells netfilter the timeout value of the CLOSE-WAIT state, which is also defined in the RFC 793. This state is entered if the client receives a FIN packet and then replies with a FIN/ACK packet. When this happens, the connection will enter a CLOSE-WAIT state. This state is then maintained until the client sends out the final FIN packet, at which time the connection will change state to LAST-ACK.

The default value of the ip_ct_tcp_timeout_close_wait variable is set to 43200 seconds, or 12 hours as of the tcp-window-tracking patch entering the kernel. Previously, this was per default set to 60 seconds, which in turn led to a lot of badly timed out connections. This timeout should in general be large enough to let most connections exit the CLOSE-WAIT state, but if you are having problems in the other direction that you are running out of conntrack entries, due to a lot of connections getting stuck in the CLOSE-WAIT state, your best bet is to either get more memory, or to bring this value down a few hours.

3.7.8. ip_ct_tcp_timeout_established

The ip_ct_tcp_timeout_established variable tells us the default timeout value for tracked connections in the ESTABLISHED state. All connections that has finished the initial 3-way handshake, and that has not seen any kind of FIN packets are considered as ESTABLISHED. This is in other words more or less the default state for a TCP connection.

Since we never want a connection to be lost on either side of the netfilter firewall, this timeout is set extremely high so we do not accidentally erase entries that are still used. Per default, the ip_ct_tcp_timeout_established variable is set to 432000 seconds, or 5 days.

You should not consider lowering this variable because you have too many active connection tracking entries going. If this is your problem, you should be looking at the ip_conntrack_core.c file, function ip_conntrack_init which defines the maximum connection tracking entries. Unfortunately, this maximum value is static as of writing this, and will probably remain so for a long time since each conntrack entry requires a non-swappable memory.

3.7.9. ip_ct_tcp_timeout_fin_wait

The ip_ct_tcp_timeout_fin_wait variable defines the timeout values for both the FIN-WAIT-1 and FIN-WAIT-2 states as described in RFC 793. The FIN-WAIT-1 state is entered when the server send a FIN packet, while the FIN-WAIT-2 state is entered when the server receives a FIN/ACK packet from the client in return to the initial FIN packet. If the server receive a FIN while still waiting for the FIN/ACK packet it enters the CLOSE (defined as CLOSING in RFC 793) state instead of FIN-WAIT-2.

The ip_ct_tcp_timeout_fin_wait variable is per default set to 120 seconds, or 2 minutes. The default here should generally be a good value but may be raised in case clients and servers are left in this state because the firewall stopped forwarding the packets due to the conntrack entries timing out in advance. Of course, if you have problems with conntrack running out of hash entries, this value may also be lowered, but not more than allowing the full closing handshake to take place on both ends.

3.7.10. ip_ct_tcp_timeout_last_ack

The ip_ct_tcp_timeout_last_ack variable sets the timeout value of the LAST-ACK state. This state is entered when the client sends a FIN packet in reply to an already received and replied FIN packet from the server. This state follows the CLOSE-WAIT state and is ended once we receive the final FIN/ACK packet in return to our own FIN packet. At this point, the conntrack entry is destroyed and we enter the CLOSED state (ie, no conntrack entry at all).

The default value of the ip_ct_tcp_timeout_last_ack variable is set to 30 seconds and should generally be more than sufficient for the last replying FIN/ACK packet, however, in certain cases this value may time out. If this is the case, you should try to raise this value. If you are having problems with running out of connection entries, you could possibly try to lower this value but avoid lowering it so much that your clients are left in a LAST-ACK state.

3.7.11. ip_ct_tcp_timeout_listen

This value is the initial state that all TCP receiving sockets are set to according to RFC 793. In other words, this state is reached for all sockets that sits and listens for connecting SYN packets. This state is never used in conntrack since conntrack can impossibly know about this state in advance since there is no network traffic indicating it. However, it is still made available to stay conformant with RFC 793 and perhaps for some other reasons that the netfilter core team may have.

This variable is per default set to 120 seconds, or 2 minutes. This could be lowered to 0 if you feel like it, but this may lead to strange behaviours and really bad problems. Since this value is never really used, you can as well leave it at the default value. It will not change any of the behaviours of netfilter as it looks now.

3.7.12. ip_ct_tcp_timeout_none

This variable is only used for an extremely brief period of time and indicates the connection before conntrack actually knows which state to put it in. For example, the firewall may never know for sure at what state a specific TCP connection is in when it sees the connection for the first time. When it sees the first packet, it sets the packet to state NONE. After this, it tries to decide at what state this connection is in according to RFC 793. Depending on what TCP flags the packet has set, netfilter can derive that the connection is in state SYN-SENT, ESTABLISHED, TIME-WAIT or CLOSE.

What all of the above really means, is that the connection is really never in the NONE state, or to be more accurate, it is only for an extremely brief timeperiod. There should in other words be no real need or usage in lowering this states timeout, since it is barely used anyways, and the packet should almost never fail to move on to another state from this state.

The ip_ct_tcp_timeout_none variable is per default set to 1800 seconds, or 30 minutes. This should generally pose no problem as already described and you have very little to win by changing this default value.

3.7.13. ip_ct_tcp_timeout_syn_recv

The ip_ct_tcp_timeout_syn_recv variable sets the timeout value for the SYN-RECEIVED (also known as SYN-RCVD or SYN-RECV) state as defined in RFC 793. The SYN-RECEIVED state is entered from the LISTEN or SYN-SENT state once the server receives a SYN packet and then replies with a SYN/ACK packet. The SYN-RECEIVED state is left for the ESTABLISHED state once the server receives the final ACK packet in the 3-way handshake.

The default value of the ip_ct_tcp_timeout_syn_recv variable is 60 seconds, or 1 minute. This should generally be a good value, but if you do experience timeouts where your server or clients end up in a SYN-RECV or SYN-SENT state, you should consider raising this value a bit. It is generally a bad idea to lower this variable to get over any problems with connections timing out.

3.7.14. ip_ct_tcp_timeout_syn_sent

The ip_ct_tcp_timeout_syn_sent state sets the timeout of the SYN-SENT state as defined in RFC 793. The SYN-SENT state is entered once the client has sent out a SYN packet and is still awaiting the returning SYN/ACK packet. The SYN-SENT state is then left for the SYN-RCVD or ESTABLISHED states once we get the SYN/ACK packet.

The default value of the ip_ct_tcp_timeout_syn_sent variable is set to 120 seconds, or 2 minutes. This should generally be a good setting, but if you experience problems where the client and server gets stuck in a SYN-SENT or SYN-RCVD state, you may possibly need to raise this value. It is generally a bad idea to lower this value to get around problems with not having enough conntrack entries.

3.7.15. ip_ct_tcp_timeout_time_wait

The ip_ct_tcp_timeout_time_wait variable defines the timeout value of the TIME-WAIT state as defined by RFC 793. This is the final state possible in a TCP connection. When a connection is closed in both directions, the server and client enters the TIME-WAIT state, which is used so that all stale packets have time to enter the client or server. One example of the usage of this may be if packets are reordered during transit between the hosts and winds up in a different order at either side. In such a case, the timewindow defined in the ip_ct_tcp_timeout_time_wait variable is used so that those packets may reach their destinations anyways. When the timeout expires, the conntrack entry is destroyed and we enter the state CLOSED, which means that there is no conntrack data at all for the connection in question.

The default value of the ip_ct_tcp_timeout_time_wait variable is set to 120 seconds, or 2 minutes. You should generally want to keep this value if you know that you live on a connection that is slow and that often reorders the packets in question. If this value is too low you will often experience corrupt downloads or missing data in downloaded data, you should definitely avoid tuning this value down in such a case, and you may most definitely consider raising the timeout of this value in such case. If you never experience such behaviour or any other problems like that, you may most probably lower this value so that conntrack entries die faster, and hence recycle the conntrack entry space faster.

3.7.16. ip_ct_udp_timeout

The ip_ct_udp_timeout variable specifies the timeout for initial UDP packets in a connection. When a UDP connection is initialized, the UDP packet enters an NEW and then ESTABLISHED state once it has seen return traffic to the original UDP packet. However, it maintains the same timeout until it has seen several packets go back and forth and becomes assured, at which point it is instead considered a stream.

While this initial state is maintained, the default timeout is 30 seconds. If you are using UDP protocols that send very little data during longer timeframes, you should consider raising this value so that the state machine is able to keep track of your connections properly. It is generally a bad idea to lower this, unless you know that your hosts sends UDP packets very often and don't expect a lot of late replies, which would mean a lot of unnecessary open conntrack entries.

3.7.17. ip_ct_udp_timeout_stream

The ip_ct_udp_timeout_stream variable specifies the timeout values of the UDP streams once they have sent enough packets to reach the assured state. This state is normally reached for connections that send a lot of data and relatively often, such as streaming services or ICQ. Examples of streaming services may be certain realplayer servers, or speak freely. This value should always be larger than the initial timeout value for UDP streams since it is used on connections that we know for sure expects a lot of traffic back and forth, even though it may not be very often.

The ip_ct_udp_timeout_stream variable is per default set to 180 seconds, or 3 minutes in recent kernels. If you are having problems with connections timing out, you may try raising this value a bit. It is generally a bad idea to lower this value, since the connection will be destroyed once it times out from this state. Unfortunately, UDP is a stateless protocol, so it is very hard to derive any specific states of the connections. Because of this, there is no specific conntrack timeouts for UDP streams that are about to close, or that has closed.

3.8.1. error_burst

This variables is used in conjunction with error_cost to limit how many ICMP destination unreachable messages the routing code will send out. This variable tells the function the maximum amount of tokens that we have available, while the error_cost variable tells us how many tokens are used up by each ICMP destination unreachable packet. If error_burst is emptied and we receive more packets for that host, we will ignore them.

ICMP destination unreachable messages are generally sent when our host, or router, does not know how to reach a specific host or network. This may be for three basic reasons: We can not reach the nexthop to the destination. We have no route set up for the network segment or host. We have a routing rule or route set to unreachable, throw or prohibit. During these three sircumstances, the networking code sends out ICMP Destination Unreachable messages with three different codes if necessary: ICMP host unreachable in case the host should be directly connected to a network we are part of, or if the host was set to unreachable or throw through a rule or route. ICMP network unreachable if we do not know how to reach the network in question, or if the network was set to unreachable or throw through a rule or route. ICMP communication administratively prohibited by filtering is sent if we have a rule or route set to prohibit.

The error_burst variable is per default set to 500 and takes an integer value. Together with the default value of error_cost this means that we allow the routing code to send 5 ICMP Destination unreachables per second.

3.8.2. error_cost

For a complete explanation, see the error_burst variable. Basically, this variable sets the cost of sending a single ICMP destination unreachable to someone.

The error_cost variable is per default set to 100, which means we can send a maximum of 5 ICMP destination unreachables per second, together with the default value of error_burst.

3.8.3. flush

This variable is extremely simple in use. It can not be read since it contains no real data. If you write anything to it as root, it will simply flush the whole routing cache. For example, if you know that a route has changed somewhere, you would simply echo something into this file, and the route cache will be emptied. If you would like to read the route cache, take a look at the /proc/net/rt_cache. This file contains a lot of information about the routes currently in the cache.

3.8.4. gc_elasticity

3.8.5. gc_interval

3.8.6. gc_min_interval

3.8.7. gc_thresh

3.8.8. gc_timeout

3.8.9. max_delay

3.8.10. max_size

3.8.11. min_adv_mss

3.8.12. min_delay

3.8.13. min_pmtu

3.8.14. mtu_expires

3.8.15. redirect_load

3.8.16. redirect_number

3.8.17. redirect_silence