Huawei Cloud Global Edition Huawei Cloud ECS routing table configuration

Huawei Cloud Global Edition Introduction: Routing Tables Aren’t Magic, They’re Just Very Opinionated

Routing tables in Huawei Cloud ECS are one of those topics that sound like they belong in a detective movie: “The culprit is… a missing route entry.” You can have perfectly working servers, clean security group rules, and enthusiastic application code—yet your packets still refuse to go where you want. That’s usually because the network doesn’t know the path.

This article explains how to configure routing tables for Huawei Cloud Elastic Cloud Server (ECS) in a way that is clear, structured, and practical. We’ll cover the concepts, the typical objects you’ll encounter (VPCs, subnets, gateways, route tables), and how to set route entries for common scenarios. We’ll also include troubleshooting steps so you can stop blaming your code and start blaming the router like a responsible adult.

What a Routing Table Actually Does (In Plain English)

A routing table tells a network device (or the virtual networking layer in your cloud) where to send traffic based on its destination IP range. If you send a packet to 10.10.20.30, the routing decision might be: “Send it to gateway X,” or “Send it to next hop Y,” or “Drop it and pretend you didn’t hear that.”

In cloud environments, routing tables are often tied to VPCs and subnets. ECS instances pick routes based on which subnet they belong to. That means: if you configure routes for the subnet but your instance is actually in a different one, the universe will not correct you. It will just continue to misroute your traffic.

So think of routing tables as a set of “postal rules” for packets. Every rule says: “When the destination is in this range, deliver it via this path.” If the rule is missing, packets may go to a default route, or they may be discarded. Default routes are convenient but also mischievous in the way a default “all cats go here” policy can be mischievous.

Before You Touch Anything: Key Components You’ll See

Huawei Cloud ECS routing configuration typically involves the following building blocks. The exact names in the console may vary slightly depending on your setup, but the concepts stay consistent.

Huawei Cloud Global Edition 1) VPC (Virtual Private Cloud)

Your VPC is your isolated network space. It contains subnets, route tables, and other networking elements. You can think of it as the neighborhood your ECS instances live in.

Huawei Cloud Global Edition 2) Subnet

A subnet is a slice of the VPC’s IP address range. ECS instances are placed into a specific subnet. Routing behavior is often tied to the subnet.

3) ECS Instances

Your servers. They don’t “write their own routing tables” in the way you might imagine from bare metal. Instead, their traffic is guided by the routing rules associated with their network environment. You can also configure host-level routes inside the OS, but for most use cases, the cloud route tables are the correct place to start.

4) Route Tables

A route table contains route entries. Each entry maps a destination CIDR to a next hop (or a gateway). When traffic leaves an instance, the system uses the route table associated with the relevant subnet to decide where to send it.

5) Gateways and Next Hops

Depending on the scenario, your next hop could be an Internet gateway, NAT gateway, virtual private network gateway, transit gateway, or a peering connection endpoint. The goal is always the same: get traffic to the right place.

6) Security Groups and Network ACLs (The “Nope” Department)

Routing tells you where to send packets; security controls tell you whether packets are allowed. You can have perfect routes and still fail connectivity if security groups deny traffic. So in troubleshooting, you always check both layers.

The Big Picture Workflow (How to Configure Routing Without Losing Your Mind)

Here’s a sane workflow that works across many Huawei Cloud setups:

1. Identify the source subnet and the destination network (CIDR).
2. Decide which path should be used (next hop/gateway).
3. Create or update the route table with an entry that matches the destination CIDR.
4. Associate the route table with the correct subnet(s).
5. Verify routing by testing connectivity (ping, traceroute, TCP connections) from a test instance.
6. Confirm security group rules allow the traffic.

If your route changes don’t seem to apply, it’s usually one of these: wrong subnet association, incorrect CIDR, or expecting the wrong gateway to exist. Sometimes it’s also because you updated a route table that is not actually attached to the instance subnet, like rearranging furniture in a house you don’t live in.

Scenario 1: ECS Needs to Reach the Internet

When people say “routing to the internet,” they often mean one of two things: either you want direct outbound access to public internet, or you want controlled outbound through a NAT. The routing table configuration depends on what gateways are available in your design.

