หนึ่งวันในชีวิตประจำวัน: ตาราง BGP ทั่วโลก

 (articles.foletta.org)
2 คะแนน โดย GN⁺ 2024-11-27 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • จาก BGP UPDATE 464,673 รายการ ที่ได้รับภายในหนึ่งวันจากเพียร์ที่มีตาราง BGP ครบถ้วน มีการสังเกตความผันผวนระยะสั้นของตารางเราต์ติ้งทั่วโลก แทนที่จะดูแนวโน้มการเติบโตระยะยาว
  • ทันทีหลังการเพียร์ เส้นทางทั้งหมดและ NLRI ถูกส่งเข้ามาเป็นก้อนภายในประมาณ 5 วินาที และจำนวน route ที่เชื่อมกับเส้นทางเริ่มต้นมี 949,483 รายการ
  • หลังจากนั้น UPDATE ถูกส่งมาเป็นชุดตามช่วง Route Advertisement Interval 30 วินาที โดยพบการอัปเดตเส้นทางประมาณ 50 รายการทุก 30 วินาทีสำหรับ IPv4 และประมาณ 47 รายการสำหรับ IPv6
  • ใน IPv4 พบความสัมพันธ์เป็นคาบประมาณ 40 นาที ทั้งในจำนวนเส้นทางและการเปลี่ยนแปลงของพื้นที่แอดเดรส แต่สาเหตุยังคงเป็นคำถามที่ยังไม่ได้คำตอบ
  • การทำ AS path prepending มากเกินไป, path attribute 255 ที่ถูกสงวนไว้, และการ flapping อย่างหนักของ NLRI บางรายการ แสดงให้เห็นทั้งความซับซ้อนและความยืดหยุ่นของการดำเนินงาน BGP ทั่วโลก

การสังเกตตาราง BGP ในระดับหนึ่งวัน

  • การวิเคราะห์ตาราง BGP ทั่วโลกมักมุ่งไปที่ แนวโน้มระดับหลายเดือนหรือหลายปี เช่น การเติบโตของตารางเราต์ติ้ง หรือการนำ IPv6 มาใช้
  • การวิเคราะห์นี้ดูว่า เมื่อเราเตอร์ได้รับอัปเดต BGP ของอินเทอร์เน็ตที่เปลี่ยนแปลงอยู่ตลอดโดยตรง ภายในหนึ่งวันมีความผันผวนระยะสั้นแบบใดเกิดขึ้นบ้าง
  • หัวข้อที่สังเกตแบ่งเป็นสามส่วน
    • กระแส UPDATE ทั่วไปตลอดหนึ่งวัน
    • path attribute ที่ผิดปกติ
    • flappy path ที่เปลี่ยนบ่อย

การเก็บข้อมูลและ bgpsee

  • แทนที่จะแยกวิเคราะห์เอาต์พุตดีบักของเราเตอร์โดยตรง ผู้เขียนนำ BGP daemon ที่เคยทำค้างไว้ในอดีตมาปรับให้ใช้งานได้ แล้วใช้ bgpsee
  • bgpsee เป็นเครื่องมือ BGP peering แบบมัลติเธรดสำหรับ CLI ซึ่งหลังจากเพียร์กับเราเตอร์อื่นแล้วจะแยกวิเคราะห์ข้อความ BGP และส่งออกเป็น JSON
    • ข้อความที่ประมวลผลคือ OPEN, KEEPALIVE และ UPDATE
    • UPDATE อาจมี path attribute เช่น NLRI, withdrawn routes, ORIGIN, AS_PATH, NEXT_HOP, AS4_PATH
  • ชุดข้อมูลถูกรวบรวมตั้งแต่วันที่ 6 มกราคม 2024 ถึง 7 มกราคม 2024 และประกอบด้วย BGP UPDATE 464,673 รายการ ที่ได้รับจากเพียร์ที่มีตาราง BGP ครบถ้วน

การส่งข้อมูลครบชุดครั้งแรกและจำนวนเส้นทาง

  • เมื่อเริ่ม BGP peering ครั้งแรก เส้นทางทั้งหมดในตาราง BGP ของเราเตอร์และ NLRI ที่เกี่ยวข้องจะถูกส่งมาเป็น UPDATE ชุดใหญ่
  • ชุดเริ่มต้นนี้ถูกรับภายในประมาณ 5 วินาที หลังเริ่ม peering
  • หลังจากนั้นจะได้รับเฉพาะ UPDATE สำหรับเส้นทางที่เปลี่ยนแปลง หรือ withdrawn routes ที่ไม่มีเส้นทางอีกต่อไป
  • ชุดเริ่มต้นและ UPDATE หลังจากนั้นมีโครงสร้างเหมือนกัน ต่างกันที่เวลาที่ได้รับและขอบเขตของข้อมูล
  • จุดสำคัญคือการแยกความหมายระหว่าง path กับ route
    • path คือหน่วย BGP UPDATE หนึ่งรายการที่มีชุด path attribute และ NLRI ที่เชื่อมอยู่กับชุดนั้น
    • path หนึ่งรายการอาจเชื่อมกับ route หนึ่งรายการหรือหนึ่งพันรายการก็ได้
    • จำนวน route ที่เชื่อมกับ path ทั้งหมดในชุดเริ่มต้นคือ 949,483 รายการ

กระแส UPDATE ราย 30 วินาที

  • หลังจากการส่งข้อมูลครบชุดครั้งแรก UPDATE ไม่ได้เข้ามาเหมือนสตรีมแบบเรียลไทม์ แต่ถูกส่งเป็นชุดตามตัวจับเวลา Route Advertisement Interval
  • ใน peering นี้ Route Advertisement Interval คือ 30 วินาที
  • จำนวน UPDATE เฉลี่ยที่สังเกตได้มีดังนี้
    • IPv4: ประมาณ 50 การอัปเดตเส้นทาง ทุก 30 วินาที
    • IPv6: ประมาณ 47 การอัปเดตเส้นทาง ทุก 30 วินาที
  • แม้ค่าเฉลี่ยจะใกล้เคียงกัน แต่ช่วงความผันผวนของ IPv4 มากกว่า
    • ส่วนเบี่ยงเบนมาตรฐานของ IPv4: 64.3
    • ส่วนเบี่ยงเบนมาตรฐานของ IPv6: 43
  • นอกจากการนับ UPDATE แบบง่าย ๆ ยังมีการคำนวณปริมาณรวมของพื้นที่ IP address ที่เปลี่ยนทุก 30 วินาทีด้วย
    • นำจำนวน IP address ที่รวมอยู่ในแต่ละ UPDATE มาบวกกันทั้งหมด แล้วใช้ log2()
    • ตัวอย่างคือแปลง /22, /23, /24 เป็นจำนวนแอดเดรสแต่ละรายการ แล้วบวกก่อนนำไปหาลอการิทึม
  • เมื่อดูจากพื้นที่แอดเดรส IPv4 โดยเฉลี่ยทุก 30 วินาทีมีแอดเดรสประมาณ 2^16 รายการ หรือประมาณ /16 ที่เปลี่ยนเส้นทางในตารางเราต์ติ้งทั่วโลก
  • ในช่วง 95% พื้นที่แอดเดรส IPv4 ที่เปลี่ยนอยู่ระหว่างประมาณ 2^20.75 ถึง 2^13.85
    • เทียบได้คร่าว ๆ กับช่วง /11 ถึง /18

คาบ 40 นาทีของอัปเดต IPv4

  • ทั้งการเปลี่ยนแปลงของจำนวนเส้นทางและพื้นที่ IP address ใน IPv4 UPDATE แสดง พฤติกรรมเป็นวัฏจักร
  • เพื่อตรวจสอบคาบ มีการใช้ฟังก์ชันอัตสหสัมพันธ์ (ACF)
    • UPDATE ถูกจัดกลุ่มเป็นช่วงละ 1 นาที และ 1 lag หมายถึง 1 นาที
    • คำนวณความสัมพันธ์ระหว่างจำนวนเส้นทาง ณ เวลาปัจจุบันกับจำนวนเส้นทางในอดีตตามแต่ละ lag
  • ในช่วงประมาณ 7 lag แรกพบความสัมพันธ์สูง
    • สอดคล้องกับประเด็นที่การเปลี่ยนแปลงของเส้นทางอาจแพร่กระจายไปทั่วโลกและก่อให้เกิดการเปลี่ยนแปลงเส้นทางอื่น ๆ ได้
  • ที่ lag 40 และ 41 ก็พบความสัมพันธ์สูงเช่นกัน ยืนยันพฤติกรรมเป็นคาบประมาณ 40 นาที
  • สาเหตุของคาบ 40 นาทีนี้ยังคงเป็นคำถามที่ยังตอบไม่ได้

กรณี AS path prepending มากเกินไป

  • ผู้ดูแลเครือข่ายสามารถใช้หลายวิธีเพื่อปรับว่าทราฟฟิกจะเข้ามายัง ASN ของตนอย่างไร
    • วิธีใช้ network prefix ที่ยาวขึ้นมีความสามารถในการขยายตัวไม่ดี และในมุมมองของ BGP ก็ไม่พึงประสงค์
    • MED attribute เป็นแบบ non-transitive จึงมีข้อจำกัดเมื่อ peering กับหลาย AS
    • โดยทั่วไปจะลดความพึงประสงค์ของเส้นทางด้วย AS path prepending คือเติม AS ของตนเองซ้ำหลายครั้งไว้ด้านหน้าสำหรับเพียร์บางราย
  • ในชุดข้อมูล ความยาว AS path ของ IPv4 ที่ยาวที่สุดคือ 105
    • ถือว่าเป็นค่ามาก เมื่อพิจารณาว่าความยาวเส้นทางที่ยาวที่สุดโดยไม่มี prepending คือ 14
    • เส้นทาง IPv4 นี้มีต้นทางจาก AS149381 “Dinas Komunikasi dan Informatika Kabupaten Tulungagung” ในอินโดนีเซีย
    • NLRI 103.179.250.0/24 ดังกล่าวปรากฏเมื่อวันที่ 6 มกราคม 2024 เวลา 06:31:18 ด้วยความยาว AS path 105 และถูกอัปเดตเป็นความยาว 4 ในเวลา 13:21:35 หรือประมาณ 6.84 ชั่วโมง หลังจากนั้น
  • สำหรับ IPv6 ความยาว AS path ที่ยาวที่สุดสูงถึง 599
    • AS path ประกอบด้วย AS set หรือ AS sequence หนึ่งรายการขึ้นไป
    • ความยาวสูงสุดของแต่ละ AS sequence คือ 255 ดังนั้นเส้นทางนี้จึงต้องใช้ AS sequence สามรายการ
  • ในเส้นทาง IPv6 ที่ยาวที่สุด ผู้ที่ทำ prepending ไม่ใช่ originator แต่เป็น AS8772 NetAssist LLC ซึ่งเป็น ISP ในยูเครน
    • เป้าหมายคือเส้นทางไปยัง AS203868, Rifqi Arief Pamungkas ในอินโดนีเซีย
    • เป็นรูปแบบที่ AS8772 ทำ prepending เพื่อทำให้เส้นทางนั้นมีความพึงประสงค์น้อยลง
  • เมื่อดูจำนวน ASN ในทุกตำแหน่งของเส้นทางที่ยาวที่สุด 50 อันดับแรก ความแตกต่างใหญ่ระหว่าง IPv4 และ IPv6 เชื่อมโยงกับการใช้ ASN บางตัวซ้ำ ๆ

