Spoke to spoke мультикаст в сетях DMVPN

Про настройку и диагностику технологии DMVPN в интернете написано немало статей. Однако про использование мультикаста поверх DMVPN лучшее, что мне удалось найти – это маленькая заметка в Configuration Guide.

“In DMVPN, it is recommended to configure a Rendezvous Point (RP) at or behind the hub. If there is an IP multicast source behind a spoke, the ip pim spt-threshold infinity command must be configured on spokes to avoid multicast traffic going through spoke-to-spoke tunnels.”

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

Как можно заметить, это самый обыкновенный DMVPN Phase 2, собранный в GNS3. Интерфейсы Loopback на каждом маршрутизаторе позволяют смоделировать клиентские подсети; также логично разместить RP на Hub-маршрутизаторе как центральной точке логической топологии. Для удобства адресации примем Hub = R1, Spoke1 = R2, Spoke2 = R3, Internet = R4.

Настроим PIM и RP внутри DMVPN облака.

Hub Spoke1 Spoke2

interface Loopback0
 ip address 1.1.1.1 255.255.255.255
 ip pim sparse-mode
interface Tunnel0
 ip address 192.168.0.1 255.255.255.0
 no ip redirects
 no ip split-horizon eigrp 1
 ip pim sparse-mode
 ip nhrp map multicast dynamic
 ip nhrp network-id 1
 tunnel source FastEthernet0/0
 tunnel mode gre multipoint
 tunnel vrf A
ip pim rp-address 1.1.1.1

interface Loopback0
ip address 2.2.2.2 255.255.255.255
ip pim sparse-mode
interface Tunnel0
ip address 192.168.0.2 255.255.255.0
no ip redirects
ip pim sparse-mode
ip nhrp network-id 1
ip nhrp nhs 192.168.0.1 nbma 192.168.14.1 multicast
tunnel source FastEthernet0/1
tunnel mode gre multipoint
tunnel vrf A
ip pim rp-address 1.1.1.1

 interface Loopback0
ip address 3.3.3.3 255.255.255.255
ip pim sparse-mode
interface Tunnel0
ip address 192.168.0.3 255.255.255.0
no ip redirects
ip pim sparse-mode
ip nhrp network-id 1
ip nhrp nhs 192.168.0.1 nbma 192.168.14.1 multicast
tunnel source FastEthernet1/0
tunnel mode gre multipoint
tunnel vrf A
ip pim rp-address 1.1.1.1

На данном этапе есть связность между Spoke, а также необходимые протоколы управления групповым вещанием. Самое время подписаться на мультикаст поток на Spoke1.

Spoke1(config)#int lo 0
Spoke1(config-if)#ip igmp join-group 224.1.1.1
Spoke1#sho ip mroute
(*, 224.1.1.1), 00:00:37/00:02:22, RP 1.1.1.1, flags: SJCL
  Incoming interface: Tunnel0, RPF nbr 192.168.0.1
  Outgoing interface list:
   Loopback0, Forward/Sparse, 00:00:37/00:02:22

Запустим сам поток в виде ICMP echo request сообщений, отправляемых на multicast адрес, на Spoke2.

Spoke2#ping 224.1.1.1 source lo0 rep 1000 Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 3.3.3.3
Reply to request 0 from 2.2.2.2, 156 ms..…

Не работает, причём довольно хитрым образом: первый пакет проходит (мы получаем на него ответ), однако последующие почему-то пропадают. Взглянем на то, что происходит в данный момент, на уровне пакетов.

Spoke1

Hub

Итак, это Hub не шлёт пакеты потока после обработки самого первого пакета. С чего бы вдруг?

Hub#sho ip mroute
<output omitted>
(*, 224.1.1.1), 00:03:31/00:02:55, RP 1.1.1.1, flags: SP
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list: Null
(3.3.3.3, 224.1.1.1), 00:03:08/00:02:46, flags: PJT
  Incoming interface: Tunnel0, RPF nbr 192.168.0.3
  Outgoing interface list: Null

Список OIL (outgoing interface list) пуст, что и является причиной потери потока. Или не является? Почему же тогда прошёл самый первый пакет? Давайте взглянем на Hub за пару секунд до того.

Hub#sho ip mroute
<output omitted>
(*, 224.1.1.1), 00:00:13/00:03:16, RP 1.1.1.1, flags: S
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
   Tunnel0, Forward/Sparse, 00:00:13/00:03:16

(*,G) содержит Tunnel0, что ожидаемо; RPF сосед также пока неизвестен, поскольку ни один пакет из потока ещё не прошёл через Hub. А дальше следите за руками:

  1. Spoke2 шлёт самый первый мультикаст пакет внутри unicast сообщения RP-Register;
  2. Hub, он же RP, получает RP-Register и выполняет следующие два действия: отправляет пакет согласно OIL (Tunnel0); кроме того, отправляет PIM Join в сторону источника потока (Tunnel0);
  3. В режиме PIM-SM входящий интерфейс (IIF, incoming interface) не может присутствовать в OIL (RPF check), поскольку это может породить петлю; следовательно, Tunnel0 необходимо исключить из OIL – в этот момент Spoke2 теряет поток.

Суть проблемы кроется в NBMA (non-broadcast multiple access) поведении DMVPN: Spoke2 логически находится в одном широковещательном сегменте со Spoke1, хотя физически это совсем не так (а Вы думали, Frame-Relay жил, Frame-Relay жив, Frame-Relay будет жить; надеюсь, это шутка). Впрочем, решение задачи довольно простое – надо явно указать Hub, что Tunnel0 следует рассматривать не как один интерфейс, а как набор нескольких.

Hub#sho run | i Tunnel0|nbma
  interface Tunnel0
   ip pim nbma-mode

Теперь таблица маршрутизации мультикаста правильная.

Hub#sho ip mroute
(*, 224.1.1.1), 00:03:51/00:03:27, RP 1.1.1.1, flags: S
 Incoming interface: Null, RPF nbr 0.0.0.0
 Outgoing interface list:
  Tunnel0, 192.168.0.2, Forward/Sparse, 00:00:02/00:03:27
(3.3.3.3, 224.1.1.1), 00:03:29/00:02:25, flags: JT
  Incoming interface: Tunnel0, RPF nbr 192.168.0.3
 Outgoing interface list:
   Tunnel0, 192.168.0.2, Forward/Sparse, 00:00:02/00:03:27

Поскольку Tunnel0 теперь работает как несколько интерфейсов, таблица маршрутизации мультикаста содержит не только сам интерфейс, но и адреса как получателя (192.168.0.2), так и отправителя (192.168.0.3) потока. Стоит отметить ещё одну любопытную особенность поведения DMVPN, когда поток мультикаста идёт со стороны Hub в сторону Spoke. По умолчанию, DMVPN отправляет мультикаст каждому Spoke (ip nhrp map multicast dynamic), что успешно используют протоколы маршрутизации, отправляя служебную информацию или обновления мультикастом. Однако если сеть является географически распределённой (например, несколько регионов), такое поведение может быть нежелательным: мультикаст, отправленный во все регионы, в том числе туда, где нет PIM подписки, занимает полосу, после чего его отбрасывают все Spoke, кроме того, кому поток был действительно нужен. Такое поведение можно исправить использованием PIM NBMA режима для DMVPN, что позволяет различать Spoke по адресам на уровне мультикаста и отправлять поток только тем регионам, где на него есть подписка.

Настало время ещё раз проверить связность между Spoke для мультикаста.

Spoke2#ping 224.1.1.1 so lo 0 rep 1000 Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 3.3.3.3
Reply to request 0 from 2.2.2.2, 176 ms..…

Ничего не поменялось, но мы упорные. Начнём проверять по порядку, начиная с Hub.

Hub#sho ip mroute
(*, 224.1.1.1), 00:52:32/00:02:58, RP 1.1.1.1, flags: S
 Incoming interface: Null, RPF nbr 0.0.0.0
 Outgoing interface list:
  Tunnel0, 192.168.0.2, Forward/Sparse, 00:02:12/00:02:58
(3.3.3.3, 224.1.1.1), 00:01:30/00:01:31, flags: PT
 Incoming interface: Tunnel0, RPF nbr 192.168.0.3
  Outgoing interface list: Null

(S,G) запись неактивна (флаг P) на Hub, соответственно, OIL пуст. Очевидно, что это дело рук Spoke1, больше некому.

Spoke1#sho ip mroute
<output omitted>
(*, 224.1.1.1), 00:52:44/stopped, RP 1.1.1.1, flags: SJCL
 Incoming interface: Tunnel0, RPF nbr 192.168.0.1
 Outgoing interface list:
  Loopback0, Forward/Sparse, 00:09:18/00:02:26
(3.3.3.3, 224.1.1.1), 00:01:39/00:01:20, flags: LJT
 Incoming interface: Tunnel0, RPF nbr 192.168.0.3
 Outgoing interface list:
   Loopback0, Forward/Sparse, 00:01:39/00:02:26

Вроде бы таблица правильная… Но нет: RPF сосед – Spoke 2, а должен быть Hub. Посмотрим внимательно на весь процесс ещё раз.

  1. Spoke2 отправляет первый пакет потока внутри RP-Register;
  2. Hub пересылает пакет Spoke1 и начинает построение SPT дерева в сторону Spoke2;
  3. Spoke1 получает первый пакет, создаёт новое состояние для потока в таблице маршрутизации, высылает ответ.
  4. Spoke1 осознаёт, что RPF сосед для источника мультикаста – это Spoke2, поэтому он отправляет SPT-Join в сторону Spoke2. Однако в силу NBMA поведения DMVPN, физически SPT-Join идёт в сторону Hub. Последний его с радостью отбрасывает, поскольку внутри пакета в качестве RPF соседа указан Spoke2.
  5. IIF для RPT и SPT один и тот же, Tunnel0, поэтому Spoke1 отправляет сообщение (*,G) Prune в сторону Hub, где он и обрабатывается.

В результате, Hub отключает у себя (*,G) запись, а Spoke1 не может завершить создание (S,G) записи в таблице маршрутизации, что приводит к нарушению связности между Spoke.Корень зла в этом случае – SPT-switchover: между Spoke нет прямой связности для мультикаста, единственный доступный путь – через Hub. В конце концов, мы пришли к команде, которая упоминается в Configuration Guide – ip pim spt-threshold infinity. Неужели теперь связность появится?

Spoke2#ping 224.1.1.1 so lo 0 rep 1000 Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 3.3.3.3
Reply to request 0 from 2.2.2.2, 112 ms
Reply to request 1 from 2.2.2.2, 84 ms
Reply to request 2 from 2.2.2.2, 76 ms
Reply to request 3 from 2.2.2.2, 80 ms
Reply to request 4 from 2.2.2.2, 52 ms
Reply to request 5 from 2.2.2.2, 48 ms

На данном этапе мультикаст работает, как и ожидалось вначале. Поток может быть передан в любом направлении (hub-spoke, spoke-spoke, spoke-hub), причём только в сторону тех Spoke, которые на него подписались. Стоит отметить, однако, что передача мультикаста напрямую между Spoke чревата повышением нагрузки на канал вследствие рассылки мультикаста внутри направленных пакетов; канал до Spoke на такую нагрузку, как правило, не рассчитан, что может привести как к проблемам с масштабированием решения, так и к ухудшению связности для существующих приложений.

В статье мы рассмотрели, что необходимо добавить к обычному DMVPN Phase 2, чтобы успешно запустить поверх него мультикаст. К тонким моментам можно отнести, пожалуй, только режим PIM NBMA и SPT-switchover – это единственное отличие от общеизвестных настроек DMVPN Phase 2.

ASUS AiMesh по проводам

Введение

Архитектура

Проводное подключение

Настройка коммутатора

Настройка AiMesh

Дополнительные параметры

Заключение

Введение

Технология AiMesh позволяет создать защищенную сеть Wi-Fi со стабильным сигналом, бесшовным роумингом между узлами и охватом помещений любого размера. Широкая функциональность, легкость использоваться и отсутствие компромиссов с точки зрения максимальной скорости и зоны действия – это идеальное решение Wi-Fi для вашего дома!

Именно таким описанием наградила компания ASUS свою технологию AiMesh, поддерживаемую большинством новых моделей беспроводных двухдиапазонных маршрутизаторов этого вендора. С помощью технологии AiMesh создаётся ячеистая беспроводная сеть. Клиентские устройства подключаются к узлу с наиболее высоким уровнем сигнала, а при перемещении клиентского оборудования внутри зоны покрытия происходит роуминг, то есть переподключение к другому узлу AiMesh.

Архитектура

Система состоит из беспроводного маршрутизатора AiMesh, который, по сути, является центральной точкой беспроводной сети, и одного или нескольких узлов AiMesh. По умолчанию, для связи между узлами AiMesh сети используется выделенный беспроводной канал, работающий на частоте 5 ГГц.

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

Приятной особенностью такой ячеистой сети стала поддержка функции самовосстановления. При выходе одного из узлов из строя, всё оборудование автоматически переподключится к функционирующим узлам.

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

Именно о проводном способе подключения узлов AiMesh к беспроводному маршрутизатору мы сегодня и поговорим.

Проводное подключение

Беспроводное подключение узлов AiMesh к центральному беспроводному маршрутизатору хорошо всем, кроме производительности. Да, модули 5 ГГц некоторых моделей маршрутизаторов вполне способны перешагнуть рубеж производительности в 1 Гбит/с. Но это верно лишь при определённых условиях. Взаимное расположение узлов вкупе с отсутствием прямой видимости между ними вполне могут в значительной степени снизить производительность беспроводных магистральных каналов. Снижения производительности каналов узел-маршрутизатор можно избежать при использовании кабельного подключения. В этом случае, как рекомендует производитель, необходимо соединять WAN-порт узла AiMesh с LAN-портом маршрутизатора AiMesh, как это показано на рисунке выше.

Но что делать, если такое прямое кабельное соединение невозможно? Казалось бы, выход есть и довольно простой – установить коммутатор между маршрутизатором и узлом AiMesh, то есть по сути подключить оба устройства к новой или уже существующей L2-сети, добавить их в один VLAN. Однако на практике всё оказывается не так просто.

Для взаимного обнаружения беспроводные устройства в сети AiMesh используют протокол LLDP. Этот протокол предназначен для обмена сообщениями о возможностях, поддерживаемых каждой из сторон. Обмен LLDP сообщениями возможен только с непосредственно подключённым соседним устройством, то есть маршрутизатор и узел AiMesh не будут видеть друг друга, но будут обмениваться сообщениями LLDP с коммутатором между ними.

switch#sho lld ne
Capability codes:
(R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
(W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other
Device ID Local Intf Hold-time Capability Port ID
Cat3750 Gi1/0/2 120 B,R Gi1/0/14
0015.176a.f39b Gi1/0/4 3601 0015.176a.f39b
RT-AX56U Gi1/0/5 20 B 04d9.f5b4.68a0
Total entries displayed: 3

К счастью, выход есть и из этой ситуации. Для проброса LLDP сообщений через коммутатор можно использовать технологию QinQ, позволяющую прозрачно туннелировать через L2-сеть сообщения нескольких служебных протоколов.

Настройка коммутатора

В нашем распоряжении был коммутатор Cisco Catalyst C3560CX-8XPD, поддерживающий технологию QinQ, а также беспроводные маршрутизаторы ASUS RT-AX88U и RT-AX56U. Начали мы с создания выделенной виртуальной сети для передачи данных AiMesh сети. Самый обычный VLAN без каких-либо вспомогательных настроек.

switch(config)#vla 17
switch(config-vlan)#name
switch(config-vlan)#name AiMesh
switch(config-vlan)#^Z
switch#

Затем мы настроили интерфейсы, к которым подключаются члены сети AiMesh. Настройка интерфейса не зависит от того, подключён к нему беспроводной маршрутизатор или узел AiMesh. Пояснения к командам даны непосредственно в листинге.

interface GigabitEthernet1/0/5
switchport access vlan 17
!Выбор виртуальной сети, по которой будут передаваться данные AiMesh.
switchport mode dot1q-tunnel
!Выбор режима работы интерфейса
l2protocol-tunnel lldp
!Список туннелируемых протоколов
no lldp transmit
no lldp receive
!Отключение приёма/передачи коммутатором сообщений LLDP.

Кроме туннелирования сообщений протокола LLDP наш коммутатор позволяет пересылать сообщения ещё нескольких протоколов, однако для работы AiMesh этого не требуется.

switch(config-if)#l2protocol-tunnel ?
cdp Cisco Discovery Protocol
drop-threshold Set drop threshold for protocol packets
lldp Link Layer Discovery Protocol
point-to-point point-to-point L2 Protocol
shutdown-threshold Set shutdown threshold for protocol packets
stp Spanning Tree Protocol
vtp Vlan Trunking Protocol

Мостовая таблица, соответствующая нашей виртуальной сети, будет содержать MAC-адреса как оборудования AiMesh, так и клиентских устройств.

switch#sho mac address-table int gi1/0/5
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
17 04d9.f5b4.68a0 DYNAMIC Gi1/0/5
17 d868.c310.f0f1 DYNAMIC Gi1/0/5
Total Mac Addresses for this criterion: 2

Со стороны беспроводных устройств, поддерживающих сеть AiMesh также требуется произвести незначительную настройку, к описанию которой мы и переходим.

Настройка AiMesh

Для каждого узла AiMesh необходимо выбрать способ подключения к беспроводному маршрутизатору AiMesh (опция «Приоритет подключения»).

Используемый в данный момент способ подключения узла к центральному маршрутизатору отображается также и в виде иконки в списке подключённых узлов AiMesh.

Всё. Настройка узлов беспроводной AiMesh сети на этом завершена.

Дополнительные параметры

Значительную часть настроек, относящихся к работе Wi-Fi модуля, беспроводной маршрутизатор AiMesh передаёт на рядовые узлы в процессе их подключения. Однако есть ряд опций, которые могут быть настроены индивидуально на каждом устройстве. К числу таких опций относится, например, работа светодиодных индикаторов на лицевой панели устройств, образующих AiMesh сеть.

Подключение к узлам AiMesh с помощью протоколов HTTP/HTTPS невозможно, поэтому единственным способом их настройки является протокол SSH (не рекомендованный производителем для рядовых пользователей). Выяснить IP-адрес узла AiMesh можно с помощью карточки узла AiMesh.

Для отключения световых индикаторов на лицевой панели используется параметр led_disable, задаваемый с помощью утилиты nvram, о которой мы уже рассказывали ранее.

admin@RT-AX58U-3F40:/# nvram
======== NVRAM CMDS ========
[set] : set name with value
[setflag] : set bit value
[unset] : remove nvram entry
[get] : get nvram value with name
[getflag] : get bit value
[show:dump:getall] : show all nvrams
[loadfile] : populate nvram value from files
[savefile] : save all nvram value to file
[kset] : set name with value in kernel nvram
[kunset] : remove nvram entry from kernel nvram
[kget] : get nvram value with name
[commit] : save nvram [optional] to restart wlan when following restart
[restart] : restart wlan
[save] : save all nvram value to file
[restore] : restore all nvram value from file
[erase] : erase nvram partition
[fb_save] : save the romfile for feedback
============================
admin@RT-AX58U-3F40:/# nvram show | grep led_disable
size: 67930 bytes (63142 left)
led_disable=0
admin@RT-AX58U-3F40:/# nvram set led_disable=1
admin@RT-AX58U-3F40:/# nvram get led_disable
1
admin@RT-AX58U-3F40:/# nvram commit

После того, как все необходимые настройки выполнены, необходимо перезагрузить AiMesh узел вручную, либо удалённо с помощью команды reboot.

Заключение

Конечно, мы понимаем, что описанное нами в статье коммутационное оборудование компании Cisco едва ли будет установлено у большинства пользователей дома. Однако если в сети используется управляемый коммутатор другого производителя, существует ненулевая вероятность поддержки им технологии QinQ, позволяющей в рамках отдельной виртуальной сети объединить несколько устройств AiMesh. Для большинства же пользователей установка коммутатора не потребуется, так как для построения небольшой AiMesh сети будет достаточно LAN-портов, которыми располагает AiMesh маршрутизатор (некоторые модели обладают восьмью LAN-портами).

Кроме того, хотелось бы отметить, что производитель также работает над исправлением проблемы. Вероятно, это будет достигнуто за счёт использования другого протокола обнаружения AiMesh соседей, либо модернизации существующего.

Введение

Внешний вид и аппаратная платформа

Обновление прошивки

Веб-интерфейс

Беспроводной контроллер

Командная строка

Тестирование

Заключение

Введение

Обычно на сайте нашей лаборатории появляются обзоры конкретного сетевого оборудования, определённых устройств, моделей. Изредка можно обнаружить статьи, посвящённые какой-либо технологии без привязки к производителю. Однако сегодня мы хотим немного отойти от привычных рамок и представить нашим читателям обзор беспроводного решения от компании Zyxel, включающего в себя несколько компонентов. Справедливости ради, стоит сказать, что мы не ограничивали себя каким-либо «решением под ключ», вместо этого было принято решение рассмотреть несколько устройств, работающих как по отдельности, так и в связке друг с другом.

Работу беспроводных сетей обеспечивает оборудование двух типов: точки доступа и беспроводные контроллеры. Конечно же, сюда можно отнести и поддерживающую проводную инфраструктуру, однако в этот раз мы решили практически не касаться данного вопроса. В нашем распоряжении были две точки доступа: Zyxel NWA5123-AC и WAC6103D-I, а также аппаратный брандмауэр Zyxel ZyWALL 310, который выполнял функции контроллера.

Итак, приступим!

Внешний вид и аппаратная платформа

Точка доступа Zyxel NWA5123-AC обладает белым пластиковым корпусом, габариты которого составляют 130x130x55 мм при массе всего 300 г. На верхней панели размещено название компании-производителя, а также светодиод, отображающий состояние устройства.

Консольный порт, интерфейс Gigabit Ethernet, разъём для подключения внешнего источника питания, наклейки с краткой информацией об устройстве, вентиляционная решётка, а также система крепления точки доступа к стене или потолку расположены на нижней панели.

Модель NWA5123-AC может работать как от внешнего блока питания (поставляется в комплекте), так и через PoE. Энергопотребление устройства составляет 9 Ватт.

Электронная начинка точки доступа Zyxel NWA5123-AC представлена двумя зелёными текстолитовыми платами, одна из которых выполняет функции беспроводного модуля. К сожалению, практически все интересующие нас компоненты скрыты под защитными экранами. Для обозрения доступен только контроллер PoE Texas Instruments TPS23756, а также два модуля флеш-памяти Macronix 25L12835F, объём каждого из которых составляет 16 Мбайт.

Точка доступа Zyxel WAC6103D-I выполнена в белом пластиковом корпусе, габариты которого составляют 204x192x35 мм при массе 445 г. Данную модель можно назвать по-настоящему тонкой.

На верхней панели расположены световые индикаторы состояния устройства целиком, а также проводных и беспроводных интерфейсов.

Вентиляционная решётка занимает значительную часть нижней поверхности точки доступа. Также здесь расположены небольшие наклейки с краткой информацией о модели и специальное крепление, позволяющее разместить точку доступа на стене или под потолком. В небольшом углублении размещаются два порта Gigabit Ethernet; аппаратный переключатель, позволяющий выбрать способ размещения; кнопка Reset для сброса пользовательских настроек и консольный порт. Питание точки доступа осуществляется только с помощью технологии Power over Ethernet, использование какого-либо иного блока питания не предусмотрено. Потребляемая мощность составляет 12.48 Ватт.

Аппаратная платформа представлена одной зелёной текстолитовой платой, основные элементы расположены с одной стороны. К сожалению, почти все чипы скрыты под защитными экранами. Для обозрения доступен только модуль флеш-памяти Micron Technologies 29F2G08ABAEA, объём которого составляет 256 Мбайт, и PoE-контроллер Texas Instruments TPS23756.

Мы не станем здесь разбирать аппаратные особенности брандмауэра ZyWALL 310, так как в данном случае это устройство выступает лишь как пример сетевого оборудования, на которое может быть возложена роль беспроводного контроллера. Единственное, что нас несколько смущает, так это то, что мы так и не нашли среди большого списка устройств с поддержкой роли WLC моделей, обладающих двумя блоками питания. Как нам кажется, корпоративные продукты, предназначенные для работы в крупных сетях, должны обладать такой опцией.

Обновление прошивки

Точки доступа моделей NWA5123-AC и WAC6103D-I могут работать в одном из двух режимов: самостоятельном или под управлением беспроводного контроллера. При работе в самостоятельном режиме обновление микропрограммного обеспечения производится с помощью вкладки «Firmware Package» пункта «File Manager» меню «MAINTENANCE». Весь процесс занимает порядка пяти минут и не требует от пользователя никакой специализированной квалификации.

Убедиться в успешном обновлении прошивки можно с помощью меню «DASHBOARD».

При построении корпоративной беспроводной сети без контроллера не обойтись. Когда точки доступа работают под управлением беспроводного контроллера, обновление их программного обеспечения также производится с помощью контроллера. Однако прежде чем переходить к рассмотрению процесса централизованного обновления прошивки на точках доступа, нам бы хотелось рассмотреть процедуру смены микропрограммного обеспечения на самом контроллере. В нашем случае функции WLC были возложены на брандмауэр Zyxel ZyWALL 310, поэтому обновлять мы будем именно его. Обновление контроллера необходимо не только для добавления новых опций, но также и для расширения списка поддерживаемых точек доступа.

Обновление прошивки ZyWALL 310 производится с помощью вкладки «Управление микропрограммой» пункта «Файловый менеджер» меню «ОБСЛУЖИВАНИЕ». Весь процесс занимает порядка пяти минут (без учёта времени, необходимого на загрузку файла с новой прошивкой из глобальной сети) и не требует от администратора никакой специализированной подготовки.

Справедливости ради, стоит отметить, что обновление ZyWALL 310 может происходить не только в полуавтоматическом, но и в полностью автоматическом режиме (по расписанию).

После того, как программное обеспечение самого контроллера было обновлено, можно обратиться ко вкладке «Микропрограмма» пункта «Управление точками доступа» группы «Беспроводная сеть» меню «КОНФИГУРАЦИЯ» для обновления прошивки на всех контролируемых точках доступа. Для успешной работы беспроводной сети требуется, чтобы все подконтрольные точки доступа имели одинаковую версию микропрограммного обеспечения. При обнаружении расхождений в установленных прошивках, контроллер самостоятельно произведёт обновление или возврат к предыдущей версии микропрограммного обеспечения.

Стоит также заметить, что компания Zyxel предлагает утилиту ZAC – Zyxel AP Configurator, позволяющую автоматизировать некоторые рутинные процессы обслуживания нескольких точек доступа в сети без контроллера.

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

Веб-интерфейс

Получить доступ к веб-интерфейсу точки доступа Zyxel NWA5123-AC можно с помощью любого современного браузера. Доступ осуществляется по протоколу HTTPS. Адрес по умолчанию – 192.168.1.2. При входе требуется ввести логин и пароль, равные по умолчанию admin/1234. Мы не станем подробно рассматривать все возможности веб-интерфейса устройства, однако остановимся на наиболее интересных.

После ввода корректных учётных данных пользователь попадает на стартовую страничку устройства (меню «Dashboard»), на которой содержится информация о самой точке доступа, операционной системе и сетевых интерфейсах. Администратор по своему желанию может включать или отключать вывод той или иной информации.

С помощью пункта «Network Status» меню «Monitor» администратор может получить информацию о параметрах работы сетевых интерфейсов точки доступа, а также просмотреть статистические данные.

С помощью пунктов группы «Wireless» меню «Monitor» администратор может просмотреть информацию о работе беспроводных модулей для обоих частотных диапазонов; выяснить, какие беспроводные клиенты подключены; изучить существующие WDS подключения; а также отобразить список подозрительных точек доступа.

Пункт «Log» содержит журнальную информацию о работе модели NWA5123-AC.

Управление IP-параметрами производится с помощью пункта «Network» меню «Configuration». Стоит отметить, что NWA5123-AC поддерживает не только IPv4, но также и IPv6. Также здесь можно выбрать способ поиска беспроводного контроллера.

В случае управления точками доступа с помощью беспроводного контроллера практически все параметры их функционирования задаются с его помощью. Однако при самостоятельной работе точек доступа, управление беспроводными параметрами производится при помощи пунктов группы «Wireless» меню «Configuration». Здесь администратор для каждого из частотных диапазонов может выбрать режим работы устройства (точка доступа, режим мониторинга, корневая точка доступа или повторитель), выбрать профиль радиомодуля, указать максимальную излучаемую мощность, настроить параметры балансировки нагрузки на точки доступа, а также выбрать доступный радиоканал.

Управление учётными записями пользователями, имеющими доступ к интерфейсу управления самой точкой доступа, производится с помощью пункта «User» группы «Object» меню «Configuration».

Чтобы изменить и создать профили работы беспроводных модулей, необходимо обратиться к пункту «AP Profile» той же группы.

Управление профилями работы устройства в режиме мониторинга производится с помощью пункта «MON Profile».

Настройки WDS профиля собраны в одноимённом пункте группы «Object».

Пункт «Certificate» предназначен для управления собственными и доверенными сертификатами.

Изменить имя точки доступа, настроить дату и время на устройстве, а также управлять параметрами работы протоколов HTTP(S), SSH, Telnet, FTP и SNMP можно с помощью пунктов группы «System».

Для изменения параметров сохранения и отправки журнальной информации необходимо обратиться к пунктам группы «Log & Report». За выбор сохраняемой информации отвечает пункт «Diagnostics» меню «Maintenance».

Изменить конфигурационные файлы, обновить прошивку, запустить выполнения скрипта можно с помощью вкладок пункта «File Manager» меню «Maintenance».

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

Выключение и перезагрузка модели NWA5123-AC производится с помощью одноимённых пунктов меню «Maintenance». Стоит отметить, что производитель настоятельно рекомендует программно выключать точки доступа перед тем, как отключить подачу питания на них.

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

В заключение стоит отметить, что веб-интерфейс точек доступа может незначительно отличаться, что связано с различием в наборе поддерживаемых функций. Так, например, модель WAC6103D-I обладает аппаратным переключателем, позволяющим выбрать место расположения точки доступа: на стене или на потолке. Соответствующая настройка присутствует также и в веб-интерфейсе обсуждаемой модели (вкладка «Antenna Switch» подпункта «Antenna» меню «MAINTENANCE»).

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

Беспроводной контроллер

Точки доступа Zyxel могут работать в двух режимах: standalone, то есть самостоятельно, без контроллера, и с централизованным управлением при помощи беспроводного контроллера. Соответствующая настройка доступна во вкладке «AC Discovery» пункта «Network» меню «CONFIGURATION».

Администратор может либо полностью отказаться от использования беспроводного контроллера, либо указать его вручную (основной и резервный). Допускается также автоматический поиск контроллера в сети, в этом случае точка доступа периодически выполняет широковещательную рассылку сообщений CAPWAP-control Discovery Request. Пример такого сообщения представлен ниже.

В нашем распоряжении был аппаратный брандмауэр Zyxel ZyWALL 310, позволяющий взять на себя роль беспроводного контроллера в сети. Мы не станем рассматривать никакие другие возможности данного устройства кроме тех, которые непосредственно относятся к управлению беспроводными устройствами.

Группа «Беспроводная сеть» меню «МОНИТОРИНГ» позволяет администратору получить информацию об обнаруженных точках доступа (как доверенных, так и не доверенных), количестве подключённых клиентских устройств, параметрах работы беспроводных интерфейсов, настроенных идентификаторах SSID.

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

При необходимости администратор может получить доступ к журнальной информации, хранящейся на каждой отдельно взятой точке с контроллера, для чего потребуется обратиться ко вкладке «Лог беспроводной сети» пункта «Лог» меню «МОНИТОРИНГ».

Управление подключённым беспроводным оборудованием производится с помощью пунктов группы «Беспроводная сеть» меню «КОНФИГУРАЦИЯ». Так, например, с помощью пункта «Контроллер» администратор может выбрать код страны, на территории которой производится развёртывание беспроводной сети, а также задать способ регистрации точек доступа на контроллере.

Вкладка «Список управляемых точек доступа» пункта «Управление точками доступа» позволяет отредактировать определённые параметры работы каждой точки доступа, перезагрузить оборудование, запустить динамический выбор каналов (DCS – Dynamic Channel Selection), включить или выключить светодиоды на лицевой панели точки доступа. С помощью контроллера допускается переопределить параметры мощности передатчика каждой из точек, значение SSID, настройки VLAN и физического порта, а также параметры работы световых индикаторов.

Здесь же стоит отметить, что точки доступа могут работать в одном из следующих режимов: Режим точки доступа, Режим мониторинга, Root AP и Repeater. Последние два используются при построении сетей ZyMesh. Точки доступа, имеющие проводное подключение к контроллеру, должны работать в режиме Root AP, для тех же, что не имеют прямого доступа к проводной части сети, следует выбирать режим Repeater.

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

Управлять большим количеством точек доступа будет гораздо удобнее, если предварительно сгруппировать их. Соответствующая настройка доступна во вкладке «Группа точек доступа».

Выбор прошивок, под управлением которых работают точки доступа, производится с помощью вкладки «Микропрограмма». Все подконтрольные точки доступа должны иметь одинаковую версию прошивки, чтобы контроллер мог управлять ими. К сожалению, у администратора нет возможности вручную выгрузить на контроллер новую прошивку для той или иной точки доступа, так как загрузка прошивок поддерживается только в автоматическом режиме и с сайта производителя.

Управление списками нелегальных и доверенных точек доступа производится с помощью пункта «Профили мониторинга».

В случае выхода точки доступа из строя, беспроводной контроллер может автоматически изменить параметры работы оставшихся устройств так, чтобы восстановить покрытие беспроводной сетью проблемной области. Для управления данной опцией предназначен пункт «Auto Healing».

Для управления системой позиционирования Ekahau RTLS (Real Time Location Service) необходимо обратиться к одноимённому пункту.

В заключение добавим, что для управления сетями ZyMesh необходимо обратиться к пункту «Профиль ZyMesh» группы «Объект» меню «КОНФИГУРАЦИЯ», а для управления беспроводными профилями придётся воспользоваться пунктом «Профили точек доступа» той же группы.

Приятной особенностью, обнаруженной нами при настройке профиля безопасности, стала поддержка быстрого роуминга в рамках стандарта IEEE 802.11r.

Напоследок хочется сделать одно очевидное заключение, что некоторые опции доступны для изменения как при работе точки доступа в самостоятельном режиме, так и под управлением контроллером. Например, речь идёт о выборе SSID или беспроводного канала. Однако ряд функций появляется лишь при выборе централизованного способа управления. К числу таких функций можно отнести опцию Auto Healing, позволяющую соседним точкам доступа попытаться заменить вышедшее из строя устройство.

На этом мы завершаем краткое рассмотрение возможностей по управлению беспроводной сетью с использованием контроллера и переходим к рассмотрению возможностей интерфейса командной строки.

Командная строка

Включение/отключение доступа к командной строке устройства производится с помощью подпунктов «SSH» и «TELNET» меню «CONFIGURATION» веб-интерфейса. SSH-доступ включён по умолчанию, тогда как поддержка протокола Telnet обычно отключена из соображений безопасности.

Стоит также отметить, что администратор может просмотреть те команды, которые будут добавлены в конфигурацию устройства после применения внесённых изменений.

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

***************** Warning **********************
* *
* Telnet service is not a secure service!! *
* Please use SSH service for remote management *
* *
************************************************
Welcome to WAC6100
Username: admin
Password:
Bad terminal type: "ansi". Will assume vt100.
Router>

apply
atse
clear
configure
copy
daily-report
debug
delete
diag Diagnostic
diaginfo
dir
disable
enable
exit
htm
interface
no
nslookup
packet-trace
ping
ping6
psm
reboot
release
rename
renew
run
setenv
show
shutdown
sshcon
telnet
test
tracepath
tracepath6
traceroute
traceroute6
wlan-report
write
Router>

Командная строка точек доступа Zyxel очень похожа на CLI Cisco, поэтому сетевым администраторам, знакомым с оборудованием указанного производителя, не составит труда разобраться в командном интерпретаторе Zyxel. Единственное, что нас смущало в начале, так это невозможность использования сокращённых версий команд, но к этому быстро привыкаешь, особенно учитывая возможность автоматического дописывания команды при нажатии клавиши Tab.

Router> ena
% Command not found
retval = -1
ERROR: Parse error/command not found!
Router> enable

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

С помощью вызова show interface all можно получить информацию о том, какими сетевыми интерфейсами обладает устройство и каково их состояние.

Router# show interface all
No. Name Status IP Address Mask IP Assignment
===============================================================================
2 lan Up 192.168.1.21 255.255.255.0 Static
3 wlan-1 n/a n/a n/a n/a
4 wlan-1-1 Up 0.0.0.0 0.0.0.0 static

Опции команды show capwap позволяют администратору изучить состояние связи точки доступа с беспроводным контроллером.

Router# show capwap
ap
bridge
fw-updating
vlan
Router# show capwap ap
ac-ip
discovery-type
idle
info
Router# show capwap ap info
;

|
Router# show capwap ap info
AC-IP 192.168.1.255
Fallback Disable
Fallback Interval 0
Discovery type Broadcast
SM-State DISC(2)
msg-buf-usage 0/10 (Usage/Max)
capwap-version 10003
Radio Number 2/4 (Usage/Max)
BSS Number 8/8 (Usage/Max)
IANA ID 037a
Description

Информацию о средней загрузке процессора точки доступа предоставляет команда show cpu status, тогда как для просмотра времени, прошедшего с последнего включения оборудования, придётся воспользоваться вызовом show system uptime.

Router# show cpu status
CPU utilization: 1 %
CPU utilization for 1 min: 1 %
CPU utilization for 5 min: 2 %
Router# show system uptime
system uptime: 00:39:20

Если устройство занято поиском поддельных (rogue) точек доступа, то информацию о работе данного механизма можно получить с помощью команды show rogue-ap detection info.

Router# show rogue-ap
containment
detection
Router# show rogue-ap detection
info
list
monitoring
status
Router# show rogue-ap detection info
;

|
Router# show rogue-ap detection info
rogue ap: 0
friendly ap: 0
adhoc: 0
unclassified ap: 0

Текущая конфигурация точки доступа может быть получена с помощью команды show running-config. Ниже предоставлена лишь малая часть конфигурации.

Router# show running-config
!
!
hybrid-mode standalone
!
hardware-watchdog-timer 10
!
software-watchdog-timer 300
!
interface-name ge1 ge1
!
interface-name br0 lan
!

Серийный номер устройства может быть получен удалённо из вывода команды show serial-number. В идентификации конкретной точки доступа на местности также может оказаться полезной команда led_locator, включающая специальный светодиод на лицевой панели устройства.

Router# show serial-number
serial number: S172L16141905
Router(config)# led_locator
blink-timer
off
on
Router(config)# led_locator blink-timer
<1..60>
Router(config)# led_locator blink-timer
Router(config)# show led_locator status
Locator LED Status : ON
Locator LED Time : 1
Locator LED Time Lease: 367

Выяснить открытые порты и установленные сессии поможет команда show socket.

Router# show socket open
No. Proto Local_Address Foreign_Address State
===============================================================================
1 tcp 127.0.0.1:6379 127.0.0.1:40195 ESTABLISHED
2 tcp 127.0.0.1:40196 127.0.0.1:6379 ESTABLISHED
3 tcp 127.0.0.1:40195 127.0.0.1:6379 ESTABLISHED
4 tcp 192.168.1.21:23 192.168.1.120:59163 ESTABLISHED
5 tcp 127.0.0.1:6379 127.0.0.1:40196 ESTABLISHED
6 tcp 127.0.0.1:6379 127.0.0.1:40193 ESTABLISHED
7 tcp 127.0.0.1:40193 127.0.0.1:6379 ESTABLISHED
8 udp 0.0.0.0:161 0.0.0.0:0
9 udp 0.0.0.0:43605 0.0.0.0:0
Router# show socket listen
No. Proto Local_Address Foreign_Address State
===============================================================================
1 tcp 0.0.0.0:80 0.0.0.0:0 LISTEN
2 tcp 127.0.0.1:50000 0.0.0.0:0 LISTEN
3 tcp 0.0.0.0:21 0.0.0.0:0 LISTEN
4 tcp 0.0.0.0:22 0.0.0.0:0 LISTEN
5 tcp 0.0.0.0:443 0.0.0.0:0 LISTEN
6 tcp 127.0.0.1:60000 0.0.0.0:0 LISTEN
7 tcp 127.0.0.1:60001 0.0.0.0:0 LISTEN
8 tcp 127.0.0.1:60002 0.0.0.0:0 LISTEN
9 tcp 127.0.0.1:60003 0.0.0.0:0 LISTEN
10 tcp 127.0.0.1:6379 0.0.0.0:0 LISTEN

Сведения о модели точки доступа и прошивке предоставляет команда show version.

Router# show version
Zyxel Communications Corp.
model : WAC6103D-I
firmware version: V5.10(AAXH.2)
BM version : V2.3
build date : 2017-10-02 05:59:08

Информацию о работе беспроводного модуля можно получить с помощью опций команды show wlan.

Router# show wlan
<slot1,...>
all Everything
channels
country-code
radio
Router# show wlan all
;

|
Router# show wlan all
slot: slot1
card: none
Role: ap
Profile: default
SSID_profile_1: default
SSID_profile_2:
SSID_profile_3:
SSID_profile_4:
SSID_profile_5:
SSID_profile_6:
SSID_profile_7:
SSID_profile_8:
SLOT_1_Output_power: 30dBm
Activate: yes
WDS_Role: none
WDS_Profile: default
WDS_uplink: auto
Antenna_Type: ceiling
slot: slot2
card: none
Role: ap
Profile: default2
SSID_profile_1: default
SSID_profile_2:
SSID_profile_3:
SSID_profile_4:
SSID_profile_5:
SSID_profile_6:
SSID_profile_7:
SSID_profile_8:
SLOT_2_Output_power: 30dBm
Activate: no
WDS_Role: none
WDS_Profile: default
WDS_uplink: auto
Antenna_Type: ceiling
Router# show wlan country-code
;

|
Router# show wlan country-code
Default Country Code : ED
Router# show wlan radio
% (after 'radio'): Parse error
retval = -1
ERROR: Parse error/command not found!
Router# show wlan radio
macaddr
Router# show wlan radio macaddr
;

|
Router# show wlan radio macaddr
slot1: B8:EC:A3:AC:5C:1A
slot2: B8:EC:A3:AC:5C:1B
Router# show wlan channels
11A
11G
Router# show wlan channels 11
11A 11G
Router# show wlan channels 11A
;

cw
|
Router# show wlan channels 11A
Available Channels: ED
No. Channel string
===============================================================================
1 36 36
2 40 40
3 44 44
4 48 48
5 52 52 - (DFS)
6 56 56 - (DFS)
7 60 60 - (DFS)
8 64 64 - (DFS)
9 100 100 - (DFS)
10 104 104 - (DFS)
11 108 108 - (DFS)
12 112 112 - (DFS)
13 116 116 - (DFS)
14 120 120 - (DFS)
15 124 124 - (DFS)
16 128 128 - (DFS)
17 132 132 - (DFS)
18 136 136 - (DFS)
19 140 140 - (DFS)
Router#

Полный список просмотровых команды представлен ниже.

Router# show

aaa
address-object
address-object-match
address6-object
antenna
app-watch-dog
apply
arp-table
arpseal
boot
bridge
ca
capwap
clock
comport
console Console
contingency-access
cpu
daily-report
dcs
description
dhcp6
diag-info
diaginfo
disk
dual-image
extension-slot
force-auth
fqdn
hardware-watchdog-timer
hybrid-mode
interface
interface-name
ip
ipv6
language
led
led_locator
led_suppress
load-balancing
lockout-users
logging
mac
manager
mem
ntp
object-group
periodically-collect-data
port
power
radius-server
ram-size
reference
report
rogue-ap
rtls
running-config
serial-number
session
slide-switch
snmp
snmp-server
socket
software-watchdog-timer
speed-test
sshcon
system
username
users
version
vlan
vrpt
web-auth
wireless-hal
wlan
wlan-l2isolation-profile
wlan-macfilter-profile
wlan-monitor-profile
wlan-monitor-profile-by-slot
wlan-radio-profile
wlan-radio-profile-by-slot
wlan-security-profile
wlan-ssid-profile
wlan-wds-profile
zon
zymesh-profile

Офисные точки доступа Zyxel могут работать в одном из двух режимов: самостоятельном (standalone) и под управлением беспроводным контроллером (managed). Переключение между режимами можно произвести с помощью команды hybrid-mode режима глобальной конфигурации. После изменения режима будет произведена автоматическая перезагрузка устройства.

Router(config)# hybrid-mode
managed
standalone

Как мы указывали ранее, беспроводная точка доступа Zyxel WAC6103D-I обладает программным и аппаратным переключателем, позволяющем в явном виде указать тип размещения устройства: на стене или на потолке. Управление данным переключателем, очевидно, может производиться не только с помощью веб-интерфейса.

Router(config)# antenna
config
sw-control
Router(config)# antenna sw-control
enable
Router(config)# antenna sw-control enable
;

|
Router(config)# antenna sw-control enable
Router(config)# antenna config
slot1
slot2
Router(config)# antenna config s
slot1 slot2
Router(config)# antenna config slot
slot1
slot2
Router(config)# antenna config slot1
chain3
Router(config)# antenna config slot1 chain3
ceiling
wall
Router(config)# antenna config slot1 chain3 wall
;

|
Router(config)# antenna config slot1 chain3 wall

В заключение нашего беглого обзора возможностей командной строки оконечного беспроводного оборудования Zyxel нам хотелось бы указать на две очевидные команды: reboot – перезагружает устройство, copy running-config startup-config – сохраняет введённые администратором изменения.

Тестирование

Традиционно данный раздел мы начинаем с измерения времени загрузки устройств, под которым понимается интервал времени с момента подачи питания на оборудование и до получения первого эхо-ответа по протоколу ICMP. Точка доступа Zyxel NWA5123-AC загружается за 65 секунд, тогда как на загрузку WAC6103D-I потребуется немногим больше времени – 68 секунд. Мы считаем это хорошим результатом. Также мы решили выяснить, за какое время точки доступа смогут не только загрузиться, но и успешно зарегистрироваться на контроллере. Регистрацию точек доступа мы отслеживали с помощью вкладки «Список точек доступа» пункта «Точки доступа» группы «Беспроводная сеть» меню «МОНИТОРИНГ». Модели NWA5123-AC требуется примерно 95 секунд для того, чтобы загрузиться и зарегистрироваться на беспроводном контроллере. Модель WAC6103D-I на ту же операцию затратит около 105 секунд. Таким образом получается, что процедура поиска контроллера и регистрации на нём занимает приблизительно 30-40 дополнительных секунд. На наш взгляд, это вполне достойный результат.

Беспроводное оборудование Zyxel поддерживает mesh-сети (функция ZyMesh). Мы решили выяснить, за какое время точка доступа модели NWA5123-AC загрузится, подключится к существующей беспроводной сети на базе контроллера ZyWAL 310 и корневой точки доступа WAC6103D-I. Весь процесс загрузки и ассоциации занял приблизительно 101 секунду (измерения производились по состоянию точки доступа в веб-интерфейсе контроллера), таким образом подключение к существующей сети ZyMesh из одного хопа занимает около 6 секунд.

Время, необходимое на загрузку беспроводного контроллера, будет зависеть от того, какое конкретно устройство играет роль WLC в сети. В нашем распоряжении был аппаратный брандмауэр Zyxel ZyWALL 310, на который в наших тестах и была возложена роль контроллера. Модель ZyWALL 310 в нашем случае загрузилась за 115 секунд (конечно же, мы понимаем, что указанное время зависит от версии прошивки и активированных сервисов).

Следующий не менее традиционный тест – проверка защищённости устройства, проводимый при помощи сканера сетевой безопасности Positive Technologies XSpider 7.8. При сканировании обеих точек доступа было обнаружено пять открытых портов: UDP-161 (SNMP), TCP-443 (HTTPS), TCP-22 (SSH), TCP-21 (FTP) и TCP-80 (HTTP). В обоих случаях сканер сетевой безопасности обнаруживал наличие общеизвестных учётных данных для протокола SNMP. К чести производителя стоит отметить, что администратор уведомляется об этом каждый раз при подключении к веб-интерфейсу точки доступа.

Однако то, что действительно вызывает опасения, тоже связано с поддержкой протокола SNMP, - это подозрения на множественные уязвимости в реализациях протокола. Стандартной рекомендацией в данном случае является отключение поддержки протокола SNMP первой версии.

Обе наши точки доступа (модели NWA5123-AC и WAC6103D-I) позволяют указать IP-адрес основного и резервного контроллеров в явном виде. Такая возможность окажется полезной в ситуации, когда управляющий интерфейс точек доступа и беспроводного контроллера расположены в разных сегментах сети, разных IP-подсетях. Мы решили проверить работоспособность данной опции, поэтому установили маршрутизатор между точками доступа и контроллером, после чего задали адрес контроллера для одной из них.

Тестирование показало, что точка доступа успешно зарегистрировалась на контроллере.

Очевидно, такое решение нельзя назвать масштабируемым, так как администратору бы пришлось настраивать каждую точку доступа вручную. К счастью, существует промышленное решение, которое мы также решили протестировать. Суть его заключается в том, чтобы сообщить точкам доступа адрес контроллера с помощью протокола DHCP. Мы перехватили сообщение DHCP Discover, отправляемое устройством, и обнаружили опцию №138 (CAPWAP Access Controllers) в списке запрашиваемых опций.

Мы добавили соответствующую настройку в конфигурацию нашего тестового DHCP-сервера и перезагрузили точку доступа.

switch#sho run | sec dhcp
ip dhcp excluded-address 192.168.20.1 192.168.20.199
ip dhcp pool test2
network 192.168.20.0 255.255.255.0
default-router 192.168.20.10
dns-server 8.8.8.8
option 138 ip 192.168.1.1

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

Одним из отличий между точками доступа, находящимися на тестировании в нашей лаборатории, является наличие внешнего блока питания. Так, например, модель NWA5123-AC обладает внешним блоком питания, тогда как для модели WAC6103D-I его использование не предусмотрено в принципе. Вне зависимости от модели оба устройства позволяют получать электроэнергию с помощью технологии PoE, для чего требуются либо специальные инжекторы, либо коммутатор с поддержкой соответствующей технологии. Более масштабируемым решением, очевидно, является использование коммутаторов с поддержкой стандартов IEEE 802.3af-2003 и IEEE 802.3at-2009. Листинг ниже представляет информацию о потреблении электроэнергии обеими точками доступа при незначительном пользовательском трафике.

switch#sho lldp neighbors
Capability codes:
(R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
(W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other
Device ID Local Intf Hold-time Capability Port ID
nwa5123-ac Gi1/0/3 120 B,W,R 1
wac6103d-i Gi1/0/5 120 B,W,R 1
Total entries displayed: 2
switch#sho power inline
Module Available Used Remaining
(Watts) (Watts) (Watts)
------ --------- -------- ---------
1 240.0 30.8 209.2
Interface Admin Oper Power Device Class Max
(Watts)
--------- ------ ---------- ------- ------------------- ----- ----
Gi1/0/1 auto off 0.0 n/a n/a 30.0
Gi1/0/2 auto off 0.0 n/a n/a 30.0
Gi1/0/3 auto on 15.4 Ieee PD 0 30.0
Gi1/0/4 auto off 0.0 n/a n/a 30.0
Gi1/0/5 auto on 15.4 Ieee PD 4 30.0
Gi1/0/6 auto off 0.0 n/a n/a 30.0
Te1/0/7 auto off 0.0 n/a n/a 30.0
Te1/0/8 auto off 0.0 n/a n/a 30.0
switch#sho power inline gi1/0/3 de
Interface: Gi1/0/3
Inline Power Mode: auto
Operational status: on
Device Detected: yes
Device Type: Ieee PD
IEEE Class: 0
Discovery mechanism used/configured: Unknown
Police: off
Power Allocated
Admin Value: 30.0
Power drawn from the source: 15.4
Power available to the device: 15.4
Actual consumption
Measured at the port: 3.2
Maximum Power drawn by the device since powered on: 4.5
Absent Counter: 0
Over Current Counter: 0
Short Current Counter: 0
Invalid Signature Counter: 0
Power Denied Counter: 0
Power Negotiation Used: None
LLDP Power Negotiation --Sent to PD-- --Rcvd from PD--
Power Type: - -
Power Source: - -
Power Priority: - -
Requested Power(W): - -
Allocated Power(W): - -
Four-Pair PoE Supported: No
Spare Pair Power Enabled: No
Four-Pair PD Architecture: N/A
switch#
switch#sho power inline gi1/0/5 de
Interface: Gi1/0/5
Inline Power Mode: auto
Operational status: on
Device Detected: yes
Device Type: Ieee PD
IEEE Class: 4
Discovery mechanism used/configured: Unknown
Police: off
Power Allocated
Admin Value: 30.0
Power drawn from the source: 15.4
Power available to the device: 15.4
Actual consumption
Measured at the port: 4.3
Maximum Power drawn by the device since powered on: 5.2
Absent Counter: 0
Over Current Counter: 0
Short Current Counter: 0
Invalid Signature Counter: 0
Power Denied Counter: 0
Power Negotiation Used: None
LLDP Power Negotiation --Sent to PD-- --Rcvd from PD--
Power Type: - -
Power Source: - -
Power Priority: - -
Requested Power(W): - -
Allocated Power(W): - -
Four-Pair PoE Supported: No
Spare Pair Power Enabled: No
Four-Pair PD Architecture: N/A
switch#

Также мы решили измерить температуру корпуса точек доступа в момент небольшой нагрузки на сеть. Оказалось, что температура корпуса модели NWA5123-AC составляла 35°С, тогда как температура корпуса WAC6103D-I равнялась 36°С при средней температуре воздуха в помещении около 25°С. Мы считаем нормальными полученные температурные показатели.

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

Компонент ПК Ноутбук
Материнская плата ASUS Maximus VIII Extreme ASUS M60J
Процессор Intel Core i7 7700K 4 ГГц Intel Core i7 720QM 1.6 ГГц 
Оперативная память DDR4-2133 Samsung 64 Гбайта DDR3 PC3-10700 SEC 16 Гбайт
Сетевая карта Intel PRO/1000 PT
ASUS PCE-AC88
Atheros AR8131
Zyxel NWD6605
Операционная система  Windows 7 x64 SP1 Rus Windows 7 x64 SP1 Rus 

 Свои измерения мы начали с модели NWA5123-AC, в качестве клиента использовалась беспроводная сетевая карта ASUS PCE-AC88. Измерения производились для обоих частотных диапазонов для одного, пяти и пятнадцати одновременных TCP-соединений. В качестве тестового инструмента мы использовали утилиту JPerf версии 2.0.2.

Подобные тесты мы произвели также для модели WAC6103D-I.

Мы повторили измерения производительности точки доступа WAC6103D-I, но в этот раз в качестве беспроводного клиента использовали сетевую карту с интерфейсом USB – Zyxel NWD6605. Результаты измерений представлены на диаграммах ниже.

Вернёмся теперь к тестам функциональности и проверим работу системы в режиме коммутации с помощью контроллера и при локальной коммутации. Напомним, что при использовании локальной коммутации точка доступа сразу же отправляет пользовательские данные в ту виртуальную сеть (VLAN), которая соответствует SSID пользователя. В противном же случае все данные инкапсулируются в CAPWAP и отправляются точкой в сторону контроллера, который затем уже самостоятельно пересылает фреймы в нужную виртуальную сеть. Но сначала создадим соответствующий SSID. С помощью вкладки «SSID» пункта «Профили точек доступа» группы «Объект» необходимо создать профиль безопасности, после чего осуществить его привязку к профилю SSID.

Обратите внимание на то, что выбор режима коммутации производится с помощью опции «Режим пересылки» при создании профиля SSID.

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

Следующий шаг, который должен быть выполнен, состоит в привязке профиля SSID к группе точек доступа и добавлении необходимых точек в группу. Соответствующая настройка доступна во вкладке «Группа точек доступа» пункта «Управление точками доступа» группы «Беспроводная сеть» меню «КОНФИГУРАЦИЯ».

Если все настройки были выполнены правильно, то в списке доступных для подключения сетей появится новая.

Итак, мы готовы осуществить тестовое подключение беспроводного клиента. Точки доступа соединены с портами Gi1/0/3 и Gi1/0/5 коммутатора, тогда как ZyWAL 310 подключен к интерфейсу Gi1/0/2. SSID fox соответствует виртуальной сети с VID 30. На нашем тестовом L3-коммутаторе мы создали SVI, соответствующий VLAN 30.

switch#sho vla bri
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Gi1/0/1, Gi1/0/4, Gi1/0/6, Te1/0/7, Te1/0/8, Te1/0/1, Te1/0/2
20 test active
30 SSID_fox active
1002 fddi-default act/unsup
1003 token-ring-default act/unsup
1004 fddinet-default act/unsup
1005 trnet-default act/unsup
switch#sho lldp ne
Capability codes:
(R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
(W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other
Device ID Local Intf Hold-time Capability Port ID
nwa5123-ac Gi1/0/3 120 B,W,R 1
wac6103d-i Gi1/0/5 120 B,W,R 1
Total entries displayed: 2
switch#sho int tru
Port Mode Encapsulation Status Native vlan
Gi1/0/2 on 802.1q trunking 1
Gi1/0/3 on 802.1q trunking 1
Gi1/0/5 on 802.1q trunking 1
Port Vlans allowed on trunk
Gi1/0/2 1-4094
Gi1/0/3 1-4094
Gi1/0/5 1-4094
Port Vlans allowed and active in management domain
Gi1/0/2 1,20,30
Gi1/0/3 1,20,30
Gi1/0/5 1,20,30
Port Vlans in spanning tree forwarding state and not pruned
Gi1/0/2 1,20,30
Gi1/0/3 1,20,30
Gi1/0/5 1,20,30
switch#sho ip int bri | e unas
Interface IP-Address OK? Method Status Protocol
Vlan1 192.168.1.10 YES NVRAM up up
Vlan20 192.168.20.10 YES NVRAM up up
Vlan30 192.168.30.10 YES manual up up
switch#sho ip dhcp pool SSID_fox
Pool SSID_fox :
Utilization mark (high/low) : 100 / 0
Subnet size (first/next) : 0 / 0
Total addresses : 254
Leased addresses : 0
Excluded addresses : 199
Pending event : none
1 subnet is currently in the pool :
Current index IP address range Leased/Excluded/Total
192.168.30.200 192.168.30.1 - 192.168.30.254 0 / 199 / 254

Условием успешного завершения данного теста будет появление доступа беспроводного клиента к VLAN 30, обнаружение MAC-адреса клиента на порту, к которому подключена одна из точек доступа.

Итак, мы осуществили подключение к обнаруженному SSID fox.

Убедимся в доступности SVI коммутатора с клиента.

C:\>ping 192.168.30.10
Pinging 192.168.30.10 with 32 bytes of data:
Reply from 192.168.30.10: bytes=32 time=4ms TTL=255
Reply from 192.168.30.10: bytes=32 time=3ms TTL=255
Reply from 192.168.30.10: bytes=32 time=3ms TTL=255
Reply from 192.168.30.10: bytes=32 time=3ms TTL=255
Ping statistics for 192.168.30.10:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 3ms, Maximum = 4ms, Average = 3ms

Теперь проверим, что MAC-адрес клиента виден через соответствующий интерфейс коммутатора.

switch#sho mac address-table dy vla 30
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
30 240a.6449.70af DYNAMIC Gi1/0/3
Total Mac Addresses for this criterion: 1

В качестве дополнительной проверки убеждаемся, что беспроводной клиент получил IP-параметры динамически с использованием DHCP-пула, сконфигурированного на нашем тестовом L3-коммутаторе.

C:\>ipconfig /all
Windows IP Configuration
Host Name . . . . . . . . . . . . : FOX
Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Mixed
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
Wireless LAN adapter Беспроводное сетевое соединение 5:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Broadcom 802.11ac Network Adapter
Physical Address. . . . . . . . . : 24-0A-64-49-70-AF
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::a861:9ebc:9e29:2e4e%38(Preferred)
IPv4 Address. . . . . . . . . . . : 192.168.30.200(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : 25 декабря 2017 г. 2:05:19
Lease Expires . . . . . . . . . . : 26 декабря 2017 г. 2:13:31
Default Gateway . . . . . . . . . : 192.168.30.10
DHCP Server . . . . . . . . . . . : 192.168.30.1
DHCPv6 IAID . . . . . . . . . . . : 707005028
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-14-F9-D5-EB-90-E6-BA-97-A9-30
DNS Servers . . . . . . . . . . . : 2001:470:1f1d:d01::1
8.8.8.8
NetBIOS over Tcpip. . . . . . . . : Enabled

Отключим теперь нашего тестового беспроводного клиента и произведём перенастройку нашей сети так, чтобы точки доступа пересылали трафик через туннель на беспроводной контроллер. Стоит, правда, отметить, что в данном случае виртуальная сеть, соответствующая нашему SSID, должна быть предварительно создана на ZyWAL 310.

Мы также решили предоставить нашим читателям схему пути следования данных при передаче трафика через беспроводной контроллер.

Убедимся теперь в доступности для клиента SVI-интерфейса коммутатора.

C:\>ping 192.168.30.10
Pinging 192.168.30.10 with 32 bytes of data:
Reply from 192.168.30.10: bytes=32 time=1ms TTL=255
Reply from 192.168.30.10: bytes=32 time=3ms TTL=255
Reply from 192.168.30.10: bytes=32 time=3ms TTL=255
Reply from 192.168.30.10: bytes=32 time=2ms TTL=255
Ping statistics for 192.168.30.10:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 3ms, Average = 2ms

Кроме того, чтобы признать тест полностью успешным, нам необходимо обнаружить MAC-адрес клиента на интерфейсе коммутатора, к которому подключен беспроводной контроллер.

switch#sho mac address-table | i 240a.6449.70af
30 240a.6449.70af DYNAMIC Gi1/0/2

Результаты эксперимента убедительно доказывают, что предлагаемое компанией Zyxel решение по организации беспроводных сетей успешно справляется как с локальной коммутацией, так и с передачей пользовательских данных через контроллер. В последнем случае у администратора появляются дополнительные возможности по фильтрации пользовательского трафика, так, например, его можно подвергнуть антивирусной проверке.

На этом мы завершаем тестирование беспроводного решения на базе оборудования компании Zyxel и переходим к подведению итогов.

Заключение

В целом мы остались довольны решением по организации беспроводных сетей, предлагаемым компанией Zyxel. В протестированном нами решении участвовали две точки доступа моделей NWA5123-AC и WAC6103D-I, а также беспроводной контроллер на базе брандмауэра ZyWALL 310. Судя по изменениям, вносимым в прошивки контроллеров и точек доступа, данное направление активно развивается компанией Zyxel, то есть, как нам кажется, стоит ожидать ещё больших улучшений и нововведений в ближайшее время.

Поддержка брандмауэрами и другими устройствами безопасности Zyxel функций беспроводного контроллера, как нам кажется, является хорошей идеей, так как в этом случае у администраторов появляется возможность производить фильтрацию даже локального трафика (при коммутации трафика с помощью контроллера/брандмауэра).

К сильным качествам отдельных моделей и решения целиком можно отнести следующее:

  • поддержка mesh-сетей;
  • возможность питания точек доступа с помощью PoE;
  • поддержка быстрого роуминга 802.11r;
  • большой ассортимент моделей точек доступа;
  • возможность возложить функции беспроводного контроллера не только на специализированные устройства, но, например, и на брандмауэры;
  • поддержка локальной коммутации точкой доступа, либо возможность отправки пользовательских данных на контроллер с помощью CAPWAP;
  • возможность автоматического обновления прошивки;
  • поддержка нескольких беспроводных контроллеров одновременно;
  • возможность поиска нелегитимных точек доступа в подконтрольной зоне;
  • наличие нескольких способов аутентификации и биллинга беспроводных пользователей;
  • возможность автоматизации некоторых рутинных процессов управления точками доступа без использования контроллера;
  • наличие программных инструментов, упрощающих процесс планирования беспроводной сети и её мониторинга.

К сожалению, мы не можем не указать и на обнаруженные недочёты:

  • не все беспроводные контроллеры на данный момент поддерживают работу со всеми моделями точек доступа (планируется к исправлению);
  • неправильные часовые пояса (исправлено в последних версиях прошивок);
  • подозрение на наличие уязвимостей в реализации протокола SNMPv1;
  • не самая высокая скорость передачи данных в беспроводном сегменте.

Нам хотелось бы дать небольшое пояснение касательно последнего пункта в списке. Результаты тестирования беспроводных сетей зависят от множества факторов: конфигурации помещения, используемого канала, наличия чужих беспроводных сетей и помех, не связанных с Wi-Fi.

На момент написания данного обзора средняя цена точки доступа NWA5123-AC в интернет-магазинах Москвы составляла 14325 рублей, тогда как модель WAC6103D-I стоила от 18200 рублей и выше. Цена на брандмауэр ZyWALL 310 начиналась от 77000 рублей без учёта дополнительных лицензий.

Введение

Конфигурация

Тестирование

Заключение

Введение

Постоянное развитие беспроводных сетей заставляет сетевых администраторов безостановочно модернизировать свои проводные сегменты, поддерживающие работу Wi-Fi. На сегодняшний день при использовании высокоскоростных точек доступа проводные интерфейсы коммутаторов доступа начинают становиться узким местом, ограничивая скорости передачи данных в беспроводном сегменте. Это кажется невероятным, но даже гигабитного интерфейса порой уже становится недостаточно. Однако переход к использованию сетей на базе 10GE не будет считаться оправданным в течение ещё долгого времени, так как пока скорости, предоставляемые Wi-Fi точками доступа, не планируют перешагнуть этот рубеж.

Предвидя осложнение ситуации в проводном сегменте в связи с появлением устройств с поддержкой 802.11AC Wave 2, компания Cisco Systems совместно с рядом других производителей основала в 2014 году альянс NBASE-T. Целью данной организации стала разработка стандартов Ethernet, позволяющих осуществлять передачу данных на скоростях 2,5 и 5 Гбит/с, используя существующую кабельную инфраструктуру категорий 5е и 6.

Чем же грозит сетевым администраторам появление устройств с поддержкой «второй волны» стандарта 802.11AC? Во-первых, произойдёт увеличение максимальных теоретических скоростей передачи данных до 6.8 Гбит/с. Конечно, это лишь теоретический максимум (реальные скорости окажутся традиционно в два раза ниже), к тому же достижимый лишь при использовании самых производительных клиентов, расположенных в непосредственной близости от точки доступа. Второе улучшение, предусмотренное в стандарте 802.11AC Wave 2, состоит в поддержке технологии MU-MIMO. Использование MU-MIMO позволит более эффективно распределять доступную полосу пропускания между несколькими беспроводными клиентами, работающими одновременно. Так, например, точка доступа с антенной конфигурацией 4x4 сможет обслуживать двух клиентов 2x2 одновременно, а не последовательно, как это было раньше.

Оба улучшения, доступные в 802.11AC Wave 2, приведут к значительно большей утилизации проводных сегментов сети. Именно для устранения узких мест в современных L2-сегментах и были разработаны стандарты NBASE-T, позволяющие с минимальными затратами подготовиться к внедрению беспроводного оборудования с поддержкой IEEE 802.11AC Wave 2. Кроме этого, в NBASE-T нельзя не отметить наличие поддержки технологии Power over Ethernet, позволяющей осуществлять удалённое питание точек доступа, камер видеонаблюдения и иного сетевого оборудования.

Сегодня в нашей тестовой лаборатории находится коммутатор Cisco Catalyst WS-C3560CX-8XPD-S (IOS версии 15.2(6)E), обладающий двумя мультигигабитными интерфейсами. Указанные интерфейсы поддерживают следующие скорости передачи: 100 Мбит/с, 1 Гбит/с, 2.5 Гбит/с, 5Гбит/с и 10 Гбит/с. Конечно же, два мультигигабитных порта – не единственные интерфейсы коммутатора. Модель 3560CX-8XPD оснащена также шестью портами Gigabit Ethernet, а также двумя разъёмами для модулей SFP+. Все восемь медных интерфейсов поддерживают передачу питания PoE+, энергетический бюджет коммутатора составляет 240 Вт.

Конфигурация

Коммутатор Cisco 3560CX-8XPD несёт на борту четыре интерфейса 10GE: Te1/0/1, Te1/0/2, Te1/0/7 и Te1/0/8, два последних как раз и обладают поддержкой NBASE-T.

fox_3560CX-8XPD#sho int status
Port Name Status Vlan Duplex Speed Type
Gi1/0/1 notconnect 1 auto auto 10/100/1000BaseTX
Gi1/0/2 notconnect 1 auto auto 10/100/1000BaseTX
Gi1/0/3 notconnect 1 auto auto 10/100/1000BaseTX
Gi1/0/4 notconnect 1 auto auto 10/100/1000BaseTX
Gi1/0/5 notconnect 1 auto auto 10/100/1000BaseTX
Gi1/0/6 notconnect 1 auto auto 10/100/1000BaseTX
Te1/0/7 connected 1 a-full 100 100/1G/2.5G/5G/10GBaseT
Te1/0/8 connected 1 a-full 100 100/1G/2.5G/5G/10GBaseT
Te1/0/1 notconnect 1 full 10G Not Present
Te1/0/2 notconnect 1 full 10G Not Present

Мультигигабитные интерфейсы не требуют какой-либо дополнительной конфигурации – даже скорость может быть определена автоматически.

fox_3560CX-8XPD(config)#int te1/0/7
fox_3560CX-8XPD(config-if)#?
Interface configuration commands:
aaa Authentication, Authorization and Accounting.
access-session Access Session specific Interface Configuration Commands
arp Set arp type (arpa, probe, snap) or timeout or log options
auto Configure Automation
auto Configure Automation
bandwidth Set bandwidth informational parameter
bfd BFD interface configuration commands
bgp-policy Apply policy propagated by bgp community string
carrier-delay Specify delay for interface transitions
cdp CDP interface subcommands
channel-group Etherchannel/port bundling configuration
channel-protocol Select the channel protocol (LACP, PAgP)
crypto Encryption/Decryption commands
cts Configure Cisco Trusted Security
dampening Enable event dampening
datalink Interface Datalink commands
default Set a command to its defaults
delay Specify interface throughput delay
description Interface specific description
downshift link downshift feature
exit Exit from interface configuration mode
flow-sampler Attach flow sampler to the interface
flowcontrol Configure flow operation.
help Description of the interactive help system
history Interface history histograms - 60 second, 60 minute and 72 hour
hold-queue Set hold queue depth
ip Interface Internet Protocol config commands
ipv6 IPv6 interface subcommands
isis IS-IS commands
iso-igrp ISO-IGRP interface subcommands
keepalive Enable keepalive
l2protocol-tunnel Tunnel Layer2 protocols
lacp LACP interface subcommands
link Interface link related commands
lldp LLDP interface subcommands
load-interval Specify interval for load calculation for an interface
location Interface location information
logging Configure logging for interface
mac MAC interface commands
macro Command macro
macsec Enable macsec on the interface
mdix Set Media Dependent Interface with Crossover
media-proxy Enable media proxy services
metadata Metadata Application
mka MACsec Key Agreement (MKA) interface configuration
mls mls interface commands
mvr MVR per port configuration
neighbor interface neighbor configuration mode commands
network-policy Network Policy
nmsp NMSP interface configuration
no Negate a command or set its defaults
onep Configure onep settings
ospfv3 OSPFv3 interface commands
pagp PAgP interface subcommands
power Power configuration
priority-queue Priority Queue
queue-set Choose a queue set for this queue
rep Resilient Ethernet Protocol characteristics
rmon Configure Remote Monitoring on an interface
routing Per-interface routing configuration
service-policy Configure CPL Service Policy
shutdown Shutdown the selected interface
small-frame Set rate limit parameters for small frame
snmp Modify SNMP interface parameters
source Get config from another source
spanning-tree Spanning Tree Subsystem
speed Configure speed operation.
srr-queue Configure shaped round-robin transmit queues
storm-control storm configuration
subscriber Subscriber inactivity timeout value.
switchport Set switching mode characteristics
timeout Define timeout values for this interface
topology Configure routing topology on the interface
transmit-interface Assign a transmit interface to a receive-only interface
tx-ring-limit Configure PA level transmit ring limit
udld Configure UDLD enabled or disabled and ignore global UDLD setting
vtp Enable VTP on this interface
fox_3560CX-8XPD(config-if)#speed ?
100 Force 100 Mbps operation
1000 Force 1000 Mbps operation
10000 Force 10000 Mbps operation
2500 Force 2500 Mbps operation
5000 Force 5000 Mbps operation
auto Enable AUTO speed configuration

Настройка дуплекса для портов NBASE-T отсутствует.

fox_3560CX-8XPD(config)#int gi1/0/1
fox_3560CX-8XPD(config-if)#du ?
auto Enable AUTO duplex configuration
full Force full duplex operation
half Force half-duplex operation
fox_3560CX-8XPD(config-if)#int te1/0/7
fox_3560CX-8XPD(config-if)#du ?
% Unrecognized command

Что же касается работы функции Auto MDI/MDIX, то в данном коммутаторе определение использованного кабеля производится вне зависимости от скорости, на которой функционирует интерфейс.

При использовании автоматического согласования скорости администратор может в явном виде указать, какие скорости допустимы для согласования. Справедливости ради, стоит отметить, что аналогичная настройка доступна и для гигабитных интерфейсов тоже.

fox_3560CX-8XPD(config-if)#spe au ?
100 Include 100 Mbps in auto-negotiation advertisement
1000 Include 1000 Mbps in auto-negotiation advertisement
10000 Include 10000 Mbps in auto-negotiation advertisement
2500 Include 2500 Mbps in auto-negotiation advertisement
5000 Include 5000 Mbps in auto-negotiation advertisement

Мы соединили патч-кордом интерфейсы Te1/0/7 и Te1/0/8 между собой. Вывод некоторых диагностических команд представлен ниже.

fox_3560CX-8XPD#sho run int te1/0/7
Building configuration...
Current configuration : 59 bytes
!
interface TenGigabitEthernet1/0/7
load-interval 30
end
fox_3560CX-8XPD#sho run int te1/0/8
Building configuration...
Current configuration : 71 bytes
!
interface TenGigabitEthernet1/0/8
load-interval 30
speed 5000
end
fox_3560CX-8XPD#sho int status
Port Name Status Vlan Duplex Speed Type
Gi1/0/1 notconnect 1 auto auto 10/100/1000BaseTX
Gi1/0/2 notconnect 1 auto auto 10/100/1000BaseTX
Gi1/0/3 notconnect 1 auto auto 10/100/1000BaseTX
Gi1/0/4 notconnect 1 auto auto 10/100/1000BaseTX
Gi1/0/5 notconnect 1 auto auto 10/100/1000BaseTX
Gi1/0/6 notconnect 1 auto auto 10/100/1000BaseTX
Te1/0/7 connected 1 a-full a-5000 100/1G/2.5G/5G/10GBaseT
Te1/0/8 connected 1 a-full 5000 100/1G/2.5G/5G/10GBaseT
Te1/0/1 notconnect 1 full 10G Not Present
Te1/0/2 notconnect 1 full 10G Not Present
fox_3560CX-8XPD#sho int te1/0/7
TenGigabitEthernet1/0/7 is up, line protocol is up (connected)
Hardware is Ten Gigabit Ethernet, address is 9c57.adb0.3487 (bia 9c57.adb0.3487)
MTU 1500 bytes, BW 5000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 5000Mb/s, media type is 100/1G/2.5G/5G/10GBaseT
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:01, output 00:00:01, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
30 second input rate 0 bits/sec, 0 packets/sec
30 second output rate 1000 bits/sec, 1 packets/sec
538 packets input, 102715 bytes, 0 no buffer
Received 325 broadcasts (325 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 325 multicast, 0 pause input
0 input packets with dribble condition detected
1622 packets output, 172091 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
fox_3560CX-8XPD#sho int te1/0/8
TenGigabitEthernet1/0/8 is up, line protocol is up (connected)
Hardware is Ten Gigabit Ethernet, address is 9c57.adb0.3488 (bia 9c57.adb0.3488)
MTU 1500 bytes, BW 5000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 5000Mb/s, media type is 100/1G/2.5G/5G/10GBaseT
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:01, output 00:00:09, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
30 second input rate 0 bits/sec, 0 packets/sec
30 second output rate 0 bits/sec, 0 packets/sec
1626 packets input, 172811 bytes, 0 no buffer
Received 1413 broadcasts (1397 multicasts)
0 runts, 0 giants, 0 throttles
4 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 1397 multicast, 0 pause input
0 input packets with dribble condition detected
561 packets output, 104187 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
fox_3560CX-8XPD#

Перед тем как непосредственно перейти к нагрузочному тестированию, мы решили подключить точку доступа с поддержкой PoE к интерфейсу Te1/0/7 и предоставить нашим читателям некоторую диагностическую информацию.

fox_3560CX-8XPD#sho power inline tenGigabitEthernet 1/0/7
Interface Admin Oper Power Device Class Max
(Watts)
--------- ------ ---------- ------- ------------------- ----- ----
Te1/0/7 auto on 15.4 Ieee PD 4 30.0
Interface AdminPowerMax AdminConsumption
(Watts) (Watts)
---------- --------------- --------------------
Te1/0/7 30.0 15.4
fox_3560CX-8XPD#sho lldp ne de
fox_3560CX-8XPD#sho lldp ne detail
------------------------------------------------
Local Intf: Te1/0/7
Chassis id: b8ec.a3ac.5c19
Port id: 1
Port Description: UPLINK
System Name: WAC6103D-I
System Description:
Linux
Time remaining: 118 seconds
System Capabilities: B,W,R
Enabled Capabilities: B,W,R
Management Addresses:
IP: 192.168.1.2
Auto Negotiation - not supported
Physical media capabilities - not advertised
Media Attachment Unit type - not advertised
Vlan ID: - not advertised
Total entries displayed: 1
fox_3560CX-8XPD(config)#int te1/0/7
fox_3560CX-8XPD(config-if)#po
fox_3560CX-8XPD(config-if)#power ?
inline Inline power configuration
fox_3560CX-8XPD(config-if)#power i
fox_3560CX-8XPD(config-if)#power inline ?
auto Automatically detect and power inline devices
consumption Configure the inline device consumption
never Never apply inline power
police Police the power drawn on the port
port Configure Port Power Level
static High priority inline power interface

На этом раздел, посвящённый конфигурированию мультигигабитных интерфейсов, подошёл к концу.

Тестирование

В данном разделе мы хотим предоставить нашим читателям результаты тестов производительности коммутатора не только при использовании мультигигабитных интерфейсов, но и «стандартных» портов. В качестве трафик-генератора использовался программно-аппаратный комплекс IXIA. Начать мы решили с измерения производительности (полоса пропускания, задержка и джиттер) модели 3560CX-8XPD, выполняющей коммутацию с использованием интерфейсов Gigabit Ethernet. Измерения производились для фреймов различной длины. Во время проведения данных тестов мы не фиксировали потери пакетов (исключая тест маршрутизации IPv6), поэтому данный график мы решили не включать в статью.

Поскольку модель Cisco Catalyst 3560CX-8XPD обладает возможностью выполнять не только коммутацию Ethernet-кадров, но маршрутизацию IP-пакетов, мы решили не оставлять данную функциональность без внимания.

Как видно из приведённых выше графиков, производительность устройства практически не отличается как при выполнении функций L2, так и L3.

Следующим этапом стало измерение производительности коммутатора при подключении к его оптическим портам 10GE также в L2 и L3 режимах.

 

 

 

Тестируемый коммутатор может выполнять не только маршрутизацию трафика IPv4, но также и IPv6. Естественно, мы не оставили без внимания такую возможность.

Здесь стоит отметить, что при маршрутизации пакетов, размер которых составлял 72 байта, наблюдались потери пакетов 0.029%. Величина потерь невелика, однако мы всё равно посчитали необходимым упомянуть об этом.

Мы подошли, пожалуй, к самой интересной части данного раздела – измерению производительности коммутатора при использовании портов NBASE-T. Трафик-генератор подключался к оптическим интерфейсам коммутатора (10GE). Мультигигабитные интерфейсы были соединены друг с другом с помощью патч-корда длиной 0.5 метра. На графиках ниже представлены значения скорости, задержки и джиттера для всех поддерживаемых интерфейсами скоростей. При построении графиков зависимости задержки от размера пакетов мы, естественно, учитывали, что в данной схеме фреймы проходят коммутатор дважды.

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

На этом мы завершаем раздел тестирования и переходим к подведению итогов.

Заключение

В данной статье мы рассмотрели медные мультигигабитные интерфейсы на примере компактного коммутатора Cisco Catalyst 3560CX-8XPD, обладающего двумя портами с поддержкой NBASE-T. Использование портов NBASE-T позволит с минимальными затратами обновить существующие проводные сегменты сети и подготовиться к развёртыванию беспроводных сетей следующего поколения IEEE 802.11AC Wave 2. Использование NBASE-T позволяет значительно увеличить производительность проводных сегментов без замены кабельной инфраструктуры. Поддержка мультигигабитными интерфейсами также и «стандартных» скоростей 1GE и 10GE позволит осуществить замену оборудования максимально плавно и последовательно.

Стоит также заметить, что появление новых стандартов с «промежуточными» скоростями произошло не только в мире медных сетевых интерфейсов с разъёмами RJ45 (8P8C), но также и в сегменте оптических сетей. Примером может служить коммутатор Cisco Nexus 3232C с высокой плотностью портов, несущий на борту 32 фиксированных 100GE интерфейса формата QSFP28, что позволяет обеспечить поддержку следующих скоростей оптических интерфейсов: 10G/25G/40G/50G/100G. Однако это уже совсем другая история.