WireShark

Network Admin တစ်ယောက်ဖြစ်လာပြီဆိုရင် တစ်ချိန်မဟုတ်တစ်ချိန် ကြုံတွေ့ရမှာကတော့ Application Layer issue တွေပါပဲ။ အထူးသဖြင့် Network Operation ပိုင်းမှာ အလုပ်လုပ်သူအများစုပေါ့။ Implementation သမားတွေကြတော့ တပ်ဆင်ပြီးသွားရင် သူတို့အပိုင်းကပြီးပြီလေ။ နေ့စဉ်အသုံးပြုတဲ့ ကိစ္စတွေ၊ User/Customer တွေနေ့တိုင်းအသုံးပြုရာမှာ ကြုံတွေ့လာမဲ့ အခက်အခဲတွေ၊ အဆင်မပြေဖြစ်တာတွေကြတော့ Operation ဖက်ကသူတွေက ပိုပြီးဖြေရှင်းပေးရလေ့ရှိပါတယ်။ ဥပမာအားဖြင့် Application နှေးနေတာတို့၊ ဖိုင်ကူးနေရင်းပြတ်သွားတာတို့၊ (Intermittent) ရလိုက်မရလိုက်ဖြစ်နေတာတို့ စသဖြင့်ပေါ့။ ဒါမျိုးတွေဖြစ်လာပြီဆိုရင် Router/Switch တွေက Show command တွေသုံးရုံနဲ့ အဖြေရှာဖို့သိပ်မလွယ်တော့ဘူး။ တခြားအကူအညီတွေလိုလာပြီ။ Application/ Protocol Level အထိလိုက်ကြည့်ရတော့မှာ။ ဒီလိုနေရာမှာ Protocol Analyzer ဆိုတာကို အသုံးပြုမှသာ ဘယ်မှာဘာဖြစ်နေတယ်ဆိုတာကို TCP/UDP flows တွေကိုလိုက်ကြည့်ရင်းနဲ့ အဖြေထုတ်ရတော့မှာဖြစ်ပါတယ်။

အခုလိုကိစ္စတွေ အတွက်သိထားသင့်တဲ့ Tools တစ်ခုကတော့ WireShark ပါ။ အရင်က Etherreal အနေနဲ့ လူသိများခဲ့ပြီး နောက်ပိုင်းမှာ WireShark ဆိုပြီးပြောင်းသွားပါတယ်။ နာမည်ပြောင်းသွားသလို လုပ်ဆောင်မှုတွေလည်းပိုပြီးကောင်းလာပါတယ်။ ကျွန်တော့သူငယ်ချင်းတစ်ယောက်ပြောသလို ပြန်ပြောရရင် ငါးလေးတွေ ငါးကန်ထဲမှာကူးခတ်နေတာကို မြင်နေရသလို Data တွေ Wire အထဲမှာ ဘယ်လိုသွားနေသလဲဆိုတာကို မြင်နိင်ပါတယ်။ WireShark နဲ့တွဲပြီးပါလာတာကတော့ Winpcap ပါ၊ တွဲပါလာတယ်ဆိုတာထက် အဲဒါပါမှသုံးလို့ရတာဖြစ်ပါတယ်။ Hardware level အထိဆင်းသုံးဖို့လိုအပ်တဲ့ libraries Set တွေပါ။ အဲဒါကိုထုတ်တဲ့အဖွဲ့အစည်းက Cacetech ပါ။ ဒါပေမယ့် သူ့ကိုအခုနာမည်ကြီး တစ်ခုဖြစ်တဲ့ Riverbed ကဝယ်ထားပါတယ်။ Wireshark ကိုအခုအဓိက အထောက်အပံ့ပေးနေတာလဲ Riverbed ပါပဲ။ Riverbed product တွေရဲ့ အားသာချက်ဖြစ်တဲ့ Application level control တွေဟာ အရမ်းကောင်းပါတယ်။ Report တွေဆိုရင်လည်း ခုနကပြောသလိုငါးဘယ်နှစ်ကောင် ကန်ထဲမှာရှိလဲ ဘယ်အရောင်ကဘယ်နှစ်မျိုးဆိုတာမျိုးကို ပြောနိုင်လောက်တဲ့အထိ Application တွေကိုပြောပြနိင်ပါတယ်။ CACE ရဲ့နည်းပညာအထောက်အကူကြောင့်လို့ဆိုရင်လဲ မမှားပါဘူး။ ကျွန်တော့်အထင်သက်သက်ပါ။

Wireshark အတွက် OS platform အမျိုးမျိုးရှိပါတယ်။ ကိုယ်တိုင်အနေနဲ့တော့ Linux ပေါ်မှာ Ethereal အနေနဲ့သုံးခဲ့ဖူးပြီး၊ Wireshark အနေနဲ့ကတော့ Windows ပေါ်မှာပဲ သုံးဖြစ်ပါတယ်။ Application Install လုပ်ပြီးတာနဲ့ တန်းသုံးလို့ရပါပြီ။ Default အနေနဲ့ အသုံးပြုရတာတော့ အခက်အခဲသိပ်မရှိပဲ တခြား Filter တွေဘာတွေသုံးမှသာ သေချာလေ့လာဖို့လိုပါတယ်။ သူ့အနေနဲ့ ပြဿနာကိုဖြေရှင်းပေးတာမဟုတ်ပဲ Network အထဲမှာဘာတွေဖြစ်နေတယ်ဆိုပဲဖော်ပြပေးပါမှာပါ။ ကျန်တာက Network Admin ရဲ့အပိုင်းပါ။ Admin ရဲ့ Network Knowledge ရှိသလောက် အထောက်အကူဖြစ်ပါတယ်။ ငါးအလှမွေးဆိုင်က ရောင်းတဲ့သူတစ်ယောက်လိုပေါ့ ကန်ထဲမှာ ငါးပေါင်းစုံရှိနေတဲ့ အထဲက ဘယ်ငါးကဘာအမျိုးအစား ဘယ်လောက်တန် တန်းသိနေသလိုပေါ့။ မကျွမ်းကျင်တဲ့ သူအဖို့တော့ ငါးတွေမြင်နေရပေမယ့်လည်း ဆိုတေးဆိုတာဘာရောင်မှန်းမသိ၊ ရွှေငါးလား ပုလဲငါးလား မသိလိုဖြစ်နေမှာ။ ဒီတော့ TCP/UDP Flows တွေ တွေ့နေပေမယ့် TCP Hand shake လောက်ကို Trace မလိုက်နိုင်ရင် ဘာဖြစ်နေလဲဆိုတာ သိဖို့မလွယ်ပါဘူး။ Telnet application အလုပ်လုပ်တဲ့အခါ Client နဲ့ Server ဘယ်လိုစကားပြောလဲဆိုတာမျိုး၊ DHCP client တွေဘယ်လိုပုံစံမျိုးနဲ့ IP address တောင်းဆိုကြသလဲ စတာတွေကို Wireshark သုံးပြီးကြည့်လိုက်ရင် သီအိုရီတွေဖတ်တုန်းကနားမလည်တွေတောင် ပြန်ပြီးရှင်းသွားပါလိမ့်မယ်။

ဟုတ်ပီ။ ညွှန်းတာတွေတော့များနေပြီ ဘယ်လိုကြည့်ရမလဲလုပ်အုံးဆိုရင်တော့ ကိုယ့်ရဲ့ PC NIC ကို promiscuous mode ကိုရွေးလိုက်ပြီး Capture လို့လုပ်လိုက်တာနဲ့ စတွေ့ရမှာပါ။ ဒါပေမဲ့ ကိုယ့်ရဲ့ NIC ကမြင်ရတဲ့ Data တွေကိုသာမြင်ရမှာဖြစ်ပါတယ်။ Network အတွင်းကတခြားဟာတွေမြင်ချင်ရင်တော့ Switch မှာ ကိုယ်ကြည့်ချင်တဲ့ Source port ကိုရွေး၊ Mirror port/ SPAN port စတာတွေလုပ်ပြီးကိုယ့် NIC ကို Destination port မှထားသုံးလိုက်ရင်ရပါပြီ။ ဒီနေရာမှာ ဆက်စပ်ပြီးလေ့လာရမှာ၊ လေ့လာခဲ့ဖူးတာတွေကို ပေါင်းစပ်ပစ်ရတော့မှာ။ အရင်က SPAN အကြောင်းလေ့လာတုန်းက Source port Destination port ဆိုပြီးသိခဲ့တယ်။ အခုအဲ့ဒါကို အသုံးပြုတာက Wireshark လို Protocol Analyzer/ Packet sniffer တွေပါပဲ။ ဒါသုံးဖို့တော့ ဘာမှထွေထွေထူးထူးမလိုပါဘူး။ အခုပဲ Download လုပ် Install လုပ်ပြီး ကိုယ့် PC/Laptop က NIC မှာဘာတွေမြင်ရသလဲဆိုတာတာ ကြည့်လိုက်ကြပါစို့။ SPAN ဆိုတာဘာလဲသိချင်ရင်တော့ ကျွန်တော့အရင်ပို့စ် အဟောင်းတွေမှာ ပြန်ရှာဖတ်ကြည့်နိုင်ပါတယ်။ 



ကိုဖြိုး

VSS Dual-Active

VSS အကြောင်းပြောရင် Dual-active ကိစ္စကိုထည့်ပြောဖို့လိုအပ်ပါတယ်။ Dual-active detection configuration မပါတဲ့ VSS Setup ဟာတစ်နေ့တစ်ချိန်မှာ ပြဿနာအကြီးကြီးဖြစ်ပေါ်အောင် ဖန်တီးထားသလိုနဲ့တူပါလိမ့်မယ်။ VSS ပြုလုပ်ပြီးတဲ့အချိန်မှာလည်း အဲဒီ Dual-active detection ဟာ တကယ်အလုပ်ဖြစ်မဖြစ် စမ်းသပ်ကြည့်ဖို့လိုပါတယ်။ ဒါမှသာ ပြဿနာဖြစ်လာရင် ကိုယ်တွက်ချက်မှန်းဆထားတဲ့အတိုင်း ဖြစ်လာမှာပါ။ ဒီတော့ Dual-Active ဆိုတာဘာလဲ ဘာကြောင့်ဖြစ်ရလဲဆိုတဲ့ ကိစ္စကို အရင်သိထားမှဖြစ်မယ်။ VSS ဟာ Catalyat Switch နှစ်လုံးကိုပေါင်းစပ်ထားတဲ့ Virtual System ဖြစ်ပြီး Control ပိုင်းကိုတစ်လုံးက Active အနေနဲ့ ထိန်းချုပ်ပြီး Switch နှစ်ခုစလုံးက Line Card တွေကိုအသုံးပြုတာဖြစ်တဲ့အတွက် ဘယ်သူက Active Control လဲဆိုတာ အဓိကပါ။ Line card တွေအနေနဲ့တော့ အကုန်လုံး Active ပါပဲ။ ဒီနေရာမှာ VSL ကအသက်ပါ။ VSL ပြတ်သွားရင် အရင်စီစဉ်ထားတဲ့ အတိုင်း ဘယ်သူက Active ဘယ်သူက Standby အနေနဲ့ ရှိမနေတော့ပဲ နှစ်လုံးစလုံးက Active Control ဖြစ်လာပြီး ကျန်တဲ့ Stanby ပျောက်သွားတယ်ဆိုပြီး ယူဆမှပါ။ သူတို့အနေနဲ့တော့ ဘာမှမဖြစ်ပေမယ့် အောက်ကချိတ်ဆက်ထားတဲ့ Router တွေ၊ Switch တွေ၊ Server တွေအဖို့ကတော့ ပြဿနာဖြစ်လာပါပြီ။

အဲဒီလိုအချိန်မျိုးမှာ သူတို့ကိုပြန်ပြီး အသိပေးဖို့အတွက် Dual-active detection ကိုအသုံးပြုရပါတယ်။ Network ထဲမှာ ဆရာနှစ်ယောက်ဖြစ်နေပြီ၊ ကျန်တဲ့သူတွေ ဘယ်သူ့ဆရာခေါ်ရမလဲ မသိတော့ဘူး တစ်ခုခုတော့လုပ်အုံးဆိုပြီး ပြောပေးရပါတယ်။ ဒါပေမယ့် သူရဲ့သဘာဝအရ Standby အနေနဲ့ နေလာတဲ့သူက Active အဖြစ်ဆုပ်ကိုင်ထားပါတယ်။ သူ့ဖက်ကကြည့်ရင် ပထမ ဆရာလုပ်တဲ့သူကတော့ ပြန်တက်လာပြီ ဒါပေမယ့် Network တည်ငြိမ်ရေးအတွက် ငါ့မှာတာဝန်ရှိတယ် Standby အနေနဲ့ ပြန်မဆင်းပေးနိုင်ဘူးပေါ့။ အရင် Active အဖြစ်နေလာတဲ့ သူကတော့ ကြားက VSL ပယောကကြောင့် ငါတော့ ခံလိုက်ရပြီ ပြန်လည်နေရာယူဖို့ချက်ချင်းတော့မဖြစ်သေးဘူးဆိုပြီး Recovery mode ကိုပြောင်းလိုက်ပါတယ်။ အခြေအနေကောင်းပြီဆိုမှ ကိုယ်တိုင် Reboot လုပ်လိုက်ပြီး ပြန်လည်ဝင်ရောက်ဖို့ကြိုးစားရပါတယ်။ ဒါပေမယ့် သူ့အနေနဲ့ Standby mode ကိုသာ ပြန်ရရှိနိုင်ပါတယ်။ လက်ရှိ Active ယူထားတဲ့ သူကလည်း Network တည်ငြိမ်ရေး အကြောင်းပြပြီး Priority အနိမ့်အမြင့်တွေရေးထားပေမယ့် ဂရုမစိုက်ပဲ Active အနေနဲ့သာ ဆက်ယူထားပါတယ်။

ဒီအချိန်မှာ အရင်က ဆရာလုပ်ခဲ့တဲ့သူက Active ပြန်ဖြစ်ဖို့ရာအတွက် အနုနည်းပဲသုံးရပါတယ်။ လက်ရှိ Active ဖြစ်နေတဲ့သူကို ပြေပြေလည်လည် လွှဲပြောင်းပေဖို့ အကူအညီတောင်းရပါတယ်။ ဘာလို့လဲဆိုတော့ Standby conole ကနေဘာမှလုပ်လို့မရလို့ပါ။ လက်ရှိ Active console ကိုင်ထားတဲ့သူကသာ Command တွေသုံးလို့ရတာပါ။ ဒါမှမဟုတ် အကြမ်းနည်းနဲ့ VSL ဆွဲဖြုတ်၊ Power ဆွဲပိတ်လုပ်ရင်တော့ ရတာပေါ့၊ ဒါပေမယ့် ခံရမဲ့သူတွေက ကိုယ်တိုင်မဟုတ်ပဲ အောက်က ကိုယ့်ကိုချိတ်ဆက်ထားတဲ့သူတွေဖြစ်တဲ့ အတွက် ရင်ကြားစေ့ရေးနဲ့သာ အသုံးပြုသင့်ပါတယ်။ လက်ရှိ Active ယူထားတဲ့သူကို Redundancy force-swithover ဆိုတဲ့ Command ကိုအသုံးပြုပြီး Active control ကိုပြန်ယူရပါတယ်။ ဆင်းပေးရတဲ့သူကလည်း Standby mode ကိုတန်းသွားလို့မရပါဘူး အရင်ဆုံး ကိုယ်တိုင် Reboot လုပ်ပြီးမှ Standby အဖြစ်ပြန်တက်လာတာပါ။ ဒီတော့ သူကိုချိတ်ထားတဲ့ Server တွေ၊ Switch တွေအနေနဲ့ Network ပြတ်တောက်တာ ခဏတော့ ခံလိုက်ရအုံးမှာပါ။ အခုလို ဟိုပြောင်းဒီပြောင်းဖြစ်တဲ့ ကိစ္စတွေအတွက် အကြမ်းအားဖြင့် ၈မိနစ်၊ ၉ မိနစ်ခန့် ကြာပါတယ်။ အဲဒီဖြစ်နေတဲ့ အချိန်အတွင်းမှာ နှစ်ဖက်စလုံးကို ချိတ်ထားခြင်း မရှိတဲ့ သူတွေအဖို့တော့ Network ပြတ်တောက်တာနဲ့ ကြုံရမှပါ။ ဒါကြောင့် အရင်ရေးဖူးသလိုပဲ Dual-home/Dual-link မရှိတဲ့ server/router တွေအဖို့ VSS ရဲ့ အသုံးဝင်မှုကို ခံစားရမှာ မဟုတ်ပါဘူး။ Network ဖက်မှာတောင် ပါဝါအပြောင်းအလဲလုပ်ရတာ မလွယ်ပါဘူး၊ အပြင်မှာဆိုရင်တော့ စဉ်းစားသာ ကြည့်ပေတော့။ 

ဒါတွေကို အပြင်ကစောင့်ကြည့်သူဖြစ်တဲ့ Network Admin တစ်ယောက်အနေနဲ့တော့ နှစ်လုံးစလုံးမှာ Console တတ်ထားပြီး ကြည့်ရတာ အတော်ကြည့်ကောင်းပါတယ်။ အရင်မှတ်ထားတဲ့ Logs တွေထဲက အရေးပါတဲ့ အကြောင်းအရာတွေကို အောက်မှာ ပြထားပေးပါတယ်။

Dual-Active PAGP detection Log

%VSLP-SW1-2-VSL_DOWN:   All VSL links went down while switch is in ACTIVE role
%DUAL_ACTIVE-SW1-1-DETECTION: PAGP running on Te1/4/5 detected dual-active condition:
%DUAL_ACTIVE-SW1-1-RECOVERY: Dual-active condition detected: Starting recovery-mode, all non-VSL and non-excluded interfaces have been shut down

Dual-Active Fast-Hello Detection Log

%VSLP-SW1-2-VSL_DOWN:   All VSL links went down while switch is in ACTIVE role
%DUAL_ACTIVE-SW1-1-DETECTION: Fast-hello running on Gi1/2/1 detected dual-active condition
%DUAL_ACTIVE-SW1-1-RECOVERY: Dual-active condition detected: Starting recovery-mode, all non-VSL and non-excluded interfaces have been shut down
After the dual-active detection, it rebooted and went into recovery-mode

SW1(recovery-mode)#

VSL recovered and switch reloaded and back into Standby mode

%DUAL_ACTIVE-SW1-1-VSL_RECOVERED: VSL has recovered during dual-active situation: Reloading switch 1
%RF-SW1-5-RF_RELOAD: Shelf reload. Reason: dual-active

%SYS-SW1-5-RELOAD: Reload requested by Delayed Reload. Reload Reason: dual-active
SW1-sdby>
Standby console disabled
To switch-over to another switch

SW2#redundancy force-switchover
This will reload the active unit and force switchover to standby[confirm]
Preparing for switchover..


ကိုဖြိုး

New CCDP

Cloud တွေ၊ SDN တွေခေတ်စားလာချိန်မှာ Network သမားတွေကျဆုံးဖို့ အချိန်ရောက်လာပြီလား ဆိုပြီး မေးခွန်းတွေထွက်လာပါတယ်၊ တဖက်ကလည်း Cisco Exam များဟာ နောက်ဆိုသုံးမရတော့သလို ကိုယ်လိုရာဆွဲတွေးပြီး ပြောကြတာတွေလဲ နားထောင်ဖူးပါတယ်။ အဲဒီအချိန်မှာ ကျွန်တော်စဉ်းစားမိတာက Cisco ဟာ တော်ရုံနဲ့တဲ့ ဒီလမ်းကြောင်းပေါ်ကနေ အလွယ်တကူ ဆင်းသွားမှာ မဟုတ်ပါဘူး။ သူရဲ့ Certification တွေကို ဒီနည်းပညာအသစ်တွေနဲ့ ကိုက်ညီအောင် လိုက်လာပြီး ပြန်လည်ဆန်းသစ်လာမယ်လို့လဲ ယုံကြည်ထားပါတယ်။ ဒါကြောင့် အကြံညဏ်လာတောင်းတဲ့ ညီငယ်ညီမငယ်တို့တွေကိုလည်း ဒီလမ်းပေါ်ကို ရဲရဲသာ ဆက်လျောက်ဖို့အကြံပေးခဲ့ပါတယ်။

သိပ်အကြာကြီး မစောင့်လိုက်ရပါဘူး။ Cisco ဟာ အလျှင်အမြန်ပဲ နည်းပညာအသစ်တွေနောက်လိုက်ပြီးပြောင်းလဲလာပါတယ်။ အဓိက လက်မှတ်ဖြစ်တဲ့ CCIE မှာ အဲဒီအရာတွေကို မဖြစ်မနေလိုက်ဖြည့်ပါတော့တယ်။ CCIE စာမေးပွဲများပြောင်းလဲပြီးနောက်မှာ တခြားစာမေးပွဲတွေရဲ့ သွားနေတဲ့လမ်းကြောင်းကို ထပ်လေ့လာဖြစ်ပါတယ်။ အဲဒီထဲက တစ်ခုကတော့ ဒီဇိုင်းဘက်က CCDP Exam အကြောင်းပါ။ CCDP ဟာ ပရော်ဖက်ရှင်နယ်လက်မှတ်တွေထဲမှာ အထင်ကရလက်မှတ်တစ်ခုဖြစ်ပါတယ်။ အရင်က CCDE မပေါ်ခင်ကဆို သူဟာ ဒီဇိုင်းဖက်မှာ တစ်ခုတည်းသောလက်မှတ်တစ်ခုဖြစ်ပါတယ်။ Operations ဖက်က CCIE သမားတွေဦးဆောင်နေချိန်မှာ ဒီဇိုင်းဖက်ကိုလည်း အဆင့်မြင့်လက်မှတ်တစ်ခုလိုအပ်လာပြီဆိုပြီး CCDE ကိုမွေးထုတ်ခဲ့ပုံရပါတယ်။ ဒီအချိန်မှာတော့ CCDP ဟာ CCDE သွားချင်သူတွေအတွက် အထောက်အကူဖြစ်လာမဲ့ လမ်းကြောင်းတစ်ခုအနေနဲ့ပါ ပိုပြီးတော့ အရေးပါလာပါတယ်။

သူရဲ့ဆန်းသစ်လာတဲ့ ပုံစံတွေကို မြင်သာအောင်လို့ Cisco website ကနေ ကူးယူဖော်ပြထားပေးပါတယ်။ အသေးစိတ်ကို URL ကတစ်ဆင့်သွားကြည့်ပေါ့။ Cisco Press ကနေစာမေးပွဲအတွက်ထုတ်လေ့ရှိတဲ့ Exam certification guide လိုစာအုပ်မျိုးတော့ ထွက်လာတာတော့မတွေ့သေးပါဘူး။ သူရဲ့ Exam blueprint ကိုကြည့်ပြီး လေ့လာရမှာပါ။ မကြာခင်မှာတော့  ထွက်လာလိမ့်မယ်လို့ ထင်ပါတယ်။

http://www.cisco.com/c/en/us/training-events/training-certifications/certifications/professional/ccdp.html

Topics Removed from the ARCH Exam:

• Design for infrastructure services
• Identify network management capabilities in Cisco IOS Software
• Create summary-able and structured addressing designs
• Describe IPv6 for campus design considerations
• Describe the components and technologies of a SAN network
• Create an effective e-commerce design
• Create remote access VPN designs for the teleworker

Topics Added to the ARCH Exam:

• Create stable, secure, and scalable routing designs for IS-IS
• Determine IPv6 migration strategies
• Design data center interconnectivity
• Design data center and network integration
• Select appropriate QoS strategies to meet customer requirements
• Design end to end QoS policies
• Design a network to support Network Programmability (SDN)
• Describe network virtualization technologies for the data
• center

ကိုဖြိုး

VSS Configuration

VSS configuration ဟာသိပ်ပြီးတော့ရှုပ်ထွေးမှုမရှိပါဘူး။ Configuration ထက်စာရင် သူ့ကိုအသုံးပြုဖို့အတွက်ဘာတွေလိုအပ်သလဲ၊ ဘယ်လိုအလုပ်လုပ်သလဲ၊ တစ်ခုခုပြဿနာဖြစ်ရင် ဘယ်တွေကိုကြည့်ရမလဲ စတာတွေကိုပိုပြီးနားလည်ထားဖို့ပဲလိုပါတယ်။
စတင်ပြီး Configure လုပ်တဲ့နေရာမှာ အခြေခံအားဖြင့်ဆိုရင် VSS Domain တစ်ခုတည်ဆောက်၊ ပြီးရင် ဘယ်လင့်တွေကိုတော့ VSL အဖြစ်အသုံးပြုမယ်၊ ဘယ် Switch ကိုအဓိက Control အနေနဲ့သုံးမယ်ဆိုတာကို ထည့်ပေးရပါတယ်။ ပြီးရင် နဂိုအနေအထားကနေ Virtual switch အနေနဲ့ပြောင်းလဲပြီး Reload ကနေပြန်တက်လာရင် VSS အဖြစ် Configure လုပ်ပြီးပါပြီ။ ဒုတိယ Switch တက်လာပြီး VSL တက်သွားပြီ အချင်းချင်းတွေ့သွားပြီဆိုရင် VSS အဖြစ်စတင်ပြီးသုံးလို့ရပါပြီ။ Dual-active detection အတွက်ကိုတော့ နောက်မှထပ်ထည့်လဲရပါတယ်။

Configuration အတွက် Cisco best practice document ကိုကြည့်တာ အကောင်းဆုံးနဲ့ အပြည့်စုံဆုံးဖြစ်ပါလိမ့်မယ်။

http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Campus/VSS30dg/campusVSS_DG/VSS-dg_appa-configs.html

Convert လုပ်ပြီးတဲ့အခါမှာ Interface နံပါတ်တွေပြောင်းသွားတာကို တွေ့ရပါလိမ့်မယ်။ Switch 1 က Module/Interface တွေအရှေ့မှာ Switch number 1 ဆိုတာပါလာပြီး Switch 2 က Interface များမှာတော့ အရှေ့က 2 ဆိုတာပါလာပါလိမ့်မယ်။ ဒါကိုကြည့်လိုက်တာနဲ့ ဘယ် Switch မှာ ချိတ်ဆက်ထားတယ်ဆိုတာကို အလွယ်တကူတွေ့နိုင်ပါတယ်။ Convert လုပ်တဲ့ အချိန်မှာလည်း အခုလို သေချာပြထားပါတယ်။

sw1#switch convert mode virtual

This command will convert all interface names to naming convention "interface-type switch-number/slot/port",
save the running config to startup-config and reload the switch.

Convert လုပ်ပြီးသွားပြီ၊ ဒုတိယ Switch လည်းတက်လာပြီဆိုရင်တော့ VSS အခြေအနေကို စစ်ဆေးကြည့်ရပါမယ်။ ဒါကိုတော့ VSL Link အခြေအနေနဲ့ VSS role ကိုခေါ် ကြည့်လိုက်ရင် သိနိုင်ပါတယ်။ VSL status က တက်နေပြီ၊ Switch 2 ကိုမြင်နေရပြီဆိုရင် အခြေအနေကောင်းပါပြီ။

sw1#show switch virtual link
VSL Status : UP
VSL Uptime : 10 minutes
VSL SCP Ping : Pass
VSL ICC Ping : Pass
VSL Control Link : Te1/1/5 
VSL Encryption : Configured Mode - Off, Operational Mode - Off

sw1#show switch virtual
Switch mode                  : Virtual Switch
Virtual switch domain number : 1
Local switch number          : 1
Local switch operational role: Virtual Switch Active
Peer switch number           : 2
Peer switch operational role : Virtual Switch Standby

Module တွေအားလုံး တက်သွားပြီး အားလုံး Pass ဖြစ်သွားပြီဆိုရင်တော့ ကျန်တဲ့ Configuration ဖြစ်တဲ့ Port assignment တွေ၊ Routing တွေစပြီး ထည့်လို့ရပါပြီ။ Configure လုပ်တဲ့နေရာမှာ Active switch ကသာ လုပ်ဆောင်ရမှာဖြစ်ပါတယ်။ ဒုတိယ Switch Console ကတော့ အသုံးပြုလို့မရတော့ပဲ Disable အနေနဲ့ ရှိနေပါလိမ့်မယ်။

Standby console disabled

sw1-sdby>?Standby console disabled

ကိုဖြိုး

VSS

Cisco ရဲ့Network System Virtualization Technology ဖြစ်တဲ့ VSS (Virtual Switching System) ဆိုတာကို လေ့လာကြည့်ရအောင်။ VSS ဟာ Catalyst 6500/4500 တွေမှာအသုံးပြုလို့ရတဲ့ System Virtualization နည်းပညာဖြစ်ပါတယ်၊ ဒါပေမယ့် Cat65/45 အတိုင်းမှာ သုံးလို့တော့မရပါဘူး။ Switch တွေကို အဓိက ထိန်းချုပ်ထားတဲ့ Supervisor Engine အပေါ်မူတည်ပါတယ်။ VS Supervisor Engine တွေ ဥပမာ (VS-S720-10GE-3C / VS-S720-10GE-3CXL/ VS-SUP2T-10G) နဲ့သာ အသုံးပြုလို့ရမှာ ဖြစ်ပါတယ်။ ဒီ Switch တွေဟာ DC/Campus တွေရဲ့ Distribution Layer တွေမှာ အသုံးများတဲ့အတွက် အဲဒီနေရာတွေမှာ အလုပ်လုပ်နေတဲ့သူတွေအဖို့ သိထားသင့်တဲ့ နည်းပညာတစ်ခုပါ။

VSS ကဘာလုပ်ပေးလဲဆိုရင် အဲဒီ Cat65/45 နှစ်လုံးကို Virtual System တစ်ခုအဖြစ်ပေါင်းစပ်ပေးပါတယ်။ Modular Switch တွေမဟုတ်တဲ့ Cat37/36 တို့မှာ Stack လုပ်သလိုမျိုးပေါ့။ ပေါင်းစပ်ပြီးတဲ့အခါမှာ Management/Control plane ကိုတစ်ခုထဲအနေနဲ့တွေ့ရပြီး IP တစ်ခု၊ Console တစ်ခုထဲကပဲ ကိုင်တွယ်ရပါတယ်။ Standby Switch ရဲ့ Console ဟာ Lock ဖြစ်နေပြီး ဝင်လို့မရတာကိုတွေ့ရပါလိမ့်မယ်။ ဒါပေမယ့် Switch နှစ်ခုလုံမှာရှိတဲ့ Line card/ Modules တွေကတော့ တပြိုင်နက် အလုပ်လုပ်နေပြီး Switch ဒါမှမဟုတ် Module တစ်ခုခုဖြစ်သွားရင် ပြတ်တောက်သွားမှုနည်းအောင် SSO (Stateful Switchover) နည်းနဲ့ အချင်းချင်း Synced လုပ်ထားပါတယ်။ ဒီနေရာမှာ သတိထားသင့်တာက VSS ကိုလာရောက်ချိတ်ဆက်ထားတဲ့ Access Switch တွေ၊ Server တွေဟာ VSS ရဲ့ Member Switch နှစ်ခုစလုံးကိုချိတ်ဆက်ထားမှသာ SSO ရဲ့ ရလာဒ်ကိုခံစားရမှာပါ။ မဟုတ်ရင်တော့ Module ပျက်ရင် အဲဒီမှာချိတ်ထားတဲ့ Server/Switch ဟာလဲ ပြတ်တောက်သွားမှာဖြစ်ပါတယ်။

VSS ရဲ့ အဓိကအသက်ကတော့ သူတို့အချင်းချင်းကို ချိတ်ဆက်ထားပေးတဲ့ VSL ခေါ် Virtual Switch Link ဖြစ်ပါတယ်။ VSL ကိုအနဲဆုံးနှစ်လင့်လောက်အသုံးပြုသင့်ပါတယ်။ VSS Network မှာ VSL ပြတ်တောက်သွားရင် ပြန်တက်အောင်လုပ်ဖို့ သိပ်မလွယ်ပါဘူး။ ဘာလို့လဲဆိုရင် VSL မရှိတဲ့နောက်မှာ Member Switch တွေဟာ Dual-Active ဖြစ်သွားပြီးတော့ မမျှော်မှန်းထားတဲ့ ပြဿနာတွေ ဖြစ်လာတတ်ပါတယ်။ ဒါကြောင့် VSS မှာ Dual-active Detection ဖြစ်တဲ့ PAgP Detection တို့ Fast Hello Link တို့နဲ့ ထပ်ပြီးကူရပါတယ်။ ဒီတော့ အောက်ကသုံးထားတဲ့ Port Channel တွေရဲ့ Channel protocol တွေကိုရွေးချယ်မှုဟာလဲ အရေးပါပါတယ်။ ON mode သုံးထားရင်တော့ Fast Hello ကိုပဲသုံးရပါလိမ့်မယ်။ Dual-active detection ဖြစ်သွားရင် Active Switch က သူ့ရဲ့ Module တွေအားလုံးကို shutdown လုပ်လိုက်ပြီး Recovery mode ကိုရောက်သွားပါတယ်။ ဒီအချိန်မှာ သူ့ကိုချိတ်ထားတဲ့ Device တွေအကုန်လုံးဟာ ပြတ်တောက်သွားမှာဖြစ်ပါတယ်။ Standby Switch မှာချိတ်ထားတဲ့ Device တွေကတော့ ဆက်ပြီး အလုပ်လုပ်နေမှာဖြစ်ပါတယ်။ ဒါကြောင့် အထက်ကပြောခဲ့သလိုပဲ Member Switch နှစ်ခုလုံးမှာ ချိတ်ထားတဲ့ Device သာ VSS ရဲ့ အကျိုးကို ခံစားရမှာပါ။

Recovery mode ကနေ နဂိုအခြေအနေကိုပြန်ရောက်ဖို့အတွက် Force-Switchover ပြန်လုပ်ရမှာဖြစ်ပါတယ်။ VSS မှာ HSRP/VRRP တို့လို Preempt မပါပါဘူး၊ အရင်က ပါခဲ့ပေမယ့် Cisco က မသုံးဖို့ပြောပါတယ်၊ နောက်ပိုင်းမှာ မပါတော့ပါဘူး။ ဘာလို့လဲလို့လေ့လာကြည့်တဲ့အခါမှာ VSS Switchover လုပ်တဲ့အချိန်မှာ Active ကနေ Standby mode ကိုသွားမဲ့ Member switch ဟာ Reload ဖြစ်သွားပြီး နောက်ထပ်ပြတ်တောက်မှု တစ်ကြိမ်ထပ်ကြုံရပါတယ်။ HSRP တို့လိုအလျှင်အမြန်ပြောင်းသွားတာမဟုတ်ပါဘူး။ ဒါကြောင့် Cisco က မလုပ်စေချင်တာပါ။ VSS ကို Force-Switchover လုပ်ရင် သီးသန့် အချိန်ယူပြီးမှ (Maintenance Window) လုပ်သင့်ပါတယ်။ ဒါကြောင့် VSL ဟာအဲဒီ Network တည်ငြိမ်ဖို့အတွက် အရေးအကြီးဆုံးပါ။ ဒီနေရာမှာ မေးစရာရှိတာက ဒါလောက်တောင် ပြဿနာတွေရှိနေရင် ဘာကြောင့် VSS ကိုသုံးနေကြသေးလဲ ဆိုတဲ့ မေးခွန်းပါ။

အရင်ဦးဆုံးမြင်သာတာကတော့ MEC လို့ခေါ်တဲ့ Multichasis EtherChannel ပါ၊ အခုနောက်ပိုင်း Server တွေဟာ Switch တွေလိုပဲ PortChannel တွေလိုအပ်လာပါတယ်၊ VSS မရှိရင် Redundancy အနေနဲ့ MEC သုံးလို့မရပဲ Switch တစ်ခုထဲကိုပဲချိတ်ဆက်ပြီးသုံးရမှာ ဖြစ်ပါတယ်။ Nexus မသုံးနိင်သေးတဲ့ Network တွေမှာ VSS သာ အသုံးဝင်နေဆဲပါ။ ပြီးတော့ Virtual Switch တစ်ခုဖြစ်သွားတဲ့အတွက် အောက်ကလာရောက်ချိတ်ဆက်မဲ့ Switch တွေဟာ STP ရဲ့ တစ်ဖက်ပိတ်တဲ့ ကိစ္စကို ကျော်လွှားနိုင်ပြီး Bandwidth အနေနဲ့ ပိုမိုသုံးလို့ရလာမှာဖြစ်ပါတယ်။ နောက်တခါ Distribution Level မှာသုံးနေကျ HSRP/VRRP တို့လဲ မလိုတော့ပါဘူး။ Backplane bandwidth အနေနဲ့လဲ ပိုမိုများပြားလာပြီးတော့  SSO ကြောင့် Topology changes convergence တွေကိုသိပ်ပြီး မခံစားရတော့ပဲ ပြတ်တောက်မှုတွေကိုနည်းပါးစေပါတယ်။ ဒါ့အပြင် IOS upgrade လုပ်တဲ့အခါမျိုးမှာလဲ ISSU တနည်းအားဖြင့် eFSU Enhanced Fast Software Upgrade တို့ကိုသုံးပြီး ပြတ်တောက်ချိန်အနည်းဆုံးနဲ့ လုပ်ငန်းကို မထိခိုက်အောင် တွဲပြီးလုပ်ဆောင်လို့ရပါတယ်။

Configuration ပိုင်းအနေနဲ့ ကတော့သီးသန့်ခွဲရေးမှသာ အဆင်ပြေပါလိမ့်မယ်။ မြင်သာအောင် Cisco site ကနေယှဉ်ပြထားတဲ့ VSS နဲ့ VSS မပါတဲ့ ပုံကိုကြည့်ပါ။ 

ကိုဖြိုး

Multicast Protocols

Multicast အကြောင်းကို အပေါ်ယံလောက်လေ့လာပြီးပြီ၊ Addressing အကြောင်းကိုတီးခေါက်မိပြီဆိုရင်တော့ သူ့ရဲ့အလုပ်လုပ်ပုံကိုစတင်လေ့လာလို့ ရပါပြီ။ အဲဒီမှာ အရင်ဆုံးတွေ့ရမှာကတော့ Multicast Protocols တွေပါပဲ။ သူတို့ရဲ့ အဓိကလုပ်ဆောင်ပုံကတော့ Multicast Source ကနေ Client တွေဆီကို Multicast Distribution Tree ကနေဘယ်လိုရောက်အောင်သွားမလဲဆိုတာပါပဲ။ Unicast မှာတုန်းက Client တွေက ကိုယ်ရောက်ချင်တဲ့ နေရာကိုရောက်အောင်သွားဖို့ကြိုးစားတယ်၊ အခု Multicast မှာတော့ Client တွေဆီကိုပြန်လာဖို့ကြိုးစားတယ်လို့လည်း ပြောလို့ရပါတယ်။

