Re: [Live Chat] Transcript Posted: Junos Scripting and Automation
Here's the transcript from today's live chat for those who missed it.
Transcript for Chat: 'Federal Chat', Thu Apr 29 2010 mcr16: To rockettf Welcome to the chat rockettf. We will begin in 4 minutes. mcr16: Welcome to the chat everyone. We will being in approximately 2 minutes mcr16: Please be sure you sign-in to JNet using your username and password to you are able to participate in the chat. rockettf: Hi there! ac: Feel free to send in your questions anytime everyone mcr16: To jstafford Hi jstafford. Thank you for joining the chat. Our experts are standing by, so please feel free to send you questions at any time. mcr16: To kick things off here is one of the questions that came in prior to the chat: mcr16: Q: Are there any repositories of example scripts that I can reference or use on my Junos device? A: Juniper maintains an official repository of scripts here: http://www.juniper.net/us/en/community/junos/script-automation/library/ In addition, an unofficial repository with additional scripts is located here: http://code.google.com/p/junoscriptorium/source/browse/#svn/trunk/library/juniper mcr16: Hi everyone that just joined. Thanks for attending today's chat. Our experts are standing by to answer your questions on Junos Scripting, so please feel free to send you questions at any time. mcr16: Here is another question that just came in: Q: Is it better to program Junos scripts in SLAX or XSLT? A: Both SLAX and XSLT are capable of accomplishing the same things, so this becomes a question of preference. If you are already familiar with XSLT then it makes sense to continue using that language as you would have less to learn, but if you are unfamiliar with XSLT then SLAX would likely be a better fit for you. It was designed to be more comfortable for someone with a C or Perl background, and in fact has a lot in common with the style of Junos configuration, so it will probably be an easier language to pick up than XSLT. In addition, all of the Day One guides of the Junos Automation Series are based on SLAX rather than XSLT. mcr16: Hi mnarine, we are currently working on your question. Please stand by. ac: Please make sure you sign into J-Net first if you'd like to post a question. Our experts are standing by to answer your questions in the order received mnarine: Are there any performance issues we should be aware of when running scripts? For example, we needed a script to replicate the function of SSG's Track-IP. Since this script would need to run frequently, any negatives we need to be aware of? scardali: To mnarine With scripting itself, I'd say there's no significant performance impact. What *you do* with those scripts, sure you need to consider the actions you are taking. That's where our commit / rollback model really comes into play. rfjaeger: To mnarine i think the TrackIP is just doing a frequent ping, correct? scardali: With scripting itself, I'd say there's no significant performance impact. What *you do* with those scripts, sure you need to consider the actions you are taking. That's where our commit / rollback model really comes into play. scardali: Scripts run on the RE therefore have no impact on data plane whatsoever. litvanyi: In commit scripts, it is mentioned to be careful how your script deals with boot time, as an error on the commit at boot time will result in the box booting with no config. We haven't investigated yet, but we are wondering if there is an easy way to say "don't run at boot time", since we are only using the commit scripts to catch realtime pilot error prior to a manual commit. ccall: To litvanyi Commit scripts are not currently informed if they are being run at boot-time or not, but if you are only looking for sanity checking of user changes then one approach would be to check the $user parameter and not perform any checks when the $user == "root" because that is the user that will perform the first commit. morty: Thanks for "commit confirm"! It rocks. rfjaeger: To mnarine track ip is triggered every 60 seconds so it should not affect performance mnarine: Yes, the trackIP function would just do a ping and if it fails, it would change a forwarding-instance. dark: Do you plan to add a "classical" language like perl ? scardali: To dark Perl has been supported from day 1 of JUNOScripting back in the JUNOS 7 days with off-box scripting and interfacing with JUNOS via the Perl XML API. mnarine: Also, is there a script repository of official scripts from Juniper? mcr16: To mnarine Juniper maintains an official repository of scripts here:http://www.juniper.net/us/en/community/junos/script-automation/library/ In addition, an unofficial repository with additional scripts is located here: http://code.google.com/p/junoscriptorium/source/browse/#svn/trunk/library/juniper scardali: Using the JUNOScript XML API, off-box scripting allows for remote configuration and management of a JUNOS platform (or client in this case) and the ability to create a script outside of the JUNOS operating system environment using a language such as Perl, ruby or C++ scripts on the platform of his/her choice of which those scripts interact with the JUNOS client (in this case) over the secure NETCONF based (RFC4741) protocol and make configuration additions/deletions/changes via XML. The same set of XML APIs is leveraged for on-box scripting automation. They are complementary in terms of usage. There are benefits to run a script on-box and off-box. The best part is they all run on top of the same XML underpinnings in JUNOS. scardali: Dark this was in response to your question but I saw you dropped momentarily... scardali: Using the JUNOScript XML API, off-box scripting allows for remote configuration and management of a JUNOS platform (or client in this case) and the ability to create a script outside of the JUNOS operating system environment using a language such as Perl, ruby or C++ scripts on the platform of his/her choice of which those scripts interact with the JUNOS client (in this case) over the secure NETCONF based (RFC4741) protocol and make configuration additions/deletions/changes via XML. The same set of XML APIs is leveraged for on-box scripting automation. They are complementary in terms of usage. There are benefits to run a script on-box and off-box. The best part is they all run on top of the same XML underpinnings in JUNOS. dark: I was disconnected : Nevertheless i see your answer and that i have asked a "silly" question !! scardali: To dark Not silly at all... perfect actually. morty: Question: what does the whole "JunOS Scripting and Automation" mean? Our sales guy sent this to me without much explanation. Are you guys just referring to generic scripting (i.e. expect-style), or is there a formal product that you guys sell/give away under this name? rfjaeger: To morty junos scripting is very different than expect scripting. We have supported off-box scripting, which uses an XML api to monitor and configure the router remotely. automation refers to on box scripting. there are three types: commit, event, and operation. Commit scripts allow you to verify a configuration at commit time, and take actions like display a warning, change the configuration to fix a user mistake, or fail the commit. Event scripts monitor the log and catch logged events. Based on catching an event, an action can be taken. Operations scripts allow for performing operational commands (possibly several commands) and display a result to the user. for example, troubleshooting a bgp problem may involving many show command and looking at the configuration file. The script can do several commands and consolidate the output into a series of Pass Fail tests and even tell the user exactly what is wrong with the system. rfjaeger: To mnarine so i have a bgp example i can share regarding a BGP operational script ... rfjaeger: To mnarine a. Scripting provides the ability for tier 1 engineers to solve problems on their own without escalating to tier two. One example script that’s been successful for our customer is a troubleshooting script that identifies exactly where to look for network problems. For example, a government network using IP encryptors with Red routers has both OSPF and BGP running over GRE tunnels. Our script reads through the configuration for GRE, OSPF, and BGP, looks at OSPF adjacencies, identifying which ones are not in FULL state, pings GRE endpoints to test reachability, and verifies that all configured BGP peers are ESTABLISHED. In the case of BGP, if not established, we check that the peer address can be pinged, and if so, we actually read the configuration from the down peer and do a line by line comparison pointing out problems like mismatched autonomous system numbers, or mismatched peer addresses, or if the remote router doesn’t have the local router configured as a peer. The output of the script is a very readable concise display that pulls out the pertinent information and status that is the result of a comprehensive troubleshooting exercise. rfjaeger: To mnarine does that make sense? ccall: It is probably a little out of the way for most on this chat, but I wanted to mention that Juniper will be participating in the upcoming Network Automation 2010 conference in Paris on June 1-3. We will be delivering three presentations: Reducing Opex with on-Device Automation, How to Achieve a Broader Adoption of Embedded Automation to Yield Higher Operations Efficiency, and Designing for Manageability. Here are the conference details: http://www.upperside.fr/networkautomation2010/networkautomation2010program.htm rockettf: It makes a whole lot of sense dark: Do you think it is possible to use the automation capabilities to run something like an HTTP server on the router which can display a part of the configurations (like a looking glass server but on the router itself) ? scardali: To dark My first thought is... you don't want your router running as an HTTP server. But what you could do is write an off-box script to gather the statistics you were interested in, then another off-box script to format/present the data to the HTTP service on that remote box. But again, I wouldn't think you would ever want to task your router's routing-engine as a web-server. Do you agree, does that make sense? morty: What on-device languages do you guys support? Last I checked, you weren't shipping with Perl or Ruby. scardali: To morty the JUNOS configuration is stored as XML natively. scardali: To morty on box, we support SLAX and XSL. mnarine: rfjaeger, makes sense. lots of capabilities with it... just need to use it more. dark: Well, i work as an operator and the customers want to access to some information on their routers. They have SNMP (and sometimes telnet access) but i'd like to offer them a web access rfjaeger: To mnarine that's probably a good application for off box scripting rfjaeger: To mnarine pull the information you need and display it via a browser scardali: Dark this is for you... Understood. You can give them read access to JWEB to read interface statistics and what not but the answer is still that you cannot (and do not I believe) want to run other server services on a production router. rockettf: How one can automate the troubleshooting of network connections rfjaeger: To rockettf troubleshooting what kind of connections? can you be more specific? protocols? tunnels? i always approach scripts from the perspective of how would i do it without a script. then think about how to best put that into a script that provides concise output that gets me the answer fastest -- i hate wading through show command output mcr16: Thank you everyone for submitting your questions. Our experts are still busy typing up responses, and they will be answered in the order they are submitted. In the meantime, here is another question that was submitted to our team prior to the session. Q: Can I use Junos scripting to do fun things? A: While Junos scripting was designed for production uses there is no reason why you can’t have some fun with it as well. The unofficial script repository includes two games: A Colossal Cave Adventure conversion to SLAX: http://junoscriptorium.googlecode.com/svn/trunk/library/juniper/op/games/adventure/adventure.xml And a simple game of Tic-Tac-Toe that can be played against the computer or a human opponent: http://junoscriptorium.googlecode.com/svn/trunk/library/juniper/op/games/tic-tac-toe/tic-tac-toe.xml We need more! rockettf: routing protocols and static routes Spearfish: This is my first chat, will this session be available. I realized I was not logged in and once logged in all of the chats disappeared from the window. The welcome screen displayed. ac: To Spearfish Hi Spearfish, an archive of this chat will be posted 24 hours after the event ends morty: Are SLAX and XSL powerful enough to actually let you do automations, or do you use a real language to do the heavy lifting? ccall: To morty Both SLAX and XSL are capable of fully controlling the device configuration, invoking operation commands and working with their output, etc. These on-box scripts can be invoked as part of the commit process, as custom op scripts, or in response to an event. litvanyi: I am sure as we look at implementing these kinds of things I'm going to get questions about the scripts' priority, how it is ensured we don't cause memory or cpu issues for operations, etc. I saw your answer of basically no perf impact for scripting in and of itself, but do you have something you can point me to about be "safe" in this way within scripting? Sorry for being vague. scardali: To litvanyi That's okay... good questions. Scripting like programming requires error checking. It's up to you as the programmer to test a script before implementing it (say on a lab router), but JUNOS scripting is not throttled or come with any safety guards that I'm aware of. rfjaeger: hi rockettf -- to troubleshoot protocols, typically you look for the status with "show ospf neighbor" commands, parse the output (programmatically going through the XML tags) and look for status, and if there is an issue (not in FULL), you can begin to do the normal troubleshooting things you would do from the CLI , just in a script. For GRE tunnels, you must look through the configuration for configured GRE tunnels, then attempt to ping the other end of each tunnel. With BGP, you look at your show bgp summary, and see the state. One of the really cool things is being able to grab the configurations on remote routers and compare configurations boriszhang: for on-device script, I think it have to be saved somewhere , does it sync automatically between primary and secondary RE or we have to manually sync it ,I am considering RE switchover case ccall: To boriszhang Generally speaking, the on-box scripts must be saved on the routing-engine, and yes they must be placed on all routing-engines when multiple are present (including EX virtual chassis). Junos does not currently have a way to automatically synchronize scripts between REs, but it would be easy to create an op script that did so. Note also that as of Junos 10.0 it is possible to invoke op scripts that are stored locally by using the op url command. mnarine: Not sure if this was provided before... What resources are available to learn the scripting? I am aware of the Day One book. Is there anything else provided by Juniper to help learn scripting? scardali: To mnarine There are JUNOScript references available via the technical documentation portion of the Juniper Support website to get you started with both on and off box scripting. Also, there are repositories for scripts that others have already developed. mcr16: To mnarine A: Juniper maintains an official repository of scripts here: http://www.juniper.net/us/en/community/junos/script-automation/library/ In addition, an unofficial repository with additional scripts is located here: http://code.google.com/p/junoscriptorium/source/browse/#svn/trunk/library/juniper scardali: To mnarine ‘show | display xml’ is obviously not documentation, but I find that it alleviates the need to reference documentation. If you’re not certain of the exact syntax for the JUNOS configuration you’re attempting to implement via an apply-macro, go ahead and configure it from the CLI as you normally would (remember there’s no need to commit it so you will not affect the active/running state of the JUNOS platform), then issue a ‘show | display xml’ from configuration mode and you’ve got a very simple task to achieve now by simply copying the resulting configuration change to your OS clipboard and incorporating it into your SLAX code. scardali: To mnarine show | display xml mcr16: Hi All...on a sidenote - everyone who attends this chat is eligible to receive a free copy of Junos for Dummies. All you need to do to receive your copy of the book is send the following information to JuniperNetworks-FederalEvents@juniper.net: First Name: Last Name: Organization: JNet User Name: Email: Address: Phone: Spearfish: Does anyone know of a scripting tool for JUNOS or is there a module to add-on to a product such as Notepad ++? A lot of times these type of tools come in handy to validate syntax errors, etc. or some type of validator like F5 has for their iRules, there is an F5 iRules Editor. There are tools to help with Cisco but I have not seen much if any for JUNOS. scardali: To Spearfish I really like EditPad Pro. They have a free version available, but it has the capability to color code your script as an IDE environment would do. mnarine: scardali, thanks. sounds simple enough. scardali: Spearfish: EditPad Pro also has curly-brace matching.... priceless ;-) scardali: I set the color-coding scheme to "python" Spearfish: Gotcha, Thanks... ccall: To Spearfish Something else to consider for SLAX syntax checking is to run the slax-doctor.slax script on the Junos device to check your script for common syntax errors: http://junoscriptorium.googlecode.com/svn/trunk/library/juniper/op/debug/slax-doctor/slax-doctor.xml mcr16: We have about 15 minutes left! Please continue to submit your questions. We will reach out to you after the chat session with answers to any questions we do not get to in time. Spearfish: Excellent, Thank you for the info. litvanyi: Re: impact/priority/resources - answer was do your own error checking as per any other programming task.: Well, for example, if user_1 is running some complex op script (ok, might be hard to make one sooooo complex, but work with me here), is that likely to have any impact on user_2, who is trying to diagnose the problem interactively? Or is that "programmer beware", handle dangers yourself with good programming practices, etc.? I'm sorta wondering if scripts run in the background, such that ... ccall: To litvanyi The running scripts are treated similarly to logged in users. The Junos inter-process scheduler handles the priority issues between them and the various daemons. Looking specifically at the example of an op script, it is basically equivalent to a logged in user that is entering commands at a very high rate. But, just like Junos handles the priority between user sessions and its other daemons (like routing) to prevent issues, it does the same thing with scripts. rfjaeger: since the CPU typically runs at less than 10% utilization (typically 99% idle) it should not be a problem. mcr16: We are at the 5 minute mark now, so please submit your final questions. mcr16: Here is another question that just came through: Q: What are the differences between normal changes and ‘transient changes’? A: Transient changes apply specifically to commit scripts and are often used in apply-macro scenarios where you’re looking to automate a task like creating many IPSec VPNs and by implementing an apply-macro based commit script, you have the ability to minimize the number of inputs needed per instantiation of (in this case) IPSec VPN as you’ve templated out all but the required variable inputs to each VPN config with the commit-script. The apply-macro is where you specify the per-instance variables. Sticking with this apply-macro example, if you’re creating say 10, or 50 or even 100 VPNs with apply-macros, you may or may not want those VPN configurations to appear in the JUNOS configuration as it will add a significant amount of configuration bloat. By using the <transient-changes> element within the commit-script, the administrator will not see changes made by the commit-script when viewing the active or candidate configuration. Transient changes allow for less ‘config bloat’ and also allows for intelligent configuration groups, such as if/then conditions that yield a configuration change only if a certain condition is met at the time the script is executed. mcr16: sorry for the strange symbols...those should be quotes. mcr16: Don't forget that everyone who joined today's chat is eligible to receive a free Junos for Dummies book. All you need to do to receive your copy of the book is send the following information to JuniperNetworks-FederalEvents@juniper.net: First Name: Last Name: Organization: JNet User Name: Email: Address: Phone: ac: We will post the transcript of this chat in the Junos board 24 hours after the event ends http://forums.juniper.net/t5/Junos/bd-p/JUNOS Spearfish: Just send it and Thanks for the session. dmcpherson: but transient changes can still be seen (if you want) by using "show config | display commit" scardali: To dmcpherson True... show | display commit-scripts will show you applied transient changes applied. dark: Thanks for the session and the answers ac: Thank you all for attending today's chat session ac: this concludes our session for today, have a great day! Remember to check the Junos board later for a transcript of this live chat mnarine: Thank you for the session. It was helpful. scardali: To mnarine You're very welcome!
[Live Chat] Transcript Posted:: Junos Scripting and Automation
[ Edited ]
Join us on April 29 at 2PM Eastern/11AM Pacific for a live text chat on Junos Scripting and Automation. All attendees will be eligible to receive a Junos for Dummies book! For more information please go to: