Решение от Aruba уже научилось dot1x/radius vlan assignment без включения statefull firewall на контроллере?
Помню, это очень покоробило — либо включать ограничение количества сессий на пользователя (я не хочу этого делать на контроллере беспроводной сети, если потребуется — это задача фаерволов), либо вся беспроводная сеть падала при сканировании интернетов каким-нибудь masscan'ом, по очевидным причинам.
Несколько лет назад имел возможность потестировать оба решения на топовых (на тот момент) точках. Контроллер арубы был очень перегружен дополнительными свистелками и перделками, но хуже выполнял основную задачу по перекладыванию фреймов из воздуха в проводную сеть.
>В итоге, после того как инженер из команды мониторинга создаст отчёт и оформит все проблемы, руководители возлагают на администраторов следующие задачи
В софте 7.3..4 — медный патчкорд между контроллерами был обязательным требованием.
Теоретически — этот патчкорд можно было засунуть в свич и пробросить куда угодно, но требовалось обеспечить падение физического интерфейса на другой стороне для корректной работы фейловера. Городить ради этого mpls'ный псевдопровод мы не стали.
В начале работ у нас был только план типового этажа офисного здания, а так же примерная схема расположения рабочих мест. Исходя из этого была спланирована расстановка точек, с учетом количества устройств которые будут приходиться на каждую точку доступа, проницаемости стен в двух диапазонах и межэтажных перекрытий. После чего были сгенерированы heatmap'ы и проведена проверка их достоверности в реальных условиях.
Да. Собрали тестовый стенд из точки доступа, большого упса и макбука. Побродили среди строителей, сделали замеры для типового этажа, покатались на крыше лифта.
Это отдельностоящяя башня, без каких-либо соседних офисов и источников интерференции, с большими открытыми опенспейсами — поэтому результаты измерений практически не отличались от сгененрированных карт и умозрительных предсказаний.
MC-LAG на джуниперах (MX'ах) — имхо ничем не лучше стека, хотя за последние пару лет стали стабильней.
Те же самые проблемы общего (пусть и частично) контролплейна и синхронизации ARP'ов, ipv6 нейборов, запрет на использование *STP и т.д.
> Для надёжности они застэкированы через модули
сомнительное в плане надежности решение — иметь на двух железках общий контрол-плейн. А софт обновлять? А внезапные креши?
Что касается балансировки в LAG, вероятно в режиме custom хешируется 4 бита вместо 3-х. По тем же самым полям.
Пользовался аналогичным решением на displaylink с двумя дополнительными мониторами на OSX. Все очень плохо:
1) Полность софтовая прорисовка. Драйвер отжирал по 10-60% CPU на air11, на pro 13.
2) Низкая скорость обновления, тот же просмотр ютуба на таком мониторе некомфортен.
3) Плохое взаимодействие с window-сервером макоси. Артефакты, сбои при отрисовке, периодически сбивалась настройка расположения мониторов. + теперь есть ограничение на один такой монитор для OSX.
4) После 10.10 — не работала прозрачность окон. Сильно лагал скролинг. Очень редко обновляют дрова — первая бета выходит через месяц после новой макоси, окончательно допиливают (убирая баги) — через полгода или около того.
я сопрягал, в целом работает. Есть проблемы с гранулярностью SA — требуется явно указать proxy-id для каждого соедиенния со стороны SRX. Поддержка нескольких proxy-id для одного соединения появилась в JunOS буквально пару месяцев назад, фича еще сырая, и все равно с динамическим роутингом все будет непросто. Пока что если за SRX находится несколько неагрегируемых сетей — лучше по старинке делать gre-over-ipsec.
Когда эти точки в России можно будет купить? Либо хотя бы модули AIR-RM3000AC-R-K9 для предыдущего поколения? Есть ли хоть какая-то возможность уже сейчас завести AC на контроллере и точках с доменом -R-? На цискоконнект никаких сроков так и не назвали.
По теме — srx не слишком удобны в эксплуатации.
Особенно кластеры: безумно долгое применение конфигурации (и как следствие медленная работа скриптов), периодическая рассинхронизация, не работающий commit confirmed (который описан в конце статьи), отсутствие нормального ECMP.
На роутерах остуствует понятие зон безопаности (кроме софтовой J серии), эту секцию можно было бы пропустить. Другой, более гибкий синтаксис бриджеваняи ( interface vlan -> irb, vlan -> bridge domain).
Обычно и сами кеши тянут контент друг с друга, если связанность позволяет.
Помню, это очень покоробило — либо включать ограничение количества сессий на пользователя (я не хочу этого делать на контроллере беспроводной сети, если потребуется — это задача фаерволов), либо вся беспроводная сеть падала при сканировании интернетов каким-нибудь masscan'ом, по очевидным причинам.
Несколько лет назад имел возможность потестировать оба решения на топовых (на тот момент) точках. Контроллер арубы был очень перегружен дополнительными свистелками и перделками, но хуже выполнял основную задачу по перекладыванию фреймов из воздуха в проводную сеть.
Что имелось в виду? Equal-cost multi-path все-таки не протокол, а стратегия маршрутизации.
Теоретически — этот патчкорд можно было засунуть в свич и пробросить куда угодно, но требовалось обеспечить падение физического интерфейса на другой стороне для корректной работы фейловера. Городить ради этого mpls'ный псевдопровод мы не стали.
Это отдельностоящяя башня, без каких-либо соседних офисов и источников интерференции, с большими открытыми опенспейсами — поэтому результаты измерений практически не отличались от сгененрированных карт и умозрительных предсказаний.
Те же самые проблемы общего (пусть и частично) контролплейна и синхронизации ARP'ов, ipv6 нейборов, запрет на использование *STP и т.д.
сомнительное в плане надежности решение — иметь на двух железках общий контрол-плейн. А софт обновлять? А внезапные креши?
Что касается балансировки в LAG, вероятно в режиме custom хешируется 4 бита вместо 3-х. По тем же самым полям.
1) Полность софтовая прорисовка. Драйвер отжирал по 10-60% CPU на air11, на pro 13.
2) Низкая скорость обновления, тот же просмотр ютуба на таком мониторе некомфортен.
3) Плохое взаимодействие с window-сервером макоси. Артефакты, сбои при отрисовке, периодически сбивалась настройка расположения мониторов. + теперь есть ограничение на один такой монитор для OSX.
4) После 10.10 — не работала прозрачность окон. Сильно лагал скролинг. Очень редко обновляют дрова — первая бета выходит через месяц после новой макоси, окончательно допиливают (убирая баги) — через полгода или около того.
Особенно кластеры: безумно долгое применение конфигурации (и как следствие медленная работа скриптов), периодическая рассинхронизация, не работающий commit confirmed (который описан в конце статьи), отсутствие нормального ECMP.
для europe/moscow
>http://www.shrubbery.net/rancid/