Vietnamese Professional - CCNA 200-301

Vì sao SD-WAN vẫn ra đời và được nhiều doanh nghiệp chuyển sang?

dungabx — Sat, 05 Sep 2026 10:25:05 GMT

Nhân viên ở chi nhánh gọi video call nội bộ mà giật lag liên tục, dù đường truyền Internet tại đó đo tốc độ vẫn rất cao. Vấn đề không nằm ở băng thông, mà ở việc gói tin bị bắt vòng về trung tâm dữ liệu để qua tường lửa kiểm duyệt, rồi mới được thả ra Internet - đi thêm một quãng đường không cần thiết chỉ vì kiến trúc mạng cũ buộc phải làm vậy. Đây chính là bài toán mà SD-WAN sinh ra để giải quyết.

WAN truyền thống, chủ yếu dựa trên MPLS, vận hành theo kiểu mỗi router một pháo đài riêng: cấu hình qua CLI, định tuyến theo địa chỉ đích bằng OSPF hay BGP, hoàn toàn không biết gói tin đó thuộc ứng dụng gì. Muốn đổi chính sách cho toàn bộ chi nhánh, kỹ sư phải đăng nhập tay từng thiết bị một. SD-WAN đảo ngược mô hình đó bằng cách tách control plane - nơi ra quyết định - ra khỏi data plane - nơi chuyển tiếp gói tin, y hệt triết lý của SDN. Một bộ điều khiển trung tâm tính toán chính sách, rồi đẩy xuống đồng loạt cho toàn bộ thiết bị biên, và quan trọng nhất là định tuyến dựa trên loại ứng dụng cùng chất lượng đường truyền thời gian thực, chứ không chỉ dựa vào địa chỉ đích như trước.

Hai khái niệm hay bị nhầm với nhau là underlay và overlay. Underlay là toàn bộ hạ tầng vật lý đã có sẵn - đường Internet băng rộng, MPLS, 4G/5G - những con đường thật sự mà gói tin chạy qua. Overlay là mạng logic SD-WAN dựng lên trên nền đó bằng các tunnel mã hóa, tạo cảm giác như một mạng riêng thống nhất bất kể bên dưới là loại đường truyền gì. Giống như một hãng logistics không tự xây đường mới, mà chỉ vẽ ra các tuyến vận chuyển ưu tiên trên nền đường xá sẵn có, quyết định xe nào đi tuyến nào và đổi tuyến lúc nào nếu tắc đường, tùy theo loại hàng hóa đang chở.

Động lực chuyển từ MPLS sang SD-WAN phần lớn đến từ bài toán tiền và tốc độ. MPLS tính phí trên mỗi Mbps rất cao, lắp thêm một kênh mới có thể mất hàng tuần đến hàng tháng vì phụ thuộc nhà mạng, còn băng thông cố định thì doanh nghiệp phải trả tiền cho công suất dự phòng ít khi dùng tới. Càng nhiều chi nhánh, chi phí và độ phức tạp cấu hình càng tăng theo cấp số nhân.

Nhưng lý do sâu xa hơn nằm ở xu hướng dịch chuyển lên cloud. Trong kiến trúc cũ, mọi lưu lượng kể cả truy cập Office 365 hay tài nguyên trên AWS đều bị ép quay về trung tâm dữ liệu trước khi ra ngoài - hiện tượng gọi là hairpinning hay backhaul, chính là nguyên nhân gây lag ở ví dụ mở đầu. SD-WAN giải quyết bằng Direct Internet Access: chi nhánh đi thẳng ra Internet và cloud tại chỗ, không cần vòng qua trung tâm, kết hợp định tuyến theo SLA để luôn chọn đường ngắn và ổn định nhất tới điểm SaaS gần nhất.

Cơ chế định tuyến thông minh của SD-WAN chạy liên tục chứ không phải một lần cấu hình rồi thôi. Thiết bị biên dùng deep packet inspection để nhận diện từng luồng dữ liệu thuộc ứng dụng gì - VoIP, video call, ERP, web thường - đồng thời liên tục gửi gói thăm dò qua từng tunnel để đo độ trễ, jitter và tỷ lệ mất gói theo thời gian thực. Khi một chỉ số vượt ngưỡng SLA đã đặt cho loại ứng dụng đó, ví dụ VoIP vốn nhạy với jitter hơn nhiều so với truyền file, hệ thống tự động chuyển luồng sang tunnel khác đạt chuẩn, thường chỉ trong vài trăm mili-giây đến vài giây, người dùng gần như không cảm nhận được gián đoạn.

Vì lưu lượng giờ đây chạy qua Internet công cộng thay vì đường riêng MPLS, bảo mật buộc phải chuyển hướng khác. Mỗi kết nối overlay giữa hai edge đều được bọc trong tunnel IPsec, một số nền tảng dùng DTLS, tạo thành lưới an toàn tách biệt hoàn toàn với hạ tầng công cộng bên dưới. Nhiều nền tảng SD-WAN hiện đại tích hợp sẵn tường lửa thế hệ mới ngay tại thiết bị biên, và xu hướng đang hội tụ dần về SASE - nơi các dịch vụ bảo mật được phân phối từ cloud gần người dùng nhất, thay vì tập trung một điểm duy nhất như mô hình cũ. Hướng đi xa hơn còn tiến tới nguyên lý Zero Trust: không chỉ mã hóa đường truyền, mà còn xác thực và đánh giá rủi ro liên tục cho từng luồng dữ liệu trước khi được phép định tuyến đi.

Việc đưa một chi nhánh mới vào hệ thống cũng khác hẳn thời phải cử kỹ sư đến tận nơi ngồi gõ CLI. Với Zero-Touch Provisioning, nhân viên tại chỗ chỉ cần cắm nguồn và cắm cáp uplink, thiết bị tự động gọi về orchestrator bằng mã kích hoạt đã đăng ký sẵn, tải cấu hình theo template, tự thiết lập tunnel overlay và gia nhập mạng lưới - toàn bộ quá trình thường chỉ mất vài phút đến vài chục phút.

SD-WAN phù hợp nhất với các tổ chức có nhiều chi nhánh phân tán và phụ thuộc nhiều vào cloud/SaaS - chuỗi bán lẻ, ngân hàng nhiều phòng giao dịch, chuỗi nhà hàng khách sạn. Nhưng đi cùng với đó là một thay đổi tư duy bắt buộc cho kỹ sư mạng: từ việc debug từng router riêng lẻ theo giao thức, sang tư duy intent-based - mô tả mục tiêu như "lưu lượng VoIP luôn ưu tiên đường có độ trễ thấp nhất" và để controller tự dịch thành cấu hình, thay vì tự tay viết từng dòng.

Hệ thống chỗ bạn đang chạy MPLS thuần, hay đã chuyển sang SD-WAN hybrid rồi? Chia sẻ trải nghiệm để mọi người cùng tham khảo nhé.

Một buổi Lab CCNA tại VnPro diễn ra như thế nào?

Cẩm Thanh — Fri, 04 Sep 2026 08:48:36 GMT

Một buổi Lab CCNA tại VnPro diễn ra như thế nào? 👀

📍 Một vài khoảnh khắc từ buổi học thực hành của lớp CCNA 26A10 tại VnPro.

Không phải chỉ mở máy lên và gõ vài dòng lệnh.

Một buổi Lab là lúc học viên đưa những kiến thức đã học vào tình huống thực tế:

🔹 Tiếp cận và kết nối thiết bị

🔹 Trực tiếp cấu hình Router/Switch

🔹 Kiểm tra kết nối và kết quả

🔹 Gặp lỗi → tìm nguyên nhân → troubleshooting

🔹 Trao đổi cùng mentor để hiểu bản chất vấn đề

Điều quan trọng không phải là “gõ đúng câu lệnh”, mà là hiểu:

▫️Tại sao phải cấu hình như vậy?

▫️Điều gì đang xảy ra trong hệ thống?

▫️Nếu có lỗi, mình sẽ kiểm tra từ đâu?

Đó cũng là lý do thực hành Lab luôn là một phần quan trọng trong quá trình học Network.

---VnPro

🌐www.vnpro.vn

☎Hotline/Zalo: 0933427079

📞Anh Thư: 0339943732

📞Như Ngọc: 0765944386

🚀 muốn bắt đầu sự nghiệp network? Hãy bắt đầu từ ccna.

Anh Thư — Fri, 04 Sep 2026 07:16:07 GMT

Từ nền tảng Network → NOC/Network Support → Network Engineer, CCNA là bước nền quan trọng để bạn xây dựng năng lực và tiếp tục phát triển lên các cấp độ chuyên sâu hơn.

🎯 KHÓA HỌC CCNA (200-301) – OFFLINE TẠI VnPro
📚 2 lịch học linh hoạt để lựa chọn:
🌙 Tối 2-4-6: 18H30–21H
☀️ Sáng – chiều T7: 8H30–11H | 13H30–16H

🔹 Học kiến thức nền tảng + thực hành Lab
🔹 Lộ trình từ cơ bản đến nâng cao
🔹 Phù hợp cho sinh viên CNTT, người mới theo Network, IT Support/Helpdesk

👉 Inbox “CCNA” để nhận lộ trình + học phí và tư vấn lịch học phù hợp.

---VnPro
🌐www.vnpro.vn
☎Hotline/Zalo: 0933427079
📞Anh Thư: 0339943732
📞Như Ngọc: 0765944386

vnpro ccna #CCNA200301 #NetworkEngineer network #HocCNTT #ITCareer

🛠️ 5 lỗi cấu hình mạng “nhìn rất đúng” nhưng không ping được

ThanhTho — Fri, 04 Sep 2026 03:12:25 GMT

Trong quá trình học CCNA và thực hành Lab, chắc hẳn nhiều người từng gặp tình huống quen thuộc:

👉 Cấu hình xong.
👉 Kiểm tra IP thấy đúng.
👉 Interface cũng đã cấu hình.
👉 Mô hình kết nối nhìn hoàn toàn bình thường.

Nhưng khi thực hiện lệnh:

ping x.x.x.x

Kết quả vẫn là:

❌ Request timed out
❌ Destination host unreachable

Đây là lúc nhiều người bắt đầu kiểm tra lại toàn bộ cấu hình và tự hỏi: “Mình làm đúng hết rồi, tại sao vẫn không Ping được?”

Thực tế, rất nhiều lỗi mạng không đến từ cấu hình phức tạp. Đôi khi chỉ một chi tiết nhỏ bị bỏ sót cũng đủ khiến toàn bộ kết nối thất bại.

Dưới đây là 5 lỗi cấu hình phổ biến nhìn có vẻ rất đúng nhưng vẫn khiến các thiết bị không thể Ping được nhau.

1️⃣ IP ADDRESS ĐÚNG, NHƯNG SAI SUBNET MASK

Đây là lỗi rất phổ biến với người mới học Networking.

Ví dụ:

PC1: 192.168.10.10/24
PC2: 192.168.10.20/16

Nhìn qua, cả hai đều có địa chỉ bắt đầu bằng 192.168.x.x, nên nhiều người sẽ nghĩ chúng thuộc cùng một mạng.

Nhưng thực tế:

PC1 hiểu mạng của mình là 192.168.10.0/24
PC2 lại hiểu mạng là 192.168.0.0/16

Mỗi thiết bị đang có cách xác định Network khác nhau. Điều này có thể khiến quá trình xử lý lưu lượng không đúng như mong muốn.

🔥 Bài học quan trọng: Đừng chỉ kiểm tra IP Address. Hãy luôn kiểm tra cả Subnet Mask hoặc Prefix Length.

Một IP Address đúng nhưng Subnet Mask sai vẫn có thể khiến thiết bị không thể giao tiếp bình thường.

2️⃣ IP ĐÚNG, NHƯNG SWITCH PORT SAI VLAN

Trong các mô hình sử dụng nhiều VLAN, đây là lỗi xuất hiện rất thường xuyên.

Ví dụ, PC được cấu hình IP thuộc mạng VLAN 10. Bạn cũng đã tạo VLAN 10 trên Switch.

Nhưng Switch Port đang kết nối với PC lại thuộc VLAN 1 hoặc một VLAN khác.

Kết quả:

👉 IP Address nhìn hoàn toàn hợp lý.
👉 VLAN đã được tạo.
❌ Nhưng thiết bị vẫn không nằm trong Broadcast Domain mong muốn.

Để kiểm tra, bạn có thể sử dụng:

show vlan brief

Lệnh này giúp xác định:

VLAN đã tồn tại hay chưa
Port đang thuộc VLAN nào
Access Port có được gán đúng VLAN không

🔥 Hãy nhớ: IP Address đúng không đồng nghĩa thiết bị đang nằm đúng VLAN.

Khi Troubleshooting trong mạng Switching, hãy kiểm tra Layer 2 trước khi kết luận rằng IP hoặc Router đang có vấn đề.

3️⃣ QUÊN HOẶC CẤU HÌNH SAI DEFAULT GATEWAY

Hai thiết bị cùng mạng LAN có thể giao tiếp trực tiếp với nhau mà không cần Router.

Ví dụ:

PC1: 192.168.1.10/24
PC2: 192.168.1.20/24

Nhưng nếu PC1 muốn Ping đến một thiết bị ở mạng khác, ví dụ:

192.168.2.10

thì PC1 cần gửi Packet đến Default Gateway.

Nếu Default Gateway:

Chưa được cấu hình
Sai địa chỉ IP
Không cùng mạng với PC

thì PC sẽ không biết phải gửi Packet đi đâu để đến mạng khác.

Đây là lý do bạn có thể gặp tình huống:

✅ Ping được thiết bị cùng mạng
❌ Không Ping được thiết bị khác mạng

Khi đó, hãy kiểm tra ngay bộ ba:

IP Address → Subnet Mask → Default Gateway

4️⃣ INTERFACE CÓ IP, NHƯNG VẪN ĐANG SHUTDOWN

Đây là lỗi kinh điển trong các bài Lab Cisco.

Bạn vào Interface và cấu hình:

ip address 192.168.1.1 255.255.255.0

Kiểm tra lại thấy địa chỉ IP đã xuất hiện. Mọi thứ có vẻ chính xác.

Nhưng Interface vẫn có thể đang ở trạng thái:

❌ administratively down

Trên nhiều Router Cisco, Interface có thể đang Shutdown và cần được bật bằng lệnh:

no shutdown

Sau đó kiểm tra:

show ip interface brief

Một Interface hoạt động bình thường thường có trạng thái:

Status: up
Protocol: up

🔥 Khi Troubleshooting, đừng chỉ nhìn vào cấu hình. Hãy kiểm tra trạng thái thực tế của Interface.

Một IP Address được cấu hình đúng sẽ không có ý nghĩa nếu Interface chưa thực sự hoạt động.

5️⃣ ACL ĐANG ÂM THẦM CHẶN PING

Đây là lỗi khiến nhiều người mất khá nhiều thời gian để tìm nguyên nhân.

Bạn đã kiểm tra:

✅ IP đúng
✅ VLAN đúng
✅ Default Gateway đúng
✅ Interface hoạt động
✅ Router có Route phù hợp

Nhưng Ping vẫn thất bại.

Lúc này, hãy nghĩ đến ACL – Access Control List.

ACL có thể được sử dụng để kiểm soát lưu lượng đi qua Router hoặc Interface. Nếu ACL chặn ICMP, lệnh Ping sẽ không hoạt động dù đường truyền và Routing hoàn toàn bình thường.

Bạn có thể kiểm tra bằng:

show access-lists

Ngoài ra, cần kiểm tra ACL đang được áp dụng ở đâu và theo chiều nào:

Inbound
Outbound

🔥 Một ACL đặt sai vị trí hoặc sai hướng cũng có thể khiến lưu lượng bị chặn ngoài ý muốn.

🎯 KHI KHÔNG PING ĐƯỢC, HÃY TROUBLESHOOT THEO TỪNG LAYER

Một trong những kỹ năng quan trọng nhất khi học CCNA không phải là nhớ thật nhiều câu lệnh.

Đó là khả năng xác định lỗi theo từng Layer.

Thay vì kiểm tra ngẫu nhiên toàn bộ cấu hình, hãy đi theo trình tự: 🔹 LAYER 1 – PHYSICAL

Kiểm tra:

Dây kết nối
Interface có hoạt động không
Link có trạng thái Up không

🔹 LAYER 2 – DATA LINK

Kiểm tra:

Port thuộc đúng VLAN chưa?
VLAN đã được tạo chưa?
MAC Address Table có học địa chỉ thiết bị không?

🔹 LAYER 3 – NETWORK

Kiểm tra:

IP Address đúng chưa?
Subnet Mask đúng chưa?
Default Gateway đúng chưa?
Routing Table có đường đi không?

🔹 SECURITY

Cuối cùng, kiểm tra:

ACL có chặn lưu lượng không?
Firewall có chặn ICMP không?

Khi kiểm tra theo từng Layer, bạn sẽ nhanh chóng xác định được Packet đang bị dừng ở đâu thay vì phải cấu hình lại toàn bộ mô hình.

🔥 KẾT LUẬN

Một mô hình mạng không Ping được chưa chắc vì bạn cấu hình sai toàn bộ.

Đôi khi nguyên nhân chỉ là:

❌ Sai Subnet Mask
❌ Sai VLAN
❌ Sai Default Gateway
❌ Interface chưa no shutdown
❌ ACL đang chặn ICMP

Đó cũng là lý do học Networking không chỉ là học cách cấu hình.

Cấu hình giúp hệ thống hoạt động. Troubleshooting giúp bạn hiểu vì sao hệ thống không hoạt động.

Và lần tiếp theo khi nhìn thấy dòng:

Request timed out...

Đừng vội cấu hình lại từ đầu.

Hãy bình tĩnh và tự hỏi:

👉 Packet đã đi được đến đâu?

💬 Trong quá trình học CCNA, bạn thường gặp lỗi nào nhiều nhất khi Ping không thành công?

Rất nhiều doanh nghiệp nghĩ rằng một khi đã 'lên cloud', bảo mật gần như là chuyện của nhà cung cấp?

dungabx — Fri, 04 Sep 2026 01:08:26 GMT

Rất nhiều doanh nghiệp nghĩ rằng một khi đã "lên cloud", bảo mật và vận hành gần như là chuyện của nhà cung cấp lo hết. Sự thật là ranh giới trách nhiệm đó dịch chuyển tùy theo mô hình dịch vụ bạn chọn - và không hiểu rõ ranh giới này là nguyên nhân của không ít sự cố rò rỉ dữ liệu tưởng như vô lý.

Trước khi nói tới trách nhiệm, cần phân biệt cloud được triển khai theo mô hình nào. Public cloud là tài nguyên dùng chung, do bên thứ ba sở hữu và vận hành, trả phí theo mức sử dụng giống như hóa đơn điện nước. Private cloud dành riêng cho một tổ chức duy nhất, có thể đặt tại chỗ hoặc thuê chỗ ở data center của nhà cung cấp, đổi lại là toàn quyền kiểm soát và tùy biến. Hybrid cloud kết hợp cả hai: dữ liệu nhạy cảm giữ trong private, còn khối lượng công việc cần mở rộng đột biến thì đẩy ra public - rất hợp với các công ty startup muốn tối ưu chi phí mà vẫn giữ được phần lõi an toàn. Community cloud là biến thể ít gặp hơn, nơi vài tổ chức có chung tiêu chuẩn bảo mật hoặc quy trình (thường thấy ở các cơ quan nhà nước) chia sẻ chung một hạ tầng multi-tenant thay vì mỗi bên tự dựng riêng.

Giờ mới đến phần hay bị hiểu lầm nhất: ranh giới trách nhiệm giữa người dùng và nhà cung cấp thay đổi hoàn toàn tùy theo mô hình dịch vụ.

Với hạ tầng chạy tại chỗ theo kiểu truyền thống, gần như mọi thứ - từ ứng dụng, dữ liệu, runtime, middleware, hệ điều hành, ảo hóa, mạng, lưu trữ, đến chính máy chủ vật lý - đều do đội IT nội bộ tự quản lý.

IaaS bắt đầu chuyển giao phần cứng ra cho nhà cung cấp: server, lưu trữ, mạng và tầng ảo hóa giờ là việc của họ, còn hệ điều hành, middleware, runtime, ứng dụng và dữ liệu vẫn là trách nhiệm của bạn. Đây là lý do IaaS linh hoạt gần như tuyệt đối - bạn có thể cài bất kỳ hệ điều hành hay phần mềm nào lên trên - nhưng cũng đồng nghĩa nếu hệ điều hành đó thiếu bản vá, lỗi hoàn toàn thuộc về bạn chứ không phải nhà cung cấp.

