Comments 14
Помимо невозможности продраться через кириллические аббревиатуры (часть которых не объяснена вообще — что такое УКБД? — управление контроллерами беспроводного доступа?), непонятна оригинальность решения.
Всё же сводится к:
* распихаем клиентов по разным вланам (через SSID? через .1x? смешная третья опция?) (добавлено) Это, кстати, был бы самый интересный момент, т.к. всё остальное не участвует в непосредственно балансировке. Либо у нас с вами разное понимание термина «балансировка трафика». Покажете картинки трафика «было»/«стало»?
* первый влан подключается по-умолчанию в 1 BNG, второй — во второй, у обоих есть резерв в виде оставшегося шлюза.
И какие у вас VRF на коммутаторах? Этот момент не совсем понятен — вы не описали ядро.
Отвечу про балансировку на уровне радио, так как вопрос касался только этой части.
SSID использовался один.
Балансировка пользователей выполнялась не совсем штатно, с помощью фичи:
[7] AP Group VLANs with Wireless LAN Controllers Configuration Example, www.cisco.com
Ядро состояло из пары коммутаторов Catalyst 6500, к которым через набор гагабитных линков подключали пару BNG, mpls-сеть и коммутаторы с контроллерами WiFi.
Сложность была в том, что сессия пользователя на BNG могла быть привязана только к 1 физическому интерфейсу (не Etherchannel).
Т.е. нужно было поделить трафик пользователей на n-е число сегментов и равномерно распределить их на разные физические интерфейсы BNG, обеспечить NAT (при большом числе трансляций и ) и «симметрию» обратного трафика для того, что бы он возвращался через тот же самый BNG, что и исходящий трафик.
С точки зрения маршрутизации задачка оказалась очень нетривиальной.
Было/стало показать нет возможности.
Речь про использование VRF-lite на коммутаторах.
Получается, сами BNG ничего подобного не умеют, и вы делали обвязку, верно?
У вас со ссылками беда, вы бы делали лучше не на цискоком, а не конкретную статью. Плюс у вас часть со ссылками перегружена ненужной информацией. Например, нет нужды приводить RFC по CIDR или HSRP — это общеизвестные вещи. Ссылайтесь на то, что даст понять, в чём суть проблемы.
6500 как L2 — это жирно, конечно :) Как чистые L2 или венок из hairpin-ов из платы в плату?
Да. Не знаю, лечится ли заменой софта.
Спасибо, чувствую, надо бы переписать текст. :)
6500, как чистые L2, даже без VSS.
Не совсем понял вопрос про BNG. Функционал BNG как шлюза услуг здесь не описан (интеграции с AAA, биллингом и сервером политик и т.д.). Только физическая топология и маршрутизация трафика пользователей в т.ч. на BNG.
Были ограничения, например такое, что пользовательская сессия может быть привязана только к 1 физическому интерфейсу (из-за чего нельзя было использовать Etherchannel, пришлось придумывать схему балансировки, учитывающей то, как распределяется трафик по каналам с помощью CEF и OSPF). Оптимальный вариант был использовать 8 каналов. Но это уже лишние тонкости. :)
Заголовок поправлю, если придумаю более подходящее название. :)
Большая часть информации на схемах, текст как пояснение.
Не добавлял описание, как сеть устроена на Layer 2, тогда было бы понятнее.
Про 6500 в ядре добавлю, что использовались как L2 устройства.
Физическая топология:
L2 6500
|__ WiSM+L3 6500
|__ PE routers
|__ 2xBNG
|__ стек 2 х (L3 SW + VRV lite) <---> (nat routers) <---> (bgp routers)
Плюс к этому организация основных и резервных l2 виртуальных каналов с помощью stp.
Как будет возможность, обновлю картинки до хорошо читаемых.
Сделал апдейт статьи.
В проекте этой информации не было. Все хранилось в голове автора (me) и было зашифровано на картинках.
И почему я не стал пересдавать лабу RS в свое время. :) Представляю какими монстрами стали те, кто подошел к этому вопросу более серьезно. )
Хотя там на всех ужас
Office.com и встроенный редактор изображений на телефоне для начинающих типа меня. :)
Уж не знаю, заметил ли кто-нибудь.
Вчера операторы сотовой связи перешли на NAT и отключили IPv6.
Знаково и потенциально потянет кучу проблем.
Балансировка трафика в IP-сетях оператора