#
这本书里面的一些句子还是挺经典的。
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.