应用识别策略如何核验

应用识别策略如何核验，要看会议、备份、网页这些流量是不是真的走到了你指定的那条线上。策略页面里多了一行规则，只能说明有人保存过配置，不能说明识别已经对上了公司正在用的软件。

先把要识别的应用和期望路径写在一张表上。例如视频会议走专线，普通上网走宽带，夜里的备份可以走便宜的出口。表上每一行只留一个下一跳。两行都能配上同一条流量时，先把范围改窄，再谈核验。默认规则单独占一行，写明它接到哪条线，因为没被认出来的新版本软件，最后都会掉进这一行。

核验用公司真实的客户端。不要拿一个名字相近的网页测试工具代替会议软件。客户端版本也要记下来。加密方式或版本一变，设备可能不再把它认成原来的名字，流量就不再命中你以为的那条规则。所以核验记录里要有软件名、版本和当天的命中次数。次数不增加，先确认你看的是不是这台设备、这个统计周期里的那一个计数。有的平台计数会延迟，有的计数在另一张报表上。次数没动，是要继续查的线索，不是已经证明规则失效。

规则顺序经常是实际原因。更具体的规则排在后面，会被前面那条宽规则截走。把会议规则移到默认规则前面，再发起一次会议，看专线统计是否上升、宽带上是否没有这段流量。有的平台挂断后计数会停，有的平台要等统计周期刷新，不要把「挂断后立刻停」写成所有设备的通例。挂断后计数仍在涨，先核对是不是混进了别的会话，再决定这次算不算通过。

这篇没有绑定某一家设备的型号和软件版本。计数器怎么命名、回退怎么点，以你这台设备当时的手册为准。改之前导出上一版，失败就回到那一版。下面说的是核对顺序，不是某一台防火墙的配置命令。

没有报表的站点，用更笨的办法。试验窗口里先只留专线，会议能开，说明这条线本身能承载。再只留宽带，看会议是否变差或直接失败。两条同时打开、用起来仍像只有宽带，不能据此断定策略没把会议送进专线。体感一样，可能是专线本身也挤，也可能是会议根本没命中那条策略。要一起看三样：会话表里这条会议走的下一跳，策略命中计数有没有增加，出口或隧道记录里有没有对应的会话。少一样，就还不能下结论。厂商文档里的计数器名称以你这台设备的版本为准，框架说明代替不了这台设备上的记录。这个对比比看「策略已启用」有用。

识别失误要有人负责改，不要在工作时间连续试。改之前导出上一版。谁改的、哪一天、影响哪些站点，写在变更记录里。失败就回退，不要在同一小时里改顺序、改识别库、改线路三件事。三件一起改，晚上复盘时说不清是哪一件让会议恢复的。

总部和分支要一起看。分支把会议送进专线，总部的回程却从宽带出去，有的会话会不稳。不是每一种应用都会因此中断。核验时把来回路径都记下来。只在分支看发出去的字节，会把半截路径当成整条路径。回程不一致，也还不是「这通电话必然卡住」的证明。

举一个能通过的下午。表上写明会议走专线。发起会议后专线计数上升，宽带没有这段流量，规则命中加一，挂断后停止。分支和总部看到的是同一条线。记录里留了客户端版本。

举一个没通过的下午。页面上有「会议优先」，流量却全在默认宽带上。你看的那个命中次数是零。先确认计数没有延迟、没有落在另一张报表，再调规则顺序和识别版本，不先宣布专线坏了。专线单独测试时会议是通的，问题更可能在分类，不在线路。次数为零本身还不是分类失败的证明。

以后每次客户端大版本更新，把这一项重做一次。识别库不会自动知道你们新装的软件。应用识别策略如何核验，就是用真实应用看流量落在哪条线、你看的那个计数有没有变化、来回是不是同一条线。计数没变，先核对统计周期。回程不一致，记下来再判断这一种应用受不受影响。只在页面上看到一条策略，核验还没开始。