၁ · BGP အလုပ်လုပ်ပုံ¶

BGP သည် TCP port 179 ပေါ်တွင် run သည်။ ထိုအချက်တစ်ခုတည်းကပင် အကြောင်းအရာများစွာကို ရှင်းပြပေးနေသည် — Sessions များကို manual အတိအလင်း configure လုပ်ပေးရမည် (အလိုအလျောက် discovery မရှိပါ)၊ ဒေတာပေးပို့မှုသည် စိတ်ချရသောကြောင့် BGP သည် packet များကို retransmit ပြန်လုပ်စရာမလိုပါ၊ TCP ပြတ်တောက်သွားပါက session ပါ သေဆုံးသွားသည်။

State Machine အဆင့်ဆင့် လည်ပတ်ပုံ¶

BGP session တစ်ခုသည် သတ်မှတ်ထားသော states ၆ ခုကို ဖြတ်သန်းရသည်။ မည်သည့်နေရာတွင် ရပ်တန့်နေသည်ကို သိရှိပါက အကြောင်းရင်းကို ချက်ချင်း သိရှိနိုင်သည်။

graph LR
    I["Idle"] --> C["Connect"] --> A["Active"] --> OS["OpenSent"] --> OC["OpenConfirm"] --> E["Established"]
    classDef s fill:#1565c0,stroke:#90caf9,color:#ffffff,stroke-width:2px,font-size:14px;
    classDef g fill:#2e7d32,stroke:#a5d6a7,color:#ffffff,stroke-width:2px,font-size:14px;
    class I,C,A,OS,OC s; class E g;

State	အဓိပ္ပာယ်	ဤနေရာတွင် ရပ်တန့်နေပါက →
Idle	စတင်မကြိုးပမ်းသေးပါ၊ သို့မဟုတ် failure ပြီးနောက် ခေတ္တရပ်နားနေသည်	Peer ဆီသို့ route မရှိခြင်း သို့မဟုတ် peer ကို configure မလုပ်ရသေးခြင်း
Connect	TCP handshake လုပ်ဆောင်နေဆဲ	ခေတ္တခဏသာ ဖြစ်သည်; မြင်တွေ့ရခဲသည်
Active	TCP တည်ဆောက်မှု မအောင်မြင်သဖြင့် ပြန်လည်ကြိုးစားနေသည်	အဖြစ်အများဆုံး ချို့ယွင်းချက် — Peer ဆီသို့ မရောက်ရှိနိုင်ခြင်း၊ filter ပိတ်ခံရခြင်း သို့မဟုတ် IP မှားယွင်းခြင်း
OpenSent	Open packet ပေးပို့ပြီး တစ်ဖက်ထံမှ Open ကို စောင့်ဆိုင်းနေသည်	AS number မကိုက်ညီခြင်း သို့မဟုတ် router-ID တိုက်ဆိုင်နေခြင်း
OpenConfirm	Open packet လက်ခံရရှိပြီး Keepalive ကို စောင့်ဆိုင်းနေသည်	ဖြစ်ခဲသည်; ပုံမှန်အားဖြင့် authentication မကိုက်ညီခြင်း
Established	ပုံမှန်အလုပ်လုပ်နေပြီ — Updates များ စတင်ဖလှယ်နိုင်ပြီ	✅

'Active' သည် BGP တွင် အလွဲမှားဆုံး နားလည်တတ်သည့် စကားလုံးဖြစ်သည်

အသံထွက်အရ ပုံမှန်ကောင်းမွန်စွာ လည်ပတ်နေသည်ဟု ထင်ရသော်လည်း အမှန်စင်စစ် ဆန့်ကျင်ဘက် ဖြစ်ပါသည် — TCP တည်ဆောက်၍ မရနိုင်သဖြင့် BGP က ထပ်ခါတလဲလဲ ပြန်လည်ကြိုးပမ်းနေခြင်း ဖြစ်သည်။ Idle နှင့် Active အကြား အပြန်အလှန် လူးလှိမ့်နေသော session သည် လုံးဝ up မဖြစ်သေးသော session ဖြစ်သည်။

Lab 01 တွင် ဤအခြေအနေ ဖြစ်ပွားရခြင်း၏ အဓိကအကြောင်းရင်းမှာ iBGP peer ၏ loopback address သည် OSPF ထဲတွင် ထည့်သွင်းရန် ကျန်ခဲ့သောကြောင့် ဖြစ်သည် — Route မရှိသော IP address တစ်ခုဆီသို့ BGP အနေဖြင့် TCP session ဖွင့်လှစ်၍ မရနိုင်ပေ။

