JONOScripts (among others) make it possible to automatically respond to random events. For example, when detecting a 2% loss on the link to increase ospf metric. Mechanism powerful and flexible.
In our case, it took two applications:
1. Need to reserve L2-transport. And one of the ways BPDU does not pass, so that any options STP does not fit (bpdu tunneling does not work either).
2. Traffic to the client is distributed on two link as multipath bgp, the client should limit the bandwidth of the sum of these two paths. Since speed limit of the MX is placed on each ICHIP independently and sabinterfeysy client we belonged to different physical 10GE-interfaces, bandwidth limitation The brute force is not obtained.
Both problems are successfully resolved through the event scripts.
In the first case - the reaction of either OSPF, or the ping tests. If you fall main link specified list Wilanow from this trunk is removed, and in the trunk to the backup link is added. When lifting the basic link configuration is reset. Script
second - a reaction to the change of state BGP with the client. If both sessions are alive, each sabinterfeysov prescribed limit in half of the put client bandwidth. If one of the BGP fell - on the remaining poliser increases up to a full band. script
In the configuration of event policy no tricks there, so do not quote, and just lazy. If anyone interested - show, moreover, that the scripts without a description, and not oriented in slax, to understand how and with what parameters to run them, problematic, sorry.
In general, everything works. However, there are nuances.
It would seem that the fall ospf or physical interface to say in one place "shutdown" (well, or "Set disable"), in the other - "no shutdown" (ie "clear disable") can be directly, the response time of such a mechanism can be much better than the rapid-stp. Indeed - the interface went to Downe, immediately dropped OSPF, immediately went to an event, run the script, changed the config - all about all the tens of milliseconds (well, maybe a hundred). But then about a minute done commit. :-( It's not like Cisco, where the shutdown and no shutdown are processed immediately.
second nuance - how to be a lock change config? What if someone is currently editing the configuration? If you just open the configuration file, make changes and commit the, we risk to use someone's not ready to change. If we make exclusive - we simply will not be allowed to change the configuration, do not switch to a backup channel for the fall primary. If private - run the risk of unnoticed undo somebody else's changes (human or a script), made during Our commit. Nevertheless, the changes from the script private - the most viable option for manual changes - the usual edit (without options). So the risk is obtained minimal (though nonzero).
Maybe implement a lock with the expectation of their own, inside the script? For example, put a file on a semaphore while editing configuration. Alas, the idea failed: when attempting to execute any command "file ..." from a script error: "Operation allowed only from CLI". Do not put out a functional language contact to external resources. : (Something got to do what protection through jcs: dampen (), which stores data in a file system, but would not say that this defense is a beautiful and reliable.
Well, among other things, it turned out that the scripting support in general is still quite crude and buggy. For example, in 9.5R1 to the parameters of the script appended to the end gaps. 9.5R2 on why something does not work, editing by private, add in the config comment (junos: comment) - either private, or comment, but not both. If you try to run the event script does not from the root, get the error:
Oct 1931 16:31:32 eventd [932]: UI_DBASE_OPEN_FAILED: Database open failed for file '/ var / run / db / schema.db': Permission denied Oct 31 16:31:32 eventd [932]: UI_CONFIGURATION_ERROR: Process: eventd, path: \u0026lt;none>, statement: \u0026lt;none>, Opening configuration database: Could not open database schema
Sometimes, if you want to gently close the session (not just dropnut connection, and said request-end-session), we obtain the following:
Oct 1929 11:28:37 rpc name: request-end-session
Oct 1929 11:28:37 buffer trace: normal: 0x80e8000 (364/0x16c)
Oct 1929 11:28:37 buffer: {{{\u0026lt;? xml version = "1.0" encoding = "us-ascii "?>}}}
Oct 1929 11:28:37 buffer : {{{\u0026lt;junoscript xmlns = " http://xml.juniper.net/xnm/1.1/xnm " xmlns:junos=" http://xml.juniper.net/junos/9.5R2/junos " schemaLocation=" http://xml.juniper.net/junos/9.5R2/junos junos/9.5R2/junos.xsd" os="JUNOS" release="9.5R2.7" hostname="" version="1.0">}}}
Oct 29 11:28:37 buffer: {{{<rpc-reply xmlns:junos=" http://xml.juniper.net/junos/9.5R2/junos " xmlns="">}}}
Oct 29 11:28:37 buffer trace: normal: 0x80eb02d (15/0xf)
Oct 29 11:28:37 buffer: {{{<end-session/>}}}
Oct 29 11:28:37 buffer trace: normal: 0x80ed154 (13/0xd)
Oct 29 11:28:37 buffer: {{{</rpc-reply>}}}
Oct 29 11:28:37 buffer trace: normal: 0x80eb161 (69/0x45)
Oct 29 11:28:37 buffer: {{{]]>]]>}}}
Oct 29 11:28:37 buffer: {{{<!-- session end at 2009-10-29 11:28:37 EET -->}}}
Oct 29 11:28:37 buffer: {{{</junoscript>}}}
Oct 29 11:28:37 buffer trace: read fails: 0x80ef1a6 (0/0x0)
Oct 29 11:28:37 error: [filename: xmn:rpc results] [line: 6] Sequence ']]>' not allowed in content
Oct 29 11:28:37 error: [filename: xmn:rpc results] [line: 6] [input: detected an error in element content] internal error
Oct 29 11:28:37 error: [filename: xmn:rpc results] [line: 6] Extra content at the end of the document
Oct 29 11:28:37 commit script: xml-mode: could not read content
Oct 29 11:28:37 invalid reply to rpc
Oct 29 11:28:37 could not get reply
Oct 29 11:28:37 xmlXPathCompiledEval: evaluation failed
Oct 29 11:28:37 runtime error: file /var/db/scripts/op/move-vlans.slax element value-of
Oct 29 11:28:37 XPath evaluation returned no result.
В общем, скрипты - это хорошо, но, I hope future versions will be even better. :)
