Что: af256a5826f43fe1375903978e6a59e0e08d1fcc
Когда: 2023-11-18 18:11:00+03:00
Темы: bsd hard netperf
Снова firewall. Поднял collectd. Ошибки на 10GbE витой паре
https://collectd.org/
https://calomel.org/rrdtool.html
После начала применения AQM с FQ-CoDel
(6588786a31b2cbec545beeecf1232338609ff9ce), захотелось на графиках
трафика за длительное время посмотреть меняется ли чего. Так то
невооружённым глазом вижу насколько всё стало отзывчевее -- прям это
реально must-have! А вот BitTorrent трафик в последнее время не забивает
весь канал на выход. Но у меня тут большие пертурбации со всеми этими
торрентами были и возможно дело именно в них -- в особенности их "роя
пиявок" (так и оказалось). Плюс снова люто порефакторил правила своего
firewall-а, ибо я тут вообще конченый идиот (даже после
f8e2e4dfc6870c4dad7e62be9bb02ae9dd73d180).
Сколько раз я видел в man-ах, в документациях, и на ответах на форумах
FreeBSD упоминание того, что пакет штатно проходит два раза firewall?
Тысячу. Но как-то до меня это совершенно не доходило и в голове я по
сути делал one_pass для пакета -- разрешил ему вход, а дальше как-то
считал что с ним покончено, решение принято, он должен уйти. И не всегда
я понимал почему то тут, то там правило не отрабатывает как я ожидаю.
Прозрел. Сделал по сути аналоги цепочек как в iptables:
$add skipto 02000 ip4 from any to any in
$add skipto 04000 ip4 from any to any out
$add skipto 08000 ip6 from any to any in
$add skipto 10000 ip6 from any to any out
где я уже осознанно понимаю что где пакет вошёл, а где выходит. Когда
логировал пакеты, то обнаружил что один и тот же пакет у меня по два
раза входит в NAT: когда входит по внутренней сети, и когда выходит
наружу, очевидно. Не, всё это работает, просто отнюдь не самым
эффективным образом.
Более того, сколько раз я читал про recv и xmit, in/out правила и
разницу между via и ними? Сколько раз писали что например у loopback
пакетов нет in/recv? Но я всё равно в некоторых правилах решил как можно
точнее типа описывать что я хочу и в итоге многое у меня всё равно не
работало. Когда дошло про все (?) особенности in/out пакетов, то прям
чувство что я на 100% понимаю почему, как, зачем и для чего каждая
строчка (кроме всего что касается queue/shaper) ipfw мне нужна. Плюс
даже строчки с tablearg стал делать:
$add 10000 queue tablearg ip6 from any to any out xmit "table(ip6out)"
После всего этого, искал кто может собирать всякую статистику и красиво
в RRD-like виде отображать. Ну и чтобы попроще, типа suckless. Вообще и
самому то не сложно написать всё это, но остановился на collectd. А в
качестве интерфейса использую его Perl CGI скрипт, который просто парсит
директорию на файловой системе с иерархией проб и для кучи .rrd файлов
вызывает rrdtool для рендеринга. Но rrdtool, если хочется рендерить,
зависит от Cairo, который вообще тянет за собой очень нехилые по тяжести
зависимости. Иметь такое на сервере не хотелось бы. Но так как смотреть
то это всё буду только я, а rrdtool на моей машине имеет все зависимости
(и так X11 и Cairo есть), то я монтирую директорию с данными collectd по
NFS и локально запускаю web-сервер, который дёргает CGI. На сервере
rrdtool собрал облегчённой версии.
Сервер то у меня godlighty, давно не делал в нём настроек, кроме
copy-paste статических сайтов. Но CGI добавить тривиально, пример даже
не забыл закоммитить.
godlighty.Hosts[host] = &godlighty.HostCfg{
Root: "/tmp",
Hooks: []godlighty.Hook{
func(w http.ResponseWriter, r *http.Request) bool {
rc.RunCGIAndLog(host, w, r, &cgi.Handler{
Path: "/usr/local/www/collectd/collection.cgi",
Dir: "/var/empty",
})
return true
},
},
}
Заметил что торренты ночью поспокойнее раздаются. Со времён ivi то я
помнил что реально люди спят по ночам, а не смотрят фильмы, поэтому
обновления софта на серверах там проходило в ночь с воскресенья на
понедельник. Но я думал что BitTorrent то уж на ночь, как минимум,
оставляют, а днём наверняка многие отключают чтобы не мешал. Помню и про
зарубежных пользователей, да и про россиян, где чуть ли не на полсуток
может быть разница в часовом поясе -- но волна трафика у меня повторяет
картину которую на MSK-IX или ivi можно видеть.
А ещё обратил внимание, что на 10GbE, который к к моему рабочему
компьютеру идёт по обычной витой паре -- прям постоянно и регулярно
имеются ошибки передачи, даже при трафике в несколько MiB/sec. Не, я с
самого начала на это обратил внимание и ничего тут удивительного конечно
-- ибо это обычный Cat.5. Но по twinax DAC-у ошибок нет вообще, по нулям.
Сгенерирован: SGBlog 0.34.0