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.
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.
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:
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:
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.
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
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 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.
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.
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.
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-backups/ 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.
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:
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.
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.
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.
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.
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.
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.
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.)
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).
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.
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
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.
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:
admin@labsystem1.fiedler# show config candidate flat
config authority router Fabric128 name Fabric128
config authority router Fabric128 node labsystem1 name labsystem1
config authority router Fabric128 node labsystem1 id 1
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
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
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.)
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.
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.
Shows all hostnames that require DNS resolution. Hostnames can be specified throughout the configuration; commonly defined on the network-interface and within a service.
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.
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.
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.
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.
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.
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.
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.
Forward session key: [discriminator 42949672960, tenant seattle-reid.field-eng.corp, peer <unknownPeer>, src ip 172.25.128.59, dest ip 23.45.228.49, src port 38562, dest port 443, proto 6]
Reverse session key: [discriminator 42949672960, tenant seattle-reid.field-eng.corp, peer <unknownPeer>, src ip 23.45.228.49, dest ip 96.93.108.35, src port 443, dest port 61291, proto 6]
State info:
Session state: ESTABLISHED
Redundancy state: SYNCED
Time info:
Start time: 0 days 0:02:00
Ttl duration for database: 1900
Forward flows:
Key: [src ip 172.25.128.59, dest ip 23.45.228.49, src l4 port 38562, dest l4 port 443, proto 6, vlan 6, device port 3]
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.
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).
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).
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.
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.
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.
The write log snapshot command is debugging tool that outputs zookeeper state information related information to each respective process that utilizes zookeeper.