โปรโตคอลเกตเวย์ชายแดน

โปรโตคอลการสื่อสาร
สถานะเครื่อง BGP
คำย่อ	บีจีพี
วัตถุประสงค์	แลกเปลี่ยนข้อมูลการกำหนดเส้นทางโปรโตคอลอินเทอร์เน็ต
การแนะนำ	1 มิถุนายน พ.ศ. 2532 [ 1 ] ( 1989-06-01 )
อ้างอิงจาก	อีจีพี
เลเยอร์ OSI	ชั้นแอปพลิเคชัน
ท่าเรือ	tcp/179
อาร์เอฟซี	§ เอกสารมาตรฐานสำหรับ BGP-4

โปรโตคอลเกตเวย์ชายแดน ( BGP ) เป็นโปรโตคอลเกตเวย์ภายนอก มาตรฐาน ที่ออกแบบมาเพื่อแลกเปลี่ยน ข้อมูล การกำหนดเส้นทางและการเข้าถึงระหว่างระบบอิสระ ( AS) บนอินเทอร์เน็ต^{[ 2 ]} BGP จัดเป็นโปรโตคอลการกำหนดเส้นทางเวกเตอร์เส้นทาง^{[ 3 ]}และจะตัดสินใจกำหนดเส้นทางตามเส้นทาง นโยบายเครือข่าย หรือชุดกฎที่กำหนดค่าโดยผู้ดูแลระบบเครือข่าย

โปรโตคอล BGP ที่ใช้สำหรับการกำหนดเส้นทางภายในระบบอิสระเรียกว่าInterior Border Gateway Protocol ( iBGP ) ในทางตรงกันข้าม การใช้งานโปรโตคอลนี้บนอินเทอร์เน็ตเรียกว่าExterior Border Gateway Protocol ( EBGP )

ในเดือนมกราคม พ.ศ. 2532 ในการประชุม IETF ครั้งที่ 12 ที่เมืองออสติน รัฐเท็กซัส Yakov Rekhter , Len Bosackและ Kirk Lougheed ได้นั่งลงที่โต๊ะเพื่อออกแบบสิ่งที่ในที่สุดก็กลายเป็น Border Gateway Protocol (BGP) การออกแบบ BGP ครั้งแรกถูกบันทึกไว้บนกระดาษเช็ดปากสองแผ่น จึงมักถูกเรียกว่า “Two-Napkin Protocol” ^{[ 4 ]}การออกแบบบนกระดาษเช็ดปากนั้นถูกขยายเป็นกระดาษที่เขียนด้วยลายมือสามแผ่น ซึ่งนำไปสู่การพัฒนาการใช้งาน BGP ที่สามารถทำงานร่วมกันได้เป็นครั้งแรกอย่างรวดเร็ว ปัจจุบันสำเนาของกระดาษสามแผ่นนี้แขวนอยู่บนผนังของพื้นที่พัฒนาโปรโตคอลการกำหนดเส้นทางที่Cisco Systemsในเมืองมิลปิตัส รัฐแคลิฟอร์เนียในปีเดียวกันนั้นRFC  1105 ^{[ 5 ]}ได้รับการเผยแพร่ และโปรโตคอล BGP (ในรูปแบบต่างๆ) ได้ถูกนำไปใช้บนอินเทอร์เน็ตตั้งแต่ปี พ.ศ. 2537 ^{[ 6 ]}

ครึ่งปีหลังจากการเผยแพร่ครั้งแรก คำจำกัดความของโปรโตคอลได้ถูกเปลี่ยนแปลงในปี 1990 ด้วยการเผยแพร่RFC  1136 ^{[ 7 ]}ในเดือนตุลาคม 1991 BGP เวอร์ชัน 3 ได้รับการกำหนดในRFC  1267 ^{[ 8 ]}ซึ่งทำให้เวอร์ชันก่อนหน้าสองเวอร์ชันนั้นล้าสมัย ในปี 1994 เวอร์ชันปัจจุบัน (BGP4) ได้รับการเผยแพร่เป็นRFC  1654 ^{[ 9 ]}คำจำกัดความของมันถูกแทนที่ในเดือนมีนาคม 1995 โดยRFC  1771 ^{[ 10 ]}ในเดือนมกราคม 2006 RFC  4271 ^{[ 11 ]}ได้รับการเผยแพร่ ซึ่งปัจจุบันเป็นคำจำกัดความล่าสุดของ BGP4 (แม้ว่าจะมีการอัปเดตโดย RFC อื่นๆ อีกมากมาย)

RFC 4271 ได้แก้ไขข้อผิดพลาด ชี้แจงความกำกวม และอัปเดตข้อกำหนดด้วยแนวปฏิบัติทั่วไปในอุตสาหกรรม การปรับปรุงที่สำคัญของ BGP4 คือการสนับสนุนClassless Inter-Domain Routing (CIDR) และการใช้การรวมเส้นทางเพื่อลดขนาดของตารางเส้นทางในรูปแบบดั้งเดิม โปรโตคอล BGP4 สามารถทำงานได้เฉพาะกับที่อยู่ IPv4 เท่านั้น นับตั้งแต่การเผยแพร่RFC  2283 ^{[ 12 ]}ในปี 1998 ข้อมูลการกำหนดเส้นทางเกี่ยวกับ "ตระกูลที่อยู่" ที่หลากหลาย ( IPv4 , IPv6 , IPXเป็นต้น) สามารถส่งผ่านได้ 'ส่วนขยายมัลติโปรโตคอล' ได้รับการอัปเดตในปี 2000 ด้วยRFC  2858 ^{[ 13 ]}และในที่สุดในปี 2007 ด้วยRFC  4760 ^{[ 14 ]}ด้วยส่วนขยายเหล่านี้ โปรโตคอลนี้จึงถูกเรียกว่าMultiprotocol BGP (MP-BGP) ด้วย

เพื่อนบ้าน BGP ที่เรียกว่า peer จะถูกสร้างขึ้นโดยการกำหนดค่าด้วยตนเองระหว่างเราเตอร์เพื่อสร้าง เซสชัน TCPบนพอร์ต 179 BGP speaker จะส่งข้อความ keep-alive ขนาด 19 ไบต์ทุกๆ 30 วินาที (ค่าเริ่มต้นของโปรโตคอล สามารถปรับแต่งได้) เพื่อรักษาการเชื่อมต่อ^{[ 15 ]}ในบรรดาโปรโตคอลการกำหนดเส้นทาง BGP มีความโดดเด่นในการใช้ TCP เป็นโปรโตคอลการขนส่ง

เมื่อโปรโตคอล BGP ทำงานระหว่างสองอุปกรณ์ใน ระบบอิสระเดียวกัน(AS) จะเรียกว่าInternal BGP ( iBGPหรือInterior Border Gateway Protocol ) ส่วนเมื่อทำงานระหว่างระบบอิสระที่แตกต่างกัน จะเรียกว่าExternal BGP ( eBGPหรือExterior Border Gateway Protocol ) เราเตอร์ที่อยู่บนขอบเขตของ AS หนึ่งที่แลกเปลี่ยนข้อมูลกับ AS อื่นเรียกว่า เราเตอร์ ขอบเขตหรือเราเตอร์ขอบหรือเรียกง่ายๆ ว่าeBGP peerและโดยทั่วไปจะเชื่อมต่อกันโดยตรง ในขณะที่iBGP peerสามารถเชื่อมต่อกันผ่านเราเตอร์ตัวกลางอื่นๆ ได้ นอกจากนี้ยังสามารถใช้งานในรูปแบบ อื่นๆ ได้ เช่น การใช้งาน eBGP peerภายใน อุโมงค์ VPNซึ่งช่วยให้สองไซต์ที่อยู่ห่างไกลสามารถแลกเปลี่ยนข้อมูลการกำหนดเส้นทางได้อย่างปลอดภัยและแยกจากกัน

ความแตกต่างหลักระหว่างการเชื่อมต่อแบบ iBGP และ eBGP อยู่ที่วิธีการส่งต่อเส้นทางที่ได้รับจากคู่ค้าหนึ่งไปยังคู่ค้าอื่นๆ โดยค่าเริ่มต้น:

• เส้นทางใหม่ที่ได้รับจาก eBGP peer จะถูกส่งต่อไปยัง iBGP และ eBGP peer ทั้งหมด
• เส้นทางใหม่ที่ได้รับจากอุปกรณ์ iBGP จะถูกส่งต่อไปยังอุปกรณ์ eBGP ทั้งหมดเท่านั้น

กฎการเผยแพร่เส้นทางเหล่านี้กำหนดให้เพื่อนร่วมเครือข่าย iBGP ทั้งหมดภายใน AS ต้องเชื่อมต่อกันแบบเต็มรูปแบบด้วยเซสชัน iBGP

วิธีการเผยแพร่เส้นทางสามารถควบคุมได้อย่างละเอียดผ่าน กลไก แผนที่เส้นทางกลไกนี้ประกอบด้วยชุดของกฎ แต่ละกฎอธิบายว่าสำหรับเส้นทางที่ตรงตามเกณฑ์ที่กำหนด ควรดำเนินการอย่างไร การดำเนินการอาจเป็นการลบเส้นทาง หรืออาจเป็นการแก้ไขคุณลักษณะบางอย่างของเส้นทางก่อนที่จะแทรกเข้าไปในตารางการกำหนดเส้นทาง

ระหว่างการจับมือกันของเพียร์ริ่ง เมื่อมีการแลกเปลี่ยนข้อความ OPEN สปีกเกอร์ BGP สามารถเจรจาความสามารถเสริมของเซสชันได้^{[ 16 ]}รวมถึงส่วนขยายมัลติโปรโตคอล^{[ 17 ]}และโหมดการกู้คืนต่างๆ หากมีการเจรจาส่วนขยายมัลติโปรโตคอลสำหรับ BGP ในขณะที่สร้าง สปีกเกอร์ BGP สามารถเพิ่มคำนำ หน้าตระกูลที่อยู่ให้กับข้อมูลการเข้าถึงเลเยอร์เครือ ข่าย (NLRI) ที่โฆษณา ตระกูลเหล่านี้ได้แก่ IPv4 (ค่าเริ่มต้น), IPv6, เครือข่ายส่วนตัวเสมือน IPv4/IPv6 และ BGP แบบมัลติแคสต์ BGP ถูกใช้มากขึ้นเรื่อยๆ ในฐานะโปรโตคอลการส่งสัญญาณทั่วไปเพื่อส่งข้อมูลเกี่ยวกับเส้นทางที่อาจไม่ได้เป็นส่วนหนึ่งของอินเทอร์เน็ตทั่วโลก เช่น VPN ^{[ 18 ]}

เพื่อประกอบการตัดสินใจในการทำงานร่วมกับอุปกรณ์อื่น ๆ ในระบบ BGP อุปกรณ์นั้นจะใช้เครื่องสถานะจำกัด (Finite-State Machineหรือ FSM) อย่างง่าย ซึ่งประกอบด้วยสถานะหกสถานะ ได้แก่ ว่าง (Idle); เชื่อมต่อ (Connect); ทำงาน (Active); ส่งคำขอ (OpenSent); ยืนยันคำขอ (OpenConfirm); และ สร้างการเชื่อมต่อ (Established) สำหรับแต่ละเซสชันแบบ peer-to-peer ระบบ BGP จะเก็บตัวแปรสถานะไว้เพื่อติดตามว่าเซสชันนั้นอยู่ในสถานะใดในหกสถานะนี้ BGP จะกำหนดข้อความที่อุปกรณ์แต่ละฝ่ายควรแลกเปลี่ยนเพื่อเปลี่ยนสถานะของเซสชันจากสถานะหนึ่งไปยังอีกสถานะหนึ่ง

