Vietnamese Professional - CCNP Advanced Routing

4 lỗi thường gặp ở DHCP

dangquangminh — Thu, 03 Sep 2026 07:48:27 GMT

🔧 4 lỗi DHCP phổ biến trong hệ thống mạng và IP Phone

DHCP (Dynamic Host Configuration Protocol) giúp thiết bị tự động nhận IP Address, Subnet Mask, Default Gateway, DNS và các DHCP Option cần thiết. Với hệ thống VoIP, DHCP đặc biệt quan trọng vì IP Phone cần có IP trước khi tiếp tục quá trình khởi động và đăng ký với Call Control.

Theo hình minh họa, có 4 lỗi DHCP phổ biến: 1. DHCP Server không hoạt động

The DHCP server is unavailable.

DHCP Server có thể bị shutdown, mất kết nối mạng, dịch vụ DHCP bị dừng hoặc bị Firewall/ACL chặn.

Kết quả: IP Phone gửi DHCP Discover nhưng không nhận được DHCP Offer.

👉 Kiểm tra đầu tiên: DHCP Server có reachable và DHCP service có đang chạy hay không.

2. DHCP Server không có Scope phù hợp

The DHCP server does not have a correct scope for the phones.

Ví dụ Voice VLAN sử dụng:

10.20.20.0/24

nhưng DHCP Server chỉ có scope cho:

10.10.10.0/24

IP Phone sẽ không nhận được cấu hình IP phù hợp.

Ngoài subnet mask và gateway, trong môi trường VoIP còn cần kiểm tra các DHCP Option cần thiết, chẳng hạn Option 150 trong một số triển khai Cisco IP Phone để cung cấp địa chỉ TFTP Server. 3. DHCP Scope đã hết địa chỉ

All addresses in the scope are currently leased.

Ví dụ DHCP Scope:

192.168.10.100 – 192.168.10.200

Nếu toàn bộ địa chỉ đã được cấp phát, IP Phone mới sẽ không còn IP để nhận.

👉 Cần kiểm tra DHCP Lease, giải phóng các lease không còn sử dụng hoặc mở rộng Address Pool nếu cần. 4. IP Phone và DHCP Server khác subnet

The phone is not on a common subnet with the DHCP server.

DHCP Discover ban đầu là broadcast, mà Router mặc định không forward broadcast sang subnet khác.

Ví dụ:
IP Phone
VLAN 20
|
| DHCP Discover
↓
Router/L3 Switch
|
X
|
DHCP Server
VLAN 100

Trường hợp này cần cấu hình DHCP Relay Agent, trên thiết bị Cisco thường sử dụng:
interface Vlan20
ip helper-address 10.10.100.10

Router/L3 Switch sẽ chuyển DHCP request của Phone đến DHCP Server ở subnet khác.

🎯 Cách nhớ nhanh khi troubleshoot DHCP

Khi IP Phone không nhận được IP, hãy kiểm tra 4 câu hỏi:

DHCP Server có UP không? → Có đúng Scope không? → Scope còn IP không? → Khác subnet thì đã có DHCP Relay chưa?

Đặc biệt trong VoIP, nhận được IP chưa có nghĩa là DHCP đã hoàn toàn đúng. Phone có thể nhận IP, Gateway và DNS bình thường nhưng vẫn không đăng ký được nếu thiếu hoặc sai các DHCP Option cần thiết cho quá trình provisioning.

Troubleshooting BGP

dangquangminh — Wed, 26 Aug 2026 10:51:44 GMT

Slide Troubleshooting BGP.

BFD – Phát hiện sự cố Layer 3 tốc độ cao

dangquangminh — Sun, 16 Aug 2026 02:35:13 GMT

BFD – Phát hiện sự cố Layer 3 tốc độ cao

Trong thiết kế Fast Convergence, một trong những vấn đề lớn là routing protocol thường phát hiện failure dựa trên timer của chính nó. Nếu giảm Hello/Hold/Dead timer quá thấp, control plane phải xử lý nhiều packet hơn và mạng có thể trở nên nhạy cảm với các sự cố thoáng qua.

