The Command Line Reference guide is better understood if you know the basics of operating the programmable command line interface (PCLI). Commands and actions such as clear, edit, delete, restore, and show, for example, are described here. If you have not used the PCLI before, please refer to About the PCLI for an explanation of how it works.
adopt
Assign the current router to a Mist organization.
Usage
adopt [{org-id <org-id> | registration-code <registration-code>}] [force] [router-name <router-name>]
Keyword Arguments
name | description |
---|
force | Skip confirmation prompt. |
org-id | The ID of the Mist organization where the router is assigned. |
registration-code | The registration code used to assign this router to an organization. |
router-name | Assign a name to the router. |
See Also
command | description |
---|
show mist | Display information about the link between the SSR and the Mist Cloud |
Description
If you know the ID of the organization in Mist, or the registration code for the router, you can use the optional org-id
or registration-code
arguments. Otherwise, use the interactive dialog to walk through entering Mist credentials and assigning the router to an organization.
Release | Modification |
---|
6.0.0 | This feature was introduced |
clear app-id cache
Clear app-id entries from cache
Usage
clear app-id cache [force] [stale-entries] [node <node>] {router <router> | resource-group <resource-group>} [<cache>]
Keyword Arguments
name | description |
---|
force | Skip confirmation prompt |
node | The node on which to clear app-id cache entries |
resource-group | The name of the resource group |
router | The router on which to clear app-idcache entries |
stale-entries | Only clear the stale (expired) entries |
Positional Arguments
name | description |
---|
cache | Clear app-id entries from address cache, domain cache, url cache, or all (default: all) |
See Also
clear app-id cache-entry address
Clear specific app-id entry from cache by address key
Usage
clear app-id cache-entry address [force] [node <node>] {router <router> | resource-group <resource-group>} <ip> <port> <protocol>
Keyword Arguments
name | description |
---|
force | Skip confirmation prompt |
node | The node on which to clear app-id cache entry |
resource-group | The name of the resource group |
router | The router on which to clear app-id cache entry |
Positional Arguments
name | description |
---|
ip | IP address of the address key [type: IP address] |
port | Port of the address key [type: port] |
protocol | Protocol of the address key [type: string or uint8] |
See Also
clear app-id cache-entry domain
Clear specific app-id entry from cache by domain name key
Usage
clear app-id cache-entry domain [force] [node <node>] {router <router> | resource-group <resource-group>} <domain>
Keyword Arguments
name | description |
---|
force | Skip confirmation prompt |
node | The node on which to clear app-id cache entry |
resource-group | The name of the resource group |
router | The router on which to clear app-id cache entry |
Positional Arguments
name | description |
---|
domain | Domain name |
See Also
clear app-id cache-entry url
Clear specific app-id entry from cache by url key
Usage
clear app-id cache-entry url [force] [node <node>] {router <router> | resource-group <resource-group>} <url>
Keyword Arguments
name | description |
---|
force | Skip confirmation prompt |
node | The node on which to clear app-id cache entry |
resource-group | The name of the resource group |
router | The router on which to clear app-id cache entry |
Positional Arguments
See Also
clear app-id stats
Clear inactive app-id stats
Usage
clear app-id stats [force] [node <node>] {router <router> | resource-group <resource-group>}
Keyword Arguments
name | description |
---|
force | Skip confirmation prompt |
node | The node on which to clear inactive app-id stats |
resource-group | The name of the resource group |
router | The router on which to clear inactive app-id stats |
See Also
clear arp
Refresh the entire ARP cache or a subset if arguments are provided.
Usage
clear arp [{vlan <vlan> | ip <ip>}] [device-interface <device-interface>] [force] [node <node>] {router <router> | resource-group <resource-group>}
Keyword Arguments
name | description |
---|
device-interface | The device interface on which to refresh the ARP cache (default: all). |
force | Skip confirmation prompt. Only required when targeting all routers. |
ip | The IP address for which to clear an ARP entry (must be specified after 'device-interface'). [type: IP address] |
node | The name of the node. |
resource-group | The name of the resource group. |
router | The name of the router. |
vlan | The VLAN on which to clear the ARP cache (must be specified after 'device-interface'). [type: int] |
See Also
command | description |
---|
show arp | Shows the contents of the ARP table on the specified node. |
Description
The clear arp
command is typically used during troubleshooting to force a refresh of ARP (Address Resolution Protocol) entries from an SSR or node's ARP cache. The command has multiple filters, allowing administrators to specify which entry to refresh. The PCLI auto-completes typed entries for improved accuracy.
ARP entries are not removed or deleted; instead the command forces a refresh of the cache outside of the scheduled ARP timeout.
Version History
Release | Modification |
---|
3.2.0 | This feature was introduced |
clear bgp
Clear routes associated with one or all BGP neighbors.
Usage
clear bgp [{in | out | soft}] [vrf <vrf>] [force] {router <router> | resource-group <resource-group>} <neighbor>
Keyword Arguments
name | description |
---|
force | Skip confirmation prompt. Only required when targeting all routers |
in | Soft reset received BGP updates |
out | Soft reset transmitted BGP updates |
resource-group | The name of the resource group |
router | The name of the router for which to clear BGP neighbors |
soft | Soft reset received and transmitted BGP updates |
vrf | VRF name |
Positional Arguments
name | description |
---|
neighbor | neighbor ip-address [type: IP address or 'all'] |
See Also
command | description |
---|
show bgp | Displays information about the state of the BGP process on the SSR. |
clear history
Clear the PCLI's command history for this user.
Usage
See Also
command | description |
---|
show history | Show PCLI command history for the current user. |
clear pim mroute
Clears all multicast routes.
Usage
clear pim mroute [vrf <vrf>] [force] {router <router> | resource-group <resource-group>}
Keyword Arguments
name | description |
---|
force | Skip confirmation prompt. Only required when targeting all routers |
resource-group | The name of the resource group |
router | The name of the router for which to clear multicast routes |
vrf | VRF name |
clone
Clone the configuration of one router to create a new router with a new name and identical contents.
Usage
router [force] <name> <new-name>
Keyword Arguments
name | description |
---|
force | Skip confirmation prompt |
Positional Arguments
name | description |
---|
name | An identifier for the router |
new-name | The new value for the router name |
Example
admin@conductor-east-1.RTR_EAST_CONDUCTOR# configure authority clone router Boston NewYork
Description
The clone command duplicates the configuration data from the existing Boston
router into a new router with the name NewYork
, and stages it to the candidate configuration.
Version History
Release | Modification |
---|
5.0.0 | This feature was introduced |
commit
Commit the candidate config as the new running config.
Usage
commit [force] [validate-router-all]
Keyword Arguments
name | description |
---|
force | Skip confirmation prompt |
validate-router-all | Distribute config to each managed router for validation and wait for results before committing |
Description
The commit
command causes the SSR to validate the candidate configuration, and then replace the running configuration with the candidate configuration (assuming it passes the validation step). It is used once a series of configuration changes have been made, and an administrator wishes to "activate" those configuration changes.
When run from an SSR conductor, the conductor only validates the configuration itself locally before committing the configuration and then distributing it to all managed routers. If the user wishes, the conductor has the ability to distribute the configuration to all managed routers for each of them to validate it and report the results of their validation before the commit takes place (assuming a successful validation). This operation is much slower than local validation because the conductor must wait for all routers to report their results and some may be unreachable or timeout. The user may request a distributed validation by using the validate-router-all
keyword.
The commit
command will prompt a user for confirmation, as this is a (potentially) service affecting command. By supplying the optional force
keyword, the confirmation step is skipped:
*admin@labsystem1.fiedler# commit
Are you sure you want to commit the candidate config? [y/N]: y
Configuration committed
*admin@labsystem1.fiedler# commit force
Configuration committed
admin@labsystem1.fiedler#
If the validation step fails, the administrator will be notified, the commit step is not executed, and the existing running configuration will remain in place. The validator will get a list of all errors that must be addressed before the commit can be completed. There may also be warnings displayed in the event that the candidate configuration contains elements that are deprecated.
Example
*admin@burl-corp-primary.burl-corp# commit
✖ Validating, then committing...
% Error: Failed to commit:
1. Service name "bar" does not exist
config
authority
router burl-corp
service-route foo
service-name
2. A service route must have at least one next-hop, peer,
nat-target, use-learned-routes, routing-stack or host configured. It cannot have both
the peer and nat-target configured.
config
authority
router burl-corp
service-route foo
3. Service-route foo for service '' is not allowed on router burl-corp. Please check the applies-to config
on the service.
config
authority
router burl-corp
service-route foo
Version History
Release | Modification |
---|
1.0.0 | This feature was introduced |
3.0.0 | force feature was added |
compare config
Display the differences between two configurations.
Usage
compare config [<old>] [<new>]
Positional Arguments
name | description |
---|
old | The original configuration against which differences should be computed (default: running). Can be candidate, running, factory-defaults, or the name of a previously exported configuration. |
new | The updated configuration for which differences should be computed. Can be candidate, running, factory-defaults, or the name of a previously exported configuration. |
Description
The compare config
command presents a list of differences between the two configurations specified as arguments on the command line. The one listed first influences the output in a very important way: the SSR will return a list of configuration commands that will cause the configuration to be listed first to be brought to parity with the one listed second. (Note: since the only editable configuration is the "candidate" configuration, the changes outlined by the compare config command cannot be directly applied to the "running" configuration.)
The ability to specify a previously exported configuration file to compare against the running or candidate config allows you to compare configurations without having to import the exported config into the candidate config for comparison.
In the example below, the candidate and running configurations are identical save for a single service-route that has been added to the candidate configuration.
*admin@labsystem1.fiedler# compare config running candidate
config
authority
router Fabric128
name Fabric128
service-route myRoute
name myRoute
service-name myService
destination 10.10.10.10
exit
exit
exit
exit
This shows that the running configuration is missing the candidate's service-route. By reversing the order of the arguments, the output changes:
*admin@labsystem1.fiedler# compare config candidate running
config
authority
router Fabric128
name Fabric128
delete service-route force myRoute
exit
exit
exit
Note here that the output shows that the running configuration has deleted the candidate configuration's service-route via the delete service-route force myRoute
statement. Cutting and pasting this configuration into the PCLI will affect the candidate configuration – and make it match the running configuration.
When two configurations are identical, comparing them will return that there are no changes to display:
admin@labsystem1.fiedler# compare config candidate running
# No differences
admin@labsystem1.fiedler#
See Also
Version History
Release | Modification |
---|
2.0.0 | This feature was introduced |
5.1.0 | Added the ability to compare between the running or candidate config and an exported config, or between two exported configurations. |
Usage
configure [authority [ ... ] ]
Description
The configure
command places administrators into the configuration tree (hierarchy), where they will be making changes to the candidate configuration. When entered as a standalone command (i.e., configure
by itself), the administrator is placed at the top of the configuration tree.
admin@labsystem1.fiedler# configure
admin@labsystem.beacon (config)#
Alternatively, administrators may execute the configure
command with optional arguments to enter into configuration mode "deeper" in the configuration tree. For example:
admin@labsystem1.fiedler# configure authority router Fabric128
admin@labsystem1.fiedler (router[name=Fabric128])#
By supplying optional arguments to the configure command as in the above example, the administrator has entered into the configuration tree at the "router" tier, within the router element named "Fabric128". Not only can administrators enter into the configuration tree at any point through this technique, but new configuration can also applied directly in this same way.
admin@labsystem1.fiedler# configure auth router Fabric128 description "sample description"
admin@labsystem1.fiedler# show config candidate
config
authority
name Authority128
router Fabric128
name Fabric128
location usa
description "sample description"
...
Required Fields
Some arguments and subcommands contain required fields for configuration. The configure
help text now identifies required fields. For example:
...
usage: inter-node-security [<security-ref>]
The name of the security policy used for inter node communication between router interfaces
positional arguments:
security-ref The value to set for this field
security-ref (leafref) (required): This type is used by other entities that need to reference configured security policies.
Options: internal, aes1, or test
Version History
Release | Modification |
---|
1.0.0 | This feature was introduced |
2.0.0 | Command was renamed to configure from config |
connect
Connect to a Managed Router. For more information, read Connecting to SSRs from Conductor.
Usage
connect [username <username>] router <router> node <node>
Keyword Arguments
name | description |
---|
node | The node to connect to |
router | The router to connect to |
username | Username to use for login to the Managed Router (default: <current user>) |
create capture-filter
Creates a capture-filter using BPF syntax (as used in wireshark) on the target interface.
Usage
create capture-filter device-interface <device-interface> router <router> node <node> <capture-filter>
Keyword Arguments
name | description |
---|
device-interface | The device interface on which to create the capture filter |
node | The node on which to create the capture filter |
router | The router on which to create the capture filter |
Positional Arguments
name | description |
---|
capture-filter | The capture-filter to create (Uses BPF syntax) |
See Also
Example
admin@tp-colo-primary.tp-colo# create capture-filter device-interface blended-5 "host 172.18.5.4"
Successfully created capture-filter
Version History
Release | Modification |
---|
4.4.0 | This feature was introduced |
create certificate request webserver
Create a certificate signing request.
Usage
create certificate request webserver
See Also
Description
The create certificate request webserver
generates a certificate-request, which is then sent to a Certificate Authority. The SSR will, through a series of interactive prompts, request information from the administrator to generate either the request or certificate, as appropriate.
The certificate created by the create certificate
command stores its output file at /etc/128technology/pki/
.
create certificate self-signed webserver
Create a self-signed certificate.
Usage
create certificate self-signed webserver
See Also
Description
The create certificate self-signed webserver
generates a self-signed certificate which is used for the local webserver. The SSR will, through a series of interactive prompts, request information from the administrator to generate either the request or certificate, as appropriate.
Example
admin@labsystem1.fiedler# create certificate self-signed webserver
Certificate common name: test.128technology.com
Country name (2 char): US
State name: MA
Organization name: 128Technology
RSA key size (2048/4096) [4096]: 4096
Certificate validity in days (1 - 7300) [365]: 365
Self-signed certificate successfully
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 31228 (0x79fc)
...
create config autogenerated
Run configuration generation.
Usage
create config autogenerated
Description
Forces re-generation of all automatically generated configuration items, and stages the configuration changes into the current candidate configuration. Configuration generation is done automatically as part of a commit
. This command serves only to aid in debugging, and allows you to validate, inspect, and make edits, without committing the changes.
See Also
Version History
Release | Modification |
---|
5.1.0 | This feature was introduced |
create session-capture
Creates a session capture at the specified node and service.
Usage
create session-capture [source-ip <source-ip>] [source-port <source-port>] [destination-ip <destination-ip>] [destination-port <destination-port>] [protocol <protocol>] [session-count <session-count>] [packet-count <packet-count>] [local-only] [tag <tag>] service <service> router <router> node <node>
Keyword Arguments
name | description |
---|
destination-ip | The destination IP address/prefix to match [type: IP prefix] (default: 0.0.0.0/0) |
destination-port | The destination port to match (can be a range) [type: port or port-range] (default: 0-65535) |
local-only | Session capture is local to the node |
node | The ingress node on which to create the session capture |
packet-count | The number of packets to capture per session, in each direction [type: 'unlimited' or positive int] (default: 100) |
protocol | The protocol to match (in decimal or by name, eg 'tcp') [type: string or uint8] (default: all) |
router | The router on which to create the session capture |
service | The service on which to create the session capture |
session-count | The number of sessions to capture [type: 'unlimited' or positive int] (default: 100) |
source-ip | The source IP address/prefix to match [type: IP prefix] (default: 0.0.0.0/0) |
source-port | The source port to match (can be a range) [type: port or port-range] (default: 0-65535) |
tag | An optional custom name for the session capture pcap files |
See Also
Description
When destination or source IPs are not specified, any IP will be matched.
When destination or source port is not provided, port range of 0-65535 is used.
When protocol is not provided, all protocols will be matched.
When session-count is not specified, default will be unlimited.
When packet-count is not specified, default is 100 packets in each direction for each session matched.
create user
Create a new user account interactively.
Usage
Positional Arguments
name | description |
---|
username | the name of the account to create |
See Also
Description
The create user
command allows administrators to create user accounts for user and/or administrative access to the SSR's management port. Issuing the create user <username>
launches an interactive session that prompts for the new user's full name, password, whether they are an administrative or basic user, and the enabled/disabled state of that user account.
Password policies have been updated with the release of version 5.6. Please see Password Policies for additional information.
Example
admin@labsystem1.fiedler# create user jdeveloper
Creating account "jdeveloper"...
Full Name: Joe Developer
Password: <not echoed to screen>
Confirm: <not echoed to screen>
Role (user | admin) [user]: admin
Enabled: true
Account "jdeveloper" successfully created
Version History
Release | Modification |
---|
2.0.0 | This feature was introduced |
delete capture-filter
Deletes a capture-filter created using create capture-filter. (It will not delete filters committed as part of the configuration.)
Usage
delete capture-filter device-interface <device-interface> router <router> node <node> <capture-filter>
Keyword Arguments
name | description |
---|
device-interface | The device interface on which to delete the capture filter |
node | The node on which to remove the capture filter |
router | The router on which to remove the capture filter |
Positional Arguments
name | description |
---|
capture-filter | The capture-filter to remove (Uses BPF syntax) |
See Also
Example
admin@tp-colo-primary.tp-colo# delete capture-filter device-interface blended-5 "host 172.18.5.4"
Successfully deleted capture-filter
Version History
Release | Modification |
---|
4.4.0 | This feature was introduced |
delete (in config)
Usage
delete { <configuration> } [ force ]
Description
The delete
command, when issued within the configuration hierarchy, lets administrators delete portions of the candidate configuration. This can be used to delete specific fields within a configuration element, or entire elements.
The command will prompt you for confirmation before deleting the configuration, unless the optional keyword force
is included.
Example
admin@labsystem1.fiedler# config authority router burlington
admin@labsystem1.fiedler (router[name=burlington])# delete node combo1
Are you sure you want to delete item "[name=combo1]" [y/N]: N
Operation canceled
Version History
Release | Modification |
---|
1.0.0 | This feature was introduced |
delete certificate webserver
Delete the webserver certificate.
Usage
delete certificate webserver [force]
Keyword Arguments
name | description |
---|
force | Skip confirmation prompt |
See Also
Description
The delete certificate webserver command allows administrators to delete certificates that are stored on the SSR. Note that the SSR will always prompt the administrator to confirm deletion (the "force" keyword is not allowed).
Example
admin@labsystem1.fiedler# delete certificate webserver
Are you sure you want to delete certificate 'webserver'? [y/N]: y
admin@labsystem1.fiedler#
Version History
Release | Modification |
---|
1.0.0 | This feature was introduced |
delete config exported
Delete an exported configuration from disk.
Usage
delete config exported [force] <name>
Keyword Arguments
name | description |
---|
force | Skip confirmation prompt |
Positional Arguments
name | description |
---|
name | Name of the exported configuration to delete |
See Also
Description
The delete config command allows administrators to delete configurations from the SSR's filesystem that had previously been exported with the export config command. The force flag will skip the confirmation check without prompting the user.
Example
admin@cnd1.conductor# delete config exported 20180115_export.gz
Are you sure that you want to delete exported config '20180115_export.gz'? [y/N]: y
Successfully deleted exported configuration: '20180115_export.gz'
admin@cnd1.conductor#
Version History
Release | Modification |
---|
3.2.0 | This feature was introduced |
delete flows
Clears all active flow data from this node.
Usage
delete flows [force] [node <node>] {router <router> | resource-group <resource-group>}
Keyword Arguments
name | description |
---|
force | Skip confirmation prompt |
node | The node from which to delete flow entries |
resource-group | The name of the resource group |
router | The router from which to delete flow entries |
Description
The delete flows command clears all active flow data from this node. Administrators can specify which node to clear flow data from by adding the node name as an optional argument to the command.
This command has been maintained for backward compatibility to older versions of software. The delete sessions command is preferred in versions newer than 3.2.0.
This may be a service impacting operation.
Example
admin@labsystem1.fiedler# delete flows linecard-test
admin@labsystem1.fiedler#
Version History
Release | Modification |
---|
1.0.0 | This feature was introduced |
delete session-capture
Deletes session capture from selected service.
Usage
delete session-capture [source-ip <source-ip>] [source-port <source-port>] [destination-ip <destination-ip>] [destination-port <destination-port>] [protocol <protocol>] [session-count <session-count>] [packet-count <packet-count>] [local-only] [tag <tag>] service <service> router <router> node <node>
Keyword Arguments
name | description |
---|
destination-ip | The destination IP address/prefix to match [type: IP prefix] (default: 0.0.0.0/0) |
destination-port | The destination port to match (can be a range) [type: port or port-range] (default: 0-65535) |
local-only | Session capture is local to the node |
node | The node on which to remove the session-capture filter |
packet-count | The number of packets to capture per session, in each direction [type: 'unlimited' or positive int] (default: 100) |
protocol | The protocol to match (in decimal or by name, eg 'tcp') [type: string or uint8] (default: all) |
router | The router on which to remove the session-capture filter |
service | The service on which to create the session capture |
session-count | The number of sessions to capture [type: 'unlimited' or positive int] (default: 100) |
source-ip | The source IP address/prefix to match [type: IP prefix] (default: 0.0.0.0/0) |
source-port | The source port to match (can be a range) [type: port or port-range] (default: 0-65535) |
tag | An optional custom name for the session capture pcap files |
Subcommands
command | description |
---|
by-id | Deletes session-capture by capture-id from selected service. |
See Also
delete session-capture by-id
Deletes session-capture by capture-id from selected service.
Usage
delete session-capture by-id service <service> router <router> node <node> <capture-id>
Keyword Arguments
name | description |
---|
node | The node on which to remove the session-capture filter |
router | The router on which to remove the session-capture filter |
service | The service on which to create the session capture |
Positional Arguments
name | description |
---|
capture-id | The session-capture to remove. |
See Also
delete sessions
Delete all current sessions or a subset if arguments are provided.
Usage
delete sessions [{session-id <session-id> | service-name <service-name>}] [force] [node <node>] {router <router> | resource-group <resource-group>}
Keyword Arguments
name | description |
---|
force | Skip confirmation prompt |
node | The node from which to delete sessions |
resource-group | The name of the resource group |
router | The router from which to delete sessions |
service-name | The name of the service for which to delete all sessions |
session-id | The identifier of the session to be deleted |
Description
The delete sessions command removes all current sessions or a subset if arguments are provided.
This may be a service impacting operation.
delete system software
Remove or cancel a previously started download.
Usage
delete system software version <version>
Keyword Arguments
name | description |
---|
version | The version to cancel or remove. |
See Also
delete user
Delete a user account
Usage
delete user [force] <username>
Keyword Arguments
name | description |
---|
force | Skip confirmation prompt |
Positional Arguments
name | description |
---|
username | the name of the account to delete |
Subcommands
command | description |
---|
tokens | Revoke API access tokens for a user. |
See Also
Example
admin@labsystem1.fiedler# delete user jdeveloper
Delete account 'jdeveloper'? [y/N]: y
Account 'jdeveloper' successfully deleted
Version History
Release | Modification |
---|
2.0.0 | This feature was introduced |
delete user tokens
Revoke API access tokens for a user.
Usage
delete user tokens [force] <username>
Keyword Arguments
name | description |
---|
force | Skip confirmation prompt |
Positional Arguments
name | description |
---|
username | the name of the account to revoke API tokens for |
See Also
edit prompt
Allows the user to specify a custom format for the PCLI prompt.
Usage
Positional Arguments
name | description |
---|
format | Format string for the prompt display |
See Also
Description
The edit prompt command lets administrators change the display of the PCLI prompt, and includes a flexible array of options for customizability. In addition to various variables, the prompt string can include conditional statements, to affect the display of the prompt under different operating modes. All of this is accomplished by supplying a format string, which contains the syntax of the desired PCLI prompt.
State Variables
===============
{user} - Name of the currently logged in user
{address} - Address (node.router) of the current system
{node} - Name of the connected node
{router} - Name of the connected router
{context} - Currently set context if one is set; empty otherwise
{path} - Full path to the current PCLI menu, separated by '/'
{location} - Name of current PCLI menu
{privilege} - "#" if the current user has administrator privileges, else ">"
Conditional Variables
=====================
{top-level} - Evaluates true if the PCLI is at the top menu
{uncomitted} - Evaluates true if the candidate configuration differs from the running configuration
Conditionals
============
A conditional statement allows the prompt to be customized with conditional or state variables
The format of a conditional statement is:
[condition?value_if_true:value_if_false]
The condition is true if a state variable is not an empty string or if a conditional variable is true
For example:
'This prompt is [top-level?definitely:not] top level'
Yields one of the following:
'This prompt is definitely top level' (if top-level is true or has a value)
'This prompt is not top level' (if top-level is false or has no value)
Timestamps
==========
Custom timestamps are created with the use of standard strftime format codes
For example:
'(%x %H:%M) {user}@{address}$ '
Yields:
'(03/08/17 11:46) admin@node.router$ '
See <https://docs.python.org/3/library/datetime.html#strftime-strptime-behavior> for all format codes
Any '?'s that appear in a timestamp must be escaped with a '\'
Special characters*
==================
\n - Newline
\t - Tab
\[ - Literal '['
\] - Literal ']'
{{ - Literal '{'
}} - Literal '}'
%% - Literal '%'
* Use \\ if not using a quoted string to specify the prompt
Version History
Release | Modification |
---|
3.1.0 | This feature was introduced |
edit user
Modify an existing user account
Usage
Positional Arguments
name | description |
---|
username | The name of the account to modify (default: <current user>) |
Subcommands
command | description |
---|
mode | Edit the current user's configuration mode. |
See Also
Description
The password must be at least eight characters long, with at least one uppercase letter, one lowercase letter, one digit, and cannot contain any characters that repeat more than three times.
The edit user command enters a configuration subtree specific to administering user accounts. From within this subtree, administrators can change any of the attributes associated with a user account (full name, password, role, and enabled state). This is done in a "configuration-like" way, where commands are issued as attribute value.
As with standard configuration, using the "?" command will list the options available for editing.
Example
admin@labsystem1.fiedler# edit user jdeveloper
admin@labsystem1.fiedler (user[name=jdeveloper])# ?
User Attributes
---------------
enabled Enable or disable this user.
full-name The user's full name, for display purposes only.
password No help available
role A list of roles assigned to the user.
General Commands
----------------
delete Delete an attribute from a user account
do Execute a top-level command
exit Exit this menu (You can also press Ctrl+D)
quit Quit the PCLI
top Return to the root menu
up Exit this menu and navigate up the hierarchy the given number of levels
where Display the current location in the CLI hierarchy
admin@labsystem1.fiedler (user[name=jdeveloper])#
Modifying these attributes is done as follows:
admin@labsystem1.fiedler (user[name=jdeveloper])# full-name "Joseph Developer"
Account 'jdeveloper' updated successfully
admin@labsystem1.fiedler (user[name=jdeveloper])# top
admin@labsystem1.fiedler# show user jdeveloper
=============================
Information for jdeveloper:
=============================
Enabled: true
Full Name: Joseph Developer
Role: admin
admin@labsystem1.fiedler#
Version History
Release | Modification |
---|
2.0.0 | This feature was introduced |
edit user mode
Edit the current user's configuration mode.
Usage
Positional Arguments
name | description |
---|
value | basic | advanced |
See Also
Description
Advanced mode exposes additional configuration elements for editing and viewing.
exit (in config)
The exit command moves your focus to the PCLI home.
Usage
Example
admin@labsystem1.fiedler# config authority router beacon
admin@labsystem1.fiedler (router[name=beacon])# where
configure authority router beacon
admin@labsystem1.fiedler (router[name=beacon])# exit
admin@labsystem1.fiedler# where
admin@labsystem1.fiedler#
Version History
Release | Modification |
---|
1.0.0 | This feature was introduced |
export config
Export a copy of the current running or candidate config.
Usage
export config <datastore> <export-name>
Positional Arguments
name | description |
---|
datastore | running | candidate |
export-name | A name consisting of alphanumeric characters or any of the following: . - _ |
See Also
Description
The export command takes a configuration from a previously created backup (via create config backup), from the candidate configuration, or from the SSR's running configuration, and stores it as a file on the local filesystem. It can then be taken off, moved onto other systems, archived, etc.
Exported files are stored in /etc/128technology/config-exports/ and are stored as GZIP compressed files.
The export command's complement, import is used to reverse the process, taking a configuration archive and restoring it onto a system.
The delete config exported command removes unneeded exported configurations.
Example
admin@labsystem1.fiedler# export config candidate myCandidate
Successfully exported configuration: /etc/128technology/config-exports/myCandidate.gz
admin@labsystem1.fiedler#
Version History
Release | Modification |
---|
2.0.0 | This feature was introduced |
3.1.0 | The location of the exported configuration changed |
import certificate webserver
Import a certificate to be used by the webserver.
Usage
import certificate webserver
See Also
Description
This command allows administrators to load certificates into their SSR by pasting them into their active PCLI session. By issuing the import certificate
command, the PCLI prompts the user for the name of the certificate they plan to import, then asks whether it is a CA (certificate authority) certificate or not. Once these questions are answered, administrators can paste the certificate, and is reminded to press CTRL-D once the pasting is complete. Pressing CTRL-D causes the SSR to validate the configuration to ensure it is a valid X.509 certificate before loading it into persistent storage. If the X.509 validation fails, the user is informed as follows:
Example
admin@labsystem1.fiedler# import certificate webserver
Enter the CA certificate in PEM format (Press CTRL-D to finish):
Certificate is not in valid X509 format
admin@labsystem1.fiedler#
Version History
Release | Modification |
---|
1.0.0 | This feature was introduced |
import config
Import a configuration as the candidate config.
Usage
import config [force] <name>
Keyword Arguments
name | description |
---|
force | Skip confirmation prompt |
Positional Arguments
name | description |
---|
name | Name of the configuration file to import |
See Also
Description
This command takes a backup configuration (one that has been stored with the export
command) and overwrites the current candidate configuration with its contents. Inclusion of the optional "force" keyword will skip the prompt for confirmation.
Example
admin@labsystem1.fiedler# import config myCandidate.gz
Replace the existing candidate configuration with the contents of backup _myCandidate.gz_? [y/N]: y
Backup configuration _myCandidate.gz_ successfully written to the candidate config
admin@labsystem1.fiedler#
Version History
Release | Modification |
---|
2.0.0 | This feature was introduced |
import iso
Import SSR ISO to the local repository
Usage
import iso [check-rpm-signature <check-rpm-signature>] [force] [verbose] {hunt | filepath <filepath>}
Keyword Arguments
name | description |
---|
check-rpm-signature | required | allow-unsigned | disabled (default: required) |
filepath | The absolute filepath to the ISO |
force | Skip confirmation prompt |
hunt | Find and import all ISOs from the filesystem |
verbose | Increase log level verbosity |
Example
admin@conductor.Conductor# import iso hunt
This command is resource intensive and can take a while. Are you sure? [y/N]: y
Current Installer version: 2.5.0-0.20200326163206.snapshot
Installer will run in non-interactive mode
Refreshing DNF cache (this may take a few minutes)
Cleaning DNF data: expire-cache
Making the DNF cache
Cleaning legacy local repos (this may take a few minutes)
Installer will hunt for ISOs to import
Importing packages for 128T-4.4.0-0.202004021313.release.el7.x86_64.rpm
Installer complete
Import success
Version History
Release | Modification |
---|
4.4.0 | This feature was introduced |
lookup application by-address
Look up application identification by address key
Usage
lookup application by-address router <router> node <node> <ip> <port> <protocol>
Keyword Arguments
name | description |
---|
node | The node on which to look up application identification |
router | The router on which to look up application identification |
Positional Arguments
name | description |
---|
ip | IP address of the address key [type: IP address] |
port | Port of the address key [type: port] |
protocol | Protocol of the address key [type: string or uint8] |
See Also
lookup application by-domain
Look up application identification by domain name or url key
Usage
lookup application by-domain router <router> node <node> <domain-url>
Keyword Arguments
name | description |
---|
node | The node on which to look up application identification |
router | The router on which to look up application identification |
Positional Arguments
name | description |
---|
domain-url | Domain name or URL |
See Also
manage plugin install
Install a plugin on conductor.
Usage
manage plugin install [node <node>] <name> [<version>]
Keyword Arguments
name | description |
---|
node | Node to install on (default: all) |
Positional Arguments
name | description |
---|
name | Name of plugin to install |
version | Version of plugin to install (default: latest) |
See Also
manage plugin remove
Remove an installed plugin.
Usage
manage plugin remove [node <node>] <name>
Keyword Arguments
name | description |
---|
node | Node to remove on (default: all) |
Positional Arguments
name | description |
---|
name | Name of plugin to be removed |
See Also
migrate
Migrate an SSR to a new conductor. For more details on the SSR router migration refer to How to: Conductor Migration.
Usage
migrate [skip-validation] [force] conductor <address> [<address>] router <router>
Keyword Arguments
name | description |
---|
conductor | The address(es) of the conductor node(s) to migrate to |
force | Skip confirmation prompt |
router | The router to migrate |
skip-validation | Attempt to migrate the router without checking if migration is possible |
See Also
ping
Send an ICMP request through a network interface.
Usage
ping [count <count>] [size <size>] [timeout <timeout>] [set-df-bit] [egress-interface <egress-interface>] [gateway-ip <gateway-ip>] router <router> node <node> <destination-ip>
Keyword Arguments
name | description |
---|
count | Number of ping requests to send [type: int] (default: 4) |
egress-interface | Network interface from which to ping |
gateway-ip | Gateway IP address from which to ping [type: IP address] |
node | The node from which to send the ping request |
router | The router from which to send the ping request |
set-df-bit | Set the IPv4 'Don't Fragment' bit on the request packet |
size | Number of data bytes to send [type: int] (default: 56) |
timeout | Time to wait for a response, in seconds [max: 10 seconds] [type: int] (default: 1) |
Positional Arguments
name | description |
---|
destination-ip | Destination IP of the ping request [type: IP address] |
Description
This issues ICMP requests to the specified destination-ip merely as a connectivity test, and bypasses the typical packet processing logic that would potentially restrict access to various tenants and destined for service addresses. The count modifier will affect the number of pings that are issued. The interface modifier lets administrators specify the egress interface for issuing the pings. The timeout modifier will set the waiting period for a reply before declaring the ping as a failure. The set-df-bit and record-route options enable the respective flags in the outgoing ICMP request.
Example
admin@gouda.novigrad# ping egress-interface wan-interface 8.8.8.8
PING 8.8.8.8 56 bytes of data.
Ping from 8.8.8.8 (8.8.8.8): icmp_seq=0 ttl=57 time=12.97ms
Ping from 8.8.8.8 (8.8.8.8): icmp_seq=1 ttl=57 time=10.597ms
Ping from 8.8.8.8 (8.8.8.8): icmp_seq=2 ttl=57 time=10.643ms
Ping from 8.8.8.8 (8.8.8.8): icmp_seq=3 ttl=57 time=10.444ms
Version History
Release | Modification |
---|
3.2.0 | This feature was introduced. The previous behavior of the ping command is now realized as service-ping |
quit
Quit the PCLI.
Usage
Description
This command logs the user out, and quits the PCLI.
Version History
Release | Modification |
---|
1.0.0 | This feature was introduced |
refresh dns resolutions
Refreshes all DNS resolutions configured on the platform.
Usage
refresh dns resolutions [{router <router> | resource-group <resource-group>}] [hostname <hostname>] [force]
Keyword Arguments
name | description |
---|
force | Skip confirmation prompt. Only required when targeting all routers |
hostname | The DNS hostname belonging to a node |
resource-group | The name of the resource group |
router | The name of the router (default: <current router>) |
See Also
release dhcp lease
Releases an active DHCP lease.
Usage