Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Managing Third-Party Applications

Using Intercept Libraries

Junos OS Evolved can run third-party applications because it runs on native Linux. There are some differences between the way Linux displays requested network topology information such as interface and route data and the way Junos OS displays this information. The CLI is designed to overcome these differences. But typically, third-party applications running on native Linux obtain this information directly from the native Linux sources using shell commands.

Junos OS Evolved uses an intercept mechanism that redirects shell requests for network topology information to a space where the information can be obtained from Junos OS. This intercept mechanism is accomplished through intercept libraries, libsi.so and libnli.so, that you preload. After you preload the intercept library, certain types of requests are intercepted and show Junos OS information.

The intercept libraries are optional; they are needed only if the application requires the APIs mentioned in Table 1:

Table 1: APIs That Require Intercept Libraries

API

Description

Packet IO and Linux socket APIs

Ability to send and receive packets over management and/or data interfaces. Standard libc, such as send, receive, listen.

rtnetlink

Ability to use rtnetlink to query networking state like interfaces, routes.

netdevice

Ability to configure network devices.

proc

Ability to query kernel data structures using standard interfaces provided by Linux kernel.

Junos APIs

Ability to access Juniper North Bound APIs - NetConf/JET/Telemetry.
Note:

For more information on Juniper Northbound APIs, see the following:

Note:

Junos OS Evolved Release 20.1R1 supports the following features:

  • Use the set system netlink-async-mode configuration to enable NETLINK_ROUTE asynchronous notifications. This feature is disabled by default. Use show nsld mode to show the current netlink asynchronous mode.

  • SIOCETHTOOL ioctl, which can be used by other applications.

  • Multipath next-hop route information through netlink route attributes.

Example of a Preloaded Linux Command

An example how the preload directive works follows using the command ifconfig, which displays interfaces.

If you preload the ifconfig command with the intercept library, Junos OS interface information is returned. Notice that the intercept library only translates logical interfaces. In this example, because there are logical interfaces only on lo0 and re0:mgmt-0.0, the output displays only these two interfaces for the preloaded ifconfig command.

You can get the same results by running jbash, which is a shell provided with Junos OS Evolved that preloads libnli.so and libsi.so by default.

CAUTION:

Only use jbash to get the network state information. Don’t use jbash as your default shell.

If you issue the command without preloading it with the intercept library, the output shown is from Linux. Notice that the following output is longer than that from Junos OS. Linux does not make the distinction between physical interfaces and logical interfaces that the Junos CLI does.

Interface Name Translation

One limiting factor to using this intercept mechanism is that Linux interface naming is incompatible with the Junos OS interface naming. Linux supports 15-byte interface names (15 + null-character); network interface names that exceed this limit are truncated in outputs. Junos OS logical interface names could be longer than 15 bytes, for example, et-0/0/10:2.32767.

To work around this difference, Junos OS Evolved uses a translation rule (see Table 2) to render logical interface names in a Linux-compliant format. The translation renders a format such as name-fpcSlot/picSlot/port:channelId.subUnit to nn-ffpttccssss. Using interface names translated according to this rule, third-party applications can effectively fetch the topology information from Junos OS.

Only translation of logical interface names is supported, and translation of both channelized and nonchannelized logical interface names is supported.

Table 2: Translation Rule for Interface Names

Value

Description

Allotted Space (in bytes)

Range

nn

mapped name bytes

2

ff

fpc in hex

2

0-255

p

pic in hex

1

0-15

tt

port number in hex

2

0-255

cc

channel in hex; use “xx” if not present

2

0-255

ssss

subunit in hex

4

0-65535

Except for management interfaces, if the logical interface name does not have a hyphen (-) in it, the dot (.) in the name is changed to an underscore (_), for example: ifdname.subunit gets translated to ifdname_subunit.

For management interfaces, reX:mgmt-Y.Z translates to mgmt-x-yy-zzzz, where x, yy, zzzz are in hex-padded with 0 for a fixed length. And the reverse translation happens on the same lines.

See Table 3 for examples of Junos logical interface names and their Linux-compliant forms.

Table 3: Examples of Translated Logical Interface Names

Junos Logical Interface Name

Translated Linux-Compliant Interface Name

et-1/2/3.4

et-01203xx0004

ge-1/2/3.32

ge-01203xx0020

et-1/15/3.4

et-01f03xx0004

et-1/2/255:6.7

et-012ff060007

et-1/2/4:5.32767

et-01204057fff

re0:mgmt-1.2

mgmt-0-01-0002

ae0.1

ae0_1

irb0.11

irb0_11

When accessing Junos OS states by preloading libnli.so, the interface name in the output is shown as a translated Linux-compliant interface name. You must also use the translated Linux-compliant interface name when using it as an argument in a command. The translated et-01000000000 interface name is used as an argument in the following example:

Caveats for the Intercept Feature

This intercept feature supports read-only requests. Any write request returns an error.

Representation of certain Junos network state may not be mappable to Linux equivalents. In these cases, the data is either be omitted or re-mapped to a comparable Linux model. For example, Junos OS Evolved supports a rich suite of nexthop types such as composite or unilist that do not have comparable implementations in native Linux.

Third-party applications that are linked statically cannot be intercepted and, therefore, are not supported by this feature.

Removing Third-Party Applications

There are several methods for removing third-party applications. The method you should use is based on how you installed the application.

  • If a third-party application was installed with the request system software add command, then you can remove the same application by using the request system software delete command.

  • The first step in removing these applications is to unlink the key with the request security system-keystore unlink key command.

    Next, remove any binaries that you installed for the application with the rm -f /path/to/binary1 /path/to/binary2 shell command.

  • If a third-party application was installed through a Docker container, then use the following Docker command to remove the container: