Dear reader, please download one of Myanmar unicode font and install it on your PC to see my blog well.Thanks.

It's all about CCIE Exam and track

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

ပထမဆုံးအနေနဲ့ CCIE Certificate ဟာ တန်ဖိုးရှိသေးလား ဖြေသင့်သေးလားပေါ့။
အဖြေကို ပုံစံနှစ်မျိုးနဲ့ ဖြေရပါမယ်။
ပထမတခုကတော့
လွန်ခဲ့တဲ့ ၅ နှစ်နဲ့ ၁၀ နှစ်ဝန်းကျင်ကဆိုရင် CCIE ဆိုတာ ဝင်ငွေကောင်းတဲ့ Certificate တခုပါ။
ဒီဖက်ခေတ်မှာတော့ CCIE အပြင်တခြား သိစရာတွေသိပ်များပါတယ်။
အခုဆို Cloud တွေ Info Security Certificate တွေကလဲ အရမ်းခေတ်စားနေပြီး CCIE တွေထက်တောင် လစာ ပိုကောင်းနေပါသေးတယ်။
ဒီအတွက် CCIE တခုတည်းနဲ့ မလုံလောက်တော့ပါဘူး။ ဒါပေမယ့် Cloud လို Technology တွေဟာ BGP, MPLS, VPN တွေပေါ်မှာ ပဲ အခြေခံထားတဲ့အတွက် CCIE လမ်းကြောင်းကို လုပ်နေတဲ့သူတယောက်ဟာ ဒီနည်းပညာတွေကို လေ့လာရာမှာ သူများထက် တပန်းသာသလို ပိုလဲ ခရီးရောက်ပါတယ်။
ကျတော်အခုပြောနေတာက Routing and Switching အတွက်ပါ။ ကျန်တဲ့ Track တွေလဲသူ့ဟာနဲ့သူတော့ ရှိနေတာပါပဲ။
Exam သွားဖြေတဲ့အခါ CCIE Security, CCIE Wireless, CCIE Data Center တွေကို ဖြေနေတဲ့သူတွေ ရှိနေသေးတာပါပဲ။

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

ဒီလို အဖက်ဖက်က ခက်ခဲတဲ့ အလုပ်ကို လုပ်ပြီးအောင်မြင်တယ်ဆိုတာဟာလဲ အတော်ကျေနပ်စရာ ကောင်းတဲ့ တခုပါ။
ဒါကြောင့် ဒီလိုခံစားကျေနပ်ချင်တယ်ဆိုရင် လဲ CCIE တယောက်ဖြစ်အောင် လုပ်ပေါ့ဗျာ။

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

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

ကဲ ဒါကတော့ CCIE ဖြေသင့်မဖြေသင့်ပေါ့။

နောက်တခုကတော့ ဘယ်လိုလေ့လာလဲဆိုတာပါ။

CCNP နဲ့ CCIE ကြားမှာ ကွာဟချက်ကလေးတွေ ရှိပါတယ်။
အဓိက ကွာခြားချက်တွေက တော့
- QoS
- Multicast
- MPLS
- BGP
- IPv6
- Route Redistribution တို့ပါပဲ။

CCNP မှာ အပေါ်က ခေါင်းစဉ်တွေ အကြောင်း သင်ရလုပ်ရပေမယ့် အရမ်း အသေးစိတ်မသွားပါဘူး။
CCIE မှာတော့ အသေးစိတ်သွားပါတယ်။
BGP, MPLS, Route Redistribution တို့ဆို အတော်ကို လုပ်ရပါတယ်။

ဒါတွေအတွက်တော့ အထူးတလည် ဘယ်လိုတွေလေ့လာသင့်တယ် ပြောမနေတော့ပါဘူး။
အခုခေတ်မှာ သီအိုရီတွေ နဲ့ Lab လေ့ကျင့်ခန်းတွေကို Youtube , Facebook အစရှိတဲ့ နေရာတွေကနေ နည်းမျိုးစုံနဲ့ လေ့လာနိုင်နေလို့ပါ။
လိုအပ်တဲ့ သင်ထောက်ကူ ပစ္စည်းတွေဆိုတာကလဲ ကျတော်တို့ လေ့ကျင့်တုန်းကဆို GNS3 ပဲရှိလို့ တချို့လက်တွေဆိုလုပ်မရတဲ့အတွက် INE Rack Rental တွေ ကို နာရီနဲ့ ငှားပြီးလုပ်စရာ မလိုတော့လောက်အောင်ကို ရှိနေပါပြီ။
ဥပမာ EVE Emulator နဲ့ Virtual Box , VMware Workstation, VMware Player တွေလိုပေါ့။

သီအိုရီနဲ့ Lab သင်ခန်းစာတွေနဲ့  ပတ်သက်ပြီး အကောင်းဆုံး သင်ခန်းစာတွေ သင်ပေးနေတဲ့ အထဲက ကျတော် အကြိုက်ဆုံး Vendor တွေကတော့
- INE "www.ine.com"
- IPexpert (ကျတော်သိတာတော့ သူက အခု ပိတ်သွားပါပြီ။ အရင်က Video Lesson တွေကို လေ့လာလို့ရပါသေးတယ်။)
- Micronics Training  'https://micronicstraining.com"

တို့ပါပဲ။

ကိုယ်တိုင်လေ့လာဖို့ အပေါ်က အချက်တွေက ပြည့်စုံနေပါပြီ။
ပြီးရင်တော့ ကိုယ်က ပိုက်ဆံတတ်နိုင်သေးရင် Preparation Bootcamp program တွေဘာတွေ တက်ပေါ့။
နောက်တခုအရေးကြီးတာကတော့ Study Patner ပါပဲ။
CCIE Lab တွေက ခက်ခဲရှုပ်ထွေးတဲ့ အတွက် တချို့ အပိုင်းတွေမှာ ဆွေးနွေးဖို့ သူငယ်ချင်းတယောက်တော့ အနည်းဆုံးရှိသင့်ပါတယ်။
ဒါမှ ကိုယ်ခက်ခဲတဲ့နေရာမှာ သူ့အတွက်လွယ်နေတတ်ပြီး သူခက်ခဲတဲ့နေရာမှာ ကိုယ့်အတွက်လွယ်နေတာမျိုးတွေ ကို သိလာမှာပါ။

