Build and Packaging Procedure

A virtual build environment is included with the SDK and runs in the VMware Player you install on your development computer.

You can also install the VBE on a server for multiple users to share.

The VMware image provided of the virtual build environment is FreeBSD version 7.1. While it is possible to create your build environment directly in a FreeBSD operating system without VMware, Juniper Networks supports only the the VBE released as a part of the SDK. The VMware Player must be downloaded directly from the VMware website.

These instructions assume that you have already installed the Junos Software and the Junos SDK, and that you are about to build your first SDK application. For details about installing the Junos Software, see the Junos Software Installation and Upgrade Guide in the Juniper Networks documentation set. For details about installing the SDK, see the installation guide included with this package.

If you are porting an application environment to the 9.6 or later release, see Porting an SDK Build Environment from a Release Prior to 9.6.

Sandbox Overview

This section assumes you have already read the detailed installation instructions that are included with this documentation package.
When you use pkg_add to unpack the Junos SDK, the package adds the junos-sdk directory to your system. By default, this directory is created in /usr/local. It includes two packages:

You then use the mksb command to create a sandbox for your application code. Code in your sandbox is compiled and linked with the libraries in the backing sandbox to produce an SDK package that can be loaded on a supported Junos router (using the regular Junos package install semantics) without any disruption in service.

The following figure summarizes the SDK build process:


Build Process

The end product of the build process is a package that your customers install on a Junos router. This package contains the daemons, shared libraries, installation scripts, and other files neccessary for your particular value-added functionality.

For example, the Junos Software places many of its daemons, such as rpd, mgd, and so forth, in a jroute package. If you were the SDK developer for the Acme Corporation, you might have an acme_corp package. The package build makefile in sandbox/src/lib/ddl/input/ would include the command and configuration DDL files for each SDK-built daemon in the package and the XML file to describe the daemon to the system.

Your package name must not exceed 51 characters; otherwise, the system will fail to mount the package and validation will fail.

Entering a Sandbox

To change directories to a sandbox, and especially to switch between multiple sandboxes, it is important to use the UNIX workon utility rather than sourcing the sandbox environment into an existing shell. workon starts a subshell that you can exit at any time to drop the context of the current sandbox.

The syntax is:

workon [-base SB_BASE] sandbox-name [command [args]]

For example:

workon /build65/jsmith/sb-9.6

If no SB_BASE is provided and sandbox-name is not an absolute path, the system looks in any directories named in the environment variable SB_BASE_PATH. It then looks in the current directory for a directory containing a sandbox called sandbox-name. The environment variable WORKON_SB_BASE is then set to the base directory under which the sandbox was found.

Each invocation of workon starts a new Unix shell. If you perform operations such as upgrading your backing sandbox, navigating between trees, or changing .sandbox-env, you need to exit and re-enter the workon shell. Be careful not to invoke workon from within a workon shell.

Typical Setup Tasks

Follow these steps to add your application to the build environment.

  1. Update the daemon table and the requirements table with your application information. For details, see Updating System Tables to Describe Your Application.

  2. Add variables to the top level makefile for the application to represent the *_odl.h, *_out.h and *.sequence.h filenames in source file includes.

    You will use two different variables in makefiles and in the manifest. Both are set automatically by the SDK installation process:

    For example, the following in the jnx-ifinfod makefile uses the PROVIDER_PREFIX variable (for a sample use of INSTALLDIR, see Writing the Manifest later in this topic):

    .include <>
    CFLAGS += -DJNX_IFINFOD_ODL_H="<xmltags/${PROVIDER_PREFIX}-ifinfo_odl.h>"
    CFLAGS += -DJNX_IFINFOD_OUT_H="<feature/${PROVIDER_PREFIX}-ifinfo_out.h>"
    CFLAGS +=

    Your source files then use the variable names when they include these header files. For example, jnx-ifinfod_config.c includes the following:

    #include JNX_IFINFOD_OUT_H

  3. In sandbox/src/lib/ddl/input, update the makefile to include your new user-interface definitions (see Creating the User Interface in the Hello World code example for a more extensive example).

    For example:

    .include <>

  4. In sandbox/src/lib/odl/input, update the makefile to include the ODL file. For example:

    .include <>
    ${PROVIDER_PREFIX}-app1_INPUT_FILES += app1.odl
    ${PROVIDER_PREFIX}-app2_INPUT_FILES += app2.odl

  5. Your ODL files compile into libraries that need to be linked into your applications. Thus, you will also need to add variables referencing the libraries (in this example, LIB_APP1_ODL) to your application's makefiles:

    1. Add ${LIBAPP1_ODL} to the DPLIBS list in the sandbox/src/sbin/app1/Makefile.

    2. To sandbox/src/build/mk/, add the following:
      LIBAPP1_ODL= ${OBJTOP}/lib/odl/xmltags/lib${PROVIDER_PREFIX}-app1-odl.a

  6. Place your process code in the sandbox/src/sbin directory. The following example shows a directory structure containing two sets of code, jnx-exampled and jnx-ifinfod:

    [user@junos-10_0-sdk ~/102SBs/my-sb/src]$ ls -R sbin
    Makefile                jnx-exampled            jnx-ifinfod             jnx-ifinfod-ctrl
    Makefile                jnx-exampled_kcom.c     jnx-exampled_snmp.c     jnx-exampled_ui.c
    jnx-exampled.h          jnx-exampled_kcom.h     jnx-exampled_snmp.h
    jnx-exampled_config.c   jnx-exampled_main.c     jnx-exampled_trap.c
    jnx-exampled_config.h   jnx-exampled_mthd.c     jnx-exampled_trap.h
    Makefile                jnx-ifinfod_conn.h      jnx-ifinfod_mthd.c      jnx-ifinfod_util.c
    jnx-ifinfod_config.c    jnx-ifinfod_kcom.c      jnx-ifinfod_snmp.c      jnx-ifinfod_util.h
    jnx-ifinfod_config.h    jnx-ifinfod_kcom.h      jnx-ifinfod_snmp.h
    jnx-ifinfod_conn.c      jnx-ifinfod_main.c      jnx-ifinfod_ui.c
    Makefile                jnx-ifinfod-ctrl_main.c

  7. In sandbox/src/sbin/your-application-directory, update the makefile to include your source code files. For example, this makefile code specifies building the source files in the ifinfod sample application:

    SRCS= \
          ifinfod_config.c \
          ifinfod_main.c \
          ifinfod_kcom.c \
          ifinfod_util.c \

    For information on updating the makefile to include C++ source files, see Updating the Makefile to Handle C++ Source Code.

  8. In sandbox/src/sbin, update the makefile to include your source code directories. For example, this simple makefile specifies building two applications named jnx-exampled and jnx-ifinfod:

    SUBDIR = \
    	jnx-exampled \
    .include <>

  9. Optionally, write a policy for your package that specifies additional constraints on shared system resources. For more information, see Specifying Application Constraints.

  10. Use the mk command to build the binaries and create the package. For details, see Makefile Syntax for Building Applications.

  11. Change to directory sandbox/src/release and create a manifest for your source files. In the manifest, specify roles, program and package IDs, and any indirect execution. For details, see Writing the Manifest.

  12. In the sandbox/src/release directory, issue a mk command for the package. This generates a signed package named according to the manifest filename, in the sandbox/src/ship directory:

  13. In the sandbox/src/package-scripts/package-name directory, create a package configuration file named junos-package.xml. For details, see Creating the Package Configuration File.

  14. Deploy the application on the router. For details, see Deploying the Application on the Router.

Makefile Syntax for Building Applications

In general, the mk command with no targets builds binaries only; the mk release command builds both binaries and packages.

The following examples show how to build binaries and packages for i386-based Routing Engines, for octeon-based (SRX) Routing Engines, and for the Multiservices PIC (XLR). In these examples, $SB refers to the development sandbox.

$SB/src/etc/mk             Builds the certificate chain file in the etc directory for i386-based Routing Engines
$SB/src/etc/mk-xlr         Builds the certificate chain file in the etc directory for the Multiservices PIC (XLR)
$SB/src/etc/mk-octeon      Builds the certificate chain file in the etc directory for octeon-based (SRX) Routing Engines

$SB/src/lib/mk             Builds the library binaries (for example, DDL and ODL) for i386-based Routing Engines
$SB/src/lib/mk-xlr         Builds the library binaries for the Multiservices PIC (XLR)
$SB/src/lib/mk-octeon      Builds the library binaries for octeon-based (SRX) Routing Engines

