အင်တာဗျူး မေးခွန်းများ — IGP¶
ဤ Phase တစ်ခုလုံးအတွက် ကိုယ်တိုင်လေ့လာဆန်းစစ်နိုင်သော မေးခွန်းဘဏ် (self-test bank) ဖြစ်သည်။ စာမျက်နှာတစ်ခုစီ၏ အဆုံးတွင်လည်း သက်ဆိုင်ရာ မေးခွန်းများ ပါဝင်ပြီးဖြစ်သည်; ဤနေရာတွင် ၎င်းတို့ကို စုစည်းပေးထားသည့်အပြင် နည်းပညာအလုပ်အင်တာဗျူး screening round များတွင် အဓိက မေးလေ့ရှိသော အချက်အလက် ပြန်လည်အမှတ်ရမှု (factual-recall) မေးခွန်းများကိုပါ ထည့်သွင်းထားပါသည်။
မေးခွန်းတစ်ခုစီ၏ အဖြေကို မဖွင့်ကြည့်မီ မိမိဘာသာ အရင်ဆုံး ဖြေဆိုကြည့်ပါ။ အကယ်၍ အဖြေတစ်ခုက သင့်ကို အံ့အားသင့်စေပါက သက်ဆိုင်ရာ စာမျက်နှာဆီသို့ ပြန်သွား၍ ပြန်လည်ဖတ်ရှုပါ — အချက်အလက်ထက် အကြောင်းပြချက်ဆိုင်ရာ တွေးခေါ်မှုက ပိုမိုအရေးကြီးပါသည်။
Link-State အခြေခံသဘောတရားများ¶
ကြီးမားသော ကွန်ရက်များအတွက် link-state သည် distance-vector ထက် အဘယ်ကြောင့် ပိုမိုကောင်းမွန်သနည်း။
Distance-vector router များသည် အိမ်နီးချင်းများထံမှ ကောက်ချက်ချထားသော အဖြေများ ("X ဆီ ရောက်ဖို့ cost ၅ ဖြစ်တယ်") ကို ဖလှယ်ပြီး ဆက်လက်လက်ဆင့်ကမ်းကြသည်၊ ထို့ကြောင့် သတင်းဆိုးများသည် hop တစ်ခုပြီးတစ်ခုသာ ပျံ့နှံ့သဖြင့် သတင်းမရောက်မချင်း မရှိတော့သော လမ်းကြောင်းကို router က ဆက်လက်ယုံကြည်နေနိုင်သည်။ Link-state router များမှာမူ မိမိတို့တိုက်ရိုက်သိရှိသော အချက်အလက်အစစ်အမှန်များ — မိမိ link များနှင့် cost များ — ကို လူတိုင်းထံ flood ပြုလုပ်သဖြင့် router တိုင်းသည် ထပ်တူညီသော မြေပုံတစ်ခုကို ကိုယ်တိုင်တည်ဆောက်ပြီး သီးခြားစီ တွက်ချက်ကြသည်။ ထို့ကြောင့် convergence မြန်ဆန်ပြီး loop ကာကွယ်ရေး ဖြတ်လမ်းနည်းများ မလိုဘဲ ဖွဲ့စည်းပုံအရ loop-free စနစ်ကို ရရှိစေသည်။
SPF သည် အမှန်တကယ် ဘာကို တွက်ချက်ပေးသနည်း၊ မည်မျှ မကြာခဏ run သနည်း။
Local router ကို root အဖြစ်ထားကာ LSDB ပေါ်တွင် Dijkstra's algorithm ကို run ပြီး destination တိုင်းဆီသို့ shortest-path tree တစ်ခုကို ထုတ်ပေးသည်။ Topology ပြောင်းလဲမှုတစ်ခုခု ဖြစ်ပေါ်တိုင်း ၎င်းကို ပြန်လည် run သည်။ Full SPF တစ်ခုကို တွက်ချက်ခြင်းသည် ကုန်ကျစရိတ်ကြီးမားသောကြောင့် router များတွင် throttle စနစ် ထည့်သွင်းထားသည် — ပြောင်းလဲမှု စတင်ဖြစ်ပေါ်ချိန်တွင် တိုတောင်းသော delay အနည်းငယ် စောင့်ဆိုင်းပြီး ပြောင်းလဲမှုများ ဆက်တိုက် ရောက်ရှိနေပါက back-off အချိန်ကို တိုးမြှင့်သွားသည် — သို့မှသာ flapping link တစ်ခုကြောင့် CPU အလွန်အမင်း ဝန်ပိသွားခြင်း မဖြစ်စေရန် ကာကွယ်ပေးနိုင်မည် ဖြစ်သည်။
Area တစ်ခုအတွင်းရှိ Router နှစ်ခုသည် topology နှင့် ပတ်သက်၍ အချက်အလက်ကွဲလွဲပါက မည်သို့ဖြစ်မည်နည်း။
၎င်းတို့သည် မတူညီသော shortest-path tree များကို တွက်ချက်မိကြပြီး packets များကို လမ်းကြောင်းလွဲမှားစွာ ပေးပို့မိနိုင်သည် — ယင်းသည် link-state protocol တစ်ခုတွင် routing loop ဖြစ်ပေါ်စေသည့် နည်းလမ်းဖြစ်သည်။ Area တစ်ခုအတွင်း identical LSDBs ရှိနေရခြင်းသည် ရွေးချယ်စရာ optimization မဟုတ်ဘဲ မဖြစ်မနေ လိုအပ်သော မှန်ကန်မှု စည်းမျဉ်း (correctness requirement) ဖြစ်သည်။ Database checksums များကို နှိုင်းယှဉ်စစ်ဆေးပါ; Mismatch ဖြစ်နေပါက အလေးအနက် ဖြေရှင်းရမည့် ပြဿနာဖြစ်သည်။
Link-state သည် ကြီးမားသော ကွန်ရက်များကို ကိုင်တွယ်နိုင်ပါက Area များကို အဘယ်ကြောင့် ခွဲခြမ်းသတ်မှတ်ရန် လိုအပ်သေးသနည်း။
Link-state သည် အကန့်အသတ်မရှိ အလကား scale မလုပ်နိုင်သောကြောင့် ဖြစ်သည်။ ပိုမိုကြီးမားသော LSDB သည် memory ပိုမိုသုံးစွဲစေပြီး SPF တွက်ချက်မှု ပိုမိုလေးလံစေသည်၊ ထို့အပြင် နေရာတစ်ခုတွင် ပြောင်းလဲမှုဖြစ်တိုင်း နေရာတိုင်းတွင် ပြန်လည်တွက်ချက်ရသည်။ Area များသည် topology အသေးစိတ်ကို ကန့်သတ်ထားပြီး နယ်စပ်များတွင် summaries များကိုသာ ဖလှယ်စေသည်။ တည်ငြိမ်မှုရရှိရန် အသေးစိတ်မြင်ကွင်းအချို့ကို စွန့်လွှတ်လိုက်ခြင်းဖြစ်သည် — Area တစ်ခုအတွင်း link flap ဖြစ်ရုံဖြင့် network တစ်ခုလုံးကို အနှောင့်အယှက် မဖြစ်စေတော့ပေ။
BFD ဆိုသည်မှာ အဘယ်နည်း၊ ကြမ်းတမ်းသော IGP timers များအစား ၎င်းကို အဘယ်ကြောင့် အသုံးပြုသင့်သနည်း။
Bidirectional Forwarding Detection (BFD) သည် အလွန်လျင်မြန်သော hello packets များကို ဖလှယ်ပြီး လမ်းကြောင်းပြတ်တောက်သွားသည့်အခါ ၎င်း၏ client protocols များထံ အချက်ပြအကြောင်းကြားပေးသော ပေါ့ပါးသည့် protocol တစ်ခု ဖြစ်သည်။ OSPF ၏ default dead interval က ၄၀ စက္ကန့် ကြာမြင့်ချိန်တွင် BFD က မီလီစက္ကန့်ပိုင်းအတွင်း ပြတ်တောက်မှုကို သိရှိနိုင်သည်။ OSPF timers များကို လျှော့ချ၍လည်း ရနိုင်သော်လည်း ၎င်းသည် routing process ကို ဝန်ပိစေပြီး network load များချိန်တွင် မပြတ်တောက်ဘဲ ပြတ်တောက်သည်ဟု မှားယွင်းယူဆမှုများ (false positives) ဖြစ်စေနိုင်သည်; BFD သည် သီးသန့်တည်ဆောက်ထားပြီး ကုန်ကျစရိတ်သက်သာကာ OSPF, IS-IS နှင့် BGP တို့ကို တပြိုင်နက်တည်း ဝန်ဆောင်မှု ပေးနိုင်သည်။
OSPF — ဖွဲ့စည်းပုံဆိုင်ရာ¶
OSPF area တိုင်းသည် Area 0 နှင့် အဘယ်ကြောင့် မဖြစ်မနေ ချိတ်ဆက်ရသနည်း။
OSPF တွင် area များ အချင်းချင်းကြား loop ကာကွယ်ရေး ယန္တရား မပါရှိပါ — Inter-area routes များသည် router က နောက်ကွယ်ရှိ topology ကို မမြင်နိုင်သော summaries များဖြစ်ပြီး distance-vector နှင့် သဘောတရားချင်း တူသည်။ Inter-area traffic အားလုံးကို backbone တစ်ခုတည်းမှ ဖြတ်သန်းစေခြင်းဖြင့် algorithm ပေါ် အားကိုးစရာမလိုဘဲ ဖွဲ့စည်းပုံအရ loop မဖြစ်နိုင်အောင် (structurally impossible) ကာကွယ်ပေးထားခြင်း ဖြစ်သည်။
OSPF area အမျိုးအစားများနှင့် တစ်ခုစီက မည်သည့်အရာကို block ပြုလုပ်သည်ကို ဖော်ပြပါ။
Standard သည် မည်သည့်အရာကိုမျှ block မလုပ်ပါ။ Stub သည် type 5 external routes များကို block လုပ်ပြီး default route ဖြင့် အစားထိုးသည်။ Totally stubby သည် types 3, 4 နှင့် 5 များကို block လုပ်ပြီး intra-area နှင့် default route သာ ချန်ထားသည်။ NSSA သည် type 5 ကို block သော်လည်း area အတွင်း ကိုယ်ပိုင် external source ရှိနိုင်ရန် type 7 ကို ခွင့်ပြုသည်။ Totally NSSA သည် 3, 4 နှင့် 5 များကို block သော်လည်း type 7 ကို ဆက်လက်ခွင့်ပြုထားသည်။
Stub area များ ရှိပြီးသားဖြစ်ပါလျက်နှင့် NSSA ကို အဘယ်ကြောင့် တီထွင်ခဲ့ရသနည်း။
Stub area တစ်ခုသည် သတ်မှတ်ချက်အရ external routes များကို သယ်ဆောင်ခွင့် မရှိပါ — သို့သော် အခြားအချက်အားလုံးတွင် stub ပုံစံဖြစ်ပြီး ပြင်ပ routes များကို ပြန်လည်ဖြန့်ဝေပေးမည့် redistributing router ကိုယ်ပိုင်ရှိနေသော area တစ်ခု ဖြစ်နေနိုင်သည်။ NSSA သည် ဤပဋိပက္ခကို type 7 ဖြင့် ဖြေရှင်းပေးသည်- လုပ်ဆောင်ချက်အရ external ဖြစ်သော်လည်း NSSA အတွင်း ခွင့်ပြုထားပြီး ပြင်ပသို့ ထွက်ခွာသည့်အခါ ABR က type 5 သို့ ပြောင်းလဲပေးသည်။
Area 0 သည် Stub area ဖြစ်နိုင်ပါသလား။
မဖြစ်နိုင်ပါ။ Backbone သည် အခြား area တိုင်းအတွက် transit အဖြစ် သယ်ယူပို့ဆောင်ပေးရသောကြောင့် ထိုနေရာတွင် LSA types များကို block လုပ်လိုက်ပါက inter-area routing တစ်ခုလုံး ပျက်စီးသွားမည် ဖြစ်သည်။
Multi-area network တစ်ခုတွင် တွေ့ရမည့် OSPF LSA အမျိုးအစားများကို စာရင်းပြုစုပါ။
Area တစ်ခုစီအတွင်း Type 1 router LSAs နှင့် Type 2 network LSAs; အခြား area များကို ဖော်ပြပေးသော ABRs ထံမှ Type 3 summaries; ASBR ဆီသို့ မည်သို့သွားရမည်ကို ပြသသော Type 4; ASBR ထံမှ Type 5 externals; NSSA အတွင်း Type 5 အစား အသုံးပြုသော Type 7 တို့ ဖြစ်ကြသည်။
OSPF area အဖွဲ့ဝင်ဖြစ်မှုသည် IS-IS နှင့် မည်သို့ ကွဲပြားသနည်း။
OSPF သည် Interface တစ်ခုစီကို area သို့ သတ်မှတ်ပေးသောကြောင့် router တစ်ခုတည်းက area များစွာတွင် interfaces များ ပါဝင်နိုင်သည် — ၎င်းသည် ABR ဖြစ်သည်။ IS-IS သည် Router တစ်ခုလုံးကို area သို့ သတ်မှတ်ပေးသည်; ABR နှင့် တူညီသော အခန်းကဏ္ဍမှာ L1 နှင့် L2 နှစ်မျိုးစလုံးကို run ထားသော router ဖြစ်သည်။
OSPF — လမ်းကြောင်း ရွေးချယ်မှု¶
OSPF သည် prefix တစ်ခုတည်းကို intra-area cost 500 နှင့် inter-area cost 10 အဖြစ် သင်ယူရရှိသည်။ မည်သည့် route က အနိုင်ရမည်နည်း။
Cost အဆငါးဆယ် ပိုမိုများပြားနေသော်လည်း intra-area route က အနိုင်ရပါမည်။ OSPF သည် cost မတိုင်မီ route type ကို ဦးစွာ နှိုင်းယှဉ်သည်- Intra-area၊ ထို့နောက် Inter-area၊ ထို့နောက် E1၊ ထို့နောက် E2 ဖြစ်သည်။ Cost သည် အမျိုးအစားတူ အချင်းချင်းကြားတွင်သာ အနိုင်အရှုံး ခွဲခြားပေးသည်။
E1 နှင့် E2 external routes များအကြား ကွာခြားချက်မှာ အဘယ်နည်း။
E2 သည် ASBR က သတ်မှတ်လိုက်သော ပုံသေ metric အတိုင်း ဆက်လက်တည်ရှိနေပြီး router သည် ၎င်းနှင့် မည်မျှပင် ဝေးကွာပါစေ မပြောင်းလဲပါ၊ ၎င်းသည် default ဖြစ်သည်။ E1 သည် external metric ပေါင်း ASBR ဆီသို့ ရောက်ရှိရန် internal cost ကို ပေါင်းထည့်တွက်ချက်သဖြင့် အကွာအဝေး ဝေးကွာလာသည်နှင့်အမျှ တန်ဖိုး ကြီးထွားလာသည်။
ပြင်ပ destination တစ်ခုတည်းဆီသို့ ထွက်ပေါက် ၂ ခု ရှိနေပြီး traffic သည် ပိုမိုဝေးကွာသော ထွက်ပေါက်ဆီသို့ သွားနေသည်။ အဘယ်ကြောင့်နည်း။
E2 route ဖြစ်နေသောကြောင့် ဖြစ်ရန် သေချာသလောက် ရှိပါသည်။ ပုံသေ metric ဖြစ်နေသောကြောင့် router တိုင်းသည် ထွက်ပေါက်နှစ်ခုစလုံးကို တူညီသော cost အဖြစ် မြင်တွေ့ရပြီး အနီး/အဝေး အကွာအဝေးအစား tiebreaker စည်းမျဉ်းများဖြင့်သာ ရွေးချယ်မိနေခြင်း ဖြစ်သည်။ E1 အဖြစ် ပြန်လည် redistribute လုပ်ပါ၊ ထိုအခါ router တစ်ခုစီသည် ASBR ဆီသို့ မိမိကိုယ်ပိုင် အကွာအဝေးကို ပေါင်းထည့်ကာ ပိုမိုနီးကပ်သော ထွက်ပေါက်ကို သဘာဝကျစွာ ရွေးချယ်သွားပါလိမ့်မည်။
Router တစ်ခုသည် ၎င်း၏ OSPF Router ID ကို မည်သို့ ရွေးချယ်သနည်း။
Manually သတ်မှတ်ထားသော router-id ကို ဦးစွာ ရွေးချယ်သည်; မရှိပါက up ဖြစ်နေသော loopback interfaces များအနက် အမြင့်ဆုံး IP; မရှိပါက up ဖြစ်နေသော physical interfaces များအနက် အမြင့်ဆုံး IP ကို ရွေးချယ်သည်။ အမြဲတမ်း explicitly သတ်မှတ်ပေးပါ — အလိုအလျောက် ရွေးချယ်မှုသည် interface များ ပြောင်းလဲသွားသည့်အခါ ID ပါ ပြောင်းလဲသွားနိုင်ပြီး LSA တိုင်းတွင် ID ပါဝင်နေသဖြင့် area တစ်ခုလုံး re-flooding နှင့် SPF computation ပြန်လုပ်ရစေသည်။ ထို့အပြင် OSPF process ကို restart မလုပ်မချင်း router ID အသစ်သည် အသက်မဝင်သည်ကို သတိပြုပါ။
OSPF — လုပ်ငန်းလည်ပတ်မှုဆိုင်ရာ¶
Router နှစ်ခုသည် ExStart/Exchange အဆင့်တွင် ရပ်တန့်နေပါသည်။ မည်သည့်အရာကို စစ်ဆေးမည်နည်း။
MTU ကို စစ်ဆေးပါမည်။ Database exchange ပြုလုပ်နေစဉ် တစ်ဖက်စီသည် မိမိကိုယ်ပိုင် MTU အရွယ်အစားရှိသော packet များကို ပေးပို့သည်; အကယ်၍ တစ်ဖက်က လက်မခံနိုင်ပါက exchange သည် ဘယ်တော့မှ ပြီးဆုံးမည် မဟုတ်ပါ။ Hellos များသည် သေးငယ်သဖြင့် အဆင်ပြေစွာ ဖြတ်သန်းနိုင်သောကြောင့် ရှုပ်ထွေးစေသည် — Packet သေးသေးလေးများ သွားနိုင်သော်လည်း ကြီးမားသော packet များ မသွားနိုင်ခြင်း ဖြစ်သည်။
LAN ပေါ်ရှိ Router တစ်ခုသည် 2-Way တွင်သာ ရှိနေပြီး Full အဆင့်သို့ မရောက်ပါ။ ပျက်စီးနေခြင်းလား။
ပုံမှန်အားဖြင့် မပျက်စီးပါ။ Multi-access segment ပေါ်တွင် DR နှင့် BDR သာလျှင် Full သို့ ရောက်ရှိကြပြီး; အခြား router အချင်းချင်းကြားတွင်မူ 2-Way အဆင့်၌သာ တမင် ရပ်တန့်နေကြသည်။ ထို router သည် DR သို့မဟုတ် BDR ဖြစ်သင့်ပါလျက်နှင့် မဖြစ်လာသည့် အခြေအနေမျိုးတွင်သာ ပြဿနာရှိခြင်း ဖြစ်သည်။
Default hello နှင့် dead intervals များသည် မည်မျှနည်း။
Broadcast နှင့် point-to-point links များပေါ်တွင် 10 နှင့် 40 စက္ကန့်; NBMA နှင့် point-to-multipoint ပေါ်တွင် 30 နှင့် 120 စက္ကန့် ဖြစ်သည်။ Dead timer သည် ပုံမှန်အားဖြင့် hello ၏ ၄ ဆ ဖြစ်ပြီး neighbours အချင်းချင်း ထပ်တူညီရပါမည်၊ သို့မဟုတ်ပါက adjacency မတည်ဆောက်နိုင်ပါ။
Reference bandwidth ကို အဘယ်ကြောင့် ပြောင်းလဲသင့်သနည်း၊ သတိပြုရမည့် အချက်မှာ အဘယ်နည်း။
Cost သည် reference ÷ interface bandwidth ဖြစ်ပြီး default reference မှာ 100 Mbps ဖြစ်သည်၊ ထို့ကြောင့် 100 Mbps နှင့် အထက်ရှိသော link တိုင်းသည် cost 1 သာ ဖြစ်နေရသည် — 1G နှင့် 100G link တို့သည် မခွဲခြားနိုင်အောင် တူညီနေပေလိမ့်မည်။ Reference ကို မြှင့်တင်ခြင်းဖြင့် ခွဲခြားနိုင်စွမ်းကို ပြန်လည်ရရှိစေသည်။ သတိပြုရမည့်အချက်မှာ Router တိုင်းတွင် တူညီစွာ သတ်မှတ်ပေးရမည် ဖြစ်သည်၊ သို့မဟုတ်ပါက router များအကြား cost ကွဲလွဲပြီး မတူညီသော trees များကို တွက်ချက်မိကြလိမ့်မည်။
OSPF တွင် မည်သည့်နေရာ၌ မည်သည့် command ဖြင့် summarise ပြုလုပ်နိုင်သနည်း။
နယ်စပ်များ (borders) တွင်သာ ပြုလုပ်နိုင်သည်။ ABR ပေါ်တွင် area <id> range ဖြင့် inter-area type 3 routes များကို summarise လုပ်နိုင်သည်; ASBR ပေါ်တွင် summary-address ဖြင့် external routes များကို summarise လုပ်နိုင်သည်။ ၎င်းတို့ကို အပြန်အလှန် လဲလှယ်၍ မရပါ။ Area အတွင်းရှိ router များသည် တူညီသော databases များကို ထိန်းသိမ်းထားရမည်ဖြစ်သောကြောင့် area အလယ်တွင် summarise မပြုလုပ်နိုင်ပါ။
Virtual link ဆိုသည်မှာ အဘယ်နည်း၊ မည်သည့်အချိန်တွင် အသုံးပြုသင့်သနည်း။
Area 0 နှင့် မထိစပ်တော့သော area တစ်ခုကို ချိတ်ဆက်ရန်အတွက် ကြားခံ non-backbone transit area ကို ဖြတ်သန်းဖောက်လုပ်ထားသော tunnel တစ်ခု ဖြစ်ပြီး ကုမ္ပဏီများ ပေါင်းစည်းပြီးနောက် သို့မဟုတ် backbone ပြတ်တောက်သွားသည့်အခါများတွင် အသုံးပြုသည်။ ၎င်းသည် တရားဝင် အရေးပေါ်ပြင်ဆင်မှု ဖြစ်သော်လည်း ရေရှည်ဒီဇိုင်း မဟုတ်ပါ- နုနယ်လွယ်ပြီး transit area ၏ ကျန်းမာကြံ့ခိုင်မှုအပေါ် မှီခိုနေရကာ ဖွဲ့စည်းပုံဆိုင်ရာ ပြဿနာကို ဖုံးကွယ်ထားတတ်သည်။ အကယ်၍ virtual link ကို အဓိက အားထားနေရပါက ထို area ကို backbone ဆီသို့ တိုက်ရိုက် ပြန်လည်ချိတ်ဆက်ပေးပါ။
Passive-interface သည် အဘယ်အရာကို လုပ်ဆောင်ပေးသနည်း၊ မည်သည့်နေရာတွင် အသုံးပြုသင့်သနည်း။
ထို interface ပေါ်တွင် hellos များ ထုတ်လွှင့်ခြင်းကို ပိတ်ပင်ထားစဉ် ထို interface ၏ network ကို OSPF ထဲသို့ ကြေညာပေးသည်။ OSPF neighbour မရှိသော မည်သည့် interface တွင်မဆို အသုံးပြုသင့်သည် — User subnets များ၊ loopbacks များ။ ၎င်းသည် မလိုအပ်သော adjacency ကြိုးပမ်းမှုများကို ဖယ်ရှားပေးပြီး လုံခြုံရေး တိုက်ခိုက်ခံရနိုင်သည့် မျက်နှာပြင်ကို လျှော့ချပေးသည်။
Routed link ပေါ်တွင် Broadcast ထက် Point-to-Point ကို အဘယ်ကြောင့် ပိုမိုဦးစားပေးသင့်သနည်း။
Router နှစ်ခုတည်းသာ ရှိသဖြင့် ရွေးကောက်စရာ ဘာမှမရှိသောကြောင့် DR election သည် အကျိုးမရှိဘဲ စတင်ချိန်နှောင့်နှေးမှုကိုသာ ဖြစ်စေသည်။ Point-to-point သည် adjacency ပိုမိုမြန်ဆန်စွာ ဖွဲ့စည်းစေပြီး type-2 network LSA မလိုတော့သဖြင့် database ကို ပိုမိုရှင်းလင်းစေသည်။
OSPFv3¶
OSPFv2 နှင့် OSPFv3 အကြား အဓိက ကွာခြားချက်များမှာ အဘယ်နည်း။
v3 သည် subnet အလိုက်မဟုတ်ဘဲ link အလိုက် အလုပ်လုပ်သောကြောင့် addressing သည် adjacency ကို မဟန့်တားတော့ပါ; Neighbours များသည် link-local fe80:: address များပေါ်တွင် peer ဖွဲ့ကြသည်; Topology နှင့် prefixes များ သီးခြားသွားလာနိုင်ရန် addressing ကို router နှင့် network LSAs များထဲမှ သီးခြားခွဲထုတ်ထားသည်; ထို့အပြင် built-in authentication အစား IPsec ကို အသုံးပြုသည်။ Area model နှင့် algorithm မှာမူ ပြောင်းလဲခြင်း မရှိပါ။
IPv6-only OSPFv3 network တစ်ခုရှိ Router IDs များနှင့် ပတ်သက်၍ သတိပြုရမည့် အချက်မှာ အဘယ်နည်း။
၎င်းတို့သည် dotted-quad ဖြင့် ရေးသားရသော 32-bit အတိုင်း ဆက်လက်တည်ရှိနေခြင်း ဖြစ်သည်။ IPv4 address လုံးဝ မရှိသောအခါ ID အဖြစ် ယူစရာ မရှိတော့သဖြင့် မဖြစ်မနေ manual configure ပြုလုပ်ပေးရမည်။ Router ID မရှိခြင်းသည် OSPFv3 ဘာသံမှမမြည်ဘဲ စတင်မလည်ပတ်နိုင်ခြင်း၏ အဖြစ်များသော အကြောင်းရင်း ဖြစ်သည်။
OSPF တွင် Dual-stack အသုံးပြုခြင်း၏ ကုန်ကျစရိတ်မှာ အဘယ်နည်း။
Adjacencies သီးခြား၊ databases သီးခြားနှင့် SPF computation သီးခြားစီရှိသော သီးခြား protocols နှစ်ခု (v2 နှင့် v3) ကို တပြိုင်နက် run ရခြင်း ဖြစ်သည်။ ၎င်းတို့သည် လမ်းကြောင်းကွဲလွဲနိုင်သောကြောင့် တူညီသော links များပေါ်တွင် IPv4 နှင့် IPv6 တို့ မတူညီသော လမ်းကြောင်းများမှ သွားနေနိုင်ပြီး troubleshooting ပြုလုပ်တိုင်း နှစ်ခါစီ လုပ်ဆောင်ရမည် ဖြစ်သည်။
IS-IS¶
Service provider များသည် IS-IS ကို အဘယ်ကြောင့် ပိုမိုနှစ်သက်ကြသနည်း။
၎င်းသည် Layer 2 ပေါ်တွင် တိုက်ရိုက် run သောကြောင့် link ပြင်ပမှ လှမ်းမရောက်ရှိနိုင်သလို တိုက်ခိုက်၍လည်း မရနိုင်ပါ။ TLV encoding ကြောင့် စွမ်းဆောင်ရည်အသစ်များ (IPv6, segment routing, TE) ကို protocol တစ်ခုလုံး အသစ်မရေးရဘဲ extensions အဖြစ် လက်ခံနိုင်သည်။ ထို့အပြင် L2 backbone သည် နံပါတ်တပ်ထားသော area မဟုတ်ဘဲ routers ကွင်းဆက်ဖြစ်သဖြင့် ကွန်ရက်ချဲ့ထွင်ခြင်းနှင့် ပေါင်းစည်းခြင်းများတွင် အနှောင့်အယှက် အနည်းဆုံး ဖြစ်စေသည်။
NET 49.0001.0000.0000.0001.00 ကို ခွဲခြမ်းစိတ်ဖြာပြပါ။
49 သည် RFC 1918 နှင့် ညီမျှသော OSI private AFI ဖြစ်သည်။ 0001 သည် area ဖြစ်ပြီး router တစ်ခုလုံးနှင့် သက်ဆိုင်သည်။ 0000.0000.0001 သည် router ကို အမှန်တကယ် ဖော်ပြပေးသော ခြောက် bytes အရွယ်အစား domain-wide unique system ID ဖြစ်သည်။ အနောက်ဆုံးရှိ 00 သည် router အတွက် အမြဲတမ်း 00 ဖြစ်သော NSEL ဖြစ်သည်။
ATT bit ဆိုသည်မှာ အဘယ်နည်း၊ ၎င်းက မည်သည့်ပြဿနာကို ဖြစ်ပေါ်စေသနည်း။
L1/L2 router သည် မိမိ area မှ ထွက်ခွာနိုင်သော ထွက်ပေါက်အဖြစ် မိမိကိုယ်ကို ကြေညာရန် ၎င်း၏ L1 LSP ထဲတွင် attached bit ကို သတ်မှတ်သည်။ L1 router များသည် ထိုသို့သော အနီးဆုံး router ဆီသို့ default route အတိုင်း သွားကြသည်။ ပြဿနာမှာ အနီးဆုံးသည် အမြဲတမ်း အကောင်းဆုံး မဟုတ်နိုင်ခြင်းဖြစ်သည် — အကယ်၍ destination သည် အခြား L1/L2 router တစ်ခု၏ နောက်ကွယ်တွင် ရှိနေပါက traffic သည် အနီးဆုံး ထွက်ပေါက်ဆီ အရင်သွားပြီးမှ backbone ကို ဖြတ်သန်းကာ ပြန်သွားရမည် ဖြစ်သည်။
Route leaking က ထိုပြဿနာကို မည်သို့ ဖြေရှင်းပေးသနည်း၊ အရာအားလုံးကို အဘယ်ကြောင့် leak မလုပ်သင့်သနည်း။
L1/L2 router သည် သတ်မှတ်ထားသော L2 prefixes များကို L1 ထဲသို့ leak ပြုလုပ်ပေးသဖြင့် L1 router များသည် default route သာမက အစစ်အမှန် destinations များကို မြင်တွေ့ရပြီး မှန်ကန်သော ထွက်ပေါက်ကို တိုက်ရိုက် ရွေးချယ်နိုင်သည်။ အရာအားလုံးကို leak လုပ်ပါက level ခွဲခြားထားခြင်း၏ ရည်ရွယ်ချက် ပျက်စီးသွားမည်ဖြစ်သည် — ထွက်ပေါက်ရွေးချယ်မှု အမှန်တကယ် အရေးပါသော နေရာများကိုသာ leak လုပ်သင့်သည်။
Overload bit ကို မည်သည့်အတွက် အသုံးပြုသနည်း။
"ငါ့ဆီ ရောက်နိုင်တယ်၊ ဒါပေမယ့် transit traffic တွေကို ငါ့ကို ဖြတ်မပို့ပါနဲ့" ဟု ကြေညာခြင်း ဖြစ်သည်။ တိုက်ရိုက်ချိတ်ဆက်ထားသော destinations များ အလုပ်လုပ်နေဆဲဖြစ်သော်လည်း အခြားနေရာများဆီသို့ သွားရန် ထို router ကို လမ်းကြောင်းအဖြစ် မသုံးတော့ပေ။ BGP table မပြည့်စုံသေးသော router က transit traffic များကို black-hole မဖြစ်စေရန် စက်စဖွင့်ချိန်တွင် အလိုအလျောက် သတ်မှတ်လေ့ရှိပြီး၊ ပြုပြင်ထိန်းသိမ်းမှု မတိုင်မီ traffic များကို လမ်းကြောင်းလွှဲရန် manual သတ်မှတ်လေ့ရှိသည် — Interface များကို shut ချလိုက်ခြင်းထက် များစွာ ပိုမိုသန့်ရှင်းသည်။
Metric-style wide သည် ဂဏန်းပမာဏ ပိုမိုကြီးမားလာခြင်းအပြင် အဘယ်ကြောင့် အရေးပါသနည်း။
Narrow metrics သည် link တစ်ခုလျှင် 63 သာ ကန့်သတ်ထားသဖြင့် ခေတ်သစ် bandwidth ကွာခြားချက်များကို မဖော်ပြနိုင်ပါ။ Wide metrics များကို အပိုဆောင်းအချက်အလက်များ ထည့်သွင်းနိုင်သော TLVs များဖြင့် သယ်ဆောင်ထားသဖြင့် Segment Routing နှင့် Traffic Engineering အတွက် မဖြစ်မနေ လိုအပ်သော ကြိုတင်သတ်မှတ်ချက် ဖြစ်လာသည်။ ထို့အပြင် Domain တစ်ခုတည်းတွင် metric စတိုင်များ ရောနှောခြင်းသည် router များအကြား cost မကိုက်ညီမှုများကို ဖြစ်ပေါ်စေသည်။
DIS သည် OSPF ၏ DR နှင့် မည်သို့ ကွဲပြားသနည်း။
Backup မရှိပါ — ပျက်စီးသွားပါက ရွေးကောက်ပွဲအသစ် ချက်ချင်း ပြန်လုပ်ပြီး IS-IS က ၎င်းကို လုံလောက်စွာ မြန်ဆန်သည်ဟု သတ်မှတ်သည် — ထို့ပြင် OSPF ၏ DR က မတည်မငြိမ်မဖြစ်စေရန် ရာထူးကို ဆက်လက်ထိန်းသိမ်းထားချိန်တွင် DIS ကိုမူ ဦးစားပေး priority ပိုမြင့်သော router အသစ်က အစားထိုး သိမ်းပိုက်နိုင်သည် (pre-empted)။
ဒီဇိုင်းနှင့် နှိုင်းယှဉ်ချက်များ¶
Provider backbone အသစ်တစ်ခု၊ Segment Routing သုံးရန် စီစဉ်ထားသည်။ မည်သည့် IGP ကို သုံးမည်နည်း။
IS-IS ကို ရွေးချယ်ပါမည်။ SR extensions များသည် TLVs များဖြစ်ပြီး IS-IS က protocol အပြောင်းအလဲမလိုဘဲ လက်ခံနိုင်သည် — SR သည် ထိုနေရာသို့ အရင်ဆုံးနှင့် အဆင်ပြေဆုံး ရောက်ရှိခဲ့သည်။ L2 backbone သည် ချဲ့ထွင်ရန် ပိုမိုလွယ်ကူပြီး IP မဟုတ်သောကြောင့် တိုက်ခိုက်ခံရနိုင်ခြေ နည်းသည်။ OSPF ကလည်း SR ကို ထောက်ပံ့သော်လည်း ဤသည်မှာ ခိုင်မာသော ဦးစားပေး ရွေးချယ်မှု ဖြစ်သည်။
တစ်စုံတစ်ယောက်က သပ်ရပ်လှပမှုအတွက် ကောင်းမွန်စွာ အလုပ်လုပ်နေသော OSPF network ကို IS-IS သို့ ပြောင်းရန် အဆိုပြုလာသည်။
၎င်းက မည်သည့် လက်တွေ့ပြဿနာကို ဖြေရှင်းပေးမည်နည်းဟု မေးမြန်းပါမည်။ ခိုင်လုံသော တွန်းအားမရှိဘဲ (Segment Routing၊ backbone ကြီးထွားမှု၊ သီးခြားလုံခြုံရေး လိုအပ်ချက် စသည်) ပြောင်းလဲပါက migration ကုန်ကျစရိတ်နှင့် team က ကျွမ်းကျင်မှုနည်းသော protocol ကို ကိုင်တွယ်ရသည့် စွန့်စားရမှုတို့သည် ဒီဇိုင်းအကျိုးကျေးဇူးထက် ပိုမိုဆိုးရွားပါလိမ့်မည်။ ဖိအားများကြားတွင် အင်ဂျင်နီယာများ troubleshoot လုပ်နိုင်သော protocol သည် နည်းပညာအရ အနည်းငယ်သာလွန်သော်လည်း မကိုင်တွယ်နိုင်သော protocol ထက် များစွာ ပိုမိုတန်ဖိုးရှိပါသည်။
IS-IS တွင် Dual-stack သည် အဘယ်ကြောင့် ပိုမိုရိုးရှင်းသနည်း။
IPv6 သည် instance တစ်ခုတည်းအတွင်း TLV တစ်ခုအဖြစ် ရှိနေသည် — Protocol တစ်ခု၊ adjacency တစ်ခု၊ database တစ်ခု။ OSPF တွင်မူ v2 နှင့်အတူ v3 ကိုပါ run ရသည်- လမ်းကြောင်းကွဲလွဲနိုင်သော၊ သီးခြားစီ စစ်ဆေးရမည့် protocol နှစ်ခု ဖြစ်သည်။
Single-topology IS-IS dual-stack သည် မည်သည့်အချိန်တွင် မှားယွင်းသနည်း။
Link တိုင်းပေါ်တွင် IPv4 နှင့် IPv6 နှစ်မျိုးစလုံး မရှိသည့် အခြေအနေတိုင်းတွင် ဖြစ်သည်။ Single topology သည် families နှစ်ခုစလုံးအတွက် tree တစ်ခုတည်းကိုသာ တွက်ချက်သဖြင့် IPv6 traffic သည် IPv4 သာရှိသော link ပေါ်သို့ ရောက်ရှိသွားကာ black-hole ဖြစ်သွားနိုင်သည်။ Multi-topology က family တစ်ခုစီအတွက် သီးခြား tree တွက်ချက်ပေးသဖြင့် incremental rollout ကာလအတွင်း အလုံခြုံဆုံး ရွေးချယ်မှု ဖြစ်သည်။
VXLAN-EVPN fabric အတွက် IGP ရွေးချယ်မှုသည် အရေးပါပါသလား။
မပြောပလောက်ပါ။ Underlay သည် loopback တိုင်းကို ရောက်ရှိနိုင်ရန်သာ လိုအပ်ပြီး ပုံမှန်အားဖြင့် point-to-point links များပါဝင်သော flat area တစ်ခုသာ ဖြစ်သည်။ Protocol နှစ်ခုစလုံးက တူညီစွာ ကောင်းမွန်စွာ လုပ်ဆောင်နိုင်သောကြောင့် လုပ်ငန်းခွင် ရင်းနှီးကျွမ်းဝင်မှုအပေါ်သာ မူတည်ပါသည် — သို့မဟုတ်ပါက IGP ကို လုံးဝချန်လှပ်ပြီး underlay အဖြစ် eBGP ကို အသုံးပြုနိုင်သည်။
IGP နှင့် တိုက်ရိုက် မသက်ဆိုင်သော်လည်း အရေးကြီးဆုံး ပြဿနာ¶
MPLS တွင် labels များ မပေါ်လာပါ၊ BGP peer မဖွဲ့နိုင်ပါ၊ VXLAN tunnels များ မတည်ဆောက်နိုင်ပါ။ မည်သည့်နေရာကို ကြည့်မည်နည်း။
IGP ကို စစ်ဆေးပါမည်။ ဤလက္ခဏာ ၃ ခုစလုံးသည် မတူညီသော အသွင်သဏ္ဌာန်များ ဆင်မြန်းထားသည့် အခြေခံ ချို့ယွင်းချက် တစ်ခုတည်းသာ ဖြစ်သည်- Loopbacks များသည် အချင်းချင်း မရောက်ရှိနိုင်ခြင်း ဖြစ်သည်။ LDP သည် IGP မှ ရရှိသော prefixes များနှင့် labels များကို တွဲချိတ်သည်၊ iBGP သည် loopbacks များပေါ်တွင် peer ဖွဲ့သည်၊ VTEPs များသည် loopbacks များမှတစ်ဆင့် tunnels တည်ဆောက်သည်။
ဖြစ်လေ့ရှိသော အကြောင်းရင်းမှာ Interface တွင် IP address သတ်မှတ်ထားသော်လည်း IGP ထဲသို့ ထည့်သွင်းသတ်မှတ်ရန် ကျန်ခဲ့ခြင်း ဖြစ်သည် — အများအားဖြင့် Loopback interface တွင် ip ospf area statement ကျန်ခဲ့ခြင်း ဖြစ်သည်။ Interface တစ်ခုတွင် address သတ်မှတ်ပေးခြင်းနှင့် ၎င်းကို advertise လုပ်ခြင်းတို့သည် သီးခြားစီ ဖြစ်ကြသည်။
Overlay ကို မထိမီ Loopback-to-loopback အချင်းချင်း ရောက်ရှိနိုင်စွမ်းကို အရင်ဆုံး သက်သေပြပါ။ စက္ကန့် ၃၀ သာ ကြာမြင့်ပြီး လက်တွေ့တွင်လည်း ချို့ယွင်းချက် အမှန်တကယ် ရှိနေလေ့ရှိသော နေရာ ဖြစ်သည်။
FAANG / Hyper-Scale အမြင်¶
Data center တစ်ခုတွင် ဆာဗာပေါင်း ၅၀,၀၀၀ ရှိပါက OSPF အစား နေရာတိုင်းတွင် eBGP ကို အဘယ်ကြောင့် အသုံးပြုနိုင်သနည်း။
ဧရာမ scale ကြီးမားသည့်အခါ link-state protocol များသည် blast radius ကြောင့် ပြိုလဲကျရှုံးသွားသည်။ Link flap ဖြစ်တိုင်း LSA/LSP တစ်ခု ထုတ်ပေးပြီး area အတွင်းရှိ router တိုင်းဆီသို့ flood လုပ်ရကာ router တိုင်း SPF ပြန် run ရသည်။ Switch ပေါင်း ၁,၀၀၀ ပါဝင်သော Clos fabric တွင် links များသည် အမြဲတစေ flap ဖြစ်နေတတ်သည်။ eBGP သည် distance-vector protocol ဖြစ်သဖြင့် direct neighbors များဆီသို့သာ updates ပို့ပြီး မိမိ၏ အကောင်းဆုံး (best) လမ်းကြောင်းကိုသာ ကြေညာသောကြောင့် topology မတည်ငြိမ်မှုများအတွက် firewall တစ်ခုသဖွယ် လုပ်ဆောင်ပေးသည်။ ထို့ပြင် BGP သည် OSPF metrics ထက် traffic engineering အတွက် များစွာ သာလွန်သော policy control (route maps, communities) ကို ပေးစွမ်းနိုင်သည်။
ဗဟိုချုပ်ကိုင်မှု SDN controller နှင့် IS-IS ကဲ့သို့ distributed protocol အကြား အပေးအယူကို ရှင်းပြပါ။
Distributed protocol (IS-IS) သည် router တိုင်းအား ကိုယ်ပိုင်လွတ်လပ်စွာ ဆုံးဖြတ်ချက် ချခွင့်ပေးသည်။ ၎င်းသည် controller ချို့ယွင်းမှုဒဏ်ကို ခံနိုင်ရည်ရှိသော်လည်း convergence ဖြစ်စဉ်အတွင်း သီးခြား မမြင်ရသော ကန်းကွက်များနှင့် micro-loops များ ဖြစ်ပေါ်စေနိုင်ပြီး လမ်းကြောင်းအားလုံးပေါ်တွင် traffic ကို တစ်ကမ္ဘာလုံးအတိုင်းအတာဖြင့် အကောင်းဆုံး ပိုမိုကောင်းမွန်အောင် လုပ်ဆောင်ရန် ရုန်းကန်ရသည်။ Centralized controller (Google ၏ B4 ကဲ့သို့သော SDN) တွင်မူ လိုအပ်ချက်များနှင့် capacities အားလုံး၏ global view အပြည့်အစုံရှိသဖြင့် ပြီးပြည့်စုံသော traffic engineering နှင့် bin-packing ကို လုပ်ဆောင်နိုင်သည်။ သို့သော် ၎င်းသည် single point of failure (controller/control network) ကို ဖြစ်ပေါ်စေပြီး forwarding tables များကို သတ်မှတ်ရာတွင် latency အနည်းငယ် ရှိနိုင်သည်။
Hyper-scaler များသည် Core network တွင် state မတည်ဆောက်ဘဲ Segment Routing (SR) အတွက် IS-IS ကို မည်သို့ အသုံးပြုကြသနည်း။
IS-IS ကို ၎င်း၏ ချဲ့ထွင်နိုင်သော TLVs များ အသုံးပြု၍ node labels (SIDs) များကို ဖြန့်ဝေပေးရန် သီးသန့် အသုံးပြုသည်။ Router များသည် label တစ်ခုကို IS-IS next-hop နှင့် ရိုးရှင်းစွာ တွဲချိတ်ပေးရုံသာ ဖြစ်သည်။ SDN controller က ညွှန်ကြားထားသော ingress router သည် packet ပေါ်တွင် ဤ labels stack တစ်ခုကို ထည့်သွင်း (push) လိုက်သည်။ Core router များသည် သီးခြား flow တစ်ခုစီအတွက် state ထိန်းသိမ်းရန်၊ RSVP tunnels သို့မဟုတ် LDP bindings များ ပြုလုပ်ရန် မလိုဘဲ ထိပ်ဆုံးရှိ label ပေါ် အခြေခံ၍ packet ကို forward ပေးရုံသာ ဖြစ်သည်။