taf_321

Помониторьте свободное место на /tmp. Падения случаются не тогда, когда там место кончается? У меня что-то подобное было и как раз было связано с исчерпанием места под кольцевые буферы.

Таки нарушением будет применение кабеля, не входящего в список допустимых.

Кстати да. Под серверной нагрузкой первым из строя выходит именно SLC кэш. Вроде как по TBW ресурса достаточно, а ядро сыпет ошибочными секторами. В итоге имеем еще приличный запас на TLC/QLC матрицах, но в целом устройство уже не рабочее. Кэш под nginx и хранилище БД это немного разные профили записи-чтения. В местах, где основная нагрузка чтение, любая SSD будет годами успешно трудится.

Если у вас уже живет внутри iBGP, то смысл наличия OSPF теряется. Пусть префиксы на белые и серые бегают в iBGP, только на границе поставить соответствующую фильтрацию анонсов.

Разве поля, присутствующие в v5 не представлены полностью в v9?

2модераторы: перенесите, плз, тему в раздел "Программное обеспечение, биллинг и *unix системы", где ей самое место.

Не смотрели на эту тему в сторону openvswitch?

Это замечательно работает в обе стороны. Все улыбаются, а ты не лыбишься? Да ты подозрительный тип, надо тебя спросить что ты забыл в этом районе и вообще чё там у тебя по карманам. Кто свалил в Пресветлый Валинор эту тему сразу на себе прочувствовали.

Не может такого случиться, что у вас банально исчерпался пул адресов? И по этой причине сервер начал дрючить лизы чтобы быстрее ловить высвободившиеся.

Да, надо убрать на боевом применении. Только убирать counter из чейна на мой взгляд не стоит. Все-таки регулярно бывает ситуация, когда надо знать - потери пакетов от того что они просто теряются, или это работа полисера. Да. Запихал все в postrouting по старой привычке, когда настоящий шейпер работает исключительно для исходящего трафика.

Там всё достаточно просто: table inet mangle { map poly_u_4 { type ipv4_addr : verdict flags interval counter } map poly_d_4 { type ipv4_addr : verdict flags interval counter } map poly_u_6 { type ipv6_addr : verdict flags interval counter } map poly_d_6 { type ipv6_addr : verdict flags interval counter } chain POSTROUTING { type filter hook postrouting priority mangle; policy accept; ip saddr vmap @poly_u_4 ip6 saddr vmap @poly_u_6 ip daddr vmap @poly_d_4 ip6 daddr vmap @poly_d_6 } } таблицы набиваем элементами вида: table inet mangle { map poly_d_4 { type ipv4_addr : verdict flags interval counter elements = { 100.64.0.1/32 : goto policer_dl_51776, } } } Сама нарезка в соотвествующем чейне table inet mangle { chain policer_dl_51776 { limit rate over 12500 kbytes/second burst 2500 kbytes counter drop } } И как упомянул, массово заливать в ядро тысячи правил и элементов через nft add будет грусть-печаль, поэтому приходится для компиляции подготавливать полноценный структурированный конфиг, а не набор команд на исполнение.

Что можно сказать после некоторого времени использования. Таки при нагрузке на 4-5 гигабитах при ~20 тыс чейнов и ~40 тыс элементов в vmap разницы с модульным ratelimit не замечено. Но только в рамках полисинга. При этом решение на nftables оказалось в целом на порядок менее требовальным к ресурсам процессора, чем связка iptables + ipset + ipt_ratelimit.

16 гигабит пока вряд ли сможем организовать, но сейчас в процессе внедрения на месте, где прогоняется 4-6 гигабит. Один нюанс уже вылез - добавлять через add chain и add rule тысячи правил и чейнов не самая удачная идея. Всё ОЧЕНЬ неторопливо. Потому надо рисовать сразу цельный файл рулесета с чейнами и содержимым vmap. Тогда компиляция и вливание байткода в ядро происходят за десятые доли секунды.

Оживить вряд ли, но данные вытащить можно. Контор, которые этим занимаются уже достаточно. Вопрос в ценнике за эту услугу + стоимость донора.

Вот в этом случае скорость 125000 kbytes/second будет делиться между 10.10.115.10 и 10.10.115.11, или 125000 kbytes/second выделяться каждому?

#!/bin/sh curl --user INN_AS_USERNAME:PASSWORD -X POST -o dump.no-clear-base64 \ -d "<?xml version=\"1.0\" encoding=\"UTF-8\"?> \ <soap:Envelope soap:encodingStyle=\"http://schemas.xmlsoap.org/soap/encoding/\" \ xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\" \ xmlns:wsdl=\"http://schemas.xmlsoap.org/wsdl/\" \ xmlns:soapenc=\"http://schemas.xmlsoap.org/soap/encoding/\" \ xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" \ xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\" \ xmlns:tns=\"http://vigruzki.rkn.gov.ru/OperatorRequest/\"> \ <soap:Body> <tns:getResultSocResources> \ <code xsi:type=\"xsd:string\"></code> \ </tns:getResultSocResources> \ </soap:Body></soap:Envelope>" \ "https://vigruzki2.rkn.gov.ru/services/OperatorRequest2/" grep -oP "<registerZipArchive>.*</registerZipArchive>" dump.no-clear-base64|cut -d ">" -f 2 | cut -d "<" -f 1|base64 -d > dump-soc.zip

На сколько это все хорошо работает со списком правил ~10 тыс? Ситуация с плоским фильтром iptables не повторяется?

Собирается на ядрах вплоть до 5.16 и iptables-1.8.7 (новее не проверялось). И даже работает. Но проблема, что нельзя задать полосу более 2 гигабит остается.

У топикстартера проблемы начинаются когда он выползает за пределы тарифа. Да, тогда начинаются дропы и трафик приводится к тарифным значениям. Собственно, это штатная работа полисера. Это местечковый ведомственный оператор, Иркутскэнергосвязь. Как вижу, на самом деле практика отмены буста (соррь, неправильно выразился ранее) весьма широко применяется.

Оборудование абсолютно адекватное и никто никуда не деградировал. Просто кое-кто ухи накушался, выбрав тариф не по потребностям. И предложение взять другой тариф с более высокой скоростью тут совершенно корректен. Если так жалко отдавать клиентские деньги провайдеру, то никто вам не мешает сделать шейпер со своей стороны, чтобы обломать провайдерский полисер. На современных тарифных скоростях никто уже в ШПД не шейпит, везде полисинг. На прошлой неделе выхватили аналогичную проблему под выходные. Жесткие дропы, "танкисты" воют в саппорт. По внешним каналам вроде до потолка еще дохрена. А оказалось что одной ноге надоело считать бёрст, и она ввела жесткий верхний лимит. Вот так, в пятницу под конец рабочего дня.

Обычно линк пропадает после пары-тройки вытаскиваний-втыканий, когда полировку совсем ушатывают. При стыке UPC+APC, кстати, даже перетыкать не надо. Достаточно чтобы патчкорд шевелился при лазании по кроссу.

Мне вообще непонятно зачем заливать портянки через терминал, если есть более надёжный и быстрый способ через tftp/sftp. to Saab95: у микротика перестали течь дескрипторы от открываемых сеансов ssh?

Этот параметр для ipoe, речь шла про pppoe, на нем это работать не будет.

Это совсем печаль. Уж не помню с какой версии (возможно как раз в помянутой 3.12) они переехали на православный postgresql с каноничный postgis для картирования объектов. Вполне возможно что в скрипте миграции с mysql -> pgsql нужная вам конвертилка уже есть.

Как он останавливается, позвольте спросить?