task accounting juniper

[M/MX/T-series] Troubleshooting Checklist - Routing Engine High CPU

This article provides a checklist that can be used to troubleshoot Routing Engine (RE) High CPU utilization related issues on M/MX/T routers.

A checklist that can be used to troubleshoot RE High CPU utilization related issues on M/MX/T routers.

Perform the following checks:

lab> show chassis routing-engine Routing Engine status: Slot 0: <SNIP> CPU utilization: User 0 percent Background 0 percent Kernel 5 percent Interrupt 0 percent Idle 95 percent <SNIP> Routing Engine status: Slot 1: <SNIP> CPU utilization: User 94 percent Background 0 percent Kernel 0 percent Interrupt 1 percent Idle 2 percent <SNIP>

• User : Percentage of CPU time being used by user processes. For example, RPD and various other daemons.
• Background : Percentage of CPU time being used by background processes.
• Kernel : Percentage of CPU time being used by kernel processes.
• Interrupt : Percentage of CPU time being used by interrupts.
• Idle : Percentage of CPU time that is idle. For more information about the output of the 'show chassis routing-engine' command, refer to the following link: http://www.juniper.net/techpubs/en_US/junos/topics/reference/command-summary/show-chassis-routing-engine.html

If the NTPD process is high, jump to NTPD_process_consuming_High_CPU .

Look for which process is consuming WCPU (Weighted CPU). Also observe the STATE of the process.  From the output above, you can see that RPD is at 93% utilization and is in the kqread (kernel queue read) state. Also, look for TIME (number of system and user CPU seconds that the process has used) and RES (current amount of resident memory, in kilobytes which should be less than SIZE allocated to it).

If the RPD process is high, jump to RPD consuming high CPU .

For more information about the output of the above command, refer to the following link:

http://www.juniper.net/techpubs/en_US/junos/topics/reference/command-summary/show-system-processes.html

Check the output of the following commands around the time of the High CPU utilization event for any additional clues:

For more information on the above command output please refer to the following:

• show log messages | no-more       

KB22637 - Data Collection Checklist - Logs/data to collect for troubleshooting .

RPD consuming high CPU

• Check the interfaces: Check if any interfaces are flapping on the router. This can be verified by looking at the output of the show log messages and show interfaces ge-x/y/z extensive commands. Find out why they are flapping; if possible you can consider enabling the hold-time for link up and link down.  
• Check if there any Traceoptions configured.
• Check if there are syslog error messages related to interfaces or any FPC/PIC, by looking at the output of show log messages .
• Check the routes:  Verify the total number of routes that are learned by the router by looking at the output of show route summary . Check if it has reached the maximum limit.
• Check the RPD tasks: Identify what is keeping the process busy. This can be checked by first enabling set task accounting on .   Important:  This might increase the load on the CPU and its utilization; so do not forget to turn it off when you are finished with the required output collection.  Then run show task accounting and look for the thread with the high CPU time: 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 Find out why a thread, which is related to a particular prefix or a protocol, is taking high CPU. You can also verify if routes are oscillating (or route churns) by looking at the output of the shell command: % rtsockmon –t sender flag type op [12:12:24] rpd P route delete inet 110.159.206.28 tid=0 plen=30 type=user flags=0x180 nh=indr nhflags=0x4 nhidx=1051574 altfwdnhidx=0 filtidx=0 [12:12:24] rpd P route change inet 87.255.194.0 tid=0 plen=24 type=user flags=0x0 nh=indr nhflags=0x4 nhidx=1048903 altfwdnhidx=0 filtidx=0 [12:12:26] rpd P route delete inet 219.94.62.120 tid=0 plen=29 type=user flags=0x180 nh=indr nhflags=0x4 nhidx=1051583 altfwdnhidx=0 filtidx=0 Pay attention to the timestamp, behavior, and prefix. If a massive routing update can be found with the same prefix or protocol, then there could be route oscillation or interface bouncing.

http://www.juniper.net/techpubs/en_US/junos/topics/reference/general/rpd-memory-faq.html .

KB22637 - Data Collection Checklist - Logs/data to collect for troubleshooting and open a case with your technical support representative.

Another way to check the rtsockmon output is as follows:  

Then in a Unix-like OS which is not Junos OS, issue:

The output will look something like this:

The first column will be the number of times the route was added. The second column is the prefix. So in the above example, 10.51.145.116 flappe: 151 times!

Interrupt process consuming High CPU

CPU utilization: User 0 percent Background 0 percent Kernel 11 percent Interrupt 47 percent Idle 42 percent

• show chassis routing-engine
• show system process extensive | no-more
• show system virtual-memory | no-more
• show task memory detail | no-more
• show log messages | no-more

