# Default Connectivity The default connectivity story is the **Global VPC** (`VPC-Default`). Every account has one. It spans every region in the default mesh, and every region in that mesh already has a subnet in it — pre-provisioned, with a non-overlapping CIDR, with no configuration from you. Instances placed into the Global VPC reach each other directly across regions, over private IP. A 10 Kbps free bandwidth baseline is provisioned so you can run connectivity checks (`ping`, `traceroute`) between regions out of the box; this is not enough for production traffic, so any real workload needs that rate raised. ![Default Mesh](/files/lghw1UjV9tRjLqpvuyab) ## The Global VPC — `VPC-Default` `VPC-Default` is a single VPC object in your account. Its subnets are the platform's view of "one subnet per region," auto-assigned so that every region has private-IP space without you planning it. Concretely, `VPC-Default` uses a pre-planned address plan, and each region gets one `/20` inside it. Looking at the subnet list in the [VPC console](https://console.zenlayer.com/zec/vpc), you'll see entries like the table below: | Region | Default Subnet CIDR | | ----------------------------------- | ------------------- | | asia-southeast-1 (Hong Kong) | `10.130.64.0/20` | | asia-southeast-2 (Jakarta) | `10.130.96.0/20` | | asia-southeast-3 (Kuala Lumpur) | `10.131.0.0/20` | | asia-southeast-4 (Ho Chi Minh City) | `10.131.80.0/20` | | asia-southeast-5 (Hanoi) | `10.130.176.0/20` | | asia-southeast-6 (Manila) | `10.131.160.0/20` | | asia-southwest-1 (Singapore) | `10.130.128.0/20` | | me-central-1 (Riyadh) | `10.130.112.0/20` | | europe-central-1 (Frankfurt) | `10.130.48.0/20` | | europe-south-1 (Marseille) | `10.131.144.0/20` | | europe-east-1 (Istanbul) | `10.131.32.0/20` | | na-west-1 (Los Angeles) | `10.130.80.0/20` | | na-east-1 (Washington, D.C.) | `10.131.16.0/20` | | na-south-1 (Miami) | `10.131.112.0/20` | | na-central-2 (Dallas) | `10.130.208.0/20` | | sa-east-1 (São Paulo) | `10.131.96.0/20` | | sa-north-1 (Bogotá) | `10.131.48.0/20` | | sa-west-1 (Lima) | `10.131.64.0/20` | | sa-south-1 (Santiago) | `10.131.176.0/20` | | sa-south-2 (Buenos Aires) | `10.131.128.0/20` | The list in your console may include more regions as they come online; the exact CIDR for each region is assigned by the platform and is stable for the lifetime of `VPC-Default`. The naming convention is `Subnet--Default`, and each subnet is marked as the region's **Default subnet** — new instances in that region land here unless you explicitly place them in a VPC you created. ## What's Reachable By Default When two instances live in the **same VPC** (whether that's `VPC-Default` or a Global VPC you created), and their subnets are in regions in the default mesh: * They reach each other over private IPs, in either direction. * ICMP, TCP, and UDP all work. Running `ping` between regions succeeds out of the box. * Both IPv4 and IPv6 traffic is carried. * The peer's subnets are already visible in the VPC route table — you don't add cross-region routes. * A 10 Kbps free bandwidth baseline is available immediately — enough for connectivity checks (ping, traceroute) but not for production traffic. Production throughput requires raising the [Cross-Region Bandwidth](/welcome/elastic-compute/networking/01-overview-1/03-region-links.md) for the region pair. This applies to any pair of regions in the default mesh. Hong Kong to São Paulo, Frankfurt to Los Angeles, Singapore to Riyadh — all the same. **Security groups do not filter cross-region intra-VPC traffic.** The platform's security groups apply to public-network traffic, not to private traffic between subnets in the same VPC. If a cross-region `ping` fails, the network itself is the thing to look at — not a security group. Instance-level OS firewalls (iptables, Windows Firewall, etc.) are on you. If you've blocked ICMP or a port inside the guest, cross-region traffic hits that the same way local traffic does. ## Regions Outside the Default Mesh A small number of regions are not in the default mesh, typically for regulatory reasons. **China** is the canonical example. These regions participate in Cross-Region Network differently: * They are not meshed with the rest of the Global VPC by default. * Reachability into and out of them is arranged explicitly, under the relevant regulatory constraints. * Don't assume `ping` between a mesh region and a regulated region works — plan for explicit connectivity when your architecture spans that boundary. If you operate in a regulated region, contact [support](mailto:support@zenlayer.com) for the supported connectivity path. Treat it as a separate scope from the default Global VPC. ## What the Default Bandwidth Does *Not* Guarantee **Enough throughput for a real workload.** The 10 Kbps free baseline is enough for connectivity checks (ping, traceroute) but is *not* sized to carry production traffic. Any real use case — even a lightly used service — must **raise the Cross-Region Bandwidth for the pair**. See [Cross-Region Bandwidth](/welcome/elastic-compute/networking/01-overview-1/03-region-links.md). **Cross-VPC reach.** The default mesh applies within a single VPC. Two separate VPCs — even if both have subnets in the same regions — are independent. **Dynamic routing with external networks.** The default mesh carries traffic between subnets inside your VPC. It does not exchange routes with your on-premises routers or with external autonomous systems. For that, use **Border Gateway**. ## Behavior Under Failure Cross-Region Network uses multiple paths across the backbone. If a single path degrades or fails, traffic is rerouted automatically. You should not see persistent loss from a single backbone incident, but you may see a short reconvergence window during the reroute. ## Common Misconceptions **"I need to create VPCs in each region before I can use cross-region traffic."** No. The Global VPC already has a subnet in every region. Creating an instance in a new region places it in that region's default subnet, which is already connected to the rest. **"I have to pick a CIDR that won't collide across regions."** Not in `VPC-Default`. The platform's per-region `/20` assignments don't collide with each other, and you don't choose them. You only pick CIDRs when you create a VPC of your own. **"Ping doesn't work — I need to add a security group rule."** Security groups on this platform are for public-network traffic. They don't gate private traffic between subnets in the same VPC, cross-region or otherwise. Check OS firewalls on the instance first. **"I need a VPC peering between regions."** There is no peering step inside a VPC — the per-region subnets of the same VPC are already connected. Peering only comes up if you need two *different* VPCs to reach each other. **"Cross-Region Network carries only IPv4."** It carries both IPv4 and IPv6. If your application is dual-stack, both stacks work across regions within the same VPC. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.console.zenlayer.com/welcome/elastic-compute/networking/01-overview-1/02-default-connectivity.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.