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.
The clear arp command is typically used during troubleshooting, to remove ARP (Address Resolution Protocol) entries from an SSR router or node's ARP cache. The command has multiple filters, allowing administrators to specify which specific entry to remove. The PCLI will auto-complete typed entries for improved accuracy.
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.
The commit command causes the SSR router 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.
*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
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.
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 128T router 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.
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#
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.
Alternatively, administrators may execute the configure command with optional arguments to enter into configuration mode "deeper" in the configuration tree. For example:
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" ...
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
The create certificate request webserver generates a certificate-request, which is then sent to a Certificate Authority. The SSR router 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/.
The create certificate self-signed webserver generates a self-signed certificate which is used for the local webserver. The SSR router will, through a series of interactive prompts, request information from the administrator to generate either the request or certificate, as appropriate.
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.
The create user command allows administrators to create user accounts for user and/or administrative access to the SSR router'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.
note
Password policies have been updated with the release of version 5.6. Please see Password Policies for additional information.
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
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.
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
The delete certificate webserver command allows administrators to delete certificates that are stored on the SSR router. Note that the SSR router will always prompt the administrator to confirm deletion (the "force" keyword is not allowed).
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.
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#
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.
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
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.
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#
The export command takes a configuration from a previously created backup (via create config backup), from the candidate configuration, or from the SSR router'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.
This command allows administrators to load certificates into their 128T router 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 128T router 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:
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#
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.
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#
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
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.
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.
This command removes all administrator-added configuration, and restores the basic configuration to all of the SSR router's factory default settings. The PCLI will prompt for confirmation before resetting the configuration, unless the optional force modifier is added.
admin@labsystem1.fiedler# restore config factory-default Are you sure you want to restore the candidate config to factory defaults? [y/N]: n Operation canceled
This command removes all administrator-added configuration since the last commit, effectively bringing the running configuration and the candidate configuration back to parity. The PCLI will prompt for confirmation before resetting the configuration, unless the optional force modifier is added.
*admin@node1.bernstein# restore config running Are you sure you want to discard uncommitted changes from the candidate config? [y/N]: y Candidate configuration changes successfully discarded *admin@node1.bernstein#
Once initiated, the system will begin to stop all running processes and restore the system to the factory default configuration. Once the process has been completed, the system will reboot.
The restore users factory-default command deletes all administratively created user accounts (i.e., all but the ones that are installed with the SSR routing software natively) and leaves the system with just the admin and user accounts.
This command is used to rotate log files (i.e., close the current log file and open a new one) generated by the various processes that comprise the SSR router to rotate. The SSR router's log files, stored in /var/log/128technology, keep 25 prior logs for each process, space permitting. Files are rotated such that, for instance, pcli.log becomes pcli.1.log while pcli.1.log becomes pcli.2.log, and so on. The oldest log file for each process is removed.
The rotate log command is useful prior to engaging in troubleshooting exercises, to help narrow down which files may contain items of interest. It is particularly useful when used in conjunction with the write command, described elsewhere in this document.
Without any arguments, the rotate log command will rotate all log files on all nodes.
The optional arguments process-name and node-name let administrators specify which processes should rotate their logs, and on which nodes.
admin@labsystem1.fiedler# shell ls -ltr /var/log/128technology/ | grep highwayManager -rw-r--r-- 1 root root 14964 Oct 8 05:34 highwayManager.4.log -rw-r--r-- 1 root root 35908 Oct 8 05:42 highwayManager.3.log -rw-r--r-- 1 root root 10653 Oct 11 11:12 highwayManager.2.log -rw-r--r-- 1 root root 146057 Oct 11 11:42 highwayManager.1.log -rw-r--r-- 1 root root 117673 Oct 11 14:48 highwayManager.log admin@labsystem1.fiedler# rotate log highwayManager labsystem1 Logs successfully rotated admin@labsystem1.fiedler# shell ls -ltr /var/log/128technology/ | grep highwayManager -rw-r--r-- 1 root root 14964 Oct 8 05:34 highwayManager.5.log -rw-r--r-- 1 root root 35908 Oct 8 05:42 highwayManager.4.log -rw-r--r-- 1 root root 10653 Oct 11 11:12 highwayManager.3.log -rw-r--r-- 1 root root 146057 Oct 11 11:42 highwayManager.2.log -rw-r--r-- 1 root root 117673 Oct 11 14:48 highwayManager.1.log -rw-r--r-- 1 root root 0 Oct 12 09:45 highwayManager.log
In this example you can see that what was previously named highwayManager.4.log has been rotated to highwayManager.5.log; likewise, all other logs were incremented. What was highwayManager.log is now highwayManager.1.log, and a new highwayManager.log file has been created, and is empty.
This command packages statistics, logs and other diagnostic data, to exchange with 128 Technology's support team. The tech-support-info command echoes the location where it stores the file when complete (/var/log/128technology/tech-support-info.tar.gz).
New manifest files can be created and placed into /etc/128technology/tech-support-manifests. Each manifest contains a list of PCLI commands, shell commands, files, and systemd journal's to collect.
note
This command collect a lot of data, and may take some time to complete.
The search command and its various subcommands let users search through the SSR router's PCLI command tree, the configuration tree, and user-supplied configuration data to locate the information specified by the supplied find string.
When omitting the optional filter, the search command will return results for all of the types of information it can locate: commands, configuration attributes, and configuration data.
admin@labsystem1.fiedler# search ntp Commands: - show ntp - show config candidate authority router system ntp - show config candidate authority router system ntp server - show config candidate authority router system ntp server ip-address - show config candidate authority router system services ntp - show config running authority router system ntp - show config running authority router system ntp server - show config running authority router system ntp server ip-address - show config running authority router system services ntp Configuration Attributes: - configure authority router system ntp - configure authority router system services ntp
This issues ICMP requests to the specified destination-ip, and offers the administrators a variety of ways to formulate the request. The tenant and service-name modifiers specify which "source tenant" to use for the request, and the name of the service for which the destination-ip applies. 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.
admin@node1.t128# set config encryption Are you sure you would like to enable configuration encryption? [y/N]: y ✔ Encrypting configuration... 1/1 targets complete. Configuration was successfully encrypted.
admin@node1.t128# set config encryption disabled Are you sure you would like to disable configuration encryption? [y/N]: y ✔ Disabling configuration encryption... 1/1 targets complete. Configuration encryption was successfully disabled.
The set context node command puts the PCLI into a mode where every subsequent command that is issued that can take a node (in the case of a 128T router) as an argument will default to the context's values.
The set context router command can be used to set the PCLI into a mode where every subsequent command that is issued that can take a router (in the case of the 128T Conductor) or a node (in the case of a 128T router) as an argument will default to the context's values.
note
This does not "remote shell" into the router/node specified by the context's values, it merely uses these as default values for commands that (generally) display value. E.g., show stats, show flows, etc.
When a context is set, the prompt changes to indicate the context as a parenthetical label at the beginning of each PCLI command.
Setting the context to a router is only available within the PCLI of a 128T Conductor.
A timestamp string that can include date, time, or both. Special value "now" sets the start time point to the current time [type: timestamp or 'now'] (default: now)
set context stats start-time lets administrators set a "zero time" for all statistics that the 128T has accumulated. While this stats start-time context is set, all of the output for show stats commands will reflect the accumulation of statistics since that time. This is very useful when troubleshooting issues, or after making configuration changes, to only show data relevant to the exercise at hand.
The set context stats start-time has a flexible parser and can accept many different forms of "time" strings that include date information, time information, or both. There's also a keyword "now" that sets the stats start-time to the current 128T system clock. (The "now" behavior is the default, and thus the 128T will set the stats start-time to the current clock time when no argument is supplied.)
admin@cnd1.conductor# set context stats start-time Stats start time set to: 2018-02-07 10:41:58 admin@cnd1.conductor# set context stats start-time "December 25, 2017" Stats start time set to: 2017-12-25 00:00:00
The set log level command adjusts the degree to which the SSR router writes information into its log files. This is used to selectively turn up and down log verbosity for troubleshooting purposes.
The optional <process-name> and <node-name> arguments, can selectively change only a specific SSR router's software process on a given node.
The level must be one of: fatal, error, warning, info, debug, and trace. These are listed in order of increasing verbosity. 128 Technology, Inc. generally recommends that systems be set to info level by default under normal operating circumstances.
As of software version 3.1, a new subcommand set log level category, allows administrators to collectively adjust groups of related functionality for specific troubleshooting exercises – instead of blindly adjusting the entire system's log level and potentially impacting performance.
The category can be any of the following:
Category Name
Long Name
Description
ATCS
Analytics
Components related to the 128T Analytics Engine.
DATA
Metadata Database
Components related to the configuration and state databases.
DISC
Discovery
Discovery-based components (except BFD). Today this is DHCP and ARP.
USER
User
User-created log messages, generated via the 'write' command.
FLC
FastLane Control
Control system for packet forwarding.
FLPP
First Packet Processing
System for processing the initial packet of each new session.
HWMC
HighwayManager Control
Control system for packet processing.
IPC
Interprocess Communications
The subsystem responsible for messaging between components within the 128T product.
LINK
Internode Link Detection
The subsystem for inter-node communication (today, BFD).
PLAT
Platform
Components related to the underlying platform management.
PLUG
Plugin Components
Components related to plugin management.
RDB
Redundancy Database
The subsystem responsible for synchronizing data between nodes.
Will return the SSR router's logging behavior to the verbosity specified within the configuration, located at: authority > router > system > log-level. Alternatively, administrators can specify a log level to dynamically change all system processes to use.
The set password command allows a PCLI user to change their password. As is typical with most password changing routines, as a security precaution the user must enter their current password before they're permitted to change it.
note
If a password is lost or forgotten and the account is inaccessible, the account cannot be recovered. Please keep password records accessible and secure.
The set provisional-status command allows a specific interface to be brought down without a configuration change. This is useful in situations where you need to temporarily bring down a just device interface (i.e., to trigger an interface failover).
The shell command allows administrators to execute a bash shell, or to execute a command within the context of a bash shell (specified as a series of optional parameters to the shell command).
admin@cnd1.conductor# show alarms Wed 2018-01-17 15:14:03 EST ================== ===================== ========== ============= ========== =================================== ID Time Severity Source Category Message ================== ===================== ========== ============= ========== =================================== cnd1.conductor:4 2018-01-17 13:22:38 major unavailable system No connectivity to b1.branch1 cnd1.conductor:5 2018-01-17 13:22:38 major unavailable system No connectivity to dc1.datacenter cnd1.conductor:6 2018-01-17 13:22:38 major unavailable system No connectivity to dc2.datacenter There are 0 shelved alarms Completed in 0.35 seconds
The show application modules registration subcommand shows all of the modules that provide application names to SSR as part of its Application Classification feature.
The show application modules status subcommand shows all of application names and transport information of a module, as well as other debugging information.
The show application names subcommand shows all of the application names that the SSR has learned, or been configured to recognize, as part of its Application Classification feature.
The number of active sessions for the application.
Ip Tuple Count
The number of addresses and ports associated with the application.
Date Discovered
The time at which the router first learned this application. Restarting the router or deleting the application will reset the time.
Last Updated
The time at which the router updated the entries for the application. The time is updated when the ip tuple information associated with the application has changed.
The show arp subcommand displays the ARP table (MAC address to IP address binding) for a given node. The number of lines of output may be controlled through the use of the optional rows attribute. When not present, the SSR router will default to displaying the first 50 rows of the specified node's ARP table.
admin@gouda.novigrad# show arp Wed 2020-04-22 16:01:05 UTC Node: gouda ========== ====== ================= =================== ======== Dev Name VLAN IP Dest MAC State ========== ====== ================= =================== ======== kni254 0 169.254.127.127 1a:f1:bd:a4:ae:6e Valid lan 0 192.168.0.34 b1:7b:c1:04:0b:ba Valid lan 0 192.168.0.35 01:0e:58:b1:94:bf Valid lan 0 192.168.0.146 a4:83:e7:0b:d7:e1 Valid wan 0 1.2.3.4 21:41:71:c1:99:c1 Valid Completed in 0.07 seconds
The show assets command displays the automated provisioning status of the SSR nodes within an Authority. With SSR's automated provisioning feature set, each "asset" represents a platform into which the SSR software is installed, updated, managed, etc. The show assets command allows administrators to see, at a glance, the state of all assets – including which software versions have been installed on which nodes, what their router and node identifiers are, etc.
The show bgp command and associated subcommands display information about the state of the BGP process on the SSR router. Each of these subcommands will be described in more detail in the sections that follow.
When the show bgp command is issued with no command line arguments, the system returns the general status of the BGP process:
admin@labsystem1.fiedler# show bgp BGP table version is 0, local router ID is 128.128.128.128 Status codes: s suppressed, d damped, h history, \* valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Origin codes: i - IGP, e - EGP, ? – incomplete Network Next Hop Metric LocPrf Weight Path *> 172.18.11.0/24 172.18.1.2 0 0 4200000001 i *> 172.18.22.0/24 172.18.2.2 0 0 4200000002 i *> 172.31.255.10/32 172.18.3.2 0 4200000003 i *> 192.168.128.0 0.0.0.0 0 32768 i Total number of prefixes 4
The <route> argument is given as an IP prefix (CIDR). The show bgp <route> command gives detailed information on the specified route, if it exists in the 128T router's Routing Information Base (RIB).
admin@labsystem1.fiedler# show bgp 172.18.11.0/24 BGP routing table entry for 172.18.11.0/24 Paths: (1 available, best #1, table Default-IP-Routing-Table) Advertised to non peer-group peers: 172.18.2.2 172.18.3.2 4200000001 172.18.1.2 from 172.18.1.2 (1.1.1.1) Origin IGP, metric 0, localpref 100, valid, external, best Last update: Wed Feb 10 19:08:49 2016
The show bgp neighbors command displays detailed information about each of the SSR router's BGP peers. By specifying a specific peer (through the optional argument <neighbor-ip>), administrators can view state information about one peer at a time. When specifying a specific neighbor, the output may include the routes shared with that peer by appending advertised-route or received from that peer by appending received-routes.
admin@labsystem1.fiedler# show bgp neighbors BGP neighbor is 172.18.1.2, remote AS 4200000001, local AS 4200000128, external link BGP version 4, remote router ID 1.1.1.1 BGP state = Established, up for 00:27:25 Last read 00:00:25, hold time is 90, keepalive interval is 30 seconds Configured hold time is 90, keepalive interval is 30 seconds Neighbor capabilities: 4 Byte AS: advertised and received Route refresh: advertised and received(old & new) Address family IPv4 Unicast: advertised and received Graceful Restart Capabilty: advertised and received Remote Restart timer is 120 seconds Address families by peer: none ...
The show bgp summary gives administrators a high-level summary table of the state of all of the SSR router's BGP peers.
It includes information on each BGP neighbor, including the version (V) of BGP that they are using (generally v4), the Autonomous System number (AS), the number of BGP messages sent and received (MsgSent, MsgRcvd), the table version (TblVer), etc.
Shows all configured capture-filters, including static capture-filters that exist as part of the configuration as well as dynamic capture-filters (i.e., those created using the create capture-filter command).
This command returns the current candidate configuration on the 128T router (i.e., the configuration that is currently being edited, not the configuration that is actively running). The output from show config candidate will only show fields and values within the configuration that are set to non-default values, for brevity.
The show config candidate command has two optional flags: verbose and flat. Adding the verbose flag will show the entire configuration, including items that are part of the system's default configuration (normally hidden when using show config candidate by itself). Adding the flat flag will output the configuration as a series of individual, fully qualified configuration statements, which can singularly affect each component of the configuration discretely. That is, any of the lines can be used without any context to configure a single attribute, object, etc.
Note that the output from show config candidate is formatted in such a way so as to allow the text to be cut and pasted into a CLI session to configure a separate 128T router.
admin@labsystem1.fiedler# show config candidate config authority router Fabric128 name Fabric128 node labsystem1 name labsystem1 id 1 description "Primary lab system" location "Newton, MA" role combo device-interface 1 id 1 description "external network" type ethernet pci-address 0000:02:00.0 ...
The same configuration using the flat flag is displayed quite differently:
The show config candidate command also lets users show specific portions of the configuration by specifying the path to the areas of interest. For multiple instance items, such as node, service, etc., a keyword all will display all items of the specified type:
admin@labsystem1.fiedler# show config candidate authority session-type verbose all config authority session-type HTTP name HTTP service-class Standard timeout 7200000 transport tcp protocol tcp port-range 80 start-port 80 exit port-range 8080 start-port 8080 exit exit exit ...
This command lists the set of exported configurations that are stored on your SSR router.
The show config exports command has two optional flags: name and flat. Use the name flag to identify a specific configuration to display. Adding the flat flag will output the configuration as a series of individual, fully qualified configuration statements.
This command returns the current running configuration on the 128T router (i.e., the configuration that is active and processing traffic). The output from show config running will only show fields and values within the configuration that are set to non-default values, for brevity.
The show config running command has two optional flags: verbose and flat. Adding the verbose flag will show the entire configuration, including items that are part of the system's default configuration (normally hidden when using show config running by itself). Adding the flat flag will output the configuration as a series of individual, fully qualified configuration statements, which can singularly affect each component of the configuration discretely. That is, any of the lines can be used without any context to configure a single attribute, object, etc.
Note that the output from show config running is formatted in such a way so as to allow the text to be cut and pasted into a CLI session to configure a separate 128T router.
admin@labsystem1.fiedler# show config running config authority name Authority128 router Fabric128 name Fabric128 description "Default router" inter-node-security internal ...
The show config running command also lets users show specific portions of the configuration by specifying the path to the areas of interest. For multiple instance items, such as node, service, etc., a keyword all will display all items of the specified type:
admin@labsystem1.fiedler# show config running authority service-class verbose all config authority service-class Standard name Standard dscp 0 priority 0 rate-limit false max-flow-rate 0 max-flow-burst 0 exit service-class NetworkControl name NetworkControl dscp 48 priority 0 rate-limit false max-flow-rate 0 max-flow-burst 0 exit ...
This command displays the version number of the running configuration on the SSR router. This version number is auto-generated, and is the UNIX timestamp when the configuration is committed. (As a consequence, you should expect that successive commits to the same configuration will increment the version by more than one. This is a change in behavior from pre-2.0 software, which used a monotonically incrementing integer to represent the configuration version.)
admin@labsystem1.fiedler# show config version Fri 2017-02-24 09:34:43 EST Version 1487780689 committed at: Wed 2017-02-22 11:24:49 Completed in 0.17 seconds
The show context stats start-time subcommand shows the stats start-time (if set), or indicates that there is no start-time currently set. For more information on setting stats start-time, please refer to set context in this manual.
admin@cnd1.conductor# show context stats start-time No stats start time set, show stats will be relative to launch time admin@cnd1.conductor# set context stats start-time "December 25, 2017" Stats start time set to: 2017-12-25 00:00:00 admin@cnd1.conductor# show context stats start-time Stats start time set to: 2017-12-25 00:00:00 admin@cnd1.conductor# clear context stats start-time Success admin@cnd1.conductor# show context stats start-time No stats start time set, show stats will be relative to launch time
This command displays detailed information about device interface(s) (i.e., physical ports) on an SSR router node. The optional command line arguments allow a user to reduce the set of information to a specific set of interfaces on a given node, or a specific interface on a specific node.
Omitting all optional arguments will display detailed information on all device interfaces defined within the SSR router.
admin@gouda.novigrad# show dhcp mappings Wed 2020-04-22 15:05:25 UTC Node: gouda ================= ================== ====== ============== ================ ============= Src Device Port Dest Device Port VLAN Mapping Type IP Family Type Config Type ================= ================== ====== ============== ================ ============= 1 252 0 originating ipv4 server 2 0 0 originating ipv4 client 252 1 0 derived ipv4 server Completed in 0.05 seconds
Shows all hostnames that require DNS resolution. Hostnames can be specified throughout the configuration; commonly defined on the network-interface and within a service.
admin@gouda.novigrad# show dns resolutions Wed 2020-04-22 14:31:54 UTC ========== ======= ========================= ========== ====================== ====================== Router Node Hostname Resolved Last Resolved Expiration ========== ======= ========================= ========== ====================== ====================== novigrad gouda my.host.name Y 2020-04-22T14:30:43Z 2020-04-22T14:34:43Z Completed in 0.02 seconds
Specifying the argument detail provides additional information
admin@gouda.novigrad# show dns resolutions detail Wed 2020-04-22 14:43:43 UTC ============================================= Node: gouda.novigrad ============================================= Router: novigrad Node: gouda DNS Resolution: Hostname: my.host.name Resolved: Y IPv4 Address: 1.2.3.4 Last Resolved: 2020-04-22T14:42:44Z Expiration: 2020-04-22T14:46:44Z Completed in 0.10 seconds
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 display entitlement utilized. Conductor routers will show the entitlement utilized per project of all conducted routers. (default: <current router>)
The SSR Networking Platform calculates the Peak Router Bandwidth Capacity; this is the highest router bandwidth value of any 5 second interval over the specific license period. The Router Bandwidth is calculated based on the aggregate of sessions traversing the router.
Display configuration with full paths on each line instead of as a hierarchy. Only applicable for 'admin.running_config_change' events.
force
Skip confirmation prompt. Only required when targeting all routers
from
Only show events after the provided time. Can either be a timestamp or a delta, such as 45m, 1d, or 1mo [type: timestamp] (default: 1970-01-01 00:00:00)
limit
The total number of events to retrieve [type: int]
resource-group
The name of the resource group
router
The name of the router for which to display events (default: <current router>)
rows
The number of events to display at once [type: int or 'all'] (default: 50)
to
Only show events before the provided time. You can use the provided standard timestamps, such as 45m, 1d, or 1mo; or enter a value [type: timestamp]
The show events command displays various event records that the SSR collects during operation.
The output can be optionally restricted to specific time windows using the from and to qualifiers. Because this command can generate a lot of output, the rows limiter is particularly useful on busy systems.
Categories can be enabled or disabled individually in config > authority > router > audit. There are five main top-level categories that can be filtered using the type argument.
admin: A catch-all category for events that are triggered by a user's action.
alarm: A historical record of 'show alarms' including a unique event each time an alarm was created and cleared.
system: A catch-all category for events that the system creates itself.
traffic: A record of whether traffic was allowed or denied. By default this is disabled.
provisioning: A historical record of show assets including unique events for each internal state transition.
Additional filtering can be done by specifying a dot (.) followed by a subtype. For example, type admin.running_config_change will only show configuration change events, while type system.ntp_adjustment will only display NTP adjustment events.
The output can be optionally restricted to specific time windows using the from and to qualifiers. Because this command can generate a lot of output, the rows and limit limiters are particularly useful on busy systems.
user@labsystem1.fiedler> show events alarm Fri 2017-07-21 11:59:51 EDT =================== ============ ====================== ========== Node Event Type Time Severity ... =================== ============ ====================== ========== labsystem1 clear 2017-07-21T15:24:04Z major labsystem1 clear 2017-07-21T15:24:04Z major labsystem1 add 2017-07-21T15:23:59Z major labsystem2 add 2017-07-21T15:23:59Z major labsystem2 clear 2017-07-21T15:23:19Z major labsystem1 clear 2017-07-21T15:23:19Z major labsystem1 clear 2017-07-21T15:23:19Z major labsystem1 clear 2017-07-21T15:23:19Z major labsystem1 add 2017-07-21T15:23:14Z major Completed in 0.11 seconds
This command shows the Forwarding Information Base (FIB) entries on the node that is specified by the node-name argument. The output may be limited to a specified number of rows by adding the optional rows modifier at the end of the command.
This command can generate a large quantity of output on a busy system, and it is advised that administrators exercise caution when issuing this command without the rows modifier.
This command shows the Forwarding Information Base (FIB) entries on the node that is specified by the node-name argument. The output may be limited to a specified number of rows by adding the optional rows modifier at the end of the command.
This command can generate a large quantity of output on a busy system, and it is advised that administrators exercise caution when issuing this command without the rows modifier.
admin@gouda.novigrad# show history 1 show run 2 show config running 3 quit 4 shell ... 465 show ntp 466 show network-interface 467 show network-interface wan-interface 468 show network-interface name wan-interface 469 show network-interface application 470 show history
The show load-balancer command provides feedback on the SSR router's load balancing behavior, when configured to balance traffic (via a service-policy).
This command, when issued without any filters (agent, node, or service) will display all agents, nodes, and services that are subject to load balancing. (The output can be quite verbose.) These filters may be combined to "hone in" on specific agents/nodes/services selectively.
This command is extremely helpful for identifying why the SSR router selected specific destinations for its session-oriented traffic.
The show network-interface, a counterpart to show device-interface, shows information and statistics relevant to the logical interfaces configured on your SSR networking platform.
The show network-interface command will show router, node, and device names, as well as the network-interface name and basic information about each interface.
The command show network-interface application can be used to display information regarding DHCP client reservations when running a DHCP server on the respective network-interface.
The show ntp subcommand displays properties of the NTP (Network Time Protocol) process running on the local node, or on the node specified as the optional <node‑name> parameter passed on the command line.
admin@combo-east.ComboEast# show ospf Fri 2020-04-17 19:11:06 UTC =========== ============ ========== ============= ==================== ========= =========== ============= Router Router ID ABR Type ASBR Router External LSA Count Area ID Area Type Area Border Router =========== ============ ========== ============= ==================== ========= =========== ============= ComboEast 172.16.4.2 cisco true 1 0.0.0.0 ComboEast 172.16.4.2 cisco true 1 0.0.0.1 normal Completed in 0.35 seconds
Specifying the argument detail provides additional information
admin@combo-east.ComboEast# show ospf detail Fri 2020-04-17 19:11:14 UTC ==================================================== Router: ComboEast ==================================================== Router ID: 172.16.4.2 Deferred Shutdown: 0.0 s RFC1583 Compatible: false Stub Advertisement Enabled: false Opaque Capable: false Post-Start Enabled: 0.0 s Pre-Shutdown Enabled: 0.0 s SPF Schedule Delay: 0.0 s Holdtime Minimum: 50 ms Holdtime Maximum: 5000 ms Holdtime Multiplier: 1 SPF Last Executed: 4m 16s ago SPF Last Duration: 0 ms SPF Has Not Run: false SPF Timer Due: 0.0 s LSA Minimum Interval: 5.0 s LSA Minimum Arrival: 1.0 s Write Multiplier: 20 Refresh Timer: 10.0 s ABR Type: cisco ASBR Router: true External LSA Count: 1 External LSA Checksum: 0x00004aa4 Opaque AS LSA Count: 0 Opaque AS LSA Checksum: 0x00000000 Attached Area Count: 2 Adjacency Changes Logged: false Adjacency Changes Logged (all): false Area: Area ID: 0.0.0.0 Backbone: true Interface Total Count: 1 Interface Active Count: 1 Fully Adjacent Neighbor Count: 1 Authentication: none Passing Fully Virtual Adjacencies: 0 SPF Executed Count: 8 LSA Count: 5 LSA Router Count: 2 LSA Router Checksum: 0x00019ad4 LSA Network Count: 1 LSA Network Checksum: 0x0000f755 LSA Summary Count: 2 LSA Summary Checksum: 0x0000f3ad LSA ASBR Count: 0 LSA ASBR Checksum: 0x00000000 LSA NSSA Count: 0 LSA NSSA Checksum: 0x00000000 LSA Opaque Link Count: 0 LSA Opaque Link Checksum: 0x00000000 LSA Opaque Area Count: 0 LSA Opaque Area Checksum: 0x00000000 Area: Area ID: 0.0.0.1 Area Type: normal Backbone: false No Summaries: false Shortcutting Mode: default S-bit Concensus: true Interface Total Count: 1 Interface Active Count: 1 Fully Adjacent Neighbor Count: 0 Authentication: none Passing Fully Virtual Adjacencies: 0 SPF Executed Count: 3 LSA Count: 3 LSA Router Count: 1 LSA Router Checksum: 0x000042bc LSA Network Count: 0 LSA Network Checksum: 0x00000000 LSA Summary Count: 2 LSA Summary Checksum: 0x00014c4b LSA ASBR Count: 0 LSA ASBR Checksum: 0x00000000 LSA NSSA Count: 0 LSA NSSA Checksum: 0x00000000 LSA Opaque Link Count: 0 LSA Opaque Link Checksum: 0x00000000 LSA Opaque Area Count: 0 LSA Opaque Area Checksum: 0x00000000 Completed in 0.29 seconds
admin@combo-east.ComboEast# show ospf interfaces Fri 2020-04-17 19:29:52 UTC ============= ================== =========== ======== ============ =========== ========= =========== Router Name Device Interface Network Status IP Address OSPF Type Area ID Area Type Interface ============= ================== =========== ======== ============ =========== ========= =========== ComboEast 10 intf10 up 172.16.1.2 Peer 0.0.0.1 normal /24 ComboEast 11 intf11 up 172.16.3.2 Peer 0.0.0.0 normal /24 Completed in 0.37 seconds
Specifying the argument detail provides additional information
admin@combo-east.ComboEast# show ospf interfaces detail Fri 2020-04-17 19:30:06 UTC =============================================== Router: ComboEast =============================================== Interface: Device Interface: 10 Network Interface: intf10 Interface Index: 3 Status: up MTU Size: 1500 bytes Bandwidth: 10 Mbps OSPF Enabled: true OSPF Running: false Flags: - UP - BROADCAST - RUNNING - MULTICAST Address: IP Address: 172.16.1.2/24 Broadcast IP Address: unavailable Unnumbered Interface: false V-Link Peer: unavailable MTU Mismatch Detection: false Router ID: 172.16.4.2 OSPF Type: Peer OSPF State: DR Area ID: 0.0.0.1 Area Type: normal Network Type: BROADCAST Cost: 10 Transmit Delay: 1.0 s Priority: 1 BDR ID: unavailable BDR Address: unavailable LSA Sequence: 0x00000000 Multicast Member (All): true Multicast Member (DR): true Timer Hello: 0.1 s Timer Dead: 0.025 s Timer Wait: 0.025 s Timer Retransmit: 0.2 s Timer Hello Due: 6.981 s Timer Passive: false Neighbor Count: 0 Adjacent Neighbor Count: 0 Interface: Device Interface: 11 Network Interface: intf11 Interface Index: 4 Status: up MTU Size: 1500 bytes Bandwidth: 10 Mbps OSPF Enabled: true OSPF Running: false Flags: - UP - BROADCAST - RUNNING - MULTICAST Address: IP Address: 172.16.3.2/24 Broadcast IP Address: unavailable Unnumbered Interface: false V-Link Peer: unavailable MTU Mismatch Detection: false Router ID: 172.16.4.2 OSPF Type: Peer OSPF State: Backup Area ID: 0.0.0.0 Area Type: normal Network Type: BROADCAST Cost: 10 Transmit Delay: 1.0 s Priority: 1 BDR ID: 172.16.4.2 BDR Address: 172.16.3.2 LSA Sequence: 0x00000000 Multicast Member (All): true Multicast Member (DR): true Timer Hello: 0.1 s Timer Dead: 0.025 s Timer Wait: 0.025 s Timer Retransmit: 0.2 s Timer Hello Due: 1.85 s Timer Passive: false Neighbor Count: 1 Adjacent Neighbor Count: 1 Completed in 0.32 seconds
admin@combo-east.ComboEast# show ospf neighbors Fri 2020-04-17 19:30:22 UTC ============= ==================== ========== ======= ==================== =================== =========== Router Name Neighbor Router ID Priority State Dead Timer Due (s) Interface Address Interface State ============= ==================== ========== ======= ==================== =================== =========== ComboEast 172.16.4.3 1 Full 31.302 172.16.3.2 DR Completed in 0.32 seconds
Specifying the argument detail provides additional information
admin@combo-east.ComboEast# show ospf neighbors detail Fri 2020-04-17 19:30:36 UTC ============================================================== Router: ComboEast ============================================================== Neighbor: Neighbor Router ID: 172.16.4.3 Priority: 1 State: Full Dead Timer Due: 37.832 s Interface Address: 172.16.3.2 Device Interface: 11 Network Interface: intf11 Interface State: DR Area ID: 0.0.0.0 Area Type: normal Database Summary List Count: 0 LSA Request List Count: 0 LSA Retransmission List Count: 0 State Change Count: 6 changes Last Progressive Change: 35m 52s ago Last Regressive Change: never Last Regressive Change Reason: NoEvent Designated Router ID: 172.16.3.3 Backup Designated Router ID: 172.16.3.2 Options: - E Thread Inactivity Timer: true Thread Database Description Retransmission: false Thread LSA Request Retransmission: true Thread LSA Update Retransmission: true Completed in 0.30 seconds
The show peers command displays properties of each of the "neighboring" SSR routers that the router in question has a peering association with.
This command shows information on peering associations between SSR routers, not peering associations with BGP peers. For information on BGP peering statistics, refer to "show bgp" in this document.
For each peer it shows which interface the peer is reachable via, the destination IP address for which the peer is reached, the VLAN to use to reach it, and whether the peer is currently "up", "down", or "initializing".
The show platform command displays properties of the underlying platform upon which the SSR software is running. This can assist in finding PCI addresses and MAC addresses for the hardware in the system, as well as disk information, OS information, etc.
admin@labsystem1.fiedler# show platform Mon 2017-02-27 16:00:20 EST ======================================================== labsystem1 ======================================================== ------------------ Memory Information ------------------ Memory: --------------- CPU Information --------------- Type: Pentium (Fill By OEM) Speed: 1.60 Cores: 4 ...
The show rib subcommand displays the contents of the SSR router's Routing Information Base (RIB). This is the complete list of connected, direct, and learned routes on the system. (Note that the output may be quite verbose.)
When issuing the command without any arguments, the entire RIB is displayed.
admin@labsystem1.fiedler# show rib Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP, P - PIM, A - Babel, > - selected route, * - FIB route C>* 10.0.0.0/16 is directly connected, eth0 C>* 127.0.0.0/8 is directly connected, lo C>* 172.16.1.0/24 is directly connected, 1-10.0 C>* 172.16.2.0/24 is directly connected, 1-11.0 C>* 172.16.3.0/24 is directly connected, dpdk3
When a specific route is given as an argument to the command, more detail is shown for that route:
admin@labsystem1.fiedler# show rib 10.0.0.0/16 summary Routing entry for 10.0.0.0/16 Known via "connected", distance 0, metric 0, vrf 0, best * directly connected, eth0 admin@labsystem1.fiedler#
admin@gouda.novigrad# show rib connected Fri 2020-04-17 18:35:34 UTC Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR, > - selected route, * - FIB route C>* 96.230.191.0/24 is directly connected, g1, 6d05h38m C>* 169.254.127.126/31 is directly connected, g4294967294, 6d05h38m C>* 169.254.128.132/32 is directly connected, g5, 6d05h38m C>* 172.16.0.0/24 is directly connected, g4, 6d05h38m C>* 192.168.0.0/24 is directly connected, g2, 6d05h38m Completed in 0.22 seconds
@combo-east.ComboEast# show rib ospf Fri 2020-04-17 19:10:07 UTC Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR, > - selected route, * - FIB route O 172.16.1.0/24 [110/10] is directly connected, g1, 00:03:46 O>* 172.16.2.0/24 [110/20] via 172.16.3.3, g2, 00:15:15 O 172.16.3.0/24 [110/10] is directly connected, g2, 00:15:25
admin@gouda.novigrad# show rib static Fri 2020-04-17 18:54:38 UTC Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR, > - selected route, * - FIB route S>* 1.1.1.1/32 [10/0] is directly connected, g1, 00:00:07 S>* 10.10.10.10/32 [5/0] unreachable (blackhole), 00:01:24 Completed in 0.31 seconds
The show security key-status subcommand displays information and statistics related to the SSR's security rekeying feature. It will indicate the current key index (which will be common among all routers managed by an SSR conductor) and relevant statistics on when the last rekey event occurred, when the next will occur, etc.
The show service command display active service information from the SSR router. This command has multiple service filters allowing target to specific service or services. Output can be displayed in summary or in detail view.
The show service-path command displays active service paths passing through the SSR router. This simplifies troubleshooting, allowing you to determine where sessions belonging to a particular service would egress. Multiple service filters allow you to target a specific service or services. Output can be displayed as a summary or in a detail view with pagination support. When using the detail argument, in-path metrics are managed by the performance monitor when enabled. If the performance monitor is not enabled, the local metrics generated by BFD are used.
show service-path Service Service-route Type Destination Next-Hop Interface Vector Cost Rate Capacity State Web web-route1 service-agent 4.4.4.4 1.1.1.2 lan red 10 1 200/3000 Up* Web web-route1 service-agent 4.4.4.4 1.1.1.3 lan red 10 1 200/3000 Up Web web-route2 service-agent 5.5.5.5 2.2.2.2 lan blue 20 2 50/unlimited Down Login <None> BgpOverSVR 10.1.1.1 1.2.3.4 wan red 10 3 - Up Login <None> BgpOverSVR 11.1.1.1 1.2.3.4 wan red 10 1 - Up App1 <None> Routed - - - - - - - - App1 learned-routed Routed - - - - - - - -
The show sessions command displays active sessions passing through the SSR router (or the node specified by the optional node-name argument. The output from the command shows the sessions internal ID (useful for searching through log files), the service, tenant, and source/destination IP information for each active session.
The NAT IP and Port fields will be populated whenever a session is subject to source NAT (see source-nat later in this reference guide for more information). It also shows the timeout value that will cause the session to expire if it remains idle for that number of seconds.
Various services and tenants may display with surrounding braces to indicate that these are internally-generated services and tenants. These internal services and tenants are created when peering between adjacent nodes, establishing BGP sessions, BFD sessions, etc.
info
The contents of the table will vary based upon the software version in use. This applies when, for example, a conductor running a new software version requests session table data from routers running older software versions.
The top bandwidth subcommand will list, in order, the top ten highest consumers of bandwidth among all active sessions. This is useful to understand the current utilization on your SSR network resources.
The show system subcommand displays overall system health for the nodes that comprise your SSR router. It includes the state of the node ("starting" is displayed when the node is in the process of starting up and is not yet ready for handling traffic, "running" means the node is active, "offline" means the node is configured but not currently present), its role, software version, and uptime.
The connectivity subcommand displays the state of all connected systems. On an SSR Conductor, this is a convenient way to display all of the nodes that are connected, disconnected, or "unconfigured". (Note: when a node appears as unconfigured, it means that it is attempting to connect to the SSR conductor, but that conductor does not have any supporting configuration to supply to it.)
The internal subcommand of show system connectivity internal will report all interprocess connections that are currently available on the system, as well as connections between a router and conductor (if applicable).
The processes subcommand will list the processes for all nodes in the cluster, and which processes on which nodes are considered leaders (from a high availability standpoint).
The registry subcommand shows the processes/services that have registered with the local system's "SSC" (system services coordinator). On an SSR Conductor, this will show all of the connected routers_ registered system processes/services.
Most SSR processes are under the control of a process aptly named the processManager. Some services must exist outside of the control of the processManager and are instead goverened by Linux's systemd. show system services displays a table summarizing statuses of SSR systemd services.
admin@tp-cond-primary.tp-cond# show system services Wed 2020-04-15 20:41:18 UTC ========================= ============================== ============== Node Service Active State ========================= ============================== ============== tp-cond-primary.tp-cond 128T-plugin-adapter.service active tp-cond-primary.tp-cond 128TWeb.service active tp-cond-primary.tp-cond 128TWebAuth.service active tp-cond-primary.tp-cond auditd.service active tp-cond-primary.tp-cond mars.service active tp-cond-primary.tp-cond prank.service active tp-cond-primary.tp-cond t128-process-metrics.service active tp-cond-primary.tp-cond tank.service active Completed in 0.11 seconds
The show tenant subcommand displays the mapping logic that the SSR router uses for associating the source IP address of inbound requests to tenant definitions – whether they be interface-based (i.e., a tenant has been configured on a network-interface) or member based (i.e., a prefix has been configured within a neighborhood).
admin@gouda.novigrad# show tenant members Wed 2020-04-15 19:10:00 UTC Node: gouda ============ ========= =================== ================ =================== ==================== ============= Device I/F VLAN ID Network I/F Network I/F IP Source IP Prefix Tenant Source Type ============ ========= =================== ================ =================== ==================== ============= lan 0 lan-interface 192.168.0.2 192.168.0.0/24 lanSubnet PUBLIC lan 0 lan-interface 192.168.0.2 192.168.0.32/32 MBP.lanSubnet PUBLIC lan 3000 lan-untrusted 172.16.0.1 0.0.0.0/0 untrustedLanSubnet PUBLIC wan 0 wan-interface 96.230.191.130 35.156.0.0/14 blocklist PUBLIC wan 0 wan-interface 96.230.191.130 217.0.0.0/8 blocklist PUBLIC wan 0 wan-interface 96.230.191.130 218.0.0.0/8 blocklist PUBLIC dh00000001 0 dhcp-server-gen-2 169.254.128.132 0.0.0.0/0 <global> PUBLIC kni254 0 controlKniIf 169.254.127.126 0.0.0.0/0 _internal_ PUBLIC wan 0 wan-interface 96.230.191.130 220.0.0.0/8 blocklist PUBLIC wan 0 wan-interface 96.230.191.130 222.0.0.0/8 blocklist PUBLIC Completed in 9.01 seconds
An SSR router may need to transform TCP packets into UDP packets to enable SVR to traverse stateful firewalls. By default, the SSR router runs a firewall detector process over peer paths, and will dynamically enable UDP transform when necessary. (Administrators may also elect to enable UDP transform if they know there are stateful firewalls in the path.) This command shows whether a path has UDP transform enabled, and if so, which firewall detection tests triggered the feature to be enabled.
The show user subcommand displays the attributes for the specified user account (i.e., whether the account is enabled, the user's full name, and their role).
admin@labsystem1.fiedler# show user jdeveloper ============================= Information for jdeveloper: ============================= Enabled: true Full Name: Joe Developer Role: admin admin@labsystem1.fiedler#
If the 128T is configured to obtain user accounts from LDAP, the connectivity status of the LDAP server is displayed at the end of the output.
admin@labsystem1.fiedler# show user all ============== ====================== ======= =============== ========= Username Full Name Roles Features Enabled ============== ====================== ======= =============== ========= admin admin configure true user user user show-commands true jdeveloper Joe Developer admin configure true LDAP server is configured and online
Provides details about all configured VRF’s including name, tenants, network-interfaces, and routing-interfaces in each VRF. Use to verify whether the configuration was specified correctly and resulted in the desired VRF state.
This command will force a network element (or group of network elements) to synchronize any dynamically-learned IP addresses to its conductor. (The conductor will redistribute these dynamic addresses to other members of the Authority as necessary.)
When time preceeds another command, it will provide the total amount of wall clock time it takes for the operation to complete. Natively not all PCLI commands output the duration it takes to complete the operation. The time command, much like the Linux version, provides this information.
Are you sure you want to commit the candidate config? [y/N]: y ✔ Validating, then committing... Configuration committed admin@gouda.novigrad# time commit Wed 2020-04-15 15:50:26 UTC Are you sure you want to commit the candidate config? [y/N]: y ✔ Validating, then committing... Configuration committed Completed in 4.86 seconds
This command validates the current candidate configuration to check for referential integrity among the various configuration objects, to check for the use of deprecated configuration elements, and to supply warnings when various configuration elements cannot be validated.
Many configuration elements within the SSR router refer to other configuration elements by their name. If an administrator mistypes a name, or a referenced object is deleted without updating the source of that reference, this candidate configuration is said to be invalid. By using the validate command, administrators can ensure their configuration is valid prior to committing it to be the running configuration.
note
Validation occurs automatically whenever the commit command is run; this standalone
command allows administrators to check for validity without requiring that the
configuration is committed immediately.
The validate command provides warnings when a configuration contains deprecated elements - elements that are scheduled for removal in a future release of the SSR software. This is to give administrators the opportunity to replace the impacted configuration stanzas with their replacement.
The validate command will also provide warnings when a configuration cannot be validated and requires administrative oversight.
When validation fails, the administrator is notified via output to the CLI. The output from the validate command will identify the configuration that is failing validation.
When run from an SSR conductor, the conductor only validates the configuration itself locally. 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. 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 executing validate router all.
note
validation occurs automatically whenever the commit command is run; this standalone command allows administrators to check for validity without requiring that the configuration is committed immediately.
This command returns the user's current position within the CLI hierarchy. When executed from the main CLI prompt, it returns nothing. When executed from within the configuration tree, it returns the user's current position within the tree.
admin@labsystem1.fiedler# where admin@labsystem1.fiedler# conf auth router newton admin@labsystem1.fiedler (router[name=newton])# where configure authority router newton admin@labsystem1.fiedler (router[name=newton])#
The write log message command lets administrators write messages into log files; this is typically used as a marker during troubleshooting exercises, to insert a string that can later be located to reference the onset of a test.
admin@labsystem1.fiedler# write log message "---- starting test here ----" Log message successfully written admin@labsystem1.fiedler#
This message will appear in the log files with the category type "USER", as is demonstrated here:
[admin@labsystem1 ~]$ tail -n 5 /var/log/128technology/stateMonitor.log "message" : "No connectivity to labsystem5.burlington", "value" : "2" }} Total alarms for node: 0 Mar 13 14:14:38.345 [USER| -- ] INFO (stateMonitPoller) ---- starting test here ---- [admin@labsystem1 ~]$
The write log snapshot command is debugging tool that outputs zookeeper state information related information to each respective process that utilizes zookeeper.