JUNOS RPM: TESTING YOUR JUNIPER NETWORK WITH REAL-TIME PERFORMANCE MONITORS

Network engineers often find they need a way to test something, and then take some action if that test fails.

For example, you might want to send a constant ping down your primary internet connection, and move over to your backup line if the pings fail. You might want to test UDP jitter between two places, to make sure that VOIP calls are consistent, and send an SNMP trap if the jitter hits unacceptable levels. Or, you might want to “test” your contemptible son Brayven (13) by leaving him in charge of your award-winning horses for a week, and “put him up for adoption” if he fails to win their respect.

Wait, what was I talking about? Oh yeah: testing your network.

Well, you can do these tests oh-so-easily in Junos with a thing called Real-Time Performance Monitoring. Juniper calls this RPM for short, which seems weird to me: I think it should be RTPM. Then again, I drank a six-pack of gin before going into work today, so absolutely do not listen to a single one of my opinions.

RPM is what “other vendors” might call IP SLA. How do they work? Good question, Andrew! Observe, this explanation. Use your eyes to read the words, and your brain to understand:

 

REAL-TIME PERFORMANCE MONITORING

To make an RPM in Junos, you first create a named probe. You then create one or more tests within the probe, in which a set number of packets are sent out. In the real world people usually configure one test per probe, but you can configure more if you like.

Here’s an example of a test: after defining the target address, you tell your router how many packets to send per test. This number is known as the “probe-count”. Then, you define how long the device should wait between packets (“the probe-interval”).

When all the packets are sent, you’ve done one complete test. So for example, you might have a test in which you send 3 pings, with 5 seconds between pings. That is one complete test.

Let’s configure a probe called UPTIME_PING. As you say that name, feel free to sing it to the tune of either Billy Joe’s Uptown Girl or Bruno Mars’s Uptown Funk, depending on your age.

Within the probe, let’s make a test called PING_GOOGLE, where we ping 8.8.8.8. Let’s send 10 pings (the probe-count), with a 3 second probe-interval between pings:

set services rpm probe UPTIME_PING test PING_GOOGLE probe-type icmp-ping
set services rpm probe UPTIME_PING test PING_GOOGLE target address 8.8.8.8
set services rpm probe UPTIME_PING test PING_GOOGLE probe-count 10
set services rpm probe UPTIME_PING test PING_GOOGLE probe-interval 3

In addition, you can choose to set how long you want to wait between tests, in seconds (the “test-interval”). You can start the next test immediately (0), in a day (86400) or anything in between. It’s literally up to you!

So, once all ten pings are sent, let’s wait 5 seconds before we run the test again. In the real world you probably wouldn’t want to wait 5 seconds, you’d probably just immediately start the next test. But let’s configure it like this anyway, just to see what options are available to us:

set services rpm probe UPTIME_PING test PING_GOOGLE test-interval 5

One thing you can’t do while setting up an RPM in Junos is write a 1,000-word letter of apology to your son Brayven for leaving him locked up with your horses for 7 days. Junos will reject the letter as being invalid, and will refuse to commit it to config – no matter how heart-felt your letter might be.

Here’s our config so far:

chris@SRX110> show configuration services rpm

probe UPTIME_PING {
     test PING_GOOGLE {
          probe-type icmp-ping;
          target address 8.8.8.8;
          probe-count 10;
          probe-interval 3;
          test-interval 5;
     }
}

OTHER THINGS YOU CAN DO WITH RPMs

If the device at the other end of your test is also a Junos device, you can actually set up a ping probe to keep timestamps, using the probe-type of “icmp-ping-timestamp” Here’s the four timestamps it’ll keep:

— When the packet leaves the source
— When it arrives at the destination
— When the reply leaves the destination
— When the reply reaches the source again.

It’s clear that this level of detail will help you to make some very accurate decision making. You know: like the kind of decision making you should have employed before commanding your son to live with your handsome stallions.

You can run a test for ping of course, and UDP jitter, but you can also get it to do a HTTP-get request, or a TCP connection. The only limit is your imagination! Or, more specifically, the only limit is whatever Junos limits you to.

Setting a Junos device up to receive RPM traffic over TCP or UDP is super easy, and the commands are here.

If you want your test to go out of a specific interface, use these commands:

set services rpm probe UPTIME_PING test PING_GOOGLE destination-interface fe-0/0/1.0
set services rpm probe UPTIME_PING test PING_GOOGLE next-hop 50.50.50.2

You can use the dscp-code-points command to, well, add DSCP code points! You can even add the probe to a particular routing-instance, like so:

set services rpm probe UPTIME_PING test PING_GOOGLE routing-instance CUSTOMER-VRF-NAME

 

USING THE PROBE TO FALL OVER TO A BACKUP LINE

Once you’ve set up am RPM ping probe, you could attach it to an ip-monitoring policy. It’s this policy that decides the action to take when a probe fails.

So, for example, let’s say that we want to trigger an action if we drop three pings in a row, OR if we drop six pings in a single test:

set services rpm probe UPTIME_PING test PING_GOOGLE thresholds successive-loss 3
set services rpm probe UPTIME_PING test PING_GOOGLE thresholds total-loss 6

There’s lots of thresholds you can check, including rtt (round-trip time), jitter-rtt, and even std-dev-rtt, which allows you to configure a standard deviation that the round-trip time should fall into. (Personally, I make it clear on my online dating profiles that I’m not a “standard deviant”. No no: I’m a very unique deviant.)

Now we’ve set up our probe, and our thresholds, let’s configure the failover. Like a lot of things in Junos, IP Monitoring consists of a match/then statement. Here’s how you’d use our new ping RPM to fall over to an alternative line:

set services ip-monitoring policy FAILOVER match rpm-probe UPTIME_PING
set services ip-monitoring policy FAILOVER then preferred-route route 0.0.0.0/0 next-hop 60.60.60.2

 

CHECK THAT EVERYTHING’S WORKING A-OK

To see the status of your RPM probe, use the command show services rpm probe-results.

First you’ll see the high-points of the probe. Below you can see the probe name and destination IPs, but if you’d configured a source address and routing instance then you’d also see those at the top too. Next, you can see three sections: the current test results, the last test results, and the results over all tests.

otherchris@Home-SRX110> show services rpm probe-results owner UPTIME_PING
   Owner: UPTIME_PING, Test: PING_GOOGLE
   Target address: 8.8.8.8, Probe type: icmp-ping, Test size: 10 probes
   Probe results:
     Response received, Wed Aug 15 09:24:26 2018, No hardware timestamps
     Rtt: 25869 usec
   Results over current test:
     Probes sent: 5, Probes received: 5, Loss percentage: 0
     Measurement: Round trip time
       Samples: 5, Minimum: 25791 usec, Maximum: 26386 usec, Average: 26007 usec, Peak to peak: 595 usec,
       Stddev: 220 usec, Sum: 130033 usec
   Results over last test:
     Probes sent: 10, Probes received: 10, Loss percentage: 0
     Test completed on Wed Aug 15 09:24:09 2018
     Measurement: Round trip time
       Samples: 10, Minimum: 25722 usec, Maximum: 26537 usec, Average: 26123 usec, Peak to peak: 815 usec,
       Stddev: 252 usec, Sum: 261232 usec
   Results over all tests:
     Probes sent: 55, Probes received: 55, Loss percentage: 0
     Measurement: Round trip time
       Samples: 55, Minimum: 25722 usec, Maximum: 30122 usec, Average: 26164 usec, Peak to peak: 4400 usec,
       Stddev: 599 usec, Sum: 1439002 usec

You can also change the word probe-results to “history-results” if you just want to see the results of some of the most recent tests. This command actually gives you the results of every test, so be careful with it! Below I’ve just shown the first few lines of the results, but you might want to pipe it with something like “last 10” to just see the 10 most recent results:

otherchris@Home-SRX110> show services rpm history-results owner UPTIME_PING brief | count
Count: 35 lines

otherchris@Home-SRX110> show services rpm history-results owner UPTIME_PING brief
Owner, Test                 Probe received        Round trip time
UPTIME_PING, PING_GOOGLE    Wed Aug 15 09:28:20 2018      28153 usec
UPTIME_PING, PING_GOOGLE    Wed Aug 15 09:28:23 2018      25990 usec
UPTIME_PING, PING_GOOGLE    Wed Aug 15 09:28:26 2018      25893 usec
UPTIME_PING, PING_GOOGLE    Wed Aug 15 09:28:29 2018      26025 usec
UPTIME_PING, PING_GOOGLE    Wed Aug 15 09:28:32 2018      26106 usec

Change the word brief to detail if you want to see more information about any one of these results.

 

THAT’S IT!

Do you use RPM probes in your network? If so, why not leave a comment telling us how you use them? Please include your full configuration, plus your router’s IP address, plus the username and password, plus your bank details, your mother’s maiden name, the name of your first pet, the road you grew up on, and a high-definition scan of your passport. You know: so we can all learn from each other’s experiences.

Thank you very much for reading this post! I hope you found it helpful. If you’re on Mastodon, follow me to find out when I make new posts. (2024 edit: I’m also on BlueSky nowadays too. I was once on Twitter, but I’ve given up on it, on account of… well, I don’t need to finish that sentence, do I.)

And of course, you’ll make my day if you share this post on your social media of choice. The more people see it, the more I smile.

If you fancy some more learning, take a look through my other posts. I’ve got plenty of cool new networking knowledge for you on this website, especially covering Juniper tech and service provider goodness.

It’s all free for you, although I’ll never say no to a donation. This website is 100% a non-profit endeavour, in fact it costs me money to run. I don’t mind that one bit, but it would be cool if I could break even on the web hosting, and the licenses I buy to bring you this sweet sweet content.