September 2021

SO SÁNH KIẾN TRÚC HAI NỀN TẢNG SMARTZONE VÀ ZONE DIRECTOR CỦA RUCKUS WIRELESS

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:

Một số chức năng khác được thực hiện trên SmartZone và trên AP được thể hiện ở bảng sau:

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.

Kiến thức cơ bản về SAN – Phần 1: Lưu trữ & Quản lý Thông tin

Chào mọi người,

Hôm nay chúng ta sẽ có một cái nhìn tổng quan về Quản lý và Lưu trữ Thông tin (ISM) và biết về các thành phần của hệ thống lưu trữ thông minh.

Giới thiệu cơ bản

Thông tin ngày càng quan trọng trong cuộc sống hàng ngày của chúng ta. Chúng ta đã trở thành những người phụ thuộc vào thông tin của thế kỷ XXI, sống trong một thế giới theo lệnh, theo yêu cầu có nghĩa là chúng ta cần thông tin khi nào và ở đâu. Chúng ta truy cập Internet mỗi ngày để thực hiện tìm kiếm, tham gia vào mạng xã hội, gửi và nhận e-mail, chia sẻ hình ảnh và video cũng như điểm số của các ứng dụng khác. Tại đây chúng ta có thể tìm hiểu về những điều cơ bản của Thông tin, Sự phát triển của công nghệ Lưu trữ và Kiến trúc và các yếu tố cốt lõi của nó.

Dữ liệu là tập hợp các dữ kiện thô mà từ đó có thể rút ra kết luận. Các bức thư viết tay, một cuốn sách in, một bức ảnh gia đình, một bộ phim trên băng video, bản sao giấy tờ thế chấp được in và ký hợp lệ, sổ cái của ngân hàng và sổ tiết kiệm của chủ tài khoản đều là những ví dụ về dữ liệu.

Ngày nay, dữ liệu tương tự có thể được chuyển đổi thành các dạng tiện lợi hơn như tin nhắn e-mail, sách điện tử, hình ảnh được ánh xạ bit, hoặc phim kỹ thuật số. Dữ liệu này có thể được tạo bằng máy tính và được lưu trữ dưới dạng chuỗi 0s và 1s.

Các loại dữ liệu. Dữ liệu có hai loại.

Dữ liệu có cấu trúc:

Dữ liệu có cấu trúc được tổ chức thành các hàng và cột theo một định dạng được xác định chặt chẽ.

Dữ liệu không có cấu trúc:

Dữ liệu không có cấu trúc nếu các phần tử của nó không thể được lưu trữ trong các hàng và cột, và do đó rất khó để truy vấn và truy xuất bởi các ứng dụng kinh doanh.

Ví dụ: Địa chỉ liên hệ của khách hàng có thể được lưu trữ dưới nhiều hình thức khác nhau như ghi chú dán, tin nhắn e-mail, danh thiếp hoặc thậm chí các tệp định dạng kỹ thuật số như .doc, .txt,và .pdf. Do tính chất phi cấu trúc của nó, rất khó để truy xuất bằng ứng dụng quản lý quan hệ khách hàng.

Thông tin

Dữ liệu, dù có cấu trúc hay không có cấu trúc, không đáp ứng bất kỳ mục đích nào cho cá nhân hoặc doanh nghiệp trừ khi nó được trình bày dưới dạng có ý nghĩa. Thông tin là trí tuệ và kiến thức thu được từ dữ liệu.

Cơ sở hạ tầng Trung tâm Dữ liệu

Các tổ chức duy trì các trung tâm dữ liệu để cung cấp khả năng xử lý dữ liệu tập trung trong toàn doanh nghiệp. Trung tâm dữ liệu lưu trữ và quản lý một lượng lớn dữ liệu quan trọng. Cơ sở hạ tầng của trung tâm dữ liệu bao gồm máy tính, hệ thống lưu trữ, thiết bị mạng, dự phòng nguồn điện chuyên dụng và kiểm soát môi trường (chẳng hạn như điều hòa không khí và ngăn chặn hỏa hoạn)

Yếu tố cốt lõi

Năm yếu tố cốt lõi cần thiết cho chức năng cơ bản của trung tâm dữ liệu:

– Ứng dụng: Ứng dụng là một chương trình máy tính cung cấp logic cho các hoạt động tính toán. Các ứng dụng, chẳng hạn như hệ thống xử lý đơn hàng, có thể được xếp lớp trên cơ sở dữ liệu, từ đó sử dụng các dịch vụ của hệ điều hành để thực hiện các thao tác đọc / ghi vào thiết bị lưu trữ.

– Cơ sở dữ liệu: Thông thường hơn, hệ quản trị cơ sở dữ liệu (DBMS) cung cấp một cách có cấu trúc để lưu trữ dữ liệu trong các bảng được tổ chức hợp lý có liên quan với nhau. DBMS tối ưu hóa việc lưu trữ và truy xuất dữ liệu.

– Máy chủ và hệ điều hành: Một nền tảng máy tính chạy các ứng dụng và cơ sở dữ liệu.

– Mạng: Đường dẫn dữ liệu tạo điều kiện giao tiếp giữa máy khách và máy chủ hoặc giữa máy chủ và bộ lưu trữ .

– Thiết bị lưu trữ: Một thiết bị lưu trữ dữ liệu liên tục cho những lần sử dụng tiếp theo.

Yêu cầu chính đối với các phần tử của trung tâm dữ liệu

