Sunday 21 February 2016

IPJ

IPJ



A Quarterly Technical Publication for Internet and Intranet Professionals

IPJ ကိုမသိသေးသူတွေအတွက် အထင်ကရ ဂျာနယ်တစ်ခုဖြစ်တဲ့ IPJ နဲ့မိတ်ဆက်ပေးချင်ပါတယ်။ Cisco ကအရင်ထုတ်ဝေခဲ့တာဖြစ်ပြီး အင်တာနက်နည်းပညာများကို ရှုထောင့်စုံကနေ ရေးထားတဲ့ ဂျာနယ်တစ်ခုဖြစ်ပါတယ်။ Cisco ကထုတ်တာဆိုပေမယ့် သူ့ရဲ့ပစ္စည်းပိုင်းကိုကြော်ငြာတာမျိုးမဟုတ်ပဲ နည်းပညာသက်သက်ကိုသာ အလေးထားပြီးဆွေးနွေးထားတာဖြစ်ပါတယ်။ ဟိုးအရင်ကလုပ်ခဲ့တဲ့အလုပ်မှာ Printed copy ပုံမှန်ယူထားတဲ့အတွက် ၃လတစ်ကြိမ် ဖတ်ခဲ့ရပါတယ်။ ကျွန်တော်မှတ်မိသလောက်တော့ Online version ကိုမဖတ်ဖြစ်ခဲ့ပါဘူး၊ ကိုယ့်လက်ထဲ စာအုပ်ရနေတာကြောင့်လဲပါပါလိမ့်မယ်။ စာရွက်နဲ့ Online ဆိုရင်အခုချိန်ထိ စာရွက်၊ စာအုပ်နဲ့ဖတ်ရတာကိုပိုသဘောကြနေဆဲပါ။ နောက်ပိုင်းအလုပ်ပြောင်းသွားတော့ IPJ နဲ့ အလှမ်းဝေးသွားခဲ့ပါတယ်။ တစ်ခါလောက် သတိရလို့ ရှာကြည့်တော့ Cisco ကထပ်မထုတ်တော့ဘူးလို့သိရတယ်။ ဒီတော့လဲ ပြီးပြီပေါ့။

OCTOBER 2013: TO OUR READERS

At this time, Cisco Systems, Inc. has decided not to continue publishing The Internet Protocol Journal (IPJ) effective immediately.
Cisco wishes to thank Ole Jacobsen, the Editor and Publisher of IPJ for his tireless and professional efforts to inform the community of the Internet, its varied protocols, and its impact upon the world through this publication. Cisco also wishes to thank the authors of the published articles, and all those who submitted articles. A special note of thanks goes to the IPJ Editorial Advisory Board and the article reviewers who have helped to maintain the very high standards of journalistic and technical quality of IPJ.

တစ်နေ့က စာဖတ်ဖို့ရှာရင်းနဲ့ Google မှာ IPJ ဆိုတာသွားပြန်တွေ့တယ်။ ဒါနဲ့ သွားကြည့်တော့ Protocol Journal ဆိုပြီးရောက်သွားတယ်။ ဒီတခါတော့ Cisco တစ်ခုထဲမဟုတ်တော့ပဲ အဖွဲ့အစည်းအများစုရဲ့ ပံ့ပိုးမှုနဲ့ စက်တင်ဘာ ၂၀၁၄ မှာပြန်စပြီး ထုတ်နေပြန်တယ်လို့ဆိုတယ်။  ခုနောက်ဆုံးထုတ်ထားက ဒီဇင်ဘာ ၂၀၁၅ ဆိုတော့ကာ အခုလာမဲ့ မတ်လမှာ နောက်ထပ်တစ်စောင်ထွက်တော့မယ်။ နောက်ဆုံးထုတ်ထားတဲ့ စာစောင်မှာ IoT Network and Security Architecture အကြောင်းရေးထားတယ်။ သေချာတော့ မဖတ်ရသေးဘူး။ တခြားအဟောင်းတွေအားလုံးကိုလဲ စုပေါင်းပြီး download ပေးထားတဲ့အတွက် အချိန်ရတဲ့သူတွေအတွက်ကတော့ ပြန်ဖတ်ကြည့်လို့ရတာပေါ့။ သူ့အထဲကအကြာင်းအရာတွေက သိပ်ပြီးပေါ့ပေါ့ပါးပါးမရှိတဲ့အတွက်ကြောင့် တစ်ချို့အနေနဲ့ ဖတ်ရတာကြိုက်မှာမဟုတ်ပါဘူး၊ ကျွန်တော့လိုဖတ်နေရင်းနဲ့လဲ ငိုက်သွားနိုင်ပါတယ် ဒါပေမယ့် တစ်ချို့အကြောင်းအရာတွေဟာ စိတ်ဝင်စားဖို့ကောင်းပါတယ် (ဥပမာ Fog-Computing ဆိုတာမျိုး) တခါတလေမှာ ကိုယ်တခါမှ မကြားဖူး မမြင်ဖူးတဲ့ ကိစ္စတွေပါတဲ့ အတွက်ကြောင့် ဗဟုသုတအနေနဲ့ ဖတ်ကြည့်သင့်တဲ့ ဂျာနယ်တစ်စောင်ဖြစ်ကြောင်းဝေမျှလိုက်ပါတယ်။

http://protocoljournal.org/


ကိုဖြိုး

Saturday 13 February 2016

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 ဆိုတာဘာလဲသိချင်ရင်တော့ ကျွန်တော့အရင်ပို့စ် အဟောင်းတွေမှာ ပြန်ရှာဖတ်ကြည့်နိုင်ပါတယ်။ 



ကိုဖြိုး

Sunday 7 February 2016

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..



ကိုဖြိုး