cloudflare · aaron-ruby-df · Oct 29, 2020
@@ -17,7 +17,7 @@ Cloudflare encapsulates the ICMP reply packet and transmits the probe across the
 
 Every Cloudflare edge server configured to process your traffic sends a tunnel health check probe every 60 seconds. When a probe attempt fails, each server detecting the failure quickly probes up to 2 more times to obtain an accurate result.
 
-<Aside>
+<Aside type='note' header='Note'>
 
 To avoid control plane policies enforced by the origin network, tunnel health checks use an encapsulated ICMP reply (rather than an ICMP echo request). To use echo request packets, please contact your Cloudflare account team.
 
@@ -41,7 +41,7 @@ Magic Transit steers traffic to tunnels based on priorities you set when you [as
 
 Tunnel routes with lower values have priority over those with higher values.
 
-<Aside>
+<Aside type='note' header='Note'>
 
 Since Cloudflare does not synchronize the health checks among edge servers and the Internet is not homogenous, Cloudflare edge servers may be able to reach the origin infrastructure from some locations at a given time but not others.
 

@@ -54,7 +54,7 @@ Because ECMP is probabilistic, the algorithm routes roughly the same number of f
 
 For example, consider a scenario with many very low-bandwidth TCP connections and one very high-bandwidth TCP connection. Packets for the high-bandwidth connection have the same hash and thus use the same tunnel. As a result, that tunnel utilizes greater bandwidth than the others.
 
-<Aside>
+<Aside type='note' header='Note'>
 
 Magic Transit supports a "weight" field that you can apply to a tunnel so that a specified percentage of traffic uses that tunnel rather than other equal-cost tunnels.
 

@@ -10,7 +10,7 @@ This diagram illustrates the flow of traffic with Magic Transit:
 
 ![GRE tunnel flow](../static/mt-gre-tunnel-flow.png)
 
-<Aside>
+<Aside type='note' header='Note'>
 
 Egress packets are routed by your ISP interface, not Cloudflare.
 
@@ -24,7 +24,7 @@ This diagram illustrates how Magic Transit encapsulates packets at the Cloudflar
 
 ![Encapsulation diagram](../static/magic-transit-anycast-1.png)
 
-<Aside>
+<Aside type='note' header='Note'>
 
 To accommodate the additional header data introduced by encapsulation, the maximum segment size (MSS) must be adjusted so that packets comply with the standard Internet routable maximum transmission unit (MTU), which is 1500 bytes.
 

@@ -186,7 +186,7 @@ _ah, ax.25, dccp, ddp, egp, eigrp, encap, esp, etherip, fc, ggp, gre, hip, hmp,
   - Packet length
   - Bit field match (Cloudflare is able to match on any part of an IP packet to apply, allow, or drop rules)
 
-<Aside>
+<Aside type='warning' header='Important'>
 
 When you or your end users are using other Cloudflare services (eg. CDN, Spectrum) that proxy traffic, be aware of the following:
 

@@ -51,7 +51,7 @@ These routing changes return any traffic generated within the Cloudflare edge ne
 
 You control the edge router advertisement, which dictates whether Cloudflare’s edge network advertises your prefixes. Advertisement is activated at the go-live call, routing traffic via Cloudflare and the GRE tunnels to your data center(s).
 
-<Aside>
+<Aside type='warning' header='Important'>
 
 It is critical that you put the appropriate MSS clamps in place before routing changes are made. Failure to apply an MSS clamp may result in dropped packets and hard-to-debug connectivity issues.
 

@@ -9,38 +9,34 @@ type: table
 
 ## Anycast edge IP addresses
 
-Cloudflare will assign 2 Anycast IP addresses shortly after the [onboarding kickoff call](/set-up/onboarding). Use these Anycast edge IPs as the GRE tunnel destinations on your data center routers/endpoints.
+Cloudflare will assign 2 Anycast IP addresses shortly after your [onboarding](/set-up/onboarding)  kickoff call. Use these Anycast edge addresses as the GRE tunnel destinations on your data center routers/endpoints.
 
 ## Generic Routing Encapsulation (GRE)
 
 Cloudflare recommends 2 GRE tunnels for each ISP and data center router combination, one per Anycast IP.
 
 To configure the GRE tunnel(s) between Cloudflare and your data center(s), you must provide the following data for each tunnel:
 
-* **Customer edge IP address**—A public Internet routable IP address that is outside of the prefixes Cloudflare will advertise on your behalf. These are generally IP addresses provided by your ISP. If you are using a physical or virtual connection ([Cloudflare Network Interconnect](https://developers.cloudflare.com/network-interconnect/about)), leave this section blank - Cloudflare will provide this IP.
+* **Customer edge IP address**—A public Internet routable IP address that is outside of the prefixes Cloudflare will advertise on your behalf. These are generally IP addresses provided by your ISP. If you intend to use a physical or virtual connection ([Cloudflare Network Interconnect](https://developers.cloudflare.com/network-interconnect/about)), you do not need to provide edge addresses—Cloudflare will provide them.
 * **Private subnet**—A 31-bit subnet (/31 in CIDR notation) supporting 2 hosts, one for each side of the tunnel. Select the subnet from the following private IP space:
-  * 10.0.0.0 – 10.255.255.255
-  * 172.16.0.0 – 172.31.255.255
-  * 192.168.0.0 – 192.168.255.255
+  * 10.0.0.0–10.255.255.255
+  * 172.16.0.0–172.31.255.255
+  * 192.168.0.0–192.168.255.255
 * **Private IP addresses**—The private IP address assigned to the **Cloudflare** and **customer** sides of the tunnel
 
 For an example GRE tunnel configuration, refer to this table:
 
-### Example GRE tunnel IPs
-
 </ContentColumn>
 
-<TableWrap>
-
 <table>
   <thead>
     <tr>
-      <th><span style="white-space: nowrap">GRE tunnel</span></th>
-      <th><span style="white-space: nowrap">Customer edge IP</span></th>
-      <th><span style="white-space: nowrap">Cloudflare Anycast IP</span></th>
-      <th><span style="white-space: nowrap">Private subnet</span></th>
-      <th><span style="white-space: nowrap">Customer private IP</span></th>
-      <th><span style="white-space: nowrap">Cloudflare private IP</span></th>
+      <th style='min-width:70px'>GRE tunnel</th>
+      <th style='min-width:125px'>Customer edge IP</th>
+      <th style='min-width:100px'>Anycast IP</th>
+      <th style='min-width:130px'>Private subnet</th>
+      <th style='min-width:115px'>Customer private IP</th>
+      <th style='min-width:100px'>Cloudflare private IP</th>
     </tr>
   </thead>
   <tbody>
@@ -79,4 +75,121 @@ For an example GRE tunnel configuration, refer to this table:
   </tbody>
 </table>
 
-</TableWrap>
+<ContentColumn>
+
+## Scoped routes for GRE tunnels
+
+To reduce latency for your GRE tunnel configurations, especially if you operate your own Anycast network, Cloudflare can steer your traffic by scoping it to specific Cloudflare data center regions.
+
+Valid Cloudflare regions include AFR, APAC, EEUR, ENAM, ME, OC, SAM, WEUR, and WNAM.
+
+To configure scoping for your traffic, you must provide Cloudflare with GRE tunnel data for each Cloudflare region.
+
+For an example of scoping configuration data, see the table below. It lists GRE tunnels and their associated Cloudflare region codes:
+
+<table>
+ <thead>
+  <tr>
+   <th>GRE tunnel</th>
+   <th>Region code</th>
+   </tr>
+  </thead>
+  <tbody>
+  <tr>
+     <td>GRE_1_IAD</td>
+     <td>AFR</td>
+  </tr>
+  <tr>
+    <td>GRE_2_IAD</td>
+    <td>EEUR</td>
+  </tr>
+  <tr>
+    <td>GRE_3_ATL</td>
+    <td>ENAM</td>
+  </tr>
+  <tr>
+    <td>GRE_4_ATL</td>
+    <td>ME</td>
+    </tr>
+</tbody>
+</table>
+
+Cloudflare has 13 geographic regions across the world. This table lists region codes and their associated regions:
+
+<table>
+  <thead>
+    <tr>
+      <th>Region code</th>
+      <th>Region</th>
+    </tr>
+  </thead>
+  <tbody>
+    <tr>
+    <td>WNAM</td>
+    <td>Western North America
+    </td>
+    </tr>
+    <tr>
+    <td>ENAM</td>
+    <td>Eastern North America
+    </td>
+    </tr>
+    <tr>
+    <td>WEU</td>
+    <td>Western Europe
+    </td>
+    </tr>
+    <tr>
+    <td>EEU</td>
+    <td>Eastern Europe
+    </td>
+    </tr>
+    <tr>
+    <td>NSAM</td>
+    <td>Northern South America
+    </td>
+    </tr>
+    <tr>
+    <td>SSAM</td>
+    <td>Southern South America
+    </td>
+    </tr>
+    <tr>
+    <td>OC</td>
+    <td>Oceania
+    </td>
+    </tr>
+    <tr>
+    <td>ME</td>
+    <td>Middle East
+    </td>
+    </tr>
+    <tr>
+    <td>NAF</td>
+    <td>Northern Africa
+    </td>
+    </tr>
+    <tr>
+    <td>SAF</td>
+    <td>Southern Africa
+    </td>
+    </tr>
+    <tr>
+    <td>IN</td>
+    <td>India
+    </td>
+    </tr>
+    <tr>
+    <td>SEAS</td>
+    <td>Southeast Asia
+    </td>
+    </tr>
+    <tr>
+    <td>NEAS</td>
+    <td>Northeast Asia
+    </td>
+    </tr>
+  </tbody>
+</table>
+
+</ContentColumn>
@@ -22,7 +22,7 @@ For an example prefix configuration, refer to this table:
 | 131.0.72.0/22   | AS395747       |
 | 103.21.245.0/24 | AS395747       |
 
-<Aside>
+<Aside type='note' header='Note'>
 
 When customers supply their own ASN, Cloudflare prepends the main Cloudflare ASN (AS13335) to the BGP AS_PATH. For example, if the customer ASN is AS64496, anyone directly peering with Cloudflare sees the path as `13335 64496`.
 

@@ -103,7 +103,7 @@ Local MSS: 1436
 Remote MSS: 1436
 ```
 
-<Aside>
+<Aside type='warning' header='Important'>
 
 When you do not have a publicly available TCP endpoint for which Cloudflare can verify your MSS settings, you must provide a screenshot of the cURL command results, similar to the one above.
 

@@ -11,7 +11,7 @@ A common workflow is to enable prefix advertisement during an attack so that you
 
 To ensure smooth operation in general and simplify the advertisement process during an attack scenario, see [_Dynamic advertisement: Best practices_](https://developers.cloudflare.com/byoip/dynamic-advertisement/best-practices).
 
-<Aside>
+<Aside type='note' header='Note'>
 
 Once you have set up Magic Transit, all Cloudflare traffic to your prefixes uses GRE tunnels to reach your origin. This is true even when you disable dynamic advertising.
-Original file line number
+Diff line change
@@ Expand Up @@
     For example, consider a scenario with many very low-bandwidth TCP connections and one very high-bandwidth TCP connection. Packets for the high-bandwidth connection have the same hash and thus use the same tunnel. As a result, that tunnel utilizes greater bandwidth than the others.
-    <Aside>
+    <Aside type='note' header='Note'>
     Magic Transit supports a "weight" field that you can apply to a tunnel so that a specified percentage of traffic uses that tunnel rather than other equal-cost tunnels.
@@ Expand Down @@