สถานะแรกคือสถานะ Idle ในสถานะ Idle นั้น BGP จะเริ่มต้นทรัพยากรทั้งหมด ปฏิเสธความพยายามเชื่อมต่อ BGP ขาเข้าทั้งหมด และเริ่มต้นการเชื่อมต่อ TCP กับอุปกรณ์ปลายทาง สถานะที่สองคือสถานะ Connect ในสถานะ Connect เราเตอร์จะรอให้การเชื่อมต่อ TCP เสร็จสมบูรณ์ และเปลี่ยนไปสู่สถานะ OpenSent หากสำเร็จ หากไม่สำเร็จ เราเตอร์จะเริ่มตัวจับเวลา ConnectRetry และเปลี่ยนไปสู่สถานะ Active เมื่อหมดเวลา ในสถานะ Active เราเตอร์จะรีเซ็ตตัวจับเวลา ConnectRetry เป็นศูนย์และกลับไปยังสถานะ Connect ในสถานะ OpenSent เราเตอร์จะส่งข้อความ Open และรอรับข้อความตอบกลับเพื่อเปลี่ยนไปสู่สถานะ OpenConfirm มีการแลกเปลี่ยนข้อความ Keepalive และเมื่อได้รับข้อความสำเร็จ เราเตอร์จะอยู่ในสถานะ Established ในสถานะ Established เราเตอร์สามารถส่งและรับข้อความ Keepalive, Update และ Notification จากอุปกรณ์ปลายทางได้

• สถานะไม่ได้ใช้งาน :
  • ปฏิเสธการเชื่อมต่อ BGP ขาเข้าทั้งหมด
  • เริ่มกระบวนการกำหนดค่าทริกเกอร์เหตุการณ์
  • เริ่มต้นการเชื่อมต่อ TCP กับคู่ค้า BGP ที่กำหนดค่าไว้
  • คอยรับการเชื่อมต่อ TCP จากอุปกรณ์ฝั่งตรงข้าม
  • เปลี่ยนสถานะเป็นเชื่อมต่อแล้ว
  • หากเกิดข้อผิดพลาดในขั้นตอนใดๆ ของกระบวนการ FSM เซสชัน BGP จะถูกยุติทันทีและกลับสู่สถานะว่าง (Idle) สาเหตุบางประการที่ทำให้เราเตอร์ไม่สามารถเปลี่ยนสถานะจากว่าง (Idle) ได้ ได้แก่:
    • พอร์ต TCP 179 ไม่ได้เปิดใช้งาน
    • พอร์ต TCP แบบสุ่มบนหมายเลข 1023 ไม่ได้เปิดใช้งาน
    • มีการตั้งค่าที่อยู่ Peer ไม่ถูกต้องบนเราเตอร์ตัวใดตัวหนึ่ง
    • หมายเลข AS ถูกตั้งค่าไม่ถูกต้องบนเราเตอร์ตัวใดตัวหนึ่ง
• สถานะการเชื่อมต่อ :
  • รอจนกว่าการเจรจา TCP กับฝั่งตรงข้ามจะสำเร็จ
  • BGP จะไม่ใช้เวลานานในสถานะนี้หากการเชื่อมต่อ TCP ได้ถูกสร้างขึ้นสำเร็จแล้ว
  • ส่งข้อความ Open ไปยังผู้รับปลายทางและเปลี่ยนสถานะเป็น OpenSent
  • หากเกิดข้อผิดพลาด BGP จะเปลี่ยนสถานะเป็น Active สาเหตุของข้อผิดพลาดบางประการ ได้แก่:
    • พอร์ต TCP 179 ไม่ได้เปิดใช้งาน
    • พอร์ต TCP แบบสุ่มบนหมายเลข 1023 ไม่ได้เปิดใช้งาน
    • มีการตั้งค่าที่อยู่ Peer ไม่ถูกต้องบนเราเตอร์ตัวใดตัวหนึ่ง
    • หมายเลข AS ถูกตั้งค่าไม่ถูกต้องบนเราเตอร์ตัวใดตัวหนึ่ง
• สถานะใช้งาน :
  • หากเราเตอร์ไม่สามารถสร้างการเชื่อมต่อ TCP ได้สำเร็จ เราเตอร์จะเปลี่ยนไปอยู่ในสถานะ Active
  • BGP FSM จะพยายามเริ่มต้นเซสชัน TCP ใหม่กับคู่ค้า และหากสำเร็จก็จะส่งข้อความ Open ไปยังคู่ค้า
  • หากไม่สำเร็จอีกครั้ง FSM จะถูกรีเซ็ตเป็นสถานะว่าง (Idle)
  • การทำงานผิดพลาดซ้ำๆ อาจส่งผลให้เราเตอร์สลับสถานะระหว่างไม่ได้ใช้งานและใช้งานอยู่ สาเหตุบางประการได้แก่:
    • พอร์ต TCP 179 ไม่ได้เปิดใช้งาน
    • พอร์ต TCP แบบสุ่มบนหมายเลข 1023 ไม่ได้เปิดใช้งาน
    • เกิดข้อผิดพลาดในการกำหนดค่า BGP
    • ความแออัด ของเครือข่าย
    • อินเทอร์เฟซเครือข่ายทำงานผิดปกติ
• สถานะ OpenSent :
  • BGP FSM จะคอยรับฟังข้อความ Open จากคู่ค้า
  • เมื่อได้รับข้อความแล้ว เราเตอร์จะตรวจสอบความถูกต้องของข้อความ Open นั้น
  • หากเกิดข้อผิดพลาด นั่นเป็นเพราะฟิลด์ใดฟิลด์หนึ่งในข้อความ Open ไม่ตรงกันระหว่างอุปกรณ์ทั้งสอง เช่น เวอร์ชัน BGP ไม่ตรงกัน เราเตอร์ที่เชื่อมต่อคาดหวัง My AS ที่แตกต่างกัน เป็นต้น จากนั้นเราเตอร์จะส่งข้อความ Notification ไปยังอุปกรณ์ปลายทางเพื่อแจ้งสาเหตุที่เกิดข้อผิดพลาด
  • หากไม่มีข้อผิดพลาด ระบบจะส่งข้อความ Keepalive ตั้งค่าตัวจับเวลาต่างๆ และเปลี่ยนสถานะเป็น OpenConfirm
• สถานะ OpenConfirm :
  • ฝั่งผู้รับกำลังรอรับข้อความ Keepalive จากฝั่งผู้รับอีกฝั่ง
  • หากได้รับข้อความ Keepalive และไม่มีตัวจับเวลาใดหมดอายุก่อนได้รับข้อความ Keepalive นั้น BGP จะเปลี่ยนสถานะเป็น Established
  • หากตัวจับเวลาหมดเวลาก่อนที่จะได้รับข้อความ Keepalive หรือหากเกิดข้อผิดพลาด เราเตอร์จะเปลี่ยนกลับไปสู่สถานะ Idle โดยอัตโนมัติ
• รัฐที่จัดตั้งขึ้น :
  • ในสถานะนี้ คู่ค้าจะส่งข้อความอัปเดตเพื่อแลกเปลี่ยนข้อมูลเกี่ยวกับแต่ละเส้นทางที่กำลังประกาศไปยังคู่ค้า BGP
  • หากมีข้อผิดพลาดใดๆ ในข้อความอัปเดต ระบบจะส่งข้อความแจ้งเตือนไปยังอุปกรณ์ปลายทาง และ BGP จะเปลี่ยนกลับไปสู่สถานะว่าง (Idle)

ในการจัดเรียงที่ง่ายที่สุด เราเตอร์ทั้งหมดภายใน AS เดียวกันและมีส่วนร่วมในการกำหนดเส้นทาง BGP จะต้องได้รับการกำหนดค่าในรูปแบบตาข่ายเต็มรูปแบบ: เราเตอร์แต่ละตัวจะต้องได้รับการกำหนดค่าให้เป็นคู่หูของเราเตอร์อื่นๆ ทุกตัว ซึ่งทำให้เกิดปัญหาด้านการขยายขนาด เนื่องจากจำนวนการเชื่อมต่อที่ต้องการจะเพิ่มขึ้นเป็นกำลังสองตามจำนวนเราเตอร์ที่เกี่ยวข้อง เพื่อบรรเทาปัญหานี้ BGP จึงนำเสนอสองทางเลือก ได้แก่ตัวสะท้อนเส้นทาง (RFC 4456) และกลุ่ม BGP (RFC 5065) การอธิบายเกี่ยวกับการประมวลผลการอัปเดตพื้นฐานต่อไปนี้จะสมมติว่าเป็นการใช้ตาข่าย iBGP เต็มรูปแบบ

เราเตอร์ BGP อาจยอมรับการอัปเดตข้อมูลการเข้าถึงระดับเครือข่าย (NLRI)จากเพื่อนบ้านหลายราย และโฆษณา NLRI ไปยังเพื่อนบ้านกลุ่มเดียวกัน หรือกลุ่มที่แตกต่างกันก็ได้ กระบวนการ BGP รักษาฐานข้อมูลการกำหนดเส้นทาง ไว้หลายฐาน :

• RIBตารางข้อมูลการกำหนดเส้นทางหลักของเราเตอร์
• Loc-RIB: ฐานข้อมูลการกำหนดเส้นทางภายใน BGP จะเก็บรักษาตารางการกำหนดเส้นทางหลักของตนเองแยกต่างหากจากตารางการกำหนดเส้นทางหลักของเราเตอร์
• Adj-RIB-In: สำหรับเพื่อนบ้านแต่ละราย กระบวนการ BGP จะรักษาฐานข้อมูลข้อมูลการกำหนดเส้นทางที่อยู่ติดกันในเชิงแนวคิด (incoming ) ซึ่งประกอบด้วย NLRI ที่ได้รับจากเพื่อนบ้าน
• Adj-RIB-Out: สำหรับเพื่อนบ้านแต่ละราย กระบวนการ BGP จะรักษาฐานข้อมูลข้อมูลการกำหนดเส้นทางที่อยู่ติดกันในเชิงแนวคิด (Concentration Adjacent Routing Information Base)ซึ่งประกอบด้วย NLRI ที่ส่งไปยังเพื่อนบ้านนั้น

การจัดเก็บทางกายภาพและโครงสร้างของตารางเชิงแนวคิดเหล่านี้ถูกกำหนดโดยผู้เขียนโค้ด BGP โครงสร้างของตารางเหล่านี้จะไม่ปรากฏให้เห็นแก่เราเตอร์ BGP อื่นๆ แม้ว่าโดยปกติแล้วจะสามารถสอบถามได้ด้วยคำสั่งการจัดการบนเราเตอร์ท้องถิ่นก็ตาม ตัวอย่างเช่น เป็นเรื่องปกติที่จะจัดเก็บAdj-RIB-InและAdj-RIB-Outไว้ ด้วยกันใน โครงสร้างข้อมูลLoc-RIBเดียวกันโดยมีข้อมูลเพิ่มเติมแนบมากับรายการ RIB ข้อมูลเพิ่มเติมจะบอกกระบวนการ BGP ว่ารายการแต่ละรายการควรอยู่ในสำหรับเพื่อนบ้านเฉพาะหรือไม่ กระบวนการเลือกเส้นทางระหว่างเพื่อนบ้านทำให้ได้รับนโยบายที่มีคุณสมบัติเหมาะสมสำหรับหรือไม่ และรายการมีคุณสมบัติเหมาะสมที่จะส่งไปยังกระบวนการจัดการตารางเส้นทางของเราเตอร์ท้องถิ่น หรือไม่Adj-RIBsLoc-RIBLoc-RIB

BGP จะส่งเส้นทางที่พิจารณาว่าดีที่สุดไปยังกระบวนการสร้างตารางเส้นทางหลัก ขึ้นอยู่กับการใช้งานของกระบวนการนั้น เส้นทาง BGP อาจไม่ได้รับการเลือกเสมอไป ตัวอย่างเช่น เส้นทางที่มีการเชื่อมต่อโดยตรง ซึ่งเรียนรู้จากฮาร์ดแวร์ของเราเตอร์เอง มักจะได้รับเลือกเป็นอันดับแรก ตราบใดที่อินเทอร์เฟซของเส้นทางที่มีการเชื่อมต่อโดยตรงนั้นยังทำงานอยู่ เส้นทาง BGP ไปยังปลายทางจะไม่ถูกเพิ่มเข้าไปในตารางเส้นทางหลัก เมื่ออินเทอร์เฟซนั้นหยุดทำงานและไม่มีเส้นทางที่ได้รับเลือกอีกต่อไป เส้นทาง Loc-RIB จะถูกติดตั้งในตารางเส้นทางหลัก

BGP ส่งข้อมูลที่กฎภายในเราเตอร์ที่ใช้ BGP สามารถใช้ในการตัดสินใจเชิงนโยบายได้ ข้อมูลบางส่วนที่ส่งมาซึ่งมีจุดประสงค์ชัดเจนในการนำไปใช้ในการตัดสินใจเชิงนโยบาย ได้แก่:

• ชุมชน
• ตัวแยกประเภทแบบหลายทางออก (MED)
• ระบบอัตโนมัติ (AS)

มาตรฐาน BGP ระบุปัจจัยการตัดสินใจหลายประการ มากกว่าที่ใช้ในกระบวนการกำหนดเส้นทางทั่วไปอื่นๆ สำหรับการเลือก NLRI ที่จะนำไปใส่ใน Loc-RIB จุดตัดสินใจแรกสำหรับการประเมิน NLRI คือ คุณสมบัติ next-hop ของมันต้องสามารถเข้าถึงได้ (หรือสามารถระบุได้) อีกวิธีหนึ่งในการกล่าวว่า next-hop ต้องสามารถเข้าถึงได้คือ ต้องมีเส้นทางที่ใช้งานอยู่แล้วในตารางกำหนดเส้นทางหลักของเราเตอร์ไปยังพรีฟิกซ์ที่สามารถเข้าถึงที่อยู่ next-hop ได้

ถัดไป สำหรับแต่ละเพื่อนบ้าน กระบวนการ BGP จะใช้เกณฑ์มาตรฐานและเกณฑ์ที่ขึ้นอยู่กับการใช้งานต่างๆ เพื่อตัดสินใจว่าเส้นทางใดควรถูกส่งไปยัง Adj-RIB-In ตามแนวคิด เพื่อนบ้านอาจส่งเส้นทางที่เป็นไปได้หลายเส้นทางไปยังปลายทาง แต่ลำดับความสำคัญอันดับแรกจะอยู่ที่ระดับเพื่อนบ้าน จะมีเพียงเส้นทางเดียวไปยังปลายทางแต่ละแห่งเท่านั้นที่จะถูกติดตั้งใน Adj-RIB-In ตามแนวคิด กระบวนการนี้จะลบเส้นทางใดๆ ที่ถูกถอนออกโดยเพื่อนบ้านออกจาก Adj-RIB-In ด้วย

เมื่อใดก็ตามที่ค่า Adj-RIB-In ในเชิงแนวคิดเปลี่ยนแปลง กระบวนการ BGP หลักจะตัดสินใจว่าเส้นทางใหม่ของเพื่อนบ้านเส้นใดเส้นหนึ่งนั้นเหมาะสมกว่าเส้นทางที่มีอยู่แล้วใน Loc-RIB หรือไม่ ถ้าใช่ ก็จะทำการแทนที่เส้นทางเหล่านั้น หากเส้นทางใดเส้นหนึ่งถูกถอนออกโดยเพื่อนบ้าน และไม่มีเส้นทางอื่นไปยังปลายทางนั้น เส้นทางนั้นจะถูกลบออกจาก Loc-RIB และจะไม่ถูกส่งไปยังตัวจัดการตารางเส้นทางหลักโดย BGP อีกต่อไป หากเราเตอร์ไม่มีเส้นทางไปยังปลายทางนั้นจากแหล่งที่ไม่ใช่ BGP เส้นทางที่ถูกถอนออกจะถูกลบออกจากตารางเส้นทางหลัก

ตราบใดที่ยังมีคะแนนเสมอกัน กระบวนการคัดเลือกเส้นทางจะดำเนินต่อไปในขั้นตอนถัดไป

การกำหนดค่าความชอบ น้ำหนัก และเกณฑ์อื่นๆ ในระดับท้องถิ่นสามารถปรับเปลี่ยนได้ด้วยการกำหนดค่าและการทำงานของซอฟต์แวร์ในระดับท้องถิ่น การปรับเปลี่ยนดังกล่าว แม้ว่าจะใช้กันทั่วไป แต่ก็อยู่นอกขอบเขตของมาตรฐาน ตัวอย่างเช่น คุณลักษณะ community (ดูด้านล่าง) ไม่ได้ถูกใช้โดยตรงในกระบวนการเลือก BGP กระบวนการ BGP neighbor สามารถมีกฎเพื่อกำหนดค่าความชอบในระดับท้องถิ่นหรือปัจจัยอื่นๆ โดยอิงจากกฎที่ตั้งโปรแกรมด้วยตนเองเพื่อกำหนดค่าคุณลักษณะหากค่า community ตรงกับเกณฑ์การจับคู่รูปแบบบางอย่าง หากเส้นทางนั้นเรียนรู้มาจาก peer ภายนอก กระบวนการ BGP ต่อ neighbor จะคำนวณค่าความชอบในระดับท้องถิ่นจากกฎนโยบายในระดับท้องถิ่น จากนั้นจึงเปรียบเทียบค่าความชอบในระดับท้องถิ่นของเส้นทางทั้งหมดจาก neighbor นั้น

ชุมชน BGP คือแท็กแอตทริบิวต์ที่สามารถนำไปใช้กับพรีฟิกซ์ขาเข้าหรือขาออกเพื่อให้บรรลุเป้าหมายร่วมกัน^{[ 21 ]}แม้ว่าโดยทั่วไปจะกล่าวกันว่า BGP อนุญาตให้ผู้ดูแลระบบกำหนดนโยบายเกี่ยวกับวิธีการจัดการพรีฟิกซ์โดย ISP แต่โดยทั่วไปแล้วสิ่งนี้เป็นไปไม่ได้อย่างแท้จริง ตัวอย่างเช่น โดยพื้นฐานแล้ว BGP ไม่มีแนวคิดที่จะอนุญาตให้ AS หนึ่งบอก AS อื่นให้จำกัดการโฆษณาพรีฟิกซ์เฉพาะลูกค้าที่เชื่อมต่อในอเมริกาเหนือเท่านั้น แต่โดยทั่วไปแล้ว ISP จะเผยแพร่รายการชุมชนที่เป็นที่รู้จักหรือเป็นกรรมสิทธิ์พร้อมคำอธิบายสำหรับแต่ละชุมชน ซึ่งโดยพื้นฐานแล้วจะกลายเป็นข้อตกลงเกี่ยวกับวิธีการจัดการพรีฟิกซ์

ตัวอย่างของชุมชนทั่วไป ได้แก่:

• การปรับการตั้งค่าตามความชอบในท้องถิ่น
• ทางภูมิศาสตร์
• ข้อจำกัดประเภทเพื่อนร่วมงาน
• การระบุการโจมตีแบบปฏิเสธการให้บริการ
• ตัวเลือกการเพิ่มคำนำหน้า AS

ผู้ให้บริการอินเทอร์เน็ตอาจระบุเส้นทางที่ได้รับจากลูกค้าโดยมีตัวอย่างดังต่อไปนี้:

• ถึงลูกค้าในอเมริกาเหนือ (ชายฝั่งตะวันออก) 3491:100
• ถึงลูกค้าในอเมริกาเหนือ (ชายฝั่งตะวันตก) 3491:200

ลูกค้าเพียงแค่ปรับการตั้งค่าเพื่อให้รวมชุมชนที่ถูกต้องสำหรับแต่ละเส้นทาง และ ISP มีหน้าที่รับผิดชอบในการควบคุมว่าคำนำหน้าจะถูกโฆษณาไปยังใครผู้ใช้ปลายทางไม่มีความสามารถทางเทคนิคในการบังคับใช้การกระทำที่ถูกต้องที่ดำเนินการโดย ISP แม้ว่าปัญหาในด้านนี้โดยทั่วไปจะเกิดขึ้นได้ยากและเกิดขึ้นโดยบังเอิญ^{[ 23 ] [ 24 ]}

เป็นกลยุทธ์ทั่วไปที่ลูกค้าปลายทางจะใช้ชุมชน BGP (โดยปกติคือ ASN:70,80,90,100) เพื่อควบคุมลำดับความสำคัญในพื้นที่ที่ ISP กำหนดให้กับเส้นทางที่โฆษณาแทนที่จะใช้ MED (ผลลัพธ์คล้ายกัน) คุณลักษณะของชุมชนนั้นสามารถส่งต่อได้ แต่ชุมชนที่ลูกค้าใช้แทบจะไม่แพร่กระจายออกไปนอก AS ของ next-hop เลย ISP บางรายไม่ได้เปิดเผยชุมชนของตนต่อสาธารณะ^{[ 25 ]}

แอตทริบิวต์ BGP Extended Community ถูกเพิ่มเข้ามาในปี 2549 ^{[ 26 ]}เพื่อขยายขอบเขตของแอตทริบิวต์ดังกล่าวและเพื่อจัดโครงสร้างแอตทริบิวต์ชุมชนโดยใช้ฟิลด์ประเภท รูปแบบที่ขยายประกอบด้วยไบต์หนึ่งหรือสองไบต์สำหรับฟิลด์ประเภท ตามด้วยไบต์เจ็ดหรือหกไบต์สำหรับเนื้อหาแอตทริบิวต์ชุมชนที่เกี่ยวข้องIANAบริหารจัดการทะเบียนสำหรับประเภท BGP Extended Communities ^{[ 27 ]}

แอตทริบิวต์ Extended Communities นั้นเป็นแอตทริบิวต์ BGP ที่สามารถส่งต่อได้และเป็นตัวเลือก บิตใน ฟิลด์ Typeภายในแอตทริบิวต์จะตัดสินว่า Extended Community ที่เข้ารหัสมีลักษณะที่สามารถส่งต่อได้หรือไม่ได้ ดังนั้น IANA registry จึงจัดเตรียมช่วงหมายเลขที่แตกต่างกันสำหรับประเภทแอตทริบิวต์ เนื่องจากช่วงแอตทริบิวต์ที่ขยายออกไป การใช้งานจึงมีหลากหลาย RFC 4360 ได้กำหนด "Two-Octet AS Specific Extended Community", "IPv4 Address Specific Extended Community", "Opaque Extended Community", "Route Target Community" และ "Route Origin Community" ไว้เป็นตัวอย่าง ร่าง BGP QoS จำนวนหนึ่งยังใช้โครงสร้างแอตทริบิวต์ Extended Community นี้สำหรับการส่งสัญญาณ QoS ระหว่างโดเมน^{[ 28 ]}

เมื่อมีการนำหมายเลข AS 32 บิตมาใช้ ปัญหาบางอย่างก็ปรากฏชัดเจนขึ้นทันทีเกี่ยวกับแอตทริบิวต์ชุมชนที่กำหนดฟิลด์ ASN เพียง 16 บิต ซึ่งป้องกันการจับคู่ระหว่างฟิลด์นี้กับค่า ASN จริง ตั้งแต่ปี 2014 ชุมชนแบบขยายสามารถใช้งานร่วมกับ ASN 32 บิตได้^{[ 29 ]}เพื่อรองรับหมายเลข AS 32 บิตในชุมชน BGP จึงมีการกำหนดแอตทริบิวต์ชุมชนขนาดใหญ่ 12 ไบต์^{[ 30 ] [ 31 ]}โดยแบ่งออกเป็นสามฟิลด์ ฟิลด์ละ 4 ไบต์ (AS:ฟังก์ชัน:พารามิเตอร์) ^{[ 32 ]}

MEDs ซึ่งกำหนดไว้ในมาตรฐาน BGP หลัก เดิมทีมีจุดประสงค์เพื่อแสดงให้ AS เพื่อนบ้านอื่นทราบถึงความต้องการของ AS ที่โฆษณาว่าลิงก์ใดในหลายๆ ลิงก์นั้นเหมาะสมที่สุดสำหรับทราฟฟิกขาเข้า อีกหนึ่งการใช้งานของ MEDs คือการโฆษณาค่า ซึ่งโดยทั่วไปจะอิงตามค่าความล่าช้า ของ AS หลายๆ ตัวที่มีอยู่ในIXPซึ่งเป็นค่าที่ AS เหล่านั้นกำหนดขึ้นเพื่อส่งทราฟฟิกไปยังปลายทางบางแห่ง

เราเตอร์บางรุ่น (เช่น Juniper) จะใช้ค่า Metric จาก OSPF ในการกำหนดค่า MED

ตัวอย่างการใช้งาน MED ร่วมกับ BGP เมื่อส่งออกไปยัง BGP บน Juniper SRX

# run show ospf route Topology default Route Table: Prefix Path Route NH Metric NextHop Nexthop  Type Type Type Interface Address/LSP 10.32.37.0/24 Intra Network IP 16777215 10.32.37.0/26 Intra Network IP 101 ge-0/0/1.0 10.32.37.241 10.32.37.64/26 Intra Network IP 102 ge-0/0/1.0 10.32.37.241 10.32.37.128/26 Intra Network IP 101 ge-0/0/1.0 10.32.37.241#แสดงเส้นทางการโฆษณาโปรโตคอลbgp 10.32.94.169  Prefix Nexthop MED Lclpref AS path * 10.32.37.0/24 Self 16777215 I * 10.32.37.0/26 Self 101 I * 10.32.37.64/26 Self 102 I * 10.32.37.128/26 Self 101 I 

ข้อความ BGP ทั้งหมดมีรูปแบบส่วนหัวดังต่อไปนี้

เครื่องหมาย: 128 บิต

รวมไว้เพื่อความเข้ากันได้ ต้องตั้งค่าทั้งหมดเป็นหนึ่ง

ความยาว: 16 บิต

ความยาวทั้งหมดของข้อความในหน่วยอ็อกเท็ต รวมทั้งส่วนหัว

ประเภท: 8 บิต

ประเภทของข้อความ BGP ค่าที่กำหนดค่าไว้มีดังนี้:

• เปิด (1)
• อัปเดต (2)
• การแจ้งเตือน (3)
• KeepAlive (4)
• รีเฟรชเส้นทาง (5)

ด้วย แพ็กเก็ต แบบเปิด (Open packet) เซสชัน BGP สามารถเริ่มต้นได้

เวอร์ชัน: 8 บิต

เวอร์ชันของ BGP ที่ใช้

AS ของฉัน: 16 บิต

หมายเลขระบบอัตโนมัติของผู้ส่ง

ระยะเวลาคงค่า: 16 บิต

ตัวจับเวลาหมดเวลา ใช้ในการคำนวณข้อความ KeepAlive ค่าเริ่มต้นคือ 90 วินาที

รหัส BGP: 32 บิต

เก็บที่อยู่ IP ของผู้ส่งไว้

ความยาวของพารามิเตอร์: 8 บิต

ความยาวทั้งหมดของฟิลด์พารามิเตอร์ในหน่วยอ็อกเท็ต หากฟิลด์นี้ (บังคับ) ^{[ 11 ] : §4.2} เป็นศูนย์ แสดงว่าไม่มีพารามิเตอร์ในข้อความ

พารามิเตอร์: ตัวแปร

พารามิเตอร์เสริม ฟิลด์นี้ใช้เพื่อสื่อสารความสามารถที่ผู้ส่งแพ็กเก็ตนี้มีให้กับคู่ค้า[ ^{33 ] IANA}จะดูแลรายการความสามารถทั้งหมด

ตัวอย่างข้อความเปิด

ประเภท: เปิดข้อความ (1) เวอร์ชัน: 4 หมายเลข AS ของฉัน: 64496 ระยะเวลารอสาย: 90 รหัส BGP: 192.0.2.254 พารามิเตอร์เสริม ความยาว: 16 พารามิเตอร์เสริม: ความสามารถ: ความสามารถในการขยายโปรโตคอลหลายรายการ (1) ความสามารถ: ความสามารถในการรีเฟรชเส้นทาง (2) ความสามารถ: ความสามารถในการรีเฟรชเส้นทางขั้นสูง (70) 

เฉพาะการเปลี่ยนแปลงเท่านั้นที่จะถูกส่งไป หลังจากทำการแลกเปลี่ยนครั้งแรกแล้ว จะส่งเฉพาะส่วนต่าง (เพิ่ม/เปลี่ยนแปลง/ลบ) เท่านั้น

ความยาวของเส้นทางที่ถูกยกเลิก: 16 บิต

ความยาวของเส้นทางที่ถูกยกเลิกต่อไปนี้ อาจเป็นศูนย์หากไม่มีเส้นทางใดถูกยกเลิก

เส้นทางที่ยกเลิก: เปลี่ยนแปลงได้

รายชื่อเส้นทางที่ถูกยกเลิก โดยระบุเป็นชุดของคู่ <ความยาว, คำนำหน้า >

ความยาวแอตทริบิวต์เส้นทางทั้งหมด: 16 บิต

ความยาวของแอตทริบิวต์เส้นทางต่อไปนี้ อาจเป็นศูนย์หากไม่มีแอตทริบิวต์ใดๆ

คุณลักษณะของเส้นทาง: ตัวแปร

รายการคุณลักษณะของเส้นทาง ซึ่งระบุไว้ในรูปแบบโครงสร้างTLV หลายชุด

ข้อมูลการเข้าถึงระดับเครือข่าย (NLRI): ตัวแปร

ข้อมูลการเข้าถึงระบุเป็นชุดของคู่ <ความยาว, คำนำหน้า> ความยาวของฟิลด์นี้สามารถคำนวณได้ดังนี้: ความยาว - 23 - ความยาวของเส้นทางที่ถูกยกเลิก - ความ ยาวคุณลักษณะเส้นทางทั้งหมด

ตัวอย่างข้อความอัปเดต

ประเภท: ข้อความอัปเดต (2) ระยะเวลาของเส้นทางที่ถูกยกเลิก: 0 ความยาวแอตทริบิวต์เส้นทางทั้งหมด: 25 คุณลักษณะของเส้นทาง ที่มา: IGP AS_PATH: 64500 NEXT_HOP: 192.0.2.254 ดิสก์ทางออกหลายทาง: 0 ข้อมูลการเข้าถึงระดับเครือข่าย (NLRI) 192.0.2.0/27 192.0.2.32/27 192.0.2.64/27

หากเกิดข้อผิดพลาด แสดงว่าฟิลด์ใดฟิลด์หนึ่งในข้อความ OPEN หรือ UPDATE ไม่ตรงกันระหว่างคู่ค้า ตัวอย่างเช่น เวอร์ชัน BGP ไม่ตรงกัน หรือเราเตอร์คู่ค้าคาดหวัง 'My AS' ที่แตกต่างกัน จากนั้นเราเตอร์จะส่งข้อความแจ้งเตือนไปยังคู่ค้าเพื่อระบุสาเหตุที่เกิดข้อผิดพลาด ข้อผิดพลาดในการสื่อสารมักนำไปสู่การยุติเซสชัน BGP เพื่อหลีกเลี่ยงการยุติเซสชันจำนวนมากเนื่องจากข้อผิดพลาดเพียงครั้งเดียว ซึ่งอาจเกิดขึ้นในสถานการณ์ที่ซับซ้อนกับเราเตอร์ที่มีความสามารถจำกัด จึงต้องใช้ความพยายามเป็นพิเศษในการแยกปัญหาและรักษาเซสชันส่วนใหญ่ให้ทำงานต่อไป^{[ 34 ]}

รหัสข้อผิดพลาด: 8 บิต

ค่าที่บ่งบอกถึงประเภทหรือที่มาของข้อผิดพลาด

รหัสข้อผิดพลาดย่อย: 8 บิต

ค่าที่ระบุว่าเกิดข้อผิดพลาดอะไรขึ้น

 รหัสข้อผิดพลาด และ รหัสย่อย

รหัสข้อผิดพลาด	ชื่อ	รหัสย่อย
		รหัส	ชื่อ
1	ข้อผิดพลาดส่วนหัวของข้อความ	1	การเชื่อมต่อไม่ตรงกัน
		2	ความยาวข้อความไม่ดี
		3	ประเภทข้อความไม่ถูกต้อง
2	ข้อผิดพลาดในการเปิดข้อความ	1	หมายเลขเวอร์ชันที่ไม่รองรับ
		2	เพื่อนร่วมงานที่ไม่ดี AS.
		3	รหัส BGP ไม่ถูกต้อง
		4	รหัสยืนยันตัวตนไม่รองรับ
		5	การตรวจสอบสิทธิ์ล้มเหลว
		6	ระยะเวลารอสายที่ยอมรับไม่ได้
3	ข้อความอัปเดตผิดพลาด	1	รายการแอตทริบิวต์ผิดรูปแบบ
		2	คุณลักษณะที่รู้จักกันดีแต่ไม่ได้รับการยอมรับ
		3	คุณลักษณะที่รู้จักกันดีหายไป
		4	ข้อผิดพลาดเกี่ยวกับแฟล็กแอตทริบิวต์
		5	ข้อผิดพลาดเกี่ยวกับความยาวของแอตทริบิวต์
		6	แอตทริบิวต์ ORIGIN ไม่ถูกต้อง
		7	AS Routing Loop
		8	แอตทริบิวต์ NEXT_HOP ไม่ถูกต้อง
		9	ข้อผิดพลาดเกี่ยวกับแอตทริบิวต์เสริม
		10	ช่องข้อมูลเครือข่ายไม่ถูกต้อง
		11	AS_PATH มีรูปแบบไม่ถูกต้อง
4	เวลาการล็อกหมดลงแล้ว
5	ข้อผิดพลาดของเครื่องสถานะจำกัด
6	หยุด

ข้อมูล: ตัวแปร

ข้อมูลเพิ่มเติมเพื่อช่วยในการวินิจฉัยปัญหา (ไม่บังคับ)

ตัวอย่างข้อความแจ้งเตือน

ประเภท: ข้อความแจ้งเตือน (3) รหัสข้อผิดพลาดหลัก: ข้อผิดพลาดข้อความเปิด (2) รหัสข้อผิดพลาดเล็กน้อย (ข้อความเปิด): Peer AS ไม่ถูกต้อง (2) เซิร์ฟเวอร์ปลายทางที่ไม่ถูกต้อง AS: 65200 

ข้อความ KeepAlive จะถูกส่งเป็นระยะๆ โดยทั้งสองฝ่ายในเซสชัน เพื่อตรวจสอบว่าอีกฝ่ายยังคงใช้งานได้อยู่หรือไม่ ควรส่งข้อความเหล่านี้ในช่วงเวลาหนึ่งในสามของเวลาholdtimeทั้งหมด

แพ็กเก็ต Keep-alive ไม่มีข้อมูลอยู่ภายใน

นอกเหนือจากประเภทข้อความ BGP เริ่มต้นแล้ว ยังมี route-refresh ซึ่งช่วยให้สามารถอัปเดตแบบนุ่มนวลได้Adj-RIB-inโดยไม่ต้องรีเซ็ตการเชื่อมต่อ^{[ 35 ]}

ก่อนที่จะใช้ฟีเจอร์นี้ จะต้องระบุความสามารถ 'Route Refresh Capability (2)' ในข้อความ 'Open' การอัปเดตเส้นทางแบบละเอียดอาจทำได้เมื่อมีการระบุความสามารถ 'Enhanced Route Refresh Capability (70)' ด้วย

รหัสระบุตระกูลที่อยู่ (AFI): 16 บิต

ตัวระบุสำหรับตระกูลที่อยู่ ( IPv4 , IPv6 , IPX , AppleTalkเป็นต้น) รายชื่อนี้ได้รับการดูแลโดยIANA

ชนิดย่อยของข้อความ: 8 บิต

ฟิลด์นี้ระบุว่าข้อความรีเฟรชเส้นทางนี้เป็นประเภทใด^{[ 36 ]}

ตัวระบุตระกูลที่อยู่ถัดไป: 8 บิต

ช่องนี้ให้ข้อมูลเพิ่มเติมเกี่ยวกับประเภทของข้อมูลการเข้าถึงระดับเครือข่าย (Network Layer Reachability Information หรือ NLRI) ที่อยู่ในแอตทริบิวต์ ค่า: 1 (unicast); 2 (multicast); 3 (ทั้งสองแบบ)

ข้อมูลการเข้าถึงระดับเครือข่าย (NLRI): ตัวแปร

ข้อมูลการเข้าถึงระบุเป็นชุดของคู่ <ความยาว, คำนำหน้า>

ตัวอย่างข้อความ ROUTE-REFRESH

ประเภท: ข้อความ ROUTE-REFRESH (5) ตัวระบุตระกูลที่อยู่ (AFI): IPv4 (1) ประเภทย่อย: คำขอรีเฟรชเส้นทางปกติ (0) ตัวระบุตระกูลที่อยู่ถัดไป (SAFI): ยูนิคาสต์ (1) 

BGP เป็น "โปรโตคอลการกำหนดเส้นทางที่ปรับขนาดได้ดีที่สุด" ^{[ 37 ]}