PaaS đẩy ranh giới lên thêm một bậc: nhà cung cấp lo luôn cả hệ điều hành, middleware và runtime, bạn chỉ còn việc viết code và quản lý dữ liệu ứng dụng của chính mình. Tốc độ phát triển nhanh hơn hẳn, nhưng đổi lại bạn bị khóa khá chặt vào ngôn ngữ lập trình và công cụ mà nền tảng đó hỗ trợ.

SaaS thì gần như giao hết, trừ đúng một thứ bạn không bao giờ được nhường: dữ liệu. Outlook, Gmail, Dropbox đều là SaaS - nhà cung cấp lo từ hạ tầng đến chính ứng dụng, bạn chỉ việc đăng nhập và dùng, nhưng nội dung, tài liệu, thông tin khách hàng nằm trong đó vẫn luôn là trách nhiệm pháp lý và bảo mật của bạn, không phải của nhà cung cấp.

Một biến thể ít được nhắc tới hơn là DaaS - toàn bộ desktop ảo hóa được xử lý trên cloud, máy trạm người dùng chỉ còn là thiết bị hiển thị (thin client), dữ liệu không bao giờ thực sự nằm trên máy đầu cuối. Cách này giúp việc quản lý hàng loạt máy trạm và bảo mật dữ liệu tập trung dễ hơn nhiều so với việc rải dữ liệu ra hàng trăm laptop cá nhân.

Kết nối lên cloud cũng có mấy lựa chọn khác biệt rõ về mức độ an toàn và tốc độ. VPN mã hóa một đường hầm chạy đè lên Internet công cộng, đủ an toàn cho phần lớn nhu cầu truy cập từ xa, kể cả qua Wi-Fi công cộng. Private-direct connection thì bỏ hẳn Internet công cộng ra khỏi phương trình, kéo một đường cáp vật lý chuyên dụng thẳng tới nhà cung cấp cloud, cho tốc độ và độ ổn định cao hơn hẳn nhưng chi phí cũng cao tương ứng, thường chỉ hợp với các luồng dữ liệu doanh nghiệp cực lớn.

Multitenancy là khái niệm nền cho tất cả các mô hình cloud dùng chung: nhiều khách hàng chạy trên cùng phần cứng vật lý, giống như một tòa chung cư dùng chung điện nước, thang máy, nhưng mỗi căn hộ vẫn có khóa riêng và không ai xem được đồ đạc của ai. Vấn đề là nếu hạ tầng multitenancy bị cấu hình sai, ranh giới cách ly đó có thể bị xuyên thủng - đây cũng là lý do IaaS luôn liệt kê rủi ro chia sẻ tài nguyên vật lý là một điểm cần cân nhắc.

Vài thuật ngữ hay xuất hiện khi vận hành cloud ở quy mô lớn: elasticity là khả năng hệ thống tự phình to hoặc co lại theo đúng lưu lượng thực tế, tránh vừa lãng phí lúc vắng khách vừa nghẽn lúc cao điểm. Infrastructure as Code biến việc dựng hạ tầng thành các file cấu hình có thể đọc, review, và chạy lại y hệt mỗi lần, thay vì click chuột thủ công dễ sai sót. Automation là tự động hóa một tác vụ đơn lẻ, còn orchestration là ghép nhiều automation lại thành một quy trình hoàn chỉnh - automation lo từng bước, orchestration lo cả dây chuyền.

Chọn sai mô hình triển khai hay mô hình dịch vụ không chỉ là vấn đề chi phí, mà còn quyết định luôn ai là người chịu trách nhiệm khi có sự cố xảy ra - và đó là câu hỏi nên trả lời rõ ràng trước khi ký hợp đồng, không phải sau khi dữ liệu đã rò rỉ.

Tổ chức bạn đang dùng mô hình cloud nào - IaaS để tự chủ động, hay SaaS cho gọn nhẹ? Chia sẻ để mọi người cùng tham khảo nhé.

🌐 một gói tin từ pc đến google đã đi qua những gì?

ThanhTho — Thu, 03 Sep 2026 13:45:19 GMT

Mỗi ngày, chúng ta mở trình duyệt, nhập một địa chỉ website và nhấn Enter. Chỉ vài giây sau, nội dung xuất hiện trên màn hình.

Nhưng phía sau thao tác tưởng chừng đơn giản đó là một hành trình khá thú vị của dữ liệu. Một yêu cầu từ máy tính của bạn phải đi qua nhiều bước, nhiều thiết bị và nhiều công nghệ mạng khác nhau trước khi đến được máy chủ trên Internet.

Nếu đang học CCNA, bạn có thể thử nhìn việc truy cập một website dưới góc độ khác:

Một gói tin thực sự đã đi đâu từ PC của bạn ra Internet?

💻 BƯỚC 1: TỪ TÊN MIỀN ĐẾN ĐỊA CHỈ IP

Giả sử máy tính của bạn đang có thông tin:

IP Address: 192.168.1.10/24
Default Gateway: 192.168.1.1
DNS Server: 8.8.8.8

Bạn mở trình duyệt và nhập tên một website.

Vấn đề là máy tính không sử dụng tên miền để định tuyến dữ liệu. Các thiết bị mạng cần biết địa chỉ IP của máy chủ đích.

Vì vậy, một trong những bước đầu tiên là DNS Resolution.

Máy tính gửi yêu cầu đến DNS Server để hỏi địa chỉ IP tương ứng với tên miền. Sau khi nhận được kết quả, PC mới biết cần gửi dữ liệu đến đâu.

Đây cũng là lý do trong thực tế có trường hợp máy tính vẫn có kết nối Internet, thậm chí Ping được một địa chỉ IP, nhưng không truy cập được website bằng tên miền. Khi đó, vấn đề có thể nằm ở DNS.

🔍 BƯỚC 2: PC KIỂM TRA ĐÍCH ĐẾN

Sau khi biết IP Address của máy chủ, PC sẽ kiểm tra:

Máy chủ đích có nằm cùng mạng với mình hay không?

Với địa chỉ 192.168.1.10/24, PC thuộc mạng:

192.168.1.0/24

Một máy chủ trên Internet rõ ràng không nằm trong mạng nội bộ này.

Lúc đó, PC hiểu rằng nó không thể gửi dữ liệu trực tiếp đến máy chủ đích. Thay vào đó, Packet phải được gửi đến Default Gateway.

Default Gateway chính là thiết bị giúp máy tính chuyển lưu lượng đến những mạng khác ngoài mạng LAN hiện tại.

Đây là một trong những khái niệm quan trọng nhất khi bắt đầu học Routing.

🔄 BƯỚC 3: ARP – TÌM MAC ADDRESS CỦA DEFAULT GATEWAY

PC đã biết IP Address của Default Gateway là 192.168.1.1, nhưng để truyền dữ liệu trong mạng Ethernet, nó vẫn cần biết MAC Address của thiết bị nhận.

Lúc này, ARP – Address Resolution Protocol bắt đầu hoạt động.

PC gửi một ARP Request dạng Broadcast với nội dung:

“Ai đang sở hữu IP Address 192.168.1.1?”

Router hoặc thiết bị Gateway sẽ trả lời bằng MAC Address của mình.

Sau đó, PC lưu thông tin này vào ARP Table.

Bây giờ PC đã có hai thông tin quan trọng:

Destination IP Address: Địa chỉ của máy chủ cần truy cập
Destination MAC Address: MAC Address của Default Gateway

Đây là điểm giúp chúng ta phân biệt rõ hơn vai trò của IP và MAC Address.

IP Address giúp xác định đích đến ở Layer 3, trong khi MAC Address được sử dụng để chuyển Frame trong từng chặng kết nối Layer 2.

🔀 BƯỚC 4: SWITCH CHUYỂN FRAME ĐẾN ROUTER

PC đóng gói dữ liệu thành Ethernet Frame và gửi đến Switch.

Switch hoạt động chủ yếu dựa trên MAC Address. Nó kiểm tra Destination MAC Address và tìm kiếm trong MAC Address Table để xác định Frame cần được chuyển ra cổng nào.

Nếu Switch đã biết MAC Address của Router nằm ở cổng tương ứng, Frame sẽ được chuyển trực tiếp đến Router.

Trong trường hợp chưa biết MAC Address đích, Switch có thể Flood Frame trong VLAN tương ứng.

Qua bước này, chúng ta có thể thấy các kiến thức như:

MAC Address Table
Switching
VLAN
Broadcast Domain

không phải những nội dung riêng lẻ. Chúng đều xuất hiện trong một quá trình truyền dữ liệu thực tế.

🚦 BƯỚC 5: ROUTER QUYẾT ĐỊNH ĐƯỜNG ĐI

Khi nhận được Frame, Router xử lý thông tin Layer 2 và kiểm tra Destination IP Address trong Packet.

Sau đó, Router tìm kiếm trong Routing Table để trả lời câu hỏi:

“Muốn đến mạng này, tôi phải gửi dữ liệu đi đâu tiếp theo?”

Routing Table có thể chứa:

Connected Route
Static Route
Default Route
Dynamic Route như OSPF

Sau khi xác định được đường đi, Router sẽ gửi Packet đến Next-Hop phù hợp.

Một điều rất quan trọng khi học CCNA là:

🔥 MAC Address có thể thay đổi sau mỗi chặng, nhưng Packet vẫn được định tuyến dựa trên địa chỉ IP nguồn và IP đích.

Mỗi khi Packet đi qua một Router, nó được đóng gói lại vào một Frame mới để tiếp tục hành trình trên liên kết tiếp theo.

🌍 BƯỚC 6: NAT – TỪ MẠNG NỘI BỘ RA INTERNET

Trong mạng doanh nghiệp hoặc gia đình, máy tính thường sử dụng Private IP Address như:

192.168.x.x
10.x.x.x
172.16.x.x – 172.31.x.x

Những địa chỉ này không được định tuyến trực tiếp trên Internet công cộng.

Vì vậy, khi dữ liệu đi ra Internet, Router hoặc Firewall thường thực hiện NAT – Network Address Translation.

Ví dụ:

192.168.1.10 → Public IP Address

Thiết bị NAT chuyển đổi địa chỉ Private thành Public IP phù hợp để dữ liệu có thể tiếp tục đi ra Internet.

Khi máy chủ gửi dữ liệu phản hồi trở về, thiết bị NAT sẽ dựa vào thông tin đã lưu để chuyển lưu lượng về đúng máy tính trong mạng nội bộ.

