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

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)

















Useful Cisco Feature Tools

ဒီနေ့ ပျင်းပျင်းနဲ့ Cisco Site ကို မွှေရင်းနဲ့ အရင်ကထက် ပိုများနေတဲ့ Feature Tools တွေ တွေ့မိလို့ သဘောကျတဲ့ Tool လေးတွေ ပြန်မျှလိုက်ပါတယ်။

IPSec Overhead Calculator Tool ကတော့ ASA နဲ့ IOS device တွေမှာ IPsec tunnel သုံးတဲ့ အခါ MTU Size ကို တွက်လို့ရအောင် သုံးနိုင်ပါတယ်။
https://cway.cisco.com/tools/ipsec-overhead-calc/


IPsec Lan to Lan Configuration Checker ကတော့ IPsec Configuration လုပ်ထားတာ မှန် မမှန် စစ်ဆေးပေးတာပါ။
https://cway.cisco.com/tools/L2L-Checker/


Packet Capture Config Generator and Analyzer ကတော့ Wireshark တွေဘာတွေ မသုံးတော့ပဲ Device ထဲမှာ တခါတည်း Packet Capture လုပ်ပြီး Real Time ကြည့်လို့ရအောင် Configure လုပ်ပေးဖို့ ကူညီတာပါ။
https://cway.cisco.com/tools/CaptureGenAndAnalyse/


Subnet Calculator ဒါကတော့ Third-Party Website/Tool တွေ မသုံးချင်ရင် အဆင်ပြေတာပေါ့။
https://cway.cisco.com/tools/subnetcalc/

Cisco Firewall Configuration Conversion Tool ကိုတော့ တခြား Firewall Vendor (ဥပမာ Juniper/Checkpoint) ကနေ Cisco ASA ကို Migrate လုပ်ချင်တဲ့ အခါ ကူညီပေးဖို့ပါ။
https://fwmig.cisco.com/


Access List Checker ကတော့ အလွန်အင်မတန်များပြားလှတဲ့ Access List တွေ နဲ့ Device တွေမှာ Access List ကို စစ်ဆေးချင်တဲ့ အခါ သိချင်တဲ့ Access List တခုကို ရှာတဲ့ အခါ လွယ်ကူအောင် လုပ်ပေးတာပါ။
https://cway.cisco.com/tools/accesslist/


အပေါ်က ပြောထားတဲ့ Tool တွေ အပြင် IOS Device Command ကနေ NXOS Device Command ကိုပြောင်းသုံးဖို့ Convert လုပ်ပေးတဲ့ Tool အစရှိတဲ့ များပြားစွားသော Tool တွေကို လက်တည့်စမ်းကြည့်ချင်ရင်တော့ အောက်က လင့်မှာ ရနိုင်ပါတယ်။
အားလုံး အတွက် Cisco ID လေးပဲ လိုပါတယ်။ တော်တော်များများကတော့ Beta Version ပဲရှိသေးတာ ဖြစ်လို့ ပြည့်စုံကောင်းမွန်တဲ့ အဆင့်ရောက်ဖို့တော့ အနည်းငယ်လိုပါသေးတယ်။
https://www.cisco.com/c/en/us/support/web/ToolsCatalogNew.html#/

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

Contact Form for ictformyanmar.com

Name

Email *

Message *