[Contents] [Prev] [Next] [Index] [Report an Error]

Creating a Macro to Read the Custom Syntax and Generate Related Configuration Statements

By itself, the custom syntax in an apply-macro statement has no operational impact on the routing platform. To give meaning to your syntax, there must be a corresponding commit script that uses the syntax as data for generating related standard JUNOS statements. To write such a script, follow these steps:

  1. Include the Extensible Stylesheet Language Transformations (XSLT) or SLAX template boilerplate.

    You must include either the XSLT or SLAX boilerplate in all commit scripts. For detailed information about this boilerplate, see Boilerplate for Commit Scripts.

    XSLT Boilerplate

    <?xml version="1.0" standalone="yes"?>
    <xsl:stylesheet version="1.0"
        xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
        xmlns:junos="http://xml.juniper.net/junos/*/junos"
        xmlns:xnm="http://xml.juniper.net/xnm/1.1/xnm"
        xmlns:jcs="http://xml.juniper.net/junos/commit-scripts/1.0">

        <xsl:import href="../import/junos.xsl"/>

        <xsl:template match="configuration">
            <!- - ... insert your code here ... - ->
        </xsl:template>

    </xsl:stylesheet>

    SLAX Boilerplate

    version 1.0;

    ns junos = "http://xml.juniper.net/junos/*/junos";
    ns xnm = "http://xml.juniper.net/xnm/1.1/xnm";
    ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0";

    import "../import/junos.xsl";
    match configuration {
        /*
            * Insert your code here.
        */
    }
  2. Include one or more XSLT or SLAX programming instructions that inspect the configuration for the apply-macro statement at a specified hierarchy level.
  3. Include one or more XSLT or SLAX programming instructions that change the configuration to include standard JUNOS CLI syntax.

    For an XSLT example, see XSLT Syntax. For a SLAX example, see SLAX Syntax.

  4. After you are finished with your commit script, save the script with the name filename.
  5. Copy the script to the /var/db/scripts/commit directory on your routing platform.

    If a platform has dual Routing Engines and you want the script to take effect on both Routing Engines, you must copy the script to the /var/db/scripts/commit directory on each Routing Engine. The commit synchronize command does not automatically copy the scripts from one Routing Engine directory into the other Routing Engine directory.

  6. Enable the script by including the file statement at the [edit system scripts commit] hierarchy level:
    [edit system scripts commit]
    file filename;
  7. If your script includes transient changes, include the allow-transients statement at the [edit system scripts commit] hierarchy level:
    [edit system scripts commit]
    allow-transients;

If all the commit scripts run without errors, any transient changes are loaded into the checkout configuration, but not to the candidate configuration. Any persistent changes are loaded into the candidate configuration. The commit process then continues by validating the configuration and propagating changes to the affected processes on the routing platform.


[Contents] [Prev] [Next] [Index] [Report an Error]