🔁 VÀ CUỐI CÙNG, DỮ LIỆU QUAY VỀ PC

Sau khi yêu cầu đến được máy chủ, máy chủ xử lý và gửi phản hồi trở lại.

Dữ liệu tiếp tục đi qua các Router trên Internet, quay về hệ thống mạng của bạn.

Thiết bị NAT thực hiện chuyển đổi địa chỉ, Router chuyển Packet vào mạng nội bộ và Switch chuyển Frame đến đúng cổng đang kết nối với PC.

Cuối cùng, dữ liệu xuất hiện trên màn hình.

Chỉ với một lần nhấn Enter, phía sau đã có sự phối hợp của rất nhiều công nghệ:

DNS → ARP → Switching → Routing → NAT → Internet

🎯 CCNA KHÔNG CHỈ LÀ NHỮNG CÂU LỆNH

Khi học CCNA, chúng ta thường học từng chủ đề riêng biệt: VLAN, STP, Routing, OSPF, NAT hay ACL.

Nhưng trong một hệ thống mạng thực tế, những kiến thức này không hoạt động độc lập.

Chúng kết hợp với nhau để giải quyết một nhiệm vụ rất đơn giản:

Đưa dữ liệu từ điểm này đến đúng điểm khác.

Vì vậy, thay vì chỉ hỏi:

“Câu lệnh này dùng để làm gì?”

Hãy thử đặt câu hỏi:

🔥 “Nếu Packet bắt đầu từ PC này, bước tiếp theo nó sẽ đi đâu?”

Khi bạn theo dõi được hành trình của một Packet, bạn sẽ bắt đầu hiểu rõ hơn cách Switch hoạt động, vì sao cần Default Gateway, Router dựa vào đâu để chọn đường đi và NAT có vai trò gì khi truy cập Internet.

Đó cũng chính là lúc việc học CCNA không còn chỉ là ghi nhớ câu lệnh.

💬 Theo bạn, trong hành trình từ PC ra Internet, phần nào khó hiểu nhất: ARP, Routing hay NAT?

Ccna: Các mô hình triển khai wi-fi doanh nghiệp bạn cần nắm

SinhNguyen — Thu, 03 Sep 2026 10:02:42 GMT

Cắm một cục AP ở nhà thì ai cũng làm được. Nhưng bước vào lab CCNA, nhìn sơ đồ có WLC, CAPWAP, FlexConnect... nhiều anh em mới bắt đầu hơi ngợp, không biết nên bám vào đâu để hiểu bản chất.
Thật ra chỉ cần nắm chắc 3 mô hình lõi trong hệ sinh thái Cisco — Autonomous AP, Lightweight AP (Local Mode) và (FlexConnect) — là đã nắm được phần lớn bức tranh Wi-Fi doanh nghiệp rồi. Và cách nhớ dễ nhất không phải là học thuộc lệnh cấu hình, mà là hình dung qua vài ẩn dụ đời thường sau đây. 1. Autonomous AP — "Bưu cục địa phương độc lập"

Ẩn dụ: AP giống như một bưu cục nhỏ hoạt động độc lập. Thư đến, bưu cục tự phân loại, đóng gói và chuyển đi mà không cần báo cáo về trung tâm.
Kỹ thuật: AP tự xử lý cả Control Plane và Data Plane, không cần Controller.
Nếu AP chỉ phát một SSID tương ứng với một VLAN, Switch có thể dùng Access Port.
Nhưng nếu AP phát nhiều SSID, ví dụ Employee, Guest, IoT tương ứng với nhiều VLAN, AP phải xử lý 802.1Q tagging. Khi đó cổng Switch kết nối AP thường sẽ là Trunk Port.
Ví dụ: Quán cà phê hoặc văn phòng nhỏ. Mỗi AP được cấu hình riêng và không có hệ thống quản lý tập trung. 2. Lightweight AP – Local Mode — "Hòm thư & Trung tâm phân loại"

Ẩn dụ: AP giống như một hòm thư. Nó nhận thư từ người dùng, đóng gói vào một đường hầm và chuyển về trung tâm phân loại là WLC.
Kỹ thuật: Cisco sử dụng kiến trúc Split-MAC và giao thức CAPWAP để kết nối AP với WLC.
Trong Local Mode, traffic client được tunnel về WLC. Vì nhiều SSID/VLAN được đưa qua đường hầm CAPWAP, cổng Switch kết nối AP thường chỉ cần là Access Port cho VLAN quản lý AP.
Việc xử lý traffic và đưa vào các VLAN phía mạng doanh nghiệp được WLC đảm nhiệm.
Ví dụ: Trường đại học, khách sạn hoặc doanh nghiệp có hàng trăm AP. WLC giúp quản lý tập trung và hỗ trợ các cơ chế roaming giữa các AP. 3. Lightweight AP – FlexConnect — "Chi nhánh thông minh"

Ẩn dụ: FlexConnect giống như một cửa hàng nhượng quyền thông minh. Trụ sở vẫn quản lý và điều khiển, nhưng cửa hàng có thể tự xử lý việc bán hàng tại chỗ khi mất kết nối với trụ sở.
Kỹ thuật: AP vẫn duy trì kết nối Control với WLC khi có thể, nhưng Data traffic có thể được chuyển mạch trực tiếp tại chi nhánh bằng cơ chế Local Switching.
Vì Data traffic được xử lý tại chỗ, nếu nhiều SSID tương ứng với nhiều VLAN thì cổng Switch kết nối AP thường cần cấu hình Trunk Port.
Một điểm cần nhớ: mất WAN không đồng nghĩa mọi client đều chắc chắn kết nối được.
Khả năng client mới đăng nhập phụ thuộc vào cơ chế authentication:

Open/PSK: có thể tiếp tục hoạt động trong nhiều kịch bản.

802.1X + RADIUS ở trụ sở: có thể không xác thực được khi mất đường tới RADIUS.

RADIUS dự phòng tại chi nhánh: có thể giúp duy trì khả năng xác thực.

Ví dụ: Doanh nghiệp có hàng chục chi nhánh, WLC đặt tại trụ sở nhưng muốn Wi-Fi tại chi nhánh vẫn hoạt động khi đường WAN gặp sự cố. Nhớ nhanh 3 mô hình

Autonomous AP:
AP tự xử lý → không cần Controller.
Local Mode:
AP → CAPWAP → WLC → xử lý tập trung.
FlexConnect:
Control → WLC
Data → Local Switching tại chi nhánh.
Chỉ cần nhớ 3 câu hỏi:
Data đi đâu?
Control đi đâu?
VLAN được xử lý ở đâu?
Nắm được ba điểm này, bạn sẽ hiểu bản chất của các mô hình Wi-Fi thay vì chỉ học thuộc cấu hình.
Và Wi-Fi doanh nghiệp chưa dừng lại ở đây.
Xu hướng hiện nay tiến thêm một bước với Cloud-managed AP, tiêu biểu như Cisco Meraki. Thay vì triển khai WLC vật lý tại doanh nghiệp, hệ thống quản lý được đưa lên Cloud, hỗ trợ triển khai và quản lý AP từ xa.
Phần Cloud-based Wi-Fi sẽ là chủ đề cho bài tiếp theo.
Anh em đang làm lab CCNA thì thường gặp mô hình nào nhất?
#CCNA #Networking #Infrastructure

Phần lớn lưu lượng trong data center hiện đại còn chẳng buồn đi ra Internet.

dungabx — Thu, 03 Sep 2026 04:33:03 GMT

Trong một trung tâm dữ liệu hiện đại, phần lớn lưu lượng mạng còn chẳng buồn đi ra Internet. Nó chạy lòng vòng giữa server với server, ngay bên trong bốn bức tường - và chính sự thật này đã âm thầm viết lại toàn bộ cách người ta thiết kế mạng data center trong hơn một thập kỷ qua.

Lưu lượng trong data center được chia theo hai hướng. North-South là lưu lượng đi xuyên biên ra ngoài, giữa client và server, qua tường lửa perimeter để vào hoặc ra khỏi trung tâm dữ liệu. East-West là lưu lượng nội bộ, server nói chuyện với server, switch nói chuyện với switch, hoàn toàn không rời khỏi ranh giới vật lý. Với sự bùng nổ của ảo hóa và microservices, East-West giờ đây mới là phần chiếm khối lượng áp đảo, chứ không còn là North-South như thời web server truyền thống.

Kiến trúc mạng ba lớp truyền thống - Access, Distribution, Core - vốn được thiết kế cho một thế giới mà North-South là chính. Access layer dùng switch Top-of-Rack nối trực tiếp server. Distribution gộp các switch access lại, lo cân bằng tải và uplink tốc độ cao. Core là tầng trên cùng, định tuyến dung lượng lớn kết nối tới các dịch vụ lõi. Vấn đề là cấu trúc này cần chạy Spanning Tree Protocol để chặn vòng lặp switch phát sinh từ các liên kết dự phòng - mà STP thì luôn khóa chết một số đường liên kết ở trạng thái chờ, coi như lãng phí băng thông đã đầu tư.

Đó là lý do kiến trúc Spine-Leaf ra đời để thay thế dần mô hình ba lớp trong các data center hiện đại. Leaf là các switch access nối trực tiếp server, không leaf nào nối thẳng với leaf khác. Spine nối tới tất cả các leaf theo kiểu full-mesh. Kết quả là từ bất kỳ server nào đến bất kỳ server nào, số hop luôn bằng nhau, độ trễ luôn có thể dự đoán được, và một switch Spine chết cũng không tạo ra điểm lỗi đơn lẻ vì luôn còn đường khác chạy song song - không còn phải hy sinh băng thông cho STP như trước.

Song song với thay đổi về cấu trúc vật lý, SDN thay đổi cách quản lý mạng. Thay vì để từng switch, router tự quyết định đường đi một cách phân tán, SDN tách hẳn control plane - phần ra quyết định - khỏi data plane - phần chuyển tiếp gói tin vật lý, rồi gom control plane vào một bảng điều khiển trung tâm. Quản trị viên cấu hình toàn bộ chính sách mạng qua phần mềm, dùng SSH, SNMP hoặc gọi API trực tiếp, thay vì đăng nhập thủ công vào từng thiết bị.