Tính khả dụng: Tất cả các phần tử của trung tâm dữ liệu phải được thiết kế để đảm bảo khả năng truy cập. Việc người dùng không thể truy cập dữ liệu có thể có tác động tiêu cực đáng kể đến doanh nghiệp.

Bảo mật: Các chính sách, thủ tục và sự tích hợp thích hợp của các yếu tố cốt lõi của trung tâm dữ liệu sẽ ngăn chặn truy cập trái phép vào thông tin phải được thiết lập. Ngoài các biện pháp bảo mật để truy cập máy khách, các cơ chế cụ thể phải cho phép máy chủ chỉ truy cập vào các tài nguyên được phân bổ của chúng trên các mảng lưu trữ.

Khả năng mở rộng: Các hoạt động của trung tâm dữ liệu phải có thể phân bổ khả năng xử lý bổ sung hoặc lưu trữ theo yêu cầu mà không làm gián đoạn hoạt động kinh doanh. Tăng trưởng kinh doanh thường đòi hỏi phải triển khai thêm máy chủ, ứng dụng mới và cơ sở dữ liệu bổ sung. Giải pháp lưu trữ sẽ có thể phát triển cùng với doanh nghiệp.

Hiệu suất: Tất cả các yếu tố cốt lõi của trung tâm dữ liệu phải có thể cung cấp hiệu suất tối ưu và phục vụ tất cả các yêu cầu xử lý ở tốc độ cao. Cơ sở hạ tầng phải có thể hỗ trợ các yêu cầu về hiệu suất.

Tính toàn vẹn của dữ liệu: Tính toàn vẹn của dữ liệu đề cập đến các cơ chế như mã sửa lỗi hoặc bit chẵn lẻ đảm bảo rằng dữ liệu được ghi vào đĩa chính xác như khi nó được nhận. Bất kỳ sự thay đổi nào về dữ liệu trong quá trình truy xuất đều có nghĩa là bị hỏng, có thể ảnh hưởng đến hoạt động của tổ chức.

Dung lượng: Hoạt động của trung tâm dữ liệu yêu cầu đủ nguồn lực để lưu trữ và xử lý một lượng lớn dữ liệu một cách hiệu quả. Khi các yêu cầu về dung lượng tăng lên, trung tâm dữ liệu phải có khả năng cung cấp thêm dung lượng mà không làm gián đoạn tính khả dụng hoặc ít nhất là với sự gián đoạn tối thiểu. Năng lực có thể được quản lý bằng cách phân bổ lại các nguồn lực hiện có, thay vì bằng cách bổ sung các nguồn lực mới.

Khả năng quản lý: Một trung tâm dữ liệu phải thực hiện tất cả các hoạt động và hoạt động theo cách hiệu quả nhất. Khả năng quản lý có thể đạt được thông qua tự động hóa và giảm sự can thiệp của con người (thủ công) vào các công việc chung.

Vòng đời thông tin

Vòng đời thông tin là “ sự thay đổi giá trị của thông tin ” theo thời gian. Khi dữ liệu được tạo lần đầu tiên, nó thường có giá trị cao nhất và được sử dụng thường xuyên. Khi dữ liệu cũ đi, nó được truy cập ít thường xuyên hơn và có ít giá trị hơn đối với tổ chức. Hiểu được vòng đời thông tin giúp triển khai cơ sở hạ tầng lưu trữ thích hợp, theo giá trị thay đổi của thông tin.

HP 3PAR CLI command list

showalert        - show status of system alerts
showauthparam    - show authentication parameters
showbattery      - show battery status information
showblock        - show block mapping info for vvs, lds, pds
showcage         - show disk cage information
showcim          - show the CIM server information
showclienv       - show CLI environment parameters
showcpg          - show Common Provisioning Groups (CPGs)
showdate         - show date and time on all system nodes
showdomain       - show domains in the system
showdomainset    - show sets of domains in the system
showeeprom       - show node eeprom information
showeventlog     - show event logs
showfirmwaredb   - show current database of firmware levels
showhost         - show host and host path information
showhostset      - show sets of hosts in the system
showinventory    - show hardware inventory
showiscsisession - show iscsi sessions
showld           - show logical disks (LDs) in the system
showldch         - show LD to PD chunklet mapping
showldmap        - show LD to VV mapping
showlicense      - show installed license key
shownet          - show network configuration and status
shownode         - show node and its component information
shownodeenv      - show node environmental status (voltages,temperatures)
showpatch        - show what patches have been applied to the system
showpd           - show physical disks (PDs) in the system
showpdata        - show preserved data status
showpdch         - show status of selected chunklets of physical disks
showpdvv         - show PD to VV mapping
showport         - show Fibre Channel and iSCSI ports in the system
showportarp      - show ARP table for ports
showportdev      - show detailed information about devices on a Fibre Channel port
showportisns     - show iSNS host information for ports
showportlesb     - show Link Error Status Block information about devices on Fibre Channel port                         
showrcopy        - show remote copy configuration information
showrctransport  - show information about end-to-end transport for remote copy                         
showrsv          - show information about reservation and registration of VLUNs connected on a Fibre Channel port
showsched        - show scheduled tasks in the system
showsnmppw       - shows SNMP access passwords
showsnmpmgr      - show SNMP trap managers
showspace        - show estimated free space
showspare        - show information about spare and relocated chunklets
showsshkey       - show ssh public keys authorized by the current user
showsys          - show system information (system name, serial number etc.)
showsysmgr       - show system manager startup state
showtarget       - show unrecognized targets
showtask         - show information about tasks
showtemplate     - show templates
showtoc          - show system Table of Contents (TOC) summary
showtocgen       - show system Table of Contents (TOC) generation number
showuser         - show user accounts and SSH keys
showuseracl      - show user access control list
showuserconn     - show user connections
showversion      - show software versions
showvlun         - show virtual LUNs (VLUNs) in the system
showvv           - show virtual volumes (VVs) in the system
showvvmap        - show VV to LD mapping
showvvpd         - show VV distribution across PDs
showvvset        - show sets of VVs in the system
checkhealth        - perform checks to determine overall state of the system
checkpassword     - display authentication and authorization details
checkport         - perform loopback test on fc ports
checkpd           - perform surface scan or diagnostics on physical disks
checkld           - perform validity checks of data on logical disks
checkvv           - perform validity checks of virtual volume administrative information.

