၂ · Path Attributes များ¶

BGP route တိုင်းသည် attributes များကို သယ်ဆောင်ထားသည်။ Policy က ၎င်းတို့ကို သတ်မှတ်ပေးပြီး best-path algorithm က ၎င်းတို့ကို နှိုင်းယှဉ်ပေးသည်။ Attributes များကို နားလည်သဘောပေါက်ခြင်းသည် BGP တစ်ခုလုံး၏ အဓိကအစိတ်အပိုင်းကို နားလည်ခြင်း ဖြစ်သည်။

အောက်တွင် lab fabric မှ ရယူထားသော route တစ်ခု၏ attributes အစစ်အမှန်များကို ဖော်ပြထားပါသည် -

BGP routing table entry for 172.16.30.0/24
 Paths: 1 available
  65002
    10.0.13.3 from 10.0.13.3 (3.3.3.3)
      Origin IGP, metric 0, localpref 100, IGP metric 0, weight 0, tag 0
      Received 00:29:38 ago, valid, external, best

65002 သည် AS path ဖြစ်သည်။ ထို့နောက် Origin၊ MED (metric အဖြစ် ပြသထားသည်)၊ Local preference၊ Weight — နှင့် အဆုံးအဖြတ်ဖြစ်သော valid, external, best တို့ ဖြစ်ကြသည်။

အဓိက အမျိုးအစား ၄ မျိုး (The four categories)¶

ဤအမျိုးအစား ခွဲခြားမှုများသည် အခေါ်အဝေါ်သက်သက် မဟုတ်ပါ — Router တစ်ခုသည် မိမိနားမလည်သော attribute တစ်ခုနှင့် တွေ့ကြုံရသည့်အခါ မည်သို့ တုံ့ပြန်ဆောင်ရွက်ရမည်ကို တိကျစွာ သတ်မှတ်ပေးထားခြင်း ဖြစ်ပြီး ယင်းကြောင့်ပင် BGP သည် router အဟောင်းများကို မထိခိုက်စေဘဲ communities ကဲ့သို့သော လုပ်ဆောင်ချက်အသစ်များကို တိုးချဲ့လက်ခံနိုင်ခဲ့ခြင်း ဖြစ်သည်။

အမျိုးအစား (Category)	Support လုပ်ရန် မဖြစ်မနေ လိုသလား	နားမလည်ပါက ဆက်လက်လက်ဆင့်ကမ်းရမလား
Well-known mandatory	ဟုတ်ကဲ့ — Update တိုင်းတွင် မဖြစ်မနေ ပါဝင်ရမည်	သက်ဆိုင်ခြင်းမရှိပါ
Well-known discretionary	ဟုတ်ကဲ့	သက်ဆိုင်ခြင်းမရှိပါ
Optional transitive	မလိုပါ	ဟုတ်ကဲ့၊ Partial အဖြစ် သတ်မှတ်၍ လက်ဆင့်ကမ်းသည်
Optional non-transitive	မလိုပါ	မဟုတ်ပါ၊ ဖျက်ပစ်သည် (dropped)

Attribute	အမျိုးအစား
ORIGIN, AS_PATH, NEXT_HOP	Well-known mandatory
LOCAL_PREF, ATOMIC_AGGREGATE	Well-known discretionary
COMMUNITY, Extended Communities	Optional transitive
MED, ORIGINATOR_ID, CLUSTER_LIST	Optional non-transitive

Optional Transitive အဘယ်ကြောင့် အရေးပါသနည်း

Communities ကို နားမလည်သော router တစ်ခုသည်ပင် ၎င်းတို့ကို ဆက်လက် forward လုပ်ပေးသည်၊ ထို့ကြောင့် သင်သတ်မှတ်လိုက်သော community သည် ၎င်းကို အသုံးမပြုသော ကြားခံကွန်ရက်များကို ဖြတ်သန်းသွားနိုင်ဆဲ ဖြစ်သည်။ ဤဂုဏ်သတ္တိကြောင့်ပင် communities ကို provider အချင်းချင်းကြား သတင်းအချက်အလက် ပေးပို့သည့် signalling ယန္တရားအဖြစ် အသုံးပြုနိုင်ခြင်း ဖြစ်သည်။