ค่า 255 ที่ถูกสงวนไว้ใน Path attribute

  • BGP UPDATE แต่ละรายการประกอบด้วยข้อมูลการเข้าถึงได้ในชั้นเครือข่ายและ path attribute
    • ตัวอย่างเช่น AS_PATH, NEXT_HOP เป็นต้น
  • RFC4271 Section 5 แบ่งชนิดของ BGP attribute ไว้ดังนี้
    • well-known mandatory
    • well-known discretionary
    • optional transitive
    • optional non-transitive
  • เมื่อดูจำนวน attribute ในเส้นทาง IPv4 ทั้งหมด attribute แบบ well-known mandatory อย่าง ORIGIN, NEXT_HOP, AS_PATH มีอยู่ในทุก UPDATE และปรากฏในจำนวนเท่ากัน
  • นอกจากนี้ยังพบ attribute ที่พบบ่อยอย่าง AGGREGATOR และ attribute ที่พบน้อยกว่าอย่าง AS_PATHLIMIT, ATTR_SET
  • บาง AS ใส่ attribute 255 ใน UPDATE
  • ผ่าน routeviews.org สามารถยืนยันได้ว่าบาง AS ยังประกาศเส้นทางโดยแนบ attribute นี้อยู่ และยังสังเกตค่า raw byte ได้ด้วย
    • พบ attribute 255 ใน AS265999, AS10429, AS52564
    • ค่า raw byte ของ ISP ทั้งสามมีโครงสร้างคล้ายกัน
  • ยังไม่สามารถยืนยันได้ว่า vendor รายใดกำลังใช้ attribute ที่สงวนไว้สำหรับการพัฒนา และใช้เพื่ออะไร

NLRI ที่ flapping รุนแรงที่สุด

  • มีการรวบรวม NLRI อันดับต้น ๆ ที่ถูกรวมอยู่ใน UPDATE มากที่สุดในบรรดา route ที่เส้นทางเปลี่ยนหรือถูก withdraw อย่างสมบูรณ์ภายในหนึ่งวัน
  • NLRI ที่ active 10 อันดับแรกและจำนวนครั้งที่ถูกรวมใน UPDATE มีดังนี้
    • 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 เป็นกรณีที่ผันผวนรุนแรงที่สุดในวันนั้น และพื้นที่แอดเดรสดังกล่าวเป็นของ EpicUp
  • บล็อก 30 วินาทีทั้งหมดมี 2,879 บล็อก และ route นี้ปรากฏใน 2,637 บล็อก ในรูปแบบเส้นทางอื่นหรือ withdrawn route
    • อัตราการปรากฏ: {p:93}
    • อัตราจริงคือ 92.8%

ความหลากหลายของ peering ที่เส้นทาง flapping แสดงให้เห็น

  • เพื่อดูรูปแบบการ flapping ของ 140.99.244.0/23 มีการใช้กราฟที่กำหนดให้ ASN ของ path ทั้งหมดไปยังเครือข่ายดังกล่าวเป็นโหนด และคู่ AS เป็นเอดจ์
  • เส้นทางหลักดูเหมือนเป็นเส้นทางกลางที่ผ่าน NTT AS2914 และ Lumen/Level3 AS3356
  • เส้นทางเคลื่อนไปมาระหว่าง ISP tier 1 เหล่านี้กับ ISP รายอื่น
    • ตัวอย่างรวมถึง Arelion AS1299, PCCW AS3419
  • จากข้อมูลนี้เพียงอย่างเดียว แทบเป็นไปไม่ได้ที่จะระบุสาเหตุที่แน่ชัดของการ flapping
    • สาเหตุที่เป็นไปได้ซึ่งถูกกล่าวถึง ได้แก่ ลิงก์เสีย ไฟดับ เราเตอร์ล่ม
  • ขณะเดียวกัน กรณีนี้ก็แสดงให้เห็น ความหลากหลายของ peering ในเครือข่ายทั่วโลกยุคใหม่ และความยืดหยุ่นของโปรโตคอลเราต์ติ้งที่มีอายุ 33 ปี

