Một ngày thường nhật: bảng BGP toàn cầu

 (articles.foletta.org)
2 điểm bởi GN⁺ 2024-11-27 | 1 bình luận | Chia sẻ qua WhatsApp
  • Thông qua 464.673 BGP UPDATE nhận từ một peer có toàn bộ bảng BGP trong suốt một ngày, bài viết quan sát các biến động ngắn hạn của bảng định tuyến toàn cầu thay vì xu hướng tăng trưởng dài hạn
  • Ngay sau khi peering được thiết lập, toàn bộ route và NLRI được đẩy đến cùng lúc trong khoảng 5 giây, và số route gắn với các path ban đầu là 949.483
  • Sau đó, các UPDATE được gom lại theo các khoảng 30 giây Route Advertisement Interval; trung bình quan sát được khoảng 50 cập nhật path IPv4 và khoảng 47 cập nhật path IPv6 mỗi 30 giây
  • Ở IPv4, cả số lượng path lẫn biến động không gian địa chỉ đều cho thấy tương quan theo chu kỳ khoảng 40 phút, nhưng nguyên nhân vẫn là một câu hỏi chưa có lời giải
  • Việc lạm dụng AS path prepending, path attribute 255 được dành riêng, và hiện tượng flapping dữ dội ở một số NLRI cụ thể cho thấy cả sự phức tạp lẫn khả năng phục hồi của vận hành BGP toàn cầu

Quan sát bảng BGP theo đơn vị một ngày

  • Việc phân tích bảng BGP toàn cầu thường tập trung vào các xu hướng kéo dài hàng tháng hoặc hàng năm như tăng trưởng bảng định tuyến hay việc triển khai IPv6
  • Phân tích này xem xét những biến động ngắn hạn nào xuất hiện trong suốt một ngày, trong bối cảnh router trực tiếp nhận các bản cập nhật BGP Internet luôn thay đổi
  • Đối tượng quan sát được chia thành ba nhánh
    • luồng UPDATE thông thường trong một ngày
    • các path attribute bất thường
    • các flappy path thay đổi thường xuyên

Thu thập dữ liệu và bgpsee

  • Thay vì trực tiếp parse output debug của router, tác giả hoàn thiện lại một BGP daemon từng làm dở trước đây để có thể chạy được và sử dụng bgpsee
  • bgpsee là một công cụ peering BGP đa luồng cho CLI; sau khi peering với router khác, nó parse các bản tin BGP và xuất ra JSON
    • Các loại bản tin được xử lý là OPEN, KEEPALIVE và UPDATE
    • UPDATE có thể chứa NLRI, withdrawn routes, và các path attribute như ORIGIN, AS_PATH, NEXT_HOP, AS4_PATH
  • Bộ dữ liệu được thu thập từ ngày 2024-01-06 đến 2024-01-07 và gồm 464.673 BGP UPDATE nhận từ một peer có đầy đủ bảng BGP

Truyền toàn bộ ban đầu và số lượng path

  • Khi BGP peering được dựng lên lần đầu, mọi path trong bảng BGP của router cùng các NLRI liên quan sẽ được gửi đi trong một cụm UPDATE lớn
  • Cụm ban đầu này được nhận trong khoảng 5 giây sau khi peering bắt đầu
  • Sau đó, chỉ còn các UPDATE cho những path đã thay đổi hoặc các withdrawn route không còn đường đi nữa được gửi đến
  • Cụm ban đầu và các UPDATE về sau có cấu trúc giống nhau; khác biệt nằm ở thời điểm nhận và phạm vi
  • Điểm phân biệt quan trọng ở đây là giữa path và route
    • path là một đơn vị BGP UPDATE gồm tổ hợp path attribute và các NLRI gắn với nó
    • một path có thể gắn với một route hoặc một nghìn route
    • số route gắn với toàn bộ các path trong cụm ban đầu là 949.483