MED သည် မူလဒီဇိုင်းအရ non-transitive ဖြစ်သည် — ၎င်းသည် တိုက်ရိုက်ကပ်လျက်ရှိသော AS နှစ်ခုကြား၌သာ အဓိပ္ပာယ်ရှိသဖြင့် အခြားပြင်ပသို့ ဆက်လက် မပေါက်ကြားသင့်ပေ။

AS_PATH¶

Route တစ်ခု ဖြတ်သန်းခဲ့သော AS နံပါတ်များ စာရင်းဖြစ်သည်။ အဓိက တာဝန် ၂ ခု ရှိသည် -

Loop ကာကွယ်ခြင်း (Loop prevention)။ Router တစ်ခုသည် မိမိကိုယ်ပိုင် AS နံပါတ် ပါဝင်နေပြီးသား မည်သည့် route ကိုမဆို ပယ်ချ (reject) သည်။ ဤအချက်ကြောင့်ပင် eBGP တွင် သီးခြား loop ယန္တရား မလိုအပ်ခြင်း ဖြစ်သည် — ထို့အပြင် AS prepending မလုပ်သော iBGP တွင်မူ full-mesh စည်းမျဉ်း လိုအပ်ရသည့် အကြောင်းရင်း ဖြစ်သည်။

Path အလျား (Path length)။ Best-path algorithm ၏ အဆင့် ၄ ဖြစ်သည်။ တိုတောင်းသော လမ်းကြောင်းက အများအားဖြင့် အနိုင်ရသည်။

Prepending ပြုလုပ်ခြင်း သည် လမ်းကြောင်းတစ်ခုအား ဆွဲဆောင်မှုနည်းပါးသွားစေရန် အသုံးပြုသော စံနည်းလမ်းဖြစ်သည် -

route-map PREPEND permit 10
 set as-path prepend 65001 65001 65001

Provider နှစ်ခုထံ တူညီသော prefix ကို ကြေညာပြီး backup လိုင်းပေါ်တွင် prepending ပြုလုပ်လိုက်ပါက အတွင်းသို့ ဝင်ရောက်လာသော inbound traffic များသည် တိုတောင်းသော အခြားလမ်းကြောင်းကို ဦးစားပေး ရွေးချယ်သွားမည် ဖြစ်သည်။

Prepending သည် အကြမ်းဖျင်း ထိန်းချုပ်မှုသာ ဖြစ်သည်

သင်သည် internet တစ်ခုလုံးအား အခြားလမ်းကြောင်းကို ရွေးချယ်ရန် တောင်းဆိုနေခြင်းဖြစ်ပြီး သင့် prefixes များအပေါ်တွင် local preference သတ်မှတ်ထားသော မည်သူမဆိုသည် သင့် prepending ကို လုံးဝ လျစ်လျူရှုပါလိမ့်မည် — အကြောင်းမှာ local-pref ကို အဆင့် ၂ တွင် နှိုင်းယှဉ်ပြီး prepending ကိုမူ အဆင့် ၄ ရောက်မှ နှိုင်းယှဉ်သောကြောင့် ဖြစ်သည်။

Prepending သည် လွှမ်းမိုးမှုသာ ပေးနိုင်သည် (influences); တိုက်ရိုက်မထိန်းချုပ်နိုင်ပါ (does not control)။ Provider က အသိအမှတ်ပြုရန် သဘောတူထားသော Communities များသည် ပိုမိုတိကျသော ထိန်းချုပ်မှုကို ပေးစွမ်းနိုင်သည်။

NEXT_HOP¶

ဤ prefix ဆီသို့ traffic ပေးပို့ရမည့် နေရာဖြစ်သည်။

eBGP — ကြေညာသော router က မိမိကိုယ်ကို အဖြစ် သတ်မှတ်သည်
iBGP — မပြောင်းလဲဘဲ မူလအတိုင်း ဆက်လက်လက်ဆင့်ကမ်းသည်

