Scripting and Customization in JUNOS

Previous posts have shown you how to maneuver around within the JUNOS configuration hierarchy, and how it checks for correct syntax every time you hit the space bar as you're entering a configuration line.

But there are times when you can enter all the individual lines of a configuration correctly, and the configuration can still be wrong. That is, the combination of commands do not work correctly together or there's something missing among the lines.

From Network World editor: LIVE CHAT: IPv6 strategies for the enterprise

Chat live with Fred Wettling, Patrick Grossetete, Ciprian Popoviciu on Wednesday Sept. 10 from 2 p.m. to 3 p.m. EST. The co-authors of the book Global IPv6 strategies will be available to answer your questions about IPv6.

In the following example, I set up a very simple BGP configuration. First, I move from the top of the hierarchy to a BGP peering group that I've named External_Peer. I didn't have to use the set command to create this group; just by moving to that level, the group is created for me. Next, I specify a neighbor at 172.16.1.5. Then I specify that the neighboring autonomous system for the group is 65502. Finally, I specify that an export policy named External_Peer_Policy is used to modify or filter routes sent (exported) to the neighbor. When I'm done, I return to the top of the configuration hierarchy.

At each configuration line JUNOS accepts the entries, indicating that I have not made any mistakes (extraordinary for me):

[edit]jeff@Juniper5# edit protocols bgp group External_Peer [edit protocols bgp group External_Peer]jeff@Juniper5# set neighbor 172.16.1.5 [edit protocols bgp group External_Peer]jeff@Juniper5# set peer-as 65502 [edit protocols bgp group External_Peer]jeff@Juniper5# set export External_Peer_Policy [edit protocols bgp group External_Peer]jeff@Juniper5# top [edit]jeff@Juniper5#

But then when I try to commit the configuration, JUNOS objects:

[edit]

jeff@Juniper5# commit error: Policy error: Policy External_Peer_Policy referenced but not defined [edit protocols bgp group External_Peer]BGP: export list not appliederror: configuration check-out failed

'export'

[edit]jeff@Juniper5#

It's telling me that the export policy I referenced in my BGP configuration does not exist anywhere in the configuration. (It should be found somewhere under the [edit policy-options] level).

When the commit command is invoked, JUNOS runs a set of scripts that examine the candidate configuration. If some situation is found, like the one I just showed you, in which the various lines of the configuration do not work together, the commit fails and an error message is displayed explaining why the commit failed.

By the way, you can use the commit check command to tell JUNOS to run the scripts against the candidate configuration without attempting a commit. That's very useful if you're adding a bunch of new statements to the configuration and want the scripts to occasionally check your work as you go.

These kinds of error-checking scripts have been consistently added to JUNOS since its inception, and are based on observed configuration inconsistencies or those that the JUNOS development team can anticipate.

There is another use for such scripting that goes beyond checking for errors and inconsistencies. The same sorts of scripts could be used to verify that the configuration adheres to a best practice. But whose best practice? Every network is different, and the rules you set for your configuration standards might be different from the rules I set for my configuration standards.

There is no way for JUNOS developers to write scripts that cover every possible configuration preference, so instead they did something radical and opened the scripting to JUNOs users with a capability called commit scripts.

Commit scripts allow you to write your own scripts for checking your candidate configuration whenever you invoke the commit command. They work alongside the error and inconsistency checking scripts that run whenever you do a commit, but these custom scripts are written for your network, to insure not just that the configuration is right but that it adheres to standards you've designed for your network:

Maybe you require all of your operators to have a description accompanying every interface, providing certain information about the interface for maintenance and troubleshooting reference. You can write a commit script to do that.

Maybe in your network, RSVP-TE should run on all SONET interfaces. You can write a commit script that looks at all the SONET interfaces on the router and verifies that each one is accounted for under the [edit protocols mpls] hierarchy.

Maybe your configuration standard requires certain traceoptions (statements similar to IOS debug that gather information on specified traffic or behaviors and adds it to a file) to be enabled globally for BGP, other traceoptions to be enabled for each BGP peer group, and still other traceoptions to be enabled for each neighbor under each group. And you require every neighbor to be running MD5 authentication. You can write a commit script to check all that.

Your commit script could be as simple as checking to make sure that every configuration includes your standard security banner and that it will be displayed whenever anyone logs in.

The point is that you want your configuration files to have certain features and be organized in a certain way. You can write a custom commit script that checks exactly the parameters you specify, and prevent the candidate configuration from successfully becoming the active configuration of it fails the check.

You can write a commit script using either the Extensible Stylesheet Language Transformation (XSLT) or the Stylesheet Language Alternative Syntax (SLAX) scripting language. If a script you've created runs and finds something that you have deemed out of spec, the script will stop the commit and display an error or warning message (also of your specification), or send a custom message to a syslog server.

It can also – and this is where things start to get cool – correct the configuration file to bring it into compliance with your configuration standard. This is done with a macro, and at this point you should start to see the value of commit scripts: Configurations that are inconsistent from one router to another in your network, or even inconsistent among different parts of the same configuration, can slow down operations personnel as they try to figure out the different configurations. And they are a source of mistakes as operators misinterpret or simply miss something that someone else wrote out of standard.

Configuration scripts can be used to insure that every one of your configurations is 100% in compliance with your configuration standards, 100% of the time.

But back to those macros. It turns out that these are very powerful tools for simplifying your network operations. I'll write about them in my next post.

Related:

Copyright © 2008 IDG Communications, Inc.

The 10 most powerful companies in enterprise networking 2022