Multicast protocols တွေကိုလေ့လာတဲ့အခါမှာ  IGMP (Internet Group Management Protocol), CGMP(Cisco Group Management Protocol) နဲ့ PIM (Protocol Independent Multicast) တို့အကြောင်းကိုအရင်လေ့လာရပါမယ်။ သူတို့ကိုတော့ Intradomain Multicast Protocols တွေလို့ခေါ်ပါတယ်။ ပြီးမှ Interdomain Multicast Protocols တွေကိုဆက်လေ့လာသင့်ပါတယ်။ ဒီ Protocols တွေဟာ Multicast Distribution Tree တစ်ခုဖြစ်ပေါ်လာဖို့အတွက် အဓိကလုပ်ဆောင်ပေးပါတယ်။

ထပ်ပြီးခွဲကြည့်မယ်ဆိုရင် IGMP ဟာ Client/Host နဲ့ သူ့ရဲ့ Multicast Router တို့ကြားမှာ အသုံးပြုတဲ့ Protocol ဖြစ်ပြီး ဘယ် Multicast Group ကိုတော့ ဆက်သွယ်ချင်တယ် ဘယ် host တွေကတော့ အဲဒီအုပ်စုထဲမှာ ရှိနေသေးတယ်၊ ထွက်သွားပြီ စသဖြင့်ကို စောင့်ကြည့်ပေးတဲ့နေရာမှာ အလုပ်လုပ်ပါတယ်။ သူနဲ့ပက်သက်လာရင် သိထားသင့်တာကတော့ Membership report, Membership query, Leave group စတဲ့ Message တွေပါ။ လွယ်အောင်ထပ်ပြောရရင် host တွေဟာ သူတို့ဘယ်အုပ်စုကို ဆက်သွယ်ချင်တယ်ဆိုတာကို Router ဆီကို Membership report ပို့တယ်၊ Router က query ကိုပုံမှန် ပြန်ပို့ရင်း အဲဒီ Host တွေရှိသေးလား၊ ထပ်တိုးလာလား၊ ထွက်သွားပြီလားဆိုတာကို မှတ်ထားတယ်။ Host ကမသုံးချင်တော့ဘူး ထွက်တော့မယ်ဆိုရင်တော့ Leave group message ပြန်ပို့လိုက်တာပါပဲ။ IGMP v1 မှာတော့ Leave group မပါသေးပါဘူး။

ဒါပေမယ့် host တွေဟာ Multicast Router တွေဆီကို တိုက်ရိုက်ချိတ်ဆက်ထားတာမဟုတ်ပါဘူ။ ကြားထဲက Switch တွေကနေဖြတ်သွားရတာပါ။ ဒီတော့ Switch တွေကနေ အခုလို Message တွေကို ကိုင်တွယ်ဖို့အတွက် CGMP ကိုအသုံးပြုပါတယ်။ သူ့ကိုအသုံးပြုချင်းအားဖြစ် Switch အနေနဲ့သူ့ရဲ့နဂိုလုပ်ဆောင်ပုံဖြစ်တဲ့ Ports တွေအားလုံးကို ပို့မယ့်အစား ဒီအုပ်စုတွေမှာ ပါဝင်ပက်သက်မဲ့ Host Ports တွေကိုပို့ပေးပါတော့တယ်။ ဒီလိုလုပ်ဆောင်ပေးချင်းအားဖြင့် Switch ရဲ့စွမ်းဆောင်ရည်ကို ထိန်းချုပ်နိုင်ပါတယ်။ မလိုအပ်တဲ့ အရာတွေကိုအသုံးပြုစရာမလိုတဲ့အတွက် Efficiency ကိုမကျစေဘူးပေါ့။ ဘာနဲ့တူမလဲဆိုရင် Trunk ပေါ်မှာ Vlan/VTP Pruning လုပ်သလိုပေါ့၊ ဖြတ်သွားစရာမလိုတဲ့ Vlan တွေကိုဖယ်လိုက်သလိုမျိုး။

ကျန်တဲ့အပိုင်းကတော့ Multicast Router ရဲ့အလုပ်ပေါ့။ သူ့တာဝန်ကတော့ Source နဲ့ Receiver/Client တွေအကြား Loop Free Multicast Distribution Tree တည်ဆောက်ဖို့ပါ။ ဒီတစ်ခါအလှည့်ကြတာကတော့ PIM ပေါ့။ PIM ကို Protocol Independent လို့ဆိုပေမယ့် တကယ်ကတော့ သူ အလုပ်လုပ်ရမဲ့ Network အထဲမှာရှိတဲ့ ရှိသမျှ Protocol အားလုံးနဲ့ အတူတွဲလုပ်ရမယ်လို့ဆိုလိုချင်တာဖြစ်ပါတယ်။ သူ့တစ်ခုထဲနဲ့ ဘာမှလုပ်မရပါဘူး။ အဲဒီ Unicast routing protocol တွေရဲ့ အကူအညီနဲ့မှ Multicast Routing table ကိုသူ့အနေနဲ့တည်ဆောက်လို့ရပါတယ်။ အဲဒါရပြီဆိုမှာ Multicast Forwarding ကို ပုံစံ၃ခုခွဲခြားပြီး အလုပ်လုပ်ပါတယ်။ PIM-DM (Dense mode) , PIM-SM(Sparse mode), Bidir-PIM (Bidirectional PIM)။ PIM ဟာကျယ်ပြန့်တဲ့အတွက် သီးသန့်အချိန်ပေးပြီးလေ့လာရပါမယ်။ အခုလောက်ဆို Multicast ဇတ်လမ်းရှည်ကြီးကို တဖြည်းဖြည်းချင်းဇတ်ရည်လည်လာပြီလို့ ထင်ပါတယ်။

ကိုဖြိုး

၁၉ နှစ်သား CCIE

၁၉  နှစ်သား CCIE

Cisco certification and Delivery Team ကရေးသားထားတဲ့ အမေရိက က ၁၉ နှစ်သား လူငယ်လေးတစ်ယောက် အကြောင်းကို ဖတ်ဖြစ်ပါတယ်။ သူ့ရဲ့ကြိုးစားအားထုတ်မှု၊ ဇွဲကောင်းမှုတို့ဟာ အားကျစရာကောင်းတဲ့အတွက် ဒီလမ်းကိုလျှောက်နေကြတဲ့ ဘဝတူ လူငယ်တွေ အားတက်ဖို့ရာအတွက် ရှယ်ပေးလိုပါတယ်။

