7.2.0 release documentation

docs/cert_validation_requirements.md

@@ -8,6 +8,7 @@ sidebar_label: Certificate Requirements and Validation
 | Release | Modification                |
 | ------- | --------------------------- |
 | 7.0.0   | Certificate management and validation support added. |
+| 7.2.0   | Subject Alternative Name URI support for peering identity. |
 
 This page describes the certificate properties that the SSR enforces, how `validation-mode` affects behavior, and the differences between config-time and runtime validation.
 
@@ -112,6 +113,7 @@ Client certificates used for peering are validated as leaf (end-entity) certific
 | --- | --- |
 | Signature Algorithm | Must be an [accepted algorithm](#accepted-cryptographic-algorithms). |
 | Public Key | Must be an [accepted key type and size](#key-requirements). |
+| Subject Alternative Name (optional) | Starting in SSR 7.2.0, a `urn:ssr:peering:<alias>` SAN URI can be used to carry SVR peering identity as an alternative to the Common Name. See [Enhanced Security Key Management — API Naming Rules](sec_enhanced_key_mgmt.md#api-naming-rules) for details. |
 
 ### Intermediate CA Certificates
 

docs/concepts_machine_communication.md

@@ -87,7 +87,9 @@ Peering SSR routers will perform path MTU discovery on each peer path between ea
 
 In order to accommodate these deployments where “ICMP Destination Unreachable - Fragmentation Needed” response messages are not generated (RFC1911 is not followed), three successive non-responses are considered equivalent to ICMP responses for the purposes of driving the algorithm with an inferred MTU.
 
-The discovered MTU is viewable in the output of `show peers`.
+The discovered MTU is viewable in the output of `show peers`. 
+
+For additional information, see [Path MTU Discovery](config_pmtu.mdx).
 
 ### Secure Vector Routing Traffic
 

docs/config_bgp.md

@@ -1037,3 +1037,148 @@ admin@branchoffice1.seattlesite1 (routing-protocol[type=bgp])# confederation mem
 admin@branchoffice1.seattlesite1 (routing-protocol[type=bgp])# confederation member-as 2200
 admin@branchoffice1.seattlesite1 (routing-protocol[type=bgp])# exit
 ```
+
+## Viewing Filtered BGP Routes
+
+When an inbound BGP policy rejects prefixes received from a neighbor, those routes do not appear in the BGP table or the FIB. The `filtered-routes` option exposes exactly which prefixes were suppressed by the inbound policy for a given neighbor, making it straightforward to troubleshoot why expected routes are absent from the routing table.
+
+:::note
+This feature is available in SSR version 7.2.0-r1 and above.
+:::
+
+### PCLI
+
+The `filtered-routes` option is available as a third choice alongside `received-routes` and `advertised-routes` in the `show bgp neighbors` command:
+
+```
+show bgp neighbors [vrf <vrf_name>] <neighbor_ip> filtered-routes [ipv4 | ipv4-vpn | ipv6 | ipv6-vpn]
+```
+
+**Examples**
+
+Display filtered routes for a neighbor in the default VRF using IPv4 unicast (the default address family):
+
+```text
+admin@router1.site1# show bgp neighbors 172.16.3.3 filtered-routes
+```
+
+Display filtered IPv6 routes for a neighbor in a named VRF:
+
+```text
+admin@router1.site1# show bgp neighbors vrf vrfA fd00:5::3 filtered-routes ipv6
+```
+
+When no routes have been filtered, the command returns an empty table. When routes are present, the output format mirrors that of `received-routes` and `advertised-routes`. If the neighbor address is unknown, the VRF does not exist, or the address family is invalid, the PCLI surfaces the underlying error string describing the problem.
+
+### REST API
+
+A new endpoint mirrors the PCLI functionality:
+
+```
+GET /api/v1/routing/bgp/neighbors/filtered-routes
+```
+
+**Query Parameters**
+
+| Parameter | Required | Default | Description |
+|---|---|---|---|
+| `neighborAddress` | Yes | — | IP address of the BGP neighbor |
+| `vrf` | No | `default` | VRF name |
+| `addressFamily` | No | `ipv4` | Address family: `ipv4`, `ipv4-vpn`, `ipv6`, or `ipv6-vpn` |
+| `firstIndex` | No | `0` | Zero-based starting index for paginated results |
+| `elementCount` | No | all | Maximum number of routes to return (range: 1–5000) |
+
+:::note
+The REST endpoint does not support `vrf all` or `addressFamily all`. Each VRF and address family must be queried individually.
+:::
+
+**Example: IPv4, default VRF**
+
+```bash
+curl --unix-socket /var/run/128technology/speakeasy.sock -i -XGET \
+  'http://localhost/api/v1/routing/bgp/neighbors/filtered-routes?neighborAddress=172.16.3.3&firstIndex=0&elementCount=1'
+```
+
+Response:
+
+```json
+{
+  "bgpTableVersion": 14,
+  "bgpLocalRouterId": "2.1.1.1",
+  "defaultLocPrf": 100,
+  "localAS": 2,
+  "bgpStatusCodes": {
+    "suppressed": "s", "damped": "d", "history": "h",
+    "valid": "*", "best": ">", "multipath": "=",
+    "internal": "i", "ribFailure": "r", "stale": "S", "removed": "R"
+  },
+  "bgpOriginCodes": { "igp": "i", "egp": "e", "incomplete": "?" },
+  "filteredRoutes": [
+    {
+      "prefix": "10.99.1.0/24",
+      "network": "10.99.1.0/24",
+      "nextHop": "172.16.3.2",
+      "metric": 0,
+      "weight": 0,
+      "path": "3",
+      "bgpOriginCode": "?",
+      "valid": true,
+      "best": true
+    }
+  ],
+  "totalPrefixCounter": 1,
+  "filteredPrefixCounter": 0,
+  "nextEntry": 1
+}
+```
+
+**Example: IPv6, named VRF**
+
+```bash
+curl --unix-socket /var/run/128technology/speakeasy.sock -i -XGET \
+  'http://localhost/api/v1/routing/bgp/neighbors/filtered-routes?neighborAddress=fd00:5::3&firstIndex=0&elementCount=1&addressFamily=ipv6&vrf=vrfA'
+```
+
+Response:
+
+```json
+{
+  "bgpTableVersion": 1,
+  "bgpLocalRouterId": "2.1.1.1",
+  "defaultLocPrf": 100,
+  "localAS": 2,
+  "filteredRoutes": [
+    {
+      "prefix": "2001:db8:5::1/128",
+      "network": "2001:db8:5::1/128",
+      "nextHopGlobal": "fd00:5::3",
+      "metric": 0,
+      "weight": 0,
+      "path": "3",
+      "bgpOriginCode": "?",
+      "valid": true,
+      "best": true
+    }
+  ],
+  "totalPrefixCounter": 1,
+  "filteredPrefixCounter": 0,
+  "nextEntry": 1
+}
+```
+
+### Troubleshooting
+
+| Failure | PCLI behavior | REST behavior |
+|---|---|---|
+| `bgpd` not running | Surfaces vty error string | Returns standard upstream failure with informative status code |
+| Unknown neighbor IP, neighbor not in specified VRF/address family | Surfaces vty error string with neighbor details | Returns `200 OK` with a `warning` key in the JSON body |
+| Invalid `addressFamily` or `vrf` argument | Surfaces vty error string | Returns `200 OK` with a `warning` key in the JSON body |
+| vty call timeout (120 s) | Surfaces timeout error string | Returns `HTTP 400` with timeout exception message |
+
+PCLI and REST activity is logged in `routingManager.log`. FRR vty-level logs are in `routingEngine.log`.
+
+### Version History
+
+| Release | Modification |
+|---|---|
+| 7.2.0 | Feature introduced. |

docs/config_custom_certs.md

@@ -7,7 +7,8 @@ sidebar_label: Configure Certificate Management
 
 | Release | Modification                |
 | ------- | --------------------------- |
-| 7.0.0   | Certificate Management support added. | 
+| 7.0.0   | Certificate Management support added. |
+| 7.2.0   | Subject Alternative Name support added to CSR generation. | 
 
 Security is a critical component of SD-WAN products. The effectiveness of any security strategy relies on the strength of the security algorithm and how related information is exchanged between participants.
 
@@ -51,8 +52,8 @@ The following are some details of certificate security.
 
 ## Provisioning Process
 
-:::important
-It is necessary for all of the REST APIs to use the name `custom_ssr_peering` in order for this private key and certificate to be visible and usable by Enhanced Security Key Management in 7.0. This is a reserved name specifically used by the Enhanced Security Key Management feature.
+:::note Legacy Name
+In SSR 7.0.x, the `name` field in all REST API calls was required to be `custom_ssr_peering` (a reserved name) for ESKM visibility. Starting with SSR 7.1.0, any consistent name may be used. The examples below use `my_peering_cert`.
 :::
 
 :::tip Swagger API Reference
@@ -191,7 +192,7 @@ Create the following file (update algorithm and key size to your preference):
 
 ```
 {
-    "name": "custom_ssr_peering",
+    "name": "my_peering_cert",
     "algorithm": "RSA",
     "rsa_key_size": "2048"
 }
@@ -213,7 +214,7 @@ curl -k -X POST https://10.27.35.89/api/v1/router/combo-east/node/node2/private-
   -d @key_request.json
 ```
 
-Upon success, `ssh` to the target SSR and verify that `/etc/128technology/pki/custom_ssr_peering.key` exists on disk.
+Upon success, `ssh` to the target SSR and verify that `/etc/128technology/pki/my_peering_cert.key` exists on disk.
 
 ### Issue a `certificate-signing-request`
 
@@ -226,11 +227,13 @@ This requirement is lifted starting with SSR 7.1.0.
 :::
 <!---remove this note when 7.0.4 is released and the restriction is lifted for 7.0.x --->
 
-1. Create a file containing the CSR request body. At a minimum provide `name` and a `common_name` that is unique to this router or node:
+1. Create a file containing the CSR request body. At a minimum provide `name` and a `common_name`:
 
 :::important Naming Rules
-- **`name`** must be **the same value across all routers and nodes** — `custom_ssr_peering` in SSR 7.0.x (reserved). This is the authority-wide identifier required for ESKM visibility.
-- **`common_name`** must be **unique per router/node** and must **exactly match** that router's configured `peering-common-name`. Using the wrong `common_name` will cause ESKM peer authentication to fail.
+- **`name`** must be **the same value across all routers and nodes**. In SSR 7.1+, any consistent name may be used.
+- **`common_name`** must be **unique per router/node**. It must match that router's configured `peering-common-name` — either directly, or via a `urn:ssr:peering` SAN URI in the certificate (SSR 7.2.0+).
+
+For full details on SAN URI peering identity, see [Enhanced Security Key Management — API Naming Rules](sec_enhanced_key_mgmt.md#api-naming-rules).
 
 Example mapping for a two-router deployment:
 
@@ -240,15 +243,27 @@ Example mapping for a two-router deployment:
 | combo-west | `west-alias` | `west-alias` |
 :::
 
-**csr_request.json**
+**csr_request.json** (minimum):
 
 ```
 {
-    "name": "custom_ssr_peering",
+    "name": "my_peering_cert",
     "common_name": "east-alias"
 }
 ```
 
+**csr_request.json** (with Subject Alternative Name URI for HA):
+
+```json
+{
+    "name": "my_peering_cert",
+    "common_name": "combo-east-node1",
+    "subject_alt_names": [
+        {"type": "urn_ssr_peering", "value": "east-alias"}
+    ]
+}
+```
+
 This example represents the minimum requirements. Any of the following additional details may be added to the request:
 
 - country_name (string, optional): The country name.
@@ -261,6 +276,12 @@ This example represents the minimum requirements. Any of the following additiona
 - rsa_key_size (integer, optional): The RSA key size. Only valid when algorithm is set to “RSA”. Valid key sizes are any multiple of 256 between 2048 and 4096.
 - ecc_curve (string, optional): The ECC curve to use. Only valid when algorithm is set to “ECC”.Valid curves are: (SECP256R, SECP384R1, SECP521R1)
 - validity_period (integer, optional): The validity period in days.
+- subject_alt_names (array, optional, SSR 7.2.0+): An array of Subject Alternative Name entries to include in the CSR. Each entry is an object with `type` and `value` fields. Supported types:
+  - `dns` — a DNS hostname (e.g., `"example.com"`)
+  - `ip` — an IPv4 or IPv6 address (e.g., `"192.168.1.1"`)
+  - `email` — an email address (e.g., `"admin@example.com"`)
+  - `uri` — a URI (e.g., `"https://example.com"`)
+  - `urn_ssr_peering` — a convenience alias that automatically expands the value to `URI:urn:ssr:peering:<value>`. Use this type to carry the SVRv2 peering identity in the SAN extension.
 
 2. Issue the CSR request to the SSR:
 
@@ -301,7 +322,7 @@ When the signed certificate is returned, instruct the SSR to ingest the certific
 ```
 POST /api/v1/router/{router_name}/node/{node_name}/certificate
 {
-    "name": "custom_ssr_peering",
+    "name": "my_peering_cert",
     "certificate": "-----BEGIN CERTIFICATE-----
 MIIF3DCCBESgAwIBAgIKAf9HQjJKSQd1lTANBgkqhkiG9w0BAQsFADBaMQswCQYD
 VQQGEwJERTERMA8GA1UECgwIT3BlblhQS0kxDDAKBgNVBAsMA1BLSTEqMCgGA1UE
@@ -319,8 +340,8 @@ Once the certificate is successfully ingested, verify that the certificate was a
 
 1. `ssh` to the SSR. 
 2. Log in as the root user: `sudo su`.
-3. Verify that `/etc/128technology/pki/custom_ssr_peering.pem` exists on disk.
-  `ls -l /etc/128technology/pki/custom_ssr_peering.pem`
+3. Verify that `/etc/128technology/pki/my_peering_cert.pem` exists on disk.
+  `ls -l /etc/128technology/pki/my_peering_cert.pem`
 
 ### Activate the Certificate in Configuration
 
@@ -330,9 +351,9 @@ On the Conductor, configure `client-certificate` using the same `name` value use
 
 ```
 config authority
-    client-certificate  custom_ssr_peering
-        name             custom_ssr_peering
-        file             custom_ssr_peering
+    client-certificate  my_peering_cert
+        name             my_peering_cert
+        file             my_peering_cert
         validation-mode  strict
     exit
 exit