Vietnamese Professional - CCIE Security

Hướng dẫn Troubleshooting GRE Tunnel

dangquangminh — Fri, 05 Jun 2026 11:16:24 GMT

Hướng dẫn troubleshooting GRE Tunnel

Generic Routing Encapsulation (GRE) là một giao thức đường hầm (tunneling protocol) được sử dụng để đóng gói nhiều loại gói tin lớp mạng khác nhau bên trong giao thức GRE để có thể truyền qua mạng IP. Ví dụ, bạn có thể đóng gói các gói tin IPv6 bên trong GRE để truyền qua hạ tầng IPv4. GRE là một chủ đề khá rộng. Tuy nhiên, trong phạm vi phục vụ cho việc troubleshooting và ôn tập chứng chỉ CCNP, chúng ta sẽ tập trung vào các lợi ích của GRE trong kết nối site-to-site và những nguyên nhân thường gặp khiến GRE Tunnel không hoạt động như mong đợi.

GRE Tunnel hoạt động như thế nào?

GRE cho phép tạo một kết nối điểm-điểm (point-to-point) ảo giữa hai router Cisco ở xa nhau thông qua mạng IP trung gian.
Trong ví dụ HQ (San Francisco), Branch (Toronto) cùng kết nối Internet nhưng không kết nối trực tiếp với nhau. Thông qua GRE Tunnel HQ sử dụng địa chỉ Tunnel: 172.16.1.1/30, Branch sử dụng địa chỉ Tunnel: 172.16.1.2/30.
Cấu hình router HQ:
interface Tunnel0
ip address 172.16.1.1 255.255.255.252
tunnel source FastEthernet3/0
tunnel destination 203.0.113.1
Router chi nhánh Branch:
interface Tunnel0
ip address 172.16.1.2 255.255.255.252
tunnel source FastEthernet1/0
tunnel destination 192.0.2.1
Nếu không chỉ định tunnel mode thì Cisco sẽ sử dụng mặc định:
tunnel mode gre ip hay còn gọi là GRE/IP.

Lợi ích lớn nhất của GRE

GRE cho phép hai site trao đổi thông tin định tuyến động (OSPF, EIGRP, RIP...) qua Internet. Ví dụ Router HQ học được mạng 192.168.1.0/24 từ Branch. Router Branch học được mạng 10.1.1.0/24 từ HQ. Điều này rất hữu ích khi xây dựng VPN Site-to-Site hoặc DMVPN.

Cấu trúc gói tin GRE

Khi một gói tin đi qua GRE Tunnel, Router Cisco sẽ:
Bước 1: Giữ nguyên gói tin gốc (Passenger Protocol)
Bước 2: Thêm GRE Header (Carrier Protocol)
Bước 3: Thêm IP Header mới (Transport Protocol)
Điều này cho phép gói tin riêng tư bên trong được vận chuyển qua Internet công cộng.

7 Nguyên Nhân Thường Gặp Khi GRE Tunnel Không Hoạt Động

1. Hai đầu không reach được nhau qua mạng công cộng

GRE Tunnel không thể hình thành nếu hai router không ping được địa chỉ public của nhau. Cách Kiểm tra:
ping
Ví dụ:
HQ# ping 203.0.113.1
Branch# ping 192.0.2.1
Nếu ping thất bại, hãy kiểm tra Routing, ISP, ACL, Firewall, NAT.

2. Địa chỉ Tunnel IP không cùng subnet

Tunnel Interface thực chất là một kết nối point-to-point. Hai đầu tunnel phải nằm trong cùng subnet. Ví dụ đúng:
HQ 172.16.1.1/30
Branch 172.16.1.2/30
Lệnh dùng để Kiểm tra:
show interfaces tunnel 0
show ip interface brief

3. Sai Tunnel Source hoặc Tunnel Destination

GRE cần biết tunnel bắt đầu từ đâu (source) và tunnel kết thúc ở đâu (destination). Hai đầu phải đối xứng. Ví dụ:
HQ:
tunnel source 192.0.2.1
tunnel destination 203.0.113.1
Branch:
tunnel source 203.0.113.1
tunnel destination 192.0.2.1
Chỉ cần sai một địa chỉ là Tunnel sẽ down.

