Failure Detection ရဲ့ အရေးပါမှုနှင့် BFD

Failure Detection ဟာ Network တခုအတွက် ဘယ်လောက် အရေးပါလည်း ဆိုတာနဲ့ Bidirectional Forwarding Detection (BFD) ဆိုတာ ဘာလဲ။ ဘယ်လို အခြေအနေမျိုးမှာ ဘာကြောင့် သုံးကြ တယ်ဆိုတာ လေ့လာ ကြည့်ရအောင်။ ကိုယ်တာဝန်ယူထားရတဲ့ Network တခုမှာ တခုခုပြဿနာဖြစ်ပီ ဆိုရင် ဘယ် နေရာမှာ ဘာဖြစ်နေတယ်ဆိုတာကို အရင်ဆုံးသိဖို့က အရေးကြီးပါတယ်။ ဒါမှသာ ဘာဆက်လုပ်သင့်တယ်၊ ဘယ်နေရာတွေ ပြင်ရမယ်ဆိုတာ သိမှာပါ။ ဘယ်နေရာက ဘာဖြစ်နေမှန်းမသိဘူးဆိုရင် ဖြေရှင်းဖို့မလွယ်ကူသလို၊ ဖြေရှင်းရမဲ့ အချိန်ကိုပါ ကြာမြင့်စေပါတယ်။ တနည်းအားဖြင့်ပြောရရင် ပြတ်တောက်ချိန် Outage ကိုကြာမြင့်စေတဲ့အတွက် မလိုလားအပ်တဲ့ ကိစ္စတွေ ပေါ်ပေါက်နိုင်စေပါတယ်။

ဒီနေရာမှာ အချက် ၂ ချက်က အရေးကြီးပါတယ်။ ပထမတခုက Failure detection နဲ့ ဒုတိယတခုက Time ပါ။ ပထမ အချက်က အဓိကပေမဲ့ အချိန်ကလဲ အရေးကြီးပါတယ်။ ကိုယ်ရဲ့ Network နဲ့ SLA အပေါ်မူတည်ပါတယ်။ Failure Detection အတွက် NMS တွေ၊ Devices' syslog တွေ၊ traps တွေတခြားလိုအပ်တဲ့ အချက်အလက် တွေနဲ့ Admin တယောက်အတွက် မြင်သာအောင် စီစဉ်ထားရပါတယ်။ အဲဒါတွေကလည်း ကိုယ်အသုံးပြုနေတဲ့ Device/Link/Protocols တွေရဲ့ သဘာဝအပေါ်မူတည်ပါတယ်။ သူတို့က ပေးပို့တာ နောက်ကျရင် NMS နဲ့ Syslog ကသိတာလည်း နောက်ကျပါတယ်။ Poll Method ဖြစ်ဖြစ်၊ Push Method ဖြစ်ဖြစ် အတူတူပါပဲ။

နောက်တခုက Network outage တွေမှာ ပြဿနာဖြစ်ရင် Admin/user fault ရယ်၊ Links/ Circuits outage က equipment/device failure ကပိုပါတယ်။ တော်ရုံ Device တွေဟာ Power ကြောင့်ကလွဲရင် hardwar ကြောင့်   ဖြစ်တာ နဲပါတယ်။ ဒီတော့ အများအားဖြင့် Link/Circuit တွေ၊ Configuration error တွေကိုအဓိက စောင့်ကြည့်ရတာများပါတယ်။ Link/Circuit တွေရဲ့ အခြေအနေကိုကြည့်ပြီး အပေါ်က Protocol တွေက Neighbor တွေဆောက် ၊ Routing တွေ ဖလှယ်ကြပါတယ်။ အဲဒီနေရာမှာ Protocol တွေရဲ့ Hello တို့ Hold time တို့က အဓိက အလုပ် လုပ်တယ်။ Protocol တခုနဲ့တခု၊ Link အမျိုးအစား တခုနဲ့တခု Hold time တွေမတူကြပါဘူး။ အဲဒီ Hello ပျောက်သွားပြီ Hold time ကျော်သွားပြီဆိုတော့မှ Neighbor ပျောက်ပီဆိုပြီးတော့ Failover ကိစ္စတွေ စလုပ်ပါတယ်။ အဲဒီ Hold time အတွင်းမှာ traffic တွေဟာ black hole အထဲကို ရောက်သွားပါတယ်။ ပြန်ကောင်းသွားလို့ပဲဖြစ်ဖြစ် Failover ကအလုပ်လုပ်သွားတာပဲ ဖြစ်ဖြစ် ရတော့မှ ပြန်အဆင်ပြေသွားပါတယ်။ ပြန်မကောင်းခင် အချိန်အတွင်းမှာ ဖြစ်သွားတာကတော့ Packet loss ပေါ့။ Convergence time နှေးလေ Outage ကြာချိန်များလေပါပဲ။

Failure detect ဖြစ်တယ် dynamic Failover အလုပ်လုပ်တယ်ဆိုရင် ပြည့်စုံပြီလို့ ဆိုလို့ရပေမယ့် အဲဒီ protocol တွေရဲ့ တမိနစ်လောက်ရှိတဲ့ hold time ကို မစောင့်နိုင်တဲ့ အခြေအနေတွေရှိပါတယ်။ နောက်တခါ multiple protocols တွေရှိနေတဲ့ အချိန်မျိုးမှာ Failure detection ကိုတတ်နိုင်သလောက် တူညီအောင် Circuit/Link တွေကို စောင့်ကြည့်မယ်ဆိုရင်တော့ protocol တခုစီရဲ့ hello နဲ့ hold time တွေကို လိုက်ညှိရပါလိမ့်မယ်။ OSPF fast hello မျိုးပေါ့။ ဒါပေမယ့် တကယ့်လက်တွေ့မှာ သိပ်မလွယ်ပါဘူး။ နောက်တခါ dynamic protocol မသုံးထားတဲ့လင့်မျိုးမှာ hello မရှိရင် Layer 2 ရဲ့ hardware alarm ကိုပဲအားထားရပါတယ် ဒါပေမဲ့ Ethernet လိုမျိုး interface အတွက် အဆင် မပြေပြန်ဘူး။ အထူး သဖြင့် Metro Ethernet Link တွေမှာ MUX/MC/Switch က ခံနေတဲ့ အတွက် interface down stage ကိုဘယ်တော့မှ မရောက်ပါဘူး။ Interface down မဖြစ်တဲ့အတွက် Failover ကလဲ အလုပ်မလုပ်ပါဘူး။

ဒီကိစ္စကိုဖြေရှင်းဖို့အတွက် IP LSA တို့ EEM တို့သုံးပြီး Failure detection ရအောင်လုပ်ကြပါတယ်။ Point to point link တွေအတွက်တော့ ပေါ့ပါးပီး မြန်ဆန်တဲ့ Bidirectional Forwarding Detection ခေါ် BFD ကိုလည်းသုံးကြပါတယ်။ BFD ရဲ့ timer ဟာ msec အထိဆင်းပြီး လုပ်ဆောင်နိုင်တဲ့အတွက် IGP hello တွေ လုပ်ဆောင်နိုင်တဲ့ အချိန်နဲ့ အများကြီး ကွာပါတယ်။ နောက် dynamic protocol မရှိတဲ့ နေရာမျိုးအတွက်လည်း overhead နဲနဲနဲ့ Failure detection ကို လုပ်ဆောင်ပေးပါတယ်။ Interface level နဲ့ routing protocols level မှာ အသုံးပြုရပါတယ်။ ဒါပေမဲ့ ကိုယ်အသုံးပြုနေတဲ့ IOS က support လုပ်ဖို့တော့လိုပါတယ်။

သူ့ရဲ့အလုပ်လုပ်ပုံကလည်း ရှင်းရှင်းလေးပါ။ Timer တွေပါတဲ့ BFD control packet ကို တဖက်ကနေ တဖက်ပို့ပေးရင်း Neighbor ရှိနေသေးလားကြည့်ပေးတာပါ။ packet ရောက်မလာရင် Down ပေါ့။ Operations mode အနေနဲ့ ၂ မျိုးရှိတယ်။ Asynchronous mode ရယ် Demand mode ရယ်။ Primary mode ဖြစ်တဲ့ Asynchronous mode က ၂ ဖက်စလုံးက peer တွေက control packet ကို ပုံမှန်ပေးပို့ပြီး စောင့်ကြည့်တယ်။ Demand mode ကတော့ neighbor ဖြစ်ပြီးသွားရင် ပုံမှန်မပို့ပဲ လိုအပ်တယ်လို့ထင်မှ ထပ်ပို့ကြတယ်။ သူတို့တွဲသုံးတဲ့ လုပ်ဆောင်ချက်တခုကတော့ Echo function လို့ခေါ်တယ်။ သူကတော့ ဒီဖက်ကပို့လိုက်တဲ့ Control packet က Loop ပေးသလိုမျိုး Echo ပြန်ရောက်လာတဲ့ ပုံစံမျိုး။ ဘယ် Mode ကိုသုံးရမလဲဆိုတာကတော့ ကိုယ့် Network အခြေအနေ ကိုယ်သုံးတဲ့ Device နဲ့ OS အပေါ်မှမူတည်ပါတယ်။ Aggressive detection အတွက်တော့ Asynchronous နဲ့ Echo သုံးကြပြီး Overhead လျော့ချင်ရင်တော့ Demand mode ကိုသုံးကြပါတယ်။

BFD ဟာ Failure Detection အတွက် အထောက်အကူပြုတဲ့ Protocol ဖြစ်ပါတယ် ဒါပေမဲ့ သေချာစဉ်းစားပြီး ကိုယ့် Network အတွက် တကယ်လိုအပ်မှသာ အသုံးပြုသင့်ပါတယ်။ Failure Detection ဟာ မြန်နိုင်သလောက်ကောင်းလေ ဆိုပေမယ့် တဖက်မှာတော့ Network stability ကိုလည်း ပြန်ကြည့် ရပါတယ်။ Convergence time ဟာ Protocol default setting တွေနဲ့လုံလောက်တယ်ဆိုရင်တော့ Network Stability အတွက်ပိုပြီး ဦးစားပေး စဉ်းစားသင့်ပါတယ်။ အခုလောက်ဆို Failure Detection ဟာ ဘယ်လောက်အရေးပါလည်းဆိုတာ ကိုသိလောက်ပါပြီ။ ဒါနဲ့အတူ BFD ဆိုတဲ့ Protocol အကြောင်းကိုပါ တီးမိခေါက်မိ ရှိလောက်ပြီလို့ထင်ပါတယ်။ BFD ရဲ့ အသေးစိတ်ကိုထပ်ဖတ်မယ်ဆိုရင်တော့ RFC 5880 မှာဖတ်ကြည့်ပါ။ Configuration အတွက်ကတော့ ကိုယ်သုံးတဲ့ Device နဲ့ OS ပေါ်မူတည်ပြီး Cisco Documentation မှာရှာကြည့်ပါ။

ကိုဖြိုး

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



ကိုဖြိုး

Ethernet, Static Route နဲ့ လုပ်ငန်းခွင်သုံး IP SLA

Static route ဟာ Routing မှာ အခြေခံ အကျဆုံး ဖြစ်သလို အလွန်အသုံးဝင်တဲ့ Route

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

အားနည်းချက်ကတော့ Complex Network အကြီးတွေ Routes တွေသိပ်များတဲ့ အချိန်တွေမှာ သူ့သဘာ၀ဖြစ်တဲ့ အတိုင်းတစ်ကြောင်းစီ အသွားရောအပြန်ရောလိုက်ထည့်နေရတဲ့ အတွက်အဆင်မပြေတော့ပါ၊

အဲဒီလိုအချိန်မျိုးမှာတော့ Dynamic Routes တွေဖြစ်တဲ့ OSPF/ EIGRP/ BGP တို့သုံးကြတာပေါ့

ဒါပေမယ့် Small Office/Home Office လို Internet သီးသန့်သုံးတဲ့ နေရာတွေမှာ ကိုယ့်အတွက် Default Route တခုကလွဲရင် တခြား ဘာ Route မှမလိုပါဘူး၊ Dynamic Routing မသုံးလဲ ရပါတယ်၊

Dynamic Routing သုံးချင်ပေမယ့်လဲ Service Provider ဘက် က Dynamic Routing မပေးရင်လဲ သုံးမရပါဘူး၊ ဒီလိုအခြေနေမှာ Static Route ကိုသာ သုံးရပါတယ်။

ရုံးတော်တော်များများဟာ Internet link ၂ ခုကို Failover/Backup အနေနဲ့သုံးလေ့ရှိပါတယ်၊ Router တစ်လုံးမှာ ၂ လိုင်းသုံးတာရှိသလို ပိုပီးစိတ်ချရအောင်Router ၂ လုံးနဲ့တစ်လိုင်းစီခွဲသုံးတာလဲရှိပါတယ်၊

Static route ကိုလည်း AD ၂ခုနဲ့ ပထမ၊ ဒုတိယ ဆိုပီးထည့်ကြတာပေါ့၊ E1/Serial Interfaces တွေမှာ အဲဒီ ပုံစံက အလုပ်ဖြစ်ပါတယ်၊ Protocol down ရင် static route က Routing table ကနေပြောက်သွားပါတယ်။

ဒါပေမယ့် Ethernet interface မှာဆိုရင်တော့ပြဿနာရှိပါတယ်။ Provider တွေဟာ Ethernet link ကို သူတို့ရဲ့ Mux သို့မဟုတ် Media Converter ကနေပေးကြပါတယ် အဲဒီမှာ ကိုယ့် Router ရဲ့Ethernet Interface ကိုလာတဲ့ Link ဟာ အမြဲတမ်းကောင်းနေပေမယ့် Mux/MC အပြင်က WAN/Metro link တွေဟာ မကြာခဏ ပြသနာပေးလေ့ရှိပါတယ်။

Link က up/up ဖြစ်နေပေမယ့် next hop IP ကို မရောက်တဲ့အချိန်မှာ static route ဟာ Routing table ထဲမှာ ကျန်နေပါတယ် ဒုတိယ AD နဲ့Route ကိုလည်းပြောင်းမသွားဘဲ Black Hole ဖြစ်ပီး ပြဿနာ ဖြစ်တော့တာပေါ့၊ ဒီအချိန်မှာ ပထမ Route ကို ဝင်ဖြုတ်ပေးမှ ဒုတိယ Route ကအလုပ်စလုပ်မှာပါ။

အခုလို Manual လုပ်ရတာအဆင်မပြေရင် Auto Failover ဖြစ်အောင် IP SLA ကိုသုံး အဲဒီ Static Route ကို Track လုပ်ပီး ဖြုတ်ပေးနိုင်ပါတယ်၊ ကိုယ်ကြိုက်တဲ့ IP SLA အမျိုးမျိုးနဲ့Track သုံးလို့ရပါတယ်၊

အသုံးများတာကတော့ Next hop IP ကို IP SLA နဲ့ICMP သုံးပီး Monitor လုပ် ပီးရင်Track နဲ့တွဲ၊ Loss ဖြစ်သွားရင် IP SLA နဲ့Track က Static route ကို Auto ဖြုတ်ပေးတာနဲ့ အဆင်ပြေသွားမှာပါ၊

စမ်းသပ်ချင်ရင်တော့ Router ၃လုံးကို Switch ခံပီး FE နဲ့ချိတ်၊ Router တလုံးမှာ Default route ကို Track နဲ့ထည့်၊ IP SLA နဲ့Monitor လုပ်၊ ပီးရင် ပထမ Route ရဲ့ Next hop router ရဲ့IP ကိုပြောင်းပီး IP SLA trigger ဖြစ်ရင် လိုချင်တဲ့ရလဒ်ရမှာပါ၊

ip sla 10

icmp-echo 192.168.1.2 source-ip 192.168.1.1

frequency 180

ip sla schedule 10 life forever start-time now

track 1 rtr 10 reachability

R1#sh run | i ip route

ip route 0.0.0.0 0.0.0.0 192.168.1.2 track 1

ip route 0.0.0.0 0.0.0.0 192.168.1.3 100

