မာတိကာ သို့ သွားရန်

၂ · OSPF

OSPF သည် Enterprise အဖွဲ့အစည်း အများစု အသုံးပြုကြသော IGP ဖြစ်ပြီး၊ ဤသင်ရိုးညွှန်းတမ်း၏ နောက်ပိုင်း phase တိုင်းကလည်း ၎င်းအပေါ်တွင် တိတ်တဆိတ် အမှီပြုထားကြသည်။ ဤစာမျက်နှာတွင် လက်တွေ့လုပ်ငန်းခွင်၌ အမှန်တကယ် အရေးပါသောအချက်များနှင့် IPv6 အတွက် OSPFv3 မည်သို့ ကွဲပြားသွားသည်ကို လေ့လာသွားပါမည်။

အောက်ဖော်ပြပါ command ထုတ်ပြန်ချက်များကို မှတ်ဉာဏ်ထဲမှ ရေးသားထားခြင်း မဟုတ်ဘဲ တိုက်ရိုက်လည်ပတ်နေသော three-router cEOS fabric ပေါ်မှ လက်တွေ့ဖမ်းယူထားခြင်း ဖြစ်သည်။


Area များ- စနစ်တကျ ဖွဲ့စည်းတည်ဆောက်မှု အခြေခံ

OSPF သည် ကွန်ရက်တစ်ခုကို areas များအဖြစ် ပိုင်းခြားထားပြီး area တိုင်းသည် backbone ဖြစ်သော area 0 နှင့် တိုက်ရိုက် ထိစပ်ချိတ်ဆက်နေရပါမည်။ Backbone မဟုတ်သော area နှစ်ခုအကြားရှိ traffic များသည် area 0 ကို အမြဲတစေ ဖြတ်သန်းသွားလာရသည်။

ဤကန့်သတ်ချက်သည် မလိုအပ်ဘဲ တင်းကျပ်လွန်းသည်ဟု ထင်ရနိုင်သော်လည်း ၎င်းက မည်သည့်အရာကို ကာကွယ်ပေးသည်ကို သိရှိပါက သဘောပေါက်သွားပါလိမ့်မည် — မဖြစ်မနေ လိုအပ်သော ဗဟို hub တစ်ခု မရှိပါက area အချင်းချင်းကြား routing ပြုလုပ်ရာတွင် loop ကာကွယ်ရေး ယန္တရား လိုအပ်လာမည် ဖြစ်ပြီး OSPF တွင် ယင်းစနစ်ကို ရည်ရွယ်ချက်ရှိရှိ ထည့်သွင်းမထားပေ။ တင်းကျပ်သော hub-and-spoke ပုံစံသည်သာ loop မဖြစ်အောင် ကာကွယ်ပေးထားခြင်း (is the loop prevention) ဖြစ်သည်။

Router များကို ၎င်းတို့ တည်ရှိရာ နေရာပေါ်မူတည်၍ အောက်ပါအတိုင်း ခေါ်ဆိုကြသည် -

အခန်းကဏ္ဍ (Role) တည်နေရာ (Position)
Internal Interface အားလုံးသည် area တစ်ခုတည်းအတွင်း၌သာ ရှိသည်
ABR (Area Border Router) Interface များသည် area နှစ်ခု သို့မဟုတ် နှစ်ခုထက်ပို၍ တည်ရှိသည် — အနည်းဆုံးတစ်ခုမှာ area 0 ဖြစ်ရမည်
ASBR (AS Boundary Router) ပြင်ပ routes များကို OSPF ထဲသို့ inject ပြုလုပ်ထည့်သွင်းပေးသည်

Area အဖွဲ့ဝင်ဖြစ်မှုသည် Interface အလိုက် ဖြစ်သည်

Router တစ်ခုလုံးသည် area တစ်ခုထဲတွင် ရှိနေခြင်း မဟုတ်ဘဲ ၎င်း၏ interface တစ်ခုစီ အလိုက် area ခွဲခြားသတ်မှတ်ခြင်း ဖြစ်သည်။ ၎င်းသည် router တစ်ခုလုံး level တစ်ခုစီအလိုက် သတ်မှတ်ခံရသော IS-IS နှင့် လက်တွေ့ကွာခြားသည့် အချက်ဖြစ်ပြီး အင်တာဗျူးများတွင် မေးလေ့ရှိသော မေးခွန်းတစ်ခု ဖြစ်သည်။

အောက်တွင် single-area fabric တစ်ခု၏ ဥပမာကို ဖော်ပြထားပါသည် — Interface တစ်ခုစီတွင် Area 0.0.0.0 ဟု ဖော်ပြထားသည်ကို သတိပြုပါ -

   Interface          Instance VRF        Area            IP Address         Cost  State      Nbrs
   Et2                1        default    0.0.0.0         10.1.2.1/24        10    P2P        1
   Et1                1        default    0.0.0.0         10.1.1.1/24        10    P2P        1
   Lo0                1        default    0.0.0.0         1.1.1.1/32         10    DR         0

Area အမျိုးအစားများ- မြင်ကွင်းနှင့် အရွယ်အစားကို အပေးအယူပြုလုပ်ခြင်း

Area တိုင်းသည် ကွန်ရက်တစ်ခုလုံး၏ အပြည့်အစုံကို သိရှိရန် မလိုအပ်ပါ။ အကယ်၍ area တစ်ခုတွင် အပြင်ထွက်ပေါက် တစ်ခုတည်းသာ ရှိပါက ထို area အတွင်းရှိ router များအား ကမ္ဘာပေါ်ရှိ external route တိုင်းကို အသိပေးနေခြင်းသည် memory ဖြုန်းတီးရာ ရောက်ပါသည် — အကြောင်းမှာ ၎င်း routes အားလုံးသည် အဆုံးတွင် ထိုထွက်ပေါက်တစ်ခုတည်းဆီသို့သာ သွားကြရမည် ဖြစ်သောကြောင့် ဖြစ်သည်။

