အင်တာဗျူး မေးခွန်းများ — BGP¶
Routing ဆိုင်ရာ အင်တာဗျူးတစ်ခုတွင် BGP သည် အများအားဖြင့် မေးခွန်းအများဆုံးဖြစ်သော အဓိက ခေါင်းစဉ်တစ်ခု ဖြစ်သည်။ ဤမေးခွန်းဘဏ်သည် Phase တစ်ခုလုံးကို လွှမ်းခြုံထားပါသည်။
Sessions နှင့် State အဆင့်ဆင့်¶
BGP သည် မည်သည့် Transport protocol ကို အသုံးပြုသနည်း၊ ယင်းကြောင့် မည်သည့် အကျိုးဆက်များ ဖြစ်ပေါ်လာသနည်း။
TCP port 179 ကို အသုံးပြုသည်။ TCP သည် စိတ်ချရပြီး ချိတ်ဆက်မှုအခြေပြု (reliable and connection-oriented) ဖြစ်သောကြောင့် BGP သည် packet များကို retransmission ပြန်လုပ်ရန် သို့မဟုတ် အစဉ်လိုက်စီစဉ်ရန် ကိုယ်တိုင် ပြုလုပ်စရာမလိုပါ၊ Sessions များကို အလိုအလျောက် discover မလုပ်ဘဲ explicitly configure လုပ်ပေးရမည်ဖြစ်ပြီး TCP connection ပြတ်တောက်သွားပါက BGP session ပါ ပြုတ်ကျသွားသည်။
BGP states များကို အစဉ်လိုက် ဖော်ပြပါ။
Idle → Connect → Active → OpenSent → OpenConfirm → Established ဖြစ်သည်။ Established state တစ်ခုတည်းတွင်သာ routes များကို အပြန်အလှန် ဖလှယ်နိုင်သည်။
Session တစ်ခုသည် Idle နှင့် Active အကြား ခုန်ပေါက်နေပါသည်။ မည်သည့်အရာ မှားယွင်းနေသနည်း။
TCP ချိတ်ဆက်မှု မတည်ဆောက်နိုင်ခြင်း ဖြစ်သည်။ Active သည် နားထောင်ကောင်းသော်လည်း အမှန်တကယ်တွင် "TCP ကျရှုံးသဖြင့် ပြန်လည်ကြိုးစားနေဆဲ" ဟု အဓိပ္ပာယ်ရသည်။ Peer IP သို့ reachability ရှိမရှိ၊ TCP/179 ပိတ်ဆို့မခံရခြင်း ရှိမရှိနှင့် peer address မှန်မမှန် စစ်ဆေးပါ။ iBGP အတွက်မူ အများအားဖြင့် peer ၏ loopback address သည် IGP (OSPF/IS-IS) ထဲတွင် ထည့်သွင်းရန် ကျန်ခဲ့ခြင်းကြောင့် ဖြစ်သည်။
OpenSent တွင် ရပ်တန့်နေခြင်း — မည်သည့်အရာကို ညွှန်ပြနေသနည်း။
Open message ကို ပေးပို့ခဲ့သော်လည်း တစ်ဖက်မှ ပြန်ကြားချက်သည် မှန်ကန်ကြောင်း မအတည်ပြုနိုင်ခြင်း ဖြစ်သည်။ အများအားဖြင့် Remote-AS number မကိုက်ညီခြင်း သို့မဟုတ် peers နှစ်ခုစလုံးတွင် router ID တူညီနေခြင်းကြောင့် ဖြစ်သည်။
BGP message အမျိုးအစား ၄ မျိုးမှာ အဘယ်နည်း။
Open (AS၊ router ID၊ hold time၊ capabilities များကို ညှိနှိုင်းသည်)၊ Update (Prefixes များကို ကြေညာသည်/ဖျက်သိမ်းသည်)၊ Keepalive (အသက်ရှင်နေဆဲဖြစ်ကြောင်း စစ်ဆေးသည်) နှင့် Notification (အမှားအယွင်းဖြစ်ပွားခြင်း — Session ကို အမြဲတမ်း ချက်ချင်း ပိတ်သိမ်းသည်)။
Default keepalive နှင့် hold timers များသည် မည်မျှနည်း။
Keepalive 60s၊ Hold 180s ဖြစ်သည် — Hold time သည် စံသတ်မှတ်ချက်အရ keepalive ၏ ၃ ဆ ဖြစ်သည်။ Open message အတွင်း peers နှစ်ခုအနက် နည်းသော hold time တန်ဖိုးကို ညှိနှိုင်းရယူသည်။
Convergence မြန်ဆန်စေရန်အတွက် BGP timers များကို လျှော့ချသင့်ပါသလား။
ခဲယဉ်းစွာသာ ပြုလုပ်သင့်သည်။ Aggressive timers များသည် CPU ဝန်ပိချိန် သို့မဟုတ် ယာယီ ကွန်ရက်ကြပ်တည်းချိန်များတွင် session ကို မလိုအပ်ဘဲ ပြုတ်ကျစေနိုင်ပြီး session တစ်ခု bounce ဖြစ်ခြင်းသည် ပြတ်တောက်မှုကို နှေးကွေးစွာ သိရှိခြင်းထက် ပိုမိုဆိုးရွားသည်။ BGP ကိုယ်တိုင်ကို နုနယ်မသွားစေဘဲ — BGP အား အချက်ပြပေးနိုင်သည့် ပေါ့ပါးသော protocol ဖြစ်သည့် BFD ကို အသုံးပြုပါ။
eBGP နှင့် iBGP¶
eBGP နှင့် iBGP မည်သို့ ကွဲပြားသနည်း။
Protocol အတူတူပင်ဖြစ်သော်လည်း eBGP သည် ယုံကြည်စိတ်ချရမှုမရှိသော နယ်နိမိတ်ကို ဖြတ်သန်းရသဖြင့် စည်းမျဉ်းများ ကွဲပြားသည်။ eBGP သည် TTL 1 ဖြင့် physical interface addresses များပေါ်တွင် peer ဖွဲ့သည်၊ AS path ကို prepend လုပ်သည်၊ Next-hop ကို မိမိကိုယ်ကိုအဖြစ် ပြောင်းလဲသတ်မှတ်သည်။ iBGP သည် loopbacks များပေါ်တွင် peer ဖွဲ့သည်၊ AS path နှင့် next-hop ကို မူလအတိုင်း ထားရှိသည်၊ Local-pref ကို သယ်ဆောင်ပေးပြီး iBGP မှ သင်ယူရရှိသော routes များကို အခြား iBGP peers များထံ ဘယ်တော့မှ ထပ်မံ မကြေညာပါ။
iBGP peers များသည် Loopbacks များကို အဘယ်ကြောင့် အသုံးပြုကြသနည်း။
iBGP peers များသည် ပုံမှန်အားဖြင့် redundant paths များစွာရှိသော hop ပေါင်းများစွာ ခြားထားလေ့ရှိသည်။ Loopback session သည် physical link တစ်ခုတည်း ပျက်စီးသွားသော်လည်း IGP က အခြားလမ်းကြောင်းမှ ပြန်လည်ရှာဖွေပေးနိုင်သဖြင့် ဆက်လက်အသက်ရှင်နိုင်သည် — သို့သော် IGP ထဲတွင် loopbacks များကို ကြေညာထားမှသာ ဖြစ်နိုင်မည် ဖြစ်သည်။
Next-hop-self ဆိုသည်မှာ အဘယ်နည်း၊ မည်သည့်အချိန်တွင် လိုအပ်သနည်း။
Router တစ်ခုသည် eBGP မှ သင်ယူရရှိသော prefix တစ်ခုကို iBGP peers များထံ ကြေညာသည့်အခါ next hop သည် အိမ်နီးချင်း ပြင်ပ AS အတွင်းရှိ link IP ကို ဆက်လက်ညွှန်ပြနေတတ်သည် — ထို address ကို internal router များက မရောက်ရှိနိုင်ပါ။ next-hop-self သည် ထို next hop အား internal IGP မှ ကြေညာထားသော advertising router ၏ ကိုယ်ပိုင် address သို့ ပြန်လည် rewrite လုပ်ပေးသည်။
BGP တွင် route တစ်ခုသည် valid and best ဟု ပြသနေသော်လည်း traffic မရောက်ရှိနိုင်ပါ။
Next hop သည် Data-plane route တစ်ခုဖြင့် ရောက်ရှိနိုင်ခြင်း ရှိမရှိ စစ်ဆေးပါ။ BGP သည် default route အပါအဝင် မည်သည့်နည်းဖြင့်မဆို next hop ကို resolve လုပ်နိုင်ပါက route ကို valid အဖြစ် သတ်မှတ်သည်။ Labs များတွင် ထို default route သည် management interface ဖြစ်နေတတ်သဖြင့် route install ဖြစ်သွားသော်လည်း traffic များကို out-of-band သို့ တိတ်တဆိတ် ပေးပို့နေမိတတ်သည်။ show ip route <next-hop> ဖြင့် စစ်ဆေးပြီး FIB entry က အမှန်တကယ် ဘာကို ညွှန်ပြနေသည်ကို ကြည့်ပါ။
iBGP သည် အခြား iBGP peers များထံ routes များကို အဘယ်ကြောင့် ပြန်လည်မကြေညာနိုင်သနည်း။
Loop ကာကွယ်ရန် ဖြစ်သည်။ iBGP သည် AS path ကို prepend မလုပ်သောကြောင့် ထိုနည်းဖြင့် loop ကို မရှာဖွေနိုင်ပါ။ ထို့ကြောင့် စည်းမျဉ်းအရ speaker တိုင်းသည် route ကို တိုက်ရိုက် ကြားသိနေရမည် ဖြစ်သည် — ယင်းကြောင့် full mesh ဖြစ်လာပြီး route reflectors များက ORIGINATOR_ID နှင့် CLUSTER_LIST တို့ကို အသုံးပြု၍ ဤစည်းမျဉ်းကို ဖြေလျှော့ပေးခြင်း ဖြစ်သည်။
Attributes များ¶
Attribute အမျိုးအစားများမှာ အဘယ်နည်း၊ ၎င်းတို့သည် အဘယ်ကြောင့် အရေးပါသနည်း။
Well-known mandatory (ORIGIN, AS_PATH, NEXT_HOP)၊ Well-known discretionary (LOCAL_PREF)၊ Optional transitive (COMMUNITY)၊ Optional non-transitive (MED, ORIGINATOR_ID, CLUSTER_LIST) တို့ ဖြစ်ကြသည်။ Router တစ်ခုသည် မိမိနားမလည်သော attribute နှင့် တွေ့သည့်အခါ ဘာလုပ်ရမည်ကို ၎င်းတို့က သတ်မှတ်ပေးသည် — Transitive attributes များကို ဆက်လက်လက်ဆင့်ကမ်းပေးသောကြောင့် communities ကို အသုံးမပြုသော ကွန်ရက်များကို ဖြတ်သန်းသွားနိုင်ခြင်း ဖြစ်သည်။
Local preference နှင့် MED — မည်သည့်အရာက ဘာကို ထိန်းချုပ်သနည်း။
Local-pref သည် မိမိ AS အနေဖြင့် မည်သည့်ထွက်ပေါက်ကို သုံးမည်ဟူသော ဆုံးဖြတ်ချက်ဖြစ်သည် — ၎င်းသည် Outbound traffic ကို ထိန်းချုပ်ပြီး မိမိ AS အတွင်း အကြွင်းမဲ့ အာဏာရှိသည်။ MED သည် အိမ်နီးချင်း AS အား မည်သည့်အပေါက်မှ ဝင်ရောက်လာပါဟု အကြံပြုချက်ဖြစ်သဖြင့် Inbound traffic ကို လွှမ်းမိုးသည် — သို့သော် ၎င်းတို့၏ local-pref ကို ဦးစွာ နှိုင်းယှဉ်သောကြောင့် တောင်းဆိုချက်မျှသာ ဖြစ်သည်။
MED ကို တူညီသော AS မှ လာသည့် paths များကြားတွင်သာ အဘယ်ကြောင့် နှိုင်းယှဉ်သနည်း။
အကြောင်းမှာ MED တန်ဖိုးများသည် တူညီသော စံနှုန်းတစ်ခု မဟုတ်သောကြောင့်ဖြစ်သည် — Provider တစ်ခု၏ 50 သည် အခြား provider ၏ 500 နှင့် နှိုင်းယှဉ်ပါက အဓိပ္ပာယ်မရှိပေ။ မတူညီသော ASes များအကြား နှိုင်းယှဉ်ခြင်းသည် အဓိပ္ပာယ်မရှိပါ၊ သို့သော် always-compare-med က ၎င်းကို အတင်းအကျပ် နှိုင်းယှဉ်ပေးနိုင်သည်။
Weight ဆိုသည်မှာ အဘယ်နည်း၊ Local-pref နှင့် မည်သို့ ကွဲပြားသနည်း။
Weight သည် Router တစ်လုံးတည်းတွင်သာ သက်ဆိုင်ပြီး ပြင်ပသို့ ဘယ်တော့မှ မကြေညာပါ; Local-pref မှာမူ iBGP မှတစ်ဆင့် AS တစ်ခုလုံးသို့ ပျံ့နှံ့သည်။ Weight သည် အဆင့် ၁ ဖြစ်ပြီး Local-pref သည် အဆင့် ၂ ဖြစ်သည်။ AS တစ်ခုလုံး သက်ရောက်စေလိုသော ကိစ္စများအတွက် local-pref ကိုသာ ဦးစားပေးပါ — Weight သည် စက်တစ်လုံးတည်းကိုသာ တိတ်တဆိတ် သက်ရောက်သဖြင့် troubleshooting လုပ်ရာတွင် ရှုပ်ထွေးစေသည်။
Origin codes များသည် အဘယ်အရာကို ဆိုလိုသနည်း။
network statement မှ လာသော i (IGP)၊ သမိုင်းဝင်ဖြစ်သော e (EGP)၊ Redistribution မှ လာသော ? (incomplete) တို့ ဖြစ်သည်။ ဦးစားပေးအစဉ်လိုက်မှာ IGP > EGP > Incomplete ဖြစ်ပြီး အဆင့် ၅ တွင် နှိုင်းယှဉ်သည်။ တူညီသော အခြားအချက်များ ရှိနေပါက redistribute လုပ်ထားသော route သည် network statement မှ route ကို အရှုံးပေးရသည်။
NO_EXPORT သည် အဘယ်အရာကို လုပ်ဆောင်ပေးသနည်း။
"ဤ route ကို AS ပြင်ပသို့ ဆက်လက်မကြေညာပါနှင့်" ဟု အဓိပ္ပာယ်ရသော well-known community တစ်ခု ဖြစ်သည်။ Internet ကွန်ရက်ကြီးတစ်ခုလုံးဆီသို့ မပေါက်ကြားစေဘဲ ပြည်တွင်း၌သာ သို့မဟုတ် တိုက်ရိုက်ချိတ်ဆက်ထားသော peer တစ်ခုနှင့်သာ သုံးစွဲလိုသည့် ပိုမိုတိကျသော subnets များအတွက် အသုံးဝင်သည်။
Best-Path ရွေးချယ်မှု စည်းမျဉ်း¶
Best-path algorithm အဆင့်ဆင့်ကို ရှင်းပြပါ။
Weight (အမြင့်ဆုံး) → Local-pref (အမြင့်ဆုံး) → Locally originated → AS path length (အတိုဆုံး) → Origin (IGP < EGP < Incomplete) → MED (အနည်းဆုံး) → eBGP over iBGP → Next hop ဆီသို့ IGP metric (အနည်းဆုံး) → Oldest path → Lowest router ID → Lowest neighbour IP။ ကွဲပြားခြားနားမှုကို စတင်ဖြစ်ပေါ်စေသည့် ပထမဆုံးအဆင့်က အနိုင်ရသည်; ၎င်း၏ အောက်ရှိ အရာများကို စစ်ဆေးတွက်ချက်ခြင်း မပြုတော့ပါ။
Path A တွင် local-pref 200, AS path 3 ခု ရှိသည်။ Path B တွင် local-pref 100, AS path 1 ခုသာ ရှိသည်။ မည်သူ အနိုင်ရမည်နည်း။
Path A က အနိုင်ရပါမည်၊ အဆင့် ၂ တွင် ဆုံးဖြတ်ပြီးသွားသည်။ Local preference ကို AS path မတိုင်မီ စစ်ဆေးသောကြောင့် Path B ၏ ပိုတိုသော လမ်းကြောင်းကို လုံးဝ ထည့်သွင်းစဉ်းစားခွင့် မရတော့ပါ။ ၎င်းသည် လက်တွေ့တွင် အဖြစ်အများဆုံး အံ့အားသင့်ရသည့် အချက်ဖြစ်သည် — "ပိုတိုသော လမ်းကြောင်းကို အသုံးမပြုပါ" ဆိုသည်မှာ အမြဲတစေနီးပါး local-pref က ၎င်း၏ အလုပ်ကို လုပ်ဆောင်နေခြင်းသာ ဖြစ်သည်။
Hot-potato routing ဆိုသည်မှာ အဘယ်နည်း။
အဆင့် ၈ ဖြစ်သည် — အခြားအရာအားလုံး သရေကျနေသည့်အခါ next hop ဆီသို့ IGP metric အနည်းဆုံး (အနီးဆုံး ထွက်ပေါက်) ရှိသော လမ်းကြောင်းကို ဦးစားပေးသည်။ မိမိ AS အတွင်းမှ traffic ကို အမြန်ဆုံး စွန့်ထုတ်၍ အခြား AS အား သယ်ဆောင်စေခြင်းဖြစ်ရာ မိမိအတွက် အသက်သာဆုံး ဖြစ်သည်။
'Oldest path' သည် အဘယ်ကြောင့် Tiebreak တစ်ခု ဖြစ်ရသနည်း၊ အားနည်းချက်မှာ အဘယ်နည်း။
တည်ငြိမ်မှုအတွက် ဖြစ်သည် — တူညီစွာ ကောင်းမွန်သော လမ်းကြောင်းအသစ်တစ်ခု ပေါ်လာရုံဖြင့် best path ကို မတည်မငြိမ် မပြောင်းလဲစေရန် ဖြစ်သည်။ အားနည်းချက်မှာ ရလဒ်သည် ရောက်ရှိလာသည့် အချိန်အစဉ်လိုက် (arrival order) အပေါ် မူတည်သွားသဖြင့် တူညီသော tables ရှိသည့် router နှစ်ခုက မတူညီစွာ ရွေးချယ်မိနိုင်ပြီး debug လုပ်ရန် အလွန်ခက်ခဲစေသည်။
Provider တစ်ခုဆီသို့ Equal-cost paths နှစ်ခု ရှိနေသည်။ အဘယ်ကြောင့် တစ်ခုတည်းကိုသာ သုံးနေသနည်း။
BGP သည် default အားဖြင့် အကောင်းဆုံး best path တစ်ခုတည်းကိုသာ install လုပ်ပေးသည်။ maximum-paths N ဖြင့် multipath ကို ဖွင့်ပေးနိုင်သည်; Candidates များသည် IGP metric အထိ သရေကျနေရမည်ဖြစ်ပြီး တူညီသော AS path length ရှိရမည်။ Best path တစ်ခုတည်းကိုသာ အခြားသူများထံ ဆက်လက်ကြေညာပေးဆဲ ဖြစ်သည်။
Policy¶
Prefix list နှင့် Route map အကြား ကွာခြားချက်မှာ အဘယ်နည်း။
Prefix list သည် prefixes များနှင့် subnet lengths များကိုသာ match ပြုလုပ်သည် — စစ်ဆေးရွေးချယ်မှု သက်သက်သာ ဖြစ်သည်။ Route map သည် policy engine ဖြစ်သည်: Prefix lists၊ AS paths သို့မဟုတ် communities များကို match လုပ်ပြီး permit၊ deny သို့မဟုတ် attributes များကို သတ်မှတ်ပေးသည် (set attributes)။ Route maps သည် local-pref၊ MED သို့မဟုတ် communities များကို အမှန်တကယ် ပြောင်းလဲပေးနိုင်သော အရာဖြစ်သည်။
Route map တွင် Matching clause မပါရှိပါက မည်သို့ဖြစ်မည်နည်း။
Implicit deny ဖြစ်သည် — အရာအားလုံး drop ဖြစ်သွားမည်။ မပြီးပြတ်သေးသော route map ကို production peer ပေါ်တွင် သတ်မှတ်လိုက်ပါက ထို session ၏ routes အရေအတွက် သုညသို့ ချက်ချင်း ကျဆင်းသွားစေသည်။ show ip bgp neighbors <ip> received-routes နှင့် table ထဲရှိ routes များကို နှိုင်းယှဉ်စစ်ဆေးပါ။
AS-path regex ^$ သည် မည်သည့်အရာနှင့် ကိုက်ညီသနည်း၊ အဘယ်ကြောင့် အရေးပါသနည်း။
အလွတ်ဖြစ်နေသော AS path — မိမိကိုယ်တိုင် စတင်ထုတ်လွှင့်သော routes များနှင့် ကိုက်ညီသည်။ Upstream providers များထံ Outbound filter အဖြစ် သတ်မှတ်လိုက်ပါက "ငါ့ကိုယ်ပိုင် prefixes များကိုသာ ကြေညာပါ" ဟု အဓိပ္ပာယ်ရပြီး သင်သည် မတော်တဆ transit network ဖြစ်သွားခြင်းမှ ကာကွယ်ပေးသည်။ ၎င်းအမှားသည် ကြီးမားသော အင်တာနက်ပြတ်တောက်မှုများစွာ၏ အကြောင်းရင်း ဖြစ်ခဲ့သည်။
Policy များကို စနစ်တကျ ထိန်းသိမ်းနိုင်ရန် Communities ကို မည်သို့ အသုံးပြုမည်နည်း။
Ingress နယ်စပ်တွင် route လာရာအရင်းအမြစ်အလိုက် Tag တွဲကပ်ပါ — Customer၊ Peer၊ Transit — ထို့နောက် အခြားသော policy အားလုံးတွင် ထို community ကိုသာ match လုပ်ပါ။ Customer အသစ်ထပ်တိုးပါက route-map တိုင်းကို ပြင်စရာမလိုဘဲ tag တစ်ခုတည်း သတ်မှတ်ပေးရုံဖြင့် ပြီးစီးသွားမည်။
eBGP peers များတွင် Maximum-prefix ကို အဘယ်ကြောင့် သတ်မှတ်သင့်သနည်း။
Peer တစ်ခုက အင်တာနက် full table တစ်ခုလုံးကို မှားယွင်းယိုစိမ့်ပို့ဆောင်လာပါက memory ကုန်ခမ်းသွားပြီး Sessions အားလုံး ပြုတ်ကျသွားနိုင်သည်။ Max-prefix သည် ထိုမကောင်းသော session တစ်ခုတည်းကိုသာ ဖြတ်တောက်လိုက်သည်။ မျှော်လင့်ထားသော ပမာဏအနီးတွင် သတ်မှတ်ပါ — Prefixes ၁၀ ခုသာ ပို့မည့် customer ကို တစ်သန်းအထိ မထားသင့်ပေ။
GTSM ဆိုသည်မှာ အဘယ်နည်း၊ ebgp-multihop ထက် အဘယ်ကြောင့် ပိုမိုကောင်းမွန်သနည်း။
eBGP သည် တိုက်ရိုက်ချိတ်ဆက်ထားသည်ဟု ယူဆကာ default TTL 1 ကို သုံးသည်။ Multihop အတွက် ebgp-multihop သုံးခြင်းက ထိုကာကွယ်မှုကို အားနည်းစေသည်။ GTSM သည် စစ်ဆေးမှုကို ပြောင်းပြန်လှန်လိုက်သည် — ရောက်ရှိလာသော packets များတွင် မြင့်မားသော TTL ရှိရမည်ဟု တောင်းဆိုသဖြင့် အဝေးမှ spoofed packets များကို BGP ထံ မရောက်မီ hardware အဆင့်မှာပင် drop ပစ်လိုက်သည်။
Inbound policy တစ်ခုကို Session မပြတ်တောက်ဘဲ မည်သို့ ပြောင်းလဲသတ်မှတ်မည်နည်း။
clear ip bgp <peer> soft in ကို run ပါ၊ ၎င်းသည် ညှိနှိုင်းထားသော Route refresh capability ကို အသုံးပြု၍ peer အား routes များ ပြန်လည်ပို့ပေးရန် တောင်းဆိုသည်။ Session မပြတ်တောက်ပါ။ Production တွင် clear ip bgp * ကို ဘယ်တော့မှ မ run ပါနှင့် — ၎င်းသည် session အားလုံးကို reset ချပြီး table တစ်ခုလုံးကို ပြန်လည် converge လုပ်စေသည်။
ယခုအခါ Dampening ကို အဘယ်ကြောင့် သတိထား၍သာ သုံးကြသနည်း။
Aggressive dampening သည် တိုတောင်းသော မတည်ငြိမ်မှုလေးတစ်ခုအပြီးတွင် ကောင်းမွန်သော prefixes များကိုပါ နာရီပေါင်းများစွာ ပိတ်မိစေပြီး flap ဖြစ်ရုံထက် ပိုမိုဆိုးရွားသော ပြတ်တောက်မှုများကို ဖြစ်ပေါ်စေခဲ့သောကြောင့် ဖြစ်သည်။
Scaling စနစ်¶
iBGP full mesh သည် အဘယ်ကြောင့် Scale မလုပ်နိုင်သနည်း။
n(n−1)/2 sessions လိုအပ်သောကြောင့်ဖြစ်သည် — Routers ၅၀ တွင် session ပေါင်း ၁,၂၂၅ ခု ရှိလာမည်။ ပိုမိုဆိုးရွားသည်မှာ router တစ်ခု ထပ်တိုးတိုင်း ရှိပြီးသား router တိုင်းကို လိုက်လံပြင်ဆင်ရသဖြင့် change window အလွန်ကြီးမားလာသည်။
Route reflector သည် မည်သို့ အလုပ်လုပ်သနည်း။
၎င်းသည် iBGP မှ သင်ယူရရှိသော routes များကို မိမိ၏ clients များထံ ပြန်လည်ကြေညာပေးခွင့် (re-advertise) ရှိသည်၊ ထို့ကြောင့် clients များသည် reflector နှင့်သာ peer ဖွဲ့ပြီး sessions အရေအတွက် n အထိ ကျဆင်းသွားသည်။ Reflector ပေါ်တွင်သာ configure လုပ်ရန်လိုပြီး client မှာမူ သာမန် iBGP speaker တစ်ခုသာ ဖြစ်သဖြင့် အဆင့်ဆင့် တိုးချဲ့အသုံးပြုနိုင်သည်။
Reflection စည်းမျဉ်းများမှာ အဘယ်နည်း။
Client ထံမှ ရရှိပါက — အခြား clients များနှင့် non-clients များထံ reflect လုပ်သည်။ Non-client ထံမှ ရရှိပါက — Clients များထံသို့သာ reflect လုပ်သည်။ eBGP ထံမှ ရရှိပါက — လူတိုင်းထံ ပို့သည်။ Non-client routes များကို non-clients အချင်းချင်းကြား မပို့သောကြောင့် non-clients များအချင်းချင်းကြားတွင်မူ full mesh ဆက်လက် လိုအပ်နေဆဲ ဖြစ်သည်။
AS-path မပါရှိဘဲ Route Reflection သည် Loops မဖြစ်အောင် မည်သို့ ကာကွယ်သနည်း။
ORIGINATOR_ID သည် မူလ စတင်ကြေညာခဲ့သော router ၏ router ID ကို သယ်ဆောင်ထားသည်; Router တစ်ခုသည် မိမိကိုယ်ပိုင် ID ကို တွေ့ပါက ထို route ကို ပယ်ဖျက်သည်။ CLUSTER_LIST သည် ဖြတ်သန်းခဲ့သော clusters များကို မှတ်တမ်းတင်ထားသည်; Reflector တစ်ခုသည် မိမိကိုယ်ပိုင် cluster ID ကို တွေ့ပါက ပယ်ဖျက်သည်။ နှစ်ခုစလုံးသည် optional non-transitive ဖြစ်ပြီး AS ပြင်ပသို့ ဘယ်တော့မှ မထွက်ခွာပါ။
Reflectors နှစ်လုံး ထားရှိသည့်အခါ Cluster ID တူညီသင့်သလား သို့မဟုတ် မတူညီသင့်သလား။
တူညီပါက တစ်ခု၏ reflected routes များကို အခြားတစ်ခုက လျစ်လျူရှုသဖြင့် memory သက်သာသော်လည်း clients များအတွက် paths ရွေးချယ်စရာ နည်းပါးသွားသည်။ မတူညီပါက အချင်းချင်း၏ routes များကို အသစ်အဖြစ် မှတ်ယူသဖြင့် memory ပိုကုန်ပြီး duplicate updates ဖြစ်သော်လည်း ပိုမိုကောင်းမွန်သော redundancy နှင့် path diversity ကို ရရှိစေသည်။ ခေတ်သစ်တွင် မတူညီသော Cluster IDs ကို ပိုမိုရွေးချယ်ကြသည်။
Route reflection ကြောင့် မည်သည့်အရာ ဆုံးရှုံးရသနည်း။
Path diversity (လမ်းကြောင်း ကွဲပြားစုံလင်မှု) ဆုံးရှုံးရသည်။ Reflector သည် ၎င်း၏ ကိုယ်ပိုင် best path တစ်ခုတည်းကိုသာ ကြေညာသောကြောင့် clients များသည် မိမိတို့၏ ကိုယ်ပိုင် IGP အနေအထားမှ မဟုတ်ဘဲ reflector ၏ IGP အနေအထားမှ ရွေးချယ်ထားသော လမ်းကြောင်းတစ်ခုတည်းကိုသာ မြင်တွေ့ရသည် — ယင်းသည် အကောင်းဆုံး မဟုတ်သော sub-optimal routing ဖြစ်စေနိုင်သည်။ add-path က paths များစွာ ကြေညာခွင့်ပေးနိုင်သော်လည်း memory ပိုမို သုံးစွဲစေသည်။
Route reflectors သုံးသင့်သလား သို့မဟုတ် Confederations သုံးသင့်သလား။
အမြဲတစေနီးပါး Route reflectors ကိုသာ သုံးသင့်သည်။ နှစ်ခုစလုံးက mesh ပြဿနာကို ဖြေရှင်းပေးသော်လည်း Reflection သည် ကွန်ရက်မပြတ်တောက်ဘဲ အဆင့်ဆင့် တပ်ဆင်နိုင်ချိန်တွင် Confederations မှာမူ AS numbering စနစ်တစ်ခုလုံးကို အသစ်ပြန်လည်ဒီဇိုင်းဆွဲရသည်။ Confederations သည် စောစီးစွာကတည်းက စတင်ခဲ့သော ကွန်ရက်ဟောင်းများတွင်သာ ကျန်ရစ်တော့သည်။
Platform ဆိုင်ရာ¶
eBGP နှင့် iBGP ၏ Administrative Distance မှာ မည်မျှနည်း။
အစဉ်အလာအရ 20 နှင့် 200 ဖြစ်သည် — သို့သော် ၎င်းသည် Cisco IOS ၏ သတ်မှတ်ချက်သာဖြစ်ပြီး စံစနစ် (standard) မဟုတ်ပါ။ Arista EOS သည် နှစ်မျိုးစလုံးအတွက် Default 200 ကို သတ်မှတ်ထားပါသည်၊ ယင်းကို Lab 01 တွင် လက်တွေ့စစ်ဆေးအတည်ပြုထားသည်။ သမားရိုးကျ အဖြေကို ပြောပြပြီး vendor အလိုက် ကွဲပြားနိုင်ကြောင်း ထည့်သွင်းပြောကြားပါ။