Cisco 9800 WLC – Client tự động mất kết nối (Client Disconnections)

Gần đây tôi phải xử lý một vài trường hợp client tự động mất kết nối trong hệ thống mạng wireless cisco và sự cố này khá phổ biến. Bài viết này sẽ đề cập đến cách khắc phục một số sự cố thường gặp nhất trên Cisco 9800 Wireless LAN Controller. Hầu hết các sự cố được đề cập ở đây cũng áp dụng cho các AireOS WLCs.

Session Timeout

Recommendation:

Session timeout = 3600 seconds

Session timeout là khoảng thời gian mà sau đó client sẽ bị kicked out khỏi mạng và buộc phải xác thực lại. Trên các phiên bản Catalyst 9800 WLC cũ hơn, giá trị này theo mặc định được đặt thành 1800 giây (30 phút), điều này rất nghiêm trọng và gây ra nhiều lần ngắt kết nối không mong muốn. Các phiên bản mới hơn đã tăng giá trị mặc định lên 43200 giây (12 giờ).

Đặt giá trị thành 0 không có nghĩa là thời gian chờ là vô hạn và không được khuyến khích vì nó có thể ngăn client thực hiện roaming nhanh trên một số bản phát hành 9800.

Tuy nhiên, bạn nên tăng giá trị này lên 1 ngày (86400 giây ). Có thể thực hiện việc này thông qua CLI theo cấu hình policy profile:

configure terminal
wireless profile policy <Policy-profile-name>
 session-timeout 3600

webUI

2. Idle Timeout

Recommendation:

Idle timeout = 3600 seconds

Thời gian Idle Timeout thể hiện khoảng thời gian mà sau đó client sẽ bị loại khỏi mạng nếu không gửi bất kỳ dữ liệu nào. Theo mặc định, giá trị này được đặt là 300 giây (5 phút), một con số quá cao. Nhiều thiết bị client, đặc biệt là điện thoại IP, có xu hướng chuyển sang chế độ ngủ lâu hơn 5 phút, dẫn đến tình trạng hết thời gian chờ..

Khi client vô tình rời khỏi mạng, dữ liệu cũ có thể vẫn nằm trên WLC trong suốt thời gian Timeout, do đó không nên tăng giá trị này quá nhiều. Nên tăng giá trị này lên 3600 giây (1 giờ).

Có thể thay đổi theo cấu hình chính sách bằng cách sử dụng các lệnh:

conf t
wireless profile policy <Policy-profile-name>
 idle-timeout 3600

webUI

Fast Roaming (802.11r) & OKC

Recommendation:

FT = Enabled
Over the DS = Disabled

Auth Key Mgmt = 802.1x & FT+802.1x
OKC = Enabled

Nếu không có giao thức fast roaming, việc di chuyển giữa 2 access points sẽ khiến thiết bị client phải thực hiện lại quy trình xác thực đầy đủ. Đối với các mạng open và bảo mật PSK, điều này không sao cả, vì các loại xác thực này thường nhanh. Tuy nhiên, đối với các mạng bảo mật dạng dot1x, quá trình xác thực đầy đủ có thể mất tới hơn 1 giây. Điều này có nghĩa là mỗi khi client của bạn thay đổi AP, bạn sẽ gặp phải khoảng cách 1 giây trở lên, điều này có thể rất dễ nhận thấy nếu người dùng đang thực hiện cuộc gọi thoại/video.

Giao thức fast roaming 802.11r cho phép client roaming trong vòng vài mili giây. Giao thức này có thể được đặt thành chế độ tắt, bật, thích ứng và được gọi là “chế độ hỗn hợp”, có hoặc không có chế độ Over the DS. Tùy chọn Over the DS không được nhiều thiết bị client hỗ trợ, vì vậy nên tắt nó và sử dụng chế độ mặc định, over the air mode

