Articles
Сигнализация PIM
Введение
У крупных корпоративных клиентов периодически появляется желание передавать групповой трафик (multicast) не только внутри своих сетей в крупных офисах и дата-центрах, но также и между ними. Операторам связи приходится решать поставленные перед ними задачи по обеспечению доставки таких пакетов между точками присутствия клиентов.
Среди наиболее распространённых способов передачи группового трафика в MPLS-сетях можно отметить несколько: Rosen и mLDP, RSVP и head-end replication, например, в EVPN; в данной статье мы сосредоточимся на одном из них – Rosen (по фамилии одного из авторов RFC).
При передаче multicast-трафика в Rosen режиме между двумя PE маршрутизаторами (Provider Edge) устанавливается специальный GRE-туннель, по которому и передаются групповые пакеты. Стоит отметить, что underlay сеть может быть как с настоящей поддержкой multicast, так и с его эмуляцией (например, в сетях DMVPN, то есть при использовании 2547oDMVPN).
Сигнализация при этом может быть на основе различных протоколов: PIM, mLDP, BGP. Разберёмся, что происходит в сети, когда для сигнализации используется протокол PIM SM (Profile 0 Default MDT - GRE - PIM C-mcast Signaling).
Топология
Чтобы упростить себе задачу, рассмотрим underlay сеть безо всяких дополнительных туннельных протоколов, например, DMVPN.
В MPLS-сеть провайдера входят следующие устройства: PE1, P1, P2 и PE2. Назначение маршрутизатора понятно из его названия. В качестве платформы для эмуляции операторского оборудования был выбран виртуальный маршрутизатор Cisco CSR1000v, на который установлена последняя версия программного обеспечения (IOS-XE линейки 17.3). Клиентское оборудование представлено маршрутизаторами Cisco серии 7200 (IOS версии 15.2). Единственное, что стоит упомянуть отдельно – устройства Sender и Receiver. В данной статье в качестве отправителя и получателя группового трафика мы использовали маршрутизаторы, естественно, что в реальной сети для этих целей будут применяться настоящие рабочие станции, серверы, медиа-плееры.
Underlay
Под underlay сетью в данном случае мы будем понимать инфраструктуру провайдера. В сети оператора мы использовали следующие протоколы: OSPF и LDP.
PE1#sho run | s r o
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
mpls ldp autoconfig
PE1#sho mpls ldp neighbor
Peer LDP Ident: 1.1.1.1:0; Local LDP Ident 3.3.3.3:0
TCP connection: 1.1.1.1.646 - 3.3.3.3.35398
State: Oper; Msgs sent/rcvd: 70/72; Downstream
Up time: 00:53:14
LDP discovery sources:
GigabitEthernet2, Src IP addr: 172.16.0.2
Addresses bound to peer LDP Ident:
172.16.1.1 172.16.0.2 1.1.1.1
PE1#sho mpl fo
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
16 Pop Label 1.1.1.1/32 0 Gi2 172.16.0.2
17 16 2.2.2.2/32 0 Gi2 172.16.0.2
18 Pop Label 172.16.1.0/24 0 Gi2 172.16.0.2
19 17 172.16.2.0/24 0 Gi2 172.16.0.2
20 19 4.4.4.4/32 0 Gi2 172.16.0.2
Также в underlay сети присутствует поддержка multicast-трафика. Для сигнализации используется PIM sparse-mode. На ряде линеек устройств компании Cisco маршрутизация multicast-трафика по умолчанию отключена, поэтому кроме включения протокола PIM на всех нужных интерфейсах необходимо также включить маршрутизацию multicast-пакетов. В качестве Rendezvous Point (RP) был выбран маршрутизатор PE1, информация о котором по сети распространяется с помощью стандартного протокола автоматического выбора RP - BootStrap Router (BSR).
PE1(config)#ip multicast-routing distributed
PE1(config)#^Z
PE1#sho ip pim interface
Address Interface Ver/ Nbr Query DR DR
Mode Count Intvl Prior
3.3.3.3 Loopback0 v2/S 0 30 1 3.3.3.3
172.16.0.1 GigabitEthernet2 v2/S 1 30 1 172.16.0.2
PE1#sho run | i candi
ip pim bsr-candidate Loopback0 0
ip pim rp-candidate Loopback0
Убедимся, что на маршрутизаторе PE2 присутствует вся необходимая информация для работы с multicast в сети провайдера: обнаружены PIM-соседи, получена информация об адресе RP.
PE2#sho ip pim nei
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
P - Proxy Capable, S - State Refresh Capable, G - GenID Capable,
L - DR Load-balancing Capable
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
172.16.2.1 GigabitEthernet2 00:06:04/00:01:36 v2 1 / S P G
PE2#sho ip pim rp map
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 3.3.3.3 (?), v2
Info source: 3.3.3.3 (?), via bootstrap, priority 0, holdtime 150
Uptime: 00:45:18, expires: 00:01:36
Мы решили снять дамп на линке P1-P2 и найти в нём сообщение, с помощью которого маршрутизатор PE1 анонсирует себя в качестве кандидата на роли BSR и RP.
Unicast overlay
Для обработки пользовательского трафика был создан VRF A. За передачу маршрутной информации между PE1 и PE2 отвечает протокол MP-BGP. Обмен маршрутами с пользовательскими маршрутизаторами CE1 и CE2 производится с помощью протокола OSPF.
PE1#sho run | s r b
router bgp 1
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 4.4.4.4 remote-as 1
neighbor 4.4.4.4 update-source Loopback0
!
address-family ipv4
exit-address-family
!
address-family vpnv4
neighbor 4.4.4.4 activate
neighbor 4.4.4.4 send-community extended
exit-address-family
!
address-family ipv4 vrf A
redistribute ospf 2 match internal external 2
exit-address-family
PE1#sho run | s r ospf 2
router ospf 2 vrf A
capability vrf-lite
redistribute bgp 1
network 0.0.0.0 255.255.255.255 area 0
Распространение сервисных MPLS-меток производится с помощью протокола MP-BGP (address-family vpnv4).
PE1#sho bgp vpnv4 unicast vrf A labels
Network Next Hop In label/Out label
Route Distinguisher: 1:1 (A)
5.5.5.5/32 192.168.0.2 22/nolabel
6.6.6.6/32 4.4.4.4 nolabel/22
10.0.0.0/24 192.168.0.2 23/nolabel
10.0.1.0/24 4.4.4.4 nolabel/23
192.168.0.0 0.0.0.0 21/nolabel(A)
192.168.1.0 4.4.4.4 nolabel/21
Несложно убедиться в том, что пользовательские маршрутизаторы обладают всеми необходимыми префиксами.
CE1#sho ip ro
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is not set
5.0.0.0/32 is subnetted, 1 subnets
C 5.5.5.5 is directly connected, Loopback0
6.0.0.0/32 is subnetted, 1 subnets
O E2 6.6.6.6 [110/1] via 192.168.0.1, 00:43:33, GigabitEthernet0/0
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
C 10.0.0.0/24 is directly connected, GigabitEthernet1/0
L 10.0.0.1/32 is directly connected, GigabitEthernet1/0
O E2 10.0.1.0/24 [110/1] via 192.168.0.1, 00:43:33, GigabitEthernet0/0
192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.0.0/24 is directly connected, GigabitEthernet0/0
L 192.168.0.2/32 is directly connected, GigabitEthernet0/0
O E2 192.168.1.0/24 [110/1] via 192.168.0.1, 00:43:33, GigabitEthernet0/0
Так как устройства Sender и Receiver имитируют хосты, то никакой динамической маршрутизации на них не используется.
Receiver#sho ip ro
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is 10.0.1.1 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via 10.0.1.1
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.1.0/24 is directly connected, GigabitEthernet1/0
L 10.0.1.2/32 is directly connected, GigabitEthernet1/0
Узлы Sender и Receiver успешно обмениваются данными.
Receiver#ping 10.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/32/44 ms
Мы перехватили одно из указанных ICMP-сообщений на линке P1-P2.
Обратите внимание на наличие обеих MPLS-меток у пакета: сервисной и транспортной.
Multicast overlay
Функции Rendezvous Point для VRF A мы решили возложить на клиентское оборудование, то есть маршрутизатор CE1 будет объявлять себя как C-RP и C-BSR.
CE1#sho run | i candi
ip pim bsr-candidate Loopback0 0
ip pim rp-candidate Loopback0
CE1#sho ip pim rp map
PIM Group-to-RP Mappings
This system is a candidate RP (v2)
This system is the Bootstrap Router (v2)
Group(s) 224.0.0.0/4
RP 5.5.5.5 (?), v2
Info source: 5.5.5.5 (?), via bootstrap, priority 0, holdtime 150
Uptime: 00:55:21, expires: 00:02:06
В сети провайдера нужно обязательно включить поддержку multicast-маршрутизации не только глобально, но ещё и для VRF A.
PE1(config)#ip multicast-routing vrf A distributed
Но и это ещё не всё. Каждый vrf должен быть настроен на использование уникальных multicast-групп для передачи пользовательского трафика с помощью команд mdt default и mdt data. Последняя команда опциональна.
PE1#sho run vrf | s def
vrf definition a
rd 1:1
route-target export 1:1
route-target import 1:1
!
address-family ipv4
mdt default 239.1.1.1
mdt data 239.1.2.0 0.0.0.255 threshold 1
mdt data threshold 1
exit-address-family
По умолчанию весь трафик передаётся с помощью группы, указанной в команде mdt default, однако если скорость передачи трафика превышает некоторый предел, заданный с помощью опции threshold, то данный поток пользовательского трафика переводится в одну из data-групп.
После того, как мы осуществили привязку default-группы к VRF, все PE-маршрутизаторы автоматически подписываются на эту группу и пытаются обнаружить PIM-соседей в overlay-сети.
Это очень интересный и показательный пакет, который мы перехватили в сети провайдера. Он отправляется маршрутизатором PE2 в сторону устройства, выполняющего функции RP в underlay-сети. Это unicast-пакет, поэтому к нему стандартным образом добавляется транспортная MPLS-метка. Внутри этого IPv4-пакета расположено сообщение Register протокола PIM. То есть маршрутизатор PE2 пытается переслать некоторый multicast-пакет в сторону RP пока ещё нет никакой подписки со стороны RP. Всё как и в случае обычной групповой рассылки. Но что это за IP-пакет, который PE2 хочет доставить до PE1? А это ни много ни мало рассылка для группы 239.1.1.1, которая у нас была объявлена как mdt default для VRF A. Производим декапсуляцию дальше: GRE заголовок и потом снова IPv4. Это уже попытка роутера PE2 внутри VRF A обнаружить PIM-соседей (судя по адресу получателя 224.0.0.13) при помощи сообщения PIM Hello.
В результате мы видим, что все PIM-маршрутизаторы внутри VRF A обнаружены, и соседство с ними установлено.
PE2#sho ip pim vrf a neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
P - Proxy Capable, S - State Refresh Capable, G - GenID Capable,
L - DR Load-balancing Capable
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
3.3.3.3 Tunnel1 00:06:31/00:01:38 v2 1 / S P G
192.168.1.2 GigabitEthernet1 00:03:28/00:01:43 v2 1 / DR S P G
На какие же группы и каких отправителей теперь подписан маршрутизатор PE2? То есть маршрутизатор PE2 заинтересован в получении трафика группы 239.1.1.1, настроенной как mdt default.
PE2#sho ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
x - VxLAN group, c - PFP-SA cache created entry,
* - determined by Assert, # - iif-starg configured on rpf intf,
e - encap-helper tunnel flag
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.1.1.1), 01:09:41/stopped, RP 3.3.3.3, flags: SJCFZ
Incoming interface: GigabitEthernet2, RPF nbr 172.16.2.1
Outgoing interface list:
MVRF a, Forward/Sparse, 01:09:41/00:02:18
(3.3.3.3, 239.1.1.1), 01:09:41/00:01:13, flags: JTZ
Incoming interface: GigabitEthernet2, RPF nbr 172.16.2.1
Outgoing interface list:
MVRF a, Forward/Sparse, 01:09:41/00:02:18
(4.4.4.4, 239.1.1.1), 01:09:41/00:03:13, flags: FT
Incoming interface: Loopback0, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet2, Forward/Sparse, 01:09:41/00:02:38
(*, 224.0.1.40), 01:26:41/00:02:22, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Loopback0, Forward/Sparse, 01:26:39/00:02:22
На данный момент сеть готова к передаче пользовательского multicast-трафика.
С помощью протокола IGMP подпишемся на группу 239.7.7.7 с устройства Receiver.
Receiver#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Receiver(config)#int gi1/0
Receiver(config-if)#ip igmp jo 239.7.7.7
На изображении ниже видно соответствующее сообщение протокола IGMP (Membership Report), которое отправлено с маршрутизатора Receiver. Конечные узлы ничего не знают о том, как реализована поддержка multicast в сети оператора, и используют стандартные IGMP сообщения Membership Report.
Убедимся в успешности подписки конечного узла на маршрутизаторе CE2.
CE2#sho ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter Group Accounted
239.7.7.7 GigabitEthernet1/0 00:03:49 00:02:37 10.0.1.2
224.0.1.40 GigabitEthernet0/0 01:43:29 00:02:55 192.168.1.1
224.0.1.40 Loopback0 01:43:36 00:02:27 6.6.6.6
Убедимся, что все пользовательские подписки были продублированы маршрутизатором CE2 в сторону оборудования провайдера по протоколу PIM.
PE2#sho ip mroute vrf a
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
x - VxLAN group, c - PFP-SA cache created entry,
* - determined by Assert, # - iif-starg configured on rpf intf,
e - encap-helper tunnel flag
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.7.7.7), 00:05:12/00:03:12, RP 5.5.5.5, flags: S
Incoming interface: Tunnel1, RPF nbr 3.3.3.3
Outgoing interface list:
GigabitEthernet1, Forward/Sparse, 00:05:12/00:03:12
(*, 224.0.1.40), 01:45:32/00:02:31, RP 0.0.0.0, flags: DPL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
Несмотря на то, что канал CE2-PE2 – линк в сторону провайдера, никакие операторские технологии здесь не используются, только стандартный PIM.
Убедимся, что маршрутизатор CE1, выполняющий функции Rendezvous Point для клиентской сети, также получил информацию о группах, на которые выполнена подписка.
CE1#sho ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.7.7.7), 00:10:46/00:02:32, RP 5.5.5.5, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet0/0, Forward/Sparse, 00:02:21/00:02:32
(*, 224.0.1.40), 01:50:51/00:02:48, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet0/0, Forward/Sparse, 01:50:49/00:02:48
Вновь заглянем в дамп на канале между P1 и P2, где найдём сообщение, с помощью которого и производится подписка.
Итак, перед нами стандартное PIM-сообщение Join/Prune, отправляемое маршрутизатором PE2 в IP-пакете с адресом отправителя 4.4.4.4 и групповым адресом получателя 224.0.0.13. Однако это сообщение в overlay-сети, поэтому оно инкапсулируется внутрь GRE, после чего инкапсулируется внутрь пакета IPv4, передаваемого по underlay сети. Адрес получателя во внешнем IP-пакете равен 239.1.1.1, что соответствует группе mdt default для VRF A. Именно по этому адресу получателя опорная сеть отличает групповые потоки разных VRF.
Внутри самого PIM-сообщения мы также видим два IP-адреса: 3.3.3.3 и 5.5.5.5. Адрес 3.3.3.3 идентифицирует маршрутизатор PE1 – PIM-соседа для PE2. Адрес 5.5.5.5 указывает на «конечную точку», то есть адрес RP. Подписка на группы по протоколу PIM происходит последовательно по направлению от получателя в сторону Rendezvous Point (при отсутствии узла, отправляющего трафик для этой группы): CE2 подписывается на PE2, PE2 подписывается на PE1, PE1 – на CE1. Это означает, например, что на линке CE2-PE2 в качестве Upstream-neighbor будет указан адрес 4.4.4.4, при этом адрес RP (5.5.5.5) меняться не будет.
Data plane
Единственное, что осталось сделать, - убедиться в успешности передачи группового трафика между Sender и Receiver.
Sender#ping 239.7.7.7 repeat 5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 239.7.7.7, timeout is 2 seconds:
Reply to request 0 from 10.0.1.2, 164 ms
Reply to request 1 from 10.0.1.2, 52 ms
Reply to request 2 from 10.0.1.2, 44 ms
Reply to request 3 from 10.0.1.2, 56 ms
Reply to request 4 from 10.0.1.2, 48 ms
Внутри сети оператора ICMP сообщения Echo Request, отправляемые на групповой адрес, выглядят так, как представлены ниже.
Сообщения ICMP Echo Reply отправляются в виде unicast, поэтому для этих пакетов применяются все стандартные правила передачи данных внутри VRF.
Если скорость потока multicast превышает заданную величину, то на underlay сети происходит переключение с группы mdt default на одну из групп mdt data. В этот момент по underlay-сети передаётся сообщение PIM Join –подписка на mdt data группу от устройства PE2 в сторону PE1.
Заключение
Групповое вещание может успешно передаваться по сети MPLS-оператора внутри VRF. Сигнализация может выполняться при помощи разных протоколов: в данном материале мы ограничились рассмотрением сигнализации PIM, однако в ближайшее время мы планируем описать сигнализацию с помощью протокола BGP.
Решение на базе Rosen GRE является весьма популярным, не в последнюю очередь благодаря практически повсеместной поддержке со стороны сетевого оборудования.
Конфигурация всех маршрутизаторов приведена в архиве.
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 |
interface Loopback0 |
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
ASUS 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-AC56U и RT-AX58U. Начали мы с создания выделенной виртуальной сети для передачи данных 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 рублей без учёта дополнительных лицензий.
Страница 2 из 8