ระบบอิสระที่มีโปรโตคอล BGP ภายใน (iBGP) จะต้องให้เราเตอร์ทุกตัวที่มี iBGP เชื่อมต่อถึงกันแบบFull Mesh (ที่ทุกคนสื่อสารกันโดยตรง) การกำหนดค่าแบบ Full Mesh นี้ต้องการให้เราเตอร์แต่ละตัวรักษาการเชื่อมต่อกับเราเตอร์ตัวอื่นทุกตัว ในเครือข่ายขนาดใหญ่ จำนวนการเชื่อมต่อดังกล่าวอาจทำให้ประสิทธิภาพของเราเตอร์ลดลง เนื่องจากหน่วยความจำไม่เพียงพอหรือความต้องการประมวลผลของ CPU สูง

ตัวสะท้อนเส้นทาง (RR) ช่วยลดจำนวนการเชื่อมต่อที่จำเป็นใน AS เราเตอร์ตัวเดียว (หรือสองตัวเพื่อความซ้ำซ้อน) สามารถกำหนดให้เป็น RR ได้ เราเตอร์อื่นๆ ใน AS จำเป็นต้องกำหนดค่าให้เป็น peer กับ RR เท่านั้น RR นำเสนอทางเลือกแทนข้อกำหนด full-mesh เชิงตรรกะของ iBGP จุดประสงค์ของ RR คือการรวมศูนย์ เราเตอร์ BGP หลายตัวสามารถ peer กับจุดศูนย์กลางคือ RR ซึ่งทำหน้าที่เป็นเซิร์ฟเวอร์ RR แทนที่จะ peer กับเราเตอร์อื่นๆ ทุกตัวใน full mesh เราเตอร์ iBGP อื่นๆ ทั้งหมดจะกลายเป็นไคลเอ็นต์ RR ^{[ 38 ]}

วิธีการนี้ คล้ายกับ ฟีเจอร์ DR/BDR ของ OSPFซึ่งช่วยเพิ่มความสามารถในการปรับขนาดของ iBGP ในเครือข่ายขนาดใหญ่ ในเครือข่าย iBGP แบบ mesh เต็มรูปแบบที่มีเราเตอร์ 10 ตัว จำเป็นต้องใช้คำสั่ง CLI ถึง 90 คำสั่ง (กระจายอยู่ทั่วเราเตอร์ทั้งหมดในโทโพโลยี) เพียงเพื่อกำหนด remote-AS ของแต่ละ peer ซึ่งจะกลายเป็นเรื่องยุ่งยากในการจัดการอย่างรวดเร็ว โทโพโลยี RR สามารถลดคำสั่งเหล่านี้จาก 90 คำสั่งเหลือเพียง 18 คำสั่ง ซึ่งเป็นโซลูชันที่เหมาะสมสำหรับเครือข่ายขนาดใหญ่ที่ดูแลโดย ISP

RR เป็นจุดล้มเหลวเพียงจุดเดียวดังนั้นจึงต้องกำหนดค่า RR อย่างน้อยหนึ่งตัวเพื่อเพิ่มความซ้ำซ้อน เนื่องจากเป็นโหนดเพิ่มเติมสำหรับเราเตอร์อีก 10 ตัว จึงทำให้จำนวนคำสั่ง CLI เพิ่มขึ้นเป็นสองเท่าโดยประมาณ โดยต้องใช้คำสั่งเพิ่มเติม11 × 2 − 2 = 20คำสั่งในกรณีนี้ ในสภาพแวดล้อม BGP แบบมัลติพาธ RR เพิ่มเติมยังสามารถเป็นประโยชน์ต่อเครือข่ายโดยการเพิ่มปริมาณงานการกำหนดเส้นทางในพื้นที่ หาก RR ทำหน้าที่เป็นเราเตอร์แบบดั้งเดิมแทนที่จะเป็นเพียงบทบาทเซิร์ฟเวอร์ RR โดยเฉพาะ

ทั้ง RR และคอนเฟเดอเรชันช่วยลดจำนวนพีร์ iBGP ของแต่ละเราเตอร์ จึงช่วยลดภาระการประมวลผลลงได้ RR เป็นเทคนิคที่ช่วยเพิ่มประสิทธิภาพการทำงานโดยตรง ในขณะที่คอนเฟเดอเรชันยังสามารถใช้เพื่อกำหนดนโยบายที่ละเอียดกว่าได้อีกด้วย

เซิร์ฟเวอร์ RR จะกระจายเส้นทางภายใน AS โดยอิงตามกฎต่อไปนี้:

• เส้นทางต่างๆ จะถูกส่งไปยังอุปกรณ์ eBGP เสมอ
• เส้นทางต่างๆ จะไม่แสดงให้ผู้สร้างเส้นทางเห็น
• หากได้รับเส้นทางจากโหนดที่ไม่ใช่ไคลเอ็นต์ ให้ส่งข้อมูลนั้นไปยังโหนดไคลเอ็นต์ด้วย
• หากได้รับเส้นทางจากโหนดไคลเอ็นต์ ให้ส่งต่อเส้นทางนั้นไปยังโหนดไคลเอ็นต์และโหนดที่ไม่ใช่ไคลเอ็นต์ด้วย

RR และไคลเอ็นต์ของมันจะรวมตัวกันเป็นคลัสเตอร์ จากนั้น รหัสคลัสเตอร์จะถูกแนบไปกับทุกเส้นทางที่ RR ประกาศไปยังไคลเอ็นต์หรืออุปกรณ์อื่นที่ไม่ใช่ไคลเอ็นต์ รหัสคลัสเตอร์เป็นคุณลักษณะ BGP แบบสะสมและไม่ส่งต่อ และทุก RR ต้องเพิ่มรหัสคลัสเตอร์ในพื้นที่ลงในรายการคลัสเตอร์เพื่อหลีกเลี่ยงลูปการกำหนดเส้นทาง

สมาพันธ์คือชุดของระบบอิสระ ในทางปฏิบัติทั่วไป^{[ 40 ]}อินเทอร์เน็ตโดยรวมจะเห็นเพียงหมายเลข AS ของสมาพันธ์เพียงหมายเลขเดียวเท่านั้น สมาพันธ์ถูกใช้ในเครือข่ายขนาดใหญ่มาก ซึ่งสามารถกำหนดค่า AS ขนาดใหญ่ให้ครอบคลุม AS ภายในที่เล็กกว่าและจัดการได้ง่ายกว่า

AS แบบรวมกลุ่ม (Confederated AS) ประกอบด้วย AS หลายตัว แต่ละ AS ในกลุ่มจะมี iBGP แบบเต็มรูปแบบและมีการเชื่อมต่อกับ AS อื่นๆ ภายในกลุ่ม แม้ว่า AS เหล่านั้นจะมี eBGP peer กับ AS ภายในกลุ่ม แต่ AS เหล่านั้นจะแลกเปลี่ยนข้อมูลการกำหนดเส้นทางราวกับว่าใช้ iBGP ด้วยวิธีนี้ กลุ่มจะรักษาข้อมูล next hop, metric และ local preference ไว้ได้ สำหรับโลกภายนอก กลุ่มจะปรากฏเป็น AS เดียว ด้วยโซลูชันนี้ ปัญหา iBGP transit AS สามารถแก้ไขได้ เนื่องจาก iBGP ต้องการการเชื่อมต่อแบบเต็มรูปแบบระหว่างเราเตอร์ BGP ทั้งหมด ซึ่งหมายถึงจำนวนเซสชัน TCP ที่มาก และการทำซ้ำของทราฟฟิกการกำหนดเส้นทางที่ไม่จำเป็น

สามารถใช้ Confederations ร่วมกับ route reflectors ได้ ทั้ง Confederations และ route reflectors อาจเกิดการแกว่งตัวอย่างต่อเนื่องได้ เว้นแต่จะปฏิบัติตามกฎการออกแบบเฉพาะที่มีผลต่อทั้ง BGP และโปรโตคอลการกำหนดเส้นทางภายใน^{[ 41 ]}

ทางเลือกเหล่านี้อาจก่อให้เกิดปัญหาของตัวเองได้เช่นกัน ซึ่งรวมถึงปัญหาดังต่อไปนี้:

• การแกว่งของเส้นทาง
• การกำหนดเส้นทางที่ไม่เหมาะสม
• การเพิ่มขึ้นของเวลาบรรจบกันของ BGP ^{[ 42 ]}

นอกจากนี้ ตัวสะท้อนเส้นทาง (route reflectors) และกลุ่มเครือข่าย BGP (BGP confederations) ไม่ได้ถูกออกแบบมาเพื่อช่วยให้การกำหนดค่าเราเตอร์ BGP ง่ายขึ้น อย่างไรก็ตาม เครื่องมือเหล่านี้เป็นเครื่องมือทั่วไปสำหรับสถาปนิกเครือข่าย BGP ที่มีประสบการณ์ เครื่องมือเหล่านี้อาจนำมาใช้ร่วมกันได้ เช่น ในรูปแบบลำดับชั้นของตัวสะท้อนเส้นทาง

ตารางเส้นทางที่จัดการโดยการใช้งาน BGP จะได้รับการปรับเปลี่ยนอย่างต่อเนื่องเพื่อสะท้อนการเปลี่ยนแปลงที่เกิดขึ้นจริงในเครือข่าย เช่น ลิงก์หรือเราเตอร์ที่หยุดทำงานและกลับมาทำงานอีกครั้ง ในเครือข่ายโดยรวม การเปลี่ยนแปลงเหล่านี้มักเกิดขึ้นเกือบตลอดเวลา แต่สำหรับเราเตอร์หรือลิงก์ใดๆ การเปลี่ยนแปลงนั้นคาดว่าจะเกิดขึ้นไม่บ่อยนัก หากเราเตอร์ได้รับการกำหนดค่าหรือจัดการอย่างไม่ถูกต้อง อาจทำให้เกิดวงจรการสลับสถานะระหว่างหยุดทำงานและกลับมาทำงานอย่างรวดเร็ว รูปแบบการถอนและประกาศซ้ำๆ นี้ ซึ่งเรียกว่าroute flappingสามารถทำให้เกิดกิจกรรมมากเกินไปในเราเตอร์อื่นๆ ทั้งหมดที่รู้จักเอนทิตีที่กำลังวนรอบ เนื่องจากเส้นทางเดียวกันถูกแทรกและถอนออกจากตารางเส้นทางอย่างต่อเนื่อง การออกแบบ BGP เป็นเช่นนั้น การส่งข้อมูลอาจไม่ทำงานในขณะที่เส้นทางกำลังได้รับการอัปเดต บนอินเทอร์เน็ต การเปลี่ยนแปลงเส้นทาง BGP อาจทำให้เกิดการหยุดชะงักเป็นเวลาหลายนาที

คุณสมบัติที่เรียกว่าการลดความผันผวนของเส้นทาง (route flap damping)ถูกสร้างขึ้นในระบบ BGP หลายระบบ^{[ 43 ]}เพื่อพยายามลดผลกระทบของความผันผวนของเส้นทาง หากไม่มีการลดความผันผวน กิจกรรมที่มากเกินไปอาจทำให้เกิดภาระการประมวลผลหนักบนเราเตอร์ ซึ่งอาจทำให้การอัปเดตเส้นทางอื่นล่าช้า และส่งผลต่อเสถียรภาพการกำหนดเส้นทางโดยรวม การลดความผันผวนจะทำให้ความผันผวนของเส้นทางลดลงแบบทวีคูณในครั้งแรก เมื่อเส้นทางไม่สามารถใช้งานได้และปรากฏขึ้นอีกครั้งอย่างรวดเร็ว การลดความผันผวนจะไม่มีผล เพื่อรักษาระยะเวลาการสลับเส้นทางตามปกติของ BGP ในครั้งที่สอง BGP จะละเว้นพรีฟิกซ์นั้นเป็นระยะเวลาหนึ่ง การเกิดขึ้นครั้งต่อๆ ไปจะถูกละเลยเป็นระยะเวลานานขึ้นแบบทวีคูณ หลังจากความผิดปกติสิ้นสุดลงและระยะเวลาที่เหมาะสมผ่านไปสำหรับเส้นทางที่ก่อปัญหา พรีฟิกซ์สามารถกลับมาใช้งานได้อีกครั้งโดยเริ่มต้นใหม่ การลดความผันผวนยังสามารถลดการโจมตีแบบปฏิเสธการให้บริการได้ อีกด้วย

