dev feedback and copy edits

robswain · robswain · commit 8b2dbe63542a · 2024-05-01T18:18:33.000+01:00
diff --git a/articles/private-5g-core/collect-required-information-for-a-site.md b/articles/private-5g-core/collect-required-information-for-a-site.md
@@ -67,8 +67,8 @@ Collect all the values in the following table to define the packet core instance
    |Value  |Field name in Azure portal  |
    |---------|---------|
    | The IP address for the control plane interface on the access network. For 5G, this interface is the N2 interface; for 4G, it's the S1-MME interface; for combined 4G and 5G, it's the N2 and S1-MME interfaces. You identified this address in [Allocate subnets and IP addresses](complete-private-mobile-network-prerequisites.md?pivots=ase-pro-2#allocate-subnets-and-ip-addresses). </br></br> This IP address must match the value you used when deploying the AKS-HCI cluster on your Azure Stack Edge Pro device. You did this as part of the steps in [Order and set up your Azure Stack Edge Pro device(s)](complete-private-mobile-network-prerequisites.md?pivots=ase-pro-2#order-and-set-up-your-azure-stack-edge-pro-devices). |**N2 address (Signaling)** (for 5G), **S1-MME address** (for 4G), or **S1-MME/N2 address (Signaling)** (for combined 4G and 5G). |
-   | The virtual network name on port 3 on your Azure Stack Edge Pro 2 corresponding to the control plane interface on the access network. For 5G, this interface is the N2 interface; for 4G, it's the S1-MME interface; for combined 4G and 5G, it's the N2/S1-MME interface. | **ASE N2 virtual subnet** (for 5G), **ASE S1-MME virtual subnet** (for 4G), or **ASE N2/S1-MME virtual subnet** (for combined 4G and 5G). |
-   | The virtual network name on port 3 on your Azure Stack Edge Pro 2 corresponding to the user plane interface on the access network. For 5G, this interface is the N3 interface; for 4G, it's the S1-U interface; for combined 4G and 5G, it's the N3/S1-U interface.  | **ASE N3 virtual subnet** (for 5G), **ASE S1-U virtual subnet** (for 4G), or **ASE N3/S1-U virtual subnet** (for combined 4G and 5G). |
+   | The virtual network name on port 3 on your Azure Stack Edge Pro 2 corresponding to the control plane interface on the access network. For 5G, this interface is the N2 interface; for 4G, it's the S1-MME interface; for combined 4G and 5G, it's the N2/S1-MME interface. </br></br> For an HA deployment, this IP address MUST NOT be in any control plane or user plane subnets; it is used as the destination of routes in the access network gateway router(s). | **ASE N2 virtual subnet** (for 5G), **ASE S1-MME virtual subnet** (for 4G), or **ASE N2/S1-MME virtual subnet** (for combined 4G and 5G). |
+   | The virtual network name on port 3 on your Azure Stack Edge Pro 2 corresponding to the user plane interface on the access network. For 5G, this interface is the N3 interface; for 4G, it's the S1-U interface; for combined 4G and 5G, it's the N3/S1-U interface. </br></br> For an HA deployment, this IP address MUST NOT be in any control plane or user plane subnets; it is used as the destination of routes in the access network gateway router(s).  | **ASE N3 virtual subnet** (for 5G), **ASE S1-U virtual subnet** (for 4G), or **ASE N3/S1-U virtual subnet** (for combined 4G and 5G). |
 :::zone-end
 
 ## Collect UE usage tracking values
diff --git a/articles/private-5g-core/configure-routers-high-availability.md b/articles/private-5g-core/configure-routers-high-availability.md
@@ -12,50 +12,53 @@ ms.custom: template-how-to
 
 # Configure routers for a Highly Available (HA) deployment
 
-For a Highly Available Azure Private 5G Core deployment, you need to deploy a gateway router (strictly, a Layer 3 capable device – either a router or an L3 switch (router/switch hybrid)) in between the Azure Stack Edge cluster and:
+In a Highly Available Azure Private 5G Core deployment, the Azure Kubernetes Service (AKS) cluster runs on a pair of ASE devices. The ASE devices are deployed in an active / standby configuration, with the backup ASE rapidly taking over service in the event of a failure. Incoming traffic uses a virtual IP address which is routed to the physical IP address of the active ASE. Bidirectional Forwarding Detection (BFD) is used to detect failures.
+
+This requires you to deploy a gateway router between the ASE cluster and:
 
 - the RAN equipment in the access network
 - the data networks.
- 
-This how-to guide describes the configuration required on your routers to support an HA deployment.
 
-## Access network router
+The routers should rapidly detect the failure of an ASE device through a BFD session going down and immediately redirect all traffic to the other ASE. With the recommended settings, BFD should be able to detect failure in about one second, ensuring that traffic should be restored in less than 2.5 seconds.
+
+This how-to guide describes the configuration required on your router or routers to support an HA deployment. The gateway router for the access network and the gateway router for the data networks may be the same device or separate devices.
+
+## Collect router configuration values
+
+To determine how to configure the static routes on the gateway routers, navigate to your **Packet Core Control Plane** resource in the Azure portal. Under **Settings**, select **Router configuration**. This shows the N2S1 and N3 virtual IP addresses, the IP prefix for all UE pools for each data network and the next hops and relative priorities.
+
+## Configure the access network router
 
-Configure routers in the access network with the following static routes. The IP addresses defined in the access network are described in [private mobile network prerequisites](/azure/private-5g-core/complete-private-mobile-network-prerequisites).
+Configure the router in the access network with the following static routes. The IP addresses defined in the access network are described in [private mobile network prerequisites](/azure/private-5g-core/complete-private-mobile-network-prerequisites).
 
 |Destination  |Prefix length   |Next hop  |Priority (lower values are more preferred)  |
 |---------|---------|---------|---------|
 |Virtual N2 | 32 |One of the IP addresses defined in the access network as vNIC addresses on the AMFs’ interfaces to the local access subnet. | 10 |
 |Virtual N2 | 32 |The other IP address defined in the access network as vNIC addresses on the AMFs’ interfaces to the local access subnet. | 10 |
-|Virtual N3 | 32 |The preferred IP address defined in the access network as one of the vNIC addresses on the UPFs’ interfaces to the local access subnet.* | 10 |
-|Virtual N3 | 32 |The non-preferred IP address defined in the access network as one of the vNIC addresses on the UPFs’ interfaces to the local access subnet.* | 20 |
+|Virtual N3 | 32 |The preferred IP address defined in the access network as one of the vNIC addresses on the UPFs’ interfaces to the local access subnet. | 10 |
+|Virtual N3 | 32 |The non-preferred IP address defined in the access network as one of the vNIC addresses on the UPFs’ interfaces to the local access subnet. | 20 |
 
-*See the [Gateway router](#gateway-router) section for how to view the preferred and non-preferred IP addresses.
+### Configure BFD on the access network router
+
+The access network router must be configured with the following BFD sessions:
+
+- Two BFD sessions between the access network router and the pair of AMF vNIC addresses.
+- Two BFD sessions between the access network router and the pair of UPF vNIC addresses in the access network.
 
-## Data network router
+BFD sessions on the access data network routers should be configured to use a polling interval of 330 ms. The maximum tolerable packet loss should be set to 3 packets (this is the default on most routers).
 
-If network address translation (NAT) is not enabled, configure the routers in each data network with the following static routes. As for user plane traffic in the access network, one of the static routes is preferred to the other so that, in normal operation, all data network traffic uses the same route. Each data network supports a single subnet.
+## Configure the data network routers
+
+If network address translation (NAT) is not enabled, configure the routers in each data network with the following static routes. For user plane traffic in the access network, one of the static routes is preferred to the other so that, in normal operation, all data network traffic uses the same route. Each data network supports a single subnet.
 
 |Destination  |Prefix length   |Next hop  |Priority (lower values are more preferred)  |
 |---------|---------|---------|---------|
 |All UE subnets | Variable |DN preferred vNIC (vNIC addresses on the UPFs’ interfaces to the DN).| 10        |
 |All UE subnets | Variable |DN preferred vNIC (vNIC addresses on the UPFs’ interfaces to the DN).| 20        |
 
-## Gateway router
-
-To determine how to configure the static routes on the gateway routers, navigate to your **Packet Core Control Plane** resource in the Azure portal. Under **Settings**, select **Router configuration**. This shows the N2S1 and N3 virtual addresses, the IP prefix for all UE pools for each data network and the next hops and relative priorities.
-
-## Bi-directional Forwarding Detection (BFD)
-
-The access and data network routers must have the following BFD sessions configured:
-
-- Two BFD sessions between the access network router and the pair of AMF vNIC addresses.
-- Two BFD sessions between the access network router and the pair of UPF vNIC addresses in the access network.
-- Two BFD sessions per data network between the data network router and the pair of UPF vNIC addresses in that data network.
-
-BFD sessions on the access data network routers should be configured to use a polling interval of 200 ms. The maximum tolerable packet loss should be set to 3 packets (this is the default on most routers).
+### Configure BFD on the data network routers
 
-The routers should rapidly detect the failure of an Azure Stack Edge device through a BFD session going down and immediately redirect all traffic to the other Azure Stack Edge device. With the recommended settings, BFD should be able to detect failure in about 600 ms, ensuring that traffic should be restored in less than 1.5 seconds.
+Each data network router must be configured with two BFD sessions between the data network router and the pair of UPF vNIC addresses in that data network.
 
 ## Next steps
 