BFD – Bidirectional Forwarding Detection giải quyết bài toán này bằng cách tách chức năng phát hiện failure khỏi routing protocol.

Thay vì để OSPF, EIGRP, IS-IS hay BGP tự phát hiện lỗi, chúng ta có thể để BFD làm việc đó rồi thông báo kết quả cho routing protocol.
BFD detects failure
↓
OSPF / EIGRP / IS-IS / BGP
↓
Neighbor/session removed
↓
Route recalculation
↓
Fast Convergence Tại sao BFD tốt hơn aggressive protocol timers?

Slide nhấn mạnh BFD được strongly recommended over aggressive protocol timers vì ba ưu điểm chính.

Reduced control-plane load and link bandwidth usage: thay vì mỗi routing protocol phải chạy timer cực thấp riêng, nhiều protocol có thể tận dụng chung cơ chế BFD để phát hiện lỗi.

Sub-second failure detection: BFD được thiết kế để phát hiện lỗi ở mức dưới một giây, thậm chí nhanh hơn tùy platform, timer và khả năng xử lý.

In-flight timer negotiation: hai BFD peer có thể trao đổi các giá trị timer và xác định tốc độ gửi/nhận phù hợp với khả năng của hai bên.

Điểm cần nhớ:

BFD không tìm best path và cũng không chạy SPF. BFD chỉ trả lời rất nhanh câu hỏi: đường forwarding giữa hai endpoint còn sống hay đã chết?

BFD Operation Modes – BFD hoạt động như thế nào?

BFD session được thiết lập thông qua asynchronous control packets.

Hai thiết bị gửi BFD Control packet cho nhau để xác nhận khả năng bidirectional forwarding.

Slide mô tả hai cách hoạt động chính. 1. Asynchronous Mode – Không sử dụng Echo

Trong chế độ cơ bản:
R1 R2
| ---- BFD Control ----> |
| <--- BFD Control ----- |
| ---- BFD Control ----> |
| <--- BFD Control ----- |

Hai router độc lập gửi BFD Control packet theo tốc độ đã thương lượng.

Mỗi router về cơ bản đang nói với router kia:
"I'm alive."

Nếu không nhận được BFD packet trong khoảng thời gian:
Detection Time ≈ Interval × Multiplier

peer sẽ được xem là Down.

Ví dụ nếu negotiated receive interval là 100 ms và multiplier bằng 3, về nguyên tắc failure có thể được phát hiện sau khoảng:
100 ms × 3 = 300 ms

Sau đó BFD thông báo cho routing protocol liên quan để quá trình convergence bắt đầu.

2. Asynchronous Mode + Echo

Nếu hai bên hỗ trợ và thương lượng BFD Echo, cách phát hiện failure có thể được tối ưu hơn.

Lúc này có hai loại traffic:
BFD Control packets → gửi với tốc độ chậm hơn

BFD Echo packets → dùng để kiểm tra forwarding path

Điểm thú vị của Echo Mode là packet được gửi sang neighbor rồi được loop/forward trở lại chính thiết bị gửi.

Có thể hình dung:
Echo
R1 -----------------> R2
^ |
|_____________________|
returned

R1 gửi Echo packet qua R2 và chờ packet quay trở lại. Nhờ đó R1 có thể kiểm tra trực tiếp forwarding path.

Khi Echo được sử dụng, BFD Control packet không nhất thiết phải gửi với tần suất cao như trước, giúp giảm phần processing liên quan đến control packets.

Control Packet và Echo Packet khác nhau ở đâu?

Đây là điểm dễ nhầm khi học BFD.

Với Asynchronous Mode, hai router kiểm tra nhau:
R1 → "R1 alive" → R2
R2 → "R2 alive" → R1

Còn với Echo, router kiểm tra forwarding path bằng packet quay về chính nó:
R1 → Echo → R2 → R1
R2 → Echo → R1 → R2

Vì vậy hình thứ hai có nhiều đường packet hơn hình đầu tiên.

Tư duy troubleshooting BFD