After addressing the ARP problem, the issue was resolved.

• Another trigger is due to out of band (OOB) devices. You can identify this by looking at the output of show system process extensive : PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 27 root 1 -48 -167 0K 12K RUN 223:30 48.19% swi0: sio Some particular logs from chassisd and log messages: Feb 7 00:55:53 I2CS write cmd to FPM#0 [0x0], reg 0x44, cmd 0x11 Feb 7 00:55:54 I2CS write cmd to FPM#0 [0x0], reg 0x44, cmd 0x11 Dec 22 01:19:59.261 2009 igw01.ash.re1 /kernel: %KERN-3: sio1: 164 more interrupt-level buffer overflows (total 450) Dec 22 01:20:00.847 2009 igw01.ash.re1 /kernel: %KERN-3: sio1: 315 more interrupt-level buffer overflows (total 765) Dec 28 17:37:09.835 2009 igw01.ash.re1 getty[3917]: %AUTH-3: getty exiting due to excessive running time Dec 28 17:38:17.154 2009 igw01.ash.re1 getty[3918]: %AUTH-3: getty exiting due to excessive running time This issue can be resolved by changing the console cable.

Kernel process consuming High CPU          

CPU utilization: User 0 percent Background 0 percent Kernel 87 percent Interrupt 11 percent Idle 2 percent

• show system processes memory <pid|process-name>
• From Shell:  /sbin/sysctl -a | grep vm.kmem (to verify if kernel has high memory untilization)

Some of the reasons for high kernel CPU are as follows:

• CLI sessions are not closed gracefully on the router.  In this case, one would see mgd running high on CPU, starving the kernel of CPU cycles.  1059 root 1 132 0 24344K 18936K RUN 405.0H 43.75% mgd 26275 root 1 132 0 24344K 18936K RUN 353.5H 43.75% mgd CPU utilization: User 12 percent Kernel 87 percent Interrupt 0 percent Idle 0 percent One way to address this issue is to kill the mgd processes eating up the CPU.
• 'Sampling' is enabled on the router.  This sometimes leads to high kernel CPU; to address this, reduce the rate at which you are sampling on the router.  

Cscript process consuming High CPU

• Collect the output of the following commands:
• Display logging data associated with all script processing using show log cscript.log . Check which scripts are running and consuming the HIGH CPU. For example:
• The log messages Event message: Process (41037,cscript) has exceeded 85% of RLIMIT_DATA may refer to PR722161:
• Killing the CSCRIPT process via the PID will be a temporary fix until the script starts again. The PID can be found via show sys proc exten . Example:
• Dampening script execution:
• If the CSCRIPT is still high then the script may containCPU-intensive remote procedure call. To fix this the running scripts must be deactivated from configuration. Deactivate the running scripts checked from previous command show log cscript.log | last, example below:

NTPD process consuming High CPU

Collect the output of the following commands:      

If unwanted NTP requests come into a Junos device, the NTP process will occupy resources such as memory and CPU, slowing down other processes and affecting overall system functionality. In extreme cases, the situation could result in traffic loss or protocol flaps. The most effective mitigation is to apply a firewall filter to allow only trusted addresses and networks, plus the router's loopback address, access to the NTP service on the device, rejecting all other requests. For example:

Apply the firewall filter to the lo0 interface.  

2020-06-08: Under 'RPD consuming high CPU' section, added check Traceoptions configured. 2020-02-03: Article reviewed for accuracy. Article is correct and complete.

AFFECTED PRODUCT SERIES / FEATURES

People also viewed.

Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Enabling Accounting on Inbound and Outbound Interfaces

Unlike DCU, which only requires implementation on a single interface, accounting for SCU must be enabled on two interfaces: the inbound and outbound physical or logical interfaces traversed by the source class. You must define explicitly the two interfaces on which SCU monitored traffic is expected to arrive and depart. This is because SCU performs two lookups in the routing table: a source address (SA) and a destination address (DA) lookup. In contrast, DCU only has a single destination address lookup. By specifying the addresses involved in the additional SCU SA lookup, you minimize the performance impact on your router.

An individual SCU interface can be configured as an input interface, an output interface, or both. SCU can be enabled in an IPv4 ( family inet ) or IPv6 ( family inet6 ) network. To configure SCU accounting, include the source-class-usage statement at the [edit interfaces interface-name unit logical-unit-number family (inet | inet 6) accounting] hierarchy level:

After the full SCU configuration is enabled, every packet arriving on an SCU input interface is subjected to an SA-based lookup and then a DA-based lookup. In addition, an individual set of counters for every configured SCU class is maintained by the router on a per-interface and per-protocol family basis.

Related Documentation

• Source Class Usage Overview
• System Requirements for SCU
• Roadmap for Configuring SCU
• SCU Configuration

Juniper MX Series by

Get full access to Juniper MX Series and 60K+ other titles, with a free 10-day trial of O'Reilly.

There are also live events, courses curated by job role, and more.

Junos is a purpose-built networking operating system based on one of the most stable and secure operating systems in the world: FreeBSD. Junos is designed as a monolithic kernel architecture that places all of the operating system services in the kernel space. Major components of Junos are written as daemons that provide complete process and memory separation.

One of the benefits of monolithic kernel architecture is that kernel functions are executed in supervisor mode on the CPU while the applications and daemons are executed in user space. A single failing daemon will not crash the operating system or impact other unrelated daemons. For example, if there was an issue with the SNMP daemon and it crashed, it wouldn’t impact the routing daemon that handles OSPF and BGP.

Creating a single network operating system that’s able to be leveraged across routers, switches, and firewalls simplifies network operations, administration, and maintenance. Network operators need only learn Junos once and become instantly effective across other Juniper products. An added benefit of a single Junos is that there’s no need to reinvent the wheel and have 10 different implementations of BGP or OSPF. Being able to write these core protocols once and then reuse them across all products provides a high level of stability, as the code is very mature and field tested.

Software Releases

Every quarter for nearly 15 years there has been a consistent and predictable release of Junos. The development of the core operating system is a single release train. This allows developers to create new features or fix bugs once and share them across multiple platforms.

The release numbers are in a major and minor format. The major number is the version of Junos for a particular calendar year and the minor release indicates which quarter the software was released. This happens to line up nicely for Junos 11 and Junos 12 as they directly tied the year released. For example, Junos 11 was released in 2011.

This wasn’t always the case. Before Junos 10.1, the major release didn’t line up to the year released. Historically, the “.0” release was reserved for major events such as releasing software for new products like the MX240 with Junos 9.0.

Each release of Junos is supported for 18 months. The last release of Junos in the calendar year is known as the Extended End of Life (EEOL), and this release is supported for 36 months.

Figure 1-1. Junos release model

There are a couple of different types of Junos that are released more frequently to resolve issues: maintenance and service releases. Maintenance releases are released about every six weeks to fix a collection of issues and they are prefixed with “R.” For example, Junos 11.1R2 would be the second maintenance release for Junos 11.1. Service releases are released on demand to specifically fix a critical issue that has yet to be addressed by a maintenance release. These releases are prefixed with a “S.” An example would be Junos 11.1S2.

The general rule of thumb is that new features are added every minor release and bug fixes are added every maintenance release. For example, Junos 11.1 to 11.2 would introduce new features, whereas Junos 11.1R1 to 11.1R2 would introduce bug fixes.

Most production networks prefer to use the last Junos release of the previous calendar year; these Junos releases are EEOL releases that are supported for three years. The advantage is that the EEOL releases become more stable with time. Consider that 11.1 will stop providing bug fixes after 18 months, while 11.4 will continue to have bug fixes for 36 months.

Three Release Cadence

In 2012, Junos created a new release model to move from four releases per year to three. This increased the frequency of maintenance releases to resolve more issues more often. The other benefit is that all Junos releases as of 2012 are supported for 24 months, while the last release of Junos for the calendar year will still be considered EEOL and have support for 36 months.

Table 1-1. Junos End of Engineering and End-of-Life schedule

By extending the engineering support and reducing the number of releases, network operators should be able to reduce the frequency of having to upgrade to a new release of code.

Figure 1-2. New 2012 Junos three-release candidate

With the new Junos three-release cadence, network operators can feel more confident using any version of Junos without feeling pressured to only use the EEOL release.

Software Architecture

Junos was designed from the beginning to support a separation of control and forwarding plane. This is true for the MX Series, where all of the control plane functions are performed by the routing engine while all of the forwarding is performed by the packet forwarding engine (PFE). Providing this level of separation ensures that one plane doesn’t impact the other. For example, the forwarding plane could be routing traffic at line-rate and performing many different services while the routing engine sits idle and unaffected.

Control plane functions come in many shapes and sizes. There’s a common misconception that the control plane only handles routing protocol updates. In fact, there are many more control plane functions. Some examples include:

Updating the routing table

Answering SNMP queries

Processing SSH or HTTP traffic to administer the router

Changing fan speed

Controlling the craft interface

Providing a Junos micro kernel to the PFEs

Updating the forwarding table on the PFEs

Figure 1-3. Junos software architecture

At a high level, the control plane is implemented entirely within the routing engine while the forwarding plane is implemented within each PFE using a small, purpose-built kernel that contains only the required functions to route and switch traffic.

The benefit of control and forwarding separation is that any traffic that is being routed or switched through the router will always be processed at line-rate on the PFEs and switch fabric; for example, if a router was processing traffic between web servers and the Internet, all of the processing would be performed by the forwarding plane.

The Junos kernel has four major daemons; each of these daemons play a critical role within the MX and work together via Interprocess Communication (IPC) and routing sockets to communicate with the Junos kernel and other daemons. The following daemons take center stage and are required for the operation of Junos.

Management daemon (mgd)

Routing protocol daemon (rpd)

Device control daemon (dcd)

Chassis daemon (chassisd)

There are many more daemons for tasks such as NTP, VRRP, DHCP, and other technologies, but they play a smaller and more specific role in the software architecture.

Management Daemon

The Junos User Interface (UI) keeps everything in a centralized database. This allows Junos to handle data in interesting ways and open the door to advanced features such as configuration rollback, apply groups, and activating and deactivating entire portions of the configuration.

The UI has four major components: the configuration database, database schema, management daemon ( mgd ), and the command line interface ( cli ).

The management daemon ( mgd ) is the glue that holds the entire Junos User Interface (UI) together. At a high level, mgd provides a mechanism to process information for both network operators and daemons.

The interactive component of mgd is the Junos cli ; this is a terminal-based application that allows the network operator an interface into Junos. The other side of mgd is the extensible markup language (XML) remote procedure call (RPC) interface; This provides an API through Junoscript and Netconf to allow for the development of automation applications.

The cli responsibilities are:

Command-line editing

Terminal emulation

Terminal paging

Displaying command and variable completions

Monitoring log files and interfaces

Executing child processes such as ping, traceroute, and ssh

mgd responsibilities include:

Passing commands from the cli to the appropriate daemon

Finding command and variable completions

Parsing commands

It’s interesting to note that the majority of the Junos operational commands use XML to pass data. To see an example of this, simply add the pipe command display xml to any command. Let’s take a look at a simple command such as show isis adjacency .

So far everything looks normal. Let’s add the display xml to take a closer look.

As you can see, the data is formatted in XML and received from mgd via RPC.

Routing Protocol Daemon

The routing protocol daemon ( rpd ) handles all of the routing protocols configured within Junos. At a high level, its responsibilities are receiving routing advertisements and updates, maintaining the routing table, and installing active routes into the forwarding table. In order to maintain process separation, each routing protocol configured on the system runs as a separate task within rpd . The other responsibility of rpd it to exchange information with the Junos kernel to receive interface modifications, send route information, and send interface changes.

Let’s take a peek into rpd and see what’s going on. The hidden command set task accounting toggles CPU accounting on and off. Use show task accounting to see the results.

Now we’re good to go. Junos is currently profiling daemons and tasks to get a better idea of what’s using the routing engine CPU. Let’s wait a few minutes for it to collect some data.

OK, let’s check it out:

Not too much going on here, but you get the idea. Currently, running daemons and tasks within rpd are present and accounted for.

The set task accounting command is hidden for a reason. It’s possible to put additional load on the Junos kernel while accounting is turned on. It isn’t recommended to run this command on a production network unless instructed by JTAC. After your debugging is finished, don’t forget to turn it back off with set task accounting off .

Don’t forget to turn off accounting.

Device Control Daemon

The device control daemon ( dcd ) is responsible for configuring interfaces based on the current configuration and available hardware. One feature of Junos is being able to configure nonexistent hardware, as the assumption is that the hardware can be added at a later date and “just work.” An example is the expectation that you can configure set interfaces ge-1/0/0.0 family inet address 192.168.1.1/24 and commit. Assuming there’s no hardware in FPC1, this configuration will not do anything. As soon as hardware is installed into FPC1, the first port will be configured immediately with the address 192.168.1.1/24.

Chassis Daemon (and Friends)

The chassis daemon ( chassisd ) supports all chassis, alarm, and environmental processes. At a high level, this includes monitoring the health of hardware, managing a real-time database of hardware inventory, and coordinating with the alarm daemon ( alarmd ) and the craft daemon ( craftd ) to manage alarms and LEDs.

Figure 1-4. Juniper MX960 craft interface

It should all seem self-explanatory except for craftd ; the craft interface that is the front panel of the device. Let’s take a closer look at the MX960 craft interface.

The craft interfaces is a collection of buttons and LED lights to display the current status of the hardware and alarms. Information can also be obtained.