လေ့ကျင့်ဖို့အတွက် အချိန်ကတော့ အောက်က စာမေးပွဲ အကြောင်း မှာ ဆက်ပြောပါမယ်။


စာမေးပွဲ နဲ့ Exam Center တွေ အကြောင်းပြောပါရစေ။

Exam Center က ၂ မျိုးရှိပါတယ်။
ဟောင်ကောင် တို့ ဂျပန်တို့လိုနိုင်ငံတွေမှာ ရှိတဲ့ Fixed Location Lab Exam Center နဲ့
စင်ကာပူလိုနိုင်ငံအတွက် Mobile Lab Exam Center ဆိုပြီးတော့ပါ။

Fixed Locatin အတွက် Exam ကြေးက USD 1600 ဖြစ်ပြီး၊ Mobile Lab အတွက် က USD 1900 ဖြစ်ပါတယ်။
အကြောင်း အမျိုးမျိုးကြောင့် ဖြေမယ့်ရက်ကို ရွှေ့ချင်တယ်ဆိုရင် (၄၅) ရက်နဲ့ အထက်ဆိုပါက USD 350 ပေးရမှာ ဖြစ်ပြီး၊ (၄၅) ရက်အတွင်းဆိုပါက USD 500 ပေးရမှာ ဖြစ်ပါတယ်။
Exam အတွက် Lab Seat Booking ကို ရက် (၉၀) မတိုင်မှီအထိ Free ဖြစ်ပြီး ရက် (၉၀) အတွင်း ဝင်ပြီဆိုတာနဲ့ ပိုက်ဆံ အကျေပေးရမှာပါ။ မပေးနိုင်ရင် ကိုယ့် ခုံကို Cisco က Cancel လုပ်ပါတယ်။

စာမေးပွဲအချိန်က (၈) နာရီပါ။
Troubleshooting Section အတွက် (၂) နာရီ
Diagnostic Section အတွက် (၃၀) မိနစ်နဲ့
Configuration Section အတွက် (၅) နာရီ (၃၀) မိနစ်ပါ။

မော်နီတာက ၂၃ လက်မ နှစ်လုံးပေးထားပြီး ဘယ်ဖက် မော်နီတာက Primary ပါ။
ပေးထားတဲ့ System က Cisco Documentation ရယ်၊ Notepad ရယ်၊ Calculator ရယ်သုံးလို့ရပါတယ်။
ကီးဘုတ်နဲ့ မောက်စ်ကတော့ နေရာပေါ်မူတည်ပြီး ကွာပါတယ်။
စင်ကာပူမှာဆိုရင် မောက်စ်တွေ ကီးဘုတ်တွေက အသစ်ဖြစ်လို့ တော်တော် အဆင်ပြေပါတယ်။ ဒါပေမယ့် Connection ကတော့ အနည်းငယ်နှေးပါတယ်။
ထိုင်ခုံကလဲ အနိမ့်အမြင့် ညှိလို့မရပါဘူး။
ဟောင်ကောင်မှာကတော့ ထိုင်ခုံက ဆုံလည်ထိုင်ခုံဖြစ်ပြီး အနိမ့်အမြင့် ညှိလို့ရပါတယ်။
ဒါပေမယ့် ကီးဘုတ် နဲ့ မောက်စ်တွေက ဟောင်းနေတဲ့ အတွက် သိပ်အဆင်မပြေပါဘူး။
ကျတော် နောက်ဆုံးဖြေတုန်းကဆို "i" key နဲ့ "space" key က မာနေတဲ့အတွက် အချိန်ပိုကုန်ပါတယ်။
Connection ကတော့ Mobile Lab တွေထက် အနည်းငယ် မြန်ပါတယ်။

ပထမဆုံးဖြေရတာကတော့ Troubleshooting Section ဖြစ်ပြီး သတ်မှတ်ချိန် က (၂) နာရီပါ။
တကယ်လို့( ၂) နာရီနဲ့ မပြီးရင်တော့ Configuration Section က အချိန် (၃၀) မိနစ်ကို ချေးယူပြီးသုံးလို့ရပါတယ်။

တကယ်လို့ (၂) နာရီမပြည့်ခင် (၁) နာရီလောက်နဲ့ ပြီးရင်လဲ Section ကို End လုပ်လိုက်ပြီ: Diagnostic Section ကို သွားနိုင်ပါတယ်။
ပိုတဲ့ အချိန်ကို Configuration Section အတွက် သုံးနိုင်ပါတယ်။

Diagnostic Section အတွက်ကတော့ (၃၀) မိနစ်ကို အတိအကျ သုံးရပါတယ်။ စောပြီးလို့လဲ Configuration Section ကို ကျော်သွားလို့မရပါဘူး။ Section End သွားတဲ့ အထိ ထိုင်စောင့်နေရပါတယ်။ ဒီအချိန်မှာတော့ Configuration Section အတွက် Common ဖြစ်တဲ့ Configuration တွေကို ကြိုပြီးပြင်ဆင်ထားလို့ရတာပေါ့။ ဥပမာ OSPF, BGP , MPLS လိုဟာတွေဆို ကြိုပြီး ပြင်ထားလို့ရတာပေါ့။

Configuration Section မှာတော့ ကျန်တဲ့ အချိန် အကုန်လုံးကို သုံးပြီး ဖြေရပါတယ်။

ထမင်းစားချိန်ကတော့ (၁၅) မိနစ်ကနေ (၂၀) မိနစ်ခန့်ကြာတတ်ပါတယ်။

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

စာမေးပွဲ အချိန် (၈) နာရီက ထမင်းစားတဲ့ အချိန်မပါပါဘူး။

Troubleshooting နဲ့ Diagnostic Section နှစ်ခုစလုံးမှာ Count Down Timer လေးပါပါတယ်။
Troubleshooting Section မှာတော့ Monitor ရဲ့ ညာဖက်အပေါ်ထောင့်မှာ မြင်ရမှာ ဖြစ်ပြီး
Diagnostic Section မှာတော့ Monitor ရဲ့ ဘယ်ဖက်အပေါ်ထောင့်မှာ မြင်ရမှာ ဖြစ်ပါတယ်။
Section နှစ်ခုစလုံးရဲ့ Timer တွေက အချိန်ပြည့်ဖို့ ၅ မိနစ်ပဲ လိုတော့တဲ့ အခါ အနီရောင်ပြောင်းသွားပါတယ်။

Configuration Section မှာတော့ Timer မပါပဲ Proctor က အချိန်သတ်မှတ်ပေးထားပါတယ်။ အချိန်ပြည့်ခါနီးဆိုရင် သူက လာသတိပေးပါတယ်။ အချိန်စေ့ပြီဆိုရင်တော့ သူကိုယ်တိုင်ကပဲ လာပြီး Section End လုပ်ခိုင်းပါတယ်။

စာမေးပွဲ မဖြေခင်မှာ Exam Center ကို ၁၅ မိနစ်လောက်စောရောက်အောင် သွားရပါတယ်။
ရောက်တဲ့အခါ ဖြေမယ့်လူစုံရင် Proctor က အိမ်သာ ကိုဘယ်လိုသွားရလဲ လမ်းပြပါတယ်။ ပြီးရင် တခြားဆောင်ရန် ရှောင်ရန်တွေပြောပါတယ်။
ဘာပစ္စည်းမှာ မိမိနဲ့ အတူတူ ယူထားလို့မရပါဘူး။ အကုန် locker ထဲမှာ ထည့်သိမ်းရပါတယ်။ ချိုချဉ်တွေဘာတွေ နဲ့ ရေဘူး ယူချင်ရင် Proctor ကို အသိပေးပြီး ယူထားနိုင်ပါတယ်။ ဖြေနေတုန်းမှာ တခုခု (ဥပမာ ရှူဆေးတွေဘာတွေ) လိုချင်ရင်တော့ Proctor ကို ခွင့်တောင်းပြီးမှ ယူလို့ရပါမယ်။
အားလုံးရှင်းပြပြီးတဲ့အခါမှာ စာမေးပွဲအခန်းထဲဝင်ပြီး White Board ပေါ်မှာ စာမေးပွဲစချိန်နဲ့ နေ့လည် ထမင်းစားမယ့်အချိန်ကို ချရေးပါတယ်။
နေ့လည် ထမင်းစားပြီးတဲ့အခါ White Board ပေါ်မှာပဲ Exam ပြန်စတဲ့ အချိန်နဲ့ ပြီးမယ့်အချိန်ကို ထပ်ရေးပေးထားပါတယ်။
စာမေးပွဲဖြေနေတဲ့သူတွေ နာရီကြည့်ပြီး လုပ်နိုင်ကိုင်နိုင်အောင်လို့ပါ။

System ထဲကို login ဝင်ဖို့ Username နဲ့ Password ပါတဲ့ စာရွက်လေး ၂ ရွက် ပေးပါတယ်။ အဲဒီစာရွက်တွေမှာ ကိုယ့်ရဲ့ Cisco ID ပါပါတယ်။
စာရွက်ပေါ်မှာ မိမိစိတ်ကြိုက် note တွေချရေးနိုင်ပါတယ်။ Exam ပြီးရင်တော့ စာရွက်တွေကို Proctor ကို ပြန်ပေးရပါတယ်။

ဒီလိုနဲ့ ဖြေပြီးရင် Exam Section  ကို Proctor ကို အသိပေးပြီး End လုပ်ပြီးတာနဲ့ ထွက်ရပါတယ်။
ထွက်ပြီးရင်တော့ ပုံမှန်ဆို ၂ နာရီကနေ ၄ နာရီကြား အကြာမှာ Exam Result ထွက်ပါတယ်။ ဒါပေမယ့် တခါတလေဆိုရင်တော့ နောက်ရက်မှ ထွက်တတ်ပါတယ်။
ပုံသေတော့ တွက်ထားလို့မရပါဘူး။ ဖြေဘူးသမျှနဲ့ သူငယ်ချင်းတွေရဲ့ အတွေ့အကြုံအရကတော့ နောက်ရက်မှ Result ထွက်တာဆိုလို့ တခါပဲ တွေ့ဖူးပါသေးတယ်။

ကဲ ဒီလောက်ဆိုရင် CCIE နဲ့ ပတ်သက်တာတွေ တော်တော် ပြည့်စုံပြီလို့ ထင်ပါတယ်။

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

ဒီထက်ပိုပြီး သိချင်သေးရင် အောက်က Link တွေမှာ CCIE နဲ့ ပတ်သက်တာတွေ ထပ်ဖတ်နိုင်ပါသေးတယ်။
အောက်က လင့်တွေမှာဆိုရင် CCIE Exam အကြောင်းတွေ၊ ဘယ်လိုပြင်ဆင်ရပုံတွေနဲ့ CCIE တခုနဲ့တင် မလုံလောက်တော့တဲ့ အကြောင်းတွေကိုပါ ဖတ်ရမှာပါ။

http://kophyoccie.blogspot.com/2015/07/ccie-certificate.html

http://bimtrainings.com/2015/11/13/ccie-journey-part-1/

http://bimtrainings.com/2015/11/19/ccie-journey-part-2/

http://bimtrainings.com/2017/03/24/when-ccie-is-not-enough/

https://www.cbtnuggets.com/blog/2018/08/is-the-ccie-still-worth-it/


ကျေးဇူးတင်ပါတယ်။
(Be knowledgeable, pass it on then)


Quality of Service - IP Precedence and DSCP Values




IP Packet တခုမှာ Type of Service Field (TOS byte လို့လဲ ခေါ်ကြတယ်) ဆိုတာပါပါတယ်။
အဲဒီ TOS byte ကိုသုံးပြီး ကျတော်တို့တွေက Layer 3 Network Equipment တွေကို throughput, low delay, reliable service တွေအတွက် priority တွေကစားလို့ရပါတယ်။
ဒီတော့ TOS byte ကို နားလည်ဖို့အတွက် IP Precedence, DSCP အစရှိတဲ့ အခေါ်အဝေါ်ပေါင်းများစွာကို ကျတော်တို့ လေ့လာရမှာပါ။
ပထမဆုံး IP Precedence ဆိုတာကို လေ့လာရအောင်။

8 bits ရှိတဲ့ TOS byte  ကို ရှေ့ 3 bits နဲ့ နောက် 5 bits ခွဲထုတ်လိုက်ပါမယ်။

ရှေ့ 3 bits ကို precedence လို့ခေါ်ပြီး သူ့တန်ဖိုးကို IP Packet တခုရဲ့ Priority ကစားတဲ့အခါမှာ သုံးပါတယ်။
တကယ်လို့  Network Busy ဖြစ်နေပြီး Line congested ဖြစ်နေတဲ့အခါမှာ Precedence တန်ဖိုးပိုမြင့်တဲ့ IP Packet ကို Router က အရင် Process လုပ်ပြီး Precedence တန်ဖိုးနိမ့်တဲ့ IP Packet ကိုတော့ Drop လုပ်ပစ်မှာပဲ ဖြစ်ပါတယ်။
နောက်က 5 bits ကိုတော့ Type of Service လို့ ခေါ်ပြီး Network ရဲ့ Delay, Throughput နဲ့ Reliable အမျိုးအစားတွေကို သတ်မှတ်ချင်တဲ့အခါမှာ အသုံးပြုပါတယ်။
ဒီနေရာမှာ 8 bits လုံးကို Type of Service Byte လို့ခေါ်ပြီး 8 bits ရဲ့ နောက်ပိုင်း 5 bits ကိုတော့ Type of Service Bits လိုခေါ်တာကို ရောပြီအမှတ်မမှားမိအောင် သတိထားဖို့လို့ပါတယ်။
အောက်က ဇယားမှာတော့ bit တခုချင်းစီရဲ့ အဓိပ္ပာယ်တွေကို ရှင်းပြထားပါတယ်။


အပေါ်က ပြောခဲ့တာတွေထဲက type of service bits တွေကို လက်တွေ့မှာ တခါမှ အသုံးမပြုကြပါဘူး။
ဒါနဲ့ အဲ့ဒီ Type of Service 5 bits ထဲက နောက်ဆုံး 1 bit ကို MBZ (Must Be Zero) အဖြစ်သတ်မှတ်ပြီး အပြင်မှာ မသုံးပဲ စမ်းသပ်ဖို့အတွက်ပဲ ထားမယ်ဆိုပြီး RFC 1349 ထပ်ထွက်လာပါတယ်။


ဒီတော့ Type of Service Bits ဟာ 4 bits ပဲ ရှိပါတော့မယ်။
ဒီ 4 bits ပဲရှိတော့တဲ့ Type of Service Bit တွေရဲ့ အဓိပ္ပာယ်ကို အောက်က ဇယားမှာ ပြထားပါတယ်။
ဒီမှာ လည်း တကယ်တော့ Type of Service Bits, 4 Bits ကို အပြင်မှာ မသုံးကြပါဘူး။
ဒီတော့ ဘာသုံးလဲ။ Differentiated Services ဆိုတာကို သုံးကြပါတယ်။
Differentiated Services
TOS Byte ကို DS (Differentiated Services) Field လို့ပြောင်းလိုက်တဲ့ RFC 2474 ဆိုတာ ထပ်ထွက်လာပါတယ်။

အဲဒီ 8 bits ရှိတဲ့ DS Field ကို ရှေ့ပိုင်း 6 bits ကို Differentiated Services CodePoint (DSCP) ၊ နောက်ပိုင်း 2 bits ကို Currently Unused (CU) ဆိုပြီး သတ်မှတ်ပါတယ်။
DSCP က အပေါ်က ပြောခဲ့တဲ့ Precendance value လိုမျိုး Traffic တွေကို Priority သတ်မှတ်ဖို့အတွက် သုံးတာပါ။
ဒီ DSCP value တွေကပဲ host/node တခုချင်းစီ အပေါ် Per Hop Behavior (PHB) လို့ ခေါ်တဲ့ traffic ဖြတ်သန်းသွားလာမှုပုံစံတွေကို တမျိုးတဖုံ အကျိုးသက်ရောက်စေပါတယ်။
ဥပမာ အနေနဲ့ ရှင်းပြရမယ်ဆိုရင် QoS မှာ End to End connection အတွက် Traffic ကို reserve လုပ်တဲ့အခါ End to End ကြားထဲမှာ ရှိတဲ့ Network Device တခုချင်းစီကို bandwidth reserve လုပ်ပေးရတဲ့ IntServ (Integrated Services) ဆိုတာနဲ့ Network Device တခုချင်းစီကို မတူညီတဲ့ priority value codepoint တွေနဲ့ bandwidth reserve လုပ်လို့ရတဲ့ တနည်းအားဖြင့် mark လုပ်လို့ရတဲ့ DiffServ (Differentiated Services) ဆိုပြီး ရှိပါတယ်။
ဒီနှစ်မျိုးထဲက DiffServ ဆိုတာက Per Hop Behavior ရဲ့ idea ကို ယူသုံးထားတာပါပဲ။
PHB မှာလဲ
Default PHB နဲ့ Class-Selector (CS) PHB ဆိုပြီး နှစ်မျိုးရှိပါသေးတယ်။
Default PHB ကတော့ DSCP Value ကို 000000 သုည ခြောက်လုံး ထားလိုက်ပြီး packet ကို “best effort” အဖြစ် process လုပ်ခိုင်းတာပါ။
DSCP ကို support မလုပ်နိုင်ပဲ IP Precedence ကိုပဲ support လုပ်တဲ့ network device အဟောင်းတွေအတွက် compatible ဖြစ်အောင် Class-Selector PHB ဆိုတာကို သုံးပါတယ်။ သူ့မှာတော့ DS Field ရဲ့ ရှေ့ 3 bits ကို class-selector codepoint တွေရှိအဖြစ်သတ်မှတ်ထားပါတယ်။ အောက်က ဇယားလေးကို ကြည့်လိုက်ရင် ရှင်းသွားမှာပါ။


အချိန်အနည်းငယ်ကြာတဲအခါ
Queueing နဲ့ Congestion Avoidance ဆိုတဲ့ Function နှစ်ခုပါတဲ့ Assured Forwarding PHB (AF PHB) ဆိုတဲ့ နောက်ထပ် RFC တခု ထွက်လာပြန်ပါတယ်။
ဒီမှာတော့ Traffic Class ၄ မျိုးခွဲထားပြီး တမျိုးချင်းစီမှာ queue ပုံစံ အမျိုးမျိုးထပ်ခွဲထားပါတယ်။ Precedence အနေနဲ့ တော့ low, medium နဲ့ high ဆိုပြီး level ၃ ခုသတ်မှတ်ထားပါတယ်။
အောက်က DS Field ပုံလေးမှာ ပြထားတာကို ကြည့်ရင် ရှင်းပါတယ်။


ရှေ့ 3 bits က Class ခွဲဖို့ ဖြစ်ပြီး နောက် 3 bits က queue ပြည့်နေရင် ဘယ် traffic ကို drop လုပ်ရမလဲ ဆုံးဖြတ်ဖို့ ဖြစ်ပါတယ်။ နောက်ဆုံး 2 bits က တော့ နောက်ပိုင်းမှာ သုံးဖို့အတွက်ဖြစ်ပြီး လက်ရှိမှာတော့ unused ပေါ့။
Class 1 က priority အနိမ့်ဆုံးဖြစ်ပြီး Class 4 ကတော့ priority အမြင့်ဆုံးဖြစ်ပါတယ်။
ဒါကြောင့် Video Traffic တွေအတွက် QoS configuration တွေကို ကြည့်တဲ့အခါ AF41 လေးတွေနဲ့ ဆိုတာ သတိထားမိပါလိမ့်မယ်။


Assured Forwarding PHB (AF PHB) ကိုသိပြီးရင် Expedited Forwarding PHB (EF PHB) ဆိုတာကိုလဲ မသိလို့မရဘူး။

သူ့မှာလဲ Queueing နဲ့ Policing ဆိုတဲ့ Function ၂ မျိုးရှိပါတယ်။
သူ့ကို သုံးရတဲ့ ရည်ရွယ်ချက်ကတော့ voice traffic လိုမျိုး delay နဲ့ packet loss သိပ်အဖြစ်ခံလို့မရတဲ့ traffic မျိုးအတွက် သုံးရတာပါ။ Network က အရမ်းအလုပ်များပြီး congested ဖြစ်နေတဲ့အချိန်မှာ packet loss ဖြစ်တာတို့ delay ဖြစ်တာတို့ ကြုံရပါတယ်။ အဲ့လို အချိန်မျိုးမှာ Voice Traffic လိုမျိုး packet ကို priority queue ထဲကို ထည့်ပြီး တခြား queue ထဲက packet တွေထက် အရင် send out လုပ်ခိုင်းတာမျိုးကို Expedited Forwarding လုပ်တယ်လို့ ခေါ်တာပါ။
သူ့ကို သုံးရင် rate limit လေးနဲ့ သုံးမှအဆင်ပြေပါတယ်။ မဟုတ်ရင် တခြား packet တွေအတွက် အခွင့်အရေးကို ရတော့မှာ မဟုတ်တော့လို့ပါ။ သူ့အတွက် DSCP တန်ဖိုးကိုတော့ EF ဆိုပြီး သတ်မှတ်ထားပါတယ်။
သူ့ကိုတော့ Voice Traffic အတွက် QoS configuration တွေကို ကြည့်တဲ့အခါ dscp ef ဆိုတာမျိုး မြင်ရပါလိမ့်မယ်။


အပေါ်က ပြောခဲ့တာတွေက သီအိုရီတွေပဲ ဖြစ်ပြီး ဝင်လာတဲ့ Traffic တွေကို အမျိုးအစားခွဲပြီး value သတ်မှတ်ယုံပဲ ရှိပါသေးတယ်။ တကယ့်လက်တွေမှာတော့ ဒီ Traffic ကို ဒီ Value ထားပါ ဆိုပြီး Class တွေကို ခွဲထားယုံနဲ့ Router တွေ Switch တွေက လိုချင်တဲ့ Queue Processing ကို လုပ်မပေးနိုင်ပါဘူး။ အဲလိုလုပ်ဖို့အတွက် ဒီ Class ကိုတော့ မြန်မြန် send ပါ။ ဒီ Class ကိုတော့ နောက်မှ send ပါ ဆိုတာမျိုး ထပ်ခိုင်းရပါသေးတယ်။

နောက်တခုက အပေါ်က IP Precedence နဲ့ DSCP Value တွေက Vendor တခုနဲ့ တခု သတ်မှတ်ပုံ မတူတဲ့အတွက် QoS configure လုပ်ဖို့လိုပြီဆိုရင် သက်ဆိုင်ရာ Vendor ရဲ့ Guide ကို ဖတ်ဖို့လိုပါတယ်။
အောက်မှာတော့ အပေါ်က ပြောခဲ့တာတွေရဲ့ RFC တွေကို ဖတ်ချင်ရင် ဖတ်ရအောင် ထည့်ပေးထားပါတယ်။

ကဲ ဒီလောက်ဆို QoS ရဲ့ Value တွေအကြောင်း တီးမိခေါက်မိပြီလို့ ထင်ပါတယ်။


တခြား QoS post တွေကိုတော့ အောက်က လင့်တွေမှာ ဖတ်နိုင်ပါတယ်။


Quality of Service - Classification in brief



ပျော်ရွှင်ပါစေဗျာ။
(Be knowledgeable, pass it on then)


Software Defined Networking (SDN) – 101, Part 2

ပြီးခဲ့တဲ့ Part 1 မှာတုန်းက Traditional Networking ရဲ့ ကန့်သတ်ချက်တွေ အကြောင်းနဲ့ SDN အကြောင်းကို အနည်းငယ် အစပျိုးခဲ့ပါတယ်။
အခုစပြောမှာကတော့ SDN ရဲ့ အဓိက အစိတ်အပိုင်းဖြစ်တဲ့ SDN Controller အကြောင်းပါ။
သူကတော့ Traditional Network တွေမှာတုန်းက လိုအပ်တဲ့ Configuration တွေကို Configure လုပ်ဖို့ Network Device တခုချင်းစီရဲ့ Control Plane ကို ဝင်ပြီး configure လုပ်ရတာမျိုးမဟုတ်တော့ပဲ။ သူ့ရဲ့ Control Plane တခုတည်းကို Configure လုပ်ပြီး Network Device တွေကို ခိုင်းတာပါ။
ဒီမှာလဲ SDN Controller ရဲ့ Vendor ပေါ်မူတည်ပြီး Controller မှာပဲ Control Plane ရှိတာမျိုးနဲ့ Network Device တွေရဲ့ Control Plane တွေကို Control လုပ်တဲ့ Controller ဆိုပြီး ကွဲပါသေးတယ်။
အောက်ကပုံကို ကြည့်လိုက်ရင် SDN Controller ဆိုတာ ဘာလဲ ဆိုတာကို အနည်းငယ် ထင်သာမြင်သာရှိပါလိမ့်မယ်။


SDN Controller မှာ
Northbound Interface နဲ့ Southbound Interface ဆိုပြီး ရှိပါတယ်။
Northbound Interface ဆိုတာကတော့ SDN Controller ကို Access လုပ်ဖို့နဲ့ လိုအပ်တဲ့ Instruction တွေပို့ပေးဖို့ / ရယူဖို့ အတွက် သုံးရတဲ့ Interface ပါ။
ဒီ Interface ကို Access လုပ်ဖို့အတွက် API (Application Programming Interface) ကို
- သူ့ ရဲ့ Vendor က ထည့်ပေးလိုက်တဲ့ GUI
- JavaScript လို Scripting Language တမျိုးမျိုး
- Python ကဲ့သို့တော့ Programming Language တမျိုးမျိုး
- တခြား Third Party Application မျိုးနဲ့
Access လုပ်နိုင်ပါတယ်။
SDN Controller က REST API (Representational State Transfer) ဆိုတာကို သုံးပြီး Instruction တွေကို အပေးအယူလုပ်ပါတယ်။
ဒီလို လုပ်တဲ့အခါ သုံးတဲ့ Message ကတော့ ကျတော်တို့ နေ့စဉ်သုံးနေကျဖြစ်တဲ့ HTTP message ပဲ ဖြစ်ပါတယ်။
ကျတော် အပေါ်မှာ ပြောခဲံတဲ့ API ကို Access လုပ်နိုင်တဲ့ ပုံစံတမျိုးမျိုးနဲ့ SDN Controller ကို HTTP Get message ပို့ပြီး Network မှာ လက်ရှိရှိနေတဲ့ VLAN Information တွေကို Request လုပ်လိုက်တယ်ဆိုပါစို့။
SDN Controller က HTTP Respone message ပြန်ပို့ပြီး ကိုယ်လိုချင်တဲ့ information ကို ပြန်ပို့ပေးပါတယ်။
ဒီလိုပြန်ပို့ပေးတဲ့ အခါ Format ၂ မျိုးနဲ့ ပို့ပေးပါတယ်။ သူတို့ကတော့
- JSON (JavaScript Object Notation) နဲ့
- XML (eXtensible Markup Language) တို့ပဲ ဖြစ်ပါတယ်။
ဒါကတော့ Northbound Interface အကြောင်းပါ။ အောက်ကပုံလေးကို ကြည့်လိုက်ရင် အပေါ်က ပြောထားတာတွေထက် ပိုရှင်းပါလိမ့်မယ်။



Southbound Interface ကတော့ SDN Controller ကနေ Network Device တွေကို ချိတ်ဆက်ဖို့ပြီး Instuction တွေပေးဖို့အတွက် လိုအပ်တဲ့ Interface ပါ။
သူကလဲ Physical Interface မဟုတ်ပဲ Software Interface တခုပါပဲ။
ကျတော်တို့ မြင်ဖူးကြားဖူးနေတဲ့
- OpenFlow
- Cisco OpFlex နဲ့
- အခုလက်ရှိ Network Device တွေအတွက် Cisco က ထုတ်ပေးထားတဲ့ APIC-EM ဆိုတာတွေကတော့ အပေါ်က ပြောတဲ့ Soutbound Interface တွေပဲ ဖြစ်ပါတယ်။
အောက်ကပုံလေးကတော့ Southbound Interface ကို ထင်သာမြင်သာရှိစေပါတယ်။


ကဲ ဒါကတော့ SDN Controller နဲ့ သူ့ရဲ့ Interface နှစ်ခုအကြောင်းပါပဲ။
အကျဉ်းချုံးမှတ်ရမယ်ဆိုရင်တော့
Southbound Interface ဆိုတာကတော့ Network Device တွေကို Configure လုပ်ဖို့အတွက် Instruction တွေပေးဖို့ (တနည်းအားဖြင့် Program ပေးဖို့) ဖြစ်ပြီး။
Nothbound Interface ဆိုတာကတော့ SDN Controller ကြီးကို Control လုပ်ဖို့အတွက် ဖြစ်ပါတယ်။
SDN မှာ အားသာချက်က Network Device တခုချင်းစီအတွက် ပေးရမယ့် အချိန်သက်သာပြီး Infrastructure ရဲ့ Topology တခုလုံးကို Centralize လုပ်နိုင် မြင်နိုင်တာဖြစ်ပါတယ်။
အားနည်းချက်ကတော့ Centralize ဖြစ်နေတဲ့အတွက် လုံခြုံရေးပိုင်းနဲ့ မှာ အထူးဂရုစိုက်ဖို့ လိုသလို Controller မှာ အမှားတခုခုလုပ်လိုက်တာနဲ့ Network တခုလုံး ပြဿနာတက်မှာပဲ ဖြစ်ပါတယ်။

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

Original Source : https://networklessons.com/cisco/ccna-routing-switching-icnd2-200-105/introduction-to-sdn-software-defined-networking/