Adaptive mode là chế độ đặc biệt được hỗ trợ chủ yếu bởi điện thoại thông minh Apple và Samsung, cho phép chỉ những điện thoại này roaming nhanh.

Chỉ cần đặt FT thành Bật sẽ chỉ cho phép các thiết bị khách hỗ trợ FT tham gia mạng. Các thiết bị không hỗ trợ FT sẽ không được phép tham gia.

Tuy nhiên, việc đặt FT thành Bật và thay đổi tùy chọn Quản lý Khóa Xác thực thành 802.1x & FT+802.1X sẽ đặt nó ở chế độ được gọi là “mixed” mode, trong đó cả client hỗ trợ và không hỗ trợ Fast Roaming đều có thể tham gia. Đây là chế độ được khuyến nghị và tương thích với nhiều thiết bị client nhất.

Để thiết lập Mixed mode FT, hãy chạy lệnh trong cấu hình WLAN:

conf t
wlan <Profile-Name> 1 <SSID-name>
 security ft
 security wpa akm ft dot1x

webUI:

Một giải pháp thay thế cho các thiết bị không hỗ trợ 802.11r là thuật toán  OKC. Thuật toán này chậm hơn một chút so với 802.11r Fast Roaming và được bật theo mặc định, vì vậy bạn nên giữ nguyên chế độ này.

DCA Algorithm Interval

Recommendation:

2.4 GHz DCA interval = 4 hours

5 GHz DCA interval = 8 or 12 hours

6 GHz DCA Interval = 8 or 12 hours

Thuật toán Dynamic Channel Assignment là một quy trình chịu trách nhiệm gán kênh cho tất cả các AP và chạy theo mặc định cứ sau 10 phút. Điều này có nghĩa là kênh AP có thể thay đổi sau mỗi 10 phút, làm tăng khả năng  khả năng client  bị ngắt kết nối.

Cấu hình khoảng thời gian cho thuật toán DCA bằng lệnh:

configure terminal
ap dot11 24ghz rrm channel dca interval 4
ap dot11 5ghz rrm channel dca interval 12
ap dot11 6ghz rrm channel dca interval 12

WebUI – Configuration > RRM > 2.4/5/6 GHz > DCA

DCA Channel Width

Recommendation:

On 5 GHz — Static 20/40 MHz

On 6 GHz — Static 20/40/80 MHz

Việc thiết lập độ rộng kênh giúp client dễ dàng quét toàn bộ mạng. Nếu client đã kết nối với kênh 20 MHz, trước tiên nó sẽ quét tất cả các kênh 20 MHz trước khi bắt đầu quét các kênh 40 MHz. Việc thiết lập độ rộng kênh thành “Best” cho phép kết hợp các kênh có độ rộng 20/40/80 MHz trong mạng, giúp làm chậm quá trình chuyển vùng.

Để đảm bảo roaming đáng tin cậy hơn, chúng tôi khuyến nghị giữ nguyên độ rộng kênh trên tất cả các AP. Do số lượng kênh khả dụng trên băng tần 5GHz khá lớn và không nên bật kênh rộng 80 MHz trong môi trường văn phòng thông thường.

Có thể thực hiện thay đổi theo cấu hình RF bằng cách sử dụng lệnh:

configure terminal
 ap dot11 5ghz rrm channel dca chan-width 20
ap dot11 5ghz rf-profile <RF-Profile-Name>
 channel chan-width 20
ap dot11 6ghz rf-profile <RF-Profile-Name>
 channel chan-width 20

webUI

Global config — value set to Best

EAP Broadcast Key Interval

Recommendation:

EAP-Broadcast Key Interval = 86400

Theo mặc định, AP và tất cả các clients được kết nối sẽ thương lượng lại khóa phát sóng sau mỗi 1 giờ. Điều này có nghĩa là người dùng văn phòng trung bình phải thực hiện trao đổi này 8 lần mỗi ngày, làm tăng khả năng xảy ra sự cố.