Luồng UPDATE theo đơn vị 30 giây

  • Sau đợt truyền toàn bộ ban đầu, các UPDATE không đến như một luồng thời gian thực mà được gom lại và gửi theo timer Route Advertisement Interval
  • Trong peering này, Route Advertisement Interval là 30 giây
  • Số UPDATE trung bình quan sát được như sau
    • IPv4: khoảng 50 cập nhật path mỗi 30 giây
    • IPv6: khoảng 47 cập nhật path mỗi 30 giây
  • Dù trung bình tương tự nhau, biên độ dao động của IPv4 lớn hơn
    • độ lệch chuẩn IPv4: 64,3
    • độ lệch chuẩn IPv6: 43
  • Thay vì chỉ đếm số UPDATE đơn thuần, tác giả còn tính tổng lượng không gian địa chỉ IP thay đổi trong mỗi 30 giây
    • Cộng tổng số địa chỉ IP có trong từng UPDATE rồi áp dụng log2()
    • Ví dụ là đổi /22, /23, /24 sang số lượng địa chỉ tương ứng, cộng lại rồi lấy log
  • Theo không gian địa chỉ IPv4, trung bình cứ mỗi 30 giây có khoảng 2^16 địa chỉ, tức tương đương một /16, đổi path trong bảng định tuyến toàn cầu
  • Trong khoảng 95%, không gian địa chỉ IPv4 thay đổi nằm trong khoảng từ 2^20.75 đến 2^13.85
    • xấp xỉ tương ứng từ /11 đến /18

Chu kỳ 40 phút của cập nhật IPv4

  • Cả biến động số lượng path lẫn biến động không gian địa chỉ IP đều cho thấy UPDATE IPv4 có hành vi tuần hoàn
  • Để xác nhận chu kỳ, tác giả dùng hàm tự tương quan (ACF)
    • UPDATE được gom theo khoảng 1 phút, và 1 lag tương ứng 1 phút
    • Tính tương quan giữa số lượng path ở thời điểm hiện tại và số lượng path ở các lag trong quá khứ
  • Có tương quan mạnh ở khoảng 7 lag đầu tiên
    • Điều này cũng phù hợp với việc thay đổi route lan truyền toàn cầu có thể tạo ra các thay đổi route khác
  • Tương quan mạnh cũng xuất hiện ở lag 40 và 41, xác nhận hành vi có chu kỳ khoảng 40 phút
  • Nguyên nhân của chu kỳ 40 phút này vẫn là một câu hỏi chưa thể trả lời

Trường hợp lạm dụng AS path prepending

  • Quản trị viên mạng có thể dùng nhiều cách để điều chỉnh cách lưu lượng đi vào ASN của mình
    • Dùng prefix mạng dài hơn không có tính mở rộng tốt và cũng không được coi là cách làm lý tưởng dưới góc nhìn BGP
    • Thuộc tính MED là non-transitive nên có hạn chế khi peering với nhiều AS
    • Thông thường, người ta giảm mức độ được ưu tiên của route bằng AS path prepending, tức lặp lại ASN của mình nhiều lần ở phía trước đối với một peer cụ thể
  • Trong bộ dữ liệu, độ dài AS path IPv4 lớn nhất là 105
    • Đây là con số rất lớn nếu xét rằng path dài nhất không có prepending chỉ dài 14
    • Path IPv4 này bắt nguồn từ AS149381 của Indonesia, “Dinas Komunikasi dan Informatika Kabupaten Tulungagung”
    • NLRI 103.179.250.0/24 xuất hiện với độ dài AS path 105 vào lúc 2024-01-06 06:31:18, và khoảng 6,84 giờ sau, lúc 13:21:35, được cập nhật về độ dài 4
  • Với IPv6, độ dài AS path lớn nhất lên tới 599
    • AS path được cấu thành từ một hoặc nhiều AS set hoặc AS sequence
    • Mỗi AS sequence có độ dài tối đa 255, nên path này cần ba AS sequence
  • Ở path IPv6 dài nhất, việc prepending không do originator thực hiện mà do ISP Ukraine AS8772 NetAssist LLC thực hiện
    • Đích là route đi tới AS203868 của Indonesia, Rifqi Arief Pamungkas
    • Đây là dạng prepending để AS8772 làm cho route đó kém được ưu tiên hơn
  • Nếu nhìn vào số lượng ASN ở mọi vị trí trong 50 path dài nhất, khác biệt lớn giữa IPv4 và IPv6 có liên quan đến việc lặp lại một số ASN cụ thể

