Vietnamese Professional - CCIE®

Cisco AI Tech

dangquangminh — Sat, 06 Jun 2026 00:33:48 GMT

Cisco AI Technical Practitioner (AITECH) là gì?

Cisco AI Technical Practitioner (AITECH) là lộ trình đào tạo dành cho các chuyên gia kỹ thuật muốn tận dụng sức mạnh của Trí tuệ Nhân tạo (AI) để nâng cao hiệu quả công việc, tự động hóa quy trình và tạo ra giá trị đổi mới trong tổ chức.

Khóa học không tập trung vào việc đào tạo chuyên gia nghiên cứu AI hay Data Scientist, mà hướng đến các kỹ sư mạng, kỹ sư hệ thống, chuyên gia vận hành CNTT, AIOps, Solutions Architect, Technical Lead, Manager và Business Analyst muốn ứng dụng AI vào công việc thực tế.

Mục tiêu của chương trình

Chương trình giúp học viên chuyển đổi từ cách làm việc truyền thống dựa trên kiến thức chuyên môn sang mô hình làm việc được tăng cường bởi AI (AI-Augmented Workforce), nơi AI đóng vai trò như một trợ lý kỹ thuật thông minh hỗ trợ phân tích, lập trình, thiết kế giải pháp và tự động hóa.

Những kỹ năng học viên sẽ đạt được

1. Sử dụng AI để lập trình và phát triển phần mềm

Học viên sẽ biết cách sử dụng các công cụ AI như GitHub Copilot và các nền tảng AI Coding Assistant để:

Sinh mã nguồn tự động
Tái cấu trúc (refactor) mã nguồn
Tăng tốc phát triển ứng dụng
Xây dựng nguyên mẫu (prototype) nhanh hơn
Áp dụng quy trình phát triển phần mềm có AI hỗ trợ

Đây là kỹ năng đặc biệt hữu ích cho DevOps Engineer, Network Automation Engineer và Software Developer.

2. Ứng dụng Generative AI trong phân tích dữ liệu

Học viên sẽ học cách sử dụng AI để:

Khám phá dữ liệu (Exploratory Data Analysis)
Làm sạch dữ liệu (Data Cleaning)
Chuyển đổi dữ liệu (Data Transformation)
Tự động tạo báo cáo
Trích xuất thông tin có giá trị từ dữ liệu

Nội dung này phù hợp với Data Analyst, AIOps Engineer và các nhóm vận hành CNTT.

3. Xây dựng quy trình làm việc tự động với AI

Chương trình giới thiệu cách thiết kế:

Multi-step AI Workflow
AI Agents
Agentic AI Systems
Tự động hóa quy trình nghiệp vụ

Đây là nền tảng quan trọng của các hệ thống AI Agent hiện đại đang được triển khai trong doanh nghiệp.

4. Thiết kế giải pháp AI cho doanh nghiệp

Học viên sẽ được làm quen với:

Thu thập và phân tích yêu cầu AI
Đánh giá kiến trúc AI phù hợp
So sánh Fine-Tuning và RAG
Lựa chọn mô hình triển khai
Thiết kế quy trình AI có khả năng mở rộng

Đây là phần rất quan trọng đối với Solutions Architect và Technical Lead.

5. Tùy chỉnh và triển khai mô hình AI

Nội dung bao gồm:

Khai thác các mô hình AI mã nguồn mở và thương mại
Fine-Tuning mô hình
Triển khai hệ thống Retrieval-Augmented Generation (RAG)
Đánh giá hiệu năng mô hình
Vận hành AI trong môi trường thực tế

Đây là kỹ năng đang được các doanh nghiệp triển khai GenAI rất quan tâm.

6. Vận hành và tối ưu hóa hệ thống AI

Học viên sẽ học cách:

Giám sát hoạt động của AI
Kiểm soát chất lượng dữ liệu
Đảm bảo an toàn và bảo mật
Theo dõi hiệu năng mô hình
Tối ưu chi phí vận hành AI

Nội dung này rất gần với các vai trò AIOps và MLOps hiện nay. Góc nhìn dành cho cộng đồng VnPro

Nếu nhìn từ góc độ kỹ sư hạ tầng, chương trình AITECH nằm ở vị trí trung gian giữa:

Người sử dụng AI (AI User) → AI Technical Practitioner → AI Engineer / AI Developer

Nó phù hợp với những người đang làm:

CCNA / CCNP / CCIE
System Engineer
Cloud Engineer
Security Engineer
DevOps Engineer
Automation Engineer
Technical Manager

muốn hiểu cách ứng dụng AI vào công việc kỹ thuật mà chưa cần đi sâu vào toán học, Machine Learning hay Data Science.

Có thể xem AITECH là một trong những chương trình đầu tiên của Cisco giúp các kỹ sư hạ tầng chuyển từ "Networking for AI" sang "Working with AI", bao gồm các chủ đề rất thực tế như AI Coding Assistant, RAG, AI Agent, Workflow Automation và AI Operations. Đây cũng là những kỹ năng đang được nhiều doanh nghiệp tìm kiếm khi triển khai GenAI trong giai đoạn 2025–2027.

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.

So sánh MultiPath và Load Balancing

dangquangminh — Wed, 03 Jun 2026 13:13:30 GMT

Vì sao ECMP chưa đủ cho Storage Network?

Trong các mạng AI, HPC hoặc Storage hiện đại, chúng ta thường triển khai nhiều đường kết nối song song giữa máy chủ và hệ thống lưu trữ nhằm tăng băng thông và khả năng dự phòng.
Nhiều người cho rằng ECMP sẽ tự động phân phối lưu lượng đều trên tất cả các đường truyền. Tuy nhiên thực tế không hoàn toàn như vậy. Mời các bạn đọc tiếp để hiểu rõ hơn sự khác nhau giữa hai cơ chế này.
ECMP hoạt động dựa trên cơ chế băm (hashing) các thông tin của một flow như Source IP, Destination IP, Protocol, Source Port và Destination Port. Sau khi tính toán, toàn bộ dòng lưu lượng (flow) sẽ được gán vào một đường đi cụ thể. Điều này có nghĩa là:

Một phiên NVMe/TCP có thể sử dụng duy nhất một liên kết 100G.

Một luồng RoCEv2 có thể chỉ chạy trên một đường truyền duy nhất.

Một số liên kết có thể hoạt động gần như tối đa công suất trong khi các liên kết khác lại nhàn rỗi.

Đây là hiện tượng hot spot hoặc uneven utilization (sử dụng tài nguyên không đồng đều). Trong khi đó, Fibre Channel từ lâu đã hỗ trợ cân bằng tải theo từng tác vụ I/O, giúp các hoạt động đọc ghi được phân bố đồng đều hơn trên nhiều đường kết nối.
Để đạt được hiệu quả tương tự trong môi trường IP Storage, các nhà sản xuất khuyến nghị triển khai MPIO (Multipath I/O) trên máy chủ. MPIO cho phép hệ điều hành nhìn thấy nhiều đường truy cập đến cùng một thiết bị lưu trữ và chủ động phân phối các lệnh I/O qua nhiều đường khác nhau. Kết quả của kỹ thuật này là:

Tận dụng tốt hơn tổng băng thông của nhiều liên kết.

Giảm hiện tượng nghẽn cục bộ.

Tăng khả năng chịu lỗi khi một đường truyền gặp sự cố.

Cải thiện hiệu năng tổng thể cho các ứng dụng AI, cơ sở dữ liệu và lưu trữ hiệu năng cao.

Góc nhìn thực tế cho HẠ TẦNG AI Infrastructure

Trong các cụm GPU AI hiện đại sử dụng NVMe/TCP hoặc RoCEv2 trên Ethernet 100G/200G/400G, việc chỉ dựa vào ECMP thường không đủ để khai thác hết năng lực mạng. Do đó, các kiến trúc AI-ready Data Center thường kết hợp:

ECMP trong mạng Spine-Leaf để mở rộng quy mô (scale-out)

MPIO trên máy chủ để phân phối I/O hiệu quả

RDMA/RoCEv2 để giảm độ trễ

Nhiều NIC và nhiều đường truyền vật lý để tăng thông lượng

Tóm lại, ECMP giúp cân bằng các dòng lưu lượng flow mạng, còn MPIO cân bằng các hoạt động lưu trữ. Muốn khai thác tối đa hạ tầng Storage Network cho AI, cần kết hợp cả hai cơ chế này thay vì chỉ dựa vào ECMP.

4 lệnh Cisco giúp bạn troubleshooting DHCP

dangquangminh — Sun, 31 May 2026 02:37:43 GMT

4 Lệnh Cisco Mà Bạn Cần Biết Khi Troubleshooting DHCP

