7.2.0 release documentation

docs/_install_interactiveoverview.md

@@ -8,4 +8,4 @@ The steps in this section describe the *interactive conductor installation* from
 The Conductor installation must be completed before installing a Session Smart Router or routers using the ISO. The same ISO is used for both installations.
 :::
 
-To install a router **after** installing and configuring the Conductor, use the [SSR Installation](intro_installation_bootable_media.mdx). The [Router Installation Using OTP](intro_otp_iso_install.mdx) procedure can be used for whitebox and air-gap, conductor-managed network installations. 
+To install a router **after** installing and configuring the Conductor, use the [SSR Installation](intro_installation_bootable_media.mdx). The [Router Installation Using OTP](intro_otp_iso_install.md) procedure can be used for whitebox and air-gap, conductor-managed network installations. 

docs/bcp_att_avpn_configuration.md

@@ -3,8 +3,6 @@ title: AT&T AVPN Configuration
 sidebar_label: AT&T AVPN Configuration
 ---
 
-import Mermaid from '@theme/Mermaid';
-
 This guide is for network engineers and architects using their Session Smart Router to connect to AT&T’s MPLS VPN (AVPN) service. It will cover:
 - Service class definitions for the various COS queues on the AT&T MPLS network
 - Strategies for mapping `service` configuration to the COS queues using `service-policy` elements
@@ -229,37 +227,37 @@ The base class `service-policy` configurations presented here are derived from t
 The SSR uses four traffic engineering queues for prioritizing egress traffic during times of congestion or link contention. The general practice of mapping the `traffic-class` assignments (high, medium, low, best-effort) into the various 6COS queues is shown below.
 
 
-<Mermaid chart={`
-  graph LR
-    voip-audio --> ATT-COS1
-    id1(BFD, BGP) -.-> ATT-control
-    voip-video --> ATT-COS2V
-    video-streaming --> ATT-COS2V
-    voip-signaling --> ATT-COS2
-    data-mission-critical --> ATT-COS2
-    remote-desktop --> ATT-COS2
-    management-interactive --> ATT-COS3
-    management-m2m --> ATT-COS3
-    data-interactive --> ATT-COS3
-    data-best-effort --> ATT-COS4
-    data-scavenger --> ATT-COS5
-    video-streaming-scavenger --> ATT-COS5
-    subgraph best-effort
+```mermaid
+graph LR
+  voip-audio --> ATT-COS1
+  id1(BFD, BGP) -.-> ATT-control
+  voip-video --> ATT-COS2V
+  video-streaming --> ATT-COS2V
+  voip-signaling --> ATT-COS2
+  data-mission-critical --> ATT-COS2
+  remote-desktop --> ATT-COS2
+  management-interactive --> ATT-COS3
+  management-m2m --> ATT-COS3
+  data-interactive --> ATT-COS3
+  data-best-effort --> ATT-COS4
+  data-scavenger --> ATT-COS5
+  video-streaming-scavenger --> ATT-COS5
+  subgraph best-effort
     ATT-COS5
-    end
-    subgraph low
+  end
+  subgraph low
     ATT-COS4
-    end
-    subgraph medium
+  end
+  subgraph medium
     ATT-COS2V
     ATT-COS2
     ATT-COS3
-    end
-    subgraph high
+  end
+  subgraph high
     ATT-COS1
     ATT-control
-    end
-`}/>
+  end
+```
 
 Each AT&T AVPN circuit has a *profile* associated with it (referred to as a "COS Package"), that maps to bandwidth allocations for the various COS queues. These in turn need to be mapped to the four egress traffic engineering queues on the SSR. The COS Package from AT&T is expressed as a set of six numbers (corresponding to the queues), where the first number is the percentage of the circuit bandwidth allocated for COS1, and the remaining five numbers (which sum to 100%) represent the amount of *bandwidth remaining* from the bandwidth not used by COS1.
 

docs/bcp_sdwan_design_guide.md

@@ -89,7 +89,7 @@ There are many considerations with a pod design. In the drawing above, the hando
 
 ### Tenancy Design
 
-*Main article: [Tenancy Design](bcp_tenants.mdx)*
+*Main article: [Tenancy Design](bcp_tenants.md)*
 
 From the discussion with the end customer on segmentation, the definition of tenants should be relatively straight forward. The goal is to create a list of global profiles that can be used for access policies to services. Conceptually, tenancy should not be tied to a location and should be a global construct available whenever we want to classify traffic to a profile when it enters the SSR fabric across the authority (though at times due to business logic defined by the customer, a tenant may reflect a location). At any point in the authority, when traffic ingresses into an SSR, tenancy is applied. Typically this is done by assigning the tenant to the network-interface according to the purpose of the VLAN for which the SSR is the router. For example "POS" for point of sale, "voice" for telephony devices, and "core" for traffic coming from the customer's core network (if no further breakdown of tenancy is required for this traffic). The SSR can also restrict ingress traffic into a tenant further by creating a neighborhood on the network interface. Neighborhoods serve multiple purposes and an additional discussion of neighborhoods will occur in an ensuing section. In the global tenant configuration, this neighborhood may be referenced as a "member" and then CIDR block ranges for source addresses can be defined within this member. In this manner, a shared neighborhood name can be configured on a common LAN network for a site category and the tenant configuration can be updated with the specific list of CIDR ranges that will be used to identify which source IP addresses belong to a particular tenant for traffic coming in on this interface.
 

docs/bcp_tenants.mdx → docs/bcp_tenants.md

@@ -3,8 +3,6 @@ title: Tenancy Design
 sidebar_label: Tenancy Design
 ---
 
-import Flowchart from '../src/components/Flowchart';
-
 The *tenant* is one of the foundational data model elements within the Session Smart Router (SSR), and represents a consumer of network *services*. Tenancy is the logical partitioning of a network’s resources, done in the interest of restricting access to network services to only the users and groups for which they’re intended.
 
 This document provides an overview of tenancy in the SSR, how it is configured, and provides guidance for modeling the segmentation of a network using the SSR's data modeling language.
@@ -41,26 +39,20 @@ As new sessions arrive at an SSR, the router will attempt to classify the source
 
 Should none of these result in a definitive determination on the tenant of the source of this session request, the session is associated with the *global tenant* (see the section on "Special Tenants" for more information on the global tenant). Once the tenant has been identified – either as a specific tenant, or as the global tenant – this acts as a filter into the SSR’s FIB. Only the routes associated with that tenant are available to that user group. While this somewhat resembles the way a legacy router uses VRFs to create separate RIBs and FIBs, the segment by *tenant* is pervasive among all routers within an Authority by design, and is applied ubiquitously among all varieties of networks: public IP space, private, cloud, IPv4, IPv6, etc.
 
-<Flowchart
-  chartCode={`
-    st=>start: Packet Arrives
-      metadata=>condition: Packet has metadata?
-      int=>condition: Interface has a tenant?
-      nh=>condition: Neighborhood-based tenant?
-      tm=>operation: Tenant taken from metadata
-      ti=>operation: Tenant taken from interface
-      th=>operation: Tenant taken from neighborhood
-      global=>operation: Tenant assigned as "global"
-      e=>end: Proceed to FIB lookup
-    st->metadata
-    metadata(no)->int
-    metadata(yes,right)->tm->e
-    int(yes,right)->ti->e
-    int(no)->nh
-    nh(yes,right)->th->e
-    nh(no)->global->e
-  `}
-/>
+```mermaid
+flowchart TD
+    st([Packet Arrives]) --> metadata{Packet has metadata?}
+    metadata -->|no| int{Interface has a tenant?}
+    metadata -->|yes| tm[Tenant taken from metadata]
+    tm --> e([Proceed to FIB lookup])
+    int -->|yes| ti[Tenant taken from interface]
+    ti --> e
+    int -->|no| nh{Neighborhood-based tenant?}
+    nh -->|yes| th[Tenant taken from neighborhood]
+    th --> e
+    nh -->|no| gl["Tenant assigned as &quot;global&quot;"]
+    gl --> e
+```
 
 #### Viewing a Router's Tenancy
 

docs/cc_fips_downloading_iso.md

@@ -11,7 +11,7 @@ Juniper Session Smart Networking provides the following workflows for the compli
 
 - **Package-based ISO:** This ISO offers multiple local installation methods.
   - **One Touch Provisioning (OTP)** is the default and preferred method of Router installation. OTP sets up DHCP on all interfaces and boots a Web Server GUI. After installing the Conductor and configuring routers through the Conductor, the OTP quickstart process will install and configure the router. See the following procedures for OTP installation steps: 
-    - [Router Installation Using OTP](intro_otp_iso_install.mdx)
+    - [Router Installation Using OTP](intro_otp_iso_install.md)
     - [Quickstart from the OTP ISO](intro_install_quickstart_otpiso.md)
   - **Interactive:** For Conductor installations and bespoke deployments where customized platform configuration is necessary, an interactive mode exists. Installation is done using the serial console. An interactive session is started to configure network interfaces, passwords, node name and type, and conductor IP (if applicable) before the SSR software is started.
 

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.md).
 
 ### Secure Vector Routing Traffic
 

