0

I have a server running Debian 11 with two 1Gbps and 10Gbps uplinks respectively. When running any network related commands, I observe a very high latency at the beginning of the command execution.

For example, if I run the command curl -I google.com, it hangs for a couple of seconds and then outputs the result:

$ curl -I google.com
  *** hangs for about 5 seconds ***
HTTP/1.1 301 Moved Permanently
Location: http://www.google.com/
Content-Type: text/html; charset=UTF-8
Date: Wed, 13 Apr 2022 16:20:09 GMT
Expires: Fri, 13 May 2022 16:20:09 GMT
Cache-Control: public, max-age=2592000
Server: gws
Content-Length: 219
X-XSS-Protection: 0
X-Frame-Options: SAMEORIGIN

There is a similar problem for apt:

$ sudo apt update
0% [Working]    # <--- hangs for 2-3 seconds
Hit:1 https://mirror.yandex.ru/debian bullseye InRelease
...

At the same time, the speed of the Internet connection is acceptable:

$ wget http://tb.ip4market.ru/file1gb.bin
--2022-04-13 19:11:28--  http://tb.ip4market.ru/file1gb.bin
Resolving tb.ip4market.ru (tb.ip4market.ru)... 193.0.203.203
Connecting to tb.ip4market.ru (tb.ip4market.ru)|193.0.203.203|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1073741824 (1.0G) [application/octet-stream]
Saving to: ‘file1gb.bin’

file1gb.bin               100%[==================================>]   1.00G  17.0MB/s    in 49s

2022-04-13 19:12:22 (21.1 MB/s) - ‘file1gb.bin’ saved [1073741824/1073741824]

On other servers connected to the same switch, there is no such problem.

How can this be fixed, or at least how to determine the cause of this strange behavior?

Thanks in advance.

Improve this question
4
  • 1
    One classic cause for this is broken DNS. Ensure that your resolv.conf points to a reliable DNS server. The kind of DNS delay you're describing can easily arise from having a system query a faulty DNS server first, then having to make a second query to another server before obtaining a satisfactory result.
    – Jim L.
    Commented Apr 13, 2022 at 17:03
  • yep, almost certainly is DNS; in multi-interface setups, you might be sending out DNS requests on the wrong interface. If it's not DNS, using tcpdump / wireshark to figure out what goes on on the network interfaces might help.
    – Marcus Müller
    Commented Apr 13, 2022 at 17:05
  • Yes, the address of one of the DNS servers was misspelled in the resolv.conf file. I hadn't noticed that before, because I was checking for correct DNS addresses in the systemd-networkd configs. Thanks a lot!
    – async await
    Commented Apr 13, 2022 at 17:17
  • @asyncawait cool! Can you post what you found and how you solved it as an answer? I think it would be good if we could mark this question as "answered".
    – Marcus Müller
    Commented Apr 13, 2022 at 18:22

1 Answer 1

Reset to default
0

I used systemd-networkd for static network configuration. Accordingly, suspecting that the problem might be with the wrong DNS address, I looked for an error in the configuration file 20-wan0.network, where I specified DNS addresses. There were no errors in that file. Later, after asking the question and getting comments, I checked the file /etc/resolv.conf just in case, and saw a typo in the first DNS address. This file was left from the original network configuration, which was made during the installation of the system. When using systemd-netowrkd and systemd-resolved it should be replaced with a symbolic link to /run/systemd/resolve/resolv.conf, which I ended up doing.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .