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>] [mist-instance <mist-instance>]
Keyword Arguments
name | description |
---|
force | Skip confirmation prompt. |
mist-instance | Global01 | Global02 | Global03 | Global04 | Global05 | EMEA01 | EMEA02 | EMEA03 | APAC01 | APAC02 | APAC03 | APAC04 | APAC05 | USGov01 (default: Global01) |
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.
This command can only be run on a Router.
Release | Modification |
---|
6.0.0 | This feature was introduced |
6.3.0 | Added mist-instance |
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 |
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>) |
Description
This command can only be run on a Conductor.
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 system connectivity authorized-keys
Adds an entry to the ssh authorized keys file.
Usage
create system connectivity authorized-keys [{router <router> | resource-group <resource-group>}] [force] [node <node>] <key-type> <key-value> <comment>
Keyword Arguments
name | description |
---|
force | Skip confirmation prompt. Only required when targeting all routers |
node | The name of the node |
resource-group | The name of the resource group |
router | The name of the router (default: <current router>) |
Positional Arguments
name | description |
---|
key-type | The type of key (e.g. ssh-rsa) |
key-value | The base64 encoded public key |
comment | A comment (usually the asset-id) to be associated with entry |
See Also
create system connectivity known-hosts
Adds an entry to the ssh known hosts file.
Usage
create system connectivity known-hosts [{router <router> | resource-group <resource-group>}] [force] [node <node>] <host> <key-type> <key-value> <comment>
Keyword Arguments
name | description |
---|
force | Skip confirmation prompt. Only required when targeting all routers |
node | The name of the node |
resource-group | The name of the resource group |
router | The name of the router (default: <current router>) |
Positional Arguments
name | description |
---|
host | The domains/IP addresses associated with the key |
key-type | The type of key (e.g. ssh-rsa) |
key-value | The base64 encoded public key |
comment | A comment (usually the asset-id) to be associated with entry |
See Also
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.
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 connectivity authorized-keys autoclean
Automatically removes unrecognized entries from the ssh authorized keys file.
Usage
delete system connectivity authorized-keys autoclean [{router <router> | resource-group <resource-group>}] [force] [node <node>]
Keyword Arguments
name | description |
---|
force | Skip confirmation prompt. Only required when targeting all routers |
node | The name of the node |
resource-group | The name of the resource group |
router | The name of the router (default: <current router>) |
delete system connectivity authorized-keys entry
Deletes entries from the ssh authorized keys file based on specified parameters.
Usage
delete system connectivity authorized-keys entry [{router <router> | resource-group <resource-group>}] [key-type <key-type>] [key-value <key-value>] [comment <comment>] [force] [node <node>]
Keyword Arguments
name | description |
---|
comment | Optionally specifies a comment to delete entries by (default: ) |
force | Skip confirmation prompt. Only required when targeting all routers |
key-type | Optionally specifies which key type to delete (default: ) |
key-value | Optionally specifies a key value to delete entries by (default: ) |
node | The name of the node |
resource-group | The name of the resource group |
router | The name of the router (default: <current router>) |
See Also
delete system connectivity known-hosts autoclean
Automatically removes unrecognized entries from the ssh known hosts file.
Usage
delete system connectivity known-hosts autoclean [{router <router> | resource-group <resource-group>}] [force] [node <node>]
Keyword Arguments
name | description |
---|
force | Skip confirmation prompt. Only required when targeting all routers |
node | The name of the node |
resource-group | The name of the resource group |
router | The name of the router (default: <current router>) |
delete system connectivity known-hosts entry
Deletes entries from the ssh known hosts file based on specified parameters.
Usage
delete system connectivity known-hosts entry [{router <router> | resource-group <resource-group>}] [host <host>] [key-type <key-type>] [key-value <key-value>] [comment <comment>] [force] [node <node>]
Keyword Arguments
name | description |
---|
comment | Optionally specifies a comment to delete entries by |
force | Skip confirmation prompt. Only required when targeting all routers |
host | Optionally specifies a host to delete entries for |
key-type | Optionally specifies which key type to delete |
key-value | Optionally specifies a key value to delete entries by |
node | The name of the node |
resource-group | The name of the resource group |
router | The name of the router (default: <current router>) |
See Also
delete system software
Remove or cancel a previously started download.
Usage
delete system software [{router <router> | resource-group <resource-group>}] [force] [node <node>] version <version>
Keyword Arguments
name | description |
---|
force | Skip confirmation prompt |
node | The node on which to cancel or remove SSR software |
resource-group | The name of the resource group |
router | The router on which to cancel or remove SSR software (default: <current router>) |
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 the running or candidate configuration from the SSR 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, tarball, checksum or signature file |
force | Skip confirmation prompt |
hunt | Find and import all image, checksum and signature files from the filesystem matching 128T*.iso, SSR*.iso or SSR*.tar and any corresponding checksum and signature files |
verbose | Increase log level verbosity |
initialize conductor
Initializes the current device as a conductor.
Usage
initialize conductor [artifactory-user <artifactory-user>] [artifactory-password <artifactory-password>] [dns-servers <dns-servers>] [node-ip <node-ip>] [node-gateway <node-gateway>] [interface-name <interface-name>] [clustered] [ha-ip <ha-ip>] [ha-interface-name <ha-interface-name>] [ha-peer-ip <ha-peer-ip>] [ha-peer-name <ha-peer-name>] [learn-from-ha-peer] [ha-peer-username <ha-peer-username>] [unsafe-ha-peer-password <unsafe-ha-peer-password>] router-name <router-name> node-name <node-name>
Keyword Arguments
name | description |
---|
artifactory-password | Password portion of the artifactory credentials |
artifactory-user | User portion of the artifactory credentials |
clustered | Whether or not this conductor is to be configured as an HA pair |
dns-servers | comma separated list of DNS servers |
ha-interface-name | Interface name (matching a port in the device-map) to bind the ha-ip to. |
ha-ip | The IPv4 address to assign to the HA interface on this node |
ha-peer-ip | The IPv4 address of the node to be used as an HA peer |
ha-peer-name | The name of the Node to be used as an HA peer |
ha-peer-username | The user on the peer node to authenticate as. This user must have sudo privileges. Required if 'learn-from-ha-peer' is true. |
interface-name | Interface name (matching a port in the device-map) to bind the node-ip and node-gateway to. |
learn-from-ha-peer | If true, the Initializer will use the HA peer to obtain setup information. |
node-gateway | The IP address of the gateway of the node being provisioned |
node-ip | The IPv4 address of the node being provisioned (x.x.x.x/y) |
node-name | The name of the node being provisioned |
router-name | Assign a name to the router |
unsafe-ha-peer-password | The password for the user on the peer node to authenticate as. WARNING: If this field is used, the preferences file should not be world-readable to avoid leaking the peer node password. Required if 'learn-from-ha-peer' is true. |
See Also
initialize conductor-managed
Initializes the current device as a conductor-managed router.
Usage
initialize conductor-managed router-name <router-name> conductor-ip <address> [<address>]
Keyword Arguments
name | description |
---|
conductor-ip | The address(es) of the conductor node(s) |
router-name | Assign a name to the router |
See Also
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
Description
This command can only be run on a Conductor.
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
Description
This command can only be run on a Conductor.
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
release dhcp lease [force] [node <node>] {router <router> | resource-group <resource-group>} network-interface <network-interface>
Keyword Arguments
name | description |
---|
force | Skip confirmation prompt. Only required when targeting all routers |
network-interface | The network interface on which to release the current DHCP lease |
node | The name of the node (default: all) |
resource-group | The name of the resource group |
router | The name of the router |
See Also
repeat
Repeat any command multiple times.
Usage
repeat [beep] [exit-on-failure] [interval <interval>] <command> [<command> ...]
Keyword Arguments
name | description |
---|
beep | Beep if the command fails to execute |
exit-on-failure | Exit if the command fails to execute |
interval | Seconds to wait between updates [type: int] (default: 2) |
Positional Arguments
name | description |
---|
command | Command to repeat |
Description
This command can be used to "watch" statistics over a specified period. In order to stop the repeat command, the user must issue a CTRL-C
.
Example
admin@gouda.novigrad# repeat show stats device-interface
Running "show stats device-interface" every 2 seconds
Wed 2020-04-22 17:42:04 UTC
Retrieving statistics...
Device Interface Management Stats
---------------------------------
================= ======= =======
Metric Node Value
================= ======= =======
message-failure gouda 0
message-success gouda 2
Completed in 1.66 seconds
replace config
Search for and replace configuration data that matches a specified pattern.
Usage
replace config <find> <replace>
Keyword Arguments
name | description |
---|
force | Replace all matching data without prompts |
Positional Arguments
name | description |
---|
find | The text to find in the candidate configuration |
replace | The new value to replace 'find' with |
Description
The replace command is a powerful tool for making sweeping configuration changes, similar to a "find and replace" operation in a word processor.
The replace command has several optional arguments that affect how the replacement occurs; case-sensitive will only match elements within the configuration that match the case supplied with the query string. The regex argument treats the query string as a regular expression. The whole-word argument requires that the match be an entire word, rather than just a substring or partial match.
The user-supplied query string and replacement string are the matching text, and the replacement text, respectively.
Example
admin@labsystem1.fiedler# replace config all internal newInternal
Replacing 'config authority router RTR_EAST_CONDUCTOR inter-node-security internal' with 'newInternal'...
Replacing 'config authority router RTR_EAST_COMBO inter-node-security internal' with 'newInternal'...
Replacing 'config authority router RTR_WEST_COMBO inter-node-security internal' with 'newInternal'...
Replacing 'config authority router RTR_CENTRAL_COMBO inter-node-security internal' with 'newInternal'...
Replacing 'config authority security internal name internal' with 'newInternal'...
Replace completed successfully
admin@labsystem1.fiedler#
Version History
Release | Modification |
---|
3.1.0 | This feature was introduced |
request idp restart
Restart IDP Command
Usage
request idp restart [force] [rebuild] router <router> node <node>
Keyword Arguments
name | description |
---|
force | Skip confirmation prompt |
node | The node for which to restart IDP |
rebuild | Delete and rebuild IDP |
router | The router for which to restart IDP |
See Also
Description
Initiate a restart of the underlying IDP engine.
Version History
Release | Modification |
---|
6.0.4 | This feature was introduced |
6.1.0 | show idp application details added |
request idp signature-query
Request IDP signature database connectivity.
Usage
request idp signature-query [force] [node <node>] {router <router> | resource-group <resource-group>}
Keyword Arguments
name | description |
---|
force | Skip confirmation prompt. Only required when targeting all routers |
node | The node for which to refresh security signature data |
resource-group | The name of the resource group |
router | The router for which to refresh security signature data |
Description
Query and display the IDP signature database connectivity details.
See Also
Version History
Release | Modification |
---|
6.0.4 | This feature was introduced |
request system software download
Download a new version of the SSR.
Usage
request system software download [{router <router> | resource-group <resource-group>}] [skip-version-check] [cohort-id <cohort-id>] [force] [node <node>] version <version>
Keyword Arguments
name | description |
---|
cohort-id | Assign a cohort ID to the operation. |
force | Skip confirmation prompt |
node | The node on which to download SSR software |
resource-group | The name of the resource group |
router | The router on which to download SSR software (default: <current router>) |
skip-version-check | Skip the version check to allow downloading SSR software at a lower version than what is currently installed. |
version | The version to download. |
See Also
request system software health-check
Perform a health check of an SSR.
Usage
request system software health-check [{router <router> | resource-group <resource-group>}] [force] [node <node>] [<target>]
Keyword Arguments
name | description |
---|
force | Skip confirmation prompt. Only required when targeting all routers |
node | The node on which to perform the health-check |
resource-group | The name of the resource group |
router | The router on which to perform the health-check (default: <current router>) |
Positional Arguments
name | description |
---|
target | The target health-check (default: steady-state) |
See Also
request system software revert
Revert to a previous version of the SSR.
Usage
request system software revert [{router <router> | resource-group <resource-group>}] [simultaneous] [cohort-id <cohort-id>] [force] [node <node>]
Keyword Arguments
name | description |
---|
cohort-id | Assign a cohort ID to the operation. |
force | Skip confirmation prompt |
node | The name of the node |
resource-group | The name of the resource group |
router | The router on which to revert to previous SSR software (default: <current router>) |
simultaneous | Revert both nodes in an HA router at the same time to maximize speed but interrupt service. Only valid when targeting a router. |
See Also
Description
Revert a router or node to a previous version of the SSR software. When targeting a router with the revert command the default behavior for HA routers is to perform a sequenced revert, which will revert each node one at a time to minimize service impact. The 'simultaneous' flag will revert both nodes at once to maximize speed but impact service.
When targeting a node in an HA router with the revert command, only the target node will be reverted.
This may be a service impacting operation.
request system software upgrade
Upgrade to a new version of the SSR.
Usage