Next hop ပြောက်သွားရင်

*Mar 1 00:14:10.891: %TRACKING-5-STATE: 1 rtr 10 reachability Up->Down

ပြန်တက်လာရင်

*Mar 1 00:17:05.899: %TRACKING-5-STATE: 1 rtr 10 reachability Down->Up

ဒါဟာ IP SLA ရဲ့ အခြေခံ အကျဆုံး အသုံးပြုပုံပါ၊ တခြား TCP/UDP/HTTP စတာတွေနဲ့လည်းသုံးလို့ရပါတယ်၊ Voice သုံးတဲ့သူတွေ ကတော့ UDP Jitter, delay , packetloss တွေကို Monitor လုပ်ကြပါတယ်

လိုအပ်ချက်ပေါ်မူတည်ပီး Operations နဲ့Measurements တွေပြောင်းပီး သုံးရတာပေါ့။

အသေးစိတ်သိချင်ရင်

http://www.cisco.com/c/en/us/td/docs/ios/12_4/ip_sla/configuration/guide/hsla_c.html

ကိုဖြိုး

လုပ်ငန်းခွင်သုံး Netflow ရဲ့အရေးပါပုံ

Enterprise အကြီးတွေ ဖြစ်ဖြစ် Small Office တွေဖြစ်ဖြစ် Connection/ links/Circuit တွေဖြစ်တဲ့ MPLS, VPLS, IPLC, ME, INTERNET တွေကိုService provider တွေကနေဈေးကြီးကြီး နဲ့ငှားသုံးရတာပါဘဲ။

အဲဒီထဲမှာ INTERNET က ဈေးအသက်သာဆုံးဖြစ်မယ်ထင်ပါတယ်၊ Bandwidth ပေါ်လဲ မူတည်တာပေါ့။

Management ဖြစ်တဲ့ လူကြီးတွေကလဲ သူတို့ဈေးအများကြီး ပေးထားရတဲ့ လင့်တွေကို ဘာတွေအများကြီးသုံးနေလဲ၊ အလုပ်နဲ့သက်ဆိုင်ရဲ့လား၊ ရသင့်တဲ့ Bandwidth ရရဲ့လား၊ထပ် မြှင့်ရမလား၊ ကုန်ကြစရိတ်သက်သာအောင် လျော့ချရမလား ဆိုပြီး မေးခွန်းပေါင်းစုံ မေးတတ်ပါတယ်၊ များသောအားဖြင့် Monthly Report, Quarterly Report တွေမှာ Network Manager/ Network administrator တွေက တင်ပြပီးရှင်းရပါတယ်။

နောက်တခုက Troubleshooting ၊ ဘယ်လိုအချိန်မှာလဲဆိုတော့ ဥပမာ ပြောရရင် အရေးကြီးတဲ့အချိန်တွေဖြစ်တဲ့ ရုံးစဖွင့်ချိန် ၉ ကနေ ၁၀ နာရီကြား၊ နေ့လည် ၂ ကနေ ၄ နာရီတွေဟာ ရုံးတော်တော်များများအတွက် Peak Traffic Hours တွေ ဖြစ်ပါတယ်၊ Link က နှေးနေပီ၊ ဘယ် Traffic က အသုံးများနေလဲ မသိဘူး၊ Virus ကြောင့်လား၊ ရုံး တစ်ရုံးနဲ့ရုံး ဖိုင်တွေ ကူးနေကြလား၊ ဒါတွေကို Network အဖွဲ့သားများ အနေနဲ့သိသင့် ပါတယ်၊ ဒါမှလိုအပ်လာရင် ဘာလုပ်ရမယ်ဆိုတာသိမှာ။ ဘယ်လိုသိအောင်လုပ်မလဲ။

