[KMS_]

Доброго времени суток.

 

делаем Vlan per user на mikrotik для сетки на 8000 абонов.

 

придумали использовать CCR-1036.

конфигурация делается так:

 

/interface vlan

add arp=disabled interface=sfp-sfpplus1 l2mtu=1576 mtu=1504 name=Q50 vlan-id=50

add arp=proxy-arp interface=Q50 l2mtu=1572 name=50.100 vlan-id=100

add arp=proxy-arp interface=Q50 l2mtu=1572 name=50.101 vlan-id=101

/ip pool

add name=50.100 ranges=10.25.0.113

add name=50.101 ranges=10.25.0.114

/ip dhcp-server

add address-pool=50.100 interface=50.100 name=50.100

add address-pool=50.101 interface=50.101 name=50.101

/ip address

add address=10.25.0.1 interface=50.100 network=10.25.0.113

add address=10.25.0.1 interface=50.100 network=10.25.0.114

/ip dhcp-server network

add address=10.25.0.0/16 dns-server=77.88.8.8 gateway=10.25.0.1

/ip firewall address-list

add address=10.25.0.113 list=allow

add address=10.25.0.114 list=allow

 

Имеем на каждого абонента в среднем 5 записей в конфиге.

 

1000 абонентов, все Ок полет нормальный, регенерация конфига через API за 10-15 сек, все пашет

3000 абонентов, все Ок полет нормальный, API тупит, регенерация за 1-4 минуты, может отвалится по таймауту, абоны пашут.

5000 и больше, API или не отвечает, или часто отваливается с внутренней ошибкой и просьбой обратится в саппорт, регенерация конфига практически невозможна, в винбоксе интерфейсы не выводятся, в ссх тоже (подозреваю что и то и то обращается через внутреннее соединение к API)

 

Методом проб и ошибок выявлено следующее. Если сбрасываем микротик в ноль, и вливаем туда без нагрузки 5-8 тыс абонов, апи работает и интерфейс с SSH выводит данные. Стоит начать изменять данные конфига командами set, remove, add - API втупливает и встает колом, а через некоторое время микротик уходит в ребут с ошибкой kernel fail. Иногда выдает большой дамп ядра в консоль rs-232. После перезагрузки, не успевая применить в конфиг уходит в ребут, иногда может не послушаться команды reboot, как и любой другой.

 

Предвидя вопросы по чрезмерной перегрузке API микротика запросами сразу отмечу - оно не трет все подряд и не создает заново, конфиг анализируется, ненужное удаляется, недостающее добавляется, неправильное правится командой set, никаких лишних движений не делается (заменять set на последовательный remove + add пробовал, не меняется ничего.)

 

Думаю, стоит отметить, за всё время загрузка CPU ни разу не превысила 12-13%.

 

Может подскажет кто-либо, как правильно настроить микротик ?

Заранее благодарю.

Изменено 2 ноября, 2015 пользователем KMS_

[Mindaugas]

Зачем вам по VLAN для каждого клиента?

[dimmons]

Зачем вам по VLAN для каждого клиента?

 

Это вопрос филосовский, давайте будем считать что это данность, ибо все плюсы и минусы дано уже разжеваны по форумам, минусы мы успешно преодолели, плюсы эксплуатируем, вопрос только о том как к этому приспособить микротик.

[Saab95]

/ip firewall address-list

add address=10.25.0.113 list=allow

add address=10.25.0.114 list=allow

 

Это совершенно лишнее. Если у абонента нет средств, то помещайте его в список должников. Если у него деньги есть, никакие записи не нужны. Учитывая то, что должников обычно меньше, тем тех, кто регулярно платит, то именно такое решение оптимальное.

 

Если у вас на 3000 абонентах все работает, то и не вешайте больше на одну железку, поставьте две. Можно сказать циска более 3000 абонентов вытягивает без проблем.

[dimmons]

Есть разные варианты распределния абонентов по адресным листам, в данном случае вариант тестовый, есть варианты с гораздо более широким спектром применения списков адресов, по направлениям и т.п. Суть проблемы не в этом, конфиг микротика с более чем 15 тыс элементов вызывает проблемы при его систематической модернизации. Это пороховая бочка, я не знаю на каком объеме конфигурации и при каком масштабе вносимых изменений в конфигурацию произойдет сбой. На 3 тыс абонентов уже наблюдаются затруднения, при том что потенциал железки не использован даже на 10-12 процентов. В режиме простой марщрутизации, 36 ядерный микротик не напрягаясь переваривает 8 тыс абонентов имея при этом 2 кратный запас. Весь затык на агрегации, проблема в объеме настроек и количестве вносимых изменений. Беда явно гдето в механизме хранения конфигурации. Сосбтвенно создавая топик, была надежда найти решение именно этой проблемы.

 

Цели померится с цисками нет, циски стоят и работают, но это вендорозависимость плюс еще ряд лично мне неудобных моментов в эксплуатации, ищется удобная и предсказуемаю (в сопоставимых ценах) альтернатива.