One final responsibility of chassisd is monitoring the power and cooling environmentals. chassisd constantly monitors the voltages of all components within the chassis and will send alerts if the voltage crosses any thresholds. The same is true for the cooling. The chassis daemon constantly monitors the temperature on all of the different components and chips, as well as fan speeds. If anything is out of the ordinary, chassisd will create alerts. Under extreme temperature conditions, chassisd may also shut down components to avoid damage.

Routing Sockets

Routing sockets are a UNIX mechanism for controlling the routing table. The Junos kernel takes this same mechanism and extends it to include additional information to support additional attributes to create a carrier-class network operating system.

Figure 1-5. Routing socket architecture

At a high level, there are two actors when using routing sockets: state producer and state consumer. The rpd daemon is responsible for processing routing updates and thus is the state producer. Other daemons are considered state consumers because they process information received from the routing sockets.

Let’s take a peek into the routing sockets and see what happens when we configure ge-1/0/0.0 with an IP address of 192.168.1.1/24. Using the rtsockmon command from the shell will allow us to see the commands being pushed to the kernel from the Junos daemons.

The author configured the interface ge-1/0/0 in a different terminal window and committed the change while the rtstockmon command was running.

The command rtsockmon is a Junos shell command that gives the user visibility into the messages being passed by the routing socket. The routing sockets are broken into four major components: sender, type, operation, and arguments. The sender field is used to identify which daemon is writing into the routing socket. The type identifies which attribute is being modified. The operation field is showing what is actually being performed. There are three basic operations: add, change, and delete. The last field is the arguments passed to the Junos kernel. These are sets of key and value pairs that are being changed.

In the previous example, you can see how dcd interacts with the routing socket to configure ge-1/0/0.0 and assign an IPv4 address.

dcd creates a new logical interface (IFL).

dcd changes the interface device (IFD) to set the proper MTU.

dcd adds a new interface family (IFF) to support IPv4.

dcd sets the nexthop, broadcast, and other attributes that are needed for the RIB and FIB.

dcd adds the interface address (IFA) of 192.168.1.1.

rpd finally adds a route for 192.168.1.1 and brings it up.

The rtsockmon command is only used to demonstrate the functionality of routing sockets and how daemons such as dcd and rpd use routing sockets to communicate routing changes to the Junos kernel.

Get Juniper MX Series now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Don’t leave empty-handed

Get Mark Richards’s Software Architecture Patterns ebook to better understand how to design components—and how they should interact.

It’s yours, free.

Check it out now on O’Reilly

Dive in for free with a 10-day trial of the O’Reilly learning platform—then explore all the other resources our members count on to build skills and solve problems every day.

Stack Exchange Network

Stack Exchange network consists of 183 Q&A communities including Stack Overflow , the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Network Engineering Stack Exchange is a question and answer site for network engineers. It only takes a minute to sign up.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Cause of high CPU load on Juniper peering router's routing engine

Recently the routing engine CPU utilization on two of our Juniper peering routers increased from ~10-20% average load to 80+%. I'm trying to figure out what's causing this (and how to get this high load back down).

Some info on the routers: both run the same JunOS version, both are connected to the same two peering IXP LANs and have a large number (several hundreds) of (almost identical) IPv4 and IPv6 sessions. Both routers have a connection to a different IP transit provider and are connected in the same way to the rest of our network. The routing engines' CPU load isn't flatline on 80+%, there are drops back to normal levels for minutes to hours, but these drops are not that often.

Things I've checked:

• no configuration changes have been made at the moment the increase started
• there's no increase in non-unicast traffic directed at the control plane
• there's no (substantial) change in the amount of traffic being forwarded (though even a increase shouldn't matter)
• show system processes summary indicates the rpd process is causing the high CPU load
• there are no rapidly flapping BGP peers causing a large amount of BGP changes

One possible explanation I can come up with is a peer (or more than one) on one of the IXP's both routers are connected to sending a large number of BGP updates. Currently I only have statistics on the number of BGP messages for my transit sessions (showing no abnormal activity) and with several hundreds of BGP sessions on the peering LANs it's not that easy to spot the problematic session(s) if I should create graphs for all sessions.

My questions are:

• are there any other things I should check to find the cause of this increase in CPU load on the routing engines?
• how can I easily find out which sessions are causing these problems (if my assumption is right)? Enabling BGP traceoptions generates huge amounts of data, but I'm not sure if it gives me any real insights.

2 Answers 2

There might be some helpful information for you at the Juniper Knowledge Center .

If RPD is consuming high CPU, then perform the following checks and verify the following parameters:

Check the interfaces: Check if any interfaces are flapping on the router. This can be verified by looking at the output of the show log messages and show interfaces ge-x/y/z extensive commands. Troubleshoot why they are flapping; if possible you can consider enabling the hold-time for link up and link down.

Check if there are syslog error messages related to interfaces or any FPC/PIC, by looking at the output of show log messages.

Check the routes: Verify the total number of routes that are learned by the router by looking at the output of show route summary. Check if it has reached the maximum limit.

Check the RPD tasks: Identify what is keeping the process busy. This can be checked by first enabling set task accounting on. Important: This itself might increase the load on CPU and its utilization; so do not forget to turn it off when you are done with the required output collection. Then run show task accounting and look for the thread with the high CPU time:

Find out why a thread, which is related to a particular prefix or a protocol, is taking high CPU.

You can also verify if routes are oscillating (or route churns) by looking at the output of the shell command: %rtsockmon –t

Check RPD Memory. Some times High memory utilization might indirectly lead to high CPU.

• 1 RPD is bit annoying blackbox. On top of great suggestions rtsockmon -t and show task account, I'd also like to add 'show krt queue' as potentially useful tool. –  ytti Jun 28, 2013 at 8:02
• show krt queue will show you any route updates going form the control to the data plane. You should see nothing queued for most of the time. When a flap happens this can stay queued for quite some time –  mellowd Jun 28, 2013 at 8:17
• Due to PR836197 it could literally be in the hours :( –  ytti Jun 28, 2013 at 8:24
• A couple of those points were too obvious to mention (flapping interfaces, errors in logs), but the rtsockmon and task accounting suggestions were insightful. It looks like a lot of CPU cycles are used for SNMP, so next up is figuring out which boxes and tools are polling these routers. –  Teun Vink ♦ Jun 28, 2013 at 10:15
• 1 Sorry if they were too obvious, I've come from a support background where getting a user to check if its plugged in was a hassle! –  user275 Jun 28, 2013 at 10:18

I know this thread is old but for sake of completeness:

If the high cpu occurs randomly and you are not able to determine the process causing this we can create the script below.

With this script we are going to capture the process extensive when a process raises more than the normal or expected threshold, this should not disrupt any traffic but a MW is still recommended. However i see you have narrowed it to be RPD.

DISPLAY SET OUTPUT>

Also have you checked if any ddos messages have been reported? You could run the following commands:

Then depending what you see it can be narrowed down for example:

Juniper also has a collection list for this type of issues under KB22637

High CPU CLI Commands

Turn on task accounting and collect the task accounting detail output (three times with a gap of 30 seconds). Don't forget to turn it off after finished.

Archive /var/log as specified in Step 1 above Traceoptions

Also if you are running an old version which made be prone for bugs, you might want to check the life support of the code:

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

Another point to mention which could be a vector attack is not having protected your RE from unwanted exception traffic. Make sure you have a firewall filter under the loopback.

I have seen in the past scripts on the router causing high cpu not sure if rpd came into my view, but this is something you might not want to overlook.

If you see in the logs many hits with RPD_MPLS_PATH_BANDWIDTH_CHANGE you might be using a very aggressive adjust-interval

Check any drops on "show system queue: this is the kernel queue, some clue may appear.

Your Answer

Sign up or log in, post as a guest.

Required, but never shown

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct .

Not the answer you're looking for? Browse other questions tagged router juniper or ask your own question .

• The Overflow Blog
• Like Python++ for AI developers
• Being creative with math: The immersive artist who traded a sketchpad for a...
• Featured on Meta
• Alpha test for short survey in banner ad slots starting on week of September...
• What should be next for community events?

Hot Network Questions

• How many recipients can fit in a single Ark shared output?
• How can I force an arrow in TikZ to go horizontally into a node?
• How to get the current value of LC_CTYPE etc. in Bash?
• What happens when a sniper picks up a bigger gun in Mutants and Masterminds?
• Does the increase in German exports to Russia's neighbors make up for losses in Russia proper?
• Why does English use the French "sans" for sans serif?
• "bieten" with the meaning of "to ensure"
• What should I do if I am strongly burned out at work, but resigning now would cause problems for my coworkers and burn bridges?
• When is "ct" silent?
• Is there an algorithm to generate graphs with given order and diameter?
• Colourful Scenery
• Can the collapse of the wave function be modelled as a quantum system on its own?
• Story about a secret agent or spy with skill set by personas
• Why does ranges::for_each return the function?
• What attracted Abimelech to an old woman in her 80s or 90s?
• What is mode borrowing?
• Can you "open" RAW camera files?
• Being asked to sign a release form after being terminated
• I (rev)?(pal)? the source code, you (rev)?(pal)? the input!
• Why is each transaction broadcast twice in the Bitcoin network?
• How to describe the Sun's location to an alien from our Galaxy?
• New chain coming off under torque
• What does "(which see)" means in various Emacs help docstrings?
• How to move forward after microaggression allegations against my TA

Your privacy

By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy .

junos-rpc-task

Junos RPC YANG module for task command(s)

• Source Cooked

Version: 2019-01-01

junos-rpc-task@2019-01-01

© 2023 YumaWorks, Inc. All rights reserved.

블로그 마켓 판매자의 이력 관리를 위해 블로그 주소 변경이 불가합니다.

블로그에서 진짜 나를 기록하고 다양한 이웃과 소식을 만나보세요. 지금 시작해볼까요?

• 설정한 아이디는 나중에 변경할 수 없으니 신중하게 입력해주세요.
• 변경 전 공유된 블로그/글/모먼트 링크는 연결이 끊길 수 있습니다.
• 네이버 아이디 또는 개인정보가 포함된 문자 사용 은 피해주세요.
• 블로그 도움말에서 아이디 변경 유의사항을 확인해보세요.

1. 이전 주소로 공유된 글은 3개월간 새로운 주소로 연결을 지원하며 이후 언제든 연결이 끊길 수 있습니다.

2. 블로그 아이디는 한번 변경하면 다시 변경이 불가능 합니다.

블로그 아이디는 한번 정하면 다시 변경이 불가능합니다.

이 아이디로 블로그를 만들까요?

환영합니다! 블로그 아이디가 만들어졌어요.

기본정보를 입력해주세요..

나중에 언제든지 변경할 수 있어요.

관심분야를 선택해주세요.

선택한 분야의 글과 이웃을 추천받을 수 있어요.

인기블로거와 이웃을 맺으세요.

이웃을 맺으면 이웃새글에서 글을 받아볼 수 있어요.

The command rtsockmon is a Junos shell command that gives the user visibility into the messages being passed by the routing socket. The routing sockets are broken into four major components: sender, type, operation, and arguments. The sender field is used to identify which daemon is writing into the routing socket. The type identifies which attribute is being modified. The operation field is showing what is actually being performed. There are three basic operations: add, change, and delete. The last field is the arguments passed to the Junos kernel. These are sets of key and value pairs that are being changed.

In the previous example, you can see how dcd interacts with the routing socket to configure ge-1/0/0.0 and assign an IPv4 address.

1) dcd creates a new logical interface (IFL).

