NetPrime Training

13/10/2026

VXLAN & BGP EVPN EP.6 มาต่อแล้วครับ 😃

Thanaris Field Note | VXLAN & BGP EVPN EP.6
VXLAN = Data Plane แล้ว BGP EVPN = Control Plane ยังไง?
-----
จาก EP.5 เราลองเอา BGP EVPN ออกจาก VXLAN Fabric กันไปแล้ว
แล้วพบว่า... VXLAN สามารถทำงานแบบ Flood-and-Learn ได้
ถ้า VTEP ยังไม่รู้ว่า Remote MAC อยู่ที่ไหน ก็ต้องอาศัย Flood / Replicate Traffic
แล้วค่อยเรียนรู้ Remote Endpoint จาก Data Plane Traffic ที่เกิดขึ้นจริง
หรือถ้าจะจำแบบที่เราทิ้งไว้ท้าย EP.5 ก็คือ
"Flood-and-Learn = Traffic มาก่อน แล้วค่อย Learn Remote Endpoint ทีหลัง"
แต่ก่อนจบ EP.5 ผมมีทิ้งคำถามไว้ว่า...
จะเป็นยังไง ถ้า VTEP ไม่จำเป็นต้องรอ Remote Traffic ก่อน?
แต่หลังจาก Leaf ตัวหนึ่งเรียนรู้ Endpoint ของตัวเองแล้ว
มันสามารถบอก Leaf ตัวอื่นได้เลยว่า...
"MAC นี้อยู่หลังผมนะ"
วันนี้เราจะเอา BGP EVPN กลับเข้ามาในภาพครับ 😄
-----
ลองกลับมาที่ Topology เดิมของเรา
Host-A อยู่หลัง Leaf-1
Host-B อยู่หลัง Leaf-2
ทั้งสองฝั่งอยู่ใน Overlay Service เดียวกัน
สมมติว่าเป็น VNI 10010
และ Underlay มี IP Reachability ระหว่าง VTEP เรียบร้อยแล้ว
สมมติว่า
Leaf-1 VTEP = 10.255.1.1
Leaf-2 VTEP = 10.255.2.1
ถ้า Host-A ต้องการส่ง Ethernet Frame ไปหา Host-B
Leaf-1 จะรู้ได้ยังไงว่า... "MAC ของ Host-B อยู่หลัง VTEP ตัวไหน?"
ลองดูสิ่งที่เรามีอยู่ก่อน
- VXLAN Header มี VNI ซึ่งเอาไว้ระบุว่า Traffic นี้อยู่ใน Overlay Service ไหน
- Outer IP Header มี Destination IP ซึ่งเอาไว้ส่ง VXLAN Packet ไปยัง Remote VTEP
- ส่วน Underlay Routing ก็ช่วยพา Packet ไปยัง VTEP ปลายทาง
แต่ทั้งหมดนี้มันก็ยังไม่ได้ตอบคำถามว่า...
"MAC ของ Host-B อยู่ที่ไหน?" ถูกไหมครับ
VNI ไม่ใช่ MAC Directory
และ Routing Table ของ Underlay ก็ไม่ได้เก็บ Location ของ Host MAC
ตรงนี้แหละครับที่ Control Plane จะเริ่มเข้ามามีบทบาท
-----
ก่อนอื่นต้องแยกสองเรื่องนี้ออกจากกันให้ชัดก่อน
VXLAN = Data Plane
หน้าที่หลักคือ Encapsulate Ethernet Frame ให้กลายเป็น VXLAN Packet
แล้วส่ง Traffic ผ่าน IP Fabric ไปยัง Remote VTEP
เมื่อถึงปลายทางก็ Decapsulate แล้วนำ Original Ethernet Frame ไป Forward ต่อ
ส่วน...
BGP EVPN = Control Plane
หน้าที่คือแลกเปลี่ยน Reachability Information ระหว่างอุปกรณ์ที่เข้าร่วม EVPN Service
หรือถ้าพูดแบบสั้น ๆ ก็คือ
- VXLAN ทำหน้าที่ใน Data Plane สำหรับ Encapsulation / Decapsulation Traffic
- ส่วน EVPN ช่วยให้ VTEP เรียนรู้ว่า Endpoint นั้น Reachable ผ่าน VTEP ไหน
แต่สองอย่างนี้ไม่ได้ทำหน้าที่แทนกันนะครับ
-----
ลองมาดู Flow การทำงานกัน เริ่มจาก Host-B ที่อยู่หลัง Leaf-2
เมื่อ Host-B ส่ง Ethernet Frame เข้ามา
Leaf-2 จะเรียนรู้ Source MAC ของ Host-B จาก Local Data Plane ตามปกติ
สมมติว่า MAC ของ Host-B คือ "MAC-B"
Leaf-2 ก็เรียนรู้ว่า "MAC-B อยู่ฝั่ง Local ของผมนะ"
ถึงตรงนี้ยังเหมือน Ethernet Switching ที่เราคุ้นกัน ถูกไหมครับ
แต่สิ่งที่เพิ่มเข้ามาเมื่อมี BGP EVPN ก็คือ...
หลังจาก Leaf-2 เรียนรู้ Local Endpoint แล้ว
Leaf-2 สามารถ Advertise Endpoint Reachability ออกไปผ่าน BGP EVPN Control Plane
หรือพูดสั้น ๆ ได้ประมาณว่า... "ถ้าจะไปหา MAC-B ให้มาทางผมนะ"
ข้อมูล Endpoint แบบนี้ ใน EVPN จะเกี่ยวข้องกับ Route Type 2 หรือ MAC/IP Advertisement Route
ซึ่งสามารถ Advertise MAC Address และถ้ามี IP Binding ที่ใช้งานได้ ก็สามารถมี IP Address ไปด้วยได้
แต่ Route Type 2 เอาไว้ค่อยลงลึกอีกที ใน EP ถัด ๆ ไปละกันครับ
ตอนนี้เอาแค่ภาพใหญ่ให้เข้าใจก่อน 😄
ถัดมา เมื่อ Leaf-1 ได้รับและ Import EVPN Route ที่เกี่ยวข้องกับ Service ของมัน
Leaf-1 ก็สามารถเรียนรู้ได้ว่า MAC-B จะไป Remote VTEP 10.255.2.1
ตรงนี้คือจุดต่างสำคัญจาก EP.5
คราวนี้ Leaf-1 ไม่ต้องรอให้ VXLAN Traffic จากฝั่ง Leaf-2 วิ่งมาก่อนแล้วค่อยเรียนรู้ MAC-B จาก Remote Data Plane
แต่ Remote MAC Reachability สามารถถูกแจกมาทาง BGP EVPN Control Plane ได้
ดังนั้น...
Local Endpoint Learning ยังเกิดจาก Local Data Plane ตามปกติ
เราไม่ได้ยกเลิก MAC Learning
แต่สิ่งที่เปลี่ยนไปก็คือ... "Remote VTEP ได้ข้อมูล Endpoint Location มายังไง?"
จากเดิมที่ต้องพึ่ง Remote Data-plane Flood-and-Learn
แต่ตอนนี้มันสามารถเรียนรู้ผ่าน Control Plane ได้
แล้วตอน Packet วิ่งจริงล่ะ จะเป็นยังไง?
-----
สมมติ Host-A รู้ Destination MAC ของ Host-B แล้ว
1. Host-A ส่ง Ethernet Frame เข้ามาที่ Leaf-1 โดย Destination MAC = MAC-B
.
2. Leaf-1 Lookup Forwarding State แล้วพบว่า MAC-B Reachable ผ่าน VTEP 10.255.2.1
.
3. Leaf-1 ทำ VXLAN Encapsulation โดยใส่ VNI 10010 เพื่อระบุ Overlay Service และใช้ Outer Destination IP = 10.255.2.1
.
4. จากนั้น VXLAN Packet ถูกส่งเข้า Underlay ซึ่งทำการ Lookup Route → เลือก Path → แล้ว Forward Packet ไปหา 10.255.2.1
.
5. เมื่อ Leaf-2 ได้รับ Packet ก็ Decapsulate VXLAN Header ออก แล้วนำ Original Ethernet Frame ไป Forward ต่อหา Host-B
.
จบครับ 😄
.
-----
แต่มีจุดหนึ่งที่อยากให้ทุกคนสังเกตให้ดี...
ตอนที่ User Traffic วิ่งจริง ๆ
BGP EVPN ไม่ได้เป็นตัวที่ใช้ขน Ethernet Frame
ตัวที่ทำ Encapsulation / Decapsulation Traffic ยังคงเป็น VXLAN
และตัวที่พา Outer IP Packet เดินทางผ่าน Fabric ก็คือ Underlay Routing
ถ้าสรุปแบบสั้น ๆ ก็คือ
- EVPN บอกว่า Endpoint Reachable ผ่าน VTEP ไหน
- VXLAN ทำ Encapsulation / Decapsulation
- Underlay พา VXLAN Packet ไปถึง Remote VTEP
.
จะเห็นว่าทั้งสามอย่างทำงานร่วมกัน แต่ทำหน้าที่คนละเรื่อง
.
-----
ทีนี้ก็มีอีกคำถามให้คิดตามกันต่อว่า...
BGP EVPN แจกข้อมูลแค่ Endpoint MAC อย่างเดียวหรือเปล่า?
คำตอบคือ... ไม่ใช่ครับ 😄
ลองนึกย้อนกลับไป EP.5
ตอนที่เราพูดถึง BUM Traffic ก็จะมีอีกคำถามหนึ่งว่า
"ใน VNI 10010 มี VTEP ไหนเข้าร่วม Service นี้อยู่บ้าง?"
ซึ่ง EVPN ก็มีข้อมูลอีกชนิดหนึ่ง ที่ใช้บอก Layer 2 Service Membership ได้เหมือนกัน
ข้อมูลตรงนี้จะเกี่ยวข้องกับ EVPN Route Type 3 หรือ IMET
เดี๋ยวเรื่อง EVPN Route Type เราจะไว้คุยกันใน EP ถัด ๆ ไปอีกทีนะครับไม่ต้องซีเรียส 555
ตอนนี้แค่รู้ไว้ก่อนว่า EVPN มี Route Type หลายแบบ
และแต่ละแบบตอบคำถามคนละเรื่อง
เช่น...
Route Type 2 ช่วยตอบประมาณว่า "Endpoint นี้คือใคร และ Reachable ผ่าน VTEP ไหน?"
ส่วน Route Type 3 ช่วยตอบประมาณว่า "ใครบ้างที่ Participate อยู่ใน Layer 2 Service นี้?"
ส่วนรายละเอียดว่า Membership นี้ ถูกนำไปใช้กับ BUM Handling ยังไง
เดี๋ยวไปว่ากันต่อใน EP.7 ครับ 😄
-----
โอเคครับ พออ่านมาถึงตรงนี้ อาจจะเริ่มคิดว่า...
"งั้นพอมี BGP EVPN แล้ว ก็ไม่มี Flooding เลยหรือเปล่า?"
ยังไม่ใช่ครับ 555
BGP EVPN ช่วยลดการพึ่งพา Remote Data-plane Flood-and-Learn
แต่ไม่ได้หมายความว่า BUM Traffic จะหายไปทั้งหมด
Broadcast
Unknown Unicast
Multicast
ยังต้องมี Forwarding Behavior ตาม Design ของ Fabric อยู่
ดังนั้น...
การใช้ BGP EVPN ไม่ได้แปลว่าไม่มี Flood เลย
แต่มันเพิ่ม Control Plane สำหรับแลกเปลี่ยน Reachability และ Service Information
ทำให้ Fabric ไม่จำเป็นต้องพึ่ง Remote Data-plane Learning เพียงอย่างเดียว
แล้วอีกเรื่องที่สำคัญมาก คือ...
ต่อให้มี EVPN Route แล้ว ก็ไม่ได้แปลว่า Data Traffic จะส่งผ่านได้แน่นอน
สมมติ Leaf-1 รู้แล้วว่า MAC-B → VTEP 10.255.2.1
แต่ถ้า Underlay Route ไปหา 10.255.2.1 ไม่ได้ VXLAN Packet ก็ไปไม่ถึงอยู่ดี 😅
เพราะฉะนั้นเวลา Troubleshoot ลองแยกคิดเป็นชั้น ๆ ออกมา
Underlay
→ Reach Remote VTEP ได้ไหม?
EVPN Control Plane
→ เรียน Reachability ที่ถูกต้องหรือยัง?
Forwarding State
→ ข้อมูลถูก Install พร้อมใช้งานหรือยัง?
Data Plane
→ VXLAN Packet วิ่งจริงไหม?
เพราะแต่ละชั้นสัมพันธ์กัน แต่ไม่ใช่สิ่งเดียวกันนะครับ
ดังนั้นเราจะเห็นว่า...
การเข้าใจ Control Plane กับ Data Plane มันสำคัญกว่าการจำแค่ว่า
Feature นี้ต้องเปิด Command อะไรบ้าง
โอเคครับ ทิ้งคำถามกันไว้ให้คิดต่อก่อนจบ EP.6
ถ้า Endpoint Reachability เป็นเรื่องหนึ่ง แล้ว VTEP จะรู้ได้ยังไงว่า...
"ใครบ้างเข้าร่วม VNI 10010?"
Route Type 3 หรือ IMET เข้ามาเกี่ยวข้องตรงไหน?
แล้วข้อมูล Membership นี้ ถูกนำไปใช้กับ BUM Traffic ยังไง?
เดี๋ยว EP.7 เรามาต่อเรื่องนี้กันครับ 😄

12/10/2026

🏗️ Route Reflector คืออะไร? ทำไม Network ใหญ่ถึงต้องใช้?

ถ้าใน Network มี Router หลายสิบตัวที่ต้องใช้ iBGP เราจำเป็นต้องสร้าง BGP Neighbor เชื่อมต่อกันทุกตัวเลยไหม?

ถ้าใช้วิธี Full Mesh ก็ต้องสร้าง iBGP Session ให้ Router ทุกคู่เชื่อมต่อถึงกัน

ลองดูตัวเลขนี้

Router 5 ตัว = 10 Sessions

Router 10 ตัว = 45 Sessions

Router 20 ตัว = 190 Sessions

ยิ่งมี Router มากขึ้น จำนวน Session ที่ต้องดูแลก็ยิ่งเพิ่มขึ้น ทั้ง Configuration และการจัดการ Peer ในระยะยาว

แล้วทำไม iBGP ถึงต้องทำ Full Mesh?

เพราะตามหลักการของ iBGP Router จะไม่ส่ง Route ที่เรียนรู้จาก iBGP Peer หนึ่งต่อไปยัง iBGP Peer อื่นโดยตรงตามปกติ

หากไม่มีวิธีจัดการเพิ่มเติม Router ทุกตัวจึงต้องมี Session เชื่อมถึงกันแบบ Full Mesh เพื่อให้ Routing Information กระจายไปถึงกันได้

ตรงนี้เองที่ Route Reflector เข้ามาช่วย

Route Reflector (RR) คือ Router ที่ทำหน้าที่สะท้อน BGP Route ระหว่าง iBGP Peer ตามกฎของ Route Reflection ช่วยลดความจำเป็นในการทำ Full Mesh ระหว่าง Router ทุกตัว

แล้วมันทำงานยังไง?

สมมติว่ามี Router 4 ตัว โดยให้ R4 ทำหน้าที่เป็น Route Reflector

R1 ──┐
R2 ──┼── R4 (Route Reflector)
R3 ──┘

R1, R2 และ R3 ทำหน้าที่เป็น RR Client โดยสร้าง iBGP Session กับ R4

เมื่อ R1 ส่ง Route ให้ R4 ผ่าน iBGP แล้ว R4 สามารถสะท้อน Route นั้นไปยัง Client ตัวอื่นได้ โดยไม่จำเป็นต้องสร้าง iBGP Session ระหว่าง Client ทุกคู่

แล้ว RR สะท้อน Route ตามกฎอะไร?

สำหรับ Route ที่ RR เรียนรู้ผ่าน iBGP จะมีกฎพื้นฐานดังนี้

ถ้า RR ได้รับ Route จาก Client
RR สามารถสะท้อน Route ไปยัง Client อื่นที่ไม่ใช่ต้นทาง และ Non-client Peer ได้

ถ้า RR ได้รับ Route จาก Non-client iBGP Peer
RR จะสะท้อน Route ไปยัง Client Peer

โดยทั่วไป RR จะเลือก Best Path และสะท้อน Route ตามกฎของ Route Reflection รวมถึง Routing Policy ที่กำหนดไว้ ไม่ได้ส่งทุก Route หรือทุก Path ให้ทุก Peer โดยอัตโนมัติ

แล้ว Route Reflector ช่วยอะไรบ้าง?

ช่วยลดจำนวน iBGP Sessions ที่ต้องสร้างระหว่าง Router

ช่วยให้การออกแบบและบริหาร BGP Network ขนาดใหญ่ทำได้ง่ายขึ้น

ช่วยให้ขยาย Network ได้สะดวก โดยไม่ต้องเพิ่ม Full Mesh ทุกครั้งที่มี Router ใหม่

แต่ยังมีเรื่องที่ต้องระวัง

Route Reflector ไม่ได้ทำให้ Network เลือกเส้นทางได้ดีที่สุดเสมอไป เพราะการเลือก Best Path ของ RR อาจมีผลต่อเส้นทางที่ Client มองเห็น จึงต้องวางแผน Topology และ Routing Policy ให้เหมาะสม

นอกจากนี้ Route Reflection ยังใช้ Attribute สำคัญอย่าง ORIGINATOR_ID และ CLUSTER_LIST เพื่อช่วยตรวจจับและป้องกัน Routing Information Loop

สำหรับ Network ขนาดใหญ่ มักพิจารณาใช้ Route Reflector มากกว่าหนึ่งตัวเพื่อเพิ่ม Redundancy ลดการพึ่งพาอุปกรณ์ตัวเดียว และควรออกแบบการเชื่อมต่อระหว่าง RR ให้เหมาะสมด้วย

สรุปง่าย ๆ

iBGP Full Mesh = ทุก Router ต้องมี Session เชื่อมถึงกันครบทุกคู่

Route Reflector = ใช้ Router ที่ทำหน้าที่สะท้อน Route ช่วยลดความจำเป็นในการทำ Full Mesh

นี่จึงเป็นหนึ่งในแนวทางสำคัญในการออกแบบ BGP สำหรับองค์กรและ Service Provider ที่มี Network ขนาดใหญ่

📚 Cisco BGP Classroom | 2 วัน

อยากเข้าใจ BGP มากกว่าแค่การตั้ง Neighbor?

เรียนรู้ตั้งแต่ BGP Fundamentals, iBGP/eBGP, Path Selection, Route Policy, Route Filtering ไปจนถึง BGP Optimization และ Troubleshooting พร้อม Hands-on Lab บน Cisco

📅 17–18 ตุลาคม 2569
🕘 09.00–17.30 น.
🏫 Classroom | NetPrime Training
💰 7,900 บาท / ท่าน

รายละเอียดหลักสูตรและลงทะเบียน
https://www.netprimetraining.com/course/cisco-bgp-classroom-oct-2026

สอบถามเพิ่มเติม
📞 062-559-4622
💬 LINE:
📘 NetPrime Training
🌐 www.netprimetraining.com

09/10/2026

💬 ลองวิเคราะห์: BGP Established แล้ว แต่ Ping ไม่ผ่าน คุณคิดว่าเกิดจากอะไร?

ลองนึกภาพว่าคุณกำลังดูแล Network อยู่

BGP Neighbor ขึ้นเป็น Established แล้ว แต่พอลอง Ping จากเครื่องต้นทางไปยัง Server ปลายทาง กลับไม่ผ่าน

ถ้าเป็นคุณ จะเริ่มตรวจสอบจากจุดไหนก่อน?

A. ตรวจสอบ Routing Table ว่ามี Route ไปยังปลายทาง และ NEXT_HOP สามารถ Resolve ได้หรือไม่

B. ตรวจสอบว่าฝั่งปลายทางมี Route สำหรับส่ง Traffic กลับมายังต้นทางหรือไม่

C. ตรวจสอบ ACL หรือ Firewall ว่ามีการ Block ICMP หรือเปล่า

D. ตรวจสอบ Interface, Layer 2 Connectivity และเส้นทางการ Forward Traffic

E. ตรวจสอบว่า Prefix ปลายทางถูกประกาศและรับเข้ามาหรือไม่ รวมถึงมี Route Policy กรองไว้หรือเปล่า

ลองเลือกมา 1 ข้อ ว่าคุณจะเริ่มเช็กจากจุดไหนก่อน แล้วบอกเหตุผลด้วยว่าทำไมถึงเลือกข้อนั้น

เพราะ BGP Neighbor เป็น Established ไม่ได้หมายความว่า Traffic จะไปถึงปลายทางได้เสมอ

เวลา Troubleshoot จริง เราต้องแยกให้ออกว่าปัญหาอยู่ที่ Route ขาไป, NEXT_HOP, Route ขากลับ, Policy หรือการ Forward Traffic

แล้วคุณล่ะ? เจอแบบนี้จะเริ่มเช็กจากจุดไหนก่อน?

Cisco BGP Classroom | 2 วัน

เรียนรู้ตั้งแต่ BGP Fundamentals, Neighbor, iBGP/eBGP, Path Selection, Route Policy, Route Filtering, BGP Optimization ไปจนถึง Troubleshooting พร้อม Hands-on Lab บน Cisco

วันที่ 17–18 ตุลาคม 2569
เวลา 09.00–17.30 น.
สถานที่ Classroom | NetPrime Training
ราคา 7,900 บาท / ท่าน

รายละเอียดหลักสูตรและลงทะเบียน
https://www.netprimetraining.com/course/cisco-bgp-classroom-oct-2026

สอบถามเพิ่มเติม
โทร. 062-559-4622
LINE:
Facebook: NetPrime Training
เว็บไซต์: www.netprimetraining.com

07/10/2026

🎯 BGP Next-Hop คืออะไร?
ทำไมมี Route แล้ว Traffic ยังไปไม่ได้?

เคยเจอไหมครับ?

BGP Neighbor ขึ้นเป็น Established แล้ว
ใน BGP Table ก็เห็น Route อยู่
แต่ Route กลับไม่ถูกติดตั้งใน Routing Table

หนึ่งในจุดที่ควรตรวจสอบคือ NEXT_HOP

ลองดูตัวอย่างนี้

10.10.10.0/24
NEXT_HOP = 192.168.12.1

BGP กำลังบอกว่า
ถ้าจะไป 10.10.10.0/24
ให้ใช้ 192.168.12.1 เป็น Next-Hop

แต่มีอีกเรื่องที่ต้องเช็กต่อ

Router สามารถไปหา 192.168.12.1 ได้หรือไม่?

เพราะ Router ต้องสามารถ Resolve NEXT_HOP ผ่าน Routing Table ได้ก่อน
จึงจะนำ BGP Route นี้ไปพิจารณาใช้งานต่อ

พูดง่าย ๆ คือ

Route = ปลายทางอยู่ไหน
NEXT_HOP = ควรส่งต่อไปหาใคร

ถ้า NEXT_HOP ไม่สามารถ Resolve ได้
Route นั้นก็จะไม่ผ่านเงื่อนไข Route Resolvability
และจะไม่ถูกนำไปใช้ในกระบวนการเลือก Route เพื่อติดตั้งใน Loc-RIB

ดังนั้นอาจเจออาการแบบนี้ได้

BGP Neighbor = Established
BGP Table = มี Route
แต่ Route = ไม่ถูกติดตั้งใน Routing Table

และนี่คือเหตุผลว่า

มี Route ใน BGP Table
ไม่ได้แปลว่า Route นั้นพร้อมใช้งานเสมอ

แล้วทำไมเรื่องนี้ถึงเจอบ่อยใน iBGP?

ลองดู Scenario นี้

R1 → eBGP → R2 → iBGP → R3

สมมติ R1 ประกาศ

10.10.10.0/24

โดยมี NEXT_HOP เป็น

192.168.1.1

เมื่อ R2 ส่ง Route นี้ต่อไปให้ R3 ผ่าน iBGP
โดยทั่วไป NEXT_HOP ของ Route ที่ไม่ได้ Originated locally จะยังคงเป็นค่าเดิม

ดังนั้น R3 อาจเห็น

10.10.10.0/24
NEXT_HOP = 192.168.1.1

ถ้า R3 มี Route ไปหา 192.168.1.1
ก็สามารถ Resolve NEXT_HOP ได้

แต่ถ้าไม่มี
Route นี้ก็จะไม่ผ่าน Route Resolvability

แล้ววิธีที่ใช้กันบ่อยในกรณีนี้คือ

neighbor x.x.x.x next-hop-self

คำสั่งนี้ทำให้ Router ใช้ IP ของตัวเองเป็น NEXT_HOP
เมื่อส่ง Route ไปยัง Neighbor

เช่น

R2 → R3

จากเดิม

NEXT_HOP = 192.168.1.1

เมื่อใช้ next-hop-self

NEXT_HOP = IP ของ R2

จากนั้น R3 ก็สามารถใช้ Routing Table
เพื่อ Resolve NEXT_HOP ไปยัง R2 ได้

แต่ต้องจำไว้ว่า

NEXT_HOP Reachable ไม่ได้หมายความว่า Route จะถูกติดตั้งทันที

Route ยังต้องผ่านการเลือก Best Path
และเงื่อนไขอื่นของ BGP รวมถึง Routing Policy ด้วย

เวลาเจออาการ
“มี Route แต่ Route ไม่ถูกใช้งาน”

อย่าดูแค่ Prefix

ลองไล่ดูว่า

NEXT_HOP คืออะไร?
NEXT_HOP Reachable หรือไม่?
Routing Table มี Route ที่ใช้ Resolve NEXT_HOP หรือไม่?
Route นี้เป็น Best Path หรือไม่?
มี Policy หรือเงื่อนไขอื่นที่ทำให้ Route ไม่ถูกเลือกหรือไม่?
Route ถูกติดตั้งลง Routing Table แล้วหรือยัง?

บน Cisco สามารถเริ่มตรวจสอบได้ด้วย

show ip bgp

ตัวอย่าง

show ip bgp 10.10.10.0

เพื่อดูรายละเอียดของ BGP Path และ NEXT_HOP

จากนั้นตรวจสอบเส้นทางไปยัง Next-Hop ด้วย

show ip route

ตัวอย่าง

show ip route 192.168.12.1

เพื่อดูว่า Router มีเส้นทางที่ใช้ Resolve NEXT_HOP หรือไม่

ถ้า NEXT_HOP ไม่สามารถเข้าถึงได้
ในบางกรณี Cisco อาจแสดงสถานะ inaccessible

ลองจำเป็นภาพง่าย ๆ

BGP Route
↓
ดู NEXT_HOP
↓
ตรวจสอบ Route Resolvability
↓
พิจารณา Best Path / Policy
↓
ติดตั้ง Route ใน Routing Table
↓
Forward Traffic

สรุปง่าย ๆ

มี Route
ไม่ได้แปลว่าใช้งานได้เสมอ

ต้องดูด้วยว่า

NEXT_HOP ไปถึงหรือไม่
Route ถูกเลือกเป็น Best Path หรือไม่
และ Route ถูกติดตั้งใน Routing Table แล้วหรือยัง

เพราะเวลา Troubleshoot BGP จริง
เราไม่ได้ต้องการแค่เห็นว่า Route มีอยู่

แต่ต้องรู้ว่า
Router สามารถนำ Route นั้นไปใช้งานจริงได้หรือยัง

📚 Cisco BGP Classroom | 2 วัน

เรียนตั้งแต่ BGP Fundamentals, Neighbor, iBGP/eBGP, Path Selection, NEXT_HOP, Route Policy, Route Filtering และ BGP Optimization ไปจนถึง Troubleshooting

พร้อม Hands-on Lab บน Cisco
เน้นให้เข้าใจทั้ง Concept และการนำไปใช้กับ Network จริง

📅 17–18 ตุลาคม 2569
🕘 09.00–17.30 น.
🏫 Classroom | NetPrime Training
💰 7,900 บาท / ท่าน

รายละเอียดหลักสูตรและลงทะเบียน
https://www.netprimetraining.com/course/cisco-bgp-classroom-oct-2026

📞 062-559-4622
💬 LINE:
📘 NetPrime Training
🌐 www.netprimetraining.com

06/10/2026

VXLAN & BGP EVPN EP.5 มาแล้วววว
VXLAN without EVPN ถ้ายังไม่มี Control Plane แล้ว VTEP จะรู้ได้ยังไงว่า MAC อยู่หลัง VTEP ไหน?