$SB/src/sbin/mk            Builds all process binaries for i386-based Routing Engines
$SB/src/sbin/mk-xlr        Builds all process binaries for the Multiservices PIC (XLR)
$SB/src/sbin/mk-octeon     Builds all process binaries for octeon-based (SRX) Routing Engines

$SB/src/mk includes:

$SB/src/mk-xlr includes:

$SB/src/mk-octeon includes:

$SB/src/mk release includes:

$SB/src/mk-octeon release includes:

Additional Notes About Building Applications

Writing the Manifest

The manifest file, which you include in the sandbox/src/release directory, specifies the contents of your application package; that is, it tells the system how to extract files needed from the application sandbox as needed to create the package.

Typical contents for an RE SDK application include the following:

%TOPDIR% resolves to obj-i386, obj-octeon, or obj-xlr, depending on which version of mk you run.

The manifest also specifies privilege levels called roles, and the program and package IDs (these are explained later in this topic). Binaries can have different roles.

You should set the permissions on the files listed in the manifest to 555 for executables and 444 for all other file types.

A sample manifest for the jnx-ifinfo sample application follows:

/set package_id=30 role=Provider_Daemon

%TOPDIR%/lib/odl/xmltags/ store=opt/lib/render/ mode=444
%TOPDIR%/lib/ddl/feature/ store=opt/lib/dd/ mode=444
%TOPDIR%/sbin/jnx-ifinfod/jnx-ifinfod store=%INSTALLDIR%/sbin/jnx-ifinfod mode=555 program_id=1
%TOPDIR%/lib/ddl/feature/jnx-ifinfo.dml store=opt/lib/dd/%PROVIDER_PREFIX%-ifinfo.dml mode=444 no_copy

%INSTALLDIR% expands to /opt/sdk/provider-name and is the mandatory location for any processes. Any subdirectories of /opt/sdk/provider-name (for example, sbin) are acceptable.

A Services SDK application's manifest typically includes only the paths to the executable and the configuration file (see Initialization Configuration File). An example follows:

%TOPDIR%/../obj-xlr/sbin/dpm-ctrl/dpm-ctrl store=opt/sdk/sbin/dpm-ctrl mode=555
%TOPDIR%/etc/dpm.conf store=/var/etc/init.dir/dpm.conf mode=444

Once you install the sample applications, you can find manifests for each one in the sandbox/src/release directory in your development sandbox.

Setting Manifest Keywords

You set various keywords that are required for verification on the Routing Engine (on the Multiservices PIC, the system performs only basic package authentication).

indirect can also be used as an optimization to avoid using memory in the kernel. SDK applications use indirect in this way for .crrdl files. For example, a custom policy could be specified as follows:

%TOPDIR%/lib/rrdl/input/policy/policy-sync-0/policy-sync-0.crrdl store=pkg/policy-sync-0.crrdl mode=444 indirect no_symlink

%TOPDIR%/lib/ddl/feature/jnx-ifinfo.dml store=opt/lib/dd/%PROVIDER_PREFIX%-ifinfo.dml mode=444 no_copy

Using set and unset

You can use the /set command to set the package_id and role keywords for all manifest entries that follow the /set line. For example, the following line sets the package ID and the role:

/set package_id=25 role=Provider_Daemon

The keyword/value pairs consist of a keyword, followed by an equals sign, followed by a value, without whitespace characters.

To erase all global settings for a keyword, use the /unset command. For example:

/unset role

Only the role can be unset and reset. Once a role keyword has been set, its value remains unchanged until either unset or reset.

For an example of setting keywords, see Manifest Example.

Specifying Roles

You must specify a role name for each process in the package manifest (see the sample manifest shown earlier). You will normally use the Daemon roles: the Application roles are meant for command-line applications that are executed as needed, whereas the Daemon roles are meant for processes that run continuously from startup until shutdown of the router. However, it is also possible to use the Application roles for programs that are daemons and the Daemon roles for ephemeral processes that are launched from a CLI command (such as ping).

The roles and their permissions are shown in the following table. In this table:


Provider_Application Nice level 10
Max 256 open files
Max 16 MB data segment size
Max 8 MB stack size
Max 8 MB locked-in (mlock) memory
Max 24 MB resident in RAM

Provider_RTSOCK_Application All capabilities in Provider_Application

Read-only access to RTSOCK
Write access to GENCFG


All capabilities in Provider_Application

Raw IPv4 sockets permitted


All capabilities in Provider_Application



All capabilities in Provider_Raw_Traffic_Application

All capabilities in Provider_RTSOCK_Application
All capabilities in Binding to low ports permitted
All capabilities in Provider_BPF_Capture_Application


Read-only access to RTSOCK
Write access to GENCFG
Binding to low ports permitted
Nice level 10
Max 512 open files
Max 64 MB data segment size
Max 8 MB stack size
Max 16 MB locked-in (mlock) memory
Max 24 MB resident in RAM


All capabilities in Provider_Daemon

Raw IPv4 sockets permitted


All capabilities in Provider_Daemon



All capabilities in Provider_Daemon


Raw IPv4 sockets permitted
Binding to low ports permitted

Manifest Example

The following example shows the settings for the most basic application (Hello World) that does not require many privileges, and for a more complex application (Counter) that requires KCOM and GENCFG:

/set package_id=25 role=Provider_Application
# Application: helloworld
%TOPDIR%/lib/odl/xmltags/ store=opt/lib/render/ mode=444
%TOPDIR%/lib/ddl/feature/ store=opt/lib/dd/ mode=444
%TOPDIR%/sbin/helloworldd/helloworldd store=%INSTALLDIR%/sbin/helloworldd mode=555 program_id=1

/unset role
/set role=Provider_RTSOCK_Application
# Application: counter
%TOPDIR%/lib/odl/xmltags/ store=opt/lib/render/ mode=444
%TOPDIR%/lib/ddl/feature/ store=opt/lib/dd/ mode=444
%TOPDIR%/sbin/counterd/counterd store=%INSTALLDIR%/sbin/counterd mode=555 program_id=2
# This one is everything in the package for mgd:
%TOPDIR%/lib/ddl/feature/daemon_desc.dml store=opt/lib/dd/%PROVIDER_PREFIX%-daemon_desc.dml mode=444

Specifying Application Constraints

Before packaging your application, you have the option to create an XML policy file that defines new roles based on the roles defined in Specifying Roles. The new roles can include any of the predefined roles and redefine resource limits as long as the new limit is less than or equal to the predefined limit. When your software testing is complete, it is recommended that you restrict your application to what you expect it to need in order to protect system resources and, thus, the other software running on the system.

You can have one policy file for each SDK package you generate. The compiled policy file that the system builds from your policy file is signed by the certificate provided to the SDK partner.

Create this file in the directory sandbox/src/lib/rrdl/input/. A sample file follows:

    <namespace name="jnx-example"> <!-- The name should match the package 
	                                       name -->
	<using>provider</using>          <!-- This is mandatory -->
	<generation>1</generation>       <!-- This is mandatory -->

	<role name="Provider_Jnx_Daemon">


	</role> <!-- End of Role -->


The resource limits you can specify are as follows:

             priority           Highest piority (nice level) at which the process
                                can run 
             time               Maximum amount of CPU time that can be

             data-size          Maximum size of the data segment
             locked-in          Maximum bytes that can be locked into
             resident-set-size  Maximum amount of physical memory at 
                                any given moment
             socket-buffers     Maximum amount of physical memory that
                                may be dedicated to socket buffers
             stack-size         Maximum size of the stack segment
             size               Maximum size of a file that can be
             open               Maximum number of simultaneous open files
             core-size          Maximum size of a core file that can be

When you have added the file, write a Makefile in the same directory that includes the following code (replace jnx-example with the package name) to ensure that the system reads the file:

POLICIES = jnx-example

.include <>

Finally, add the following entry as the first entry in the manifest (replace jnx-example with the name of your package and Provider_Jnx_Daemon with the role you are defining):

/set package_id=29 role=Provider_Jnx_Daemon policy=jnx-example.crrdl

%TOPDIR%/lib/rrdl/input/jnx-example.crrdl store=pkg/jnx-example.crrdl mode=444 indirect no_symlink

Notes on Application Constraints

To change the policy file for an SDK package, you must rebuild the SDK package with new policies. All packages are signed, so rebuilding a package is required to get a new one with the changed policies.

To ship packages with different policies for different customers, you need to create an SDK package for each customer.

Updating the Makefile to Handle C++ Source Code

By default, the SDK makefile includes rules only for building .cc files. To build .cpp and .cxx files, you must add rules to the Makefile at sandbox/src/sbin/your-application-directory to remove warning options that are not supported by g++.

