由于误引入静态路由邻居设备出现CPU升高

发布时间:  2014-06-24 浏览次数:  78 下载次数:  0
问题描述
某局点路由器RouterAV3R3升级到V6R7BGP邻居Established后,多台邻居设备出现CPU 100%。删除BGP邻居后可恢复,重新建立邻居CPU又会升高。
处理过程

【分析思路】

1、与BGP路由相关的CPU高一般是由路由震荡、环路或循环迭代引起。因此,首先需要确认BGP邻居是否有震荡,是否有大量路由更新频繁接收或发布。

2、如果并没有路由频繁刷新,则需确认是否发生路由循环迭代,即路由经过若干次迭代后下一跳迭代回自己。

最常见的是两条路由互为下一跳。也可能出现a的下一跳是bb的下一跳是c,依此类推经过几次迭代后找到下一跳还是a

3、寻找路由源头,寻找解决方案。

4、问题发生在升级之后,因此需确认问题触发条件,是否与升级有关。

 

【故障分析】

1、经确认,BGP邻居在故障期间并未震荡。在RouterAdisplay bgp peer显示MsgSent数值并不大。因此排除RouterA频繁发布路由更新导致邻居设备CPU高的可能。

 

<RouterA>display bgp peer

 

 BGP local router ID : 123.2.1.3

 Local AS number : 65500

 Total number of peers : 11               Peers in established state : 11

 

  Peer            V          AS  MsgRcvd  MsgSent  OutQ  Up/Down       State PrefRcv

 

  123.1.1.1      4       65500     2129     1766     0 0028h43m Established     934

  123.2.1.129    4       65500     1506     2081     0 0028h43m Established      70

  123.2.1.143    4       65500     1482     2055     0 0028h43m Established       3

  123.2.1.190    4       65500     1497     2069     0 0028h43m Established      20

(略)

 

2、据了解,现网的11个邻居中123.1.1.1是一级反射器,RouterA作为二级反射器,将路由反射给其他10个是客户端。出现CPU高的设备都是客户端。从现象看来,中断邻居后,对端设备CPU立刻恢复正常,邻居Established后又立刻升高,因此推断问题与客户端收到的路由强相关,很可能出现了路由循环迭代。因此,问题的关键在于找到有问题的路由。


123.2.1.143
为例,在RouterA配置ip-prefix控制向邻居发布不同网段的路由,逐渐缩小会可疑路由的范围。

bgp 65500

 ipv4-family unicast

  peer 123.2.1.143 ip-prefix to143 export

#

ip ip-prefix to143 permit 123.0.0.0 8 less-equal 32

当缩小到123.32.17.0/24~32位掩码和123.32.18.0/24~32位掩码网段范围时,发现同时发布这两段范围的路由就会引起邻居设备CPU高,但是单独发布其中任一段范围的路由却不会出现CPU高。

查看RouterA发往123.2.1.143BGP路由表,发现了可疑路由。123.32.17.190的下一跳是123.32.18.97,而123.32.18.97命中路由123.32.18.96/30,下一跳是123.32.17.190

<RouterA>display bgp routing-table peer 123.2.1.143 advertised-routes

 BGP Local router ID is 123.2.1.3

 Status codes: * - valid, > - best, d - damped,

               h - history,  i - internal, s - suppressed, S - Stale

               Origin : i - IGP, e - EGP, ? - incomplete

 Total Number of Routes: 941

      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn

...

 *>i  123.32.17.153/32    123.32.17.190    0          100        0      ?

 *>i  123.32.17.190/32    123.32.18.97     0          100        0      ?

 *>i  123.32.17.191/32    123.32.18.97     0          100        0      ?

...

 *>i  123.32.18.92/30     123.32.17.138    0          100        0      ?

 *>i  123.32.18.96/30     123.32.17.190    0          100        0      ?

 *>i  123.32.18.100/30    123.32.17.190    0          100        0      ?

... 

 

这两条路由都是来自反射器123.1.1.1。在RouterA查看IP路由表,还有一条ISIS路由123.32.18.96/30下一跳是123.1.17.105,不是123.32.17.190。因为ISIS路由优先级高于BGP路由,所以,RouterA上两条路由在IP路由表中没有出现互为下一跳的情况,因此不会出现循环迭代。

<RouterA>display ip routing-table 123.32.18.97 verbose

Route Flags: R - relay, D - download to fib

------------------------------------------------------------------------------

Routing Table : Public

Summary Count : 2

 