Thanaris Field Note | VXLAN & BGP EVPN EP.5
VXLAN without EVPN ถ้ายังไม่มี Control Plane แล้ว VTEP จะรู้ได้ยังไงว่า MAC อยู่หลัง VTEP ไหน?
-----
จาก EP.4 เราคุยกันเรื่อง VLAN กับ VNI ไปแล้ว
และท้าย EP ผมทิ้งคำถามเอาไว้ว่า...
ถ้า Host-A อยู่หลัง Leaf-1 และ Host-B อยู่หลัง Leaf-2
และทั้งสองฝั่งอยู่ใน Overlay Service เดียวกัน เช่น VNI 10010
คำถามคือ... "Leaf-1 จะรู้ได้ยังไงว่า MAC Address ของ Host-B อยู่หลัง VTEP ไหน?"
ถ้ามี BGP EVPN อยู่แล้ว หลายคนอาจจะพอเดาคำตอบได้
แต่เดี๋ยวเราเอา EVPN ออกไปก่อนครับ 555
เหลือแค่ VXLAN Data Plane ล้วน ๆ แล้วลองดูกันว่า...
มันจะหา Remote Endpoint กันยังไง?
-----
มาลองดูการทำงานปกติที่ Switch ทำกันมาตลอดก่อน
เวลา Switch ได้รับ Ethernet Frame เข้ามา มันสามารถเรียนรู้ Source MAC Address จาก Port ที่ Frame วิ่งเข้ามา
อันนี้เป็นเรื่องปกติของ Ethernet Switching เลยถูกไหมครับ
พอ Host-A ส่ง Frame เข้ามา Leaf-1 ก็เรียนรู้ได้ว่า
"MAC ของ Host-A อยู่ฝั่ง Local ของผมนะ"
ตรงนี้ยังดูไม่มีอะไรซับซ้อนครับ
แต่... ปัญหาจะเริ่มตอนที่ Host-A ต้องการคุยกับ Host-B ซึ่งอยู่หลัง Leaf-2
แต่ก่อนจะส่ง Frame หา Host-B ได้

Host-A ต้องรู้ MAC ของ Host-B ก่อน
Host-A จึงส่ง ARP Request ออกมาว่า
"ใครมี IP นี้ ช่วยบอก MAC หน่อย"
ARP Request เป็น Broadcast
Leaf-1 รับมาแล้ว คำถามคือ... "Broadcast นี้ต้องส่งไปหา Leaf ตัวไหนบ้าง?" 😅
ใน Ethernet แบบที่เราคุ้นกัน
ถ้าเป็น Broadcast หรือ Switch ไม่รู้ว่า Destination MAC อยู่ Port ไหน
สิ่งที่มันทำก็คือ Flood ออกทุกพอร์ต (ยกเว้นพอร์ตที่รับเข้ามา) ใช่ไหมครับ
ซึ่ง VXLAN แบบ Flood-and-Learn ก็ใช้แนวคิดคล้ายกันครับ
เพียงแต่ Layer 2 Service ของเราไม่ได้อยู่แค่ใน Switch ตัวเดียว มันถูก Extend ข้าม VXLAN Fabric
ดังนั้น Traffic แบบนี้ต้องถูก Flood / Replicate ภายใน VNI นั้น
ไปยัง Remote VTEP ที่เกี่ยวข้องกับ Service นั้น ถูกไหมครับ ?
แล้ว Leaf-1 รู้ได้ยังไงว่าใน VNI 10010 มี VTEP ไหนเข้าร่วมอยู่บ้าง?
ถ้ายังไม่มี EVPN หรือ Control Plane อื่นมาช่วยบอก Membership
เราก็ต้องมีวิธีทำให้ VTEP รู้ว่า Remote VTEP ไหนอยู่ใน Service นี้
ใน Flood-and-Learn แบบคลาสสิก
ถ้าใช้ Ingress Replication
เราอาจต้อง Config รายชื่อ Remote VTEP / Flood List ไว้ล่วงหน้า
หรืออีกแบบนึงก็คือ Map VNI เข้ากับ Multicast Group
แล้วให้ Underlay Multicast ช่วยกระจาย BUM Traffic
หรือจะพูดง่าย ๆ คือ...
แม้แต่ "ใครอยู่ในวงเดียวกันบ้าง" เราก็ยังต้องมีวิธีกำหนดให้ระบบรู้
ถ้าใช้ Static Flood List แล้วมี Leaf ใหม่เข้ามา ก็ต้องมีการอัปเดต Membership / Flood List ให้ถูกต้อง
Fabric เล็ก ๆ ก็ยังพอไหว ถ้า Fabric ใหญ่ ๆ นี่เริ่มไม่ไหวแล้ว 555
-----
ลองกลับมาที่ตัวอย่างของเรา
Leaf-1 Replicate ARP Request ออกไปใน VNI 10010
เมื่อ Traffic ไปถึง Leaf-2
Leaf-2 Decapsulate VXLAN Packet ออกมา
แล้ว Forward Frame เข้า Local Layer 2 Service ของมัน
Host-B ได้รับ ARP Request
แต่มีอีกอย่างนึงที่เกิดขึ้นระหว่างทาง คือ...
Leaf-2 เห็นว่า Source MAC ของ Frame นี้คือ MAC ของ Host-A และมาจาก VTEP ของ Leaf-1
Leaf-2 จึงเรียนรู้ได้ว่า "ถ้าจะไปหา MAC ของ Host-A ให้ส่งไปทาง VTEP ของ Leaf-1"
นี่คือ Remote MAC Learning ที่เกิดจาก Data Plane Traffic
พอ Host-B ส่ง ARP Reply กลับมาหา Host-A
คราวนี้ Leaf-2 รู้แล้วว่า Host-A อยู่ไหน จึงส่งแบบ Known Unicast ไปที่ Leaf-1 ได้เลย
และ Leaf-1 ก็ได้เรียนรู้ในทางกลับกันว่า "MAC ของ Host-B อยู่หลัง VTEP ของ Leaf-2"
หลังจากนี้ Traffic รอบต่อ ๆ ไป ก็สามารถ Forward แบบ Known Unicast ไปยัง Remote VTEP ที่ถูกต้องได้
นี่แหละครับคือการทำงานของ "Flood-and-Learn"
ยังไม่รู้ก็ Flood ไปก่อน แล้วค่อย Learn จาก Traffic ที่เกิดขึ้นจริง
มันคือการส่ง Data Traffic ไปก่อนแล้วนั่นแหละ
แล้วพอส่ง Data Traffic ไป จังหวะนั้นถึงค่อย Learning MAC 😄
-----
แล้ว Unknown Unicast เกิดตอนไหน?
เกิดเมื่อมี Ethernet Frame เข้ามา แต่ Leaf Lookup แล้วไม่พบ Destination MAC ใน MAC Table
Frame นั้นก็จะกลายเป็น Unknown Unicast
และต้องถูก Flood / Replicate ภายใน VNI ตามกลไกที่เราออกแบบไว้
ถึงตรงนี้คงพอเห็นภาพแล้วว่า BUM Traffic ที่เราได้ยินกันบ่อย ๆ คืออะไร
BUM ย่อมาจาก
B = Broadcast
U = Unknown Unicast
M = Multicast
ตัวอย่างเช่น
Broadcast = ARP Request
Unknown Unicast = มี Destination MAC อยู่ใน Frame แต่ Leaf ยังไม่รู้ว่า MAC นั้นอยู่ที่ไหน
Multicast = Traffic ที่ส่งไปยัง Multicast Group
Traffic กลุ่มนี้มีสิ่งนึงที่คล้ายกัน นั่นคือ..
มันไม่สามารถ Forward แบบ Known Unicast ไปยัง Remote Destination เดียวได้
จึงต้องมีกลไกในการส่ง Traffic ไปยัง Remote VTEP ที่เกี่ยวข้องกับ VNI นั้น
ซึ่งก็คือสิ่งที่เราเพิ่งพูดถึงไปนั่นเอง "Ingress Replication" หรือ "Underlay Multicast"
รายละเอียดสองแบบนี้เดี๋ยวมี EP แยกเรื่อง BUM โดยเฉพาะอีกทีครับ 😄
-----
ถึงตรงนี้อาจจะรู้สึกว่า... "ก็ทำงานได้นี่นา แล้วมีปัญหาอะไร?" 555
ก็ถูกครับ... Flood-and-Learn ทำงานได้
และไม่ได้แปลว่ามันเป็นวิธีที่ผิด
แต่จะเริ่มเห็นปัญหาเมื่อ Fabric ใหญ่ขึ้น
1. เรื่องแรก... Replication
VNI หนึ่งอาจมี VTEP เข้าร่วมหลายตัว
เมื่อเกิด BUM Traffic Traffic ก็ต้องถูกส่งไปยัง Remote VTEP ที่เกี่ยวข้องกับ VNI นั้น
ยิ่ง Service ใหญ่ขึ้น ภาระในการจัดการ Replication ก็มีโอกาสเพิ่มขึ้นตามไปด้วย
2. เรื่องที่สอง... ต้องรอ Traffic ก่อนถึงจะรู้
VTEP ไม่มีใครมาบอกล่วงหน้าว่า
MAC A อยู่ตรงนี้
MAC B อยู่ตรงนั้น
ต้องรอ Traffic วิ่งมาก่อนครับ ถึงจะเรียนรู้ได้ 😅
Remote MAC Learning จึงเกิดจาก Data Plane Traffic
และ ARP Request ที่เป็น Broadcast ก็ยังต้องมีกลไก Flood / Replicate ไปยัง VTEP ที่เกี่ยวข้องใน VNI
หากยังไม่มีกลไกอย่าง ARP Suppression มาช่วยลดการ Flood
3. เรื่องที่สาม... Operational Visibility
ตอน Troubleshoot เราอยากรู้ว่า "MAC ของ Host-B จริง ๆ อยู่หลัง VTEP ไหน?"
ถ้าอาศัย Flood-and-Learn อย่างเดียว ข้อมูลที่เรามีคือสิ่งที่ Data Plane เคยเห็น
เราต้องไล่ดู MAC Table / VXLAN State เพื่อหาว่า Remote Endpoint ถูกเรียนรู้จากทางไหน
เพราะยังไม่มี Control Plane ที่ทำหน้าที่แจก Endpoint Reachability ให้ VTEP โดยตรง
พอ Network ใหญ่ขึ้น เรื่องพวกนี้ก็เริ่มสนุกขึ้นเรื่อยๆ (สนุกใครไม่รู้ 555)
-----
แล้ว... จะเป็นยังไงถ้า Leaf-1 เรียนรู้ Host-A จาก Local Data Plane ตามปกติ
แต่หลังจากเรียนรู้แล้ว มันสามารถ "บอก" VTEP ตัวอื่นได้เลยว่า "MAC นี้อยู่หลังผมนะ"
และ Control Plane ไม่ได้ช่วยแค่เรื่อง Endpoint Location เท่านั้น
มันยังสามารถใช้แลกเปลี่ยนข้อมูลว่า
"VTEP ไหนเข้าร่วม Layer 2 Service / VNI นี้อยู่บ้าง"
Remote VTEP จึงไม่ต้องพึ่ง Data-plane Learning อย่างเดียว
และไม่ต้องอาศัย Static Membership แบบเดิมทุกอย่าง
ตรงนี้แหละครับที่ BGP EVPN เริ่มเข้ามามีบทบาท
แต่มีจุดหนึ่งที่อยากฝากไว้ก่อน
BGP EVPN ไม่ได้หมายความว่า "ต่อไปนี้ VXLAN จะไม่มี Flood หรือ BUM Traffic อีกแล้ว" ไม่ใช่นะ 😄
สิ่งที่มันช่วยคือ... ลดการพึ่งพา Remote Data-plane Flood-and-Learn
และเพิ่ม Control Plane สำหรับแจก Reachability Information
-----
ดังนั้น "Flood-and-Learn = Traffic มาก่อน แล้วค่อย Learn Remote Endpoint"
ส่วน EVPN จะมาเปลี่ยนเกมตรงไหน?
VXLAN เป็น Data Plane แล้ว BGP EVPN เป็น Control Plane ยังไง?
แล้วจริง ๆ VXLAN กับ EVPN เป็นสิ่งเดียวกันหรือเปล่า?
เดี๋ยว EP.6 เรามาต่อกันครับ 😄

05/10/2026

🔄 BGP State Machine: จาก Idle ไปถึง Established เกิดอะไรขึ้นบ้าง?

เวลา BGP Router สองตัวจะสร้าง Neighbor
ไม่ได้หมายความว่า Config เสร็จแล้วจะขึ้น Established ทันที

BGP มี State Machine สำหรับควบคุมขั้นตอนการสร้าง BGP Session
ทั้งหมด 6 State

Idle
Connect
Active
OpenSent
OpenConfirm
Established

ลองมาดูกันว่าแต่ละ State กำลังเกิดอะไรขึ้น

1. Idle

เป็น State เริ่มต้นของ BGP

เมื่อ BGP เริ่มทำงาน Router จะเริ่มกระบวนการสร้าง Connection ไปยัง Peer

ในขั้นนี้ยังไม่มี BGP Session ที่พร้อมแลกเปลี่ยน Routing Information

จำง่าย ๆ

Idle = เริ่มต้นกระบวนการสร้าง BGP Session

2. Connect

Router กำลังรอให้ TCP Connection กับ Peer สำเร็จ

BGP ใช้ TCP Port 179

ถ้า TCP Connection สำเร็จ
BGP จะส่ง OPEN Message และเข้าสู่ OpenSent

แต่ถ้าการสร้าง TCP Connection ไม่สำเร็จ
BGP จะเข้าสู่ Active

จำง่าย ๆ

Connect = กำลังรอ TCP Connection

3. Active

จุดนี้หลายคนมักเข้าใจผิด

Active ไม่ได้หมายความว่า BGP ทำงานปกติแล้ว

ใน State นี้ BGP กำลังพยายาม acquire Peer
โดยรอรับ TCP Connection จาก Peer

ถ้า TCP Connection สำเร็จ
BGP จะส่ง OPEN และเข้าสู่ OpenSent

ถ้า ConnectRetryTimer หมดอายุ
BGP จะกลับไป Connect และพยายามสร้าง TCP Connection ใหม่

ดังนั้นถ้า Neighbor ค้างอยู่ที่ Active
ควรเริ่มตรวจสอบเรื่องที่เกี่ยวข้องกับการสร้าง TCP Connection เช่น

Routing / Reachability
TCP Port 179
Firewall / ACL
การเชื่อมต่อระหว่าง Peer

จำง่าย ๆ

Active = กำลังพยายามสร้าง Connection กับ Peer

4. OpenSent

TCP Connection สำเร็จแล้ว

Router จะส่ง OPEN Message และเข้าสู่ OpenSent
เพื่อรอ OPEN Message จากอีกฝั่ง

OPEN Message จะมีข้อมูลสำคัญ เช่น

BGP Version
AS Number
Hold Time
BGP Identifier
Optional Parameters

ถ้า OPEN จาก Peer ถูกต้องและยอมรับได้
BGP จะส่ง KEEPALIVE และเข้าสู่ OpenConfirm

จำง่าย ๆ

OpenSent = ส่ง OPEN และรอ OPEN จาก Peer

5. OpenConfirm

ตอนนี้ OPEN ผ่านแล้ว

Router กำลังรอ KEEPALIVE หรือ NOTIFICATION จาก Peer