นอกจากนี้ ยังมีข้อเสนอแนะว่าการลดการสั่นสะเทือนของเส้นทางเป็นคุณสมบัติที่พึงประสงค์มากกว่าหากนำไปใช้กับเซสชันโปรโตคอลเกตเวย์ชายแดนภายนอก (เซสชัน eBGP หรือเรียกง่ายๆ ว่า peer ภายนอก) และไม่ใช่กับเซสชันโปรโตคอลเกตเวย์ชายแดนภายใน (เซสชัน iBGP หรือเรียกง่ายๆ ว่า peer ภายใน) ^{[ 43 ] : §4} ด้วยวิธีการนี้ เมื่อเส้นทางเกิดการสั่นสะเทือนภายในระบบอิสระ เส้นทางนั้นจะไม่ถูกเผยแพร่ไปยัง AS ภายนอก การสั่นสะเทือนของเส้นทางไปยัง eBGP จะทำให้เกิดการสั่นสะเทือนต่อเนื่องสำหรับเส้นทางนั้นๆ ตลอดโครงข่ายหลัก วิธีนี้ยังช่วยหลีกเลี่ยงค่าใช้จ่ายเพิ่มเติมของการลดการสั่นสะเทือนของเส้นทางสำหรับเซสชัน iBGP ได้อย่างมีประสิทธิภาพ

งานวิจัยต่อมาแสดงให้เห็นว่าการลดการสั่นสะเทือนของแฟลปอาจทำให้เวลาบรรจบกันยาวนานขึ้นในบางกรณี และอาจทำให้เกิดการหยุดชะงักในการเชื่อมต่อแม้ว่าลิงก์จะไม่เกิดการสั่นสะเทือน ก็ตาม ^{[ 44 ] [ 45 ]}ยิ่งไปกว่านั้น เนื่องจากลิงก์หลักและโปรเซสเซอร์เราเตอร์เร็วขึ้น สถาปนิกเครือข่ายบางคนจึงแนะนำว่าการลดการสั่นสะเทือนของแฟลปอาจไม่สำคัญเท่าที่เคยเป็นมา เนื่องจากเราเตอร์สามารถจัดการกับการเปลี่ยนแปลงตารางการกำหนดเส้นทางได้เร็วขึ้นมาก^{[ 43 ]}สิ่งนี้ทำให้กลุ่มทำงานด้านการกำหนดเส้นทางของ RIPE เขียนว่า "ด้วยการใช้งานการลดการสั่นสะเทือนของแฟลป BGP ในปัจจุบัน ไม่แนะนำให้ใช้การลดการสั่นสะเทือนของแฟลปในเครือข่าย ISP ... หากมีการใช้งานการลดการสั่นสะเทือนของแฟลป ISP ที่ดำเนินการเครือข่ายนั้นจะทำให้เกิดผลข้างเคียงต่อลูกค้าและผู้ใช้อินเทอร์เน็ตของเนื้อหาและบริการของลูกค้า ... ผลข้างเคียงเหล่านี้มีแนวโน้มที่จะแย่กว่าผลกระทบที่เกิดจากการไม่ใช้การลดการสั่นสะเทือนของแฟลปเลย" ^{[ 46 ]}

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

จนกระทั่งปลายปี 2544 ตารางเส้นทางทั่วโลกเติบโตอย่างรวดเร็วมากจนอาจนำไปสู่การล่มสลายของการเชื่อมต่อในวงกว้าง เพื่อป้องกันปัญหานี้ ผู้ให้บริการอินเทอร์เน็ต (ISP) จึงร่วมมือกันลดขนาดของตารางเส้นทางทั่วโลกให้เหลือน้อยที่สุดเท่าที่จะเป็นไปได้ โดยใช้การกำหนดเส้นทางระหว่างโดเมนแบบไร้คลาส (CIDR) และการรวมเส้นทาง แม้ว่าวิธีนี้จะช่วยชะลอการเติบโตของตารางเส้นทางให้เป็นกระบวนการเชิงเส้นเป็นเวลาหลายปี แต่ด้วยความต้องการใช้ งานหลายเส้นทาง (multihoming)ที่เพิ่มขึ้นของเครือข่ายผู้ใช้ปลายทาง การเติบโตจึงกลับมาเป็นแบบเกินเชิงเส้นอีกครั้งในช่วงกลางปี ​​2547

ปัญหา ข้อมูลล้นระบบคล้ายกับปัญหา Y2Kเกิดขึ้นในปี 2014 สำหรับอุปกรณ์รุ่นที่ไม่ได้รับการอัปเดตอย่างเหมาะสม

ในขณะที่ตาราง BGP IPv4 เต็มรูปแบบ ณ เดือนสิงหาคม 2557 (512k วัน) ^{[ 47 ] [ 48 ]}มีพรีฟิกซ์เกิน 512,000 รายการ^{[ 49 ]}เราเตอร์รุ่นเก่าจำนวนมากมีขีดจำกัดที่ 512k (512,000–524,288) ^{[ 50 ] [ 51 ]}รายการตารางการกำหนดเส้นทาง ในวันที่ 12 สิงหาคม 2557 การหยุดชะงักอันเนื่องมาจากตารางเต็มส่งผลกระทบต่อeBay , LastPassและMicrosoft Azureและอื่นๆ^{[ 52 ]}เราเตอร์ Cisco จำนวนมากที่ใช้กันทั่วไปมีTCAM ซึ่งเป็นรูปแบบของ หน่วยความจำที่สามารถระบุที่อยู่เนื้อหาความเร็วสูงสำหรับการจัดเก็บเส้นทางที่โฆษณา BGP บนเราเตอร์ที่ได้รับผลกระทบ TCAM จะถูกจัดสรรโดยค่าเริ่มต้นเป็นเส้นทาง IPv4 512k และเส้นทาง IPv6 256k แม้ว่าจำนวนเส้นทาง IPv6 ที่ประกาศไว้จะมีเพียงประมาณ 20,000 เส้นทาง แต่จำนวนเส้นทาง IPv4 ที่ประกาศไว้กลับถึงขีดจำกัดเริ่มต้น ทำให้เกิดผลกระทบล้นเกินเนื่องจากเราเตอร์พยายามชดเชยปัญหานี้โดยใช้การกำหนดเส้นทางด้วยซอฟต์แวร์ที่ช้า (ตรงข้ามกับการกำหนดเส้นทางด้วยฮาร์ดแวร์ที่รวดเร็วผ่าน TCAM) วิธีหลักในการจัดการกับปัญหานี้คือ ผู้ให้บริการต้องเปลี่ยนการจัดสรร TCAM เพื่ออนุญาตให้มีรายการ IPv4 มากขึ้น โดยการจัดสรร TCAM บางส่วนที่สงวนไว้สำหรับเส้นทาง IPv6 ใหม่ ซึ่งต้องรีบูตเราเตอร์ส่วนใหญ่ ปัญหา 512,000 ได้รับการคาดการณ์โดยผู้เชี่ยวชาญด้านไอทีหลายคน^{[ 53 ] [ 54 ] [ 55 ]}

การจัดสรรจริงซึ่งผลักดันจำนวนเส้นทางให้สูงกว่า 512,000 เส้นทางนั้น มาจากการประกาศเส้นทางใหม่ประมาณ 15,000 เส้นทางในเวลาอันสั้น เริ่มตั้งแต่เวลา 07:48 UTC เส้นทางเหล่านี้เกือบทั้งหมดเป็นเส้นทางไปยังVerizon Autonomous Systems 701 และ 705 ซึ่งสร้างขึ้นจากการแยกบล็อกขนาดใหญ่ ทำให้เกิดเส้นทางใหม่/ 24เส้นทางหลายพันเส้นทาง และทำให้ตารางการกำหนดเส้นทางมีรายการถึง 515,000 รายการ เส้นทางใหม่เหล่านี้ดูเหมือนจะถูกรวมเข้าด้วยกันภายใน 5 นาที แต่ความไม่เสถียรบนอินเทอร์เน็ตยังคงดำเนินต่อไปอีกหลายชั่วโมง^{[ 56 ]}แม้ว่า Verizon จะไม่ได้ทำให้ตารางการกำหนดเส้นทางมีรายการเกิน 512,000 รายการในช่วงเวลาสั้นๆ แต่ก็คงเกิดขึ้นในไม่ช้าจากการเติบโตตามธรรมชาติ

การสรุปเส้นทางมักใช้เพื่อปรับปรุงการรวมกลุ่มของตารางเส้นทางทั่วโลกของ BGP ซึ่งจะช่วยลดขนาดตารางที่จำเป็นในเราเตอร์ของ AS สมมติว่า AS1 ได้รับการจัดสรรพื้นที่แอดเดรสขนาดใหญ่172.16.0.0/16 ซึ่งจะนับเป็นเส้นทางเดียวในตาราง แต่เนื่องจากข้อกำหนดของลูกค้าหรือวัตถุประสงค์ด้านการจัดการจราจร AS1 ต้องการประกาศเส้นทางที่เล็กกว่าและเฉพาะเจาะจงกว่า ได้แก่172.16.0.0/18 , 172.16.64.0/18 และ 172.16.128.0/18 เนื่องจากพรีฟิกซ์ 172.16.192.0/18 ไม่มีโฮสต์ใดๆดังนั้นAS1 จึงไม่ประกาศเส้นทางเฉพาะ172.16.192.0/18ทั้งหมดนี้จึงนับว่า AS1 ประกาศเส้นทางสี่เส้นทาง

AS2จะเห็นเส้นทางทั้งสี่จาก AS1 ( 172.16.0.0/16 , 172.16.0.0/18 , 172.16.64.0/18 และ 172.16.128.0/18 )และขึ้นอยู่กับนโยบายการกำหนดเส้นทางของ AS2 ว่าจะคัดลอกเส้นทางทั้งสี่หรือไม่ หรือเนื่องจาก172.16.0.0/16 ทับซ้อนกับเส้นทาง เฉพาะอื่นๆ ทั้งหมดจึง จะเก็บ เฉพาะข้อมูลสรุป172.16.0.0/16 เท่านั้น

หาก AS2ต้องการส่งข้อมูลไปยังพรีฟิกซ์172.16.192.0/18 ข้อมูลจะถูกส่งไปยังเราเตอร์ของ AS1 บนเส้นทาง172.16.0.0/16 ที่ AS1 ข้อมูลอาจถูกทิ้งหรือ อาจส่งข้อความ ICMP แจ้ง ว่าปลายทางไม่สามารถเข้าถึงได้ กลับมา ขึ้นอยู่กับการกำหนดค่าของเราเตอร์ของ AS1

หาก AS1ตัดสินใจยกเลิกเส้นทาง172.16.0.0/16 ใน ภายหลังเหลือเพียง172.16.0.0/18 , 172.16.64.0/18 และ 172.16.128.0/18 จำนวนเส้นทางที่ AS1 ประกาศจะลดลงเหลือสามเส้นทาง ขึ้นอยู่กับนโยบายการกำหนดเส้นทางของ AS2 มันจะจัดเก็บสำเนาของเส้นทางทั้งสาม หรือรวม172.16.0.0/18 และ172.16.64.0/18 เข้าด้วยกันเป็น172.16.0.0/17 ซึ่งจะทำให้จำนวนเส้นทางที่AS2จัดเก็บลดลงเหลือสองเส้นทาง ( 172.16.0.0/17และ172.16.128.0/18 )

หาก AS2ต้องการส่งข้อมูลไปยังพรีฟิกซ์172.16.192.0/18 ข้อมูลนั้น จะถูกทิ้ง หรือจะมีการส่งข้อความ ICMP แจ้งว่าปลายทางไม่สามารถเข้าถึงได้กลับไปยังเราเตอร์ของ AS2 (ไม่ใช่ AS1 เหมือนก่อนหน้านี้) เนื่องจาก172.16.192.0/18ไม่อยู่ในตารางเส้นทาง

ในปี พ.ศ. 2538 ข้อกำหนด BGP-4 ฉบับแรกได้เข้ารหัสหมายเลข AS บน 16 บิต^{[ 10 ]}สำหรับหมายเลข AS สาธารณะที่เป็นไปได้ 64,510 หมายเลข^{[ a ]} ​​ในปี พ.ศ. 2554 เหลือหมายเลข AS เพียง 15,000 หมายเลขเท่านั้น และการคาดการณ์^{[ 57 ]}ระบุว่าหมายเลข AS ที่มีอยู่จะหมดลงในเดือนกันยายน พ.ศ. 2556

