Chinaunix首页 | 论坛 | 博客
  • 博客访问: 578721
  • 博文数量: 56
  • 博客积分: 5062
  • 博客等级: 大校
  • 技术积分: 773
  • 用 户 组: 普通用户
  • 注册时间: 2008-05-13 06:00
文章分类

全部博文(56)

文章存档

2016年(8)

2012年(1)

2010年(9)

2009年(3)

2008年(35)

分类: 系统运维

2010-08-02 00:20:34

Contents                                                                   Page

 

【原创】一个ISIS故障分析... 1

1ISIS故障现象描述... 2

2ISIS故障分析... 3

3ISIS故障解决方法... 6

4 故障总结... 6

 

 

 

  • 作者:张蒙 zmouc
  • 电子邮箱:meng@163.com
  • MSN
  • QQ  : 407-960-134
  • 博客地址:http://zmouc.cublog.cn
  • 建立日期:20100802
  •     本:1.1
  • 更新说明:1.1版本新增了r3路由器LSP的问题阐述
  • 版权说明:本文基于创作共用约定,内容归作者版权所有,欢迎大家转载,但要保留作者的完整信息和出处,谢谢!

 

ISIS故障现象描述

  这几天在做ISIS的实验,遇到了一个故障,实验拓扑如下:

 

 

图一(ISIS实验拓扑)

 

故障的具体现象是,在Level 1路由器r2上查看路由表如下:

 

图二(r2路由器的缺省路由)

 

可以看到,路由器r2上缺省路由的下一跳只有r3,为什么没有r4呢?

ISIS故障分析

在此,我们先来了解下ISISLevel 1路由器如何获得缺省路由:

 

ISISLevel 1路由器收到level 1LSP之后,会去查看该Level 1 LSP的头部,若其中的区域关联位(ATT)设置为1,那么表明始发这条Level 1 LSP的路由器是一台L1/L2路由器,也就是说始发这条Level 1 LSP的路由器连接到Level 2区域,所以,依据这个ATT字段是否设置,Level 1路由器就可以判断出始发这条Level 1 LSP的路由器是否具有到达骨干网的能力。若此字段被设置,那么L1路由器就会在自己的路由表内添加一条缺省路由(值得注意的是,这条缺省路由是L1路由器自己产生的,而非L1/L2路由器下发的),并且这条缺省路由的下一跳指向L1/L2路由器,也就是始发这条设置了ATT字段的Level 1 LSP的路由器,如果L1路由器收到多个L1/L2路由器下发的LSP呢?那么它会选择metric最小的路由器作为缺省路由的下一跳,若metric一致,则都添加进路由表,作为负载均衡。

 

  那么问题来了,从拓扑中可以很清晰地看到r3r4都是L1/L2路由器,并且r2通过收到的LSP可以知道这一点。同时,r2r3r4的链路代价(metric)都是一样的,那么通过上面的表述,r2应该把r3r4都作为自己缺省路由的下一跳,但是路由表中却并非如此,这是不正常的。

 

  我们来查看一下r2ISIS链路状态数据库:

 

图三(r2的链路状态数据库)

 

通过上图可以很清晰地看到,r2收到的r3Level 1 LSP的区域关联字段被设置,而r4Level 1 LSP的区域关联字段却没有被设置,这导致了r2认为r4是一台Level 1路由器,而非L1/L2路由器,从而判断出r4路由器有问题。

 

  先来查看r4的邻接关系状态:

 

图四(r4的邻接关系状态)

 

可以看到,所有的邻居都已经是UP状态,说明邻接关系完全正常,但也看到了不正常的一点,那就是对于em4.45这个接口的对端邻居,其system-id字段直接是数值形式,而非路由器hostname形式,这不正常。

 

  通过试验拓扑我们知道r4em4.45连接的是r5,那么r4为什么没有获得r5hostname呢?我们知道,hostname这个信息是通过Dynamic Host Name TLV传递的,而这个TLV是封装在LSP报文中的,从而说明r4根本没有获得r5发送给它的LSP,这一点可以通过查看r4Level 2链路状态数据库来确认:

 

图五(r4Level 2链路状态数据库)

 

可以看到,r4Level 2链路状态数据库根本没有来自r3r5Level 2 LSP,这说明它们之间的LSP交换出现了问题。

 

  通过上面的分析,r4与邻居之间的邻接关系完全正常而LSP的交换不正常,这一点通常都是由于基于level的认证不通过导致的,我们在r4上配置:

 

mm# set logical-routers r4 protocols isis no-authentication-check

 

r4对接收到的LSP进行伪认证处理,也就是说r4仍然会对收到的LSP进行认证核查,但是即使认证不通过,也会接受该LSP,并放入链路状态数据库中,我们再来查看r4的邻居的邻接关系状态:

 

 

图六(配置了伪认证后r4的邻接关系状态)

 

  可以看到,现在r4的邻接关系已经完全正常了,通过查看r4Level 2链路状态数据库来进一步确认:

 

图七(配置了伪认证后r4Level 2链路状态数据库)

 

现在r4Level 2链路状态数据库已经能够正常接受r3以及r5LSPISIS运行恢复正常。

 

现在我们来看一下r2的路由表:

 

图八(r2的缺省路由)

 

可以看到,r2的缺省路由已经有两个等价有效的下一跳,分别是r3r4,至此故障原因已经清楚:r4r3r5Level 2认证不匹配。

 

2.2 82版本更新

  虽然现在问题解决了,但是有的同学可能会问,为什么r4的邻接关系示意图中(图四)中r3system-id显示的是hostname呢?要知道r3r4r5这三者维护一个Level 2链路状态数据库,既然最后确定是r4Level 2认证配置错误,r3r5Level 2认证配置都正确。

那么没有道理不能收到r5hostname,而能收到r3hostname

  这个问题的描述呢,全部都是正确的,只是忽略了一点,r3r4都是L1/L2路由器,它们之间除了维护一个Level 2的链路状态数据库,同时还维护一个Level 1的链路状态数据库,而区域49.0002Level 1运行是完全正常的,所以r4可以通过Level 1LSP获得r3hostname,如下图所示:

 

图九(r4Level 1 LSP

 

ISIS故障解决方法

通过上面的分析,我们分别重新配置r3r4r5Level 2认证,最后提交,然后再分别查看各相关路由器的邻接关系状态、链路状态数据库、路由表,一切恢复正常,至此,故障解决。

故障总结

  准确的配置是保证网络正常运行的第一要务,其次故障发生后,准确的分析和推理也很重要。

 

  

张蒙

2010/8/2

阅读(3021) | 评论(2) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2010-11-12 17:39:37

不是IOS,是Junos,版本为8.5R1.14

chinaunix网友2010-10-02 00:36:21

你使用的IOS版本是什么?