Hướng dẫn về tốc độ khung hình trong camera giám sát (Frame rate in CCTV)

Đây là bài viết hướng dẫn chuyên sâu về tốc độ khung hình trong camrea giám sát. Đầu tiên, bạn cần phải biết tốc độ của vật thể, thông thường là con người.

Tốc độ của con người

Người di chuyển càng nhanh, bạn càng có nhiều cơ hội bỏ lỡ hành động, Bạn biết “tốc độ” của Frame rate là 1 khung hình / giây (1 fps), 10 khung hình / giây (10 fps), 25 khung hình/ giây (25 fps)… nhưng bạn cần tốc độ bao nhiêu khung hình để ghi hình tin cậy nhất.

Đây là cách mọi người di chuyển:

Đối với một người đi bộ, tốc độ bình thường thì thường là ~4 feet/s (khoảng 1,2 mét / giây) . Đây là video ghi lại người đi bộ bình thường 6 mét trong khoảng 5 giây:

Đối với một người đang chạy, chúng ta có video di chuyển 6 mét trong khoảng 1,25 giây, tức là anh ấy di chuyển với ~5 mét trong 1 giây:

Ví du: Nếu bạn chỉ có 1 khung hình/ giây (1 fps), một người có thể di chuyển từ 1,2 mét tới 4.8 mét trong khoảng thời gian đó. Vì thế chúng ta cần lưu ý điều này khi đánh giá lựa chọn tốc độ khung hình.

Trong hướng dẫn này, tôi xin đề cập đến:

Tốc độ mọi người di chuyển ra sao và làm thế nào để so sánh với tốc độ khung hình.
Đi bộ: Bạn có những rủi ro nào khi bắt hình một người đang đi bộ ở tốc độ 1, 10 và 30 khung hình / giây.
Chạy: Bạn đã nắm bắt được ai đang chạy ở tốc độ 1, 10 và 30 khung hình / giây.
Xoay đầu (ngó nghiêng): Bạn nhận mặt mũi rõ ràng của một người như thế nào ở 1, 10 và 30 khung hình / giây.
Chơi bài: Bạn không nắm bắt được thông tin gì về bài chơi ở mức 1, 10 và 30 khung hình / giây.
Tốc độ màn trập so với tốc độ khung hình: Cả hai có sự liên quan như thế nào?
Tỷ lệ băng thông so với khung: băng thông tăng với tăng tốc độ khung hình như thế nào?
Tỷ lệ khung hình trung bình được sử dụng: Trung bình trong camera giám sát là bao nhiêu?

Ví dụ đi bộ.

Khi người mẫu đi xuyên qua góc nhìn camera, chúng ta xem anh ấy chuyển từ khung này tới khung khác như thế nào. Trong luồng video 30 fps và 10 fps, anh ấy không hoàn thành một bước đi đầy đủ. Tuy nhiên, trong ví dụ 1fps, anh ta đã tiến tới ~1,2 mét giữa các khung hình, và phù hợp với tốc độ đi bộ của chúng ta đo được ~1,2 mét / giây.

Ví dụ khi chạy.

Khi người mẫu chạy qua góc nhìn camera, luồng 30 fps vẫn bắt kịp anh ta, trong khi ở luồng 10 khung hình / giây, anh ấy đã đi ~0,3 mét giữa các khung. Trong ví dụ 1 fps, chỉ có một khung của đối tượng bị bắt, với góc nhìn của camera giữa các khung, chỉ với chân sau của người mẫu có thể nhìn thấy trong khung thứ hai.

Chụp khuôn mặt

Cố gắng để có được một khuôn mặt rõ ràng có thể khó khăn khi mọi người di chuyển bởi vì họ tự nhiên xoay đầu của họ thường xuyên. Trong video này, chúng ta có người mẫu vừa đi bộ ở hành lang vừa lắc đầu với tốc độ khung hình khác nhau.
Hãy xem:

Chú ý, ở tốc độ 1 khung hình / giây, chỉ có một cú đánh đầu rõ ràng là bị bắt, nhưng ở tốc độ 10 khung hình / giây, bạn sẽ có nhiều hơn thế. Cuối cùng, ở tốc độ 30 khung hình / giây, bạn có thể nhận được một hoặc hai lần, nhưng không cải thiện nhiều.

Chơi bài

Trong bài kiểm tra này, chủ đề của chúng ta là xử lý một loạt các lá bài từ Át (ace) đến năm với máy ảnh được đặt thành tốc độ màn trập (shutter) mặc định (1/30).