Lưu trữ trong data center cũng đi theo một logic tách biệt tương tự. SAN là mạng lưu trữ chuyên dụng, khiến ổ đĩa từ xa hiện diện với server y như một ổ đĩa gắn cục bộ. Fibre Channel cho hiệu năng cao nhất nhưng đắt đỏ và cần hạ tầng cáp quang riêng. FCoE gói khung FC chạy trên hạ tầng Ethernet có sẵn để tiết kiệm chi phí đầu tư song song. iSCSI đơn giản nhất, chạy lệnh SCSI qua IP thông thường, rẻ và đủ dùng cho phần lớn doanh nghiệp vừa và nhỏ. InfiniBand dành riêng cho những khối lượng tính toán cần độ trễ cực thấp, thường thấy trong các cụm HPC hoặc AI training.

Bên dưới tất cả những lớp trên vẫn là bài toán muôn thuở: một ổ đĩa vật lý có thể hỏng bất cứ lúc nào, và RAID là câu trả lời kinh điển nhất cho việc đó. RAID 0 chỉ để tăng tốc, phân mảnh dữ liệu qua nhiều đĩa, không chịu được lỗi - một đĩa hỏng là mất trắng cả mảng. RAID 1 nhân bản dữ liệu, chịu được một đĩa hỏng nhưng tốn 50% dung lượng. RAID 5 dùng tối thiểu 3 đĩa, rải parity đều lên tất cả các đĩa, chịu được một đĩa hỏng mà không tốn dung lượng nhiều như RAID 1 - đây là lựa chọn cân bằng phổ biến nhất. RAID 6 thêm một lớp parity thứ hai, chịu được hai đĩa hỏng cùng lúc, đánh đổi bằng hiệu năng ghi chậm hơn. RAID 10 kết hợp phân mảnh và nhân bản, vừa nhanh vừa chịu lỗi tốt, nhưng đòi hỏi tối thiểu 4 đĩa và vẫn tốn nửa dung lượng như RAID 1. Với hệ thống cực lớn, RAID 50 và RAID 60 xếp chồng thêm một lớp phân mảnh lên trên các tập đĩa RAID 5 hoặc RAID 6 để vừa mở rộng dung lượng vừa giữ khả năng chịu lỗi.

Nhìn xuyên suốt cả chương, một điểm chung xuất hiện lặp đi lặp lại: từ kiến trúc mạng, cách quản lý, đến cách lưu trữ, mọi thiết kế hiện đại đều nhắm tới đúng hai mục tiêu - loại bỏ điểm lỗi đơn lẻ, và không để một thành phần trung tâm nào tự ý quyết định một mình.

Hệ thống chỗ bạn đang chạy theo kiến trúc ba lớp truyền thống hay đã chuyển sang Spine-Leaf rồi? Chia sẻ để mọi người cùng tham khảo nhé.

Thử sức ccna: 30 vlan mới – bạn có chia subnet đủ không?

ThanhQuyen — Mon, 31 Aug 2026 09:20:37 GMT

THỬ SỨC CCNA: 30 VLAN MỚI – BẠN CÓ CHIA SUBNET ĐỦ KHÔNG?

Bạn đang quản trị một mạng 192.168.0.0/24.
Hiện tại VLAN 10 có 3 PC. Nhưng hệ thống dự kiến sẽ mở rộng thêm 30 VLAN nữa.
Câu hỏi tưởng đơn giản nhưng lại kiểm tra một kiến thức cực kỳ quan trọng trong CCNA:
Bạn sẽ chọn subnet mask nào để vừa đủ số subnet, vừa đáp ứng số host cho mỗi VLAN? CÂU HỎI

Một kỹ sư được giao nhiệm vụ cấp phát IP cho VLAN hiện tại với 3 PC.
Cấu hình cũng phải đủ khả năng mở rộng thêm 30 VLAN, sử dụng cùng một mạng Class C để subnetting.
Lệnh nào sau đây phù hợp với yêu cầu mở rộng?
A. ip address 192.168.0.1 255.255.255.128
B. ip address 192.168.0.1 255.255.255.248
C. ip address 192.168.0.1 255.255.255.0
D. ip address 192.168.0.1 255.255.255.128
Bạn hãy thử tự tính trước khi xem phần phân tích. PHÂN TÍCH ĐỀ

Có 2 yêu cầu cần đồng thời thỏa mãn: Cần bao nhiêu subnet?

Mạng ban đầu là:
192.168.0.0/24
Có VLAN hiện tại và cần mở rộng thêm 30 VLAN.
Như vậy cần ít nhất:
31 subnet
Muốn có ít nhất 31 subnet thì số bit mượn từ phần host phải đủ tạo ra số subnet tương ứng.

Mượn 3 bit → 8 subnet

Mượn 4 bit → 16 subnet

Mượn 5 bit → 32 subnet

Vậy cần subnet /29. /29 có đủ host cho mỗi VLAN không?

Với /29:

Có 8 địa chỉ IP/subnet

Trừ Network Address và Broadcast Address

Còn 6 địa chỉ host sử dụng được

VLAN hiện tại chỉ có 3 PC, vì vậy 6 host là đủ.
Như vậy /29 vừa đáp ứng được số lượng subnet, vừa đáp ứng được số lượng host. ĐÁP ÁN: B

192.168.0.1 255.255.255.248
Trong đó:
255.255.255.248 = /29
Đây là điểm quan trọng cần nhớ:
Đề không chỉ hỏi “có đủ IP cho 3 PC hay không”, mà còn hỏi khả năng mở rộng thêm 30 VLAN.
Nếu chỉ nhìn vào 3 PC, bạn rất dễ chọn một subnet lớn hơn.
Nhưng khi đọc kỹ đề, yêu cầu quyết định đáp án lại là:
Cần tối thiểu 31 subnet.
/29 tạo được 32 subnet, đồng thời mỗi subnet có 6 host usable → phù hợp với yêu cầu. ĐIỂM DỄ SAI CỦA CÂU NÀY

Đây chính là kiểu câu hỏi CCNA dễ khiến người học tính đúng host nhưng lại chọn sai subnet mask.
Muốn làm tốt dạng bài này, đừng chỉ học thuộc bảng subnet.
Hãy hình thành thói quen:
Đọc yêu cầu → xác định số subnet → xác định số host/subnet → chọn subnet mask.
Khi đã hiểu bản chất, những câu hỏi subnetting sẽ không còn là bài toán “nhớ công thức”, mà trở thành bài toán logic. CCNA (200-301) – HỌC TỪ NỀN TẢNG ĐẾN THỰC HÀNH

Nếu bạn nhìn câu hỏi này và có thể tự tính ra /29, rất tốt.
Nhưng nếu bạn vẫn đang phân vân:
Vì sao phải mượn 5 bit?
Vì sao /29 tạo được 32 subnet?
Vì sao mỗi subnet chỉ có 6 host?
Khi nào nên dùng /27, /28 hay /29?
Thì đó chính là những phần kiến thức cần được học và thực hành bài bản trong CCNA. KHÓA CCNA (200-301) – VNPRO

Lớp ONLINE
Khai giảng: 07/09/2026
Đừng học CCNA chỉ để nhớ đáp án.
Hãy học để nhìn một bài toán mạng và biết mình phải bắt đầu từ đâu.
Hotline: 0933 427 079
#VnPro #CCNA #CCNA200301 #Cisco #Networking #Subnetting #NetworkEngineer #HocCCNA #ITCareer

Chỉ sai 1 thao tác, cả chính sách conditional access có thể không đáp ứng yêu cầu!

ThanhQuyen — Mon, 31 Aug 2026 08:37:00 GMT

CHỈ SAI 1 THAO TÁC, CẢ CHÍNH SÁCH CONDITIONAL ACCESS CÓ THỂ KHÔNG ĐÁP ỨNG YÊU CẦU!

Trong quá trình học và luyện thi AZ-104, có rất nhiều câu hỏi khiến người học dễ chọn sai không phải vì không biết Azure, mà vì nhìn thấy một từ khóa quen thuộc rồi vội vàng chọn giải pháp.
Hãy cùng phân tích một câu hỏi thực tế dưới đây Yêu cầu của đề bài là gì?

Công ty đang sử dụng Azure Active Directory (Azure AD) và muốn triển khai một Conditional Access Policy.
Chính sách cần đảm bảo:
Thành viên nhóm Global Administrators phải sử dụng Multi-Factor Authentication (MFA).
Khi kết nối Azure AD từ untrusted locations, người dùng phải sử dụng thiết bị Azure AD-joined.
Nói cách khác, đề bài yêu cầu một chính sách kiểm soát truy cập dựa trên nhiều điều kiện khác nhau, bao gồm:
User/Group
Location
Device
Access Control Giải pháp đề bài đưa ra là gì?

Truy cập Azure Portal để thay đổi Session Controls của Azure AD Conditional Access Policy.
Câu hỏi:
Giải pháp này có đáp ứng yêu cầu không?
Đáp án đúng: B – NO Vì sao đáp án là NO?

Đây chính là điểm dễ gây nhầm lẫn.
Đề bài yêu cầu:

Bắt buộc MFA cho Global Administrators.

Kiểm soát thiết bị Azure AD-joined.

Áp dụng điều kiện khi đăng nhập từ untrusted locations.

Trong khi đó, Session Controls trong Conditional Access tập trung vào việc kiểm soát phiên truy cập sau khi quá trình xác thực và các điều kiện truy cập được xử lý.
Ví dụ, Session Controls có thể liên quan đến việc quản lý hoặc giới hạn phiên làm việc.
Nhưng Session Controls không phải nơi để cấu hình các điều kiện chính như User/Group, Location, Device hoặc yêu cầu MFA.
Vì vậy:
Thay đổi Session Controls
≠ Cấu hình đầy đủ yêu cầu MFA + Location + Azure AD-joined Device.
Do đó, giải pháp được đưa ra không đáp ứng mục tiêu của đề bài. Đáp án chính xác: B – NO

Cách tư duy để tránh mất điểm ở dạng câu hỏi này

Đừng chỉ nhìn thấy các từ quen thuộc như:
Conditional Access → Azure Portal → Session Controls
rồi nghĩ ngay rằng giải pháp chắc chắn đúng.
Hãy tập thói quen hỏi:
“Đề bài yêu cầu cấu hình ở phần nào, và giải pháp đề xuất có thực sự tác động đến đúng phần đó không?”
Với câu hỏi này:
Yêu cầu:
MFA + User/Group + Location + Device
Giải pháp:
Session Controls
Không đúng khu vực cấu hình cần thiết.
Kết luận: NO.
Đây cũng là tư duy rất quan trọng khi làm bài AZ-104: không học theo kiểu thấy từ khóa nào quen thì chọn, mà phải đọc yêu cầu – xác định chức năng – đối chiếu giải pháp – đưa ra kết luận. HỌC AZURE KHÔNG CHỈ ĐỂ NHỚ ĐÁP ÁN, MÀ ĐỂ HIỂU VÌ SAO ĐÁP ÁN ĐÚNG

Nhiều bạn khi tự học AZ-104 gặp tình trạng:
Làm nhiều câu hỏi nhưng vẫn không hiểu bản chất.
Đổi tình huống là bắt đầu phân vân.
Nhìn đáp án quen nhưng không biết vì sao chọn.
Học xong lý thuyết nhưng chưa biết áp dụng vào Azure thực tế.
Đó là lý do việc học theo tình huống và tư duy phân tích quan trọng hơn việc chỉ ghi nhớ đáp án. AZURE 104 – LỚP ONLINE

Khai giảng: 04/09/2026
Khóa học phù hợp cho những bạn muốn:
Xây dựng nền tảng quản trị Microsoft Azure bài bản.
Hiểu cách các dịch vụ Azure hoạt động trong thực tế.
Thực hành và làm quen với các tình huống quản trị Cloud.
Rèn tư duy phân tích câu hỏi thay vì học thuộc đáp án.
Chuẩn bị kiến thức và nền tảng cho kỳ thi AZ-104.
Một câu hỏi đúng không chỉ giúp bạn có thêm 1 đáp án. Quan trọng hơn, nó giúp bạn hiểu Azure đang hoạt động như thế nào.
AZURE 104 – LỚP ONLINE khai giảng ngày 04/09/2026 – dành cho những bạn muốn học bài bản, hiểu bản chất và tự tin hơn trên hành trình chinh phục Cloud.
Hotline: 0933 427 079
#VnPro #AZ104 #Azure104 #MicrosoftAzure #AzureAdministrator #CloudComputing #HocAzure #CloudCareer

ở xa, bận công việc – vẫn có thể học ccna tại vnpro

ThanhQuyen — Mon, 31 Aug 2026 08:04:50 GMT

Ở XA, BẬN CÔNG VIỆC – VẪN CÓ THỂ HỌC CCNA TẠI VNPRO

Bạn muốn học CCNA nhưng lịch làm việc không cho phép đi học 2–3 buổi mỗi tuần?
Bạn ở Vũng Tàu, Bình Dương, Đồng Nai, Tiền Giang..., muốn học trực tiếp nhưng ngại chuyện phải di chuyển nhiều lần lên TP.HCM?
Một tuần chỉ cần sắp xếp 1 ngày để học – vẫn có thể theo đuổi CCNA.
Và đây cũng là lý do lớp CCNA (200-301) sáng + chiều thứ 7 tại VnPro được xây dựng dành cho những người có lịch trình bận rộn.

“Một tuần đi học 1 ngày có đủ không?”

Có – nếu bạn thực sự biết mình đang học gì và có kế hoạch học tập nghiêm túc.
Thay vì phải chạy đi chạy lại nhiều ngày trong tuần, bạn có thể tập trung trọn một ngày thứ 7 cho việc học.
Sáng: Học kiến thức, phân tích bản chất
Chiều: Thực hành, lab và củng cố kiến thức
Những ngày còn lại, bạn có thể dành thời gian cho công việc, gia đình và tự ôn luyện.
Đặc biệt, mô hình này rất phù hợp với những bạn đang đi làm nhưng vẫn muốn nâng cấp chuyên môn, hoặc các bạn ở tỉnh xa muốn tìm một môi trường đào tạo trực tiếp chất lượng.

VÀ ĐÂY KHÔNG PHẢI LÀ CHUYỆN HIẾM Ở VNPRO

Trong những lớp học tại VnPro, có không ít học viên từ Vũng Tàu, Bình Dương, Đồng Nai, Tiền Giang... chủ động sắp xếp thời gian để lên học.
Có người đi làm cả tuần.
Có người ở khá xa.
Có người phải dành gần như trọn ngày thứ 7.
Nhưng họ vẫn chọn cách:
“Một tuần đi học một ngày, còn hơn muốn học nhưng cứ trì hoãn mãi vì không sắp xếp được thời gian.”
Và đó là điều VnPro rất trân trọng.
Bởi học CNTT, đặc biệt là Networking, không phải cuộc đua xem ai học nhanh nhất.
Quan trọng là bạn có bắt đầu và kiên trì đủ lâu hay không.

CCNA KHÔNG CHỈ DÀNH CHO NGƯỜI Ở GẦN

Nếu bạn đang ở xa nhưng muốn:
Xây dựng nền tảng Network bài bản
Học trực tiếp với giảng viên
Được thực hành Lab thay vì chỉ học lý thuyết
Có môi trường học tập nghiêm túc
Chuẩn bị cho chứng chỉ CCNA 200-301
Tạo nền tảng để phát triển tiếp lên CCNP / Network / Cloud / Security
thì khoảng cách địa lý không nhất thiết phải là lý do để bạn bỏ cuộc.
Chỉ cần bạn có thể dành 1 ngày mỗi tuần cho mục tiêu của mình.

VNPRO CHIÊU SINH CCNA (200-301)

Lịch học: SÁNG + CHIỀU THỨ 7
Khai giảng: 12/09/2026
Một ngày học tập trung – một tuần có thêm một bước tiến.
Nếu bạn đang đi làm, đang ở tỉnh xa hoặc đơn giản là không thể sắp xếp lịch học nhiều buổi trong tuần, đây có thể là lịch học phù hợp với bạn.
Đừng chờ đến khi “rảnh” mới bắt đầu học.
Hãy tìm một lịch học phù hợp với cuộc sống hiện tại của mình.
Đăng ký / tư vấn và nhận những ưu đãi hấp dẫn dành cho khóa học này!
Hotline/Zalo: 0933 427 079
Anh Thư: 0339 943 732
Như Ngọc: 0765 944 386
#VnPro #CCNA #CCNA200301 #Cisco #Networking #NetworkEngineer #HocCCNA #ChungChiCCNA #CCNACisco

Phần lớn các ca 'mạng bị lỗi' không nằm ở cáp hay switch.

dungabx — Mon, 31 Aug 2026 07:12:38 GMT

Phần lớn các ca "mạng bị lỗi" mà kỹ sư IT xử lý hàng ngày không nằm ở cáp hay switch, mà nằm ở đúng ba dịch vụ ít ai để ý: DHCP, DNS và NTP. Chỉ cần một trong ba cái này trục trặc, người dùng sẽ báo "mạng chậm", "không vào được web", hay "đăng nhập domain lỗi" - dù hạ tầng vật lý hoàn toàn bình thường.

Bắt đầu với DHCP - dịch vụ cấp IP tự động mà ai cũng dùng nhưng ít người hiểu rõ 4 bước bên trong nó, gọi là tiến trình DORA. Discover: máy khách chưa có IP nên bắt buộc gửi broadcast ở cả lớp 2 lẫn lớp 3 để tìm bất kỳ máy chủ DHCP nào đang lắng nghe. Offer: máy chủ phản hồi một đề xuất IP, broadcast ở lớp 3 nhưng đã là unicast ở lớp 2 vì lúc này đã biết địa chỉ MAC của client. Request: máy khách broadcast lần nữa để xác nhận công khai rằng nó chấp nhận đề xuất từ đúng một máy chủ cụ thể (bước này cần thiết vì có thể có nhiều DHCP server cùng trả lời). Ack: máy chủ gửi xác nhận cuối cùng, hoàn tất việc gán IP.

Vì bước Discover và Request đều là broadcast, DHCP mặc định không vượt qua được ranh giới subnet. Nếu máy chủ DHCP nằm ở một mạng con khác với client, router ở giữa phải được cấu hình IP helper để chuyển gói broadcast đó thành unicast rồi gửi thẳng tới DHCP server - thiếu bước này là nguyên nhân kinh điển khiến cả một dãy máy trong subnet mới không nhận được IP dù DHCP server vẫn chạy tốt.

Vài khái niệm hay gặp khi vận hành DHCP: exclusions là những IP nằm trong dải nhưng bị giữ lại để gán tĩnh cho máy in, switch hay server - quên khai báo exclusion là lý do phổ biến gây xung đột IP. Lease duration là thời hạn thuê IP, mặc định 8 ngày trên Windows Server, hết hạn mà không gia hạn được thì máy sẽ rơi về APIPA.

Sang DNS - hệ thống dịch tên miền sang IP mà gần như mọi sự cố "không vào được web" đều nên nghi ngờ đầu tiên. Khi máy tra một tên miền, resolver cục bộ sẽ kiểm tra cache trước, nếu không có nó chuyển lên recursive resolver để thay mặt client đi hỏi vòng qua toàn bộ hệ thống phân cấp: bắt đầu từ Root Server, xuống TLD server tương ứng đuôi tên miền như .com hay .net, rồi cuối cùng chạm tới Authoritative Name Server - nơi duy nhất giữ câu trả lời chính xác cho đúng tên miền đó.

Bản ghi DNS cũng có vai trò rất khác nhau chứ không chỉ có một loại. A trỏ sang IPv4, AAAA trỏ sang IPv6, CNAME tạo alias trỏ sang một tên miền khác, MX chỉ định server nhận mail, PTR làm nhiệm vụ tra ngược từ IP ra tên miền, và TXT thường được dùng để xác thực sở hữu domain hoặc cấu hình chống giả mạo email như SPF. Riêng SOA giữ thông tin quản trị của cả một zone, còn Zone Transfer là quá trình nhân bản dữ liệu zone đó từ DNS chính sang DNS phụ để dự phòng - cấu hình transfer sai phạm vi có thể vô tình để lộ toàn bộ cấu trúc domain nội bộ ra ngoài.

Cuối cùng là NTP - dịch vụ âm thầm nhất nhưng ảnh hưởng ngầm đến rất nhiều thứ, chạy trên cổng UDP 123. Nếu thời gian giữa các máy lệch nhau, log hệ thống sẽ sai lệch trình tự sự kiện lúc điều tra sự cố, xác thực Active Directory có thể từ chối đăng nhập vì Kerberos vốn rất nhạy với sai lệch thời gian, còn các giao thức định tuyến hội tụ cũng dựa một phần vào đồng bộ thời gian.