Live fabric ပေါ်မှ ဖမ်းယူထားသော အထောက်အထား -

  BGP state is Established, up for 00:29:18

BGP မက်ဆေ့ဂျ် အမျိုးအစား ၄ မျိုး¶

မက်ဆေ့ဂျ် (Message)	ရည်ရွယ်ချက် (Purpose)
Open	ညှိနှိုင်းခြင်း- AS number၊ router ID၊ hold time နှင့် capabilities များ
Update	အဓိကအလုပ်ကို လုပ်ဆောင်ခြင်း — Prefixes များကို advertise လုပ်ခြင်း သို့မဟုတ် withdraw ဖျက်သိမ်းခြင်း
Keepalive	ပြောစရာ အသစ်မရှိသည့်အခါ "ဆက်လက်အသက်ရှင်နေဆဲ" ဖြစ်ကြောင်း အသိပေးခြင်း
Notification	တစ်စုံတစ်ခု မှားယွင်းသွားပြီဖြစ်ကြောင်း အကြောင်းကြားခြင်း; Session သည် ချက်ချင်း ပိတ်သိမ်းသွားသည်

မှတ်သားထားသင့်သည့် အကျိုးဆက် ၂ ခု -

Notification သည် Session ကို အမြဲတမ်း ချက်ချင်း ဖြတ်တောက်စေသည်။ BGP တွင် warning (သတိပေးချက်) သဘောတရား မရှိပါ — Protocol error တစ်ခုခု ဖြစ်ပေါ်ပါက session ချက်ချင်း ရပ်စဲသွားပြီး error code က အကြောင်းရင်းကို ရှင်းပြပေးသည်။

Capabilities များကို Open မက်ဆေ့ဂျ်တွင် ညှိနှိုင်းကြသည်။ Protocol တစ်ခုတည်းက IPv4၊ IPv6၊ VPNv4 နှင့် EVPN များကို သယ်ဆောင်နိုင်ရခြင်းမှာ ဤနည်းလမ်းကြောင့်ဖြစ်သည် — စတင်ချိန်တွင် peers အချင်းချင်း capability တစ်ခုစီကို သဘောတူညီကြခြင်း ဖြစ်သည်။ ထို့ကြောင့် address family အသစ်တစ်ခု ထည့်သွင်းလိုက်သည့်အခါ capability အပြောင်းအလဲကြောင့် session ခေတ္တ restart ကျသွားတတ်ခြင်း ဖြစ်သည်။

Timers များ¶

Lab fabric မှ ဖမ်းယူထားသော timers အချက်အလက်များ -

  Hold time is 180, keepalive interval is 60 seconds
  Effective minimum hold time is 3 seconds
  Hold timer is active, time left: 00:02:17

Keepalive 60၊ Hold 180 — Default တန်ဖိုးများဖြစ်ပြီး စံအင်တာဗျူး မေးခွန်းတစ်ခု ဖြစ်သည်။ Hold time သည် ပုံမှန်အားဖြင့် keepalive ၏ ၃ ဆ ဖြစ်သည်။

Open message တွင် ညှိနှိုင်းပြီးနောက် Peers နှစ်ခုအနက် နည်းသော hold time တန်ဖိုးက အနိုင်ရသည်။ Hold time ကို 0 သတ်မှတ်ခြင်းမှာ "ဘယ်တော့မှ timeout မဖြစ်စေရ" ဟု အဓိပ္ပာယ်ရပြီး သတ်မှတ်ခွင့်ရှိသော်လည်း မသုံးသင့်ပေ။

Timers များကို အလွန်အကျွံ လျှော့ချ၍ အမြန် converge ဖြစ်အောင် မလုပ်ပါနှင့်

3/9 စက္ကန့်အထိ လျှော့ချခြင်းသည် ပြတ်တောက်မှုကို ပိုမိုမြန်ဆန်စွာ သိရှိနိုင်သော်လည်း CPU ဝန်ပိချိန် သို့မဟုတ် ယာယီ ကွန်ရက်ကြပ်တည်းချိန်များတွင် sessions များကို မလိုအပ်ဘဲ ပြုတ်ကျသွားစေနိုင်သည် — BGP session တစ်ခု bounce ဖြစ် (ပြုတ်ကျ/ပြန်တက်) သွားခြင်းသည် စက္ကန့်အနည်းငယ် ကြန့်ကြာခြင်းထက် ကွန်ရက်အတွက် များစွာ ပိုမိုဆိုးရွားသော ထိခိုက်မှုကို ဖြစ်စေသည်။

