Juniper对等路由器的路由引擎上CPU负载过高的原因


20

最近,我们两台Juniper对等路由器上路由引擎的CPU利用率从平均负载的10%增至80%。我试图找出是什么原因造成的(以及如何降低高负载)。

路由器上的一些信息:都运行相同的JunOS版本,都连接到相同的两个对等的IXP LAN,并且具有大量(几百个)(几乎相同)IPv4和IPv6会话。这两个路由器都连接到不同的IP传输提供商,并且以相同的方式连接到我们网络的其余部分。路由引擎的CPU负载并不是80%以上的水平,而是下降到正常水平持续数分钟到数小时,但这种下降并不常见。

我检查过的事情:

  • 开始增加时,未进行任何配置更改
  • 指向控制平面的非单播流量没有增加
  • 转发的流量没有(大幅度)变化(尽管即使增加也不重要)
  • show system processes summary指示该rpd进程正在导致较高的CPU负载
  • 没有快速震荡的BGP对等体导致BGP大量更改

我可以提出的一种可能的解释是,IXP的两个路由器之一都连接了一个对等点(或多个),以发送大量BGP更新。目前,我仅具有有关我的传输会话的BGP消息数量的统计信息(显示无异常活动),并且在对等LAN上有数百个BGP会话,如果要为这些会话创建图,则发现有问题的会话并不那么容易所有会议。

我的问题是:

  • 我还应该检查其他事情以找到路由引擎上CPU负载增加的原因吗?
  • 如果我的假设是正确的,我如何轻松找出导致这些问题的会话?启用BGP跟踪选项会生成大量数据,但是我不确定是否能提供任何真正的见解。

Answers:


17

瞻博网络知识中心可能为您提供了一些有用的信息。

如果RPD消耗大量CPU,请执行以下检查并验证以下参数:

  • 检查接口:检查路由器上是否有接口在震荡。可以通过查看show log消息和show interface ge-x / y / z扩展命令的输出来验证。解决它们为何扑动的问题;如果可能的话,您可以考虑启用保持时间以建立链接和断开链接。

  • 通过查看显示日志消息的输出,检查是否存在与接口或任何FPC / PIC相关的系统日志错误消息。

  • 检查路由:通过查看show route summary的输出,验证路由器了解的路由总数。检查是否已达到最大限制。

  • 检查RPD任务:确定什么使流程繁忙。这可以通过首先启用设置任务记帐来检查。重要提示:这本身可能会增加CPU的负载及其利用率。因此,完成所需的输出集合后,请不要忘记将其关闭。然后运行show task accounting并查找具有较高CPU时间的线程:

    user@router> show task accounting
    Task                       Started    User Time  System Time  Longest Run
    Scheduler                   146051        1.085        0.090        0.000
    Memory                           1        0.000            0        0.000  <omit>
    BGP.128.0.0.4+179              268       13.975        0.087        0.328
    BGP.0.0.0.0+179      18375163 1w5d 23:16:57.823    48:52.877        0.142
    BGP RT Background              134        8.826        0.023        0.099
    

找出与特定前缀或协议相关的线程为何占用大量CPU。

  • 您还可以通过查看shell命令的输出来验证路由是否振荡(或路由搅动): %rtsockmon –t

  • 检查RPD内存。有时,高内存利用率可能会间接导致CPU占用率很高。


1
RPD有点烦人。除了建议rtsockmon -t和show task account之外,我还想添加“ show krt queue”作为潜在有用的工具。
ytti

show krt queue将显示从控件到数据平面的所有路由更新。在大多数情况下,您应该不会看到任何排队。当发生襟翼时,可以在队列中停留很长一段时间
柔和的氛围,2013年

由于PR836197,它实际上可能是在小时内:(
ytti 2013年

其中有几点太明显了,无法提及(拍打界面,日志错误),但是rtsockmon和任务统计建议很有见地。SNMP似乎使用了很多CPU周期,因此下一步是弄清楚哪些机箱和工具正在轮询这些路由器。
Teun Vink

1
抱歉,如果它们太明显了,我来自技术支持背景,请用户检查其是否插入麻烦!
Artanix

2

我知道此线程很旧,但出于完整性考虑:

如果高CPU随机发生,并且您无法确定导致此问题的过程,我们可以在下面创建脚本。

使用此脚本,当流程的上升幅度超过正常阈值或预期阈值时,我们将广泛捕获流程,这不应中断任何流量,但仍建议使用MW。但是我看到您将其范围缩小为RPD。

snmp {
    health-monitor {
        interval 30;
        rising-threshold 60;
        falling-threshold 50;
    }
}

event-options {
    policy MONITOR-CPU {
        events snmpd_health_mon_thresh_cross;
        attributes-match {
            snmpd_health_mon_thresh_cross.event-name matches "Health Monitor.+CPU.+rising";
        }
        then {
            execute-commands {
                commands {
                    "show system processes extensive";
                }
                output-filename cpu-processes;
                destination local-flash;
                output-format text;
            }
        }                               
    }
    destinations {
        local-flash {
            archive-sites {
                /var/tmp;
            }
        }
    }
}

显示设置输出>

set snmp health-monitor interval 30
set snmp health-monitor rising-threshold 60
set snmp health-monitor falling-threshold 50
set event-options policy MONITOR-CPU events snmpd_health_mon_thresh_cross
set event-options policy MONITOR-CPU attributes-match snmpd_health_mon_thresh_cross.event-name matches "Health Monitor.+CPU.+rising"
set event-options policy MONITOR-CPU then execute-commands commands "show system processes extensive"
set event-options policy MONITOR-CPU then execute-commands output-filename cpu-processes
set event-options policy MONITOR-CPU then execute-commands destination local-flash
set event-options policy MONITOR-CPU then execute-commands output-format text
set event-options destinations local-flash archive-sites /var/tmp

您是否还检查了是否已报告任何ddos消息?您可以运行以下命令:

show ddos-protection protocols statistics brief
show ddos-protection statistics
show ddos-protection version

然后根据您看到的内容缩小范围,例如:

show ddos-protection protocols ttl statistics
show ddos-protection protocols ttl violations
show ddos-protection protocols ttl flow-detection detail  */*this cm needs prior config*/*

瞻博网络还根据KB22637提供了此类问题的收集列表

高CPU CLI命令

set cli timestamp
show chassis routing-engine (multiple snapshots, atleast 5)
show system processes extensive (multiple snapshots atleast 5)
show system users
show system connections
show system statistics

打开任务记帐并收集任务记帐明细输出(三次,间隔30秒)。完成后不要忘记将其关闭。

set task accounting on 
show task accounting detail
set task accounting off

show task memory detail
show task memeory summary
show task io
show task history
show task statistics
show task job
show task jobs
show krt queue
show krt state

日志

按照上述Traceoptions的步骤1中的说明归档/ var / log

user@router# show routing-options 
traceoptions { 
file routing-trace size 10m files 20 world-readable; 
flag task; 
flag state; 
flag timer; 
}

另外,如果您正在运行的旧版本容易出现错误,则可能需要检查代码的生命周期支持:

http://www.juniper.net/support/eol/junos.html

值得一提的另一点可能是媒介攻击,它没有保护您的RE免受不必要的异常流量的侵害。确保环回下有防火墙过滤器。

我过去曾在路由器上看到导致高CPU使用率的脚本,但不确定rpd是否进入了我的视野,但这是您可能不想忽略的事情。

如果您在日志中看到许多RPD_MPLS_PATH_BANDWIDTH_CHANGE的匹配,则您使用的调整间隔可能非常大

检查“显示系统队列”上的所有内容:这是内核队列,可能会出现一些提示。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.