6.3.0 install updates

docs/about_releases.mdx

@@ -24,6 +24,7 @@ Version `6.1.0` introduces changes to the SSR software release model. Every six
 
 | Version | Initial GA Version | First Release Shipping Date | Latest GA Version | End of Software Engineering support | End of Support |
 | --| -- | -- | -- | -- | -- |
+| Release 6.3 | [6.3.0](release_notes_128t_6.3.md) | September 19, 2024 | [6.3.0](release_notes_128t_6.3.md) | June 19, 2025 | March 19, 2026 |
 | Release 6.2 | [6.2.0](release_notes_128t_6.2.md#release-620-39) | November 16, 2023 | [6.2.6](release_notes_128t_6.2.md#release-626-15r2) | November 16, 2025 | May 16, 2026 |
 | Release 6.1 | [6.1.0](release_notes_128t_6.1.md#release-610-55) | April 14, 2023 | [6.1.10](release_notes_128t_6.1.md#release-6110-8) | September 22, 2025 | June 22, 2026 |
 | Release 5.6 | [5.6.7](release_notes_128t_5.6.md#release-567-4) | March 16, 2023 | [5.6.15](release_notes_128t_5.6.md#release-5615-1) | June 16, 2024 | December 16, 2024 |

docs/bcp_per-adjacency_traffic_engineering.md

@@ -1,13 +1,13 @@
 ---
-title: Per Adjacency Traffic Engineering
-sidebar_label: Per Adjacency Traffic Engineering
+title: Adjacency Traffic Engineering
+sidebar_label: Adjacency Traffic Engineering
 ---
 
-Packet loss due to congestion in networks, particularly over WAN links, is inevitable. Depending on where drops occur, it can have a major impact on perceived quality of experience. Packet loss due to exceeding transmit caps between instances of SSR should be avoided. Per-adjacency traffic engineering can be enabled to regulate the upload and download rates between peers.  
+Adjacency traffic engineering can be enabled to regulate the upload and download rates between peers.  
 
 ## Overview 
 
-Per-adjacency traffic engineering provides targeted traffic engineering for both directions on a bandwidth restricted link between two SSR instances. Traffic engineering on the device interface continues to be associated with the upload rate of a connected link; the `transmit-cap`. Traffic engineering at the adjacency level is associated with the download limit of the adjacent SSR instance; the `receive-cap`.  
+Adjacency traffic engineering provides targeted traffic engineering for both directions on a bandwidth restricted link between two SSR instances. While device interface traffic engineering is associated with the upload rate (`transmit-cap`) of a connected link, traffic engineering at the adjacency level is associated with the download limit of the adjacent SSR instance; the `receive-cap`.  
 
 For example, in the following hub and spoke diagram the Datacenter router has 5 adjacencies off of the individual device interface with a `transmit-cap` upload speed configured at 50Mb. The adjacent branch routers have 10Mb, 5Mb, 1Mb, 5Mb, and 2.5Mb configured as their device interface transmit caps. With such a large `transmit-cap` at the Datacenter, traffic rates exceeding the allowed download speeds (10Mb, 5Mb, 1Mb, 5Mb, and 2.5Mb) on each of the paths to the branch routers will result in traffic being dropped by the ISP. 
 
@@ -64,10 +64,48 @@ network-interface foo
     exit
 exit
 ```
+
+### Limitations
+
+Traffic engineering includes a performance impact to the packet-per-second processing rate of the worker cores. When used in conjunction with other traffic engineering settings, performance is further impacted; each level of traffic engineering requires buffering for their scheduled objects. 
+
 ### Gathering Statistics
 
 To gather information about Per-Adjacency Traffic Engineering, query the following statistics using the `show stats traffic-eng device-interface peer-path` command within the CLI. These statistics are specific to the peer-path and provide insight into how the adjacency schedulers are operating.
 
+```
+[email protected]# show stats traffic-eng device-interface peer-path
+Tue 2024-03-19 13:39:58 UTC
+Retrieving statistics...
+
+Peer Path Traffic Engineering Stats
+-----------------------------------
+
+==================================================== ============== ============ ============== ============= ====== ==================
+ Metric                                               Node           Peer-name    Peer-host      Device-name   Vlan              Value
+==================================================== ============== ============ ============== ============= ====== ==================
+ dequeue-cycle-count                                  combo-east-a   combo-west   172.16.102.2   11-red           0   7077545161474020
+ enqueue-cycle-count                                  combo-east-a   combo-west   172.16.102.2   11-red           0   7077545161474020
+ packets-queued                                       combo-east-a   combo-west   172.16.102.2   11-red           0                  0
+ per-traffic-class buffer-capacity-exceeded-bytes     combo-east-a   combo-west   172.16.102.2   11-red           0                  0
+ per-traffic-class buffer-capacity-exceeded-packets   combo-east-a   combo-west   172.16.102.2   11-red           0                  0
+ per-traffic-class dequeue-aqm-drop-bytes             combo-east-a   combo-west   172.16.102.2   11-red           0                  0
+ per-traffic-class dequeue-aqm-drop-packets           combo-east-a   combo-west   172.16.102.2   11-red           0                  0
+ per-traffic-class dequeue-max-latency-drop-bytes     combo-east-a   combo-west   172.16.102.2   11-red           0                  0
+ per-traffic-class dequeue-max-latency-drop-packets   combo-east-a   combo-west   172.16.102.2   11-red           0                  0
+ per-traffic-class dequeue-success-bytes              combo-east-a   combo-west   172.16.102.2   11-red           0           94918726
+ per-traffic-class dequeue-success-packets            combo-east-a   combo-west   172.16.102.2   11-red           0             244021
+ per-traffic-class schedule-failure-bandwidth         combo-east-a   combo-west   172.16.102.2   11-red           0                  0
+ per-traffic-class schedule-failure-bytes             combo-east-a   combo-west   172.16.102.2   11-red           0                  0
+ per-traffic-class schedule-failure-packets           combo-east-a   combo-west   172.16.102.2   11-red           0                  0
+ per-traffic-class schedule-success-bandwidth         combo-east-a   combo-west   172.16.102.2   11-red           0            1201245
+ per-traffic-class schedule-success-bytes             combo-east-a   combo-west   172.16.102.2   11-red           0           94918726
+ per-traffic-class schedule-success-packets           combo-east-a   combo-west   172.16.102.2   11-red           0             244021
+ scheduler-reset                                      combo-east-a   combo-west   172.16.102.2   11-red           0                  0
+```
+
+### Statistics Descriptions
+
 - `enqueue-cycle-count`: The current enqueue cycle count in traffic engineering for this peer path.
 - `dequeue-cycle-count`: The current dequeue cycle count in traffic engineering for this peer path.
 - `packets-queued`: The current number of packets queued in traffic engineering for this peer path.

docs/cc_fips_otp_router_install.md

@@ -108,6 +108,53 @@ When you modify the GRUB kernel behavior by editing the GRUB menu at boot time,
 
 This installation process is an automated workflow which does not require user interaction after selecting and initiating the OTP menu option. The system will power off after installation.
 
+### Enable Strict Host Key Checking 
+
+Enabling strict `host-key-checking` provides secure communication between the conductor and a router. 
+Similar to SSH, there are two `host-key-checking` options; `yes` which requires the host key to be provisioned manually, or `accept-new` which accepts the key on first connection. 
+
+There are two configuration parameters where `host-key-checking` can be set: 
+
+- **`inter-router host-key-checking`** controls host key verification between a router and the conductor. When set to `yes`, strict host key checking is enabled between the router and the conductor. However, the host keys must be manually provisioned on each router. 
+
+ ```
+ config authority router RTR_EAST_COMBO node combo-east-1 ssh-settings inter-router host-key-checking yes
+ config authority router RTR_EAST_COMBO node combo-east-2 ssh-settings inter-router host-key-checking yes
+ ```
+
+- **`inter-node host-key-checking`** controls host key verification between redundant HA nodes. When set to `yes`, strict host key checking is enabled between the router and the conductor **between each node** of an HA router. However, the host keys must be manually provisioned on each router. 
+
+```
+config authority router RTR_EAST_COMBO node combo-east-1 ssh-settings inter-node host-key-checking yes
+config authority router RTR_EAST_COMBO node combo-east-2 ssh-settings inter-node host-key-checking yes
+```
+
+To save the work of manually provisioning the host key on the router, set the `accept-new` parameter. This automatically loads the host key on first connection.
+
+```
+config authority router RTR_EAST_COMBO node combo-east-1 ssh-settings inter-router host-key-checking accept-new
+```
+
+Use the `show system connectivity known-hosts` to view the accepted host keys for the current node.
+
+#### Manual Provisioning of the Conductor Key
+
+If a router is configured for strict `inter-router host-key-checking` (set to `yes`), but **does not** have `accept-new` configured, it will be necessary to manually provision the conductor key **prior** to onboarding the router to the conductor. This will require the administrator to retrieve the host key of each node of the conductor and configure this in the router.
+
+On the conductor, identify the `key` for each node using the command `show system connectivity host-keys node all`.
+
+From the router PCLI, provision each conductor key using the following command:
+`create system connectivity known-hosts node <node> <conductor address> ssh-rsa <key> <comment>`
+
+- `<node>` is the router node. The key should be added on each router node in an HA pair. 
+- `<conductor address>` is the conductor address. This should be added for each conductor address of an HA conductor pair.
+- `<key>` is the `Key` retrieved from the previous step.
+- `<comment>` is an option that can be used to identify the key; for example `Conductor1`.
+
+The following example manually configures the key to the conductor node `192.168.1.13`:
+
+`create system connectivity known-hosts router RTR_EAST_COMBO node combo-east-1 [192.168.1.13]:930 ssh-rsa <public key contents>`
+
 ### Root Access
 To permit root access to the SSR system, ensure that there is at least one user configured on each system with super user (sudo) privileges. Failure to do so may result in the loss of management connectivity to the router. 
 **Logging in as `root` over SSH is not permitted.**