34

On my Ubuntu machine, in /etc/sysctl.conf file, I've got reverse path filtering options commented out by default like this:

#net.ipv4.conf.default.rp_filter=1
#net.ipv4.conf.all.rp_filter=1

but in /etc/sysctl.d/10-network-security.conf they are (again, by default) not commented out:

net.ipv4.conf.default.rp_filter=1
net.ipv4.conf.all.rp_filter=1

So is reverse path filtering enabled or not? Which of the configuration locations takes priority? How do I check the current values of these and other kernel options?

Gilles 'SO- stop being evil'
  • 807,993
  • 194
  • 1,674
  • 2,175
Desmond Hume
  • 2,718
  • 5
  • 21
  • 21

3 Answers3

57

Checking the value of a sysctl variable is as easy as

sysctl <variable name>

and, by the way, setting a sysctl variable is as straightforward as

sudo sysctl -w <variable name>=<value>

but changes made this way will probably hold only till the next reboot.

As to which of the config locations, /etc/sysctl.conf or /etc/sysctl.d/, takes precedence, here is what /etc/sysctl.d/README file says:

End-users can use 60-*.conf and above, or use /etc/sysctl.conf directly, which overrides anything in this directory.

After editing the config in any of the two locations, the changes can be applied with

sudo sysctl -p
Desmond Hume
  • 2,718
  • 5
  • 21
  • 21
  • Is this not `sysctl -e` for edit and `sysctl -f` for executing the config? – Nils Dec 08 '12 at 21:01
  • @Nils http://linux.die.net/man/8/sysctl – Desmond Hume Dec 08 '12 at 21:34
  • Right - strangely both options work. – Nils Dec 11 '12 at 22:15
  • FYI, as noted in Bozzy's answer [below](https://unix.stackexchange.com/a/391765/466741), although it is true that `/etc/sysctl.conf` overrides anything in `/etc/sysctl.d/`, that only matters if the same setting is configured in both locations, with different values. In the OP's example, since his settings are only set in `/etc/sysctl.d/` (they're commented out in `/etc/sysctl.conf`), his settings in `/etc/sysctl.d/` would NOT get overridden by `/etc/sysctl.conf` (since, again, there are no conflicting values in `/etc/sysctl.conf` to override them with). – Seth Aug 26 '22 at 23:12
4

This kind of stuff is usually in the /proc and/or /sys kernel interfaces (first, keep in mind nothing in those directories is a regular disk file, they are all direct lines to the kernel).

So, eg:

»for x in /proc/sys/net/ipv4/conf/*/rp_filter; do echo -ne "$x "`cat $x`"\n"; done
/proc/sys/net/ipv4/conf/all/rp_filter 0
/proc/sys/net/ipv4/conf/default/rp_filter 1
/proc/sys/net/ipv4/conf/em1/rp_filter 1
/proc/sys/net/ipv4/conf/lo/rp_filter 0
/proc/sys/net/ipv4/conf/wlan0/rp_filter 1

Looks like I have rp_filter set for em1, wlan0, and "default". You can set or unset them by just writing to the file handle:

»cd /proc/sys/net/ipv4/conf/lo
»echo 1 > rp_filter
»cat rp_filter
1
»echo 0 > rp_filter
»cat rp_filter
0

As mentioned, this is direct communication with the kernel, so that takes effect immediately. These are not configuration files. If you try and do something wrong:

»echo whatever > rp_filter
bash: echo: write error: Invalid argument

Which is not to say you can't screw things up this way, of course. And be sure to read the comments below.

goldilocks
  • 86,451
  • 30
  • 200
  • 258
  • I'd rather stick to configuration files because this way I can keep dozens of lines of my preferred configuration in a plain text file and reuse (some of) them when needed. Writing a script for this purpose feels like an unnecessary complication. But thanks for the info on a method to check current values. – Desmond Hume Dec 07 '12 at 15:40
  • Definitely using config files is much better. I was not suggesting you write a script, just illustrating that those are not "read only" values and can be used to make manual tweaks. ;) – goldilocks Dec 07 '12 at 15:48
  • 1
    That shell script is a rather interesting way to re-write `sysctl -a` ... – derobert Dec 07 '12 at 16:21
  • True, but (depending on the nature of your file browser) perusing proc/sys might be considered more convenient, which is one reason it is worth knowing about. Another is that WRT to getting information programmatically, that interface is more efficient than piped "system(sysctl)" type stuff, and works regardless of language, available libs, etc. – goldilocks Dec 09 '12 at 13:24
  • Not quite. There are already some cases where a write with echo may fail, while using `sysctl -w` works. You might also encounter systems, where /proc is not mounted. – Nils Dec 11 '12 at 22:17
  • 1
    You misunderstand what I mean by *programmatically*, perhaps I need to clarify: I did not mean shell scripts. There is a native C equivalent of `sysctl` (see `man 2 sysctl`), however, this is not ported to most other languages (it is in some), and in these cases the best option is to read or write to proc. It may well be that bash's `echo` may fail, as I can say that the high level stream I/O functions available in C and other languages can. The low level read/write will not, however. In any case, knowing about the proc interface is important, which is why I brought it up... – goldilocks Dec 12 '12 at 14:28
  • Also note from the sysctl man page: "The parameters available are those listed under /proc/sys/. Procfs is required for sysctl support in Linux." This implies to me that `sysctl` won't work either if proc is not mounted (I have not checked directly). And, again, it is better to be aware of the interface and how it works than not. I think the bases are decently covered by the two separate answers to this question. – goldilocks Dec 12 '12 at 14:33
  • As a (hopefully final) quick comment, I have run across people who are dubious of using the proc interface programmatically because low level I/O on what is apparently the filesystem will be a (hardware) bottleneck. This is part of the reason I emphasized that they are not really disk files, ie., their is no slow hardware interface involved to cause such a bottleneck. – goldilocks Dec 12 '12 at 14:40
2

To complete the accepted answer, while it's true that /etc/sysctl.conf settings take precedence over the ones in /etc/sysctl.d/, the example exposed in the original question shows two commented out variables in /etc/sysctl.conf:

#net.ipv4.conf.default.rp_filter=1
#net.ipv4.conf.all.rp_filter=1

and the same variables not commented out in /etc/sysctl.d/10-network-security.conf:

net.ipv4.conf.default.rp_filter=1
net.ipv4.conf.all.rp_filter=1

This may be misleading because a comment is not a setting, but only a remark of what could be a setting.

In this situation, the variables are actually both set to 1, despite the fact that in the stronger config file they're commented out.

If in /etc/sysctl.conf we had:

net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.all.rp_filter=0

then the variables would eventually be set to 0.

Bozzy
  • 121
  • 3