Typical Setup: Private Subnet with NAT Gateway for Outbound

Many architectures put ECS instances in private subnets (no public IP). In that case, outbound internet traffic usually goes through a NAT gateway.

Routing conceptually becomes:

• Destination: 0.0.0.0/0 (the “everything else” bucket)
• Next hop: NAT gateway

So you add a default route entry in the route table associated with the private subnet.

Steps to Configure a Default Route

1. Find the route table associated with the subnet where your ECS resides.
2. Check whether a route entry already exists for 0.0.0.0/0.
3. If not, create a route entry:
• Destination CIDR: 0.0.0.0/0
• Next hop: NAT gateway (or the correct outbound gateway for your VPC design)
4. Make sure the route table is properly associated with the ECS subnet.
5. Test from the ECS instance: try ping (if allowed), or curl to a known website (like a public IP or domain).

Pro tip: If your environment requires domain resolution, don’t forget DNS. Routing can be correct, but DNS can still be wrong. That’s the network equivalent of having a perfectly working doorbell but no batteries in the remote.

Scenario 2: ECS Needs to Reach an On-Prem Network

Connecting ECS to your on-premises network often involves a VPN gateway, Direct Connect, or a transit gateway. From the routing table’s perspective, you need a route for the on-prem CIDR(s) pointing to the appropriate next hop.

Example

Let’s say:

• ECS is in subnet A: 172.16.10.0/24
• On-prem network is 192.168.0.0/16
• You have a VPN tunnel or interconnect that can reach 192.168.0.0/16 via a specific gateway

You would add a route entry to route traffic destined to 192.168.0.0/16 via that gateway.

Steps: Add a Specific Route (Not Just a Default Route)

Best practice is to add explicit routes for on-prem networks instead of relying only on default routes. Specific routes prevent accidental traffic patterns and make troubleshooting simpler.

1. Identify the destination CIDR(s) you need to reach (for example, 192.168.0.0/16).
2. Identify the next hop: VPN gateway / interconnect / transit gateway attachment.
3. In the route table for the ECS subnet, add a route entry:
• Destination CIDR: 192.168.0.0/16
• Next hop: the on-prem connectivity gateway
4. Validate that the gateway has the necessary peering or tunnel status.
5. On the on-prem side, ensure your on-prem routers have return routes back to the VPC CIDR(s). This is a classic “one-way street” problem.
6. Test connectivity from ECS to an on-prem host IP within the destination range.

Remember: routing is symmetrical only when both sides agree. If only one side has the route, your packets may travel out but not come back. That’s not a haunting; it’s just missing return routes.

Scenario 3: Routing Between Subnets Within the Same VPC

If two subnets are in the same VPC, routing is often simpler, because the VPC internal network can typically handle traffic without custom route entries for common internal CIDRs.

However, you may still need routing configuration if:

• Subnets overlap with other networks via peering connections.
• You use transit gateways or complex segmentation.
• You want to route traffic through a centralized firewall or inspection layer.

In those cases, you may configure routes for the destination subnet CIDR pointing to a virtual appliance or gateway.

When Traffic Should Stay Internal

If you want traffic between subnets to remain internal, ensure you are not accidentally routing the destination CIDR to an external gateway. A wrongly set default route can cause internal-to-internal traffic to take a detour around the entire planet, which is both inefficient and oddly dramatic.

Scenario 4: Centralized Firewall / Inspection Routing

Some designs route all traffic through a security appliance or firewall VM. In that model, routing tables are used to direct traffic to the firewall as the next hop.

Example idea:

• All outbound traffic from subnet A to the internet should pass through a firewall at 10.0.0.10 (an appliance IP in another subnet)

Then you add routes like:

• Destination 0.0.0.0/0 -> next hop = firewall appliance

Two important cautions:

1. The firewall needs connectivity back to where it’s sending traffic.
2. The return traffic needs correct routing. Otherwise, you’ll have traffic entering the firewall but never returning.

This is where your routing table becomes less like a GPS and more like a stage manager. Everything needs to happen in the correct order, or the show ends abruptly.

How to Think About Route Entries: Destination CIDR, Next Hop, and Priority

Route tables usually match traffic using the destination CIDR. The most specific match wins in many routing systems (longest prefix match). Even if Huawei Cloud uses a particular matching logic internally, the practical takeaway is: be specific when you can.

Destination CIDR

This is the IP range you want to match. You’ll often use:

• Specific network ranges like 10.20.0.0/16
• Single subnets like 172.16.10.0/24
• Default route: 0.0.0.0/0 (IPv4) for all unspecified destinations

Huawei Cloud Global Edition Next Hop

This is where the traffic goes next. It could be a gateway or a next-hop device. Choose the next hop that can actually reach the destination network.

A Quick Note on IPv4 vs IPv6

If you’re doing IPv6 routing, the CIDRs and defaults differ (for example, ::/0 for default route). If your environment is mixed, double-check which IP family your route table is configured for. Otherwise you’ll be staring at a route table that is doing exactly nothing for your IPv4 traffic, like a lifeguard reading poetry in the wrong language.

Verification: How to Tell Whether Your Routes Are Working

Let’s assume you’ve configured a route entry. How do you confirm it’s actually being used?

1) Use Traceroute or Tracing Tools

From the ECS instance, run traceroute (or a similar diagnostic tool) to a destination IP. The hop you see should align with your intended next hop/gateway.

If traceroute is blocked by security policies, you can still test with TCP connections or ping to intermediate gateways (if permitted).

2) Test With a Known Destination in the CIDR

Don’t test with a random IP unless you’re sure it falls inside the route’s destination CIDR. Common mistake: you add a route for 192.168.1.0/24 but test 192.168.2.10. Routing is literal, not interpretive.

3) Check Security Groups and NACLs

Even a perfect route will fail if traffic is blocked.

• Ensure outbound security group rules allow traffic from your ECS to the destination.
• Huawei Cloud Global Edition Ensure inbound rules on the destination (if inside VPC or on-prem) allow return traffic.
• If you use NACLs, verify stateless rules also allow the traffic.

4) Verify Route Table Association

This is the “I’m pretty sure I updated the right thing” problem. Confirm the route table is attached to the exact subnet where the ECS instance resides.

Instances won’t magically inherit routes from other subnets just because you wish they would. The network follows rules, not feelings.

Huawei Cloud Global Edition Troubleshooting: The Most Common Routing Failures

Here’s a list of frequent issues and what they usually mean. Think of it as a troubleshooting bingo card, except everyone wins when the ping works.

Problem: No Connectivity to Destination CIDR

• Possible cause: missing route entry for the destination CIDR.
• Possible cause: route entry uses wrong next hop gateway.
• Possible cause: route table not associated with the ECS subnet.
• Possible cause: security group or NACL blocking traffic.
• Possible cause: on-prem side missing return route.

Problem: One-Way Traffic (You Can Send but Can’t Receive)

This is classic return-route trouble. If ECS can send packets to on-prem but on-prem can’t send replies back, your connection fails.

• Fix: ensure on-prem routers have routes back to the VPC CIDR(s).
• Fix: ensure the return path uses correct gateway and security policy on both sides.

Problem: Everything Tries to Go Out to the Firewall or NAT, Even Internal Traffic

This usually happens when you set an overly broad route, often the default route, and didn’t add more specific routes for internal destinations.

• Fix: add specific routes for internal CIDRs that should bypass the firewall/NAT.
• Fix: review longest prefix matching behavior if applicable.

Problem: Route Exists, But Traffic Still Fails

Then we look beyond routing:

• Is the next hop gateway healthy and properly connected?
• Is the tunnel up (if using VPN)?
• Is the firewall appliance reachable and forwarding correctly?
• Is DNS working if you’re testing by domain?

Best Practices: How to Make Your Routes Less Fragile

If you want routing tables that behave like well-trained pets instead of chaos gremlins, follow these best practices:

Keep Routes Specific

Whenever possible, add routes for precise CIDRs instead of relying only on a default route. Specific routes reduce unintended traffic paths and make troubleshooting easier.

Document Your Route Intent

