H3C 交换机采用自定义 ACL 查找OSPF Router ID 冲突方法

对于OSPF网络中，Router ID是标识OSPF设备的重要依据，一旦冲突会导致OSPF LSA频繁的老化和产生，进而导致网络不稳定。对于OSPF Router ID冲突的故障现象及通过LSDB查方法，可查看如下链接案例：http://kms.h3c.com/View.aspx?id=43808，总结起来就是通过观察每台运行OSPF设备LSDB表中相关LSA的老化时间、序列号的变化来判断Router ID的产生，进而判断出存在冲突相关设备。

但是通过观察LSBD表项来判断存在Router ID冲突的问题，在实际的大型网络中排查实现难度较大：

原因一：OSPF LSDB表项在实际网络中信息大，通过检查LSA的老化时间、序列号的方法耗时耗力；

原因二：通过人工的检查LSDB表项存在遗落的风险，排查效率低；

原因三：OSPF LSDB表项变化，对一线工程师理论知识、经验要求高，受众面较低。

那么，有没有更加高效且简便的方法呢？方法当然是有的，下面将介绍在交换机上通过部署自定义ACL来判断OSPF网络中Router ID冲突的方法。

在正式介绍自定义ACL方法前，我们先需要明确在实际网络中，某交换机上哪些部署环境将导致存在OSPF Router ID冲突，总结起来存在如下几点：

环境1：同Area区域直连设备之间OSPF Router ID冲突；

环境2：同Area区域非直连设备之间OSPF Router ID冲突；

环境3：不同Area区域非直连设备之间OSPF Router ID冲突，不引入外部路由；

环境4：不同Area区域非直连设备之间OSPF Router ID冲突，引入外部路由。

对于环境1，同Area区域直连设备之间如果OSPF Router ID冲突，则设备之间无法建立OSPF Peer，好排查。

对于环境2、3、4，设备之间OSPF Peer均可正常正常建立，常规方式仅能通过观察LSDB信息来判断，难度大，因此可以通过部署自定义ACL方法来进行判断排查。

以下面的拓扑图为例，SW1、SW2、SW3 三台交换机运行OSPF协议：

• 当这三台设备属于同Area时，若SW1、SW3设备Router ID均为1.1.1.1冲突（环境2的情况），如下拓扑部署所示：

由于SW1、SW3均与SW2建立了OSPF邻居，但是SW1、SW3的Router ID冲突，因此LSBD表中的LSA信息会大量的刷新（具体原因见案例http://kms.h3c.com/View.aspx?id=43808说明），在SW1上会频繁收到如下报文：

上述报文为SW2发给SW1的LSU报文，携带了SW3发来的路由信息，其中Adertising Rouer:1.1.1.1为SW3的Router ID（与SW1冲突）。

• 当这三台设备属于不同Area时，若SW1、SW3设备Router ID均为1.1.1.1冲突，且不引入了外部路由（环境3的情况），如下拓扑部署所示：

由于SW1、SW3均与SW2建立了OSPF邻居，且在不同的Area中。在SW1与SW2建立邻居关系时，SW1会收到SW2的如下报文：

上述报文为SW2发给SW1的LSU报文，携带了SW3发来的路由信息，其中Adertising Rouer:1.1.1.1为SW3的Router ID（与SW1冲突）。

• 当这三台设备属于不同Area时，若SW1、SW3设备Router ID均为1.1.1.1冲突，且引入了外部路由（环境4的情况），如下拓扑部署所示：

由于SW1、SW3均与SW2建立了OSPF邻居，且在不同的Area中。当SW3引入了外部路由8.8.8.8时，当SW1与SW3 Router ID冲突时，在SW1上会频繁收到如下报文：

上述报文为SW2发给SW1的LSU报文，携带了SW3发来的路由信息，其中Adertising Rouer:1.1.1.1为SW3的Router ID（与SW1冲突）。

对上述的情况进行分析可得知，当SW1与下游的某一台设备存在OSPF Router ID冲突时，SW1将会收到Adertising Router为自己（1.1.1.1）的LSU报文。由于Adertising Router字段在OSPF LSU协议报文的字段位置相对固定（一个LSU报文中将可能携带多个LSA，在每个LSA中都包含Adertising Router字段），因此我们变可通过自定义ACL的方式，将这种报文给定义出来。举例：

#

acl number 5001

 rule 1 permit l2 01010101 ffffffff 70 //“01010101”为Adertising Router：1.1.1.1十六进制表示；“70”表示字段的偏移量，表示OSPF LSU报文第一个LSA中Adertising Router固定的偏移量为70字节（受设备芯片限制最大便宜量为95字节）。

#

截止目前，我们已经将OSPF Router ID冲突的交互报文给定义出来了，下面就通过在中间非运行OSPF的设备物理接口上用包过滤方式，将其过滤掉。这样将造成设备与下游存在Router ID冲突的网络首次建立邻居时无法建立OSPF FULL关系，进而快速缩小排查网络设备的范围。举例如下：

如上图所示，增加SW4 二层交换机红圈接口inbound方向部署packet-filter自定义acl，对Adertising Router为冲突的IP地址的LSU过滤。步骤如下：

第一步：SW4创建ACL 5001，并在物理接口下发包过滤规则

#
acl number 5001
 rule 2 deny l2 01010101 ffffffff 70 //冲突的Router ID 1.1.1.1 十六进制表示
#
interface GigabitEthernet3/0/18
 port link-mode bridge
 combo enable copper
 packet-filter 5001 inbound
#

第二步：将SW4与SW1、2交换机互联，确保接口UP。

第三步：在SW1上通过display ospf peer命令观察邻居状态

<SW1>dis ospf peer 

                  OSPF Process 1 with Router ID 1.1.1.1
                        Neighbor Brief Information

 Area: 0.0.0.0        
 Router ID       Address         Pri Dead-Time      State           Interface
 2.2.2.2         12.1.1.2        1   38         Loading/DR        XGE1/0/1

由于SW1一直无法收到SW2发来的带有Adertising Router=1.1.1.1的报文，因此与SW2的邻居一直处于Loading状态。

到此为止，我们便可以确认造成SW1 OSPF Router ID冲突的设备是在SW1的1/0/1下游的网络设备造成。

按照同样的方法，将部署了ACL 5001包过滤的二层交换机SW4串如到下行网络设备之间，依次检查，逐步缩小网络范围，直到找到冲突的另一台设备。比如：将SW4串如SW2与SW3之间

在SW2上观察ospf邻居表可发现与SW3之间的无法建立OSPF FULL邻居，说明在SW2上，互联SW3设备的下游网络存在与SW1 OSPF Router ID冲突的情况。

[SW2]dis ospf peer 

         OSPF Process 1 with Router ID 2.2.2.2
               Neighbor Brief Information

 Area: 0.0.0.0        
 Router ID       Address         Pri Dead-Time     State           Interface
 1.1.1.1         23.1.1.3        1   37         ExStart/DR        GE1/0/2
 1.1.1.1         12.1.1.1        1   35         Full/DR         GE1/0/1 

以上内容便是通过自定义ACL的方式，来定位排查网络OSPF Router ID冲突的方法。有同学可能会有疑问，为什么非要在网络中增加一台二层交换机，在二层交换机（非运行OSPF的设备）上部署自定义ACL包过滤规则，难道不能直接在运行OSPF的三层设备接口上下发自定义ACL过滤吗？若对此感兴趣，可接着下面的分析。

对于我司的交换机，当使能OSPF协议后，设备会自动在交换机底层下发ACL，将OSPF的协议报文上送到交换机CPU处理，具体ACL如下：

========
Acl-Type RX IPv4 Middle High, Stage IFP, Global, Installed, Active
Prio Mjr/Sub 523/21, Group 1 [1], Slice/Idx 6/34, Entry 95, Double: 1058/1314
Rule Match --------
        Ports: 0x00001fffffffffffe; 0x22223ffffffffffff
        Lookup: VLAN ID valid[y], STP forwarding, 0x1c, 0x1c 
        Dest IP: 224.0.0.5, 255.255.255.255 
        IP protocol: ospf
        Vlan Class id: 0x0    Mask: 0x20
