Case study: Route leak từ upstream làm mạng full, xử lý và bài học rút ra

linh_pham

Chào anh em,

Mở màn bằng một case thực tế về route leak từ upstream mà chắc nhiều ISP/enterprise cũng từng gặp.

Bối cảnh:

Mạng: ISP tầm trung ở VN.
Kết nối:
- Upstream A: full table IPv4/IPv6
- Upstream B: full table IPv4, một số prefix ưu tiên
- Peering nội địa, IX, và một số private peer.
Core chạy iBGP với RR, edge BGP ra ngoài.

Sự cố:

CPU route reflector + edge router tăng cao
BGP session flap nhẹ
Số lượng prefix nhận từ upstream A tăng đột biến (gấp _2–3 lần bình thường)
Phát hiện upstream A bị leak full table từ một khách hàng/peer của họ, policy phía mình chưa chặn đủ nên lọt vào mạng, load CPU/memory.

Nguyên nhân chính:
1) max-prefix chưa chặt
2) Prefix/AS-PATH filter tin upstream quá mức
3) Chưa có cơ chế tự động throttling/shutdown session khi vượt ngưỡng.

Cách xử lý tức thời:

Áp max-prefix strict hơn, cho session down có kiểm soát khi vượt ngưỡng
Thêm prefix-list/route-filter chặn prefix rõ ràng không liên quan
Làm việc với NOC của upstream, gửi log + AS-PATH + thời gian.

Bài học rút ra:

Không tin 100% vào upstream: luôn có max-prefix, filter theo AS-PATH/community
Build sẵn leak scenario trong lab để test ngưỡng chịu đựng
Monitoring số prefix theo neighbor, CPU/mem, BGP state, convergence time.

Anh em chia sẻ thêm:

Đang set max-prefix cho upstream/peer thế nào?
Có dùng RPKI/IRR/ROA không?
Có ai từng gặp case tương tự với IX/peering nội địa?

haibgp

Bên mình từng dính route leak kiểu tương tự, sau đó set max-prefix 120% so với baseline và dùng thêm community để phân loại prefix trusted/untrusted. Nhờ vậy lần sau upstream có vấn đề thì mình nhận cảnh báo sớm hơn, đỡ tới mức full table mới biết.

Secu_uyen

Từ góc nhìn security thì route leak không chỉ là misconfig mà hoàn toàn có thể bị lợi dụng để làm DoS lên core/edge. Nên ngoài max-prefix em nghĩ nên có luôn playbook IR riêng cho BGP: ai được phép shutdown session, quy trình thông báo khách hàng, cách lưu lại log/AS-PATH phục vụ post-mortem.

VuAuto

Bên em có viết một job nhỏ dùng Python gọi API router, theo dõi số prefix trên từng neighbor. Nếu vượt ngưỡng lạ thì bot đẩy cảnh báo về Telegram và log lại full thông tin neighbor, top AS-PATH. Sau đó có thể mở rộng thêm bước auto-apply policy tạm thời nếu thật sự cần.

Hunter

Cho mình hỏi lúc sự cố xảy ra thì thứ tự các bước troubleshoot bên anh là gì? Ưu tiên soi BGP summary trước hay CPU/memory, rồi mới drill-down vào AS-PATH từng neighbor? Em muốn học thêm về cách ưu tiên bước khi mọi thứ cùng kêu một lúc.

ChichBon

Bài học lớn nhất chắc là phải biến mấy kinh nghiệm này thành chính sách nội bộ luôn. Ví dụ: checklist bắt buộc cho session với upstream/peer (max-prefix, filter tối thiểu, monitor), và review định kỳ 6–12 tháng để tránh config drift. Không thì vài năm sau hạ tầng đổi mà policy vẫn cũ.