NTP tổ chức theo mô hình Stratum: Stratum 0 là nguồn chuẩn tuyệt đối như đồng hồ nguyên tử hoặc GPS, không nối trực tiếp vào mạng. Stratum 1 là máy chủ nối trực tiếp với Stratum 0. Từ Stratum 2 trở đi, mỗi tầng lấy giờ từ tầng ngay phía trên qua kết nối mạng, càng xa nguồn gốc độ chính xác lý thuyết càng giảm, tối đa tới Stratum 15, còn Stratum 16 coi như không đáng tin cậy. Một yếu tố khác cần theo dõi là jitter - độ biến thiên của tín hiệu thời gian so với nguồn chuẩn - jitter cao nghĩa là đồng bộ không ổn định dù trung bình vẫn đúng giờ.

Cả ba dịch vụ này có một điểm chung dễ bị bỏ qua: chúng chạy nền, ít khi được để ý cho đến khi hỏng, và khi hỏng thì triệu chứng lại hiện ra ở một chỗ hoàn toàn khác - người dùng thấy "mạng lỗi" nhưng gốc rễ nằm ở một dịch vụ họ chưa từng nghe tên.

Lần gần nhất bạn debug một sự cố tưởng do mạng nhưng hoá ra lỗi DHCP, DNS hay NTP là khi nào? Kể lại xem thử nhé.

Kỹ thuật dò tìm Topology và truy vết thiết bị khi không có sơ đồ mạng

SinhNguyen — Mon, 31 Aug 2026 03:53:00 GMT

Phòng server không sơ đồ, cáp mạng rối như tơ, và chẳng ai nhớ chính xác thiết bị nào đang nối với thiết bị nào. Đó là lúc một câu hỏi tưởng đơn giản lại quyết định bạn xử lý sự cố trong 5 phút hay thức trắng cả đêm: máy này đang thực sự cắm ở đâu, và traffic đang đi qua ngả nào? Tin vui là hệ thống luôn để lại dấu vết — vấn đề chỉ là bạn có biết hỏi đúng lệnh hay không.
Cùng mình điểm qua 3 tình huống thực tế nhất nhé!
1. Switch này đang kết nối với Router/Switch Core nào?
Cách làm: Dùng CDP với thiết bị Cisco hoặc LLDP – chuẩn chung cho nhiều hãng.
Ví dụ, bạn đang cấu hình một Switch tầng 1 và muốn biết uplink đang kết nối tới cổng nào của Router/Switch Core.
Chỉ cần:

SW-FLOOR1# show cdp neighbors

Device ID Local Intrfce Holdtme Capability Platform Port ID
CORE-SW01 Gi1/0/48 145 S I C9300 Gi1/0/24
CORE-R01 Gi1/0/47 132 R S I ISR4451 Gi0/0/0
Nhìn vào:
Gi1/0/48 ↔ Gi1/0/24
là biết ngay Switch tầng 1 đang kết nối tới CORE-SW01 bằng hai cổng tương ứng.
Khi nào dùng?
Khi cần kiểm tra hoặc dựng lại topology giữa các thiết bị mạng.
Ưu điểm: Nhanh và cho biết cả thiết bị lẫn cổng kết nối ở hai đầu.
Lưu ý: CDP/LLDP cần thiết bị bên kia hỗ trợ và đang quảng bá thông tin. Một số thiết bị đầu cuối như IP Phone, AP... cũng có thể hỗ trợ, nhưng đây không phải công cụ chính để truy tìm PC thông thường.
2. PC/máy in đang cắm vào cổng nào?
Đây là lúc chúng ta truy theo chuỗi:
IP → MAC → Port
Ví dụ người dùng báo:

"Máy tôi mất mạng, IP là 192.168.1.50."
Bước 1: Tìm MAC từ IP
Trên Router/L3 Switch:

R1# show ip arp

Protocol Address Age Hardware Addr Type Interface
Internet 192.168.1.1 - aaaa.bbbb.0001 ARPA Vlan10
Internet 192.168.1.50 12 aaaa.bbbb.cccc ARPA Vlan10
Internet 192.168.1.51 3 aaaa.bbbb.dddd ARPA Vlan10
Ta có:
192.168.1.50 → aaaa.bbbb.cccc
Bước 2: Tìm MAC trên Switch

SW-FLOOR1# show mac address-table

Vlan Mac Address Type Ports
---- ----------- -------- -----
10 aaaa.bbbb.cccc DYNAMIC Fa1/0/5
10 aaaa.bbbb.dddd DYNAMIC Fa1/0/6
20 1111.2222.3333 DYNAMIC Gi1/0/48
Kết quả:
192.168.1.50 → aaaa.bbbb.cccc → Fa1/0/5
Vậy là chúng ta đã xác định được thiết bị đang nằm ở port Fa1/0/5.
Nhưng nếu MAC nằm trên uplink hoặc Port-Channel, chưa được kết luận đây là port của PC.
Ví dụ:

aaaa.bbbb.cccc → Gi1/0/48
Có thể Gi1/0/48 chỉ là uplink sang một Switch khác.
Khi đó tiếp tục truy MAC trên Switch kế tiếp:

SW-FLOOR2# show mac address-table address aaaa.bbbb.cccc

Vlan Mac Address Type Ports
---- ----------- -------- -----
10 aaaa.bbbb.cccc DYNAMIC Fa1/0/5
Cuối cùng mới xác định được:
IP → MAC → Switch → Access Port
Khi nào dùng?
Khi cần tìm chính xác vị trí của End-device để đổi VLAN, kiểm tra lỗi hoặc xác định thiết bị đang kết nối ở đâu.
3. Traffic đang đi qua đâu?
Khi cần kiểm tra đường đi Layer 3, dùng:
traceroute trên thiết bị mạng
hoặc
tracert trên Windows.
Ví dụ:
Chi nhánh không truy cập được Server 10.0.0.10.
Trên Windows chạy:

C:\> tracert 10.0.0.10

Tracing route to 10.0.0.10

1 <1 ms <1 ms <1 ms 192.168.1.1
2 2 ms 2 ms 3 ms 10.10.10.1
3 5 ms 4 ms 5 ms 10.20.20.1
4 8 ms 7 ms 8 ms 10.0.0.10

Trace complete.
Ta có thể hình dung:
PC → 192.168.1.1 → 10.10.10.1 → 10.20.20.1 → Server
Nhờ đó có thể khoanh vùng đường đi của traffic qua hệ thống Layer 3.
Nhưng hãy nhớ:

3 * * * Request timed out.
Không có nghĩa chắc chắn Router ở hop 3 bị lỗi.
Thiết bị có thể đang chặn hoặc giới hạn ICMP, không trả lời traceroute, hoặc có chính sách Firewall/ACL.
Vì vậy * * * chỉ là một manh mối để điều tra, không phải bằng chứng kết luận.
Khi nào dùng?
Khi cần khoanh vùng vấn đề trên WAN hoặc hệ thống lớn mà chúng ta không thể trực tiếp nhìn thấy toàn bộ đường đi.
Tóm lại, chỉ cần nhớ 3 câu:
CDP / LLDP
→ "Tôi đang kết nối với ai?"
ARP + MAC Address Table
→ "Thiết bị này đang nằm ở đâu?"
Traceroute / Tracert
→ "Traffic đang đi qua đâu?"
Nếu nắm được 3 nhóm công cụ này, bạn đã có một bộ công cụ rất cơ bản nhưng cực kỳ hữu ích để "bắt mạch" topology và truy tìm thiết bị trong hệ thống mạng.
Bạn đã từng gặp một hệ thống mạng không có sơ đồ, dây cáp không nhãn, nhưng vẫn phải tìm đúng thiết bị chưa?
Hãy chia sẻ case thực tế của bạn, biết đâu chúng ta lại có thêm một bài troubleshooting hay để cùng phân tích!

Bẫy Thông Số: Vì Sao Cùng 24 Cổng Gigabit Nhưng Giá Trị Lại Cách Biệt?

SinhNguyen — Sat, 29 Aug 2026 13:56:07 GMT

Khi nhìn vào thông số, nhiều người thường đặt câu hỏi:
“Đều là Switch 24 cổng Gigabit, tại sao giá lại chênh lệch nhiều đến vậy?”
Sự khác biệt thực tế không nằm ở lớp vỏ hay đơn giản là số lượng cổng mạng.
Điều tạo nên giá trị của một chiếc Switch Enterprise nằm sâu bên trong thiết bị: kiến trúc phần cứng được thiết kế để hệ thống vẫn hoạt động ổn định khi phải xử lý tải lớn, lưu lượng phức tạp và nhiều tính năng mạng cùng lúc.
Một Switch Enterprise thường có những lợi thế như:

Switching Capacity lớn, giúp xử lý lưu lượng cao mà không trở thành nút thắt cổ chai.

RAM và Packet Buffer lớn để hấp thụ những đợt bùng nổ dữ liệu.

TCAM chuyên dụng để xử lý ACL, QoS và các chính sách bảo mật ở tốc độ phần cứng.

Khả năng xử lý các giao thức mạng như MSTP, EtherChannel, Routing…

Khả năng mở rộng và dự phòng như Stacking, nguồn dự phòng và uplink tốc độ cao.

Trong Phần 1, chúng ta sẽ bắt đầu với một trong những khái niệm dễ gây nhầm lẫn nhất: Bandwidth và Switching Capacity có thực sự giống nhau?

Để dễ hình dung, hãy tưởng tượng một chiếc Switch giống như một hệ thống cấp nước.
Các cổng mạng chính là những chiếc van nước.
Còn ASIC bên trong Switch chính là hệ thống máy bơm và đường ống trung tâm.
Khi bạn nhìn thấy thông số:
24 cổng × 1Gbps
Nhiều người sẽ mặc định rằng chiếc Switch này có thể xử lý đồng thời 24Gbps dữ liệu.
Nhưng thực tế không hẳn như vậy.
Bởi vì tốc độ của từng cổng và khả năng xử lý tổng thể của toàn bộ Switch là hai khái niệm khác nhau. Bandwidth – Tốc độ của từng cổng

