၄ · OSPF နှင့် IS-IS ရွေးချယ်ခြင်း¶
Protocol နှစ်ခုစလုံးသည် link-state ဖြစ်ကြသည်၊ နှစ်ခုစလုံး Dijkstra algorithm ကို run ကြသည်၊ ကျွမ်းကျင်သူများ၏ လက်ထဲတွင် နှစ်ခုစလုံးသည် ကြီးမားကျယ်ပြန့်သော ကွန်ရက်များအထိ ကောင်းမွန်စွာ scale လုပ်နိုင်ကြသည်။ တစ်ခုက အခြားတစ်ခုထက် အကြွင်းမဲ့ ပိုမိုကောင်းမွန်သည်ဟု ပြောဆိုနေသူ မည်သူမဆိုသည် အချက်အလက်အမှန်ကို ချန်လှပ်ထားခြင်း ဖြစ်ပေလိမ့်မည်။
အောက်တွင် ဓမ္မဓိဋ္ဌာန်ကျသော အမှန်တရားကို ဖော်ပြထားပါသည် — ၎င်းတို့ အမှန်တကယ် မည်သည့်နေရာတွင် ကွဲပြားကြသနည်း၊ မည်သည့်ကွာခြားချက်များက ဒီဇိုင်းဆိုင်ရာ ဆုံးဖြတ်ချက်ကို အမှန်တကယ် ပြောင်းလဲစေသနည်း။
ဘေးချင်းယှဉ် နှိုင်းယှဉ်ချက် (Side by side)¶
| OSPF | IS-IS | |
|---|---|---|
| အခြေခံ လည်ပတ်မှု (Runs on) | IP (protocol 89) | Layer 2 ပေါ်တွင် တိုက်ရိုက် |
| အဆင့်ဆင့် ဖွဲ့စည်းပုံ (Hierarchy) | Areas များ၊ အားလုံး Area 0 နှင့် ထိစပ်ရသည် | Levels များ (L1 / L2) |
| Area အဖွဲ့ဝင်ဖြစ်မှု | Interface တစ်ခုစီအလိုက် | Router တစ်ခုလုံးအလိုက် |
| Backbone | Area 0၊ နံပါတ်တပ်ထားသော area | အချင်းချင်းဆက်စပ်နေသော L2 routers ကွင်းဆက် |
| သတင်းလွှာ ကြေညာချက် | LSA အမျိုးအစားပေါင်းများစွာ | Router တစ်ခုလျှင် TLVs ဖြင့် တည်ဆောက်ထားသော LSP တစ်ခု |
| စွမ်းရည် တိုးချဲ့နိုင်စွမ်း (Extensibility) | Protocol အပြောင်းအလဲများ မကြာခဏ လိုအပ်သည် | TLV အသစ် ထည့်သွင်းရုံသာ |
| IPv6 ထောက်ပံ့မှု | OSPFv3 — သီးခြား protocol တစ်ခု | ထို instance ထဲတွင်ပင် TLV တစ်ခုအဖြစ် |
| Dual-stack | Instances ၂ ခု၊ databases ၂ ခု | Instance ၁ ခု၊ single သို့မဟုတ် multi-topology |
| LAN ရွေးကောက်တင်မြှောက်မှု | DR + BDR၊ အစားထိုး သိမ်းပိုက်ခွင့်မရှိ (no pre-emption) | DIS၊ backup မရှိ၊ အစားထိုး သိမ်းပိုက်နိုင်သည် (pre-emptable) |
| Segment routing | ထောက်ပံ့သည်၊ နောက်မှ ရောက်ရှိလာသည် | အစကတည်းက အဆင်ပြေပြေ ပေါင်းစပ်ပါဝင်သည် |
| အသုံးများသော နေရာများ | Enterprise၊ Data Center | Service Provider backbone |
အမှန်တကယ် အရေးပါသော ကွာခြားချက်များ¶
စွမ်းရည် တိုးချဲ့နိုင်စွမ်း (Extensibility)။ ၎င်းသည် အကြီးမားဆုံး အချက်ဖြစ်သည်။ TLV encoding ကြောင့် IS-IS သည် protocol version အသစ် ထုတ်လုပ်စရာမလိုဘဲ စွမ်းဆောင်ရည်အသစ်များကို အလွယ်တကူ လက်ခံရယူနိုင်သည်။ IPv6 နှင့် Segment Routing နှစ်ခုစလုံးသည် IS-IS ထံသို့ extensions အဖြစ် ရောက်ရှိလာခဲ့ကြပြီး OSPF တွင်မူ IPv6 အတွက် protocol အသစ်တစ်ခုလုံးကို ဖန်တီးခဲ့ရသည်။
အကယ်၍ သင်၏ နည်းပညာလမ်းပြမြေပုံတွင် Segment Routing ပါဝင်နေပါက ၎င်းတစ်ခုတည်းဖြင့်ပင် IS-IS ကို ရွေးချယ်ရန် ခိုင်လုံသော အကြောင်းပြချက် ဖြစ်စေသည်။
Backbone ပြောင်းလွယ်ပြင်လွယ်မှု (Backbone flexibility)။ OSPF ကွန်ရက်ကို ချဲ့ထွင်ခြင်းဆိုသည်မှာ Area 0 ကို ချဲ့ထွင်ခြင်းဖြစ်ပြီး ပထဝီအနေအထားအရ အဆင်မပြေပါက virtual links များကို သုံးရတတ်သည်။ IS-IS backbone ကို ချဲ့ထွင်ရန်အတွက်မူ router များတွင် L2 ကို enable လုပ်ပေးလိုက်ရုံသာ ဖြစ်သည်။ ကုမ္ပဏီ ပေါင်းစည်းဝယ်ယူမှုများဖြင့် ကြီးထွားလာသော အဖွဲ့အစည်းများသည် ဤကွာခြားချက်ကို သိသာစွာ ခံစားရသည်။
တိုက်ခိုက်ခံရနိုင်သည့် မျက်နှာပြင် (Attack surface)။ IS-IS ကို link ပြင်ပမှ လှမ်းရောက်ရှိတိုက်ခိုက်၍ မရနိုင်ပါ၊ အကြောင်းမှာ ၎င်းဆီသို့ လမ်းကြောင်းရှာပေးမည့် IP header မပါရှိသောကြောင့် ဖြစ်သည်။ Internet နှင့် တိုက်ရိုက်ထိတွေ့နေသော backbone တစ်ခုအတွက် ၎င်းသည် စာတွေ့သက်သက် မဟုတ်ဘဲ အလွန်အဓိပ္ပာယ်ရှိသော ဂုဏ်သတ္တိတစ်ခု ဖြစ်သည်။
လုပ်ငန်းခွင် ရင်းနှီးကျွမ်းဝင်မှု (Operational familiarity)။ အထက်ပါ အားသာချက်အားလုံးကို ဆန့်ကျင်နေသောအချက်မှာ — OSPF ကို တတ်ကျွမ်းသော အင်ဂျင်နီယာ အရေအတွက် များစွာ ပိုမိုများပြားခြင်း ဖြစ်သည်။ ညဉ့်နက်သန်းခေါင် ၃ နာရီတွင် သင်၏ team က အခက်အခဲမရှိ troubleshoot လုပ်နိုင်သော protocol တစ်ခုသည် နည်းပညာအရ သာလွန်သော်လည်း team က ကောင်းစွာ မကိုင်တွယ်နိုင်သော protocol ထက် ပိုမိုကောင်းမွန်ပါသည်။ ၎င်းသည် လျစ်လျူရှု၍မရသော လက်တွေ့အင်ဂျင်နီယာဆိုင်ရာ အကြောင်းပြချက်ဖြစ်ပြီး protocol အစွဲကြီးသူများ ဝန်ခံလိုသည်ထက် ပိုမို၍ အနိုင်ရလေ့ရှိသည်။
လက်တွေ့ ရွေးချယ်မှု လမ်းညွှန်¶
OSPF ကို ရွေးချယ်ပါ- သင်သည် enterprise သို့မဟုတ် data-centre network တစ်ခုကို run နေပြီး၊ သင်၏ team က OSPF ကို ရင်းနှီးကျွမ်းဝင်ပြီးသားဖြစ်ကာ၊ segment routing အသုံးပြုရန် လတ်တလော အစီအစဉ်မရှိသည့်အခါ။ ၎င်းကို လူသိများပြီး tool အထောက်အပံ့ ကောင်းမွန်ကာ ၎င်း၏ area model သည် enterprise အများစု ဖွဲ့စည်းတည်ဆောက်ထားပုံနှင့် သပ်သပ်ရပ်ရပ် ကိုက်ညီပါသည်။
IS-IS ကို ရွေးချယ်ပါ- သင်သည် service-provider backbone တစ်ခုကို တည်ဆောက်နေပြီး၊ segment routing သို့မဟုတ် traffic engineering ကို အသုံးပြုရန် မျှော်လင့်ထားသည့်အခါ၊ backbone ကို ပြန်လည်မပြင်ဆင်ဘဲ ကွန်ရက်များကို လွယ်ကူစွာ ချဲ့ထွင်/ပေါင်းစည်းလိုသည့်အခါ၊ သို့မဟုတ် protocol ကို IP တိုက်ခိုက်မှု မျက်နှာပြင်မှ ကင်းလွတ်စေလိုသည့်အခါ။
အကြောင်းပြချက် ခိုင်လုံမှုမရှိဘဲ ကောင်းမွန်စွာ အလုပ်လုပ်နေသော ကွန်ရက်တစ်ခုကို ပြောင်းလဲခြင်း မပြုပါနှင့်။ IGP ကို migrate လုပ်ခြင်းသည် လုပ်ငန်းအနှောင့်အယှက်များစေပြီး ဒီဇိုင်းသပ်ရပ်ရုံ သက်သက်ဖြင့် အရင်းအနှီး ပြန်မကျေနိုင်ပါ။ "တစ်နေ့နေ့တော့ SR သုံးချင်သုံးမယ်" ဆိုသည်မှာ မလုံလောက်ပါ; "လာမည့်သုံးလပတ်တွင် SR ကို စတင်အသုံးပြုမည်" ဆိုပါက ခိုင်လုံသော အကြောင်းပြချက် ဖြစ်သည်။
VXLAN-EVPN fabric တွင် ဤရွေးချယ်မှုသည် သိပ်မကွာခြားပါ
Spine-leaf underlay တွင် တာဝန်တစ်ခုတည်းသာ ရှိသည်- Loopback တိုင်းကို အချင်းချင်း ရောက်ရှိနိုင်စေရန် ဖြစ်သည်။ ၎င်းသည် ပုံမှန်အားဖြင့် point-to-point links များပါဝင်သော hierarchy မရှိသည့် single area သာ ဖြစ်သည်။
Protocol နှစ်ခုစလုံးက ထိုတာဝန်ကို အပြစ်ဆိုဖွယ်မရှိ အောင်မြင်စွာ လုပ်ဆောင်ပေးနိုင်သည်။ သင်၏ team ရင်းနှီးကျွမ်းဝင်ရာကိုသာ ရွေးချယ်ပါ — Phase 4 တွင် ဤအကြောင်းပြချက်ကြောင့်ပင် OSPF ကို အသုံးပြုထားခြင်း ဖြစ်သည်။
Hyper-Scale ကွန်ရက်များ၏ ခြွင်းချက် (eBGP)
အကယ်၍ သင်သည် (Google သို့မဟုတ် Meta ကဲ့သို့ node ပေါင်း သောင်းနှင့်ချီသော) ဧရာမ data center ကြီးတစ်ခုကို တည်ဆောက်နေပါက fabric တွင် IGP များကို လုံးဝ စွန့်လွှတ်လိုက်ကြသည်။ Link-state protocol များသည် အပ်ဒိတ်များကို router တိုင်းဆီသို့ flood လုပ်ကြသဖြင့် link များ flap ဖြစ်သည့်အခါ ထိခိုက်မှု အတိုင်းအတာ (blast radius) အလွန် ကြီးမားသွားနိုင်သည်။ Hyper-scaler များသည် underlay အဖြစ် eBGP ကို အစားထိုး အသုံးပြုကြသည်၊ အကြောင်းမှာ distance-vector protocol များသည် topology မတည်ငြိမ်မှုများကို ဖုံးကွယ်ပေးနိုင်ပြီး blast radius ကို ကန့်သတ်ပေးသောကြောင့် ဖြစ်သည်။ (၅ · Hyper-Scale ကွန်ရက်များရှိ IGPs ကို ကြည့်ပါ)။
Dual-Stack မဟာဗျူဟာ¶
IPv6 ကို ပေါင်းထည့်အသုံးပြုခြင်းသည် protocol နှစ်ခုအကြား လက်တွေ့လုပ်ငန်းခွင်၌ အကွဲပြားဆုံးသော အပိုင်းဖြစ်သည်။
OSPF တွင် protocol နှစ်ခုကို တပြိုင်နက် run ရသည်။ IPv4 အတွက် OSPFv2၊ IPv6 အတွက် OSPFv3 — Adjacencies သီးခြား၊ databases သီးခြား၊ SPF သီးခြား ဖြစ်သည်။ ၎င်းတို့သည် သဘောထားကွဲလွဲနိုင်ပြီး တူညီသော physical links များပေါ်တွင် IPv4 က လမ်းကြောင်းတစ်ခု၊ IPv6 က အခြားလမ်းကြောင်းတစ်ခုမှ သွားနေခြင်းသည် အမှားအယွင်း မဟုတ်ဘဲ ပုံမှန်ဖြစ်ရိုးဖြစ်စဉ် ဖြစ်သည်။ Troubleshooting ပြုလုပ်တိုင်း နှစ်ခါစီ လုပ်ဆောင်ရမည် ဖြစ်သည်။
IS-IS တွင်မူ protocol တစ်ခုတည်းကိုသာ run ရသည်။ ထို့နောက် အောက်ပါတို့ကို ရွေးချယ်နိုင်သည် -
- Single topology — Address families နှစ်ခုစလုံးအတွက် SPF တစ်ခုတည်း။ ပိုမိုရိုးရှင်းသော်လည်း link တိုင်းတွင် protocol နှစ်မျိုးစလုံး ရှိရမည်ဟု ယူဆထားသည်။ IPv4 သာရှိသော link ပေါ်သို့ IPv6 traffic ရောက်သွားပါက black-hole ဖြစ်သွားမည်။
- Multi-topology — Family တစ်ခုစီအတွက် သီးခြား SPF၊ ထို့ကြောင့် ကွန်ရက်တစ်စိတ်တစ်ပိုင်းစီ စတင်တပ်ဆင်နေချိန်တွင် ဘေးကင်းလုံခြုံသည်။
လက်တွေ့ကျသော အကြံပြုချက်- IPv6 ကို အဆင့်ဆင့် ချဲ့ထွင်နေစဉ်ကာလအတွင်း Multi-Topology ကို အသုံးပြုပါ။ Dual-stack သည် ကွန်ရက်တစ်ခုလုံးတွင် အမှန်တကယ် ပြည့်စုံသွားပြီး နောင်တွင်လည်း ထိုအတိုင်း ဆက်လက်ထိန်းသိမ်းမည်ဟု သေချာမှသာ Single Topology သည် လုံခြုံပါလိမ့်မည် — သို့သော် ကွန်ရက်များသည် ထိုမျှလောက် အမြဲတစေ သပ်ရပ်မနေတတ်ပါ။
အင်တာဗျူး မေးခွန်းများ (Interview questions)¶
သင်သည် Provider backbone အသစ်တစ်ခုကို ဒီဇိုင်းဆွဲနေပြီး Segment Routing သုံးရန် စီစဉ်ထားသည်။ မည်သည့် IGP ကို ရွေးချယ်မည်နည်း၊ အဘယ်ကြောင့်နည်း။
IS-IS ကို ရွေးချယ်ပါမည်။ Segment routing extensions များကို TLVs အဖြစ် သယ်ဆောင်ထားပြီး IS-IS သည် protocol ပြောင်းလဲမှုမလိုဘဲ အသစ်များကို လက်ခံနိုင်ရန် မူလကတည်းက တည်ဆောက်ထားသောကြောင့် ဖြစ်သည် — SR သည် ထိုနေရာသို့ အရင်ဆုံးနှင့် အဆင်ပြေဆုံး ရောက်ရှိခဲ့သည်။ ထို့အပြင် ကွန်ရက်ကြီးထွားလာသည်နှင့်အမျှ L2 backbone ကို ချဲ့ထွင်ရန် ပိုမိုလွယ်ကူပြီး IP မဟုတ်သောကြောင့် တိုက်ခိုက်ခံရနိုင်ခြေ လျော့နည်းစေသည်။ OSPF ကလည်း SR ကို ထောက်ပံ့သော်လည်း ဤသည်မှာ ဂေဟစနစ်တစ်ခုလုံး ရွေ့လျားသွားသော ဦးတည်ချက် ဖြစ်သည်။
သင်၏ Enterprise တွင် OSPF run နေပြီး တစ်စုံတစ်ယောက်က သပ်ရပ်လှပမှုအတွက် IS-IS သို့ ပြောင်းရန် အဆိုပြုလာသည်။ သင် မည်သို့ တုံ့ပြန်မည်နည်း။
၎င်းက မည်သည့် လက်တွေ့ပြဿနာကို ဖြေရှင်းပေးမည်နည်းဟု မေးမြန်းပါမည်။ အကယ်၍ ခိုင်လုံသော တွန်းအားမရှိပါက (ဥပမာ Segment Routing သုံးရန်၊ backbone ကြီးထွားမှု ပြဿနာများရှိရန်၊ သီးခြားလုံခြုံရေး လိုအပ်ချက်ရှိရန် မဟုတ်ပါက) migration ပြုလုပ်ရသည့် ကုန်ကျစရိတ်နှင့် team က ကျွမ်းကျင်မှုနည်းသော protocol ကို ကိုင်တွယ်ရသည့် စွန့်စားရမှုတို့သည် ဒီဇိုင်းလှပမှုထက် ပိုမိုဆိုးကျိုးများပါလိမ့်မည်။ ဖိအားများကြားတွင် အင်ဂျင်နီယာများ troubleshoot လုပ်နိုင်သော protocol သည် နည်းပညာအရ အနည်းငယ်သာလွန်သော်လည်း မပြင်ဆင်နိုင်သော protocol ထက် များစွာ ပိုမိုတန်ဖိုးရှိပါသည်။
IS-IS တွင် Dual-stack သည် OSPF ထက် အဘယ်ကြောင့် ပိုမိုရိုးရှင်းသနည်း။
IS-IS သည် IPv6 ကို instance တစ်ခုတည်းအတွင်း TLV အဖြစ် သယ်ဆောင်ထားသဖြင့် protocol တစ်ခုတည်း၊ adjacency တစ်ခုတည်းနှင့် database တစ်ခုတည်းသာ ရှိသည်။ OSPF တွင်မူ OSPFv2 နှင့်အတူ OSPFv3 ကိုပါ တပြိုင်နက် run ရသဖြင့် လမ်းကြောင်းကွဲလွဲနိုင်သော၊ သီးခြားစီ စစ်ဆေးရမည့် သီးခြား protocols နှစ်ခု ဖြစ်လာသည်။
Single-topology IS-IS dual-stack တွင် မည်သည့်အရာ ပျက်စီးနိုင်သနည်း။
၎င်းသည် link တိုင်းတွင် protocol နှစ်မျိုးစလုံး ရှိသည်ဟု ယူဆကာ families နှစ်ခုစလုံးအတွက် shortest-path tree တစ်ခုတည်းကိုသာ တွက်ချက်သည်။ အကယ်၍ link အချို့သည် IPv4 သာရှိပါက IPv6 traffic များသည် ထို link များပေါ်သို့ လမ်းကြောင်းလွဲရောက်ရှိသွားပြီး black-hole ဖြစ်သွားနိုင်သည်။ Multi-topology ကမူ family တစ်ခုစီအတွက် သီးခြား tree တွက်ချက်ပေးသဖြင့် ဤပြဿနာကို ရှောင်ရှားနိုင်သည်။
VXLAN-EVPN fabric အတွက် IGP ရွေးချယ်မှုသည် အရေးပါပါသလား။
သိပ်မအရေးပါပါ။ Underlay သည် loopback တိုင်းကို ရောက်ရှိနိုင်ရန်သာ လိုအပ်ပြီး ပုံမှန်အားဖြင့် point-to-point links များပါဝင်သော single flat area တစ်ခုသာ ဖြစ်သည်။ Protocol နှစ်ခုစလုံးက တူညီစွာ ကောင်းမွန်စွာ လုပ်ဆောင်နိုင်သောကြောင့် ဆုံးဖြတ်ချက်သည် လုပ်ငန်းခွင် ရင်းနှီးကျွမ်းဝင်မှုအပေါ်သာ မူတည်ပါသည် — သို့မဟုတ်ပါက IGP ကို လုံးဝချန်လှပ်ပြီး underlay အဖြစ် eBGP ကို အသုံးပြုနိုင်သည်။
ဆက်လက်လေ့လာရန် (Where to go next)¶
နောက်ဆက်တွဲ phase တိုင်းက အခြေပြုမည့် အသိပညာများကို သင် ယခု ရရှိပြီးဖြစ်ပါသည်။
| နောက်တစ်ခု | ဤအခြေခံပေါ်တွင် မည်သို့ တည်ဆောက်ထားသနည်း |
|---|---|
| Phase 1 · BGP | IGP က ရောက်ရှိနိုင်အောင် လုပ်ဆောင်ပေးထားသော loopbacks များပေါ်တွင် iBGP peers များ ဖွဲ့စည်းသည် |
| Phase 3 · MPLS | LDP သည် IGP မှ သင်ယူရရှိသော prefixes များနှင့် labels များကို တွဲချိတ်ပေးသည် — route မရှိပါက label လည်း မရှိနိုင်ပါ |
| Phase 4 · EVPN | VTEPs များသည် IGP မှ ကြေညာထားသော loopbacks များမှတစ်ဆင့် tunnels များ တည်ဆောက်သည် |
ထို့ပြင် အားလုံးတွင် အသုံးချရမည့် စည်းမျဉ်းတစ်ခုမှာ — Overlay ကို troubleshoot မလုပ်မီ Underlay ကောင်းမွန်ကြောင်း အရင်ဆုံး သက်သေပြပါ။ "Overlay ပျက်စီးနေသည်" ဟူသော တိုင်ကြားချက် အားလုံးနီးပါးသည် အမှန်စင်စစ် လမ်းကြောင်း (route) ပျောက်ဆုံးနေခြင်းက မျက်နှာဖုံးစွပ်ထားခြင်းသာ ဖြစ်တတ်သည်။