သူ့အမည်က Jorge Ospina ဖြစ်ပါတယ်။ သူဟာ အသက် ၁၃ နှစ်အရွယ်မှာ(၂၀၀၉) CCNA Certificate ကိုရရှိခဲ့ပြီး နောက်ထပ်တစ်နှစ် အတွင်းမှာပဲ CCNP ဖြစ်လာခဲ့ပါတယ်။ CCIE ဖြစ်ဖို့ရာအတွက် သူ့အနေနဲ့ သိပ်မလွယ်ပါဘူး၊ လုပ်ငန်းအတွေ့အကြုံမရှိတာရယ် လက်တွေ့မရှိတာ တွေက အဓိက အဟန့်အတားပေါ့၊ ဒါပေမယ့် Written ကိုတော့ ရအောင်ဖြေခဲ့ပါတယ်။ အဲဒီအချိန်မှာ သူ့အမေဖြစ်တဲ့ Christina Ospina ဟာ Cisco ရဲ့ CEO(ဟောင်း) John Chambers ထံကို စာရေးပြီး အကူအညီတောင်းပါတယ်။ အဲဒီစာကို တစ်ဆင့်ပြီး တစ်ဆင့် လူအများစုရဲ့ အကူအညီနဲ့ ပေးပို့သွားရာကနေ နောက်ဆုံးမှာ Certification and Lab delivery က ဒါရိုက်တာ Chris Jacobs ဆီရောက်သွားပါတယ်။ ကံကောင်းချင်တော့ Chris က ဒီလူငယ်ရဲ့ ကြိုးစားမှုကို စိတ်ဝင်စားပြီး ကူညီမယ်လို့ဆုံးဖြတ်လိုက်ပါတယ်။

Chris က ရက်အတန်ကြာမှာပဲ အင်တာဗျူးတစ်ခုကို စီစဉ်ခဲ့ပြီး ဒီလူငယ်လေးရဲ့ အိမ်မက်တွေကို အကောင်အထည်ဖော်နိုင်ဖို့အတွက် CCIE Mentor နှစ်ယောက်ကို အကူအညီပေးဖို့ရယ် LAB လုပ်နိုင်ဖို့အတွက်ရယ်ကို စီစဉ်ပေးခဲ့ပါတယ်။ သုံးနှစ်အကြာမှာ LAB ဖြေဖို့အတွက်ကတော့ သူ့ရဲ့အကြီးကျယ်ဆုံးစမ်းသပ်မှု တစ်ခုပါပဲ။ သေချာတာကတော့ သူ့မှာ CCIE ခရီးအတွက် လိုအပ်တာတွေ အားလုံးအဆင့်သင့်ဖြစ်နေပြီဆိုတာပါပဲ။ ၂၀၁၁ မှာ ပထမဆုံးအကြိမ်အဖြစ်ဖြေဆိုခဲ့ရာမှာ မအောင်မြင်ခဲ့ပါဘူး။ နောက်နှစ်မှာ နောက်တစ်ကြိမ်ထပ်မံဖြေဆိုခဲ့ရာမှာလည်း ကျခဲ့တာပါပဲ။ အဲဒီအချိန်မှာ သူသဘောပေါက်သွားတာကတော့ စာအုပ်ထဲက အရာတွေလေ့ကျင့်ယုံနဲ့တင် မလုံလောက်ဘူးဆိုတာပါပဲ။ ဒီတော့ အလုပ်ဝင်လုပ်ဖို့ဆုံးဖြတ်ခဲ့ပါတယ်။

အလုပ်လုပ်ရင်း တစ်ဖက်ကလဲ ကျောင်းတက်ပေါ့။ ၂၀၁၃ မှာကောလိပ်ဒီဂရီရပြီးတဲ့ အချိန်နောက်ပိုင်းမှာ ထိုင်းမှာ ၃လ CCIE Bootcamp လာတက်ခဲ့ပါတယ်။ အဲဒီနောက်မှာတော့ သူ့ရဲ့တတိယအကြိမ်အဖြစ် CCIE LAB exam ကိုဖြေဆိုခဲ့ပါတယ်။ ဒီတစ်ကြိမ်မှာတော့ သူအောင်မြင်စွာဖြေဆိုနိုင်ခဲ့ပြီး CCIE တစ်ယောက်ဖြစ်လာခဲ့ပါတယ်။ အဲဒီအချိန်မှာတော့ သူ့အသက်က ၁၉ ပဲရှိပါသေးတယ်။

သူဟာ အဖက်ဖက်က ကူညီမှု ပံ့ပိုးမှုတွေရခဲ့တဲ့ လူငယ်တစ်ယောက်လို့ဆိုလိုရပေမယ့် သူ့ရဲ့ တစိုက်မတ်မတ် ကြိုးစားအားထုတ်မှု၊ ဇွဲကောင်းမှုနဲ့ အလျှော့မပေး လိုချင်တာကိုရအောင်ကြိုးစားခဲ့ပုံကိုတော့ ချီးကျူးရမှာဖြစ်ပါတယ်။ ငါလည်းဒီလိုပံပိုးမှုတွေရှိရင် ရနိုင်ပါတယ်လို့အလွယ်မပြောစေချင်ပါ။ တကယ်လုပ်ကြည့်မှ သိမှာပါ။ တစ်ရက်ကို ၂နာရီ လောက်တောင် ၂နှစ် ၃နှစ်လောက် ဆက်တိုက် လုပ်နိုင်ဖို့ဆိုတာသိပ်မလွယ်ပါ။ ကျွန်တော်တွေ့ဖူးသလောက်တော့ အများစုဟာ ၃ လလောက်နေရင် အကြောင်းအမျိုးမျိုးကြောင့် စတင်ပေါ့လျော့လာပြီး လမ်းကြောင်းပေါ်ကနေ သွေဖယ်သွားကြပါတယ်။

ဒီဆောင်းပါးကိုခြုံပြီးကြည့်ရမယ်ဆိုရင်တော့။

CCIE ရရှိဖို့ဆိုတာ လက်လှမ်းမမှီတဲ့ ကိစ္စတစ်ခုမဟုတ်ပါ
အစဉ်မပြတ်ကြိုးစားမှုနဲ့ဇွဲရှိဖို့လိုပါတယ်
အချိန်၊ ငွေကြေးနဲ့ပံပိုးမှုလိုပါတယ် (မိသားစု၊ သူငယ်ချင်း၊အလုပ်ရှင်၊ဆရာ)
လုပ်ငန်းအတွေ့အကြုံဟာ အဓိကကြတဲ့နေရာက ပါဝင်ပါတယ်
သူ့လိုအကူအညီရဖို့ဆိုတာ တခြားနိုင်ငံတွေမှာ ဆိုရင်တော့ မလွယ်လောက်ပါဘူး
Cisco ရဲ့ကူညီမှုဟာတော့ ဝမ်းမြောက်စရာပါ

https://learningnetwork.cisco.com/blogs/certifications/2015/05/22/ccna-age-13-ccnp-age-14-ccie-age-19-bam

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

ကိုဖြိုး