DHCP thường hoạt động rất "êm", nhưng khi người dùng không nhận được IP hoặc xuất hiện lỗi địa chỉ trùng lặp, các lệnh kiểm tra trên Cisco Router sẽ giúp bạn nhanh chóng xác định nguyên nhân.

1. Kiểm tra xung đột địa chỉ IP (Duplicate IP)
show ip dhcp conflict

Lệnh này hiển thị các địa chỉ IP bị phát hiện trùng lặp trên mạng. Cisco DHCP Server thường sử dụng cơ chế ping để kiểm tra trước khi cấp phát địa chỉ. Nếu phát hiện IP đã được sử dụng, địa chỉ đó sẽ bị đưa vào danh sách conflict và không được cấp phát cho client khác.

2. Kiểm tra các địa chỉ đã cấp phát
show ip dhcp binding

Lệnh này cho biết DHCP Server đã cấp IP nào, cho thiết bị nào (MAC Address/Client-ID), thời gian lease còn lại bao lâu. Đây là lệnh được sử dụng nhiều nhất khi xác minh DHCP có hoạt động hay không.

3. Theo dõi sự kiện DHCP Server
debug ip dhcp server events

Hiển thị các sự kiện liên quan đến DHCP như tạo pool, cập nhật database, kiểm tra subnet hoặc lỗi cấu hình. Trong ví dụ, thông báo:
DHCPD: no subnet configured for 192.168.1.238

cho thấy DHCP Server không tìm thấy pool phù hợp cho mạng của client.

4. Theo dõi gói tin DHCP theo thời gian thực
debug ip dhcp server packet

Đây là lệnh cực kỳ hữu ích trong thực chiến vì cho phép quan sát trực tiếp quá trình DORA:

DHCPDISCOVER
DHCPOFFER
DHCPREQUEST
DHCPACK

Ngoài ra, bạn còn có thể thấy các bản tin DHCPRELEASE khi máy khách trả lại địa chỉ IP cho DHCP Server.

Trong thực tế, nếu người dùng báo "không lấy được IP", kỹ sư mạng thường bắt đầu bằng show ip dhcp binding, sau đó kiểm tra show ip dhcp conflict, và cuối cùng sử dụng debug ip dhcp server packet để quan sát toàn bộ quá trình DORA diễn ra như thế nào. Chỉ với 4 lệnh này, bạn có thể xử lý phần lớn các sự cố DHCP trong môi trường Cisco Enterprise.

Ba cách triển khai RDMA

dangquangminh — Fri, 29 May 2026 11:29:16 GMT

Hình này mô tả ba cách triển khai RDMA (Remote Direct Memory Access) trên hạ tầng mạng hiện đại: RoCE, RoCEv2 và iWARP, đồng thời cho thấy cách chúng ánh xạ giữa thế giới Ethernet và InfiniBand.

Điểm quan trọng nhất là ứng dụng AI, HPC hay Storage không làm việc trực tiếp với TCP/IP hay Ethernet. Chúng sử dụng tập lệnh RDMA Verbs của InfiniBand để truy cập bộ nhớ từ xa với độ trễ cực thấp và gần như không cần CPU tham gia.

iWARP hoạt động trên nền TCP. Nó tận dụng cơ chế đáng tin cậy của TCP như truyền đúng thứ tự, kiểm soát luồng (flow control) và kiểm soát nghẽn (congestion control). Ưu điểm là dễ triển khai trên mạng IP hiện hữu, nhưng chi phí xử lý giao thức thường cao hơn.

RoCE (RDMA over Converged Ethernet) là RDMA chạy trực tiếp trên Ethernet Layer 2. Phiên bản đầu tiên không hỗ trợ định tuyến IP nên chỉ hoạt động trong cùng miền Layer 2. Vì vậy RoCE thường yêu cầu mạng lossless sử dụng các cơ chế như PFC (Priority Flow Control).

RoCEv2 là phiên bản được sử dụng phổ biến hiện nay. Thay vì chỉ chạy trên Ethernet Layer 2, nó đóng gói RDMA vào UDP/IP nên có thể định tuyến qua mạng Layer 3. Nhờ đó RoCEv2 phù hợp với các AI Data Center quy mô lớn sử dụng kiến trúc Spine-Leaf. RoCEv2 thường kết hợp với:

ECN (Explicit Congestion Notification) để tránh nghẽn.
DSCP để phân loại QoS.
UDP để hỗ trợ cân bằng tải trên mạng.