Giá trị 255 dành riêng xuất hiện trong path attribute

  • Mỗi BGP UPDATE bao gồm thông tin khả năng tiếp cận tầng mạng và path attribute
    • Ví dụ như AS_PATH, NEXT_HOP
  • RFC4271 Section 5 chia các loại BGP attribute như sau
    • well-known mandatory
    • well-known discretionary
    • optional transitive
    • optional non-transitive
  • Khi nhìn vào số lượng attribute trên toàn bộ các path IPv4, các attribute well-known mandatory là ORIGIN, NEXT_HOP và AS_PATH xuất hiện trong mọi UPDATE với số lượng như nhau
  • Các attribute phổ biến như AGGREGATOR cũng được quan sát thấy, cùng với các attribute ít phổ biến hơn như AS_PATHLIMIT và ATTR_SET
  • Một số AS gắn attribute 255 vào UPDATE
    • Giá trị này là attribute reserved for development
    • Khi đó, bgpsee chưa lưu giá trị của những path attribute hiếm như vậy
  • Qua routeviews.org, có thể xác nhận rằng một số AS vẫn gắn attribute này khi quảng bá route, và cũng có thể quan sát giá trị raw byte của nó
    • attribute 255 xuất hiện ở AS265999, AS10429 và AS52564
    • raw byte của ba ISP này có cấu trúc khá giống nhau
  • Chưa xác định được vendor nào đang dùng attribute dành riêng cho phát triển này, cũng như mục đích sử dụng là gì

Những NLRI flapping mạnh nhất

  • Các NLRI đứng đầu về số lần xuất hiện trong UPDATE, trong số những route có path thay đổi hoặc bị withdraw hoàn toàn trong ngày, đã được thống kê
  • Top 10 active NLRI và số lần xuất hiện trong UPDATE như sau
    • 140.99.244.0/23: 2.596
    • 107.154.97.0/24: 2.583
    • 45.172.92.0/22: 2.494
    • 151.236.111.0/24: 2.312
    • 205.164.85.0/24: 2.189
    • 41.209.0.0/18: 2.069
    • 143.255.204.0/22: 2.048
    • 176.124.58.0/24: 1.584
    • 187.1.11.0/24: 1.582
    • 187.1.13.0/24: 1.580
  • 140.99.244.0/23 là trường hợp biến động mạnh nhất trong ngày, và không gian địa chỉ này thuộc sở hữu của EpicUp
  • Có tổng cộng 2.879 khối 30 giây, và route này xuất hiện trong 2.637 khối dưới dạng path khác hoặc withdrawn route
    • tỷ lệ xuất hiện: {p:93}
    • tỷ lệ thực tế là 92,8%

Sự đa dạng peering thể hiện qua các path flapping

  • Để xem cách 140.99.244.0/23 flapping, tác giả dùng một đồ thị trong đó ASN của mọi path đi tới mạng này là các node, còn các cặp AS là edge
  • Path chính dường như là tuyến trung tâm đi qua NTT AS2914 và Lumen/Level3 AS3356
  • Các path dịch chuyển giữa các ISP tier 1 này và những ISP khác
    • Ví dụ có Arelion AS1299 và PCCW AS3419
  • Chỉ với dữ liệu này thì gần như không thể xác định chính xác nguyên nhân của flapping
    • Những nguyên nhân có thể gồm liên kết kém, mất điện hoặc router bị crash
  • Đồng thời, trường hợp này cũng cho thấy sự đa dạng peering của mạng toàn cầu hiện đại và khả năng phục hồi của một giao thức định tuyến đã 33 năm tuổi

Một bộ dữ liệu để lại nhiều câu hỏi hơn

  • Bộ dữ liệu này có quá nhiều chủ đề để khám phá, nên phân tích chỉ tập trung vào một số trường hợp
  • UPDATE trong bảng BGP toàn cầu có thể phản ánh các sự kiện trong thế giới thực như bất ổn chính trị, hiện tượng tự nhiên như động đất hay hỏa hoạn, hoặc sai sót của quản trị viên mạng
  • Tính kinh tế của peering Internet và yếu tố con người của các operator với năng lực rất khác nhau cũng cùng hiện diện trong những BGP UPDATE nhỏ bé đó
  • Phần lớn thời gian, BGP toàn cầu vẫn hoạt động và chuyển tải vô số thay đổi của thế giới thực thành một luồng cập nhật nhỏ đến tận laptop

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-11-27
Các ý kiến trên Hacker News

  • 25 năm trước tôi làm ở một ISP nhỏ; ban đầu chúng tôi chỉ có một ISP upstream nên tôi được giao phụ trách cấu hình multihome
    Tôi học từ một bài hướng dẫn của Avi Freedman, và nhờ đó có thể nhận một khối /20 từ ARIN rồi quảng bá route tới hai peer
    Việc học nguyên lý hoạt động thật sự rất thú vị, và càng biết nhiều thì tôi càng ngạc nhiên hơn trước sự thật rằng Internet bằng cách nào đó vẫn hoạt động được
    (1) http://avi.freedman.net/
    Avi

    • Cảm ơn! Cũng giống cơ thể người, càng nghiên cứu Internet thì điều đáng ngạc nhiên không phải là đôi khi nó hỏng, mà là bản thân việc nó có thể hoạt động
      Điều đó đặc biệt đúng với những thứ như video/điện thoại, và tôi vui vì nội dung đó có ích
      Tôi đã tập hợp một số liên kết tới các bài hướng dẫn thời đó và các bài Boardwatch cũ trên avi.net
      Động lực ban đầu thuần túy là sự bức bối với tài liệu khi ấy, nhưng tôi cũng nhanh chóng thấy rằng nếu viết bài hay để giúp người khác thì sẽ có những “phần thưởng” kiểu như “có mua được T1 không?” hay “anh vận hành mạng toàn cầu lớn của chúng tôi nhé?”
      Vì vậy đến giờ tôi vẫn luôn khuyên mọi người viết về những chủ đề gây bối rối và khó chịu
    • Tôi từng làm việc cùng Avi ở Kentik; ông ấy là người thông minh và tử tế, và tôi có ký ức tốt đẹp rằng ông ấy viết những bài này để giúp mọi người
    • Hơi lạc đề một chút, nhưng trên HN thỉnh thoảng tôi thấy cuối bình luận có chỉ một từ nằm riêng trên một dòng mới như thế này
      Tôi tự hỏi liệu bình luận có bị cắt mất, hay là lỗi copy/paste
      Cũng tò mò không biết người khác có từng thấy chưa, và liệu đó có thể là dấu vết của bình luận được tạo tự động hoặc của một công cụ cụ thể nào đó không
      Tôi chủ yếu thấy trên HN và hình như cũng từng thấy một lần trên Reddit; tần suất nhiều hơn tôi nghĩ nếu chỉ coi là trùng hợp hay sai sót đơn thuần

  • Bài viết hay, nhưng prefix 140.99.244.0/23 của EpicUp bị flapping đáng ra nên là đối tượng của route dampening
    Thông thường ISP sẽ áp rate limit theo từng peer hoặc từng prefix cho mọi peer, để ngăn một prefix đơn lẻ chiếm phần lớn biến động BGP toàn cầu
    Mối tương quan giữa các cập nhật mà tác giả xem là hiệu ứng dây chuyền không thuyết phục lắm
    Việc thay đổi quảng bá của mình dựa trên route tới prefix của hệ tự trị khác, đặc biệt là một route không ổn định, là một thiết kế khá thô
    Tôi cũng không cho là có chu kỳ 40 phút. Ít nhất khi tôi đào sâu BGP cách đây 8 năm thì không có chuyện đó; có vẻ bộ dữ liệu tình cờ trông như vậy, hoặc do đặc tính của mạng mà tác giả nhận feed BGP
    Nếu nhìn vào dữ liệu thực tế xem AS và prefix nào thay đổi, chúng rải rác khắp nơi và hầu như không có mẫu hình lớn
    Vào bất kỳ ngày nào cũng có vài ISP ồn ào vì sự cố đường truyền hoặc lỗi cấu hình, xen lẫn với việc prefix ra vào khi dịch vụ mới được đưa lên lần đầu, hoặc route thay đổi do bảo trì draining thông thường
    Việc một máy xúc ở một ISP nhỏ tại Kansas cắt đứt cáp quang lại hiện lên trên router ở Perth vừa hấp dẫn vừa hơi đáng sợ, đồng thời nhờ rất nhiều chính sách thủ công mà tần suất cập nhật toàn cầu vẫn được giữ ở mức dưới 10Hz

    • Trong các mạng ngày nay, route dampening phần lớn đã hết thịnh hành
      Lý do là nhiều cấu hình từng bị thiết lập sai nghiêm trọng, và router hiện nay cũng không còn bị bóp nghẹt CPU đến cực độ như trước
      Tất nhiên nó chưa biến mất hoàn toàn; khi tôi làm BGP Battleships(https://blog.benjojo.co.uk/post/bgp-battleships), 3356 lúc đó đang dùng route dampening nên tôi đã phải tạm dừng chơi

  • Nếu muốn học BGP, đặc biệt là muốn biết hoạt động thường nhật trong bối cảnh peering, loạt video Network Startup Resource Center của University of Oregon rất hay
    https://learn.nsrc.org/bgp

  • Tìm nhanh thì có vẻ thuộc tính BGP dành riêng 0xff nhiều khả năng là hành vi đặc thù của Huawei
    Phần lớn 0xff thấy trên bgp.tools đều theo cùng định dạng như trong bài, và một số mạng trong đó dường như dùng thiết bị Huawei

  • Tôi học được khá nhiều điều chưa biết về BGP từ bài này, và điều thú vị nhất là nó vận hành một cách hỗn loạn như vậy
    Tôi cũng muốn đọc các bài tiếp theo đào sâu hơn

  • Trước đây tôi từng thiết kế và cấu hình một mạng lai vệ tinh–vi ba cho một khách hàng lớn của Mỹ có các văn phòng hiện trường quanh khu vực Borneo
    Tôi vẫn không quên lần làm việc bàn giao leased line ở Jakarta
    Vì hoàn toàn không có kinh nghiệm kiểu này, tôi tìm thử thì thấy người ta nói dùng BGP khi nối mạng OSPF/UBNT của chúng tôi với WAN doanh nghiệp IGRP/Cisco của khách hàng
    Khi nhờ bên Tata cấu hình BGP trên router, phản ứng của họ là “các anh tưởng mình là AT&T chắc?”
    Cho đến trước khi phần lớn AirFiber của chúng tôi hỏng sau một mùa sấm sét, chúng tôi cũng hơi có cảm giác như vậy thật

  • Tôi đã viết một script Python để trích xuất dữ liệu từ các file MRT chứa route BGP ở [1], rồi nhập vào Neo4j để khám phá
    File này có khoảng 56 triệu route với mức trùng lặp cực cao, và Neo4j rất phù hợp để “merge” xử lý kiểu dữ liệu này
    [1] https://data.ris.ripe.net/rrc00/

  • Cách dễ nhất để một người bình thường truy cập trực tiếp dữ liệu BGP là gì? Tôi không quen ai ở ISP nhưng muốn thử phân tích tương tự

  • Nếu theo thời gian thấy một hành vi mang tính chu kỳ nào đó trong các cập nhật IPv4, cả ở thay đổi route lẫn không gian IP, thì có phải nghĩa là Internet cũng có thứ giống thủy triều không?

  • Sẽ thật tốt nếu sáng kiến Memory Safety, vốn xử lý việc tái triển khai hạ tầng Internet cốt lõi bằng Rust để tăng bảo mật và an toàn, cũng đảm nhận cả phần triển khai máy chủ BGP
    [1] https://www.memorysafety.org/