PeeringDB vừa tổng kết các thay đổi từ tháng 4 đến tháng 9/2026: Advanced Search có thể xuất truy vấn API theo nhiều định dạng, xem facility trên bản đồ; dữ liệu AS-SET được gắn rõ Internet Routing Registry (IRR); đồng thời cộng đồng đang thảo luận kiến trúc API v3. Với đội vận hành mạng, đây là các thay đổi giúp biến tra cứu interconnection từ thao tác thủ công thành workflow có thể tự động hóa và kiểm chứng.
Advanced Search nay mở rộng chức năng Copy API Query. Người dùng dựng bộ lọc trên giao diện web, sau đó lấy truy vấn tương đương dưới dạng curl và một số ngôn ngữ lập trình phổ biến. Cách làm này hữu ích khi cần tra cứu ban đầu bằng giao diện, rồi đưa chính điều kiện đó vào script kiểm kê, pipeline capacity planning hoặc công cụ nội bộ.
Điểm đáng giá là giảm sai lệch giữa hai bước: thay vì tự viết lại logic lọc từ đầu trong API, kỹ sư có một truy vấn mẫu xuất phát từ kết quả đã nhìn thấy. Vẫn cần lưu version API, kiểm tra pagination, timeout và rate limit trước khi chạy định kỳ ở quy mô lớn.
Advanced Search có thêm map view tùy chọn, bật trong profile. Bản đồ hiển thị vị trí facility trong một thành phố, bổ sung cho bảng kết quả vốn phù hợp hơn khi đọc chi tiết. Người cần phân tích địa lý rộng hơn vẫn có thể dùng full facility dataset dạng KMZ trong công cụ GIS.
Đây không thay thế khảo sát thực tế hay dữ liệu hợp đồng. Nhưng khi đánh giá vị trí đặt cache, chọn IX, tìm đường kết nối dự phòng hoặc so sánh cụm data centre, lớp trực quan này giúp phát hiện nhanh các facility ở gần nhau và đặt câu hỏi đúng trước khi đi sâu vào carrier, cross-connect, latency và chi phí.
PeeringDB đã đổi cách hiển thị AS-SET để giảm mơ hồ: khi biết nguồn, tên sẽ kèm IRR xuất phát. Ví dụ AS4608:AS-APNIC được hiển thị thành APNIC::AS4608:AS-APNIC. Nền tảng cũng liên hệ trực tiếp operator khi không tự xác định được IRR và thêm editor để nhập dữ liệu nhất quán hơn.
Chi tiết này quan trọng với policy BGP. Cùng một chuỗi tên không nên bị hiểu là cùng một object nếu chúng thuộc các IRR khác nhau. Khi dùng dữ liệu PeeringDB làm đầu vào cho kiểm tra peering hoặc tạo policy, đội mạng vẫn phải xác thực object, authority và trạng thái registry trong nguồn IRR phù hợp; không nên coi dữ liệu directory là cấu hình router có thể áp thẳng.
PeeringDB thử bỏ public beta ở đợt phát hành tháng 8, chuyển từ kiểm thử nội bộ lên production, sau khi cộng đồng phản hồi rằng beta hiện tại không còn đem lại nhiều giá trị và đợt thử không phát sinh vấn đề. Các thay đổi lớn, nhất là tác động giao diện hoặc hành vi API, vẫn sẽ dùng public beta khi phù hợp.
Nền tảng cũng hoàn tất tái phát triển operations dashboard nội bộ. Quyền truy cập được rollout cho volunteer trong tháng 9 và có kế hoạch công khai dashboard sau đó. Nếu dùng PeeringDB trong automation, đội vận hành nên tách rõ dữ liệu directory với nguồn giám sát production của mình: trạng thái một entry tốt không xác nhận BGP session, route acceptance hoặc năng lực cổng đang hoạt động.
Bản thảo API mới nêu hai mục tiêu chính. Thứ nhất, tách phần đọc và ghi của kiến trúc để có thể đặt instance PeeringDB tại nhiều nơi. Thứ hai, hỗ trợ query hiệu quả hơn cho các quan hệ thường dùng: một network cùng các presence tại exchange, một exchange cùng thành viên, hoặc một facility cùng các occupant.
PeeringDB cũng xem xét cảnh báo khi maximum prefix công bố của một network nhỏ hơn số prefix quan sát được. Đây là tín hiệu hữu ích cho trao đổi peering, nhưng không phải phán quyết tự động: số prefix quan sát được phụ thuộc vantage point, thời điểm và policy, còn max-prefix phải được thống nhất theo quan hệ vận hành thực tế.
Interconnection data chỉ có giá trị vận hành khi đi được từ “tìm thấy” tới “hành động lặp lại”. Copy API Query và các query quan hệ trong API v3 nhắm đúng khoảng cách đó: kỹ sư tra cứu một lần, sau đó biến kết quả thành inventory, candidate list hoặc kiểm tra định kỳ. Việc tách read/write còn cho thấy PeeringDB đang chuẩn bị cho nhu cầu truy vấn phân tán lớn hơn.
Đổi lại, tự động hóa dữ liệu peering cần rào chắn. Directory có thể cũ, AS-SET có thể sai namespace, còn maximum-prefix quan sát được có thể không phản ánh cam kết bilateral. Workflow tốt là dùng PeeringDB để thu hẹp vùng tìm kiếm, sau đó xác minh qua IRR/RPKI, looking glass, dữ liệu router và trao đổi trực tiếp với đối tác. Như vậy, dữ liệu cộng đồng trở thành tín hiệu giúp quyết định nhanh hơn, không thành nguồn cấu hình thiếu kiểm soát.
