Merge pull request #295010 from sushantjrao/break-glass-setup

NNF 8.0 Features

Author: denrea

articles/operator-nexus/.openpublishing.redirection.operator-nexus.json

@@ -69,6 +69,11 @@
       "source_path": "howto-create-cluster-with-user-assigned-managed-identity.md",
       "redirect_url": "howto-cluster-managed-identity-user-provided-resources",
       "redirect_document_id": false
+    },
+    {
+      "source_path": "howto-replace-a-terminal-server.md",
+      "redirect_url": "howto-replace-terminal-server",
+      "redirect_document_id": false
     }
   ]
 }

articles/operator-nexus/TOC.yml

@@ -210,14 +210,26 @@
           href: howto-set-up-break-glass-access.md
         - name: How to use-break-glass-access
           href: howto-use-break-glass-access.md
+        - name: How to set up break-glass access using In-Band management
+          href: howto-set-up-break-glass-access-using-in-band-management.md
         - name: How to enable-Micro-BFD on CE and PE devices
           href: howto-enable-micro-bfd.md
-        - name: How to replace a terminal server
-          href: howto-replace-a-terminal-server.md
+        - name: How to replace terminal server
+          href: howto-replace-terminal-server.md
         - name: How to upgrade os of terminal server
           href: howto-upgrade-os-of-terminal-server.md
         - name: How to restrict serial port access and set timeout on terminal-server
           href: howto-restrict-serial-port-access-and-set-timeout-on-terminal-server.md
+        - name: How to append custom suffix to interface descriptions
+          href: howto-append-custom-suffix-to-interface-descriptions.md
+        - name: How to reboot Network Device in Azure Operator Nexus Network Fabric
+          href: howto-reboot-network-device.md
+        - name: How to Configure NNF with Bring Your Own (BYO) Storage
+          href: howto-configure-bring-your-own-storage-network-fabric.md
+        - name: How to upgrade OS of terminal server
+          href: howto-upgrade-os-of-terminal-server.md
+        - name: How to restrict serial port access and set timeout on terminal-server
+          href: howto-restrict-serial-port-access-and-set-timeout-on-terminal-server.md           
     - name: Cluster
       expanded: false
       items:
@@ -269,6 +281,8 @@
           href: howto-kubernetes-cluster-install-microsoft-defender.md
         - name: Kubernetes cluster features
           href: howto-kubernetes-cluster-features.md
+
+
     - name: Nexus Virtual Machine
       expanded: false
       items:

articles/operator-nexus/concepts-access-control-lists.md

@@ -53,6 +53,21 @@ The action property of an ACL statement can have one of the following types:
 - **Drop**: Discards packets that match specified conditions.
 - **Count**: Counts the number of packets that match specified conditions.
 
+## Control plane traffic policy (CP-TP)
+
+Additionally to add an additional layer of control plane protection for enhancing network security, users can also configure and modify control plane traffic policies on supported devices via APIs. 
+
+•	A Traffic Policy (TP) solution for securing the Fabric device Control Plane (packets destined to or originating from the Fabric device) of the supported devices in AON.
+
+•	The device control plane (which includes Policing/Rate Limiting) can be implemented as Traffic Policies based on source/destination IP, source/destination ports, and protocols.
+•	API supports create, update, and delete the TP entries/rules/Policing/Rate Limiting.
+
+To implement the functionality for Control Plane ACL - Traffic Policy: 
+
+•	For existing deployments, users must create a CPTP ACL resource, associate it with the Network Fabric (NF), and perform a patch operation.
+
+•	For new deployments, users should create the CPTP ACL resource either during Fabric creation or after the Fabric has been provisioned, followed by patching it to the NF resource. Since the CPTP ACL resource is not created by default, users must manually create it before attaching it to the NF.
+
 ## Next steps:
 
 [Creating Access Control List (ACL) management for NNI and layer 3 isolation domain external networks](howto-create-access-control-list-for-network-to-network-interconnects.md)

articles/operator-nexus/concepts-isolation-domain.md

@@ -15,15 +15,17 @@ An Isolation Domain resource enables the creation of layer-2 and layer-3 network
 
 -   **Layer-2 isolation domain** - provides layer-2 networking capabilities within and across the racks for workloads running on servers. Workloads can take advantage of the isolated layer-2 network to establish direct connectivity among themselves at layer 2 and above.
 
+- **L2 isolation domain with extended VLAN Support (L2VRF)** - Nexus provides a way to extend Layer 2 (L2) connectivity from the Customer Edge (CE) router to the Provider Edge (PE) router. This is particularly useful workloads that require Layer 2 reachability outside nexus instance  
+
 -   **Layer-3 isolation domain with Internal Networks** - provides workloads the ability to connect across a layer 3 (IP) network.
 
--   **Layer-3 isolation domain with External Network** - provides workloads the ability to connect across a layer 3 network, and provides connectivity to the operator's network outside of the Operator Nexus network fabric.
+-   **Layer-3 isolation domain with External Network** - provides workloads the ability to connect across a layer 3 network, and provides connectivity to the operator's network outside of the Operator Nexus Network Fabric.
 
 An isolation domain offers:
 
 -   Unified network capabilities with full integration with your compute resources, enabling connectivity between your Operator Nexus platform workloads.
 