ถ้าได้รับ KEEPALIVE
BGP จะเข้าสู่ Established

ถ้าได้รับ NOTIFICATION
Session จะถูกยุติตาม Error ที่เกิดขึ้น

จำง่าย ๆ

OpenConfirm = รอ KEEPALIVE หรือ NOTIFICATION

6. Established

มาถึง State ที่เราต้องการ

BGP Session ถูกสร้างขึ้นเรียบร้อยแล้ว
และสามารถแลกเปลี่ยน Routing Information กับ Peer ได้

ใน State นี้จะมีการแลกเปลี่ยน

UPDATE
KEEPALIVE
NOTIFICATION

UPDATE ใช้แลกเปลี่ยน Routing Information
KEEPALIVE ใช้รักษา Session
NOTIFICATION ใช้แจ้ง Error

แล้วลำดับปกติเป็นอย่างไร?

Idle
↓
Connect
↓
OpenSent
↓
OpenConfirm
↓
Established

แต่ Active ไม่ได้เป็นขั้นที่ต้องผ่านทุกครั้ง

ถ้า TCP Connection สำเร็จจาก Connect
BGP สามารถไป OpenSent ได้เลย

Active จะเข้ามาเกี่ยวข้องเมื่อการสร้าง TCP Connection ยังไม่สำเร็จ
และ BGP กำลังพยายามสร้างหรือรับ Connection กับ Peer

ถ้าดูเพื่อ Troubleshoot ให้จำแบบนี้

Idle
เริ่มต้นกระบวนการ

Connect
กำลังรอ TCP Connection

Active
กำลังพยายามเชื่อมต่อกับ Peer

OpenSent
ส่ง OPEN และรอ OPEN

OpenConfirm
รอ KEEPALIVE หรือ NOTIFICATION

Established
Session พร้อมแลกเปลี่ยน Routing Information

แล้ว State ช่วย Troubleshoot ยังไง?

ถ้า Neighbor อยู่ที่ Idle
ลองดูว่า BGP ถูก Start และ Configuration ของ Peer พร้อมหรือไม่

ถ้าอยู่ที่ Connect
ให้เริ่มมองเรื่อง TCP Connection และการเชื่อมต่อไปยัง Peer

ถ้าอยู่ที่ Active
ให้เน้นตรวจ Reachability, TCP Port 179 และ Firewall / ACL

ถ้าอยู่ที่ OpenSent
แปลว่า TCP Connection ขึ้นแล้ว แต่ยังอยู่ในขั้นตอนแลกเปลี่ยน OPEN

ถ้าอยู่ที่ OpenConfirm
แปลว่า OPEN ผ่านแล้ว และกำลังรอ KEEPALIVE หรือ NOTIFICATION

ถ้าเป็น Established แต่ไม่มี Route
ค่อยไปดู UPDATE, Routing Policy และ Route Filtering

สิ่งสำคัญคืออย่าดูแค่ว่า

“BGP Neighbor ขึ้นหรือยัง?”

ลองถามต่อว่า

“ตอนนี้ BGP อยู่ State ไหน?”

เพราะ State ที่เห็นช่วยบอกได้ว่า
Session กำลังติดอยู่ตรงขั้นตอนไหน

เมื่อรู้ว่าติดตรงไหน
เราก็จะไล่ Troubleshoot ได้เป็นระบบมากขึ้น

📚 Cisco BGP Classroom | 2 วัน

คอร์สนี้เน้นตั้งแต่ BGP Fundamentals, Neighbor, Path Selection, Route Policy, Route Filtering, BGP Optimization ไปจนถึง Troubleshooting และ Hands-on Lab

เน้นให้เข้าใจทั้ง Concept และการนำไปใช้กับ Network จริง

📅 17–18 ตุลาคม 2569
🕘 09.00–17.30 น.
🏫 Classroom | NetPrime Training
💰 7,900 บาท / ท่าน

รายละเอียดหลักสูตรและลงทะเบียน
https://www.netprimetraining.com/course/cisco-bgp-classroom-oct-2026

📞 062-559-4622
💬 LINE:
📘 NetPrime Training
🌐 www.netprimetraining.com

02/10/2026

🧩 BGP Neighbor ไม่ขึ้นแบบนี้…คุณคิดว่าเกิดจากอะไร?

ลองทดสอบกันหน่อย

สมมติว่าคุณ Config BGP เรียบร้อยแล้ว
แต่สถานะ Neighbor ยังไม่เป็น Established

ตอนนี้ตรวจสอบเบื้องต้นแล้วว่า

IP Address ถูกต้อง
AS Number ถูกต้อง
Interface ใช้งานได้

แต่ BGP ยังไม่ขึ้น

ถ้าเป็นคุณ จะเริ่มเช็กจากจุดไหนต่อ?

A. ตรวจสอบ TCP Port 179
B. ตรวจสอบ Routing / Reachability
C. ตรวจสอบ BGP State และ Log
D. ตรวจสอบ Config ของ Neighbor ทั้งสองฝั่งอีกครั้ง
E. ตรวจสอบหลายจุดร่วมกันตามลำดับการทำงานของ BGP

ลองเลือกคำตอบกันดูก่อน
แล้วบอกเหตุผลด้วยว่า ทำไมถึงเลือกข้อนั้น

เพราะเวลา Troubleshoot BGP จริง
เราไม่ได้ดูแค่ว่า Config ถูกหรือไม่

แต่ต้องไล่ดูว่า BGP Session ติดอยู่ตรงขั้นตอนไหน
และแต่ละขั้นตอนมีอะไรที่อาจทำให้ Session ไม่ขึ้น

ยิ่งเข้าใจลำดับการทำงานของ BGP
ก็ยิ่งไล่หาสาเหตุของปัญหาได้เป็นระบบมากขึ้น

แล้วคุณล่ะ?
ถ้าเจออาการแบบนี้ จะเริ่มเช็กตรงไหนก่อน?

🎓 Cisco BGP | Classroom

📅 17–18 ตุลาคม 2569
🕘 09.00–17.30 น.
📍 Classroom | NetPrime Training
💰 7,900 บาท / ท่าน

เรียน Routing & OSPF, BGP Fundamentals, iBGP/eBGP, Path Selection, Route Policy, Route Filtering, BGP Optimization รวมถึง Troubleshooting และ Hands-on Lab

📌 สอบถาม / สมัครอบรม

📞 062-559-4622
💬 LINE:
📘 NetPrime Training
🌐 www.netprimetraining.com

รายละเอียดหลักสูตร
https://www.netprimetraining.com/course/cisco-bgp-classroom-oct-2026

01/10/2026

📡 BGP Router คุยอะไรกันตอนสร้าง Session?

เคยสงสัยไหมว่า เวลาที่ BGP Router สองตัวเริ่มคุยกัน
จริง ๆ แล้ว Router ใช้ Message อะไรในการสื่อสาร?

หลายคนอาจจำได้ว่า BGP มี OPEN, KEEPALIVE, UPDATE และ NOTIFICATION
แต่ถ้าเข้าใจว่าแต่ละตัวทำหน้าที่อะไร และเกิดขึ้นตอนไหน
เวลา Troubleshoot BGP จะเข้าใจภาพรวมได้ง่ายขึ้นมาก

BGP-4 กำหนด Message หลักไว้ 4 ประเภท

1. OPEN

หลังจาก TCP Connection ถูกสร้างขึ้น
BGP Speaker แต่ละฝั่งจะส่ง OPEN Message เพื่อเริ่มต้น BGP Session

