edit pass: network-fabric-articles

Author: paulth1

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

@@ -136,7 +136,7 @@ AR-CE2(Fab3-AR-CE2):Et1/1 to CR1-TOR1(Fab3-CP1-TOR1)-Port23
 
 ## Network interface updates
 
-Updates were made to the network interface of the network device to standardize the interface description. Also, these updates now link the interface to the Azure Resource Manager (ARM) resource ID of the connected interface for better management and tracking.
+Updates were made to the network interface of the network device to standardize the interface description. Also, these updates now link the interface to the Azure Resource Manager resource ID of the connected interface for better management and tracking.
 
 ### Standardized interface descriptions
 
@@ -148,7 +148,7 @@ Interface descriptions follow a consistent format of the source device to the de
 
 ### connectedTo property
 
-The `connectedTo` property returns the ARM resource ID of the connected interface, where available.
+The `connectedTo` property returns the Azure Resource Manager resource ID of the connected interface, where available.
 
 ### Comparison of old and new values
 
@@ -161,11 +161,11 @@ The `connectedTo` property returns the ARM resource ID of the connected interfac
 
 All the preceding features are available for the following interface types:
 
-- Agg Rack CE
-- Agg Rack Management
-- Comp Rack TOR
-- Comp Rack Management
-- Network Packet Broker device
+- Agg Rack customer edge
+- Agg Rack management
+- Comp Rack top of rack
+- Comp Rack management
+- Network packet broker device
 
 > [!NOTE]
-> For devices that Azure Operator Nexus Network Fabric doesn't manage, such as personal electronics or storage devices, the `connectedTo` property continues to reflect the value as a `string` with no active link.
+> For devices that Azure Operator Nexus Network Fabric doesn't manage, such as provider edge or storage devices, the `connectedTo` property continues to reflect the value as `string` with no active link.

articles/operator-nexus/howto-apply-access-control-list-to-network-to-network-interconnects.md

@@ -1,6 +1,6 @@
 ---
-title: Azure Operator Nexus - Applying ACLs to Network-to-Network Interconnects (NNI)
-description: Learn how to apply Access Control Lists (ACLs) to network-to-network interconnects (NNI) within Azure Nexus Network Fabric.
+title: 'Azure Operator Nexus: Apply ACLs to Network-to-Network Interconnects'
+description: Learn how to apply access control lists (ACLs) to network-to-network interconnects (NNIs) within Azure Operator Nexus Network Fabric.
 author: sushantjrao
 ms.author: sushrao
 ms.service: azure-operator-nexus
@@ -9,69 +9,68 @@ ms.date: 04/23/2024
 ms.custom: template-how-to, devx-track-azurecli
 ---
 
-# Access Control List (ACL) Management for NNI
+# Access control list (ACL) management for NNI
 
-In Azure Nexus Network Fabric, maintaining network security is paramount for ensuring a robust and secure infrastructure. Access Control Lists (ACLs) are crucial tools for enforcing network security policies. This guide leads you through the process of applying ACLs to network-to-network interconnects (NNI) within the Nexus Network Fabric.
+In Azure Operator Nexus Network Fabric, maintaining network security is paramount for ensuring a robust and secure infrastructure. Access control lists (ACLs) are crucial tools for enforcing network security policies. This article leads you through the process of applying ACLs to network-to-network interconnects (NNIs) within Azure Operator Nexus Network Fabric.
 
-## Applying Access Control Lists (ACLs) to NNI in Azure Fabric
+## Apply ACLs to NNIs in Azure Operator Nexus Network Fabric
 
-To maintain network security and regulate traffic flow within your Azure Fabric network, applying Access Control Lists (ACLs) to network-to-network interconnects (NNI) is essential. This guide delineates the steps for effectively applying ACLs to NNIs.
+To maintain network security and regulate traffic flow within your Azure Operator Nexus Network Fabric network, applying ACLs to NNIs is essential. This article delineates the steps for effectively applying ACLs to NNIs.
 
-#### Applying ACLs to NNI
+#### Apply ACLs to NNIs
 
-Before applying ACLs to NNIs, utilize the following commands to view ACL details.
+Before you apply ACLs to NNIs, use the following commands to view ACL details.
 
-#### Viewing ACL details
+#### View ACL details
 
-To view the specifics of a particular ACL, execute the following command:
+To view the specifics of a particular ACL, run the following command:
 
 ```azurecli
 az networkfabric acl show --name "<acl-ingress-name>" --resource-group "<resource-group-name>"
 ```
 
 This command furnishes detailed information regarding the ACL's configuration, administrative state, default action, and matching conditions.
 
-#### Listing ACLs in a resource group
+#### List ACLs in a resource group
 
