Automating the Junos System with op scripts
Learn how Junos op scripts can customize your device, automatically respond to events, and more.
Op Scripts
Op and event scripts are powerful tools you can use to automate the operation of your router. Have you ever wished you had a way to script a CLI command on the router? Or that you could program your router to always run a particular CLI command when a particular event occurs? Op and event scripts can do these things and more.
In this chapter, we will focus on op scripts. However, much of this information will also help you work with event scripts.
Use Cases
Before diving into the way op scripts work, let’s take a moment to look at the big picture: what can you do with op and event scripts? To give you an idea, let’s look at some use cases.
Custom CLI Commands
Junos has a robust and useful CLI, with many, many commands to cover a variety of situations. Using the CLI, it is fairly easy to perform just about any action you desire. However, there are times when you could make things even easier if you were able to script command sequences.
Consider this example. Imagine your network has a monitoring system that reports when a BGP session goes down. Your standard response is to log in to the router, run show interfaces terse
to find the interface that carries the session, and then run show interfaces extensive
to look at the details for that interface.
You could simplify this process by simply being able to run a single command that automatically figures out which interface has the destination and then runs show interfaces extensive
for that interface.
For example, this op script takes a remote IP address and runs show interfaces extensive
for that interface:
user@r0> op show-interface ip 10.10.10.253
Physical interface: ge-1/0/7, Enabled, Physical link is Up
Interface index: 148, SNMP ifIndex: 524, Generation: 151
Link-level type: Ethernet, MTU: 1514, MRU: 1522, LAN-PHY mode,
Speed: 1000mbps, BPDU Error: None, MAC-REWRITE Error: None,
Loopback: Disabled, Source filtering: Disabled, Flow control: Enabled,
Auto-negotiation: Enabled, Remote fault: Online
Pad to minimum frame size: Disabled
Device flags : Present Running
Interface flags: SNMP-Traps Internal: 0x4000
Link flags : None
CoS queues : 8 supported, 4 maximum usable queues
Schedulers : 0
Hold-times : Up 0 ms, Down 0 ms
...output trimmed...
Automatically Responding to Events
Of course, while automating CLI command sequences is useful, it is even better if we can have the router automatically respond to events. To extend our preceding example further, imagine your standard response to a down BGP session is:
-
Determine the interface over which the session should run. Determine whether it is down, has errors, or has high utilization.
-
Try to ping the remote side. If this fails, assume a connectivity problem. Try to reset the interface.
-
Get the reason the BGP session went down from the
show bgp neighbors
output and send it (along with this troubleshooting information) to an escalation engineer.
It is possible to write a script that performs all these steps and tell the router to execute that script anytime a BGP session goes down. If the BGP session stays down, it can then send a trap to an SNMP management station that includes the information gathered.
Customizing Your Device
In addition to the specific examples just shown, you have the general benefit of being able to customize your device to do what you want in the way you want, all without asking Juniper to schedule a feature change to the operating system.
For example, one of the authors of this book helped a customer with an event script to change the way the router responded to errors on aggregated interface bundles. This customer wanted to automatically deactivate member links when a certain number of errors were seen in a short enough time. We were able to satisfy the customer’s desire using a fairly simple event script.
And we’ve even heard of larger requirements (such as “don’t advertise any BGP routes for the first 10 minutes a router is up”) that could be at least partially handled through some creative event scripts.
In short, if you wish your device behaved differently, you may be able to use an op or event script to change its behavior.
Now, with that said, there are still limits to what an op or event script can do. They can access or modify current operational or configuration state using existing CLI or shell commands, they can process their arguments and the operational or configuration state they can access, and they can produce output using a custom format. However, they cannot add new routing protocols, modify the way daemons process information, or allow access to new kinds of information that you could not discern from existing CLI or shell commands. But even with their limitations, op and event scripts can be very powerful.