บทนำ: ทำไม BGP ถึงเป็นโปรโตคอลที่สำคัญที่สุดของอินเทอร์เน็ต
หากจะมีโปรโตคอลใดที่ถูกเรียกว่าเป็น “กาวที่ยึดอินเทอร์เน็ตเข้าด้วยกัน” โปรโตคอลนั้นก็คือ BGP หรือ Border Gateway Protocol อินเทอร์เน็ตทั่วโลกที่เราใช้กันทุกวันนี้ประกอบด้วยเครือข่ายอิสระนับหมื่นเครือข่าย ตั้งแต่ ISP ขนาดเล็กในต่างจังหวัดไปจนถึง Hyperscaler อย่าง Google, Amazon และ Microsoft เครือข่ายเหล่านี้ต้องแลกเปลี่ยนข้อมูลเส้นทาง (Routing Information) ระหว่างกันเพื่อให้แพ็กเก็ตข้อมูลเดินทางข้ามเครือข่ายได้อย่างถูกต้อง BGP คือโปรโตคอลที่ทำหน้าที่นี้ทั้งหมด
ในปี 2026 อินเทอร์เน็ตมี Route มากกว่า 1 ล้าน Prefix ใน Global Routing Table และมี Autonomous System Number (ASN) ที่ Active อยู่มากกว่า 80,000 ระบบ ทั้งหมดนี้พึ่งพา BGP ในการแลกเปลี่ยนข้อมูลเส้นทาง หาก BGP หยุดทำงาน อินเทอร์เน็ตทั้งระบบจะล่มในทันที ตัวอย่างที่เห็นได้ชัดคือเหตุการณ์ Facebook Outage ในเดือนตุลาคม 2021 ที่ BGP Withdrawal ทำให้ Facebook, Instagram, WhatsApp ล่มพร้อมกันนานกว่า 6 ชั่วโมง สร้างความเสียหายมหาศาล
สำหรับ IT Admin และ Network Engineer ในประเทศไทย ความเข้าใจ BGP มีความสำคัญอย่างยิ่ง ไม่ว่าจะทำงานใน ISP, Enterprise ที่ต้องการ Multihoming, Data Center หรือแม้แต่ Cloud Provider ที่ต้อง Peer กับ ISP ในไทย บทความนี้จะอธิบาย BGP อย่างครบถ้วนตั้งแต่พื้นฐานไปจนถึงการ Configure, Troubleshoot และ Security ที่เกี่ยวข้อง
BGP คืออะไร และทำไมต้อง BGP
ความหมายของ Border Gateway Protocol
BGP (Border Gateway Protocol) คือ Exterior Gateway Protocol (EGP) ที่ใช้แลกเปลี่ยน Routing Information ระหว่าง Autonomous Systems (AS) บนอินเทอร์เน็ต BGP เป็น Path Vector Protocol ซึ่งต่างจาก Interior Gateway Protocol (IGP) อย่าง OSPF ที่เป็น Link-State หรือ EIGRP ที่เป็น Distance Vector ตรงที่ BGP ใช้ AS-Path เป็นเกณฑ์หลักในการเลือกเส้นทาง แทนที่จะใช้ Metric อย่าง Cost หรือ Bandwidth
Autonomous System (AS) คือกลุ่มของ Network หรือ IP Prefix ที่อยู่ภายใต้การบริหารจัดการของหน่วยงานเดียวกัน และมี Routing Policy เดียวกัน แต่ละ AS จะได้รับ AS Number (ASN) จาก Regional Internet Registry (RIR) เช่น APNIC สำหรับภูมิภาคเอเชียแปซิฟิก ASN เปรียบเสมือน “ที่อยู่” ของแต่ละเครือข่ายบนอินเทอร์เน็ต ตัวอย่างเช่น TRUE มี ASN 7470, AIS มี ASN 131090, 3BB มี ASN 45758
BGP Version ปัจจุบันคือ BGP-4 ที่กำหนดไว้ใน RFC 4271 ซึ่งรองรับ Classless Inter-Domain Routing (CIDR) และ Aggregation ทำให้สามารถรองรับอินเทอร์เน็ตที่มีขนาดใหญ่ได้ BGP-4 รองรับทั้ง IPv4 และ IPv6 (ผ่าน Multiprotocol Extensions – MP-BGP ตาม RFC 4760)
BGP เปรียบเทียบกับ IGP (OSPF, EIGRP)
การเปรียบเทียบ BGP กับ IGP เป็นสิ่งสำคัญที่ Network Engineer ต้องเข้าใจ IGP เช่น OSPF และ EIGRP ออกแบบมาเพื่อ Route Traffic ภายใน AS เดียวกัน โดยเน้นการ Converge เร็วและเลือกเส้นทางที่ดีที่สุดตาม Metric เช่น Cost ใน OSPF หรือ Composite Metric ใน EIGRP ในขณะที่ BGP ออกแบบมาเพื่อ Route Traffic ระหว่าง AS โดยเน้น Policy-based Routing มากกว่า Shortest Path
OSPF ใช้ SPF Algorithm (Dijkstra) ในการคำนวณ Shortest Path Tree และใช้ Link-State Database ที่ทุก Router ภายใน Area เดียวกันจะมีข้อมูลเหมือนกัน OSPF เหมาะกับ Network ภายในองค์กรที่มี Router จำนวนหลายสิบถึงหลายร้อยตัว แต่ไม่เหมาะกับอินเทอร์เน็ตที่มี Router นับแสนตัว เพราะ Link-State Database จะใหญ่เกินไป
EIGRP ใช้ DUAL Algorithm และเป็น Cisco Proprietary (แม้ว่าจะเปิดเป็น Standard แล้วใน RFC 7868 แต่ในทางปฏิบัติยังใช้กับอุปกรณ์ Cisco เป็นหลัก) EIGRP Converge เร็วมากเพราะมี Feasible Successor เก็บไว้เป็น Backup Route สามารถ Failover ได้ทันทีโดยไม่ต้องคำนวณใหม่ แต่ EIGRP ก็เหมาะกับ Network ภายในเท่านั้น
BGP มีข้อแตกต่างหลักจาก IGP หลายประการ ประการแรก BGP ใช้ TCP Port 179 ในการสื่อสาร ทำให้มี Reliable Transport ในตัว ไม่ต้องพัฒนา Reliability Mechanism เอง ประการที่สอง BGP ส่งเฉพาะ Incremental Update (เปลี่ยนแปลงเท่านั้น) ไม่ส่ง Full Routing Table ซ้ำๆ ทำให้ประหยัด Bandwidth ประการที่สาม BGP ใช้ Path Attributes หลายตัวในการตัดสินใจเลือกเส้นทาง ทำให้ Administrator สามารถกำหนด Policy ได้อย่างละเอียด ประการที่สี่ BGP มี Convergence Time ที่ช้ากว่า IGP โดยตั้งใจ เพื่อป้องกัน Route Instability บนอินเทอร์เน็ต
AS Number: หมายเลขประจำตัวเครือข่ายบนอินเทอร์เน็ต
Public ASN vs Private ASN
AS Number (ASN) แบ่งออกเป็น 2 ประเภท คือ Public ASN และ Private ASN เหมือนกับ IP Address ที่มี Public IP และ Private IP
Public ASN คือหมายเลขที่ได้รับจัดสรรจาก RIR อย่าง APNIC สำหรับใช้บนอินเทอร์เน็ต Public ASN มี 2 ขนาด คือ 2-byte ASN (16-bit) ที่มีค่าตั้งแต่ 1 ถึง 65535 และ 4-byte ASN (32-bit) ที่มีค่าตั้งแต่ 1 ถึง 4294967295 เนื่องจาก 2-byte ASN มีจำนวนจำกัดและกำลังจะหมด ปัจจุบัน RIR จึงจัดสรร 4-byte ASN เป็นหลัก โดย 4-byte ASN จะเขียนในรูปแบบ asplain (เช่น 131090) หรือ asdot (เช่น 2.102)
Private ASN สงวนไว้สำหรับใช้ภายในองค์กร ไม่ควรปรากฏบนอินเทอร์เน็ต สำหรับ 2-byte ASN ช่วง Private คือ 64512-65534 และสำหรับ 4-byte ASN ช่วง Private คือ 4200000000-4294967294 ใช้ในกรณีที่ Enterprise ต้องการ Run BGP กับ ISP แต่ไม่ต้องการ Public ASN เช่น Enterprise ที่ Multihome กับ ISP เดียว (Single-homed Multihoming) ISP จะ Strip Private ASN ออกก่อนที่จะ Advertise ไปยังอินเทอร์เน็ต
การขอ ASN จาก APNIC
สำหรับองค์กรในประเทศไทยที่ต้องการ Public ASN จะต้องขอผ่าน APNIC หรือ National Internet Registry (NIR) ของไทย ซึ่งเงื่อนไขหลักคือต้องมีความจำเป็นในการใช้ BGP เพื่อ Multihome กับ ISP มากกว่า 1 ราย ต้องมี IP Address Block ของตัวเอง (หรือได้รับจัดสรรจาก ISP) และต้องมี Technical Staff ที่สามารถบริหาร BGP ได้ ค่าธรรมเนียมรายปีของ APNIC Account ขึ้นอยู่กับขนาดของ IP Allocation
eBGP vs iBGP: สองโหมดการทำงานของ BGP
External BGP (eBGP)
eBGP ใช้สำหรับแลกเปลี่ยน Routing Information ระหว่าง Router ที่อยู่คนละ AS กัน นี่คือรูปแบบการใช้งาน BGP ที่คนส่วนใหญ่นึกถึง เช่น ISP Peer กับ ISP อื่น หรือ Enterprise Peer กับ ISP เพื่อรับ Full Internet Route
eBGP มีคุณสมบัติสำคัญหลายอย่าง TTL ของ Packet จะถูกตั้งเป็น 1 โดย Default ซึ่งหมายความว่า eBGP Peer ต้องเชื่อมต่อกันโดยตรง (Directly Connected) ถ้าต้องการ Peer ข้ามหลาย Hop ต้องใช้ eBGP Multihop ซึ่งจะเพิ่ม TTL ให้ นอกจากนี้ eBGP จะเปลี่ยน Next-Hop ของ Route ที่ได้รับเป็น IP ของ Peer เองโดย Default และ eBGP จะเพิ่ม AS Number ของ Local AS ลงใน AS-Path ทุกครั้งที่ Advertise Route ออกไป ซึ่งเป็นกลไกป้องกัน Loop (ถ้าเห็น ASN ของตัวเองใน AS-Path จะ Reject Route นั้นทันที)
Administrative Distance (AD) ของ eBGP คือ 20 ซึ่งต่ำกว่า IGP อย่าง OSPF (110) หมายความว่า Route ที่ได้จาก eBGP จะถูก Prefer มากกว่า Route จาก OSPF ถ้ามี Destination เดียวกัน
Internal BGP (iBGP)
iBGP ใช้สำหรับแลกเปลี่ยน Routing Information ระหว่าง Router ที่อยู่ใน AS เดียวกัน iBGP จำเป็นเมื่อ AS มี Router หลายตัวที่ต้องรู้ External Route ที่ได้จาก eBGP Peer
iBGP มีกฎสำคัญที่ต่างจาก eBGP ประการแรก iBGP ไม่เปลี่ยน Next-Hop โดย Default ซึ่งหมายความว่า Route ที่ได้จาก eBGP Peer แล้ว Redistribute เข้า iBGP จะยังคง Next-Hop เป็น IP ของ eBGP Peer ซึ่ง iBGP Peer ตัวอื่นอาจไม่สามารถ Reach ได้ ต้องใช้คำสั่ง next-hop-self เพื่อเปลี่ยน Next-Hop เป็น IP ของ Router ที่ Advertise
ประการที่สอง iBGP มี Split Horizon Rule คือ Route ที่ได้จาก iBGP Peer จะไม่ถูก Advertise ต่อไปยัง iBGP Peer ตัวอื่น เพื่อป้องกัน Loop กฎนี้ทำให้ iBGP ต้องการ Full Mesh Topology ระหว่าง iBGP Peer ทั้งหมด ซึ่งสร้างปัญหา Scalability เมื่อมี Router จำนวนมาก สูตรจำนวน Session คือ n(n-1)/2 เช่น 100 Router ต้องมี 4,950 Session
วิธีแก้ปัญหา Full Mesh ของ iBGP มี 2 วิธีหลัก คือ Route Reflector (RR) และ Confederation Route Reflector ใช้ RR Client ที่ส่ง Route ไปยัง RR แล้ว RR จะ Reflect Route ไปยัง Client ตัวอื่น ลดจำนวน Session ลงเหลือ n-1 (ถ้ามี RR 1 ตัว) Confederation แบ่ง AS ใหญ่ออกเป็น Sub-AS ย่อยๆ แล้วใช้ eBGP ระหว่าง Sub-AS ซึ่งช่วยลดจำนวน iBGP Session ภายในแต่ละ Sub-AS
Administrative Distance (AD) ของ iBGP คือ 200 ซึ่งสูงกว่า IGP ทั้งหมด หมายความว่า Route จาก IGP จะถูก Prefer มากกว่า Route จาก iBGP ถ้ามี Destination เดียวกัน นี่เป็นการออกแบบโดยตั้งใจเพื่อให้ Internal Routing มีความเสถียร
BGP Neighbor Establishment: ขั้นตอนการสร้าง Peering
BGP Finite State Machine (FSM)
การสร้าง BGP Neighbor Relationship ผ่าน 6 สถานะ (State) ที่เรียกว่า BGP Finite State Machine ความเข้าใจ FSM เป็นสิ่งจำเป็นสำหรับการ Troubleshoot BGP
Idle State: เป็นสถานะเริ่มต้น BGP Process เริ่มทำงาน ค้นหา Route ไปยัง Neighbor ในตาราง Routing ถ้าพบ Route จะเริ่ม TCP Connection ไปยัง Port 179 ของ Neighbor ถ้า BGP ค้างอยู่ใน Idle State มักเกิดจาก ไม่มี Route ไปยัง Neighbor IP, ACL Block TCP Port 179, หรือ BGP Configuration ผิด
Connect State: BGP รอ TCP Three-way Handshake จะสำเร็จ ถ้า TCP Connect สำเร็จ จะส่ง Open Message และเปลี่ยนไป OpenSent State ถ้า TCP Connect ไม่สำเร็จ จะเปลี่ยนไป Active State ถ้า ConnectRetry Timer หมดเวลา จะกลับไป Connect State ใหม่
Active State: BGP กำลังพยายามสร้าง TCP Connection อีกครั้ง ถ้า BGP ค้างอยู่ใน Active State มักเกิดจาก Neighbor ไม่ได้ Configure BGP กลับมา, Firewall Block, Physical Connectivity มีปัญหา, หรือ Source IP ที่ใช้ในการ Peer ไม่ถูกต้อง
OpenSent State: BGP ได้ส่ง Open Message ไปยัง Neighbor แล้ว และกำลังรอ Open Message จาก Neighbor BGP จะตรวจสอบ Open Message ที่ได้รับว่า BGP Version ตรงกัน, Source IP ตรงกับ Neighbor ที่ Configure ไว้, AS Number ถูกต้อง, BGP Identifier (Router ID) ไม่ซ้ำกัน และ Optional Parameters (Capabilities) เข้ากันได้ ถ้าทุกอย่างตรง จะส่ง Keepalive และเปลี่ยนไป OpenConfirm State
OpenConfirm State: BGP ได้ส่ง Keepalive และรอ Keepalive จาก Neighbor ถ้าได้รับ Keepalive จะเปลี่ยนไป Established State ถ้าได้รับ Notification Message (แจ้งข้อผิดพลาด) จะกลับไป Idle State
Established State: BGP Session สร้างสำเร็จแล้ว เริ่มแลกเปลี่ยน Routing Information ผ่าน Update Message นี่คือสถานะที่ต้องการ ถ้า BGP Session อยู่ใน Established State แสดงว่า Peering ทำงานปกติ Keepalive Message จะถูกส่งทุก 60 วินาที (Default) และถ้าไม่ได้รับ Keepalive ภายใน Hold Timer (180 วินาที Default) Session จะถูก Tear Down
BGP Message Types: ประเภทข้อความใน BGP
Open Message
Open Message เป็นข้อความแรกที่ BGP Peer ส่งหลังจาก TCP Connection สร้างสำเร็จ ข้อมูลสำคัญใน Open Message ประกอบด้วย BGP Version (ปัจจุบันคือ 4), My AS Number (หมายเลข AS ของผู้ส่ง), Hold Time (เวลาที่รอก่อน Tear Down Session ถ้าไม่ได้รับ Keepalive สองฝ่ายจะ Negotiate ใช้ค่าที่ต่ำกว่า), BGP Identifier (Router ID ที่เป็น IP Address ใช้ระบุตัวตนของ BGP Router), และ Optional Parameters (Capabilities เช่น Multiprotocol Extensions, Route Refresh, 4-byte ASN Support, Graceful Restart)
Update Message
Update Message ใช้แลกเปลี่ยน Routing Information ซึ่งเป็นหัวใจสำคัญของ BGP ประกอบด้วย Withdrawn Routes (รายการ Prefix ที่ต้อง Remove ออกจาก Routing Table), Path Attributes (คุณสมบัติของเส้นทาง เช่น AS-Path, Next-Hop, Local Preference ฯลฯ), และ Network Layer Reachability Information (NLRI) (รายการ Prefix ที่สามารถ Reach ได้พร้อม Prefix Length)
Update Message อาจมีเฉพาะ Withdrawn Routes (แจ้งว่า Route ถูกถอน), เฉพาะ NLRI กับ Path Attributes (แจ้ง Route ใหม่), หรือทั้งสองอย่าง ใน BGP จะส่งเฉพาะ Update ที่เปลี่ยนแปลง (Incremental Update) ไม่ส่ง Full Table ซ้ำ ทำให้ประหยัด Bandwidth
Keepalive Message
Keepalive Message มีขนาดเล็กมาก (19 bytes เท่ากับ BGP Header) ส่งเป็นระยะ (Default ทุก 60 วินาที ซึ่งเป็น 1/3 ของ Hold Timer 180 วินาที) เพื่อแจ้งว่า BGP Peer ยังทำงานอยู่ ถ้าไม่ได้รับ Keepalive ภายใน Hold Timer ระบบจะถือว่า Peer ตายและ Tear Down Session
Notification Message
Notification Message ส่งเมื่อเกิดข้อผิดพลาดในการทำงานของ BGP เช่น Message Header Error, Open Message Error, Update Message Error, Hold Timer Expired, Finite State Machine Error หรือ Cease (เมื่อ Admin Clear Session) หลังจากส่ง Notification Message แล้ว BGP Session จะถูก Tear Down ทันที เมื่อ Troubleshoot BGP ควรดู Notification Message ใน Log เพื่อหาสาเหตุของ Session Down
BGP Path Attributes: คุณสมบัติเส้นทางที่ BGP ใช้ตัดสินใจ
ประเภทของ Path Attributes
BGP Path Attributes แบ่งออกเป็น 4 ประเภทตาม RFC ประเภทแรกคือ Well-known Mandatory ที่ทุก BGP Implementation ต้องรองรับและต้องมีใน Update Message ทุกครั้ง ได้แก่ AS-Path, Next-Hop และ Origin ประเภทที่สองคือ Well-known Discretionary ที่ทุก Implementation ต้องรองรับแต่ไม่จำเป็นต้องมีใน Update ทุกครั้ง เช่น Local Preference, Atomic Aggregate ประเภทที่สามคือ Optional Transitive ที่ไม่จำเป็นต้องรองรับทุก Implementation แต่ถ้าไม่เข้าใจก็จะ Forward ต่อ เช่น Community, Extended Community ประเภทที่สี่คือ Optional Non-transitive ที่ไม่จำเป็นต้องรองรับและจะไม่ Forward ต่อถ้าไม่เข้าใจ เช่น MED (Multi-Exit Discriminator)
AS-Path
AS-Path คือ Path Attribute ที่สำคัญที่สุดของ BGP เก็บรายการ AS Number ที่ Route ผ่าน เรียงจาก AS ที่ใกล้ที่สุดไปยัง AS ต้นทาง ตัวอย่างเช่น AS-Path 7470 4637 15169 หมายความว่า Route นี้มาจาก AS 15169 (Google) ผ่าน AS 4637 (Reach/Telstra) แล้วมาถึง AS 7470 (TRUE)
AS-Path ทำหน้าที่ 2 อย่าง คือ Loop Prevention (ถ้า Router เห็น ASN ของตัวเองใน AS-Path จะ Reject Route นั้น) และ Path Selection (Route ที่มี AS-Path สั้นกว่าจะถูก Prefer มากกว่า) นอกจากนี้ยังสามารถใช้ AS-Path Prepending เพื่อทำ Traffic Engineering โดยการเพิ่ม ASN ของตัวเองซ้ำหลายครั้งใน AS-Path เพื่อทำให้ Route ดูยาวขึ้นและ Peer อื่นจะไม่ Prefer เส้นทางนี้
Next-Hop
Next-Hop คือ IP Address ที่ Router จะส่ง Packet ไปเพื่อ Reach Destination Prefix ใน eBGP Next-Hop จะถูกเปลี่ยนเป็น IP ของ Advertising Router ทุกครั้ง แต่ใน iBGP Next-Hop จะไม่ถูกเปลี่ยนโดย Default ซึ่งอาจทำให้ iBGP Peer ไม่สามารถ Reach Next-Hop ได้ วิธีแก้ปัญหานี้คือใช้ next-hop-self บน Router ที่ Redistribute Route จาก eBGP เข้า iBGP หรือให้ IGP Advertise Subnet ของ eBGP Peer Link
Local Preference
Local Preference เป็น Attribute ที่ใช้ภายใน AS เท่านั้น (iBGP) ค่า Default คือ 100 Route ที่มี Local Preference สูงกว่าจะถูก Prefer มากกว่า Local Preference ใช้สำหรับกำหนด Outbound Traffic Policy เช่น ถ้า AS มี 2 Uplink ไปยัง ISP สามารถตั้ง Local Preference ให้ Route จาก ISP ที่ต้องการเป็น Primary สูงกว่า Route จาก ISP ที่เป็น Backup เพื่อให้ Traffic ออกทาง Primary ISP เป็นหลัก
MED (Multi-Exit Discriminator)
MED ใช้แจ้ง Neighbor AS ว่าควรส่ง Traffic เข้ามาทางไหน เมื่อมีหลาย Entry Point MED มีค่า Default เป็น 0 และ Route ที่มี MED ต่ำกว่าจะถูก Prefer MED จะถูก Compare เฉพาะ Route ที่มาจาก AS เดียวกัน (By Default) ถ้าต้องการ Compare MED จาก AS ที่ต่างกันต้องใช้ bgp always-compare-med
ตัวอย่างการใช้ MED เช่น ISP A มี 2 Peering Link กับ ISP B ที่ กรุงเทพ และ เชียงใหม่ ISP A สามารถตั้ง MED ต่ำกว่าให้ Route ที่ Advertise จากกรุงเทพ เพื่อบอก ISP B ว่าควรส่ง Traffic เข้ามาทาง Link กรุงเทพ เป็นหลัก
Community
BGP Community เป็นค่า Tag ขนาด 32-bit ที่แนบไปกับ Route เพื่อจัดกลุ่มและใช้กำหนด Policy ได้อย่างยืดหยุ่น Community เขียนในรูปแบบ ASN:Value เช่น 7470:100 มี Well-known Community ที่กำหนดไว้ใน Standard ได้แก่ no-export (ห้าม Advertise Route นี้ออกนอก AS), no-advertise (ห้าม Advertise Route นี้ให้ Peer ใดเลย), internet (Advertise ได้ทั่วไป), และ local-AS (ห้าม Advertise ออกนอก Sub-AS ใน Confederation)
ISP ในประเทศไทยส่วนใหญ่มี Community ที่กำหนดไว้ให้ลูกค้าใช้ เช่น Community สำหรับ Blackhole (Drop Traffic ไปยัง Prefix ที่ถูกโจมตี DDoS), Community สำหรับกำหนด Local Preference บน ISP Router (เพื่อควบคุม Inbound Traffic ของลูกค้า), Community สำหรับ Prepend AS-Path เมื่อ ISP Advertise ต่อ
Weight (Cisco Proprietary)
Weight เป็น Attribute พิเศษของ Cisco ที่มี Priority สูงสุดในการเลือก Path Weight มีค่า Default 0 สำหรับ Route ที่ได้จาก Neighbor และ 32768 สำหรับ Route ที่ Originate จาก Local Router Route ที่มี Weight สูงกว่าจะถูก Prefer Weight ไม่ถูกส่งไปยัง BGP Peer ใดๆ ใช้เฉพาะ Local บน Router ตัวนั้น Weight เหมาะสำหรับกำหนด Outbound Traffic Policy บน Router ตัวเดียวโดยไม่กระทบ Router อื่น
BGP Path Selection Algorithm: กระบวนการเลือกเส้นทาง
เมื่อ BGP Router ได้รับหลาย Path ไปยัง Destination เดียวกัน จะใช้ Path Selection Algorithm ในการเลือก Best Path ลำดับการพิจารณามีดังนี้ (เรียงจาก Priority สูงสุด)
ลำดับที่ 1: Weight สูงสุด (Cisco Only) ค่า Default 32768 สำหรับ Local Route และ 0 สำหรับ Learned Route เลือก Route ที่มี Weight สูงที่สุด
ลำดับที่ 2: Local Preference สูงสุด ค่า Default 100 เลือก Route ที่มี Local Preference สูงที่สุด ใช้กำหนด Outbound Policy ภายใน AS
ลำดับที่ 3: Locally Originated Route ที่ Originate จาก Local Router (network command, redistribute, aggregate) จะถูก Prefer มากกว่า Route ที่ Learn จาก Neighbor
ลำดับที่ 4: AS-Path สั้นที่สุด Route ที่ผ่าน AS น้อยกว่าจะถูก Prefer สามารถ Disable การ Compare AS-Path Length ได้ด้วย bgp bestpath as-path ignore
ลำดับที่ 5: Origin Type ต่ำสุด IGP (i) ดีกว่า EGP (e) ดีกว่า Incomplete (?) โดย IGP มาจาก network command, EGP มาจาก EGP Protocol เดิม (แทบไม่ใช้แล้ว) และ Incomplete มาจาก redistribute
ลำดับที่ 6: MED ต่ำสุด เปรียบเทียบเฉพาะ Route จาก AS เดียวกัน (By Default) Route ที่มี MED ต่ำกว่าจะถูก Prefer
ลำดับที่ 7: eBGP ดีกว่า iBGP Route ที่ได้จาก eBGP Peer จะถูก Prefer มากกว่า Route จาก iBGP Peer
ลำดับที่ 8: IGP Metric ไปยัง Next-Hop ต่ำสุด Route ที่มี IGP Cost ไปยัง BGP Next-Hop ต่ำที่สุดจะถูก Prefer นี่คือ Hot Potato Routing ที่ Router พยายามส่ง Traffic ออกจาก AS ของตัวเองเร็วที่สุด
ลำดับที่ 9: Oldest Route Route ที่ได้รับมานานกว่าจะถูก Prefer เพื่อความเสถียร (เฉพาะ eBGP Route)
ลำดับที่ 10: Router ID ต่ำสุด Route จาก Peer ที่มี Router ID ต่ำที่สุดจะถูก Prefer
ลำดับที่ 11: Neighbor IP ต่ำสุด ถ้ายังเท่ากัน เลือก Route จาก Neighbor ที่มี IP Address ต่ำที่สุด
วิธีจำลำดับนี้ Network Engineer หลายคนใช้ตัวย่อ “We Love Oranges AS Oranges Mean Pure Refreshment” ซึ่งย่อมาจาก Weight, Local Preference, Originate, AS-Path, Origin, MED, Paths (eBGP > iBGP), Reach (IGP Metric)
การ Configure BGP บน Cisco Router
Basic BGP Configuration
การ Configure BGP บน Cisco Router เริ่มจากการเข้า Router BGP Process ด้วยคำสั่ง router bgp ตามด้วย AS Number ของ Local Router จากนั้นกำหนด Neighbor ด้วยคำสั่ง neighbor ตามด้วย IP Address ของ Peer และ Remote AS Number สุดท้ายกำหนด Network ที่ต้องการ Advertise ด้วยคำสั่ง network ตามด้วย Prefix และ Subnet Mask
ตัวอย่าง Configuration สำหรับ eBGP Peering กับ ISP จะเริ่มจาก router bgp 65001 (สมมติ AS ขององค์กรคือ 65001) จากนั้น neighbor 203.0.113.1 remote-as 7470 (IP ของ ISP Router ใน AS 7470) และ network 198.51.100.0 mask 255.255.255.0 (Prefix ขององค์กรที่ต้องการ Advertise ไปยัง ISP)
สิ่งสำคัญที่ต้องจำคือ คำสั่ง network ใน BGP ไม่เหมือนกับ OSPF ใน OSPF คำสั่ง network ใช้เปิด Interface เข้า OSPF Process แต่ใน BGP คำสั่ง network ใช้ Advertise Prefix ที่มีอยู่ใน Routing Table Prefix ที่ Advertise ต้องตรงกับ Entry ใน Routing Table ทั้ง Network Address และ Subnet Mask ถ้าไม่ตรง BGP จะไม่ Advertise Prefix นั้น
iBGP Configuration กับ Route Reflector
การ Configure iBGP ต้องกำหนด Neighbor ที่มี remote-as เป็น AS เดียวกัน สำหรับ Route Reflector ต้อง Configure บน RR Server ด้วยคำสั่ง neighbor [IP] route-reflector-client ให้แต่ละ Client ส่วน Client ไม่ต้อง Configure อะไรเพิ่ม RR จะ Reflect Route จาก Client หนึ่งไปยัง Client อื่นโดยอัตโนมัติ
Best Practice สำหรับ iBGP คือใช้ Loopback Interface เป็น Source ของ iBGP Session เนื่องจาก Loopback ไม่มีวัน Down ทำให้ iBGP Session มีความเสถียร ใช้คำสั่ง neighbor [IP] update-source Loopback0 เพื่อกำหนด Source Interface และอย่าลืมใช้ neighbor [IP] next-hop-self บน Router ที่เชื่อมต่อ eBGP เพื่อเปลี่ยน Next-Hop ให้ iBGP Peer สามารถ Reach ได้
BGP Route Filtering: การกรองเส้นทาง
Prefix List
Prefix List ใช้กรอง Route ตาม Network Address และ Prefix Length สามารถกำหนดได้ทั้ง Exact Match และ Range ของ Prefix Length ตัวอย่างเช่น ip prefix-list FILTER seq 5 permit 10.0.0.0/8 le 24 จะ Match ทุก Prefix ในช่วง 10.0.0.0/8 ที่มี Prefix Length ตั้งแต่ 8 ถึง 24 ส่วน ip prefix-list FILTER seq 10 deny 0.0.0.0/0 le 32 จะ Deny ทุก Prefix ที่เหลือ
Prefix List มีประสิทธิภาพสูงกว่า Access Control List (ACL) ในการกรอง Route เพราะสามารถ Match ทั้ง Network Address และ Prefix Length ได้อย่างยืดหยุ่น และทำงานเร็วกว่า ACL ในการ Process ใน Production Network ควรใช้ Prefix List แทน ACL เสมอ
Route Map
Route Map เป็นเครื่องมือที่ทรงพลังที่สุดในการ Filter และ Modify BGP Route Route Map ทำงานคล้าย Programming Language ที่มี if-then-else Logic โดยมี Match Condition (เงื่อนไขในการ Match เช่น Prefix List, AS-Path ACL, Community) และ Set Action (การเปลี่ยนแปลง Attribute เช่น Set Local Preference, Set MED, Set Community, Set AS-Path Prepend)
ตัวอย่างการใช้ Route Map เพื่อตั้ง Local Preference ให้ Route จาก ISP A เป็น 200 (Primary) และ Route จาก ISP B เป็น 100 (Backup) จะเริ่มจากสร้าง Route Map ชื่อ ISP-A-IN ที่มี match ip address prefix-list ALL (Match ทุก Route) และ set local-preference 200 จากนั้นใช้คำสั่ง neighbor [ISP-A-IP] route-map ISP-A-IN in เพื่อ Apply Route Map กับ Route ที่ได้รับจาก ISP A
AS-Path Access List
AS-Path Access List ใช้กรอง Route ตาม AS-Path โดยใช้ Regular Expression ตัวอย่างเช่น ip as-path access-list 1 permit ^$ จะ Match Route ที่ Originate จาก Neighbor AS โดยตรง (AS-Path มีแค่ 1 AS) ip as-path access-list 2 permit _7470_ จะ Match Route ที่ผ่าน AS 7470 และ ip as-path access-list 3 deny _0_ จะ Deny Route ที่มี AS 0 ใน Path ซึ่งมักเป็น Bogon AS
BGP Communities: การจัดกลุ่มและกำหนดนโยบายเส้นทาง
BGP Community เป็นเครื่องมือที่ใช้กันอย่างแพร่หลายใน ISP และ Enterprise Network สำหรับ Policy Management Community ช่วยให้ ISP สามารถให้ลูกค้ากำหนด Policy ได้โดยไม่ต้องสร้าง Custom Filter ให้แต่ละลูกค้า
ตัวอย่าง Community Schema ที่ ISP ในไทยมักใช้ ได้แก่ ASN:100 สำหรับ Route จากลูกค้า ASN:200 สำหรับ Route จาก Peering Partner ASN:300 สำหรับ Route จาก Transit Provider ASN:666 สำหรับ Blackhole Community (ใช้ Drop Traffic ไปยัง Prefix ที่ถูก DDoS) ASN:1000-1999 สำหรับ Action ต่างๆ เช่น Set Local Preference, Prepend AS-Path เมื่อ Advertise ไปยัง Upstream
Extended Community ขนาด 64-bit ให้พื้นที่มากขึ้น ใช้ใน MPLS VPN (Route Target, Route Distinguisher), EVPN และ Feature อื่นๆ ที่ต้องการ Community ที่มีความหมายเฉพาะ Large Community ขนาด 96-bit (RFC 8092) ออกแบบมาสำหรับ 4-byte ASN โดยเฉพาะ มีรูปแบบ ASN:Function:Parameter เช่น 131090:1:200 หมายถึง AS 131090 Function 1 Parameter 200
BGP Security: การรักษาความปลอดภัยของ BGP
ปัญหาความปลอดภัยของ BGP
BGP ถูกออกแบบมาในยุคที่อินเทอร์เน็ตยังเล็กและทุกคนเชื่อใจกัน BGP จึงไม่มี Authentication Mechanism ที่แข็งแกร่ง Router จะเชื่อ Route ที่ได้รับจาก Peer โดยไม่มีการตรวจสอบว่า Peer มีสิทธิ์ Advertise Prefix นั้นจริงหรือไม่ นี่ทำให้เกิดปัญหา BGP Hijacking
BGP Hijacking เกิดขึ้นเมื่อ AS หนึ่ง Advertise Prefix ที่ไม่ใช่ของตัวเอง ทำให้ Traffic ถูก Redirect ไปยัง AS ที่ Hijack เหตุการณ์ BGP Hijacking ที่มีชื่อเสียง ได้แก่ Pakistan Telecom Hijack YouTube (2008) ที่ Pakistan Telecom Advertise Prefix ของ YouTube ทำให้ YouTube ล่มทั่วโลก, Rostelecom Hijack ที่ Redirect Traffic ของ Bank และ Government Website, และ China Telecom Incident ที่ Advertise Prefix จำนวนมากเป็นเวลาสั้นๆ อย่างต่อเนื่อง
RPKI (Resource Public Key Infrastructure)
RPKI เป็นระบบ Cryptographic ที่ช่วยยืนยันว่า AS มีสิทธิ์ Advertise Prefix ที่ระบุจริง RPKI ทำงานโดยให้ IP Address Holder สร้าง Route Origin Authorization (ROA) ที่ระบุว่า AS ใดมีสิทธิ์ Originate Prefix ใด ROA จะถูกลงนาม Digital Signature และเก็บไว้ใน RPKI Repository
Router ที่รองรับ RPKI จะ Validate Route ที่ได้รับโดยตรวจสอบกับ ROA ผลลัพธ์มี 3 สถานะ คือ Valid (AS และ Prefix ตรงกับ ROA), Invalid (AS หรือ Prefix ไม่ตรงกับ ROA อาจเป็น Hijacking), และ Not Found (ไม่มี ROA สำหรับ Prefix นี้) Router สามารถกำหนด Policy ว่าจะทำอย่างไรกับแต่ละสถานะ เช่น Accept เฉพาะ Valid, Reject Invalid, Accept Not Found (เพราะยังมี Prefix จำนวนมากที่ยังไม่มี ROA)
ในปี 2026 RPKI มีการ Adopt มากขึ้นเรื่อยๆ โดย ISP รายใหญ่ทั่วโลกส่วนใหญ่ Enable RPKI Validation แล้ว ในไทย ISP รายใหญ่อย่าง TRUE, AIS, DTAC ก็เริ่ม Deploy RPKI แม้ว่าอัตราการ Cover ROA ของ Prefix ในไทยยังไม่ครบ 100% แต่ Trend ชัดเจนว่า RPKI กำลังกลายเป็น Standard
BGPsec
BGPsec เป็น Extension ของ BGP ที่เพิ่ม Digital Signature ให้กับทุก AS ใน AS-Path ทำให้สามารถ Verify ได้ว่า Route ผ่าน AS ที่ระบุจริง BGPsec ป้องกัน Path Manipulation ที่ RPKI ไม่สามารถป้องกันได้ เช่น การ Modify AS-Path โดยไม่เปลี่ยน Origin AS อย่างไรก็ตาม BGPsec ยังไม่ได้ Deploy อย่างแพร่หลายเนื่องจาก Performance Overhead ในการ Sign และ Verify Signature ของทุก Route Update สูงมาก และต้องการ RPKI เป็นพื้นฐานก่อน
วิธีป้องกัน BGP Hijacking ที่ใช้ได้ในปัจจุบัน
นอกจาก RPKI แล้ว ยังมีมาตรการป้องกัน BGP Hijacking อื่นๆ ที่ใช้ได้ในปัจจุบัน ประการแรก BGP Session Authentication ด้วย TCP MD5 Signature (RFC 2385) หรือ TCP-AO (RFC 5925) เพื่อป้องกัน Session Hijacking ประการที่สอง Maximum Prefix Limit กำหนดจำนวน Prefix สูงสุดที่ยอมรับจาก Peer เพื่อป้องกัน Route Leak ที่ Peer ส่ง Full Table มาโดยไม่ตั้งใจ ประการที่สาม Strict Prefix Filtering กรอง Prefix ที่ยอมรับจาก Customer ตาม IRR Database (Internet Routing Registry) ประการที่สี่ BGP Monitoring ใช้ BGP Monitoring Protocol (BMP) และ BGP Looking Glass เพื่อ Monitor Route Change
BGP สำหรับ Enterprise Multihoming
ทำไม Enterprise ต้อง Multihome
Enterprise ที่มี Internet Service สำคัญ เช่น Web Server, Email Server, VPN Gateway ที่ต้อง Available ตลอดเวลา ควร Multihome กับ ISP มากกว่า 1 ราย เพื่อ Redundancy ถ้า ISP หลักล่ม Traffic จะ Failover ไปยัง ISP สำรองโดยอัตโนมัติ
รูปแบบ Multihoming มีหลายแบบ แบบแรกคือ Single-homed (1 ISP, 1 Link) ไม่มี Redundancy ไม่ต้องใช้ BGP แบบที่สองคือ Dual-homed (1 ISP, 2 Links) มี Link Redundancy แต่ไม่มี ISP Redundancy อาจใช้ BGP หรือ Static Route ก็ได้ แบบที่สามคือ Multihomed (2 ISP, 1 Link ต่อ ISP) มีทั้ง Link และ ISP Redundancy ต้องใช้ BGP แบบที่สี่คือ Dual Multihomed (2 ISP, 2 Links ต่อ ISP) มี Redundancy สูงสุด ต้องใช้ BGP
สำหรับ Enterprise ในไทยที่ต้องการ Multihome สิ่งที่ต้องพิจารณา ได้แก่ การขอ PI (Provider Independent) IP Address จาก APNIC เพื่อให้สามารถ Advertise Prefix เดียวกันผ่านทั้ง 2 ISP ถ้าใช้ PA (Provider Assigned) IP จาก ISP แต่ละราย จะไม่สามารถ Failover ได้สมบูรณ์ เพราะ IP Address จะเปลี่ยนเมื่อ Failover การขอ ASN (Public หรือ Private) และการประสานงานกับ ISP ทั้ง 2 รายเพื่อ Configure BGP Peering
Traffic Engineering ด้วย BGP
BGP ช่วยให้ Enterprise ควบคุม Traffic Flow ได้ทั้ง Outbound (Traffic ออก) และ Inbound (Traffic เข้า) สำหรับ Outbound Traffic ใช้ Local Preference หรือ Weight เพื่อกำหนดว่า Traffic ขาออกจะไปทาง ISP ไหน เช่น ตั้ง Local Preference สูงกว่าให้ Route จาก ISP ที่มี Bandwidth สูงกว่า
สำหรับ Inbound Traffic ใช้ AS-Path Prepending หรือ MED เพื่อ Influence ว่า Traffic จากอินเทอร์เน็ตจะเข้ามาทาง ISP ไหน เช่น Prepend ASN ซ้ำ 3 ครั้งบน ISP ที่เป็น Backup เพื่อทำให้ AS-Path ยาวขึ้น Peer อื่นจะ Prefer เส้นทางผ่าน ISP หลักที่มี AS-Path สั้นกว่า หรือใช้ Community ที่ ISP กำหนดให้เพื่อควบคุม Local Preference บน ISP Router
BGP Looking Glass และ Monitoring Tools
BGP Looking Glass เป็นเครื่องมือที่ ISP และ IX (Internet Exchange) ให้บริการ ช่วยให้ Network Engineer สามารถดู BGP Routing Table จากมุมมองของ Router ที่อยู่ใน AS อื่น ทำให้ตรวจสอบได้ว่า Prefix ที่ Advertise ถูก Propagate ไปยังอินเทอร์เน็ตอย่างไร มี AS-Path อย่างไร และมี Route ไปถึง Prefix หรือไม่
เครื่องมือ Looking Glass ที่ใช้กันอย่างแพร่หลาย ได้แก่ RIPE RIS (Routing Information Service) ที่มี Route Collector ทั่วโลก, RouteViews ของ University of Oregon ที่เก็บ BGP Data ย้อนหลัง, Hurricane Electric BGP Toolkit (bgp.he.net) ที่สามารถค้นหา ASN, Prefix, Peering Information, และ BGPStream ของ CAIDA ที่ Monitor BGP Event เช่น Hijacking และ Route Leak แบบ Real-time
สำหรับ Monitoring ภายใน AS ควรใช้ BGP Monitoring Protocol (BMP) ตาม RFC 7854 เพื่อส่ง BGP Data ไปยัง Monitoring System โดยไม่ต้อง Parse CLI Output BMP ส่งข้อมูล Adj-RIB-In, Adj-RIB-Out และ Local-RIB ไปยัง BMP Station เช่น OpenBMP, PMacct หรือ GoBMP ทำให้ Network Engineer สามารถ Analyze BGP Route Change, Detect Anomaly และ Troubleshoot ได้อย่างมีประสิทธิภาพ
BGP ใน Data Center: eBGP Spine-Leaf Architecture
ทำไม Data Center ถึงใช้ BGP แทน IGP
ในช่วงหลายปีที่ผ่านมา Data Center Network Design เปลี่ยนจาก Traditional Three-tier (Core-Aggregation-Access) มาเป็น Spine-Leaf (Clos) Architecture และ Routing Protocol ก็เปลี่ยนจาก Spanning Tree + OSPF/EIGRP มาเป็น eBGP ทั้งหมด แนวคิดนี้ถูกนำเสนอโดย RFC 7938 (Use of BGP for Routing in Large-Scale Data Centers) โดยมี Facebook (Meta), Microsoft Azure และ LinkedIn เป็นผู้นำ
เหตุผลที่ Data Center ใช้ eBGP แทน IGP มีหลายประการ ประการแรก Simplicity ใช้ Protocol เดียว (eBGP) สำหรับทุก Layer ไม่ต้อง Mix IGP กับ BGP ประการที่สอง Scalability BGP มี Incremental Update ไม่ต้อง Flood LSA ทั้ง Area เมื่อมี Change ประการที่สาม Policy Control BGP มี Path Attributes ที่ให้ Control มากกว่า IGP ประการที่สี่ Multi-path eBGP สามารถใช้ ECMP (Equal-Cost Multi-Path) ได้ง่ายด้วย maximum-paths ประการที่ห้า Failure Domain แต่ละ eBGP Session เป็นอิสระ ปัญหาใน Session หนึ่งไม่กระทบ Session อื่น ต่างจาก OSPF ที่ปัญหาใน Area หนึ่งอาจ Flood ไปทั้ง Domain
BGP Spine-Leaf Design
ใน Spine-Leaf Architecture ทุก Leaf Switch จะ Peer eBGP กับทุก Spine Switch และทุก Spine Switch จะ Peer eBGP กับทุก Leaf Switch แต่ละ Switch จะมี ASN เฉพาะของตัวเอง (ใช้ Private ASN) หรือใช้ ASN ตาม Role (Spine ใช้ ASN เดียวกัน, Leaf ใช้ ASN ต่างกัน)
การ Configure BGP ใน Spine-Leaf มักใช้ Unnumbered BGP (BGP over IPv6 Link-Local) เพื่อไม่ต้องจัดสรร IP ให้ทุก Point-to-Point Link ใช้ BFD (Bidirectional Forwarding Detection) เพื่อ Detect Link Failure เร็ว (Millisecond) ใช้ BGP Allowas-in หรือ AS Override เพื่อให้ Spine ที่มี ASN เดียวกันสามารถแลกเปลี่ยน Route ได้ และใช้ ECMP สำหรับ Load Balancing Traffic ข้าม Spine หลายตัว
Troubleshooting BGP: การแก้ไขปัญหา BGP
BGP Session ไม่ Established
ปัญหาที่พบบ่อยที่สุดคือ BGP Session ไม่เข้าสู่ Established State สาเหตุและวิธีแก้ไขมีดังนี้
Stuck ใน Idle State: ตรวจสอบว่ามี Route ไปยัง Neighbor IP หรือไม่ด้วย show ip route [neighbor-ip] ตรวจสอบว่า ACL ไม่ได้ Block TCP Port 179 ตรวจสอบว่า Interface ที่ใช้ Peer มี IP Address ถูกต้องและ Up ตรวจสอบ BGP Configuration ว่า neighbor command ถูกต้อง
Stuck ใน Active State: สาเหตุส่วนใหญ่คือ Peer ไม่ได้ Configure BGP กลับมา ตรวจสอบ Configuration ทั้ง 2 ฝ่าย ตรวจสอบ Firewall ระหว่างทาง ลองใช้ telnet [neighbor-ip] 179 เพื่อทดสอบ TCP Connectivity ตรวจสอบว่า update-source ถูกต้อง (ถ้าใช้ Loopback)
Stuck ใน OpenSent/OpenConfirm: ตรวจสอบ AS Number ว่าตรงกับที่ Peer Configure ตรวจสอบ Router ID ไม่ซ้ำกัน ตรวจสอบ BGP Capability ว่า Compatible กัน ดู Log Message เพื่อหา Notification Error
Route ไม่ปรากฏใน BGP Table
ถ้า BGP Session Established แล้วแต่ Route ไม่ปรากฏใน BGP Table ให้ตรวจสอบ ว่า Peer Advertise Route มาหรือไม่ด้วย show ip bgp neighbors [IP] received-routes ตรวจสอบว่ามี Route Filter (Prefix List, Route Map, AS-Path ACL) ที่ Block Route หรือไม่ ตรวจสอบว่า Route ไม่ถูก Reject เพราะ AS-Path Loop (มี Local ASN ใน Path) ตรวจสอบ Maximum Prefix Limit ว่าเกินหรือไม่
Route ไม่ถูก Install ใน Routing Table
ถ้า Route อยู่ใน BGP Table แต่ไม่ถูก Install ใน Routing Table (show ip route) ให้ตรวจสอบว่า Next-Hop Reachable หรือไม่ด้วย show ip bgp [prefix] ดูว่า Route ถูก Mark ว่า valid หรือไม่ ตรวจสอบว่ามี Route จาก Protocol อื่นที่มี AD ต่ำกว่าอยู่แล้ว และตรวจสอบ RIB Failure ด้วย show ip bgp rib-failure
คำสั่ง Troubleshoot BGP ที่ใช้บ่อย
คำสั่งที่ Network Engineer ใช้บ่อยในการ Troubleshoot BGP ได้แก่ show ip bgp summary (แสดงสรุป BGP Neighbor ทั้งหมดพร้อม State และจำนวน Prefix), show ip bgp (แสดง BGP Table ทั้งหมด), show ip bgp [prefix] (แสดงรายละเอียดของ Prefix เฉพาะ รวมถึง Path Attributes), show ip bgp neighbors [IP] (แสดงรายละเอียด Neighbor Session), show ip bgp neighbors [IP] advertised-routes (แสดง Route ที่ Advertise ไปยัง Neighbor), show ip bgp neighbors [IP] received-routes (แสดง Route ที่ได้รับจาก Neighbor ก่อน Filter), debug ip bgp updates (แสดง BGP Update Message แบบ Real-time ใช้ด้วยความระมัดระวังใน Production)
Best Practices สำหรับ BGP ในองค์กร
สำหรับ Enterprise ที่ใช้ BGP ควรปฏิบัติตาม Best Practices ต่อไปนี้
Security: ใช้ MD5 Authentication ทุก BGP Session, Enable RPKI Validation, กำหนด Maximum Prefix Limit ทุก Neighbor, Filter Bogon AS และ Bogon Prefix (RFC 5735, RFC 6890), ใช้ Prefix List กรอง Route ที่ยอมรับอย่างเข้มงวด โดยเฉพาะจาก Customer, ไม่ Advertise Default Route หรือ Full Table ให้ Customer โดยไม่ตั้งใจ
Stability: ใช้ Loopback เป็น Source ของ iBGP Session, ใช้ BFD สำหรับ Fast Failure Detection, ตั้ง Hold Timer ให้เหมาะสม (ไม่สั้นเกินไปจนเกิด False Positive), ใช้ Graceful Restart เพื่อลด Traffic Loss เมื่อ BGP Process Restart, ใช้ Route Dampening อย่างระมัดระวัง (อาจทำให้ Convergence ช้าลง)
Scalability: ใช้ Route Reflector แทน Full Mesh iBGP, Aggregate Prefix ให้ใหญ่ที่สุดเท่าที่เป็นไปได้ก่อน Advertise, ใช้ Soft Reconfiguration หรือ Route Refresh (RFC 2918) แทน Hard Reset เมื่อเปลี่ยน Policy, Peer ที่ IXP (Internet Exchange Point) เช่น BKNIX ในไทย เพื่อลด Transit Cost และเพิ่ม Peering Options
Monitoring: Monitor BGP Session Status อย่างต่อเนื่องด้วย SNMP หรือ BMP, ตั้ง Alert เมื่อ BGP Session Down, Monitor Prefix Count เพื่อ Detect Route Leak, ใช้ Looking Glass ตรวจสอบ Route Propagation เป็นประจำ, เก็บ BGP Log และ Syslog ไว้สำหรับ Post-mortem Analysis
Key Takeaway สำหรับ Network Engineer คือ BGP เป็นโปรโตคอลที่ซับซ้อนแต่มีความสำคัญอย่างยิ่งต่อการทำงานของอินเทอร์เน็ตและ Enterprise Network ความเข้าใจ BGP Path Selection, Path Attributes และ Route Filtering เป็นพื้นฐานที่จำเป็น การเรียนรู้ BGP ไม่ใช่แค่ท่องจำ Configuration แต่ต้องเข้าใจ Logic เบื้องหลังว่าทำไม BGP ถึงออกแบบมาแบบนี้ เมื่อเข้าใจหลักการแล้ว การ Configure, Troubleshoot และ Optimize BGP จะทำได้อย่างมีประสิทธิภาพ ลงทุนเวลาเรียน BGP เพราะเป็น Skill ที่ทุก ISP และ Enterprise ต้องการ และจะเป็นจุดแข็งที่สำคัญใน IT Career ของคุณในปี 2026 และอนาคต
