> For the complete documentation index, see [llms.txt](https://docs.console.zenlayer.com/welcome/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.console.zenlayer.com/welcome/elastic-compute/networking/01-overview-1/02-default-connectivity.md). # 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.