經(jīng)過對揭陽數(shù)據(jù)的研究，我終于找到問題的根源。
1. 對路由的發(fā)現(xiàn)，以前的代碼有點問題。又找出以前的論文，明確一下算法。
2. 揭陽設備路由表的nextHop全是VLAN。所以，這不是H3C或Cisco的問題。如果cisco這樣設置，如果沒有CDP，目前的程序一樣得不出正確的結果。
3. 比較吃驚或者奇怪的是，H3C的設備有支持Bridge.mib，有的支持Q-brideg.mib，而有的二者都有。
4. 另一個，H3C的設備比較奇怪的是，它的bridge-mac不會出現(xiàn)在任何交換機的fdb表。因此，通用的二層鏈路發(fā)現(xiàn)算法無法運用。
5. 因為4，所以我只能從路由表進行發(fā)現(xiàn)，對于nextHop是VLAN，必須轉(zhuǎn)成物理接口，然后用排除法（這個算法與通用二層鏈路算法有點類似，只是不用依賴bridge-mac）判斷這條鏈路是否是真實的物理鏈路。
6. 根據(jù)5，修改了發(fā)現(xiàn)程序，對現(xiàn)在數(shù)據(jù)進行“發(fā)現(xiàn)”，得到了正確結果！