Rất thường xảy ra trường hợp clients đang ở chế độ ngủ và không phản hồi gói tin M5 đến từ AP yêu cầu trao đổi khóa phát sóng, dẫn đến client bị xóa do lý do xóa

CO_CLIENT_DELETE_REASON_GROUP_KEY_UPDATE_TIMEOUT.

Nên tăng giá trị này lên 1 ngày (86400 giây)

wireless security dot1x group-key interval 86400

hoặc trong webUI tại mục Configuration > EAP

EAP Request & EAP Identity Request Timeout And Retries

Recommendation:

EAP-Identity-Request Timeout = 1s
EAP-Identity-Request Max Retries = 10

EAP-Request Timeout = 1s
EAP-Request Max Retries = 10

Client driver upgrade

Khi các client dot1x không hỗ trợ Fast Roaming và phải di chuyển từ AP này sang AP khác, chúng phải thực hiện xác thực dot1x đầy đủ, bao gồm toàn bộ quá trình trao đổi EAP.

Trong quá trình trao đổi này, WLC gửi 2 gói tin quan trọng: yêu cầu Nhận dạng EAP và yêu cầu EAP, mà client được kỳ vọng sẽ phản hồi. Nếu client không phản hồi, WLC sẽ đợi 30 giây để truyền lại gói tin. Nó thử tổng cộng 2 lần trước khi từ bỏ và loại client ra. Điều này có nghĩa là nếu client không phản hồi, toàn bộ quá trình có thể mất đến một phút để thất bại.

Thông thường, do lỗi phía trình điều khiển, thiết bị không phản hồi gói tin yêu cầu Danh tính. Sự cố này thường đi kèm với lỗi CO_CLIENT_DELETE_REASON_CLIENT_EAP_TIMEOUT_FAILURE và lỗi CO_CLIENT_DELETE_REASON_CLIENT_EAP_ID_TIMEOUT, cùng lỗi 5440 Endpoint đã hủy phiên EAP và bắt đầu lại trên Cisco ISE.

Việc đặt giá trị này thành 10 lần thử lại mỗi 1 giây sẽ đảm bảo WLC cố gắng kết nối với client mạnh mẽ hơn. Việc thay đổi các giá trị này không đảm bảo sự cố sẽ được giải quyết. Cách duy nhất để khắc phục là nâng cấp trình điều khiển của thiết bị và hy vọng thiết bị client sẽ bắt đầu phản hồi các gói tin yêu cầu EAP (nhận dạng).

Timers có thể được cấu hình bằng cách sử dụng

conf t
wireless security dot1x identity-request retries 10
wireless security dot1x identity-request timeout 1
wireless security dot1x request retries 10
wireless security dot1x request timeout 1

webUI under Configuration > Advanced EAP

WPA3 & PMF

Recommendation:

WPA3 Policy = Disabled

PMF = Disabled

WPA3 và Protected Management Frame (PMF) đã ra mắt được một vài năm, nhưng vẫn còn rất nhiều vấn đề cần giải quyết với nhiều thiết bị client cũ.

Bạn nên tắt WPA3 và Protected Management Frame (PMF), đặc biệt là trên mạng mà bạn không có quyền kiểm soát client. Bạn có thể thực hiện việc này thông qua giao diện webUI trong phần cấu hình WLAN

DHCP Required

Recommendation:

DHCP Required = Disabled

Khi bật tính năng này, các thiết bị client được yêu cầu thực hiện DHCP mỗi khi tham gia mạng. Tất cả các máy khách đều thực hiện việc này theo mặc định. Tuy nhiên, vấn đề sẽ phát sinh khi chúng bắt đầu chuyển vùng.