-To list all ACLs within a resource group, use the command:
+To list all ACLs within a resource group, use the following command:
 
 ```azurecli
 az networkfabric acl list --resource-group "<resource-group-name>"
 ```
 
 This command presents a comprehensive list of ACLs along with their configuration states and other pertinent details.
 
-#### Applying Ingress ACL to NNI
+#### Apply an ingress ACL to an NNI
 
 ```azurecli
 az networkfabric nni update --resource-group "<resource-group-name>" --resource-name "<nni-name>" --fabric "<fabric-name>" --ingress-acl-id "<ingress-acl-resource-id>"
 ```
 
 | Parameter         | Description                                      |
 |-------------------|--------------------------------------------------|
-| --ingress-acl-id | Apply the ACL as ingress by specifying its resource ID.  |
+| `--ingress-acl-id` | Apply the ACL as ingress by specifying its resource ID.  |
 
-#### Applying Egress ACL to NNI
+#### Apply an egress ACL to an NNI
 
 ```azurecli
 az networkfabric nni update --resource-group "example-rg" --resource-name "<nni-name>" --fabric "<fabric-name>" --egress-acl-id "<egress-acl-resource-id>"
 ```
 
 | Parameter        | Description                                    |
 |------------------|------------------------------------------------|
-| --egress-acl-id | Apply the ACL as egress by specifying its resource ID. |
+|`--egress-acl-id` | Apply the ACL as egress by specifying its resource ID. |
 
-#### Applying Ingress and Egress ACLs to NNI:
+#### Apply ingress and egress ACLs to NNIs
 
 ```azurecli
 az networkfabric nni update --resource-group "example-rg" --resource-name "<nni-name>" --fabric "<fabric-name>" --ingress-acl-id "<ingress-acl-resource-id>" --egress-acl-id ""<egress-acl-resource-id>""
 ```
 
 | Parameter         | Description                                                                                                    |
 |-------------------|----------------------------------------------------------------------------------------------------------------|
-| --ingress-acl-id, --egress-acl-id | To apply both ingress and egress ACLs simultaneously, create two new ACLs and include their respective resource IDs. |
+| `--ingress-acl-id`, `--egress-acl-id` | To apply both ingress and egress ACLs simultaneously, create two new ACLs and include their respective resource IDs. |
 
+## Related content
 
-## Next steps
-
-[Updating ACL on NNI or External Network](howto-update-access-control-list-for-network-to-network-interconnects.md)
+[Update ACLs on NNIs or an external network](howto-update-access-control-list-for-network-to-network-interconnects.md)

articles/operator-nexus/howto-configure-bgp-prefix-limit-on-customer-edge-devices.md

@@ -11,7 +11,7 @@ ms.custom: template-how-to, devx-track-azurecli
 
 # BGP prefix limiting overview
 
-Border Gateway Protocol (BGP) prefix limiting is an essential overload protection mechanism for customer edge (CE) devices. It helps prevent the Nexus fabric from being overwhelmed when a Nexus tenant advertises an excessive number of BGP routes into a Nexus virtual routing and forwarding (VRF) instance. This feature helps to ensure network stability and security by controlling the number of prefixes received from BGP peers.
+Border Gateway Protocol (BGP) prefix limiting is an essential overload protection mechanism for customer edge (CE) devices. It helps prevent the Nexus fabric from being overwhelmed when a Nexus tenant advertises an excessive number of BGP routes into a Nexus virtual routing and forwarding (VRF) instance. This feature helps to ensure network stability and security by controlling the number of prefixes that are received from BGP peers.
 
 ## Configuration of BGP prefix limits
 
@@ -43,7 +43,7 @@ To configure the BGP prefix limit on CE devices for Azure Operator Nexus, follow
 Configure the BGP prefix limits by using the parameters `maximumRoutes` and `threshold`:
 
 - `maximumRoutes`: This parameter defines the maximum number of BGP prefixes that the router accepts from a BGP peer.
-- `threshold`: This parameter defines the warning threshold as a percentage of the `maximumRoutes`. When the number of prefixes exceeds this threshold, a warning is generated.
+- `threshold`: This parameter defines the warning threshold as a percentage of the `maximumRoutes` parameter. When the number of prefixes exceeds this threshold, a warning is generated.
 
 #### Step 2: Configure on the CE device
 
@@ -61,7 +61,7 @@ This configuration automatically restarts the session after a defined idle time
 }
 ```
 
-- **Explanation**:
+- Explanation:
 
   - `maximumRoutes`: The limit for the BGP session is 5,000 routes.
   - `threshold`: A warning is triggered when the prefix count reaches 80% (4,000 routes).
@@ -80,7 +80,7 @@ This configuration shuts down the session when the maximum prefix limit is reach
 }
 ```
 