Ở phía phải của hình là InfiniBand, vốn được thiết kế ngay từ đầu cho HPC và AI với cơ chế credit-based flow control giúp tránh mất gói. Trong khi đó Ethernet phải bổ sung các công nghệ như PFC và ECN để đạt được hành vi gần tương tự.

Nếu nhìn từ góc độ hạ tầng AI hiện nay:

InfiniBand vẫn thống trị các siêu máy tính và cụm GPU cực lớn.
RoCEv2 đang trở thành lựa chọn phổ biến trong các AI Data Center dựa trên Ethernet.
iWARP ít phổ biến hơn trong các triển khai AI quy mô lớn.

Một cách đơn giản, có thể xem:

InfiniBand = RDMA nguyên bản

RoCEv2 = RDMA chạy trên Ethernet/IP

iWARP = RDMA chạy trên TCP/IP

Đây cũng là lý do tại sao khi xây dựng mạng cho AI/ML, các kỹ sư mạng ngày nay phải hiểu thêm về PFC, ECN, QoS, Spine-Leaf và RDMA, thay vì chỉ tập trung vào các giao thức Ethernet truyền thống.

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)

Ba kiểu mạng trong Data Center

dangquangminh — Tue, 26 May 2026 13:56:05 GMT

Ba “hệ sinh thái mạng” chính trong Data Center hiện đại cho AI.

Nếu nhìn theo góc độ framing (đóng gói dữ liệu) và encoding (mã hóa tín hiệu). Đây là cách rất hay để hiểu vì sao trong data center không chỉ có Ethernet.

1. Ethernet – “ông vua phổ thông” của hạ tầng Data Center

Ethernet là công nghệ quen thuộc nhất với dân network vì nó bám theo mô hình OSI cổ điển. Từ Layer 1 (Physical) cho tới Layer 7 (Application), mọi thứ đều rất chuẩn hóa và phổ biến. Trong Data Center, Ethernet chủ yếu phục vụ cho traffic giữa server server, giữa VM VM, giữa Container container, hoặc từ User application. Các loại lưu lượng này còn được gọi là lưu lượng East-West traffic. Điểm đáng chú ý là Ethernet có thêm các cơ chế như:
PFC (Priority Flow Control). Đây là mở rộng của chuân Ethernet để giảm mất gói packet loss trong môi trường yêu cầu low latency hoặc storage traffic như AI.
Pause Frames trong Ethernet
Tính năng này cho phép “tạm dừng” traffic khi buffer đầy, thay vì drop packet. Vấn đề truyền thống của Ethernet là nó vốn thiết kế theo kiểu best-effort. Nghĩa là mạng của chúng ta sẽ cố gắng chuyển gói tin packet tốt nhất có thể, nhưng mất gói là chuyện bình thường (Best effort mà - Cố gắng hết sức). Chính vì vậy mới xuất hiện các cải tiến như Data Center Bridging (DCB), RoCE hay Lossless Ethernet...

2. Fibre Channel – thế giới storage truyền thống

Nếu Ethernet là mạng IP phổ thông, thì Fibre Channel là “mạng storage chuyên dụng”. Nó có stack riêng:

FC-0 → Physical

FC-1 → Encode / Decode

FC-2 → Framing + Signaling

FC-3 → Services

FC-4 → Mapping upper protocol

Ví dụ mà chúng ta đã biết qua như:

SCSI over Fibre Channel

NVMe over Fibre Channel

Điểm khác biệt lớn Fibre Channel không chơi kiểu best-effort như Ethernet truyền thống. Thay vào đó nó dùng Credit-based flow control. TRong cơ chế này, thiết bị chỉ gửi frame khi biết đầu bên kia còn bộ đệm buffer (cách này giống như RTS/ CTS trong modem cổ xưa...). Nghĩa là "Tôi chỉ gửi nếu anh xác nhận còn chỗ chứa."
Lúc này, gần như không packet loss, độ trễ latency ổn định, rất phù hợp cho các lưu lượng của storage traffic. Ngoài ra, các khái niệm như Buffer-to-buffer credits, R_RDY (Receiver Ready) chính là nền tảng của Fibre Channel SAN. Nhiều enterprise vẫn dùng FC SAN cho các ứng dụng mission-critical database, mainframe, storage array loại lớn....
3. InfiniBand – thế giới HPC và AI
Nếu Fibre Channel dành cho storage enterprise, thì InfiniBand là một loại quái vật dành cho các công nghệ như HPC, supercomputer, AI cluster, GPU fabric. Stack của nó không đi theo OSI chuẩn. Hình cho thấy các thành phần bao gồm:

Physical

Link

Network

Transport

Upper Layers

Và nổi bật nhất là RDMA Verbs. Đây là chìa khóa. Công nghệ RDMA (Remote Direct Memory Access - đã nhiều lần trình bày trong group này) cho phép máy A đọc/ghi trực tiếp vào memory của máy B mà gần như bỏ qua CPU. Lợi ích của RDMA là độ trễ latency cực thấp, throughput cực cao, CPU overhead thấp. Rất phù hợp cho lưu lượng AI. Đây là lý do NVIDIA DGX, AI factory, training cluster dùng InfiniBand rất nhiều.
4. So sánh bản chất của 3 công nghệ
Ethernet: best effort, linh hoạt, phổ thông, scale lớn.
Fibre Channel: lossless, deterministic, storage-first.
InfiniBand: ultra-low latency, HPC-first, AI-first.
5. Xu hướng hiện đại: Ethernet đang “xâm lấn” lãnh địa của hai bên còn lại
Ngày xưa thì Ethernet dùng cho general networking, Fibre Channel dùng cho storage, còn InfiniBand → HPC. Ngày nay ranh giới mờ dần. Ví dụ: RoCEv2 RDMA chạy trên Ethernet. Điều này dẫn đến Ethernet bắt đầu cạnh tranh với InfiniBand.
NVMe/TCP là storage tốc độ cao chạy trên Ethernet. => Ethernet cạnh tranh với Fibre Channel.
Điều này lý giải vì sao trong AI Data Center hiện đại, nhiều nơi chọn:

400G Ethernet

800G Ethernet

RoCE fabric

VXLAN EVPN fabric

thay vì InfiniBand thuần túy.

Góc nhìn thực tế

Nếu bạn là network engineer truyền thống, Data Center hiện đại không còn chỉ là VLAN + STP + OSPF nữa. Bạn sẽ phải tìm hiểu thêm các khái niệm như Ethernet lossless, DCB, PFC, ECN, RDMA, RoCE, NVMe-oF, AI fabric...AI đang kéo networking sang một thế giới mới: network as a compute fabric.

Hạ tầng cho AI

dangquangminh — Mon, 25 May 2026 11:22:31 GMT

AI không chỉ là mô hình, mà là cả một bài toán hạ tầng

Nhiều người khi nói về AI thường chỉ nghĩ đến mô hình: LLM nào tốt hơn, tham số bao nhiêu tỷ, dùng pre-training hay fine-tuning, có tích hợp RAG hay không. Nhưng nếu nhìn từ góc độ hạ tầng, mô hình AI thực ra chỉ là phần nổi của tảng băng.

Phía sau một hệ thống AI chạy được trong môi trường thật là cả một stack công nghệ khá đồ sộ.

Ở lớp trên cùng là vòng đời của mô hình AI: huấn luyện ban đầu (pre-training), tinh chỉnh (fine-tuning), bổ sung tri thức ngoài qua RAG, rồi cuối cùng là giai đoạn suy luận (inference) — tức lúc người dùng thực sự gửi prompt và chờ phản hồi. Mỗi giai đoạn này lại có yêu cầu hạ tầng rất khác nhau. Huấn luyện thì ngốn GPU, inference thì cần tối ưu độ trễ, còn RAG lại phụ thuộc mạnh vào hệ thống lưu trữ và truy xuất dữ liệu.

Ngay bên dưới là lớp framework và công cụ quản lý AI. Đây là thế giới của PyTorch, TensorFlow, Hugging Face, orchestration pipeline, model serving và monitoring. Xa hơn nữa là lớp ảo hóa và Kubernetes — thứ đang dần trở thành “VMware của thời AI”.

Nhưng điều thú vị nhất nằm ở phần data center.

Dù là AI triển khai trong doanh nghiệp (on-prem AI) hay các cụm AI quy mô hyperscale, những thành phần cốt lõi gần như không thay đổi: compute, storage, kiến trúc mạng, bảo mật và khả năng quan sát hệ thống.

Compute thì ai cũng nghĩ đến GPU. Nhưng network mới là thứ dễ bị đánh giá thấp.

AI training không giống workload enterprise truyền thống. GPU không thể ngồi chờ dữ liệu. Nếu mạng chậm, latency cao, congestion xảy ra hoặc east-west traffic nghẽn, cụm GPU trị giá hàng triệu đô có thể bị idle chỉ vì network bottleneck.

