Обновления ПО aireos 8.0 и ios-xe обзор новых возможностей ·...

Обновления ПО AireOS 8.0 и IOS-XE 3.6 – обзор новых возможностей

Виктор Платов, инженер-консультант, CCIE

Максим Сафаргалеев, системный инженер

15 июля 2014

Cisco Confidential 2 © 2013-2014 Cisco and/or its affiliates. All rights reserved.

Нужно ли переводить слайды?


AireOS 8.0

Введение

Переработанный FlexConnect

Улучшенные механизмы High Availability

AVC Phase 3

Новые возможности RRM / HDX

«Мелкие» улучшения

IOS-XE 3.6

Поддержка новых моделей ТД

Локальное профилирование и классификация

Смешанный режим 802.11r

Содержание


Матрица совместимости 8.0

ПО контроллера БЛВС 8.0

Продукт

Версия

Статус

WLC (AireOs)

8.0

Июль 2014

WLC(IOS)

3.6

Июль 2014

CPI

2.1*

Апрель 2014

CPI

2.2^

Октябрь/Ноябрь 2014

MSE

8.0

Июль 2014

ISE

1.2.1 и 1.3

1.2.1 – Май 2014. 1.3 – Август 2014

*Поддерживает фичи 8.0 только в режиме монитора; ^Полная поддержка релиза 8.0.


Аппаратные платформы, поддерживаемые в 8.0

Продукт Поддерживаемые аппаратные платформы

ТД Модули WSSI, 11ac, 3G

1260, 3500, 600,1600, 3600, 2600, 3700, 2700, 702, 702W,

802,1530, 1552WU, 1550**

*1040, *1140,*#1130, *#1240, **1520

КБЛВС 2500, WLCM2, 5500, WiSM2, 7500 , 8500, vWLC, HA-SKU, UCS-E

MSE 3355, Virtual Appliance

*EOL Platforms in 8.0

*# фичи аналогичны 7.6; фичи 8.0 не подерживаются

** 1520 и 1550 с 64MB не будут поддерживать PPPoE и PMIPv6


Привычный интерфейс контроллера


Теперь его можно раскрасить


Переработанный FlexConnect


• Smart AP Image Upgrade

• ACL на FlexConnect AP

• AAA Over-ride of VLAN - dynamic VLAN assignment for locally switched clients

• FlexConnect Re-branding

• Fast Roaming for Voice Clients

• Peer to Peer Blocking

• PEAP and EAP-TLS Support (7.5)

• FlexConnect Group specific WLAN-VLAN mapping(7.5)

• AAA Client ACL(7.5)

• Flex 7500 Scale Update

• VLAN Based Central Switching

• Split Tunneling

• Central DHCP Processing

• WGB/uWGB Support with local switching

• Bidirectional Rate Limiting

• Support for ISE BYOD Registration & Provisioning

9

• Ethernet Fallback (7.6)

• Videostream for Local switching (8.0)

• Faster time to deploy (8.0)

• Flex with Mesh deployment support (8.0)

Flex – 7.2 Flex – 7.3 & 7.4

Flex – 7.5, 7.6, 8.0


Контроллеры

5508, 7510, 8510, 2504, vWLC, WiSM2

Точки доступа

1140, 1260, 3500, 1600, 2600, 3600, 3700, 2700, 1530

Релиз ПО

CUWN Release 8.0

FlexConnect VideoStream поддерживается на:


(Cisco Controller) >config media-stream multicast-direct ?

enable Enable Global Multicast to Unicast Conversion

disable Disable Global Multicast to Unicast Conversion

Настройка FlexConnect VideoStream Включить VideoStream глобально


Настройка FlexConnect VideoStream Добавить описание потока

(Cisco Controller) >configure media-stream add multicast-direct <media-stream-

name> <start-IP> <end-IP> [template | detail <bandwidth> <packet-size> <Re-

evaluation> video <priority> <drop|fallback>]’


Настройка FlexConnect VideoStream Включить VideoStream на уровне WLAN

(Cisco Controller) >config wlan media-stream multicast-direct 1 ?

enable Enables Multicast-direct on the WLAN

disable Disables Multicast-direct on the WLAN.


(Cisco Controller) >show flexconnect media-stream client summary

Client Mac Stream Name Multicast IP AP-Name VLAN Type

----------------- -------------------- --------------- ------------------------- ----- ----------------

7c:d1:c3:86:7e:dc Media2 229.77.77.28 AP_1600 0 Multicast Direct

88:cb:87:bd:0c:ab Media2 229.77.77.28 AP_1600 0 Multicast Direct

d8:96:95:02:7e:b4 Media2 229.77.77.28 AP_1600 0 Multicast Direct

Мониторинг FlexConnect VideoStream На контроллере БЛВС


Мониторинг FlexConnect VideoStream WireShark

Data Rate : 24 Mbps

Destination MAC: 01:00:5E:02:02:02

Data Rate : 115 Mbps

Destination MAC: 00:A0:B0:A4:01:18

QoS : 4-Video

Обычный мультикаст Multicast Direct


Мониторинг FlexConnect VideoStream Точка доступа

AP_1600#show capwap mcast flexconnect clients

======

Bridge Group: 1

=======

Multcast Group Address 229.77.77.28::

MCUC List:

Number of MCUC Client: 3

88cb.87bd.0cab(Bridge Group = 1 Vlan = 0)

7cd1.c386.7edc(Bridge Group = 1 Vlan = 0)

d896.9502.7eb4(Bridge Group = 1 Vlan = 0)

--------

MC Only List:

Number of MC Only Client: 0

--------


Ограничения FlexConnect VideoStream

Отсутствует admission control для запросов на подключение к видео потокам локально коммутируемых клиентов

Из-за ограничения на размер поля полезной нагрузки пакета CAPWAP, только первые 100 медиапотоков будут отправлены с контроллера на ТД

Например, config media-stream add multicast-direct stream1 225.0.0.1 225.0.0.10 template coarse является одной записью из 100 возможных

Роуминг в случае недоступности контроллера (standalone mode) на FlexConnect ТД поддерживаться не будет

Поддерживается только IPv4

Session Message Config не поддерживается


Устраняет необходимость перезагрузки ТД при ее переводе в режим FlexConnect

Любые другие изменения режима/подрежима (кроме wIPS) все еще требуют перезагрузки

Настройка ТД в режим FlexConnect


Режим работы Flex + Bridge (Flex для Mesh точек доступа)

• Новый режим работы ТД, позволяющий подключить удаленные mesh точки доступа

• Control plane поддерживает:

• Connected (контроллер доступен)

• Standalone (контроллер недоступен)

• Data Plane поддерживает:

• Централизованную коммутацию (split MAC)

• Локальную коммутацию (local MAC)

• Flexconnect Groups

• Максимально 8 Mesh хопов, 32 MAPна RAP

• Поддержка Local AAA

• Контроллер может иметь набор из Bridge и Flex + Bridge точек доступа

• MAP использует VLAN-ы родительских RAP

2

2

WAN

Центральный

офис

Филиал

Централизованный

трафик

Локальный

трафик

Контроллеры БЛВС

Local Data WLAN

Central Data WLAN


Flex+bridge Failover

• AP SSO поддерживается только для RAP

• Внедрения Flex+bridge должны использовать схему резервирования N+1

• Для отказоустойчивости можно использовать несколько RAP с секторными антеннами

• RAP переходит в режим standalone при недоступности контроллера

• MAP переходят в режим standalone когда контроллер недоступен, а шлюз доступен

• В режиме standalone mode новые ТД не могут подключиться к Mesh дереву

WAN

Сервер

приложений

Primary

Филиал

Secondary


Проводные VLAN-ы должны совпадать с беспроводными VLAN-ами, настроенными на RAP

MAP унаследует проводные VLANы (до 4-ех на1552) от своего родителя

Настройка VLAN будет меняться каждый раз при смене родителя

Flex+bridge MAP наследование VLAN

RAP1

RAP2

Проводные VLANы: 10, 20

Беспроводные VLANы: 10, 20

Настроенные

VLAN-ы:

60, 70

MAP


VLAN-ы:

10, 20


VLAN-ы:

30, 40


VLAN-ы:

60, 70

Проводные VLANы: 30, 40

Беспроводные VLANы: 30, 40

Проводные

VLAN-ы будут

унаследованы

при смене

родителя


Wireless Access Points AP_NAME General

Wireless Access Points AP_NAME FlexConnect

Настройка Flex + Bridge

После

изменения ТД

перезагрузитс

я

Аналогично ТД

в режиме Flex


• Active – Standby 1:1

Redundancy

• Оба контроллера используют одинаковые IP адреса

• Синхронизация конфигурации (полная и инкрементальная)

• ТД не переходят в состояние Discovery в случае выхода из строя активного контроллера

• Поддерживается на контроллерах 5500 / 7500 / 8500 и WiSM-2

• Время восстановления 5 - 1000 мс в случае отказа устройства, ~3 секунды в случае проблем с сетью

• Автоматическое восстановление

из режима maintenance при

восстановлении доступности

Peer-RP и шлюза

• Поддержка Internal DHCP сервера

в режиме SSO

• Поддержка SSO для sleeping clients

• Поддержка SSO для OEAP 600

• Статистика CAC и Call Statistics копируется на Standby

• Улучшен механизм проверки доступности шлюза для снижения числа ложных срабатываний

• ICMP Peer ping эхо пакеты заменены на UDP сообщения

• Уменьшено время настройки HA пары

• Active – Standby могут быть

географически распределены

L2 VLAN/Оптика

• База данных клиентов

копируется на Standby

• Информация о клиенте

синхронизируется когда

он перемещается в

состояние RUN

• Не требуется

реассоциация клиента

при аварийном

переключении

• Время восстановления

сервиса= Время

детектирования

неисправности+ время

переключения(восстановление

сети/сходимость)

Фаза 1 : APSSO

7.3

Фаза 2 : Client SSO

7.5

Фаза 3 : Улучшения в

8.0


Механизм слежения за статусом Bulk Sync, синхронизации информации о ТД и клиентах

Статус может быть Pending/In-progress/Complete

Вывод команды “show redundancy summary” будет отражать статус Bulk Sync

Статус Bulk Sync


Новые категории статистических данных All

Infra

Transport

Keep-Alive

GW-Reachability

Config-Sync

Улучшенные Debug-и: Redundancy Statistics


Keep-alive retry

От 3 до 10

Keep-alive timer

От 100 до 1000мс

Peer search timer

От 60 до 300с

Настраиваемые параметры Keepalive и Peer search


ICMP ping on RMI заменен на UDP сообщение (RMI – Redundancy Management Interface)

•Лучше, потому что ICMP Ping могут теряться при высокой нагрузке на сеть

Улучшения механизма проверки доступности шлюза : после 6 последовательных потерь пинга, на адрес шлюза отсылается ARP запрос

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

Standby WLC входит в режим MTC «на лету» без перезагрузки

