#
這本書里面的一些句子還是挺經典的。
We came to ZS again.After making unremitting efforts,SourceFlow succeeded in receiving netflow
data steadily.
I was busy with research work for layer-2 discovery.Further study shows not only Aij＝Ak ＋ Sk_MAC
is right,there are conditions under which Aij＝Ak or Aij＝Ak ＋ if_mac can deduce two switches are
directly connected.
This is a very important conclusion.
** Version 2.2.1.Alpha, Release Date 2008.04.13
* Attached chinese alias to subnets and devices,so the topological map became more direct.
* Fixed a bug in the report module.
** Version 2.3.0.Alpha, Release Date 2008.04.14
* Added a monitor for http url.
* Added a monitor for IIS.
Building a layer-3 topology is relatively easy because routers must be
explicitly aware of their neighbors in order to perform their basic function.
Therefore, standard routing information is adequate to capture
and represent layer-3 connectivity. Unfortunately, layer-3 topology
covers only a small fraction of the interrelationships in an IP
network, since it fails to capture the complex interconnections of
layer-2 network elements (e.g., switches and bridges) that comprise
each subnet. As more switches are deployed to provide
more bandwidth through subnet microsegmentation, the portions
of the network infrastructure that are invisible to a layer-3
mapping will continue to grow. Under such conditions, it is obvious
that the network manager’s ability to troubleshoot end-toend
connectivity or assess the potential impact of link or device
failures in switched networks will be severely impaired.
The lack of automated solutions for capturing physical (i.e.,
layer-2) topology information means that network managers are
routinely forced to manually input such information for each
management tool that they use. Given the dynamic nature and
the ever-increasing complexity of today’s IP networks, keeping
track of topology information manually is a daunting (if not impossible)
task. This situation clearly mandates the development
of effective, general-purpose algorithmic solutions for automatically
discovering the up-to-date physical topology of an IP network.
An additional challenge in the design of such algorithms
is dealing with the lack of established, industry-wide standards
on the topology information maintained locally at each element
and the diversity of elements and protocols present in today’s
multi-vendor IP networks. The combination of these factors implies
that any practical solution to the problem of discovering
physical IP topology needs to deal with three fundamental difficulties.
1. Limited local information.
2. Transparency of elements across protocol layers.
3. Heterogeneity of network elements.
1. 對于網管系統，主要調試網絡管理部分，包括拓撲發現和事件告警等。
修改了一些bug，這周基本完成預期計劃。
對二層發現問題，有更加清晰地認識。如果不存在Hub，我的程序可以準確地運行，
但對于存在hub的情況，算法太復雜，我還沒認真去研究。
下周去，首先把網絡部分演示給管網絡的用戶看一下，看是否還有需要改進的。
其次，對小型機的監視，與用戶作進一步溝通。
從目前情況看，系統穩定。但因為現在沒有固定的服務器，暫時無法測試系統長
時間（至少是10天）連續運行情況。
2. 對于流量系統，在公司測試時沒問題，但在ZSP，數據比我們估計大得多，
我們的程序撐不住。
這幾天改進程序，待下周再去測試。
我覺得我們的系統如果能在ZSP正常運行，就基本能適合一般的企業應用。
所以現在遇到些問題并不是件壞事。
待這個項目之后，netflow會重新設計，升級到2.0。
昨天發現很sysoid為1.3.6.1.4.1.6889.1.69.1.6的設備，程序判斷為路由器，
因為路由表有好多項，但我相信它肯定不是路由器。
1.3.6.1.4.1.6889.為Avaya的企業oid，那wind river systems與avaya公司又
是什么關系呢？
但我最想知道的是這種設備有是干什么用的。
但了wind river和cisco的網站
http://www.windriver.com/products/vxworks/
http://www.cisco.com/en/US/docs/net_mgmt/cisco_network_connectivity_monitor/
1.1_IDU_2/device_support/table/ncm_idu2_dev.html
猜想這設備應該能內嵌入cisco的交換機，具體做什么就不清楚了。
Improved topological map showing program,reduced code duplication.
The result was my expectation,but was not the best.It's necessary to
develop a new algorithm.
Expanded the discovery scope,form 128.1 to 191.255,instead of from
182.1 to 191.255.Lots more devices were discovered,including some of
windows and aix servers.
Moreover,some of strange devices were discovered too,whose SYSOID is
1.3.6.1.4.1.6889.1.69.1.6,SYSDESCR is VxWorks SNMPv1/v2c Agent by
Wind River Systems.
Layer-2 discovery is very difficult in a environment without CDP or STP.
My final goal is my program can get a accurate result in any network.
ZSP is a good place to test my discovery program of the general algorithm
instead of CDP.
The program of the general algorithm was wrote according to a paper,
that was proved to be correct in our company lan.However,it didn't work
at all in ZSP environment.The radical reason is the switch mac(bridge mac)
does not exist in fdb table of the other switch which is dircet connected
with it,so the algorithm lose its effectiveness.
I modified the program,set the mac address of some designated interfaces to be
the symbol mac intead of the bridge mac.This time,program run a satisfactory
conclusion excluding those switches who were connected with hubs.
As for the environment with hubs,I should study more.
Discovered ZSP network, using CDP protocol for all devices
here were cisco.The scope was from 182.1 to 191.255.
SourceView2.0 spent 4 minutes on topological discovery,then
drawing a distinct map.The amount of devices is 165.
I renamed those subnets to their relevant chinese alias.
This is the first step for ZSP project,it is a crucial step too,
I completed it sucessfully.So I set my heart at rest.
Release Notes - SourceView2.0
** Version 2.0.0.Alpha, Release Date 2008.04.01
* Completed almost all features according to the requestment document.
** Version 2.1.0.Alpha, Release Date 2008.04.03
* Completed the program related to discovery,including general and CDP algorithm.
* Completed modification of topological map showing,add two classes,using strategy
pattern.
** Version 2.1.1.Alpha, Release Date 2008.04.05
* Add a field to TOPO_SUBNET table,alias,which stores chinese name for the subnet.
* Add a table,HOST_SUBNET_MAPPING,which stores the relationship between hosts and subnets.
* Add a table,FDB_TABLE,to store fdb data from switches.
** Version 2.2.0.Alpha, Release Date 2008.04.07
* Add a monitor for monitoring oracle users.
* Improve operability of topological map,user can search device interfaces' ip directly
on topological map.
* Attach subnets' information to topological map.
1.Completed modification of topological discovery.
2.Tested the program based on the LAN of our company successfully.
3.The relationship between hosts and subnets is very important for
network discovery,so I wrote program to save the data related to that into DB.
4.Wrote a new class,FdbCollector,to extract fdb data from devices.
結論1：交換機非葉端口與交換機直接相連判定：交換機Si其下行非葉端口Sij的MAC表的集合Aij等于其最大子樹的根節點Sk的所有下行端口的MAC表的和再加上Sk的MAC地址即Aij＝Ak ＋ Sk_MAC，則Si通過下行端口Sij與Sk的上行端口直接連接。
------------------
只有這個算法最適用，今天我把這個算法寫出來了，并在公司的網絡中測試通過。
引理1：如果Lij∪Lkl=u（u指子網內所有交換機的合集）且Lij∩Lkl＝∮（∮空集）則端口Sij與端口Skl直接連接[1]。
-------------------------------
這個算法也不適合，因為Lij∪Lkl=u是很難實現的。
間接連接定理：
只要滿足以下3個條件之一，就可以確定交換機A和B通過x和y端口間接相連。設交換機A在x端口上學習到的MAC地址的集合為FxA。
1.FxA和FyB中同時存在著對方的MAC地址；
2.FxA中存在B的MAC地址，并且A上存在一個端口k（k≠x），使得FyB∩FkA≠ф；
3.在B上存在兩個端口i，j，使得FxA∩FiB≠ф且FxA∩FjB≠ф，并且A上存在端口k（k≠x），使得FkA∩FyB≠ф。
由于交換機之間很少通信，所以條件1和2中要求的交換機A的FxA中存在B的MAC地址很難滿足，可以利用IP欺騙的方法盡量地使條件滿足。具體做法是：對于子網中的每個交換機Si，利用IP欺騙方法，以Si的IP地址為源地址，向子網中的其他交換機發送ICMP ECHO消息。在Si收到回應后，將導致Si的FDB中保存有其他交換機的MAC地址。
基于間接連接確定直接連接
根據子網內交換機之間的間接連接關系，就可以確定交換機之間的直接連接關系。設子網內的所有交換機構成的集合為G。根據STP協議，交換機之間將構成一棵樹。任選其中一個交換機Si為根，假設Si通過n個端口與其他交換機構成間接連接，則可以將G－{Si}構成一個劃分Πi，劃分中包含n個元素，每個元素是與Si的某個端口p相間接連接的交換機的集合，設為Gp。在Gp中任選一個交換機Sj，則Sj必然通過某個端口q與Si的端口p間接連接，如果Sj不通過端口q與Gp中的其他交換機間接連接，則可以判定Sj通過端口q與Si的端口p直接連接。
------------------------------
這是很久以前看過一篇論文里的一部分。
從間接連接中推出直接連接，這個不難。但要找出間接連接是困難的，為什么？因為要實現那三個條件判斷，代碼量和運算量都極大，所以我沒有選擇這個算法。
不過其中提到IP欺騙的方法倒是很實用，因為如果兩交換機不通信，那么其中各接口的FDB表就不完整，甚至FDB表完全沒有數據。
Program related to map showing wrote by Zhanghf could not go well now.I must write the
program again by myself.
Netflow,which ftped by Yang occured an error.
Today is not my day.
Wrote two classes to realize topological map showing,using strategy pattern,each class run
the different algorithm.However,I could not develop a program who adapts any network
enviroment.