ထို့ကြောင့် OSPF တွင် ABR ထံ၌ LSA types များကို ပိတ်ဆို့ (block) ထားပြီး default route ဖြင့် အစားထိုးခွင့် ပြုထားသည်။ Area type တစ်ခုစီသည် block ပြုလုပ်နိုင်သော အတိုင်းအတာ အနည်းငယ်စီ ကွာခြားသည် -

Area type ပိတ်ဆို့မှု (Blocks) လက်ခံရရှိနေဆဲ (Still gets) အသုံးပြုသင့်သည့် အခြေအနေ
Standard ဘာမှမပိတ်ဆို့ပါ အရာအားလုံး Backbone သို့မဟုတ် အသေးစိတ်အချက်အလက် လိုအပ်သော areas များ
Stub Type 5 (external) Types 1–4 + default ထွက်ပေါက်တစ်ခုတည်းရှိပြီး external source မရှိသော branch ရုံးခွဲများ
Totally stubby Types 3, 4, 5 Types 1–2 + default အထက်ပါအတိုင်းဖြစ်ပြီး inter-area အသေးစိတ်ကိုပါ မလိုအပ်သည့်အခါ
NSSA Type 5 Types 1–4 + type 7 မိမိကိုယ်ပိုင် external source ရှိနေသော stub area ဖြစ်သည့်အခါ
Totally NSSA Types 3, 4, 5 Types 1–2 + type 7 + default Inter-area အသေးစိတ်ကိုပါ မလိုအပ်သော NSSA ဖြစ်သည့်အခါ

လူအများစု သတိမမူမိသော အချက်မှာ NSSA အဘယ်ကြောင့် ပေါ်ပေါက်လာသနည်း ဟူသည့် အချက်ဖြစ်သည်။ Stub area တစ်ခုသည် ပြင်ပ external routes များကို လက်မခံနိုင်ပါ — ယင်းမှာ ၎င်း၏ အဓိပ္ပာယ်သတ်မှတ်ချက် ဖြစ်သည်။ သို့သော် stub ကဲ့သို့သော area တစ်ခုအတွင်း ပြင်ပ routes များကို ပြန်လည်ဖြန့်ဝေပေးမည့် redistributing router ကိုယ်ပိုင်ရှိနေပါက မည်သို့လုပ်မည်နည်း။ ၎င်းကို standard area အဖြစ် ပြောင်းလဲလိုက်ပါက stub ၏ အကျိုးကျေးဇူးများ ဆုံးရှုံးသွားပါလိမ့်မည်။

NSSA သည် ယင်းပြဿနာကို type 7 ဖြင့် ဖြေရှင်းပေးသည် — လုပ်ဆောင်ချက်အရ external route နှင့် အတူတူပင်ဖြစ်သော်လည်း NSSA အတွင်း သွားလာခွင့်ပြုထားသည်။ ထို route သည် ABR မှတစ်ဆင့် ပြင်ပသို့ ထွက်ခွာသည့်အခါ ABR က type 7 မှ type 5 သို့ ပြောင်းလဲပေးလိုက်သည်။ အချက်အလက်မှာ အတူတူပင်ဖြစ်သော်လည်း area ၏ စည်းမျဉ်းအရ type-5 wrapper ကို ခွင့်မပြုထားသောကြောင့် wrapper အိတ်ခွံကိုသာ ပြောင်းလဲပေးခြင်း ဖြစ်သည်။

လူအများ မှားယွင်းတတ်သော စည်းမျဉ်း ၂ ခု

Area အတွင်းရှိ router တိုင်းသည် တူညီသော area type ကို လက်ခံသဘောတူရပါမည်။ ၎င်းကို hello packet အတွင်း ညှိနှိုင်းသောကြောင့် mismatch ဖြစ်ပါက adjacency မတည်ဆောက်နိုင်ပါ — လက္ခဏာမှာ routing အမှားအယွင်း မဟုတ်ဘဲ neighbour လုံးဝ မပေါ်လာခြင်း ဖြစ်သည်။

Area 0 သည် မည်သည့် stub အမျိုးအစားမျှ ဖြစ်ခွင့်မရှိပါ။ ၎င်းသည် အရာအားလုံးအတွက် transit အဖြစ် သယ်ယူပို့ဆောင်ပေးရသောကြောင့် Area 0 တွင် LSAs များကို block လုပ်လိုက်ပါက inter-area routing တစ်ခုလုံး ပျက်စီးသွားမည် ဖြစ်သည်။


လမ်းကြောင်း ဦးစားပေးမှု အဆင့်ဆင့် (Path preference: which route actually wins)

OSPF သည် prefix တစ်ခုတည်းကို တစ်ကြိမ်ထက်မက သင်ယူရရှိသည့်အခါ cost များကို ဦးစွာ မနှိုင်းယှဉ်ပါ။ Route type ကို အရင် နှိုင်းယှဉ်ပြီး တူညီသော type အတွင်း၌သာ cost ဖြင့် အနိုင်အရှုံး ဆုံးဖြတ်သည် -

intra-area  (O)      ← ကုန်ကျစရိတ် မည်မျှပင်များစေကာမူ အမြဲတမ်း အနိုင်ရသည်
inter-area  (O IA)
external E1 (O E1)
external E2 (O E2)   ← အမြဲတမ်း အရှုံးပေးရသည်

Cost များသော intra-area route သည် cost နည်းသော inter-area route ကို အနိုင်ရသည်။ Cost သည် အမျိုးအစားတစ်ခု အတွင်းတွင်သာ အနိုင်အရှုံးခွဲခြားပေးခြင်းဖြစ်ပြီး အမျိုးအစား အချင်းချင်းကြားတွင် မယှဉ်ပြိုင်နိုင်ပါ — ၎င်းသည် စာမေးပွဲများတွင် အလွန်ထောင်ချောက်ဆင်လေ့ရှိသော အချက်ဖြစ်သည်။

E1 နှင့် E2 နှိုင်းယှဉ်ချက် — အမြဲမေးလေ့ရှိသော မေးခွန်း

