Border Gateway Protocol (BGP) ဆိုတာ exterior gateway protocol ပါပဲ။
RIP, OSPF, EIGRP စတာတွေကတော့ interior gateway protocol တွေပေါ့။
လက်ရှိ သုံးနေတဲ့ BGP version ကတော့ Version 4 ပါ။
BGP ကို "path vector" routing protocol လို့ ပြောနိုင်သေးတယ်။
သူ့ကို Autonomous System (AS) တွေထဲမှာ Route လုပ်ဖို့ဆိုတာထက် Autonomous System (AS) တွေတခုနဲ့တခုကြားမှာ Route လုပ်ဖို့အတွက် ဖန်တီးထားတာလို့ပြောလို့ရတယ်။
သူ့မှာ လဲ သတ်မှတ်ထားတဲ့ Autonomous System Number (ASN) ဆိုတာရှိပါသေးတယ်။
အရင်ကတော့ 16-bit number သုံးတဲ့ 1 ကနေ 65535 ပေါ့။ သူ့မှာ Internet ပေါ်မှာ သုံးလို့ရတဲ့ public AS range နဲ့ Internet ပေါ်မှာ သုံးမရတဲ့ private AS range ဆိုပြီးရှိသေးတယ်။
Private AS range ကတော့ 64512 ကနေပြီးတော့ 65535 ထိပါ။
၂၀၀၉ ခုနှစ် ဇန်နဝါရီက စပြီး 32-bit AS number ကိုစသုံးကြပါတယ်။
AS Number format က 0-65535.0-65535 ဖြစ်သွားတယ်ပေါ့။
BGP က Protocol အနေနဲ့ TCP ကိုသုံးပြီး Port ကတော့ 179 ကိုသုံးပါတယ်။
ဒါတွေကတော့ knowledge အနေနဲ့ အကျဉ်းချုံးပြောထားတာပါ။ အသေးစိတ်သိချင်ရင်တော့ Internet မှာရှာဖတ်နိုင်ပါတယ်။
BGP ကို ဘယ်လိုအခြေအနေတွေမှာ သုံးလဲ?
- မတူညီတဲ့ Service Provider တွေဆီကနေ တခုထက်ပိုတဲ့ Network Connections တွေနဲ့ AS တွေကို ချိတ်ဆက်ထားတဲ့အခါမျိုး (ဥပမာ Internet Service Provider ၂ ခုဆီကနေ Internet ကိုထွက်တာမျိုး)
- Service Provider တခုတည်းကနေ သီးခြား Central Office ဒါမှမဟုတ် မတူညီတဲ့ Routing Policy တွေနဲ့ တခုထက်ပိုတဲ့ Network Connection တွေသုံးပြီး AS တွေကို ချိတ်ဆက်ထားတာမျိုး
- နောက်တခါ Transit Network လို မျိုးမှာ သုံးပါတယ်။
ရေးဖို့စိုင်းပြင်းနေတာကတော့ lab ပိုင်းပါ။ ဒါပေမယ့် သီအိုရီလေးလဲ နည်းနည်းတော့ ပြောမှ ဖြစ်မယ်ထင်လို့ ခြေဆင်းအနေနဲ့ နည်းနည်းထည့်ရေးလိုက်တာပါ။
ဆက်ပါအုံးမယ်...
ပျော်ရွှင်ပါစေဗျာ။
(Be knowledgeable, pass it on then)
Solving HCL 7.1.59 installation error
HP Router, Switch တွေနဲ့ အလုပ်လုပ်ရတဲ့အခါ Simulation လုပ်ကြည့်ဖို့အတွက်
HP Comware simulator (H3C Cloud Lab) လေး Install လုပ်တဲ့အခါ အောက်ကလို error တက်နေပါတယ်။
ကျတော်စက်မှာ Virtualbox Version 5.0.16 သွင်းထားတာပါ။ Latest Version ပါ။
ဒီ error ကိုဖြေရှင်းဖို့ registry editor ကိုဖွင့်ပြီး။
HKEY_LOCAL_MACHINE>SOFTWARE>Oracle>Virtualbox ကိုသွားပါ။
Version နဲ့ VersionExt ရဲ့ Data ကို 4.2.18 ကိုပြောင်းလိုက်ပါ။
ပြီးတာနဲ့ HP Comware Simulator (H3C Cloud Lab) ကို ပြန် install လုပ်ကြည့်ပါ။
အဆင်ပြေသွားပါလိမ့်မယ်။
Simulator installation ပြီးတဲ့အခါ Registry value ကို အရင်အတိုင်း ပြန်ပြောင်းဖို့တော့မမေ့နဲ့ပေါ့ဗျာ။
ပျော်ရွှင်ပါစေဗျာ။
(Be knowledgeable, pass it on then)
HP Comware simulator (H3C Cloud Lab) လေး Install လုပ်တဲ့အခါ အောက်ကလို error တက်နေပါတယ်။
ကျတော်စက်မှာ Virtualbox Version 5.0.16 သွင်းထားတာပါ။ Latest Version ပါ။
The virtualbox version is lower than the HCL needed.
ဒီ error ကိုဖြေရှင်းဖို့ registry editor ကိုဖွင့်ပြီး။
HKEY_LOCAL_MACHINE>SOFTWARE>Oracle>Virtualbox ကိုသွားပါ။
Version နဲ့ VersionExt ရဲ့ Data ကို 4.2.18 ကိုပြောင်းလိုက်ပါ။
ပြီးတာနဲ့ HP Comware Simulator (H3C Cloud Lab) ကို ပြန် install လုပ်ကြည့်ပါ။
အဆင်ပြေသွားပါလိမ့်မယ်။
Simulator installation ပြီးတဲ့အခါ Registry value ကို အရင်အတိုင်း ပြန်ပြောင်းဖို့တော့မမေ့နဲ့ပေါ့ဗျာ။
ပျော်ရွှင်ပါစေဗျာ။
(Be knowledgeable, pass it on then)
How to configure configuration change notification and logging on Cisco Router?
အလုပ်အသစ်မှာ နည်းနည်း အလုပ်များနေလို့ ပိုစ့်အသစ်မတင်ဖြစ်တာ တော်တော်ကြာသွားပါတယ်။ အခုတော့ logging အကြောင်းနည်းနည်း ရေးပါမယ်။
Logging Device သီးသန့် မရှိတဲ့ network infrastructure တခုမှာ Network Device တွေရဲ့ configuration changes တွေကို အတိုင်းအတာ တခုထိ သိမ်းထားဖို့လိုပါတယ်။
ဒါမှသာ လိုအပ်တဲ့အခါ ဘယ်သူက ဘယ်အချိန်မှာ configuration တွေကို changes လုပ်တယ်ဆိုတာကို ပြန်ကြည့်နိုင်မှာ ပဲ ဖြစ်ပါတယ်။
Cisco Router မှာ configuration changes notification နဲ့ logging လုပ်ပုံလေး နမူနာပြချင်ပါတယ်။
အောက်က command တွေအတိုင်း မိမိ router မှာ configure လုပ်ပါ။
Router(config)#archive
Router(config-archive)#log config
Router(config-archive-log-cfg)#logging enable
Router ရဲ့ buffer size က limitation ရှိပါတယ်။ ဒီအတွက် buffer size ကို အောက်ပါအတိုင်း သတ်မှတ်ပါမယ်။ Cisco ရဲ့ Default Buffer Size ကတော့ 100 ပါ။
ဒီမှာတော့ ကျတော် 1000 သတ်မှတ်ထားပါတယ်။
Router(config-archive-log-cfg)#logging size 1000
ဒါဆိုရင် configuration changes တွေကို log လုပ်ပါပြီ။ တခုသတိထားရမှာက console, telnet နဲ့ တခြား authentication တွေရဲ့ password တွေကို loggin က hide မလုပ်ပဲ သိမ်းပါတယ်
ဒီအတွက် password တွေကို အောက်က command နဲ့ hide ပါမယ်။
Router(config-archive-log-cfg)#hidekeys
ကဲ... ဒါဆို device log ကို local memory မှာ ဘယ်လို သိမ်းထားလို့ ရလဲ ဆိုတာ သိလောက်ပါပြီ။
တကယ်တော့ အပေါ်မှာ ကျတော်ပြောခဲ့သလို ဒီ နည်းလမ်းက logging server မရှိတဲ့အခါ မှာ သုံးသလို logging server ရှိတဲ့အခါမှာလဲ local device ထဲမှာ ကိုယ်ကြည့်ချင်တဲ့ log ရှိနေနိုင်သေးရင် တခုခု သိချင်တိုင်း server ကို သွားကြည့်နေမယ့် အစား local device ရဲ့ console ကနေပဲ ဝင်ကြည့်တော့မှာပေါ့ဗျာ။
Locally save လုပ်ထားတဲ့ log တွေကို logging server ဆီကို ပို့ချင်ရင်တော့ အောက်ကအတိုင်း configure လုပ်ပါ။
Router(config-archive-log-cfg)#notify syslog
logging အလုပ် တကယ်လုပ်မလုပ် သိချင်ရင်တော့ console ကနေ configuration တခုလောက် change ကြည့်ပြီး အောက်ကအတိုင်း ပြန်စစ်နိုင်ပါတယ်။
Router#show archive log config all
ဒီလောက်ပါပဲ။
ပျော်ရွှင်ပါစေဗျာ။
(Be knowledgeable, pass it on then)
Logging Device သီးသန့် မရှိတဲ့ network infrastructure တခုမှာ Network Device တွေရဲ့ configuration changes တွေကို အတိုင်းအတာ တခုထိ သိမ်းထားဖို့လိုပါတယ်။
ဒါမှသာ လိုအပ်တဲ့အခါ ဘယ်သူက ဘယ်အချိန်မှာ configuration တွေကို changes လုပ်တယ်ဆိုတာကို ပြန်ကြည့်နိုင်မှာ ပဲ ဖြစ်ပါတယ်။
Cisco Router မှာ configuration changes notification နဲ့ logging လုပ်ပုံလေး နမူနာပြချင်ပါတယ်။
အောက်က command တွေအတိုင်း မိမိ router မှာ configure လုပ်ပါ။
Router(config)#archive
Router(config-archive)#log config
Router(config-archive-log-cfg)#logging enable
Router ရဲ့ buffer size က limitation ရှိပါတယ်။ ဒီအတွက် buffer size ကို အောက်ပါအတိုင်း သတ်မှတ်ပါမယ်။ Cisco ရဲ့ Default Buffer Size ကတော့ 100 ပါ။
ဒီမှာတော့ ကျတော် 1000 သတ်မှတ်ထားပါတယ်။
Router(config-archive-log-cfg)#logging size 1000
ဒါဆိုရင် configuration changes တွေကို log လုပ်ပါပြီ။ တခုသတိထားရမှာက console, telnet နဲ့ တခြား authentication တွေရဲ့ password တွေကို loggin က hide မလုပ်ပဲ သိမ်းပါတယ်
ဒီအတွက် password တွေကို အောက်က command နဲ့ hide ပါမယ်။
Router(config-archive-log-cfg)#hidekeys
ကဲ... ဒါဆို device log ကို local memory မှာ ဘယ်လို သိမ်းထားလို့ ရလဲ ဆိုတာ သိလောက်ပါပြီ။
တကယ်တော့ အပေါ်မှာ ကျတော်ပြောခဲ့သလို ဒီ နည်းလမ်းက logging server မရှိတဲ့အခါ မှာ သုံးသလို logging server ရှိတဲ့အခါမှာလဲ local device ထဲမှာ ကိုယ်ကြည့်ချင်တဲ့ log ရှိနေနိုင်သေးရင် တခုခု သိချင်တိုင်း server ကို သွားကြည့်နေမယ့် အစား local device ရဲ့ console ကနေပဲ ဝင်ကြည့်တော့မှာပေါ့ဗျာ။
Locally save လုပ်ထားတဲ့ log တွေကို logging server ဆီကို ပို့ချင်ရင်တော့ အောက်ကအတိုင်း configure လုပ်ပါ။
Router(config-archive-log-cfg)#notify syslog
logging အလုပ် တကယ်လုပ်မလုပ် သိချင်ရင်တော့ console ကနေ configuration တခုလောက် change ကြည့်ပြီး အောက်ကအတိုင်း ပြန်စစ်နိုင်ပါတယ်။
Router#show archive log config all
ဒီလောက်ပါပဲ။
ပျော်ရွှင်ပါစေဗျာ။
(Be knowledgeable, pass it on then)
Multicast for beginners
One Source to One Destination
ဆိုရင် Unicast
One Source to Everyone ဆိုရင်
Broadcast
One Source to Group of
Devices ဆိုရင် Multicast ဆိုတာကိုတော့ အားလုံး သိထားပြီးဖြစ်ပါလိမ့်မယ်။
Multicast ကို ဘာလို့လိုအပ်တာလဲ၊
ဘယ်လို အသုံးချတာလဲ ဆိုတာကို unicast, broadcast တွေနဲ့ယှဉ်တွဲပြီး ဥပမာလေးတွေနဲ့ ရှင်းပြပါရစေ။
အောက်ကပုံကို ကြည့်ပါ။
Video Streaming Server နဲ့ သူ့ဆီက Video ကို
unicast ကိုသုံးပြီး ကြည့်မယ့် Host လေးလုံးရှိပါတယ်။
Host လေးလုံးမှာ နှစ်လုံးက
Local ထဲမှာ ရှိနေပြီး နောက် Host နှစ်လုံးက WAN ဖက်မှာပါ။
WAN link bandwidth က 30Mbps ရှိပြီး
6Mbps Bandwidth လိုအပ်တဲ့ High Definition Video Stream တခုကို Video Streaming
Server က နေ Host တခုချင်းစီက ယူကြည့်တယ်ပေါ့ဗျာ။
unicast ဖြစ်တဲ့အတွက် Host တလုံးစီအတွက်
6Mbps ကိုသုံးတယ်ဗျာ။ ၄ လုံးဆိုတော့ 4x6Mbps=24Mbps Bandwidth ကိုသုံးထားတယ်ပေါ့။
တကယ်လို့များ Host ၄ လုံးထပ်ပိုလာမယ်
ပိုလာတဲ့ Host တွေကလဲ Video ကို ကြည့်မယ်ဆိုရင်တော့ ပြဿနာ စတက်ပြီပေါ့ဗျာ။
ဒါက unicast သုံးထားတဲ့အတွက် ဖြစ်တဲ့
ပြဿနာပေါ့။
အပေါ်က ပုံအတိုင်းပဲ broadcast
ကို သုံးကြည့်မယ်ဗျာ။
ပုံမှာ ပြထားသလိုပဲ Router 1 မှာ
broadcast က drop ဖြစ်သွားပြီး WAN ဖက်က Host တွေလိုချင်တဲ့ Video မရတော့ဘူးပေါ့။
နောက်ပြီး LAN ဖက်က Host တလုံးက
Video မကြည့်ဘူးဆိုရင်လဲ traffic က သူ့ဆီ လာနေမှာပါပဲ။
ဒီအခြေအနေဟာဆိုရင်လဲ လိုတဲ့သူက
braoadcast ကို drop လုပ်တဲ့ router ရဲ့ သဘာဝကြောင့် လိုချင်တာကို မရသလို၊ မလိုတဲ့သူကို
ပေးနေတဲ့အတွက်လဲ bandwidth တွေဆုံးရှုံးနေတာပေါ့။
ဒါက broadcast သုံးလို့ ဖြစ်တဲ့
ပြဿနာပေါ့။
Same Topology ကိုပဲ multicast
ကိုသုံးကြည့်အုံးမယ်ဗျာ။
ဒီတခါတော့ LAN ဖက်က Host တလုံးရယ်၊
WAN ဖက်က Host တလုံးရယ်ပဲ Video Streaming ကိုကြည့်ဖို့လိုတယ်ဗျာ။
Video Streaming Server က
Video Packets တွေကို တကြိမ်ပဲ Send ဖို့လိုပါတယ်။ Network မှာရှိတဲ့ Router,
Switch တွေက multicast traffic ကို လိုတဲ့ Host ဆီကို Forward လုပ်ပေးပါတယ်။
unicast လို လိုတဲ့ Host တိုင်းကို
အကြိမ်ကြိမ် send စရာမလိုသလို၊ broadcast လိုလဲ လိုလို မလိုလို send ရတာမျိုးလဲ မရှိပါဘူး။
ဒါ multicast ပါပဲဗျာ။
ဒါပေမယ့် multicast ဟာ သူ့ချည်းပဲတော့
အလုပ်မလုပ်ဘူးဗျ။ သူကောင်းကောင်းအလုပ်လုပ်နိုင်ဖို့ တခြား component တွေလိုသေးတယ်။
ပထမဆုံးကတော့ multicast
traffic အတွက် IP address တွေပေါ့ဗျာ။ multicast IP address တွေကို သိချင်ရင်တော့
Internet မှာ ရှာကြည့်နိုင်ပါတယ်။
နောက်ပြီး multicast ကို
support လုပ်တဲ့ application တွေလဲ လိုပါသေးတယ်။ ဥပမာအနေနဲ့ဆိုရင် VLC mediaplayer
လိုမျိုးပေါ့။
နောက်တခုက အောက်ကပုံကိုကြည့်ပါ။
Router တလုံး multicast traffic ကို လက်ခံရပြီဆိုတာနဲ့ သူနဲ့ ချိတ်ထားတဲ့ Host တွေထဲက
ဒီ multicast traffic ကို လိုချင်တဲ့သူ ရှိမရှိသိအောင် လုပ်ရပါတယ်။
အဲဒီလို သိအောင် လုပ်ဖို့အတွက်
IGMP (Internet Group Management Protocol) ဆိုတာကို သုံးပါတယ်။
Multicast Traffic ကိုလိုချင်တဲ့
Host ဟာ IGMP ကိုသုံးပြီး Router ကို အသိပေးရပါတယ်။
IGMP က Router ကို ဘယ်
Interface က Multicast Traffic ကိုလိုနေတာဖြစ်ကြောင်းသိစေပြီး Forward လုပ်လို့ရအောင်
ကူညီပေးပါတယ်။
ဟုတ်ပါပြီ။ တကယ်လို့များ အောက်ကပုံလို
Router နောက်မှာ Switch တလုံးရှိနေသေးတယ်ဆိုရင် ဘယ်လိုလုပ်မလဲ။
Switch က သူ့ရဲ့ ဘယ်
Interface ကို Multicast Traffic ကို Forward လုပ်ရမလဲ ဆိုတာ မသိပါဘူး။
မပူပါနဲ့ဗျာ။ ဒီလိုအခြေအနေမှာ သုံးဖို့
IGMP snooping ဆိုတာ ရှိပါတယ်။
Switch က Router နဲ့ Host တွေကြားထဲကနေ
ပြီး IGMP message တွေကို နားထောင်တယ် ပြီးတော့မှ ဘယ် Interface ကနေ Multicast
Traffic ကို Forward လုပ်ရမလဲဆိုတာကို ဆုံးဖြတ်တယ်ပေါ့။
IGMP snooping လိုမျိုး Cisco မူပိုင်
CGMP (Cisco Group Management Protocol) ဆိုတာလဲ ရှိပါသေးတယ်။ ဒါပေမယ့် သိပ်မသုံးကြပါဘူး။
ကဲ...အခုထိ ပြောလာတာက simple
topology အတွက်ဗျ။ တကယ်လို့ အောက်ကပုံလို Router တွေ နည်းနည်းများလာမယ် နည်းနည်းရှုပ်လာမယ်ဆိုရင်
ဘယ်လိုလုပ်မလဲ။
Host 1 က လိုချင်တဲ့ Video ကို
Router 1 က multicast traffic နဲ့ ပို့မယ်ဆိုပါတော့။
unicast မှာဆိုရင်တော့ Router တွေက
destination address ကို ကြည့်ပြီး routing table အတိုင်း traffic ကို forward လုပ်လိုက်ယုံပဲ။
multicast မှာဆိုရင်တော့ ဒီလောက်မလွယ်ကူပါဘူး။
Destination Address က Multicast Group Address ဖြစ်နေတဲ့အတွက် Traffic ဟာ
Multiple Receiver ကို ပို့ရမှာ ကြောင့်ပဲ ဖြစ်ပါတယ်။
အဲဒီလို Multiple Receiver တွေဆီကို
Packet ကို Forward လုပ်ဖို့ အတွက် DVMRP
(Distance Vector Multicast Rrouting Protocol), MOSPF (Multicast Open Shortest
Path First) နဲ့ PIM (Protocol Independent Multicast) ဆိုတာတွေကို သုံးဖို့လိုပါတယ်။
Popular အဖြစ်ဆုံးကတော့ PIM ပေါ့။
Multicast မှာ advantage တွေကတော့
အများကြီးပေါ့ဗျာ။ unicast traffic နဲ့ အဓိကကျတဲ့ advantage ကိုယှဉ်မယ်ဆိုရင်တော့
multicast က scability ဖြစ်တာပါပဲ။
ဒါပေမယ့် multicast က udp ကိုပဲ
support လုပ်တဲ့ disadvantage တခုတော့ရှိပါတယ်။
Multicast ကို Youtube ,
Netflix လို Video Streaming လုပ်တဲ့ Company တွေက Internet မှာ အသုံးချလား လို့မေးရင်တော့
မသုံးပါဘူးလို့ပဲ ဖြေရမှာပါပဲ။
သူတို့က unicast တွေအများကြီးနဲ့
ပဲ သူတို့ရဲ့ Online Video တွေကို သူတို့ Customer တွေဆီကို deliver လုပ်ပါတယ်။
ဒါပေမယ့် Local ISP တွေမှာတော့
Multicast ကို သုံးတာကို တွေ့ရမှာပါ။ ဥပမာ အနေနဲ့ Singapore မှာဆိုရင် SingTel ရဲ့
IPTV လိုမျိုးပေါ့ဗျာ။
ကဲ ဒီလောက်ဆိုရင် Multicast အခြေခံလေး
နည်းနည်းရသွားပြီလို့ ယူဆပါတယ်။
နည်းနည်း ပိုပြည့်စုံသွားအောင်
CCIE တွေရေးထားတဲ့ Multicast အကြောင်းလေးတွေကို ဒီအောက်က လင့် တွေမှာ သွားဖတ်နိုင်ပါသေးတယ်။
ပျော်ရွှင်ပါစေဗျာ။
(Be knowledgeable, pass it on
then)
Understanding Cisco Switch Virtualization
ကျတော်တို့ Switch Network ကို တည်ဆောက်တဲ့အခါ Core, Distribution, Access Layer တွေနဲ့ တည်ဆောက်ကြသလို Redundant အတွက်လဲ ထည့်စဉ်းစားပြီး Design လုပ်ကြရပါတယ်။
Redundant အတွက်စဉ်းစားတဲ့အခါ loop-free topology ရဖို့အတွက် ပါ ထည့်သွင်းစဉ်းစားပြီး implement လုပ်ကြရပါတယ်။
loop-free topology အတွက် လုပ်တာနဲ့ ပုံမှန် Spanning-tree လို ဟာတွေဟာ redundant link ကို block လုပ်ထားတဲ့အတွက် resource တွေကို အပြည့်အဝ မသုံးရတဲ့ ပြဿနာလေးတွေကြုံလာရပါတယ်။
အောက်က ပုံမှာဆိုရင် မြင်တွေ့နေကြ Switch Topology တခုပေါ့။ အနီရောင်နဲ့ ပြထားတဲ့ link တွေဟာဆိုရင် spanning tree က block လုပ်ထားလို့ သုံးမရတဲ့ အခြေအနေပါ။
ဒီပုံမှာဆိုရင် Distribution Switch ၁ လုံး ပျက်သွားခဲ့ရင် နောက ၁ လုံးက take over လုပ်နိုင်ပေမယ့် Access Switch တွေကတော့ Redundant Link မရှိတဲ့အတွက် Connection Breakdown ဖြစ်သွားမှာပါ။
ဒီအခြေအနေကို ကျော်လွှားနိုင်ဖို့ ဆိုရင် အောက် က ပုံလို Access Switch ၂ လုံးကို Logical Switch ၁ လုံးအနေနဲ့ ပေါင်းပြီး uplink တွေကို EtherChannel သုံးပြီး ပေါင်းထားနိုင်ပါတယ်။
ဒီမှာဆိုရင်လဲ Spanning Tree က Logical Switch ရဲ့ uplink တခုကို block ထားပါသေးတယ်။
ဒီလို အခြေအနေကို ထပ်ကျော်လွှားဖို့အတွက် Distribution Switch ၂ လုံးကိုပါ Logical Switch ၁ လုံးအနေနဲ့ ထပ်ပေါင်းမယ်ဆိုရင် အောက်က ပုံလို ဖြစ်သွားပါမယ်။
ဒါဆိုရင်တော့ Logical Switch ၂ လုံးကြားက Link ၄ ခုစလုံး ကို EtherChannel ၁ ခုအနေနဲ့ setup လုပ်ပြီးတော့ Spanning-tree ကနေ block လုပ်ထားတာကို ကျော်လွှားနိုင်သွားပြီဖြစ်သလို၊ Physical Switches တွေအများကြီးနဲ့ setup လုပ်မရတဲ့ EtherChannel ရဲ့ ကန့်သတ်ချက်ကို လဲ ကျော်လွှားပြီးသားဖြစ်သွားပါပြီ။
နည်းနည်းရှုပ်နေမှာစိုးလို့ ပိုရှင်းသွားအောင် အောက်က ပုံ ၂ ခုနဲ့ ယှဉ်ပြပါမယ်။
ဒီအောက်က ပုံက Physical Switch တွေ ချည်းပဲ ချိတ်ထားတဲ့ပုံပါ။
အခုအောက်ကပုံကတော့တော့ Physical Switch တွေကို Logical Switch အဖြစ် ပြောင်းထားတဲ့ ပုံပါ။
ရှုပ်ယှက်ခတ်နေတဲ့ Link တွေ တော်တော်ရှင်းသွားတာကို မြင်ရပါလိမ့်မယ်။
ဒီလို မျိုး Physical Switch တွေကို Logical Switch အဖြစ် ပြောင်းနိုင်ဖို့ Cisco က Technology ၂ ခုကို ချပြထားပါတယ်။ အဲဒါတွေကတော့...
၁) Cisco Stackwise
၂) VSS (Virtual Switching System) တို့ပဲ ဖြစ်ပါတယ်။
၂ မျိုးစလုံးကို စမ်းကြည့်ဖို့အတွက် လောလောဆယ်တော့ Simulation Application တွေ ကျတော် မတွေ့မိသေးပါဘူး။
စမ်းချင်ရင်တော့ ကိုယ့်အလုပ်မှာ ဒါမျိုးလုပ်ပါစေ လို့ ဆုတောင်းပေါ့ဗျာ။ ဒါမှ မဟုတ်ရင်တော့ Cisco Catalyst 3750 လို stackable switch, Cisco Catalyst 6500/4500 လို VSS ရနိုင်တဲ့ switch မျိုး ဝယ်ပြီး စမ်းပေါ့။
ပျော်ရွှင်ပါစေဗျာ။
(Be knowledgeable, pass it on then)
Redundant အတွက်စဉ်းစားတဲ့အခါ loop-free topology ရဖို့အတွက် ပါ ထည့်သွင်းစဉ်းစားပြီး implement လုပ်ကြရပါတယ်။
loop-free topology အတွက် လုပ်တာနဲ့ ပုံမှန် Spanning-tree လို ဟာတွေဟာ redundant link ကို block လုပ်ထားတဲ့အတွက် resource တွေကို အပြည့်အဝ မသုံးရတဲ့ ပြဿနာလေးတွေကြုံလာရပါတယ်။
အောက်က ပုံမှာဆိုရင် မြင်တွေ့နေကြ Switch Topology တခုပေါ့။ အနီရောင်နဲ့ ပြထားတဲ့ link တွေဟာဆိုရင် spanning tree က block လုပ်ထားလို့ သုံးမရတဲ့ အခြေအနေပါ။
ဒီပုံမှာဆိုရင် Distribution Switch ၁ လုံး ပျက်သွားခဲ့ရင် နောက ၁ လုံးက take over လုပ်နိုင်ပေမယ့် Access Switch တွေကတော့ Redundant Link မရှိတဲ့အတွက် Connection Breakdown ဖြစ်သွားမှာပါ။
ဒီအခြေအနေကို ကျော်လွှားနိုင်ဖို့ ဆိုရင် အောက် က ပုံလို Access Switch ၂ လုံးကို Logical Switch ၁ လုံးအနေနဲ့ ပေါင်းပြီး uplink တွေကို EtherChannel သုံးပြီး ပေါင်းထားနိုင်ပါတယ်။
ဒီမှာဆိုရင်လဲ Spanning Tree က Logical Switch ရဲ့ uplink တခုကို block ထားပါသေးတယ်။
ဒီလို အခြေအနေကို ထပ်ကျော်လွှားဖို့အတွက် Distribution Switch ၂ လုံးကိုပါ Logical Switch ၁ လုံးအနေနဲ့ ထပ်ပေါင်းမယ်ဆိုရင် အောက်က ပုံလို ဖြစ်သွားပါမယ်။
ဒါဆိုရင်တော့ Logical Switch ၂ လုံးကြားက Link ၄ ခုစလုံး ကို EtherChannel ၁ ခုအနေနဲ့ setup လုပ်ပြီးတော့ Spanning-tree ကနေ block လုပ်ထားတာကို ကျော်လွှားနိုင်သွားပြီဖြစ်သလို၊ Physical Switches တွေအများကြီးနဲ့ setup လုပ်မရတဲ့ EtherChannel ရဲ့ ကန့်သတ်ချက်ကို လဲ ကျော်လွှားပြီးသားဖြစ်သွားပါပြီ။
နည်းနည်းရှုပ်နေမှာစိုးလို့ ပိုရှင်းသွားအောင် အောက်က ပုံ ၂ ခုနဲ့ ယှဉ်ပြပါမယ်။
ဒီအောက်က ပုံက Physical Switch တွေ ချည်းပဲ ချိတ်ထားတဲ့ပုံပါ။
အခုအောက်ကပုံကတော့တော့ Physical Switch တွေကို Logical Switch အဖြစ် ပြောင်းထားတဲ့ ပုံပါ။
ရှုပ်ယှက်ခတ်နေတဲ့ Link တွေ တော်တော်ရှင်းသွားတာကို မြင်ရပါလိမ့်မယ်။
ဒီလို မျိုး Physical Switch တွေကို Logical Switch အဖြစ် ပြောင်းနိုင်ဖို့ Cisco က Technology ၂ ခုကို ချပြထားပါတယ်။ အဲဒါတွေကတော့...
၁) Cisco Stackwise
၂) VSS (Virtual Switching System) တို့ပဲ ဖြစ်ပါတယ်။
၂ မျိုးစလုံးကို စမ်းကြည့်ဖို့အတွက် လောလောဆယ်တော့ Simulation Application တွေ ကျတော် မတွေ့မိသေးပါဘူး။
စမ်းချင်ရင်တော့ ကိုယ့်အလုပ်မှာ ဒါမျိုးလုပ်ပါစေ လို့ ဆုတောင်းပေါ့ဗျာ။ ဒါမှ မဟုတ်ရင်တော့ Cisco Catalyst 3750 လို stackable switch, Cisco Catalyst 6500/4500 လို VSS ရနိုင်တဲ့ switch မျိုး ဝယ်ပြီး စမ်းပေါ့။
ပျော်ရွှင်ပါစေဗျာ။
(Be knowledgeable, pass it on then)
Subscribe to:
Comments
(
Atom
)