Category: Wireless Network

Thời gian gần đây mình dần chuyển đổi các thiết bị có dây  thành các thiết bị không dây và mình gặp một vài vấn đề với hệ thống Audio. Sau khi tìm hiểu, mặc định ruckus chuyển đổi lưu lượng Multicast thành Unicast. Điều này làm các thiết bị như Yamaha MusicCast … không tìm thấy khi sử dụng spotify connect.

Để khắc phục lưu lượng Multicast trên hệ thống Wi-Fi, chúng ta cần cấu hình cho Ruckus dừng thực hiện việc chuyển đổi Multicast thành Unicast.

Hướng dẫn này sẽ chỉ cho bạn cách thực hiện điều đó

Kết nối ssh đến AP Master

Login vào AP với thông tin tài khoản được dùng để login trên Web

Sau khi đăng nhập nhập lệnh:

enable 
config

Chọn wlan cần cấu hình, trong trường hợp này mình chọn wlan test

wlan test 
no qos directed-multicast
qos directed-threshold 0

Nhập exit 2 lần để thoát

Các bước cấu hình đã hoàn tất, hãy thử lại ứng dụng của mình ! Chúc các bạn thành công

Tôi liên tục điều chỉnh để hệ thống WiFi nhiều tầng, mật độ cao của tôi hoạt động tốt với Windows, Mac OSX và các thiết bị di động.

Sau đây là các tối ưu hóa hiện tại của tôi:

Toàn hệ thống:

• Tối ưu hóa kênh: Tối ưu hóa hiệu suất, enables tất cả các kênh 5GHz, đặc biệt hữu ích trong môi trường có nhiều AP.
• Self-Healing: Tự động điều chỉnh kênh 2,4Ghz và 5Ghz bằng cách sử dụng Background scanning  (Tôi thấy ChannelFly quá bận rộn và nó không đáp ứng kỳ vọng của tôi)
• Background scanning: Chạy Background scanning sau mỗi 3600 giây. Thời gian mặc định của Rukus quá ngắn, gây ra việc thay đổi kênh không cần thiết.

Đối với Access Point:

• Radio B/G/N(2.4G): Chỉ cho phép các kênh 1, 6, 11
• Radio A/N/AC(5G) indoor: Tùy thuộc vào môi trường, có thể cho phép tất cả hoặc vô hiệu hóa một số kênh DFS hoặc kênh ngang hàng Apple TV (149).
• Channelization 2,4 GHz: 20
• Channelization 5.0GHz: 40 (80 chỉ sử dụng quá nhiều kênh trong môi trường dày đặc)
• Tôi cũng vô hiệu hóa radio 2,4 GHz trên hầu hết mọi AP khác, vì vị trí đặt AP được xây dựng cho vùng phủ sóng 5 GHz. Điều này giúp giải quyết tình trạng tranh chấp kênh 2,4 GHz.
• Giảm công suất TX cho 2,4 GHz và có thể là 5 GHz tùy thuộc vào vị trí lắp đặt.

WLAN:

• Nếu các clients không dây không cần giao tiếp trực tiếp với nhau, hãy bật tính năng Wireless client isolation.
• Cân bằng băng tần, bỏ chọn “Do not perform Band Balancing on this WLAN service”
• Enable OFDM (Tắt client chỉ sử dụng 802.11b)
• BSS Min Rate: 24,00mbps (Để khuyến khích client roaming  đến AP gần hơn)
• Enable 802.11k

Với những thiết lập này, tôi có ít phàn nàn từ người dùng và kết nối không dây “just work”. Tất nhiên, máy khách Apple (đặc biệt là OSX) là khó nhất, nhưng hầu hết các vấn đề của họ có thể được giải quyết bằng cách tắt/bật WiFi hoặc đôi khi là resetting PRAM.

Nguồn: https://www.ruckuswireless.com/

