Apply suggestions from code review

Co-authored-by: Maddy <[email protected]>

Author: marciocloudflare

src/content/docs/learning-paths/data-center-protection/concepts/what-is-magic-transit.mdx

@@ -7,11 +7,11 @@ sidebar:
 
 Magic Transit is a network security and performance solution that offers Distributed Denial-of-Service (DDoS) protection, traffic acceleration, and more for on-premise, cloud-hosted, and hybrid networks.
 
-Magic Transit works at Layer 3 of the OSI model, protecting entire IP networks from DDoS attacks. Instead of relying on local infrastructure that can be overwhelmed by large DDoS attacks, Magic Transit uses the [global Cloudflare Network](https://www.cloudflare.com/network/) to ingest and mitigate attacks close to their source.
+Magic Transit works at Layer 3 of the [OSI model](https://www.cloudflare.com/en-gb/learning/ddos/glossary/open-systems-interconnection-model-osi/), protecting entire IP networks from DDoS attacks. Instead of relying on local infrastructure that can be overwhelmed by large DDoS attacks, Magic Transit uses the [global Cloudflare Network](https://www.cloudflare.com/network/) to ingest and mitigate attacks close to their source.
 
 Magic Transit delivers its connectivity, security, and performance benefits by serving as the front door to your IP network. This means it accepts IP packets destined for your network, processes them, and then forwards them to your origin infrastructure.
 
-The Cloudflare network uses Border Gateway Protocol (BGP) to announce your company's IP address space, extending your network presence globally, and [anycast](/magic-transit/reference/tunnels/#anycast) to to absorb and distribute attack traffic.
+The Cloudflare network uses Border Gateway Protocol (BGP) to announce your company's IP address space, extending your network presence globally, and [anycast](/magic-transit/reference/tunnels/#anycast) to absorb and distribute attack traffic.
 
 Once packets hit Cloudflare's network, traffic is inspected for attacks, filtered, steered, accelerated, and sent onward to your origin. Magic Transit users have two options for their implementation: ingress traffic or ingress and egress traffic. Users with an egress implementation will need to set up policy-based routing (PBR) or ensure default routing on their end forwards traffic to Cloudflare via tunnels.
 

src/content/docs/learning-paths/data-center-protection/post-prefix-fine-tuning.mdx

@@ -21,7 +21,7 @@ For both [Advanced TCP Protection](/ddos-protection/advanced-ddos-systems/overvi
 
 Once all your prefixes are advertised and/or once all your expected traffic is cut over to the Magic Transit prefixes, reach out to your Cloudflare account team to have the thresholds configured.
 
-You can then change the mode on your Advanced TCP and DNS protections from `monitoring` to `mitigation`. You can also  create a filter for `monitoring` mode for any traffic flows for which you see false positives. Try to keep this specific so that the protection is enabled for other inbound traffic flows.
+You can then change the mode on your Advanced TCP and DNS protections from `monitoring` to `mitigation`. You can also create a filter for `monitoring` mode for any traffic flows for which you see false positives. Try to keep this specific so that the protection is enabled for other inbound traffic flows.
 
 ## Magic Firewall rules
 
@@ -33,7 +33,7 @@ Refer to Magic Firewall's [best practices](/magic-firewall/best-practices/) for
 
 ## Alerts for Magic Tunnel health checks and DDoS
 
-- Ensure all teams/members needing to receive these are getting the alerts
+- Ensure all teams/members needing to receive these are getting the alerts.
 - Check the Magic Tunnel Health Check Alert configuration for Sensitivity and Alert interval and tunnels in-scope.
 - Refer to [Set up Magic Tunnel health alerts](/learning-paths/data-center-protection/enable-notifications/#set-up-magic-tunnel-health-alerts) and [DDoS alerts](/ddos-protection/reference/alerts/) for more details.
 

src/content/docs/learning-paths/data-center-protection/troubleshooting.mdx

@@ -12,7 +12,7 @@ sidebar:
 **Potential solutions**:
 - Run a traceroute from the Magic Transit prefix out to the destination IP on the Internet.
 - Verify on your CPE there is no uRPF strict mode or anti-spoofing which would drop this traffic.
-- Verify that your CPE is not enforcing uRPF strict mode or other anti-spoofing mechanisms that could drop this traffic.. If they do, ask them to change this to loose mode.
+- Verify that your CPE is not enforcing uRPF strict mode or other anti-spoofing mechanisms that could drop this traffic. If they do, ask them to change this to loose mode.
 - Other workarounds:
 	- If you have a less-specific prefix then you can continue to advertise this to your ISP while Cloudflare advertises a more-specific prefix. For example, Cloudflare advertises a `/24` to the Internet; you advertise its parent `/23` to your ISP.
 	- You can continue advertising a `/24` to your ISP, but this is not recommended, as inbound traffic from your ISP would bypass Cloudflare and therefore not benefit from Magic Transit DDoS protection.
@@ -45,7 +45,7 @@ For example, devices cannot browse to a server which is hosted on the Magic Tran
 
 If you suspect that Cloudflare mitigations might be dropping legitimate traffic to your Magic Transit prefix:
 
-1. Go to the the [Cloudflare dashboard](https://dash.cloudflare.com/) and select your account.
+1. Go to the [Cloudflare dashboard](https://dash.cloudflare.com/) and select your account.
 2. Go to **Analytics & Logs** > **Network Analytics**.
 3. In the **All traffic** tab select **Add filter** to configure the filters for the traffic-flow in question — like source IP, destination IP and protocol/ports.
 4. Check the analytics results to determine which Cloudflare mitigation system has dropped the traffic — for example, DDoS Managed Rules, Advanced TCP/DNS Protection or Magic Firewall.

src/content/partials/networking-services/magic-transit/get-started.mdx

@@ -83,7 +83,7 @@ If you are using a [Cloudflare IP](#ips), you do not need to verify your IRR ent
 
 You can also use the Resource Public Key Infrastructure (RPKI) as an additional option to validate your prefixes. RPKI is a [security framework method](https://blog.cloudflare.com/rpki/) that associates a route with an autonomous system. It uses cryptography to validate the information before being passed onto the routers.
 
-If you operate a network (ISP, cloud provider, enterprise, etc.), using RPKI ensures that your IP prefixes are correctly recognized. This prevents service disruptions and protects your brand's reputation. Without RPKI, attackers could announce your IP space, misdirect your traffic, and potentially harm your business.
+If you operate a network (ISP, cloud provider, enterprise, and others.), using RPKI ensures that your IP prefixes are correctly recognized. This prevents service disruptions and protects your brand's reputation. Without RPKI, attackers could announce your IP space, misdirect your traffic, and potentially harm your business.
 
 To check your prefixes, you can use [Cloudflare's RPKI Portal](https://rpki.cloudflare.com/?view=validator).
 
@@ -145,7 +145,7 @@ Refer to [Maximum transmission unit and maximum segment size](/magic-transit/ref
 { props.magicWord === "Learning Path" && (
   <>
 	<AnchorHeading title="BGP for Magic Transit prefix advertisement control (optional)" depth={2} />
-	<p>If you want to use <a href="/magic-transit/how-to/advertise-prefixes/#border-gateway-protocol-bgp-control-for-advertisements-optional">BGP for prefix advertisement control</a> then you need to let the account team know the IPs and ASN for your customer premises equipment (CPE)  to use for the BGP peerings. You should allow around five working days for Cloudflare to add this to our Route Reflectors.</p>
+	<p>If you want to use <a href="/magic-transit/how-to/advertise-prefixes/#border-gateway-protocol-bgp-control-for-advertisements-optional">BGP for prefix advertisement control</a> then you need to let the account team know the IPs and ASN for your customer premises equipment (CPE) to use for the BGP peerings. You should allow around five working days for Cloudflare to add this to our Route Reflectors.</p>
   </>
   )
 }