-- **Explanation**:
+- Explanation:
 
   - `maximumRoutes`: The limit for the BGP session is 5,000 routes.
   - `threshold`: A warning is triggered when the prefix count reaches 80% (4,000 routes).
@@ -98,7 +98,7 @@ This configuration drops extra routes if the prefix limit is exceeded without ma
 }
 ```
 
-- **Explanation**:
+- Explanation:
 
   - `maximumRoutes`: The limit for the BGP session is 5,000 routes.
   - After the limit is reached, the CE device drops any extra prefixes received from the BGP peer.
@@ -117,7 +117,7 @@ This configuration generates a warning after the prefix count reaches a certain
 }
 ```
 
-- **Explanation**:
+- Explanation:
 
   - `maximumRoutes`: The limit for the BGP session is 8,000 routes.
   - `threshold`: A warning is generated when the prefix count reaches 75% (6,000 routes).
@@ -127,25 +127,25 @@ This configuration generates a warning after the prefix count reaches a certain
 
 You can use Azure CLI commands to apply the BGP prefix limits to the external network configuration for Nexus.
 
-- **With automatic restart**:
+- With automatic restart:
 
    ```bash
    az networkfabric externalnetwork create --resource-group <resource-group> --fabric-name <fabric-name> --network-name <network-name> --prefix-limits '{"maximumRoutes": 5000, "threshold": 80, "idleTimeExpiry": 100}'
    ```
 
-- **Without automatic restart**:
+- Without automatic restart:
 
    ```bash
    az networkfabric externalnetwork create --resource-group <resource-group> --fabric-name <fabric-name> --network-name <network-name> --prefix-limits '{"maximumRoutes": 5000, "threshold": 80}'
    ```
 
-- **Hard-limit drop BGP sessions**:
+- Hard-limit drop BGP sessions:
 
    ```bash
    az networkfabric externalnetwork create --resource-group <resource-group> --fabric-name <fabric-name> --network-name <network-name> --prefix-limits '{"maximumRoutes": 5000}'
    ```
 
-- **Hard-limit warning only**:
+- Hard-limit warning only:
 
    ```bash
    az networkfabric externalnetwork create --resource-group <resource-group> --fabric-name <fabric-name> --network-name <network-name> --prefix-limits '{"maximumRoutes": 8000, "threshold": 75, "warning-only": true}'
@@ -163,21 +163,21 @@ Look for the session states and the number of prefixes advertised by each peer.
 
 ### Considerations
 
-- **Threshold and maximum limits**: Ensure that you set appropriate thresholds to avoid unnecessary session terminations while still protecting the network from overload.
-- **Automatic versus manual restart**: Depending on your network operations, choose between automatic and manual restart options. Automatic restart is useful for minimizing manual intervention. Manual restart might give network administrators more control over recovery.
+- **Threshold and maximum limits:** Ensure that you set appropriate thresholds to avoid unnecessary session terminations while still protecting the network from overload.
+- **Automatic versus manual restart:** Depending on your network operations, choose between automatic and manual restart options. Automatic restart is useful for minimizing manual intervention. Manual restart might give network administrators more control over recovery.
 
 ## Handle BGP prefix limits for different networks
 
 ### Internal network
 
-The platform supports Layer 3 Isolation Domain (`L3IsolationDomain`) for tenant workloads. It performs device programming on Nexus instances and Arista devices with peer groups for both IPv4 and IPv6 address families.
+The platform supports layer 3 isolation domain (`L3IsolationDomain`) for tenant workloads. It performs device programming on Nexus instances and Arista devices with peer groups for both IPv4 and IPv6 address families.
 
-### External network option B (PE)
+### External network option B (provider edge)
 
-For external network configuration, only the **hard-limit warning-only** option is supported. Nexus supports this configuration via the Azure Resource Manager API under `NNI optionBlayer3Configuration` with the `maximumRoutes` parameter.
+For external network configuration, only the hard-limit `warning-only` option is supported. Nexus supports this configuration via the Azure Resource Manager API under `NNI optionBlayer3Configuration` with the `maximumRoutes` parameter.
 
 ### Network-to-network interface option A
 
-For network-to-network interface option A, only a single peer group is allowed. IPv4 over IPv6 and vice versa aren't supported. Warning-only mode is available for handling prefix limits.
+For network-to-network interface option A, only a single peer group is allowed. IPv4 over IPv6 and vice versa aren't supported. The `warning-only` mode is available for handling prefix limits.
 
 By following the steps in this article, you can configure BGP prefix limits effectively to protect your network from overload. You can help to ensure that BGP sessions are properly managed for both internal and external networks.