ภายใน OPEN Message จะมีข้อมูลสำคัญ เช่น

BGP Version
AS Number
Hold Time
BGP Identifier
Optional Parameters

เมื่อได้รับ OPEN และตรวจสอบแล้วว่าใช้ได้
Router จะส่ง KEEPALIVE เพื่อยืนยัน OPEN
จากนั้น BGP จะเข้าสู่ OpenConfirm State

ในช่วง OpenConfirm Router จะรอ KEEPALIVE จากอีกฝั่ง
เมื่อได้รับ KEEPALIVE ตามที่คาดไว้
จึงเปลี่ยนเข้าสู่ Established State

สรุปง่าย ๆ

OPEN = เริ่มต้นสร้าง BGP Session

2. KEEPALIVE

เมื่อ BGP Session ทำงานแล้ว
Router จะส่ง KEEPALIVE เป็นระยะ เพื่อช่วยรักษา Session

BGP ใช้ KEEPALIVE เพื่อไม่ให้ Hold Timer หมดอายุ
โดย Hold Timer จะถูกพิจารณาจากการได้รับ KEEPALIVE, UPDATE หรือ NOTIFICATION จาก Peer

ถ้า Router ไม่ได้รับ Message ที่เกี่ยวข้องภายในเวลาที่กำหนดตาม Hold Time
BGP จะถือว่า Hold Timer หมดอายุ
จากนั้นจะส่ง NOTIFICATION และปิด Connection

ดังนั้น KEEPALIVE ไม่ได้หมายถึงแค่ “เช็กว่าอีกฝั่งยังอยู่”
แต่เป็นส่วนหนึ่งของกลไกการรักษา BGP Session

สรุปง่าย ๆ

KEEPALIVE = รักษา BGP Session

3. UPDATE

UPDATE เป็น Message ที่เกี่ยวข้องกับ Routing Information โดยตรง

BGP ใช้ UPDATE เพื่อแลกเปลี่ยนข้อมูล Routing ระหว่าง Peer

UPDATE สามารถใช้สำหรับ

ประกาศ Route ใหม่
ถอน Route ที่ไม่ต้องการใช้งานแล้ว
ส่ง Path Attributes ที่เกี่ยวข้องกับ Route

ตัวอย่าง Path Attributes ที่พบได้บ่อย เช่น

AS_PATH
NEXT_HOP
LOCAL_PREF
MED

ข้อมูลเหล่านี้มีส่วนสำคัญในการประมวลผลและเลือกเส้นทางของ BGP

ดังนั้นเวลาศึกษาเรื่อง BGP Path Selection
ต้องเข้าใจทั้ง Route และ Path Attributes ที่ถูกส่งมากับ UPDATE ด้วย

สรุปง่าย ๆ

UPDATE = แลกเปลี่ยน Routing Information

4. NOTIFICATION

เมื่อ Router ตรวจพบ Error ที่ทำให้ BGP Session ไม่สามารถทำงานต่อได้
Router จะส่ง NOTIFICATION Message เพื่อแจ้ง Error ให้อีกฝั่งทราบ

ตัวอย่าง Error เช่น

Message Header Error
OPEN Message Error
UPDATE Message Error
Hold Timer Expired
Finite State Machine Error
Cease

หลังจากส่ง NOTIFICATION แล้ว
BGP Connection จะถูกปิด

สรุปง่าย ๆ

NOTIFICATION = แจ้ง Error และปิด BGP Connection

แล้ว 4 Message นี้ทำงานสัมพันธ์กันยังไง?

TCP Connection ถูกสร้างขึ้น
↓
OPEN ถูกส่งระหว่าง BGP Speaker
↓
KEEPALIVE ถูกส่งเพื่อยืนยัน OPEN
↓
OpenConfirm
↓
ได้รับ KEEPALIVE จาก Peer
↓
Established
↓
UPDATE และ KEEPALIVE ถูกแลกเปลี่ยนกัน

ถ้าเกิด Error ที่ทำให้ Session ไม่สามารถทำงานต่อได้
↓
NOTIFICATION
↓
ปิด BGP Connection

แล้ว ROUTE-REFRESH คืออะไร?

นอกจาก Message หลัก 4 ประเภทของ BGP-4 แล้ว
ยังมี ROUTE-REFRESH ซึ่งเป็น Message Type 5
ที่ถูกกำหนดเพิ่มเติมภายหลัง

ROUTE-REFRESH ใช้สำหรับขอให้ Peer ส่ง Routing Information ใหม่
โดยไม่จำเป็นต้อง Reset BGP Session

จึงมีประโยชน์ในสถานการณ์ที่ต้องการให้ Route ถูกส่งและประมวลผลใหม่
เช่น หลังจากมีการเปลี่ยน Routing Policy

ทั้งนี้การใช้ ROUTE-REFRESH ต้องอาศัยการรองรับและการประกาศ Route Refresh Capability ระหว่าง Peer

สรุปง่าย ๆ

ROUTE-REFRESH = ขอ Routing Information ใหม่โดยไม่ต้อง Reset Session

แล้วความรู้นี้ช่วยตอน Troubleshoot ยังไง?

เวลาเจอ BGP Neighbor มีปัญหา
อย่าเพิ่งดูแค่ว่า Session ขึ้นหรือไม่ขึ้น

ลองไล่ดูว่า

TCP Connection ขึ้นหรือยัง?
OPEN ผ่านหรือไม่?
Session ไปถึง OpenConfirm หรือเปล่า?
เข้าสู่ Established แล้วหรือยัง?
มี KEEPALIVE และ UPDATE แลกเปลี่ยนกันหรือไม่?
ถ้า Session หลุด มี NOTIFICATION หรือ Hold Timer Expired หรือเปล่า?

เพราะแต่ละจุดช่วยบอกได้ว่า
ปัญหาเกิดขึ้นในช่วงไหนของ BGP Session

ถ้า OPEN มีปัญหา
ก็ต้องกลับไปดูเรื่องการสร้าง Session และข้อมูลที่ใช้เจรจากัน

ถ้า Session หลุดเพราะ Hold Timer
ก็ต้องมองเรื่อง KEEPALIVE, UPDATE และการสื่อสารกับ Peer

ถ้า Session ขึ้นแล้วแต่ Route ไม่มา
ก็ต้องมอง UPDATE รวมถึง Routing Policy และ Route Filtering

นี่จึงเป็นเหตุผลว่าการทำ BGP จริง
ไม่ใช่แค่จำ Command ว่าใช้คำสั่งอะไร

แต่ต้องเข้าใจด้วยว่า
Router อยู่ใน State ไหน
กำลังส่ง Message อะไร
และ Message นั้นกำลังบอกอะไรเรา

📚 Cisco BGP Classroom | 2 วัน

เรียนตั้งแต่ BGP Fundamentals, Neighbor, Path Selection, Route Policy, Route Filtering ไปจนถึง Troubleshooting และ Hands-on Lab

เน้นให้เข้าใจทั้ง Concept และการนำไปใช้กับ Network จริง

📅 17–18 ตุลาคม 2569
🕘 09.00–17.30 น.
🏫 Classroom | NetPrime Training
💰 7,900 บาท / ท่าน

รายละเอียดหลักสูตรและลงทะเบียน
https://www.netprimetraining.com/course/cisco-bgp-classroom-oct-2026

📞 062-559-4622
💬 LINE:
📘 NetPrime Training
🌐 www.netprimetraining.com