Add the following code to support .cpp and .cxx files is as follows:

 missing-declarations \ 
 missing-prototypes \ 
 nested-externs \ 
 shadow \ 
.for s in ${SRCS:M*.cpp} ${SRCS:M*.cxx} 
.for w in ${NO_CXX_WARNINGS} 

Creating the Package Configuration File

junos-package.xml is an XML package configuration file that you include in your application package in the package-scripts directory. You can see an example of this file in each of the sample applications at sandbox/src/sbin/example-name/src/package-scripts/junos-package.xml. The pkg_add script you run as part of your SDK installation procedure generates +INSTALL, +DEINSTALL, +REQUIRE, +DESC and +COMMENT settings from the XML.

An example that includes settings for all the tags is as follows:

    <title>My Daemon</title>
        <holder>My Company</holder>
    <description>This package contains my daemon.</description>

You supply values for some of the tags. The system generates values for others at compile time.

Values You Provide

The values you provide must correspond to the dependency names used in the release makefile to identify how a package should be generated. You can provide values for the following tags.

   Tag                  Meaning                                           Possible Values
   ___                  _______                                           _______________
<junos-package>     The container tag.

<type>             Indicates one of the package types               SDK_PKG_RE : RE-SDK package (runs on the Routing Engine).
                   listed in the next column.                       SDK_PKG_PIC : Services SDK package (runs on the Multiservices PIC).
                   The <type> tag must precede all other tags       SDK_PKG_CNTR : Container package that contains PIC packages. 
                   except <junos-package>.                          SDK_PKG_BUNDLE :  Bundle package that contains Routing Engine
                                                                          and/or container packages.

<copyright>       (Optional)A container tag that is used to         <year> : (Optional) If not present, the current year is used.     
                  build the copyright string in the package         <holder> : The name of the copyright holder.
                  description file.                                 <rights-reserved> : (Optional) If present, the string "All rights reserved"
                                                                        appears on the copyright line.

<release>         (Optional) The release version of the package.  
                  If not present, the Junos Software release 
                  version of the backing sandbox is used.

<description>     (Optional) A description of the package contents.

<has-ddl>         (Optional) Indicates that the package contains 
                  at least one DDL schema library and needs mgd
                  to restart after package installation and
<has-daemon>      (Optional) Indicates that the package has a 
                   daemon that might need to be started on 
                   package installation. 
                   If the package contains more than one daemon,
                   this tag should be repeated for each daemon.
<kill-daemon>      (Optional) Indicates that the package has a 
                    daemon that might need to be killed on package
                    If the package contains more than one daemon, 
                    this tag should be repeated for each daemon.
<kill-all-daemons>  (Optional) Indicates all daemons listed with 
                    <has-daemon> tags will be killed when the 
                    package is uninstalled.
                    <kill-daemon> and <kill-all-daemons> are 
                    mutually exclusive.
<cpu-cores>         (Optional) For Services SDK applications,    <access-mask> specifies access to cores;
                     indicates which processing cores on the     <sharing-mask> specifies sharing cores with
                     Multiservices PIC the application              other applications.  
                     will use and/or share.  Each PIC contains   The system constructs a mask from values it assigns
                     8 processing cores and each core has 4      to the following tags which you include under
                     hardware threads (virtual CPUs).             <access-mask> or <sharing-mask>:   
                                                                      <control>: control core
                                                                      <data>: data core
                                                                      <user>: user core   

Settings the System Generates

Settings automatically added to the XML package configuration file during compilation are as follows. These generated tags are added before the <type> tag in the generated XML file that is put into the package. The XML schema for the package configuration file enforces the presence and order of the tags.

Tag Meaning

<name> Matches the name of the package file and is validated by the installation procedure as a sanity check.

<junos-release> The release version of the Junos Software build that the sandbox came from. This is used by the installation procedure for compatibility checks.

<junos-sdk-version> The version of the Junos SDK libraries that the sandbox came from. This is used by the installation procedure for compatibility checks.

<machine> The type of chip for which the package is being built, either i386 or octeon. This is used by the installation procedure to ensure that i386-based Routing Engine packages are not allowed to install on octeon-based Routing Engine packages, and vice versa.

Using a Signing Server

Your administrator can use a signing server to isolate the partner key, requiring applications to request the signature from a separate, protected server. If your administrator has set up a signing server, you need to set the SIGSERVER and SIGPORT environment variables to the IP address and port of the server before building your application. When you do this, the build automatically runs scripts to connect to the server, send certificate and hash information to the server, and read the signature output after the server has executed back-end processing and produced the signature.