Actions --------
        CAR cir 0x400, cbs 0x800, pir 0x400, pbs 0x800, mode srTCM color blind,Bytes
        Account mode  packets,  green and non-green 
        Copy_to_cpu : Yes  //对OSPF协议报文，进行上送CPU的处理
        Change CPU pkt COS 35
        Permit
        Red Deny 
        Red_Copy_to_cpu : No
        Yel Deny 
        Yel_Copy_to_cpu : No
MatchedName:11, IPV4_MC_OSPF_5 
Accounting: Hi 0, LO 0
========
Acl-Type RX IPv4 Middle High, Stage IFP, Global, Installed, Active
Prio Mjr/Sub 523/21, Group 1 [1], Slice/Idx 6/35, Entry 96, Double: 1059/1315
Rule Match --------
        Ports: 0x00001fffffffffffe; 0x22223ffffffffffff
        Lookup: VLAN ID valid[y], STP forwarding, 0x1c, 0x1c 
        Dest IP: 224.0.0.6, 255.255.255.255 
        IP protocol: ospf
        Vlan Class id: 0x0    Mask: 0x20
Actions --------
        CAR cir 0x400, cbs 0x800, pir 0x400, pbs 0x800, mode srTCM color blind,Bytes
        Account mode  packets,  green and non-green 
        Copy_to_cpu : Yes //对OSPF协议报文，进行上送CPU的处理
        Change CPU pkt COS 35
        Permit
        Red Deny 
        Red_Copy_to_cpu : No
        Yel Deny 
        Yel_Copy_to_cpu : No
MatchedName:12, IPV4_MC_OSPF_6 
Accounting: Hi 0, LO 0
========

缺省下发的OSPF ACL规则类型属于Acl-Type RX IPv4 Middle High，主优先级为523

而我司交换机上部署自定义ACL过滤规则，其在底层下发的情况如下：

========
Acl-Type PktFilter UDF on PORT, Stage IFP, SinglePort, Installed, Active
Prio Mjr/Sub 520/26, Group 4 [4], Slice/Idx 4/0, Entry 720, Single: 2048
 ACL GroupNo : 5001, RuleID : 2 
Rule Match --------
        Ports: 0x01000000; 0xffffffff
        Lookup: STP forwarding, 0x18, 0x18 
        Udf Data: 01010101      Udf Mask: ffffffff
Actions --------
        Deny 

管理员下发的自定义ACL规则类似属于Acl-Type PktFilter UDF on PORT，主优先级为520。

由于“自定义ACL规则”内部主优先级为520，小于“缺省下发的OSPF重定向CPU ACL规则”内部主优先级523，因此对于使能了OSPF的交换机设备当收到OSPF协议报文将重定向给CPU处理，而不会被包过滤给阻断掉。所以我们需要借助第三台不是能OSPF的二层交换机部署自定义ACL规则进行过滤操作。

步骤一：在非使能OSPF的二层交换机上物理接口inbound方向上部署自定义ACL，拒绝冲突IP字段；

#
acl number 5001
 rule 2 deny l2 xxxxxxxx ffffffff 70 //xxxxxxxx请根据实际情况添加冲突Router ID IP地址的十六进制形式
#

步骤二：将部署了自定义ACL的交换机串如网络中（网络流量会中断，请提前申请割接窗口期）；

步骤三：检查OSPF邻居状态，当发现某邻居无法建立时，则说明下游网络中存在OSPF Router ID冲突。

当网络中发现存在OSPF Router ID冲突时，但是运行OSPF协议的设备量太大，无法一一检查设备配置时，可向客户申请割接窗口期，通过自定义ACL方法来逐步缩小故障范围。自定义ACL方法：

优点：

1、配置简单易上手——仅需在二层交换机上创建ACL，其中偏移量70无需调整，仅需修改转换对应IP即可，操作员无需大量协议理论基础知识；

2、减少网络震荡范围——可逐个接口部署检查，避免大面积断网；

3、加速问题定位时间——部署操作后，仅需观察OSPF邻居状态即可判断。

缺点：

1、成本增加——需要增加一台支持自定义ACL的交换机，及相互互联线路；

2、需要现场人员配置——无法实现仅通过远程登录设备直接判断；

3、部分业务需要中断——增加二层交换机时，将导致对应业务中断。