Router on a stick

CCNA/NP လေ့လာနေသူတစ်ယောက်အတွက် Router on a stick ဆိုတာကိုသိထားသင့်ပါတယ်။ Configuration ပိုင်းအရလဲ လွယ်ကူပြီး လက်တွေ့မှာလဲ အသုံးဝင်တဲ့အတွက် ပေါ်ပြူလာဖြစ်တဲ့ Setup တစ်ခုလဲဖြစ်ပါတယ်။ Small Office Setup တွေမှာ အသုံးအများဆုံးပါ။ ဒီဟာကို အသုံးပြုဖို့အတွက် ဘာတွေသိထားသင့်သလဲဆိုတာ လေ့လာကြည့်ရအောင်။

အရင်ဆုံး VLAN ဆိုတာကို နားလည်ထားရပါမယ်။ Router on a stick ရဲ့အဓိကလုပ်ဆောင်ပေးတာက VLAN တွေကိုဆက်သွယ်ပေးတာဖြစ်ပါတယ်။ Inter Vlan Routing ဆိုပါတော့။ VLAN တွေခွဲထားပြီးပြီဆိုရင် အဲဒီ VLAN တွေ တစ်ဖက်နဲ့တစ်ဖက် ဆက်သွယ်ဖို့ရာအတွက် Layer 3 Interface လိုအပ်ပါတယ်။ ပုံမှန်ဆိုရင် VLAN  တစ်ခုစီရဲ့ Layer 3 Interface နဲ့ Physical port တွေကိုချိတ်ဆက်ရပါတယ်။ ဥပမာ VLAN ၃ခုအတွက်ဆိုရင် Physical Port ၃ခုလိုပါတယ်။ Router on a stick ကအဲဒီ Physical port ၃ခုအစား Port တစ်ခုကိုပဲ အသုံးပြုလိုက်ပါတယ်။ ဒါကြောင့် သူကို One-armed Router setup လို့လဲခေါ်ပါတယ်။ Physical port တစ်ခုရဲ့အောက်မှာ လိုအပ်သလောက် Sub-Interfaces တွေကို ခွဲပြီး သုံးလိုက်တာဖြစ်ပါတယ်။

ဒါဆို Router နဲ့ Switch ကြားမှာ ဘယ်လိုချိတ်ဆက်ရမလဲဆိုရင်တော့ Trunk အနေနဲ့ ချိတ်ရမှာဖြစ်ပါတယ်။ ဒီတော့ Trunk ဆိုတာနဲ့ 802.1Q အကြောင်းကို နားလည်းထားရပါမယ်။ ဒါမှသာ Sub-Interfaces တွေမှာသုံးတဲ့ encapsulation ဆိုတဲ့ Command နဲ့ အနောက်ကတွဲသုံးမဲ့ VLAN ID တွေရဲ့ အကြောင်းကို နားလည်မှာဖြစ်ပါတယ်။ Router on a stick setup မှာပါဝင်မဲ့ ပစ္စည်းအနေနဲ့ Router တစ်လုံး၊ Switch တစ်လုံးပါပဲ။ Switch တစ်ခုထက်ပိုလာရင်လဲ အဲဒီနောက်ထက်ချိတ်ဆက်လာမဲ့ Switch ဟာ အရင်ရှိပြီးသား Switch ကို Trunk အနေနဲ့ လာပြီးချိတ်ဆက်ရမှာဖြစ်ပါတယ်။ Router ကိုသွားချိတ်ဆက်စရာမလိုပါဘူး။ ချိတ်ဆက်လို့လဲမရပါဘူး။ ဘာဖြစ်လို့လဲဆိုရင် Router မှာ ရှိတဲ့ Interface တစ်ခုစီဟာ မတူညီတဲ့ Network အောက်မှာပဲရှိရပါတယ်။ Interfaces တွေကို Network တစ်ခုထဲအောက်မှာ အသုံးပြုချင်ရင် Bridge Group နဲ့တွဲသုံးရပါတယ်။

ဒီနေရာမှာ Router ကဘယ်လိုအလုပ်လုပ်လဲ၊ Routing ဆိုတာဘာလဲသိဖို့လိုလာပြန်ရော။ ဒီ VLAN တွေ Inter VLAN Routing လုပ်ဖို့ Routing ရေးဖို့လိုအပ်သလား၊ Dynamic Routing protocol တွေကို အသုံးပြုဖို့လိုသလားဆိုရင်တော့ မလိုအပ်ဘူးလို့ပြောရပါမယ်။ အဲဒီ Sub-Interfaces တွေဟာ Connected Routes တွေအနေနဲ့ ရှိနေမှာဖြစ်ပြီး Router ဟာ သူရဲ့ တိုက်ရိုက်ချိတ်ဆက်ထားတဲ့ Network တွေကို ဘယ်လိုသွားရမလဲဆိုတာ သိပါတယ်။ မေးစရာ ရှိလာတာက ဒီအလုပ်ဟာ Layer 3 Switch လဲ လုပ်လို့ရတာပဲ၊ အပေါ်က Router သုံးစရာလိုသေးလို့လားဆိုခဲ့ရင် YES and NO လို့ပဲဖြေရမှာပါ။ Inter VLAN Routing သီးသန့်အတွက်သုံးမယ်ဆိုရင်တော့ NO ပါ၊ Router ထပ်သုံးနေစရာမလိုပါဘူး။ ဒါပေမယ့် တကယ့်အပြင်မှာ Inter VLAN Routing ပဲသီးသန့်သုံးတာမဟုတ်ပဲ UPlink လို့ခေါ်ကြတဲ့ Internet Port/ Intranet(WAN) Port တွေကိုပါချိတ်ဆက်ပြီးသုံးလေ့ရှိပါတယ်။ ဒါမှာသာ အဲဒီNetwork သာ တခြားNetwork တွေကို သွားနိုင်မှာပါ။ ဒီလိုအခြေအနေမျိုးအတွက်ဆိုရင်တော့ YES ပါ။ ဥပမာ Internet ကိုချိတ်ဆက်ဖို့အတွက် NAT အသုံးပြုရတော့မယ်ဆိုပါစို့။ L3 Switch ဟာ NAT မလုပ်ပေးနိုင်ပါဘူး။

Configuration ပိုင်းအရကြည့်ရင် Switch မှာ VLAN ခွဲ၊ Trunk Port လုပ်၊ Router မှာ Sub-Interfaces တွေခွဲ၊ IP ပေးပြီး Switch ရဲ့ Trunk port ကိုချိတ်လိုက်ရင်ပြီးသွားပါပြီ။ ဒါပေမယ့် သူအသုံးပြုသွားတဲ့ နည်းပညာတွေကို ဆက်စပ်ပြီးလေ့လာမယ်ဆိုရင် စိတ်ဝင်စားဖို့ကောင်းတာကိုတွေ့ရပါလိမ့်မယ်။ ဒီလင့်ထဲမှာ အဲဒီ Configuration ကို စိတ်ရှည်လက်ရှည်နဲ့ ရှင်းပြထားတာတွေ့ပါတယ်။

https://learningnetwork.cisco.com/docs/DOC-23481





ကိုဖြိုး

ISSU

IOS Upgrade လုပ်ကြမယ်လို့ဆိုလိုက်တိုင်း ခေါင်းခဲရတာကတော့ Operations ဖက်မှာ အလုပ်လုပ်တဲ့ Network Admin တွေပေါ့။ အထူးသဖြင့် Core Router/Switch လိုမျိုးအဓိကကျတဲ့ နေရာမျိုး။ မပြောင်းခင် ပြင်ဆင်ရတာက တစ်မျိုး၊ ပြောင်းမဲ့အချိန် Maintenance Window နဲ့ သက်ဆိုင်တဲ့လူတွေနဲ့ ညှိရတာတစ်မျိုး၊ စီစဉ်ရတာမလွယ်ဘူး။ ပြီးတော့ ပြောင်းပြီးတဲ့အခါ အဆင်မပြေလို့ ပြန်ပြောင်းရတဲ့ (Fall-back) ကိစ္စတွေကရှိသေးတယ်။ ပြောရမယ်ဆိုရင် လွယ်တယ်လို့ထင်ရတဲ့ အလုပ်ပေမဲ့ တစ်ကယ်တမ်းကြတော့ သိပ်မလွယ်ပါဘူး။ နောက်တစ်ခုက ကြာချိန်ပေါ့ Down time ကနဲနိင်သမျှနဲမှရမှာ၊ Customer တွေကတော့ Down-time ဆို မရှိရင်အကောင်းဆုံးပဲလို့ပဲ သတ်မှတ်မှာပဲ။ ဒီတော့ Maintenance Window နဲ့ Downtime ကို အနဲဆုံးရအောင်စီစဉ်ရပါတယ်။ ဒါကြောင့်လဲ Redundancy တွေ၊ HA တွေ၊ Active-Passive တွေ စသဖြင့် အသုံးပြုရတာပေါ့။

အဲဒါတွေအပြင် ISSU လို့ခေါ်တဲ့ In-Service Software Upgrade က IOS Upgrade လုပ်တဲ့အချိန်မှာ Downtime အနဲဆုံးဖြစ်အောင်၊ မရှိအောင် router/switch တွေကို Reboot လုပ်စရာမလိုပဲ Upgrade လုပ်ပေးပါတယ်။ နည်းပညာလို့ဆိုတာထက် Procedure လို့ဆိုရင်ပိုမှန်ပါလိမ့်မယ်။ ဘာလို့လဲဆိုတော့ သူတကယ်အသုံးပြုသွားကတော့ NSF (Non-stop Forwarding) နဲ့ SSO (State-full Switch Over) ပါ၊ အဲဒါကို Redundant Route Processor ဒါမှမဟုတ် Redundant Supervisor Engine တို့နဲ့ တွဲသုံးထားတဲ့ Procedure ပါ။ မြင်သာအောင် ပြောရရင်တော့ Upgrade/Downgrade လုပ်နေတဲ့ အချိန်မှာ Packet forwarding ကိုမထိခိုက်စေတဲ့ လုပ်ဆောင်မှု ဆိုပါတော့။ Redundant RP/ Sup-Engine မရှိရင်တော့ မရပါဘူး၊ ဒါကိုကြည့်ရင် Router/switch အသေးလေးတွေမှာ မရဘူးဆိုတဲ့သဘောပါ။ အဓိက နေရတွေမှာ အသုံးပြုတဲ့ Modular Core Router/ Core Switch တွေမှသာ အသုံးပြုလို့ရနိုင်ပါလိမ့်မယ်။

