Vietnamese Professional - Cyber Security

Cấu hình router như là DHCP server

dangquangminh — Sun, 31 May 2026 02:08:50 GMT

Một router không chỉ biết định tuyến. Trong nhiều mô hình nhỏ, lab CCNA/CCNP hoặc chi nhánh doanh nghiệp, router và multilayer switch còn có thể đóng vai trò như một DHCP Server thực thụ.

Trong ví dụ này, router R1 cấp phát địa chỉ IP cho các DHCP client trong mạng 10.8.8.0/24. Câu lệnh:

ip dhcp excluded-address 10.8.8.1 10.8.8.10

dùng để loại trừ dải địa chỉ từ 10.8.8.1 đến 10.8.8.10, nghĩa là DHCP Server sẽ không cấp các địa chỉ này cho client. Thông thường, dải này được giữ lại cho gateway, server, printer, switch management hoặc các thiết bị cần IP tĩnh.

Một điểm khá hay: ta không bắt buộc phải exclude IP của chính interface router, vì router sẽ không bao giờ tự cấp phát địa chỉ IP đang được gán trên interface của nó cho DHCP client.

Cấu hình DHCP pool như sau:

ip dhcp pool POOL-A
network 10.8.8.0 255.255.255.0
default-router 10.8.8.1
dns-server 192.168.1.1
netbios-name-server 192.168.1.2

Ở đây, POOL-A là tên của DHCP pool. Router sẽ cấp địa chỉ thuộc mạng 10.8.8.0/24, gán default gateway là 10.8.8.1, DNS Server là 192.168.1.1 và WINS Server là 192.168.1.2.

Trong quá trình troubleshooting, nếu máy Windows được cấu hình nhận IP bằng DHCP nhưng lại nhận địa chỉ dạng 169.254.x.x, đây là APIPA – Automatic Private IP Addressing. Điều này cho thấy client không nhận được IP từ DHCP Server.

Ví dụ trên PC:

Autoconfiguration IP Address: 169.254.180.166
Subnet Mask: 255.255.0.0
DHCP Enabled: Yes

Tuy nhiên, đừng vội kết luận “DHCP Server bị lỗi”. Trong thực tế, DHCP chỉ là phần nổi của tảng băng. Gói DHCPDISCOVER của client có thể đã không đến được DHCP Server vì lỗi Layer 2 như sai VLAN, trunk không cho VLAN đi qua, STP blocking, port-security, DHCP snooping, hoặc cấu hình switchport sai.

Kinh nghiệm thực chiến: khi thấy client nhận IP 169.254.x.x, hãy kiểm tra theo thứ tự từ dưới lên. Trước tiên kiểm tra link, VLAN, trunk, STP và security feature. Sau đó mới kiểm tra DHCP pool, excluded-address, default-router, DNS server và trạng thái dịch vụ DHCP trên router.

Cấu hình router như DHCP Client

dangquangminh — Fri, 29 May 2026 11:45:18 GMT

Router Cisco cũng có thể "xin IP" như một chiếc PC!

Khi nhắc đến DHCP, đa số chúng ta thường nghĩ đến laptop, PC, điện thoại hoặc máy chủ là những thiết bị nhận IP từ DHCP Server. Tuy nhiên, có một điều mà nhiều bạn CCNA mới học thường bất ngờ Router Cisco cũng có thể hoạt động như một DHCP Client.
Nói cách khác, một interface của router hoàn toàn có thể tự động nhận địa chỉ IP từ DHCP Server thay vì phải cấu hình địa chỉ IP tĩnh bằng tay. Ví dụ rất phổ biến trong thực tế là kết nối Internet của doanh nghiệp nhỏ hoặc hộ gia đình. Cổng WAN của router thường kết nối đến modem hoặc thiết bị của ISP. Nhà cung cấp dịch vụ sẽ cấp phát IP động cho router thông qua DHCP. Quá trình này diễn ra hoàn toàn giống như trên một máy tính:

Router gửi DHCP Discover

DHCP Server gửi DHCP Offer

Router gửi DHCP Request

DHCP Server gửi DHCP ACK

Đây chính là quy trình DORA quen thuộc mà chúng ta đã học trong các bài trước. Ví dụ:
Router R1 <----> DHCP Server

DHCP Discover
DHCP Offer
DHCP Request
DHCP ACK
Sau khi hoàn tất quá trình này, interface của router sẽ nhận được:

Địa chỉ IP Address

Subnet Mask

Default Gateway (nếu được cung cấp)

DNS Server (nếu được cung cấp)

Trên Cisco IOS, cấu hình router để xin địa chỉ IP cực kỳ đơn giản:
R1(config)# interface fa0/1
R1(config-if)# ip address dhcp
Chỉ với một lệnh duy nhất ip address dhcp, router sẽ tự động gửi yêu cầu DHCP và nhận địa chỉ IP từ DHCP Server. Để kiểm tra địa chỉ IP đã nhận được, chúng ta có thể sử dụng lệnh show ip interface brief Hoặc show dhcp lease
Ví dụ kết quả:
Interface IP Address Status
Fa0/1 203.0.113.10 up
Trong môi trường thực tế, bạn sẽ gặp cấu hình này rất thường xuyên trên Router kết nối Internet từ ISP, Router chi nhánh (Branch Router), Thiết bị SD-WAN Edge, Thiết bị lab trong GNS3, CML hoặc EVE-NG, Router triển khai tạm thời trong các dự án. Một điểm cần lưu ý là vì địa chỉ IP được cấp động nên địa chỉ có thể thay đổi khi lease hết hạn hoặc khi router khởi động lại. Do đó, các dịch vụ yêu cầu IP cố định thường sẽ sử dụng địa chỉ tĩnh hoặc DHCP Reservation trên DHCP Server. Đối với các bạn đang theo học CCNA, hãy nhớ rằng DHCP không chỉ cấp phát IP cho PC. Router, firewall, access point, IP phone, camera IP và rất nhiều thiết bị mạng khác cũng có thể trở thành DHCP Client. Đây là một kiến thức nhỏ nhưng xuất hiện khá thường xuyên trong các bài lab và tình huống troubleshooting thực tế.

Vì sao thiết bị gửi gói tin sai hướng?

dangquangminh — Wed, 27 May 2026 11:42:34 GMT

IPv4 Troubleshooting: Vì sao thiết bị gửi packet sai hướng?

Một lỗi về địa chỉ IPv4 rất nhỏ có thể làm cả quá trình truyền dữ liệu đi sai hướng. Nhiều bạn khi học CCNA thường nghĩ rằng “miễn IP ping được là được”, nhưng thực tế trước khi một gói tin được gửi đi, máy tính phải tự trả lời một câu hỏi cực kỳ quan trọng: “Địa chỉ đích có nằm cùng subnet với mình hay không?”
Một địa chỉ IPv4 luôn gồm hai phần: phần network/subnet và phần host. Các thiết bị nằm trong cùng một subnet bắt buộc phải có cùng phần network/subnet. Nếu phần này không khớp, máy tính có thể đóng gói frame Layer 2 sai cách, dẫn đến việc gửi packet về sai hướng.
Ví dụ, ta có mạng 10.1.1.0/26. PC1 có địa chỉ 10.1.1.10, subnet mask 255.255.255.192, default gateway là 10.1.1.1. PC2 có địa chỉ 10.1.1.20, cùng subnet mask 255.255.255.192 và cũng dùng default gateway 10.1.1.1. Router R1 đóng vai trò default gateway cho subnet này.
Khi PC1 muốn giao tiếp với PC2, trước tiên PC1 cần biết địa chỉ IP của PC2, ví dụ thông qua DNS. DNS trả về địa chỉ 10.1.1.20. Lúc này PC1 chưa vội gửi gói tin ngay, mà nó phải kiểm tra xem PC2 có nằm cùng subnet với mình hay không. Kết quả kiểm tra này sẽ quyết định frame Layer 2 sẽ dùng MAC address của PC2 hay MAC address của default gateway.
PC1 lấy địa chỉ IP của mình là 10.1.1.10 và so sánh với subnet mask 255.255.255.192 ở dạng nhị phân:
10.1.1.10 được biểu diễn là:
00001010.00000001.00000001.00001010
Subnet mask /26, tức 255.255.255.192, được biểu diễn là:
11111111.11111111.11111111.11000000
Các bit 1 trong subnet mask xác định phần network/subnet. Khi PC1 thực hiện phép so sánh, nó xác định được network/subnet ID của mình là:
00001010.00000001.00000001.00
Sau đó PC1 so sánh phần network/subnet này với địa chỉ của PC2. Địa chỉ 10.1.1.20 cũng có cùng phần đầu:
00001010.00000001.00000001.00
Vì các bit phần network/subnet giống nhau, PC1 kết luận rằng PC2 nằm cùng subnet. Do đó, PC1 không cần gửi dữ liệu đến default gateway. Thay vào đó, PC1 sẽ gửi trực tiếp đến PC2. Frame Layer 2 sẽ có source MAC là MAC của PC1 và destination MAC là MAC của PC2.
Nói một cách đơn giản hơn nhé: nếu cùng subnet, máy tính sẽ tìm địa chỉ MAC của máy đích rồi gửi trực tiếp trong LAN.
Bây giờ chúng ta sẽ xét tình huống khác. PC1 muốn truy cập web server có địa chỉ 192.0.2.1. Sau khi DNS trả về địa chỉ IP này, PC1 lại tiếp tục kiểm tra xem 192.0.2.1 có cùng subnet với mình không.
PC1 vẫn có network/subnet ID là:
00001010.00000001.00000001.00
Trong khi đó, địa chỉ 192.0.2.1 ở dạng nhị phân bắt đầu bằng:
11000000.00000000.00000010.00
Rõ ràng các bit network/subnet không giống nhau. Vì vậy PC1 kết luận rằng web server nằm ở một subnet khác. Khi địa chỉ đích nằm ngoài subnet của máy nguồn, PC1 không thể gửi trực tiếp đến web server ở Layer 2. Thay vào đó, PC1 phải gửi packet đến default gateway, tức router gateway là R1.
Lúc này frame Layer 2 sẽ có source MAC là MAC của PC1, còn destination MAC là MAC của R1. Tuy nhiên, bên trong frame đó, packet Layer 3 vẫn giữ source IP là 10.1.1.10 và destination IP là 192.0.2.1. Đây là điểm rất quan trọng: MAC address thay đổi theo từng chặng Layer 2, nhưng IP source/destination vẫn đại diện cho hai đầu cuối giao tiếp.
Đây cũng là lý do khi troubleshooting IPv4 addressing, chúng ta phải kiểm tra rất kỹ IP address, subnet mask và default gateway. Chỉ cần subnet mask sai, PC có thể nghĩ rằng một địa chỉ nằm cùng subnet trong khi thực tế không phải, hoặc ngược lại. Kết quả là ARP sai, frame gửi sai MAC, packet không đi đúng hướng và người quản trị sẽ thấy các lỗi kiểu “ping không được dù IP nhìn có vẻ đúng”.
Trong thực tế, khi một PC không truy cập được server, đừng chỉ kiểm tra địa chỉ IP address. Hãy kiểm tra đủ bộ ba combo thông tin: IP address, subnet mask và default gateway. Sau đó chúng ta hãy tự hỏi: “Máy đích có cùng subnet không?” Nếu cùng subnet, thiết bị sẽ ARP để tìm MAC của máy đích. Nếu khác subnet, thiết bị sẽ ARP để tìm MAC của default gateway.
Hiểu được logic này là nền tảng rất quan trọng trước khi học sâu hơn về routing, VLAN, SVI, default gateway, ARP và troubleshooting mạng doanh nghiệp.

Các vấn đề bảo mật khi triển khai AI

dangquangminh — Mon, 25 May 2026 00:50:10 GMT

Một vấn đề rất thực tế khi doanh nghiệp triển khai Generative AI: AI không chỉ là một ứng dụng mới, mà là một bề mặt tấn công (attack surface) hoàn toàn mới.

Generative AI khác với phần mềm truyền thống ở chỗ nó non-deterministic — cùng một câu hỏi nhưng có thể sinh ra kết quả khác nhau. Điều này khiến việc kiểm thử, kiểm soát và dự đoán hành vi trở nên khó hơn rất nhiều. Nếu nhìn theo stack, rủi ro không chỉ nằm ở model mà trải dài từ Users → Applications → Models → Data → Infrastructure.

Ở tầng người dùng, rủi ro đến từ prompt injection, lộ dữ liệu nhạy cảm khi nhân viên copy dữ liệu nội bộ vào chatbot, hoặc lạm dụng AI ngoài chính sách công ty. Ở tầng ứng dụng, AI agent có thể gọi API, truy cập hệ thống backend hoặc thực hiện action không mong muốn nếu bị thao túng.

Model tạo ra một new risk vector vì đây là thành phần mới mà đội security truyền thống chưa quen bảo vệ. Model có thể hallucinate, bị jailbreak, model poisoning, hoặc bị đánh cắp thông qua API abuse.

Dữ liệu là khu vực cực kỳ nhạy cảm. Nếu training data, vector database, RAG repository hoặc prompt history không được bảo vệ tốt, nguy cơ rò rỉ thông tin doanh nghiệp là rất lớn.

Hạ tầng AI cũng mang rủi ro riêng: insecure API endpoint, container vulnerabilities, supply chain attacks từ open-source model/package, GPU cluster exposure, hoặc lateral movement trong AI infrastructure.

Kết quả cuối cùng là 5 nhóm tác động lớn mà slide bên phải nhấn mạnh: thiệt hại uy tín doanh nghiệp, mất an toàn dữ liệu và quyền riêng tư, rủi ro chuỗi cung ứng, tấn công mạng, và vi phạm tuân thủ (compliance).

Suy cho cùng, AI không chỉ là bài toán về độ thông minh của model. AI là bài toán tổng thể của cybersecurity, governance và enterprise architecture.

IP Souce Guard

dangquangminh — Sun, 24 May 2026 03:26:54 GMT

[Ôn tập ccna 200-301] IP Source Guard: Lớp phòng thủ cuối cùng chống IP Spoofing trong mạng LAN Cisco

Nếu bạn theo dõi FB group của chúng ta các ngày qua, bạn đã có:

DHCP Snooping → chặn DHCP server giả

Dynamic ARP Inspection (DAI) → chặn ARP spoofing

Nhưng vẫn còn một lỗ hổng khác. Một máy nội bộ hoàn toàn có thể tự đổi địa chỉ IP thủ công để giả danh thiết bị khác. Ví dụ:

đổi IP thành default gateway

đổi IP thành server nội bộ

đổi IP thành IP của user khác

vượt qua policy dựa trên IP

Đây gọi là giả mạo địa chỉ IP - IP Spoofing Và đây là lý do Cisco có tính năng IP Source Guard (IPSG) trên các dòng switch của họ.

Vậy, IP Source Guard là gì?

IP Source Guard là tính năng bảo mật Layer 2 giúp switch kiểm tra: “Thiết bị ở cổng này có được phép dùng địa chỉ IP này không?” Nếu địa chỉ không đúng? Switch drop traffic ngay từ access port. "Nói đơn giản là cho rớt ngay từ vòng gửi xe". DHCP Snooping kiểm tra lúc cấp IP. DAI kiểm tra ARP. IP Source Guard kiểm tra traffic data thật sự.

Vấn đề IP Spoofing

Ví dụ mạng:
PC hợp lệ: 10.1.1.10
Gateway: 10.1.1.1
Server: 10.1.1.100
Attacker đổi IP:
10.1.1.100
hoặc:
10.1.1.1
Switch Layer 2 bình thường không quan tâm. Chỉ thấy frame đi qua.
Hậu quả:

bypass ACL

giả mạo trusted host

chiếm session

gây conflict IP

phá network

IP Source Guard hoạt động thế nào?

Tính năng IPSource Guard lúc này sẽ dựa vào bảng DHCP Snooping Binding Table của DHCP Snooping.
Ví dụ:
MAC: 08:00:27:5D:06:D6
IP: 10.1.1.10
VLAN: 10
Port: Fa0/1
Switch sẽ hiểu các thông tin trên như sau:
"Fa0/1 chỉ được phép gửi traffic với source IP 10.1.1.10"
Nếu Fa0/1 gửi:
source IP = 10.1.1.10
→ cho qua
Nếu gửi:
source IP = 10.1.1.99
→ switch sẽ drop gói tin, vì nó cho là gói tin này giả mạo địa chỉ IP source.

IPSG phụ thuộc vào DHCP Snooping

Điểm rất quan trọng mà chúng ta nhận thấy là nếu không có DHCP Snooping binding thì IPSG không biết IP hợp lệ là gì. Kết quả là switch có thể deny all mọi traffic. Đây là lỗi rất hay gặp khi troubleshooting.

Lab cấu hình cơ bản

1. Bật DHCP Snooping

ip dhcp snooping
ip dhcp snooping vlan 10
no ip dhcp snooping information option

2. Trust uplink

interface GigabitEthernet0/1
ip dhcp snooping trust

interface GigabitEthernet0/2
ip dhcp snooping trust

3. Bật IP Source Guard trên access port

Ví dụ:
interface FastEthernet0/1
ip verify source
Đây là lệnh kích hoạt IPSG.

Cấu hình hoàn chỉnh

ip dhcp snooping
ip dhcp snooping vlan 10
no ip dhcp snooping information option

interface FastEthernet0/1
ip verify source

interface GigabitEthernet0/1
ip dhcp snooping trust

interface GigabitEthernet0/2
ip dhcp snooping trust Kiểm tra IPSG

Các bạn hãy dùng lệnh sau:
show ip verify source
Sau đây là ví dụ cụ thể:
Interface Filter-type Filter-mode IP-address Mac-address VLAN
Fa0/1 ip active 10.1.1.10 10
Điều này có nghĩa là:

IPSG đang active

Fa0/1 chỉ cho phép source IP: 10.1.1.10

Chế độ chỉ kiểm tra IP

Lệnh ip verify source được dùng chỉ kiểm tra:
source IP, nó không kiểm tra MAC.
Ví dụ:
Nếu attacker vẫn dùng:
10.1.1.10
nhưng MAC khác?
Switch vẫn có thể cho qua.
Đây là mức bảo vệ cơ bản.

Kiểm tra cả IP + MAC

Nếu chúng ta muốn kiểm tra chặt hơn:
ip verify source port-security
Lúc này switch kiểm tra:

source IP

source MAC

Ví dụ:
Fa0/1 ip-mac active 10.1.1.10 08:00:27:5D:06:D6
Nghĩa là:
Chỉ đúng cặp:
10.1.1.10 + 08:00:27:5D:06:D6
mới được phép.

Vì sao cần Port Security?

Khi dùng lệnh ip verify source port-security, Switch cần biết MAC hợp lệ là MAC nào. Thông tin này đến từ tính năng Port Security của switch. Nếu Port Security không bật thì Switch không khóa địa chỉ MAC cụ thể. Kết quả sẽ là switch cho phép tất cả traffic đi qua (permit-all).
Ví dụ:
Fa0/2 ip-mac active 10.1.1.20 permit-all
Nghĩa là:
IP bị kiểm soát nhưng MAC nào cũng được. Hiệu quả bảo vệ giảm mạnh.

Lỗi phổ biến: deny-all

Ví dụ:
Fa0/2 ip-mac active deny-all permit-all
Điều này rất quan trọng.
Nghĩa là:
Switch block toàn bộ traffic inbound.
Tại sao?
Vì interface bật IPSG nhưng không có DHCP binding.
Ví dụ:
Thiết bị dùng static IP:
10.1.1.20
DHCP Snooping database:
show ip dhcp snooping binding
chỉ có:
10.1.1.10
cho Fa0/1.
Không có binding cho Fa0/2.
Switch kết luận:
"Tôi không biết IP hợp lệ ở Fa0/2 là gì"
=> deny all

Case thực tế

Một admin bật IPSource Guard cho toàn bộ access ports. Ngay sau đó:

printer mất mạng

camera IP mất kết nối

server không ping được

Switch show: deny-all
Nguyên nhân: Toàn bộ thiết bị đó dùng static IP. Không có DHCP Snooping binding. Giải pháp cho tình huống này là:

bỏ IPSG trên static devices
hoặc

dùng static bindings phù hợp
hoặc

thiết kế policy khác

Troubleshooting checklist

DHCP Snooping bật chưa?

show ip dhcp snooping

Có binding không?

show ip dhcp snooping binding

IPSG bật chưa?

show ip verify source

Thiết bị dùng DHCP hay static?

Static + IPSG = lỗi rất thường gặp.

Có bật Port Security nếu dùng ip-mac?

Nếu không permit-all

Bộ ba bảo mật Layer 2

Cisco access security thường đi theo combo:
DHCP Snooping → chống rogue DHCP
Dynamic ARP Inspection → chống ARP poisoning
IP Source Guard → chống IP spoofing
Ba lớp này phối hợp rất mạnh và cần lẫn nhau để hoạt động.

TÓM TẮT

Nếu DHCP Snooping là người phát thẻ ra vào…DAI là bảo vệ kiểm tra danh tính… thì IP Source Guard là cổng kiểm soát cuối cùng, chỉ cho đúng người dùng đúng danh tính đi qua. Đây là một trong những kỹ thuật security nền tảng mà CCNP/CCIE và mạng enterprise thực tế đều nên nắm vững chắc (phải làm lab để thử nha).

DHCP Snooping

dangquangminh — Fri, 22 May 2026 11:31:03 GMT

DHCP Snooping trên Cisco: “Người gác cổng” chống DHCP giả mạo trong mạng LAN

Một trong những kiểu tấn công đơn giản nhưng cực kỳ nguy hiểm trong mạng nội bộ là Rogue DHCP Server Attack. Chỉ cần ai đó cắm một router Wi-Fi mini, một máy Linux chạy dnsmasq, hoặc thậm chí một laptop bật DHCP service vào switch, toàn bộ client trong mạng có thể nhận IP sai.

Kết quả?

Client có thể bị cấp:

Default gateway giả → toàn bộ traffic đi qua máy của attacker (Man-in-the-Middle)
DNS giả mạo → chuyển hướng người dùng đến website độc hại
IP sai subnet → mất kết nối hoàn toàn
Lease bất thường → gây gián đoạn dịch vụ

Trong mạng doanh nghiệp, đây là lý do DHCP Snooping tồn tại.

DHCP Snooping là gì?

DHCP Snooping là một tính năng bảo mật Layer 2 trên switch Cisco dùng để kiểm soát các gói DHCP hợp lệ trong mạng.

Ý tưởng rất đơn giản:

Switch sẽ phân biệt 2 loại cổng:

Trusted Port

Được phép nhận và gửi mọi loại DHCP message
Thường là uplink về DHCP server hoặc DHCP relay

Untrusted Port

Chỉ được phép gửi DHCP request từ client
Không được phép gửi DHCP offer/ack như DHCP server

Nếu một thiết bị lạ cố đóng vai DHCP server trên cổng untrusted?

Switch sẽ chặn ngay.

DHCP hoạt động bình thường như thế nào?

Quá trình DHCP gồm 4 bước quen thuộc:

DORA

Discover
Offer
Request
Acknowledge

Ví dụ:

PC mới cắm vào switch:

Bước 1
PC gửi:
DHCP Discover

broadcast để tìm DHCP server.

Bước 2
DHCP server trả lời:
DHCP Offer

đề xuất địa chỉ IP.

Bước 3
PC gửi:
DHCP Request

xin dùng địa chỉ đó.

Bước 4
Server xác nhận:
DHCP ACK

DHCP Snooping kiểm soát điều gì?

Trên switch:

Client-facing port → untrusted
Uplink tới DHCP server → trusted

Luật hoạt động:

Untrusted port chỉ được gửi

Discover
Request

Untrusted port KHÔNG được gửi

Offer
ACK
NAK

Điều này ngăn client giả mạo DHCP server.

DHCP Snooping Binding Table

Ngoài việc chặn DHCP giả, switch còn tạo ra một bảng gọi là:

DHCP Snooping Binding Database

Bảng này lưu:

MAC Address
IP Address
VLAN
Interface
Lease time

Ví dụ:
MAC: 08:00:27:5D:06:D6
IP: 10.1.1.10
VLAN: 10
Port: FastEthernet0/1
Lease: 67720 seconds

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

Switch biết chính xác:

Máy MAC này đang nằm ở cổng này và được cấp IP này hợp lệ.

Cực kỳ quan trọng.

Vì các tính năng khác sẽ dùng bảng này:

Dynamic ARP Inspection (DAI)
IP Source Guard

Cấu hình DHCP Snooping

1. Bật DHCP Snooping toàn cục

ip dhcp snooping

Nếu không có lệnh này thì mọi cấu hình khác vô nghĩa.

2. Bật trên VLAN cần bảo vệ

Ví dụ VLAN 10:
ip dhcp snooping vlan 10

DHCP Snooping không tự áp dụng cho toàn bộ VLAN.

3. Đánh dấu trusted port

Ví dụ uplink tới DHCP server:
interface GigabitEthernet0/1
ip dhcp snooping trust

Nếu có thêm uplink:
interface GigabitEthernet0/2
ip dhcp snooping trust

4. Các port access để mặc định untrusted

Mặc định:
untrusted

Không cần cấu hình gì thêm.

Đây là điểm hay.

Option 82 là gì?

Switch có thể chèn thêm thông tin:

DHCP Option 82

Đây là Relay Agent Information.

Giúp DHCP server biết:

request đến từ switch nào
port nào
VLAN nào

Ví dụ:

circuit-id
remote-id

Rất hữu ích trong mạng campus lớn.

Nhưng…

Không phải DHCP server nào cũng hỗ trợ.

Nếu server không hiểu Option 82, DHCP có thể fail.

Khi đó:
no ip dhcp snooping information option

Cấu hình hoàn chỉnh

ip dhcp snooping
ip dhcp snooping vlan 10
no ip dhcp snooping information option

interface GigabitEthernet0/1
ip dhcp snooping trust

interface GigabitEthernet0/2
ip dhcp snooping trust

Kiểm tra DHCP Snooping

Kiểm tra trạng thái

show ip dhcp snooping

Ví dụ:
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
10

DHCP snooping is operational on following VLANs:
10

Insertion of option 82 is disabled

Xác nhận:

feature đã bật
VLAN hoạt động
Option 82 trạng thái gì

Kiểm tra trusted interface

Ví dụ:
Interface Trusted
Gi0/1 yes
Gi0/2 yes

Các port không xuất hiện mặc định là:
untrusted

Kiểm tra Binding Table

show ip dhcp snooping binding

Ví dụ:
08:00:27:5D:06:D6
10.1.1.10
VLAN 10
FastEthernet0/1

Switch xác nhận:

MAC này hợp lệ
IP này được cấp hợp lệ
đang ở đúng port

Case thực tế

Một doanh nghiệp gặp hiện tượng:

user lúc vào được mạng
lúc không
DNS bị đổi
login portal nội bộ bị redirect sai

Kiểm tra phát hiện:

Một nhân viên mang router Wi-Fi gia đình tới cắm vào switch.

Router này bật DHCP server mặc định.

Hệ quả:

Một số máy nhận IP từ DHCP chính thức.

Một số máy nhận IP từ router rogue.

Giải pháp:

Bật DHCP Snooping.

uplink = trusted
access port = untrusted

Ngay lập tức rogue DHCP bị block.

Best Practice thực chiến

Không trust bừa.

Chỉ trust:

uplink tới DHCP server
uplink tới DHCP relay path

Không trust:

user ports
printer ports
IP phone ports
conference room ports

Kết hợp thêm:

DHCP Snooping
Dynamic ARP Inspection
IP Source Guard

Đây là bộ ba bảo mật Layer 2 cực kỳ mạnh.

DHCP là dịch vụ tiện lợi. Nhưng nếu không kiểm soát, nó cũng là cửa ngõ cho tấn công nội bộ. DHCP Snooping biến switch từ thiết bị chuyển frame đơn thuần thành một security enforcement point ở Layer 2. Nếu bạn đang vận hành mạng campus, enterprise access layer, hoặc lab CCNP/CCIE, đây là tính năng nên bật.

Tính năng Spanning Tree Port Fast

dangquangminh — Thu, 21 May 2026 13:10:33 GMT

PortFast trên Cisco Switch: Tăng tốc hội tụ STP nhưng phải dùng đúng chỗ!

Nếu bạn từng cắm một PC vào switch Cisco và thấy mất vài chục giây mới ping được gateway, thì thủ phạm rất có thể là Spanning Tree Protocol (STP). Đây chính là lúc PortFast phát huy tác dụng.

PortFast là gì?

PortFast là tính năng của Cisco cho phép một switchport chuyển ngay sang trạng thái Forwarding ngay khi interface được bật lên, thay vì phải đi qua các giai đoạn STP thông thường như Listening và Learning. Điều này cực kỳ hữu ích cho các thiết bị đầu cuối như:

PC
Laptop
Printer
IP Phone
Server (single-homed)

Ví dụ, khi một người dùng cắm laptop vào cổng access switch:

Khi không dùng PortFast

Switch chờ STP hội tụ
Mất khoảng 30 giây
DHCP request có thể timeout
User than phiền: "Mạng bị lỗi rồi!"

Khi có dùng PortFast

Port lên Forwarding gần như ngay lập tức
DHCP hoạt động ngay
Trải nghiệm người dùng tốt hơn nhiều

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

Khi bật PortFast, Switch bỏ qua quy trình STP thông thường và đưa cổng vào trạng thái forwarding ngay. Tuy nhiên có một cơ chế bảo vệ rất quan trọng. Nếu switch nhận được BPDU trên cổng PortFast:

Cổng sẽ thoát khỏi chế độ PortFast
Quay trở lại hoạt động như một cổng STP bình thường
Đi qua đầy đủ các bước xử lý STP

Mục tiêu là tránh việc tạo ra loop lớp 2 nếu ai đó vô tình cắm switch vào cổng vốn dành cho end-user.

Cấu hình PortFast

Bật trên từng interface

interface FastEthernet0/1
switchport access vlan 10
switchport mode access
spanning-tree portfast

Cách này phù hợp khi bạn muốn kiểm soát chính xác từng port.

Bật toàn cục

spanning-tree portfast default

Lệnh này sẽ bật PortFast cho tất cả các non-trunk access port.

Rất hữu ích trong môi trường campus có nhiều access switch.

Kiểm tra PortFast

1. Kiểm tra running config

show run interface fa0/1

Ví dụ:
interface FastEthernet0/1
switchport access vlan 10
switchport mode access
spanning-tree portfast

Nếu thấy dòng:
spanning-tree portfast

=> PortFast được cấu hình trực tiếp.

2. Kiểm tra riêng trạng thái PortFast

show spanning-tree interface fastEthernet 0/1 portfast

Output:
VLAN0010 enabled

Điều này xác nhận PortFast đang hoạt động trên VLAN đó.

3. Xem chi tiết interface STP

show spanning-tree interface fastEthernet 0/1 detail

Ví dụ:
The port is in the portfast mode

Nếu bật PortFast toàn cục:
The port is in the portfast mode by default

Khác biệt này rất quan trọng khi troubleshooting.

portfast mode → cấu hình trực tiếp
portfast mode by default → do global config

4. Kiểm tra cấu hình toàn cục

show spanning-tree summary

Ví dụ:
Portfast Default is enabled

Ngoài ra còn thấy:
PortFast BPDU Guard Default is disabled
Portfast BPDU Filter Default is disabled

Đây là các tính năng bảo vệ liên quan mà kỹ sư mạng nên để ý.

5. Kiểm tra bằng show spanning-tree

Một cách rất nhanh:
show spanning-tree

Ví dụ:
Interface Role Sts Cost Prio.Nbr Type
Fa0/1 Desg FWD 19 128.1 P2p Edge
Fa0/2 Desg FWD 19 128.2 P2p Edge
Gi0/1 Root FWD 4 128.25 P2p
Gi0/2 Altn BLK 4 128.26 P2p

Điểm cần chú ý: Edge. Nếu thấy Edge, nghĩa là cổng đó đang chạy PortFast. (Edge Port)

Khi nào nên dùng PortFast?

Dùng cho: PC, Laptop, Printer, IP Phone, End-user access ports, Server access ports không kết nối switch khác

Không dùng cho: Uplink giữa switch-switch, Trunk links, Port kết nối bridge/switch khác, Kết nối thiết bị có khả năng tạo Layer 2 loop

Best Practice thực chiến

Trong môi trường enterprise, cấu hình phổ biến là:
spanning-tree portfast default
spanning-tree portfast bpduguard default

Lý do:

PortFast giúp thiết bị đầu cuối lên mạng nhanh
BPDU Guard bảo vệ nếu ai đó cắm switch rogue

Nếu chỉ bật PortFast mà không có BPDU Guard, bạn đang mở cửa cho L2 loop.

Góc nhìn thực tế

PortFast = tối ưu cho edge port, không phải để "hack" STP. STP tồn tại để bảo vệ mạng khỏi L2 loop. PortFast chỉ là cách chúng ta nói với switch. "Tôi chắc chắn đây là cổng nối với end device, cứ forward ngay đi."

DHCP CheckList

dangquangminh — Mon, 18 May 2026 10:33:53 GMT

8 vấn đề tiềm tàng đối với DHCP và 4 cách thu thập thông tin để giải quyết

DHCP là một trong những dịch vụ hạ tầng quan trọng nhất trong mạng doanh nghiệp. Khi DHCP hoạt động bình thường, người dùng gần như không để ý đến nó. Nhưng khi xảy ra sự cố, hậu quả thường rất rõ ràng: máy trạm không lấy được IP, không truy cập được mạng nội bộ, không ra Internet, Access Point không join controller, IP bị trùng, hoặc thậm chí toàn bộ VLAN người dùng bị tê liệt.

Trong quá trình troubleshooting DHCP, việc hiểu đúng các nguyên nhân tiềm tàng sẽ giúp kỹ sư mạng rút ngắn thời gian xử lý sự cố rất nhiều. 1. Router không chuyển tiếp broadcast DHCP

Một trong những nguyên nhân phổ biến nhất là client và DHCP server nằm ở hai subnet khác nhau, nhưng router ở giữa không được cấu hình DHCP Relay Agent.

DHCPDISCOVER ban đầu được client gửi dưới dạng broadcast. Theo mặc định, router không forward broadcast traffic, nên gói tin DHCPDISCOVER sẽ bị chặn lại tại gateway.

Ví dụ:

PC ở VLAN 10: 192.168.10.0/24
DHCP Server ở VLAN 100: 192.168.100.10

Nếu trên interface gateway VLAN 10 không có:
ip helper-address 192.168.100.10

thì client sẽ không bao giờ lấy được IP.

Đây là lỗi rất thường gặp trong môi trường enterprise có segmentation nhiều VLAN.

2. DHCP Pool đã hết địa chỉ IP

DHCP pool không phải vô hạn.

Ví dụ subnet:
192.168.1.0/24

sẽ có tối đa khoảng 254 IP usable.

Nếu:

200 user devices
30 printer
20 camera
15 IP phone

thì pool có thể cạn rất nhanh.

Khi pool hết IP:

client mới sẽ không lấy được IP
request DHCP bị từ chối
người dùng có thể nhận APIPA:

169.254.x.x

Đây là dấu hiệu cực kỳ quen thuộc.

3. Cấu hình DHCP sai

Nhiều sự cố không đến từ mạng mà đến từ chính DHCP server.

Ví dụ cấu hình sai: Sai network range

Khai báo:
10.10.20.0/24

trong khi VLAN thật là:
10.10.10.0/24

Client sẽ nhận IP sai subnet.

Sai default gateway

Khai báo:
default-router 10.10.10.254

nhưng gateway thật:
10.10.10.1

Client lấy IP được nhưng không routing ra ngoài.

Sai DNS

Ví dụ:
8.8.8.8

trong khi nội bộ dùng:
10.10.1.53

Kết quả:

ping IP được
không resolve tên

Người dùng thường báo:

"Mạng chập chờn"

trong khi thực ra là DNS issue do DHCP cấp sai option.

4. Trùng địa chỉ IP (Duplicate IP)

DHCP có thể cấp phát một địa chỉ đang bị thiết bị khác dùng static.

Ví dụ:

DHCP cấp:
192.168.1.50

nhưng một printer đã được set tĩnh:
192.168.1.50

Kết quả:

ARP conflict
packet loss
intermittent connectivity
kết nối lúc được lúc không

Dạng lỗi này rất khó chịu vì thường không fail hoàn toàn.

5. DHCP Redundancy không đồng bộ

Trong enterprise, DHCP thường có HA hoặc redundancy.

Ví dụ:

DHCP Server A
DHCP Server B

Hai server cần đồng bộ lease database hoặc state information.

Nếu quá trình giao tiếp giữa hai DHCP server bị lỗi:

cả hai cùng nghĩ IP còn trống
cùng cấp một địa chỉ cho hai client khác nhau

Kết quả:

IP overlap.

Triệu chứng thường giống:

duplicate IP
ARP instability
user mất kết nối ngẫu nhiên

6. Bản chất “pull” của DHCP

Đây là điểm nhiều người mới dễ hiểu nhầm.

DHCP hoạt động theo mô hình:

Client chủ động yêu cầu thông tin.

Không phải:

Server chủ động ép client đổi IP.

Nghĩa là:

client gửi DHCPDISCOVER
server phản hồi DHCPOFFER

Nhưng nếu admin đổi cấu hình DHCP:

Ví dụ:

đổi DNS
đổi gateway
đổi subnet option

thì các client đang có lease không tự động cập nhật ngay lập tức.

Phải chờ:

lease renewal
hoặc
user release/renew

Ví dụ Windows:
ipconfig /release
ipconfig /renew

7. Router hoặc Layer 3 Switch không có interface thuộc subnet DHCP pool

Nếu router chính là DHCP server, nó phải có interface thuộc subnet mà nó đang cấp phát.

Ví dụ:

DHCP pool:
192.168.20.0/24

nhưng router interfaces:
10.1.1.1
172.16.1.1

Không có interface nào thuộc:
192.168.20.0/24

thì router sẽ không cấp IP cho subnet đó.

Lý do:

DHCP server cần biết subnet nào reachable qua interface nào.

8. Sai logic triển khai giữa DHCP Server và Relay Agent

Một lỗi thực tế là cấu hình đúng DHCP server nhưng sai relay.

Ví dụ:
ip helper-address 10.10.99.5

trong khi DHCP server thật là:
10.10.99.50

Hoặc cấu hình helper trên sai interface.

Ví dụ:

helper đặt trên uplink thay vì SVI của VLAN client.

Kết quả:

DHCPDISCOVER không đến đúng server.

4 cách thu thập thông tin để xử lý sự cố DHCP

Biết nguyên nhân tiềm tàng là một chuyện. Khi troubleshooting thực tế, cần thu thập đúng dữ liệu. 1. Kiểm tra cấu hình DHCP Server

Xác minh:

DHCP pool
network statement
subnet mask
default gateway
DNS server
excluded addresses
lease time

Cisco:
show ip dhcp pool
show ip dhcp binding
show running-config | section dhcp

Windows:
Get-DhcpServerv4Scope
Get-DhcpServerv4Lease

Linux (ISC DHCP):
cat /etc/dhcp/dhcpd.conf

2. Kiểm tra DHCP Relay Agent

Nếu client khác subnet với server, relay là checkpoint cực kỳ quan trọng.

Cisco:
show run interface vlan 10

Tìm:
ip helper-address

Xác minh:

đúng IP DHCP server
đúng interface nhận broadcast từ client

3. Kiểm tra dung lượng DHCP Pool

Mục tiêu:

DHCP còn IP hay đã cạn?

Cisco:
show ip dhcp pool

Windows:

DHCP Manager → Address Leases

Linux:
cat /var/lib/dhcp/dhcpd.leases

Nếu pool gần full, cần:

mở rộng subnet
giảm lease time
cleanup stale lease

4. Xác minh IP trên router interface

Nếu router đang đóng vai DHCP server:

Kiểm tra:
show ip interface brief

Đảm bảo interface có IP thuộc đúng subnet pool.

Ví dụ đúng:
Pool: 192.168.50.0/24
Interface VLAN50: 192.168.50.1

Ví dụ sai:
Pool: 192.168.50.0/24
Interface VLAN50: 10.10.10.1

Kết luận

Troubleshooting DHCP thường xoay quanh vài câu hỏi cốt lõi:

Broadcast DHCP có tới được server không?
DHCP server còn IP không?
Cấu hình pool đúng chưa?
Có relay agent không?
Có IP conflict không?
DHCP redundancy có hoạt động đúng không?
Router có interface đúng subnet không?

Khi đi theo checklist này, phần lớn sự cố DHCP trong môi trường Cisco, Windows hoặc Linux đều có thể được cô lập và xử lý nhanh chóng.

DHCP nhìn đơn giản, nhưng khi fail thì có thể kéo theo cả một hệ thống ngừng hoạt động

Quá trình forward frame trong Switch

dangquangminh — Sun, 10 May 2026 08:29:48 GMT

Quá trình chuyển tiếp frame (Frame Forwarding Process)

Để xử lý sự cố liên quan đến chuyển tiếp Layer 2 một cách hiệu quả, bạn cần hiểu rõ cách switch hoạt động. Đây là kiến thức nền tảng mà bạn thường đã học từ CCNA Routing and Switching. Tuy nhiên, việc ôn lại cơ chế hoạt động của switch là rất quan trọng, bởi toàn bộ quá trình troubleshooting Layer 2 đều dựa trên những nguyên lý này.

Phần này sẽ giải thích cách switch xây dựng MAC address table và cách nó quyết định xử lý một frame dựa trên thông tin có trong bảng MAC.

Hub vs Switch: Khác biệt cốt lõi

Trước khi hiểu frame forwarding, hãy phân biệt giữa Ethernet Hub và Ethernet Switch.

Ethernet hub hoạt động rất đơn giản:

nhận bit từ một cổng
phát lại chính xác những bit đó ra tất cả các cổng còn lại

Hub không có khả năng "hiểu" thiết bị nào đang kết nối ở đâu.

Điều này gây ra nhiều vấn đề:

lãng phí băng thông
collision (va chạm dữ liệu)
hiệu năng thấp
bảo mật kém

Ví dụ:

Nếu hai máy cùng truyền dữ liệu đồng thời:

frame sẽ va chạm
dữ liệu bị lỗi
cả hai thiết bị phải truyền lại

Lý do:

Toàn bộ hub nằm trong cùng một collision domain.

Switch thì thông minh hơn rất nhiều.

Switch có khả năng:

học địa chỉ MAC
ghi nhớ thiết bị nằm ở cổng nào
chỉ chuyển frame đến đúng nơi cần thiết

Kết quả:

tối ưu băng thông
loại bỏ collision
tăng hiệu suất
cải thiện bảo mật

Lý do:

Mỗi cổng trên switch là một collision domain riêng biệt.

MAC Address Table là gì?

Switch duy trì một bảng gọi là:

MAC Address Table (hay CAM Table)

Ví dụ:
VLAN MAC Address Type Port
10 0050.b60c.f258 DYNAMIC Gi0/1
10 0800.275d.06d6 DYNAMIC Fa0/1
10 0800.27a2.ce47 DYNAMIC Fa0/2

Bảng này cho switch biết:

MAC nào nằm ở cổng nào
thuộc VLAN nào
học động hay cấu hình tĩnh

Switch học MAC như thế nào?

Switch học MAC bằng cách nhìn vào:

Source MAC address của frame đi vào.

Ví dụ:

Switch nhận frame tại:
GigabitEthernet1/1

Frame có:
Source MAC = DDDD.DDDD.DDDD

Switch suy luận:

"Thiết bị có MAC DDDD.DDDD.DDDD nằm phía sau cổng Gi1/1."

Sau đó switch thêm vào MAC table:
DDDD.DDDD.DDDD → Gi1/1

Từ lần sau, nếu có frame gửi tới MAC đó, switch biết chính xác phải gửi ra đâu.

Khi switch chưa biết MAC đích

Ban đầu switch chưa biết gì cả.

MAC table trống.

Nếu switch nhận frame có destination MAC chưa tồn tại trong bảng:

Switch sẽ thực hiện:

Unknown Unicast Flooding

Tức là:

gửi frame ra tất cả cổng cùng VLAN
ngoại trừ cổng nhận frame

Ví dụ:

Frame vào từ:
Fa0/1

Switch chưa biết MAC đích.

Nó flood ra:
Fa0/2
Fa0/3
Gi0/1
Gi0/2

(trong cùng VLAN)

Broadcast Frame hoạt động thế nào?

Broadcast MAC:
FFFF.FFFF.FFFF

Khi switch thấy destination MAC này:

Nó luôn flood.

Lý do:

Không có thiết bị nào dùng MAC:
FFFF.FFFF.FFFF

Nên switch không bao giờ học được địa chỉ này một cách động.

Ví dụ từ MAC table:
All ffff.ffff.ffff STATIC CPU

Điều này cho thấy:

Broadcast được xử lý đặc biệt.

Ví dụ thực tế: PC1 kết nối Telnet tới Server

Giả sử:

PC1 và Server cùng subnet
cùng VLAN 100
không cần routing

Topology:
PC1 ---- SW1 ---- Server
VLAN 100

PC1 muốn mở Telnet tới Server.

Để làm được điều đó, PC1 cần:

IP address của Server
MAC address của Server

Bước 1: Xác định IP

IP thường:

cấu hình sẵn
hoặc
lấy từ DNS

Giả sử PC1 đã biết IP server.

Bước 2: Cần MAC Address

Ethernet truyền dữ liệu theo MAC.

Nếu PC1 chưa có MAC của server trong ARP cache:

Nó phải dùng:

ARP Request

ARP Request là broadcast

PC1 gửi:

"Ai đang giữ IP này? Hãy trả lời MAC cho tôi."

Frame:
Destination MAC = FFFF.FFFF.FFFF

Switch nhận broadcast.

Theo nguyên tắc:

Broadcast luôn flood.

Switch gửi ARP request ra mọi cổng trong VLAN 100.

Server nhận được.

ARP Reply là unicast

Server phản hồi:

"IP đó là tôi. MAC của tôi là XXXX.XXXX.XXXX"

Frame này là unicast.

Switch học:

Source MAC của server
cổng server đang kết nối

Ví dụ:
XXXX.XXXX.XXXX → Gi0/3

PC1 gửi Telnet

Bây giờ PC1 đã biết MAC server.

PC1 gửi frame:
Destination MAC = Server MAC

Switch kiểm tra MAC table.

Nếu đã có entry:

Switch forward đúng cổng duy nhất.

Không flood.

Logic chuyển tiếp của switch

Switch xử lý frame theo logic: Nếu destination MAC đã biết

→ Forward đúng cổng. Nếu destination MAC chưa biết

→ Flood trong cùng VLAN. Nếu là broadcast

→ Flood trong cùng VLAN. Nếu source MAC mới

→ Học MAC đó.

Các lệnh troubleshooting quan trọng

Kiểm tra MAC table

show mac address-table

Kiểm tra một MAC cụ thể

show mac address-table address 0800.27a2.ce47

Kiểm tra interface

show interfaces status

Kiểm tra VLAN

show vlan brief

Các lỗi Layer 2 phổ biến

Troubleshooting thực tế thường gặp: MAC không được học

Nguyên nhân:

interface down
VLAN sai
port-security block

Unknown unicast flooding liên tục

Nguyên nhân:

MAC aging timeout
flapping
topology loop

Broadcast storm

Nguyên nhân:

loop Layer 2
STP lỗi

MAC learned sai cổng

Nguyên nhân:

loop
rogue switch
topology instability

Kết luận

Hiểu cách switch học MAC và forward frame là nền tảng quan trọng nhất khi troubleshooting Layer 2.

Hãy nhớ mô hình tư duy đơn giản:

Learn from source MAC

Lookup destination MAC

Known = Forward

Unknown = Flood

Broadcast = Always Flood

Nắm chắc logic này, bạn sẽ xử lý nhanh hầu hết các sự cố switching trong mạng doanh nghiệp.

Hướng dẫn troubleshooting địa chỉ IP

dangquangminh — Sat, 09 May 2026 10:40:31 GMT

Khắc phục sự cố địa chỉ IPv4

Giống như địa chỉ nhà riêng của bạn xác định duy nhất nơi bạn sinh sống, địa chỉ IPv4 cũng xác định duy nhất vị trí của một thiết bị trong mạng. Địa chỉ nhà thường gồm hai phần: tên đường và số nhà; sự kết hợp của hai thành phần này sẽ là duy nhất trong phạm vi thành phố hoặc khu vực bạn sinh sống.

Nguyên tắc tương tự cũng áp dụng với địa chỉ IPv4. Nếu các thiết bị được cấu hình địa chỉ sai, chúng có thể nhận được hoặc không nhận được các gói tin được gửi đến cho mình. Vì vậy, việc hiểu rõ cơ chế đánh địa chỉ IPv4 và cách xác minh rằng các thiết bị đang được cấu hình đúng trên mạng là điều cực kỳ quan trọng.

Phần này tập trung vào cách xử lý các sự cố liên quan đến địa chỉ IPv4.

Các vấn đề liên quan đến địa chỉ IPv4

Một địa chỉ IPv4 bao gồm hai phần chính:

Phần mạng / mạng con (Network/Subnet Portion)
Phần host (Host Portion)

Điều quan trọng là tất cả các thiết bị nằm trong cùng một mạng hoặc cùng subnet phải có chính xác cùng phần Network/Subnet.

Nếu không giống nhau hoàn toàn, máy tính có thể xác định sai cách đóng gói frame ở lớp 2 (Layer 2), từ đó gửi gói tin theo hướng sai.

Hãy xem ví dụ với subnet 10.1.1.0/26 gồm hai máy tính PC1, PC2 và router R1 đóng vai trò default gateway. Thông tin cấu hình:

PC1

IP: 10.1.1.10
Subnet Mask: 255.255.255.192
Default Gateway: 10.1.1.1

PC2

IP: 10.1.1.20
Subnet Mask: 255.255.255.192
Default Gateway: 10.1.1.1

Web Server

IP: 192.0.2.1

Trường hợp 1: PC1 giao tiếp với PC2

Khi PC1 muốn giao tiếp với PC2, trước tiên nó thực hiện truy vấn DNS để lấy địa chỉ IP của PC2.

Kết quả trả về là:

10.1.1.20

Bây giờ PC1 cần xác định:

PC2 có nằm cùng subnet với mình hay không?

Câu trả lời sẽ quyết định frame Ethernet sẽ được gửi đến:

MAC address của PC2 (nếu cùng subnet)
hoặc
MAC address của default gateway (nếu khác subnet)

Bước 1: Xác định subnet của PC1

Địa chỉ IP của PC1 ở dạng nhị phân:
00001010.00000001.00000001.00001010

Subnet mask:
11111111.11111111.11111111.11000000

So sánh:
00001010.00000001.00000001.00001010
11111111.11111111.11111111.11000000
-----------------------------------
00001010.00000001.00000001.00

Các bit có giá trị 1 trong subnet mask chính là phần Network/Subnet.

=> Network ID của PC1 là:
10.1.1.0/26

Bước 2: So sánh với địa chỉ của PC2

Địa chỉ PC2 dạng nhị phân:
00001010.00000001.00000001.00010100

So sánh phần subnet:
PC1 subnet:
00001010.00000001.00000001.00

PC2:
00001010.00000001.00000001.00 010100

Các bit thuộc phần network hoàn toàn giống nhau.

=> PC1 kết luận:

PC2 nằm cùng subnet với mình.

Do đó:

Không cần gửi gói tin qua router
Không cần default gateway
Giao tiếp trực tiếp ở Layer 2

Frame Ethernet sẽ có:

Source MAC = MAC của PC1
Destination MAC = MAC của PC2

Trường hợp 2: PC1 giao tiếp với Web Server

Giả sử PC1 muốn truy cập web server.

PC1 truy vấn DNS và nhận được:
192.0.2.1

Một lần nữa, PC1 cần xác định:

Web server có cùng subnet với mình không?

Bước 1: Xác định subnet của PC1

(IP PC1 giống như trên)
00001010.00000001.00000001.00001010
11111111.11111111.11111111.11000000
-----------------------------------
00001010.00000001.00000001.00

Bước 2: So sánh với địa chỉ Web Server

Web server ở dạng nhị phân:
11000000.00000000.00000010.00000001

So sánh:
PC1 subnet:
00001010.00000001.00000001.00

Web Server:
11000000.00000000.00000010.00 000001

Các bit network hoàn toàn khác nhau.

=> PC1 kết luận:

Web Server nằm ở mạng khác.

Do đó PC1 không thể giao tiếp trực tiếp ở Layer 2.

Thay vào đó:

PC1 gửi frame đến default gateway
Router sẽ chịu trách nhiệm định tuyến gói tin đến mạng đích

Frame Ethernet sẽ có:

Source MAC = MAC của PC1
Destination MAC = MAC của router R1

Điểm mấu chốt khi troubleshooting IPv4

Khi xử lý sự cố IPv4, luôn kiểm tra các yếu tố sau:

Địa chỉ IP có đúng không?
Subnet mask có đúng không?
Default gateway có đúng không?
Thiết bị đích có thực sự cùng subnet không?
Máy tính có đang quyết định đúng giữa:
- gửi trực tiếp
- hay gửi qua gateway?

Rất nhiều lỗi kết nối trong mạng doanh nghiệp thực tế xuất phát từ việc cấu hình sai một trong ba thông số cơ bản:

IP Address + Subnet Mask + Default Gateway

Chỉ cần sai một thông số nhỏ, toàn bộ luồng truyền thông có thể bị lỗi.