ယင်းအစား BFD ကို အသုံးပြုပါ- သီးသန့် ပေါ့ပါးသော protocol က မီလီစက္ကန့်ပိုင်းအတွင်း ပြတ်တောက်မှုကို စစ်ဆေးတွေ့ရှိပြီး BGP အား neighbour ကို ဖြတ်တောက်ရန် အကြောင်းကြားပေးသည်။ BGP ကိုယ်တိုင်ကို နုနယ်မသွားစေဘဲ တူညီသော ရလဒ်ကောင်းကို ရရှိစေသည်။ Policy နှင့် filtering တွင် ဆက်လက်လေ့လာပါ။

eBGP နှင့် iBGP: Protocol တစ်ခုတည်း၊ စည်းမျဉ်းမတူညီခြင်း¶

eBGP သည် ယုံကြည်စိတ်ချရမှု မရှိသော အဖွဲ့အစည်းနယ်နိမိတ် (trust boundary) ကို ဖြတ်သန်းရပြီး iBGP မှာမူ မိမိအဖွဲ့အစည်းအတွင်း၌သာ ဖြစ်သောကြောင့် စည်းမျဉ်းများ ကွဲပြားခြင်း ဖြစ်သည်။

	eBGP	iBGP
Peers တည်ရှိရာ	မတူညီသော ASes များ	တူညီသော AS တစ်ခုတည်း
Peer address	Physical interface	Loopback
Default TTL	1	ပုံမှန် (Normal/255)
AS path	မိမိ AS ကို ရှေ့ဆုံးမှ ထပ်ပေါင်းထည့်သည် (prepends)	မပြောင်းလဲပါ (Unchanged)
Next hop	မိမိကိုယ်ကို အဖြစ် ပြောင်းလဲသတ်မှတ်သည် (sets to self)	မပြောင်းလဲပါ (Unchanged)
Local preference	ပေးပို့ခြင်း မရှိပါ	Peers အချင်းချင်း ပေးပို့သည်
iBGP routes များကို မည်သူ့ထံ ပြန်လည် ကြေညာခွင့်ရှိသနည်း	မည်သူ့ထံမဆို	အခြား iBGP peer ထံ ဘယ်တော့မှ ထပ်မံ မကြေညာရ
Administrative distance	အစဉ်အလာအရ 20 (Arista တွင် 200)	200

Next hop စည်းမျဉ်းသည် ပထမဆုံးအကြိမ် lab တည်ဆောက်သူများ အဖြစ်အများဆုံး ပြဿနာဖြစ်သည် — ၎င်းသည် Lab 01 ၏ အဓိက အကြောင်းအရာ ဖြစ်သည်။ Re-advertise စည်းမျဉ်းကြောင့်ပင် iBGP တွင် full mesh လိုအပ်ရခြင်းဖြစ်ပြီး ၎င်းကို Scaling တွင် ရှင်းပြထားပါသည်။

eBGP တွင် Default TTL 1 အဘယ်ကြောင့် ဖြစ်ရသနည်း

Peers များသည် တိုက်ရိုက် ကြိုးချင်း ချိတ်ဆက်ထားသည်ဟု ယူဆထားသောကြောင့် TTL လျော့ကျသွားသော packet တစ်ခု ရောက်ရှိလာပါက ၎င်းသည် သင်၏ အိမ်နီးချင်းအစစ်အမှန်ထံမှ လာခြင်းမဟုတ်ဟု သတ်မှတ်သည်။ ၎င်းသည် ရိုးရှင်းထိရောက်သော anti-spoofing ကာကွယ်မှုတစ်ခု ဖြစ်သည်။

ထို့ကြောင့် hop များစွာ ခြားထားသော Loopback address သို့ eBGP peer ဖွဲ့လိုပါက ebgp-multihop လိုအပ်ပါသည် — ပိုမိုလုံခြုံစိတ်ချရသော နည်းလမ်းဖြစ်သည့် GTSM အကြောင်းကို Policy တွင် ဖော်ပြထားပါသည်။

BGP သည် အဘယ်ကြောင့် ရည်ရွယ်ချက်ရှိရှိ နှေးကွေးနေရသနည်း¶

OSPF သည် စက္ကန့်ပိုင်းအတွင်း converge ဖြစ်သည်။ BGP သည် ရည်ရွယ်ချက်ရှိရှိ ပိုမိုအချိန်ယူသည် -