ကျေးဇူးတင်ပါတယ်ဗျာ။
(Be knowledgeable, pass it on then)








Software Defined Networking (SDN) - 101, Part 1

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

SDN ကို မပြောခင် ဘာကြောင့် SDN ကို လေ့လာဖို့ လိုသလဲ ဆိုတာလေး ပြောပါရစေ။

ဒီဘက်ခေတ်မှာ Heart Rate Monitor, Steps Counter , Watch, Wireless IP Camera အစရှိတဲ့ Device တွေဟာ Internet Access လိုလာကြပါတယ်။
ဘာလို့လိုအပ်လဲ ဆိုတဲ့ အကြောင်းပြချက် အများကြီးရှိတဲ့ အထဲက ဥပမာ အနေနဲ့ အနည်းငယ်ထုတ်ပြရမယ်ဆိုရင်

- Statistic Data Analysis
- Real Time monitoring
- Real Time Data Streaming

စတာတွေပဲ ဖြစ်ပါတယ်။

အပေါ်က ပြောခဲ့တဲ့ Device တွေကို Internet of Things (Stupid Device) တွေလို့ ခေါ်ကြပါတယ်။
အဲဒီ ပစ္စည်းတွေ ပေါ်မှာ run နေတဲ့ Application တွေအတွက် လုံလောက်တဲ့ ပြုပြင်ပြောင်းလဲမှုတွေလုပ်ဖို့ နောက်ကွယ်မှာ အလုပ်လုပ်ပေးနေတဲ့ Server တွေရှိပါတယ်။
အဲဒီ Server တွေကို အချိန်နဲ့ တပြေးညီ လိုအပ်သလို ပြုပြင်ပြောင်းလဲနေဖို့ အတွက် Intent-Based Network ဆိုတာလိုလာပြန်ပါတယ်။
အဲဒီ Network အတွက်ပဲ ကျတော်တို့တွေ SDN ဆိုတာကို လိုလာပါတယ်။

ဒီတော့ မေးစရာရှိလာပါတယ်။ SDN မှပဲ လုပ်နိုင်မှာလား။ Traditional Network မှာရော မလုပ်နိုင်ဘူးလားပေါ့။

ဒီမေးခွန်းအတွက် Traditional Network ရဲ့ ကန့်သတ်ချက်တွေ အကြောင်းကို နားလည်ထားမှ ရပါမယ်။

ဆိုကြပါတော့ Router တလုံးက သူ့ဆီကို ဝင်လာတဲ့ Packet တခုကို Route ပေးဖို့

- Destination က ဘယ်လဲ။ Routing Table ထဲမှာရော ရှိရဲ့လား။
- ဘယ် Routing Protocol နဲ့ Learn လုပ်ထားတာလဲ။
- MAC Address က ဘာလဲ။
- Destination ကို သွားဖို့ Hop ဘယ်နှစ်ခု ဖြတ်ခဲ့ပြီး ဘယ်နှစ်ခု ထပ်ဖြတ်သွားရအုံးမှာလဲ။
- ဝင်လာတဲ့ Packet ကရော မပျက်မစီးပဲ ရှိနေသေးလား။

စတဲ့ လုပ်ရမယ့် အဆင့်တွေရှိပါတယ်။

အဆိုပါ လုပ်ငန်းစဉ်တွေ လုပ်ဖို့ အတွက်

Control Plane
Data Plane
Management Plane

ဆိုတာတွေ Network Device  တွေမှာရှိပါတယ်။

Control Plane ကတော့ routing information တွေ exchange လုပ်ဖို့ အဓိက တာဝန်ယူပါတယ်။
Data Plane ကတော့ Traffic တွေကို forward လုပ်ဖို့ တာဝန်ယူပါတယ်။
Management Plane ကတော့ Network Device တွေကို access လုပ်ဖို့ အတွက်လိုအပ်မှုတွေကို ပြင်ဆင်ဖို့ တာဝန်ယူပါတယ်။

Plane တွေရဲ့ တာဝန်ယူ အလုပ်လုပ်ပုံကို အောက်က ပုံလေးမှာ နမူနာ ကြည့်နိုင်ပါတယ်။



ဒီ Plane တွေအကြောင်း အကြမ်းဖျဉ်း သိပြီဆိုရင် Traditional Netowork တွေရဲ့ ကန့်သတ်ချက်ကို ပြောပါမယ်။

အောက်က ပုံလေးကို ကြည့်ကြည့်ပါ။



Virtualized Server တွေ အများကြီး Run ထားတဲ့ ESXi Server တလုံး Network မှာ ရှိတယ်ပေါ့။

လုပ်ငန်းလိုအပ်ချက်အရ Virtual Server တလုံး run ဖို့လိုပြီး အဲဒီ Server အတွက် VLAN တခုလိုအပ်တယ်ပေါ့။
ဒီအခါမှာ System Team အတွက်က လိုအပ်တဲ့ Hardware Resource သာ ESXi မှာ ရှိသေးရင် ချက်ချင်းဆိုသလို Server ကို Provisioning လုပ်နိုင်ပါတယ်။
၅ မိနစ်တောင် မကြာပါဘူး။

ဒါပေမယ့် Network Team အတွက်ကတော့ လိုအပ်တဲ့ VLAN ကို Switch တိုင်းမှာ Create လုပ်ဖို့ ၊ SVI အသစ်အတွက် Routing ၊ VLAN အသစ်ကနေ ကျန်တဲ့ Subnet တွေကို သွားနိုင်အောင် ခွင့်ပြုဖို့ Firewall တွေ Configure လုပ်ဖို့ ၅ ရက်လောက် ကြာတတ်ပါတယ်။ ဒါက အစောဆုံးပါ။ :D

ကဲ ဒီမှာပဲ Software Defined Networking ဆိုတာကြီးက Business လိုအပ်ချက်အနေနဲ့ ပေါ်လာတော့တာပါပဲ။

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

