1 OSPF是在IP包里的，五种不同类型的OSPF包(Hello,LSR,LSU，LSAck,DD)又是由再进一层的ospf packet
header进行区分的。ABR一般都会有一个接口在Area0中，且对于不同的Area有不同的LSDB。
2 OSPF基本配置中，是这样来把每一个接口interface分配到不同的Area中的：
When the OSPF process first becomes active, it will "run" the IP
addresses of all active interfaces against the (address, inverse mask) pair of the first network statement.
All interfaces that match will be assigned to the area specified by the area portion of the command.
that this process is consecutive, beginning with the first network statement. As a result, the order of
the statements can be important。
这样的话，inverse mask就会很重要。同时从这个意义上讲，OSPF的network...area...命令并不是中，
network后面的ip地址并不是针对area中的地址范围来指定的，而是针对该路由器所在的接口的IP来起
作用的！！即network后面的IP和掩码是为了控制不同的接口在不同的Area中而起作用的。
所以你当然可以使用接口的IP地址和32位的主机掩码来控制某个端口到不同的Area中去了！！
3 BGP的TCP会话是只有一条socket的。对于这个套结字而言，连接发起方使用一个随意的端口号，而被连接方则使用179号端口。
4 我们现在墙上的一个口是连接到一个交换机的一个口上去的。这个可以通过在自己的机器上用sniffer抓包，但是
抓不到别人的机器的包的事实来证明。这个原因正是交换机与集线器的区别嘛，因为交换机只是把包放到目的
MAC对应的口上去，而不是像hub一样把包在所有口上进行广播。但是交换机并不是隔离广播的，因为你发往
广播或者多播地址的包，交换机会帮助你送到每一个交换机口上去的。
自己亲自的一个实验是：不管是接在交换机上还是接在Hub上的两个机器，只要不在同一个子网中，肯定是
Ping不通的。这个和PC上设置的Default Gateway很有可能是有瓜葛的。
自己亲自做的第二个实验结论：如果是一个连在一台路由器上的一个PC去ping另一个连在另一台路由器上的PC时，
除了我们常规能够想到的必须在路由器上要有这些路由信息外。连到路由器上的PC的Default Gateway必须是
我所连接的路由器，而且必须在同一个子网中，即子网掩码必须相同。而且如果是Linux的主机，不光是
Default Gateway相同，网络配置文件中的广播地址等都是要相同的。所以一个结论性的东西：子网掩码是非常非常重要的！！
5 No router within a stub area can be an ASBR. This restriction is intuitively understandable
because ASBRs produce type 5 LSAs and type 5 LSAs cannot exist within a stub area.
6 OSPF MaxAge是1个小时，而RefreshTime是30分钟。Refresh就是把超过30分钟时间的LSA泛洪到所有的OSPF
路由器上去。即每个路由器会对自己所发的LSA进行计时，如果到了30分钟就放到LSU中发出去。
7 BGP Update中每次最多只能宣告一个路由，但是一次可以撤销多个路由。
8 OSPF也是只在发生变化的时候，向网络中其它路由器组播改变的路由。而不是像Rip似的每30s向所有邻居广播
整个的路由表，所以有效地节省带宽并使收敛速度很快。OSPF是以链路的cost而不是像Rip只以跳数来做路由选择的
，所以选择出来的是最优路由。即每台路由器根据自己的LSDB，使用SPF算法计算自己到目的地之间每条链路的开销
(该值通常是基于链路带宽的)，加到一起作为一条路经的开销，它会选择开销最小的路经并添加到自己的转发路由表中。
9在稳定状态下，OSPF网络中一般只有hello包的
接口掩码不一致的问题导致我的zebra一直没有办法和路由器通信。
10 linux下开源的卸载方法：这里以zebra为例进行说明，其他的应该类似。
首先到.tar.gz解压后的那个文件夹中去，执行make uninstall即可。
make uninstall的本质含义是这样的，make -f Makefile uninstall
即去执行Makefile这个文件中的uninstall目标即可，进到Makefile文件中，肯定可以找到uninstall这个目标，
一般而言这个目标又会关联到其他的目标，去依次寻找即可。最后应该就是一个命令。
在linux下面卸载然后再重装一般解决不了什么太大问题，然后对于该软件自己已经做过的修改的部分是不会有覆盖的。
11 OSPF协议规定，只有有邻接关系就可以传送LSA报文信息了，即所谓的路由信息了。而半邻接和全邻接都是属于
邻接关系的。
12 通过观察并抓取zebra与路由器间的交互过程可以知道对于DD包，首先两方都使用DD包进行Master/Slave协商，这个时候
两方的DD包中都把Master位置1，而其中没有任何LSA Header，同时给出自己的一个序列号。然后谁的序列号大谁就是Master，
则下一个DD包就肯定是Slave根据Master的序列号而发的一个DD包，这个DD包中，Master位置0，同时后面开始放LSAHeader了。
然后就进行下去。最后，如果没有LSA Header了，每方都要发一个More为置0的DD包来表示DD交换完毕。
13 Type 9 10 11 Opaque-LSA:
By defining Opaque-LSA contents and appropriate processing rules, we could have more control over the network behavior and so on.
For example, we can make use of various traffic-engineering metric encapsulated in type-10 Opaque-LSAs to calculate QoS-aware routes, besides from normal SPF algorithm.
14 OSPF协议交互过程中，2-way和Master-Slave negotiation交互完成有相同的结构：
具体说是这样的，先发现2-way的会以一个用以协商M-S关系的DD包来告诉另一方已经发现了2-way
先发现自己是Slave的会以一个用以传输真正的LSA Header的DD包来告诉另一方开始Exchange了。
------------------------------------------
15跟着问题走：BGP的隐式撤销归根结底都是要由一个显式的withdraw来进行诱导的.（这个问题非常紧迫）
正如以前问到的是不是BGP再向外宣告的时候都是用network静态指定的来防止OSPF的不稳定性扩散出去。
16打开BGP同步的目的是防止一个自治系统内部出现路由黑洞，即向外宣告的路由本身不知道该如何到达，但是打开BGP同步
会让IGP的路由器去维护数以万计的BGP路由，这样对CPU和内存的需求显然不太现实。那么关闭BGP同步，又保证BGP路由
连通性的方法有三个：1 IBGP full mesh 2 Route Reflector 3 联盟
17 关于IGP与BGP的交互的问题：
传统上明智的做法是，你的网络要包含一个运行iBGP的核心网络(或者叫骨干网)，并且在内网采用的IGP协议(OSPF或其它)路由中
指定一条缺省路由。只要内部网关协议将数据包传送给主干网络，那里的路由器就能选择最佳的出口策略。
关于IGP与BGP路由互相注入的问题，有两种大的方式：动态注入和静态注入。静态注入的方式即在BGP路由器的IP路由表中增加
一条到域内目的地的静态路由，动态注入方式当然是与之相对了。在每种方式中，都有两种注入方法：redistribute方法和network方法。
redistribute方法就是所有的IGP路由都被宣告出去(这个时候宣告的路由的Origin属性肯定是Incomplete)。network方法是与之对应，
即我手动指定一些要向外宣告的路由，然后BGP会检查其IP路由表，如果存在此条目，就向外宣告（这个时候宣告的路由的Origin属性是
IGP），否则不宣告。所以当采用静态注入且是network方式的时候，即便这个IGP路由不可达了，BGP路由器还是会继续宣告的。但是
network方式确实是目前广泛采用的方式。
18 IBGP neighbor宣告它自己可达的网络的update的nexthop属性就是它自己的IP地址：（例如）
2006/10/25 13:49:32 BGP: 192.168.30.2 rcvd UPDATE w/ attr: nexthop 192.168.30.2, origin i, localpref 100, path
2006/10/25 13:49:32 BGP: 192.168.30.2 rcvd 172.30.0.0/16
18 两种类型的summary LSA即类型3和类型4的LSA都应该是会在整个AS内泛洪的,且都是由ABR产生并由ABR在AS内泛洪。
19 对于ABR的配置，即对于一个路由器上的多个不同IP地址范围内的接口分配到不同的Area中的配置，一定要在一个
OSPF的进程中进行配置，即一个router ospf 100,然后后面跟着多条network
20 让路由器上运行BGP的那个接口也在OSPF的area中，这样从其他的Area才可以ping通这个运行BGP的接口。这样，虽然在ASBR-Summary LSA
中会描述运行BGP的边界路由器的RouterID，但是在其他Area的路由器的LSDB以及FIB中有到运行BGP的接口的路由确实通过Network-summary LSA
进行泛洪而得到的。
21 关于OSPF和BGP交互的路由器配置实战经验：
1)首先配置OSPF。 要注意把运行BGP的那个接口也要配到OSPF中，具体到这个路由器所在的Area。正如20中所说的
2)其次在配1)之后，即是在配1)这个OSPF的进程中，使用default-information originate命令。
这样做的目的是让这个OSFP 的ASBR向整个OSPF域中宣告一条默认路由。这样域内的一般OSPF路由器的路由表中就不需要维护整个域间的
所有可见路由了。
3)在配置BGP的时候，使用network手动指定添加BGP向外宣告的域内路由即可。
如果宣告的确实是本OSPF域内的路由，那么这些路由肯定已经通过OSPF添加到该ASBR的路由表中了，所以network的时候，路由器
肯定可以查找到他们。
此外，与第2)步对应的方式是在配置OSPF的时候使用redistribute bgp，这样与2)对应，就会把所有的BGP路由以type5LSA的形式宣告到
OSPF域内的所有路由器中。
与第3)步对应的方式是在配置BGP的时候使用redistribute ospf，这样与3)对应，就会把所有的OSPF域内路由宣告到域间，同时也
就把域内的不稳定性扩展到了域间。
22 在路由器上配置隧道，并在此隧道上跑OSPF路由协议实战经验：
分两个步骤：1 在两个路由器间配置起隧道 2 在该隧道上跑起来OSPF
对于在两个路由器间配置起隧道，需要明确三个要素即可。第一是在路由器上建的这个Tunnel的IP地址，这个IP地址可以是完全任意的，
但是一般来讲不应该和本路由器上的其他已有接口IP在同一个网段，而且一般是和Tunnel另一端的Tunnel IP在同一个网段中的。
第二是这个Tunnel的Source IP。它是发出Tunnel报文的实际物理接口。一般来说都是本路由器的FastEnternet0/1这样类似的东西，
当然如果你不是直接在路由器上配置Tunnel，而是通过路由器为中继来配置Tunnel，那么Source Ip当然就是你的网关路由器了。
第三是这个Tunnel的Destination IP。与上一个对应，他是接受Tunnel报文的实际物理接口IP地址。一般来说当然就是对端路由器上的
某个接口的IP地址了。当然，你是首先需要保证SourceIP 和Destination IP是可以相互连通的（即可以路由的）。
下面是一段实际配置的命令：
interface Tunnel 8
ip address 8.8.8.1 255.255.255.0
tunnel source FastEthernet 0/0
tunnel destination 192.168.30.1
另一端的路由器的配置与之对等过来即可,
对于在该隧道上跑起来OSPF,和普通接口的情况是完全一样的,即在原来的OSPF进程中增加一条network命令即可来让这个Tunnel接口参与
到相应的OSPF Area中去。你肯定是要让一个Router的Tunnel接口参与到另一个Router所在的OSPF Area中才这样做的。
而且比较牛的是，你不仅可以让一个该Tunnel接口参与到本AS的其他OSPF Area中去，而且还可以让该Tunnel接口参与到其他AS的OSPF Area
中去。但是，如果你和本自治系统OSPF Area的邻接关系和与另外自治系统OSPF Area的邻接关系配置在路由器的同一个OSPF进程当中，
则会出现异常，原因很简单，一个OSPF进程就会认为对于重复的Area没有办法处理，它没有办法区分是哪个自治系统中的该Area了,当然
如果你把与不同的自治系统OSPF Area的邻接关系配置在路由器的不同的OSPF进程中，是没有什么问题的.因为在路由器中，不同的OSPF进程
使用的就是不同的数据库了，这样就互不干扰。
23 在linux PC zebra ospfd与Router 上配置GRE tunnel并在其上跑OSPF：
1 首先要先把内核模块ip_gre.o加载上
modprobe -l |grep ip_gre.o
insmode /lib/modules/2.4.20-8/kernel/net/ipv4/ip_gre.o
而且注意每次重起或者注销后都要再加载一遍
查一下相关手册，向这种ip tunnel ... ip link ... ip addr....都是什么类型的Linux网络命令。注意，这些命令的省略号处换
成help就可以看到这些命令的注释和帮助
(Tunnel在linux中的文件关系：The following steps to install and set up IPIP encapsulated tunnels on Linux.
Obtain and install a Linux v.2.0 or v.2.1 kernel
Configure the kernel for IP tunneling. Recompile. Reboot. If the kernel has been successfuly configured, then a 'cat /proc/net/dev' should show a tunl0 and tunl1 device, in additional to the usual lo and eth0 or ppp0
read /usr/src/linux/drivers/net/README.tunnel
)
网上有人这么说：
> > When you create a new gre tunnel under FreeBSD while zebra is running, do NOT
> > attempt to bring up ospf on that tunnel. When gre tunnel that is about to speak
> > ospf is created while zebra runs, it loses file descriptor and causes kernel
> > to panic. This also happens on Quagga as well. It is specific to FreeBSD and
> > zebra's kernel interaction with the tunnel interfaces. Does not happen with ipv6
> > tunnels, just plain old GRE.
24 RFC2328第10.5节有这样一段话：
Any mismatch causes processing to stop and the
packet to be dropped. In other words, the above fields are
really describing the attached network's configuration. However,
there is one exception to the above rule: on point-to-point
networks and on virtual links, the Network Mask in the received
Hello Packet should be ignored.
路由器肯定实现了，然后跟踪zebra的源代码，zebra也是这样做的。那么问题就是从gre tunnel上收到的多播包没有交给ospfd，因为
我在zebra中debug ospf packet all recv detail没有任何显示和反映，但是debug ospf packet all send detail是可以发出去的，
同时我ethereal到的gre tunnel上确实收到了远端发送过来的多播包。
25 如果一个路由器既运行BGP又运行OSPF的话，那么这两个路由进程都会去操作主IP路由表的。一个相对实际的问题的解决方案是这样的，
一般把IGP的路由向外部宣告的时候，在BGP路由器上是使用network命令进行静态宣告本地网络的。这种情况下，如果内部IGP的一个
网络前缀不可达了，BGP路由器是会向外部撤销这个路由的。因为BGP路由过程会周期性地扫描主IP路由表，如果检测到本地某个网络不可达了
，就会向外宣告撤销之。
26 关于BGP sychronization,IBGP full mesh,redistributiong:
当你的自治系统是一个transient AS的时候，你需要考虑这个问题了，一般情况下是应该下面这样的，才可以避免路由黑洞：
A router running Cisco IOS Release 12.0 or later does not select or use an IBGP route unless BOTH
of the following are true:
? the router has a route available to the next-hop router
? the router has received synchronization via an IGP (unless IGP synchronization has been
disabled)
这个问题的本质是这样的，IBGP邻居不是直接物理上相连的，而是TCP连接，那么BGP在这样的拓扑上就形成了BGP路由下一跳不可达的问题！
那么解决路由黑洞的方法就有以下几种：
1 如果你的AS不作为transient AS,不用担心这种情况
2 打开同步,让BGP路由redistribution到IGP中。这样很明显会加重IGP路由器上的负担
3 关闭同步，通过配置静态和默认路由，让BGP路由的下一跳可达。这样很明显比较麻烦，而且会人为造成路由黑洞或者环路
4 关闭同步，自治系统中的所有路由器都运行BGP，或者至少所有transit router运行BGP，然后他们Full Mesh上。
5 或者更复杂一点的情况，其实是上面的3和4的综合，仍是关闭同步，即有一个IBGP的骨干网，然后IBGP骨干网中间的IGP网中配置默认或者
静态路由，这样只要包能够发送到IBGP骨干网上的一个节点就可
我觉得这个问题立刻就引来了好几个研究点：
1 “IBGP邻居不是直接物理上相连的，而是TCP连接，那么BGP在这样的拓扑上就形成了BGP路由下一跳不可达的问题”。这个问题其实一直没有
很好地解决。
2 路由黑洞的一种造成情况和检测方法
此外解释一个点，关于下一跳的问题
如果RA和RB是AS的两个人Border Router，均运行BGP且中间由IGP中继。如果RA有一条从其他EBGP邻居RC学到的到Prefix的路由，他会通过TCP
传递给RB，这个时候RB收到的BGP Update报文中的那个NextHop字段肯定是RC的IP，但是当RB把可达Prefix的这条路由放入路由表中的时候，
因为是从RA收到的，它肯定会把路由表中，这个路由Prefix的下一跳写成RA。也就是说是有两个下一跳的，请一定要留意。
27 在配置zebra与router之间通过跑跑起来ospf的艰辛历程：
1)ip addr 命令中不用peer选项指定对方的ip,但这个时候要把本接口的IP地址加上掩码。如ip addr add 99.99.0.2/24 dev gre104
2)ip tunnel命令中一定要用dev选项指定所依赖的物理接口
3)把ospf_interface.c这段中第419行开始的那个关于point-to-point的if注释掉！
4)让linux pc上的部分接口参与到ospfd中去的时候，一定要在zebra.conf中写出这个接口的内容，且掩码要与实际中接口的掩码一致。
即在zebra.conf中要这样声明：
interface gre104
ip address 99.99.0.2/24（注意这里其实正好和第一步中所写的ip addr add 99.99.0.2/24 dev gre104完全一致起来）
multicast等
此外在ospfd.conf的network命令中也要写得和上面两个完全一致起来：
即在ospfd.conf中要这样声明：
network 99.99.0.2/24 area 1（注意而不是network 99.99.0.2/32 area 1或者network 99.99.0.0/24 area 1等）
总是,linux系统的interface ， zebra所读取到的interface，以及ospfd从zebra所读取到的interface有着密切的关系，由于时间非常紧迫
这个关系到底是怎么回事，留到有空再去搞明白吧.
但是无论如何，这个艰辛的过程都告诉我：坚持就是胜利！因为在整个过程中，确实很多时候都想放弃。还有就是不要怕麻烦，一味地想
省事反倒会更麻烦，比如不要逃避去看源代码。
28在路由器中show running-configuration中，看到redistribute bgp 1 redistribute ospf 3是什么意思？路由器是按照21种所述来配置
的？
29 BGP路由器之间建立连接，以及建立起来连接后发送的update都是需要较长时间的，至少比ospf的情形慢不少。
30 我们知道BGP协议是封装在TCP中的，在实际的抓包过程中可以看到，一般而言一个TCP包的payload里面是可以有多个BGP包的，这些包可以
是keepalive update等，而不是说一个TCP包中只有一个BGP包。
31 一些时间的记忆：
OSPF: hello interval:10s dead interval:4*10=40s RxmtInterval（重传时间间隔）:5s
LSRefreshTime:30 min LSA MaxAge:1 hour
32 在我们的小实验环境下，OSPF当有一个路由器down掉的时候，DR只会发一个缺少了该路由器的network lsa,这是很正常的，因为DR的attachedRouter
里面就是和它有adjancy关系的路由器，所以当40秒后DR发现这个adjancy关系丢失的时候会发出这个LSA，除此之外网络不会有其他类型的LSA
存在了。比如说，DR是不会发RouterLSA的，因为RouterLSA中的LinkID是这个网络中DR的IP，LinkData是该路由器接到该网络上的IP地址，所
以两个都不会变。
但是当这个路由器再起来的时候，DR却产生了一个新的该RouterLSA的实例，因为sequenceNum增加了1。其他字段都是一样的。那么我的问题就是
那么OSPF在什么时候会产生一个LSA的新的实例呢？(比如这种情况)
OSPF当然也是在网络发生变化的时候发LSUpdate更新包的，这一点和BGP是一样的。一般来讲，产生一个新的LSA有两种可能：第一是每30分钟产生
一个LSA；第二是当LSA的内容要发生变化的时候会产生一个新的LSA。而路由器发出LSA则有另外两种可能，第一就是自己产生了新的LSA，第二
就是它要负责flood LSA，比如它是DR。
33 每个路由器是以自己产生的LSA为根节点开始进行SPF计算。SPF路由计算最终都是通过这种stub的network来最终生成填入路由表的路由项目的。
34 因为OSPF的网络类型和实际物理的网络类型可以不同的，所以我就在以太网上配置成功了OSPF网络中所说的point-to-point网络。方法很简单
就是在配置interface的时候添加一条配置:ip ospf network point-to-point（也就是告诉OSPF进程这个实际网络被当成一个Point-to-Point型）
但是遇到的一个问题是如果这个以太网上路由器一多，这个p2p的OSPF连接关系就会被干扰，为什么呢？难道因为所有的包都是发往224.0.0.5这个多播地址
干扰的吗？
35 如果一个路由器的两个接口都运行BGP与其它路由器建立BGP对等的话，那么你只可能和这个路由器的其中一个接口建立BGP对等关系，
不可能和这个路由器的两个接口都建立BGP对等，那么这就存在了一个建立在哪个接口上的问题。
36 在编写网络程序的时候，很重要的一个设计思想就是做一个应用层的头，然后有一个应用层的握手机制，这样再建立socket传输，特别是
对于并发的情形更加重要了。
37 当BGP路由器使用aggregation命令来向外宣告一条聚合路由的时候，如果这个路由器中的某个具体路由不可达了，只要这个聚合路由中还有
一条具体路由存在，那么这个路由器就不会宣告任何撤销报文。
38 如果两个路由器之间有两条物理连接，通过采集路由更新报文应该是画不出来这样的情形的。因为路由器自己无论是在BGP routing table
一级还是在IP routing table一级做load balance的时候，向邻居对等体宣告的都只是一条路由，而且是next-hop-self的情形。
39 default-information originate写在哪个协议的配置子命令中(如OSPF或者BGP)，其含义就是在这个协议中注入默认路由
同样，redistribute 写在哪个协议的配置子命令中其含义就是往哪个协议中注入路由一样。
40 关于BGP同步配置的问题：
这个简单的配置问题一直困扰并耽误了我两天的时间。场景是这样的很简单，同一个AS里的两个路由器，都是既跑ospf又跑bgp，分别是RTA
和RTB，两者都从各自的EBGP邻居学到了到同一个目的地的D不同路由。但是当其中一个路由器到D的路由不可用了的时候，虽然它以前就通过IBGP学到了到D的另一条路由，但它并不将其选为最优路由，所以也就一直放不到IP路由表里去，这样虽然有备份的路由也不能走。
产生这种现象的重要原因是在这个AS的BGP配置中，同步被打开了。Cisco的路由器默认是关闭的，即no sychronization的，但并不是其他路由
器也如此啊。因为在这个场景中，我在配置OSPF的时候并没有redistribute bgp 或者default-information originate，所以BGP的路由始终没有办法注入到OSPF中去，那么这个BGP路由器一直不把它从IBGP邻居学到的路由作为最优路由的原因就是它一直在等待OSPF中也同步了这条路由。这种现象的典型体现就是在BGP路由表中 * i 192.168.100.0/24 NH 而不是 *>i 192.168.100.0/24 NH
41
When the route is originated by the AS itself, the most common practice is for the MED value to follow the internal IGP metric of the route.
Because The IGP metric within the customer's AS reflects how close to or how far from a certain entrance point to that AS a network is.
MEDs can be used by both providers and customers to balance the traffic over multiple links between two ASs.
Utilizing MEDs in the aggregation situation could potentially result in suboptimal routing because the more-specific routes of the CIDR block could be scattered throughout the AS and
MEDs associated with more-granular routes are no longer available.
42
由于Internet并不是一个单一的OSPF网络，为了与其它类型的网络进行通信，发现到其他类型网络的路由，在OSPF路由选择域的边界，就需要有运行其他路由协议的路由器的存在，这些路由器的一个主要功能就是把那些从其他路由选择协议了解到的路由选择信息引入到OSPF路由选择域中。我们把这种从其他路由选择协议中了解到的、目的地址位于OSPF路由选择域外的路由选择信息成为外部路由信息。
当收到一个新的自治系统外部连接公告时，不必要重新计算整个路由表，只需要重新计算到达这个外部网络的路由，如果已经存在到目的地的区域内或区间间的路由信息，则不要重新进行任何路由表的计算。
43
当然这个实验也顺便验证了ospf中DR选取结束后，除非DR路由器出现故障，否则就是有更高优先级或者RID的路由器进入OSPF进程，
也是无法改变DR的。既DR是不可以抢夺的！但是ospf中有一个Wait Timer计时器，在这个计时器所限定的时间内起来的OSPF可以视为同时起机，
这样就导致并不是先启动OSPF进程的路由器就是DR，而是有一个时间间隔让路由器来等待其他路由器，在这个时间间隔内，路由器相互监听
Hello包中的DR和DBR字段中的信息，并且服从优先级原则，可以这样认为——选举是公平的，因为在广播链路中的RouterDeadInterval是40秒，
所以我们看到的这个时间间隔为40秒。。那么在实际的网络情况下，在实际的网络中，即使是40秒内同时起进程的情况也少见；实际情况下是
率先启用ospf进程的路由器就很有可能成为DR，第二个启动的就很有可能成为BDR，考虑到路由器故障或者重启等情况，实际的运行效果是：
“活”得最久的路由器成为DR（比多长时间不重起） .
