[Network Flow] eli5 #4 (cloudflare#29008)

* eli5

* eli5

* eli5

* eli5

Author: marciocloudflare

src/content/partials/networking-services/mnm/rules/dynamic-threshold.mdx

@@ -2,13 +2,9 @@
 {}
 ---
 
-A dynamic threshold rule (beta) will analyze a network's traffic patterns over time and automatically adjust the rule's DDoS (Distributed Denial of Service) threshold, in terms of bits or packets, based on traffic history. The total traffic across all IP prefixes and IP addresses in the rule is compared to the current value of the dynamic threshold. If the total traffic exceeds the dynamic threshold, Network Flow (formerly Magic Network Monitoring) sends an alert.
+A dynamic threshold rule (beta) monitors your network traffic patterns and automatically adjusts the Distributed Denial of Service (DDoS) threshold based on traffic history. Network Flow (formerly Magic Network Monitoring) compares total traffic across all IP prefixes and addresses in the rule against the dynamic threshold, measured in bits or packets per second. If traffic exceeds the threshold, Network Flow sends an alert.
 
-Dynamic thresholds are calculated using a statistical measure called [Z-score](https://en.wikipedia.org/wiki/Standard_score) (also referred to as standard score). Review [How the dynamic rule threshold is calculated](#how-the-dynamic-rule-threshold-is-calculated) to learn more.
-
-Customers who send NetFlow and/or sFlow data to Cloudflare can configure dynamic threshold rules.
-
-A dynamic threshold rule can only be configured through [Cloudflare's Network Flow Rules API](/api/resources/magic_network_monitoring/subresources/rules/). Customers are unable to configure dynamic threshold rules in the Cloudflare dashboard.
+To use dynamic threshold rules, you must send NetFlow or sFlow data to Cloudflare. You can only configure dynamic threshold rules through the [Network Flow Rules API](/api/resources/magic_network_monitoring/subresources/rules/) — they are not available in the dashboard.
 
 ## Rule configuration fields
 
@@ -17,17 +13,17 @@ A dynamic threshold rule can only be configured through [Cloudflare's Network Fl
 | **Rule name** | Must be unique and cannot contain spaces. Supports characters `A-Z`, `a-z`, `0-9`, underscore (`_`), dash (`-`), period (`.`), and tilde (`~`). Maximum of 256 characters. |
 | **Rule type** | zscore |
 | **Target** | Can be defined in either bits per second or packets per second. |
-| **Sensitivity** | Z-Score sensitivity has three values: low, medium, and high. |
+| **Sensitivity** | Controls how easily traffic anomalies trigger alerts. Available values: low, medium, and high. Higher sensitivity triggers alerts on smaller deviations from normal traffic. |
 | **Auto-advertisement** | If you are a [Magic Transit On Demand](/magic-transit/on-demand) customer, you can enable this feature to automatically enable Magic Transit if the rule's dynamic threshold is triggered. Network Flow supports Magic Transit's supernet capability. To learn more refer to [Auto-Advertisement section](/network-flow/rules/#rule-auto-advertisement). |
-| **Rule IP prefix** | The IP prefix associated with the rule for monitoring traffic volume. Must be a CIDR (Classless Inter-Domain Routing) range such as `160.168.0.1/24`. The maximum is 5,000 unique CIDR entries. To learn more and review an example, refer to the [Rule IP prefixes](/network-flow/rules/#rule-ip-prefixes) section. |
+| **Rule IP prefix** | The IP prefix associated with the rule for monitoring traffic volume. Must be a CIDR range such as `160.168.0.1/24`. The maximum is 5,000 unique CIDR entries. To learn more and review an example, refer to the [Rule IP prefixes](/network-flow/rules/#rule-ip-prefixes) section. |
 
 ## API documentation
 
 To review an example API configuration call using CURL and the expected output for a successful response, go to the [Rules](/api/resources/magic_network_monitoring/subresources/rules/) section in the Network Flow API documentation.
 
 ## How the dynamic rule threshold is calculated
 
-Dynamic thresholds for this rule type use a statistical measure called Z-Score. The dynamic threshold for this rule will automatically adjust based on your traffic history as this rule uses statistical analysis to detect traffic anomalies. Z-Score compares short-term traffic patterns (five-minute time window) against long-term baselines (four-hour time window).
+Z-score compares short-term traffic patterns (five-minute window) against long-term baselines (four-hour window) to detect anomalies. The threshold adjusts automatically as your traffic history grows.
 
 Z-Score is calculated by using the following formula:
 

src/content/partials/networking-services/mnm/rules/rule-notifications.mdx

@@ -4,11 +4,9 @@
 
 import { Render, DashButton } from "~/components"
 
-After configuring one or multiple rule types in Network Flow (formerly Magic Network Monitoring), you can also choose to receive notifications via email, webhook, or PagerDuty when a rule is triggered.
+Network Flow (formerly Magic Network Monitoring) can notify you by email, webhook, or PagerDuty when a rule is triggered. When a rule detects a traffic anomaly, notifications alert your team so you can respond — or, if you use Magic Transit with auto-advertisement, Cloudflare can begin mitigating the attack automatically.
 
-You can configure multiple rule types and alerts together to create layers of DDoS protection based on your network environment and your security needs.
-
-You can read [Cloudflare's Notifications documentation](/notifications/) for more information on our notification platform including:
+For more information on the notification platform, refer to [Notifications documentation](/notifications/). You can also:
 
 - [Configure Cloudflare notifications](/notifications/get-started/)
 - [Configure PagerDuty](/notifications/get-started/configure-pagerduty/)
@@ -20,10 +18,10 @@ You can read [Cloudflare's Notifications documentation](/notifications/) for mor
 
 | Field | Description |
 | :---- | :---- |
-| **Notification name** | The name of the Network Flow notification for the rule type that was selected. |
+| **Notification name** | A label to identify this notification in your notifications list. |
 | **Description (optional)** | The description of the notification. |
-| **Webhooks** | The webhook(s) that will receive the notification. |
-| **Notification email** | The email(s) that will receive the notification. |
+| **Webhooks** | One or more webhooks to deliver the notification to. |
+| **Notification email** | One or more email addresses to deliver the notification to. |
 
 ## Rule Auto-Advertisement notifications
 

src/content/partials/networking-services/mnm/rules/s-flow-ddos-attack.mdx

@@ -2,15 +2,13 @@
 {}
 ---
 
-Network Flow (formerly Magic Network Monitoring) customers that send sFlow data to Cloudflare can receive alerts when a specific type of distributed denial-of-service (DDoS) attack is detected within their network traffic. Network Flow uses the same DDoS attack detection rules that protect Cloudflare's global network to generate these alerts.
+An sFlow DDoS attack rule (beta) alerts you when a DDoS attack is detected in your network traffic. Network Flow (formerly Magic Network Monitoring) uses the same DDoS detection rules that protect Cloudflare's global network to identify these attacks.
 
-Only customers that send sFlow data to Cloudflare can configure a sFlow DDoS attack rule.
-
-You can only configure an sFlow DDoS attack rule via Cloudflare's API. The Cloudflare dashboard does not currently support configuring sFlow DDoS attack rules.
+To use sFlow DDoS attack rules, you must send sFlow data to Cloudflare. You can only configure these rules through the [Network Flow Rules API](/api/resources/magic_network_monitoring/subresources/rules/) — they are not available in the dashboard.
 
 ## Send sFlow data from your network to Cloudflare
 
-You can export sFlow data of your network traffic to Cloudflare via Network Flow. There are [specific brands and models](/network-flow/routers/supported-routers/) of routers that are capable of generating sFlow data. Make sure to check the router specifications to ensure that it is able to export sFlow data. To configure sFlow exports to Network Flow, refer to [Configure sFlow](/network-flow/routers/sflow-config/).
+To send sFlow data to Cloudflare, your router must support sFlow exports. Refer to [Supported routers](/network-flow/routers/supported-routers/) to verify compatibility, and [Configure sFlow](/network-flow/routers/sflow-config/) for setup instructions.
 
 ## Rule configuration fields
 
@@ -20,7 +18,7 @@ You can export sFlow data of your network traffic to Cloudflare via Network Flow
 | **Rule type** | advanced_ddos |
 | **Prefix Match** | The field `prefix_match` determines how IP matches are handled. <br/><br/>**Subnet** (recommended): Automatically advertise if the attacked IPs are within a subnet of a public IP prefix that can be advertised by Magic Transit.<br/><br/>**Exact**: Automatically advertise if the attacked IPs are an exact match with a public IP prefix that can be advertised by Magic Transit.<br/><br/>**Supernet**: Automatically advertise if the attacked IPs are a supernet of a public IP prefix that can be advertised by Magic Transit. |
 | **Auto-advertisement** | If you are a [Magic Transit On Demand](/magic-transit/on-demand) customer, you can enable this feature to automatically enable Magic Transit if the rule's dynamic threshold is triggered. To learn more, refer to [Auto-advertisement](/network-flow/rules/#rule-auto-advertisement). |
-| **Rule IP prefix** | The IP prefix associated with the rule for monitoring traffic volume. Must be a Classless Inter-Domain Routing (CIDR) range such as `160.168.0.1/24`. The maximum is 5,000 unique CIDR entries. To learn more and see an example, refer to [Rule IP prefixes](/network-flow/rules/#rule-ip-prefixes). |
+| **Rule IP prefix** | The IP prefix associated with the rule for monitoring traffic volume. Must be a CIDR range such as `160.168.0.1/24`. The maximum is 5,000 unique CIDR entries. To learn more and see an example, refer to [Rule IP prefixes](/network-flow/rules/#rule-ip-prefixes). |
 
 ## API documentation
 

src/content/partials/networking-services/mnm/rules/static-threshold.mdx

@@ -4,9 +4,9 @@
 
 import { DashButton } from "~/components";
 
-A static threshold rule allows you to define a constant numeric threshold, in terms of bits or packets, for DDoS traffic monitoring. The total traffic across all IP prefixes and IP addresses in the rule is compared to the static rule threshold. If the total traffic exceeds the static rule threshold for the duration of the rule, then an alert is sent.
+A static threshold rule monitors your network traffic against a fixed threshold you define, measured in bits or packets per second. Network Flow (formerly Magic Network Monitoring) compares total traffic across all IP prefixes and addresses in the rule against this threshold. If traffic exceeds the threshold for the configured duration, Network Flow sends an alert.
 
-If you send NetFlow and/or sFlow data to Cloudflare, you can configure static threshold rules.
+To use static threshold rules, you must send NetFlow or sFlow data to Cloudflare.
 
 ## Rule configuration fields
 
@@ -18,33 +18,31 @@ If you send NetFlow and/or sFlow data to Cloudflare, you can configure static th
 | **Rule threshold** | The number of bits per second or packets per second for the rule alert. When this value is exceeded for the rule duration, an alert notification is sent. Minimum of `1` and no maximum. |
 | **Rule duration** | The amount of time in minutes the rule threshold must exceed to send an alert notification. Choose from the following values: `1`, `5`, `10`, `15`, `20`, `30`, `45`, or `60` minutes. |
 | **Auto-advertisement** | If you are a Magic Transit On Demand customer, you can enable this feature to automatically enable Magic Transit if the rule alert is triggered. Network Flow (formerly Magic Network Monitoring) supports Magic Transit's supernet capability. To learn more refer to [Auto-Advertisement section](#rule-auto-advertisement). |
-| **Rule IP prefix** | The IP prefix associated with the rule for monitoring traffic volume. Must be a CIDR (Classless Inter-Domain Routing) range such as `160.168.0.1/24`. Max is 5,000 unique CIDR entries. To learn more, refer to [Rule IP prefixes](#rule-ip-prefixes). |
+| **Rule IP prefix** | The IP prefix associated with the rule for monitoring traffic volume. Must be a CIDR range such as `160.168.0.1/24`. Max is 5,000 unique CIDR entries. To learn more, refer to [Rule IP prefixes](#rule-ip-prefixes). |
 
 ## API documentation
 
 To review an example static threshold rule, go to the [Rules](/api/resources/magic_network_monitoring/subresources/rules/) section in the Network Flow API documentation.
 
 ## Recommended rule configuration
 
-You can create Network Flow rules to monitor the traffic volume of your network for a set of IP prefixes and/or IP addresses. The traffic volume threshold for these rules is also set by you. If the traffic volume threshold is crossed, Network Flow will send an alert via email, webhook, or PagerDuty.
-
-Follow the guidelines in [Rule IP prefixes](#rule-ip-prefixes), [Rule threshold](#rule-threshold), and [Rule duration](#rule-duration) to create appropriate Network Flow rules and set accurate rule thresholds.
+Follow the guidelines in [Rule IP prefixes](#rule-ip-prefixes), [Rule threshold](#rule-threshold), and [Rule duration](#rule-duration) to create appropriate Network Flow rules and set accurate thresholds.
 
 ### Rule IP prefixes
 
-Cloudflare recommends that you start by creating one Network Flow rule for each public `/24` IP prefix within your network. It is helpful to include the range of the `/24` IP prefix to make it easier to find and filter for the rule in Network Flow analytics.
+Cloudflare recommends starting with one Network Flow rule for each public `/24` IP prefix in your network. Including the range of the `/24` prefix in the rule name makes it easier to find and filter in Network Flow analytics.
 
-As you become more familiar with the traffic patterns across each IP prefix, we encourage you to create more complex rules with IP prefixes that are smaller or larger than a `/24` prefix depending on your needs. You can also combine and monitor multiple IP prefixes within the same rule.
+As you become more familiar with traffic patterns across each prefix, create more specific rules with IP prefixes smaller or larger than `/24` depending on your needs. You can also combine multiple IP prefixes in a single rule.
 
 ### Rule threshold
 
 Follow the steps in [Initial rule configuration](#initial-rule-configuration) and [Setting the appropriate threshold](#setting-the-appropriate-threshold) to configure appropriate rule thresholds.
 
 #### Initial rule configuration
 
-When you initially configure Network Flow, you may not know the typical traffic volume patterns across each of your IP prefixes. Cloudflare recommends that you set a high rule threshold of either 10 Gbps (gigabits per second) or 10 Mpps (million packets per second) that is unlikely to be crossed during initial configuration.
+When you first configure Network Flow, you may not know the typical traffic patterns for each IP prefix. Set an initial threshold high enough that it is unlikely to trigger during setup — Cloudflare recommends 10 Gbps or 10 Mpps.
 
-This will allow you to collect initial information about the typical traffic volume for a Network Flow rule without receiving any alerts. After configuring your initial rules, you should begin monitoring for alerts and reviewing network traffic in Network Flow Analytics. Over time, each rule's threshold should be updated based on historical traffic data.
+This lets you collect baseline traffic data without receiving alerts. After configuring your initial rules, monitor for alerts and review traffic in Network Flow Analytics. Over time, update each rule's threshold based on historical traffic data.
 
 | Threshold type | Recommended rule threshold to collect initial data |
 | :---- 				 | :---- 																						  |
@@ -70,16 +68,16 @@ To find the maximum non-attack traffic for a one minute time interval over the p
 | :---- 						| :---- 	 | :---- 		 			|
 | _Monitoring Rule_ | _equals_ | `<RULE_NAME>`  |
 
-Once the rule filter is selected in Network Flow Analytics, you can check the historical traffic volume data for the rule over the selected time period. We recommend that you check your historical traffic volume data in increments of seven days since that is the largest window that shows one hour time intervals. You can select a custom seven-day time range in Network Flow Analytics by going to the top right corner of Network Flow analytics, opening the time window drop-down menu, and selecting **Custom range**.
+Once the rule filter is selected in Network Flow Analytics, you can check the historical traffic volume data for the rule over the selected time period. Cloudflare recommends reviewing historical data in seven-day increments, since that is the largest window that shows one-hour time intervals. To select a custom seven-day range, go to the top right corner of Network Flow analytics, open the time window drop-down menu, and select **Custom range**.
 
 You should review the selected seven-day time range and identify the largest traffic volume peak. Then, click and drag on the largest traffic peak to view the traffic volume data for a smaller time window. Continue until you are viewing the traffic volume data in one-minute intervals.
 
 Record the largest traffic volume peak for the rule in a spreadsheet, then repeat this process across 14-30 days of data. The rule threshold should be updated to be two times the largest traffic spike for a one minute time interval across 14-30 days of data. You should go through this process to set the threshold for each Network Flow rule.
 
 ### Rule duration
 
-Your IP prefixes may experience inconsistent spikes in traffic volume across one minute time intervals. We recommend that you set a rule duration of at least two minutes to reduce false positive alerts on short-term non-malicious traffic spikes. A rule duration of two minutes means that the traffic volume must be above the rule threshold for two minutes before an alert is fired.
+Your IP prefixes may experience inconsistent spikes across one-minute intervals. Set a rule duration of at least two minutes to reduce false positive alerts from short-term non-malicious traffic spikes. A two-minute duration means traffic must stay above the threshold for two minutes before an alert fires.
 
 ### Adjusting rules over time
 
-After you update your first set of rule thresholds based on historical traffic data, it will be important to monitor for Network Flow alerts to check if the rule thresholds are appropriate. You are encouraged to adjust the rule thresholds and the duration over time to find the ideal alert sensitivity level for your specific network environment.
+After updating your first set of thresholds based on historical data, monitor for Network Flow alerts to verify the thresholds are appropriate. Adjust thresholds and duration over time to find the right alert sensitivity for your network environment.

src/content/partials/networking-services/mnm/tutorials/ddos-testing-guide.mdx

@@ -2,7 +2,7 @@
 {}
 ---
 
-To test Cloudflare's Network Flow (formerly Magic Network Monitoring) in a repeatable manner, devise a simulated DDoS attack. At a high level, you need to:
+To test Network Flow (formerly Magic Network Monitoring) in a repeatable manner, simulate a DDoS attack. At a high level, you need to:
 
 1. Select and install a trusted, open source DDoS simulation tool.
 2. Conduct a small DDoS test attack in a safe test environment.
@@ -14,7 +14,7 @@ You need to contact Cloudflare to obtain permission before conducting a DDoS tes
 - Your property is hosted in Cloudflare.
 - Internet traffic goes through Cloudflare before reaching your property.
 
-Enterprise customers with Network Flow enabled must contact their Cloudflare Account Manager before starting DDoS testing, even if the property is not hosted in Cloudflare.
+If you are an Enterprise customer with Network Flow enabled, contact your Cloudflare Account Manager before starting DDoS testing, even if the property is not hosted in Cloudflare.
 
 Refer to [Simulating test DDoS attacks](/ddos-protection/reference/simulate-ddos-attack/) for more information.