အဲလို အချိန်နဲ့ တပြေးညီ သိနေရဖို့ နောက်ကွယ်က Run နေတဲ့ Infrastructure ဆိုတာ တခုခု ပြောင်းလဲဖို့ လိုတိုင်း စောင့်နေရတာမျိုး ဖြစ်လို့မရတော့လို့ပါပဲ။

SDN မှာတော့ Lightweight Wireless Access Point တွေကို Centralized Wireless Controller လိုမျိုး LightWeight Router, Switch, Firewall တွေကို Centralized Controller ကနေ တခါတည်းနဲ့ Configure အားလုံးကို လုပ်နိုင်တော့တာပဲ ဖြစ်ပါတယ်။

နောက် Post မှာ API, Python, SDN Controller စတာတွေကို ရေးပါမယ်။

ကျေးဇူးတင်ပါတယ်ဗျာ။
(Be knowledgeable, pass it on then)

My Acknowledgements to supporter on my CCIE journey

၂၀၁၃ မှာ Cisco Certified Entry Networking Technician (CCENT) လက်မှတ်စရပြီးတာကနေ Cisco လမ်းကို လျှောက်လာလိုက်တာ ခု 2018 ကုန်ခါနီး မှာတော့ Cisco Certified Internetwork Expert (CCIE) အဖြစ်တော့ ရောက်ခဲ့ပါပြီ။

CCIE တယောက်ဖြစ်ဖို့ အတွက် အထောက်အပံ့ကောင်းတွေ ပေးခဲ့တဲ့ ကျေးဇူးတင်ရမယ့်သူတွေ ကျတော့်မှာ ရှိပါတယ်။

တနေ့တနေ့ ကီးဘုတ်နဲ့ မော်နီတာကို ပဲ အဖော်ပြုနေတဲ့ ခင်ပွန်းကို တချက်ကလေးမှ အပြစ်မမြင်ပဲနေပေး၊ စာမေးပွဲအတွက် ပြင်ဆင်ချိန်ကနေ စာမေးပွဲ အောင်တဲ့အထိ ဆိုရင် ကားတစီးလောက် ဝယ်နိုင်တဲ့ ငွေပမဏကို သုံးတဲ့ ကျတော့်ကို တစက်ကလေးမှ အပြစ်မတင်တဲ့ ကျတော့်ရဲ့ ဇနီး Hnin Ei Phyu

စာမေးပွဲ ဖြေဖို့ ပြင်ဆင်နေတဲ့ အချိန်တလျှောက်လုံး ငြင်းကြခုန်က ဆွေးနွေးကြနဲ့ တကယ့်ကို Study Partner ကောင်းတယောက်ဖြစ်ခဲ့တဲ့ ဖြစ်လဲ ဖြစ်နေဆဲ ဖြစ်တဲ့ KO KYAW KYAW NAING

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

KO SOE MIN HTIKE (CCIE# 58654) - (Routing and Switching)
KO SAI KYAW ZIN PHYO (CCIE# 58710) - (Routing and Switching)
KO THAN HTIKE WAI (CCIE# 58711) - (Routing and Switching)

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

၂၀၁၆ ဇူလိုင်လ ကနေ ၂၀၁၆ ဒီဇင်ဘာလ အထိ တက်ခဲ့တဲ့ BIM ကတော့ ကျတော့် CCIE လမ်းကြောင်းရဲ့ အစပါပဲ။

ဒီအတွက် စင်ကာပူမှာ သင်တန်းဖွင့်ပေးခဲ့တဲ့
KO ZAY YAR PHYOE (CCIE #24573) - (Service Provider, Routing and Switching)
(ကျတော်တို့ Batch ပြီးတော့ ဆက်မဖွင့်တော့ပါ။ မြန်မာပြည်ပြန်ပြီး သူဌေးကြီးတွေပြန်လုပ်ကြတော့ မယ်ဆိုလို့ပါ။)

သီအိုရီတွေ သင်ပေးခဲ့ပြီး စာမေးပွဲ ဖြေဖို့ (စာမေးပွဲ ဖြေဖို့ Sponsor တော့မပေးပဲ) တဖွဖွ ပြောတဲ့
KO HTUN WIN NAING (CCIE #52207) -  (Routing and Switching)

Troubleshooting ကို ဘယ်လိုမျိုး လုပ်ရလဲ ဆိုတာကို စိတ်ရှည်လက်ရှည် သင်ပေးခဲ့တဲ့
KO AUNG KHING SAW OO (CCIE #51658) - (Routing and Switching)

တို့ကို ဒီနေရာကနေပဲ ကျေးဇူးတင်ကြောင်း မှတ်တမ်းတင်ပါရစေ။

Exam နဲ့ Exam Center တွေအကြောင်း မေးတိုင်း ဖြေပေးခဲ့တဲ့
KO MIN WAI (CCIE #53821) - (Routing and Switching)
KO YAN NAING AUNG (CCIE #56101) - (Routing and Switching)

စာမေးပွဲ Result မကောင်းတာနဲ့ ချက်ချင်းဖုန်းတွေဆက်ပြီး အားပေးတတ်တဲ့
KO NANDA KYAW (CCIE #55535) - (Routing and Switching)

CCIE နဲ့ပတ်သက်ပြီး မှတ်သားစရာတွေကို သူ့ blog မှာ အမြဲရေးတတ်တဲ့
KO AUNG PHYO LWIN  (CCIE #38100) - (Routing and Switching)
(သူ့စာလေးတွေထဲက မှတ်သားစရာတွေက Exam အတွက်ရော လက်တွေ့လောက အတွက်ပါ အထောက်အကူ အတော်ဖြစ်ခဲ့ပါတယ်။)

လိုအပ်တဲ့ အထောက်အပံ့တွေကို လိုအပ်တိုင်းမှာ ချက်ချင်းဆိုသလို ပေးတဲ့
KO NYAN HTOO AUNG (CCIE #59654) - (Routing and Switching)

တို့ကို ဒီနေရာကနေပဲ ကျေးဇူးတင်ကြောင်း မှတ်တမ်းတင်ပါရစေ။



ကျေးဇူးတင်ပါတယ်ဗျာ။
(Be knowledgeable, pass it on then)

















Contact Form for ictformyanmar.com

Name

Email *

Message *