Flooding မရှိခြင်း။ Router တစ်ခုစီသည် policy ကို စစ်ဆေးသုံးသပ်ပြီးမှ မည်သည့်အရာကို ဆက်လက်လက်ဆင့်ကမ်းမည်ကို ဆုံးဖြတ်သည်။
Batched updates (စုစည်း၍ ပေးပို့ခြင်း)။ MRAI (Minimum Route Advertisement Interval) — Default အားဖြင့် eBGP peer ထံ prefix တစ်ခုတည်းအတွက် update တစ်ခုနှင့်တစ်ခုကြား စက္ကန့် ၃၀ ခြားထားခြင်းဖြင့် flapping ဖြစ်နေသော prefix ကမ္ဘာအနှံ့ ပျံ့နှံ့သွားခြင်းကို ဟန့်တားပေးသည်။
Update တိုင်းတွင် Inbound နှင့် Outbound policy ကို စစ်ဆေးတွက်ချက်ခြင်း။

အချင်းချင်း မယုံကြည်ရသော ကွန်ရက်များအကြား လမ်းကြောင်းပေါင်း သန်းချီကို မျှဝေနေရသော စနစ်တစ်ခုအတွက် တည်ငြိမ်မှုမရှိ တလှုပ်လှုပ်ဖြစ်နေခြင်း (churn) ကို ထိန်းချုပ်ခြင်းသည် လျင်မြန်စွာ converge ဖြစ်ခြင်းထက် များစွာ ပိုမိုအရေးကြီးပါသည်။ တည်ငြိမ်မှု (Stability) သည် BGP ၏ အဓိက စွမ်းဆောင်ရည် ဖြစ်သည်။

ဖြစ်ပွားတတ်သော ချို့ယွင်းချက်များ (What breaks)¶

ရောဂါလက္ခဏာ (Symptom)	ဖြစ်နိုင်ခြေ အကြောင်းရင်း (Likely cause)
`Idle` တွင် ရပ်တန့်နေခြင်း	Peer ဆီသို့ route မရှိခြင်း သို့မဟုတ် peer ကို configure မလုပ်ရသေးခြင်း
`Active` တွင် ရပ်တန့်နေခြင်း သို့မဟုတ် ခုန်ပေါက်နေခြင်း	TCP/179 ပိတ်ဆို့ခံရခြင်း၊ peer address မှားယွင်းခြင်း သို့မဟုတ် ACL ပိတ်နေခြင်း
`OpenSent` တွင် ရပ်တန့်နေခြင်း	AS number မကိုက်ညီခြင်း သို့မဟုတ် router ID တူညီနေခြင်း
`Established` ဖြစ်သော်လည်း prefixes မရှိခြင်း	Address family ကို activate မလုပ်ရသေးခြင်း သို့မဟုတ် policy က အရာအားလုံးကို filter လုပ်ပစ်ခြင်း
Prefixes ရရှိသော်လည်း routing table တွင် အသုံးမပြုနိုင်ခြင်း	Next hop ဆီသို့ မရောက်ရှိနိုင်ခြင်း — Lab 01 ကို ကြည့်ပါ
Session သည် အချိန်မှန် ပြုတ်ကျနေခြင်း	MTU မကိုက်ညီခြင်း၊ keepalives များ drop ဖြစ်ခြင်း သို့မဟုတ် timers များ အရမ်းတင်းကျပ်လွန်းခြင်း

show ip bgp summary                    # peer တိုင်း၏ လက်ရှိ အခြေအနေ
show ip bgp neighbors <ip>             # timers၊ capabilities၊ counters များ
show ip bgp neighbors <ip> received-routes   # Inbound policy မတိုင်မီ လက်ခံရရှိသော routes များ
show ip bgp neighbors <ip> advertised-routes # Outbound policy အပြီး ကြေညာထားသော routes များ

အထက်ပါ နောက်ဆုံး command နှစ်ခုသည် လူအများ မေ့လျော့တတ်သော commands များ ဖြစ်ကြသည်။ received-routes နှင့် routing table ထဲရှိ routes များကို နှိုင်းယှဉ်ခြင်းဖြင့် မိမိကိုယ်ပိုင် inbound filter ကြောင့် ပြဿနာဖြစ်နေသလားဆိုသည်ကို ချက်ချင်း သိရှိနိုင်သည် — လက်တွေ့တွင် ထိုအမှားကြောင့် ဖြစ်လေ့ရှိသည်။

နောက်တစ်ခု: Path attributes များ →