xphoenix Опубликовано 16 апреля, 2013 · Жалоба Добрый день, суть вопроса в следующем. На микротик приходит билайновский l2tp, из-за специфики их сети в мангле присутствует правило /ip firewall mangle add chain=forward protocol=tcp tcp-flags=syn tcp-mss=1361-65535 action=change-mss new-mss=1360 disabled=no которое снижает все проходящие пакеты до размера 1360. И чтобы микротик смог поднять l2tp в их сети, вручную прописаны маршруты гейтов. Без правила в мангле половина сайтов не работает.. На этом же микротике авторизовываются клиенты pppoe mtu\mru по умолчанию 1480. У клиентов тарифы плана rx\tx 1m\10m. Правила пустые, создаются автоматически при авторизации pppoe. Проблема в том что при тарифе nolimit прокачка тестом по tcp выдает выдает 40мбит (по wifi-n nv2), но при установке тому же клиенту тарифа 10m прокачка тестом плавает в районе 4-6 мбит. Какие можно принять меры для исправления ситуации? пробовал в правило мангла добавить in\out interface corbina-l2tp, чтобы оно резало только входящий\исходящий только интерфейсе l2tp, сохранил, перезагрузил - не помогло. p.s. не валить все на wifi, с ним все порядке, видимость идеальная, расстояние смешное. В соседней ветке грешат именно на mtu\mru, решил задать вопрос и тут. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 16 апреля, 2013 · Жалоба 1.Учится вам надо. 2. tcp-mss - Max Send Size: оно (правило в фаере) не режет пакеты, оно меняет 2 байта в tcp заголовке и пересчитывает/обновляет контрольную сумму, таким образом обе стороны узнают максимальный размер пакета который они могут отправлять друг дружке. 3. Не насилуйте мозг и микротик, поставьте клиентам мту = 1300. Сейчас у вас роутер только и делает что собирает пакеты для дефрагментации и фрагментирует их обратно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xphoenix Опубликовано 16 апреля, 2013 (изменено) · Жалоба 1. это и делаем) 2. имеете ввиду в настройках pppoe servera на базе поставить mtu и mru 1300? как скажется на работе? Изменено 16 апреля, 2013 пользователем xphoenix Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 16 апреля, 2013 · Жалоба В идеале мту клиентских и апстримовского интерфейсов должны совпадать, и мсс фикс можно сразу применять ко всем ппп интерфейсам с одинаковой настройкой. Тогда мт не будет заниматься пересборками и фрагментацией пакетов пролетающих сквозь него. Конкретно выставление 1300 позволит сразу проверить вашу гипотезу об узком месте. И я думаю что вы режете не красиво, потому и плавает. В идеале нужно tcp с флагами пропускать в первую очередь, а остальное уже можно дропать или ставить в длинную очередь, тогда меньше плавать будет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xphoenix Опубликовано 16 апреля, 2013 (изменено) · Жалоба Загрузка не настолько высокая чтобы волноваться за мт) главное печалят эти непонятки с ограничением скорости. Поподробнее можно насчет "красивой" резки скорости и tcp с флагами, ибо не так давно занимаюсь данными вопросами, правило создаваемое pppoe или simple queues вроде самое просто чем можно резать клиентам скорость. причем заметил, чем больше тариф - тем больше провалы, например при ограничении в 4м, разница минимальна, на 10м уже 1-2м теряются, на ограничении в 20м тест показывает только 10... хотя без ограничения 40. мозг не варит уже) Изменено 16 апреля, 2013 пользователем xphoenix Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 17 апреля, 2013 · Жалоба Нужно буфер пакетов увеличивать, т.к. при малых они отбрасываются и идут сплошные переповторы и просадки на TCP. Посмотрите в сторону PCQ. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xphoenix Опубликовано 17 апреля, 2013 · Жалоба PCQ выглядит как-то уж очень страшно) неужели такие огромные просадки канала из-за уменьшения tcp mss и с этим ничем простым бороться нельзя, и почему правило в mangle действует на все интерфейсы? добавлял в него in\out interface - никаких изменений... апдейт прошивки может как-то сказаться в положительную сторону в моем случае? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 17 апреля, 2013 · Жалоба PCQ выглядит как-то уж очень страшно) неужели такие огромные просадки канала из-за уменьшения tcp mss и с этим ничем простым бороться нельзя, и почему правило в mangle действует на все интерфейсы? добавлял в него in\out interface - никаких изменений... апдейт прошивки может как-то сказаться в положительную сторону в моем случае? Вовсе нет, для этого не нужно создавать дерево очередей. Достаточно создать 2 правила, у одного классификатор в виде src address, у второго dst address. Одно будет для входящего трафика, второе для исходящего. Создаете нужное количество копий, с указанием нужного ограничения скорости. Далее распределяете клиентов по address list, создаете правила в simple queueus и указываете сопоставления списков и нужных правил PCQ, вот и все дела. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 17 апреля, 2013 · Жалоба И очереди нихрена не работают на 6.13 и ниже, только 5.хх Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Constantin Опубликовано 17 апреля, 2013 (изменено) · Жалоба И очереди нихрена не работают на 6.13 и ниже, только 5.хх о это да, Hello, Tak, nashlji chto address-list v v6.0rc13 rabotal tolko s pervimi 6 zapisjami. Probuem: http://www.mikrotik.com/download/share/routeros-tile-6.0rc14.npk http://www.mikrotik.com/download/share/routeros-x86-6.0rc14.npk http://www.mikrotik.com/download/share/all_files_6.0rc14.zip Jesji dosihpor problemi to nado poigratsja s zakonomi v mangle - zametitj action na "log" i posmotretj te lji paketi markiriruetsja. Nashi testi nepokozalji problemi s queue. последняя переписка с саппортом, прикол в том что и доступ у них есть но не настраивают сами а постоянно пишут ахинею )))) а у одного знакомого 2 коре простаивают все не может их воткнуть ибо на 6 очередя не пашут и 5 в них не влить..... Изменено 17 апреля, 2013 пользователем Constantin Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xphoenix Опубликовано 18 апреля, 2013 · Жалоба всем спасибо за инфу, на решение проблемы наткнулся случайно, уже пытаясь сделать PCQ очереди заметил косяк. Дело в том что правила создаваемые автоматически при подключении пппое клиентов по умолчанию имеют queue type - default-small, а в нем стоит pfifo=10. (при первичной настройке меняли только default на 1000) увеличение до 1000 решило все непонятки, ограничения теперь выдают столько сколько положено Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...