You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/content/docs/byoip/service-bindings/magic-transit-with-cdn.mdx
+37-35Lines changed: 37 additions & 35 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,6 @@ pcx_content_type: tutorial
4
4
sidebar:
5
5
order: 3
6
6
label: Magic Transit with CDN
7
-
8
7
---
9
8
10
9
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
21
20
22
21
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.
Add one discrete CDN service binding for `203.0.113.16` with a `/29` netmask.
38
+
Add one discrete CDN service binding for `203.0.113.16` with a `/29` netmask.
40
39
41
-
</Details>
40
+
</Details>
42
41
43
42
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.
44
43
@@ -56,14 +55,14 @@ This guide assumes that the prefix is tied to a single Cloudflare account that h
56
55
57
56
At this point, continuing the [example](#before-you-begin), you should have a mapping similar to the following:
|`{service_id}`| The ID of the CDN service within Cloudflare. <br /><br /> Example: `969xxxxxxxx000xxx0000000x00001bf`|
62
-
|`{prefix_id}`| The ID of the Magic Transit protected prefix (`203.0.113.100/24`) you want to configure. <br /><br /> Example: `6b25xxxxxxx000xxx0000000x0000cfc`|
|`{service_id}`| The ID of the CDN service within Cloudflare. <br /><br /> Example: `969xxxxxxxx000xxx0000000x00001bf`|
61
+
|`{prefix_id}`| The ID of the Magic Transit protected prefix (`203.0.113.100/24`) you want to configure. <br /><br /> Example: `6b25xxxxxxx000xxx0000000x0000cfc`|
63
62
64
63
</Example>
65
64
66
-
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.
65
+
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.
67
66
68
67
<Example>
69
68
@@ -117,6 +116,7 @@ In the response body, the initial provisioning state should be `provisioning`.
117
116
}
118
117
}
119
118
```
119
+
120
120
</Example>
121
121
122
122
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 <GlossaryTool
127
127
128
128
You can choose between two different scopes:
129
129
130
-
* Account-level: uses the address map for all proxied DNS records across all of the zones within an account.
131
-
132
-
* Zone-level: uses the address map for all proxied DNS records within a zone.
130
+
- Account-level: uses the address map for all proxied DNS records across all of the zones within an account.
131
+
- Zone-level: uses the address map for all proxied DNS records within a zone.
133
132
134
133
:::note
135
134
If you need to map only specific subdomains (and not all proxied DNS records) to specific IP addresses, you can use a [Subdomain setup](/dns/zone-setups/subdomain-setup/).
@@ -185,33 +184,36 @@ As you create the necessary DNS records, [Total TLS](/ssl/edge-certificates/addi
185
184
186
185
While the DNS record proxy status and address map will determine how Cloudflare's authoritative DNS responds to requests for your hostnames, the IP addresses specified in `A`/`AAAA` records will determine [how Cloudflare reaches the configured origin](/fundamentals/concepts/how-cloudflare-works/#how-cloudflare-works-as-a-reverse-proxy).
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:
195
194
196
195
1. Cloudflare responds to DNS requests with `203.0.113.100`.
197
-
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).
196
+
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).
198
197
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:
199
198
200
-
* Directly over the Internet in a Magic Transit direct server return model
201
-
* Back through the Magic GRE tunnel(s) in a Magic Transit egress model
199
+
- Directly over the Internet in a Magic Transit direct server return model
200
+
- Back through the Magic GRE tunnel(s) in a Magic Transit egress model
201
+
202
202
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).
203
203
204
204
</Details>
205
+
205
206
:::note
206
207
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.
207
208
:::
208
-
<Detailsheader="Example" >
209
+
210
+
<Detailsheader="Example">
209
211
210
212
Assuming `203.0.113.100` was also the origin IP, the DNS record would look like the following:
Copy file name to clipboardExpand all lines: src/content/docs/queues/get-started.mdx
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -76,7 +76,7 @@ To create a binding, open your newly generated `wrangler.toml` configuration fil
76
76
binding = "MY_QUEUE"
77
77
```
78
78
79
-
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.
79
+
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.
80
80
81
81
### Write your producer Worker
82
82
@@ -193,7 +193,7 @@ To connect your queue to your consumer Worker, open your `wrangler.toml` file an
193
193
max_batch_timeout = 5# optional: defaults to 5 seconds
194
194
```
195
195
196
-
Replace `MY-QUEUE-NAME` with the queue you created in [step 3](/queues/get-started/#3-create-a-queue).
196
+
Replace `MY-QUEUE-NAME` with the queue you created in [step 2](/queues/get-started/#2-create-a-queue).
197
197
198
198
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.
199
199
@@ -219,7 +219,7 @@ Run `wrangler tail` to start waiting for our consumer to log the messages it rec
219
219
npx wrangler tail
220
220
```
221
221
222
-
With `wrangler tail` running, open the Worker URL you opened in [step 4](/queues/get-started/#4-set-up-your-producer-worker).
222
+
With `wrangler tail` running, open the Worker URL you opened in [step 3](/queues/get-started/#3-set-up-your-producer-worker).
223
223
224
224
You should receive a `Success` message in your browser window.
225
225
@@ -229,7 +229,7 @@ With `wrangler tail` running, your consumer Worker will start logging the reques
229
229
230
230
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.
231
231
232
-
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.
232
+
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.
233
233
234
234
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.
0 commit comments