Dòng sản phẩm WLAN controller Zone Director nổi tiếng của Ruckus là một trong những sản phẩm chính đã giúp Ruckus từ một công ty khởi nghiệp năm 2008 với quy mô chỉ khoảng 100 nhân viên trở thành một công ty lớn trên thế giới về WLAN. Dòng sản phẩm này đang được sử dụng bởi hàng chục nghìn khách hàng, giúp họ dễ dàng cấu hình và quản lý mạng không dây của mình. Tuy nhiên, Ruckus không dừng lại ở đó, vào năm 2015, Ruckus đã giới thiệu một nền tảng WLAN controller mới – SmartZone, một thế hệ mới của controller nhằm giúp Ruckus Wireless tiếp cận được những nhu cầu/xu thế đang thay đổi của thị trường và khắc phục được các nhược điểm của nền tảng Zone Director.

Bài viết này sẽ so sánh sơ qua về kiến trúc giữa hai nền tảng Zone Director và SmartZone và áp dụng chúng vào việc thiết kế các mô hình mạng  như thế nào. Chúng ta sẽ bắt đầu với việc nhắc lại về các kiến trúc WLAN MAC.

1. CÁC KIẾN TRÚC WLAN MAC:

Có 3 kiến trúc WLAN MAC phổ biến trong mạng Wireless LAN 802.11, bao gồm:

Remote MAC, Split MAC và Local MAC

Remote MAC:

• AP chỉ là PHY radio, toàn bộ việc xử lý của MAC layer được thực hiện tập trung;
• Toàn bộ việc xử lý các tác vụ real-time và non-real-time đều được thực hiện bởi controller;
• Kết nối PHY layer data giữa AP và controller;
• Là kiến trúc ít phổ biến cho mạng WLAN;
• Một ví dụ điển hình cho kiến trúc remote MAC là hệ thống LTE Active DAS.

Split MAC:

• Việc xử lý MAC layer được phân chia cho cả AP và Controller;
• Các chức năng xử lý real-time MAC layer được thực hiện tại AP;
• Việc điều khiển được thực hiện thông qua giao thức LWAPP hoặc CAPWAP bởi controller tập trung;
• Việc xử lý các tác vụ non-real-time hoặc near-real-time được thực hiện bởi Controller;
• Integration Service (Chuyển đổi từ 802.11 WLAN Frame sang 802.3 Ethernet Frame) được thực hiện hoặc ở AP, hoặc ở Controller;
• Kết nối giữa AP và Controller là Layer 2 / Layer 3;
• Kiến trúc phổ biến cho các mạng WLAN;
• Ruckus Wireless Zone Director được thiết kế dựa theo kiến trúc này.

Local MAC:

• Việc xử lý MAC layer được thực hiện toàn bộ ở AP;
• Việc xử lý các tác vụ Real-time, near real-time và non-real-time đều được thực hiện tại AP;
• Toàn bộ các chức năng cơ bản đều được thực hiện tại AP vì vậy có khả năng hoạt động không phụ thuộc vào controller tập trung;
• Các dịch vụ khác có thể được thực thi bởi chức năng điều khiển (vd: Quản lý cấu hình …);
• Các hệ thông phân tán như controller dạng cloud thường lựa chọn kiến trúc này;
• Ruckus Wireless Smart Zone được thiết kế dựa theo kiến trúc này.

Theo RFC 5412, bảng sau đây mô tả về kiến trúc SPLIT MAC và LOCAL MAC:

2. KIẾN TRÚC ZONE DIRECTOR MAC

Nền tảng Ruckus Wireless Zone Director được phát triển để nhắm vào các khách hàng doanh nghiệp vừa và nhỏ. Nền tảng này được thiết kế dựa trên một phiên bản tùy biến của kiến trúc Split MAC (được định nghĩa trong RFC 5412). Dưới đây là bảng các chức năng được phân chia thực hiện bởi AP và Zone Director.

Zone Director Split MAC: Vai trò và trách nhiệm:

Việc hiểu rõ từng vai trò và trách nhiệm (hay còn gọi là các chức năng) được phân công cho AP và Zone Director là rất quan trọng trong việc thiết kế một mạng WLAN. Dưới đây là một số điểm quan trọng nhất cần xem xét khi thiết kế:

2.1. Khả năng phục hồi

 Từ bảng trên ta có thể dễ dàng nhận thấy chức năng nào sẽ bị mất khi Zone Director bị lỗi. Các client đang kết nối tới hệ thống vẫn sẽ duy trì kết nối, tuy nhiên các client mới sẽ không thể kết nối vào hệ thống nếu không có controller. Các client cũng sẽ không thể roaming giữa các AP vì tất cả các association / re-association requests đều phải gửi đến controller.

Thuật toán Ruckus SmartMesh chạy trên các AP cho phép mỗi AP tính toán các đường uplink. Tuy nhiên, chức năng SmartMesh topology change (cho phép Mesh AP kết nối với đường uplink mới) sẽ không thực hiện được nếu không có controller.

 Việc mất kết nối với Zone Director cũng ảnh hưởng đến các chức năng quản lý encryption key, xác thực RADIUS, phát hiện Rogue AP và các chức năng WLAN khác có sự tham gia của controller.

Các AP được thiết kế để làm việc với mode local breakout (Dữ liệu người dùng không tunnel về controller mà đi ra thẳng tại AP) sẽ thực hiện việc chuyển đổi frame tại AP. Các cấu hình cho các chức năng về L3/L4 Access Control Lists và client isolation được lưu tại AP vì vậy các chức năng này vẫn sẽ tiếp tục làm việc với các client đã kết nối. Chức năng L2 Access Control (MAC Address based Access Control) được thực hiện trên Zone Director khi client thực hiện associate vào hệ thống, vì vậy chức năng này cũng sẽ không hoạt động nếu không có controller.

2.2. Dự phòng và quy mô

Nền tảng Zone Director chỉ hỗ trợ dự phòng 1+1 Active/Standby (được gọi là Smart Redundancy) và không hỗ trợ khả năng tạo cluster để tang quy mô (dung lượng) của hệ thống. Việc này gây ra những khó khăn trong việc triển khai một mạng WLAN với quy mô lớn hơn 1000 AP. Zone Director cos thể chạy với mô hình dự phòng N+1 khi sử dụng tính năng Primary and Secondary Zone Director failover, tuy nhiên không hỗ trợ stateful failover (sateful failover – chuyển đổi không làm gián đoạn dịch vụ)

2.3. Authentication / Association

Hạn chế chính của Zone Director AP là tất cả các request của 802.11 Authentication và Association phải đi qua controller.

Zone Director cũng đóng vai trò là RADIUS Client cho tất cả các bản tin authentication và accounting, đồng thời cũng đóng vài trò là một 802.1X authenticator trong 802.1x framework. Zone Director chịu trách nhiệm cho việc quản lý encryption key như là tạo và phân phối Master Session Key (MSK), Pairwise Master Key (PMK), các key tạm khác. Các key này được dùng để mã hóa việc gửi thông tin qua giao diện vô tuyến của AP.

Zone Director cũng chịu trách nhiệm trong việc tích hợp các kiểu xác thực khác bao gồm LDAP / Active Directory, Captive Portal Access, Guest Access Services, Zero-IT client provisioning, Dynamic Pre-Shared Keys và Hotspot Access…

Việc bắt buộc tất cả các giao dịch  802.11 authentications / associations phải đi qua Zone Director dẫn đến một số khó khăn khi thiết kế một mạng WLAN quy mô lớn, bao gồm:

• 11 Authentication/Association request latency – Trễ xác thực 802.11
• 1X Authentication latency / packet loss – Trễ/mất gói trong xác thực 802.1X
• WPA / WPA2 4-Way handshake
• AP roaming delays – Trễ trong roaming
• Khả năng đáp ứng trong triển khai theo mô hình phân tán

802.11 Authentication/Association latency:

 Một số thiết bị có giới hạn về độ trễ giữa các gói tin gửi đi và nhận về trong quá trình xác thực. Một ví dụ là một số máy quét barcode sẽ không kết nối được mạng WLAN nếu không nhận được gói tin trả lời trong vòng 100ms trong quá trình xác thực. Các kỹ sư Ruckus đã thực hiện một thử nghiệm năm 2013 và thấy rằng hầu hết các thiết bị không bị ảnh hưởng với độ trễ là vài tram mili giấy. Độ trễ lớn nhất giữa AP và controller đã được thử nghiệm là >400ms (Gửi từ Sunnyvale tới South Africa / Beijing) và hầu như không ảnh hưởng tới việc kết nối của các thiết bị. Tuy nhiên, độ trễ tối đa được khuyến nghị sẽ là 150ms bởi vì chúng ta không thể chắc chắn hết về các thiết bị đầu cuối.

