Nexus စသုံးတဲ့အခါ သတိထားမိတာကတော့ မမြင်ဖူးတဲ့ inconsistent States တွေပါလာတာကို တွေ့ရတယ်။ အဲဒီအထဲက BA_Inc လို့ခေါ်တဲ့ Spanning Tree Loop prevention ရဲ့နောက်ဆက်တွဲတခုဖြစ်တဲ့ Bridge Assurance အကြောင်းကို လေ့လာကြည့်ကြတာပေါ့။ Catalyst 6500 ရဲ့ IOS 12.2SX နောက်ပိုင်းမှာလည်း ပါတယ်ဆိုပေမယ့် သတိမထားမိခဲ့ဘူး။ Spanning Tree ဆိုတာကလဲ CCNA ထဲကစလိုက်တာ CCIE အထိကို မပါမဖြစ်ပဲ၊ CCIE ပြီးရင်လဲပါနေအုံးမှာပဲ။ ဒီတော့ သူရဲ့အဓိကကာကွယ်လုပ်ဆောင်ပုံဖြစ်တဲ့ တခုခုဖြစ်ရင် ဘယ်လို့အကြောင်းပြချက်နဲ့ ပိတ်မယ်ဆိုတဲ့ ကိစ္စတွေကိုတော့ သိထားသင့်တယ်လို့ထင်ပါတယ်။
တကယ်တော့ BA ဟာ Loop Guard လို Unidirectional ကြောင့် Loop မဖြစ်အောင်ကာကွယ်တာပါပဲ ဒါပေမယ့် Loop Guard ထက်ပိုပြီးတော့ လုပ်ဆောင်နိုင်တယ်လို့ဆိုပါတယ်။ ( ဥပမာ VTP pruning လိုမျိုးမသုံးတဲ့ Vlan တွေကို Trunk အပေါ်မှာမသွားအောင် ချန်ထားတာမျိုး၊ BPDU ကို Keepalive အနေနဲ့အသုံးပြုထားတဲ့အတွက် Port အားလုံးမှာ BPDU Tx ကော Rx ပါရှိနေတာမျိုး ) ဒီနေရာမှာ Unidirectional အကြောင်းပြောရင် UDLD ကိုလဲမမေ့သင့်ဘူး။ သူလဲဒီအလုပ်လုပ်တာပဲ ဒါပေမယ့် အလုပ်လုပ်ပုံချင်းတော့မတူဘူး။ UDLD က သူရဲ့သီးသန့် Protocol ကိုအသုံးပြုတယ် BA နဲ့ LG (Loop Guard) ကတော့ BPDU ကိုအသုံးပြုတယ်။ UDLD က Physical ကိုအဓိကထားတယ်၊ ဒါကြောင့်များသောအားဖြင့် Tx/Rx ကွဲနေတဲ့ ဖိုင်ဘာလင့်တွေမှာသုံးတယ်၊ BA/LG ကတော့ Physical ရဲ့အပေါ် STP က တခြားပြဿနာတွေကိုပါ သိနိင်တာပေါ့။ ဥပမာ Port Channel တွေမှာဆိုရင် UDLD က Member link တခုခုပြဿနာဖြစ်ရင် အဲဒီ လင့်တခုကိုပဲ Disable လုပ်ပါတယ်၊ BA/LG ကတော့ Port Channel တခုလုံးကို inconsistent State ပြောင်းပစ်လိုက်မှာဖြစ်ပါတယ်။
BA ကို Rapid PVST+ နဲ့ MST မှာသာအသုံးပြုလို့ရပါတယ်။ Nexus မှာ BA ဟာ global အနေနဲ့အသင့်ပါဝင်ပေမယ့် Port/ Interface တွေမှာတော့ Disable အနေနဲ့ရှိနေမှာပါ။ အသုံးပြုမယ့် Port/Interface တွေမှာ Spanning-tree port type network ဆိုပြီး သီးသန့် ပြောင်းပေးရပါတယ်။ နောက်ပြီးတော့ Device/Port တွေရဲ့ နှစ်ဖက်စလုံးမှာ အဲဒါကို သုံးထားမှသာ အလုပ်လုပ်မှာဖြစ်ပါတယ်။ တဖက်ကမသုံးထားဘူးဆိုရင်တော့ သူနဲ့ချိတ်ဆက်ထားတဲ့ Port ဟာ Block ဖြစ်သွားပါလိမ့်မယ်။ သေချာတာကတော့ Network စတင်ချိတ်ဆက်တဲ့အခါမှာ သတိပြုပြီး ကိုယ်လိုချင်တဲ့နေရာ၊ Interface တွေကို Edge port/ Network port စသဖြင့် သတ်မှတ်အသုံးရမှာဖြစ်ပါတယ်။ vPC အကြောင်းဖတ်တုန်းကလဲ BA ကို Peer Llink အပေါ်မှာသာ အသုံးပြုဖို့ရေးထားတာ တွေ့ရပါတယ်။
BA နဲ့ LG တို့အသုံးပြုရင်လိုက်နာရမဲ့အချက်တွေကို Cisco ကအခုလိုဖော်ပြထားပါတယ်။
When using Bridge Assurance, follow these guidelines:
•Bridge Assurance runs only on point-to-point spanning tree network ports. You must configure each side of the link for this feature.
•We recommend that you enable Bridge Assurance throughout your network.
When using loop guard, follow these guidelines:
•You cannot enable loop guard on PortFast-enabled ports.
•You cannot enable loop guard if root guard is enabled. (Root guard forces a port to be always designated as the root port. Loop guard is effective only if the port is a root port or an alternate port. You cannot enable loop guard and root guard on a port at the same time.)
Enabling loop guard on a root switch has no effect but provides protection when a root switch becomes a nonroot switch.
Enabling loop guard on ports that are not connected to a point-to-point link will not work.
N7K1# show spanning-tree summary
Switch is in rapid-pvst mode
Bridge Assurance is enabled
Loopguard Default is disabled
BA အသုံးမပြုခင် Port type
N7K1# show spanning-tree vlan
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Eth2/1 Desg FWD 4 128.257 P2p
Eth2/3 Desg FWD 4 128.259 P2p
BA အဖြစ်ပြောင်းရန်
N7K1(config)# int e2/1-4
N7K1(config-if-range)# spanning-tree port type network
BA သုံးလိုက်တဲ့အတွက် တဖက်က Switch မှာ BA မသုံးထားရင် BA Inconsistent အဖြစ်ပြောင်းသွားမှာဖြစ်ပါတယ်။
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Eth2/1 Desg BKN*4 128.257 Network P2p *BA_Inc
Eth2/3 Desg BKN*4 128.259 Network P2p *BA_Inc
N7K1 %STP-2-BRIDGE_ASSURANCE_BLOCK: Bridge Assurance blocking port Ethernet2/1 VLAN0001
N7K1# show spanning-tree inconsistentports
Name Interface Inconsistenc
-------------------- ---------------------- ------------------
VLAN0001 Eth2/1 Bridge Assurance Inconsistent
VLAN0001 Eth2/3 Bridge Assurance Inconsistent
တဖက်က BA အသုံးပြုလိုက်ပီး ပြဿနာဘာမှမရှိဘူးဆိုရင် Port status က FWD အနေနဲ့ပဲရှိနေပါလိမ့်မယ်။
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Eth2/1 Desg FWD 4 128.257 Network P2p
Eth2/3 Desg FWD 4 128.259 Network P2p
အသေးစိတ်လေ့လာချင်ရင်
http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2SX/configuration/guide/book/stp_enha.html#wp1052528
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5000/sw/configuration/guide/cli/CLIConfigurationGuide/SpanningEnhanced.html
ကိုဖြိုး
Showing posts with label Nexus. Show all posts
Showing posts with label Nexus. Show all posts
Sunday, 16 August 2015
Sunday, 26 July 2015
DC တွေအတွက် Nexus
ထင်ရှားတဲ့လူတွေရဲ့အတ္ထုပ္ဗတ္တိတွေအကြောင်းဖတ်ရတာကောင်းသလို ပစ္စည်းတွေရဲ့ပေါ်ပေါက်လာတဲ့ နောက်ကြောင်းတွေကိုသိရတာလည်း စိတ်ဝင်စားဖို့ကောင်းပါတယ်။ CCIE လေ့လာတုန်းက Cisco Press ကစာအုပ်အထူကြီးတွေကိုဖတ်ရတာ အလွန်လေးတယ်လို့ထင်ပါတယ်။ PDF တွေကို PC နဲ့ဖတ်ပြန်တော့လဲအကြာကြီး မထိုင်နိုင်ဘူး။ သက်တောင့်သက်သာမရှိ၊ ပျင်းတာလဲပါတာပေါ့။ ရုံးကပေးထားတဲ့ Laptop ကိုပေါင်ပေါ်တင်ဖတ်ပြန်တော့လဲ နာရီဝက်လောက်ဆို ပူလာပြန်ရော၊ အဲဒီတုန်းက စိတ်ထဲမှာလိုချင်တာက ပေါ့ပေါ့ပါးပါးနဲ့ အလွယ်တကူ ဖတ်လို့ရမယ့် ပစ္စည်းမျိုးတစ်ခုလောက်ရှိရင်ကောင်းမယ် လို့စဉ်းစားခဲ့မိတယ်။ ညံ့တာက Kindle ရှိမှန်းလဲမသိခဲ့ဘူး။ သိခဲ့ရင်လဲ Touch screen မပါဝင်တဲ့ B&W Kindle ဟာအလုပ်ဖြစ်ခဲ့မယ်မထင်ပါ။ ဒါပေမယ့် နောက်ပိုင်း iPAD ပေါ်လာတော့မှ အရင်ကလိုချင်ခဲ့တာ ဒါမျိုးပါလားဆိုပြီး မချင့်မရဲဖြစ်ရတယ်။ ဆိုချင်တာကတော့ ပစ္စည်းတွေ၊ နည်းပညာတွေ ဟာလိုအပ်ချက်တွေနဲ့အတူ စဉ်းစားတီထွင်ပြီးထွက်ပေါ်လာကြတာပါ။ အဲဒီအပေါ်မှာမှ လိုအပ်ချက်၊ တီထွင်မှု၊ ဈေးကွက်ဝင်ရောက်မှုနဲ့ အချိန်ကိုက် သွားတဲ့အခါမှာ အောင်မြင်တဲ့ထုတ်ကုန်ဖြစ်သွားတယ်လို့ပြောလို့ရပါတယ်။
Nexus အကြောင်းကိုဖတ်ကြည့် နားထောင်ကြည့်တဲ့အခါမှာလဲ Server တွေ၊ Virtualization တွေဘက်ကပြောင်းလဲလာတဲ့နည်းပညာတွေကြောင့် Network ဘက်မှာလိုအပ်ချက်တွေဖြစ်ပေါ်လာတာ ကို Cisco က အဲဒီ လိုအပ်ချက်တွေကိုအသုံးချနိုင်ပြီး ဈေးကွက်ထဲကို အချိန်ကိုက်ဝင်ရောက်လာခဲ့ပုံကို တွေ့ရမှာဖြစ်ပါတယ်။ အရင်က Server တစ်လုံးမှာ OS တစ်ခုကိုသာအသုံးပြု၊ အဲဒီအပေါ်မှာ Application အနည်းငယ်ကိုသာ အသုံးပြုတဲ့အတွက် အများစုဟာ Server ရဲ့စွမ်းဆောင်ရည်ကို အပြည့်အဝ အသုံးပြုနိုင်တာ နည်းပြီးတော့ Application ပိုင်ရှင်တွေဟာ နောက်ထပ်လိုအပ်လာတဲ့ Application တွေအတွက် Server တွေကိုသာထပ်ပီးအသုံးပြုခဲ့တဲ့အတွက် Server အရေအတွက်တွေသာများသထက်များလာတာ တွေ့ရမှာပါ။ (Server Sprawl) လို့ဆိုမှာပေါ့။ Server တစ်လုံးကအသုံးပြုတဲ့ Network Traffic ဟာလည်း Catalyst Switch တွေအဖို့တော့ အေးအေးဆေးဆေးပဲပေါ့။ ဒါပေမယ့် နောက်ပိုင်း Blade တွေ VM တွေပါလာတဲ့အခါမှာတော့ Server တစ်လုံးပေါ်မှာ VM အများအပြားကို အသုံးပြုလာကြတဲ့အတွက် အဲဒီ VM တွေက အသုံးပြုတဲ့ Network Traffic ဟာများလာရော၊ 1GE port လောက်နဲ့မရချင်တော့ဘူး၊ Switch တွေရဲ့ Backplane နဲ့ Trunk တွေမှာလည်း အဲဒီ traffic တွေကိုနိုင်အောင် လုပ်ဆောင်နိုင်ဖို့ပြဿနာရှိလာတယ်။ 10GE တို့ 40GE တို့လိုကိစ္စတွေလိုလာတဲ့အခါ Catalyst တွေလည်း ဒုက္ခရောက်လာတယ်။ Bottle neck က Network မှာဖြစ်လာတယ်။
Cisco ကဒီကိစ္စကိုဖြေရှင်းဖို့အတွက် နည်းပညာအသစ် ထုတ်ကုန်အသစ်လိုအပ်လာပြီဆိုတာသိတယ်၊ အဲဒီဟာကို ပြေလည်အောင်လုပ်နိုင်ရင် ဈေးကွက်အနေနဲ့လည်း အောင်မြင်မယ်ဆိုတာကို ခန့်မှန်းလို့ရတယ်။ ဒီတော့Catalyst အပြင် Data Centre အတွက်အသုံးပြုဖို့သက်သက် ထုတ်ကုန်အသစ်ဖြစ်တဲ့ Nexus Series switch တွေကို ၂၀၀၈ မှာစတင်ပြီး ထုတ်လုပ်လိုက်တယ်။ OS ကိုလည်း IOS အစား features တွေပိုပြီးစုံလင်စွာအသုံးပြုနိုင်တဲ့ Linux based NX-OS ဆိုပြီးသုံးလာခဲ့တယ်။ ဒါများ ဘာစိတ်ဝင်စားစရာကောင်းလို့လဲ တခြား Product တွေလဲဒီလိုပဲထွက်နေကြတာပဲ လို့မေးစရာပါ။ ဆက်ကြည့်ကြရအောင်။ Virtualization နဲ့ Cloud ပေါ်လာတဲ့အခါမှာ Virtual Switch ကိုဘယ်သူကိုင်ကြမလဲဆိုတာကလဲ Systems သမားတွေနဲ့ Network သမားတွေကြားမှာ မေးစရာဖြစ်လာပါတယ်။ Systems ဘက်ကဆရာတွေကလည်း သိပ်မလုပ်ချင်ကြသလို Network ဘက်ကကိုယ့်လူတွေကလည်း Server တွေအထဲဝင်ပြီး သုံးဖို့ဝန်လေးကြပါတယ်။ Cisco က Nexus 1000v Virtual Switch ကို Hypervisor တွေအပေါ်မှာ သုံးလို့ရအောင်ထုတ်လိုက်တဲ့အတွက် အလိုလိုနေရင်း Network သမားတွေတာဝန်လိုဖြစ်သွားပါတယ်။ Cisco ကတော့ Virtual Switch အတွက်ဈေးကွက်ဝင်ယူလိုက်တာပေါ့။ Server တွေထုတ်တဲ့ HP တို့ Dell အတွက်လည်း ထုတ်ပေးလိုက်သေးတယ်။ နောက်တစ်ခါ Storage ဘက်ကိုခြေဆန့်ပြီး Nexus ကို SAN switch တွေနေရာဝင်ယူဖို့FCoE နဲ့အတူ ဝင်လာပြန်ရော။ နောက်ပြီးတော့ Nexus 7K 5K တို့နဲ့တွဲဖက်အသုံးပြုဖို့ FEX လို့ခေါ်တဲ့ 2000 Series ဆိုတာလဲပါသေးတယ်။ FEX ဟာ Remote line card တစ်ခုအနေနဲ့ရှိပြီး Parent Switch တွေကနေလှမ်းပြီးထိန်းချုပ်ရတာဖြစ်ပါတယ်။ ဒီနည်းပညာဟာ Catalyst Switch တွေမှာမမြင်ဘူးခဲ့တဲ့ပုံစံမျိုးဖြစ်ပါတယ်။ ဒါ့အပြင် ခုနောက်ပိုင်းခေတ်စားလာတဲ့ SDN တို့ High Density Ultra low latency စတာတွေအတွက်လဲ Nexus series switch တွေက အဆင်သင့်ဖြစ်နေပါပြီ။ 3000 Series တွေဟာဆိုရင် 10GE switch ports အားလုံးဟာ Layer2 ရော Layer 3 မှာပါ Wire-speed အတိုင်းအလုပ်လုပ်နိုင်တယ်လို့ဆိုပါတယ်။
Nexus အတူပါလာတဲ့ နည်းပညာတွေထဲက VDC VPC OTV စတာတွေဟာလည်း Data Centre တွေမှာလိုအပ်နေတဲ့ နည်းပညာတွေဖြစ်ပါတယ်။ OTV ကြောင့် Data Centre နှစ်ခုအကြား LAN Extension အတွက် ပိုပြီးအဆင်ပြေလာပြီး DR တို့Failover အတွက်လည်း IP address မတူတဲ့ကိစ္စတွေကိုသိပ်စဉ်းစားစရာမလိုတော့ဘူးပေါ့။ Nexus ကစလိုက်တဲ့ ကိစ္စဟာ Data Centre အထဲမှာရှိသမျှပစ္စည်းအတော်များများဟာ Cisco တစ်မျိုးနဲ့တင်တည်ဆောက်လို့ရတဲ့ပုံစံဖြစ်လာတယ်။ Server ဘက်ပဲကျန်တော့တယ်။ VM တွေရဲ့ Resource တောင်းဆိုမှုအတွက် Server ထုတ်တဲ့သူတွေဘက်မှာလည်း Memory ထုတ်လုပ်မှုအပိုင်းမှာနည်းပညာလိုအပ်ချက်ကြောင့်အလားတူ ပြဿနာတွေရှိနေတာကိုသိတဲ့ Cisco ဟာ နောက်ဆုံးမှာ Extended Memory Technolgy ကို Intel နဲ့ပေါင်းစပ်ပြီး Cisco UCS ကိုပါထုတ်လုပ်ပြီး Server ဘက်ကိုပါ ဝင်ရောက်နေရာယူလိုက်ပါတယ်။ ဒီတော့ Nexus မွေးလာခြင်းနောက်မှာ Data Centre Solution ဟာ လုံး၀ပြောင်းလဲသွားပြီး အရင်က Catalyst switch တွေနဲ့တည်ဆောက်ခဲ့တဲ့ Core Distribution Access layers ပုံစံဟာ Legacy အဖြစ်သို့ရောက်ရှိသွားပါတော့တယ်။ High performance computing နဲ့ Converge Network ခေတ်မှာ Nexus ဟာမရှိမဖြစ် မသုံးမဖြစ်အသုံးပြုရမယ့် ပစ္စည်းတစ်ခုအနေနဲ့ နောက်ဆယ်နှစ်လောက် နေရာယူထားတော့မှာဖြစ်ပါတယ်။
ကိုဖြိုး
Nexus အကြောင်းကိုဖတ်ကြည့် နားထောင်ကြည့်တဲ့အခါမှာလဲ Server တွေ၊ Virtualization တွေဘက်ကပြောင်းလဲလာတဲ့နည်းပညာတွေကြောင့် Network ဘက်မှာလိုအပ်ချက်တွေဖြစ်ပေါ်လာတာ ကို Cisco က အဲဒီ လိုအပ်ချက်တွေကိုအသုံးချနိုင်ပြီး ဈေးကွက်ထဲကို အချိန်ကိုက်ဝင်ရောက်လာခဲ့ပုံကို တွေ့ရမှာဖြစ်ပါတယ်။ အရင်က Server တစ်လုံးမှာ OS တစ်ခုကိုသာအသုံးပြု၊ အဲဒီအပေါ်မှာ Application အနည်းငယ်ကိုသာ အသုံးပြုတဲ့အတွက် အများစုဟာ Server ရဲ့စွမ်းဆောင်ရည်ကို အပြည့်အဝ အသုံးပြုနိုင်တာ နည်းပြီးတော့ Application ပိုင်ရှင်တွေဟာ နောက်ထပ်လိုအပ်လာတဲ့ Application တွေအတွက် Server တွေကိုသာထပ်ပီးအသုံးပြုခဲ့တဲ့အတွက် Server အရေအတွက်တွေသာများသထက်များလာတာ တွေ့ရမှာပါ။ (Server Sprawl) လို့ဆိုမှာပေါ့။ Server တစ်လုံးကအသုံးပြုတဲ့ Network Traffic ဟာလည်း Catalyst Switch တွေအဖို့တော့ အေးအေးဆေးဆေးပဲပေါ့။ ဒါပေမယ့် နောက်ပိုင်း Blade တွေ VM တွေပါလာတဲ့အခါမှာတော့ Server တစ်လုံးပေါ်မှာ VM အများအပြားကို အသုံးပြုလာကြတဲ့အတွက် အဲဒီ VM တွေက အသုံးပြုတဲ့ Network Traffic ဟာများလာရော၊ 1GE port လောက်နဲ့မရချင်တော့ဘူး၊ Switch တွေရဲ့ Backplane နဲ့ Trunk တွေမှာလည်း အဲဒီ traffic တွေကိုနိုင်အောင် လုပ်ဆောင်နိုင်ဖို့ပြဿနာရှိလာတယ်။ 10GE တို့ 40GE တို့လိုကိစ္စတွေလိုလာတဲ့အခါ Catalyst တွေလည်း ဒုက္ခရောက်လာတယ်။ Bottle neck က Network မှာဖြစ်လာတယ်။
Cisco ကဒီကိစ္စကိုဖြေရှင်းဖို့အတွက် နည်းပညာအသစ် ထုတ်ကုန်အသစ်လိုအပ်လာပြီဆိုတာသိတယ်၊ အဲဒီဟာကို ပြေလည်အောင်လုပ်နိုင်ရင် ဈေးကွက်အနေနဲ့လည်း အောင်မြင်မယ်ဆိုတာကို ခန့်မှန်းလို့ရတယ်။ ဒီတော့Catalyst အပြင် Data Centre အတွက်အသုံးပြုဖို့သက်သက် ထုတ်ကုန်အသစ်ဖြစ်တဲ့ Nexus Series switch တွေကို ၂၀၀၈ မှာစတင်ပြီး ထုတ်လုပ်လိုက်တယ်။ OS ကိုလည်း IOS အစား features တွေပိုပြီးစုံလင်စွာအသုံးပြုနိုင်တဲ့ Linux based NX-OS ဆိုပြီးသုံးလာခဲ့တယ်။ ဒါများ ဘာစိတ်ဝင်စားစရာကောင်းလို့လဲ တခြား Product တွေလဲဒီလိုပဲထွက်နေကြတာပဲ လို့မေးစရာပါ။ ဆက်ကြည့်ကြရအောင်။ Virtualization နဲ့ Cloud ပေါ်လာတဲ့အခါမှာ Virtual Switch ကိုဘယ်သူကိုင်ကြမလဲဆိုတာကလဲ Systems သမားတွေနဲ့ Network သမားတွေကြားမှာ မေးစရာဖြစ်လာပါတယ်။ Systems ဘက်ကဆရာတွေကလည်း သိပ်မလုပ်ချင်ကြသလို Network ဘက်ကကိုယ့်လူတွေကလည်း Server တွေအထဲဝင်ပြီး သုံးဖို့ဝန်လေးကြပါတယ်။ Cisco က Nexus 1000v Virtual Switch ကို Hypervisor တွေအပေါ်မှာ သုံးလို့ရအောင်ထုတ်လိုက်တဲ့အတွက် အလိုလိုနေရင်း Network သမားတွေတာဝန်လိုဖြစ်သွားပါတယ်။ Cisco ကတော့ Virtual Switch အတွက်ဈေးကွက်ဝင်ယူလိုက်တာပေါ့။ Server တွေထုတ်တဲ့ HP တို့ Dell အတွက်လည်း ထုတ်ပေးလိုက်သေးတယ်။ နောက်တစ်ခါ Storage ဘက်ကိုခြေဆန့်ပြီး Nexus ကို SAN switch တွေနေရာဝင်ယူဖို့FCoE နဲ့အတူ ဝင်လာပြန်ရော။ နောက်ပြီးတော့ Nexus 7K 5K တို့နဲ့တွဲဖက်အသုံးပြုဖို့ FEX လို့ခေါ်တဲ့ 2000 Series ဆိုတာလဲပါသေးတယ်။ FEX ဟာ Remote line card တစ်ခုအနေနဲ့ရှိပြီး Parent Switch တွေကနေလှမ်းပြီးထိန်းချုပ်ရတာဖြစ်ပါတယ်။ ဒီနည်းပညာဟာ Catalyst Switch တွေမှာမမြင်ဘူးခဲ့တဲ့ပုံစံမျိုးဖြစ်ပါတယ်။ ဒါ့အပြင် ခုနောက်ပိုင်းခေတ်စားလာတဲ့ SDN တို့ High Density Ultra low latency စတာတွေအတွက်လဲ Nexus series switch တွေက အဆင်သင့်ဖြစ်နေပါပြီ။ 3000 Series တွေဟာဆိုရင် 10GE switch ports အားလုံးဟာ Layer2 ရော Layer 3 မှာပါ Wire-speed အတိုင်းအလုပ်လုပ်နိုင်တယ်လို့ဆိုပါတယ်။
Nexus အတူပါလာတဲ့ နည်းပညာတွေထဲက VDC VPC OTV စတာတွေဟာလည်း Data Centre တွေမှာလိုအပ်နေတဲ့ နည်းပညာတွေဖြစ်ပါတယ်။ OTV ကြောင့် Data Centre နှစ်ခုအကြား LAN Extension အတွက် ပိုပြီးအဆင်ပြေလာပြီး DR တို့Failover အတွက်လည်း IP address မတူတဲ့ကိစ္စတွေကိုသိပ်စဉ်းစားစရာမလိုတော့ဘူးပေါ့။ Nexus ကစလိုက်တဲ့ ကိစ္စဟာ Data Centre အထဲမှာရှိသမျှပစ္စည်းအတော်များများဟာ Cisco တစ်မျိုးနဲ့တင်တည်ဆောက်လို့ရတဲ့ပုံစံဖြစ်လာတယ်။ Server ဘက်ပဲကျန်တော့တယ်။ VM တွေရဲ့ Resource တောင်းဆိုမှုအတွက် Server ထုတ်တဲ့သူတွေဘက်မှာလည်း Memory ထုတ်လုပ်မှုအပိုင်းမှာနည်းပညာလိုအပ်ချက်ကြောင့်အလားတူ ပြဿနာတွေရှိနေတာကိုသိတဲ့ Cisco ဟာ နောက်ဆုံးမှာ Extended Memory Technolgy ကို Intel နဲ့ပေါင်းစပ်ပြီး Cisco UCS ကိုပါထုတ်လုပ်ပြီး Server ဘက်ကိုပါ ဝင်ရောက်နေရာယူလိုက်ပါတယ်။ ဒီတော့ Nexus မွေးလာခြင်းနောက်မှာ Data Centre Solution ဟာ လုံး၀ပြောင်းလဲသွားပြီး အရင်က Catalyst switch တွေနဲ့တည်ဆောက်ခဲ့တဲ့ Core Distribution Access layers ပုံစံဟာ Legacy အဖြစ်သို့ရောက်ရှိသွားပါတော့တယ်။ High performance computing နဲ့ Converge Network ခေတ်မှာ Nexus ဟာမရှိမဖြစ် မသုံးမဖြစ်အသုံးပြုရမယ့် ပစ္စည်းတစ်ခုအနေနဲ့ နောက်ဆယ်နှစ်လောက် နေရာယူထားတော့မှာဖြစ်ပါတယ်။
ကိုဖြိုး
Saturday, 25 July 2015
MCE မှသည် vPC သို့
Nexus နဲ့အတူပါလာတဲ့ Feature တစ်ခုကတော့ Virtual PortChannel (vPC) ဖြစ်ပီး စိတ်ဝင်စားဖို့ကောင်းတဲ့ Feature တစ်ခုဖြစ်သလို Data Center Design ပိုင်းမှာ အလွန်အရေးပါတဲ့ အရာတစ်ခုလို့ ထင်ပါတယ်။ Configuration ပိုင်းထက် Design ကပိုပီးခက်ပါလိမ့်မယ်။ လေ့လာရာမှာလည်း အရင် Etherchannel/ PortChannel အကြောင်းကိုသိထားရင်ပိုပီးအဆင်ပြေပါလိမ့်မယ်။ ကိုယ်တိုင်လဲ အသေးစိတ် နားလည်ဖို့ လေ့လာနေဆဲ ဖြစ်ပါတယ်၊ အထူးသဖြင့် Design နဲ့ Failure Scenarios တွေပါ။ ဘာကြောင့် Design ပိုင်းဟာ ပိုခက်နိုင်တယ်လို့ ပြောတာကတော့ အရင်လို Ethernet port တွေတင်မကပဲ FEX တွေ၊ မတူညီတဲ့ Module တွေဖြစ်တဲ့ F/M အတွဲတွေ၊ Single sided မဟုတ်ပဲ Double sided topology တွေပါလာရင် ရှုပ်ထွေးနိုင်သလို၊ တခြား ကိစ္စတွေဖြစ်တဲ့ VRF တို့ပါ ထည့်သွင်းစဉ်းစားဖို့ပါလိုအပ်လာလို့ဖြစ်ပါတယ်။ ဒါပေမယ့် အဲဒီအပိုင်းတွေကို သေချာနားလည်သွားရင်တော့ ရှင်းလင်းတဲ့ Logical Design တွေအဖြစ်မြင်နိုင်လိမ့်မယ်လို့ထင်ပါတယ်။ စိတ်ဝင်စားသူတွေဖတ်ရင် အထောက်အကူဖြစ်အောင် အခြေခံအချို့ကို ဝေမျှပေးလိုက်ပါတယ်။
vPC ဟာ Feature အသစ်လို့ဆိုပေမယ့် အရင် Catalyst Switch တွေက Multi-Chasis Etherchannel (MCE) ကနေ ဆက်စပ်လာတာပါ။ ဒါပေမယ့် Catalyst တွေနဲ့မတူ ထူးခြားတာက PortChannel ကို Control နစ်ခုနဲ့ပေါင်းပီး လုပ်ဆောင်တာဖြစ်ပါတယ်။ Catalyst မှာ MCE အတွက် Stackwise နဲ့ VSS သုံးရင် Chasis အရကွဲနေပေမယ့် Control အရ တစ်ခုတည်းအနေနဲ့ ပဲအလုပ်လုပ်ပါတယ်။ Nexus မှာ Switch တစ်ခုစီဟာ သီးသန့်အဖြစ်တည်ရှိပီး vPC ကိုပေါင်းပီးလုပ်ဆောင်ကြပါတယ်။ ဒီတော့ အချင်းချင်းညှိရတဲ့ အပိုင်းတွေကလဲ အတော်များလာတာတွေ့ရပါတယ်။ Compatabity check တင်မကပဲ Configuration အရ Consistency check ပါလိုအပ်လာပါတယ်။ အရင် Catalyst မှာလို Configuration တစ်ခုထဲမှ မဟုတ်တော့တာ။ Catalyst မှာ Stackwise/ VSS လုပ်လိုက်ရင် Chasis အားလုံကို Management IP တစ်ခုနဲ့ပဲ Manage လုပ်သလို Configuration ကလဲ တစ်ခုပဲရှိပါတယ်။ Nexus မှာတော့ Management IP တစ်ခုစီနဲ့ခွဲပီး Manage လုပ်ရပါတယ်။
Nexus နှစ်လုံး vPC အတွက် အတူလုပ်ဆောင်ကြမယ်ဆိုရင် အရင်ဆုံး vPC domain တစ်ခုအောက်မှာ အတူရှိရပါမယ်။ Configuration အတွက် Features တွေအဖြစ် Feature VPC နဲ့ Link aggregation control အတွက် Feature LACP ကို Enable လုပ်ပေးရပါတယ်။ ပီးရင် အချင်းချင်း Keepalive ကိုစောင့်ကြည့်ပေးဖို့ Heartbeat link အတွက် Peer keepalive link/ Fault-Tolerant link လိုပါတယ်။ တိုက်ရိုက်ချိတ်ဆက်ထားဖို့မလိုပဲ Routed Interface ကနေ ဆက်သွယ်လို့ရရင်ဖြစ်ပါတယ်။ တစ်ခြား Production data routing တွေနဲ့မရောအောင် သီးသန့် VRF (Virtual Routing and forwarding) အောက်မှထားရပါတယ်။ ပီးရင် အဓိက ကြတဲ့ Link ဖြစ်တဲ့ vPC Peer Link ဆိုတာ လိုပါတယ်။ BPDU နဲ့ LACP တို့ကို Switch တစ်လုံးထဲအနေနဲ့ ယောင်ပြအဖြစ်မြင်အောင် ထားဖို့အတွက် မရှိမဖြစ် Link ပါ။ ဒါကြောင့် Virtual PortChannel လို့ခေါ်လိုက်တာ ဖြစ်နိုင်တယ်။ အဲဒီ Link ဟာ MAC address တွေ VLAN information တွေ၊ Port information တွေကိုဖလှယ်ဖို့ ကိုလည်း အသုံးပြုပါတယ်။ CFS/ CFSoE လို့ခေါ်တဲ့ (Cisco Fabric Services protocol) က ဒီအလုပ်တွေကိုလုပ်ဆောင်ပေးပါတယ်။ အဲဒီ Link ပြတ်သွားရင် vPC ပျက်သွားပီလို့ဆိုနိုင်ပါတယ်။ ဘာကြောင့်လဲဆိုရင် Peer Link ပြတ်သွားတာနဲ့ တပြိုင်နက် Peer Keepalive ကနေ Switch အချင်းချင်း ညှိလိုက်ပီး Secondary Switch မှာရှိတဲ့ vPC memeber port တွေနဲ့ VLAN တွေရဲ့ SVI Interface တွေကို suspend လုပ်လိုက်လို့ပါ။ ဒီတော့ Multi-Chasis ပေါ်မှာ vPC မပေးနိုင်တော့ဘူးပေါ့၊ Keepalive link ပါထပ်ပြတ်သွားရင်တော့ DC Engineer ဒုက္ခရောက်ပီပေါ့။ အဲဒီ အခြေအနေကိုတော့ Complete dual-active Failure လို့ခေါ်ပါတယ်။
Configuration ပိုင်းကိုဆက်ရမယ်ဆိုရင် တစ်ခြား Optional Configuration တွေမထည့်တော့ရင် Port Channel လုပ်မယ့် Switch တစ်ခုစီက Port တွေကို vPC လုပ်လို့ရပါပီ။ Switch port တွေဟာ အရင်က access port တို့ Trunk Port တို့လိုခေါ် ကြတာများပါတယ်။ ဒါပေမယ့် vPC က သူ့ရဲ့ vPC domain အောက်လဲရောက်သွားရော Port တွေကိုခွဲခြားလိုက်ပါတယ်။ သူနဲ့ပက်သက်တဲ့ Port တွေကိုတော့ vPC port လို့ခေါ် ပါတယ်။ Switch ရဲ့တစ်ဖက်စီမှာ ရှိရင်တော့ vPC Member port ခေါ်ပီး Port Channel ထဲမှာ မပါဝင်တဲ့ ကျန်တဲ့ Port တွေကို တော့ Orphaned port လို့ခေါ်လိုက်ပါတယ်။ ဘာကြောင့် ဒီလိုခေါ်လိုက်လဲ မသိပါဘူး၊ သိပ်ပီးတော့ ဘဝင်ကြစရာတော့ မကောင်းတာသေချာပါတယ်။ ကိုယ့်ဖာသာ Switch port အနေနဲ့ရှိနေတာကို သူနဲ့မပက်သက်တာနဲ့နေရင်းထိုင်ရင်း Orphaned port ဖြစ်သွားတယ်။ ဒါပေမယ့် ခွဲလိုက်တော့လဲ မှတ်ရလွယ်သွားတယ်လို့ပဲ ယူဆလိုက်ပေါ့၊ တကယ်လို့များ Switch တစ်ခု ဒါမှမဟုတ် Server တစ်လုံးဟာ vPC domain အောက်မှာ ရှိတဲ့ Nexus နှစ်လုံးကို vPC မသုံးပဲ ချိတ်ဆက်ခဲ့မယ်ဆိုရင် Link နှစ်ခုထဲက တစ်ခုဟာ STP(Spanning Tree) ကြောင့် တစ်ခုဟာ Blocking အနေနဲ့ပဲရှိနေမှာပါ၊ vPC ဆိုရင်တော့ Link နှစ်ခုလုံဟာ Forwarding အနေနဲ့ Parent Switch နှစ်ခုလုံးကိုသွားနိုင်ပါတယ်။ ဒီတော့ Orpahned port ဆိုရင် အပြည့်မရဘူးလို့ မှတ်ထားလို့ရပါတယ်။
ဒါပေမယ့် vPC member port မရပဲ Orphaned port ပဲရတဲ့ အခွင့်အရေးလဲရှိပါတယ်။ ဘယ်အချိန်မှလဲဆိုတော့ vPC member port ကနေဝင်လာတဲ့ Frame တစ်ခုဟာ တစ်ဖက်က Peer Switch ရဲ့ vPC member port ကနေဘယ်တော့မှ ပြန်မထွက်ရဘူးဆိုတဲ့ စည်းမျဉ်းအရ တစ်ဖက်က Peer Switch ဟာ အဲဒီလို Frame မျိုးကို Orphaned port တွေကိုပဲ Forward လုပ်ပါတယ်။ vPC Memeber port တွေကို Forward မလုပ်ပါဘူး။ ဒါကို Duplicate Frames Prevention rule လို့ဆိုပါတယ်။
အခုလောက်ဆို vPC ရဲ့ အခေါ်အဝေါ်တွေနဲ့ အဓိကအချက်တွေကို သဘောပေါက်လောက်ပီလို့ ထင်ပါတယ်၊ ဒါပေမယ့် ပိုပီးရှင်းလင်းမြင်သာအောင် Diagram တစ်ချို့နဲ့ တွဲပီးကြည့်ရင်ပိုကောင်းပါလိမ့်မယ်။ Blog ထဲမှာ Cisco Documentation တွေကနေ ရှင်းထားတဲ့ Diagram တွေကို ကူးပီးဖော်ပြထားပေးပါတယ်။
vPC မှာပါဝင်တဲ့ အစိတ်အပိုင်းတွေပါ
vPC port မဟုတ်တဲ့ Port တွေဟာ Orphaned Port တွေပါ၊ Active/Standby အခြေအနေကို ပြထားပါတယ်
အသုံးများတဲ့ Single Sided design ပါ
Double sided design ဟာ vPC domain အောက်က Switch အားလုံးအပြန်အလှန် vPC ထားရှိတဲ့အတွက် အနည်းငယ်ရှုပ်ထွေးပါတယ်
Failure အခြေအနေကို ရှင်းလင်းစွာ မြင်နိုင်ပါတယ်
Above diagrams copied from Cisco vPC fundamental Concepts 5.0 and vPC best practices design guide.
Reference: http://www.cisco.com/c/dam/en/us/td/docs/switches/datacenter/sw/design/vpc_design/vpc_best_practices_design_guide.pdf
ကိုဖြိုး
vPC ဟာ Feature အသစ်လို့ဆိုပေမယ့် အရင် Catalyst Switch တွေက Multi-Chasis Etherchannel (MCE) ကနေ ဆက်စပ်လာတာပါ။ ဒါပေမယ့် Catalyst တွေနဲ့မတူ ထူးခြားတာက PortChannel ကို Control နစ်ခုနဲ့ပေါင်းပီး လုပ်ဆောင်တာဖြစ်ပါတယ်။ Catalyst မှာ MCE အတွက် Stackwise နဲ့ VSS သုံးရင် Chasis အရကွဲနေပေမယ့် Control အရ တစ်ခုတည်းအနေနဲ့ ပဲအလုပ်လုပ်ပါတယ်။ Nexus မှာ Switch တစ်ခုစီဟာ သီးသန့်အဖြစ်တည်ရှိပီး vPC ကိုပေါင်းပီးလုပ်ဆောင်ကြပါတယ်။ ဒီတော့ အချင်းချင်းညှိရတဲ့ အပိုင်းတွေကလဲ အတော်များလာတာတွေ့ရပါတယ်။ Compatabity check တင်မကပဲ Configuration အရ Consistency check ပါလိုအပ်လာပါတယ်။ အရင် Catalyst မှာလို Configuration တစ်ခုထဲမှ မဟုတ်တော့တာ။ Catalyst မှာ Stackwise/ VSS လုပ်လိုက်ရင် Chasis အားလုံကို Management IP တစ်ခုနဲ့ပဲ Manage လုပ်သလို Configuration ကလဲ တစ်ခုပဲရှိပါတယ်။ Nexus မှာတော့ Management IP တစ်ခုစီနဲ့ခွဲပီး Manage လုပ်ရပါတယ်။
Nexus နှစ်လုံး vPC အတွက် အတူလုပ်ဆောင်ကြမယ်ဆိုရင် အရင်ဆုံး vPC domain တစ်ခုအောက်မှာ အတူရှိရပါမယ်။ Configuration အတွက် Features တွေအဖြစ် Feature VPC နဲ့ Link aggregation control အတွက် Feature LACP ကို Enable လုပ်ပေးရပါတယ်။ ပီးရင် အချင်းချင်း Keepalive ကိုစောင့်ကြည့်ပေးဖို့ Heartbeat link အတွက် Peer keepalive link/ Fault-Tolerant link လိုပါတယ်။ တိုက်ရိုက်ချိတ်ဆက်ထားဖို့မလိုပဲ Routed Interface ကနေ ဆက်သွယ်လို့ရရင်ဖြစ်ပါတယ်။ တစ်ခြား Production data routing တွေနဲ့မရောအောင် သီးသန့် VRF (Virtual Routing and forwarding) အောက်မှထားရပါတယ်။ ပီးရင် အဓိက ကြတဲ့ Link ဖြစ်တဲ့ vPC Peer Link ဆိုတာ လိုပါတယ်။ BPDU နဲ့ LACP တို့ကို Switch တစ်လုံးထဲအနေနဲ့ ယောင်ပြအဖြစ်မြင်အောင် ထားဖို့အတွက် မရှိမဖြစ် Link ပါ။ ဒါကြောင့် Virtual PortChannel လို့ခေါ်လိုက်တာ ဖြစ်နိုင်တယ်။ အဲဒီ Link ဟာ MAC address တွေ VLAN information တွေ၊ Port information တွေကိုဖလှယ်ဖို့ ကိုလည်း အသုံးပြုပါတယ်။ CFS/ CFSoE လို့ခေါ်တဲ့ (Cisco Fabric Services protocol) က ဒီအလုပ်တွေကိုလုပ်ဆောင်ပေးပါတယ်။ အဲဒီ Link ပြတ်သွားရင် vPC ပျက်သွားပီလို့ဆိုနိုင်ပါတယ်။ ဘာကြောင့်လဲဆိုရင် Peer Link ပြတ်သွားတာနဲ့ တပြိုင်နက် Peer Keepalive ကနေ Switch အချင်းချင်း ညှိလိုက်ပီး Secondary Switch မှာရှိတဲ့ vPC memeber port တွေနဲ့ VLAN တွေရဲ့ SVI Interface တွေကို suspend လုပ်လိုက်လို့ပါ။ ဒီတော့ Multi-Chasis ပေါ်မှာ vPC မပေးနိုင်တော့ဘူးပေါ့၊ Keepalive link ပါထပ်ပြတ်သွားရင်တော့ DC Engineer ဒုက္ခရောက်ပီပေါ့။ အဲဒီ အခြေအနေကိုတော့ Complete dual-active Failure လို့ခေါ်ပါတယ်။
Configuration ပိုင်းကိုဆက်ရမယ်ဆိုရင် တစ်ခြား Optional Configuration တွေမထည့်တော့ရင် Port Channel လုပ်မယ့် Switch တစ်ခုစီက Port တွေကို vPC လုပ်လို့ရပါပီ။ Switch port တွေဟာ အရင်က access port တို့ Trunk Port တို့လိုခေါ် ကြတာများပါတယ်။ ဒါပေမယ့် vPC က သူ့ရဲ့ vPC domain အောက်လဲရောက်သွားရော Port တွေကိုခွဲခြားလိုက်ပါတယ်။ သူနဲ့ပက်သက်တဲ့ Port တွေကိုတော့ vPC port လို့ခေါ် ပါတယ်။ Switch ရဲ့တစ်ဖက်စီမှာ ရှိရင်တော့ vPC Member port ခေါ်ပီး Port Channel ထဲမှာ မပါဝင်တဲ့ ကျန်တဲ့ Port တွေကို တော့ Orphaned port လို့ခေါ်လိုက်ပါတယ်။ ဘာကြောင့် ဒီလိုခေါ်လိုက်လဲ မသိပါဘူး၊ သိပ်ပီးတော့ ဘဝင်ကြစရာတော့ မကောင်းတာသေချာပါတယ်။ ကိုယ့်ဖာသာ Switch port အနေနဲ့ရှိနေတာကို သူနဲ့မပက်သက်တာနဲ့နေရင်းထိုင်ရင်း Orphaned port ဖြစ်သွားတယ်။ ဒါပေမယ့် ခွဲလိုက်တော့လဲ မှတ်ရလွယ်သွားတယ်လို့ပဲ ယူဆလိုက်ပေါ့၊ တကယ်လို့များ Switch တစ်ခု ဒါမှမဟုတ် Server တစ်လုံးဟာ vPC domain အောက်မှာ ရှိတဲ့ Nexus နှစ်လုံးကို vPC မသုံးပဲ ချိတ်ဆက်ခဲ့မယ်ဆိုရင် Link နှစ်ခုထဲက တစ်ခုဟာ STP(Spanning Tree) ကြောင့် တစ်ခုဟာ Blocking အနေနဲ့ပဲရှိနေမှာပါ၊ vPC ဆိုရင်တော့ Link နှစ်ခုလုံဟာ Forwarding အနေနဲ့ Parent Switch နှစ်ခုလုံးကိုသွားနိုင်ပါတယ်။ ဒီတော့ Orpahned port ဆိုရင် အပြည့်မရဘူးလို့ မှတ်ထားလို့ရပါတယ်။
ဒါပေမယ့် vPC member port မရပဲ Orphaned port ပဲရတဲ့ အခွင့်အရေးလဲရှိပါတယ်။ ဘယ်အချိန်မှလဲဆိုတော့ vPC member port ကနေဝင်လာတဲ့ Frame တစ်ခုဟာ တစ်ဖက်က Peer Switch ရဲ့ vPC member port ကနေဘယ်တော့မှ ပြန်မထွက်ရဘူးဆိုတဲ့ စည်းမျဉ်းအရ တစ်ဖက်က Peer Switch ဟာ အဲဒီလို Frame မျိုးကို Orphaned port တွေကိုပဲ Forward လုပ်ပါတယ်။ vPC Memeber port တွေကို Forward မလုပ်ပါဘူး။ ဒါကို Duplicate Frames Prevention rule လို့ဆိုပါတယ်။
အခုလောက်ဆို vPC ရဲ့ အခေါ်အဝေါ်တွေနဲ့ အဓိကအချက်တွေကို သဘောပေါက်လောက်ပီလို့ ထင်ပါတယ်၊ ဒါပေမယ့် ပိုပီးရှင်းလင်းမြင်သာအောင် Diagram တစ်ချို့နဲ့ တွဲပီးကြည့်ရင်ပိုကောင်းပါလိမ့်မယ်။ Blog ထဲမှာ Cisco Documentation တွေကနေ ရှင်းထားတဲ့ Diagram တွေကို ကူးပီးဖော်ပြထားပေးပါတယ်။
vPC မှာပါဝင်တဲ့ အစိတ်အပိုင်းတွေပါ
vPC port မဟုတ်တဲ့ Port တွေဟာ Orphaned Port တွေပါ၊ Active/Standby အခြေအနေကို ပြထားပါတယ်
အသုံးများတဲ့ Single Sided design ပါ
Double sided design ဟာ vPC domain အောက်က Switch အားလုံးအပြန်အလှန် vPC ထားရှိတဲ့အတွက် အနည်းငယ်ရှုပ်ထွေးပါတယ်
Failure အခြေအနေကို ရှင်းလင်းစွာ မြင်နိုင်ပါတယ်
Above diagrams copied from Cisco vPC fundamental Concepts 5.0 and vPC best practices design guide.
Reference: http://www.cisco.com/c/dam/en/us/td/docs/switches/datacenter/sw/design/vpc_design/vpc_best_practices_design_guide.pdf
ကိုဖြိုး
Features အသစ်တွေနဲ့ Nexus
ခေတ်စားနေတဲ့ Cloud Computing နဲ့အတူ အဲဒီ Cloud Infrastructure တွေနောက်ကွယ်က အဓိကကြတဲ့ Virtualization နဲ့ Data Center network တွေရဲ့ features တွေဟာလည်း Network/Systems Engineer တွေအဖို့ မဖြစ်မနေ ဆက်ပီးလေ့လာရမဲ့ နည်းပညာတွေ ဖြစ်ပါတယ်။ တဖက်ကလည်း အဲဒီနည်းပညာ တွေလေ့လာဖို့ရာအတွက် Networking ရဲ့အခြေခံတွေသိထားဖို့ ကလည်း အရေးကြီးပါတယ်။ အခြေခံမသိရင် မပိုင်နိုင်ရင် ရှေ့ကဆက်စပ်နေတဲ့ အရာတွေလေ့လာရာမှာ အခက်အခဲကြုံလာပါလိမ့်မယ်။ ဒီတော့ Data Center Switch ဖြစ်တဲ့ Nexus ရဲ့ features တွေအကြောင်း ကို အခြေခံတွေနဲ့တွဲဖက်ပီးလေ့လာကြည့်ဖို့အတွက် ဝေမျှချင်ပါတယ်။
Nexus switch တွေဟာ Cisco NX-OS ကိုသုံးထားတာဖြစ်ပီး Catalyst switch တွေမှာသုံးတဲ့ IOS နဲ့နည်းနည်းကွာပါတယ်။ Data Center အတွက်သီးသန့်သုံးဖို့ဒီအချက်တွေအပေါ်မှာ အခြေခံထားတယ်လို့Cisco ကဆိုပါတယ် (scalability modularity, reslicency and serviceability)။ Configuration ပိုင်းအရ ကြည့်မယ်ဆိုရင် အသုံးပြုဖို့ရာအတွက် Feature တစ်ခုချင်းစီကို အရင် Enable လုပ်ပေးရပါတယ်၊ ဥပမာ Catalyst Switch မှာ Layer 3 Interface SVI ကို တိုက်ရိုက် အသုံးပြုလို့ရပေမယ့် Nexus မှာ Feature အရင် enable လုပ်ပေးရပါတယ်။ Port channel သုံးချင်ရင် LACP enable လုပ်၊ စသဖြင့်ပေါ့၊ ဒီတော့မလိုအပ်သေးတဲ့ Process တွေ Resource ပေါ်မှာရှိမနေတော့ဘူးပေါ့၊
N7K-5-1# show feature (အပြည့်မဟုတ်ပါ၊ ရင်းနှီးပီးသားတွေဖြတ်ပြထားတာ)
Feature Name Instance State
——————– ——– ——–
bgp 1 disabled
dhcp 1 disabled
dot1x 1 disabled
eigrp 1 disabled
fex 1 disabled
glbp 1 disabled
hsrp_engine 1 disabled
interface-vlan 1 disabled
N7K-5-1(config-if-range)# channel-group 1 mode active
LACP process needs to be started before configuring active mode
N7K-5-1(config-if-range)# feature lacp
N7K-5-1(config)# feature interface-vlan
N7K-5-1(config)# feature hsrp
ဒီနေရာမှာ Etherchannel အကြောင်းမဖတ်ဖူးတဲ့ သူဆိုရင်ဘာကြောင့် LACP လို့သုံးတာလဲဆိုတာစဉ်းစားစရာပေါ့၊ ပီးတော့ ဆက်နွယ်နေတဲ့ Feature ဖြစ်တဲ့ VPC (Virtual port-channel) ကိုလေ့လာဖို့ရာအတွက် Etherchannel ကိုသိထားသင့်တယ်ထင်တယ်။ နောက်ပီး VSAN (Virtual Storage Area Network) VXLAN (Virtual Extensible LAN) တွေသိဖို့အတွက် VLAN ဆိုတာအရင်သိမှ အလုပ်ဖြစ်မှာပေါ့၊ နောက်တခု ပြရမယ်ဆိုရင် Nexus ရဲ့ Management port ဟာ စလာကတည်းက vrf သီးသန့်ခွဲထားပါတယ်၊ ဒီတော့ vrf အကြောင်းသိရင် ဘာကြောင့်ဆိုတာ သဘောပေါက်လွယ်လိမ့်မယ်။
N7K-5-1# show vrf
VRF-Name VRF-ID State Reason
default 1 Up —
management 2 Up —
နောက်ပီးတော့ VDC (Virtual Device Contexts) ဟာဆိုရင်လည်း ASA က Multi context mode လိုမျိုး၊ OTV (Overlay Transport Virtualization) အကြောင်းလေ့လာရင်လည်း Spanning-Tree တို့ Multicast တို့ကို နားလည်ထားမယ်ဆိုရင် သူရဲ့ရှုတ်ထွေးတဲ့ အလုပ်လုပ်ပုံတွေကို ဖတ်လို့ပိုကောင်းမယ်ထင်တယ်။ ဒါ့အပြင် Nexus မှာပါလာတဲ့ Fabric path တို့ FCOE တို့ဆိုရင်လည်း Storage/SAN ပိုင်းမှာလုပ်ဖူးတဲ့သူဆိုရင် အလွယ်တကူ နားလည်နိုင်မှာဖြစ်ပါတယ်။ ကိုယ်တိုင်ကတော့ SAN ဖက်ကလာတဲ့သူမဟုတ်တဲ့အတွက် အတော်ကို အချိန်ပေးပီးလေ့လာနေရပါတယ်။ Nexus ရဲ့ တခြား Features တွေအများကြီးကျန်ပါသေးတယ် ဒါပေမယ့် အပြင်လုပ်ငန်းခွင်မှာကို က တစ်ချို့ Features တွေကိုအသုံးပြုတာနဲနေသေးတာကတကြောင်း၊ LAB ရှားပါးတာကတကြောင်းဆိုတော့ Expert Level ရောက်ဖို့ရာအတွက်တော့ အခက်အခဲရှိပါတယ်။ Singapore မှာတောင်အလုပ်ခေါ်ရင် ၁၀ ယောက်မှ ၁ ယောက်လောက်သာ Nexus နဲ့သူရဲ့ features တွေကို သိတာတွေ့ရပါတယ်။ ဒီတော့ အဲဒီ Features တွေထဲကမှ အသုံးများပီး ထင်ရှားတဲ့ ဟာတွေကိုတော့ သိအောင်ဖတ်ထားဖို့ အကြံပေးလိုပါတယ်။
VPC
VDC
FCIP
FCOE
NPV, NPIV
FEX
Fabric-path
VSAN
VXLAN
OTV
VRF
ISSU
ကိုဖြိုး
Nexus switch တွေဟာ Cisco NX-OS ကိုသုံးထားတာဖြစ်ပီး Catalyst switch တွေမှာသုံးတဲ့ IOS နဲ့နည်းနည်းကွာပါတယ်။ Data Center အတွက်သီးသန့်သုံးဖို့ဒီအချက်တွေအပေါ်မှာ အခြေခံထားတယ်လို့Cisco ကဆိုပါတယ် (scalability modularity, reslicency and serviceability)။ Configuration ပိုင်းအရ ကြည့်မယ်ဆိုရင် အသုံးပြုဖို့ရာအတွက် Feature တစ်ခုချင်းစီကို အရင် Enable လုပ်ပေးရပါတယ်၊ ဥပမာ Catalyst Switch မှာ Layer 3 Interface SVI ကို တိုက်ရိုက် အသုံးပြုလို့ရပေမယ့် Nexus မှာ Feature အရင် enable လုပ်ပေးရပါတယ်။ Port channel သုံးချင်ရင် LACP enable လုပ်၊ စသဖြင့်ပေါ့၊ ဒီတော့မလိုအပ်သေးတဲ့ Process တွေ Resource ပေါ်မှာရှိမနေတော့ဘူးပေါ့၊
N7K-5-1# show feature (အပြည့်မဟုတ်ပါ၊ ရင်းနှီးပီးသားတွေဖြတ်ပြထားတာ)
Feature Name Instance State
——————– ——– ——–
bgp 1 disabled
dhcp 1 disabled
dot1x 1 disabled
eigrp 1 disabled
fex 1 disabled
glbp 1 disabled
hsrp_engine 1 disabled
interface-vlan 1 disabled
N7K-5-1(config-if-range)# channel-group 1 mode active
LACP process needs to be started before configuring active mode
N7K-5-1(config-if-range)# feature lacp
N7K-5-1(config)# feature interface-vlan
N7K-5-1(config)# feature hsrp
ဒီနေရာမှာ Etherchannel အကြောင်းမဖတ်ဖူးတဲ့ သူဆိုရင်ဘာကြောင့် LACP လို့သုံးတာလဲဆိုတာစဉ်းစားစရာပေါ့၊ ပီးတော့ ဆက်နွယ်နေတဲ့ Feature ဖြစ်တဲ့ VPC (Virtual port-channel) ကိုလေ့လာဖို့ရာအတွက် Etherchannel ကိုသိထားသင့်တယ်ထင်တယ်။ နောက်ပီး VSAN (Virtual Storage Area Network) VXLAN (Virtual Extensible LAN) တွေသိဖို့အတွက် VLAN ဆိုတာအရင်သိမှ အလုပ်ဖြစ်မှာပေါ့၊ နောက်တခု ပြရမယ်ဆိုရင် Nexus ရဲ့ Management port ဟာ စလာကတည်းက vrf သီးသန့်ခွဲထားပါတယ်၊ ဒီတော့ vrf အကြောင်းသိရင် ဘာကြောင့်ဆိုတာ သဘောပေါက်လွယ်လိမ့်မယ်။
N7K-5-1# show vrf
VRF-Name VRF-ID State Reason
default 1 Up —
management 2 Up —
နောက်ပီးတော့ VDC (Virtual Device Contexts) ဟာဆိုရင်လည်း ASA က Multi context mode လိုမျိုး၊ OTV (Overlay Transport Virtualization) အကြောင်းလေ့လာရင်လည်း Spanning-Tree တို့ Multicast တို့ကို နားလည်ထားမယ်ဆိုရင် သူရဲ့ရှုတ်ထွေးတဲ့ အလုပ်လုပ်ပုံတွေကို ဖတ်လို့ပိုကောင်းမယ်ထင်တယ်။ ဒါ့အပြင် Nexus မှာပါလာတဲ့ Fabric path တို့ FCOE တို့ဆိုရင်လည်း Storage/SAN ပိုင်းမှာလုပ်ဖူးတဲ့သူဆိုရင် အလွယ်တကူ နားလည်နိုင်မှာဖြစ်ပါတယ်။ ကိုယ်တိုင်ကတော့ SAN ဖက်ကလာတဲ့သူမဟုတ်တဲ့အတွက် အတော်ကို အချိန်ပေးပီးလေ့လာနေရပါတယ်။ Nexus ရဲ့ တခြား Features တွေအများကြီးကျန်ပါသေးတယ် ဒါပေမယ့် အပြင်လုပ်ငန်းခွင်မှာကို က တစ်ချို့ Features တွေကိုအသုံးပြုတာနဲနေသေးတာကတကြောင်း၊ LAB ရှားပါးတာကတကြောင်းဆိုတော့ Expert Level ရောက်ဖို့ရာအတွက်တော့ အခက်အခဲရှိပါတယ်။ Singapore မှာတောင်အလုပ်ခေါ်ရင် ၁၀ ယောက်မှ ၁ ယောက်လောက်သာ Nexus နဲ့သူရဲ့ features တွေကို သိတာတွေ့ရပါတယ်။ ဒီတော့ အဲဒီ Features တွေထဲကမှ အသုံးများပီး ထင်ရှားတဲ့ ဟာတွေကိုတော့ သိအောင်ဖတ်ထားဖို့ အကြံပေးလိုပါတယ်။
VPC
VDC
FCIP
FCOE
NPV, NPIV
FEX
Fabric-path
VSAN
VXLAN
OTV
VRF
ISSU
ကိုဖြိုး
Subscribe to:
Posts (Atom)