2) dcd changes the interface device (IFD) to set the proper MTU.

3) dcd adds a new interface family (IFF) to support IPv4.

4) dcd sets the nexthop, broadcast, and other attributes that are needed for the RIB and FIB.

5) dcd adds the interface address (IFA) of 192.168.1.1.

6) rpd finally adds a route for 192.168.1.1 and brings it up.

visited blogger

안녕하세요. 이 포스트는 네이버 블로그에서 작성된 게시글입니다. 자세한 내용을 보려면 링크를 클릭해주세요. 감사합니다.

글 보내기 서비스 안내

2009년 6월 30일 네이버 여행 서비스가 종료되었습니다. 네이버 여행 서비스를 이용해 주신 여러분께 감사드리며, 더 좋은 서비스로 보답할 수 있도록 노력하겠습니다.

악성코드가 포함되어 있는 파일입니다.

백신 프로그램으로 치료하신 후 다시 첨부하시거나, 치료가 어려우시면 파일을 삭제하시기 바랍니다.

고객님의 PC가 악성코드에 감염될 경우 시스템성능 저하, 개인정보 유출등의 피해를 입을 수 있으니 주의하시기 바랍니다.

작성자 이외의 방문자에게는 이용이 제한되었습니다.

{ALERTMESSAGE}

이용제한 파일 : {FILENAME}

네이버는 블로그를 통해 저작물이 무단으로 공유되는 것을 막기 위해, 저작권을 침해하는 컨텐츠가 포함되어 있는 게시물의 경우 글보내기 기능을 제한하고 있습니다.

상세한 안내를 받고 싶으신 경우 네이버 고객센터로 문의주시면 도움드리도록 하겠습니다. 건강한 인터넷 환경을 만들어 나갈 수 있도록 고객님의 많은 관심과 협조를 부탁드립니다.

주제 분류 제한 공지

네이버는 블로그를 통해 저작물이 무단으로 공유되는 것을 막기 위해, 저작권을 침해하는 컨텐츠가 포함되어 있는 게시물의 경우 주제 분류 기능을 제한하고 있습니다.

