Резервный канал в схеме с двумя роутерами

[theadenter]

Долгое время пользовались одним 1036-12G-4S. На нем крутились: PPPoE сервер, NAT, нарезка скорости.

Время шло, нагрузка росла, и мы уперлись в то, что NAT с PPPoE устроил настоящую войну, в итоге роутер улетал в 100% по цпу при переподключениях клиентов, что вызывало еще больший отвал клиентов и более сильную нагрузку, которую можно было исправить только ручками.

Почитав интернет, понял, что нужно покупать еще один роутер и выносить задачи NAT (вместе с его тяжелым connection tracking), маршрутизации на него. Составили схему и решили купить второй 1036-12G-4S. Сделали все по плану, все заработало. Проблему войны NAT и PPPoE решили, теперь конкретно они не нагружают проц.

failover (1).png

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

В старой схеме все было понятно. PPPoE-клиент подключался, подгружались данные из RADIUS, среди которых были лимиты скорости и данные address-list. По данной записи в address-list роутер принимал решение, можно ему пройти через резервный канал (группа authorized-failover) или нет (группа authorized).

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

Я пока вижу пару вариантов:
1) сделать отдельную подсеть для клиентов с резервным каналом. В этом случае есть неудобство - есть пользователи с белыми IP, кому также нужно резервирование
2) по отметке DSCP с определенным значением между двумя роутерами, по которому роутер будет принимать решение, разрешить ли ему резервный канал. Этот вариант пока только в теории, глубоко не копал. Не выглядит красиво.

Может есть более интересные варианты? Воткнуть в PPPoE сервер резервный канал не решение, ведь в будущем у нас будет еще один роутер с PPPoE-сервером.

[Chupaka]

Вариант с DHCP - наиболее лёгкий и адекватный в данной ситуации, как мне кажется.

По поводу 100% ЦПУ при переподключении - а вы в NAT, часом, не используете masquerade? Вроде как именно он даёт такую нагрузку при изменении интерфейсов, и переходом на src-nat проблема решается.

[theadenter]

Пришлось остановиться на первом варианте, как наиболее логичном. Все таки DSCP, по сути, приоритеты QoS (классы трафика), поэтому использовать их не по назначению - это некрасивый костыль. Белые IP решили отдельно добавлять ручками в address-list на роутере с резервным каналом. Благо их всего пара десятков.
Перевод masquerade в src-nat совсем не помог. Тоже был уверен, читая форумы, что проблема этим и решится.

[Chupaka]

Пришлось остановиться на первом варианте, как наиболее логичном. Все таки DSCP, по сути, приоритеты QoS (классы трафика), поэтому использовать их не по назначению - это некрасивый костыль.

Differentiated Services Code Point (DSCP, Точка кода дифференцированных услуг) - элемент архитектуры компьютерных сетей, описывающий простой масштабируемый механизм классификации, управления трафиком

В терминологии IPv6 заголовок называется Traffic Class

А у вас, простите, разве не дифференциацию трафика (по исходящему каналу) делать надо? Не рулить разные классы трафика в разные каналы? Так что про назначение и костыль - тут я с вами категорически не согласен.

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