7.2.0 release documentation by Chr1st0ph3rTurn3r · Pull Request #1014 · 128technology/docs

Chr1st0ph3rTurn3r · 2026-05-12T18:54:09Z

No description provided.

tjbresnahan · 2026-05-13T17:11:53Z

+SSR 7.2.0 introduces two complementary enhancements to address these gaps:
+
+1. **Underlay ICMP reaction** — When the SSR receives a TooBig packet from the underlay, it updates the affected overlay flow and generates a corrected TooBig packet toward the original packet sender, allowing the sender to adjust its segment size.
+2. **PMTUD-triggered session refresh** — When a periodic PMTUD cycle discovers a new path MTU, existing sessions that are eligible for flow-move are refreshed to use the new value on the next packet.


This is not being delivered in 7.2.0

tjbresnahan · 2026-05-13T17:15:54Z

+    Note over R2,R1: Underlay MTU between Hub and R2 drops to 1300
+    Hub->>R2: SVR packet hub-WAN to spoke-WAN (over 1300 bytes)
+    R2-->>Hub: ICMP TooBig type 3 code 4, reported MTU = 1300
+    Note over Hub: DivertedPacketHandler finds reverse flow. Updates Hub-to-Spoke PMTU to 1300.


We should emphasis that this only affects this particular flow. A different session using this same path does not realize the PMTU reported to this session. It also does not persist, meaning if the session is modified for some other reason (FIB update, device flap, etc), the egress MTU is 'reset' back to the latest at that time based on the most recent BFD-based PMTU detection test, or interface MTU if no such test has been done

tjbresnahan · 2026-05-13T17:17:11Z

+    Note over Server: Server adjusts MSS if TCP-capable
+```
+
+When R2 (an underlay device) cannot forward an oversized packet, it sends a TooBig packet to the Hub's WAN interface. The SSR's `DivertedPacketHandler` processes this message:


Should we call out DivertedPacketHandler in these docs? It feels like it crosses into implementation details. I guess it depends on how we callout individual processes elsewhere in documentation

tjbresnahan · 2026-05-13T17:18:07Z

+When R2 (an underlay device) cannot forward an oversized packet, it sends a TooBig packet to the Hub's WAN interface. The SSR's `DivertedPacketHandler` processes this message:
+
+1. It extracts the encapsulated IP header from the TooBig body to identify the affected overlay session.
+2. It finds the reverse flow using that header and updates the Hub → Spoke forward flow's PMTU to the value reported by the underlay.


Pedantic, but it doesnt have to be a reverse flow. It's whatever flow was traversed to elicit the TooBig response. In the context of a TCP download used throughout this doc, it would likely be a reverse flow

tjbresnahan · 2026-05-13T17:19:49Z

+3. It constructs a new TooBig packet directed toward the original packet sender (the Server), so the server's TCP stack can reduce its MSS.
+
+:::note
+The MTU value propagated in the new TooBig packet reflects the underlay-reported value. On paths with encryption, HMAC, FEC, or BFD tunneling overhead, the effective usable MTU will be lower than the raw underlay value. The SSR accounts for these overheads when setting the MSS on forward flow actions.


MTU, not MSS

... when setting the egress MTU on forward flow actions.

tjbresnahan · 2026-05-13T17:22:05Z

+
+## Fabric Fragmentation and Oversize Packet Behavior
+
+When the PMTU on an overlay (SVR/fabric) path is lower than the MTU of the segment immediately preceding the Hub, packets larger than the PMTU will require fragmentation along the overlay. The SSR always fragments fabric packets when necessary, even when the incoming packet carries the Don't Fragment (DF) bit. This preserves packet delivery but prevents the sender from learning about the smaller path MTU and adjusting its segment size.


IPv6 traffic also is supposed to never fragment at a router, but like the IPv4 with dont-frag, we do anyways when its an SVR path

tjbresnahan · 2026-05-13T17:23:31Z

+When the PMTU on an overlay (SVR/fabric) path is lower than the MTU of the segment immediately preceding the Hub, packets larger than the PMTU will require fragmentation along the overlay. The SSR always fragments fabric packets when necessary, even when the incoming packet carries the Don't Fragment (DF) bit. This preserves packet delivery but prevents the sender from learning about the smaller path MTU and adjusting its segment size.
+
+:::note
+For TCP traffic, setting `enforced-mss automatic` on the egress `network-interface` is the most reliable way to avoid this scenario. When set, the SSR rewrites the TCP MSS at the interface boundary to match the session MTU (including the path MTU for SVR sessions). This is not the default and must be explicitly configured.


This process is more widely known as MSS Clamping. We should sprinkle that in here. Also, the SSR will further reduce the MSS based on any overhead needed by the SSR, as mentioned earlier in the doc (thats the actual clamping)

tjbresnahan · 2026-05-13T17:25:22Z

+For TCP traffic, setting `enforced-mss automatic` on the egress `network-interface` is the most reliable way to avoid this scenario. When set, the SSR rewrites the TCP MSS at the interface boundary to match the session MTU (including the path MTU for SVR sessions). This is not the default and must be explicitly configured.
+:::
+
+### Oversize Fabric Packet Behavior


None of this section has been implemented for 7.2.0

tjbresnahan · 2026-05-13T17:25:53Z

+Packets that do not carry the DF bit fragment immediately regardless of this setting. Only packets that would otherwise be fragmented on an SVR path are subject to this behavior.
+:::
+
+#### Configuration Location


Same, this config knob doesnt exist

tjbresnahan · 2026-05-13T17:26:27Z

+exit
+```
+
+### Enabling Session Refresh on PMTU Change


This functionality is not in 7.2.0

tjbresnahan · 2026-05-13T17:29:43Z

+
+## Verification
+
+Use `show peers` to confirm the currently discovered path MTU for each peer path:


Nothing to correct here, just clarifying that this IS correct today. The show peers command investigates the peer path, which will show the PMTU at that moment in time. It's the session level part that only updates when a TooBig packet comes in, and only for that single session.

I dont think there's visibility into that from a show command perspective.

A new stat, stats/icmp/flow-mtu-updates, is a count of flows that have had their MTU updated at runtime via a TooBig packet. This counter is reset when the system resets (not persisted)

tjbresnahan · 2026-05-13T17:30:46Z

+
+- If the path MTU shown by `show peers` does not reflect the expected value, verify that `path-mtu-discovery > enabled` is `true` on both sides of the adjacency.
+- If TCP sessions continue to fragment after configuring `enforced-mss automatic`, confirm the setting is applied to the correct egress interface and that both peers have completed a PMTUD cycle.
+- If existing sessions are not picking up a new PMTU after a PMTUD cycle, verify the `service-policy` for those sessions has `session-resiliency` set to `failover` or `revertible-failover`.


This is not a useful check today

tjbresnahan · 2026-05-13T17:33:35Z

+SSR 7.2.0 introduces two complementary enhancements to address these gaps:
+
+1. **Underlay ICMP reaction** — When the SSR receives a TooBig packet from the underlay, it updates the affected overlay flow and generates a corrected TooBig packet toward the original packet sender, allowing the sender to adjust its segment size.
+2. **PMTUD-triggered session refresh** — When a periodic PMTUD cycle discovers a new path MTU, existing sessions that are eligible for flow-move are refreshed to use the new value on the next packet.


The two deliveries related to MTU are

The MTU in the TooBig packet is corrected by reducing the amount of overhead needed by the SSR

The flow which was traversed to trigger the TooBig response from the underlay is now updated to use the MTU reported in the TooBig packet

…hether changes are needed, and need to get stats example.

dmontgomeryJuniper · 2026-05-14T12:33:53Z

+
+### Configuring AES-GCM
+
+AES-GCM is selected by setting the `encryption-cipher` field of a security policy to the appropriate AES-GCM value. The security policy is then applied in the same locations as any other cipher:


Add a mention that new selectable values are aes-gcm-128 and aes-gcm-256

dmontgomeryJuniper · 2026-05-14T12:35:58Z

+
+### Verifying AES-GCM Is In Use
+
+After applying the new policy, use `show sessions by-id` to confirm the cipher is active on new sessions. The **Payload Security Policy** and **Metadata Security Policy** fields identify which security policy is applied per flow. Confirm that the policy you configured with AES-GCM is listed for the expected flows.


The Action List fields will also include GCM encryption/decryption actions: AesGcmEncrypt, AesGcmDecrypt, AesGcmEncryptSvr2, AesGcmDecryptSvr2

dmontgomeryJuniper

Couple of suggestions

MichaelBaj · 2026-05-14T19:01:00Z