ဒုတိယစည်းမျဉ်းသည် Lab 01 ၏ အဓိက ထောင်ချောက်ဖြစ်သည်။ iBGP peer တစ်ခုသည် အခြား AS အတွင်းရှိ link တစ်ခုပိုင်ဆိုင်သော next hop ကို လက်ခံရရှိပြီး ထို IP ဆီသို့ route မရှိပါက ထို route သည် အသုံးမပြုနိုင်တော့ပေ (unusable)။

Route သည် ရှိနေရုံမျှမက အသုံးပြုနိုင်ရမည် (usable ဖြစ်ရမည်)။ BGP သည် next hop ကို မည်သည့်နည်းဖြင့်မဆို resolve လုပ်နိုင်မှသာ (စမ်းသပ် lab များတွင် management interface ဖြစ်နေတတ်သော default route အပါအဝင်) route ကို valid အဖြစ် သတ်မှတ်သည်။ Lab 01 အဆင့် ၄ ကို ကြည့်ပါ။

Border router ပေါ်တွင် next-hop-self သတ်မှတ်ခြင်းဖြင့် ဖြေရှင်းနိုင်သည်။

LOCAL_PREF¶

မိမိ AS အနေဖြင့် မည်သည့် ထွက်ပေါက်ကို အသုံးပြုသင့်သနည်း။ တန်ဖိုး မြင့်မားသူက အနိုင်ရသည်။ Default မှာ 100 ဖြစ်သည်။

iBGP peers အချင်းချင်းကြား၌သာ ပေးပို့ပြီး eBGP peers များထံ ဘယ်တော့မှ မပို့ပါ — ၎င်းသည် ပြည်တွင်း ဆုံးဖြတ်ချက်ဖြစ်သောကြောင့် မိမိ AS အတွင်းသာ ပျံ့နှံ့ပြီး နယ်စပ်တွင် ရပ်တန့်သွားသည်။

route-map PREFER_PRIMARY permit 10
 set local-preference 200

၎င်းကို အဆင့် ၂ တွင် နှိုင်းယှဉ်သဖြင့် AS path၊ MED နှင့် အောက်ရှိ အခြားအရာအားလုံးကို အနိုင်ရသည်။ လမ်းကြောင်းများ မည်သို့ပင်ဖြစ်စေ "Provider A အသက်ရှင်နေသရွေ့ ၎င်းကို အမြဲတမ်းသုံးမည်" ဟူသော ရည်ရွယ်ချက်အတွက် အကောင်းဆုံး tool ဖြစ်သည်။

Local-pref သည် အပြင်ထွက်ခွာသော Outbound traffic ကို ထိန်းချုပ်သည် — မိမိကိုယ်ပိုင် router များက ထွက်ပေါက်ရွေးချယ်ရန် အသုံးပြုသည်။ အခြားသူများက သင့်ထံသို့ ပေးပို့မည့် traffic အပေါ် မည်သို့မျှ လွှမ်းမိုးနိုင်စွမ်း မရှိပါ။

MED (Multi-Exit Discriminator)¶

မိမိ AS အတွင်းသို့ ဝင်ရောက်နိုင်သော အပေါက်များစွာ ရှိသည့်အခါ မည်သည့်အပေါက်ကို အသုံးပြုသင့်သနည်း။ တန်ဖိုး နည်းပါးသူက အနိုင်ရသည်။

Local-pref ၏ ဆန့်ကျင်ဘက်ကြေးမုံပြင်ဖြစ်သည်- Local-pref သည် မိမိထွက်ခွာရန် ဆုံးဖြတ်ချက်ဖြစ်ပြီး MED မှာမူ မိမိအိမ်နီးချင်းအား အတွင်းသို့ ဝင်ရောက်ရန် အကြံပြုချက် (suggestion) ဖြစ်သည်။

MED ကို ကိုင်တွယ်ရခက်စေသော အချက် ၂ ချက် -