Write down which route table is associated with which subnet and why. Your future self will be grateful, especially at 2 a.m. when everything is on fire and your memory is on lunch break.

Use Consistent CIDR Planning

Avoid overlapping IP ranges between your VPC and on-prem networks. Overlaps cause ambiguous routing decisions and headaches that taste suspiciously like regret.

Validate Gateways and Connectivity Status

Don’t assume a gateway is ready just because it exists in the console. Confirm its status, tunnel state, and reachability.

Test in Small Steps

Start by adding one route entry and testing. Don’t batch-change five route tables and then wonder which one caused the problem. Change management is basically a seatbelt for networks.

A Practical Example Walkthrough (From “Ping Denied” to “We Have Traffic”)

Let’s do a realistic walkthrough with a fictional but familiar setup.

Setup

• Your VPC has a subnet: 172.16.10.0/24
• You launched ECS instance: ecs-01 in that subnet
• Your on-prem network is: 192.168.50.0/24
• You have a VPN gateway or interconnect that can reach on-prem
• Security groups allow outbound from ecs-01 to 192.168.50.0/24

You try to ping a host on-prem: 192.168.50.25. It fails.

Step 1: Check Route Table Association

Verify the route table attached to subnet 172.16.10.0/24 contains an entry for 192.168.50.0/24. If it doesn’t, add one.

Route entry:

• Destination CIDR: 192.168.50.0/24
• Next hop: your on-prem connectivity gateway

Step 2: Confirm Return Route on On-Prem

You check on-prem router settings and realize that on-prem routers don’t know where 172.16.10.0/24 lives. That explains the “one-way” vibe: ecs-01 sends packets, on-prem receives them (maybe), but replies can’t find their way back.

You add a route on-prem:

• Destination: 172.16.10.0/24
• Next hop: VPN tunnel interface / appropriate device

Step 3: Retest Connectivity

Now the ping works. Cue the confetti. Or at least cue the relieved sigh.

If ping still fails, you move to Step 4.

Step 4: Verify Gateway Health and Policies

• Check VPN tunnel status: is it up?
• Check that intermediate firewall rules allow ICMP (ping), if you’re using ping as the test.
• Test TCP instead of ICMP if ICMP is blocked.

Common Questions (and the Answers You’ll Wish You Had Sooner)

Do I need to configure routes on the ECS OS as well?

Usually, no. For most cloud routing cases, the cloud routing layer handles it based on route tables associated with your subnet. You only need OS-level routes if you are doing special routing within the instance (for example, multi-homing, special network namespaces, or custom appliance behavior).

If you do OS routes, make sure they don’t conflict with the cloud-level routes. Conflicting routes are a great way to make traffic walk in circles like it’s looking for the nearest coffee shop.

Huawei Cloud Global Edition What if I add a default route, but specific routes also exist?

Typically, more specific routes override the default route for matching traffic. The exact matching behavior depends on the platform’s routing logic, but the practical rule is: if traffic should go somewhere special, add a more specific route for that destination range.

Why can I ping an IP but not connect to an application port?

Because ping uses ICMP, while applications use TCP/UDP ports. Your routing can be correct, but security group rules (or on-prem firewall policies) might block the port. Check both ICMP and port-based rules depending on the test you’re doing.

Conclusion: Configure Routes With Confidence (and Mild Suspicion)

Huawei Cloud ECS routing table configuration is not inherently mysterious. It’s a structured process: identify where your traffic starts, decide where it should go, create the appropriate route entries with correct destination CIDRs, associate those route tables with the right subnets, and verify connectivity while checking security policies.

If you follow that approach, you’ll spend less time guessing and more time actually moving packets. And if things still don’t work, you’ll have a troubleshooting plan rather than a wild theory. Because when networking misbehaves, it’s rarely your application—it’s almost always the routing and the security combination doing what they were told, not what you intended.

Now go forth and configure routes like the calm professional you are. If a packet still refuses to travel, remember: the router is not haunted. It’s just being literal. Missing routes are the gremlins; long default routes are the tricksters; and correct CIDR matching is the hero. Good luck, and may your traceroutes be short and your return paths be real.