작성하신 게시글 에 사용이 제한된 문구가 포함 되어 일시적으로 등록이 제한됩니다.

이용자 분들이 홍보성 도배, 스팸 게시물로 불편을 겪지 않도록 다음과 같은 경우 해당 게시물 등록이 일시적으로 제한됩니다.

• 특정 게시물 대량으로 등록되거나 해당 게시물에서 자주 사용하는 문구가 포함된 경우
• 특정 게시물이 과도하게 반복 작성되거나 해당 게시물에서 자주 사용하는 문구가 포함된 경우

스팸 게시물이 확대 생성되는 것을 방지하기 위하여 문구 및 사용 제한기간을 상세하게 안내해 드리지 못하는 점 양해 부탁 드립니다. 모두가 행복한 인터넷 문화를 만들기 위한 네이버의 노력이오니 회원님의 양해와 협조 부탁드립니다.

더 궁금하신 사항은 고객센터 로 문의하시면 자세히 알려드리겠습니다.

수정하신 후 다시 등록해 주세요.

회원님의 안전한 서비스 이용을 위해 비밀번호를 확인해 주세요.

다시 한번 비밀번호 확인 하시면 이용중인 화면으로 돌아가며, 작성 중이던 내용을 정상적으로 전송 또는 등록하실 수 있습니다.

공감을 삭제하시겠습니까?

이 글의 공감수도 함께 차감됩니다.

작성하신 에 이용자들의 신고가 많은 표현이 포함 되어 있습니다.

다른 표현을 사용해주시기 바랍니다. 건전한 인터넷 문화 조성을 위해 회원님의 적극적인 협조를 부탁드립니다.

블로그 마켓 가입 완료

내 상품 관리에서 배송비 설정 후 상품 판매를 시작해보세요!

J-Flow is a proprietary accounting technology used by Juniper Networks that allows you to collect IP traffic flow statistics.

J-Flow enables you to export data to a UDP port on a J-Flow collector. You can also enable J-Flow on a router or network interface to collect network statistics for specific locations on your network.

J-Flow uses a connection-less protocol (UDP). When data is sent from a switch or router, the J-Flow record is purged. UDP doesn't guarantee delivery of the data. As such, inaccurate presentations of both traffic volumes and bidirectional flows, and reduced alerting capabilities, might result when using a J-Flow flow source. J-Flow traffic is based on sampled data and, therefore, might not represent all network traffic.

For more information about J-Flow , see the Juniper Networks website (www.juniper.net).

J-Flow flow source configuration

• Ensure that the appropriate firewall rules are configured.
• Ensure that the appropriate ports are configured for your IBM® QRadar® QFlow Collector .

Supported VLAN fields

• dot1qVlanId
• dot1qPriority
• dot1qCustomerVlanId
• dot1qCustomerPriority
• dot1qCustomerDEI
• postDot1qVlanId
• postDotqCustomerVlanId

Juniper AAA

published: 18th of February 2019

Junos has a robust authentication, authorization and accounting (AAA) system ensuring authenticated users have access to only the things their permissions allow.

Authentication

Junos supports two categories of user authentication.

• Local - On box user database
• Remote - TACACS or RADIUS servers.

Local Authentication

Local authentication utilizes a user database configured on the local device. Local user passwords have the following restrictions.

• At least 6 Characters long
• Cannot include control characters
• At least one change of case

Local users have a home directory automatically generated for them.

Remote Authentication

There are two methods of remote user authentication.

• TACACS - Terminal Access Controller Access-Control System
• RADIUS - Remote Authentication Dial-In User Service

Authentication Order

Multiple authentication sources can be defined. When a user attempts to login, the configured authentication sources will be attempted in order until an authentication accept is received from one of the authentication sources.

In order to consult the local user database ONLY in the event of remote authentication server failure omit the password keyword.

The local database will be used as a fallback authentication source if no remote authentication sources are available.

Authorization

Junos applies authorization policy to commands and configuration statements for all non-root users. Authorization is applied according to the following diagram.

Login Classes

A login class is a logical grouping of permission that get assigned to users. There are four default login classes.

• super-user - Root permission
• operator - View, clear, network, reset, and trace permissions
• read-only - View permissions
• unauthorized - No permissions

It is also possible to create custom login classes if the default classes do not meet your needs.

Users can be members of a single login class. The login class permissions will be applied to the user upon login.

When accounting is enabled, user activities such as logins, configuration changes, and interactive commands will be logged. The logs are sent to user defined TACACS or RADIUS servers.

Bibliography

https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/radius-accounting-configuring.html

https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/system-basics/user-access.html

https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/access-privileges-operational-mode-commands-specifying.html

On this page