最近，我们两台Juniper对等路由器上的路由引擎CPU利用率从约10-20％的平均负载增加到80 +％。我试图找出是什么原因造成的（以及如何降低高负载）。

路由器上的一些信息：两者都运行相同的JunOS版本，都连接到相同的两个对等IXP LAN，并具有大量（几百个）（几乎相同）的IPv4和IPv6会话。这两个路由器都连接到不同的IP传输提供商，并且以相同的方式连接到我们网络的其余部分。路由引擎的CPU负载并非稳定在80％以上，有数分钟到数小时下降到正常水平，但这种下降并不常见。 br />

开始增加时，没有配置更改
指向控制平面的非单播流量没有增加
（没有）更改所转发的通信量中（尽管即使增加也没关系）

show system processes summary表示rpd进程导致CPU负载过高大量的BGP变化

我可以提出的一个可能的解释是，IXP的两个路由器之一连接的对等（或多个）对等体发送大量BGP更新。目前，我只对我的传输会话的BGP消息数量进行统计（显示没有异常活动），并且在对等LAN上有数百个BGP会话，如果要为这些会话创建图，则发现有问题的会话并不那么容易所有会议。

我的问题是：


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


#1 楼

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

如果RPD占用大量CPU，请执行以下检查并验证以下参数：


检查接口：检查路由器上是否有接口在抖动。可以通过查看show log消息和show interface ge-x / y / z扩展命令的输出来验证。解决它们为何扑动的原因；如果可能的话，您可以考虑启用链接和链接断开的保持时间。
通过查看显示日志消息的输出，检查是否有与接口或任何FPC / PIC相关的syslog错误消息。 >检查路由：通过查看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



找出为什么线程与特定前缀相关



还可以通过查看shell命令的输出来验证路由是否振荡（或路由搅动）：%rtsockmon –t
检查RPD内存。有时，高内存利用率可能会间接导致CPU占用率过高。


评论

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

–ytti
13年6月28日在8:02
show krt queue将向您显示从控件到数据平面的所有路由更新。在大多数情况下，您应该不会看到任何排队。当发生襟翼时，这可能会排队很长时间

–柔和
2013年6月28日上午8:17
由于PR836197，它实际上可能是在小时内:(

–ytti
13年6月28日在8:24
这些要点中的几个太明显了，无法提及（拍打界面，日志错误），但是rtsockmon和任务记帐建议很有见地。 SNMP似乎使用了许多CPU周期，因此下一步是弄清楚哪些机箱和工具正在轮询这些路由器。

– Teun Vink♦
13年6月28日在10:15
抱歉，如果它们太明显了，我来自技术支持背景，请用户检查其是否插入麻烦！

– Artanix
13年6月28日在10:18

#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*/*


Juniper还根据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秒）。不要忘记在完成后关闭它。 /> / Traceoptions 

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


此外，如果您运行的是易于出错的旧版本，则可能要检查代码的生命周期： >
http://www.juniper.net/support/eol/junos.html

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

如果您在日志中看到许多RPD_MPLS_PATH_BANDWIDTH_CHANGE匹配，则您可能使用了非常激进的Adjust-interval

检查“显示系统队列：内核队列，可能会出现一些线索。