关于MGRE中的OSPF的收敛问题

        在 MGRE 环境中，接口默认的 ospf 工作方式为点到点，这种方式无法实 现该 NBMA 网段的邻居全连；故只能去修改接口的工作方式：

        修改 MGRE 网段所有接口为 Broadcast 工作方式， 切记若一部分接口修改为 Broadcast，另一部分接口依然保持为点到点，由 于 hello time 相同可以建立邻居关系，但工作机制在 DR/BDR 选举处不同， 故最终该网段无法正常收敛；同时，必须关注网络拓扑结构；

        ①若该网段为全连网状结构，那么 DR 选举将正常进行；但若为部分网状或中心到站点拓扑，将可能出现 DR 位置错误问题；

        ②若网络拓扑只能为部分网状或中心到站点，需要人为手工干预 DR 位 置或者将所有接口的工作方式修改为点到多点工作方式；

实验拓扑：

 配置步骤：

①配置路由器各个接口的ip地址

②向ISP路由器写缺省路由

③在路由器上打开tunnel隧道

        将R1部署为中心设备，R2、R3部署为分支站点。

④启动OSPF进程，并宣告R1R2R3的环回口和tunnel口

因为华为设备在一个MGRE网段，接口为点到点工作方式时仅和最先收到hello的设备建立邻居关系，所以在做完之后通过 display ospf peer brief 可以看到peer中并没有R3

第一种解决方法：

将tunnel口的类型全部改为broadcast，改完之后，所有的邻居都会出现但是它DR和BDR是乱的，也就是说它的收敛并没有完成

造成这种现象的原因是MGRE是伪广播，它在中心站点和各个分支站点之间各自建立了一个单播通道，所以它在逻辑上每一个通道都会选取一个DR和BDR

 此时我们需要干涉OSPF进程的DR和BDR的选取,让20.1.1.1成为DR

int t 0/0/0
ospf dr-priority 0

再次查看

测试： 

[r1]ping -a 192.168.1.1 192.168.2.1
  PING 192.168.2.1: 56  data bytes, press CTRL_C to break
    Reply from 192.168.2.1: bytes=56 Sequence=1 ttl=255 time=30 ms
    Reply from 192.168.2.1: bytes=56 Sequence=2 ttl=255 time=30 ms
    Reply from 192.168.2.1: bytes=56 Sequence=3 ttl=255 time=30 ms
    Reply from 192.168.2.1: bytes=56 Sequence=4 ttl=255 time=40 ms
    Reply from 192.168.2.1: bytes=56 Sequence=5 ttl=255 time=30 ms

  --- 192.168.2.1 ping statistics ---
    5 packet(s) transmitted
    5 packet(s) received
    0.00% packet loss
    round-trip min/avg/max = 30/32/40 ms

第二种解决方法：

将tunnel的工作方式改为点到多点

int t 0/0/0
ospf nework-type p2mp

第三种解决方法：

将网络拓扑改为全连网络拓扑，也就是说每一个站点都是中心站点，然后各个中心站点之间相互进行注册，前提是接口工作方式是广播方式。