Khi triển khai BFD, đừng chỉ hỏi:

"OSPF neighbor có Full không?"

Hãy tách thành hai câu hỏi:
BFD Session
↓
Forwarding path alive?
↓
Routing Protocol
↓
Neighbor/session alive?

Ví dụ OSPF Dead Timer là hàng chục giây nhưng BFD phát hiện failure trong vài trăm millisecond:
Link/forwarding failure
↓
BFD detects ~300 ms
↓
Notify OSPF
↓
OSPF adjacency down
↓
SPF / RIB / FIB update
↓
Traffic moves to alternate path

Đó chính là giá trị lớn nhất của BFD:

Routing protocol lo chuyện tìm đường. BFD chuyên lo phát hiện đường forwarding bị chết càng nhanh càng tốt.

Trong các mạng Enterprise Core, Data Center và Service Provider yêu cầu High Availability + Fast Convergence, BFD vì vậy thường được kết hợp với OSPF, IS-IS, EIGRP, BGP, MPLS và các cơ chế redundancy khác, thay vì đơn giản giảm mạnh timer của từng protocol.

Pipeline | trong Cisco CLI – Lọc Output Để Troubleshooting Nhanh Hơn

dangquangminh — Thu, 13 Aug 2026 11:04:45 GMT

Pipeline | trong Cisco CLI – Lọc Output Để Troubleshooting Nhanh Hơn

Khi troubleshooting trên router/switch Cisco, vấn đề đôi khi không phải là thiếu thông tin, mà là có quá nhiều thông tin. Một lệnh show running-config có thể trả về hàng nghìn dòng. Thay vì kéo màn hình và tìm bằng mắt, kỹ sư có thể sử dụng pipeline | để lọc ngay output cần quan tâm.

Cú pháp tổng quát:
show |

Trong đó | có thể hiểu là: "Lấy kết quả của lệnh bên trái rồi xử lý/lọc theo điều kiện bên phải." 1. | include – Chỉ lấy những dòng cần tìm

Ví dụ muốn tìm tất cả cấu hình có chữ route:
show running-config | include route

Trong hình, router trả về:
default-router 192.168.10.1
default-router 192.168.20.1
router ospf 1
ip route 0.0.0.0 0.0.0.0 209.165.200.2
ip route 209.165.201.0 255.255.255.0 172.16.100.2
ipv6 route ::/0 2001:DB8:D1:A5:C8::2
ipv6 router rip RIPNG

Thay vì đọc toàn bộ running-config, chỉ một lệnh đã giúp chúng ta nhanh chóng phát hiện static route đáng nghi:
ip route 209.165.201.0 255.255.255.0 172.16.100.2

Đây là cách rất hiệu quả khi nghi ngờ routing loop, static route sai hoặc cấu hình routing không đúng.

Một ví dụ khác:
show ip route | include 10.10.10.0

Dùng để nhanh chóng tìm route đến mạng 10.10.10.0.

2. | exclude – Loại bỏ những dòng không cần thiết

Trong hình có lệnh:
show ip interface brief | exclude unass

Mục tiêu là loại bỏ các interface có IP Address là:
unassigned

Nhờ vậy, output chỉ tập trung vào những interface đã được gán địa chỉ IP.

Có thể viết đầy đủ hơn:
show ip interface brief | exclude unassigned

Đây là một mẹo rất hữu ích trên những switch có 48 hoặc hàng trăm interface nhưng chỉ một số interface Layer 3 đang thực sự được sử dụng.

3. | begin – Hiển thị từ vị trí cần tìm trở xuống

Giả sử running-config rất dài nhưng bạn chỉ muốn xem từ phần OSPF:
show running-config | begin router ospf

Router sẽ bỏ qua toàn bộ phần cấu hình phía trên và bắt đầu hiển thị từ:
router ospf 1

trở xuống.

Tương tự, muốn xem cấu hình bắt đầu từ một interface:
show running-config | begin interface GigabitEthernet0/1

begin đặc biệt hữu ích khi bạn biết phần cần tìm nằm ở đâu nhưng vẫn muốn xem những dòng cấu hình phía sau nó.

