Vietnamese Professional - CISCO ISE

Phân tích chuyên sâu: Vì sao VXLAN dùng UDP?

dangquangminh — Sun, 07 Jun 2026 05:38:22 GMT

Phân tích chuyên sâu: Vì sao VXLAN dùng UDP?

Một câu hỏi rất hay khi học VXLAN là:

Tại sao VXLAN không chạy trực tiếp trên IP mà lại phải dùng UDP?

Lý do quan trọng nhất là hỗ trợ ECMP (Equal-Cost Multi-Path) trong Data Center.

Trong mạng Spine-Leaf hiện đại, giữa hai VTEP thường tồn tại nhiều đường đi song song. Các switch Spine sẽ sử dụng cơ chế hash dựa trên:

Source IP
Destination IP
Source Port
Destination Port

để phân phối lưu lượng lên nhiều đường vật lý khác nhau.

Nếu VXLAN chỉ dùng IP Protocol Number như GRE truyền thống, khả năng cân bằng tải sẽ kém hơn.

Bằng cách sử dụng UDP:

UDP Destination Port = 4789
UDP Source Port = Hash từ gói tin gốc

VXLAN tạo ra nhiều giá trị hash khác nhau, giúp:

Tận dụng toàn bộ băng thông Spine-Leaf
Tránh hiện tượng một đường quá tải trong khi các đường khác nhàn rỗi
Tăng hiệu quả truyền tải cho East-West Traffic

Đây là một trong những lý do khiến VXLAN trở thành công nghệ Overlay phổ biến nhất trong các Data Center hiện đại.

Vai trò của VNI

Trong mạng truyền thống:
VLAN ID: 12 bit
=> 4096 VLAN

Trong VXLAN:
VNI: 24 bit
=> 16.777.216 Segment

Điều này giải quyết hoàn toàn giới hạn VLAN trong các môi trường:

Cloud
Multi-Tenant Data Center
Private Cloud
AI Factory
Kubernetes Cluster quy mô lớn

Ví dụ:
VLAN 10 --> VNI 10010
VLAN 20 --> VNI 10020
VLAN 30 --> VNI 10030

Các máy chủ thuộc cùng VNI vẫn có thể giao tiếp Layer 2 với nhau ngay cả khi nằm ở các rack khác nhau hoặc ở các Leaf khác nhau.

Góc nhìn CCIE Data Center

Nếu xem VXLAN như một "chiếc phong bì", thì:

Frame Ethernet gốc là lá thư bên trong.
VNI là thông tin xác định tenant hoặc segment.
Outer IP là địa chỉ của hai bưu điện (VTEP).
UDP giúp hệ thống vận chuyển khai thác tối đa các tuyến đường trong Data Center.

Nhờ cơ chế này, VXLAN có thể mở rộng Layer 2 trên nền mạng IP Layer 3, đồng thời tận dụng toàn bộ ưu điểm của kiến trúc Spine-Leaf hiện đại. Đây chính là nền tảng của VXLAN EVPN đang được triển khai rộng rãi trong các Data Center, Cloud và AI Fabric ngày nay.

AIOPs

dangquangminh — Thu, 21 May 2026 12:23:55 GMT

Lời hứa của AIOps: Khi vận hành mạng không còn là cuộc chiến chữa cháy

Trong nhiều năm, đội vận hành hạ tầng CNTT thường sống trong trạng thái quen thuộc: màn hình đầy cảnh báo, điện thoại reo vì sự cố, người dùng than phiền hệ thống chậm, và kỹ sư phải lao vào tìm nguyên nhân giữa hàng ngàn log. AIOps xuất hiện để thay đổi cách vận hành đó. AIOps (Artificial Intelligence for IT Operations) không đơn giản chỉ là “thêm AI vào monitoring”. Nó là cách dùng machine learning, analytics, automation và correlation engine để biến dữ liệu vận hành thành hành động có giá trị.

1. Biến dữ liệu mạng thành insight có thể hành động

Network tạo ra lượng dữ liệu khổng lồ:

Syslog
SNMP telemetry
NetFlow / IPFIX
API metrics
Cloud monitoring data
Application performance data
Security events

Vấn đề là dữ liệu nhiều không đồng nghĩa với hiểu biết nhiều. AIOps giúp:

gom dữ liệu từ nhiều nguồn
correlation các event liên quan
phát hiện pattern bất thường
đưa ra nguyên nhân khả dĩ

Ví dụ: AI không chỉ báo:

"Interface utilization 95%"

Mà còn suy luận:

"Traffic spike từ ứng dụng backup làm saturate uplink, ảnh hưởng VoIP latency."

Đây là khác biệt giữa monitoring và intelligence.

2. Phát hiện vấn đề trước khi người dùng gọi điện

Mô hình truyền thống:

Issue xảy ra → User complain → IT điều tra

Còn AIOps hướng đến:

Telemetry trend → anomaly detection → predictive warning

Ví dụ:

AI thấy:

packet loss tăng dần
interface error tăng nhẹ
CPU switch tăng bất thường
wireless retransmission leo thang

Con người có thể bỏ sót.

Model ML thì thấy đây là pattern dẫn tới outage.

Kết quả:

Bạn xử lý trước khi người dùng biết có vấn đề.

Đây chính là proactive operations.

3. Giảm alert noise

SOC và NOC đều có chung một vấn đề:

Too many alerts. Too little signal.

Một lỗi thật có thể tạo ra:

200 syslog
40 SNMP traps
15 cloud alerts
10 application alarms

Nếu không correlation:

mọi thứ nhìn như 265 sự cố khác nhau.

AIOps giúp event deduplication và correlation:

"Tất cả các alert này cùng bắt nguồn từ core switch uplink failure."

Thay vì kỹ sư đọc từng log, hệ thống highlight thứ thực sự quan trọng.

4. Tăng tốc Root Cause Analysis

MTTR (Mean Time To Resolution) là KPI đau đầu nhất.

Thông thường RCA mất thời gian vì:

log nằm nhiều hệ thống
phải cross-check app + network + security
dependency mapping không rõ

AIOps giúp:

dependency graph
event timeline
anomaly correlation
probable root cause suggestion

Ví dụ:

Không chỉ nói:

"Database timeout"

Mà nói:

"Database timeout caused by east-west packet drops in spine-leaf fabric after policy push."

Khác biệt rất lớn.

5. Automation nhưng kỹ sư vẫn kiểm soát

Một nỗi sợ phổ biến:

"AI có thay kỹ sư mạng không?"

Thực tế AIOps tốt không tự động phá hệ thống. Mô hình an toàn hơn là:

human-in-the-loop automation

AI có thể:

đề xuất remediation
generate config
suggest rollback
trigger workflow

Nhưng kỹ sư sẽ là người approve.

Ví dụ:

AI đề xuất:

restart service
move traffic
reroute path
isolate bad node

Engineer quyết định.

AI là copilote, không phải ông chủ.

6. tính khả kiến Visibility toàn hệ thống

Network hiện đại không còn chỉ là switch/router. Hạ tầng giờ gồm:

campus
data center
cloud
wireless
WAN
SD-WAN
containers
applications
APIs

AIOps tạo unified observability. Nếu không, mỗi team nhìn một mảnh:

Network team thấy interface OK
App team thấy response time tăng
Security team thấy odd traffic
Cloud team thấy CPU spike

AIOps sẽ ghép toàn bộ bức tranh của toàn bộ hạ tầng mạng.

7. Kỹ sư tập trung đổi mới thay vì chữa cháy

Đây mới là lợi ích lớn nhất.

Nếu mỗi ngày chỉ:

clear alert
check log
restart service
xử lý ticket

thì đội kỹ thuật không tạo ra innovation.

AIOps giải phóng thời gian để kỹ sư tập trung:

automation
architecture
security improvement
capacity planning
AI infrastructure design

Góc nhìn thực tế

AIOps không phải magic.

Muốn hiệu quả cần:

telemetry sạch
data normalization
integration tốt
automation governance
quality alerting baseline

Garbage in → garbage out.

Nếu monitoring hỗn loạn, AI chỉ giúp tạo ra hỗn loạn thông minh hơn.

AIOps không thay thế người vận hành. Nó thay thế cách vận hành thủ công lỗi thời.

Khắc phục sự cố nguồn thông tin định tuyến (Troubleshooting Routing Information Sources)