Hầu hết thời gian, các thiết bị sẽ chỉ thực hiện một phần của quy trình DHCP DORA (Khám phá — Đề nghị — Yêu cầu — Xác nhận) khi di chuyển từ AP này sang AP khác bằng cách chỉ trao đổi Request + ACK để tăng tốc độ chuyển vùng. Tuy nhiên, một số thiết bị, sau khi di chuyển từ AP này sang AP khác, sẽ quyết định không thực hiện DHCP nữa và chỉ sử dụng lại địa chỉ cũ — về cơ bản hoạt động như một client với địa chỉ IP tĩnh.

Khi tùy chọn DHCP Required được bật, những thiết bị không thực hiện DHCP sau khi roaming sẽ không được phép tham gia và cuối cùng sẽ bị kick out. Thông thường, chúng sẽ tự động phục hồi sau khi bị kick out bằng cách thực hiện lại toàn bộ quy trình DHCP DORA, nhưng điều này vẫn sẽ gây ra khoảng cách kết nối đáng kể. Những sự cố này thường đi kèm với lý do CO_CLIENT_DELETE_REASON_IPLEARN_CONNECT_TIMEOUT hoặc CO_CLIENT_DELETE_REASON_MN_AP_IPLEARN_TIMEOUT trong trường hợp triển khai flex connect.

Tùy chọn này chỉ áp dụng cho các client thực hiện roaming chậm 802.11i (về cơ bản là xác thực đầy đủ khi roaming từ AP này sang AP khác). Tùy chọn này không áp dụng cho các máy khách thực hiện OKC hoặc Roaming nhanh 802.11. Lưu ý rằng các máy khách hỗ trợ Roaming nhanh 802.11 đôi khi có thể không thực hiện roaming nhanh và chọn không thực hiện roaming chậm, xác thực đầy đủ.

Bạn nên tắt tính năng này trong policy profile bằng lệnh:

configure terminal
wireless profile policy <Policy-profile-name>
 ipv4 dhcp required

WebUI

RX-SOP

Recommendation:

RX-SOP = Auto (disabled)

RX-SOP là một tính năng cho phép AP loại bỏ tất cả các gói tin được nhận ở cường độ tín hiệu yếu hơn cường độ tín hiệu được cấu hình. Mục đích của tính năng này là để AP loại bỏ các gói tin được gửi bởi các client ở rất xa AP, với hy vọng rằng client sẽ nhận ra rằng AP không phản hồi và cố gắng chuyển đến một AP mới.

Nó cung cấp 4 giá trị. 3 giá trị được xác định trước và một giá trị tùy chỉnh:

Cao = -79 dBm trên 2,4 GHz và -76 dBm trên 5 GHz

Trung bình = -82 dBm trên 2,4 GHz và -78 dBm trên 5 GHz

Thấp = -85 dBm trên 2,4 GHz và -80 dBm trên 5 GHz

Tùy chỉnh = được xác định bởi người dùng

Trên thực tế, tính năng này hầu như không ảnh hưởng đến quyết định roaming của client. Các thử nghiệm của tôi với MacBook và điện thoại Android cho thấy các client cố định (sticky client) sẽ liên tục cố gắng kết nối với một AP ở xa và việc bật RX-SOP hầu như không ảnh hưởng gì đến quyết định roaming. Kết quả duy nhất của việc bật RX-SOP là thay vì kết nối/tín hiệu kém khi cố gắng kết nối với một AP ở xa, client sẽ không có kết nối nào cả do các gói tin bị loại bỏ bởi RX-SOP.

Tính năng này phải được tắt (đặt thành Auto) trên globally hoặc trong cấu hình RF, tùy thuộc vào mục.

configure terminal
 ap dot11 5ghz rx-sop threshold auth
 ap dot11 24ghz rx-sop threshold auth

 ap dot11 24ghz rf-profile <24GHz-RF-profile-name>
  high-density rx-sop threshold auto
 ap dot11 5ghz rf-profile <5GHz-RF-profile-name>
  high-density rx-sop threshold auto

WebUI: