在揭阳的三天三夜

在揭阳的三天三夜

04-07
1. 测试了现有的代码，仅找到很少的几条链路，而且结果还不正确。
2. 最奇怪的是，bridge.mib里的fdb表都没有数据，我的发现算法是基于fdb来作的，
   fdb表没数据，肯定找不到链路。
3. 突然想起北京同事说的NDP，于是想用华为的NDP试试，加载huawei-hgmp.mib，
   结果发现H3C的设备里根本没有数据，太失望了。

04-08
1. 想起三年前在安徽恒源的痛苦经历，但最终是用STP得到正确的结果。于是，我又试了
   基于STP的发现，还是没结果。为什么？因为STP里的数据不满足算法的要求。
2. 看来这次真的遇到挑战了。路由表里全是OSPF，我又想起曾经看过一篇文章，写的是基本
   OSPF的拓扑发现。在网上搜索了半天，只有万方的论文里有相关文章，无奈之下，只好用
   手机短信花了3块钱下了一篇论文。按论文里的算法，改了程序，经测试后，虽然有点进步，
   但仍有多台设备处于孤立状态，找不到链路，太郁闷了。
3. 用SolarWinds下载了所有h3c上的mib，回宾馆研究。发现SolarWinds在win7下的一个bug，
   导出功能完全不能用，我只好把结果存成txt。

04-09
1. 从下载的mib数据中惊奇地发现，h3c使用了Q-bridge而不是bridge，这就难怪bridge里的fdb
   表没有数据。这又让我心中燃起了希望。但Q-bridge里的address这一字段没数据，所以要用
   walk（而不是table）才能取到数据。
2. 专门写了一个取Q-bridge fdb表数据的类。核心交换h3c7510中的fdb表项巨大，大约有800条
   之多，snmp4j没取完就超时了，用SolarWinds也会出现超时的现象。
3. 再次测试了发现程序，由于有了fdb表的数据，多找出好多链路，但仍不完整。
4. 收集了所有设备的mib数据，回广州慢慢研究。

在揭阳的三天三夜 ，紧张而痛苦。我真的遇到一个大难题......