[KMS_]

/ip firewall address-list

add address=10.25.0.113 list=allow

add address=10.25.0.114 list=allow

 

Это совершенно лишнее. Если у абонента нет средств, то помещайте его в список должников. Если у него деньги есть, никакие записи не нужны. Учитывая то, что должников обычно меньше, тем тех, кто регулярно платит, то именно такое решение оптимальное.

 

Если у вас на 3000 абонентах все работает, то и не вешайте больше на одну железку, поставьте две. Можно сказать циска более 3000 абонентов вытягивает без проблем.

 

Циска вытягивает номинальное количество абонентов. Работаем на 5-и цисках, всё ок.

Но мы ушли от темы.

[morom]

up-ну тему.

 

Тоже изучаю мат. часть по поводу реализации vlan-per-user на mikrorik.

Вопрос к топикстартеру - как-то удалось разрулить проблему с неотзывчивостью?

[Гость scx]

И я апну.

Что-то решилось? Просто у нас такая же сеть и если 3000 абонов это потолок, то в ближайшем будущем придется задумываться об апгрейде.

А заодно вопрос. Можно ли как-то обойтись без proxy-arp если нужно чтобы обмен внутри был только у определенных вланов?

[xandrman]

На данный момент тестирую работу с 55000 записями в address-list, на каждую строку API отвечает порядка 3-4 секунд, не не отваливается.

Использую CCR-1016.

Время увеличивается по мере увеличения общего количества строк.

Веду размышления на тему имеет ли смысл пробовать внешний накопитель для загрузки ОС с него (ssd, sdhc).

[alibek]

55к строк, 3 секунды на каждую - почти двое суток. Я правильно понял?

[Olejon]

мне кажется Х86 с каким нить серверным зеоном и быстрым ССД формата М2 решили бы эти проблемы... 

[xandrman]

11 часов назад, alibek сказал:

55к строк, 3 секунды на каждую - почти двое суток. Я правильно понял?

К сожалению, да.

Но тут есть особенности.

Если выгрузить полностью все списки - занимает порядка 20 секунд.

То есть я выгружаю все листы, а потом их на сервере перерабатываю, сравнивая с необходимым списком. Затем в конфиг только вносятся необходимые изменения построчно.

[Saab95]

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

[xdav]

В 25.10.2017 в 23:50, Saab95 сказал:

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

Вот тут ОЧЕНЬ интересно, когда есть 1000 абонентов, и если на Каждого создать Simple Queue то это сильно сжирает ресурсы, Деревья же абонентов с одинаковыми тарифами группируют. Или можно как то распределить прохождение пакета через список Simple Queue по аналогии цепочек Firewall?

[Saab95]

На практике нет никакой разницы, деревья это или простые правила, нагрузка одинаковая на современных прошивках. Если нужно кроме ограничения сделать приоритеты трафика на входящем канале (когда его на всех не хватает), можно сделать одно правило PCQ по внешнему направлению, указав буфер побольше.

[xdav]

Тогда для указанного примера если мы хотим ограничивать будет корректно создать на 1000 абонентов и это мало скажется на производительности?

 

/queue simple

add max-limit=10M/10M name=queue50.100 target=50.100

add max-limit=10M/10M name=queue50.101 target=50.101

...

 

То как же тогда WIKI с высказыванием:

Цитата

В случае наличия 1000 очередей, пакету, соответствующему условиям последней очереди, необходимо будет пройти через 999 очередей, прежде чем он достигнет своего назначения.

 

[Saab95]

На CCR1036 используется в некоторых местах и 1500, и 2000 простых шейперов, трафик 1-1.5гб, загрузка процессора по графику микротика не более 60-70 процентов. Естественно без ната и прочей ерунды.

 

Для простых шейперов поправьте тип буфера на PCQ, т.к. основная задача оборудования пропускать абонентский трафик без потерь, а если установлен стандартный буфер в 10 или там 50 пакетов, то на тарифах даже 10М при загрузке в потолок идут постоянные дропы, а трафик к вам из интернета пришел, а к абоненту отправлен не был - абонент запрашивает его снова и это создает дополнительную нагрузку на входящий канал. Примерно 10-15-20 процентов в зависимости от ситуации.

 

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

 

Обычно значения ставят Limit - 5k, Total Limit 200000k, и все классификаторы - 4 галочки адреса и порты.

[sauroneg]

В 01.11.2017 в 04:46, Saab95 сказал:

Обычно значения ставят Limit - 5k, Total Limit 200000k, и все классификаторы - 4 галочки адреса и порты.

Поясните пожалуйста, при замене PFIFO по умолчанию на PCQ стандартные значения 50KiB и 2000KiB остается только поставить 4 галочки?

[Saab95]

Да, если вы ставите одно правило на все ограничения скорости. Только стандартные значения желательно увеличить, в этом и весь смысл использования такого рода ограничений.

[sauroneg]

Только что, Saab95 сказал:

Да, если вы ставите одно правило на все ограничения скорости. Только стандартные значения желательно увеличить, в этом и весь смысл использования такого рода ограничений.

До каких значений желательно увеличить?

[Saab95]

Чем больше- тем лучше, но не больше максимально необходимого. То есть после настроек открываете раздел простых очередей, добавляете туда столбик с дропнутыми пакетами на прием и на передачу, сортируете по этим столбикам - если есть дропы - увеличиваете размер буфера. Если дропов нет - можно уменьшить. Но смотреть надо статистику хотя бы за сутки.

 

Смысл буферов в том, что все данные, полученные из интернета на роутер, должны быть доставлены абоненту, а не отбрасываться, т.к. это вызывает переповтор данных, что увеличивает нагрузку на входящий канал (снижает его скорость). Если ранее были другие ограничения, то переход на PCQ увеличивает реальную скорость канала на 10-15, а порой и 20 процентов.

[sauroneg]

3 минуты назад, Saab95 сказал:

Чем больше- тем лучше, но не больше максимально необходимого. То есть после настроек открываете раздел простых очередей, добавляете туда столбик с дропнутыми пакетами на прием и на передачу, сортируете по этим столбикам - если есть дропы - увеличиваете размер буфера. Если дропов нет - можно уменьшить. Но смотреть надо статистику хотя бы за сутки.

 

Смысл буферов в том, что все данные, полученные из интернета на роутер, должны быть доставлены абоненту, а не отбрасываться, т.к. это вызывает переповтор данных, что увеличивает нагрузку на входящий канал (снижает его скорость). Если ранее были другие ограничения, то переход на PCQ увеличивает реальную скорость канала на 10-15, а порой и 20 процентов.

Спасибо за советы, будем пробовать

[Timax]

В 02.11.2015 в 23:44, KMS_ сказал:

Доброго времени суток.

 

делаем Vlan per user на mikrotik для сетки на 8000 абонов.

 

придумали использовать CCR-1036.

конфигурация делается так:

 

/interface vlan

add arp=disabled interface=sfp-sfpplus1 l2mtu=1576 mtu=1504 name=Q50 vlan-id=50

add arp=proxy-arp interface=Q50 l2mtu=1572 name=50.100 vlan-id=100

add arp=proxy-arp interface=Q50 l2mtu=1572 name=50.101 vlan-id=101

/ip pool

add name=50.100 ranges=10.25.0.113

add name=50.101 ranges=10.25.0.114

/ip dhcp-server

add address-pool=50.100 interface=50.100 name=50.100

add address-pool=50.101 interface=50.101 name=50.101

/ip address

add address=10.25.0.1 interface=50.100 network=10.25.0.113

add address=10.25.0.1 interface=50.100 network=10.25.0.114

/ip dhcp-server network

add address=10.25.0.0/16 dns-server=77.88.8.8 gateway=10.25.0.1

/ip firewall address-list

add address=10.25.0.113 list=allow

add address=10.25.0.114 list=allow

 

Имеем на каждого абонента в среднем 5 записей в конфиге.

 

1000 абонентов, все Ок полет нормальный, регенерация конфига через API за 10-15 сек, все пашет

3000 абонентов, все Ок полет нормальный, API тупит, регенерация за 1-4 минуты, может отвалится по таймауту, абоны пашут.

5000 и больше, API или не отвечает, или часто отваливается с внутренней ошибкой и просьбой обратится в саппорт, регенерация конфига практически невозможна, в винбоксе интерфейсы не выводятся, в ссх тоже (подозреваю что и то и то обращается через внутреннее соединение к API)

 

Методом проб и ошибок выявлено следующее. Если сбрасываем микротик в ноль, и вливаем туда без нагрузки 5-8 тыс абонов, апи работает и интерфейс с SSH выводит данные. Стоит начать изменять данные конфига командами set, remove, add - API втупливает и встает колом, а через некоторое время микротик уходит в ребут с ошибкой kernel fail. Иногда выдает большой дамп ядра в консоль rs-232. После перезагрузки, не успевая применить в конфиг уходит в ребут, иногда может не послушаться команды reboot, как и любой другой.

 

Предвидя вопросы по чрезмерной перегрузке API микротика запросами сразу отмечу - оно не трет все подряд и не создает заново, конфиг анализируется, ненужное удаляется, недостающее добавляется, неправильное правится командой set, никаких лишних движений не делается (заменять set на последовательный remove + add пробовал, не меняется ничего.)

 

Думаю, стоит отметить, за всё время загрузка CPU ни разу не превысила 12-13%.

 

Может подскажет кто-либо, как правильно настроить микротик ?

Заранее благодарю.

 

Добрый день! И как? Получилось у вас загрузить такое количество данных без проблем? Сейчас юзаете схему vlan на абонента на mikrotik?

[KMS_]

Нет. Переписка с микротиком не приблизила нас к решению.

Решили двигаться в направлении нормального BRAS.

[agach]

se100 сейчас подешевел, хорошая альтернатива, правда придется городить LACP с нынешними скоростями на тарифах