ในปี 2550 การเข้ารหัส AS ได้ถูกขยายจาก 16 บิตเป็น 32 บิต^{[ 58 ]}ในขณะที่ยังคงช่วง AS 16 บิต (0 ถึง 65535) และหมายเลข AS ที่สงวนไว้ ซึ่งทำให้มีหมายเลข AS ที่ใช้งานได้สูงสุด 4 พันล้านหมายเลข นอกจากนี้ยังมีการกำหนดช่วง AS ส่วนตัวเพิ่มเติมอีกด้วย^{[ 59 ] [ b ]}เพื่ออนุญาตให้กลุ่มเราเตอร์ที่ไม่สามารถจัดการ ASN ใหม่เหล่านี้สามารถเดินทางผ่านได้ จึงมีการใช้แอตทริบิวต์ใหม่AS4_PATH (แบบส่งต่อได้) และ ASN 16 บิตพิเศษAS_TRANS (AS23456) ^{[ 61 ]}การกำหนด ASN 32 บิตเริ่มขึ้นในปี 2550

อีกปัจจัยหนึ่งที่ส่งผลต่อการเติบโตของตารางเส้นทางคือความจำเป็นในการกระจายโหลดของ เครือข่าย ที่มีหลายเส้นทางเชื่อมต่อ การกระจายปริมาณการรับส่งข้อมูลขาเข้าของเครือข่ายที่มีหลายเส้นทางเชื่อมต่อผ่านเส้นทางขาเข้าหลายเส้นทางนั้นไม่ใช่เรื่องง่าย เนื่องจากข้อจำกัดของกระบวนการเลือกเส้นทางของ BGP สำหรับเครือข่ายที่มีหลายเส้นทางเชื่อมต่อ หากเครือข่ายนั้นประกาศบล็อกเครือข่ายเดียวกันไปยัง BGP peer ทั้งหมด ผลที่ได้อาจทำให้ลิงก์ขาเข้าหนึ่งหรือหลายลิงก์เกิดความแออัด ในขณะที่ลิงก์อื่นๆ ยังคงใช้งานได้ไม่เต็มที่ เนื่องจากเครือข่ายภายนอกทั้งหมดเลือกชุดเส้นทางที่แออัดเหล่านั้นเป็นเส้นทางที่ดีที่สุด เช่นเดียวกับโปรโตคอลการกำหนดเส้นทางอื่นๆ ส่วนใหญ่ BGP ไม่สามารถตรวจจับความแออัดได้

เพื่อแก้ไขปัญหานี้ ผู้ดูแลระบบ BGP ของเครือข่ายที่มีการเชื่อมต่อหลายเส้นทางอาจแบ่งบล็อกที่อยู่ IP ขนาดใหญ่ที่ต่อเนื่องกันออกเป็นบล็อกขนาดเล็กกว่า และปรับแต่งการประกาศเส้นทางเพื่อให้บล็อกต่างๆ ดูเหมาะสมที่สุดบนเส้นทางที่แตกต่างกัน เพื่อให้เครือข่ายภายนอกเลือกเส้นทางที่แตกต่างกันในการเข้าถึงบล็อกต่างๆ ของเครือข่ายที่มีการเชื่อมต่อหลายเส้นทางนั้น กรณีเช่นนี้จะทำให้จำนวนเส้นทางที่ปรากฏในตาราง BGP ทั่วโลกเพิ่มขึ้น

วิธีหนึ่งในการแก้ไขปัญหาตารางเส้นทางที่เกี่ยวข้องกับการกระจายโหลดคือการติดตั้ง เกตเวย์ Locator/Identifier Separation Protocol (BGP/LISP) ภายในจุดแลกเปลี่ยนอินเทอร์เน็ตเพื่อให้สามารถจัดการการรับส่งข้อมูลขาเข้าผ่านลิงก์หลายลิงก์ได้ เทคนิคนี้ไม่ได้เพิ่มจำนวนเส้นทางที่ปรากฏในตาราง BGP ทั่วโลก

โดยการออกแบบ เราเตอร์ที่ใช้ BGP จะยอมรับเส้นทางที่ประกาศจากเราเตอร์ BGP อื่นๆ โดยค่าเริ่มต้น ซึ่งช่วยให้การกำหนดเส้นทางการรับส่งข้อมูลทั่วอินเทอร์เน็ตเป็นไปโดยอัตโนมัติและกระจายศูนย์ แต่ก็ทำให้อินเทอร์เน็ตมีความเสี่ยงต่อการหยุดชะงักโดยไม่ได้ตั้งใจหรือโดยเจตนาร้าย ซึ่งเรียกว่าการโจรกรรม BGPเนื่องจาก BGP ฝังอยู่ในระบบหลักของอินเทอร์เน็ตอย่างกว้างขวาง และมีเครือข่ายต่างๆ มากมายที่ดำเนินการโดยองค์กรต่างๆ ที่รวมกันเป็นอินเทอร์เน็ต การแก้ไขช่องโหว่นี้ (เช่น โดยการนำคีย์เข้ารหัสมาใช้เพื่อตรวจสอบตัวตนของเราเตอร์ BGP) จึงเป็นปัญหาที่ท้าทายทั้งในด้านเทคนิคและเศรษฐกิจ^{[ 62 ]}

Multiprotocol Extensions for BGP (MBGP) หรือที่บางครั้งเรียกว่า Multiprotocol BGP หรือ Multicast BGP ซึ่งกำหนดไว้ในRFC 4760เป็นส่วนขยายของ BGP ที่อนุญาตให้กระจายที่อยู่ประเภทต่างๆ (ที่เรียกว่าตระกูลที่อยู่) พร้อมกันได้ ในขณะที่ BGP มาตรฐานรองรับเฉพาะที่อยู่ unicast ของ IPv4 เท่านั้น แต่ Multiprotocol BGP รองรับทั้งที่อยู่ IPv4 และ IPv6 และรองรับทั้งแบบ unicast และ multicast ด้วย Multiprotocol BGP อนุญาตให้แลกเปลี่ยนข้อมูลเกี่ยวกับโทโพโลยีของเราเตอร์ที่รองรับ IP multicast แยกต่างหากจากโทโพโลยีของเราเตอร์ unicast IPv4 ทั่วไป ดังนั้นจึงอนุญาตให้มีโทโพโลยีการกำหนดเส้นทาง multicast ที่แตกต่างจากโทโพโลยีการกำหนดเส้นทาง unicast แม้ว่า MBGP จะช่วยให้สามารถแลกเปลี่ยนข้อมูลการกำหนดเส้นทาง multicast ระหว่างโดเมนได้ แต่ก็ยังจำเป็นต้องใช้โปรโตคอลอื่นๆ เช่น ตระกูล Protocol Independent Multicast เพื่อสร้างโครงสร้างต้นไม้และส่งต่อทราฟฟิก multicast BGP แบบหลายโปรโตคอลยังถูกใช้งานอย่างแพร่หลายในกรณีของMPLS L3 VPN เพื่อแลกเปลี่ยนป้ายกำกับ VPN ที่เรียนรู้สำหรับเส้นทางจากไซต์ลูกค้าผ่านเครือข่าย MPLS เพื่อแยกแยะความแตกต่างระหว่างไซต์ลูกค้าต่างๆ เมื่อทราฟฟิกจากไซต์ลูกค้าอื่นๆ มาถึงเราเตอร์ขอบของผู้ให้บริการเพื่อทำการกำหนดเส้นทาง  

อีกหนึ่งส่วนขยายของ BGP คือการกำหนดเส้นทางแบบหลายเส้นทาง (multipath routing ) โดยทั่วไปแล้วจะต้องการค่า MED, น้ำหนัก (weight), ต้นทาง (origin) และ AS-path ที่เหมือนกันทุกประการ แม้ว่าบางการใช้งานจะอนุญาตให้ผ่อนปรนการตรวจสอบ AS-path โดยคาดหวังเพียงความยาวของเส้นทางที่เท่ากันเท่านั้น แทนที่จะคาดหวังว่าหมายเลข AS ในเส้นทางนั้นจะต้องตรงกันด้วย จากนั้นสามารถขยายเพิ่มเติมได้ด้วยคุณสมบัติอย่างเช่น dmzlink-bw ของ Cisco ซึ่งช่วยให้สามารถกำหนดอัตราส่วนการแบ่งปันปริมาณการรับส่งข้อมูลตามค่าแบนด์วิดท์ที่กำหนดค่าไว้ในแต่ละลิงก์ได้

โดยค่าเริ่มต้น BGP รองรับการโฆษณาเส้นทางที่ดีที่สุดที่เลือกไว้ในเครื่องเพียงเส้นทางเดียวไปยังเพื่อนบ้านผ่านข้อความ Update เท่านั้นRFC 7911กำหนด ส่วนขยาย ADD-PATHซึ่งอนุญาตให้ BGP speaker โฆษณาเส้นทางหลายเส้นทางสำหรับปลายทางเดียวกันไปยังเพื่อนร่วมเครือข่ายได้ การใช้งานอย่างหนึ่งคือเมื่อใช้route reflector (RR) เพราะในกรณีนี้ RR สามารถโฆษณาเส้นทางทั้งหมดที่รู้จักไปยังไคลเอนต์ได้ แทนที่จะส่งเพียงเส้นทางเดียวที่เลือกตามกระบวนการตัดสินใจในเครื่อง ซึ่งอาจไม่ใช่เส้นทางที่ดีที่สุดสำหรับไคลเอนต์ทั้งหมด  

BGP4 เป็นมาตรฐานสำหรับการกำหนดเส้นทางบนอินเทอร์เน็ต และเป็นสิ่งที่ผู้ให้บริการอินเทอร์เน็ต (ISP) ส่วนใหญ่จำเป็นต้องใช้ในการสร้างเส้นทางระหว่างกันเครือข่าย IP ส่วนตัวขนาดใหญ่มาก ใช้ BGP ภายใน ตัวอย่างการใช้งาน คือการเชื่อมต่อเครือข่าย Open Shortest Path First (OSPF) ขนาดใหญ่หลาย เครือข่ายเข้า ด้วยกัน เมื่อ OSPF เพียงอย่างเดียวไม่สามารถรองรับขนาดที่ต้องการได้ อีกเหตุผลหนึ่งในการใช้ BGP คือการเชื่อมต่อเครือข่ายแบบหลายเส้นทาง (multihoming) เพื่อเพิ่มความซ้ำซ้อนที่ดีขึ้น ไม่ว่าจะเป็นการเชื่อมต่อจุดเชื่อมต่อหลายจุดไปยัง ISP เดียว หรือไปยัง ISP หลายแห่ง

เราเตอร์ โดยเฉพาะเราเตอร์ขนาดเล็กที่ออกแบบมาสำหรับ ใช้ใน สำนักงานขนาดเล็ก/สำนักงานที่บ้าน (SOHO) อาจไม่มีความสามารถในการใช้งาน BGP เราเตอร์เชิงพาณิชย์อื่นๆ อาจต้องการไฟล์ซอฟต์แวร์ที่รองรับ BGP หรือใบอนุญาตที่อนุญาตให้ใช้งาน อุปกรณ์ที่วางจำหน่ายในฐานะสวิตช์เลเยอร์ 3มีโอกาสน้อยที่จะรองรับ BGP เมื่อเทียบกับอุปกรณ์ที่วางจำหน่ายในฐานะเราเตอร์แต่สวิตช์เลเยอร์ 3 ระดับสูงหลายรุ่นสามารถใช้งาน BGP ได้

ผลิตภัณฑ์ที่วางจำหน่ายในชื่อสวิตช์อาจมีข้อจำกัดด้านขนาดของตาราง BGP ที่เล็กกว่าตารางอินเทอร์เน็ตเต็มรูปแบบรวมถึงเส้นทางภายในมาก อุปกรณ์เหล่านี้อาจเหมาะสมและมีประโยชน์อย่างยิ่งเมื่อใช้สำหรับการกำหนดเส้นทาง BGP ในส่วนเล็ก ๆ ของเครือข่าย เช่นASของกลุ่มองค์กรขนาดเล็กหลายแห่งที่เชื่อมโยงกันด้วยโครงข่าย BGP หรือองค์กรขนาดเล็กที่ประกาศเส้นทางไปยัง ISP แต่ยอมรับเฉพาะเส้นทางเริ่มต้นและอาจมีเส้นทางรวมจำนวนเล็กน้อยเท่านั้น