နှစ်မျိုးစလုံးသည် OSPF ပြင်ပမှ redistribute ပြုလုပ်ထားသော routes များ ဖြစ်ကြသည်။ ကွာခြားချက်မှာ လမ်းခရီးတစ်လျှောက် သွားလာစဉ် metric တန်ဖိုး မည်သို့ ပြောင်းလဲသွားသနည်းဟူသည့် အချက်ဖြစ်သည် -

  • E2 — ASBR က သတ်မှတ်လိုက်သော cost သည် သင်နှင့် မည်မျှပင် ဝေးကွာပါစေ ပုံသေ (fixed) အတိုင်း ဆက်လက်တည်ရှိနေသည်။ ၎င်းသည် default ဖြစ်သည်။
  • E1 — Cost သည် external metric ပေါင်း ASBR ဆီသို့ ရောက်ရှိရန် internal cost ဖြစ်သောကြောင့် အကွာအဝေး ဝေးကွာလာသည်နှင့်အမျှ တန်ဖိုး မြင့်တက်လာသည်။

ထို့ကြောင့် ပြင်ပ destination တစ်ခုတည်းဆီသို့ ထွက်ပေါက် ၂ ခု ရှိနေပါက E2 သည် ၎င်းတို့ကို ခွဲခြားသိမြင်နိုင်စွမ်း မရှိပါ — Router တိုင်းသည် တူညီသော cost ကိုသာ မြင်တွေ့ရသဖြင့် အနီး/အဝေး အကွာအဝေးကို မကြည့်ဘဲ tiebreaker စည်းမျဉ်းများဖြင့်သာ ရွေးချယ်သွားမည် ဖြစ်သည်။ E1 ကမူ ခွဲခြားနိုင်ပါသည်၊ အကြောင်းမှာ router တစ်ခုစီသည် ASBR ဆီသို့ မိမိကိုယ်ပိုင် အကွာအဝေး cost ကို ပေါင်းထည့်တွက်ချက်သောကြောင့် ဖြစ်သည်။

အသုံးချ လမ်းညွှန်ချက်

ထွက်ပေါက်တစ်ခုတည်းရှိပါက — E2 သည် လုံလောက်ပါသည်၊ metric ကို ရိုးရှင်းစွာ ထိန်းသိမ်းထားနိုင်သည်။ အနီးဆုံး ထွက်ပေါက်ကို router များ အသုံးပြုစေလိုသော ထွက်ပေါက် အများအပြား ရှိသည့်အခါ — E1 ကို အသုံးပြုပါ။ ထွက်ပေါက်များစွာရှိသော ဒီဇိုင်းတွင် default ဖြစ်သော E2 အတိုင်း ဆက်လက်ထားရှိခြင်းသည် ပိုမိုဝေးကွာသော ထွက်ပေါက်ဆီသို့ ကွန်ရက်ကို ဖြတ်သန်းသွားလာစေသည့် ဂန္ထဝင်အမှားတစ်ခု ဖြစ်စေသည်။


Router ID: ရွေးချယ်သတ်မှတ်ပုံ

OSPF သည် ထူးခြားသော 32-bit ID တစ်ခု လိုအပ်သည်။ ၎င်းကို အောက်ပါ တိကျသော ဦးစားပေးအစဉ်လိုက် ရွေးချယ်သည် -

၁။ Manually သတ်မှတ်ထားသော router-id — အမြဲတမ်း အနိုင်ရသည် ၂။ Up ဖြစ်နေသော loopback interface များအနက် အမြင့်ဆုံး IP address ၃။ Up ဖြစ်နေသော physical interface များအနက် အမြင့်ဆုံး IP address

Router ID ကို အမြဲတမ်း သီးခြား သတ်မှတ် (explicitly configure) ပေးပါ။ အလိုအလျောက် ရွေးချယ်မှုအပေါ် အားကိုးခြင်းသည် interface တစ်ခု down သွားသည့်အခါ သို့မဟုတ် interface အသစ်တစ်ခု ပေါ်လာသည့်အခါ ID ပြောင်းလဲသွားစေနိုင်သည် — Router ID သည် ထို router စတင်ထုတ်လွှင့်သော LSA တိုင်းတွင် ထည့်သွင်းထားသောကြောင့် ID ပြောင်းလဲသွားပါက area တစ်ခုလုံး LSA များကို ပြန်လည် flood ပြုလုပ်ပြီး SPF ကို ပြန်လည် run ရစေသည်။

ထို့ပြင် ပြောင်းလဲသတ်မှတ်လိုက်သော router ID သည် OSPF process ကို restart မလုပ်မချင်း အသက်မဝင်ပါ — အသစ်သတ်မှတ်ပြီး ဘာမှ မပြောင်းလဲသေးသည်ကို မြင်တွေ့ရသည့်အခါ အင်ဂျင်နီယာများ အံ့အားသင့်တတ်ကြသည်။


Timers နှင့် Cost သတ်မှတ်ချက်များ

Hello နှင့် dead intervals များသည် neighbours အချင်းချင်း ထပ်တူညီရပါမည်၊ သို့မဟုတ်ပါက adjacency ဘယ်တော့မှ တည်ဆောက်နိုင်မည် မဟုတ်ပါ။ Default တန်ဖိုးများသည် network type ပေါ် မူတည်ပါသည် -

Network type Hello Dead
Broadcast, point-to-point 10s 40s
NBMA, point-to-multipoint 30s 120s

Dead timer သည် ပုံမှန်အားဖြင့် hello ၏ ၄ ဆ ဖြစ်သည်။ ၎င်း timer နှစ်ခုစလုံးကို လျှော့ချခြင်းဖြင့် ပြတ်တောက်မှုကို ပိုမိုမြန်ဆန်စွာ သိရှိနိုင်သော်လည်း၊ sub-second အဆင့် လျင်မြန်စွာ converge ဖြစ်စေရန်အတွက် BFD ကို အသုံးပြုသင့်ပါသည် — BFD သည် သီးသန့်ပေါ့ပါးသော hello ဖြစ်ပြီး မီလီစက္ကန့်ပိုင်းအတွင်း link ကျရှုံးမှုကို သိရှိကာ OSPF အား neighbour ကို ချက်ချင်းဖြတ်တောက်ရန် အကြောင်းကြားပေးနိုင်သဖြင့် OSPF timer များကို လွန်ကဲစွာ လျှော့ချစရာ မလိုတော့ပေ။

