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)