MSR系列路由器OSPF端口验证告警经验案例

一、组网

二、问题描述

某银行使用MSR3011E与SR6608通过广域网对接，运行OSPF协议。MSR版本为Release 2207P02，SR6608版本为Release 2603P04。在 SR6608和MSR3011E运行OSPF对接的接口上，开启了OSPF MD5校验，MSR3011E出现以下告警信息：

15:04:58:755 2014 renshoufenhangMSR_guangdian OSPF/3/IF_AUTH_FAIL: OSPF TrapID1.3.6.1.2.1.14.16.2.6: Non-

virtual interface 10.254.9.251 index 0 Router 10.255.72.1 PacekSrc 10.254.9.249 authentication fail 6 PacketType 4 .

    信息显示，OSPF验证失败。但是此时SR6608和MSR3011E的OSPF Peer列表中都存在对方，双方路由学习正常，MSR和SR6608可以互相ping通，OSPF会话建立成功。

三、过程分析

通常情况下，如果OSPF验证失败，邻居无法建立。但是在此案例中，却出现了验证告警失败，不影响OSPF会话的现象。查看OSPF收发包debug信息：

收包：

*Mar  3 15:07:44:987 2014 renshoufenhangMSR_guangdian RM/6/RMDEBUG: OSPF 100: RECV Packet.

*Mar  3 15:07:44:990 2014 renshoufenhangMSR_guangdian RM/6/RMDEBUG: AuType: 02, Key(ascii): 0 0 64 10 0 aa c1 5d.

发包：

*Mar  3 15:07:45:979 2014 renshoufenhangMSR_guangdian RM/6/RMDEBUG: OSPF 100: SEND Packet.

*Mar  3 15:07:45:983 2014 renshoufenhangMSR_guangdian RM/6/RMDEBUG: AuType: 02, Key(ascii): 0 0 64 10 0 0 1b 71.

可以看到，收发包的Key(ascii)不一致，因此起初怀疑是双方校验配置的密码不一致。查看双方配置：

MSR侧：ospf authentication-mode md5 100 cipher $O"C5M.4\XKQ=^Q`MAF4<1!!

SR66侧：ospf authentication-mode md5 100 cipher $O"C5M.4\XKQ=^Q`MAF4<1!!

经验证，双方password一致。此时开始怀疑出现此告警时其实OSPF验证是成功的。经确认，用户的双方的机密系列号（即RFC2328里的the cryptographic sequence number）可以不同，所以收发的ospf包Key(ascII)值可以不同 。收到同一个用户的Key(ascII)是逐步增加的，同样发的序列号也是逐增的。如果顺序不对，就会打印这种告警信息。这种情况是收到的ospf 报文偶尔乱序导致的误报，并不影响ospf 邻居的建立和路由的学习。

四、解决方法

本案例中的OSPF端口验证告警属于ospf 报文偶尔乱序导致的误报，在R2311之前的MSR上时有出现。虽然不影响ospf 邻居的建立和路由的学习，但是这种告警会影响客户的使用感受，让客户产生不必要的困扰。因此，R2311以后的版本已不再打印这种误报，升级到R2311后，问题解决。

此外，对于OSPF端口验证的配置，在R2311之前的版本，对于简单验证模式，密文口令的长度必须是24位；对于MD5/HMAC-MD5验证模式，密文口令的长度必须是24位。而在R2311之后的版本，对于简单验证模式，如果以密文形式键入，则为33～41个字符的字符串；对于MD5/HMAC-MD5验证模式，如果以密文形式键入，则为33～53个字符的字符串。这里需要注意的是，R2311以后的版本密文口令输入时只能输入密文形式字符串，R2311以前的版本密文口令输入时可以输入明文字符，自动转为密文形式字符串。考虑到口令格式和长度的不同，建议两台设备在对接OSPF时端口验证时设备版本都为R2311之前或之后的版本。