The server side setup for the signing server is documented in the Installation Guide.

Special Considerations for Building Services SDK Applications

This section includes some additional points you need to know about if you are building an application to run on the Multiservices PIC.

System Configuration Flags Set During the Build Process

All makefiles for Junos SDK libraries define the flag __JUNOS_SDK__ . During mk or mk-octeon, the system also sets __JUNOS_RE_SDK__.

During mk-xlr, the system sets __JUNOS_MP_SDK__. However, your application's build Makefile must specify NEED_JUNOS_MP_SDK=yes to enable this setting.

Initialization Configuration File

You must include a daemon-name.conf file for every Services SDK daemon and place it in the etc directory in your development sandbox. This file tells the system what to do when a daemon abnormally terminates.

Control-style daemons can be respawned (using action respawn) up to three times within 60 seconds. For daemons that attach to the data cores for inline packet processing or other critical daemons, you might prefer to have the daemon start just once and, upon abnornal termination, cause a reboot of the Multiservices PIC. You can use action once to do this. These kinds of daemons can optionally restart, but with caveats (see Application Restart for more information).

If a daemon has abnormally terminated more than 3 consecutive times in 60 seconds or has terminated but has the action once directive, the failure command (typically set to the reboot script) will be executed. Setting the debugger-on-panic option can also prevent this reboot. To set that option, use the following configuration:

interfaces {
    pc-x/y/0 {
        multiservice-options {

This configuration file is only for standalone processes. Services SDK plugins are not processes, and so are not launched directly and require no configuration file. Instead, plugins have an XML file to specify their startup properties. (For details, see Writing a Plugin).

Following are the settings for the sample control daemon jnx-gateway-ctrl:

process "jnx-gateway-ctrl" {
    action respawn;
    command "/opt/sdk/sbin/jnx-gateway-ctrl -N";
    failure-command "/etc/";

Following are the settings for the sample data daemon jnx-gateway-data (note thet the action respawn command, which restarts the daemon, is replaced by action once):

process "jnx-gateway-data" {
    action once;
    command "/opt/sdk/sbin/jnx-gateway-data -N";
    failure-command "/etc/";

Shared Libraries

In order to be successfully linked on the Multiservices PIC, your application's shared libraries should be installed on the PIC in /opt/lib.

Daemons and Data Traffic

Only one daemon can process service (data traffic) packets on real-time threads bound to the virtual CPUs of the Multiservices PIC’s data cores.

Deploying the Application on the Router

To deploy your application on the router, you must first follow the instructions under “Installing the Package Certificate and Key” in the Installation Guide, to select a provider ID and generate a package using the keys and certificates. With this done and your package compiled, you will be able transfer your signed package to the router where it is to be installed.

The provider ID always corresponds to the substring before the first hyphen (-) in the filename_key.pem and filename_req.pem files generated from the sdk-certificate-request script.

Follow the steps shown in the following example to enable the provider ID and allow installation of your package:

router> edit
Entering configuration mode
router# set system extensions providers abc
router# commit
commit complete
router# exit
Exiting configuration mode
router> request system software add abcapps-10.1I20070214_2011_user-signed.tgz
Installing package '/var/home/user/abcapps-10.1I20070214_2011_user-signed.tgz'
Verified abcapps-10.1I20070214_2011_user.tgz signed by abc-enggroup
Adding abcapps...
Available space: 150060 require: 2598
Saving package file in /var/sw/pkg/abcapps-10.1B3.X_user-signed.tgz Saving state
for rollback ...

Your package is now installed and started, or ready to start when you configure it.

Related Topics

Adding an Outside Library to Your Application

Updating System Tables to Describe Your Application

Porting an SDK Build Environment from a Release Prior to 9.6

© 2007-2009 Juniper Networks, Inc. All rights reserved. The information contained herein is confidential information of Juniper Networks, Inc., and may not be used, disclosed, distributed, modified, or copied without the prior written consent of Juniper Networks, Inc. in an express license. This information is subject to change by Juniper Networks, Inc. Juniper Networks, the Juniper Networks logo, and JUNOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners.
Generated on Sun May 30 20:26:47 2010 for Juniper Networks Partner Solution Development Platform JUNOS SDK 10.2R1 by Doxygen 1.4.5