•После восстановления доступа к Peer-RP и шлюзу, механизм автовосстановления из режима MTC перезагрузит WLC и «спарит» его с активным контроллером (фича релиза 7.6)

Faster HA Pair Up – отказ от сравнения XML файлов конфигурации и лишней перезагрузки standby контроллера во время «спаривания»

•XML отсылается с активного контроллера на резервный во время инициализации перед процессом сравнения файлов конфигурации. Устраняется двойная перезагрузка.

Остальные улучшения


Поддержка встроенного DHCP сервера

Синхронизация статистики AP Radio CAC

Поддержка Sleeping Client

Поддержка ТД OEAP600

Поддержка 802.11ас клиентов

Улучшения Client SSO


‘Internal DHCP Server’ может быть настроен

на контроллерах в режиме HA

Вся информация синхронизируется с

резервным контроллером, что

позволяет продолжить работу

DHCP сервера сразу после аварийного

переключения

Поддержка встроенного DHCP сервера


БД Sleeping Client синхронизируется между активным и

резервным контроллерами

«Спящим» клиентам не требуется

проходить повторную Web аутентификацию если они проснулись

не позже sleeping client timeout даже после аварийного

переключения контроллеров

Поддержка SSO для «спящих» клиентов


ТД OEAP600 не переустанавливают CAPWAP туннель

Аварийное переключение контроллеров прозрачно для

клиентов

Поддержка SSO для ТД OEAP600


AVC Фаза 3


• Классификация и контроль1039 приложений с использованием движка NBAR2

• Поддержка 16 AVC профилей с 32 правилами на профиль

• Один AVC профиль на один WLAN; одинаковый AVC профиль может быть приложен к различным WLAN-ам

• AVC профиль, приложенный к WLAN, содержит правило с действием MARK или DROP

• Графическое отображение на контроллере всех классифицированных приложений

• Один NetFlow exporter и monitor на контроллер БЛВС

• Мониторинг AVC NetFlow с использованием PI (лицензия PAM)

• Поддержка Protocol Pack 4.1

• Поддержка дополнительных приложений – всего 1056

• Динамическая загрузка Protocol Pack для поддержки дополнительных приложений

• Protocol Pack 9.0

• NBAR Engine rel 3.1

• Динамическое применение AVC профилей на клиентов с использованием RADIUS атрибутов

• Ограничение полосы пропускания для конкретного приложения, используемого конкретным пользователем

• Интеграция AVC профилей в локальные политики доступа

• Маркирование AVC Directional QoS DSCP отдельно для Upstream и Downstream трафика

• Поддержка 1088 приложений

AVC - 7.4 Фаза 1

AVC – 7.5 Фаза 2

AVC – 8.0 Фаза 3


AAA AVC Profile Override для клиентов

В релизе 8.0 AVC profile может быть применен динамически с использованием AAA Override. Т.е. даже клиенты одного SSID могут использовать разные AVC профили

Соответствующий AAA атрибут настраивается на AAA серверах, например, Open Radius/Cisco ACS/ISE.

Данный AAA атрибут определен как Cisco “AV-Pair и может быть задан в виде пары строка/значение на стороне ААА сервера.

AAA AVC Profile определен как Cisco AV Pair. Строковая переменная называется “avc-profile-name” . Значение должно совпадать с именем профиля, заранее созданного на контроллере.

До релиза 8.0 AVC Profile настраивался для каждого WLAN, и все

клиенты, подключенные к этому WLAN, использовали данный AVC profile.


Учитель

YouTube

Учитель Ученик

YouTube Facebook bittorrent

Ученик

Cisco-av-pair=avc-profile-name=<имя профиля> PI/AAA Контроллер БЛВС

Switch

AP

SSID: Classroom

Security:WPA2/802.1x

Cisco-av-pair=role=<имя роли>

Skype

Facebook Skype bittorrent


Настройка ISE для AVC


Настройка AVC для AAA override Пример – Учитель, Ученик


(WLC) >show client detail 18:20:32:bd:52:b7

Client MAC Address............................... 18:20:32:bd:52:b7

Client Username ................................. student1

Client State..................................... Associated

Client User Group................................ student

Client NAC OOB State............................. Access

Wireless LAN Id.................................. 2

Wireless LAN Network Name (SSID)................. ClassroomAVC

Wireless LAN Profile Name........................ ClassroomAVC

Policy Manager State............................. RUN

Policy Manager Rule Created...................... Yes

Audit Session ID................................. 0a0a0a0500000061533434e9

AAA Role Type.................................... student

Local Policy Applied............................. None

AVC Profile Name: ............................... student-AVC

Проверка динамических профилей AVC с использованием CLI

> show client detail


AVC профиль в настройках WLAN

(WLC-IPv6) >show avc profile detailed <Profile Name>


Гранулярные политики AVC – Примеры использования

Политики использования приложений для каждого пользователя и для каждого устройства

Ролевая политика контроля приложений

• Alice(медсестра) и Bob(IT администратор) работают в больнице

• Оба Alice и Bob подключены к одному SSID.

• Bob может использовать некоторые приложения (например,

YouTube), Alice нет

Политика, основанная на ролях и типе клиентского устройства

• Alice получает доступ к информации EMR с корпоративного ноутбука

• Alice не может получить доступ к EMR с ее персонального iPAD

Политика, основанная на роях, типе устройств и характера

использования приложений

• Alice имеет ограниченный (rate limit) доступ в Skype с ее iPhone и

ограничения использования (только скачивание) для Bittorrent


AVC Directional QoS DSCP Marking для Upstream/Downstream трафика

