目录

简介

先决条件

要求

使用的组件

背景信息

9800 WLC内部的数据包流

控制平面跟踪

系统日志

永远在线跟踪

条件调试和RadioActive跟踪

通过Web UI进行放射性跟踪

通过CLI进行放射性跟踪

每进程非条件调试

数据平面数据包跟踪

嵌入式数据包捕获

报警LED和关键平台报警

简介

本文档介绍并概述了用于Catalyst 9800故障排除的所有Cisco IOS® XE特性和功能。

先决条件

要求

- 无线LAN控制器(WLC)的基本知识。

- 使用WLC所涉及的使用案例流的基本知识。

使用的组件

本文档涵盖9800-CL、9800-L、9800-40和9800-80控制器。它主要基于17.3 Cisco IOS® XE版本。

背景信息

运行在9800 WLC上的Cisco IOS® XE基本上由采用Cisco IOS®的Linux内核(binOS)和所有作为守护程序实施的无线进程组成。

所有进程守护程序都可以捆绑在通用术语控制平面(CP)下，并负责接入点的控制和调配(CAPWAP)、移动性、无线电资源管理(RRM)。以9800 WLC为目标或从9800 WLC为目标的恶意管理、网络移动服务协议(NMSP)。

数据平面(DP)是指在9800 WLC上转发数据的组件。

在9800的所有迭代中(9800-40、9800-80、9800-CL、9800-SW、9800-L)，控制平面仍然相当常见。

但是，数据平面因9800-40和9800-80而异，它们使用类似于ASR1k的硬件量子流处理器(QFP)复合体，而9800-CL和9800-L使用思科数据包处理器(CPP)的软件实现。

9800-SW仅利用Catalyst 9k系列交换机上的Doppler芯片组来转发数据。

9800 WLC内部的数据包流

当数据包从物理端口进入9800 WLC时，如果确定它是控制流量，则将其传送至相应的控制平面进程。

对于AP加入，这将是从接入点发出的所有capwap和dtls交换。在客户端加入的情况下，这将是从客户端发出的所有流量，直到客户端进入RUN状态。

当各种守护程序处理传入流量时，产生的源自9800 WLC的返回流量（capwap响应、dot11、dot1x、dcp响应）将重新注入数据平面，从物理端口发出。

在处理AP加入、客户端加入、移动交换时，需要编程数据平面，以便其处理数据流量转发。

当多个组件在图像所示的编程路径上顺序编程时，会发生这种情况。

Cisco IOS® XE提供了一个通用工具集，从数据包进入9800 WLC的那一刻起，直至处理的流量离开机箱，都能跟踪该数据包。

下一节介绍这些工具以及用于从命令行界面(CLI)调用这些工具的命令。

控制平面跟踪

本节介绍可用于查看控制平面进程完成的处理的命令和工具，这些处理是在从DP传送适用于9800 WLC的数据包之后进行的，或在将源自9800 WLC的响应数据包注入到DP以发出物理接口之前进行的

系统日志

9800 WLC生成的日志是验证系统总体运行状况的第一种方法。

CPU、内存、缓冲区等系统资源的预定义阈值的任何违规都会报告到日志中。

此外，任何子系统生成的任何错误都将写入日志。要查看日志，请导航到故障排除>Syslog

或运行CLI命令：

# show logging

此输出显示常规日志以及一些无线特定日志。但是，与传统Cisco IOS®相反，通常没有无线调试进入此日志记录输出。

注意：如果将WLC9800配置为将这些日志重定向到外部系统日志服务器，则还需要检查外部系统日志服务器上的日志。

永远在线跟踪

WLC9800上的每个控制层面进程都不断以Notice的日志级别记录到其自己的专用缓冲区。这称为永远在线跟踪。

这是一项独特的功能，使您可以获取已发生故障时的情景数据，而无需重现故障条件。

例如，如果您熟悉AireOS，则对于任何客户端连接故障排除，您需要启用调试并重现客户端连接问题状态以确定根本原因。