Từ version ZoneFlex 9.7, một tính năng mới đã được giới thiệu là Autonomous WLAN cho phép các Ap có thể trực tiếp trả lời các request authentication của association của client

802.1X Authentication with latency/packet loss:

Bên cạnh các bản tin xác thực 802.11, các bản tin EAPOL được gửi giữa Supplicant (client device) và Authenticator (Zone Director) cũng sẽ gặp vấn đề khi được truyền qua kết nối WAN có đã trễ cao và dễ mất gói. Nên nhớ rằng, LWAPP tunnels sử dụng UDP, các kỹ sư Ruckus đã thử nghiệm và thấy rằng các client sẽ khó xác thực 802.1x thanh công nếu  việc trao đổi các EAPOL key được thực hiện qua kết nối có đỗ trễ cao do bị mất thứ tự các frame và tăng số lượng bản tin EAPOL replay.

WPA / WPA2: 4-Way Handshake

WPA/WPA2 4-Way handshake được thực hiện bởi Client STA và Zone Director để thiết lập các khóa Pairwise Transient Key (PTK) và GroupWise Transient Keys (GTK) được sử dụng cho việc mã hóa dữ liệu được gửi qua giao diện vô tuyến. Sau khi Zone Director đã thiết lập được PTK (dùng để mã hóa lưu lượng unicast của client) và GTK (được gửi đến client để mã hóa lưu lượng multicast), nó thông báo cho AP giá trị của các key để AP có thể thực hiện mã hóa dữ liệu được gửi qua giao diện vô tuyến. Key Caching được lưu trữ tập trung tại  Zone Director và về nguyên tắc AP không cần phải biết đến giá trị của PMK hay bất cứ một Transient Keys nào.

 Từ phiên bản Zone Flex version 9.7, Ruckus Wireless đã đưa vào một tính năng mới gọi là “Autonomous WLAN” cho phép một WLAN sử dụng phương pháp xác thực “Open authentication” với tùy chọn mã hóa WPA/WPA2-Personal trong đó AP sẽ đẩm nhiệm việc sinh PTK từ PMK và lưu trữ PMK trên AP.

AP Roaming Delays:

 Một trong những yếu tố cần quan tâm khi thiết kế một mạng WLAN là độ trễ roaming khi di chuyển giữa các AP. Mỗi khi client re-associate với một AP mới, re-association request phải được chuyển tới Zone Director để phê duyệt. Nếu mã hóa được sử dụng thì sẽ phải thực hiện lại quá trình 4-way handshake giữa Client STA và Zone Director. Việc này có thể sẽ dẫn đến thời gian trễ đáng kể nếu controller đặt xa các thiết bị đầu cuối. Ngay cả khi kỹ thuật fast roaming như PMK caching được sử dụng, thời gian roaming cũng có thể quá dài đối với một số ứng dụng nhạy cảm trễ.

Trong một thử nghiệm, khi độ trễ từ Zone Director đến AP là 50ms, cũng sẽ mất tới >200ms để thực hiện việc chuyển vùng AP. Thời gian này chưa kể thời gian trao đổi các bản tin RADIUS giữa Zone Director và Authentication Server (AS).

Khả năng đáp ứng trong triển khai theo mô hình phân tán