เราเตอร์ BGP ที่ใช้สำหรับเครือข่ายที่มีจุดเข้าถึงอินเทอร์เน็ตเพียงจุดเดียว อาจมีขนาดตารางเส้นทาง (และด้วยเหตุนี้จึงต้องการ RAM และ CPU น้อยกว่า) เครือข่ายที่มีหลายจุดเข้าถึงอินเทอร์เน็ต แม้แต่การเชื่อมต่อหลายจุดแบบง่ายๆ ก็อาจมีขนาดตารางเส้นทางที่ไม่ใหญ่มากนัก ปริมาณหน่วยความจำที่จำเป็นจริงในเราเตอร์ BGP ขึ้นอยู่กับปริมาณข้อมูล BGP ที่แลกเปลี่ยนกับอุปกรณ์ BGP อื่นๆ และวิธีที่เรารเตอร์นั้นๆ จัดเก็บข้อมูล BGP เราเตอร์อาจต้องเก็บสำเนาเส้นทางมากกว่าหนึ่งชุด เพื่อให้สามารถจัดการนโยบายที่แตกต่างกันสำหรับการโฆษณาและการยอมรับเส้นทางไปยัง AS ข้างเคียงที่เฉพาะเจาะจง คำว่า "มุมมอง"มักใช้สำหรับความสัมพันธ์ของนโยบายที่แตกต่างกันเหล่านี้บนเราเตอร์ที่กำลังทำงานอยู่

หากการใช้งานเราเตอร์แบบหนึ่งใช้หน่วยความจำต่อเส้นทางมากกว่าการใช้งานแบบอื่น นี่อาจเป็นทางเลือกการออกแบบที่ถูกต้อง โดยแลกเปลี่ยนความเร็วในการประมวลผลกับหน่วยความจำ ตาราง BGP IPv4 เต็มรูปแบบ ณ เดือนกันยายน 2025 มีพรีฟิกซ์มากกว่าหนึ่งล้านรายการ^{[ 63 ] [ 49 ]} ISP ขนาดใหญ่อาจเพิ่มอีก 50% สำหรับเส้นทางภายในและเส้นทางของลูกค้า ทั้งนี้ ขึ้นอยู่กับการใช้งาน อาจมีการเก็บตารางแยกต่างหากสำหรับแต่ละมุมมองของ AS คู่ค้าที่แตกต่างกัน

ตัวอย่างการใช้งาน BGP แบบโอเพนซอร์สและฟรีที่น่าสนใจ ได้แก่:

• BIRDคือ แพ็กเกจการกำหนดเส้นทาง (routing package) ที่ได้รับอนุญาต ภายใต้ GPLสำหรับระบบปฏิบัติการที่คล้าย Unix
• FRRoutingซึ่งเป็นเวอร์ชันดัดแปลงของ Quagga สำหรับ ระบบปฏิบัติการ ที่คล้าย Unixและเวอร์ชันก่อนหน้าของมัน:
  • Quaggaเป็นโปรแกรมที่แตกแขนงมาจาก GNU Zebra สำหรับ ระบบปฏิบัติการ ที่คล้าย Unix (ปัจจุบันไม่มีการพัฒนาต่อแล้ว)
  • GNU Zebraชุดการกำหนดเส้นทาง GPL ที่รองรับ BGP4 (เลิกใช้งานแล้ว) ^{[ 64 ]}
• OpenBGPDคือระบบปฏิบัติการที่พัฒนาโดยทีมOpenBSD ภายใต้ลิценส์ BSD
• XORPหรือ eXtensible Open Router Platform คือชุดโปรโตคอลการกำหนดเส้นทางที่ได้รับอนุญาตภายใต้ระบบ BSD

ระบบสำหรับการทดสอบความสอดคล้องของ BGP ประสิทธิภาพการรับโหลดหรือความเครียด มาจากผู้จำหน่ายต่างๆ เช่น:

• บริษัท อากิเลนท์ เทคโนโลยีส์
• GNS3 เป็นโปรแกรมจำลองเครือข่ายโอเพนซอร์ส
• อิกเซีย
• สไปเรนท์

• เหตุการณ์ระบบล่มของ Facebook ในปี 2021  – เหตุการณ์ที่ส่งผลกระทบต่อบริการทั้งหมดที่ดำเนินการโดย Facebook
• เหตุการณ์ AS 7007  – การหยุดชะงักครั้งใหญ่ของอินเทอร์เน็ตเมื่อวันที่ 25 เมษายน 1997
• โปรโตคอลการตรวจสอบ BGP  – โปรโตคอลเครือข่ายคอมพิวเตอร์
• โซนที่ไม่ต้องกำหนดค่าเริ่มต้น  – โซนเครือข่ายที่ไม่จำเป็นต้องมีกฎการกำหนดเส้นทางเริ่มต้น
• องค์การกำหนดหมายเลขอินเทอร์เน็ต (IP Authority)  – องค์กรมาตรฐานที่กำกับดูแลที่อยู่ IP
• การส่งต่อแพ็กเก็ต  – การส่งต่อแพ็กเก็ตจากส่วนหนึ่งของเครือข่ายไปยังอีกส่วนหนึ่ง
• IP ส่วนตัว  – การใช้งาน VPN ที่เป็นกรรมสิทธิ์
• QPPB  – กลไกวิศวกรรมจราจร
• หน่วยงานที่รับผิดชอบด้านการกำหนดหมายเลขเครือข่ายอินเทอร์เน็ตระดับภูมิภาค  – องค์กรที่มีหน้าที่จัดการหมายเลขเครือข่าย
• โครงสร้างพื้นฐานกุญแจสาธารณะสำหรับทรัพยากร  – กรอบความปลอดภัยการกำหนดเส้นทางอินเทอร์เน็ต
• การกรองเส้นทาง  – กระบวนการยกเว้นเส้นทางเครือข่ายบางเส้นทาง
• ฐานข้อมูลการกำหนดเส้นทาง  – ทะเบียนการกำหนดเส้นทางสำหรับเครือข่ายอินเทอร์เน็ต
• ลำดับเหตุการณ์ในประวัติศาสตร์ของอินเทอร์เน็ต  – ลำดับเหตุการณ์ตามลำดับ เวลา

• RFC  1772 – " การประยุกต์ใช้โปรโตคอล Border Gateway ในอินเทอร์เน็ต " ^{[ 65 ]}ร่างมาตรฐาน
• RFC  1997 – " แอตทริบิวต์ชุมชน BGP " ^{[ 21 ]}มาตรฐานที่เสนอ
• RFC  2439 – " การลดการสั่นสะเทือนของเส้นทาง BGP " ^{[ 43 ]}มาตรฐานที่เสนอ
• RFC  2918 – " ความสามารถในการรีเฟรชเส้นทางสำหรับ BGP-4 " ^{[ 35 ]}มาตรฐานที่เสนอ
• RFC  3765 – " ชุมชน NOPEER สำหรับการควบคุมขอบเขตเส้นทางโปรโตคอลเกตเวย์ชายแดน (BGP) " ^{[ 66 ]}ข้อมูล
• RFC  4271 – " โปรโตคอลเกตเวย์ชายแดน 4 (BGP-4) " ^{[ 11 ]}ร่างมาตรฐาน
• RFC  4272 – " การวิเคราะห์ช่องโหว่ด้านความปลอดภัยของ BGP " ^{[ 67 ]}ข้อมูล
• RFC  4273 – " คำจำกัดความของวัตถุที่จัดการสำหรับ BGP-4 " ^{[ 68 ]}มาตรฐานที่เสนอ
• RFC  4274 – " การวิเคราะห์โปรโตคอล BGP-4, " ^{[ 15 ]}ข้อมูล
• RFC  4275 – " การสำรวจการใช้งาน BGP-4 MIB " ^{[ 69 ]}ข้อมูล
• RFC  4276 – " รายงานการใช้งาน BGP-4 " ^{[ 70 ]}ข้อมูล
• RFC  4277 – " ประสบการณ์กับโปรโตคอล BGP-4 " ^{[ 71 ]}ข้อมูล
• RFC  4278 – " ความแปรปรวนของความสมบูรณ์ของมาตรฐานเกี่ยวกับตัวเลือกลายเซ็น TCP MD5 (RFC 2385) และข้อกำหนด BGP-4 " ^{[ 72 ]}ข้อมูล
• RFC  4360 – " แอตทริบิวต์ชุมชนขยาย BGP " ^{[ 26 ]}มาตรฐานที่เสนอ
• RFC  4456 – " การสะท้อนเส้นทาง BGP: ทางเลือกอื่นแทน BGP ภายในแบบ Full Mesh (IBGP) " ^{[ 39 ]}ร่างมาตรฐาน
• RFC  4724 – " กลไกการเริ่มต้นใหม่อย่างราบรื่นสำหรับ BGP " ^{[ 73 ]}มาตรฐานที่เสนอ
• RFC  4760 – " ส่วนขยายมัลติโปรโตคอลสำหรับ BGP-4 " ^{[ 14 ]}มาตรฐานที่เสนอ
• RFC  5065 – " สมาพันธ์ระบบอิสระสำหรับ BGP " ^{[ 40 ]}ร่างมาตรฐาน
• RFC  5492 – " การโฆษณาความสามารถด้วย BGP-4 " ^{[ 33 ]}ร่างมาตรฐาน
• RFC  5701 – " แอตทริบิวต์ชุมชนขยาย BGP เฉพาะที่อยู่ IPv6 " ^{[ 74 ]}มาตรฐานที่เสนอ
• RFC  6793 – " การสนับสนุน BGP สำหรับพื้นที่หมายเลขระบบอิสระ (AS) สี่อ็อกเท็ต " ^{[ 61 ]}มาตรฐานที่เสนอ
• RFC  7153 – " ทะเบียน IANA สำหรับชุมชน BGP Extended " ^{[ 29 ]}มาตรฐานที่เสนอ
• RFC  7313 – " ความสามารถในการรีเฟรชเส้นทางขั้นสูงสำหรับ BGP-4 " ^{[ 36 ]}มาตรฐานที่เสนอ
• RFC  7606 – " การจัดการข้อผิดพลาดที่แก้ไขสำหรับข้อความ BGP UPDATE " ^{[ 34 ]}มาตรฐานที่เสนอ
• RFC  7911 – " การโฆษณาเส้นทางหลายเส้นทางใน BGP " ^{[ 75 ]}มาตรฐานที่เสนอ
• RFC  8092 – " คุณลักษณะชุมชนขนาดใหญ่ของ BGP " ^{[ 30 ]}มาตรฐานที่เสนอ
• RFC  8195 – " การใช้ชุมชนขนาดใหญ่ของ BGP " ^{[ 31 ]}ข้อมูล
• RFC  8642 – " พฤติกรรมนโยบายสำหรับชุมชน BGP ที่รู้จักกันดี " ^{[ 76 ]}มาตรฐานที่เสนอ
• RFC  8955 – " การเผยแพร่กฎข้อกำหนดการไหล " ^{[ 77 ]}มาตรฐานที่เสนอ
• RFC  9552 – " การกระจายข้อมูลสถานะลิงก์และวิศวกรรมการจราจรโดยใช้ BGP " ^{[ 78 ]}มาตรฐานที่เสนอ

• "โปรโตคอลเกตเวย์ชายแดน (BGP)"คู่มือเทคโนโลยี IOS บริษัทซิ สโก้ ซิสเต็มส์เก็บถาวรจากต้นฉบับเมื่อ 2011-07-08
• ฟาน ไบนัม, อิลจิตช์ (2002) บีจีพี . บริษัท โอ'ไรลีย์ มีเดีย อิงค์ISBN 978-0-596-00254-1สืบค้นข้อมูลเมื่อ31 ธันวาคม 2025

• แหล่งข้อมูลการกำหนดเส้นทาง BGP (รวมถึงส่วนเฉพาะเกี่ยวกับBGP และความปลอดภัยหลักของ ISP )
• สถิติตาราง BGP