tencent cloud

Virtual Private Cloud

DokumentasiVirtual Private Cloud

Best Practices for Connecting Layer 2 Leased Lines to the Cloud

Download
Mode fokus
Ukuran font
Terakhir diperbarui: 2026-08-04 11:53:29
Diterjemahkan oleh AI

Related Overview

What Is Layer 2 Leased Line Cloud Connectivity

Layer 2 Direct Connect to Cloud refers to establishing a large Layer 2 network channel between a Tencent Cloud VPC and a user's on-premises IDC using L2GW (Layer 2 Gateway) technology. This enables business hosts in the cloud and the on-premises IDC to reside within the same Layer 2 broadcast domain, thereby achieving direct communication between IP addresses in the same subnet.

Differences from Traditional Layer 3 Leased Lines

Level
Layer 3 Direct Connect (Traditional Solution)
Layer 2 Cloud Access via Direct Connect (L2GW)
Network layer
Layer 3 (IP routing)
Layer 2 (MAC forwarding + VXLAN tunneling)
Subnet planning
The CIDR blocks of the cloud and on-premises networks must not overlap.
Supports communication between IP addresses within the same subnet.
Migration granularity
Subnet granularity
Virtual machine/Pod granularity
IP address change
IP addresses must be changed for migration to the cloud.
No IP address change required.
Primary purpose
General hybrid cloud interconnection
Smooth migration of services to the cloud, disaster recovery, and elastic scale-out

Benefit

Business-unaware migration: It enables communication between cloud and on-premises resources within the same subnet, eliminates the need to modify IP addresses and network configurations, and makes the migration process transparent to applications.
Elastic scaling: It enables the smooth, one-by-one migration of virtual machines from the IDC to the cloud, achieving zero-downtime migration.
Disaster recovery and elasticity: When IDC resources are insufficient, you can elastically scale out part of your workloads to the cloud, sharing the same subnet.

Scenarios

Smooth Data Center Migration to the Cloud

Business Context: Enterprises need to gradually migrate their workloads from self-built data centers to Tencent Cloud. However, constrained by the existing application architecture, a large number of applications rely on fixed IP addresses for communication. Modifying IP addresses would lead to large-scale application reconfiguration and prolonged service downtime.
Solutions:
Establish a large Layer 2 network between the cloud and on-premises environments using L2GW.
Keep the original subnet planning unchanged and migrate CVMs to the cloud VPC one by one.
The cloud CVM is configured with the same subnet IP address as the original servers in the IDC.
Service interruption time is minimized during the migration process.
Typical Customers: Financial industry core system migration and traditional enterprise ERP/OA system migration to the cloud.

Overall Architecture

Architecture Topology

image
image


Core Component Description

Component
Role
Description
L2GW CVM
Layer-2 Gateway Core
A CVM instance deployed in the management VPC, responsible for Layer 2 traffic forwarding and VXLAN tunnel encapsulation/decapsulation.
Managing Subnets
Ops management plane
The subnet for deploying L2GW CVM, which uses a dedicated subnet and is separated from the service subnet.
Business Subnet
Business forwarding plane
The service subnet that actually requires Layer 2 interconnection.
VXLAN Subnet
VXLAN control plane
The subnet for establishing VXLAN tunnels, which uses a dedicated subnet and is separated from the service subnet.
HAVIP
High-availability traffic steering
A high-availability virtual IP address that serves as the traffic ingress for the VPC subnet and the IDC direction, managed by Keepalived/VRRP.
VXLAN Tunnel
Layer-2 extension
Establishes a VXLAN Overlay tunnel between the L2GW and the IDC Switch to carry Layer 2 traffic.
DCGW
Direct Connect gateway
A Tencent Cloud local gateway that enables Layer 3 network interconnection between the L2GW and the IDC.

Network Plane Isolation Design

The L2GW CVM contains three network planes:
NIC
Purpose
Description
eth0 (Management Port)
Maintenance
Used only for SSH login and daily Ops. Prohibited from service traffic forwarding.
eth1 (VPC-facing)
L2GW > VPC service communication
Binds to an ENI and connects to the user's VPC service subnet.
eth2 (IDC-facing)
L2GW > IDC service communication
Binds to an ENI, carries VXLAN tunnels and VRRP heartbeat packets, and cannot be deleted.

Deployment Preparation

Instance Type Selection Recommendations

Model
Specification
PPS
Bandwidth
Scenario
SA3.16XLARGE128
64C 128G
5.2 million PPS
25 Gbps
General-purpose scenarios, cost-effective
SA9.16XLARGE128
64C 128G
5.6 million PPS
25 Gbps
High-performance computing scenarios
SA5.16XLARGE256
64C 256G
5.6 million PPS
25 Gbps
Scenarios requiring large memory
Cluster Scale Estimation:
Assume the customer's total bidirectional traffic requirement is 120 Gbps.
25 Gbps per CVM (outbound + inbound).
Deploy five clusters (a total of 10 CVMs), with each cluster consisting of two CVMs in a primary/secondary configuration.
Note:
The actual deployment quantity should be adjusted based on the service traffic model and redundancy requirements.

Operating System Requirements

Operating System: TencentOS Server 3.3 (TK4), based on the tlinux5.x kernel + CentOS-compatible environment.
Kernel Feature: The VXLAN tunneling module must be supported.

Network planning

IP Address Planning Table

Resource Type
CIDR Planning (Example)
Description
Management VPC subnet-mgmt
10.0.0.0/24
For Ops to log in to L2GW
L2GW management IP
10.0.0.x
Assigned to L2GW-01/02 respectively
User VPC subnet1 (service subnet)
10.66.1.0/24
The cloud and on-premises networks are in the same subnet, supporting Layer 2 interconnection.
User VPC subnet2 (tunnel subnet)
10.66.2.0/24
For VXLAN tunnel bearing
IDC tunnel subnet
Define based on actual interconnection addresses.
Layer 3 interconnection with subnet2
HAVIP (VPC direction)
10.66.1.102
Bound to eth1 and used as the VPC traffic diversion address.
HAVIP (IDC direction)
10.66.2.102
Bound to eth2 and used as the dedicated line/dedicated line/LGW traffic diversion address.
IDC Switch VXLAN IP
Define based on actual interconnection addresses.
VXLAN tunnel peer address

Network Segment Planning Principles

1. Management Subnet and Service Subnet Separation: The management VPC does not carry service traffic.
2. Service Subnet with Consistent CIDR Across Cloud and On-Premises: subnet1 must use the same CIDR as the service subnet in the IDC.
3. Tunnel Subnet Independent Planning: subnet2 and the IDC tunnel subnet must be Layer 3 reachable, but their CIDR blocks must not overlap.
4. Reserve Expansion Space: It is recommended to reserve at least 50% of IP addresses as a buffer for each subnet.

Resource Inventory

Resource Item
Quantity
Remarks
L2GW CVM Instance
2 (1 active, 1 standby)
Can be scaled out to multiple clusters based on traffic.
ENI (VPC-facing)
2
One per L2GW and bound to eth1.
ENI (IDC-facing)
2
One per L2GW and bound to eth2.
HAVIP (VPC direction)
1
Allocated in subnet1 and bound to the eth1 NIC.
HAVIP (IDC direction)
1
Allocated in subnet2 and bound to the eth2 NIC.
VXLAN Tunnel
1 per large Layer 2 subnet
Destination port: 4789
Keepalived
One per L2GW.
Version v2.1.5

Deployment Best Practices

Deployment Process Overview

Step 1: Purchasing L2GW Resources

1. Create two CVM instances under the management account, selecting the specifications based on the instance type selection recommendations.
2. Create the management VPC subnet-mgmt and assign a management IP address.
3. Create two ENIs in each of the user VPC's subnet1 and subnet2, and bind them to the two L2GW CVMs respectively.

Step 2: Global Initialization