До релиза 8.0 маркирование QOS можно было настроить как правило в AVC профиле. Данная фича настраивалась как DSCP маркирования и применялось двунаправленно как к upstream, так и к downstream трафику.

В релизе 8.0 стал доступен дополнительный конфигурационный параметр (direction), который позволяет определить направление трафика, в котором следует осуществлять маркировку – Upstream или Downstream.


Настройка Directional DSCP


AVC Per-Application Per-Client Rate Limiting on WLAN До релиза 8.0 у нас был только bi-directional per client bandwidth

control.

downstream rate-limiting per client осуществляет контроллер, upstream - точка доступа.

В релизе 8.0 стала доступна возможность ограничения пропускной способности для каждого приложения каждого клиента в обоих направлениях.

Данная фича подразумевает наличие контроля за пропускной способностью приложений каждого клиента.

Находится над per client bandwidth contracts

Может работать совместно с per-client downstream rate-limiting, который более приоритетен

Замечание: Rate Limiting не поддерживается на контроллере

2504; AVC не поддерживается на vWLC;


AVC Per Application Per Client Based Rate Limiting on WLAN - Ограничения

Число приложений, для которых ограничивается полоса пропускания не более 3. Данное ограничение вводится на этапе настройки.

Только одно правило может быть настроено на приложение.

Приложение не может иметь одновременно правило Mark и rate-limit.

Одинаковые значения используются для upstream и downstream.

Скорость должна быть настроена в виде общей скорости для up/downstream.

Данные правила rate-limit не будут применяться динамически к клиентам. Применение правил происходит ТОЛЬКО как результат аутентификации/реаутентификации.


Интеграция AVC Profiles в правила Local Policy

Обеспечивает возможность применения AVC profiles (используются для контроля за приложениями) на основе роли, возвращаемой от AAA сервера

1. На основе user-group

2. Per-user

3. Per-user и per-device( задано в политике)


AVC profile определяется как часть Local policy.

Любой client/user во время аутентификации с использованием AAA сервера получит роль, определяемую для конкретного пользователя или группы пользователей как результат ответа AAA сервера.

Полученная роль используется для применения локальной политики

После успешного сопоставления ролей выбирается нужная локальная политика, и AVC profile, указанный в данной политике, применяется к клиенту/пользователю.

Тип устройства, указанный в политике, также может являться фактором принятия решения о том, к какому типу устройств нужно применять AVC profile.

Интеграция AVC Profiles в правила Local Policy


Настройка AVC profile и локальной политики


Обзор новых возможностей AVC в 8.0

• Движок NBAR2 версии 3.1 в виде библиотеки для легкого и быстрого обновления

• Новый Protocol Pack ver 9.0 для нового движка– отсутствие обратной совместимости

• Local Policy может быть применена к клиентам одного WLAN для контроля за доступом определенных устройств к определенным приложениями

• В релизах 7.5 и 7.6 все пользователи одного WLAN используют одинаковый AVC профиль

• В 8.0 появляется возможность динамически применять AVC профили к различным клиентам одного WLAN с использованием RADIUS атрибутов

• В релизах 7.5 и 7.6 мы поддерживали ограничение полосы пропускания для конкретного клиента в обоих направлениях

В направлении Downstream контроль за полосой обеспечивал контроллер, тогда как в направлении Upstream скорость контролировала ТД.

• В релизе 8.0 мы стали поддерживать ограничение полосы пропускания для конкретного приложения.

Данный контроль будет осуществляться после Per-User и per-SSID bandwidth contracts.

Число приложений, для которых выполняется действие rate-limiting ограничено тремя

Правила не применяются к пользователям динамически в любое время. Только на этап аутентификации.

Ограничение полосы пропускания осуществляется в обоих направлениях сразу.


Новые возможности RRM / HDX


8.0 Новые возможности RRM

• DCA в RF profiles!

• RX_SOP

• Optimized Roaming


DCA в RF Profiles – Почему?

• Поддержка географически распределенных (через границы государств) сетей– одна AP group на страну- каждая со своим списком доступных каналов в RF Profiles

• Управление сетью с каналами разной ширины (802.11n/ac 40/80МГц)

• Назначение канала в зависимости от физической области пространства – служба разработки на втором этаже, бухгалтерия на первом, мы хотим минимизировать их влияние друг на друга

• Конференц-центр – позволяет назначать диапазоны каналов каждому участнику для изоляции зон покрытия


RRM DCA в RF Profiles – правила применения

• На контроллере должен быть сконфигурирован соответствующий country code для того, чтобы включить настройку соответствующих ему каналов.

• Каналы должны быть выбраны в глобальной настройке DCA. Иначе они будут недоступны для настройки внутри RF профилей

• Необходимо отключить сети 802.11a/b для изменения набора DCA каналов или их ширины (20/40/80)

• В RF профиле можно настроить назначение каналов иной ширины, чем это указано глобально

• Соответствующие RF Profiles и AP groups должны быть настроены на каждом контроллере, которые управляют точками доступа, которые Вы хотите поместить в данную AP group.


RX-SOP – (Receive - Start of Packet) – Что это такое?

• Receiver Start of Packet Detection Threshold (RX-SOP) определяет уровень WiFi сигнала в dBm на котором радиоинтерфейс ТД может демодулировать и декодировать пакет.

• Чем выше этот уровень, тем менее чувствителен радиоинтерфейс точки доступа, тем меньше зона покрытия одной точки доступа

• Путем уменьшения размера ячейки, мы можем влиять на очень много параметров, начиная от распределения клиентов и заканчивая нашим видением утилизации канала