Đó là lý do vì sao trong AI data center, mạng không còn là “phần kết nối” nữa, mà trở thành một thành phần trực tiếp quyết định hiệu suất AI.

Nhìn hàng dưới của sơ đồ sẽ thấy rõ hơn: access, WAN, inter-data center, edge compute, inter-cluster. Điều này cho thấy AI không phải chỉ nằm trong một rack server. Nó là một hệ sinh thái phân tán, nơi dữ liệu, mô hình và compute liên tục di chuyển giữa nhiều domain.

AI engineer có thể nói về model, nhưng để AI chạy thật ngoài production, hạ tầng mới là nơi quyết định thành bại.

Troubleshooting Switch Port

dangquangminh — Wed, 20 May 2026 00:32:35 GMT

Troubleshooting VLAN: Khi Switchport bị gán sai VLAN (Incorrect Port Assignment)

Trong môi trường mạng chuyển mạch, một lỗi cấu hình tưởng chừng đơn giản nhưng gây ra rất nhiều sự cố kết nối là gán sai switchport vào VLAN không phù hợp.

Đây là lỗi cực kỳ phổ biến trong thực tế vận hành mạng doanh nghiệp, đặc biệt khi triển khai nhiều VLAN để phân đoạn mạng (network segmentation). VLAN và Switchport Assignment hoạt động như thế nào?

Sau khi VLAN được tạo trên switch, bước tiếp theo là gán từng switchport vào đúng VLAN tương ứng.

Việc gán này phải dựa trên thiết kế Layer 3:

Thiết bị nào thuộc subnet nào
Default gateway của subnet đó là gì
Vai trò của thiết bị trong hệ thống

Ví dụ:

Giả sử thiết kế mạng như sau:

VLAN 100 → mạng 10.1.100.0/24

PC1
PC2
PC4
Server

VLAN 200 → mạng 10.1.200.0/24

Điều này có nghĩa:

Các thiết bị trong VLAN 100 phải cùng subnet
Các thiết bị trong VLAN 200 phải cùng subnet khác
Switch sẽ chỉ forward frame Layer 2 trong cùng broadcast domain (cùng VLAN)

Nếu một máy thuộc mạng 10.1.100.0/24 nhưng cắm vào port thuộc VLAN 200:

ARP sẽ không đến đúng nơi
Broadcast bị giới hạn sai VLAN
Máy sẽ “nhìn như bị mất mạng”
Ping gateway thất bại
Người dùng báo “network down”

Case thực tế

Một user báo:

"Server không ping được từ PC2 dù IP đúng."

Thông tin:

PC2
IP: 10.1.100.22
Mask: 255.255.255.0
GW: 10.1.100.1

Server
IP: 10.1.100.50
Mask: 255.255.255.0
GW: 10.1.100.1

Thoạt nhìn:

cùng subnet
cùng gateway
IP đúng

Nhưng ping vẫn fail.

Kiểm tra VLAN:
SW1# show vlan brief

Output:
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------
1 default active Gi0/5, Gi0/6...
99 NATIVE active
100 10.1.100.0/24 active Gi0/1, Gi0/3
200 10.1.200.0/24 active Gi0/4

Sơ đồ kết nối:

PC2 → Gi0/3
Server → Gi0/4

Phát hiện:

PC2 nằm VLAN 100

Nhưng Server lại cắm vào:
Gi0/4 → VLAN 200

Kết quả:

Mặc dù IP cùng subnet, nhưng về Layer 2 chúng nằm ở hai broadcast domain khác nhau.

Switch không forward frame giữa VLAN nếu không có inter-VLAN routing.

Vì sao lỗi này gây mất kết nối?

Switch hoạt động Layer 2 dựa trên VLAN membership.

Switch không quan tâm:

IP address
subnet mask
gateway

Switch chỉ nhìn:

source MAC
destination MAC
VLAN ID

Nếu frame từ VLAN 100:
802.1Q VLAN = 100

Switch sẽ không gửi frame sang VLAN 200.

=> Broadcast ARP không tới Server.

Ví dụ:

PC2 gửi:
ARP Request:
Who has 10.1.100.50?

Frame được flood trong VLAN 100.

Nhưng Server ở VLAN 200.

Server không bao giờ nhận được ARP request.

Kết quả:
ARP unresolved
Ping fail
Application timeout

Cách kiểm tra nhanh

1. show vlan brief

Lệnh quan trọng nhất:
show vlan brief