Với các doanh nghiệp/tổ chức lớn với nhiều văn phòng/chi nhánh nằm tại các địa điểm khác nhau, trụ sở chính sẽ có một hạ tầng CNTT bao gồm các dịch Active Directory, LDAP, RADIUS, DHCP, DNS và một số máy chủ. Các văn phòng nhỏ/chi nhánh sẽ kết nối về trụ sở chính qua các kết nối WAN thường có tốc độ thấp và độ trễ cao. Trong một số trường hợp các chi nhánh có thể kết nối về trụ sở chính thông qua kết nối VPN trên môi trường internet. Với môi trường như vậy, về nguyên tắc chúng ta có thể đặt Zone Director controller tại trụ sở chính và các AP tại tất cả các trụ sở/chi nhánh sẽ kết nối về. Tuy nhiên, khi đó mọi association và AAA authentication/authorization request sẽ buộc phải tập trung về controller. Tất nhiên, mô hình này vẫn có thể hoạt động nhưng với các ứng dụng yêu cầu thời gian roaming nhỏ như là dịch vụ Vo-WiFi (yêu cầu thời gian roaming nhỏ hơn 50ms) thì yêu cầu về độ trễ của kết nối WAN giữa các trụ sở phải rất nhỏ (ví dụ với Vo-WiFi nêu trên thì độ trễ không vượt quá 12.5ms), điều này khó khả thi với các kết nối WAN hay Internet.

2.4. Layer 3 Networks:

Từ version ZoneFlex 9.4 trở lên, Ruckus không thực hiện Layer 2 LWAPP tunnels mà thực hiện L3 LWAPP tunnels giúp hỗ trợ việc đặt Zone Director và AP ở các subnet khác nhau.

2.5. Triển khai với NAT:

Tất cả các bản tin LWAPP đều xuất phát từ Access Point và gửi đến controller, vì vậy AP hoàn toàn có thể được triển khai phía sau NAT mà không gặp bất kỳ vấn đề gì. Từ version ZoneFlex 9.2 trở lên, Zone Director cũng hỗ trợ việc triển khai sau NAT, lúc đó AP sẽ được trỏ về địa chỉ public của Zone Director và tất nhiên là phải thực hiện forward một số cổng cần thiết của Zone Director ra ngoài địa chỉ public này. Tương tự vậy, chức năng Smart Redundancy cũng có thể hoạt động nếu Zone Director được đặt sau NAT.

2.6. Chuyển tiếp dữ liệu tập trung

Kiến trúc Split MAC của Zone Director cho phép dữ liệu được chuyển tiếp tập trung nhờ LWAPP tunnel (qua cổng UDP 12222). Tương tự như CAPWAP, LWAPP không hỗ trợ việc tách rời lưu lượng điều khiển và dữ liệu. Cả LWAPP control và LWAPP data tunnel đều kết nối về cùng một interface của Zone Director. Đây không thực sự là vấn đề đối với hầu hết các môi trường triển khai cho doanh nghiệp.

Tuy nhiên, đối với các nhà cung cấp dịch vụ viễn thông thì đây lại là một vấn đề lớn. Hầu hết các nhà cung cấp dịch vụ viễn thông lớn đều muốn tách rời mạng điều khiển và mạng dữ liệu của người dùng.

This is not always the case with service providers though.  Most large operators and service providers actually prefer to keep network control and subscriber data separate and forward them to parts of the network optimized for dealing with the specific traffic types.

Một vấn đề nghiêm trọng nữa là khi mà luồng điều khiển và luồng dữ liệu được truyền chung với nhau, nếu luồng điều khiển gặp vấn đề cũng sẽ làm gián đoạn luồng dữ liệu của người dùng.

Và rắc rối cuối cùng là Zone Director sẽ phải thực hiện một lượng lớn các xử lý MAC layer khi mà dữ liệu người dùng được forward tập trung về. Chính vì vậy, trong kiến trúc Split MAC về nguyên tắc một controller tối đa chỉ quản lý được vài nghìn AP.

Kết Luận:

Kiến trúc Split MAC của Zone Director có một số hạn chế vì vậy cần được cân nhắc khi triển khai các mạng WLAN dựa trên Zone Director. Việc thực thi các tác vụ của 802.11 và toàn bộ việc xác thực, quản lý key được thực hiện trên controller có thể dẫn đến việc tăng thời gian chuyển vùng AP làm việc triển khai theo mô hình phân tán gặp nhiều khó khăn. Vì vậy, việc đặt Zone Director tại chỗ ở mỗi địa điểm triển khai nên được xem xét, nhưng điều này cũng làm tăng chi phí triển khai và quản lý.

3. KIẾN TRÚC SMARTZONE MAC

Nền tảng SmartZone bắt đầu được phát triển từ đầu năm 2011 và không dựa trên kiến trúc Split MAC vốn đã được chấp nhận rộng rãi trong việc thiết kế các mạng WLAN doanh nghiệp. Nền tảng SmartZone đã triển khai một kiến trúc Local MAC tùy biến với việc tách rồi luồng điều khiển và luồng dữ liệu và sử dụng các giao thức lightweight phù hợp nhất cho mỗi nhiệm vụ. Hầu hết các công việc quan trọng của giao thức 802.11 (802.11 Client State Machine) và các chức năng khác được thực hiện tại AP. Bảng dưới đây mô tả rõ việc phân chia các chức năng giữa AP và SmartZone:

3.1. Khả năng phục hồi (khả năng hoạt động khi bị lỗi)

Như chúng ta thấy ở trong bảng trên, nền tảng SmartZone có khả năng phục hồi rất tốt với việc controller bị lỗi. Tất cả các chức WLAN cơ bản và một vài chức năng khác đều được thực hiện tại AP. Việc mất kết nối tới controller sẽ hầu như không ảnh hưởng để hoạt động bình thường của mạng WLAN.

Một số chức năng khác như Social Media Login hoặc Guest access có thể cần sử dụng CSDL người dùng được lưu trên SmartZone để xác thực người dùng có thể bị ảnh hưởng khi mất kết nối với controller. Tuy nhiên, các AP sẽ lưu trạng thái của người dùng đã kết nối với hệ thống và đảm bảo kết nối người dùng không bị ảnh hưởng.

Việc xác thực captive portal qua AP tới các CSDL bên ngoài sẽ không bị ảnh hưởng bởi kết nối tới controller.

Chức năng WiSPR Hotspot cần phải có sự hỗ trợ của SmartZone trong việc HTTP/HTTPS redirect, xử lý client proxy, tích hợp với Landing portal và xác thực RADIUS. Chức năng walled garden (một dạng whitelist trong xác thực hotspot) được thực hiện trên AP qua cơ chế DNS cache, cho phép lưu lượng người dùng đi ra internet trực tiếp từ AP mà không phải đi qua controller.

3.2. Dự phòng và quy mô:

Nền tảng SmartZone hỗ trợ dự phòng cluster N+1 active/active, cho phép tối đa lên tới 4 node trên một cluster. Các AP sẽ tự động san đều ra các node trong cluster (theo thứ tự ngẫu nhiên) để đảm bảo không có node nào bị quá tải.

Tất cả các thông tin về client được chia sẻ và đồng bộ giữa các node. Tất các cả thông tin về cấu hình và các bản ghi cố định khác được phân chia và sao lưu trên các CSDL của cluster để đảm bảo rằng nếu 1 node bất kỳ bị lỗi sẽ không ảnh hưởng đến dịch vụ.

Một controller SmartZone có thể hỗ trợ lên tới 10 000 AP và một cluster (4 node) có thể hỗ trợ lên tới 30 000 AP. SmartZone cũng hỗ trợ việc dự phòng giữa các cluster. Khi một toàn bộ cluster bị lỗi thì có thể chuyển đổi dự phòng sang một cluster khác. Cấu hình giữa 2 cluster phải được đồng bộ (thủ công hoặc đình kỳ).

3.3. 802.11 Association

Trong kiến trúc SmartZone, các thông tin để thực hiện các công việc trong giao thức 802.11 được lưu tại AP. Tất cả các nhiệm vụ về 802.11 authentication & association đều được đảm nhiệm trực tiếp bởi AP và kết quả sẽ được gửi về SmartZone (theo thời gian thực) để lưu trữ trong events logs. Vì vậy sẽ gặp phải các vấn đề về độ trễ giữa Smartzone và AP trong việc thực hiện 802.11 authentication và association.

Trong trường hợp sử dụng phương thức xác thực captive portal, AP sẽ cho phép người dùng associate và đồng thời kiểm tra trang thái của người dùng trên SmartZone. Nếu trạng thái của người dùng là “Authorized” thì AP sẽ không chuyển tiếp người dùng ra captive portal mà cho phép lưu lượng người dùng đi qua ngay lập tức (trong trường hợp kết nối Internet là cho phép ra Internet)

Trong trường hợp sử dụng WPA2-Personal, Pre-Shared Key cũng sẽ được lưu tại từng AP. Tương tự, danh sách L2 Access Control được dùng cho việc hạn chế truy cập theo MAC cũng sẽ được lưu tại AP.

Kiến trúc Local MAC của nền tảng SmartZone đã hạn chế được rất nhiều các vấn đề mà kiến trúc Split MAC gặp phải, bao gồm:

• 11 Authentication/Association request latency – Trễ xác thực 802.11
• 1X Authentication latency / packet loss – Trễ/mất gói trong xác thực 802.1X
• WPA / WPA2 4-Way handshake
• AP roaming delays – Trễ trong roaming
• Khả năng đáp ứng trong triển khai theo mô hình phân tán

Quản lý 802.1X Authentication & Encryption Key

AP đóng vai trò như là RADIUS client trong việc gửi tất cả các bản tin RADIUS Authentication và Accounting. Tuy nhiên, cũng có lựa chọn cho phép SmartZone đóng vai trò như là một Radius Proxy.

AP đóng cũng đóng vai trò là 802.1X Authenticator trong 802.1X framework và chịu tránh nhiệm trong việc quản lý tất cả các encryption key, sinh MSK, PMK và các key tạm khác sử dụng trong quá trình mã hóa giao diện vô tuyến. Khi PMK được sinh ra, nó sẽ được lưu tại AP (PMK-caching) để làm tăng trải nghiệm người dùng trong quá trình 802.1x roaming. PMK cũng được gửi từ AP tới SmartZone để lưu trữ phục vụ chức năng Opportunistic PMK Caching. Nếu người dùng chuyển vùng sang một AP mới và cung cấp PMK-ID trong quá trình re-association, AP sẽ tìm kiểm PMK-ID này trên SmartZone để không phải thực hiện lại quá trình xác thực 802.1X đầy đủ. Quá trình WPA-4 way handshake được thực hiện hoàn toàn giữa client và AP loại bỏ hoàn toàn các vấn đề về độ trễ giữa AP và controller.

Tuy nhiên, vẫn có thể xảy ra một số vấn đề liên quan đến độ trễ cao của kết nối giữa SmartZone và AP. Độ trễ trong quá trình tìm kiếm PMK của AP trên SmartZone  và có thể gây ra độ trễ không chấp nhận được trong quá trình roaming. Tuy nhiên, ảnh hưởng này là không nhiều bởi vì quá trình tìm kiếm được thực hiện ngay sau quá trình association, sau đó tất cả các tác vụ khác sẽ được thực hiện trực tiếp giữa AP và Client.

Khả năng đáp ứng trong triển khai theo mô hình phân tán:

Nền tảng SmartZone cho phép các chi nhánh triển khai các AP tích hợp thẳng vào hạ tầng CNTT tại chỗ (Active Directory, LDAP, RADIUS, DHCP, DNS, Firewalls etc.).  Điều này có nghĩa là một SmartZone controller có thể quản lý được nhiều site mà không bắt buộc các authentication request hay dữ liệu người dùng phải kết nối về SmartZone. Đương nhiên là chúng ta vẫn có thể dùng SmartZone như là một proxy nếu muốn.

3.4. Layer 3 Networks:

Các AP chạy với nền tảng SmartZone sử dụng giao thức điều khiển riêng (dựa trên SSH) để kết nối với SmartZone cho phép tất cả lưu lượng điều khiển có thể vận chuyển qua Layer 3.

3.5. Khả năng triển khai với NAT

Tất cả các bản tin trao đổi đều được xuất phát từ AP và gửi tới SmartZone, vì vậy các AP làm việc trong nền tảng SmartZone có thể triển khai được sau NAT mà không gặp trở ngại gì. Các controller trong nền tảng SmartZone bao gồm virtual SmartZone (vSZ-E, vSZ-H) and SmartZone 100/300 đều hỗ trợ khả năng triển khai sau NAT. Trong trường hợp chạy cluster, thì phải sử dụng các địa chỉ IP public riêng biệt cho từng node.

3.6. Chuyển tiếp dữ liệu tập trung

Nền tảng SmartZone giao thức điều khiển riêng (dựa trên SSH) và giao thức dựa trên GRE cho đường dữ liệu và hai đường này được tách riêng. Nền tảng SmartZone cho phép chuyển tiếp dữ liệu tập trung tới SmartZone Controller (dạng Appliance) hoặc về Data Plane (dạng ảo hóa) thông qua giao thức RuckusGRE

RuckusGRE

RuckusGRE là phiên bản tùy biến của L2oGRE (còn được gọi là Ethernet over GRE hoặc SoftGRE) bằng cách thêm vào một header lớp Transport vào gói IP. Việc thêm vào một UDP header cho phép AP thiết lập một GRE tunnel ngay cả khi nó được đặt đằng sau một NAT router. GRE tiêu chuẩn không có UPD/TCP header này.

 RuckusGRE sử dụng TLS certificate cho việc xác thực và có tùy chọn mã hóa AES 128 bit.

Xử lý riêng biệt – Differentiated Handling

SmartZone tách biệt control và data plane vì vậy cho phép xử lý riêng biệt lưu lượng điều khiển và lưu lượng người dùng. Data plane được thiết kế để nhận cấu hình từ control plane nhưng vẫn tách biệt được việc xử lý dữ liệu của người dùng.

Các controller dạng appliance như SmartZone 100/300 đều hỗ trợ data plane trên thiết bị cứng cho phép lưu lượng có thể được tunnel về cùng một thiết bị phần cứng.

Data Plane trên SmartZone 100 có thể sử dụng địa chỉ IP và subnet riêng hoặc sử dụng cùng địa chỉ IP với control plane. Còn SmartZone 300 thì yêu cầu mỗi thanh phần (data plane và control plane) cần có địa chỉ IP riêng của nó.

Virtual SmartZone Data Plane (vSZ-D) là dạng ảo hóa của DataPlane và được sử dụng cùng với dạng ảo hóa của SmartZone controller. Với phiên bản hiện tại, mỗi virtual SmartZone có thể quản lý được tối đa 10 vSZ-D và một cluster có thể quản lý lên tới 40 vSZ-D.

Triển khai Data Plane với NAT

Các controller trong nền tảng SmartZone đều hỗ trợ việc đặt data plane phía sau NAT. kết nối điều khiển giữa vSZ-D và SmartZone cũng hỗ trợ việc đặt sau NAT. Tuy nhiên, mỗi vSZ-D sẽ cần địa chỉ IP public riêng cho nó.

Yêu cầu về độ trễ:

Độ trễ được khuyến nghị giữa vSZ-D và vSZ control plane là <150ms. Đối với các controller dạng appliance (SmartZone 100/300) thì không có yêu cầu này vì dataplane và control plane nằm trên cùng một thiết bị phần cứng.

Xử lý các frame 802.11:

AP vẫn sẽ đảm nhiệm toàn bộ việc chuyển đổi từ 802.11 frame sang 802.3 frame trước khi chúng được đóng gói GRE header điều này giúp giảm tải cho và tăng hiệu năng cho DataPlane.

Kết Luận

Nền tảng SmartZone được thiết kế dựa trên kiến trúc Local MAC cho phép đơn giản hóa việc triển khai các mạng WLAN trên nhiều địa điểm địa lý khác nhau và tăng cường trải nghiệm người dùng mà không cần phải trang bị mỗi nơi một controller. Đây là một yếu tố cốt lõi cho phép triển khai các mô hình kinh doanh dạng cloud, managed service…

Kiến trúc SmartZone cũng cho thấy khả năng xử lý riêng biệt dữ liệu điều khiển và dữ liệu người dùng. Khả năng vSZ-D có thể được đặt trong một subnet riêng cho phép phân cách lưu lượng điều khiển và lưu lượng người dùng trong các mạng của nhà cung cấp dịch vụ. Khả năng vSZ-D có thể đặt được ở các vị trí địa lý khác nhau làm cho việc chuyển tiếp dữ liệu người dùng trở nên linh hoạt hơn.