Pseudowire 状态与流量计数器：哪一个才能证明投递

运行状态说明业务已配置且处于 up；计数器说明有帧真正流动。把两者按 VC 索引连接起来，并核对方向、不连续点与 MIB 支持。

一个报告 up 的 pseudowire 只告诉你业务存在，并且两个方向都认为它应当承载流量。它并没有告诉你是否真有一个客户帧从中间通过。状态对象和计数器对象是为不同目的而写的，把其中一个当作另一个的证明，正是这类看板出错的地方。把两者对照来看才是工作本身，因为只信任其中任何一个，都是在回答一个没人提出的问题。

状态与计数器回答的是不同问题

主 VC 条目带有合并的运行状态，而该状态只有在两个方向都 up 时才为 up。它背后的一切都属于控制平面与配置知识：本地接入电路、对端、信令。处于该状态的一行，是关于意图与就绪的陈述，而不是关于已转发帧的陈述。

流量位于另一张高容量计数器表中，分别记录包数与字节数，而那些行带有相同的 VC 索引。那里的增长说明在你测量的区间内，帧确实经过了那一行。 计数器不变，本身就说明不了问题。闲置的业务、读错行的采集器，以及悄悄断掉的路径，都会给出同样一条平线。

QuestionObjectWhat it can establish
Is the service up?cpwVcOperStatusBoth direction states agree the VC should carry traffic.
Which side is down?cpwVcInboundOperStatus, cpwVcOutboundOperStatusDirection of the reported fault.
Did frames move?cpwVcPerfTotalTable HC countersObserved forwarding on that row between two polls.
Is the interval clean?cpwVcPerfTotalDiscontinuityTimeWhether the counter was reset inside the window.

要把这张表读成两列证据，而不是一条严重程度阶梯。计数器平直的 up 并不是比有增长的 up 更差的版本，它是另一种观察，对应不同的下一步。

按 VC 索引关联，而不是按工单里的编号

VC 表由单个整数索引，而 VC ID、对端地址、业务类型与名称只是那一行的属性。用这些属性去找到你的业务，用索引去在第一次轮询之后继续找到它。接口索引、显示出来的电路名或 MPLS 标签都不是那个索引，哪怕数字碰巧一致。

数值 OID 要从采集器上的 MIB 文件推导，而不是从博客文章里抄，然后遍历一次表，把你找到的标识存下来。

snmptranslate -On CPW-VC-MIB::cpwVcIndex
snmptranslate -On CPW-VC-MIB::cpwVcPerfTotalDiscontinuityTime
snmpwalk -v2c -c monitor 10.60.4.21 -On CPW-VC-MIB::cpwVcTable

把管理地址和索引一起记在监控系统里。重新开通可能把业务挪到另一行，而按名称绑定 VC ID 的采集器会继续画一个过期的索引，而它仍然很客气地给出响应。

方向指的是 pseudowire，而不是用户

入方向计数器描述 VC 从分组交换网收到了什么；出方向计数器描述它朝那个网络转发了什么。在面向客户的 PE 上，这常常按某种顺序对应下载与上传。在汇聚 PE 上，或在与核心建立对端的 PE 上，同样的对象名描述的却是相反的客户体验。

每类设备角色只写一次映射，并把它留在看板标签上。一张标题写着客户上传、实际却画的是流入核心的流量，会通过评审，并悄悄误导每一个用它做容量决策的人。同样的风险也适用于建立在这些图上的告警，因为它们会叫错团队。每张图都按相对于 pseudowire 的传输方向标注，而客户侧的映射应当留在需要它的面板里。

一次测试胜过读多少条对象描述：让一个已知文件穿过业务，紧接着轮询两个方向，看看哪个计数器动了。把结果记在设备角色旁边，因为下一个人会问同样的问题。

速率只在一个不连续区间内有效

速率按字节计数器的增量除以经过的秒数计算，再乘以八得到每秒比特。若计数器下降、代理重启、行发生变化或不连续对象移动，就把该区间判为无效。该对象是以系统运行时间为基准表示的，所以设备重启同样会让它失效。丢弃这个样本，另开一个区间，而不是画出一个尖峰。

取两个已知间隔的样本，时间戳要从采集器取，而不是从你的终端历史里取。

snmpget -v2c -c monitor -Oqv 10.60.4.21 CPW-VC-MIB::cpwVcPerfTotalInHCBytes.7
sleep 60
snmpget -v2c -c monitor -Oqv 10.60.4.21 CPW-VC-MIB::cpwVcPerfTotalInHCBytes.7
snmpget -v2c -c monitor -Oqv 10.60.4.21 CPW-VC-MIB::cpwVcPerfTotalDiscontinuityTime.7

高容量计数器让单个 pseudowire 上的回绕不再是问题，所以下降几乎总是意味着重置、更换代理或换了另一行，而不是算术溢出。这就是第三条命令与前两条同样重要的原因。

核查已安装版本实际支持什么

MIB 定义只是规范，并不保证你的镜像。表可能缺失、只实现了一部分，或存在但在功能启用前一直为空，而且同一平台在不同版本之间也可能不同。 CISCO-IETF-PW-MIB 定义 给出对象名；设备才告诉你它们是否响应。

一次把两张表和固件字符串都查出来，然后与发行说明所声称的内容对照。

snmpget -v2c -c monitor -Oqv 10.60.4.21 SNMPv2-MIB::sysDescr.0
snmpwalk -v2c -c monitor 10.60.4.21 CPW-VC-MIB::cpwVcTable | wc -l
snmpwalk -v2c -c monitor 10.60.4.21 CPW-VC-MIB::cpwVcPerfTotalTable | wc -l

空遍历与不支持遍历是两种不同的失败，所以要读错误，而不只是看行数。如果状态表有响应而性能表没有，第一节里设计的关联就无处落脚，该修的是采集器而不是电路。

有争议电路的核查顺序很短：从索引确认行标识，用一次已知传输确认方向映射，只在干净的不连续区间内计算速率，并确认两张表在该版本上都能响应。每一步都排除一种可能解释。当四条都成立而计数器仍然不动，证据就指向 pseudowire 之外。这时才轮到在接入电路上抓包。

相关文章