mikrotik + beeline. проблемы с tcp mss

[xphoenix]

Добрый день, суть вопроса в следующем.

На микротик приходит билайновский 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, решил задать вопрос и тут.

[Ivan_83]

1.Учится вам надо.

2. tcp-mss - Max Send Size: оно (правило в фаере) не режет пакеты, оно меняет 2 байта в tcp заголовке и пересчитывает/обновляет контрольную сумму, таким образом обе стороны узнают максимальный размер пакета который они могут отправлять друг дружке.

3. Не насилуйте мозг и микротик, поставьте клиентам мту = 1300. Сейчас у вас роутер только и делает что собирает пакеты для дефрагментации и фрагментирует их обратно.

[xphoenix]

1. это и делаем)

2. имеете ввиду в настройках pppoe servera на базе поставить mtu и mru 1300? как скажется на работе?

Edited April 16, 2013 by xphoenix

[Ivan_83]

В идеале мту клиентских и апстримовского интерфейсов должны совпадать, и мсс фикс можно сразу применять ко всем ппп интерфейсам с одинаковой настройкой.

Тогда мт не будет заниматься пересборками и фрагментацией пакетов пролетающих сквозь него.

Конкретно выставление 1300 позволит сразу проверить вашу гипотезу об узком месте.

И я думаю что вы режете не красиво, потому и плавает. В идеале нужно tcp с флагами пропускать в первую очередь, а остальное уже можно дропать или ставить в длинную очередь, тогда меньше плавать будет.

[xphoenix]

Загрузка не настолько высокая чтобы волноваться за мт) главное печалят эти непонятки с ограничением скорости.

Поподробнее можно насчет "красивой" резки скорости и tcp с флагами, ибо не так давно занимаюсь данными вопросами, правило создаваемое pppoe или simple queues вроде самое просто чем можно резать клиентам скорость.

 

причем заметил, чем больше тариф - тем больше провалы, например при ограничении в 4м, разница минимальна, на 10м уже 1-2м теряются, на ограничении в 20м тест показывает только 10... хотя без ограничения 40. мозг не варит уже)

Edited April 16, 2013 by xphoenix

[Saab95]

Нужно буфер пакетов увеличивать, т.к. при малых они отбрасываются и идут сплошные переповторы и просадки на TCP. Посмотрите в сторону PCQ.

[xphoenix]

PCQ выглядит как-то уж очень страшно) неужели такие огромные просадки канала из-за уменьшения tcp mss и с этим ничем простым бороться нельзя, и почему правило в mangle действует на все интерфейсы? добавлял в него in\out interface - никаких изменений... апдейт прошивки может как-то сказаться в положительную сторону в моем случае?

[Saab95]

PCQ выглядит как-то уж очень страшно) неужели такие огромные просадки канала из-за уменьшения tcp mss и с этим ничем простым бороться нельзя, и почему правило в mangle действует на все интерфейсы? добавлял в него in\out interface - никаких изменений... апдейт прошивки может как-то сказаться в положительную сторону в моем случае?

 

Вовсе нет, для этого не нужно создавать дерево очередей. Достаточно создать 2 правила, у одного классификатор в виде src address, у второго dst address. Одно будет для входящего трафика, второе для исходящего. Создаете нужное количество копий, с указанием нужного ограничения скорости. Далее распределяете клиентов по address list, создаете правила в simple queueus и указываете сопоставления списков и нужных правил PCQ, вот и все дела.

[Ivan_83]

И очереди нихрена не работают на 6.13 и ниже, только 5.хх

[Constantin]

И очереди нихрена не работают на 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 в них не влить.....

Edited April 17, 2013 by Constantin

[xphoenix]

всем спасибо за инфу, на решение проблемы наткнулся случайно, уже пытаясь сделать PCQ очереди заметил косяк. Дело в том что правила создаваемые автоматически при подключении пппое клиентов по умолчанию имеют queue type - default-small, а в нем стоит pfifo=10. (при первичной настройке меняли только default на 1000) увеличение до 1000 решило все непонятки, ограничения теперь выдают столько сколько положено