dangquangminh — Mon, 11 May 2026 12:08:15 GMT

Khắc phục sự cố nguồn thông tin định tuyến (Troubleshooting Routing Information Sources)

Khi thiết kế một mạng định tuyến, kỹ sư mạng có rất nhiều lựa chọn để quyết định nguồn cung cấp thông tin định tuyến cho router. Tuyến đường có thể đến từ interface kết nối trực tiếp (connected route), tuyến tĩnh (static route), hoặc từ các giao thức định tuyến động như EIGRP, OSPF, RIP hay BGP.

Chính vì tồn tại nhiều nguồn thông tin như vậy, một câu hỏi rất quan trọng xuất hiện:

Nếu cùng một mạng đích được học từ nhiều nguồn khác nhau, router sẽ tin nguồn nào?

Đây là một khái niệm cực kỳ quan trọng, không chỉ trong thiết kế mạng mà đặc biệt trong troubleshooting. Bởi vì với mỗi destination network, router chỉ chọn một nguồn tốt nhất để cài vào bảng định tuyến (routing table).

Phần này sẽ giải thích cách router đánh giá mức độ tin cậy của từng nguồn thông tin định tuyến, cách bảng định tuyến tương tác với các cấu trúc dữ liệu của giao thức định tuyến, và cách xử lý khi xuất hiện các tuyến không mong muốn.

Routing Table và Data Structure của Routing Protocol hoạt động ra sao?

Để troubleshooting tốt, trước tiên cần hiểu cách router xử lý thông tin định tuyến bên trong.

Khi một router nhận được route từ router láng giềng, thông tin này chưa đi thẳng vào routing table ngay lập tức.

Thay vào đó, route sẽ được lưu vào data structure riêng của giao thức định tuyến.

Ví dụ:

OSPF lưu trong LSDB
EIGRP lưu trong topology table
BGP lưu trong BGP table

Tại đây, giao thức định tuyến sẽ thực hiện phân tích và chọn ra best path dựa trên metric riêng của nó.

Ví dụ:

OSPF dùng cost
EIGRP dùng composite metric
RIP dùng hop count
BGP dùng path attributes

Ngoài route học từ neighbor, data structure của routing protocol còn có thể nhận thông tin từ chính local router.

Ví dụ:

Route Redistribution

Router có thể lấy route từ routing table rồi redistribute vào một giao thức định tuyến khác.

Ví dụ:

Static route redistribute vào OSPF
OSPF redistribute vào EIGRP
Connected route redistribute vào BGP

Ngoài ra, nếu interface được kích hoạt tham gia routing protocol, network của interface đó cũng sẽ được đưa vào data structure của giao thức.

Những nguồn nào có thể cung cấp route cho Routing Table?

Một router hoàn toàn có thể đồng thời nhận route từ nhiều nguồn:

Connected interface
Static route
RIP
EIGRP
OSPF
BGP

Nếu mỗi nguồn cung cấp route đến các mạng khác nhau thì không có vấn đề gì.

Ví dụ:

Connected route đến 192.168.1.0/24
Static route đến 172.16.1.0/24
OSPF route đến 10.10.10.0/24

Tất cả đều cùng tồn tại bình thường.

Nhưng nếu nhiều nguồn cùng quảng bá chính cùng một destination network thì sao?

Ví dụ:

RIP nói:
10.1.1.0/24 reachable

OSPF cũng nói:
10.1.1.0/24 reachable

Router không thể cài cả hai cùng lúc như primary route.

Nó phải chọn một.

Câu hỏi là:

Nguồn nào đáng tin hơn?

Administrative Distance (AD) – Mức độ tin cậy của nguồn route

Cisco dùng khái niệm Administrative Distance (AD) để đo mức độ tin cậy của nguồn thông tin định tuyến.

Có thể hiểu đơn giản:

AD = độ tin cậy của route source

Nguyên tắc:

AD càng thấp → càng đáng tin → càng được ưu tiên

Ví dụ:

RIP có AD = 120
OSPF có AD = 110

Nếu cả hai cùng học route:
10.1.1.0/24

Router sẽ chọn:

OSPF

vì:
110 < 120

Nói cách khác:

OSPF đáng tin hơn RIP.

Điểm rất quan trọng cần nhớ:

Best path bên trong routing protocol chưa chắc được cài vào routing table.

Ví dụ:

EIGRP có thể chọn best path nội bộ.

Nhưng nếu routing table đang có static route cùng destination với AD thấp hơn, EIGRP route sẽ bị loại.

Default Administrative Distance của các nguồn route

Cisco mặc định các giá trị AD như sau: Connected Route

0

Tin tuyệt đối.

Nếu interface trực tiếp kết nối mạng đó, router tin ngay.

Static Route

1

Rất đáng tin.

Chỉ đứng sau connected route.

EIGRP Summary Route

5

Route summary do EIGRP tạo ra có độ tin cậy rất cao.

eBGP

20

External BGP route đáng tin hơn nhiều IGP.

EIGRP Internal

90

Route nội bộ của EIGRP.

OSPF

110

Mức phổ biến trong enterprise.

IS-IS

115

RIP

120

Khá thấp.

EGP

140

Legacy.

ODR

160

On-Demand Routing.

EIGRP External

170

Route redistribute vào EIGRP.

iBGP

200

Rất thấp về độ tin cậy.

Unknown

255

Không tin.

Route sẽ không được cài.

Kiểm tra Administrative Distance

Dùng lệnh:
show ip route

Ví dụ:
R1# show ip route 10.1.1.0

Output:
Routing entry for 10.1.1.0/26
Known via "connected", distance 0, metric 0

Phân tích:
Known via "connected"

Nguồn route:

Connected
distance 0

AD = 0

Ví dụ thứ hai:
R1# show ip route 10.1.23.0

Output:
Routing entry for 10.1.23.0/24
Known via "eigrp 100", distance 90, metric 3072

Phân tích:

Nguồn route:
EIGRP

Administrative Distance:
90

Metric:
3072

Khi nào route "biến mất" dù giao thức vẫn học được?

Đây là lỗi troubleshooting cực phổ biến.

Ví dụ:

OSPF đã học:
10.10.10.0/24

Nhưng:
show ip route

không thấy route đó.

Nhiều người nghĩ OSPF lỗi.

Không hẳn.

Có thể routing table đang ưu tiên nguồn khác:

Static route
Connected route
EIGRP
eBGP

vì AD thấp hơn.

Điều này gây:

missing routes
unexpected path selection
suboptimal routing

Administrative Distance = 255

Nếu đặt:
AD = 255

Cisco hiểu:

Do not believe this route

Route sẽ không bao giờ được cài.

Dùng khi muốn chặn route từ một nguồn nào đó.

Floating Static Route – Backup Route kinh điển

Ví dụ:

Bạn có:

Primary path:
EIGRP
AD = 90

Backup path:
Static Route
AD = 1

Nếu giữ nguyên:

Router luôn chọn static route.

Nhưng static route lại đi qua đường WAN chậm hơn.

Kết quả:

suboptimal routing

Giải pháp:

Biến static route thành floating static route.

Ví dụ:
ip route 10.10.10.0 255.255.255.0 192.168.1.1 95

AD = 95

So với:

EIGRP:
90

Kết quả:

Bình thường → EIGRP được chọn
Khi EIGRP fail → static route nổi lên

Đây là kỹ thuật backup path cực phổ biến trong production.

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

Khi route không đúng như kỳ vọng, luôn hỏi:

Router đang tin ai?

Checklist:
show ip route

Xem:

Known via
distance
metric

Nếu route bị missing:

Kiểm tra:

Có static route đè không?
Có connected route không?
Có redistribution không?
Có eBGP route xuất hiện không?
AD có bị chỉnh tay không?

Kết luận

Routing protocol không quyết định tất cả.

OSPF có thể nghĩ nó tìm được best path.

EIGRP cũng nghĩ như vậy.

BGP cũng vậy.

Nhưng quyết định cuối cùng thuộc về:

Routing Table + Administrative Distance

Trong troubleshooting thực tế, hiểu AD giúp bạn giải thích rất nhanh các hiện tượng như:

route mất bí ẩn
traffic đi sai đường
backup link không hoạt động
redistribution gây route bất ngờ
static route vô tình phá failover

Đây là một trong những kiến thức nền tảng mà mọi network engineer phải cực kỳ vững.