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