ชุดข้อมูลที่ยังเหลือคำถามอีกมาก

  • ชุดข้อมูลนี้มีหัวข้อให้สำรวจมากมายเกินไป การวิเคราะห์จึงมุ่งเน้นเพียงบางกรณี
  • UPDATE ของตาราง BGP ทั่วโลกอาจสะท้อนเหตุการณ์ในโลกจริง เช่น ความไม่สงบทางการเมือง ปรากฏการณ์ธรรมชาติอย่างแผ่นดินไหวหรือไฟไหม้ หรือความผิดพลาดของผู้ดูแลเครือข่าย
  • เศรษฐศาสตร์ของ internet peering และปัจจัยด้านมนุษย์ของผู้ปฏิบัติงานที่มีขีดความสามารถต่างกัน ก็รวมอยู่ใน BGP UPDATE เล็ก ๆ เหล่านี้ด้วย
  • BGP ทั่วโลกทำงานได้แทบตลอดเวลา และส่งผ่านความเปลี่ยนแปลงมากมายในโลกจริงมายังแล็ปท็อปในรูปแบบสตรีมอัปเดตขนาดเล็ก

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-11-27
ความคิดเห็นบน Hacker News

  • เมื่อ 25 ปีก่อนผมทำงานที่ ISP ขนาดเล็ก ตอนแรกมี upstream ISP แค่รายเดียว เลยได้รับหน้าที่ทำ คอนฟิกแบบ multihome
    ผมเรียนจากทูโทเรียลที่ Avi Freedman เขียน และด้วยเหตุนี้จึงได้ /20 จาก ARIN แล้วสามารถประกาศเส้นทางไปยัง peer สองรายได้
    การได้เรียนรู้หลักการทำงานของมันน่าสนใจมาก และยิ่งรู้มากขึ้นก็ยิ่งทึ่งกับข้อเท็จจริงที่ว่า อินเทอร์เน็ตยังไงก็ยังทำงานได้
    (1) http://avi.freedman.net/
    Avi

    • ขอบคุณครับ! คล้ายกับร่างกายมนุษย์ ยิ่งศึกษาอินเทอร์เน็ตก็ยิ่งรู้สึกทึ่งว่าไม่ใช่แค่มันพังเป็นบางครั้ง แต่คือ การที่มันทำงานได้เลยต่างหาก
      โดยเฉพาะกับอย่างวิดีโอ/โทรศัพท์ และดีใจที่คอนเทนต์มีประโยชน์
      ผมรวบรวมลิงก์บางส่วนไปยังทูโทเรียลสมัยนั้นและบทความเก่าใน Boardwatch ไว้ที่ avi.net
      แรงจูงใจล้วน ๆ คือความหงุดหงิดกับเอกสารในตอนนั้น แต่ก็เห็นได้เร็วว่า ถ้าเขียนบทความดี ๆ ช่วยคนได้ ก็มีผลตอบแทนกลับมาอย่าง “ซื้อ T1 ได้ไหม?” หรือ “ช่วยดูแลเครือข่ายโกลบอลขนาดใหญ่ของเราได้ไหม?”
      ดังนั้นตอนนี้ผมยังคงแนะนำให้เขียนเรื่องที่ทำให้สับสนและน่าหงุดหงิดต่อไป
    • เคยทำงานกับ Avi ที่ Kentik เขาเป็นคนฉลาดและเป็นคนดี และผมจำได้ดีว่าเขาเขียนบทความเหล่านี้เพื่อช่วยผู้คน
    • ออกนอกเรื่องนิดหน่อย แต่บน HN บางครั้งผมเห็นมี คำเดียวอยู่บรรทัดใหม่ แบบนี้ที่ท้ายคอมเมนต์
      เลยสงสัยว่าคอมเมนต์ถูกตัดหรือเปล่า หรือคัดลอก/วางผิด
      อยากรู้ด้วยว่าคนอื่นเคยเห็นไหม และมันอาจเป็นร่องรอยของคอมเมนต์ที่ถูกสร้างขึ้นหรือการใช้เครื่องมือบางอย่างหรือเปล่า
      ผมเห็นหลัก ๆ บน HN และเหมือนเคยเห็นบน Reddit สักครั้ง แต่ดูเกิดบ่อยกว่าจะมองว่าเป็นแค่ความบังเอิญหรือความผิดพลาดธรรมดา

  • เป็นบทความที่ดี แต่การที่ prefix 140.99.244.0/23 ของ EpicUp flap น่าจะควรถูกจัดการด้วย route dampening
    โดยทั่วไป ISP จะตั้ง rate limit แบบต่อ peer หรือแบบต่อ prefix ให้กับทุก peer เพื่อป้องกันไม่ให้ prefix เดียวกลายเป็นสัดส่วนใหญ่ของความผันผวน BGP ทั่วโลก
    ความสัมพันธ์ระหว่างอัปเดตที่ผู้เขียนมองว่าเป็นผลกระทบลูกโซ่นั้นยังไม่น่าเชื่อถือมากนัก
    การเปลี่ยนโฆษณาเส้นทางของตัวเองโดยอิงจากเส้นทางไปยัง prefix ของ autonomous system อื่น โดยเฉพาะเส้นทางที่ไม่เสถียร เป็นการออกแบบที่ค่อนข้างหยาบ
    ผมก็ไม่คิดว่ามีคาบ 40 นาที อย่างน้อยตอนที่ผมลงลึกกับ BGP เมื่อ 8 ปีก่อนก็ไม่มีอะไรแบบนั้น และรู้สึกว่าอาจเป็นเพราะชุดข้อมูลบังเอิญดูเป็นแบบนั้น หรือเป็นลักษณะของเครือข่ายที่ผู้เขียนรับ BGP feed มา
    ถ้าดูข้อมูลจริงว่า AS และ prefix ไหนเปลี่ยนบ้าง จะเห็นว่ากระจัดกระจายไปทั่วและแทบไม่มีแพตเทิร์นใหญ่ ๆ
    ไม่ว่าวันไหนก็ตาม จะมี ISP บางเจ้าเสียงดังเพราะปัญหาสายหรือคอนฟิกผิด มี prefix เข้า ๆ ออก ๆ ตอนเปิดบริการใหม่ครั้งแรก หรือมีการเปลี่ยนเส้นทางจากงานบำรุงรักษาแบบ draining ทั่วไปปะปนกัน
    การที่แบ็กโฮใน ISP เล็ก ๆ ที่แคนซัสตัดสายไฟเบอร์ แล้วเรื่องนั้นไปปรากฏให้เห็นบนเราเตอร์ในเพิร์ท เป็นเรื่องทั้งน่าหลงใหลและน่ากลัวเล็กน้อย ขณะเดียวกันด้วยนโยบายที่ทำด้วยมือจำนวนมาก ก็ทำให้ความถี่อัปเดตทั่วโลกยังคงอยู่ที่ ต่ำกว่า 10Hz

    • ในเครือข่ายสมัยนี้ route dampening ส่วนใหญ่ตกยุคไปแล้ว
      เพราะคอนฟิกจำนวนมากเคยตั้งผิดอย่างรุนแรง และเราเตอร์ส่วนใหญ่ก็ไม่ได้ขาดแคลน CPU อย่างหนักเหมือนเมื่อก่อนแล้ว
      แน่นอนว่าไม่ได้หายไปหมด ตอนที่ผมทำ BGP Battleships(https://blog.benjojo.co.uk/post/bgp-battleships) นั้น 3356 ยังทำ route dampening อยู่ในตอนนั้น เลยต้องหยุดเล่นไปชั่วคราว

  • ถ้าอยากเรียน BGP โดยเฉพาะถ้าอยากรู้การปฏิบัติงานประจำวันในสถานการณ์ peering วิดีโอซีรีส์ของ Network Startup Resource Center แห่ง University of Oregon ดีมาก
    https://learn.nsrc.org/bgp

  • จากที่ลองค้นเร็ว ๆ แอตทริบิวต์ BGP ที่สงวนไว้ 0xff น่าจะเป็น พฤติกรรมเฉพาะของ Huawei
    0xff ส่วนใหญ่ที่เห็นใน bgp.tools ใช้รูปแบบเดียวกับที่อยู่ในบทความ และบางเครือข่ายในนั้นดูเหมือนจะใช้อุปกรณ์ Huawei

  • บทความนี้ทำให้ผมได้เรียนรู้อะไรเกี่ยวกับ BGP ที่ไม่เคยรู้ค่อนข้างมาก และสิ่งที่น่าสนใจที่สุดคือมัน ทำงานไปแบบวุ่นวายขนาดนี้
    อยากอ่านบทความภาคต่อที่ขุดลึกกว่านี้ด้วย

  • เมื่อก่อนเคยออกแบบและตั้งค่า เครือข่ายไฮบริดดาวเทียม-ไมโครเวฟ ให้ลูกค้ารายใหญ่ของสหรัฐฯ ที่มีสำนักงานภาคสนามแถบเกาะบอร์เนียว
    ผมไม่ลืมงาน handoff วงจร leased line ที่ Jakarta เลย
    เพราะไม่มีประสบการณ์แบบนี้เลย ลองค้นดูแล้วพบว่าเวลาจะเชื่อมเครือข่าย OSPF/UBNT ของเรากับ WAN องค์กร IGRP/Cisco ของลูกค้า จะใช้ BGP
    พอขอให้คนฝั่ง Tata ตั้งค่า BGP บนเราเตอร์ให้ พวกเขาตอบประมาณว่า “นึกว่าตัวเองเป็น AT&T หรือไง?”
    ก่อนที่ AirFiber ส่วนใหญ่ของเราจะพังในฤดูฟ้าผ่าหนึ่งฤดู เราก็รู้สึกแบบนั้นอยู่เหมือนกัน

  • ผมทำสคริปต์ Python เพื่อดึงข้อมูลจากไฟล์ MRT ที่มีเส้นทาง BGP ใน [1] แล้วนำเข้าไปสำรวจใน Neo4j
    ไฟล์นี้มีเส้นทางประมาณ 56 ล้านรายการที่ซ้ำกันอย่างมหาศาล และ Neo4j เหมาะกับการ “merge” ข้อมูลแบบนี้
    [1] https://data.ris.ripe.net/rrc00/

  • วิธีที่ง่ายที่สุดที่คนทั่วไปจะเข้าถึงข้อมูล BGP โดยตรงคืออะไร? ผมไม่มีคนรู้จักใน ISP แต่อยากลองวิเคราะห์คล้าย ๆ กัน

  • ถ้าเมื่อเวลาผ่านไปเห็น พฤติกรรมเป็นวัฏจักร บางอย่างในอัปเดต IPv4 ทั้งด้านเส้นทางและการเปลี่ยนแปลงของพื้นที่ IP นั่นหมายความว่าอินเทอร์เน็ตก็มีอะไรคล้ายกระแสน้ำขึ้นน้ำลงหรือเปล่า?

  • คงดีถ้าโครงการ Memory Safety ที่จัดการความปลอดภัยและเสถียรภาพของโครงสร้างพื้นฐานอินเทอร์เน็ตหลักด้วยการนำมาเขียนใหม่ใน Rust จะรับทำ implementation ของเซิร์ฟเวอร์ BGP ด้วย
    [1] https://www.memorysafety.org/