AP, WLC và quá trình client kết nối WLAN
Tách tiến trình AP join Catalyst9800 khỏi client kết nối WLAN. Theo dõi policy, security, VLAN và central/FlexConnect switching tới DHCP, DNS và ứng dụng.
AP đã xuất hiện trên controller và SSID đã phát, nhưng một laptop không nhận được IP. Reset AP ngay có thể làm các client đang tốt bị ngắt, trong khi lỗi của laptop nằm ở policy VLAN hoặc DHCP. “AP joined” và “client dùng được ứng dụng” là hai mốc khác nhau.
Bài này theo dõi AP kết nối Catalyst 9800, sau đó theo một client qua WLAN, bảo mật, IP và dịch vụ. Mỗi mốc có bảng trạng thái và đường dữ liệu riêng để kiểm tra, không dùng một chữ Connected để kết luận toàn bộ hệ thống tốt.
1. Chốt central switching trước khi phân tích VLAN
Lab biên tập có AP quản trị10.99.0.20, wireless management của WLC 10.99.0.10 và đường IP giữa hai bên đã chuẩn bị. Client dùng SSID LAB-CORP, ánh xạ policy vào VLAN 20, mạng 10.20.0.0/24, gateway10.20.0.1. DHCP server 10.99.0.30 và DNS10.99.0.53 có route/relay thích hợp.
Trong ví dụ chính, AP local mode, client traffic central switched qua WLC rồi vào VLAN 20 của mạng dây. VLAN quản trị AP và VLAN dữ liệu client có vai trò khác nhau. Không bắt buộc port switch của AP phải mang mọi VLAN client chỉ vì WLC dùng các VLAN ấy; điểm bridge dữ liệu trong mô hình nằm phía WLC.
Cuộn ngang khi cần, hoặc chạm sơ đồ để mở ảnh gốc.
Nguồn và lệnh minh họa Catalyst9800 IOS XE, chưa thực thi hardware. Không dùng lệnh AireOS cũ thay tương đương một cách máy móc. AP model, image, WLC release, regulatory domain và khả năng/licensing phải được xác nhận bằng ma trận hỗ trợ hiện hành trước triển khai.
2. AP lấy IP, tìm controller rồi thiết lập quan hệ điều khiển
AP cần link/PoE phù hợp, địa chỉ quản trị, route và cách tìm controller. Discovery có thể dùng thông tin cấu hình trước, DHCP/DNS hoặc phương thức được hỗ trợ; không phải mọi AP chỉ dùng một cách duy nhất. Khi discovery thất bại, kiểm tra nguồn dữ kiện và đường management thay vì sửa VLAN client chưa được dùng tới.
Tiến trình tiếp theo liên quan thiết lập CAPWAP/DTLS, kiểm tra join, trao đổi cấu hình và image theo trạng thái. Chứng thư, thời gian, tương thích phần mềm và điều kiện mạng có thể ngăn AP đi tiếp. Một discovery request tới WLC chưa chứng minh join hoặc tải cấu hình thành công.
CAPWAP thường dùng UDP 5246 cho control và5247 cho data theo cơ chế được triển khai; cần xem thêm điều kiện DTLS, MTU, policy và mode của nền tảng. Không suy “ping được WLC” là hai cổng giao thức và mọi gói kích thước cần thiết đều qua được.
Cisco mô tả AP join với Catalyst9800 và luồng chẩn đoán AP join/disconnection. Dùng reason/state theo đúng thời điểm, không reset cả controller khi mới thấy thiếu một AP.
3. Client thấy SSID, associate và thiết lập bảo mật
Client nghe beacon hoặc dùng cơ chế tìm mạng phù hợp, chọn BSSID/radio theo hành vi và policy của nó. Cùng SSID có thể hiện ở nhiều AP, nên cần MAC/BSSID, băng tần và thời gian để ghép đúng sự kiện. Client quyết định roaming với tác động từ nhiều cơ chế mạng; không mặc định WLC ép mọi lần chuyển AP theo một ngưỡng RSSI duy nhất.
Client đi qua các bước802.11 authentication/association và thiết lập bảo mật phù hợp AKM. Từ authentication ở lớp802.11 không luôn đồng nghĩa đã kiểm tra mật khẩu doanh nghiệp. Với WPA2-Personal, quy trình khác WPA3-SAE; với Enterprise còn có802.1X/EAP và AAA theo thiết kế. Không vẽ một handshake duy nhất rồi gọi nó đúng cho mọi SSID.
Cuộn ngang khi cần, hoặc chạm sơ đồ để mở ảnh gốc.
Sau khi điều kiện bảo mật/key đạt, client mới đủ điều kiện dùng đường dữ liệu theo policy. DHCP có thể cấp IP, rồi client dùng gateway/DNS để tới ứng dụng. “Đã associate” chưa chứng minh đã có key, IP hoặc quyền truy cập. Ngược lại, một entry cache còn trong bảng cũng cần kiểm tra trạng thái/timestamp trước khi nhận là phiên đang hoạt động.
Đọc nền RF và WPA2/WPA3 để giữ riêng vấn đề tương thích radio/bảo mật. Một SSID không thấy có thể do băng tần/client/domain hoặc cấu hình phát; một client thấy nhưng auth fail cần bằng chứng khác với client đã auth nhưng DHCP fail.
4. WLAN, policy và điểm switching quyết định dữ liệu đi đâu
Trong mô hình Catalyst9800, WLAN profile mô tả SSID/security, policy profile chứa các thuộc tính như VLAN và switching. Policy tag liên kết các profile để AP áp dụng; site/RF tag có nhiệm vụ khác. Tên SSID hiển thị đúng không chứng minh AP đã được gắn đúng policy VLAN hoặc mode switching.
Với central switching, kiểm tra đường CAPWAP/data và phần VLAN/policy phía WLC. Nếu đổi sang FlexConnect local switching, AP đưa client data vào VLAN trên mạng dây tại site; port switch phía AP có thể cần trunk/allowed/native và mapping theo thiết kế. Không chuyển mode chỉ để né lỗi mà chưa rà đường DHCP, gateway và policy mới.
Hướng dẫn FlexConnect của Cisco phân biệt central/local switching và authentication. Local switching không tự nghĩa mọi xác thực đều local hoặc mất WAN thì mọi client mới chắc chắn vẫn vào được. Hành vi phụ thuộc policy, khả năng AP và dịch vụ ở site.
Lab chính vẫn dùng central switching. Nếu client đã auth nhưng không có IP, đối chiếu policy đang áp, VLAN 20 ở đúng điểm bridge, helper/route tới DHCP và phản hồi về. Thêm VLAN 20 vào AP port trong khi WLC đang bridge tập trung có thể không xử lý được nguyên nhân.
5. Đọc trạng thái AP và một client riêng, tránh đoán từ tổng số
Các lệnh đọc minh họa trên Catalyst9800, cần đối chiếu cú pháp release:
show ap summary
show ap uptime
show wireless stats ap discovery
show wireless stats ap join summary
show wireless client summary
show wireless client mac 0200.0000.0020 detailMAC 0200.0000.0020 là định danh biên tập cho client lab, cần thay bằng MAC của phiên thực tế. Cơ chế private/random MAC có thể khiến địa chỉ thay giữa các SSID hoặc lần dùng; giữ mốc thời gian và BSSID để tránh điều tra nhầm thiết bị.
So AP uptime với thời gian AP gắn controller. Uptime thấp ở nhiều AP cùng switch gợi ý kiểm tra nguồn/PoE/switch; AP còn uptime cao nhưng association time thấp gợi nhóm lỗi control path/join khác. Đây là hướng khoanh vùng, chưa là kết luận nguyên nhân duy nhất.
Trên client detail, đọc AP/radio, WLAN/policy, security state, VLAN, IP và reason khi bị xóa/không vào được. Cisco cung cấp luồng kiểm tra client connectivity. Trạng thái RUN theo WLC cho biết một mốc của phiên, không phải phép thử end-to-end tới server ứng dụng.
Cuộn ngang khi cần, hoặc chạm sơ đồ để mở ảnh gốc.
6. Điều tra một lỗi IP mà không làm gián đoạn cả WLAN
Giả sử AP đã joined, client detail cho thấy security đạt nhưng chưa có IP. Thu policy/VLAN hiện hành và DORA ở đường dữ liệu đã chọn. Nếu server nhận Discover mà không Offer, kiểm tra scope/policy; nếu có ACK nhưng client không nhận, theo đường về, tagging và các tính năng bảo vệ như snooping. Đọc DHCP/relay với đúng context switching.
Nếu đã có IP/gateway và DNS trả đúng tên, chuyển sang route/TCP/TLS thay vì sửa join profile AP. Nếu chỉ một client lỗi còn máy đối chứng cùng AP/policy tốt, đối chiếu driver, security capability, MAC/policy riêng và cấu hình IP. Máy đối chứng ở SSID hoặc mode khác chưa đủ để loại trừ WLAN.
Trace/debug wireless có thể tạo tải và lượng dữ liệu lớn. Chỉ thu theo MAC, thời gian và quy trình được phép, giữ dữ liệu cấu hình/định danh phù hợp quyền truy cập. Không bật debug không giới hạn hoặc xóa toàn bộ client để “lấy lại trạng thái sạch”. Reset AP, đổi policy/SSID/security có thể ngắt nhiều người dùng, cần cửa sổ và phương án quay lại.
Khi chỉ một AP không join, so model/image, nguồn discovery, chứng thư/thời gian và management path của nó với AP đã hoạt động cùng điều kiện. Khi nhiều AP khác switch mất kết nối cùng lúc, mở rộng đối chiếu WLC, đường chung và mốc thay đổi. Hai tình huống không nên nhận cùng một bước reset. Giữ reason đầu tiên và chuỗi sự kiện trước khi trạng thái bị thay bởi lần thử mới.
Một phép thử có giá trị là client đối chứng cùng AP, radio, WLAN và policy tại thời điểm gần nhau. Nếu client đối chứng nhận IP còn client lỗi không nhận, xem security state, MAC/policy riêng và gói DHCP của đúng phiên. Nếu cả hai lỗi nhưng client trên SSID khác tốt, chưa thể loại VLAN hoặc policy của SSID đang xét. So đúng điều kiện giúp giảm số thay đổi không cần thiết.
Trước đổi central sang local switching, viết lại đường frame client và vị trí gateway/relay ở site. AP vẫn liên lạc controller không có nghĩa VLAN mới đã được kéo tới switchport của AP. Ngược lại, một trunk mang đủ VLAN cũng không chứng minh policy mapping trên AP đúng. Cần bằng chứng tại cả nơi quyết định policy và nơi bridge gói, thay vì chỉ sửa allowed list rồi chờ mạng tự đúng.
7. Nghiệm thu hai tiến trình và đường tới ứng dụng
Kiểm tra AP ổn định qua khoảng thời gian phù hợp triệu chứng, client thử kết nối mới, nhận đúng IP/VLAN và truy cập ứng dụng bằng hostname. Nếu cần thử roaming, ghi BSSID trước/sau và ảnh hưởng tới ứng dụng; ping liên tục không thay xác nhận cuộc gọi hoặc phiên đặc thù.
- AP management, discovery, DTLS/join và image được kiểm tra riêng.
- Client được ghép đúng MAC/BSSID/timestamp và AKM phù hợp.
- WLAN/policy/tag và central/local switching khớp topology.
- IP, DNS, route và dịch vụ được thử sau trạng thái WLAN.
- Giữ reason/log trước thay đổi, phạm vi tác động và đường phục hồi.
Không tìm thấy chuyên đề WLC/CAPWAP trong text PDF đã trích xuất; phần này là bổ sung theo Cisco Catalyst9800. Topology, MAC và ba sơ đồ được dựng mới, không phải ảnh cấu hình thật. Chưa chạy lab hardware. Bài vận hành mạng Cisco sẽ nối thông tin trạng thái với backup, thời gian và giám sát để điều tra có thể lặp lại.