Destination: 123.32.18.96/30

     Protocol: ISIS-L2          Process ID: 1

   Preference: 15                     Cost: 40

      NextHop: 123.1.17.105      Neighbour: 0.0.0.0

        State: Active Adv              Age: 06h53m32s

          Tag: 0                  Priority: medium

        Label: NULL                QoSInfo: 0x0

   IndirectID: 0x0             

 RelayNextHop: 0.0.0.0           Interface: GigabitEthernet1/0/2

     TunnelID: 0x20820788            Flags:  D

 

Destination: 123.32.18.96/30

     Protocol: IBGP             Process ID: 0

   Preference: 255                    Cost: 0

      NextHop: 123.32.17.190     Neighbour: 123.1.1.1

        State: Inactive Adv Relied     Age: 06h53m32s

          Tag: 0                  Priority: low

        Label: NULL                QoSInfo: 0x0

   IndirectID: 0xe6            

 RelayNextHop: 10.1.17.105       Interface: GigabitEthernet1/0/2

     TunnelID: 0x0                   Flags: R

但是,在邻居123.2.1.143设备上,ISIS协议没有打通,IP路由表中123.32.17.190/32123.32.18.96/30都是BGP路由,且互为下一跳,因此出现了循环迭代,引起CPU升高。

 

3、寻找路由源头。查看123.32.17.190/32BGP路由信息发现该路由源自123.32.17.157,经反射器发布到RouterA

经客户确认,123.32.17.157上误将静态路由123.32.17.190/32引入BGP,并以123.32.18.97作为路由下一跳发布给邻居。客户在123.32.17.157上删除此引入路由后,CPU恢复。

<RouterA>display bgp routing-table 123.32.17.190 32

 BGP local router ID : 123.2.1.3

 Local AS number : 65500

 Paths:   1 available, 1 best, 1 select

 BGP routing table entry information of 123.32.17.190/32:

 From: 123.1.1.1 (123.1.1.1)

 Route Duration: 1d05h50m34s

 Relay IP Nexthop: 123.1.17.105

 Relay IP Out-Interface: GigabitEthernet1/0/2

 Original nexthop: 123.32.18.97

 Qos information : 0x0

 AS-path Nil, origin incomplete, MED 0, localpref 100, pref-val 0, valid, internal, best, select, pre 255, IGP cost 40

 Originator:  123.32.17.157

 Cluster list: 123.1.1.1, 123.2.1.129

 Advertised to such 10 peers:

    123.2.1.129

    123.2.1.190

    123.2.1.143

 

4、对比升级前后的版本实现,找到问题触发原因。

V3R3版本,BGP只向邻居发布在IP路由表中活跃的路由。

V6R1及之后版本,BGP 路由的发布不再受其他协议路由影响,不关心在IP路由表中是否活跃,只要在BGP路由表中优选就能发布。

因为RouterA上存在一条ISIS路由123.32.18.96/30,优先级高于BGP路由,因此在升级前,BGP路由123.32.18.96/30不会发给邻居,邻居即使收到123.32.17.190/32也不会出现循环迭代。

而升级后,该路由可以发布给邻居,邻居同时收到123.32.17.190/32123.32.18.96/30两条互为下一跳的路由,因此迭代成环导致CPU升高。

根因

问题根因在于客户在123.32.17.157误将静态路由123.32.17.190/32引入BGP路由表并发布给邻居,造成123.32.17.190/32123.32.18.96/30两条BGP路由互为下一跳。

而触发条件是RouterA升级前BGP只向邻居发布在IP路由表中活跃的路由,不会将123.32.18.96/30发布给邻居,升级后123.32.17.190/32123.32.18.96/30两条互为下一跳的路由都能发布给邻居,因此导致邻居设备循环迭代CPU升高。
解决方案

方案一:从路由源入手,在123.32.17.157设备上配置的静态路由123.32.17.190/32只是自己使用,不要引入BGP路由表,不要发布给邻居。

方案二:在BGPipv4-family unicast视图下配置active-route-advertise,仍保持BGP只向邻居发送在本地IP路由表中活跃的路由。 

方案三:在域内打通ISIS,如果邻居设备也能学到ISIS路由123.32.18.96/30且下一跳不是123.32.17.190,就不会形成循环迭代。

注:此问题的根源是静态路由的误发布,无论是方案二还是方案三都只能打破循环,而无法改变BGP路由表中这两条路由互为下一跳的存在,仍存在隐患。因此,建议方案一。

建议与总结

问题发生在升级过程中,但升级可能只是问题触发的条件,而不是根因。这种情况下,针对版本差异做规避方案,只能治标不能治本,仍存隐患。只有找到问题的根源,对症下药才能标本兼治,消除隐患。

END