Trong các ví dụ 30 và 10 fps, chúng ta có thể thấy mỗi lá khi nó được lấy ra từ phía trên bộ bài và đặt trên bàn. Tuy nhiên, trong ví dụ 1 fps, chúng ta chỉ thấy các thẻ xuất hiện trên bàn, không phải là chuyển động của người chơi, vì tốc độ khung hình quá thấp.

Tốc độ màn trập (Shutter) so với tốc độ khung hình (Frame rate)

Tốc độ khung hình không làm mờ hình ảnh. Đây là một quan niệm sai lầm. Điều khiển tốc độ màn trập tự động của camera.

Xử lý thẻ Át thông qua 5 lần nữa, chúng tôi tăng tốc độ màn trập tối thiểu của camera lên 1/4000 giây. Hình ảnh dưới đây so sánh hình ảnh mờ trong tay người chơi và lá bài, với 2 lá bài dễ dàng hơn nhiều trong ví dụ tốc độ màn trập nhanh.

1 / 4000s tốc độ màn trập hoàn toàn loại bỏ tất cả các dấu vết của mờ nhòa hình ảnh. 1/1000 và 1/2000 tốc độ màn trập lần thứ hai làm giảm đáng kể độ mờ, nhưng vẫn có thể thấy được xung quanh tay người chơi và các cạnh của lá bài khi xem khung ghi theo từng khung.
Nếu bạn bị mờ, bạn có vấn đề cấu hình tốc độ màn trập, chứ không phải tốc độ khung hình.

Tốc độ màn trập (Shutter) chậm và Tốc độ khung hình (Frame Rate)

Mặt khác, đôi khi người dùng muốn hoặc nhà sản xuất camera mặc định màn trập tối đa của họ với tốc độ chậm hơn tốc độ khung hình (ví dụ, màn trập 1/4 cho máy ảnh 1/30 giây). Không chỉ gây ra sự mờ của các đối tượng di chuyển , bạn sẽ mất khung hình.
Bài học chính: Tỷ lệ khung hình mỗi giây không bao giờ cao hơn số lần phơi sáng trên mỗi giây (tốc độ màn trập – Shutter). Nếu bạn có màn trập 1 / 4s, màn trập / phơi sáng chỉ mở và đóng 4 lần / giây (tức là 1 / 4s + 1 / 4s + 1 / 4s + 1 / 4s = 1s). Vì điều này chỉ xảy ra 4 lần, bạn chỉ có thể có 4 khung trong giây đó.
Một số nhà sản xuất làm giả khung hình với màn trập chậm, chỉ cần sao chép cùng một khung hình nhiều lần. Ví dụ: nếu bạn có màn trập 1/15, bạn chỉ có thể có 15 lần chụp, và do đó, 15 khung hình. Để làm cho nó có vẻ như bạn có 30 khung hình, mỗi khung có thể được gửi hai lần liên tiếp.
Hãy cẩn thận với màn trập chậm. Ngoài việc mờ, bạn có thể bị mất khung hoặc bộ nhớ bị rác.

Tỷ lệ băng thông so với khung hình

Tỷ lệ khung ảnh hưởng đến băng thông, nhưng đối với các chuẩn nén hiện đại, như H.264, nó ít tỷ lệ thuận hơn. Vì vậy, nếu bạn tăng tốc độ khung hình lên 10x, băng thông tăng có thể sẽ thấp hơn nhiều, thường chỉ có từ 3 đến 5 lần băng thông. Đây là điều chúng tôi thấy thường xuyên bị nhầm lẫn trong ngành CCTV.
Lý do của việc này là nén liên khung, làm giảm nhu cầu băng thông cho các phần của cảnh mà vẫn giữ nguyên trên các khung hình
Minh hoạ thêm điểm này, chúng tôi đã đo 30, 10 và 1 fps để chứng minh sự thay đổi tốc độ bit trong một thiết lập kiểm soát trong phòng thí nghiệm của chúng tôi. Bitrate trung bình như sau:

1 fps là 0.179 Mb / s
10 khung hình / giây, với 10x khung hình, tiêu thụ băng thông 4x nhiều hơn 1 khung hình / giây (0.693 Mb / s)
30 khung hình / giây, với 3x khung hình, tiêu thụ gấp đôi băng thông 10 khung hình / giây và với 30x khung, 7x băng thông 1fps (1.299 Mb / s)

Các phép đo này được thực hiện với 1 I frame trên giây, thiết lập phổ biến nhất trong camera giám sát chuyên nghiệp

Tỷ lệ khung trung bình được sử dụng

Tỷ lệ khung hình ngành công nghiệp trung bình là ~ 10 khung hình / giây, phản ánh mức độ này cung cấp đủ khung để nắm bắt hầu hết các hành động một cách chi tiết đồng thời giảm thiểu chi phí lưu trữ.

Như được hiển thị trong phần trước, đi từ 10fps đến 30fps có thể tăng gấp đôi chi phí lưu trữ nhưng chỉ cải thiện được ít chi tiết.

Juniper – Connecting Core Switch virtual chassis to SRX cluster

Đã có rất nhiều nhầm lẫn về việc làm thế nào để kết nối 2 switch chạy virtual chassis với SRX cluster. mọi người thường thêm nhiều interface vật lý và tạo ra nhiều interface RETH trên SRX sau đó gán các chức năng khác nhau cho mỗi interface RETH.

Phương pháp này không có khả năng mở rộng cao và sau một thời gian, các bạn sẽ gặp phải một mớ hỗn độn không thể quản lý được.