通过无间断跟踪，您可以回顾已捕获的跟踪并确定其是否是常见的根本原因。  根据生成的日志量，我们可以回溯数小时到数天。

现在，虽然跟踪是按单个进程记录的，但也可以针对特定情景（如客户端mac或AP mac或AP ip地址）整体查看它们。要执行此操作，请运行命令

# show logging profile wireless filter mac  to-file bootflash:

默认情况下，此命令生成和解码日志的时间只能回溯10分钟。您可以选择与一起更早地回顾过去：

# show logging profile wireless start last <number> [minutes|hours|days] filter mac  to-file bootflash:

要查看每个进程日志，请运行命令

# show logging process  to-file bootflash:

注意：这些CLI上有多个过滤选项，包括模块、日志记录级别、开始时间戳等等。要查看和探索这些选项，请运行命令

# show logging profile wireless ?

# show logging process  ?

条件调试和RadioActive跟踪

Conditional Debugging允许为相关条件的特定功能启用调试级别日志记录。

RadioActive跟踪进一步增加了功能，可以跨进程、线程有条件地打印相关条件的调试信息。

这意味着，底层架构已完全抽象化。

注意：在16.12上，放射性跟踪仅用于排除以下故障：使用AP无线电和以太网MAC地址加入AP、使用客户端MAC地址加入客户端，以及作为关注条件的使用CMX ip地址连接移动对等体ip和CMX的移动性问题。

注意：MAC地址与IP地址作为条件提供不同的输出，因为不同的进程知道同一网络实体（AP、客户端或移动对等体）的不同标识符。

在客户端连接的情况下，作为故障排除的示例，对客户端mac运行条件调试，以在控制平面获得端到端视图。

通过Web UI进行放射性跟踪

转到故障排除页面菜单并选择放射性跟踪

单击Add并输入要排除故障的客户端或AP MAC地址。  从16.12开始，只能通过GUI添加mac地址。您可以通过CLI添加IP地址。

您可以添加多个mac地址进行跟踪。如果您已准备好开始放射性跟踪，请单击start。

启动后，调试日志记录会写入磁盘，记录与跟踪的mac地址相关的任何控制平面处理。

在重现要排除的问题时，单击Stop。

对于已调试的每个mac地址，您可以通过点击Generate生成一个日志文件，整理与该mac地址相关的所有日志。

选择希望经过整理的日志文件保留多长时间，然后点击应用到设备。

现在，您可以通过点击文件名旁边的小图标下载文件。此文件存在于控制器的Bootflash驱动器中，也可以通过CLI从盒中复制。

通过CLI进行放射性跟踪

要启用条件调试，请运行命令

# debug wireless {mac | ip} {aaaa.bbbb.cccc | x.x.x.x } {monitor-time} {N seconds}

要查看当前启用的条件，请运行命令

# show debugging

这些调试不会在终端会话上打印任何输出，但会将debug输出文件存储到闪存中，以供检索和分析。文件将使用命名约定ra_trace保存_*

例如，对于mac地址aaaa.bbbb.cccc，生成的文件名是ra_trace_MAC_aaaabbbbbbcccc_HHMMSS.XXX_timezone_DayWeek_Month_Day_year.log

一个优点是相同的命令可用于排除AP加入问题（输入AP无线电mac和以太网mac）、客户端连接问题（输入客户端mac）、移动隧道问题（输入对等ip）、客户端漫游问题（输入客户端mac）。

换句话说，您不必记住多个命令，例如debug capwap、debug client、debug mobility等。

注意：debug wireless还允许指向FTP服务器并使用关键字internal运行更详细的日志记录。目前我们不推荐这些解决方案，因为有些问题正在解决。

要调试终端会话的输出文件，请运行命令

# more bootflash:ra_trace_MAC_*.log

要将调试输出重定向到外部服务器进行脱机分析，请运行该命令

# copy bootflash:ra_trace_MAC_*.log ftp://username:password@FTPSERVERIP/path/RATRACE_FILENAME.txt