Ví dụ:
SW1# show vlan brief

Output:
100 Users active Gi0/1, Gi0/3
200 Servers active Gi0/4

Cho biết:

VLAN nào tồn tại
Port nào thuộc VLAN nào

2. show interfaces switchport

Chi tiết hơn:
show interfaces gi0/4 switchport

Ví dụ:
Administrative Mode: static access
Operational Mode: static access
Access Mode VLAN: 200

Nếu thiết bị expected ở VLAN 100 nhưng thấy VLAN 200 → lỗi.

3. Kiểm tra IP endpoint

Windows:
ipconfig

Linux:
ip addr

Cisco IP phone:
show network

Đảm bảo endpoint nằm đúng subnet theo VLAN design.

Một lưu ý rất quan trọng

show vlan brief KHÔNG hiển thị trunk port

Ví dụ:

Gi0/2 là trunk:
switchport mode trunk

Port này sẽ không xuất hiện trong:
show vlan brief

Lý do:

Trunk không thuộc một VLAN duy nhất.

Nó mang traffic của nhiều VLAN.

Ví dụ:
Gi0/2 carries:
VLAN 100
VLAN 200
VLAN 300

Nên không thể liệt kê như access port.

Kiểm tra trunk bằng:
show interfaces trunk

Nếu VLAN không tồn tại thì sao?

Một bẫy khác:

Nếu port được assign vào VLAN chưa tồn tại:
switchport access vlan 500

nhưng VLAN 500 chưa được create:
no vlan 500

Port sẽ không hiện trong:
show vlan brief

Thay vào đó:
show interfaces switchport

sẽ báo:
Access Mode VLAN: 500 (Inactive)

Điều này nghĩa là:

port config đúng cú pháp
nhưng VLAN chưa active

=> traffic không chạy.

Best Practice thực chiến

Trong production:

Luôn chuẩn hóa mapping:
Finance → VLAN 100
HR → VLAN 110
Voice → VLAN 120
Server → VLAN 200
Guest → VLAN 300
Management → VLAN 999

Dùng description:
interface gi0/4
description SERVER-DB01
switchport mode access
switchport access vlan 200

Audit định kỳ:
show vlan brief
show interfaces status
show mac address-table

Kết

Lỗi Incorrect Port Assignment là một trong những nguyên nhân phổ biến nhất khiến:

user mất mạng
server unreachable
DHCP fail
VoIP không đăng ký
printer inaccessible

Bài học quan trọng:

IP đúng chưa chắc VLAN đúng.

Trong troubleshooting Layer 2, luôn kiểm tra:

Switchport → VLAN → Subnet mapping

vì chỉ một port gán sai VLAN cũng đủ làm cả hệ thống “có vẻ đúng nhưng không chạy.”

Cơ chế Packet Switching

dangquangminh — Sat, 16 May 2026 10:36:46 GMT

Packet Switching và Ảnh Hưởng Đến Hiệu Năng Router

Ngoài các vấn đề về CPU utilization cao đã đề cập trước đó, một yếu tố khác có thể ảnh hưởng mạnh đến hiệu năng của router là chế độ packet switching mà thiết bị đang sử dụng. Trong thực tế, không phải mọi router đều xử lý packet theo cùng một cách. Cách router quyết định chuyển tiếp packet phụ thuộc rất nhiều vào kiến trúc phần cứng và phần mềm của thiết bị.

Vì vậy, khi troubleshooting ngoài môi trường production, bạn luôn nên tham khảo tài liệu của dòng router cụ thể để hiểu chính xác cách nó triển khai forwarding plane.

Tuy nhiên, về mặt tổng quát, các router Cisco và multilayer switch thường hỗ trợ ba cơ chế packet switching chính:

Process Switching
Fast Switching (Route Caching)
Cisco Express Forwarding - CEF (Topology-Based Switching)

Đây là những khái niệm rất quan trọng đối với kỹ sư CCNP/CCIE, bởi vì chúng ảnh hưởng trực tiếp đến throughput, latency, CPU load, và khả năng mở rộng của hệ thống.

Packet Switching Là Gì?

Packet switching là quá trình router quyết định:

"Packet này sẽ được gửi đi đâu?"

Khi một packet đi vào router, thiết bị phải thực hiện nhiều bước xử lý:

Bước 1: Loại bỏ Layer 2 header

Ví dụ Ethernet header sẽ bị bỏ đi vì MAC source/destination chỉ có ý nghĩa trong local segment.