Cost သည် reference bandwidth ÷ interface bandwidth ဖြစ်ပြီး default reference မှာ 100 Mbps ဖြစ်သည်။ ထို default တန်ဖိုးကြောင့် 100 Mbps နှင့်အထက် ရှိသော link တိုင်းသည် cost 1 သာ ဖြစ်နေရခြင်းဖြစ်သည် — OSPF အတွက်မူ 1G နှင့် 100G link တို့သည် တူညီနေပေလိမ့်မည်။ ခေတ်မီသော မြန်နှုန်းမြင့် links များကို ခွဲခြားနိုင်ရန် reference bandwidth ကို မြှင့်တင်သတ်မှတ်ပါ၊ ထို့အပြင် router တိုင်းတွင် တူညီစွာ သတ်မှတ်ပေးပါ၊ သို့မဟုတ်ပါက router များအကြား cost ကွဲလွဲမှုများ ဖြစ်ပေါ်လာပါလိမ့်မည်။

Passive interface သည် OSPF ထဲသို့ network တစ်ခုကို ကြေညာပေးထားသော်လည်း ထို interface ပေါ်မှ hello packet များ ထုတ်လွှင့်ခြင်းကို တားမြစ်သည်။ OSPF neighbour မရှိသော interface များ (user များချိတ်ဆက်ထားသော subnets များ၊ loopbacks များ) အတွက် အလွန်သင့်လျော်ပါသည် — အကြောင်းမှာ မလိုအပ်သော adjacency ကြိုးပမ်းမှုများကို ဖယ်ရှားပေးပြီး လုံခြုံရေးအရ တိုက်ခိုက်ခံရနိုင်သည့် မျက်နှာပြင် (attack surface) ကို လျှော့ချပေးသောကြောင့် ဖြစ်သည်။


LSA အမျိုးအစားများ- မည်သူက မည်သည့်အရာကို ကြေညာသနည်း

LSDB သည် မှတ်တမ်းအမျိုးအစား တစ်ခုတည်းဖြင့် တည်ဆောက်ထားခြင်း မဟုတ်ပါ။ အခြေအနေအမျိုးမျိုးအတွက် LSA types အမျိုးမျိုး ထုတ်ပေးကြပြီး အသုံးများသော အမျိုးအစားများကို သိရှိထားခြင်းက database output များကို နားလည်ရလွယ်ကူသော အချက်အလက်များအဖြစ် ပြောင်းလဲပေးနိုင်ပါသည် -

Type အမည် ဖော်ပြချက်
1 Router "ဒါ ငါ့ရဲ့ links တွေနဲ့ သူတို့ရဲ့ costs တွေဖြစ်တယ်" — မိမိ area အတွင်း router တိုင်းက ထုတ်လွှင့်သည်
2 Network "ဒီ multi-access segment ပေါ်မှာ ဘယ်သူတွေ ရှိနေလဲ" — DR က ထုတ်လွှင့်သည်
3 Summary "ဒီ prefix ဟာ တခြား area မှာ ရှိနေတယ်" — ABR က ထုတ်လွှင့်သည်
4 ASBR Summary "ASBR ဆီကို ဒီလို ရောက်နိုင်တယ်" — ABR က ထုတ်လွှင့်သည်
5 External "ဒါက OSPF ပြင်ပက လာတဲ့ route ဖြစ်တယ်" — ASBR က ထုတ်လွှင့်သည်
7 NSSA External Type 5 နှင့် တူညီသော်လည်း not-so-stubby area အတွင်း၌သာ သွားလာသည်

Types 1 နှင့် 2 သည် area တစ်ခု အတွင်း၌သာ ကန့်သတ်တည်ရှိသည်။ ၎င်းသည် area ခွဲခြားသတ်မှတ်ခြင်း၏ အဓိက အကျိုးကျေးဇူးဖြစ်သည် — အသေးစိတ် topology အချက်အလက်များသည် ပြင်ပသို့ ဘယ်တော့မှ မထွက်ခွာပါ။

အောက်တွင် live fabric မှ ဖမ်းယူထားသော Router LSA အစစ်အမှန်များဖြစ်ပြီး router တစ်ခုစီအတွက် sequence number နှင့် age တို့ ပါဝင်ပါသည် -

                 Router Link States (Area 0.0.0.0)

Link ID         ADV Router      Age         Seq#         Checksum Link count
2.2.2.2         2.2.2.2         120         0x80000006   0x6556   3
3.3.3.3         3.3.3.3         1811        0x80000005   0xbfee   3
1.1.1.1         1.1.1.1         169         0x80000008   0xbaae   5

အဓိပ္ပာယ်မှာ- Router သုံးခုသည် မိမိကိုယ်မိမိ အသီးသီးဖော်ပြနေကြခြင်း ဖြစ်သည်။ Link count သည် ထို router က ကြေညာထားသော link အရေအတွက် ဖြစ်သည်။ Seq# သည် ပြောင်းလဲမှုတစ်ခုစီတိုင်းတွင် တိုးတက်လာသည် — Sequence number များ လျင်မြန်စွာ မြင့်တက်နေပါက တစ်စုံတစ်ခု flap ဖြစ်နေပြီဟု ညွှန်ပြနေသည်။


Adjacency: State Machine အလုပ်လုပ်ပုံ

OSPF router နှစ်ခုသည် routes များ အပြန်အလှန် မဖလှယ်မီ သတ်မှတ်ထားသော states အဆင့်များကို ဖြတ်သန်းကြရသည်။ မည်သည့်နေရာတွင် ရပ်တန့်နေသည်ကို သိရှိပါက ပြဿနာ၏ အကြောင်းရင်းကို ချက်ချင်း သိရှိနိုင်သည်။

graph LR
    D["Down"] --> I["Init"] --> T["2-Way"] --> E["ExStart"] --> X["Exchange"] --> L["Loading"] --> F["Full"]
    classDef progress fill:#1565c0,stroke:#90caf9,color:#ffffff,stroke-width:2px,font-size:15px;
    classDef working fill:#2e7d32,stroke:#a5d6a7,color:#ffffff,stroke-width:2px,font-size:15px;
    class D,I,T,E,X,L progress; class F working;
  • Init — Hello packet ကို ကြားရသော်လည်း ၎င်းထဲတွင် မိမိကိုယ်ကို မတွေ့ရသေးပါ။
  • 2-Way — နှစ်ဦးနှစ်ဖက် အပြန်အလှန် မြင်တွေ့နေရပြီ။ LAN တစ်ခုပေါ်တွင် DR သို့မဟုတ် BDR မဟုတ်သော router များသည် ဤအဆင့်တွင် တမင် ရပ်တန့်နေကြသည်၊ ၎င်းသည် ပုံမှန်ကောင်းမွန်သော အခြေအနေ ဖြစ်သည်။
  • ExStart / Exchange — မည်သူက ဦးဆောင်မည်ကို ဆုံးဖြတ်ပြီးနောက် databases များကို ဖော်ပြကြသည်။
  • Loading — တစ်ဖက်နှင့်တစ်ဖက် လိုအပ်နေသော အသေးစိတ် အချက်အလက်များကို တောင်းဆိုကြသည်။
  • Full — Databases များ အပြည့်အဝ တူညီသွားပြီ (synchronised)။ ပုံမှန်အလုပ်လုပ်နေပြီဖြစ်ကြောင်း ညွှန်ပြသော တစ်ခုတည်းသော state ဖြစ်သည်။

မည်သည့်နေရာတွင် ရပ်တန့်တတ်ပြီး အကြောင်းရင်းများမှာ-

ရပ်တန့်နေသော State ဖြစ်ပွားရသည့် အကြောင်းရင်း
Init One-way hellos — Packet filtering ဖြစ်နေခြင်း သို့မဟုတ် ACL က multicast ကို drop လုပ်နေခြင်း
2-Way (LAN မဟုတ်သည့်အခါ) DR ရွေးချယ်မှု ပြဿနာ သို့မဟုတ် router နှစ်ခုလုံးတွင် priority 0 ဖြစ်နေခြင်း
ExStart / Exchange MTU mismatch — အဖြစ်အများဆုံး ဂန္ထဝင်ပြဿနာ။ တစ်ဖက်က ပေးပို့သော database packet ကို အခြားတစ်ဖက်က လက်မခံနိုင်ခြင်း
Full state မှ ပြုတ်ကျပြီး ပြန်တက်နေခြင်း Dead intervals မကိုက်ညီခြင်း သို့မဟုတ် မတည်ငြိမ်သော link ဖြစ်နေခြင်း

ပုံမှန်ကောင်းမွန်သော pair တစ်ခုကို အောက်ပါအတိုင်း တွေ့မြင်ရပါသည် -

Neighbor ID     Instance VRF      Pri State                  Dead Time   Address         Interface
3.3.3.3         1        default  0   FULL                   00:00:38    10.1.2.2        Ethernet2
2.2.2.2         1        default  0   FULL                   00:00:38    10.1.1.2        Ethernet1

Dead Time သည် အချိန်ပြောင်းပြန် ရေတွက်နေပြီး hello ရောက်တိုင်း reset ဖြစ်သည်။ အကယ်၍ ၎င်းသည် သုညဆီသို့ နီးကပ်သွားသည်ကို တွေ့ရပါက hello packets များ မရောက်ရှိတော့ခြင်း ဖြစ်သည်။


Network အမျိုးအစားများ၊ DR နှင့် Point-to-Point ပိုမိုကောင်းမွန်ရသည့် အကြောင်းရင်း

Router ပေါင်း n ခု ရှိသော shared segment တစ်ခုပေါ်တွင် router တိုင်း အချင်းချင်း full mesh adjacencies တည်ဆောက်ပါက ချိတ်ဆက်မှုပေါင်း n(n-1)/2 ခု ဖြစ်လာမည် — အလွန်ဖြုန်းတီးရာရောက်ပြီး packet များ ရှုပ်ထွေးဆူညံစေသည်။ ထို့ကြောင့် OSPF သည် လူတိုင်း ချိတ်ဆက်ရမည့် Designated Router (DR) နှင့် အသင့်စောင့်ဆိုင်းနေမည့် BDR တစ်ခုကို ရွေးကောက်တင်မြှောက်သည်။

ရွေးကောက်မှုကို priority ဖြင့် ဆုံးဖြတ်ပြီး အမြင့်ဆုံးက အနိုင်ရကာ router-ID ဖြင့် အနိုင်အရှုံး သတ်မှတ်သည်။ Priority 0 ၏ အဓိပ္ပာယ်မှာ "ငါ့ကို DR အဖြစ် ဘယ်တော့မှ မရွေးချယ်ပါနှင့်" ဖြစ်သည်။

သို့သော် ခေတ်သစ် links အများစုမှာ point-to-point ဖြစ်ကြသည်။ Routed link ပေါ်ရှိ router နှစ်ခုကြားတွင် ရွေးချယ်စရာ ဘာမှမရှိသဖြင့် DR election လုပ်ဆောင်ခြင်းသည် အချိန်ကြန့်ကြာမှုသာ ဖြစ်စေသည်။ ထို့ကြောင့် အောက်ပါအတိုင်း သတ်မှတ်ကြသည် -

interface Ethernet1
 no switchport
 ip address 10.1.1.1 255.255.255.0
 ip ospf area 0.0.0.0
 ip ospf network point-to-point

ယခင် interface output တွင် State P2P နှင့် Nbrs 1 ဟု ဖော်ပြထားသည်ကို သတိပြုပါ — DR ရွေးချယ်မှု မပါဝင်တော့ပေ။

Router နှစ်ခုကြားရှိ routed links များပေါ်တွင် Point-to-Point ကို သတ်မှတ်ပါ

၎င်းသည် DR election ကို ကျော်သွားနိုင်ပြီး adjacency ပိုမိုမြန်ဆန်စွာ ဖွဲ့စည်းစေသည့်အပြင် ပိုမိုရိုးရှင်းသော database ကို ထုတ်ပေးသည် (type-2 LSA မလိုအပ်တော့ပါ)။ Link တိုင်းသည် routed point-to-point ဖြစ်သော spine-leaf fabric တွင် ဤသတ်မှတ်ချက်သည် သင်၏ default ဖြစ်သင့်သည်။

Loopback interface တွင်မူ DR ဟု ပြသနေဆဲဖြစ်မည် — ၎င်းသည် ပုံမှန်ဖြစ်ပြီး အန္တရာယ်မရှိပါ။ Loopback တွင် ရွေးကောက်ပွဲလုပ်ရန် အိမ်နီးချင်း မရှိသောကြောင့် ဖြစ်သည်။


Summarisation နှင့် ပြုလုပ်ခွင့်ရှိသော နေရာများ

OSPF သည် နယ်စပ်များ (borders) တွင်သာ summarise ပြုလုပ်ခွင့်ပေးထားသည် — စိတ်ကြိုက် နေရာတိုင်းတွင် မပြုလုပ်နိုင်ပါ၊ အကြောင်းမှာ area အတွင်းရှိ router များသည် တူညီသော database ကို ထိန်းသိမ်းထားရမည်ဖြစ်ပြီး area အလယ်တွင် summarise လုပ်လိုက်ပါက ထိုစည်းမျဉ်း ပျက်စီးသွားမည် ဖြစ်သောကြောင့် ဖြစ်သည်။

နေရာ (Where) Command Summarises
ABR area <id> range <prefix> Inter-area (type 3)
ASBR summary-address <prefix> External (type 5 / 7)

ဤနှစ်ခုကို ရောထွေးမှားယွင်းခြင်းသည် အင်တာဗျူးများတွင် အလွန်တွေ့ရတတ်သည် — ASBR ပေါ်တွင် area range ပေးခြင်းသည် external routes များအပေါ် မည်သို့မျှ သက်ရောက်မှုမရှိသလို၊ ABR ပေါ်တွင် summary-address ပေးခြင်းသည်လည်း inter-area routes များအပေါ် မည်သို့မျှ သက်ရောက်မှု မရှိပါ။

Summarisation သည် ကြီးမားသော OSPF domain မတည်မငြိမ်ဖြစ်ခြင်းမှ အဓိက ကာကွယ်ပေးသည့် နည်းလမ်းဖြစ်သည် — Summary ၏ နောက်ကွယ်ရှိ link တစ်ခု flap ဖြစ်နေသော်လည်း summary ပြင်ပသို့ မပြောင်းလဲသဖြင့် flap ဖြစ်မှုသည် local ၌သာ ကျန်ရစ်ပြီး network တစ်ခုလုံး SPF run ရခြင်းမှ သက်သာစေသည်။ အားနည်းချက်မှာ အသေးစိတ်မြင်ကွင်း ဆုံးရှုံးခြင်းနှင့် ထို address range အတွင်း အမှန်တကယ် မရောက်ရှိနိုင်သော traffic များကို ဆွဲဆောင်မိစေခြင်းတို့ ဖြစ်သည်။

Area တိုင်းသည် area 0 နှင့် တိုက်ရိုက် ထိစပ်ရမည်ဖြစ်သော်လည်း — ကုမ္ပဏီများ ပေါင်းစည်းပြီးနောက် သို့မဟုတ် backbone physically ပြတ်တောက်သွားသည့်အခါများတွင် အချို့သော area များ မထိစပ်နိုင်တော့ဘဲ ဖြစ်တတ်သည်။ Virtual link သည် အကြားရှိ ကြားခံ area တစ်ခုကို ဖြတ်သန်းကာ tunnel ဖောက်လုပ်ပြီး ချိတ်ဆက်မှုကို ပြန်လည် ထိန်းသိမ်းပေးသည် -

interface Ethernet1
 ...
router ospf 1
 area 0.0.0.1 virtual-link 4.4.4.4

Transit area သည် standard area ဖြစ်ရပါမည် (လိုအပ်သော LSAs များကို မသယ်ဆောင်နိုင်သည့် stub မဖြစ်ရပါ)၊ ထို့ပြင် area 0 ကိုယ်တိုင်လည်း မဖြစ်ရပါ။

Virtual Link ကို အမြဲတမ်းဒီဇိုင်းအဖြစ် မဟုတ်ဘဲ အရေးပေါ်ပြင်ဆင်မှုအဖြစ်သာ မှတ်ယူပါ

၎င်းသည် အလုပ်ဖြစ်ပြီး အရေးပေါ်အခြေအနေများအတွက် သင့်လျော်သော tool တစ်ခု ဖြစ်သည်။ သို့သော် ၎င်းသည် နုနယ်လွယ်သည် — transit area ၏ ကျန်းမာကြံ့ခိုင်မှုအပေါ် မှီခိုနေရပြီး address plan ရှိ ဖွဲ့စည်းပုံဆိုင်ရာ ပြဿနာကို ဖုံးကွယ်ထားတတ်သည်။ အကယ်၍ virtual link သည် သင်၏ network တွင် အဓိက အားထားနေရပါက အမှန်တကယ် ပြင်ဆင်ရမည့် နည်းလမ်းမှာ ထို area ကို backbone ဆီသို့ တိုက်ရိုက် ပြန်လည် ချိတ်ဆက်ပေးခြင်း (re-homing) သာ ဖြစ်သည်။


OSPFv3: IPv6 အတွက် အဘယ်အရာများ ပြောင်းလဲသွားသနည်း