对于相同的调试日志级别，有更详细的视图。若要查看此详细视图，请运行命令

# show logging profile wireless internal filter mac  to-file

要禁用特定情景的调试，或者在配置的或默认监控时间启用之前禁用调试，请运行该命令。

# no debug wireless mac <aaaa.bbbb.cccc>

注意：条件调试会启用调试级别日志记录，从而增加生成的日志量。保持此运行状态可缩短查看日志的时间间隔。因此，建议在故障排除会话结束时始终禁用调试。

要禁用所有调试，请运行以下命令

# clear platform condition all

# undebug all

每进程非条件调试

对于使用案例和进程（未针对放射性跟踪实施），您可以获取调试级别跟踪。要在特定进程上设置调试级别，请使用命令

# set platform software trace <PROCESS_NAME> wireless chassis active R0 { module_name | all-modules }

要验证各种模块的跟踪级别，请运行命令

# show platform software trace level <PROCESS_NAME> chassis active R0

要查看收集的跟踪，请运行命令

# show logging process  to-file

数据平面数据包跟踪

当数据包首次进入9800 WLC时，会在数据平面进行某些处理，以确定流量是控制平面还是数据平面。

数据包跟踪功能提供在数据平面完成的此Cisco IOS® XE处理的详细视图，以及决定是传送、转发、丢弃还是使用数据包。

WLC 9800上的此功能与ASR！k上的实现完全相同。

9800 WLC上的Packet Tracer提供与ASR1K相同的三个检测级别。

- 统计信息-提供进入和离开网络处理器的数据包计数

- 摘要-

- 收集此信息是为了满足特定条件且数量有限的数据包。

- 摘要输出指示入口和出口接口、数据平面作出的查找决策，并跟踪传送、丢弃和插入数据包（如果有）。

- 此输出提供数据平面处理的简明视图

- 路径数据-提供DP数据包处理的最详细视图。它针对有限数量的数据包进行收集，包括条件调试ID，可用于将DP数据包与控制平面调试、时间戳以及特定于功能的路径跟踪数据相关联。此详细视图有两个可选功能

- 数据包复制功能使您能够在数据包的各个层（第2层、第3层和第4层）复制入口和出口数据包

- 功能调用阵列(FIA)是由数据平面在数据包上执行的功能的顺序列表。这些功能源自WLC 9800的默认和用户启用的配置

有关功能和子选项的详细说明，请参阅Cisco IOS XE数据路径数据包跟踪功能

对于AP加入、客户端连接等无线工作流程，双向跟踪上行链路

注意：数据平面Packet Tracer仅解析外部CAPWAP报头。因此，无线客户端mac之类的条件不会产生有用的输出。

步骤1:定义关注条件。

# debug platform condition { interface | mac | ingress | egress | both | ipv4 | ipv6 | mpls | match }

警告：debug platform condition feature和debug platform condition mac aaaa.bbbb.cccc这两个命令用于控制层面数据包跟踪，不会返回任何数据层面数据包跟踪。

第二步：要查看当前启用的条件，请运行命令

# show platform conditions

第三步：对有限数量的数据包启用Packet Tracer。此数据包编号在16 ― 8192范围内被定义为2的幂。默认情况下，系统会捕获摘要数据和功能数据。或者，如果使用summary-only子选项，您可以选择仅获取摘要视图。您还有可用于获取fia跟踪、定义以字节为单位的数据包大小、跟踪传送、插入或丢弃数据包的子选项，等等。

# debug platform packet-tracer packet <packet-number> {fia-trace}

步骤4. （可选）您可以在跟踪数据包时复制并转储这些数据包

# debug platform packet-trace copy packet both size 2048 { l2 | l3 | l4 }

第五步：启用条件调试。

# debug platform condition start

第六步：要查看packet-trace是否正在收集任何输出，请验证统计信息

# show platform packet-trace statistics

步骤 7.要查看packet-trace的输出，请运行命令