Ví dụ packet đến với:
Src MAC: 00:11:22:33:44:55
Dst MAC: AA:BB:CC:DD:EE:FF

Router sẽ bỏ phần này.

Bước 2: Kiểm tra Layer 3 header

Router đọc thông tin IP:
Source IP
Destination IP
TTL
Protocol

Ví dụ:
Source IP: 10.1.1.10
Destination IP: 192.168.1.100

Router sẽ tra cứu routing table để xác định next-hop.

Bước 3: Quyết định forwarding

Ví dụ routing table:
192.168.1.0/24 via 172.16.1.1

Router xác định:

"Packet này phải gửi ra interface GigabitEthernet0/1"

Bước 4: Viết lại Layer 2 header

Router tạo Ethernet frame mới:
New Source MAC = MAC của router trên cổng ra
New Destination MAC = MAC của next-hop

Ví dụ:
Src MAC: 00:AA:BB:CC:DD:EE
Dst MAC: 11:22:33:44:55:66

Bước 5: Tính lại FCS

Do frame đã thay đổi nên checksum Layer 2 cũng phải được tính lại.

Bước 6: Forward packet

Packet được gửi ra cổng phù hợp.

1. Process Switching

Cách hoạt động

Đây là phương pháp packet switching truyền thống nhất.

Với process switching, mỗi packet đi vào đều được CPU xử lý trực tiếp.

Luồng xử lý:
Packet đến
↓
CPU kiểm tra header
↓
CPU tra routing table
↓
CPU rewrite Layer 2 header
↓
CPU tính FCS
↓
CPU gửi packet ra ngoài

Toàn bộ quyết định forwarding đều do CPU đảm nhiệm.

Minh họa logic

Incoming Packet
↓
CPU xử lý
↓
Routing Decision
↓
Rewrite Frame
↓
Outgoing Interface

Điều này tương ứng với mô hình:

Control Plane tham gia trực tiếp
CPU trở thành điểm xử lý trung tâm

Vì sao chậm?

CPU là tài nguyên hữu hạn.

Nếu traffic nhỏ:
100 pps

CPU vẫn xử lý ổn.

Nhưng nếu traffic tăng:
50,000 pps
100,000 pps
500,000 pps

CPU sẽ nhanh chóng quá tải.

Kết quả:

latency tăng
packet drop
routing protocol bị ảnh hưởng
management session lag
SSH/Telnet phản hồi chậm

Ví dụ thực tế

Router nhận traffic:
200 Mbps

Packet size trung bình:
500 bytes

Packets per second:
200,000,000 / (500 × 8)
= 50,000 pps

Nếu CPU phải process-switch 50,000 packet mỗi giây:

=> cực kỳ nặng.

Khi nào xảy ra?

Thông thường router hiện đại không dùng process switching cho forwarding thông thường.

Nhưng vẫn có thể xảy ra khi:

packet đầu tiên của flow
traffic đặc biệt cần CPU xử lý
exception traffic
control-plane traffic
fast switching bị disable
CEF bị disable

Cấu hình ép dùng Process Switching

Có thể disable Fast Switching và CEF bằng lệnh:
interface GigabitEthernet0/0
no ip route-cache

Lệnh này buộc interface dùng process switching.

Kiểm tra

show ip interface

Ví dụ:
IP fast switching is disabled

Tác động đến Troubleshooting

Nếu router CPU cao, cần kiểm tra:
show processes cpu

Nếu CPU bị packet forwarding chiếm nhiều:
IP Input

process IP Input cao thường là dấu hiệu process switching hoặc exception packet processing.

Ví dụ:
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min Process
66 458293 ... IP Input

Nếu IP Input cao bất thường:

→ nghi ngờ packet đang đi vào CPU.

Kiến thức thực chiến

Process switching gần như là “worst-case forwarding path”.

Nếu traffic data-plane phải đi qua CPU:

router sẽ giống như:

"Dùng general-purpose CPU để làm forwarding ASIC"

Điều này cực kỳ kém hiệu quả.

Tóm tắt

Process switching có đặc điểm:

Ưu điểm

đơn giản
luôn hoạt động
xử lý được exception traffic

Nhược điểm

CPU intensive
throughput thấp
latency cao
không scalable

Trong phần tiếp theo, cơ chế Fast Switching và đặc biệt Cisco Express Forwarding (CEF) mới là các kỹ thuật giúp router forwarding hiệu quả ở tốc độ cao.

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ế