From bc99eb148a5339cd32266b13aba8d7a0ce97893a Mon Sep 17 00:00:00 2001
From: Pedro Sousa <680496+pedrosousa@users.noreply.github.com>
Date: Mon, 18 Nov 2024 10:54:07 +0000
Subject: [PATCH] [Docs] Fix some anchor links
---
.../magic-transit-with-cdn.mdx | 72 ++++++++++---------
src/content/docs/queues/get-started.mdx | 8 +--
src/content/docs/zaraz/index.mdx | 40 +++++++----
3 files changed, 68 insertions(+), 52 deletions(-)
diff --git a/src/content/docs/byoip/service-bindings/magic-transit-with-cdn.mdx b/src/content/docs/byoip/service-bindings/magic-transit-with-cdn.mdx
index 2a2b7fb08871772..f37f4abf7d303c1 100644
--- a/src/content/docs/byoip/service-bindings/magic-transit-with-cdn.mdx
+++ b/src/content/docs/byoip/service-bindings/magic-transit-with-cdn.mdx
@@ -4,7 +4,6 @@ pcx_content_type: tutorial
sidebar:
order: 3
label: Magic Transit with CDN
-
---
import { Details, Example, TabItem, Tabs, GlossaryTooltip } from "~/components";
@@ -21,24 +20,24 @@ It is important to note that traffic routed to the CDN pipeline is protected at
Although it is possible to add discrete bindings for non-contiguous CIDR blocks, implementing service bindings through an **aggregated** CIDR block is **strongly** recommended as it is more efficient.
-
+
- **Magic Transit protected prefix:** `203.0.113.100/24`
+**Magic Transit protected prefix:** `203.0.113.100/24`
- **IPs to upgrade to the CDN:**
+**IPs to upgrade to the CDN:**
- `203.0.113.16`
- `203.0.113.17`
- `203.0.113.18`
- `203.0.113.19`
- `203.0.113.20`
- `203.0.113.21`
- `203.0.113.22`
- `203.0.113.23`
+`203.0.113.16`
+`203.0.113.17`
+`203.0.113.18`
+`203.0.113.19`
+`203.0.113.20`
+`203.0.113.21`
+`203.0.113.22`
+`203.0.113.23`
- Add one discrete CDN service binding for `203.0.113.16` with a `/29` netmask.
+Add one discrete CDN service binding for `203.0.113.16` with a `/29` netmask.
-
+
Once a service binding is created (or deleted), it will take **four** to **six** hours to propagate across Cloudflare's global network. Services for the IP addresses in scope will likely be disrupted during this window.
@@ -56,14 +55,14 @@ This guide assumes that the prefix is tied to a single Cloudflare account that h
At this point, continuing the [example](#before-you-begin), you should have a mapping similar to the following:
-| Variables | Description |
-|-------------------------------|----------------------------------------------------|
-| `{service_id}` | The ID of the CDN service within Cloudflare.
Example: `969xxxxxxxx000xxx0000000x00001bf` |
-| `{prefix_id}` | The ID of the Magic Transit protected prefix (`203.0.113.100/24`) you want to configure.
Example: `6b25xxxxxxx000xxx0000000x0000cfc` |
+| Variables | Description |
+| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `{service_id}` | The ID of the CDN service within Cloudflare.
Example: `969xxxxxxxx000xxx0000000x00001bf` |
+| `{prefix_id}` | The ID of the Magic Transit protected prefix (`203.0.113.100/24`) you want to configure.
Example: `6b25xxxxxxx000xxx0000000x0000cfc` |
-4. To confirm you currently only have a Magic Transit service binding and that it spans across your entire prefix, make a `GET` request to the [List Service Bindings](/api/operations/ip-address-management-service-bindings-list-service-bindings) endpoint. Replace the `{prefix_id}` in the URI path by the actual prefix ID you got from the previous step.
+4. To confirm you currently only have a Magic Transit service binding and that it spans across your entire prefix, make a `GET` request to the [List Service Bindings](/api/operations/ip-address-management-service-bindings-list-service-bindings) endpoint. Replace the `{prefix_id}` in the URI path by the actual prefix ID you got from the previous step.
@@ -117,6 +116,7 @@ In the response body, the initial provisioning state should be `provisioning`.
}
}
```
+
You can periodically check the service binding status using the [List Service Bindings](/api/operations/ip-address-management-service-bindings-list-service-bindings) endpoint.
@@ -127,9 +127,8 @@ Once you have configured your IPs to have CDN service, you can use
+
-| Type | Name | IP address | Proxy status | TTL |
-| --- | --- | --- | --- | --- |
-| `A` | `www` | `203.0.113.150` | `Proxied` | `Auto` |
+| Type | Name | IP address | Proxy status | TTL |
+| ---- | ----- | --------------- | ------------ | ------ |
+| `A` | `www` | `203.0.113.150` | `Proxied` | `Auto` |
At this point, if an address map for a zone `example.com` specifies that Cloudflare should use `203.0.113.100` for proxied records and the above record exists in the same zone, you can expect the following:
1. Cloudflare responds to DNS requests with `203.0.113.100`.
-2. Cloudflare proxies requests through the CDN and then routes the requests via [GRE](/magic-transit/reference/tunnels/#gre-and-ipsec-tunnels) or [CNI](/magic-transit/network-interconnect/) to the origin server `203.0.113.150` (Magic Transit protected prefix).
+2. Cloudflare proxies requests through the CDN and then routes the requests via [GRE](/magic-transit/reference/tunnels/) or [CNI](/magic-transit/network-interconnect/) to the origin server `203.0.113.150` (Magic Transit protected prefix).
3. Depending on whether Magic Transit is implemented with [direct server return model or with Magic Transit egress](/magic-transit/how-to/configure-tunnels/#bidirectional-vs-unidirectional-health-checks), the origin server responds back to Cloudflare either:
- * Directly over the Internet in a Magic Transit direct server return model
- * Back through the Magic GRE tunnel(s) in a Magic Transit egress model
+ - Directly over the Internet in a Magic Transit direct server return model
+ - Back through the Magic GRE tunnel(s) in a Magic Transit egress model
+
4. As the HTTP response egresses the Cloudflare network back to the client side, the source IP address of the response becomes `203.0.113.100` (the IP address that the HTTP request originally landed on).
+
:::note
Having the same IP address as ingress IP (defined in the address map) and origin IP (listed in the DNS record) will not cause any loops.
:::
-
+
+
Assuming `203.0.113.100` was also the origin IP, the DNS record would look like the following:
-| Type | Name | IP address | Proxy status | TTL |
-| --- | --- | --- | --- | --- |
-| `A` | `www` | `203.0.113.100` | `Proxied` | `Auto` |
+| Type | Name | IP address | Proxy status | TTL |
+| ---- | ----- | --------------- | ------------ | ------ |
+| `A` | `www` | `203.0.113.100` | `Proxied` | `Auto` |
@@ -220,5 +222,5 @@ Assuming `203.0.113.100` was also the origin IP, the DNS record would look like
Leverage other features according to your needs:
- [Cache](/cache/)
-- [WAF custom rules](/waf/custom-rules/#custom-rules)
-- [Security analytics](/waf/analytics/security-analytics/#security-analytics)
\ No newline at end of file
+- [WAF custom rules](/waf/custom-rules/)
+- [Security analytics](/waf/analytics/security-analytics/)
diff --git a/src/content/docs/queues/get-started.mdx b/src/content/docs/queues/get-started.mdx
index e6ef7656c161a31..dbeb13aaf2ceecf 100644
--- a/src/content/docs/queues/get-started.mdx
+++ b/src/content/docs/queues/get-started.mdx
@@ -76,7 +76,7 @@ To create a binding, open your newly generated `wrangler.toml` configuration fil
binding = "MY_QUEUE"
```
-Replace `MY-QUEUE-NAME` with the name of the queue you created in [step 3](/queues/get-started/#3-create-a-queue). Next, replace `MY_QUEUE` with the name you want for your `binding`. The binding must be a valid JavaScript variable name. This is the variable you will use to reference this queue in your Worker.
+Replace `MY-QUEUE-NAME` with the name of the queue you created in [step 2](/queues/get-started/#2-create-a-queue). Next, replace `MY_QUEUE` with the name you want for your `binding`. The binding must be a valid JavaScript variable name. This is the variable you will use to reference this queue in your Worker.
### Write your producer Worker
@@ -193,7 +193,7 @@ To connect your queue to your consumer Worker, open your `wrangler.toml` file an
max_batch_timeout = 5 # optional: defaults to 5 seconds
```
-Replace `MY-QUEUE-NAME` with the queue you created in [step 3](/queues/get-started/#3-create-a-queue).
+Replace `MY-QUEUE-NAME` with the queue you created in [step 2](/queues/get-started/#2-create-a-queue).
In your consumer Worker, you are using queues to auto batch messages using the `max_batch_size` option and the `max_batch_timeout` option. The consumer Worker will receive messages in batches of `10` or every `5` seconds, whichever happens first.
@@ -219,7 +219,7 @@ Run `wrangler tail` to start waiting for our consumer to log the messages it rec
npx wrangler tail
```
-With `wrangler tail` running, open the Worker URL you opened in [step 4](/queues/get-started/#4-set-up-your-producer-worker).
+With `wrangler tail` running, open the Worker URL you opened in [step 3](/queues/get-started/#3-set-up-your-producer-worker).
You should receive a `Success` message in your browser window.
@@ -229,7 +229,7 @@ With `wrangler tail` running, your consumer Worker will start logging the reques
If you refresh less than 10 times, it may take a few seconds for the messages to appear because batch timeout is configured for 10 seconds. After 10 seconds, messages should arrive in your terminal.
-If you get errors when you refresh, check that the queue name you created in [step 3](/queues/get-started/#3-create-a-queue) and the queue you referenced in your `wrangler.toml` file is the same. You should ensure that your producer Worker is returning `Success` and is not returning an error.
+If you get errors when you refresh, check that the queue name you created in [step 2](/queues/get-started/#2-create-a-queue) and the queue you referenced in your `wrangler.toml` file is the same. You should ensure that your producer Worker is returning `Success` and is not returning an error.
By completing this guide, you have now created a queue, a producer Worker that publishes messages to that queue, and a consumer Worker that consumes those messages from it.
diff --git a/src/content/docs/zaraz/index.mdx b/src/content/docs/zaraz/index.mdx
index d365a9c3c03d82d..bd19d5e0e496a68 100644
--- a/src/content/docs/zaraz/index.mdx
+++ b/src/content/docs/zaraz/index.mdx
@@ -6,41 +6,53 @@ sidebar:
head:
- tag: title
content: Cloudflare Zaraz
-
---
-import { CardGrid, Description, Feature, LinkTitleCard, Plan, Render } from "~/components"
+import {
+ CardGrid,
+ Description,
+ Feature,
+ LinkTitleCard,
+ Plan,
+ Render,
+} from "~/components";
-Offload third-party tools and services to the cloud and improve the speed and security of your website.
+Offload third-party tools and services to the cloud and improve the speed and security of your website.
+
-***
+---
## Features
-
-You can add many third-party tools to Zaraz, and offload them from your website.
+
+ You can add many third-party tools to Zaraz, and offload them from your
+ website.
-
-You can add Custom Managed Components to Zaraz and run them as a tool.
+
+ You can add Custom Managed Components to Zaraz and run them as a tool.
-Zaraz provides a client-side web API that you can use anywhere inside the `` tag of a page.
+Zaraz provides a client-side web API that you can use anywhere inside the `` tag of a page.
-Zaraz provides a Consent Management platform to help you address and manage required consents.
+ Zaraz provides a Consent Management platform to help you address and manage
+ required consents.
-***
+---
## More resources
@@ -48,12 +60,14 @@ Zaraz provides a Consent Management platform to help you address and manage requ
-If you have any comments, questions, or bugs to report, contact the Zaraz team on their Discord channel.
+If you have any comments, questions, or bugs to report, contact the Zaraz team on their Discord channel.
+
-Engage with other users and the Zaraz team on Cloudflare support forum.
+Engage with other users and the Zaraz team on Cloudflare support forum.
+