နောက်ဥပမာ ပေးရရင် စက်ရုံတစ်ရုံ ကနေ နောက်တစ်ရုံကို ပုံမှန် Data Feed ပေးရပါတယ်၊ Manufacturing sector မှာ အလုပ် လုပ်ဖူးတဲ့သူဆိုသိပါတယ်၊ သူ့လိုအပ်ချက်နဲ့သူပေါ့၊ အဲဒီမှာ နောက်ထပ်တိုးချဲ့အစီစဉ် အရ နောက်စက်ရုံတစ်ခုကို ပြောင်းရမယ်၊ Bandwidth ထပ်မြှင့်ရမလား၊ Link အသစ်လျှောက်ရမလား ဆိုပြီး မေးလာရင် Network ကိုင်တဲ့ သူက Bandwidth ဘယ်လောက်လိုမယ် ဘယ်လောက် Link တော့ လိုမယ်ဆိုပြီး တွက်ပေးရတော့မယ်၊ 2MB ရှိတဲ့ IPLC မှာ အဲဒီ Traffic တမျိုးဘဲရှိရင်တော့လွယ်တာပေါ့၊ အဲဒီအတိုင်းလျောက်လိုက်ရုံဘဲ၊ အဲဒီလိုမဟုတ်ဘဲ တခြားဟာတွေပါရောနေတယ်ဆိုရင်တော့ ခက်ပီပေါ့၊

တကယ်ပြောင်းလို့ Bandwidth မလောက်ရင် Planning လုပ်တဲ့သူရဲ့ အမှားဆိုတာ ပြေးမလွတ်တော့ဘူး၊ လိုတာထပ်အများကြီး ပိုနေရင်လဲ ရှင်းရမှာဘဲ၊ ဘာကို မှီငြမ်းပြီး အနီးစပ်ဆုံး ရအောင် လုပ်မလဲ၊

ပြောရရင် အများကြီး ရှိပါသေးတယ်၊ ဒါပေမဲ့ အခုလောက်ဆို အထက်ကပြောခဲ့တာတွေ

ပြေလည်ဖို့နည်းပညာလို နေပီဆိုတာ အသေခြာပေါ့။

ခြုံပြောရရင် Importance of Network Awareness ပါ။

ဒါတွေအားလုံးကို ဖြေရှင်းပေးမှာကတော့ Netflow ပါ။

Router ရဲ့Interfaces မှာ ip route cache-flow တို့Ip flow ingress/egress တို့ဖြစ်တဲ့ Netflow Command တွေသုံးလိုက်ရုံပါပဲ

လိုအပ်တဲ့ Command နဲ့အသေးစိတ်ကို သိချင်ရင် Cisco Website မှာဖတ်ပါ၊

Troubleshooting အတွက်ဆို Flow Top Talkers တို့show commands အချို့လောက်ဆိုရပါပီ၊

ဒါပေမဲ့ ခုနကပြောခဲ့တာတွေ သိနိုင်ဖို့ဆိုရင် Netflow export နဲ့Netflow collectors တွေလိုပါတယ်၊ Router ကနေ export command နဲ့ Netflow collector ဆီပို့လိုက်ရုံဘဲ။

Flow collector က အဲဒီ အချက်အလက်တွေ သိမ်းထားပီးတော့ လိုအပ်တဲ့ Report တွေကို ပြန်ထုတ်ယူရပါတယ်

အောက်က Cisco link မှာ Collectors နဲ့Reporting tools တွေ တွေ့နိုင်ပါတယ်။

စိတ်ဝင်စားသူများအတွက်

http://www.cisco.com/c/en/us/products/ios-nx-os-software/ios-netflow/index.html

http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/ios-netflow/prod_white_paper0900aecd80406232.html

ရည်ရွယ်ချက် – လုပ်ငန်းခွင်ဝင်စ Network Engineer များ ၊Management နဲ့အနီးကပ်နေရတဲ့ IT Manager များ (အထူးသဖြင့် Networking field ကမဟုတ်တဲ့) တို့အသုံးပြုနိုင်ရန် အတွက်

စမ်းသပ်ချင်သူများအတွက် Free/ Trial software များ

Solarwinds

http://www.solarwinds.com/products/freetools/netflow-analyzer.aspx

Manage engine

http://www.manageengine.com/products/netflow/

Unix ရရင်တော့ Flow-tools, Ntop နဲ့ Cacti plug in ဖြစ်တဲ့ Flowview တို့တွေလဲစမ်းကြည့်ပေါ့

ကိုဖြိုး