Vincent Bernat
vincent.bernat.ch · Personal blog · on HN since 2011
Vincent Bernat, a network and Linux engineer, writes detailed posts on Linux networking, Debian packaging, and Python tooling.
What HN saysHN commenters call it one of their favorite networking blogs and link its posts on IPv4 route lookup and Debian packaging.
97HN people shared it
34linked it in comments
104stories submitted
1.2Kstory points
3 months agolast shared
2011people per year2026
Most-shared posts
- 1SSL/TLS & Perfect Forward Secrecy12 people · 34 points · first shared 2011 · 3 comments on HN
- 2Coping with the TCP TIME-WAIT state on busy Linux servers7 people · 72 points · first shared 2014 · 18 comments on HN
- 3Pragmatic Debian packaging5 people · 19 points · first shared 2016 · 1 comments on HN
- 4Writing Sustainable Python Scripts5 people · 16 points · first shared 2019 · 1 comments on HN
- 5Pragmatic Debian Packaging (2019 Edition)5 people · 10 points · first shared 2019 · 1 comments on HN
- 6Coping with the TCP Time-Wait State on Busy Linux Servers ⁕ Vincent Bernat5 people · 8 points · first shared 2020 · discussion on HN
- 7Tuning Linux IPv4 route cache (2011)4 people · 30 points · first shared 2011 · 7 comments on HN
- 8Why content providers need IPv64 people · 23 points · first shared 2024 · 1 comments on HN
- 9IPv4 Route Lookup on Linux4 people · 6 points · first shared 2020 · discussion on HN
- 10HiDPI on dual 4K monitors with Linux4 people · 3 points · first shared 2018 · discussion on HN
- 11IPv4 route lookup on Linux3 people · 133 points · first shared 2017 · 30 comments on HN
- 12Switching to the i3 window manager3 people · 115 points · first shared 2021 · 85 comments on HN
- 13TCP Time-Wait State Linux3 people · 18 points · first shared 2017 · discussion on HN
- 14Proper isolation of a Linux bridge3 people · 8 points · first shared 2017 · discussion on HN
- 15Git as a source of truth for network automation3 people · 6 points · first shared 2021 · discussion on HN
What HN people wrote when they linked it
vbernat · 2026-07-04
I have also restored the very first articles I wrote in the 90s when I was young <https://vincent.bernat.ch/en/blog/2026-old-web-articles>. At the time, they were not "great," but now I think they have some limited historical values. For example, one of them is about how the national phone operator was billing minutes. The information was easy to find in the past but is pretty scarce now.
I didn't use the wayback machine because it didn't archive everything I needed and because I still had the files on my hard drive, but if I didn't, I would have been happy to recover them.
CameronNemo · 2022-07-27
Vincent Bernat has one of my favorite blogs about networking.
https://vincent.bernat.ch/en/blog#tag-linux
ignoramous · 2020-04-03
> Traditionally, a radix tree is used...
Here's an excellent write-up on radix-trees usage by the Linux kernel for IP routing: https://vincent.bernat.ch/en/blog/2017-ipv4-route-lookup-linux
Also see: https://news.ycombinator.com/item?id=22467251
alexandre_m · 2019-08-04
"Vxlan uses multicast which is often not supported on most cloud networks. So its best used on your own networks."
Not entirely correct.
Linux has had unicast vxlan for quite some time.
Flannel is doing unicast and works pretty much anywhere.
See "Unicast with dynamic L3 entries" section:
https://vincent.bernat.ch/en/blog/2017-vxlan-linux
gouggoug · 2015-06-19
Of course,
net.ipv4.tcp_tw_recycle causes problems with NAT-ed clients.
tcp_tw_recycle (Boolean; default: disabled; since Linux 2.4)
Enable fast recycling of TIME_WAIT sockets. Enabling this option is not recommended since this causes problems when working with NAT (Network Address Translation).
net.ipv4.tcp_tw_reuse seems fine to use, but literature about its real effects is sparse.
This link http://vincent.bernat.im/en/blog/2014-tcp-time-wait-state-linux.html mentions both of them.
IvyMike · 2013-06-24
Thanks! I knew I should have read the article more carefully.
(The same section of the article also references http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html which answers some of my follow on questions.)
waldo2k2 · 2012-02-22
What version of OpenSSL was used on the test machine? That would greatly effect stunnel's performance. See here: http://vincent.bernat.im/en/blog/2011-ssl-benchmark-round2.html
kassner · 2025-07-24
If you just want to put a binary in a .deb, for internal usage, check out https://vincent.bernat.ch/en/blog/2019-pragmatic-debian-packaging. I went through it in the last year, worked fine to build for bookworm.
neonsunset · 2025-02-19
If you like radix trees, you may also find this article interesting and useful: https://vincent.bernat.ch/en/blog/2017-ipv4-route-lookup-linux
transpute · 2024-11-05
Is that with systemd logind? Why does logind interact with BIOS?
https://vincent.bernat.ch/en/blog/2021-startx-systemd
imiric · 2024-10-12
Instead of making it an additional Ctrl key, you can also make it a new separate modifier key with XKB[1]. I've found this very useful over the years for WM-related key bindings, leaving the other modifiers for applications.
Tangentially, I really loathe how Wayland has no alternative to this. I'm expected to configure keyboard layouts in every DE or WM I use, which is a much worse UX.
[1]: https://vincent.bernat.ch/en/extending-xkb#attaching-symbols-to-keys
hnarn · 2023-03-22
Could be what's described in this post: https://vincent.bernat.ch/en/blog/2018-systemd-golang-socket-activatio…
dceddia · 2022-09-12
Just yesterday I was looking for how to do this too, and came across this article on how to create videos suitable for streaming (there’s even a Python script). https://vincent.bernat.ch/en/blog/2018-self-hosted-videos
mrspuratic · 2022-02-04
Back in the HTTP/0.9 era TIME_WAIT was a big problem when running a busy [reverse] proxy. I remember using ndd to "tune" tcp_time_wait_interval on Solaris for this, as well as the anon (ephemeral) port range.
This is my go to that topic now:
https://vincent.bernat.ch/en/blog/2014-tcp-time-wait-state-linux
"The solution is more quadruplets" is for me one those things that's blindingly obvious once pointed out.
See also the other link Cloudflare "Why we use the Linux kernel's TCP stack" link in a sibling - about half-way through they reveal they use both kernel bypass (DOS can max out iptables at ~1Mpps) and Solarflare NICs (offload options not stated), as well as Intel NICs with netmap bypass.
knowhy · 2021-02-11
> From the kernel point of view, there is a only one socket with a unique listen queue. This socket is associated to several file descriptors: one in systemd and one in the current process. The socket stays alive as long as there is at least one file descriptor. An incoming connection is put by the kernel in the listen queue and can be dequeued from any file descriptor with the accept() syscall. Therefore, this approach actually achieves zero-downtime deployment: no incoming connection is rejected. [0]
systemd can be sufficient for a zero-downtime deployment.
[0] https://vincent.bernat.ch/en/blog/2018-systemd-golang-socket-activatio…
bilegeek · 2020-03-17
I'm not sure what he's done about HiDPI, but apparently that can be invoked (depending on the app) using xsettingsd[1].
[1]https://vincent.bernat.ch/en/blog/2018-4k-hidpi-dual-screen-linux
pedant-triehard · 2018-08-08
I'll bite: tries were (and are still?) used for longest prefix match lookups on IP addresses in forwarding plane software and hardware. I've actually seen and worked with tries in real, shipping, working hardware/software.
e.g. see https://vincent.bernat.im/en/blog/2017-ipv4-route-lookup-linux
Later TCAMs came along for hardware lookups.
number6 · 2018-05-18
Here is a blog post on this topic:
https://vincent.bernat.im/en/blog/2018-route-based-vpn-wireguard
Didn't tried it myself but it looks solid
mattbierner · 2018-04-24
Very helpful. I've hosted a few videos using cloudfront but there were lots of little gotchas with setting up both the hosting and the player. I wish I had found the linked to guide earlier: https://vincent.bernat.im/en/blog/2018-self-hosted-videos
pushrax · 2016-09-25
tcp_tw_recycle is not what you want. It is only applicable to outgoing connections (i.e. not people connecting to your server), and even in that case provides little benefit over tcp_tw_reuse.
I like pointing people here for the explanation: https://vincent.bernat.im/en/blog/2014-tcp-time-wait-state-linux.html
dozzie · 2016-07-29
Actually no, it's not a terrible process, it's a misunderstood process[#].
Modern tools (debhelper 7+) allow for simple process, though one needs to
understand how the binary packages thing works.
This is a decent overview on technical details:
http://vincent.bernat.im/en/blog/2016-pragmatic-debian-packaging.html
[#] I assume you meant the friction with the tools, not the fact that package
builder needs to chase down all the dependencies and generally prepare many
source tarballs to be included in a repository.
darkarmani · 2015-03-04
TIME_WAIT: http://vincent.bernat.im/en/blog/2014-tcp-time-wait-state-linux.html
"to prevent delayed segments from one connection being accepted by a later connection relying on the same quadruplet (source address, source port, destination address, destination port). The sequence number also needs to be in a certain range to be accepted. This narrows a bit the problem but it still exists, especially on fast connections with large receive windows."
brendangregg · 2015-03-04
The problem is opening >30k connections to a single host during a TIME_WAIT period, 60 seconds. 500 connections per second. For backend servers, eg, an application server talking to a database, 500 connections per second is easy (although it's preferable if they can keep-alive).
I liked Vincent Bernat's post about TIME_WAIT: http://vincent.bernat.im/en/blog/2014-tcp-time-wait-state-linux.html
guruz · 2014-08-07
Only the first connection should be delayed a bit
http://vincent.bernat.im/en/blog/2011-ssl-session-reuse-rfc5077.html
devx · 2013-09-07
Is HTTP 2.0 finalized and approved? If not could we push for it to support PFS by default with ECDHE, which seems to add only 15 percent overhead [1]? That seems like a small price to pay if the security of every session grows exponentially, with each one being encrypted with a new key.
HTTP 2.0/SPDY already makes TLS mandatory, no? So why not make PFS mandatory, too? I'd rather we do it now than wait for HTTP 3.0, and it might force a lot more companies to adopt it by default as they move to HTTP 2.0 (companies such as Microsoft [2]).
EDIT: Links
[1] - http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html
[2] - http://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-dec…
spellboots · 2013-07-14
This article may help explain how: http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html
agwa · 2013-06-25
Unfortunately individual applications need to add support for ECDHE for it to be usable, and Apache 2.2 does not have such support. Apache 2.4 does though.
(Corroboration: http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html…
JoshTriplett · 2013-06-19
Not necessarily possible even with the private keys. If you use an SSL cipher with ephemeral keys, such as the DHE_* or ECDHE_* family of ciphers, then an eavesdropper with a recorded but not MITMed conversation cannot decrypt it even with the server's private SSL key.
See http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html for example.
phlo · 2013-06-09
With regard to your latter question, [1] gives a good overview on PFS in TLS. You'll need to exchange keys using (EC)DHE, essentially.
As for subpoenaing keys: Most CAs will allow for you to generate your key pair and certificate signing request on your own hardware. You'd then submit the CSR which the CA would in turn generate a signed certificate from. The private key should never be shared with the CA.
In order to eavesdrop on communications, the NSA would then need to subpoena each targeted company's key. Wide reach is easy (go for the 5-10 biggest fish), comprehensive reach nigh impossible.
[1] http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html