Cá nhân tôi thích tạo một interface RETH duy nhất với nhiều sub interface, mỗi interface tương ứng với L2 VLAN trên switch.

Đối với các trường hợp không yêu cầu đặc biệt tôi thường chọn cơ chế Active/Passive cho SRX Cluster. Theo kinh nghiệm của tôi Active / Active không hoạt động tốt trong SRX Chassis Cluster. Nó cũng gây khó khăn trong việc quản lý và vận hành. Không có lợi ích thực sự trong cơ chế Active / Active và gây ra các vấn đề nghiêm trọng trong thiết bị được sử dụng với lượng traffic cao. Tùy chọn khác của tôi là sử dụng SRX làm “Router on a Stick ” – Các switch chạy ở L2 và thực hiện tất cả L3/Routing/Security trên SRX.

SRX là thiết bị cực kỳ mạnh mẽ sử dụng nó theo cách này mang lại khả năng bảo mật, theo dõi phiên, định tuyến và kiểm soát tốt hơn. Thiết kế này cũng sẽ hoạt động tốt khi giảm tải các chức năng định tuyến cho switch L3.

Ví dụ bên dưới hai liên kết hoạt động trên mỗi switch vật lý, nhưng có thể mở rộng dễ dàng. Việc thêm nhiều liên kết vật lý để tăng dung lượng thực sự rất dễ và nó không ảnh hưởng đến cấu hình thực tế. Thiết kế tương tự có thể được sử dụng với nhiều switch, miễn là chúng là số chẵn

Phía SRX có 8 liên kết được kết nối với Cluster, 4 liên kết với mỗi thiết bị. Mỗi thành viên kết nối với Interface Aggregated khác nhau trên switch (ae0 – node0, ae1 – node1), nhưng chỉ một ae / node sẽ hoạt động tại một thời điểm (đây là cách hoạt động của cụm Chassis).

Phía EX: ae0 bao gồm 8 liên kết vật lý trên mỗi VC (4 cho mỗi thành viên). Mỗi thành viên có 2 Interface trong ae0 và 2 trong ae1.

Như bạn có thể thấy trong sơ đồ, lỗi của 1 thành viên EX hoặc / và 1SRX sẽ không làm gián đoạn lưu lượng và 2 đường trục liên kết sẽ được duy trì. Tăng lên 3 trung kế liên kết sẽ yêu cầu thêm liên kết vào mỗi nhóm.

Configuration

SRX

Interface reth1 được gán cho RE1. Tôi sử dụng weight=100, vì vậy việc chuyển đổi dự phòng (failover) có thể do lỗi của 3 liên kết trở lên. Chúng tôi muốn ngăn ngừa lỗi VC gây ra failover Chassis Cluster RE, vì các thiết bị được nối cáp đồng bộ.

> show configuration chassis cluster
control-link-recovery;
reth-count 3;
redundancy-group 0 {
    node 0 priority 100;
    node 1 priority 1;
}
/* To Core Switch */
redundancy-group 1 {
    node 1 priority 1;
    node 0 priority 100;
    preempt;
    inactive: hold-down-interval 180;
    interface-monitor {
        ge-0/0/4 weight 100;
        ge-0/0/5 weight 100;
        ge-0/0/6 weight 100;
        ge-0/0/7 weight 100;
        ge-5/0/4 weight 100;
        ge-5/0/5 weight 100;
        ge-5/0/6 weight 100;
        ge-5/0/7 weight 100;
    }
}

Sau đó, tôi sử dụng subinterface để gán IP cho mỗi VLAN. Mỗi subineterface sau đó được gán cho security zone, routered, etc.

> show configuration interfaces reth0
vlan-tagging;
redundant-ether-options {
    redundancy-group 1;
}
unit 1 {
    vlan-id 1;
    family inet {
        address 10.0.0.1/26;
    }
}
unit 2 {
    vlan-id 2;
        address 10.0.0.65/26;
    }
}
unit 3 {
    vlan-id 3;
    family inet {
        address 10.0.0.129/25;
    }
}

Physical Interfaces:

ge-0/0/4 {
    description "Link to EX-01 ae0:ge-0/0/46";
    gigether-options {
        redundant-parent reth1;
    }
}
ge-0/0/5 {
    description "Link to EX-01 ae0:ge-1/0/47";
    gigether-options {
        redundant-parent reth1;
    }
}
ge-0/0/6 {
    description "Link to EX-01 ae0:ge-0/0/44";
    gigether-options {
        redundant-parent reth1;
    }
}
ge-0/0/7 {
    description "Link to EX-01 ae0:ge-1/0/45";
    gigether-options {
        redundant-parent reth1;
    }
}



ge-5/0/4 {
    description "Link to EX-01 ae1:ge-1/0/46";
    gigether-options {
        redundant-parent reth1;
    }
}
ge-5/0/5 {
    description "Link to EX-01 ae1:ge-0/0/47";
    gigether-options {
        redundant-parent reth1;
    }
}
ge-5/0/6 {
    description "Link to EX-01 ae1:ge-0/0/45";
    gigether-options {
        redundant-parent reth1;
    }
}
ge-5/0/7 {
    description "Link to EX-01 ae1:ge-1/0/44";
    gigether-options {
        redundant-parent reth1;
    }
}

2. EX Virtual Chassis

Configuration is as simple as creating VLANs and assigning the phyiscal inerfaces to ae as per diagram above:

ae0 {
    description "links to SRX-01 node0";
    aggregated-ether-options {
        minimum-links 2;
        link-speed 1g;
        }
    unit 0 {
        family ethernet-switching {
            interface-mode trunk;
            vlan {
                members all;
            }
        }
    }
}
ae1 {
    description "links to SRX-01 node1";
    aggregated-ether-options {
        minimum-links 1;
        link-speed 1g;
    }
    unit 0 {
        family ethernet-switching {
            interface-mode trunk;
            vlan {
                members all;
            }
        }
    }
}


ge-0/0/44 {
    description "ae0:Link to SRX-01 ge-0/0/6";
    ether-options {
        802.3ad ae0;
    }
}
ge-0/0/45 {
    description "ae1:Link to SRX-01 ge-5/0/7";
    ether-options {
        802.3ad ae1;
    }
}
ge-0/0/46 {
    description "ae0:Link to SRX-01 ge-0/0/4";
    ether-options {
        802.3ad ae0;
    }
}
ge-0/0/47 {
    description "ae1:Link to SRX-01 ge-5/0/5";
    ether-options {
        802.3ad ae1;
    }
}


ge-1/0/44 {
    description "ae1:Link to SRX-01 ge-5/0/6";
    ether-options {
        802.3ad ae1;
    }
}
ge-1/0/45 {
    description "ae0:Link to SRX-01 ge-0/0/7";
    ether-options {
        802.3ad ae0;
    }
}
ge-1/0/46 {
    description "ae1:Link to SRX-01 ge-5/0/4";
    ether-options {
        802.3ad ae1;
    }
}
ge-1/0/47 {
    description "ae0:Link to SRX-01 ge-0/0/5";
    ether-options {
        802.3ad ae0;
    }
}

Juniper SRX VPN Troubleshooting

>show security ike security-associations 1.1.1.1 detail
>show security ike security-associations inactive
>show security ike active-peer
>show security ipsec security-associations vpn-name my_vpn
>show security ipsec security-associations vpn-name my_vpn traffic-selector t1
>show security ipsec inactive-tunnels
>show security ipsec statistics
>show interfaces st0.0 extensive

>show security flow session interface st0.0

>request security ike debug-enable local 173.167.224.13 remote 99.182.0.14 level 15

level 15 is a hidden command

>show security ike debug-status
>show log kmd

The below can narrow the output

>sh>show log kmd | match "ike|initiator|responder" 
>request security ike debug-disable

To troubleshoot inactive VPN

>sh>show log kmd# set system syslog file kmd-logs daemon info
# set system syslog file kmd-logs match KMD
# commit

> show log kmd-logs | match peer_IP

To show number of packets through the tunnel use the command below. Narrow done by using “index”. As in the example below, a lot of packets are encrypted, but nothing back from neighbor:

srxA-2> show security ipsec security-associations          
  Total active tunnels: 1
  ID    Algorithm       SPI      Life:sec/kb  Mon lsys Port  Gateway   
  <131073 ESP:3des/sha1 e9618669 664/  unlim   -   root 500   192.168.11.1    
  >131073 ESP:3des/sha1 eda114c0 664/  unlim   -   root 500   192.168.11.1    

srxA-2> show security ipsec statistics index 131073  
ESP Statistics:
  Encrypted bytes:            15368
  Decrypted bytes:                0
  Encrypted packets:            113
  Decrypted packets:              0
AH Statistics:
  Input bytes:                    0
  Output bytes:                   0
  Input packets:                  0
  Output packets:                 0
Errors:
  AH authentication failures: 0, Replay errors: 0
  ESP authentication failures: 0, ESP decryption failures: 0
  Bad headers: 0, Bad trailers: 0

Reading the Logs:

Phase 1:
The following is an example from Kmd Log. The most recent message is listed at the bottom. The above steps may display IKE Phase 2 and/or Phase 1 messages as below.

Successful VPN connection:

Phase-1 [responder] done for local=ipv4(udp:500,[0..3]=1.1.1.2) remote=ipv4(udp:500,[0..3]=2.2.2.2)

Phase-2 [responder] done for p1_local=ipv4(udp:500,[0..3]=1.1.1.2) p1_remote=ipv4(udp:500,[0..3]=2.2.2.2) p2_local=ipv4_subnet(any:0,[0..7]=10.10.10.0/24) p2_remote=ipv4_subnet(any:0,[0..7]=192.168.168.0/24)

Failing due to phase 1 proposal mismatch:

Phase-1 [responder] failed with error(No proposal chosen) for local=unknown(any:0,[0..0]=) remote=ipv4(any:0,[0..3]=2.2.2.2)1.1.1.2:500 (Responder) <-> 2.2.2.2:500 { 011359c9 ddef501d – 2216ed2a bfc50f5f [-1] / 0x00000000 } IP; Error = No proposal chosen (14)

Resolution: Confirm that all phase 1 proposal elements match exactly on both peers. Confirm external interface is correct.

Failing due to unrecognized peer:

Unable to find phase-1 policy as remote peer:2.2.2.2 is not recognized.KMD_PM_P1_POLICY_LOOKUP_FAILURE: Policy lookup for Phase-1 [responder] failed for p1_local=ipv4(any:0,[0..3]=1.1.1.2) p1_remote=ipv4(any:0,[0..3]=2.2.2.2)1.1.1.2:500 (Responder) <-> 2.2.2.2:500 { 18983055 dbe1d0af – a4d6d829 f9ed3bba [-1] / 0x00000000 } IP; Error = No proposal chosen (14)