4. | section – Lấy nguyên một khối cấu hình

Đây là một trong những filter hữu ích nhất khi troubleshooting.

Ví dụ:
show running-config | section router ospf

Bạn có thể nhận được:
router ospf 1
router-id 1.1.1.1
network 10.1.12.0 0.0.0.255 area 0
network 10.1.23.0 0.0.0.255 area 0
passive-interface GigabitEthernet0/0

Khác với include, section giúp lấy cả block cấu hình liên quan.

Ví dụ kiểm tra BGP:
show running-config | section router bgp

Hoặc kiểm tra một interface:
show running-config | section interface GigabitEthernet0/1

Đây thường là lựa chọn tốt hơn include khi troubleshooting OSPF, BGP, interface, ACL và nhiều cấu hình có cấu trúc theo section.

5. Kết hợp với Regular Expression

Pipeline còn mạnh hơn khi kết hợp với Regular Expression (Regex).

Ví dụ chỉ tìm OSPF hoặc BGP:
show running-config | include ospf|bgp

Hoặc khi kiểm tra interface:
show ip interface brief | include up|down

Trong thực tế, khả năng regex và cú pháp filter cụ thể có thể khác nhau tùy IOS/IOS XE/NX-OS và phiên bản phần mềm, vì vậy cần kiểm tra cú pháp bằng ? trên thiết bị đang sử dụng.

Một tình huống troubleshooting thực tế

Giả sử traceroute cho thấy:
Hop 1 → DSW1
Hop 2 → R1
Hop 3 → DSW1
Hop 4 → R1
...

Đây là dấu hiệu rất mạnh của Routing Loop.

Bạn đăng nhập R1 và kiểm tra:
show running-config | include route

Sau đó phát hiện:
ip route 209.165.201.0 255.255.255.0 172.16.100.2

Tiếp tục kiểm tra địa chỉ interface:
show ip interface brief | exclude unassigned

và xác định:
R1 172.16.100.1
DSW1 172.16.100.2

Như vậy R1 đang gửi traffic đến DSW1. Nếu DSW1 lại có route gửi traffic trở về R1, hai thiết bị sẽ tạo thành:
packet
↓
R1 ───────────→ DSW1
↑ │
└────────────────┘
Routing Loop

Pipeline không trực tiếp "sửa" routing loop, nhưng nó giúp kỹ sư lọc hàng nghìn dòng output xuống còn vài dòng quan trọng để kiểm chứng hypothesis rất nhanh. 4 pipeline nên thuộc lòng

show ... | include
show ... | exclude
show ... | begin
show ... | section

Có thể nhớ đơn giản: include = lấy dòng cần tìm, exclude = bỏ dòng không cần, begin = bắt đầu từ đây, section = lấy cả khối cấu hình.

Đối với CCNP/CCIE, biết nhiều lệnh show là cần thiết; nhưng biết cách dùng pipeline để biến output lớn thành đúng vài dòng mình cần mới là kỹ năng giúp troubleshooting nhanh trong môi trường thực tế.

Troubleshooting BGP Routes – Xử lý sự cố Route trong BGP

dangquangminh — Fri, 07 Aug 2026 11:21:01 GMT

Sau khi BGP adjacency được thiết lập thành công, các BGP router bắt đầu trao đổi thông tin định tuyến với nhau. Tuy nhiên, trạng thái neighbor đã Established không có nghĩa là mọi route đều xuất hiện trong BGP Table hoặc được cài đặt vào Routing Table.

Khi troubleshooting BGP, cần phân biệt hai câu hỏi rất quan trọng:

Route có vào BGP Table không?
và
Route có được chọn để đưa vào Routing Table không? 1. Những nguyên nhân phổ biến khiến BGP route bị thiếu

Sai hoặc thiếu lệnh network

Muốn quảng bá một prefix bằng BGP, lệnh network phải khớp với route đang tồn tại trong Routing Table, bao gồm cả subnet mask.

Ví dụ:
router bgp 65001
network 10.10.10.0 mask 255.255.255.0

Router phải có route 10.10.10.0/24 trong Routing Table. Nếu chỉ tồn tại 10.10.10.0/25 thì BGP sẽ không originate 10.10.10.0/24 bằng lệnh trên.

BGP Next-Hop không reachable

Một BGP route có thể xuất hiện trong BGP Table nhưng không sử dụng được nếu router không tìm được đường đến địa chỉ Next Hop.

Kiểm tra:
show bgp ipv4 unicast
show ip route

Đây là lỗi rất thường gặp trong iBGP, đặc biệt khi route được học từ eBGP rồi quảng bá sang iBGP mà next-hop vẫn được giữ nguyên.

Một giải pháp thường gặp là:
neighbor 10.1.1.2 next-hop-self

Quy tắc BGP Split Horizon của iBGP

Một nguyên tắc cực kỳ quan trọng:

Route học từ một iBGP peer sẽ không được quảng bá tiếp cho một iBGP peer khác.

Ví dụ:
R1 ----iBGP---- R2 ----iBGP---- R3

Nếu R2 học route từ R1 qua iBGP, mặc định R2 không quảng bá route đó cho R3.

Trong mạng lớn, vấn đề này thường được giải quyết bằng iBGP Full Mesh hoặc Route Reflector (RR).

Có nguồn định tuyến tốt hơn

Một prefix có thể tồn tại trong BGP Table nhưng không được cài vào Routing Table nếu router đã học chính prefix đó từ một nguồn có Administrative Distance tốt hơn.

Ví dụ, cùng một prefix được học từ OSPF và iBGP:
OSPF = AD 110
iBGP = AD 200

Trong trường hợp này, route OSPF thường được ưu tiên đưa vào Routing Table.

Route Filtering

Prefix có thể bị chặn bởi các chính sách như:
prefix-list
route-map
filter-list
distribute-list

Do đó khi neighbor đã Established nhưng route vẫn mất, hãy kiểm tra cả policy theo hai chiều inbound và outbound. 2. Kiểm tra BGP Table

Lệnh quan trọng:
show bgp ipv4 unicast

Tương đương với lệnh truyền thống:
show ip bgp

Một route có thể xuất hiện trong BGP Table vì một trong các nguyên nhân: được BGP neighbor quảng bá tới, được đưa vào bằng network, được redistribute từ giao thức khác, hoặc được tạo thành aggregate/summary. 3. Đọc Next Hop và Origin Code

Nếu trong BGP Table:
Next Hop = 0.0.0.0

thì route được router cục bộ originate vào BGP.

Nếu Next Hop là một địa chỉ khác, chẳng hạn:
10.1.12.1

thì route thường được học từ một BGP peer.

Cuối cột Path, bạn cũng thường thấy Origin Code:
i
?

Trong đó:

i – IGP Origin: prefix được originate vào BGP bằng network hoặc cơ chế aggregate/summary phù hợp.

? – Incomplete: BGP không biết rõ nguồn gốc ban đầu theo cơ chế origin của BGP; trường hợp điển hình là route được đưa vào BGP bằng redistribution.

Lưu ý: chữ i ở Origin Code không có nghĩa route được học qua iBGP. Đây là hai khái niệm hoàn toàn khác nhau. 4. Quy trình troubleshooting nên nhớ

Khi neighbor đã Established nhưng không thấy route, có thể kiểm tra theo chuỗi:

Neighbor → BGP Table → Next Hop → Best Path → Routing Table → Filtering

Ví dụ:
show bgp ipv4 unicast summary
show bgp ipv4 unicast
show bgp ipv4 unicast 172.16.10.0/24
show ip route 172.16.10.0
show ip route
show running-config | section router bgp

Điểm quan trọng nhất khi troubleshooting BGP là: Established chỉ chứng minh hai router đã hình thành BGP session. Nó không chứng minh route đã được quảng bá, được chấp nhận, trở thành best path hay được cài vào Routing Table.

Đó là lý do kỹ sư mạng nên troubleshooting BGP theo từng lớp: Peer → Prefix → Next-Hop → Policy → Best Path → RIB.