--   Northbound connectivity with customer routers using BGP peering sessions between the Operator Nexus network fabric and the operator's external network.
+-   Northbound connectivity with customer routers using BGP peering sessions between the Operator Nexus Network Fabric and the operator's external network.
 
 -   Southbound connectivity with telco workloads using internal networks.
 
@@ -39,12 +41,22 @@ A layer 2 isolation domain provides L2 networking capabilities between workloads
 
 The NNF enables operators to provision and manage layer 2 isolation domains below resource level. Each layer-2 isolation domain has an associated VLAN ID. If a workload needs connectivity to multiple VLANs, multiple layer-2 isolation domains must be created. A separate NIC resource is required for each layer-2 domain that the workload connects to.
 
+L2 isolation domain with extended VLAN Support (L2VRF) 
+
+The L2VRF feature in Nexus enhances the flexibility and scalability of network configurations, making it easier to manage complex enterprise use cases. 
+
+- **Extended VLAN Support:** The Layer 2 Isolation Domain (ISD) ARM resource now supports a new read-write property called extendedVlan, which defaults to false. When this property is set, the CEs are configured to trunk through the VLAN ID of the L2 ISD to the PE.
+
+- **Dynamic Configuration:** The extendedVlan property can be dynamically toggled, and changes apply at the point of the next Fabric commit.
+    
+- **Traffic Agnosticism:** Nexus is agnostic to the traffic running over this network and does not run any hosts or services on it. Address management, security, and services (DNS, DHCP, NTP, etc.) are user responsibilities.
+
 ## Layer 3 Isolation Domains
 
-A layer 3 isolation domain provides workloads with the ability to exchange layer-3 routing information through the Operator Nexus network fabric and with external networks.
+A layer 3 isolation domain provides workloads with the ability to exchange layer-3 routing information through the Operator Nexus Network Fabric and with external networks.
 
 Layer-3 isolation domains can provide two types of network:
 
--   **Internal Network** - a Layer 3 Isolation Domain Internal Network enables east-west layer 3 communication between workloads on the Operator Nexus Network fabric. An internal network is a complete solution for layer-3 inter and intra-rack communication for compute workloads. Each workload can connect to multiple internal networks.
+-   **Internal Network** - a Layer 3 Isolation Domain Internal Network enables east-west layer 3 communication between workloads on the Operator Nexus Network Fabric. An internal network is a complete solution for layer-3 inter and intra-rack communication for compute workloads. Each workload can connect to multiple internal networks.
 
--   **External Network** - a Layer 3 Isolation Domain External Network enables workloads to communicate with external services via the operator network. An external network creates a communication channel between Operator Nexus workloads and services hosted outside of the Operator Nexus network fabric. Each Layer 3 isolation domain supports one external network.
+-   **External Network** - a Layer 3 Isolation Domain External Network enables workloads to communicate with external services via the operator network. An external network creates a communication channel between Operator Nexus workloads and services hosted outside of the Operator Nexus Network Fabric. Each Layer 3 isolation domain supports one external network.

articles/operator-nexus/concepts-observability.md