OSPFv3 သည် algorithm အတူတူပင် ဖြစ်သော်လည်း အတွင်းပိုင်း ချိတ်ဆက်လုပ်ဆောင်ပုံ (plumbing) သိသိသာသာ ကွဲပြားပါသည်။

Per-subnet မဟုတ်ဘဲ Per-link ဖြစ်လာခြင်း။ OSPFv2 သည် IP subnet တစ်ခုတည်းရှိ router များနှင့်သာ adjacencies ဖွဲ့စည်းသည်။ OSPFv3 သည် link တစ်ခုချင်းစီအလိုက် အလုပ်လုပ်သည် — Addressing သတ်မှတ်ချက်များသည် neighbour ဖွဲ့စည်းမှုကို အဟန့်အတား မဖြစ်စေတော့ပါ။ Link တစ်ခုပေါ်တွင် prefixes များစွာ ရှိနေခြင်းသည် ပြဿနာ မဟုတ်တော့ပေ။

Neighbours များသည် link-local ဖြစ်ခြင်း။ Adjacencies များသည် fe80:: address များကို အသုံးပြုသည်။ Global prefixes များကို သယ်ဆောင်ထားသော်လည်း peers များသည် link-local အဖြစ် ပေါ်နေမည် — ၎င်းသည် မှန်ကန်သော အခြေအနေဖြစ်ပြီး configuration မှားယွင်းနေခြင်း မဟုတ်ပါ။

Router IDs များသည် 32-bit အတိုင်း ဆက်လက်တည်ရှိနေခြင်း။ IPv4 ကဲ့သို့ပင် dotted-quad ပုံစံဖြင့် ရေးသားရသည်။ IPv6-only network တွင် ID အဖြစ် ရယူစရာ IPv4 address မရှိသောကြောင့် သင်ကိုယ်တိုင် manual သတ်မှတ်ပေးရမည် — ၎င်းသည် OSPFv3 စတင်မလည်ပတ်နိုင်ခြင်း၏ အလွန်အဖြစ်များသော အကြောင်းရင်းတစ်ခု ဖြစ်သည်။

Addressing ကို Topology LSAs များထဲမှ ဖယ်ထုတ်လိုက်ခြင်း။ Router နှင့် network LSAs များသည် topology သက်သက်ကိုသာ ဖော်ပြကြသည်၊ Prefixes များသည် သီးခြား LSAs များ (Link LSAs နှင့် Intra-Area-Prefix LSAs) ဖြင့် သွားလာကြသည်။ ဤပြောင်းလဲမှုကြောင့်ပင် OSPFv3 သည် မူလဒီဇိုင်းထုတ်ထားသော protocol အပြင် အခြားသော address families များကိုပါ သယ်ဆောင်နိုင်စွမ်း ရှိလာခြင်း ဖြစ်သည်။

Authentication ကို ပယ်ဖျက်လိုက်ခြင်း။ Protocol အတွင်းရှိ authentication ကို ဖယ်ရှားပြီး IPsec ထံ လွှဲအပ်လိုက်သည် — သဘောတရားအရ ပိုမိုသန့်ရှင်းသော ဒီဇိုင်းဖြစ်သော်လည်း လက်တွေ့လုပ်ငန်းခွင်တွင် ပိုမိုရှုပ်ထွေးစေသည်။


Arista cEOS OSPFv3 Configuration

Arista cEOS ပေါ်တွင် OSPFv3 configure ပြုလုပ်ရန် IPv6 routing ကို enable ပြုလုပ်ရမည်ဖြစ်ပြီး၊ manual 32-bit router-ID တစ်ခု သတ်မှတ်ကာ interfaces များကို OSPFv3 process ID နှင့် တွဲချိတ်ပေးရမည် -

! Enable IPv6 unicast routing globally
ipv6 unicast-routing

! Define the OSPFv3 process (Process ID 100) and explicit Router ID
router ospf3 100
   router-id 1.1.1.1
   exit

! Loopback interface configuration
interface Loopback0
   ipv6 address 2001:db8:1::1/128
   ipv6 ospf 100 area 0.0.0.0

! Point-to-point inter-router link
interface Ethernet1
   no switchport
   ipv6 address 2001:db8:12::1/64
   ipv6 ospf 100 area 0.0.0.0
   ipv6 ospf network point-to-point

Interface syntax တွင် Process ID ထည့်သွင်းရန် လိုအပ်ချက်

OSPFv2 (ip ospf area 0.0.0.0) နှင့် မတူဘဲ OSPFv3 interface configuration တွင် process ID ကို အတိအလင်း ရေးသားပေးရန် လိုအပ်သည်- ipv6 ospf <process-id> area <area-id>.


OSPFv3 စစ်ဆေးအတည်ပြုခြင်း (Operational Verification)

Adjacency၊ link states နှင့် IPv6 routes များကို သီးသန့် ipv6 CLI commands များဖြင့် စစ်ဆေးနိုင်သည် -

# Check OSPFv3 adjacencies (note neighbour IP is link-local fe80::)
docker exec clab-ceos-r1 Cli -p 15 -c "show ipv6 ospf neighbor"

# Verify IPv6 routes installed by OSPFv3
docker exec clab-ceos-r1 Cli -p 15 -c "show ipv6 route ospf"

show ipv6 ospf neighbor ၏ နမူနာ output:

Neighbor ID     Instance VRF      Pri State                  Dead Time   Address       Interface
2.2.2.2         100      default  1   FULL/P2P               00:00:34    fe80::2       Ethernet1

show ipv6 route ospf ၏ နမူနာ output:

Codes: C - connected, S - static, K - kernel,
       O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
       E2 - OSPF external type 2

O        2001:db8:2::2/128 [110/20] via fe80::2, Ethernet1

v2 နှင့် v3 သည် protocol တစ်ခုတည်း၏ modes နှစ်ခု မဟုတ်ဘဲ သီးခြား protocols နှစ်ခု ဖြစ်သည်