4. Sai Tunnel Mode

Để vận chuyển IPv4 hoặc IPv6 qua mạng IPv4 cần dùng:
tunnel mode gre ip
Khi kiểm tra:
show interfaces tunnel 0
Bạn sẽ thấy:
Tunnel protocol/transport GRE/IP

5. ACL hoặc Firewall chặn GRE

Đây là lỗi rất phổ biến ngoài thực tế. GRE không dùng TCP hay UDP.. GRE sử dụng IP Protocol Number = 47. Nhiều firewall cho phép TCP, UDP, ICMP nhưng lại vô tình chặn Protocol 47.
Kiểm tra:
show ip interface
show access-list
Nếu có ACL giữa hai site, hãy đảm bảo GRE được permit.

6. Fragmentation và MTU

GRE Header chiếm 24 bytes, do đó 1500 - 24 = 1476 bytes
Payload thực tế chỉ còn khoảng 1476 bytes. Nếu máy trạm gửi gói lớn hơn 1476 bytes, Router phải thực hiện fragmentation. Hậu quả là tăng CPU, tăng độ trễ, giảm throughput, hiệu năng tunnel giảm. Kiểm tra:
show interfaces tunnel 0
Ví dụ:
Tunnel transport MTU 1476 bytes

7. Recursive Routing

Đây là lỗi kinh điển trong GRE. Thông báo:
%TUN-5-RECURDOWN:
Tunnel0 temporarily disabled due to recursive routing
Ý nghĩa là Router đang cố đi tới địa chỉ đích của tunnel bằng chính Tunnel Interface.
Ví dụ:
Tunnel Destination
↓
Routing Table
↓
Tunnel0
Điều này tạo vòng lặp logic. Tunnel sẽ tự động shutdown để bảo vệ hệ thống. Nguyên nhân thường gặp của lỗi này là:

Cấu hình Route mặc định sai

Dynamic routing học sai đường đi

Thiếu route tới địa chỉ public của peer

8. Routing Protocol không chạy trên Tunnel

Tunnel UP không đồng nghĩa lưu lượng sẽ đi qua được.
Nếu muốn học route động qua GRE, EIGRP, OSPF, IS-IS
thì Tunnel Interface phải được đưa vào tiến trình định tuyến. Ví dụ:
router ospf 1
network 172.16.1.0 0.0.0.3 area 0
Nếu chúng ta lỡ quên bước này thì tunnel vẫn UP, ping tunnel vẫn được, nhưng lúc này router không học route từ đầu bên kia
Đây là lỗi rất dễ gặp trong quá trình triển khai GRE thực tế.

Góc nhìn thực chiến CCNP/CCIE

Khi gặp sự cố GRE Tunnel, thứ tự kiểm tra nhanh mà chúng ta nên thực hiện thường sẽ là:

Ping địa chỉ public hai đầu.

Kiểm tra Tunnel Source/Destination.

Kiểm tra trạng thái Tunnel Interface.

Kiểm tra Protocol 47 có bị firewall chặn hay không.

Kiểm tra routing tới Tunnel Destination.

Kiểm tra MTU/Fragmentation.

Kiểm tra OSPF/EIGRP đang chạy trên Tunnel Interface hay chưa.

Trong môi trường doanh nghiệp, hơn 80% sự cố GRE thường xuất phát từ ba nguyên nhân: không reach được địa chỉ public, sai tunnel source/destination hoặc firewall chặn GRE Protocol 47. Đây luôn là những điểm nên kiểm tra đầu tiên trước khi đi sâu vào các vấn đề phức tạp hơn.

DHCP Dora

dangquangminh — Thu, 28 May 2026 10:38:32 GMT

DHCP – “Người phát IP” thầm lặng mà gần như mọi mạng doanh nghiệp đều đang sử dụng.

Hầu như mỗi lần chúng ta bật laptop, kết nối Wi-Fi công ty, cắm dây mạng vào switch hay khởi động máy ảo trong Data Center… đều có một tiến trình âm thầm diễn ra phía sau: DHCP. Nếu DHCP gặp sự cố, người dùng thường chỉ thấy một triệu chứng rất quen thuộc: “Có mạng nhưng không vào được Internet” hoặc “Máy tự nhận IP 169.254.x.x”.
DHCP (Dynamic Host Configuration Protocol) là giao thức phổ biến nhất dùng để cấp phát thông tin IPv4 cho thiết bị đầu cuối. Thay vì kỹ sư mạng phải cấu hình IP thủ công cho từng máy, DHCP cho phép client tự động nhận IP address, subnet mask, default gateway, DNS server và nhiều thông tin mạng khác từ DHCP Server.
DHCP Server có thể nằm ngay trong cùng subnet với client, ở subnet khác, hoặc thậm chí chính router default gateway cũng có thể đóng vai trò DHCP Server.
Trong môi trường doanh nghiệp, khi một PC vừa khởi động, nó chưa biết gì về mạng cả. Nó chưa có IP address, chưa có default gateway, cũng chưa biết DNS server là gì. Vì vậy, DHCP phải hoạt động theo một cơ chế “hỏi – đáp” đặc biệt gọi là quy trình DORA.
DORA gồm 4 bước:
D – Discover
O – Offer
R – Request
A – Acknowledgment
Đây là một trong những kiến thức quan trọng cho CCNA, CCNP và cả troubleshooting thực tế.

Bước 1 – DHCP Discover

Khi client vừa boot lên, nó sẽ gửi một gói DHCPDISCOVER để tìm DHCP Server. Vì chưa có IP address nên:

Source IP sẽ là 0.0.0.0

Destination IP sẽ là 255.255.255.255

Destination MAC sẽ là FFFF.FFFF.FFFF

Điều này có nghĩa client đang gửi broadcast ra toàn mạng LAN với nội dung kiểu như:
“Có DHCP Server nào ngoài kia không? Cho tôi xin IP với!”
Ví dụ:
Source IP: 0.0.0.0
Destination IP: 255.255.255.255
Đây là lý do vì sao khi capture Wireshark trong mạng LAN, bạn thường thấy các gói DHCP broadcast xuất hiện ngay khi máy tính bật lên.

Bước 2 – DHCP Offer

Khi DHCP Server nhận được gói Discover, nó sẽ phản hồi bằng gói DHCPOFFER. Trong gói này sẽ có:

IP address đề nghị cấp

Subnet mask

Default gateway

DNS server

Lease time

Ví dụ:
IP address: 10.1.1.50
Subnet Mask: 255.255.255.0
Gateway: 10.1.1.1
DNS: 8.8.8.8
Điểm thú vị là trong mạng có thể tồn tại nhiều DHCP Server cùng lúc. Vì DHCP Discover là broadcast nên nhiều server đều có thể trả lời Offer. Thông thường client sẽ chọn DHCP Server nào phản hồi nhanh nhất. Đây cũng là nguyên nhân gây ra các sự cố cực kỳ nguy hiểm như Rogue DHCP Server, DHCP Spoofing, Client nhận sai gateway hoặc toàn bộ traffic bị redirect sang máy của kẻ tấn công attacker. Đó là lý do các doanh nghiệp thường triển khai DHCP Snooping, IP Source Guard, Dynamic ARP Inspection
để bảo vệ hệ thống switching Layer 2.

Bước 3 – DHCP Request

Sau khi chọn được server phù hợp, client sẽ gửi DHCPREQUEST.
Nội dung của gói này giống như:
“Tôi đồng ý dùng IP mà anh vừa đề nghị. Hãy lease IP này cho tôi.”
Điểm quan trọng là DHCPREQUEST vẫn được gửi dưới dạng broadcast. Lý do là để thông báo cho các DHCP Server khác biết rằng client đã chọn server nào. Các server còn lại sẽ thu hồi các địa chỉ đã Offer nhưng chưa dùng.

Bước 4 – DHCP ACK

Cuối cùng DHCP Server gửi DHCPACK để xác nhận việc cấp phát IP hoàn tất. Lúc này client chính thức sử dụng IP address, cấu hình default gateway, Client đã Có thể giao tiếp mạng. Nếu mọi thứ thành công, người dùng bắt đầu truy cập được mạng và Internet.

Một vấn đề rất quan trọng: Broadcast không đi qua Router

Đây là phần mà rất nhiều bạn CCNA dễ quên. DHCP Discover là broadcast Layer 3 255.255.255.255. Router mặc định sẽ không forward broadcast. Điều này có nghĩa là nếu DHCP Server nằm khác subnet thì Client sẽ KHÔNG tìm thấy DHCP Server. Ví dụ như trong hình dưới đây:
PC VLAN 10 ---> Router ---> DHCP Server VLAN 20
Trong trường hợp này, router phải đóng vai trò DHCP Relay Agent.
Trên Cisco IOS, ta dùng lệnh:
interface vlan 10
ip helper-address 10.20.20.5
Lệnh ip helper-address sẽ nhận broadcast DHCP từ client, sau đó convert thành unicast và router sẽ Forward tới DHCP Server. Đây là một trong những lệnh “kinh điển” của CCNA và xuất hiện rất nhiều trong troubleshooting thực tế.

Các lỗi DHCP rất thường gặp ngoài đời thật

Một vài lỗi phổ biếnliên quan đến DHCP là:

Quên cấu hình ip helper-address

DHCP pool hết IP

Default gateway cấu hình sai

Rogue DHCP Server trong mạng

DHCP Snooping chặn nhầm port

VLAN trunk không cho phép VLAN DHCP đi qua

Client nhận APIPA 169.254.x.x

Ví dụ:
Windows IP Configuration

IPv4 Address: 169.254.10.5
Điều này thường có nghĩa:
Client không liên lạc được DHCP Server.

Góc nhìn thực chiến

Trong troubleshooting thực tế, DHCP thường là nơi đầu tiên kỹ sư mạng kiểm tra khi người dùng báo “Không vào mạng được”, “Có Wi-Fi nhưng không có Internet”, “Máy nhận IP lạ”, “Ping gateway không được”. Một kỹ sư giỏi không chỉ nhớ DORA, mà còn phải hiểu cặn kẽ:

Gói tin Broadcast hoạt động ra sao

Router sẽ xử lý DHCP Relay thế nào

Vì sao DHCP Snooping có thể làm client fail DHCP

Cách packet di chuyển giữa VLAN và DHCP Server

Đây là nền tảng cực kỳ quan trọng trước khi đi sâu hơn vào Network Security, NAC / Cisco ISE, Campus Architecture, SD-Access, Zero Trust Network Access (ZTNA)

Một router – nhiều “thế giới mạng”: VRF Lite hoạt động như thế nào?

KhanhHa — Sat, 09 May 2026 09:16:06 GMT

Một router – nhiều “thế giới mạng”: VRF Lite hoạt động như thế nào?

Trong thực tế triển khai mạng (đặc biệt ở ISP hoặc doanh nghiệp lớn), có một bài toán rất “kinh điển”:
Làm sao để một router có thể phục vụ nhiều hệ thống mạng khác nhau mà các hệ thống này không nhìn thấy nhau?
Nếu bạn chỉ dùng routing truyền thống → gần như không thể làm sạch sẽ và an toàn.
Đây chính là lúc VRF Lite xuất hiện. Vấn đề của routing truyền thống

Mặc định, router hoạt động với 1 global routing table duy nhất. Chứa:

Các mạng directly connected

Static routes

Dynamic routes (OSPF, EIGRP, BGP)

Ví dụ ban đầu trên router ISP:
ISP#show ip route connected
C 192.168.1.0/24 is directly connected
C 192.168.2.0/24 is directly connected
C 192.168.3.0/24 is directly connected
C 192.168.4.0/24 is directly connected

Tất cả network nằm chung một bảng định tuyến
Không có sự tách biệt → rủi ro về security và design VRF Lite là gì?

Bạn có thể hiểu rất nhanh:
VRF = VLAN nhưng dành cho Layer 3

Mỗi VRF = 1 routing table riêng biệt

Interface nào thuộc VRF nào → chỉ dùng routing table đó

Các VRF không nhìn thấy nhau

Áp dụng vào topology (hình lab)

Blue1 + Blue2 → thuộc VRF Blue

Red1 + Red2 → thuộc VRF Red

ISP → router trung tâm

Kết quả mong muốn:

Blue chỉ communicate với Blue

Red chỉ communicate với Red

Hai bên isolate hoàn toàn

Cấu hình VRF Lite (trên ISP)

1. Tạo VRF

ISP(config)#ip vrf Red
ISP(config-vrf)#exit
ISP(config)#ip vrf Blue
ISP(config-vrf)#exit
Lúc này mới chỉ tạo “container routing”, chưa có gì bên trong 2. Gán interface vào VRF

ISP(config)#interface FastEthernet0/0
ISP(config-if)#ip vrf forwarding Blue
Điểm rất quan trọng:
Khi gán VRF → IP trên interface sẽ bị xóa
Phải cấu hình lại:
ISP(config-if)#ip address 192.168.1.254 255.255.255.0 Kiểm tra routing table

Sau khi gán toàn bộ interface vào VRF: Global routing table gần như trống Routing table của từng VRF

VRF Blue:
ISP#show ip route vrf Blue connected
C 192.168.1.0/24
C 192.168.3.0/24
VRF Red:
ISP#show ip route vrf Red connected
C 192.168.2.0/24
C 192.168.4.0/24
Mỗi VRF có “thế giới riêng” Lỗi phổ biến (rất nhiều người gặp)

Bạn thử ping: Không được → tưởng sai config
Nhưng thực tế:
Router mặc định ping bằng global routing table Cách ping đúng trong VRF

ISP#ping vrf Blue 192.168.1.1 thì Chỉ định rõ VRF cần sử dụng VRF và Dynamic Routing

VRF không chỉ dùng static. Bạn hoàn toàn có thể chạy:

OSPF

EIGRP

Ví dụ OSPF cho VRF Blue

Blue1(config)#router ospf 1
network 192.168.1.0 0.0.0.255 area 0
network 1.1.1.1 0.0.0.0 area 0
Blue2(config)#router ospf 1
network 192.168.3.0 0.0.0.255 area 0 OSPF trên ISP cho VRF Red

ISP(config)#router ospf 2 vrf Red
network 192.168.2.0 0.0.0.255 area 0
network 192.168.4.0 0.0.0.255 area 0
Mỗi VRF cần process OSPF riêng Routing table sau khi chạy OSPF

VRF Blue:
ISP#show ip route vrf Blue ospf
O 1.1.1.1 via 192.168.1.1
O 3.3.3.3 via 192.168.3.3
VRF Red:
ISP#show ip route vrf Red ospf
O 2.2.2.2 via 192.168.2.2
O 4.4.4.4 via 192.168.4.4
Hai bảng định tuyến hoàn toàn độc lập Không bị leak route Góc nhìn Security (điều quan trọng)

VRF không chỉ là kỹ thuật routing.
Nó là một cơ chế segmentation Layer 3
Ứng dụng thực tế:

Tách khách hàng trong ISP

Tách môi trường (Production / Lab)

Tách hệ thống nội bộ (HR / IT / Finance)

Giảm blast radius khi có sự cố

ví dụ:

Router = tòa nhà

VRF = từng căn hộ

Người ở phòng Blue không thể sang phòng Red dù cùng một tòa nhà vật lý Chốt lại là

VRF Lite là một trong những nền tảng quan trọng:

Thiết kế mạng multi-tenant

Network segmentation (Security)

Bước đệm để học MPLS VPN

Điểm mấu chốt không phải là “thuộc lệnh” mà là hiểu: mỗi VRF là một routing domain độc lập
Nếu bạn đang học:

CCNA → nên biết khái niệm

CCNP → phải lab thành thạo

CCIE → dùng VRF như một công cụ thiết kế