VSS အကြောင်းပြောရင် Dual-active ကိစ္စကိုထည့်ပြောဖို့လိုအပ်ပါတယ်။ Dual-active detection configuration မပါတဲ့ VSS Setup ဟာတစ်နေ့တစ်ချိန်မှာ ပြဿနာအကြီးကြီးဖြစ်ပေါ်အောင် ဖန်တီးထားသလိုနဲ့တူပါလိမ့်မယ်။ VSS ပြုလုပ်ပြီးတဲ့အချိန်မှာလည်း အဲဒီ Dual-active detection ဟာ တကယ်အလုပ်ဖြစ်မဖြစ် စမ်းသပ်ကြည့်ဖို့လိုပါတယ်။ ဒါမှသာ ပြဿနာဖြစ်လာရင် ကိုယ်တွက်ချက်မှန်းဆထားတဲ့အတိုင်း ဖြစ်လာမှာပါ။ ဒီတော့ Dual-Active ဆိုတာဘာလဲ ဘာကြောင့်ဖြစ်ရလဲဆိုတဲ့ ကိစ္စကို အရင်သိထားမှဖြစ်မယ်။ VSS ဟာ Catalyat Switch နှစ်လုံးကိုပေါင်းစပ်ထားတဲ့ Virtual System ဖြစ်ပြီး Control ပိုင်းကိုတစ်လုံးက Active အနေနဲ့ ထိန်းချုပ်ပြီး Switch နှစ်ခုစလုံးက Line Card တွေကိုအသုံးပြုတာဖြစ်တဲ့အတွက် ဘယ်သူက Active Control လဲဆိုတာ အဓိကပါ။ Line card တွေအနေနဲ့တော့ အကုန်လုံး Active ပါပဲ။ ဒီနေရာမှာ VSL ကအသက်ပါ။ VSL ပြတ်သွားရင် အရင်စီစဉ်ထားတဲ့ အတိုင်း ဘယ်သူက Active ဘယ်သူက Standby အနေနဲ့ ရှိမနေတော့ပဲ နှစ်လုံးစလုံးက Active Control ဖြစ်လာပြီး ကျန်တဲ့ Stanby ပျောက်သွားတယ်ဆိုပြီး ယူဆမှပါ။ သူတို့အနေနဲ့တော့ ဘာမှမဖြစ်ပေမယ့် အောက်ကချိတ်ဆက်ထားတဲ့ Router တွေ၊ Switch တွေ၊ Server တွေအဖို့ကတော့ ပြဿနာဖြစ်လာပါပြီ။
အဲဒီလိုအချိန်မျိုးမှာ သူတို့ကိုပြန်ပြီး အသိပေးဖို့အတွက် Dual-active detection ကိုအသုံးပြုရပါတယ်။ Network ထဲမှာ ဆရာနှစ်ယောက်ဖြစ်နေပြီ၊ ကျန်တဲ့သူတွေ ဘယ်သူ့ဆရာခေါ်ရမလဲ မသိတော့ဘူး တစ်ခုခုတော့လုပ်အုံးဆိုပြီး ပြောပေးရပါတယ်။ ဒါပေမယ့် သူရဲ့သဘာဝအရ Standby အနေနဲ့ နေလာတဲ့သူက Active အဖြစ်ဆုပ်ကိုင်ထားပါတယ်။ သူ့ဖက်ကကြည့်ရင် ပထမ ဆရာလုပ်တဲ့သူကတော့ ပြန်တက်လာပြီ ဒါပေမယ့် Network တည်ငြိမ်ရေးအတွက် ငါ့မှာတာဝန်ရှိတယ် Standby အနေနဲ့ ပြန်မဆင်းပေးနိုင်ဘူးပေါ့။ အရင် Active အဖြစ်နေလာတဲ့ သူကတော့ ကြားက VSL ပယောကကြောင့် ငါတော့ ခံလိုက်ရပြီ ပြန်လည်နေရာယူဖို့ချက်ချင်းတော့မဖြစ်သေးဘူးဆိုပြီး Recovery mode ကိုပြောင်းလိုက်ပါတယ်။ အခြေအနေကောင်းပြီဆိုမှ ကိုယ်တိုင် Reboot လုပ်လိုက်ပြီး ပြန်လည်ဝင်ရောက်ဖို့ကြိုးစားရပါတယ်။ ဒါပေမယ့် သူ့အနေနဲ့ Standby mode ကိုသာ ပြန်ရရှိနိုင်ပါတယ်။ လက်ရှိ Active ယူထားတဲ့ သူကလည်း Network တည်ငြိမ်ရေး အကြောင်းပြပြီး Priority အနိမ့်အမြင့်တွေရေးထားပေမယ့် ဂရုမစိုက်ပဲ Active အနေနဲ့သာ ဆက်ယူထားပါတယ်။
ဒီအချိန်မှာ အရင်က ဆရာလုပ်ခဲ့တဲ့သူက Active ပြန်ဖြစ်ဖို့ရာအတွက် အနုနည်းပဲသုံးရပါတယ်။ လက်ရှိ Active ဖြစ်နေတဲ့သူကို ပြေပြေလည်လည် လွှဲပြောင်းပေဖို့ အကူအညီတောင်းရပါတယ်။ ဘာလို့လဲဆိုတော့ Standby conole ကနေဘာမှလုပ်လို့မရလို့ပါ။ လက်ရှိ Active console ကိုင်ထားတဲ့သူကသာ Command တွေသုံးလို့ရတာပါ။ ဒါမှမဟုတ် အကြမ်းနည်းနဲ့ VSL ဆွဲဖြုတ်၊ Power ဆွဲပိတ်လုပ်ရင်တော့ ရတာပေါ့၊ ဒါပေမယ့် ခံရမဲ့သူတွေက ကိုယ်တိုင်မဟုတ်ပဲ အောက်က ကိုယ့်ကိုချိတ်ဆက်ထားတဲ့သူတွေဖြစ်တဲ့ အတွက် ရင်ကြားစေ့ရေးနဲ့သာ အသုံးပြုသင့်ပါတယ်။ လက်ရှိ Active ယူထားတဲ့သူကို Redundancy force-swithover ဆိုတဲ့ Command ကိုအသုံးပြုပြီး Active control ကိုပြန်ယူရပါတယ်။ ဆင်းပေးရတဲ့သူကလည်း Standby mode ကိုတန်းသွားလို့မရပါဘူး အရင်ဆုံး ကိုယ်တိုင် Reboot လုပ်ပြီးမှ Standby အဖြစ်ပြန်တက်လာတာပါ။ ဒီတော့ သူကိုချိတ်ထားတဲ့ Server တွေ၊ Switch တွေအနေနဲ့ Network ပြတ်တောက်တာ ခဏတော့ ခံလိုက်ရအုံးမှာပါ။ အခုလို ဟိုပြောင်းဒီပြောင်းဖြစ်တဲ့ ကိစ္စတွေအတွက် အကြမ်းအားဖြင့် ၈မိနစ်၊ ၉ မိနစ်ခန့် ကြာပါတယ်။ အဲဒီဖြစ်နေတဲ့ အချိန်အတွင်းမှာ နှစ်ဖက်စလုံးကို ချိတ်ထားခြင်း မရှိတဲ့ သူတွေအဖို့တော့ Network ပြတ်တောက်တာနဲ့ ကြုံရမှပါ။ ဒါကြောင့် အရင်ရေးဖူးသလိုပဲ Dual-home/Dual-link မရှိတဲ့ server/router တွေအဖို့ VSS ရဲ့ အသုံးဝင်မှုကို ခံစားရမှာ မဟုတ်ပါဘူး။ Network ဖက်မှာတောင် ပါဝါအပြောင်းအလဲလုပ်ရတာ မလွယ်ပါဘူး၊ အပြင်မှာဆိုရင်တော့ စဉ်းစားသာ ကြည့်ပေတော့။
ဒါတွေကို အပြင်ကစောင့်ကြည့်သူဖြစ်တဲ့ Network Admin တစ်ယောက်အနေနဲ့တော့ နှစ်လုံးစလုံးမှာ Console တတ်ထားပြီး ကြည့်ရတာ အတော်ကြည့်ကောင်းပါတယ်။ အရင်မှတ်ထားတဲ့ Logs တွေထဲက အရေးပါတဲ့ အကြောင်းအရာတွေကို အောက်မှာ ပြထားပေးပါတယ်။
Dual-Active PAGP detection Log
%VSLP-SW1-2-VSL_DOWN: All VSL links went down while switch is in ACTIVE role
%DUAL_ACTIVE-SW1-1-DETECTION: PAGP running on Te1/4/5 detected dual-active condition:
%DUAL_ACTIVE-SW1-1-RECOVERY: Dual-active condition detected: Starting recovery-mode, all non-VSL and non-excluded interfaces have been shut down
Dual-Active Fast-Hello Detection Log
%VSLP-SW1-2-VSL_DOWN: All VSL links went down while switch is in ACTIVE role
%DUAL_ACTIVE-SW1-1-DETECTION: Fast-hello running on Gi1/2/1 detected dual-active condition
%DUAL_ACTIVE-SW1-1-RECOVERY: Dual-active condition detected: Starting recovery-mode, all non-VSL and non-excluded interfaces have been shut down
After the dual-active detection, it rebooted and went into recovery-mode
SW1(recovery-mode)#
VSL recovered and switch reloaded and back into Standby mode
%DUAL_ACTIVE-SW1-1-VSL_RECOVERED: VSL has recovered during dual-active situation: Reloading switch 1
%RF-SW1-5-RF_RELOAD: Shelf reload. Reason: dual-active
%SYS-SW1-5-RELOAD: Reload requested by Delayed Reload. Reload Reason: dual-active
SW1-sdby>
Standby console disabled
To switch-over to another switch
SW2#redundancy force-switchover
This will reload the active unit and force switchover to standby[confirm]
Preparing for switchover..
ကိုဖြိုး
Showing posts with label VSS. Show all posts
Showing posts with label VSS. Show all posts
Sunday, 7 February 2016
Sunday, 10 January 2016
VSS Configuration
VSS configuration ဟာသိပ်ပြီးတော့ရှုပ်ထွေးမှုမရှိပါဘူး။ Configuration ထက်စာရင် သူ့ကိုအသုံးပြုဖို့အတွက်ဘာတွေလိုအပ်သလဲ၊ ဘယ်လိုအလုပ်လုပ်သလဲ၊ တစ်ခုခုပြဿနာဖြစ်ရင် ဘယ်တွေကိုကြည့်ရမလဲ စတာတွေကိုပိုပြီးနားလည်ထားဖို့ပဲလိုပါတယ်။
စတင်ပြီး Configure လုပ်တဲ့နေရာမှာ အခြေခံအားဖြင့်ဆိုရင် VSS Domain တစ်ခုတည်ဆောက်၊ ပြီးရင် ဘယ်လင့်တွေကိုတော့ VSL အဖြစ်အသုံးပြုမယ်၊ ဘယ် Switch ကိုအဓိက Control အနေနဲ့သုံးမယ်ဆိုတာကို ထည့်ပေးရပါတယ်။ ပြီးရင် နဂိုအနေအထားကနေ Virtual switch အနေနဲ့ပြောင်းလဲပြီး Reload ကနေပြန်တက်လာရင် VSS အဖြစ် Configure လုပ်ပြီးပါပြီ။ ဒုတိယ Switch တက်လာပြီး VSL တက်သွားပြီ အချင်းချင်းတွေ့သွားပြီဆိုရင် VSS အဖြစ်စတင်ပြီးသုံးလို့ရပါပြီ။ Dual-active detection အတွက်ကိုတော့ နောက်မှထပ်ထည့်လဲရပါတယ်။
Configuration အတွက် Cisco best practice document ကိုကြည့်တာ အကောင်းဆုံးနဲ့ အပြည့်စုံဆုံးဖြစ်ပါလိမ့်မယ်။
http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Campus/VSS30dg/campusVSS_DG/VSS-dg_appa-configs.html
Convert လုပ်ပြီးတဲ့အခါမှာ Interface နံပါတ်တွေပြောင်းသွားတာကို တွေ့ရပါလိမ့်မယ်။ Switch 1 က Module/Interface တွေအရှေ့မှာ Switch number 1 ဆိုတာပါလာပြီး Switch 2 က Interface များမှာတော့ အရှေ့က 2 ဆိုတာပါလာပါလိမ့်မယ်။ ဒါကိုကြည့်လိုက်တာနဲ့ ဘယ် Switch မှာ ချိတ်ဆက်ထားတယ်ဆိုတာကို အလွယ်တကူတွေ့နိုင်ပါတယ်။ Convert လုပ်တဲ့ အချိန်မှာလည်း အခုလို သေချာပြထားပါတယ်။
sw1#switch convert mode virtual
This command will convert all interface names to naming convention "interface-type switch-number/slot/port",
save the running config to startup-config and reload the switch.
Convert လုပ်ပြီးသွားပြီ၊ ဒုတိယ Switch လည်းတက်လာပြီဆိုရင်တော့ VSS အခြေအနေကို စစ်ဆေးကြည့်ရပါမယ်။ ဒါကိုတော့ VSL Link အခြေအနေနဲ့ VSS role ကိုခေါ် ကြည့်လိုက်ရင် သိနိုင်ပါတယ်။ VSL status က တက်နေပြီ၊ Switch 2 ကိုမြင်နေရပြီဆိုရင် အခြေအနေကောင်းပါပြီ။
sw1#show switch virtual link
VSL Status : UP
VSL Uptime : 10 minutes
VSL SCP Ping : Pass
VSL ICC Ping : Pass
VSL Control Link : Te1/1/5
VSL Encryption : Configured Mode - Off, Operational Mode - Off
sw1#show switch virtual
Switch mode : Virtual Switch
Virtual switch domain number : 1
Local switch number : 1
Local switch operational role: Virtual Switch Active
Peer switch number : 2
Peer switch operational role : Virtual Switch Standby
Module တွေအားလုံး တက်သွားပြီး အားလုံး Pass ဖြစ်သွားပြီဆိုရင်တော့ ကျန်တဲ့ Configuration ဖြစ်တဲ့ Port assignment တွေ၊ Routing တွေစပြီး ထည့်လို့ရပါပြီ။ Configure လုပ်တဲ့နေရာမှာ Active switch ကသာ လုပ်ဆောင်ရမှာဖြစ်ပါတယ်။ ဒုတိယ Switch Console ကတော့ အသုံးပြုလို့မရတော့ပဲ Disable အနေနဲ့ ရှိနေပါလိမ့်မယ်။
Standby console disabled
sw1-sdby>?Standby console disabled
ကိုဖြိုး
စတင်ပြီး Configure လုပ်တဲ့နေရာမှာ အခြေခံအားဖြင့်ဆိုရင် VSS Domain တစ်ခုတည်ဆောက်၊ ပြီးရင် ဘယ်လင့်တွေကိုတော့ VSL အဖြစ်အသုံးပြုမယ်၊ ဘယ် Switch ကိုအဓိက Control အနေနဲ့သုံးမယ်ဆိုတာကို ထည့်ပေးရပါတယ်။ ပြီးရင် နဂိုအနေအထားကနေ Virtual switch အနေနဲ့ပြောင်းလဲပြီး Reload ကနေပြန်တက်လာရင် VSS အဖြစ် Configure လုပ်ပြီးပါပြီ။ ဒုတိယ Switch တက်လာပြီး VSL တက်သွားပြီ အချင်းချင်းတွေ့သွားပြီဆိုရင် VSS အဖြစ်စတင်ပြီးသုံးလို့ရပါပြီ။ Dual-active detection အတွက်ကိုတော့ နောက်မှထပ်ထည့်လဲရပါတယ်။
Configuration အတွက် Cisco best practice document ကိုကြည့်တာ အကောင်းဆုံးနဲ့ အပြည့်စုံဆုံးဖြစ်ပါလိမ့်မယ်။
http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Campus/VSS30dg/campusVSS_DG/VSS-dg_appa-configs.html
Convert လုပ်ပြီးတဲ့အခါမှာ Interface နံပါတ်တွေပြောင်းသွားတာကို တွေ့ရပါလိမ့်မယ်။ Switch 1 က Module/Interface တွေအရှေ့မှာ Switch number 1 ဆိုတာပါလာပြီး Switch 2 က Interface များမှာတော့ အရှေ့က 2 ဆိုတာပါလာပါလိမ့်မယ်။ ဒါကိုကြည့်လိုက်တာနဲ့ ဘယ် Switch မှာ ချိတ်ဆက်ထားတယ်ဆိုတာကို အလွယ်တကူတွေ့နိုင်ပါတယ်။ Convert လုပ်တဲ့ အချိန်မှာလည်း အခုလို သေချာပြထားပါတယ်။
sw1#switch convert mode virtual
This command will convert all interface names to naming convention "interface-type switch-number/slot/port",
save the running config to startup-config and reload the switch.
Convert လုပ်ပြီးသွားပြီ၊ ဒုတိယ Switch လည်းတက်လာပြီဆိုရင်တော့ VSS အခြေအနေကို စစ်ဆေးကြည့်ရပါမယ်။ ဒါကိုတော့ VSL Link အခြေအနေနဲ့ VSS role ကိုခေါ် ကြည့်လိုက်ရင် သိနိုင်ပါတယ်။ VSL status က တက်နေပြီ၊ Switch 2 ကိုမြင်နေရပြီဆိုရင် အခြေအနေကောင်းပါပြီ။
sw1#show switch virtual link
VSL Status : UP
VSL Uptime : 10 minutes
VSL SCP Ping : Pass
VSL ICC Ping : Pass
VSL Control Link : Te1/1/5
VSL Encryption : Configured Mode - Off, Operational Mode - Off
sw1#show switch virtual
Switch mode : Virtual Switch
Virtual switch domain number : 1
Local switch number : 1
Local switch operational role: Virtual Switch Active
Peer switch number : 2
Peer switch operational role : Virtual Switch Standby
Module တွေအားလုံး တက်သွားပြီး အားလုံး Pass ဖြစ်သွားပြီဆိုရင်တော့ ကျန်တဲ့ Configuration ဖြစ်တဲ့ Port assignment တွေ၊ Routing တွေစပြီး ထည့်လို့ရပါပြီ။ Configure လုပ်တဲ့နေရာမှာ Active switch ကသာ လုပ်ဆောင်ရမှာဖြစ်ပါတယ်။ ဒုတိယ Switch Console ကတော့ အသုံးပြုလို့မရတော့ပဲ Disable အနေနဲ့ ရှိနေပါလိမ့်မယ်။
Standby console disabled
sw1-sdby>?Standby console disabled
ကိုဖြိုး
Sunday, 3 January 2016
VSS
Cisco ရဲ့Network System Virtualization Technology ဖြစ်တဲ့ VSS (Virtual Switching System) ဆိုတာကို လေ့လာကြည့်ရအောင်။ VSS ဟာ Catalyst 6500/4500 တွေမှာအသုံးပြုလို့ရတဲ့ System Virtualization နည်းပညာဖြစ်ပါတယ်၊ ဒါပေမယ့် Cat65/45 အတိုင်းမှာ သုံးလို့တော့မရပါဘူး။ Switch တွေကို အဓိက ထိန်းချုပ်ထားတဲ့ Supervisor Engine အပေါ်မူတည်ပါတယ်။ VS Supervisor Engine တွေ ဥပမာ (VS-S720-10GE-3C / VS-S720-10GE-3CXL/ VS-SUP2T-10G) နဲ့သာ အသုံးပြုလို့ရမှာ ဖြစ်ပါတယ်။ ဒီ Switch တွေဟာ DC/Campus တွေရဲ့ Distribution Layer တွေမှာ အသုံးများတဲ့အတွက် အဲဒီနေရာတွေမှာ အလုပ်လုပ်နေတဲ့သူတွေအဖို့ သိထားသင့်တဲ့ နည်းပညာတစ်ခုပါ။
VSS ကဘာလုပ်ပေးလဲဆိုရင် အဲဒီ Cat65/45 နှစ်လုံးကို Virtual System တစ်ခုအဖြစ်ပေါင်းစပ်ပေးပါတယ်။ Modular Switch တွေမဟုတ်တဲ့ Cat37/36 တို့မှာ Stack လုပ်သလိုမျိုးပေါ့။ ပေါင်းစပ်ပြီးတဲ့အခါမှာ Management/Control plane ကိုတစ်ခုထဲအနေနဲ့တွေ့ရပြီး IP တစ်ခု၊ Console တစ်ခုထဲကပဲ ကိုင်တွယ်ရပါတယ်။ Standby Switch ရဲ့ Console ဟာ Lock ဖြစ်နေပြီး ဝင်လို့မရတာကိုတွေ့ရပါလိမ့်မယ်။ ဒါပေမယ့် Switch နှစ်ခုလုံမှာရှိတဲ့ Line card/ Modules တွေကတော့ တပြိုင်နက် အလုပ်လုပ်နေပြီး Switch ဒါမှမဟုတ် Module တစ်ခုခုဖြစ်သွားရင် ပြတ်တောက်သွားမှုနည်းအောင် SSO (Stateful Switchover) နည်းနဲ့ အချင်းချင်း Synced လုပ်ထားပါတယ်။ ဒီနေရာမှာ သတိထားသင့်တာက VSS ကိုလာရောက်ချိတ်ဆက်ထားတဲ့ Access Switch တွေ၊ Server တွေဟာ VSS ရဲ့ Member Switch နှစ်ခုစလုံးကိုချိတ်ဆက်ထားမှသာ SSO ရဲ့ ရလာဒ်ကိုခံစားရမှာပါ။ မဟုတ်ရင်တော့ Module ပျက်ရင် အဲဒီမှာချိတ်ထားတဲ့ Server/Switch ဟာလဲ ပြတ်တောက်သွားမှာဖြစ်ပါတယ်။
VSS ရဲ့ အဓိကအသက်ကတော့ သူတို့အချင်းချင်းကို ချိတ်ဆက်ထားပေးတဲ့ VSL ခေါ် Virtual Switch Link ဖြစ်ပါတယ်။ VSL ကိုအနဲဆုံးနှစ်လင့်လောက်အသုံးပြုသင့်ပါတယ်။ VSS Network မှာ VSL ပြတ်တောက်သွားရင် ပြန်တက်အောင်လုပ်ဖို့ သိပ်မလွယ်ပါဘူး။ ဘာလို့လဲဆိုရင် VSL မရှိတဲ့နောက်မှာ Member Switch တွေဟာ Dual-Active ဖြစ်သွားပြီးတော့ မမျှော်မှန်းထားတဲ့ ပြဿနာတွေ ဖြစ်လာတတ်ပါတယ်။ ဒါကြောင့် VSS မှာ Dual-active Detection ဖြစ်တဲ့ PAgP Detection တို့ Fast Hello Link တို့နဲ့ ထပ်ပြီးကူရပါတယ်။ ဒီတော့ အောက်ကသုံးထားတဲ့ Port Channel တွေရဲ့ Channel protocol တွေကိုရွေးချယ်မှုဟာလဲ အရေးပါပါတယ်။ ON mode သုံးထားရင်တော့ Fast Hello ကိုပဲသုံးရပါလိမ့်မယ်။ Dual-active detection ဖြစ်သွားရင် Active Switch က သူ့ရဲ့ Module တွေအားလုံးကို shutdown လုပ်လိုက်ပြီး Recovery mode ကိုရောက်သွားပါတယ်။ ဒီအချိန်မှာ သူ့ကိုချိတ်ထားတဲ့ Device တွေအကုန်လုံးဟာ ပြတ်တောက်သွားမှာဖြစ်ပါတယ်။ Standby Switch မှာချိတ်ထားတဲ့ Device တွေကတော့ ဆက်ပြီး အလုပ်လုပ်နေမှာဖြစ်ပါတယ်။ ဒါကြောင့် အထက်ကပြောခဲ့သလိုပဲ Member Switch နှစ်ခုလုံးမှာ ချိတ်ထားတဲ့ Device သာ VSS ရဲ့ အကျိုးကို ခံစားရမှာပါ။
Recovery mode ကနေ နဂိုအခြေအနေကိုပြန်ရောက်ဖို့အတွက် Force-Switchover ပြန်လုပ်ရမှာဖြစ်ပါတယ်။ VSS မှာ HSRP/VRRP တို့လို Preempt မပါပါဘူး၊ အရင်က ပါခဲ့ပေမယ့် Cisco က မသုံးဖို့ပြောပါတယ်၊ နောက်ပိုင်းမှာ မပါတော့ပါဘူး။ ဘာလို့လဲလို့လေ့လာကြည့်တဲ့အခါမှာ VSS Switchover လုပ်တဲ့အချိန်မှာ Active ကနေ Standby mode ကိုသွားမဲ့ Member switch ဟာ Reload ဖြစ်သွားပြီး နောက်ထပ်ပြတ်တောက်မှု တစ်ကြိမ်ထပ်ကြုံရပါတယ်။ HSRP တို့လိုအလျှင်အမြန်ပြောင်းသွားတာမဟုတ်ပါဘူး။ ဒါကြောင့် Cisco က မလုပ်စေချင်တာပါ။ VSS ကို Force-Switchover လုပ်ရင် သီးသန့် အချိန်ယူပြီးမှ (Maintenance Window) လုပ်သင့်ပါတယ်။ ဒါကြောင့် VSL ဟာအဲဒီ Network တည်ငြိမ်ဖို့အတွက် အရေးအကြီးဆုံးပါ။ ဒီနေရာမှာ မေးစရာရှိတာက ဒါလောက်တောင် ပြဿနာတွေရှိနေရင် ဘာကြောင့် VSS ကိုသုံးနေကြသေးလဲ ဆိုတဲ့ မေးခွန်းပါ။
အရင်ဦးဆုံးမြင်သာတာကတော့ MEC လို့ခေါ်တဲ့ Multichasis EtherChannel ပါ၊ အခုနောက်ပိုင်း Server တွေဟာ Switch တွေလိုပဲ PortChannel တွေလိုအပ်လာပါတယ်၊ VSS မရှိရင် Redundancy အနေနဲ့ MEC သုံးလို့မရပဲ Switch တစ်ခုထဲကိုပဲချိတ်ဆက်ပြီးသုံးရမှာ ဖြစ်ပါတယ်။ Nexus မသုံးနိင်သေးတဲ့ Network တွေမှာ VSS သာ အသုံးဝင်နေဆဲပါ။ ပြီးတော့ Virtual Switch တစ်ခုဖြစ်သွားတဲ့အတွက် အောက်ကလာရောက်ချိတ်ဆက်မဲ့ Switch တွေဟာ STP ရဲ့ တစ်ဖက်ပိတ်တဲ့ ကိစ္စကို ကျော်လွှားနိုင်ပြီး Bandwidth အနေနဲ့ ပိုမိုသုံးလို့ရလာမှာဖြစ်ပါတယ်။ နောက်တခါ Distribution Level မှာသုံးနေကျ HSRP/VRRP တို့လဲ မလိုတော့ပါဘူး။ Backplane bandwidth အနေနဲ့လဲ ပိုမိုများပြားလာပြီးတော့ SSO ကြောင့် Topology changes convergence တွေကိုသိပ်ပြီး မခံစားရတော့ပဲ ပြတ်တောက်မှုတွေကိုနည်းပါးစေပါတယ်။ ဒါ့အပြင် IOS upgrade လုပ်တဲ့အခါမျိုးမှာလဲ ISSU တနည်းအားဖြင့် eFSU Enhanced Fast Software Upgrade တို့ကိုသုံးပြီး ပြတ်တောက်ချိန်အနည်းဆုံးနဲ့ လုပ်ငန်းကို မထိခိုက်အောင် တွဲပြီးလုပ်ဆောင်လို့ရပါတယ်။
Configuration ပိုင်းအနေနဲ့ ကတော့သီးသန့်ခွဲရေးမှသာ အဆင်ပြေပါလိမ့်မယ်။ မြင်သာအောင် Cisco site ကနေယှဉ်ပြထားတဲ့ VSS နဲ့ VSS မပါတဲ့ ပုံကိုကြည့်ပါ။
ကိုဖြိုး
VSS ကဘာလုပ်ပေးလဲဆိုရင် အဲဒီ Cat65/45 နှစ်လုံးကို Virtual System တစ်ခုအဖြစ်ပေါင်းစပ်ပေးပါတယ်။ Modular Switch တွေမဟုတ်တဲ့ Cat37/36 တို့မှာ Stack လုပ်သလိုမျိုးပေါ့။ ပေါင်းစပ်ပြီးတဲ့အခါမှာ Management/Control plane ကိုတစ်ခုထဲအနေနဲ့တွေ့ရပြီး IP တစ်ခု၊ Console တစ်ခုထဲကပဲ ကိုင်တွယ်ရပါတယ်။ Standby Switch ရဲ့ Console ဟာ Lock ဖြစ်နေပြီး ဝင်လို့မရတာကိုတွေ့ရပါလိမ့်မယ်။ ဒါပေမယ့် Switch နှစ်ခုလုံမှာရှိတဲ့ Line card/ Modules တွေကတော့ တပြိုင်နက် အလုပ်လုပ်နေပြီး Switch ဒါမှမဟုတ် Module တစ်ခုခုဖြစ်သွားရင် ပြတ်တောက်သွားမှုနည်းအောင် SSO (Stateful Switchover) နည်းနဲ့ အချင်းချင်း Synced လုပ်ထားပါတယ်။ ဒီနေရာမှာ သတိထားသင့်တာက VSS ကိုလာရောက်ချိတ်ဆက်ထားတဲ့ Access Switch တွေ၊ Server တွေဟာ VSS ရဲ့ Member Switch နှစ်ခုစလုံးကိုချိတ်ဆက်ထားမှသာ SSO ရဲ့ ရလာဒ်ကိုခံစားရမှာပါ။ မဟုတ်ရင်တော့ Module ပျက်ရင် အဲဒီမှာချိတ်ထားတဲ့ Server/Switch ဟာလဲ ပြတ်တောက်သွားမှာဖြစ်ပါတယ်။
VSS ရဲ့ အဓိကအသက်ကတော့ သူတို့အချင်းချင်းကို ချိတ်ဆက်ထားပေးတဲ့ VSL ခေါ် Virtual Switch Link ဖြစ်ပါတယ်။ VSL ကိုအနဲဆုံးနှစ်လင့်လောက်အသုံးပြုသင့်ပါတယ်။ VSS Network မှာ VSL ပြတ်တောက်သွားရင် ပြန်တက်အောင်လုပ်ဖို့ သိပ်မလွယ်ပါဘူး။ ဘာလို့လဲဆိုရင် VSL မရှိတဲ့နောက်မှာ Member Switch တွေဟာ Dual-Active ဖြစ်သွားပြီးတော့ မမျှော်မှန်းထားတဲ့ ပြဿနာတွေ ဖြစ်လာတတ်ပါတယ်။ ဒါကြောင့် VSS မှာ Dual-active Detection ဖြစ်တဲ့ PAgP Detection တို့ Fast Hello Link တို့နဲ့ ထပ်ပြီးကူရပါတယ်။ ဒီတော့ အောက်ကသုံးထားတဲ့ Port Channel တွေရဲ့ Channel protocol တွေကိုရွေးချယ်မှုဟာလဲ အရေးပါပါတယ်။ ON mode သုံးထားရင်တော့ Fast Hello ကိုပဲသုံးရပါလိမ့်မယ်။ Dual-active detection ဖြစ်သွားရင် Active Switch က သူ့ရဲ့ Module တွေအားလုံးကို shutdown လုပ်လိုက်ပြီး Recovery mode ကိုရောက်သွားပါတယ်။ ဒီအချိန်မှာ သူ့ကိုချိတ်ထားတဲ့ Device တွေအကုန်လုံးဟာ ပြတ်တောက်သွားမှာဖြစ်ပါတယ်။ Standby Switch မှာချိတ်ထားတဲ့ Device တွေကတော့ ဆက်ပြီး အလုပ်လုပ်နေမှာဖြစ်ပါတယ်။ ဒါကြောင့် အထက်ကပြောခဲ့သလိုပဲ Member Switch နှစ်ခုလုံးမှာ ချိတ်ထားတဲ့ Device သာ VSS ရဲ့ အကျိုးကို ခံစားရမှာပါ။
Recovery mode ကနေ နဂိုအခြေအနေကိုပြန်ရောက်ဖို့အတွက် Force-Switchover ပြန်လုပ်ရမှာဖြစ်ပါတယ်။ VSS မှာ HSRP/VRRP တို့လို Preempt မပါပါဘူး၊ အရင်က ပါခဲ့ပေမယ့် Cisco က မသုံးဖို့ပြောပါတယ်၊ နောက်ပိုင်းမှာ မပါတော့ပါဘူး။ ဘာလို့လဲလို့လေ့လာကြည့်တဲ့အခါမှာ VSS Switchover လုပ်တဲ့အချိန်မှာ Active ကနေ Standby mode ကိုသွားမဲ့ Member switch ဟာ Reload ဖြစ်သွားပြီး နောက်ထပ်ပြတ်တောက်မှု တစ်ကြိမ်ထပ်ကြုံရပါတယ်။ HSRP တို့လိုအလျှင်အမြန်ပြောင်းသွားတာမဟုတ်ပါဘူး။ ဒါကြောင့် Cisco က မလုပ်စေချင်တာပါ။ VSS ကို Force-Switchover လုပ်ရင် သီးသန့် အချိန်ယူပြီးမှ (Maintenance Window) လုပ်သင့်ပါတယ်။ ဒါကြောင့် VSL ဟာအဲဒီ Network တည်ငြိမ်ဖို့အတွက် အရေးအကြီးဆုံးပါ။ ဒီနေရာမှာ မေးစရာရှိတာက ဒါလောက်တောင် ပြဿနာတွေရှိနေရင် ဘာကြောင့် VSS ကိုသုံးနေကြသေးလဲ ဆိုတဲ့ မေးခွန်းပါ။
အရင်ဦးဆုံးမြင်သာတာကတော့ MEC လို့ခေါ်တဲ့ Multichasis EtherChannel ပါ၊ အခုနောက်ပိုင်း Server တွေဟာ Switch တွေလိုပဲ PortChannel တွေလိုအပ်လာပါတယ်၊ VSS မရှိရင် Redundancy အနေနဲ့ MEC သုံးလို့မရပဲ Switch တစ်ခုထဲကိုပဲချိတ်ဆက်ပြီးသုံးရမှာ ဖြစ်ပါတယ်။ Nexus မသုံးနိင်သေးတဲ့ Network တွေမှာ VSS သာ အသုံးဝင်နေဆဲပါ။ ပြီးတော့ Virtual Switch တစ်ခုဖြစ်သွားတဲ့အတွက် အောက်ကလာရောက်ချိတ်ဆက်မဲ့ Switch တွေဟာ STP ရဲ့ တစ်ဖက်ပိတ်တဲ့ ကိစ္စကို ကျော်လွှားနိုင်ပြီး Bandwidth အနေနဲ့ ပိုမိုသုံးလို့ရလာမှာဖြစ်ပါတယ်။ နောက်တခါ Distribution Level မှာသုံးနေကျ HSRP/VRRP တို့လဲ မလိုတော့ပါဘူး။ Backplane bandwidth အနေနဲ့လဲ ပိုမိုများပြားလာပြီးတော့ SSO ကြောင့် Topology changes convergence တွေကိုသိပ်ပြီး မခံစားရတော့ပဲ ပြတ်တောက်မှုတွေကိုနည်းပါးစေပါတယ်။ ဒါ့အပြင် IOS upgrade လုပ်တဲ့အခါမျိုးမှာလဲ ISSU တနည်းအားဖြင့် eFSU Enhanced Fast Software Upgrade တို့ကိုသုံးပြီး ပြတ်တောက်ချိန်အနည်းဆုံးနဲ့ လုပ်ငန်းကို မထိခိုက်အောင် တွဲပြီးလုပ်ဆောင်လို့ရပါတယ်။
Configuration ပိုင်းအနေနဲ့ ကတော့သီးသန့်ခွဲရေးမှသာ အဆင်ပြေပါလိမ့်မယ်။ မြင်သာအောင် Cisco site ကနေယှဉ်ပြထားတဲ့ VSS နဲ့ VSS မပါတဲ့ ပုံကိုကြည့်ပါ။
ကိုဖြိုး
Subscribe to:
Posts (Atom)