• Этот функционал предназначен для сетей с высокой плотностью абонентов – и требует четкого понимания того, что Вы хотите в итоге получить

• Клиент должен иметь возможность куда-то подключиться, если мы его игнорируем текущей точкой доступа

Предостережение – это аналогично установке кирпичной стены – если вы ее

построите выше, чем клиенты могут быть услышаны – вы их больше не услышите.

На самом деле.


RX-SOP – Зачем это использовать?

• Уменьшаем чувствительность к интерференции и шуму – уменьшаем утилизацию канала

• Это четко очерчивает границу соты– мы будем слышать только то, что хотим покрыть

• Предосторожности –

• Вы можете существенно уменьшить зону беспроводного покрытия

• Вы можете сделать так, что нужные клиент не смогут подключиться и работать с Вашими точками доступа

• Данный функционал предназначен для использования совместно с текущими техниками для решения специфических проблем в том случае, когда Вы осознаете требуемую зону покрытия и модель использования сети клиентами

• RX-SOP доступен на глобальном уровне и внутри RF профилей – мы настоятельно рекомендуем применять функционал через RF профили для решения специфических для сетей с высокой плотностью абонентов сетей.


Настройка RX-SOP

• Возможные значения High, Medium, Low, Auto

• Auto значение по умолчанию. RX-SOP равен CCA threshold

• Большинство сетей могут использовать настройку LOW и при этом заметить улучшения

• Данная настройка влияет на все пакеты, принимаемые приемником

61

-80dB

-85dB

Современное

решение Cisco “Optimized Roaming”

3G или 4G

-80dB -80dB

Слабый Wi-Fi

сигнал

«Статичность» клиента –

главная причина плохой

производительности

WiFi

Падение

производительности

всей соты

Удовлетворенность

пользователя

Эффективное

использование

ячейки


Optimized Roaming

• Устанавливает пороговое значение RSSI и/или минимальная Data rate при которых

клиенту будет отсылаться deauth

• Разработано для поддержки Cellular Hand Off

• Доступна настройка четырех глобальных параметров

• Включено/Выключено

• Интервал (секунды)

• Пороговое значение Data Rate

• Пороговое значение RSSI, настраиваемое через CHDM

• Триггером является событие Pre-Coverage hole – настраивается в секции CHDM


Настройка Optimized Roaming

• Enable/Disable – Глобальная настройка

• Interval = #кол-во секунд между проверками радио

• Data Rate threshold-

• Используется совместно с RSSI threshold, если настроен, то используется как ключевой триггер: и data rate и rssi должны сработать для деаутентификации– по умолчанию выключено

• RSSI threshold – устанавливается через data RSSI в настройках CHDM на глобальном уровне и в разделе RRM в RF Profile


Логика Optimized Roaming

Data RSSI Data Rate Result

True Disable (default) Deauth

True False No Action

True True Deauth

• Использует CHDM Data RSSI как триггер

• В одиночку – решение принимается на основе RSSI принимаемого от клиента сигнала

• В комбинации с Data Rate – дает дополнительный триггер и позволяет CHDM функционировать

• При использовании совместно с Client Low RSSI check, используется бОльшее из двух значений (с гистерезисом в 6 dB).


Сравнение Optimized Roaming и Low RSSI

• Low RSSI check – это совершенно независимый функционал: он устанавливает минимальный уровень RSSI принимаемого от клиента сигнала, необходимый для его ассоциации с ТД

• В Optimized Roaming имеется встроенный 6 dB гистерезис для предотвращения пинг-понга

• Т.е. если Optimized roaming настроен на -75, тогда для переподключения клиента к точке доступа его сигнал должен увеличиться до -69 dBm

• Алгоритм проверяет low RSSI и Optimized roaming перед тем, как позволить клиенту подключиться – оба критерия должны выполняться


Часто требуется разместить удаленные ТД за маршрутизатором (или МСЭ) с функционалом Port Address Translation (PAT)

Маршрутизаторы удаляют запись в UDP таблице после 5 отсутствия трафика

В настоящее время, регулярные Keep-Alives отправляются через CAPWAP Control Tunnel, но не используются для CAPWAP Data tunnel

Это “может” привести к ситуации, в которой ТД имеет живое Control соединение с контроллером БЛВС с валидной записью в таблицах маршрутизатора, тогда как пакеты данных будут «улетать» в «черную дыру». ТД предполагает, что никаких проблем нет, тогда как МСЭ может отбрасывать эти пакеты, из-за отсутствия информации в таблице трансляций.

ТД может оставаться в этом состоянии долгое время, период которого неограничен. Перезагрузка ТД или Интернет соединения (действия пользователя по умолчанию ) на некоторое время решают проблему, что делает основную причину ненайденной.

8.0 предлагает решение этой проблемы!

CAPWAP: Поддержка Data Tunnel Keep-Alive


FlexConnect ТД может быть PPPoE клиентом

Исключает необходимость во внешнем

PPPoE маршрутизаторе

Впервые появилась в 7.3, убрана в 7.5

Снова появилась в 8.0, в

оптимизированном виде!

PPPoE Client на FlexConnect ТД вернулся!

PPPoE CAPWAP 802.11 IP PPPoE CAPWAP 802.11 IP

Контроллер PPPoE Клиент на

FlexConnect ТД

PPPoE Сервер


Один заказчик хочет добавить несколько VSA в сообщения RADIUS Accounting для конкретного SSID…

Другой заказчик хочет добавить другой набор VSA как в сообщения RADIUS Authentication так и Accounting…