Default အားဖြင့် တူညီသော neighbouring AS မှ လာသည့် paths များအချင်းချင်းကြားတွင်သာ နှိုင်းယှဉ်သည်။ မတူညီသော providers များထံမှ MED များကို နှိုင်းယှဉ်ခြင်းသည် အဓိပ္ပာယ်မရှိပါ — တိုင်းတာပုံ စကေး မတူညီပါ — သို့သော် သင်က အတင်းအကျပ် လိုလားပါက always-compare-med ဖြင့် ပြုလုပ်နိုင်သည်။
၎င်းသည် ညွှန်ကြားချက်မဟုတ်ဘဲ တောင်းဆိုချက်မျှသာ ဖြစ်သည်။ အိမ်နီးချင်း၏ local-pref ကို ဦးစွာ နှိုင်းယှဉ်သောကြောင့် MED ကို အလွယ်တကူ override လုပ်ပစ်နိုင်သည်။

Provider တစ်ခုက သင်၏ MED ကို လျစ်လျူရှုပါက ပုံမှန်သာဖြစ်သည်; MED သည် အဆင့် ၆ တွင်သာ ရှိသည်။

WEIGHT¶

Router တစ်ခုတည်းတွင်သာ သက်ဆိုင်ပြီး ပြင်ပသို့ ဘယ်တော့မှ မကြေညာပါ (Local to one router)။ တန်ဖိုး အမြင့်ဆုံးက အနိုင်ရပြီး သင်ယူရရှိသော routes များအတွက် default မှာ 0 ဖြစ်သည်။

မူလက Cisco သီးသန့်ဖြစ်ပြီး ယခုအခါ အများအပြား အကောင်အထည်ဖော်ထားသည် — အထက်ပါ CLI output တွင် Arista က ပြသထားသည်ကို တွေ့နိုင်သည်။

အဆင့် ၁ ဖြစ်ပြီး purely local ဖြစ်သောကြောင့် weight သည် router တစ်ခုတည်းအတွက် အပြတ်အသတ် override ပြုလုပ်ရာတွင် သုံးသည်။ AS တစ်ခုလုံးတွင် သက်ရောက်စေလိုသော ကိစ္စများအတွက် local-pref ကိုသာ ဦးစားပေးသုံးပါ: Weight သည် စက်တစ်လုံးတည်းကိုသာ သက်ရောက်ပြီး အခြားစက်များတွင် ဘာမှ မပြောင်းလဲသဖြင့် troubleshooting ပြုလုပ်ရာတွင် အလွန် ရှုပ်ထွေးစေသည်။

ORIGIN¶

Route သည် BGP ထဲသို့ မည်သို့ စတင်ရောက်ရှိလာသနည်း။ အဆင့် ၅ တွင် နှိုင်းယှဉ်ပြီး ဦးစားပေး အစဉ်လိုက်မှာ -

Code	အဓိပ္ပာယ်
i (IGP)	`network` statement ဖြင့် ထည့်သွင်းထားသည် — ဦးစားပေး အမြင့်ဆုံး
e (EGP)	သမိုင်းဝင်ဖြစ်ပြီး လက်တွေ့တွင် မရှိတော့ပါ
? (incomplete)	Redistribute ပြုလုပ်ထားသည် — ဦးစားပေး အနိမ့်ဆုံး

အထက်ပါ CLI capture တွင် Origin IGP အဖြစ် တွေ့ရပြီး show ip bgp တွင် အနောက်ဆုံးရှိ i အဖြစ် တွေ့ရသည်။

လက်တွေ့ အကျိုးဆက်မှာ- အခြားအချက်များ တူညီနေပါက Redistribute ပြုလုပ်ထားသော route (?) သည် network statement ဖြင့် ထည့်ထားသော route ကို အရှုံးပေးရသည်။ အကယ်၍ လမ်းကြောင်းနှစ်ခုသည် အဆင့် ၅ အထိ သရေကျနေပြီး "မှားယွင်းသော" လမ်းကြောင်းက အနိုင်ရနေပါက တစ်ဖက်က redistribute လုပ်ထားသလား စစ်ဆေးကြည့်ပါ။

COMMUNITY¶

Route ပေါ်တွင် ကပ်နှိပ်လိုက်သော တံဆိပ် (tag) တစ်ခု ဖြစ်သည်။ ၎င်းကိုယ်တိုင်က ဘာမှ မလုပ်ဆောင်ပါ — ၎င်း၏ တန်ဖိုးမှာ အခြားနေရာရှိ policy များက ၎င်းကို အခြေခံ၍ စည်းမျဉ်းများ သတ်မှတ်နိုင်ခြင်း ဖြစ်သည်။