သူကဘာလုပ်ပေးလဲဆိုရင်တော့ အရင်ဆုံး အသုံးပြုမဲ့ IOS ကို Active ကော၊ Standby မှပါ ထည့်ထား၊ ပြီးရင် Standby မှာ အဲ့ဒီ IOS အသစ်ကို ပြောင်း၊ ပြောင်းပြီးရင် Active/Standby ကို Switch-over လုပ်၊ ဒီတော့ အရင် Active က Standby အဖြစ်ပြောင်းသွားပြီး Active အသစ်က IOS အသစ်နဲ့တက်လာမှာဖြစ်ပါတယ်။ နောက်တော့မှာ အရင် Active အဟောင်း(လက်ရှိ Standby ဖြစ်သွားတဲ့) ကို IOS အသစ်ပြောင်း လိုက်တာပါ။ ဒါများ ဘာဆန်းလို့လဲဆိုရင်တော့ အဲဒီလိုအပြောင်းအလဲလုပ်နေတဲ့ အချိန်အတွင်းမှာ Packet forwarding ကိုမထိခိုက်ပဲ Downtime/Outage ကိုနဲသွားစေတာပါပဲ၊ နောက်တစ်ခုကတော့ အဆင်မပြေလို့ပဲဖြစ်ဖြစ်၊ ဆက်မလုပ်ချင်တော့ပဲဖြစ်ဖြစ် တစ်ဝက်လောက်ကနေ Auto-Rollback ပြန်လုပ်နိုင်တာပါပဲ။ ပုံမှန်အတိုင်းလုပ်မယ်ဆိုရင် အဆင်မပြေမှ ပြန်ပြောင်းရင် နောက်ထပ် Reboot တစ်ကြိမ်အတွက် အချိန်ထပ်ပေးရမယ်၊ Module တွေများရင်များသလို ကြာချိန်ပိုလိမ့်မယ်။ နောက်တစ်ခုအနေနဲ RP/Sup-Engine ကတော့ ဟုတ်ပီ Line card/ Module ကောဆိုရင်တော့ MDR လို့ခေါ်တဲ့ Minimum Disruption Restart က Ports တွေကိုအတက်အကျ(Flapping) မဖြစ်စေပဲ အသစ်တက်လာတဲ့ IOS နဲ့ ကိုက်ညီအောင် Upgrade လုပ်ပေးသွားပါလိမ့်မယ်။

Command အနေနဲ့ သိပ်အခက်ခဲမရှိပဲ ကြည့်ပြီးလိုက်လုပ်ရင် အဆင်ပြေနိုင်ပါတယ်၊ အဓိက ကတော့ Planning ပါ။ သူ့ကိုအသုံးပြုဖို့ရာအတွက် လိုအပ်ချက်တွေဖြစ်တဲ့ Redundant RP/Sup-Engine တွေနဲ့ Active RP/Sup-Engine တွေရဲ့ သုံးထားတဲ့ IOS တူဖို့၊ အရင်အသုံးပြုထားတဲ့ IOS ဟာအသစ်အသုံးပြုမဲ့ IOS ကိုတိုက်ရိုက် Upgrade လုပ်လို့ရမရ၊ ပြီးရင် SSO mode စတာတွေကို အသေးစိတ်ပြင်ဆင်ထားဖို့လိုအပ်ပါတယ်။ သူ့ရဲ့ Process Flow ကို Cisco Documentation တွေမှာပြထားတဲ့ ပုံတွေကို ကြည့်ရင်ပိုပြီးရှင်းသွားပါလိမ့်မယ်။ ဒါကို အသုံးပြုချင်းအားဖြင့် Network Admin ရဲ့အားစိုက်ထုတ်ရမှုကတော့ လျော့သွားမှာ မဟုတ်ပါဘူး၊ ဒါပေမယ့် Maintenance Window အတွင်းမှာ ဖြစ်ပေါ်နိုင်တဲ့ ပြတ်တောက်မှု၊ Downtime ကိုနဲသွားစေပြီး၊ Fallback လုပ်ဖို့ လိုအပ်လာတဲ့ အခြေအနေမျိုးမှာ အချိန်ကို ပိုမိုပြီး အသုံးချလို့ရမှာဖြစ်ပါတယ်။

 

ကိုဖြိုး