@@ -105,6 +105,10 @@ You can use the sample Azure Resource Manager workbook templates for [Operator N
 
 You can use the sample Azure Resource Manager alarm templates for [Operator Nexus alerting rules](https://github.com/microsoft/AzureMonitorCommunity/tree/master/Azure%20Services/Azure%20Operator%20Nexus#alert-rules). You should specify thresholds and conditions for the alerts. You can then deploy these alert templates on your on-premises environment.
 
+#### Hardware capacity alerts
+
+The hardware capacity threshold for devices is set at 60%, and the TrafficPolicy limit thresholds are set at 35%. All alerts will be published via syslog.
+
 ## Log Analytic Workspace
 
 A [Log Analytics Workspace (LAW)](/azure/azure-monitor/logs/log-analytics-workspace-overview) is a unique environment to log data from Azure Monitor and other Azure services. Each workspace has its own data repository and configuration but may combine data from multiple services. Each workspace consists of multiple data tables.

articles/operator-nexus/howto-append-custom-suffix-to-interface-descriptions.md

@@ -0,0 +1,141 @@
+---
+title: How to append custom suffix to interface descriptions in Azure Operator Nexus Network Fabric
+description: Learn how to append and remove custom suffix from interface descriptions in Azure Operator Nexus Network Fabric for enhanced operational annotations.
+author: sushantjrao
+ms.author: sushrao
+ms.service: azure-operator-nexus
+ms.topic: how-to
+ms.date: 02/24/2025
+ms.custom: template-how-to
+---
+
+# Append custom suffix to interface descriptions in Azure Operator Nexus Network Fabric
+
+This guide explains how to append a user-defined suffix (`additionalDescription`) to interface descriptions in Azure Operator Nexus Network Fabric. This feature provides enhanced flexibility for operational annotations, allowing users to customize interface descriptions for specific maintenance or operational requirements.
+
+## Prerequisites
+
+- **Azure CLI**: Version 2.61 or higher
+
+## Steps to append a custom suffix
+
+### 1. Check the current interface description
+
+Before making changes, verify the existing interface description using the following command:
+
+```Azure CLI
+az networkfabric interface show -g "example-rg" \
+  --network-device-name "example-device" \
+  --resource-name "example-interface" --query description
+```
+
+### Parameter Details  
+
+| Parameter                     | Short Form | Description |
+|--------------------------------|-----------|-------------|
+| `az networkfabric interface show` | N/A       | Displays details of a specified network fabric interface. |
+| `-g, --resource-group`        | `-g`      | Name of the resource group where the network device resides. |
+| `--network-device-name`       | N/A       | Name of the Network Fabric device. |
+| `--resource-name`             | N/A       | Name of the network interface resource. |
+| `--query`                     | N/A       | Filters the output to show only the specified field (e.g., `description`). |
+
+### 2. Append a suffix to the interface description
+
+To add a custom suffix, use the following command:
+
+```Azure CLI
+az networkfabric interface update --additional-description "example-description" \
+  --device "example-device" \
+  -g "example-resource-group" \
+  --resource-name "example-interface"
+```
+
+### Parameter Details  
+
+| Parameter                | Description                                      | Constraints |
+|--------------------------|--------------------------------------------------|-------------|
+| `--additional-description` | Provides an additional description for the interface update. | Alphanumeric (`A-Z`, `a-z`, `0-9`), `-`, and `_` allowed. Max 64 characters. Can be an empty string with a space or null. |
+| `--device`               | Specifies the name of the Network Fabric device. | No specific constraints. |
+| `-g, --resource-group`   | Defines the name of the resource group where the device is located. | No specific constraints. |
+| `--resource-name`        | Indicates the name of the network interface resource. | No specific constraints. |
+
+### 3. Commit the configuration
+
+After updating the description, apply the changes to the Fabric:
+
+```Azure CLI
+az networkfabric fabric commit-configuration --resource-group "example-rg" --resource-name "example-fabric"
+```
+Parameter Details:
+
+| Parameter            | Short Form | Description |
+|----------------------|-----------|-------------|
+| `--resource-group`  | `-g`      | Name of the resource group. |
+| `--resource-name`   | N/A       | Name of the Network Fabric. |
+
+### Example
+
+#### **Original interface description:**
+
+```Azure CLI
+AR-CE2(Fab3-AR-CE2):Et1/1 to CR1-TOR1(Fab3-CP1-TOR1)-Port23
+```
+
+#### **Updated Description:**
+```Azure CLI
+AR-CE2(Fab3-AR-CE2):Et1/1 to CR1-TOR1(Fab3-CP1-TOR1)-Port23-Additional_description-1234
+```
+
+## Removing the interface description
+
+To restore the default description, set `additionalDescription` to an empty string with a space (`" "`) or null:
+
+```Azure CLI
+az networkfabric interface update --additional-description "example-description" \
+  --device "example-device" \
+  -g "example-resource-group" \
+  --resource-name "example-interface"
+```
+
+### Parameter Details  
+
+| Parameter                | Description                                      | Constraints |
+|--------------------------|--------------------------------------------------|-------------|
+| `--additional-description` | Provides an additional description for the interface update. | Alphanumeric (`A-Z`, `a-z`, `0-9`), `-`, and `_` allowed. Max 64 characters. Can be an empty string with a space or null. |
+| `--device`               | Specifies the name of the Network Fabric device. | No specific constraints. |
+| `-g, --resource-group`   | Defines the name of the resource group where the device is located. | No specific constraints. |
+| `--resource-name`        | Indicates the name of the network interface resource. | No specific constraints. |
+
+### 3. Commit the configuration
+
+After removing the suffix, apply the changes to the Fabric:
+
+```Azure CLI
+az networkfabric fabric commit-configuration --resource-group "example-rg" --resource-name "example-fabric"
+```
+
+Parameter Details:
+
+| Parameter            | Short Form | Description |
+|----------------------|-----------|-------------|
+| `--resource-group`  | `-g`      | Name of the resource group. |
+| `--resource-name`   | N/A       | Name of the Network Fabric. |
+
+Once committed, the interface description reverts to its original state:
+
+```
+AR-CE2(Fab3-AR-CE2):Et1/1 to CR1-TOR1(Fab3-CP1-TOR1)-Port23
+```
+
+## Supported interface types
+
+This feature is available for the following interface types:
+
+- **Agg Rack CE**  
+- **Agg Rack Management**  
+- **Comp Rack TOR**  
+- **Comp Rack Management**  
+- **NPB Device**  
+
+> [!Note]  
+> **Existing deployments** will retain their **current descriptions** until Fabric instances are **migrated to Release 8.0**. After migration, users must update descriptions via the **API**.