+  onBrokenMarkdownLinks: 'throw',
  markdown: {
    mermaid: true,
-    hooks: {


Not sure why this change was made.

https://docusaurus.io/docs/api/docusaurus-config#onBrokenMarkdownLinks

Was existed previously is the new way to handle markdown reference handling

Not sure what that is. I asked CoPilot to try to resolve the mermaid issue, maybe that change was part of it?

Most likely. Please revert this change and let me know the mermaid error. I'll help you fix.

MichaelBaj · 2026-05-14T19:23:00Z

+
+```text
+admin@router1.site1# show bgp neighbors 172.16.3.3 filtered-routes
+```


Please provide at least a CLI output for IPv4

MichaelBaj · 2026-05-14T19:30:35Z

@@ -0,0 +1,209 @@
+---
+title: Path MTU Discovery Enhancements


Since there does not exist a document for Path MTU for the SSR, I would suggest calling this document Path MTU Discover, and leave off the Enhancements. We should use this document to describe overall PMTU behavior, including the enhancements.

The only area in our docs that covers PMTU is concepts_machine_communication.

I would leave that content there, but provide a link to this new document. It might be worthwhile to duplicate some or all of the other content here.

MichaelBaj · 2026-05-14T19:31:38Z

+
+| Release | Modification |
+| ------- | ------------ |
+| 7.2.0   | Feature introduced |


Untrue. PMTU has been around for a long time. Perhaps from the beginning? Might be better off removing this version history table.

MichaelBaj · 2026-05-14T19:41:37Z

+            node  <node-name>
+                device-interface  <device-interface-name>
+                    network-interface  <network-interface-name>
+                        oversize-fabric-packet-behavior  true


is oversize-fabric-packet-behavior true a new configuration attribute? What is the default?

MichaelBaj · 2026-05-14T19:46:33Z

+| Integrity | Authenticated; authentication failure causes immediate packet discard. |
+| HMAC settings | Ignored when AES-GCM is selected — authentication is inherent to GCM. |
+| Peer compatibility | If the remote peer does not support AES-GCM, the session falls back to the mutually supported cipher according to existing SSR negotiation behavior. |
+| Mixed-version fabrics | Supported, provided peers negotiate a mutually supported cipher. |


Same as above...

MichaelBaj · 2026-05-14T19:47:13Z

+| HMAC settings | Ignored when AES-GCM is selected — authentication is inherent to GCM. |
+| Peer compatibility | If the remote peer does not support AES-GCM, the session falls back to the mutually supported cipher according to existing SSR negotiation behavior. |
+| Mixed-version fabrics | Supported, provided peers negotiate a mutually supported cipher. |
+| Platform requirement | Requires OpenSSL with GCM capability; supported on existing SSR hardware platforms. |


I would remove this line. Of course the SSR is interoperating with other SSRs. Peers need to be on 7.2+

MichaelBaj · 2026-05-14T19:51:47Z

+:::
+
+:::caution
+Changing an encryption cipher is a service-impacting event. Existing sessions cannot be re-keyed in-place. Follow the guidance in [Changing A Security Policy](#changing-a-security-policy) and perform the change during a maintenance window.


What does happen when a security policy is changed on a running system? Will new session use the new security-policy setting while existing sessions will remain on the old configuration? Or do all sessions get updated (i.e., pre-existing sessions will be destroyed and recreated as new sessions)?

MichaelBaj · 2026-05-14T19:53:16Z

+
+### Verifying AES-GCM Is In Use
+
+After applying the new policy, use `show sessions by-id` to confirm the cipher is active on new sessions. The **Payload Security Policy** and **Metadata Security Policy** fields identify which security policy is applied per flow. The **Action List** fields include the GCM encryption and `decryption actions: `AesGcmEncrypt`, `AesGcmDecrypt`, `AesGcmEncryptSvr2`, and `AesGcmDecryptSvr2. Confirm that the policy you configured with AES-GCM is listed for the expected flows.


What is AesGcmDecryptSvr2? I see AesGcmEncryptMetadata in the output below. I'd like to think we didn't put "Svrv2" in CLI output.

MichaelBaj · 2026-05-14T19:54:22Z

+     Bytes Sent:                    151464
+     Tcp Retransmission Count:      N/A
+     Decrypt Security Policy:       <empty>
+     Action List:                    Ingress TtlValidateIpv4 IpHeaderTransform AesGcmEncrypt AppMetadataAdd AesGcmEncryptMetadata EthernetHeaderTransform AppForward


@dmontgomeryJuniper as per this doc set, is there detailed session output that displays per-session MTU values?

…ranch 'madams/7.2.0-san-uri-docs' into 7.2.0-release-documentation

…ig.js needed to be upgraded to 3.0 syntax and existing mermaid and flowchard jsx code needed to be replaced with the now native mermaid syntax

…f github.com:128technology/docs into 7.2.0-release-documentation

…hnology/docs into 7.2.0-release-documentation

MichaelBaj · 2026-05-26T20:55:35Z


 | Version | Initial GA Version | First Release Shipping Date | Latest GA Version | Support Lifetime | End of Engineering support | End of Support |
 | -- | -- | -- | -- | -- | -- | -- |
+| Release 7.2 | [7.2.0](release_notes_128t_7.2.md#release-720-10r1) | June 30, 2026 |  [7.2.0](release_notes_128t_7.2.md#release-720-10r1) | LTS | September 30, 2028 | March 30, 2029 |


The EoE date should be December 30, 2028. Math is FRS + 6 + 24 (for STS).
The EOS date should be June 30, 2029. Math is FRS + 6 + 24 + 6

MichaelBaj · 2026-05-27T14:05:53Z

+:::
+
+:::warning
+An issue has been identified involving the use of the HA Sync Redundancy Plugin with SSR 7.0.0, which prevents proper functioning of the plugin. If you use the HA Plugin in your SSR deployment, it is not advised to upgrade at this time. The issue is being investigated and will be resolved in a future release.


Given this was an issue with 7.0.0, and this is a 7.2.0 release, is this warning relevant?

MichaelBaj · 2026-05-27T14:29:05Z

+
+- **Adaptive PMTU Change Handling for Long-Lived Sessions:** The SSR performs Path MTU Discovery (PMTUD) along the overlay to determine the correct maximum transmission unit (MTU) for each peer path. Devices in the underlay may report an ICMP Destination Unreachable / Fragmentation Needed (type 3, code 4) error to indicate they could not forward a packet due to an undersized MTU. With 7.2.0, the SSR updates the affected overlay flow and generates a corrected packet toward the original packet sender, allowing the sender to adjust its segment size. The flow which was traversed to trigger the response from the underlay is now updated to use the new updated MTU. For more information, see [Path MTU Discovery](config_pmtu.md).
+------
+- **I95-61066  Simplified Interface Naming:** Removed the platform restriction (SSR400/SSR440 only) that prevented the ability to configure forwarding device-interfaces via Linux `interface-name`. `interface-name` can now be used as a device identifier on all physical and virtual SSR platforms for  both forwarding and non-forwarding interfaces, enabling stable, name-based NIC configuration for cloud VMs, bare-metal servers, and purpose-built hardware alike.


extra space after the issue ID
extra space after "SSR platforms for"

This description is incorrect. It can be stated more succinctly that device-interface names can use linux-like naming schemes for all platforms, from bare metal, to virtual, to public cloud. Please check with Vikas on the specifics for how this should be worded.

I wrote the description based on what Vikas had in the spec he sent me. I ran the text above by him before publishing it, and he agreed that it was accurate - the linux interface-name can now be used on both forwarding and non-forwarding interfaces, on all platforms.
I will bring your suggestions to him and see what we can craft for a better description.

MichaelBaj · 2026-05-27T14:57:37Z

+------
+- **I95-64645 Certificate Management - CSR Improvements:** Starting in SSR 7.2.0, the peering identity can be carried in a Subject Alternative Name (SAN) URI extension instead of the Common Name (CN). This is especially useful in **HA deployments**, where both nodes in a router share the same `peering-common-name` but enterprise PKI policies require unique CNs per certificate. See [Enhanced Security Key Management — API Naming Rules](sec_enhanced_key_mgmt.md#peering-identity-via-subject-alternative-name-uri) for details.
+------
+- **I95-64845 Add Missing Audit Events for Certificate APIs:** Addes several audit events and logs for certificate activity. See [Audit Events and Logging](sec-cert-based-encrypt.md#audit-eventslogging) for additional information.


Instead of "Add Missing", use "Add Additional"

MichaelBaj · 2026-05-27T14:58:24Z

+
+### New Features
+
+- **I95-25150 AES-GCM Encryption:** Added support for AES-GCM as an encryption and authentication algorithm. AES-GCM provides improved performance over AES-CBC + HMAC-SHA by combining encryption and authentication into a single operation.


Need link to detail configuration and troubleshooting document.

This is not in the Swift beta drop, and to be consistent with the 7.1 beta drops, only the included features are documented. In the final release notes, this will be visible with the link to the documentation.

GCM will be in the Swift beta.

MichaelBaj · 2026-05-27T16:20:49Z

+------
+- **I95-64567 SSR router status `Disconnected` on Conductor:** Resolved an issue where SSR routers may become stuck in a `Disconnected` state on the Conductor when a loopback address was configured, preventing config pushes and hiding vital data in the Conductor GUI.
+------
+- **I95-64569 GCP template interface ordering incorrect:** Resolved an issue where the GCP deployment template had incorrect interface ordering, causing interfaces to be assigned to the wrong roles.


If this should be documented, it should be in the GCP plugin docs.
Marked as exclude from release notes.
Please remove

MichaelBaj · 2026-05-27T17:16:32Z

+------
+- **I95-64619 Config validate rejects DHCP network-interface when VRRP is present:** Resolved an issue where configuration validation incorrectly rejected a DHCP-enabled network-interface if VRRP was present in the configuration, even when VRRP was not enabled.
+------
+- **I95-64696 Salt connectivity issues after Conductor upgrade to 6.3.7:** Resolved an issue where salt connectivity between routers and the conductor was lost after upgrading the conductor to version 6.3.7.


This issue was already listed in 6.2.11 release notes with the following language:

I95-64696 Salt connectivity issues after Conductor upgrade: Resolved an issue where salt-minion lost connectivity to the salt-master after a Conductor upgrade, affecting approximately 20% of routers. The minion-connector service now correctly manages the salt master address.

Let's continue to use the same language

MichaelBaj · 2026-05-27T17:22:06Z

+------
+- **I95-64696 Salt connectivity issues after Conductor upgrade to 6.3.7:** Resolved an issue where salt connectivity between routers and the conductor was lost after upgrading the conductor to version 6.3.7.
+------
+- **I95-64709 BGP stale-routes-time and Selection_Deferral_Timer:** Resolved an issue with the relationship between the SSR `stale-routes-time` configuration and RFC 4724's Selection Deferral Timer, ensuring proper BGP graceful restart behavior.


BGP stale-routes-time and Selection_Deferral_Timer -> BGP GR impacted by interaction of stale-routes-time and selection deferral timer.

MichaelBaj · 2026-05-27T17:29:27Z

+------
+- **I95-65019 TLS client peer-verification skipped when no CA certificate is configured:** Resolved a critical issue where TLS client connections without a configured CA certificate silently skipped peer verification.
+
+<!---


Why are these commented out? These should be listed, but are all Mist-specific.

MichaelBaj · 2026-05-27T17:32:14Z

+------
+- **WAN-4712 Update result directory with filtered and renamed files:** Updated the configuration transformation result directory to use filtered and renamed output files for improved analysis.
+------
+- **WAN-4724 Persist PapiDiff results in DB for analysis:** Added persistence of PapiDiff comparison results to a database for post-transformation analysis and debugging.


WAN-4724 Persist Configuration Diffs in database for analysis: Added persistence of configuration difs to a database for post-transformation analysis and debugging.

… number.

MichaelBaj · 2026-05-28T14:58:55Z

+
+### New Features
+
+- **I95-25150 AES-GCM Encryption:** Added support for AES-GCM as an encryption and authentication algorithm. AES-GCM provides improved performance over AES-CBC + HMAC-SHA by combining encryption and authentication into a single operation.


GCM will be in the Swift beta.

Chr1st0ph3rTurn3r added 2 commits May 11, 2026 16:18

adding documentation for show bgp output I95-61467

7912820

adding AES-GCM content for 7.2 Swift beta 1.

fda9957

Chr1st0ph3rTurn3r requested a review from dmontgomeryJuniper May 12, 2026 18:54

Chr1st0ph3rTurn3r requested a review from MichaelBaj as a code owner May 12, 2026 18:54

Chr1st0ph3rTurn3r requested a review from aayan-AIDE May 12, 2026 20:30

Merge branch 'master' into 7.2.0-release-documentation

e56e3cb

aayan-AIDE previously approved these changes May 12, 2026

View reviewed changes

adding pmtu topic for 7.2

76d864c

Chr1st0ph3rTurn3r dismissed aayan-AIDE’s stale review via 76d864c May 13, 2026 16:16

Chr1st0ph3rTurn3r requested a review from tjbresnahan May 13, 2026 16:20

tjbresnahan reviewed May 13, 2026

View reviewed changes

most of TJ's comments. Need the graphics to display so I can verify w…

94e4ffc

…hether changes are needed, and need to get stats example.

dmontgomeryJuniper reviewed May 14, 2026

View reviewed changes

Updates per Dennis' comments

bf3af36

MichaelBaj requested changes May 14, 2026

View reviewed changes

interim commit

c5f3aaf

merging Mike A's documentation for SAN URI into the 7.2 docs.Merge b…

3de3f5e

…ranch 'madams/7.2.0-san-uri-docs' into 7.2.0-release-documentation

MichaelBaj self-requested a review May 18, 2026 20:35

Chr1st0ph3rTurn3r and others added 16 commits May 19, 2026 10:32

restoring updated docusaurus file to 7.2 docs.

2d18615

renaming file to see whether the mermaid graphic works

918f72c

link fix

9ad0d33

In order to use the new Docusaurus mermaid syntax the docusaurus.conf…

74cace3

…ig.js needed to be upgraded to 3.0 syntax and existing mermaid and flowchard jsx code needed to be replaced with the now native mermaid syntax

Fix broken link after file name change

f827e04

Merge branch 'master' into 7.2.0-release-documentation

4c66efc

adding release notes doc and new features for swift beta

81ae4b2

merging broken link fixeMerge branch '7.2.0-release-documentation' o…

7bffa05

…f github.com:128technology/docs into 7.2.0-release-documentation

broken link fix

3379aa0

Merge branch 'master' into 7.2.0-release-documentation

a554187

adding resolved issue list

20eb7b8

issue with commented out text

d52ab36

clean up of release notes

ee97e62

Merge branch 'master' into 7.2.0-release-documentation

8edb2f9

build number change and cleanup of new features

80d2e35

mergeMerge branch '7.2.0-release-documentation' of github.com:128tec…

085be64

…hnology/docs into 7.2.0-release-documentation

MichaelBaj requested changes May 27, 2026

View reviewed changes

MichaelBaj self-requested a review May 27, 2026 17:33

Chr1st0ph3rTurn3r and others added 4 commits May 27, 2026 16:38

Merge branch 'master' into 7.2.0-release-documentation

eb30131

some updates to the release notes and LTS support dates

ec82535

updates per review, kaushik's swift beta release notes, and new build…

2c6b19c

… number.

revising 64149, removing 64514

80cb434

MichaelBaj previously approved these changes May 28, 2026

View reviewed changes

Chr1st0ph3rTurn3r and others added 2 commits May 28, 2026 11:27

Merge branch 'master' into 7.2.0-release-documentation

2fe144e

adding release notes to sidebar and doc location info for 64845.

59928cf

Chr1st0ph3rTurn3r dismissed MichaelBaj’s stale review via 59928cf May 28, 2026 16:23

Chr1st0ph3rTurn3r and others added 2 commits May 29, 2026 15:20

Merge branch 'master' into 7.2.0-release-documentation

8b3b69d

date, build number

88e8570


		## Fabric Fragmentation and Oversize Packet Behavior

		When the PMTU on an overlay (SVR/fabric) path is lower than the MTU of the segment immediately preceding the Hub, packets larger than the PMTU will require fragmentation along the overlay. The SSR always fragments fabric packets when necessary, even when the incoming packet carries the Don't Fragment (DF) bit. This preserves packet delivery but prevents the sender from learning about the smaller path MTU and adjusting its segment size.


		## Verification

		Use `show peers` to confirm the currently discovered path MTU for each peer path:


		### Configuring AES-GCM

		AES-GCM is selected by setting the `encryption-cipher` field of a security policy to the appropriate AES-GCM value. The security policy is then applied in the same locations as any other cipher:


		### Verifying AES-GCM Is In Use

		After applying the new policy, use `show sessions by-id` to confirm the cipher is active on new sessions. The Payload Security Policy and Metadata Security Policy fields identify which security policy is applied per flow. Confirm that the policy you configured with AES-GCM is listed for the expected flows.


		### New Features

		- I95-25150 AES-GCM Encryption: Added support for AES-GCM as an encryption and authentication algorithm. AES-GCM provides improved performance over AES-CBC + HMAC-SHA by combining encryption and authentication into a single operation.

Conversation

Chr1st0ph3rTurn3r commented May 12, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tjbresnahan May 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tjbresnahan May 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dmontgomeryJuniper left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tjbresnahan May 13, 2026 •

edited

Loading

tjbresnahan May 13, 2026 •

edited

Loading