Артем: Сразу оговорюсь - это будет мой последний комментарий в нашей беседе. Устал объяснять очевидный вещи, не вижу смысла продолжать дискуссию. Уж извините...
Вы изобретаете велосипед. Зачем как то хитрить с mac или arp, если ключ сети известен. Также отмечу, что любой уважающий себя сетевой инженер такие вещи как mac, arp spoofing и др. типы атак канального уровня предвидет и как минимум контролирует сеть на предмет их эксплуатации. Ну а как максимум - использует технологии защиты от них.
Артем: Браво. И вот тут возникает вопрос - а как прослушать трафик между беспроводными клиентами А и Б, если точка доступа не позволяет на себе запустить сетевой анализатор?
Артем: Вы не ответили на мой последний вопрос. Если фрейм прилетел на точку и был скомутирован обратно по воздуху другому клиенту? Он не попал в проводной сегмент вообще...
Артем: В вопросе нет ни слова о том, что автор контролирует точку. Фраза "моя сеть WiFi" этого не подразумевает, а лишь говорит о том, что автора интерисует данная проблема применительно к сети, которую он использует и знет PSK.
Артем: Уважаемый, если Вы думаете что в современной беспроводной сети (WPA2 PSK) применяется только заданный руками ключ - то Вы глубоко заблуждаетесь. Рекомендую Вам хотя бы отзнакомится со статьей википедии - en.wikipedia.org/wiki/IEEE_802.11i-2004
Если вкрадце и без технических деталей - трафик каждого клиента шифруется отдельным ключем, который генерируется на основе ряда параметров (в том числе и заданный руками PSK). Поэтому для расшифровки трафика и необходимо перехватить handshake жертвы, что позволит произвести вычисление ключа шифрования...
Насколько я понимаю, Вы применяете полиси мап на вход ouutside интерфейса. Т.е. трафик, описанный в ACL 2 c адресом источника 192.168.0.11 ожидается железкой из-вне.
Вы точно так хотели настроить?
Извините, но фраза "резервирование на железном уровне" немного вводит в заблуждение. Например в линейке ASR1000 есть модели с резевирование практически всех комопнентов - 2 головы (CP и MP), 2 x линейные карты (DP), блоки питания и вентиляторы также дублируются. Не резервируется только шасси. Так же есть поддержка ISSU - то есть апдейты ПО не влекут за собой дайнтаймы маршрутизации.
Если возьмете 2 железки, то есть HA фича поинтересней HSRP - Stateful Interchassis Redundancy (www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_n...
Так что если бюджет позволяет - тогда ASR1K. Нет - ISR послених поколений.
Как по мне, так Вас и 2-ух 29хх хватит. А ACL лучше на ASA перенести - это её хлеб.
@B_M необходимо понимание не колличства пользователей по группам, а по зданиям. На основании этой информации можно уже выбирать точки доступа и их колличестов. Из оборудования лучше смотреть на решения с централизованным управениям, что бы не нстраивать каждую точку руками (например это - www.ubnt.com/unifi/unifi-ap/, вот неплохой обзор - habrahabr.ru/company/comptek/blog/114722/). На группы можно разделить по SSID привязанные к разным VLAN коммутатора. Необхоимые правила нарезать ACL на маршрутизаторе. Если развернута AD - то можно посмотреть в сторону 802.1x для конпоративного сегмента БС. Гостевой сегмент можно тоже прикрутить в AD через WEB аутентификацию. А в целом вопрос очень обширный и если хотите получить стабильную и маштабируемую в будущем БС, то лучше начать с радиоразведки и планирования.
@vvpoloskin, тема довольна обширная. Предлагаю почитать это - docwiki.cisco.com/wiki/PfR:Home, или это - www.anticisco.ru/blogs/2011/05/%D0%B2%D0%B2%D0%B5%... Первой ссылкой я руководствовался, когда сам внедрял.
Могу рассказать по своему опыту, заранее прошу простить за стиль...
Где-то пару лет назад подключили мы второго провайдера через второй пограничный маршрутизатор. Соответственно на каждом маршрутизаторе настроили default маршрут на своего ISP. Ну и настроили нехитрую связку автоматического переключения провайдера через IP SLA.
Но руководство негодовало от того, что один канал простаивает и была поставлена задача реализовать одновременное использование обоих каналов с балансировкой по равномерной загрузке каналов. Вот с этого момента и началось мое знакомство с PfR.
Один из маршрутизаторов был настроен как MC и BR одновременно, второй только BR. Настроены таймеры и вроде все начало работать, PfR определил потоки трафика и сетевые приложения, и даже начал инжектить специфические маршруты в таблицу маршрутизации для них, но...
Но тут столкнулись с проблемой. В текущей топологии из двух маршрутизаторов не удалось нормально реализовать работу NAT (либо это ограничение самого протокола, либо просто недостаточно знаний было на тот момент). Согласно докам PfR нормально будет работать с NAT'ом топологии с одним пограничным маршрутизатором MC/BR или 3-мя и более, когда MC натит и форвардит на один из BRов.
Короче, поигравшись месячишко с PfR все-таки купили свою AS и подняли FullView с провайдерами.
Вы изобретаете велосипед. Зачем как то хитрить с mac или arp, если ключ сети известен. Также отмечу, что любой уважающий себя сетевой инженер такие вещи как mac, arp spoofing и др. типы атак канального уровня предвидет и как минимум контролирует сеть на предмет их эксплуатации. Ну а как максимум - использует технологии защиты от них.