Dual-stack အသုံးပြုခြင်းဆိုသည်မှာ database နှစ်ခုနှင့် SPF computation နှစ်ခုရှိသော သီးခြား OSPF instances နှစ်ခုကို တပြိုင်နက် run ထားခြင်း ဖြစ်သည်။ ၎င်းတို့သည် အချင်းချင်း သဘောထားကွဲလွဲနိုင်သည်- တူညီသော physical topology ပေါ်တွင် IPv4 က လမ်းကြောင်းတစ်ခုမှ သွားပြီး IPv6 က အခြားလမ်းကြောင်းတစ်ခုမှ သွားနေခြင်းမျိုး ဖြစ်ပွားနိုင်ပြီး၊ ပြဿနာရှာဖွေရာတွင် နှစ်မျိုးစလုံးကို စစ်ဆေးရပါမည်။

IS-IS သည် ဤကိစ္စကို ပိုမိုထိရောက်စွာ ကိုင်တွယ်ပုံအား ရွေးချယ်မှု လမ်းညွှန် တွင် ကြည့်ရှုပါ။


အင်တာဗျူး မေးခွန်းများ (Interview questions)

OSPF area တိုင်းသည် Area 0 နှင့် အဘယ်ကြောင့် မဖြစ်မနေ ချိတ်ဆက်ရသနည်း။

OSPF တွင် area များ အချင်းချင်းကြား loop ကာကွယ်ရေး ယန္တရား မပါရှိပါ — Inter-area routes များသည် distance-vector သဘောတရားအရ အကျဉ်းချုပ်ထားခြင်းဖြစ်ပြီး router သည် ၎င်းတို့၏ နောက်ကွယ်ရှိ topology အစစ်အမှန်ကို မမြင်နိုင်ပါ။ Inter-area traffic အားလုံးကို single backbone area 0 မှတစ်ဆင့်သာ ဖြတ်သန်းစေခြင်းဖြင့် algorithm ပေါ်တွင် အားကိုးစရာမလိုဘဲ ဖွဲ့စည်းပုံအရ loop မဖြစ်နိုင်အောင် (structurally impossible) ကာကွယ်ပေးထားခြင်း ဖြစ်သည်။

Router နှစ်ခုသည် ExStart/Exchange အဆင့်တွင် ရပ်တန့်နေပါသည်။ မည်သည့်အရာကို အရင်ဆုံး စစ်ဆေးမည်နည်း။

MTU ကို အရင်စစ်ဆေးပါမည်။ Database exchange ပြုလုပ်နေစဉ် တစ်ဖက်စီသည် မိမိကိုယ်ပိုင် MTU အရွယ်အစားရှိသော packet များကို ပေးပို့ကြသည်၊ အကယ်၍ တစ်ဖက်က လက်မခံနိုင်ပါက exchange သည် ဘယ်တော့မှ ပြီးဆုံးမည် မဟုတ်ပါ။ Interface များ up ဖြစ်နေပြီး hello packets များ ကောင်းမွန်စွာ သွားလာနိုင်သဖြင့် ရောထွေးတတ်သည် — Packet သေးသေးလေးများ သွားနိုင်သော်လည်း packet ကြီးကြီးများ မဖြတ်သန်းနိုင်ခြင်း ဖြစ်သည်။

LAN ပေါ်ရှိ Router တစ်ခုသည် 2-Way အဆင့်တွင် ရပ်တန့်နေပါသည်။ ၎င်းသည် ပျက်စီးနေခြင်းလား။

မဟုတ်နိုင်ပါ။ Multi-access segment ပေါ်တွင် DR နှင့် BDR သာလျှင် Full state သို့ ရောက်ရှိကြပြီး — အခြား router အချင်းချင်းကြားတွင်မူ 2-Way အဆင့်၌သာ တမင် ရပ်တန့်နေကြသည်။ Router သည် DR သို့မဟုတ် BDR ဖြစ်သင့်ပါလျက်နှင့် မဖြစ်လာသည့် အခြေအနေမျိုးတွင်သာ ပြဿနာရှိခြင်း ဖြစ်သည်။

OSPFv2 နှင့် OSPFv3 area များအကြား လက်တွေ့ ကွာခြားချက်မှာ အဘယ်နည်း။

သဘောတရားအရ ကွာခြားချက် မရှိပါ — Area model မှာ ထပ်တူညီပါသည်။ ကွာခြားချက်များမှာ သယ်ယူပို့ဆောင်ရေးနှင့် encoding တွင် ဖြစ်သည်- v3 သည် subnet အလိုက် မဟုတ်ဘဲ link အလိုက် အလုပ်လုပ်ခြင်း၊ link-local address များပေါ်တွင် peer ဖွဲ့ခြင်း၊ topology LSAs များထဲမှ addressing ကို သီးခြားခွဲထုတ်ထားခြင်းနှင့် built-in authentication အစား IPsec ကို အသုံးပြုခြင်းတို့ ဖြစ်သည်။

Routed link ပေါ်တွင် Broadcast ထက် Point-to-Point ကို အဘယ်ကြောင့် ပိုမိုဦးစားပေးသင့်သနည်း။

Router နှစ်ခုတည်းသာ ရှိသောကြောင့် ရွေးချယ်စရာ ဘာမှမရှိသဖြင့် DR election သည် မည်သည့်အကျိုးကျေးဇူးမျှ မရှိဘဲ စတင်ချိန် နှောင့်နှေးမှုကိုသာ ဖြစ်စေသည်။ Point-to-point သည် adjacency ပိုမိုမြန်ဆန်စွာ တည်ဆောက်နိုင်ပြီး type-2 network LSA မလိုတော့သဖြင့် database ကို ပိုမိုရှင်းလင်းစေသည်။


နောက်တစ်ခု: IS-IS → — တူညီသောအလုပ်ကို လုပ်ဆောင်သော်လည်း အလွန်ကွဲပြားသော ဒီဇိုင်းဖြစ်ပြီး Service Provider များက အဘယ်ကြောင့် ဆက်လက်ရွေးချယ်နေကြသည်ကို လေ့လာပါမည်။