Route Reflector

မင်္ဂလာပါ ဒီနေ့ Knowledge Sharing လုပ်ပေးသွားမှာ က တော့ Route Reflector အကြောင်းလေးဘဲ ဖြစ်ပါတယ်။

Route Reflector ကိုဘာအတွက်သုံးရသလဲ ?

မိမိ ကိုယ်ပိုင် Autonomous System(AS) ထဲမှာရှိသော iBGP Run ထားတဲ့ Routers တွေဟာ peers အချင်းချင်း updates တွေပေးပို့တဲ့အခါမှာ iBGP peer တစ်ခုဆီကနေ learn လုပ်ထားပြီးသား update တွေကို တခြား iBGP peer တစ်ခုဆီကိုပြန်ပြောပြခွင့်မရှိပါဘူး…ဘာကြောင့်လဲဆိုရင် loop ဖြစ်သွားမှာ ဆိုးလို့ပါ။ ဒါဆိုရင် မိမိ AS ထဲမှာရှိတဲ့ iBGP Routers တွေဟာ underlying မှာ dynamic routing protocol(ospf, eigrp, is-is, rip)တစ်ခုခုကိုအခြေခံပြီးတော့ အဲ့ဒီ့ dynamic routing protocol အပေါ်ကနေမှတဆင့် TCP 3 way handshake section ကို fully-mesh ဖြစ်အောင်တည်ဆောက်ပါတယ်။ အဲလိုတည်ဆောက်ပြီးခါမှ iBGP Routers တွေအားလုံးဟာ အဲ့ဒီ့ dynamic routing protocol အပေါ်အမှီပြုပြီးတော့ မိမိ learn လုပ်ထားတဲ့ updates တွေကို အချင်းချင်းဖလှယ်ပါတယ်။ ဒါကို Classic iBGP လို့ခေါ်ပါတယ်။ Peers အချင်းချင်း updates တွေပို့ကြရင်း loop မဖြစ်ဖို့အတွက် Classic iBGPမှာလဲဘဲ dynamic routing protocol တွေအသုံးပြုတဲ့ Split-Horizon Rule ကိုအသုံးပြုပါတယ်။

ဒါဆိုရင် TCP 3 way handshake section တည်ဆောက်ဖို့ရာအတွက် iBGP Routers တွေဟာ အနည်းငယ်ဘဲ ရှိတယ်ဆိုရင်တော့ ကိစ္စမရှိ မပြောပလောက်ပေမဲ့၊ အစုလိုက်အပြုံလိုက်အများကြီး ရှိခဲ့သည် ဖြစ်သော် routers အားလုံးဟာ တစ်လုံးချင်းစီနဲ့ peer section လိုက်ဆောက်ရတာဖြစ်တဲ့ အတွက် scalability မကောင်းတဲ့ ပြဿနာနဲ့ကြုံတွေ့ကြပါလိမ့်မယ်။

အဲ့ဒီ့ traffic loading များနေတဲ့ ကိစ္စကိုဖြေရှင်းဖို့အတွက် RouteReflector(RR) ကို သုံးလိုက်ပါ့မယ်။ RR သုံးရင်ဘာအကျိုးကျေးဇူးတွေရရှိနိုင်မှာလဲ။ မိမိစိတ်ကြိုက် iBGP Router တစ်လုံးကို Router Reflector Server အနေနဲ့ထားလိုက်ပါမယ်။ တခြားသော routers တွေဟာ Route Reflector Client အနေနဲ့ အလုပ်လုပ်ပါလိမ့်မယ်။ RR Clients တွေဟာ၊ RR Client အချင်းချင်း TCP 3 way handshake section ဆောက်စရာမလိုတော့ဘဲ RR Server နဲ့သာတိုက်ရိုက်သာ TCP section တည်ဆောက်ရမှာဖြစ်ပါတယ်။ ဖြစ်သမျှ ရသမျှ update တွေကို RR Server ဆီကို ပို့မှာဖြစ်ပြီး RR Server ကနေ RR Clients တွေကို တစ်ခုချင်းစီ ပြန်ပြောပြမှာဖြစ်ပါတယ်။

RR Server တစ်လုံးထဲ ဆိုရင်လည်း ဆိုရင်လည်း RR Server down သွားခဲ့သည်ရှိသော် Internal AS ထဲမှာ ရှိတဲ့ RR Clients တွေအကုန် အဆက်အသွယ်ပျက်သွားမှာဖြစ်ပါတယ်။ ဒါဆို Redundancy ရအောင် RR Server (၂)လုံးထားမယ်ဆိုရင် စတင် loop ဖြစ်ပါပြီ။ အဲ့လို loop မဖြစ်ဖို့ရာအတွက် RR Servers (၂) လုံးမှာ Same Originator ID တစ်ခုသတ်မှတ်ပေးရပါမယ်။ အဲ့လိုအခြေနေမှာတော့ RR Clients များဟာ ငါတို့တွေ့နေရတဲ့ RR Servers (၂)လုံးဟာ Originator ID တူတူဘဲ လို့မြင်သွားပြီး cluster attribute ထဲမှာ မိမိလက်ခံထားပြီးသား cluster ID ပါလာခဲ့ရင် လက်မခံဘဲ reject လုပ်မှာဖြစ်ပါတယ်။ RR မှာတော့ loop မဖြစ်ဖို့ Originator ID သုံးပါတယ်။ ဘယ်လိုသုံးလဲ ဆိုရင်တော့ update စတင်ပို့လွှတ်တဲ့ iBGP router က သူ့ဆီ အသစ် အသစ်သော updates တွေထပ်ရောက်လာခဲ့ရင် Originator ID ကိုစစ်ဆေးပါတယ်။ အကယ်၍ Originator ID က သူ့ရဲ့ Originator ID ဖြစ်နေခဲ့ရင်တော့ အဲ့ဒီ့ update ကို reject လုပ်ချလိုက်ပါတယ်။ RR မှာ loop မဖြစ်တော့ပါဘူး။ Originator ID ဆိုတာ Router ID ကိုပြောတာဖြစ်ပါတယ်။

ဒီနေ့တော့ စာလည်းတော်တော်ရှည်သွားပြီဆိုတော့ဒီမှာ အဆုံးသတ်ပါ့မယ်။ နောက်ထပ်လည်း core network နဲ့ပက်သက်ပြီး စိတ်ဝင်စားစရာလေးတွေထပ်ရေးပေးပါဦးမယ် ခင်ဗျ။ စာဖတ်သူအားလုံး စိတ်၏ ချမ်းသာခြင်း၊ ကိုယ်၏ကျန်းမာခြင်းနဲ့ ပြည့်စုံနိုင်ကြပါစေ ခင်ဗျာ…။

Written By Aung Nay Toe