BCC is a toolkit for creating efficient kernel tracing and manipulation programs, and includes several useful tools and examples. It makes use of extended BPF (Berkeley Packet Filters), formally known as eBPF, a new feature that was first added to Linux 3.15. Much of what BCC uses requires Linux 4.1 and above.
bpftrace is a high-level tracing language for Linux enhanced Berkeley Packet Filter (eBPF) available in recent Linux kernels (4.x)
Симптомы: часть сайтов открывается, часть – нет. tcpdump показывает нормальное прохождение пакетов в обе стороны. Всему виной PPPoE с его overhead’ом на размер пакета.
Решение простое:
iptables -I FORWARD 1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Но что оно означает? Оно означает “нормализовать пакет” согласно PMTU, то есть, уменьшить размер MSS так, что бы пакет прошёл от источника к назначению, при этом выбрав наименьший MTU среди всех промежуточных.
Важно! Правило нужно размещать в самом начале.
Расскажу об одной, на первый взгляд, странной проблеме. Основная проблема: после обновления с 10 на 11 через некоторое время интерфейс теряет адрес, полученный через DHCP. Откатываешься (это виртуальная машина, поэтому через snapshot’ы такое легко провернуть) обратно на 10-ку – всё работает. Важный момент: такое наблюдается только с серверами у которых DHCP. Так же, на всех серверах (как статических, так и с DHCP) присутствует и другая проблема: после перезагрузки, сервер отвечает на icmp, но ровно 5 минут недоступны вообще никакие сервисы: ssh, http,…
Раньше приходилось заново копировать после каждого обрыва. Но потом придумали механизм, основанный на bookmark’ах, который позволяет продолжить копирование с места разрыва.
Вводные данные: 2 сервера Linux связаны между собой через OpenVPN туннель. Нужно для части клиентов за одним из концов VPN’a завернуть весь трафик в туннель, то есть, что бы они выходили в интернет не через свой GW, а через удалённый GW, пройдя через VPN.
UPD. В данной схеме есть нюанс: она будет работать, если клиентские машины находятся за хостом, который является OpenVPN-клиентом. В обратном случае, пакеты просто не будут покидать хост, хотя через tcpdump вы их будете видеть. Связано это с особенностями самого OpenVPN’a. Пока не нашёл как это можно решить. Как workaround, можно либо изменить роли клиент-сервер, либо использовать простой туннель или другой тип VPN’a.
Вот как полностью выглядит сообщение об ошибке:
Connection timed out H=alt4.gmail-smtp-in.l.google.com [142.250.157.26]:25 DT=12m19s: SMTP timeout after sending data block (452056 bytes written)
Примечание: число в скобках и сервер гугла может быть любой.
Заметка написана, как обновление статьи, поскольку в новых ядрах произошли некоторые изменения. По сути, здесь будут выдержки из документации по управлению питанием для ядра Linux.
Начну в порядке от самой простой реализации до самой сложной.
Да, именно с таким сообщением начала падать kafka спустя некоторое время после запуска. Включение режима debug немного увеличило “понятность”
ERROR Error while accepting connection (kafka.network.Acceptor)
java.net.SocketException: Invalid argument
at sun.nio.ch.Net.setIntOption0(Native Method)
at sun.nio.ch.Net.setSocketOption(Net.java:341)
at sun.nio.ch.SocketChannelImpl.setOption(SocketChannelImpl.java:190)
at sun.nio.ch.SocketAdaptor.setBooleanOption(SocketAdaptor.java:271)
at sun.nio.ch.SocketAdaptor.setTcpNoDelay(SocketAdaptor.java:306)
at kafka.network.Acceptor.accept(SocketServer.scala:654)
at kafka.network.Acceptor.run(SocketServer.scala:579)
at java.lang.Thread.run(Thread.java:748)
