# Automating the Junos System with op scripts

Learn how Junos op scripts can customize your device, automatically respond to events, and more.

July 7, 2016
Duvel assembly line (source: Jim via Flickr)

## 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.

## Learn faster. Dig deeper. See farther.

Join the O'Reilly online learning platform. Get a free trial today and find answers on the fly, or master something new and useful.

## 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
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:

1. Determine the interface over which the session should run. Determine whether it is down, has errors, or has high utilization.

2. Try to ping the remote side. If this fails, assume a connectivity problem. Try to reset the interface.

3. 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.