docs/conductor_upgrade.md

@@ -130,7 +130,7 @@ While the linux shell is available for upgrading the conductor, it is advised to
 
 ## Next Steps
 
-See [Router Interactive Installation](intro_installation_bootable_media.mdx) or [Router Installation Using OTP](intro_otp_iso_install.mdx) for steps to install your routers. 
+See [Router Interactive Installation](intro_installation_bootable_media.mdx) or [Router Installation Using OTP](intro_otp_iso_install.md) for steps to install your routers. 
 
 If your deployment will take advantage of Mist Telemetry, see [Enable WAN Assurance on the Conductor](config_wan_assurance.md#enable-wan-assurance-on-the-conductor) for those next steps. 
 

docs/config_bgp.md

@@ -1025,6 +1025,7 @@ There is one additional field which needs to be set in route reflector's BGP con
 When the route reflector sends routes to the clients, by default it doesn't modify the next-hop. An outbound policy can be used to change the next-hop in these routes to that of the route reflector, if desired. In such instances, another option, which is turned off by default, needs to be set in the route reflector's BGP config: `Route Reflector Allow Outbound Policy = TRUE`.
 
 ### BGP Confederations
+
 When configuring iBGP, the **Confederation** feature may be helpful when dealing with an enormous autonomous system. This feature allows you to break up the AS into smaller sub-autonomous systems. Confederation can be directly configured under the routing protocol element. Here, 65535 is the **confederation identifier AS number** and, 1100 and 2200 are the **member AS** numbers of that confederation AS.
 
 ```
@@ -1037,3 +1038,145 @@ 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.
+
+### Version History
+
+| Release | Modification |
+|---|---|
+| 7.2.0 | Feature introduced. |
+
+### 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`.
+