taf_321

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

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

Да, надо убрать на боевом применении. Только убирать 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 нужная вам конвертилка уже есть.

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

Такое подозрение, что вы эти элтексы в глаза не видели, а перепеваете какого-то рабиновича. Нет tftp? Тогда можно залить по scp, то бишь по ssh.

1. Заходим на элтекс 2. делаем copy run start 3. copy start tftp://a.b.c.d/filename.cfg 4. сбрасываем его в ноль, или берем с полки новый 5. производим минимальную настройку, чтобы он мог ходить по IP 6. делаем copy tftp://a.b.c.d/filename.cfg flash://system/configuration/startup-config 7. reload И да, через tftp/scp можно заливать части конфигурации, и она будет объединена с уже имеющейся.

Через bgp_local_pref в import filter выставляем приоритеты какие нужно.

Собственно активность этой "живой" темы наглядно иллюстрирует степень актуальности и потребности в таком способе подключения.

Такой список у него есть. В виде прайса. Реальной потребности нет. То, что это нужно вам одному (остальным 100 тыс клиентам этого не надо), это не показатель "растет потребность". Еще раз, вы десятью годами оплаты своей "потребностью" не компенсируете даже дня работы специалиста, чтобы он вашу "потребность" встроил во всю цепочку взаимодействия системы - от биллинга до OLT.

Этот софт оператору вы из своего кармана купили и подарили?

Смотрите через какой порт есть маршрут до 192.168.1.0/24. Вполне вероятна ситуация, что после ваших манипуляций с портами остается висеть маршрут в статусе Unreachable