AS:value ပုံစံဖြင့် ရေးသားသည်၊ ဥပမာ 65001:100။

အများသိ လူသိများသော တန်ဖိုးများ (Well-known values) -

Community	သက်ရောက်မှု (Effect)
`NO_EXPORT`	AS ပြင်ပသို့ (သို့မဟုတ် confederation ပြင်ပသို့) ဆက်လက်မကြေညာပါနှင့်
`NO_ADVERTISE`	မည်သည့် peer ထံသို့မျှ လုံးဝ ဆက်လက်မကြေညာပါနှင့်
`LOCAL_AS`	Local sub-AS ပြင်ပသို့ ဆက်လက်မကြေညာပါနှင့်

route-map TAG_CUSTOMER permit 10
 set community 65001:100

အစစ်အမှန် စွမ်းအားမှာ Provider signalling ဖြစ်သည်- Transit provider တစ်ခုသည် "ငါ့ router တွေပေါ်မှာ local-pref 80 သတ်မှတ်ပါ" သို့မဟုတ် "AS X ဆီကို မကြေညာပါနဲ့" စသည့် communities များကို သတ်မှတ်ထုတ်ပြန်ပေးထားပြီး သင်က မိမိ route ကြေညာချက်များတွင် ထိုအတိုင်း tag တွဲပေးလိုက်ရုံသာ ဖြစ်သည်။ Prepending က အကြမ်းဖျင်းသာ တွန်းပို့ပေးနိုင်ချိန်တွင် Communities က တိကျသော ထိန်းချုပ်မှုကို ပေးစွမ်းနိုင်သည်။

Policy နှင့် filtering တွင် ဆက်လက်လေ့လာပါ။

မည်သည့်တာဝန်အတွက် မည်သည့် Attribute ကို သုံးမည်နည်း¶

သင် ထိန်းချုပ်လိုသော အရာ	အသုံးပြုရမည့် အရာ	လားရာ လမ်းကြောင်း
မိမိတို့ မည်သည့် ထွက်ပေါက်ကို သုံးမည်နည်း	LOCAL_PREF	Outbound traffic
အခြားသူများ မည်သည့် အပေါက်မှ ဝင်ရောက်လာမည်နည်း	MED၊ Prepending၊ Communities	Inbound traffic
Router တစ်လုံးတည်း၏ သီးခြားရွေးချယ်မှု	WEIGHT	ထို router သာလျှင်
Route တစ်ခု ပျံ့နှံ့မှုကို တားဆီးရန်	COMMUNITY (`NO_EXPORT`)	Advertisement scope

လူအများ မှားယွင်းတတ်သော မညီမျှမှု (Asymmetry)

မိမိထံမှ အပြင်သို့ ထွက်ခွာမည့်အရာကို အလွယ်တကူ ထိန်းချုပ်နိုင်ပြီး အတွင်းသို့ ဝင်ရောက်လာမည့်အရာကိုမူ ဖျောင်းဖျတောင်းဆိုရုံသာ တတ်နိုင်ပါသည်။

Local-pref သည် အကြွင်းမဲ့ အာဏာရှိသည် — သင်၏ router များက ၎င်းကို လိုက်နာကြသည်။ အတွင်းသို့ ဝင်ရောက်လာမည့် Inbound traffic ကို လွှမ်းမိုးလိုသည့် အရာအားလုံး (MED၊ prepending၊ communities) သည် သင်မပိုင်ဆိုင်သော အခြားကွန်ရက်များဆီသို့ တောင်းဆိုချက်မျှသာဖြစ်ပြီး ၎င်းတို့ထံတွင် သင့်တောင်းဆိုချက်ကို ပယ်ဖျက်နိုင်သော policy များ ရှိနေနိုင်သည်။

နောက်တစ်ခု: Best-path ရွေးချယ်မှု စည်းမျဉ်း → — ဤ attributes အားလုံးကို မည်သည့်အစဉ်အတိုင်း နှိုင်းယှဉ်သည်ကို ဆက်လက်လေ့လာပါမည်။