Deploy the L2GW deployment package:
Download the L2GW deployment package.
 wget https://iso-1255486055.cos.ap-guangzhou.myqcloud.com/l2gw_v1.0.tar.gz
# Extract it to the /data/ directory.
tar -xzf l2gw_v1.0.tar.gz -C /data/

# Create a symbolic link.
cd /data
ln -s l2gw_v1.0 l2gw
cd /data/l2gw_v1.0_20260302_173709/

# Perform global initialization.
./l2gw_install_global.sh
Attention:
Add l2gw_install_global.sh to /etc/rc.local to ensure the initialization parameters remain effective after the CVM reboots. After deployment, verify whether the parameters have indeed taken effect upon reboot.

Step 3: Connecting L2GW to IDC-Switch

L2GW-Side Configuration

Initialize the user plane network interface card:
# Initialize the VPC-facing network interface card.
./l2gw_install_interface.sh add eth1 10.66.1.100

# Initialize the IDC-facing network interface card (which carries VXLAN and VRRP heartbeat traffic).
./l2gw_install_interface.sh add eth2 10.66.2.100
Create an HAVIP:
Create an HAVIP with the IP address 10.66.1.102 in subnet1 (VPC-facing) and bind it to eth1.
Create an HAVIP with the IP address 10.66.2.102 in subnet2 (IDC-facing) and bind it to eth2.
Enter the HAVIP into the virtual_ipaddress field of the Keepalived configuration.

Dedicated Line/LGW-Side Configuration

Establish connectivity between the user's IDC and the L2GW CVM via the Direct Connect gateway at Layer 3.
Configure the traffic steering route for the IDC > L2GW direction.
Configure route advertisement for the L2GW > IDC direction.

Step 4: Setting Up a Keepalived Primary/Secondary Environment

Key Configuration Points:
vrrp_instance VI_L2GW {
    ...
    interface eth2               # Bind the network interface card for the L2GW→IDC direction.
    unicast_src_ip 10.66.2.100  # The local private IP address.
    unicast_peer {
        10.66.2.101             # The peer device IP address.
    }
    virtual_ipaddress {
        10.66.1.102 dev eth1   # The VPC-facing HAVIP.
        10.66.2.102 dev eth2    # The IDC-facing HAVIP.
    }
    ...
}
Key Constraints:
Select the IDC-facing eth2 network interface card for the VRRP heartbeat interface. This network interface card cannot be deleted or modified and must be retained long-term after its creation. It must not be unbound or deleted arbitrarily.
VRRP can only be deployed in unicast mode and does not support multicast.
Verification: Use systemctl status keepalived or check the logs to confirm that the primary/secondary status is normal.

Step 5: Setting Up a Large Layer 2 Subnet

Establish a Layer 2 network between the cloud and on-premises environments through a VXLAN tunnel:
# Add a VXLAN tunnel
# Parameters: vxlan_id local_ip ethx remote_ip dstport vxlan_ip
./l2gw_subnet.sh add 10000 10.66.2.102 eth1 172.16.1.200 4789 10.66.1.100
Parameter description:
Parameter
Example Value
Description
vxlan_id
10000
The VXLAN tunnel ID must be consistent between the cloud and on-premises environments.
local_ip
10.66.2.102
Local tunnel IP address (HAVIP)
ethx
eth1
The network interface where the local_ip resides
remote_ip
172.16.1.200
Peer IDC Switch tunnel IP
dstport
4789
VXLAN standard destination port
vxlan_ip
10.66.1.100
The IP address of the eth interface corresponding to the subnet

Step 6: Adding Service IP Address Routes

Configure IP address routes for cloud-based and IDC CVM instances:
# Add a route for the cloud-based CVM
./l2gw_ipaddr.sh add_vpc_eth 10.66.1.10 eth1 10000

# Add a route for the IDC server
./l2gw_ipaddr.sh add_idc_vxlan 10.66.1.11 10000

Step 7: L2GW CVM Going Online

After confirming that all network configurations are complete, perform the go-live operation:
# Go-live: Start the keepalived process and complete the gateway go-live.
./l2gw_online.sh
Best Practice: For initial setup, it is recommended to restart the device, allow the control plane Agent to pull up the configuration, and then go live, verifying that the configuration can be automatically restored after the restart.

High Availability Design

Primary/Secondary Architecture

L2GW uses a dual-node primary/secondary architecture:
The two L2GW CVMs elect a primary/secondary role through the Keepalived/VRRP protocol.
The primary L2GW holds the HAVIP and is responsible for forwarding all service traffic.
The secondary L2GW monitors VRRP heartbeats and automatically takes over when the primary fails.

Failover Process

1. The primary L2GW fails.
2. The secondary L2GW detects a VRRP heartbeat timeout (which is three times the advertisement interval by default).
3. The secondary L2GW is automatically promoted to primary and binds to the HAVIP.
4. Send gratuitous ARPs to refresh the MAC tables of network devices.
5. Service traffic is switched to the secondary L2GW.

Key Points for High Availability Configuration

1. The VRRP heartbeat network interface card cannot be deleted: The eth2 network interface card carries VRRP heartbeat communication and must be retained permanently after creation.
2. Dual HAVIP Design: One HAVIP is allocated to the VPC direction and another to the IDC direction, enabling bidirectional traffic steering.
3. Keepalived Non-Preemptive Mode: It is recommended to enable the non-preemptive mode (nopreempt) to avoid frequent switching after the primary recovers from a failure.
4. BFD Linkage: It is recommended to use BFD (Bidirectional Forwarding Detection) to achieve sub-second failure detection.

Scalability Design

When traffic exceeds the capacity of a single cluster, you can adopt horizontal scaling with multiple clusters:
Each cluster consists of two L2GW CVMs in a primary/secondary configuration.
Different clusters manage different large Layer 2 subnets.
It is recommended to reserve 20% - 30% performance headroom.

Ops Best Practices

Daily Operations Guide

Adding a CVM in the Cloud

cd /data/l2gw

# Add a new route for the cloud-based CVM
#add_idc_vxlan <ipaddr> <vxlan_id> - Add an IDC route for the vxlan interface.
#del_idc_vxlan <ipaddr> <vxlan_id> - Delete the IDC route for the vxlan interface
./l2gw_ipaddr.sh <action> <ipaddr> [interface1] [interface2]

# Examples.
./l2gw_ipaddr.sh add_vpc_eth 10.66.1.20 eth1 10000

Adding a CVM in IDC

# Add a new IDC CVM route
./l2gw_ipaddr.sh add_idc_vxlan <new_CVM_IP> <vxlan_id>
#add_idc_vxlan <ipaddr> <vxlan_id> - Add an IDC route for the vxlan interface.
#del_idc_vxlan <ipaddr> <vxlan_id> - Delete the IDC route for the vxlan interface
# Examples.
./l2gw_ipaddr.sh add_idc_vxlan 10.66.1.21 10000

Migrating IDC CVM to the Cloud

# Migrate the IDC CVM to the cloud (delete the IDC route and add the VPC route)
./l2gw_ipaddr.sh switch_idc_to_vpc <CVM_IP> <vxlan_id> <eth_interface>
# switch_vpc_to_idc <ipaddr> <eth_interface> <vxlan_id> - Delete the VPC route for the eth interface and add the IDC route for the vxlan interface
# Example: Migrate 10.66.1.21 from IDC to the cloud
./l2gw_ipaddr.sh switch_idc_to_vpc 10.66.1.21 10000 eth1

Migrating Cloud CVM Back to IDC

# Migrate the cloud-based CVM back to IDC
./l2gw_ipaddr.sh switch_vpc_to_idc <CVM_IP> <eth_interface> <vxlan_id>

Bringing L2GW Devices Online and Offline

# Decommission (Stop keepalived and switch traffic to the secondary node)
./l2gw_offline.sh

# Go-live (Start keepalived)
./l2gw_online.sh

Adding a Large Layer-2 Subnet

Complete process for adding a new Layer 2 subnet:
1. Create a cross-tenant ENI for L2GW > VPC and bind it to the L2GW CVM.
Confirm that the corresponding eth NIC status is Down and enable DirectSend. Apply for a subnet and bind the High Availability Virtual IP address (HAVIP1) to this NIC. Then, call ./l2gw_install_interface.sh add to complete the initialization.
2. Create a cross-tenant ENI for L2GW > IDC and bind it to the L2GW CVM.
Confirm that the corresponding eth NIC status is Down and enable DirectSend. Apply for and bind the High Availability Virtual IP (HAVIP2) to this NIC (execute as neededif the network of this NIC is already reachable, do not create it). Then, call ./l2gw_install_interface.sh add to complete the initialization.
3. Create a VXLAN tunnel for L2GW > IDC-Switch. Call ./l2gw_subnet.sh add to add the tunnel and configure parameters for the peer IDC switch.
4. Add all L2GW routes: Call ./l2gw_ipaddr.sh add.
5. Modify the Keepalived configuration: Manually add HAVIP1 and HAVIP2 (if any) to the Keepalived configuration file by Ops personnel (back up before modification, example: 192.168.1.102 dev eth1). Then, call l2gw_reload.sh to make the configuration take effect online.
6. Add VPC routes: including routes from VPC to L2GW CVM and routes for traffic steering via Direct Connect/LGW.

Deleting a Large Layer-2 Subnet

The deletion process is the reverse of the addition process:
1. Delete VPC routes, routes from VPC to L2GW CVM, and routes for traffic attraction via Direct Connect/LGW.
2. Modify the Keepalived configuration by removing havip1 and havip2 (if any) from the Keepalived configuration file (example: 192.168.1.102 dev eth1). Then, execute the l2gw_reload.sh command to bring the configuration online.
3. Delete the VXLAN tunnel for L2GW > IDC-Switch. Execute ./l2gw_subnet.sh del and configure the peer IDC switch.
4. Execute ./l2gw_install_interface.sh del to delete the NIC.
5. Unbind and delete havip1 and havip2 (if any) in the VPC test. Also, unbind and delete the ENI. (Note: The L2GW > IDC-Switch NIC used by the Keepalived VRRP heartbeat cannot be unbound or deleted and must be retained long-term.)
Attention:
The IDC-facing network interface card used for the VRRP heartbeat cannot be unbound or deleted and must be retained long-term.

CVM Restart and Recovery Process

After the L2GW CVM restarts, network configurations are lost (service is not affected due to primary/secondary switchover):
Server Restart
  │
  ├── Step 1: Execute the commands in the l2gw_history_cmd.log file line by line (to restore network configuration)
  │
  Step 2: Execute ./l2gw_online.sh (to bring the gateway online + start keepalived). Do not skip this step!
Procedure:
cd /data/l2gw

# 1. View Historical Commands
cat l2gw_history_cmd.log

# 3. Go-live
./l2gw_online.sh
Attention:
Critical Reminder: If you only restore the configuration without executing the go-live script, the L2GW will not function properly! Do not omit the l2gw_online.sh step.

Monitoring Recommendations

Monitoring Item
Metric Value
Alarm Threshold
L2GW CVM Status
CVM running status
abnormal shutdown
Keepalived Primary/Secondary Status
VRRP role
primary/secondary switchover alarm
Network connectivity
ping cloud-based CVM/IDC CVM
consecutive packet loss for 3 times
VXLAN Tunnel Status
Tunnel interface UP/DOWN
interface DOWN
Elastic Network Interface
NIC binding status
unbinding alarm
Bandwidth utilization
Outbound + inbound bandwidth
alarm when 80% is exceeded
HAVIP Binding Status
Floating IP address ownership
HAVIP drift alarm

Tencent Cloud Official Website FAQs

Direct Connect FAQs

Question 1: What Is the Difference Between Direct Connect and a Common Public Network VPN?

Direct Connect provides dedicated physical network connections that are completely isolated from the public network. Compared to VPN:
Direct Connect: low latency (< 5 ms within the same city), high bandwidth (up to 100 Gbps), and high security (dedicated link).
VPN: It relies on the public network, with unstable latency and bandwidth, and applies to scenarios where network quality requirements are not high.

Question 2: Does Direct Connect Support Link Aggregation (LACP)?

Currently, Tencent Cloud does not support the LACP Link Aggregation Control Protocol. For higher bandwidth requirements, you can use multiple physical dedicated lines for CLB.

Question 3: Must the Same Subnet Mask Be Used at Both Ends of the Direct Connect?

Yes. The interconnect IP addresses configured at both ends of the dedicated line must belong to the same subnet and be configured with the same subnet mask. Furthermore, the IP addresses at both ends must be unique, and IP address reuse is not allowed.

Question 4: How to Implement Primary/Secondary Redundancy for Direct Connect

Two solutions:
1. Dual Direct Connect backup: You can achieve static route failover by configuring BFD, or use BGP routing for automatic convergence.
2. Direct Connect + VPN primary/secondary: Direct Connect serves as the primary link, and VPN serves as the secondary link. Automatic failover is achieved through VPC route priority.

VPC and Networking

Question 1: How to Point a VPC Subnet Route Table to the HAVIP of an L2GW?

Configure the destination network segment via the VPC route table, with the next hop type set to HAVIP. The current network supports scenarios where the destination network segment overlaps with the VPC CIDR/subnet CIDR block when the subnet route table's next hop is HAVIP.

Question 2: What Is an ENI? What Are Its Limitations?

An ENI (Elastic Network Interface) is a cross-account shared ENI that allows a CVM from one account to bind to a network interface in another account's VPC subnet. In the L2GW scenario, it enables the L2GW CVM of the management account to access the VPC resources of the user account.
Usage restriction: A CVM can be bound to multiple ENIs. The specific number depends on the CVM specification.
Reference: ENI Overview

Question 3: What to Do If the Direct Connect Tunnel Does Not Support VLAN Tags?

If your dedicated line service provider supplies only a single-VLAN physical dedicated line, and you need to access multiple VPCs in the cloud, you can use the CCN (Cloud Connect Network) product to connect one physical dedicated line to multiple VPCs.

L2GW FAQs

Question 1: Why Do I Need to Reconfigure After an L2GW CVM is restarted?

The network configuration of the L2GW CVM (including ETH interface initialization, VXLAN tunnels, IP address routing, and so on) is stored in memory and is lost after the CVM restarts. However, service is not affected because the L2GW operates in a primary/secondary mode, and the secondary L2GW takes over the traffic.
Recovery Steps After Restart:
1. Restore the configuration line by line according to the commands recorded in the l2gw_history_cmd.log file.
2. Execute ./l2gw_online.sh to bring the gateway online.

Question 2: Why Can't the VRRP Heartbeat NIC Be Deleted?

The VRRP heartbeat network interface card (typically eth2) is used for VRRP protocol communication between the primary and secondary L2GWs. If this network interface card is deleted, the primary and secondary L2GWs will be unable to detect each other's liveliness status. This may lead to a split-brain scenario (where both L2GWs simultaneously hold the HAVIP), causing network loops or packet loss.

Troubleshooting

Question 1: Maintenance Boundary

L2GW is essentially a Layer 2 gateway software deployed on a CVM (Cloud Virtual Machine). Its runtime environment (including the operating system, system configuration, network parameters, Keepalived high availability, and so on) is deployed under the customer's cloud account. Therefore, Ops tasks for L2GW, such as daily maintenance, monitoring, failure recovery, and configuration changes, are the responsibility of the customer's Ops team.
Misconception
Actual Situation
L2GW is a managed service provided by Tencent Cloud.
L2GW is a deployment solution, not a managed service. Tencent Cloud provides deployment guidance and script tools, while Ops is the responsibility of the customer.
Tencent Cloud monitors the L2GW operational status.
Tencent Cloud monitors only the infrastructure layer (physical dedicated lines, dedicated line/LGW devices), and does not monitor components within the L2GW CVM, such as Keepalived, VXLAN tunnels, and service routes.
Tencent Cloud is responsible for L2GW version upgrades.
The upgrade of the L2GW deployment package is performed by the customer's Ops team, while Tencent Cloud provides the new version of the deployment package and technical guidance.
When L2GW encounters issues, you can submit a ticket for Tencent Cloud to fix them.
Tencent Cloud's scope of support covers infrastructure and product defects. Issues at the L2GW configuration level, such as incorrect route configuration or Keepalived configuration exceptions, fall within the customer's Ops responsibility.

Question 2: What to Do If the Direct Connect Stress Test Results Do Not Meet Expectations?

Troubleshooting steps:
1. Confirm whether the purchased dedicated line bandwidth meets expectations.
2. Test whether there is packet loss when the interconnect IP address is pinged. If packet loss is severe, contact Tencent Cloud after-sales support or report the issue to your carrier.
3. Check whether the duplex mode of the local dedicated line router is set to full-duplex.
4. Use multi-process concurrent stress testing tools such as iperf to rule out application issues.

Question 3: What to Do If a Specific Network Segment of the Direct Connect Is Unreachable via ping?

Troubleshooting steps:
1. Confirm whether the network segment is newly enabled. (New network segments require route configuration on the cloud.)
2. Check whether the route tables in the cloud have the corresponding routes pointing to the dedicated line gateway.
3. Confirm whether the cloud security groups and network ACLs allow traffic.
4. Check whether the client iptables have any blocking rules.
5. Check whether there is any abnormal MAC address learning on the IDC side.

Question 4: How to Handle a Direct Connect Outage?

1. Confirm the interruption cause: check whether the interconnect IP address is reachable via ping and whether the peer MAC address can be received.
2. The dedicated line is owned by Tencent Cloud: contact the Tencent Cloud after-sales service team. (The system will automatically receive the alarm and report the issue to the carrier.)
3. The dedicated line is owned by the user: The user should report the fault to the carrier, and request Tencent Cloud to assist with troubleshooting when necessary.

Troubleshooting Guide

Common Fault Quick Reference

Failure Symptoms
Possible cause
Troubleshooting method
Solution
Connectivity failure between cloud and on-premises environments
VXLAN Tunnel Abnormal
Check VXLAN tunnel interface status.
Recreate the VXLAN tunnel.
Frequent primary/secondary switchover
Unstable VRRP Heartbeat
Check eth2 NIC status and network latency.
Optimize the network link or adjust the VRRP timeout parameters.
Partial IP address connectivity failure
Missing Route Configuration
Compare l2gw_history_cmd.log.
Add the missing IP address route
HAVIP drift anomaly
Incorrect Keepalived Configuration
Check virtual_ipaddress configuration.
Correct the configuration and run l2gw_reload.sh.
Service connectivity failure after restart
Failure to Execute the Online Script
Check keepalived process status.
Run ./l2gw_online.sh.

Log Viewing Guide

Log File
Content
Purpose
/data/l2gw/l2gw_history_cmd.log
Historical Configuration Commands
Reference for configuration recovery after restart
/var/log/keepalived.log
Keepalived Primary/Secondary Switchover Logs
Troubleshoot VRRP-related faults.
/var/log/messages
System Logs
Troubleshoot NIC and kernel abnormalities.

Daily Inspection Checklist

Check the operational status of each L2GW CVM.
Check the primary/secondary status of Keepalived.
Verify that the HAVIP is bound to the correct L2GW.
Test the connectivity between cloud-based and on-premises CVMs using ping.
Check the status of the VXLAN tunnel interface.
Check the binding status of the ENI.
Monitor the bandwidth utilization to check whether it exceeds 80%.
Verify the integrity of the l2gw_history_cmd.log file.
Confirm that the initialization script in rc.local is valid.


Topik selanjutnya: Catatan Rilis

Bantuan dan Dukungan

Apakah halaman ini membantu?

masukan