Thông số 1Gbps cho biết tốc độ tối đa mà một cổng có thể truyền hoặc nhận dữ liệu.
Nó giống như việc bạn biết kích thước của một chiếc van nước.
Van càng lớn, lượng nước có thể đi qua trong một khoảng thời gian càng nhiều.
Nhưng điều đó chưa nói lên rằng hệ thống phía sau có đủ khả năng xử lý khi tất cả các van cùng được mở hay không.
Đây chính là điểm mà nhiều người thường bỏ qua. Switching Capacity – Sức mạnh xử lý của toàn bộ hệ thống

Hãy tưởng tượng bạn có 24 chiếc van nước rất lớn, nhưng phía sau chúng chỉ là một hệ thống máy bơm nhỏ.
Khi chỉ có 1 hoặc 2 người mở van, mọi thứ vẫn hoạt động bình thường.
Nước chảy mạnh và hệ thống có vẻ rất nhanh.
Nhưng khi cả 24 người cùng mở van ở mức tối đa, chiếc máy bơm bắt đầu trở thành điểm nghẽn.
Áp lực giảm xuống.
Lưu lượng không còn được đáp ứng đầy đủ.
Trong mạng máy tính, đây chính là lúc hiện tượng Congestion hoặc Blocking có thể xảy ra.
Và đây là lý do chúng ta cần quan tâm đến thông số:
Switching Capacity
Thông số này thể hiện khả năng xử lý tổng lưu lượng mà Switch có thể chuyển tiếp trong một khoảng thời gian. Một Switch 24 cổng Gigabit cần bao nhiêu Switching Capacity?

Giả sử chúng ta có:
24 cổng × 1Gbps
Mỗi cổng hoạt động ở chế độ Full-Duplex, nghĩa là có thể:

Truyền 1Gbps

Nhận 1Gbps

Đồng thời.
Khi đó, tổng băng thông lý thuyết cần xử lý là:
24 × 1Gbps × 2 = 48Gbps
Điều này có nghĩa rằng, nếu muốn toàn bộ 24 cổng có thể gửi và nhận dữ liệu ở tốc độ tối đa cùng lúc mà không bị nghẽn bên trong Switch, kiến trúc chuyển mạch cần đáp ứng khoảng 48Gbps Switching Capacity.
Đây chính là khái niệm thường được gọi là:
Non-blocking Architecture
Hay hiểu đơn giản hơn:
Phần cứng bên trong không được phép trở thành nút thắt cổ chai của các cổng mạng.
Một Switch Enterprise thường sở hữu ASIC và Switching Fabric đủ mạnh để đảm bảo rằng khi nhiều thiết bị truyền dữ liệu đồng thời, hệ thống vẫn có thể chuyển tiếp traffic ở tốc độ cao.
Và đây là một phần lý do vì sao hai chiếc Switch cùng có 24 cổng Gigabit nhưng giá thành có thể khác nhau rất lớn.
Bạn không chỉ đang mua:
24 cổng Gigabit.
Bạn đang mua:
một hệ thống xử lý phía sau đủ mạnh để 24 cổng đó thực sự hoạt động đúng với khả năng của chúng.
Nhưng đến đây sẽ xuất hiện một vấn đề khác.
Giả sử một Server đang gửi dữ liệu với tốc độ 10Gbps, nhưng dữ liệu lại phải đi ra một cổng kết nối tới Client chỉ có tốc độ 1Gbps.
ASIC có thể xử lý dữ liệu rất nhanh.
Nhưng cổng đầu ra lại không thể truyền dữ liệu nhanh hơn 1Gbps.
Vậy lượng dữ liệu dư thừa sẽ đi đâu?
Bị loại bỏ ngay lập tức?
Hay Switch có một nơi nào đó để tạm thời giữ chúng lại?
Đó chính là lúc RAM và Packet Buffer bước vào cuộc chơi.
Hẹn anh em ở Phần 2: Packet Buffer là gì và tại sao nó lại ảnh hưởng trực tiếp đến khả năng chịu tải của một chiếc Switch?

65.535 cổng, nhưng chỉ vài chục cổng này quyết định mạng của bạn an toàn hay không

dungabx — Sat, 29 Aug 2026 11:13:08 GMT

Ngay lúc này, rất nhiều hệ thống nội bộ vẫn đang mở cổng 23 (Telnet) hoặc cổng 21 (FTP) - hai giao thức truyền dữ liệu dưới dạng văn bản thuần, ai chặn được gói tin trên đường truyền là đọc được mật khẩu ngay lập tức. Phần lớn quản trị viên biết điều này, nhưng không phải ai cũng nhớ chính xác vì sao, và giao thức nào mới thật sự an toàn để thay thế.

Toàn bộ câu chuyện cổng và giao thức nằm trong bộ TCP/IP - thứ khác hẳn với mô hình OSI. OSI chỉ là khuôn lý thuyết để tham chiếu, còn TCP/IP là ngăn xếp giao thức thật sự đang chạy trên mọi thiết bị. TCP/IP rút gọn 7 tầng OSI xuống còn 4 tầng: Application (gộp cả Application, Presentation, Session của OSI), Transport, Internet (tương đương Network) và Network Access (gộp Data Link với Physical). Ít tầng hơn không có nghĩa là đơn giản hơn, chỉ là cách tổ chức khác đi để triển khai thực tế.

Trong 4 tầng đó, khái niệm quan trọng nhất với người mới là port. Địa chỉ IP xác định đúng máy chủ, nhưng chính port mới xác định đúng ứng dụng nào trên máy chủ đó đang xử lý dữ liệu. Có tổng cộng 65.535 port, chia thành 3 dải: well-known (0-1023) dành cho các dịch vụ hệ thống cốt lõi, registered (1024-49151) cho các phần mềm thương mại đăng ký với IANA, và dynamic/private (49152-65535) được hệ thống gán ngẫu nhiên cho mỗi phiên kết nối tạm thời.

Ở tầng Transport, TCP và UDP đại diện cho hai triết lý trái ngược hoàn toàn. TCP hướng kết nối, gán số thứ tự cho từng gói, yêu cầu bên nhận gửi ACK xác nhận, tự động truyền lại nếu gói bị lỗi hoặc mất, đồng thời có flow control để tránh bên gửi tốc độ cao làm ngộp bên nhận yếu hơn - đổi lại là độ trễ tăng lên vì phải bắt tay và xác nhận liên tục. UDP thì ngược lại hoàn toàn: không bắt tay, không xác nhận, không sắp xếp lại thứ tự, gửi xong là xong theo kiểu best-effort. Hao phí cực thấp nên UDP là lựa chọn gần như duy nhất cho video call, VoIP hay streaming, những nơi mà một gói bị rớt còn chấp nhận được hơn là độ trễ tích tụ.

Ở tầng Internet, ngoài IP lo việc định địa chỉ và định tuyến, còn có bốn giao thức hỗ trợ ít được nhắc đến nhưng chạy nền liên tục. ICMP không dùng port mà dùng type và code để báo lỗi kết nối - lệnh ping quen thuộc chính là ICMP Echo Request (type 8) và Echo Reply (type 0). ARP làm nhiệm vụ dịch từ IP sang MAC trong cùng một LAN, còn RARP làm ngược lại. IGMP quản lý các nhóm multicast trên IPv4, và được thay thế bằng MLD khi chuyển sang IPv6.

Phần hay bị học vẹt nhất chính là danh sách cổng ở tầng Application, nhưng nhìn theo từng nhóm chức năng sẽ dễ nhớ hơn nhiều thay vì học rời rạc từng dòng.

Nhóm truyền file: FTP dùng cổng 20 để truyền dữ liệu và 21 để gửi lệnh, chạy trên TCP nhưng hoàn toàn plain-text nên dễ bị nghe lén. TFTP dùng UDP ở cổng 69, nhanh và gọn nhưng không xác thực, thường chỉ dùng nội bộ để backup cấu hình router hay đẩy firmware.

Nhóm truy cập từ xa: Telnet ở cổng 23 truyền không mã hóa, gần như bị xem là lỗ hổng nếu còn bật trong mạng doanh nghiệp hiện đại. SSH ở cổng 22 làm đúng công việc tương tự nhưng mã hóa toàn bộ phiên làm việc, nên gần như đã thay thế Telnet hoàn toàn. RDP ở cổng 3389 phục vụ điều khiển máy tính từ xa qua giao diện đồ họa, đặc trưng của hệ sinh thái Windows.

Nhóm email có ba giao thức dễ nhầm vai trò với nhau: SMTP (25, hoặc 587 khi có TLS) lo việc chuyển tiếp email giữa các máy chủ. POP3 (110, hoặc 995 khi mã hóa) tải email về máy và mặc định xóa trên server. IMAP (143, hoặc 993 khi mã hóa) thì ngược lại, quản lý email ngay trên server để đồng bộ giữa nhiều thiết bị mà không cần tải hẳn về.

Nhóm hạ tầng nền: DNS (cổng 53, cả TCP lẫn UDP) dịch tên miền thành IP. DHCP (67 và 68, UDP) tự động cấp IP qua tiến trình DORA. NTP (123, UDP) đồng bộ thời gian giữa các thiết bị. SNMP (161, 162, UDP) giám sát tình trạng thiết bị mạng từ xa. LDAP (389, hoặc 636 khi có LDAPS) xác thực người dùng qua thư mục tập trung kiểu Active Directory. Syslog (514) gom log từ nhiều thiết bị về một nơi để dễ theo dõi và điều tra sự cố.

Nhóm còn lại: HTTP (80) và HTTPS (443) cho truy cập web, với HTTPS mã hóa toàn bộ bằng TLS còn HTTP thì để lộ hết. SMB (445) chia sẻ file và máy in trong mạng Windows. SIP (5060, 5061) làm nhiệm vụ báo hiệu để thiết lập và kết thúc các cuộc gọi VoIP hay hội nghị truyền hình.

Nhìn xuyên suốt danh sách này sẽ thấy một mẫu số chung: gần như mọi giao thức cũ chạy plain-text đều có một phiên bản mã hóa đi kèm ra đời sau để thay thế - FTP có SFTP, Telnet có SSH, HTTP có HTTPS, POP3/IMAP/LDAP đều có cổng riêng chạy TLS. Việc của người quản trị mạng không phải là nhớ hết 65.535 cổng, mà là biết chính xác cổng nào trong hệ thống của mình đang mở ở dạng không mã hóa và nên đóng lại từ khi nào.

Trong hệ thống bạn đang quản lý, còn cổng plain-text nào (Telnet, FTP, HTTP nội bộ...) vẫn đang mở mà chưa kịp thay thế không? Chia sẻ để anh em cùng rà soát lại nhé.