# show platform packet-tracer summary

第8步（可选）您可以导出数据包转储以供思科TAC进行离线分析

# show platform packet-trace packet all | redirect { bootflash: | tftp: | ftp: } pactrac.txt

嵌入式数据包捕获

嵌入式数据包捕获(EPC)是一种数据包捕获工具，可用于查看发往、源自和通过Catalyst 9800 WLC的数据包。这些捕获可以导出，以便使用Wireshark进行离线分析。

有关此功能的详细信息，请参阅EPC配置指南

与AireOS相比，9800 WLC无需依赖上行链路交换机上的数据包捕获和流量镜像功能，而是允许在设备上进行pcap捕获。

在9800上，可以从命令行界面(CLI)和图形用户界面(GUI)设置此捕获。

要通过GUI进行配置，请导航到故障排除>数据包捕获> +Add

步骤1:定义数据包捕获的名称。最多允许8个字符。

第二步：定义过滤器（如果有）

第三步：如果想要查看传送至系统CPU并注入数据平面的流量，请选中监控控制流量的复选框

第四步：定义缓冲区大小。最多允许100 MB

第五步：根据需要定义限制，按允许范围为1 - 1000000秒的持续时间或按允许范围为1 - 100000个数据包的数据包数量

第六步：从左侧列中的接口列表中选择接口，并选择箭头将其移动到右侧列

步骤 7.保存并应用到设备

步骤 8要开始捕获，请选择开始

步骤 9您可以让捕获运行到定义的限制。要手动停止捕获，请选择停止。

步骤 10停止后，Export按钮变为可单击状态，其中包含用于通过https、TFTP服务器、FTP服务器、本地系统硬盘或闪存将捕获文件(.pcap)下载到本地桌面的选项。

注意：CLI提供的选项精细程度稍高，例如Limit by。GUI足以捕获常见使用案例的数据包。

要通过CLI进行配置，请执行以下操作：

创建监控器捕获：

monitor capture uplink interface <uplink_of_the_9800> both

关联过滤器。可以内联指定过滤器，也可以引用ACL或类映射。

在本例中，ACL用于匹配9800的两个IP地址与另一个WLC 5520之间的流量。移动性故障排除的典型场景：

conf t

ip access-list extended mobilitywlcs

permit ip host <5520_ip_address> host <9800_ip_address>

permit ip host <9800_ip_address> host <5520_ip_address>

end

monitor capture uplink access-list mobilitywlcs

如果您希望捕获在循环缓冲区中运行，它可留出一些时间来发现问题，然后停止捕获并保存它。

例如，如果将其设置为50MB缓冲区。在9800上最多需要50MB的磁盘空间，而且它非常庞大，需要捕获几分钟数据才能解决问题。

monitor capture uplink buffer circular size 50

开始捕获。您可以从GUI或CLI对其进行访问：

monitor capture uplink start

捕获现在处于活动状态。

允许它收集必要数据。

停止捕获。您可以通过GUI或CLI执行此操作：

monitor capture uplink stop

您可以从GUI > Troubleshooting > Packet Capture > Export检索捕获。

或从CLI上载到服务器。示例通过ftp：

monitor capture uplink export ftp://x.x.x.x/MobilityCAP.pcap

收集完必要的数据后，删除捕获：

no monitor capture uplink

报警LED和关键平台报警

所有9800设备（9800-L、9800-40和9800-80）的前面板上都有ALM LED。如果该LED变为红色，则意味着平台上有一个严重警报。

您可以使用show facility-alarm status命令验证导致LED变为红色的警报

WLC#show facility-alarm status

System Totals  Critical: 2  Major: 0  Minor: 0

Source                     Time                   Severity      Description [Index]

------                     ------                 --------      -------------------

TenGigabitEthernet0/1/0    Jul 26 2019 15:14:04   CRITICAL      Physical Port Link Down [1]

TenGigabitEthernet0/1/1    Jul 26 2019 15:14:04   CRITICAL      Physical Port Link Down [1]