已交付华东4 周通用 · 网络设备适配
11 组
MIB 探测
逐表 walk 落日志
5 张
核心表
经实测验证有数据
4 类
覆盖数据类
终端 / AP / 地址池 / 流量
Java 1.8
环境兼容
不引入新依赖
Challenges
这个项目难在哪
每个案例的难点都不一样。先把难点说清楚，方案才有意义。
01
厂商提供的 MIB 文件超过三千页，OID 数以千计，逐个尝试不现实。
02
文档版本与设备固件版本不完全对应，部分 OID 位置有偏移。
03
部分表的索引结构复杂（多级索引），直接按 OID 遍历会拿到错乱的结果。
04
采集程序要跑在客户的 Java 1.8 环境里，不能用新版 SDK。
方法：先探测，再筛选，最后验证
MIB 适配这件事没有捷径，但有正确的顺序。常见错误是拿着文档直接写代码，写完发现取不到值，再回头查文档，来回折腾。
- 1以精简版 MIB 文档作为基准，先圈定候选 OID 范围，不追求全量覆盖。
- 2对每张候选表执行完整 walk，把原始返回落成日志，保留 OID、类型、值三列。
- 3从日志反推哪些表真的返回了数据——空表要么没启用，要么 OID 不对。
- 4对非空表逐列确认语义，对照 MIB 定义确认字段含义，排除文档与固件不一致的情况。
- 5最后才写采集程序，此时每个 OID 都是验证过的，不靠猜。
✓日志要保留原始形态
探测日志不要只存解析后的结果，要保留 snmpwalk 的原始输出。后面发现字段含义对不上时，原始日志是唯一能回溯的依据。
最终验证通过的 5 张核心表
| 数据类别 | 表名 | OID 根 | 用途 |
|---|---|---|---|
| 在线终端 | ruijieStaTable | .56.5.1.1.1.1 | 终端 MAC / IP / 所属 AP / 信号 |
| 终端详情 | apStationInfoGetTable | .2.81.6.1.1.1 | Radio、SSID、认证方式 |
| AP 统计 | apLinkStatisticsTable | .2.81.10.2.1.1 | 按 AP 聚合的上下行字节 |
| 地址池 | DHCP 池表 | .2.58.1.3.1.1 | 池名、网关、DNS、使用率 |
| 接口流量 | 标准 ifTable | .2.10.1.1.1 | Counter64 接口字节数 |
11 组探测里只有 5 组拿到有效数据，其余是空表或与当前固件不匹配。这个比例很正常——MIB 文件是设备全系列通用的，具体型号只实现了其中一部分。
三个必须处理的技术细节
1. 多级索引导致的结果错位
终端表这类以 MAC 加索引的表，如果只按单一索引遍历，会把不同 AP 下的同名索引混在一起。必须按完整索引链解析，否则统计出的终端数会翻倍。
2. Counter32 在高速链路上会回绕
标准 ifTable 同时提供 ifInOctets（Counter32）和 ifHCInOctets（Counter64）。在千兆以上链路必须用 64 位版本，否则几十秒就回绕一次，差值算出来是负数。
3. 文档与固件的偏移
部分 OID 在文档里标注的位置与设备实际返回不一致。处理方式是以设备实际 walk 结果为准，把偏移量记录下来写进交付文档，避免后续换固件时重复踩坑。
交付物
- 精简 OID 清单：5 张核心表、约 40 个字段，含类型、语义、取值范围。
- 11 组探测原始日志，按表分类归档。
- OID 映射表：文档标注位置 vs 设备实际位置，标注差异项。
- 可运行的采集程序，兼容 Java 1.8。
- 实测报告：每张表在目标设备上的返回样例与字段解释。
交付后客户可以直接把这套清单交给下一个项目的开发，不需要重新做一遍探测。这也是这类适配工作真正的价值——省下的不是几行代码，是几周的试错。
Talk to Us
有类似的项目？
把你的现场情况说清楚就行，不用先写需求文档。我们会告诉你从哪切入最划算、哪些环节其实可以不花钱。
工作时间内 2 小时内回复
先判断可行性，再谈报价
不需要的不会推销