Resolution: Confirm peer ID type is correct (IP address, hostname, or user@hostname). Once peer ID type is confirmed then also confirm the ID itself is correct.

Failing due to pre-shared key mismatch:

1.1.1.2:500 (Responder) <-> 2.2.2.2:500 { e9211eb9 b59d543c – 766a826d bd1d5ca1 [-1] / 0x00000000 } IP; Invalid next payload type = 17 Phase-1 [responder] failed with error(Invalid payload type) for local=unknown(any:0,[0..0]=) remote=ipv4(any:0,[0..3]=2.2.2.2)

Resolution: Re-enter pre-shared key on both peers to ensure that they match.

Failing due to phase 2 proposal mismatch:

Phase-1 [responder] done for local=ipv4(udp:500,[0..3]=1.1.1.2) remote=ipv4(udp:500,[0..3]=2.2.2.2)1.1.1.2:500 (Responder) <-> 2.2.2.2:500 { cd9dff36 4888d398 – 6b0d3933 f0bc8e26 [0] / 0x1747248b } QM; Error = No proposal chosen (14)

Resolution: Confirm all phase 2 elements match exactly on both peers. Confirm tunnel policy exists.

Failing due to phase 2 proxy ID mismatch:

Phase-1 [responder] done for local=ipv4(udp:500,[0..3]=1.1.1.2) remote=ipv4(udp:500,[0..3]=2.2.2.2) Failed to match the peer proxy ids p2_remote=ipv4_subnet(any:0,[0..7]=192.168.168.0/24) p2_local=ipv4_subnet(any:0,[0..7]=10.10.20.0/24) for the remote peer:ipv4(udp:500,[0..3]=2.2.2.2)KMD_PM_P2_POLICY_LOOKUP_FAILURE: Policy lookup for Phase-2 [responder] failed for p1_local=ipv4(udp:500,[0..3]=1.1.1.2) p1_remote=ipv4(udp:500,[0..3]=2.2.2.2) p2_local=ipv4_subnet(any:0,[0..7]=10.10.20.0/24) p2_remote=ipv4_subnet(any:0,[0..7]=192.168.168.0/24)1.1.1.2:500 (Responder) <-> 2.2.2.2:500 { 41f638eb cc22bbfe – 43fd0e85 b4f619d5 [0] / 0xc77fafcf } QM; Error = No proposal chosen (14).

Resolution: Confirm that tunnel policy has correct address book entries as well as application or service. Check to see if manual proxy-id configured on gateway.

If there are no messages; make sure the correct IP address was used. It is also possible that the Kmd Log filled up with other messages, so try to ping across the tunnel in order to attempt to bring the VPN up again. If there are still no messages, refer to KB10100- How to Troubleshoot a Site-to-Site VPN Tunnel that wont come up.

Phase 2:
Phase-2 [responder] done for p1_local=ipv4(udp:500,[0..3]=1.1.1.2) p1_remote=ipv4(udp:500,[0..3]=2.2.2.2) p2_local=ipv4_subnet(any:0,[0..7]=10.10.10.0/24) p2_remote=ipv4_subnet(any:0,[0..7]=192.168.168.0/24)

Where 2.2.2.2 is the IP address of the remote firewall in question.

Yes – See KB10093 – How to Troubleshoot a Site-to-Site VPN that is up, but, is not Passing Traffic
No – Continue with Step

The most common Phase 2 errors are:

Message: 1.1.1.2:500 (Responder) <-> 2.2.2.2:500 { cd9dff36 4888d398 – 6b0d3933 f0bc8e26 [0] / 0x1747248b } QM; Error = No proposal chosen (14)

Meaning: The JUNOS device did not accept any of the IKE Phase 2 proposals that the specified IKE peer sent.

Action: Check the local VPN configuration. Either change the local configuration to accept at least one of the remote peer’s Phase 2 proposals, or contact the remote peer’s admin and arrange for the IKE configurations at both ends of the tunnel to use at least one mutually acceptable Phase 2 proposal.

For assistance, see KB10123 – Received Message: Error = No proposal chosen (14).

Message: Failed to match the peer proxy ids p2_remote=ipv4_subnet(any:0,[0..7]=192.168.168.0/24) p2_local=ipv4_subnet(any:0,[0..7]=10.10.20.0/24) for the remote peer:ipv4(udp:500,[0..3]=2.2.2.2)

Meaning: No policy found matching the specified attributes

Action: The proxy-id must be an exact “reverse” match. For example, the address book entries must have the same number of netmask bits, the list of services must match as well as the port numbers. If any of these fields don’t match, the Phase 2 will fail. Check the address and/or service book entries.

Cấu hình truyền hình IPTV FPT với tường lửa pfSense

Nhà mạng FPT triển khai IPTV (truyền hình FPT) dựa trên giao thức IGMP, vì vậy cần phải có router hỗ trợ IGMP Proxy mới sử dụng được.

Đối với pfSense, pfSense đã tích hợp sẵn IGMP Proxy, tuy nhiên vẫn cần một số cấu hình nữa mới chạy được IPTV FPT, cách thực hiện như sau.

1. Mô hình triển khai

Firewall có 4 cổng igb0-4. Trong đó:

Cổng igb0 sẽ port WAN kết nối PPPoE đến nhà mạng FPT (cắm vào converter hoặc router FPT ở mode bridge)
Cổng igb1 chưa dùng
Cổng igb2 là cổng LAN bình thường dùng để cắm đến các thiết bị truy cập internet sử dụng dãy IP 192.168.10.0/24
Cổng igb3 là cổng dành riêng để cắm IPTV sử dụng dãy IP 192.168.20.0/24

2. Tạo interface WAN cho IPTV

Khi tạo kết nối PPPoE trên pfsense, mặc định sẽ có 1 interface PPPoE được tạo ra trên cổng vật lý đó. IGMP không thể đi chung đường PPPoE, vì vậy cần tạo thêm 1 cổng WAN nữa trên igb0 dành cho lưu lượng multicast.

Trên pfSense, vào Interface => Assignment. Chọn cổng igb0 từ danh sách Available Network Port và bấm Add

Đặt các thông số như sau:

Description: 1_WAN1_PAYTV_P0
IPv4 Type: Static
IPv6 Type: None
IPv4 Address: 169.254.254.232/32 (IP này có thể đặt tùy ý vì nó chỉ dùng để đại diện cho interface, miễn là không trùng với IP LAN và WAN)
IPv4 Gateway: None

3. Tạo interface LAN cho IPTV

Trên pfSense, vào Interface => Assignment. Chọn cổng igb3 từ danh sách Available Network Port và bấm Add

Đặt các thông số như sau:

Description: 4_IPTV_P3
IPv4 Type: Static
IPv6 Type: None
IPv4 Address: 192.168.20.1/24
IPv4 Gateway: None

Sau khi cấu hình port, vào Services => DHCP Server và chọn Interface 4_IPTV_P3

Cấu hình các thông tin như sau:

Range: 192.168.20.10 -> 192.168.20.20 (có thể mở rộng hoặc thu hẹp range tùy nhu cầu)
DNS: 210.245.31.220, 210.245.31.221 (bắt buộc dùng cặp DNS này, nếu không sẽ không phân giải được các tên miền nội bộ của IPTV)

4. Cấu hình IGMP Proxy

Sau khi cấu hình xong Interface, tiếp theo là cấu hình IGMP Proxy.

Vào Services => IGMP Proxy và chọn Enable IGMP => Save

Tại IGMP Proxy, bấm Add và lần lượt thêm 2 proxy như sau:

Interface: 1_WAN1_PAYTV_P0 (Port WAN tạo ở bước trước)
Type: Upstream Interface
Networks (Add mỗi net riêng trên 1 dòng, cảm ơn bạn Phạm Hồng Dương đã hỗ trợ thông tin này)
- 0.0.0.0/24
- 217.166.0.0/16
- 213.75.0.0/16
- 10.0.0.0/8

Interface: 4_IPTV_P3 (Port LAN tạo ở bước trước)
Type: DownstreamInterface
Networks: 192.168.20.0/24

5. Cấu hình rule firewall LAN

Vào Firewall => Rules và cấu hình các Rule như sau trên Interface 4_IPTV_P3:

Rule 1: Bấm Add và cấu hình như sau (các lựa chọn khác để mặc định):

Action: Pass
Interface: 4_IPTV_P3
Protocol: Any
Source: 4_IPTV_P3_net
Destination: Any
Bấm Display Advanced và đánh dấu chọn Allow packets with IP options to pass. Otherwise they are blocked by default. This is usually only seen with multicast traffic.

Rule 2: Bấm Add và cấu hình như sau (các lựa chọn khác để mặc định):

Action: Block
Interface: 4_IPTV_P3
Protocol: Any
Source: 4_IPTV_P3_net
Destination: 3_LAN_P2_net (ở đây chọn lớp mạng của port igb2 là port LAN theo như mô hình triển khai)

Mục đích của Rule này là để chặn không cho traffic multicast của IPTV tràn sang LAN gây nghẽn

Kiểm tra để chắc chắn thứ tự Rule như sau

6. Cấu hình rule firewall WAN

Tương tự, trên Interface 1_WAN1_PAYTV_P0 cấu hình các rule sau:

Rule 1: Bấm Add và cấu hình như sau (các lựa chọn khác để mặc định):

Action: Pass
Interface: 1_WAN1_PAYTV_P0
Protocol: UDP
Source: any
Destination: Network 224.0.0.0/4
Bấm Display Advanced và đánh dấu chọn Allow packets with IP options to pass. Otherwise they are blocked by default. This is usually only seen with multicast traffic.

Rule 2: Bấm Add và cấu hình như sau (các lựa chọn khác để mặc định):

Action: Pass
Interface: 1_WAN1_PAYTV_P0
Protocol: IGMP
Source: any
Destination: Network 224.0.0.0/4
Bấm Display Advanced và đánh dấu chọn Allow packets with IP options to pass. Otherwise they are blocked by default. This is usually only seen with multicast traffic.

Kiểm tra để chắc chắn thứ tự Rule như sau

Sau khi hoàn tất, Apply Config trên pfsense để nhận cấu hình rule mới

7. Cấu hình Bridge

Sau khi cấu hình xong Firewall, vào Interface => Assignment, sang tab Bridges và bấm Add

Tại đây chọn 2 port 1_WAN1_PAYTV_P0 và 4_IPTV_P3 (là port WAN và LAN của IPTV, giữ phím Ctrl khi chọn để chọn cùng lúc nhiều port), đặt tên tại Description và bấm Save

Lúc này, trên Bridge sẽ hiện card Bridge0, lúc này đầu thu đã có thể nhận tín hiệu truyền hình.

Chúc các bạn thành công.