…Как мы можем масштабируемо удовлетворить эти запросы?!

Легко: позволим им определять атрибуты самим!

В 8.0, сервис-провайдеры могут научить свои контроллеры новым VSA

Это достигается путем импорта XML текстового файла, который говорит контроллеру:

1. Список VSA и их значений

2. Что с ними делать

Мы позволим Вам отсылать любые Vendor Specific Attributes которые Вы пожелаете!


<radiusFile>

<avpList SSID_PROF=“SSIDProfileName” incAuth="true" incAcct="false">

<radiusAttributes>

<attributeName>SVR-Zip-Code</attributeName>

<vendorId>14369</vendorId>

<attributeId>14</attributeId>

<valueType>STRING</valueType>

<attributeValue>33612</attributeValue>

</radiusAttributes>

<radiusAttributes>

…

</radiusAttributes>

</avpList>

<avpList SSID_PROF=“SSIDProfileName” incAuth=“false” incAcct=“true”>

<radiusAttributes>

…

</radiusAttributes>

</avpList>

</radiusFile>

Vendor Specific AVP – Как выглядит этот файл?


Vendor Specific AVPs- Как загрузить файл в контроллер?


NAI (Network Access Identifier) – это идентификатор в формате “Username@Realm”

В случае dot1x, NAI виден контроллеру как часть EAP Identity Response

В случае EAP-SIM или EAP-AKA NAI выглядит как:

0<IMSI>@wlan.mnc<MNC>.mcc<MCC>.3gppnetwork.org†

Все, что после“@” и есть значение Realm

Но, знали ли Вы, что значение Realm уникально для каждого сервис-провайдера?

Что если контроллер будет использовать значение Realm для выбора RADIUS сервера

для аутентификации и/или аккаунтинга беспроводных клиентов? Будет ли от этого

польза?

Мы сделали именно это :)

†More details in the slide notes

Выбор RADIUS сервера по REALM


Легко как раз-два:

1. Включить фичу на уровне WLAN

2. Задать при добавлении RADIUS сервера соответствующие значения REALM (до 30 сервер)

RADIUS selection by REALM – Как это настроить?


При dot1x аутентификации контроллер может видеть только EAP outer identity.

Если NAI-realm включен для данного WLAN, но от клиента не получен EAP outer

identity, контроллер, как обычно, выберет первый RADIUS сервер из списка

доступных.

Однако если полученная outer identity будет содержать REALM или просто иметь в

своем составе символ“@”, но при этом данное значение REALM не будет совпадать

ни с одним из заданных для RADIUS серверов, данный беспроводной клиент

будет деассоциирован

Это хорошо работает для EAP-SIM & EAP-AKA, однако если к тому же самому WLAN

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

пользователей надо подходить осторожно.

RADIUS selection by REALM – Тонкости функционирования


Наконец! Теперь при использовании 8.0, если клиент начинает работу с https:// веб-страницы, он будет перенаправлен на WebAuth страницу аутентификации!

Но обратите внимание, что теперь страницы ошибки SSL Warning Page теперь не избежать…

Поддержка HTTPS для WebAuth гостевых пользователей

До 8.0 После 8.0!

Запомните: Это не является проблемой реализации Cisco!

Та же самая ошибка появится независимо от производителя. Так

задуман HTTPs!


Теперь можно изменять идентификаторы SSID and WLAN Profile

До 8.0

После 8.0!

• В 8.0 данные изменения можно сделать в любое время через GUI, CLI или

SNMP

• До 8.0 заказчики вынуждены были удалять WLAN создавать новый, чтобы

изменить эти параметры


Долгожданный инструмент поиска неисправностей, который активно продвигал TAC

Extended Ping доступен только через CLI.

GUI по прежнему будет иметь только базовый Ping, когда эхо пакеты отправляются с менеджмент интерфейса

Не буду утомлять вас еще одним сложным слайдом; вот как это работает:

(8500-1) > ping 10.1.1.254 ?

[<interface-name>] [<repeat count[1-100]>] [<packet size[10-2000]>]

Enter interface name and/or repeat count(1-100) and/or packet size(10-2000).

Example:

(8500-1) > ping 10.1.1.254 MyDynamicInt 10 1000

Send count=10, Receive count=10 from 10.1.1.254, Packet size = 1000

Ping от Dynamic Interfaces (extended Ping)


(8500-1) >show ap summary

Number of APs.................................... 1

Global AP User Name.............................. Not Configured

Global AP Dot1x User Name........................ Not Configured

AP Name Slots AP Model Ethernet MAC Location Country IP Address Clients DSE Location

---------- ----- ----------------- ----------------- --------- ---------- ----------- -------- --------------

8.0AP 2 AIR-CAP3602I-A-K9 44:d3:ca:42:57:a7 MyLab US 10.40.27.18 0 [0 ,0 ,0 ]

Теперь IP address отображается в выводе команды “show ap summary” + добавлен новый фильтр AP IP address

• Не надо слов…


Заказчики хотят иметь больше информации об утилизации аппаратных ресурсов контроллера

Примеры: iowait, cpu, (cpu by system, by user), load per cpu, average load, etc..

Вот список новых команд“ show system … ”добавленных в 8.0:

Больший контроль над аппаратными ресурсами

(8500-1) >show system ?

dmesg Displays dmesg logs

interfaces Displays information about the configured network interfaces

interrupts Displays the number of interrupts

iostat Displays CPU and input/output statistics for devices

meminfo Displays system memory information

neighbours Displays the IPv6 Neighbor Cache

netstat Display system network stats

process Displays process related information

route Displays system routing table

slabs Displays memory usage on slab level

timers Display system timer info

top Displays the cpu usage

vmstat Displays system virtual memory statistics


Новый метод получения стартап конфигурации

Может быть использован для восстановления настроек (Copy & Paste ready)

Аналог того, что пишется в файл при "transfer upload datatype config”

“show run-config startup-commands”

Замечания: Отнимает много процессорного времени, вызывает

«замирание» CLI/GUI на довольно продолжительное

время (до 60секунд в моих тестах)

Однако влияние ограничено только одним процессором

(из восьми) и не влияет на обработку пользовательского

трафика или время ответа на ping со стороны

контроллера

Перед выполнением команды отображается следующее

сообщение: This may take some time. Are you sure you want to start? (Y/N)


Забавный факт:

5% поставляемых нами внутриофисных ТД, заказываются с опцией ПО Mesh!!!

Также, принимая внимание тот факт, что наши внешние ТД поддерживают как Local, так и Bridge

(mesh) режимы, существует ненулевая вероятность того, что ТД будет настроена неправильно

Обычно, сначала мы должны подключить к контроллеру ТД в режиме Bridge, указав при этом ее

MAC адрес в Auth-list, для того, чтобы изменить ей режим работы.

До настоящего времени у нас были только секретные, неподдерживаемые т

недокументированные команды "test mesh mode”

В 8.0 мы добавлены 2 новых, документированных, поддерживаемых TAC команды:

capwap ap mode local† & capwap ap mode bridge†

†после ввода этих команд ТД перезагрузится

Новые команды CLI ТД для настройки режима работы (mesh, local)


Новые команды CLI ТД to configure mode (cont.) – советы по использованию ТД в режиме Local могут поставляться с урезанным образом ПО(…-rcvk9w8-…),

который не содержит Radio firmware

Перед переключением ТД из режима Local в режим Bridge убедитесь, что ТД имеет полноценный образ ПО (…-k9w8-…), и что MAC адрес ТД добавлен в фильтр на контроллере

Конечно, «старые» скрытые и неподдерживаемые команды также позволяли изменить роль Mesh ТД (т.е. RAP/ MAP), а также настроить значение BGN. Этот расширенный функционал пока недоступен в виде официально поддерживаемых команд, которые появились в 8.0

test mesh mode bridge (или local)

test mesh role rap (или map)

test mesh bgn Mybgn (настраивает значение BGN)

reload (требуется ручная перезагрузка)

Эти команды не

поддерживаются TAC-ом!


До 8.0:

Включение Telnet или SSH было доступно только для конкретной ТД

В 8.0:

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

Теперь совершенно новые ТД будут позволять собой управлять по Telnet/SSH сразу после получения IP адреса

После включения Telnet/SSH также будет доступен даже на неподключенных ТД, независимо от их режима работы (например: Bridge mode)

Включение Telnet & SSH на ТД


До 8.0: сообщения Association/Re-Association в выводе команды debug client <MAC addr> отображали только BSSID.

Жизнь была бы немного проще, если там отображалось бы имя ТД. И это случится в 8.0!

debug client: Assoc/Reassoc будет отображать имя ТД!

До 8.0

После 8.0!


…потому что это экономит время при поиске неисправностей!

show client detail: будет содержать WLAN Name & Profile

До 8.0 После 8.0!

IOS-XE 3.6.0SE


Совместимость IOS-XE 3.6.0SE

WLC IOS-XE 3.6 Based Solutions

Продукт

Версия

Статус

WLC(IOS)

3.6

CCO Июнь/июль 2014

WLC (AireOs)

7.6 / 8.0


CPI

2.1*

CCO Апрель 2014

MSE

8.0


ISE

1.2 and 1.3

1.2 Поставляется. 1.3 CCO Июль/Август2014

*Поддерживает новые устройства, но не новый функционал


AP2700I, AP 2700E

AP1532I, AP1532E

AP702W

AP702I, AP702E

Новые ТД, поддерживаемые в IOS XE 3.6


Нет поддержки AVC на 702W, 702I, 702E ( 128 M memory )

Ограничение в 100 клиентов на радио для 702I, 702E

Поддержка режимов Single и Dual Band для1532I/1532E

Подрежим wIPS поддерживается для режимов local и monitor

Поддержка режим работы и функционала

ТД / Режим Local Monitor Sniffer

2700I/2700E ✓ ✓ ✓

1532I/1532E ✓ ✓ ✗

702W ✓ ✓ ✓

702I/702E ✓ ✓ ✓


Обзор функционала AVC

3.2.0SE 3.3.0SE 3.6

• Flexible Netflow v9

• mQC based Hierarchical

QOS для 4 аппаратных

очередей для

беспроводного трафика на

контроллере

• NBAR2 выполняется на

ТД 11n второго

поколения Gen-2 AP's

• Экспорт статистики с

помощью Flexible Netflow

• Netflow апдейты

отправляются от ТД к

контроллерам каждые

90секунд

• Protocol pack = 5.1

• Привязка AVC к

QOS(Маркирование)

• Новый движок NBAR2 #16

• Новый protocol pack версии

8.0

• Привязка роли

пользователя и типа

устройства в политики AVC

• Microsoft Lync 2013 и Cisco

Jabber


IOX-XE 3.6 AVC поддерживаемый функционал Добавлена буква “C” к AVC – стал возможен контроль за приложениями

посредством политик QoS

Поддерживается на: 5760/3850/3650

Использует Protocol Pack v8.0 – NBAR2 Engine v16

