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:
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
Check RPD Memory. Some times High memory utilization might indirectly lead to high CPU.
So, after working with JTAC yesterday, "I", as in I really didn't need JTAC since I figured out the issue on my own.. realized that my firewall filter was a bit redundant and was lacking a "permit any" statement.
OSPF adjacency was breaking because the firewall filter was taking the "else" traffic (term DEFAULT) and sending it to routing-instance PATH-2, which didn't help either way since it was sending traffic right back to SW-2, something a "then accept" statement would have done easily
So, to repair the issue..
New SW-2 & RTR-2 corrected configlets:
delete routing-instances PATH-2
delete firewall family inet filter FBF-TEST term DEFAULT
set firewall family inet filter FBF-TEST term PERMIT-ANY then accept
New config snips for SW-2:
routing-options {
nonstop-routing;
interface-routes {
rib-group inet STAGING-RIB;
}
static {
route 10.100.190.0/24 next-hop 10.100.100.2;
route 10.100.191.0/24 next-hop 10.100.100.2;
}
rib-groups {
STAGING-RIB {
import-rib [ inet.0 PATH-1.inet.0 ];
}
}
router-id 10.100.254.1;
}
firewall {
family inet {
filter FBF-TEST {
term TERM-1 {
from {
source-address {
10.100.190.0/24;
10.100.191.0/24;
}
}
then {
routing-instance PATH-1;
}
}
term PERMIT-ANY {
then accept;
}
}
}
}
routing-instances {
PATH-1 {
instance-type forwarding;
routing-options {
static {
route 10.100.30.0/24 {
next-hop 10.100.254.2;
qualified-next-hop 10.10.10.1 {
preference 100;
}
}
}
}
}
}
New config snips for RTR-2:
routing-options {
interface-routes {
rib-group inet STAGING-RIB;
}
rib-groups {
STAGING-RIB {
import-rib [ inet.0 PATH-1.inet.0 ];
}
}
router-id 200.200.200.2;
autonomous-system 1;
}
firewall {
family inet {
filter FBF-TEST {
term TERM-1 {
from {
source-address {
10.100.190.0/24;
10.100.191.0/24;
}
}
then {
routing-instance PATH-1;
}
}
term PERMIT-ANY {
then accept;
}
}
}
}
routing-instances {
PATH-1 {
instance-type forwarding;
routing-options {
static {
route 10.100.30.0/24 {
next-hop 200.200.200.1;
qualified-next-hop 10.100.254.1 {
preference 100;
}
}
}
}
}
}
Best Answer
Junos Olive is an unofficial and unsupported image/version that was developed by Juniper for development purposes.
As for the vMX, it's "a full-featured, virtualized MX Series 3D Universal Edge Router" (quote from Juniper). It's an official and supported product that allows the usage of a virtualized MX router in a cloud/virtual network environment. As such, all the features/commands that are available for a physical MX router are available in vMX.
Junos Olive was never built to be a fully working version while vMX was. If you need some of the missing features from Olive (or a more updated version of Junos), vMX is a good solution (but you'll need an hypervisor to install it). Otherwise Olive should be good enough.