Поддерживает Seamless Roaming

Более1000 приложений

Поддерживается на 11n ТД второго поколения(ТД1600, 2600, 2700, 3600, 3700 и 1532)- Не поддерживается на ТД700

Centralized и Converged Access

С помощью Flexible Netflow v9 полученную статистику можно экспортировать в PI(PAM) и внешние коллекторы (Plixir, ActionPacked, и т.д.)


IOS-XE 3.6 AVC Политики QoS Политики QoS могут применяться отдельно для Upstream и Downstream трафика

Контроль приложений обеспечивается на ТД для Upstream QoS и на коммутаторе/контроллере для Downstream QoS, при этом классификация выполняется на ТД

Направление Upstream*: Mark, Police и Drop

Направление Downstream **: Mark и Police (нет Drop)

• Действие DROP (может сбросить только upstream трафик)

• Действие MARK (трафик приложений может быть помечен различными значениями DSCP или CoS. Маркировка доступна как для upstream, так и для downstream трафика

• Действие POLICE (интенсивность трафика приложений может быть ограничена вплоть до 8 Kбит/с. Полисинг может быть применен как к upstream, так и downstream трафику.

*Направление Upstream: Беспроводной клиентТДКонтроллер

**Направление Downstream: КонтроллерТДБеспроводной клиент


IOS-XE 3.6 Политики AVC QoS Application Recognition and Control настраивается в политике Client QoS

Пример политики контроля приложений в зависимости от роли пользователя:

• Alice(медсестра) и Bob (IT администратор) работают в больнице

• И Alice, и Bob подключены к одному SSID, но при этом Bob может пользоваться некоторыми приложениями, тогда как Alice – нет

• Достигается путем задания на контроллере двух политик QoS и использования AAA override совместно с ISE

AVC настраивается в GUI в два шага:

1- Создание QoS Policy

2- Применение QoS Policy к WLAN

Мониторинг за AVC осуществляется через dashboard, для каждого клиента и SSID


NBAR/AVC Кратко:

• Одна и та же политика QoS может быть приложена к различным WLANам. Но

один WLAN может иметь только одну политику QoS

• Доступно три варианта действий DROP/MARK/POLICE для каждого

классифицированного приложения

• Только 1 NetFlow exporter и monitor может быть настроен на WLAN

• Статистика AVC отображается только для 30 самых активных приложений как

в GUI, так и в CLI

• Любое приложение, которые не распознаются NBAR движком контроллера,

попадают в раздел UNCLASSFIED/Unknown трафик

• Ограничения NBAR

• Трафик IPv6 не классифицируется

• Трафик многоадресной рассылки не классифицируется

• Protocol Pack не обновляются- они привязаны к релизу ПО


Локальное профилирование и применение политик доступа

ISE имеет богатый BYOD функционал: например, определение типа устройств, автоматическая настройка, проверка состояния и применение политики доступа

Есть заказчики, которым применение ISE дорого, но при этом требуется реализовать ряд его функций

Профилирование устройств контроллером на основе MAC OUI, HTTP, DHCP

Применение политик на пользователя или на устройство


Профили устройств • Определение типа устройства (профилирование) использует шаблоны

профилей на контроллере

• Беспроводные клиент профилируются на основе MAC OUI, DHCP, HTTP user agent

• Релиз IOS XE 3.6 содержит 287 предустановленных профилей


Настройка локального профилирования

• На уровне WLAN, включите Local HTTP Profiling


Профилирование клиентских устройств

• Когда профилирование включено, тип пользовательского оборудования отображается на странице Monitor

• Диаграмма процентного соотношения типов устройств будет доступна в 3.6


OUI

Username

Классификация

User Role

Device type MAC

VLAN ACL Session

timeout

Ingress

QoS Egress

QoS

User-Role

Ученик Учительr

Admin

Identity

Джон

Device Type


Настройка применения политики

3-х шаговый процесс

Создание Service-template

Создание Policy-Map

Ассоциирование Service Policy с WLAN/VLAN

VLAN

ACL

Session

timeout

Ingress

QoS

Egress

QoS

Service

Template

VLAN

ACL

Session t/o

Ingress QoS

Egress QoS

Username

User-Role

MAC

Device Type

OUI

Policy Map

VLAN

ACL

t/o

Ingress

QoS

Egress

QoS

Username

User-Role

MAC

Device Type

OUI

WLAN Service Policy


Что нужно знать!


Удалено ограничение, требовавшее отдельный WLAN для поддержки 802.11r

Некоторые клиенты, не поддерживающие 11r, могут подключаться к SSID с включенным 802.11r

Поддержка 802.11r Mixed-mode

Устройство/Адаптер Версия драйвера Поддерживает

iPad iOS 6 ✔

iPad Air iOS 7.0 ✔

iPod iOS 6.1.3 ✔

Android Samsung Galaxy S4 ✔

D Link ✔

Linksys AE2500 5.100.68.46 (6/10/2011) ✔

MAC OS X 10.9.2 ✔

Cisco 7921 ✔

Cisco 9971 ✔

MAC OS X 10.9 ✗

MAC OS X 10.7.4 ✗

Netgear 6.30.145.30 (03/26/2013) ✗

ADU 4.3.0.305 ✗

Juniper Odyssey ✗


Настройка 802.11r Mixed-mode

Client AKM FT

802.1x

Capable

802.1x Enable

Non 802.1x

Client

PSK Enable

Thank you.

Обновления ПО aireos 8.0 и ios-xe обзор новых возможностей ·...

Documents