crazystar

2011-10-30T13:05:00.002+06:30

Internal and External BGP

BGP မွာ internal BGP (iBGP) နဲ့ external BGP (eBGP) ဆိုျပီး neighbor ၂ မ်ိဳးရွိတယ္။ ASN တူရင္ iBGP ျဖစ္ျပီး ASN မတူရင္ eBGP ျဖစ္တယ္။

BGP router တစ္လံုးသည္ iBGP နဲ့ eBGP peer ေတြကို ျပဳမူဆက္ဆံပံုခ်င္း မတူပါဘူး။ router ၂ လံုး neighbor ျဖစ္ဖို့လိုအပ္တဲ့ တူညီခ်က္ေတြ ၊ best route ကို ေရြးခ်ယ္ရာမွာ BGP path algorithm က အသံုးျပဳတဲ့ rule ေတြ ၊ BGP AS_Path PA ကို update လုပ္တဲ့ စည္းမ်ဥ္းစည္းကမ္း စတဲ့အခ်က္ေတြမွာ ကြဲျပားျခားနားတယ္။ အျခား ျခားနားခ်က္ေတြမေျပာခင္ အခု AS_Path နဲ့ ပက္သက္တဲ့ ျခားနားခ်က္ေတြကို ေလ့လာၾကစို့။

BGP peer သို့ advertise လုပ္တဲ့အခါ BGP router သည္ AS_Path PA ကို update လုပ္တယ္ ၊ ဒါေပမယ့္ iBGP သို့ advertise လုပ္တဲ့အခါမွာေတာ့ AS_Path PA ကို update မလုပ္ပါဘူး။ ဥပမာ ပံု 12-6 မွာ IBGP နဲ့ eBGP ေတြကို ခြဲျခားျပေပးထားတယ္။

ပံုမွာ ASN 12 မွ ASN 2 နဲ့ ASN 3 သို့ ေပးပို့တဲ့ route advertisement ကို ျပသထားတယ္။ အဆင့္ ၁ မွာ Router I2 သည္ eBGP peer သို့ advertise လုပ္တာမို့ သူ့ရဲ့ ASN ကို AS_Path သို့ ထပ္ေပါင္းထည့္တယ္။ အဆင့္ ၂ မွာ Router I2-1 သည္ iBGP peer (I2-2) သို့ advertise လုပ္တာမို့ သူ့ရဲ့ ASN (2) ကို AS_Path သို့ ထပ္ေပါင္းမထည့္ဘူး။ အဆင့္ ၃ မွာ Router I2-2 သည္ သူ့ရဲ့ ASN (2) ကို AS_Path သို့ ထပ္ေပါင္းထည့္ျပီးမွသာ eBGP peer I3-2 သို့ advertise လုပ္တယ္။

2011-10-30T12:51:00.004+06:30

အထက္ကပံုရဲ့ ISP တစ္ခုစီမွာ router ၂ လံုးစီ ရွိေနျပီး company ၂ ခုရဲ့ Enterprise network ေတြလည္း ပါ၀င္တယ္။ router ေတြၾကားမွာ ခ်ိတ္ဆက္ထားတဲ့ physical link သည္ ေကာင္းစြာ အလုပ္လုပ္ေနတယ္လို့ ယူဆၾကပါစို့။ router တစ္လံုးစီသည္ BGP ကို အသံုးျပဳမွာျဖစ္ျပီး ၊ link ရဲ့ တစ္ဖက္စီမွာ ရွိေနတဲ့ router ေတြသည္ BGP neighbor အျဖစ္ တည္ေဆာက္ၾကလိမ့္မယ္။ ဥပမာ ISP1 ရဲ့ I1-2 router သည္ Router I1-1 ၊ router I2-1 တို့နဲ့ BGP neighbor အျဖစ္ တည္ေဆာက္လိမ့္မယ္။

ပံု 12-5 မွာ အျခား ASN ေတြသို့ advertise လုပ္မယ့္ prefix 192.31.7.32/29 အတြတ္ BGP update ေတြကို ျပသထားတယ္။ ၄င္းပံုမွာ ေအာက္ပါအတိုင္း အဆင့္ ၄ ဆင့္ ပါ၀င္တယ္။

အဆင့္ ၁
ASN 12 ထဲက I2 သည္ ASN 12 အျပင္ဖက္သို့ route ေတြကို ေၾကျငာတဲ့အခါ ၊ သူ့ရဲ့ကိုယ္ပိုင္ ASN 12 ကို AS_Path PA ထဲသို့ ထည့္သြင္းေၾကျငာတယ္။

အဆင့္ ၂
ASN 2 ထဲက router ေတြသည္ ASN 2 ရဲ့ အျပင္ဖက္သို့ route ေတြ ေၾကျငာတဲ့အခါ သူတို့ရဲ့ ကိုယ္ပိုင္ ASN 2 ကို AS_Path PA ထဲသို့ ထည့္သြင္း ေၾကျငာတယ္။ ဒါ့ေၾကာင့္ AS_Path က (12,2) ျဖစ္လာတယ္။

အဆင့္ ၃
ASN 3 ထဲက router I3-1 မွာ ASN 2 ထံမွ learn လုပ္ျပီး သိထားတဲ့ 192.31.7.32/29 အတြတ္ AS_Path (12,2) route တစ္ေၾကာင္းရွိေနတယ္။ ဒါ့ေၾကာင့္ I3-1 သည္ သူ့ရဲ့ကိုယ္ပိုင္ ASN 3 ကို AS_Path သို့ ထည့္ေပါင္းျပီး ၊ ရလာတဲ့ AS_Path (12,2,3) route ကို ASN 1 သို့ ေၾကျငာတယ္။

အဆင့္ ၄
ထို့အတူ ASN 1 ထဲက router I1-1 သည္လည္း သူ့ရဲ့ကိုယ္ပိုင္ ASN 1 ကို AS_Path PA သို့ ထည့္သြင္းျပီး (12,2,1) route ကို ASN 3 သို့ ေၾကျငာတယ္။

အခုတဖန္ ASN 1 ထဲက router ေတြ learn လုပ္ထားတဲ့ route ေတြကို ၾကည့္ၾကဦးစို့။

192.31.7.32/29, AS_Path (12,2)
192.31.7.32/29, AS_Path (12,2,3)

BGP path selection algorithum မွာ အတိုဆံုး AS_Path ကို အသံုးျပဳတာမို့ ၊ အျခား PA ေတြကို ထည့္သြင္းတြတ္ခ်က္မွဳ မလုပ္ဘူးလို့ ယူဆရင္ ၊ ASN 1 ထဲက router ေတြသည္ အထက္ပါ path ၂ ခုအနက္က ပထမ path ကို အသံုးျပဳမွာျဖစ္ျပီး packet ေတြကို ေနာက္တစ္ဆင့္အေနနဲ့ ASN 2 သို့သာ ေပးပို့မွာျဖစ္ျပီး ၊ ASN 3 ကို အသံုးျပဳမွာ မဟုတ္ဘူး။ ထို့အတူ ASN 11 သို့ ASN 1 မွ advertise လုပ္လိုက္တဲ့ route သည္လည္း AS_Path (12,2,1) ျဖစ္ပါလိမ့္မယ္။

BGP router ေတြသည္ routing loop ေတြကို ဖယ္ရွားဖို့အတြတ္လည္း AS_Path ထဲက ASN ေတြကိုပဲ ထပ္မံအသံုးျပဳတယ္။ BGP router တစ္လံုးသည္ update တစ္ခုကို လက္ခံရရွိျပီး ၊ ၄င္း update အတြင္းမွာ မိမိရဲ့ ကိုယ္ပိုင္ ASN ပါ၀င္ေနတယ္ဆိုရင္ ၊ ၄င္း route ကို ignore လုပ္လိုက္တယ္။ မိမိကိုယ္ပိုင္ ASN ထည့္သြင္းျပီး ေၾကျငာလိုက္တဲ့ route တစ္ေၾကာင္း မိမိထံျပန္ေရာက္လာတယ္ဆိုရင္ routing loop ျဖစ္ႏိူင္တယ္လို့ ယူဆတာမို့ ignore လုပ္ျခင္းျဖစ္တယ္။

Frame Relay (7)

2011-04-17T01:53:00.002+06:30

Local Management Interface (LMI)

end station ၂ခုၾကား ၾကန့္ၾကာမွဳ အနည္းဆံုး packet-switched data transfer ကို provide လုပ္ႏိူင္ဖို့ Frame Relay ကို design လုပ္ခဲ့တယ္။

ေနာက္ပိုင္းမွာ DTE မ်ားသည္ network status နဲ့ information မ်ားကို ခ်က္ခ်င္း ရယူႏိူင္ဖို့ လိုအပ္တယ္ ဆိုတာ သိလာၾကတယ္။ မူလ Frame Relay design မွာ ဒီ feature မပါ၀င္ခဲ့ဘူး။ ရွဳပ္ေထြးတဲ့ internetworking enviroment မ်ားအတြတ္ ေနာက္ထပ္ capabilities ေတြ provide လုပ္ႏိူင္ဖို့ Cisco, Digital Equipment Corporation (DEC), Northern Telecom နဲ့ StrataCom တို့သည္ Frame Relay protocol ကို ထပ္မံ ခ်ဲ့ထြင္မွဳေတြ ျပဳလုပ္ၾကတယ္။ ၄င္း extension အားလံုးကို LMI အျဖစ္ ရည္ညႊန္းတယ္။

အေျခခံအားျဖင့္ LMI သည္ router နဲ့ Frame Relay switch အၾကား Frame Relay connection မ်ားနဲ့ ပက္သက္တဲ့ status information ေတြကို provide လုပ္တဲ့ keepaline mechanism တစ္ခုျဖစ္တယ္။ ၁၀ စကၠန့္တိုင္းမွာ end device သည္ network မွ dumb sequenced response ဒါမွမဟုတ္ channel status information ေတြကုိ request လုပ္တယ္။ အကယ္၍ network က response မလုပ္တဲ့အခါ connection down ျပီလို့ ယူဆတယ္။ network က FULL STATUS response နဲ့ တံု့ျပန္တဲ့အခါ ၊ line မွာ allocate လုပ္ထားတဲ့ DLCI မ်ားနဲ့ ပက္သက္တဲ့ status information ေတြ ပါ၀င္တယ္။

ပံုမွာ show frame-relay lmi command ရဲ့ output ကို ေတြ့ရမယ္။ Frame Relay interface က အသံုးျပဳေနတဲ့ LMI type ကို ေတြ့ရမွာ ျဖစ္တယ္။ LMI status exchange sequence အေရအတြတ္ေတြ ေတြ့ရမယ္။ LMI timeout errors ေတြ ေတြ့ရမွာ ျဖစ္တယ္။

LMI type မ်ားစြာ ရွိျပီး တစ္ခုနဲ့ တစ္ခု compatible မျဖစ္ပါ။ router မွာ အသံုးျပဳတဲ့ LMI type နဲ့ service provider မွာ အသံုးျပဳတဲ့ LMI type တို့ တူညီရမယ္။ Cisco router မ်ားမွာ support လုပ္တဲ့ LMI type 3 မ်ိဳးရွိတယ္။

Cisco
Ansi
q933a

LMI type ကို manual သတ္မွတ္တဲ့အခါ၊ router နဲ့ switch အၾကား status exchanges ေတြ timing လႊဲမွဳ မျဖစ္ေစဖို့၊ Frame Relay interface မွာ keepalive interval ကို configure လုပ္ေပးရမယ္။ LMI staus exchange messages မ်ားသည္ PVC connection မ်ားရဲ့ status ကို ဆံုးျဖတ္ေပးတယ္။ ဥပမာ switch နဲ့ router ၾကား keepalive interval မ်ားစြာ ကြဲလြဲမွဳသည္ switch ကို router down သြားျပီလို့ ယူဆသြားေစတယ္။

default မွာ Cisco serial interfaces မ်ားေပၚက keepalive time interval သည္ 10 စကၠန့္ ျဖစ္တယ္။ keepalive interval ကို keepalive interface configuration command နဲ့ ျပဳျပင္ႏိူင္တယ္။

Frame Relay (6)

2011-04-17T01:46:00.003+06:30

Frame Relay Address Mapping

router က Frame Relay ေပၚမွာ data ေတြ မပုိ့လႊတ္မွီ destination ရဲ့ layer 3 address နဲ့ DLCI တန္ဖိုးကို သိဖို့ လိုအပ္တယ္။ Cisco router မ်ားသည္ Frame Relay ေပၚမွာ network layer protocol အားလံုးကို support လုပ္တယ္။ address-to-DLCI mapping ကို static ဒါမွမဟုတ္ dynamic လုပ္ေဆာင္လို့ ရတယ္။

Inverse ARP (IP to DLCI)

အျခား station ရဲ့ layer 3 address ကို Frame Relay ရဲ့ DLCI လို layer 2 address မွ ရယူတယ္။ IARP ကို အမ်ားအားျဖင့္ Frame Relay နဲ့ ATM network မ်ားမွာ အသံုးျပဳတယ္။ ၄င္း network မ်ားမွာ layer 2 address ကို layer 2 signaling မွ ရယူႏိူင္ျပီး ၊ VC ကို အသံုးျပဳႏူိင္ဖို့ သက္ဆိုင္တဲ့ Layer 3 address ကို သိထားရမွာ ျဖစ္တယ္။

Dynamic Mapping

IARP ကို အသံုးျပဳျပီး next hop network protocol address ကို DLCI တန္ဖိုးသို့ ေျဖရွင္းတယ္။ Frame Relay router သည္ IARP request ကို PVC ေပၚသို့ ထုတ္လႊတ္ကာ Frame Relay network သို့ ခ်ိတ္ဆက္ထားတဲ့ remote device ရဲ့ protocol address ကို ရွာေဖြတယ္။ တုန့္ျပန္လာတဲ့ response မ်ားကို အသံုးျပဳျပီး router သည္ address-to-DLCI mapping table ကို တည္ေဆာက္တယ္။ ၄င္း table မွာ static နဲ့ dynamic mapping entries ေတြ အပါအ၀င္ ေျဖရွင္းျပီးသား IARP request အားလံုးပါ၀င္တယ္။

show frame-relay map command ရဲ့ output ကို အထက္မွာ ေတြ့ရမယ္။ IP address သည္ 10.1.1.2 ျဖစ္ျပီး ၄င္းရဲ့ DLCI တန္ဖိုးသည္ 102 ျဖစ္တာ ေတြ့ရမယ္။ DLCI တန္ဖိုးကို နည္းလမ္း 3 ခုနဲ့ ေဖာ္ျပတယ္၊ decimal 102 ၊ hexadecimal 0x66 နဲ့ wire ေပၚမွာ ေပၚတဲ့ 0x1860 ။ ၄င္း သည္ static entry ျဖစ္တယ္။ Cisco encapsulation ကို အသံုးျပဳထားတယ္။ (encapsulation မွာ Cisco နဲ့ IETF ဆိုျပီး ၂ မ်ိဳးရွိတယ္)။

manual static mapping ကို အသံုးျပဳျပီး dynamic Inverse ARP mapping ကို override လုပ္ႏိူင္တယ္။ ဒါေပမယ့္ DLCI နဲ့ protocol တစ္ခုအတြတ္ Inverse ARP နဲ့ map statement ကို တျပိဳင္နက္ အသံုးမျပဳလို့ မရပါ။

Frame Relay ရဲ့ အျခားတစ္ဖက္မွ network သည္ network protocol တစ္ခုအတြတ္ dynamic Inverse ARP ကို support မလုပ္တဲ့ အေျခအေနမ်ိဳးမွာ static address mapping ကို အသံုးျပဳရတယ္။

hub-and-spoke Frame Relay network မွာလည္း spoke-to-spoke rechability အတြတ္ spoke router မ်ားမွာ static address mapping ကို အသံုးျပုတယ္။ spoke router မ်ားမွာ တစ္ခုနဲ့ တစ္ခု တိုက္ရိုက္ ခ်ိတ္ဆက္မွဳ မရွိတာမို့ dynamic Inverse ARP သည္ ၄င္း router မ်ားၾကားမွာ အလုပ္မလုပ္ပါ။ dynamic IARP သည္ end ၂ ခုၾကား တိုက္ရိုက္ ခ်ိတ္ဆက္ထားတဲ့ point-to-point connection ေပၚမွာ အလုပ္လုပ္တယ္။ ဒါေၾကာင့္ hub နဲ့ spoke ၾကားမွာ dynamic IARP ကို အသံုးျပဳႏိူင္ျပီး spoke မ်ားၾကား အခ်င္းခ်င္း ဆက္သြယ္မွဳအတြတ္ static mapping လိုအပ္တယ္။

Frame Relay (5)

2011-04-17T01:35:00.003+06:30

Frame Relay Topologies

၂ ခုထက္ပိုတဲ့ sites ေတြကို ခ်ိတ္ဆက္ရမယ္ဆိုရင္ connection topology ကို စဥ္းစားရေတာ့မယ္။ topology ဆိုတာ Frame Relay network ရဲ့ visual layout ဒါမွမဟုတ္ map ျဖစ္တယ္။ Frame Relay networks မ်ားသည္ sites အေရအတြတ္ ရာ ဂဏာန္းကို ခ်ိတ္ဆက္ေပးတယ္။

network segment အသီးသီးကို star, full mesh ဒါမွမဟုတ္ partial mesh topology တစ္ခုခုအျဖစ္ ရွဳျမင္ႏိူင္တယ္။

Star Topology (Hub and Spoke)
အရိုးရွင္းဆံုး WAN topology ျဖစ္တယ္။ ဒီ topology မွာ hub သည္ central site တစ္ခုျဖစ္ျပီး အဓိက က်တဲ့ services ေတြကို host လုပ္ထားတယ္။ remote sites 5 ခုသို့ ခ်ိတ္ဆက္ထားတဲ့ connections မ်ားသည္ spoke ျဖစ္တယ္။ star topology မွာ lease-line cost အနည္ဆံုးျဖစ္မယ့္ location ကို hub အျဖစ္ ေရြးခ်ယ္တယ္။ အကြအေ၀းအလိုက္ ကုန္က်စရိတ္ တတ္တာမ်ိဳး မဟုတ္တာမို့ hub သည္ ပထ၀ီ အေနအထားအရ network ရဲ့ အလယ္မွာ ရွိေနဖို့ မလိုအပ္ဘူး။

Full Mesh Topology
access လုပ္ရမယ့္ services ေတြသည္ ပထ၀ီ အေနအထား အရ ေ၀းကြာ လြန္းေနျပီး ၊ ၄င္း service ေတြကို access လုပ္ဖို့ reliable အရမ္း လိုအပ္တယ္ဆိုရင္ full mesh topology ကို အသံုးျပဳရမယ္။ full mesh မွာ site ေတြ အားလံုးကို တစ္ခုနဲ့ တစ္ခု ခ်ိတ္ဆက္ထားတယ္။ အကယ္၍ leased line ကို အသံုးျပဳမယ္ဆိုရင္ serial interface ၁၀ ခုနဲ့ line ၁၀ ခု လိုအပ္မယ္။ Frame Relay ကို အသံုးျပဳတဲ့အခါ ၊ ရွိေနတဲ့ line အသီးသီးေပၚမွာ ေနာက္ထပ္ VCs ေတြ configuration ျပဳလုပ္ေပးလိုက္ ရံုနဲ့ ေျပလည္ေစတယ္။

Pertial Mesh Topology
အရမ္းၾကီးတဲ့ network ေတြမွာ link လိုအပ္ခ်က္ အေရအတြတ္ မ်ားျပားလြန္းတာမို့ full mesh topology တည္ေဆာက္ဖို့ ခက္ခဲတယ္။ ျပႆနာက hardware အတြတ္ ကုန္က်စရိတ္ မဟုတ္ပါဘူး။ link တစ္ခုမွာ ရရွိႏိူင္တဲ့ VCs အေရအတြတ္ ကန့္သတ္ခ်က္ေၾကာင့္ ျဖစ္တယ္။ သီအိုရီအရ link တစ္ခုမွာ 1000 VCs အသံုးျပဳႏိူင္တယ္ ဆိုေပမယ့္ တကယ့္ လက္ေတြ့မွာ ၄င္း ပမာဏထက္ ေလ်ာ့နည္းပါတယ္။ ဒါေၾကာင့္ network ၾကီးေတြမွာ ေယဘူယ်အားျဖင့္ partial mesh ကိုသာ တည္ေဆာက္တယ္။ partial mesh မွာ star ထက္လည္း ပိုမ်ားတဲ့ ၊ ဒါေပမယ့္ full mesh ေလာက္လည္း မမ်ားတဲ့ ဆက္သြယ္မွဳေတြ ပါ၀င္တယ္။

Frame Relay (4)

2011-04-17T01:28:00.002+06:30

Frame Relay Encapsulation Process

Frame Relay သည္ IP or IPX လို network layer protocol တစ္ခုမွ data packet ကို ယူတယ္၊ Frame Relay frame တစ္ခုအျဖစ္ encapsulate လုပ္တယ္၊ wire ေပၚသို့ deliver လုပ္ဖို့အတြတ္ physical layer သို့ ေပးပို့တယ္။

၄င္း process ကို ေသခ်ာေလ့လာၾကည့္မယ္။

ပထမဦးစြာ Frame Relay သည္ IP လို network layer protocol တစ္ခုမွ packet တစ္ခုကို လက္ခံယူလိုက္တယ္။ ျပီးတဲ့ေနာက္ DLCI နဲ့ checksum ပါ၀င္တဲ့ address field တစ္ခုနဲ့ ထုပ္ပိုးလိုက္တယ္။ frame ရဲ့ အစ နဲ့ အဆံုးကုိ ေဖာ္ျပဖို့ flag field ကို ထပ္ေပါင္းထည့္တယ္။ flag သည္ 7E နဲ့ စတဲ့ hexadecimal number တစ္ခု ဒါမွမဟုတ္ binary number 01111110 ျဖစ္တယ္။ packet ကို encapsulate လုပ္ျပီးတဲ့အခါ physical layer သို့ ေပးပို့လိုက္တယ္။

CPE router သည္ layer 3 packet တစ္ခုစီကို Frame Relay header နဲ့ trailer မ်ားအတြင္းမွာ encapsulate လုပ္တယ္။ header နဲ့ trailer တို့ကို Link Access Proceduer for Frame Relay (LAPF) Bearer Services specification, ITU Q.922-A တို့နဲ့ သတ္မွတ္ထားတယ္။ အတိအက်ေျပာရရင္ Frame Relay header မွာ ေအာက္ပါ အစိတ္အပိုင္းေတြ ပါ၀င္တယ္။

DLCI 10-bit DLCI သည္ Frame Relay header ရဲ့ အနွစ္ျဖစ္တယ္။ ၄င္းတန္ဖိုးသည္ DTE device နဲ့ switch ၾကားက virtual connection ကို ကိုယ္စားျပဳတယ္။ physical channel ေပၚမွာ multiplex လုပ္လိုက္တဲ့ virtual connection အသီးသီးကို တိက်တဲ့ DLCI တစ္ခုစီနဲ့ ကိုယ္စားျပဳထားတယ္။
Extended Address (EA) EA field ထဲမွာ တန္ဖိုး 1 ျဖစ္တဲ့အခါ လက္ရွိ byte သည္ ေနာက္ဆံုး DLCI octet ျဖစ္တယ္လို့ အဓိပါယ္ရတယ္။ ယခုလက္ရွိ Frame Relay inplementations မ်ားမွာ DLCI octet ၂ ခု အသံုးျပဳထားတာမို့ EA သည္ ေနာင္လာမယ့္ အနာဂတ္မွာ ပိုမိုရွည္လ်ားတဲ့ DLCI ေတြ အသံုးျပဳႏိူင္ ေစလိမ့္မယ္။
C/R ယခုလက္ရွိမွာ C/R ကို သတ္မွတ္မထားေသးဘူး။
Congestion Control 3-bit ျဖစ္တယ္။ Frame Relay congestion-notification mechanism ကို control လုပ္ဖို့ ျဖစ္တယ္။

Physical layer မွာ EIA/TIA-232, 449, 530, V.35 ဒါမွမဟုတ္ X.21 ျဖစ္မယ္။

Frame Relay (3)

2011-04-17T01:19:00.003+06:30

Multiple VCs

Frame Relay သည္ တစ္ၾကိမ္မွာ frame တစ္ခုကိုသာ transmit လုပ္တယ္။ ဒါေပမယ့္ physical line တစ္ခုေပၚမွာ logical-connections မ်ားစြာ ရွိေနႏိူင္တယ္။ Frame Relay network သို့ ခ်ိတ္ဆက္ထားတဲ့ Frame Relay Access Device (FRAD) ဒါမွမဟုတ္ router မွာ endpoint မ်ားစြာ သို့ ခ်ိတ္ဆက္ထားတဲ့ VCs မ်ားစြာ ရွိေနႏိူင္တယ္။ VC အသီးသီးမွာ သူတို့ ကိုယ္ပိုင္ DLCI တန္ဖိုးတစ္ခု ရွိၾကတာမို့ physical line တစ္ခုေပၚမွာ VC မ်ားစြာကို ခြဲျခားႏိူင္တယ္။ DLCI သည္ local significance ျဖစ္တာမို့ VC တစ္ခုရဲ့ အဆံုး ၂ ဖက္က DLCI ေတြ တူညီၾကမည္ မဟုတ္ပါ။ access line ေတြကို mesh လုပ္ဖို့အတြတ္ Frame Relay သည္ ကုန္က်စရိတ္ သက္သာတဲ့ အစားထိုး ေျဖရွင္းနည္း တစ္ခုျဖစ္တယ္။ device မ်ားစြာ ခ်ိတ္ဆက္ဖို့ equipment လိုအပ္ခ်က္နဲ့ ရွုပ္ေထြးမွု နည္းပါးတာမို့ ျဖစ္တယ္။ Frame Relay configuration မွာ endpoint တစ္ခုစီသည္ interface နဲ့ access line တစ္ခုသာ လိုအပ္တယ္။

Frame Relay မွာ customer သည္ bandwidth ထပ္မံလိုအပ္တယ္ဆိုရင္ service provider ထံမွ Frame Relay port ေတြ ထပ္မံ၀ယ္ယူရန္သာ ျဖစ္တယ္။ bandwidth အတြတ္သာ အကုန္အက် ရွိမွာျဖစ္ျပီး physical infrastructure ကို ျပဳျပင္ဖို့ မလိုအပ္တာမို့ ၄င္းအတြတ္ ကုန္က်စရိတ္ သက္သာသြားတယ္။

Frame Relay (2)

2011-04-17T00:56:00.003+06:30

Frame Relay Operation

DTE နဲ့ DCE ၾကား connection ေပၚမွာ physical layer နဲ့ data link layer components ၂မ်ိဳးစလံုး ပါ၀င္တယ္။

physical components ေတြသည္ devices မ်ားၾကား connection အတြတ္ mechanical, electrical, functional နဲ့ procedural သတ္မွတ္ခ်က္ေတြကို ျပဌာန္းတယ္။ အမ်ားဆံုး အသံုးျပဳတဲ့ physical layer interface သတ္မွတ္ခ်က္တစ္ခုမွာ RS-232 ျဖစ္တယ္။
link layer components ေတြသည္ DTE နဲ့ DCE ၾကား connection establish လုပ္ေဆာင္မယ့္ protocol ကုိ သတ္မွတ္တယ္။

LANs ေတြကို ခ်ိတ္ဆက္ဖို့ Frame Relay ကို အသံုးျပုတဲ့အခါ LAN တစ္ခုစီေပၚမွာ ရွိေနတဲ့ router ေတြသည္ DTE ျဖစ္တယ္။ T1/E1 leased line လို serial connection တစ္ခု ကို အသံုးျပဳျပီး router ကို အနီးဆံုး POP မွာ ရွိေနတဲ့ carrier ရဲ့ Frame Relay switch သို့ ခ်ိတ္ဆက္မယ္။ Frame Relay switch သည္ DCE ျဖစ္တယ္။

Virtual Circuits

DTE device ၂ခုၾကားက Frame Relay network connection ကို virtual circuit (VC) လို့ ေခၚတယ္။ network အဆံုး ၂ခုၾကားမွာ direct electrical connection မရွိတာေၾကာင့္ circuit သည္ virtual ျဖစ္တယ္။ Frame Relay သည္ users မ်ားအၾကား bandwidth ကို share လုပ္တယ္။ decicated physical lines မ်ားစြာ အသံုးျပဳဖို့ မလိုအပ္ဘဲ site တစ္ခုမွ အျခား မည္သည့္ site သို့မဆို ဆက္သြယ္ႏိူင္တယ္။ VCs ကို နည္းလမ္း ၂ ခုနဲ့ တည္ေဆာက္တယ္။

SVCs network သို့ signaling messages မ်ား ေပးပို့ျခင္းျဖင့္ switched virtual circuits ေတြကို dynamically တည္ေဆာက္တယ္။ (CALL SETUP, DATA TRANSFER, IDEL, CALL TERMINATION)
PVCs carrier က ၾကိဳတင္ configure လုပ္ထားတဲ့ permanent virtual circuit ျဖစ္တယ္။ DATA TRANSFER နဲ့ IDEL mode ေတြမွာသာ operate လုပ္တယ္။ PVC ကို အခ်ိဳ့ က private VC အျဖစ္ ရည္ညႊန္းတယ္။

Frame Relay သည္ switch အသီးသီးရဲ့ memory မ်ားထဲမွာ input-port to outport-port mapping ကို သိမ္းဆည္းထားျခင္းျဖင့္ VC တစ္ခုကို ဖန္တီးတယ္။ circuit တစ္ဖက္စြန္းမွ အျခားတစ္ဖက္စြန္းသို့ switch တစ္လံုးနဲ့ တစ္လံုး ဆက္တိုက္ ခ်ိတ္ဆက္ထားျခင္းျဖင့္ link ကို သတ္မွတ္တယ္။ VC တစ္ခုသည္ Frame Relay network အတြင္းရွိ ၾကားခံ switch မည္သည္ အေရအတြတ္ ကိုမဆို ျဖတ္သန္းႏိူင္တယ္။

VC သည္ device ၂ခုၾကား အသြားအျပန္ ဆက္သြယ္ေရးကို provide လုပ္တယ္။ VCs ေတြကို DLCIs မ်ားနဲ့ ခြဲျခား သတ္မွတ္ထားတယ္။ DLCI တန္ဖိုးေတြကို Frame Relay service provider က assign လုပ္တယ္။ Frame Relay DLCIs မ်ားသည္ local significance ျဖစ္တယ္။ VC နဲ့ ခ်ိတ္ဆက္ထားတဲ့ device ၂ ခုမွာ မတူညီတဲ့ DLCI တန္ဖိုးတစ္ခုစီ အသံုးျပဳထားႏိူင္တယ္။

frame တစ္ခု network ကို ျဖတ္သန္းတဲ့အခါ Frame Relay သည္ endpoint မ်ားၾကားက VC အသီးသီးကို DLCI တစ္ခုစီနဲ့ label လုပ္တယ္။ DLCI ကုိ frame အသီးသီးရဲ့ address field ထဲမွာထည့္သြင္းျခင္းျဖင့္ frame ကို မည္သို့ route လုပ္ရမည္ ဆိုသည္ကို network သို့ ေျပာဆိုတယ္။ DLCI 0 မွ 15 ၊ DLCI 1008 မွ 1023 ကို special purposes အတြတ္ reserve လုပ္ထားတယ္။ ဒါ့ေၾကာင့္ service providers မ်ားသည္ DLCIs ေတြကို 16 မွ 1007 range အတြင္း သတ္မွတ္တယ္။

Frame Relay (1)

2011-04-17T00:12:00.002+06:30

Frame Relay သည္ OSI reference model ရဲ့ physical နဲ့ data link layer မွာ အလုပ္လုပ္တဲ့ high-performance WAN protocol ျဖစ္တယ္။

The Frame Relay WAN

1970 ေႏွာင္းပိုင္းမွသည္ 1990 အေစာပိုင္းကာလအထိ sites ေတြကို ခ်ိတ္ဆက္ဖို့ WAN technology အျဖစ္ X .25 protocol ကို အသံုးျပဳခဲ့ၾကတယ္။ unreliable cabling infrastructure ေပၚမွာ reliable connection ကို provide လုပ္တာမို့ အလြန္ လူၾကိဳက္မ်ားခဲ့တယ္။ X.25 မွာ error control နဲ့ flow control တို့ ပါ၀င္တယ္။ ၄င္း features မ်ားေၾကာင့္ protocol ကို ေလးလံေစတယ္။

Frame Relay မွာ ၄င္း features ေတြ မပါရွိတာမို့ X.25 လို မေလးလံပါ။ ဥပမာ Frame Relay သည္ error correction ကို provide မလုပ္ပါ။ error တစ္ခုေတြ့ရတဲ့အခါ notification မျပဘဲ packet ကို drop လုပ္လိုက္တယ္။ error correction နဲ့ ပက္သက္ျပီး endpoints မ်ားအား လုပ္ေဆာင္ေစတယ္။ ဒီအခ်က္ေၾကာင့္ endpoints ၂ ခုအၾကား network ကို ျဖတ္လ်က္ propagation လုပ္ေဆာင္ရာမွာ အလြန္လ်င္ျမန္တယ္။

Frame Relay သည္ volume နဲ့ speed ကို ထိထိေရာက္ေရာက္ ကိုင္တြယ္ႏိူင္ဖို့ ၊ data link နဲ့ network layers မ်ားရဲ့ အေရးၾကီးတဲ့ လုပ္ေဆာင္ခ်က္ေတြကို protocol တစ္ခုအျဖစ္သို့ ေပါင္းစပ္တယ္။ data link protocol အျဖစ္ Frame Relay သည္ frame ေတြကို delimit လုပ္တယ္၊ အစီအစဥ္တက် အပို့အယူ လုပ္တယ္၊ CRC ကို အသံုးျပဳျပီး transmission errors ေတြကို ေဖာ္ထုတ္တယ္။ network protocol အျဖစ္ Frame Relay သည္ physical circuit တစ္ခုေပၚမွာ logical connections မ်ားစြာကို provide လုပ္တယ္။

Frame Relay သည္ LAN router လို end-user device နဲ့ network ၾကားမွာ အလုပ္လုပ္တယ္။ network ကိုယ္တိုင္သည္ အဆင္ေျပတဲ့ transmission method တစ္ခုခုကို အသံုးျပဳတယ္။ network အခ်ိဳ့မွာ Frame Relay ကို အသံုးျပဳျပီး၊ အခ်ိဳ့က digital circuit switching ဒါမွမဟုတ္ ATM cell relay systems ေတြကို အသံုးျပဳတယ္။

OSPF (25)

2011-04-16T15:39:00.003+06:30

OSPF Interface Priority

LSA ေတြကို စုစည္းဖို့ ၊ ျပန္လည္ ျဖန့္ေ၀ဖို့ DR သည္ အဓိက ျဖစ္တာမို့ ၄င္း တာ၀န္ေတြကို လုပ္ေဆာင္ဖို့ လံုေလာက္တဲ့ CPU နဲ့ memory ေတြ DR router မွာ ရွိေနဖို့ အေရးၾကီးတယ္။ DR နဲ့ BDR ကို ေရြးခ်ယ္ဖို့ router ID အေပၚမွာ မွီခိုေနမယ့္အစား ip ospf priority interface command နဲ့ ၄င္း router ေတြရဲ့ election ကို ထိန္းခ်ဳပ္ထားတာ ပိုမို ေကာင္းမြန္တယ္။
Router (config-if)#ip ospf priority {0 – 255}

ျပီးခဲ့တဲ့ သင္ခန္းစာေတြမွာ OSPF priority ေတြ တူညီခဲ့တယ္။ ဘာေၾကာင့္လဲဆိုေတာ့ router interface မ်ားအတြတ္ default တန္ဖိုးသည္ 1 ျဖစ္တာမို့ ျဖစ္တယ္။ ဒါေၾကာင့္ router ID က DR နဲ့ BDR ကို ဆံုးျဖတ္တယ္။ ဒါေပမယ့္ အကယ္၍ default တန္ဖိုး 1 ကို ပိုမိုျမင့္တဲ့ တန္ဖိုးတစ္ခုသို့ တိုးျမွင့္လိုက္မယ္ဆိုရင္ ၊ priority တန္ဖိုး ပိုမိုျမင့္တဲ့ router သည္ DR ျဖစ္လာမယ္။ ဒုတိယ တန္ဖိုးအျမင့္ဆံုး router သည္ BDR ျဖစ္လာမယ္။ priority တန္ဖိုး 0 သည္ router ကို DR သို့မဟုတ္ BDR ျဖစ္ေစေတာ့မည္ မဟုတ္ပါ။

priority သည္ interface-specific တန္ဖိုး ျဖစ္တာမို့ OSPF multiaccess network ေတြကို ပိုမို ေကာင္းမြန္စြာ ထိန္းခ်ဳပ္ထားႏိူင္တယ္။ router တစ္လံုးကို network တစ္ခုမွာ DR ျဖစ္ေစျပီး အျခား network တစ္ခုမွာ DROther ျဖစ္ေနေစတယ္။

ယခုအခါ RouterD ကို topology မွ ဖယ္ထုတ္လိုက္တယ္။ OSPF interface priority ကို show ip ospf interface command ကို အသံုးျပဳျပီး ၾကည့္မယ္။ ပံုမွာ RouterA ရဲ့ priority သည္ default တန္ဖိုး 1 ျဖစ္တာ ေတြ့ရမယ္။

ပံုမွာ RouterA နဲ့ RouterB တို့ရဲ့ modify လုပ္ထားျပီး ျဖစ္တဲ့ OSPF interface priority ကို ျပထားတယ္။ priority အျမင့္ဆံုးျဖစ္တဲ့ RouterA သည္ DR ျဖစ္လာျပီး ဒုတိယ တန္ဖိုး အျမင့္ဆံုးျဖစ္တဲ့ RouterB သည္ BDR ျဖစ္လာတယ္။ RouterC ရဲ့ OSPF interface priority သည္ default တန္ဖိုး 1 မွာပဲ ရွိေနပါတယ္။

router အားလံုးရဲ့ FastEthernet 0/0 interface ေတြမွာ shutdown နဲ့ no shutdown လုပ္ျပီးတဲ့အခါ OSPF interface priority ေတြ အေျပာင္းအလဲ ျဖစ္တာ ေတြ့ရမယ္။ RouterC ရဲ့ show ip ospf neighbor command မွာ RouterA (Router ID 192.168.31.11) သည္ OSPF interface priority အျမင့္ဆံုး 200 နဲ့ DR ျဖစ္လာတာ ေတြ့ရမယ္။ RouterB (Router ID 192.168.31.22) သည္ OSPF interface priority ဒုတိယအျမင့္ဆံုး 100 နဲ့ BDR ျဖစ္ေနဆဲ ဆိုတာ ေတြ့ရမယ္။ RouterA သည္ ၄င္း network မွာ DR ျဖစ္တာမို့ သူ့ရဲ့ show ip ospf neighbor command output မွာ DR ကို မျမင္ရျခင္း ျဖစ္တယ္ ဆိုတာ သတိျပဳပါ။

OSPF (24)

2011-04-16T15:19:00.003+06:30

DR/BDR Election Process
Timing of DR/BDR Election

multiaccess network မွာ OSPF enabled interface ပါရွိတဲ့ ပထမဆံုး router ကို စတင္ activate လုပ္လိုက္သည္နွင့္ တျပိုင္နက္ DR နဲ့ BDR election process စတင္တယ္။ router ကို power on လိုက္တဲ့အခါ ဒါမွမဟုတ္ OSPF network command ကို အသံုးျပဳျပီး interface ကို configure လုပ္တဲ့အခါ DR/BDR election စတင္တယ္။ election process သည္ အခ်ိန္အနည္းငယ္သာ ၾကာျမင့္တယ္။ multiaccess network အတြင္းရွိ router အားလံုး booting လုပ္လို့ မျပီးေသးဘူးဆိုရင္ router ID နိမ့္တဲ့ router တစ္လံုးသည္ DR ျဖစ္လာႏိူင္တယ္။ ဘာေၾကာင့္လဲဆိုေတာ့ lower-end router သည္ boot လုပ္ဖို့ အခ်ိန္ အနည္းငယ္သာ ၾကာျမင့္တာမို့ ျဖစ္တယ္။

DR နဲ့ BDR တို့ရဲ့ အခန္း ဂဏကို ေနာက္ပိုင္း သင္ခန္းစာမ်ားမွာ အေသးစိတ္ ဆက္လက္ ေဆြးေႏြးမယ္။ အခုေလာေလာဆယ္ ဘယ္အခ်ိန္မွာ DR ကို elect လုပ္သလဲဆိုတာ သိထားဖို့ အေရးၾကီးတယ္။ ေအာက္ပါ အေျခအေနေတြ ေပၚေပါက္သည္ အထိ DR သည္ DR အျဖစ္ ဆက္လက္ ရွိေနမယ္ :

DR … fail ျဖစ္သြားတဲ့အထိ
DR ေပၚက OSPF process … fail ျဖစ္သြားတဲ့အထိ
DR ေပၚက multiaccess interface … fail ျဖစ္သြားတဲ့အထိ

ပံုမွာ အထက္က အေျခအေနေတြကို ၾကက္ေျခခတ္ အနီ နဲ့ ျပထားတယ္။

အကယ္၍ DR fail ျဖစ္ခဲ့ရင္ BDR သည္ DR အျဖစ္ လက္လႊဲရယူျပီး BDR အသစ္ ကို ေရြးခ်ယ္လိမ့္မယ္။ ပံုမွာ RouterC fail ျဖစ္တဲ့အခါ BDR အျဖစ္ရွိေနတဲ့ RouterB သည္ DR ျဖစ္လာတယ္။ BDR အျဖစ္ ေရြးခ်ယ္ဖို့ RouterA တစ္လံုးသာ ရွိေနေတာ့တယ္။

DR နဲ့ BDR ကို ေရြးခ်ယ္ျပီးတဲ့ေနာက္၊ ေနာက္ထပ္ router အသစ္ ၀င္ေရာက္လာတဲ့အခါ ၄င္း router အသစ္သည္ လက္ရွိ ရွိေနတဲ့ DR နဲ့ BDR တို့ထက္ OSPF interface priority အျမင့္ဆံုး ျဖစ္ေနပါေစ ဒါမွမဟုတ္ router ID အျမင့္ဆံုး ျဖစ္ေနပါေစ DR ဒါမွမဟုတ္ BDR မျဖစ္ႏိူင္ေတာ့ပါ။ router အသစ္ကို DR သို့မဟုတ္ BDR အျဖစ္ ေရြးခ်ယ္ခံႏိူင္ဖို့ဆိုရင္ လက္ရွိ DR နဲ့ BDR တို့ fail ျဖစ္ဖို့ လိုအပ္တယ္။ ပံုမွာ RouterD သည္ network သို့ ဆက္သြယ္လာတယ္။ ၄င္းရဲ့ ID သည္ 192.168.31.44 ျဖစ္ျပီး လက္ရွိ DR နဲ့ BDR router ID တို့ထက္ ျမင့္ေနေသာ္ငွား RouterD သည္ DROther သာ ျဖစ္မယ္။

အရင္က DR အျဖစ္ရွိခဲ့တဲ့ router သည္ network သို့ ျပန္လည္ခ်ိတ္ဆက္လာေသာ္လည္း DR ျပန္လည္မျဖစ္ေတာ့ပါ။ ပံုမွာ RouterC သည္ router ID 192.168.31.33 ျဖစ္ေသာ္ငွား DROther သာ ျဖစ္မယ္။ BDR … fail ျဖစ္တဲ့အခါ DROther မ်ားအၾကား election တစ္ခု ျပဳလုပ္ျပီး BDR အသစ္ကို ေရြးခ်ယ္တယ္။

ပံုမွာ BDR router … fail ျဖစ္ေနတယ္။ RouterC နဲ့ RouterD ၾကားမွာ election ျပုလုပ္ျပီး router ID ျမင့္တဲ့ RouterD ကို BDR အျဖစ္ ေရြးခ်ယ္လိုက္တယ္။ DR နဲ့ BDR 2 ခုစလံုး fail ျဖစ္တဲ့အခါမွသာ DR/BDR နဲ့ ပက္သက္ျပီး အေျပာင္းအလဲ ျဖစ္မယ္။

ပံုမွာ RouterB … fail ျဖစ္သြားတယ္။ RouterD သည္ လက္ရွိမွာ BDR ျဖစ္ေနတာမို့ ၄င္းသည္ DR ျဖစ္လာမယ္။ RouterC သည္ BDR ျဖစ္လာမယ္။ ဒါေၾကာင့္ election မွာ DR နဲ့ BDR အျဖစ္ မိမိ ျဖစ္ေစလိုတဲ့ router ေတြ အေရြးခံရဖို့ ဘယ္လို လုပ္မလဲ? ေနာက္ထပ္ configuration ေတြ ထပ္မံ လုပ္စရာမလိုဘဲ ေအာက္ပါအတိုင္း ျပီးေျမာက္ႏိူင္တယ္ :

DR ကို ပထမဦးစြာ boot လုပ္ပါ။ ၄င္း ေနာက္မွာ BDR ကို boot လုပ္ပါ။ ေနာက္ဆံုးမွာမွ က်န္ေနတဲ့ router အားလံုးကို boot လုပ္ပါ။

ဒါမွမဟုတ္

router ေတြေပၚက interface ေတြကို ပိတ္ပါ။ ျပီးမွ DR ၊ BDR နဲ့ DROther အစီအစဥ္အတိုင္း no shutdown command ကို အသံုးျပဳျပီး ျပန္ဖြင့္ပါ။

ဒါေပမယ့္ DR/BDR election ကို ထိန္းခ်ဳပ္ဖို့ OSPF interface priority ကို အသံုးျပဳတာ ပိုမို ေကာင္းမြန္တယ္။

OSPF (23)

2011-04-16T15:11:00.003+06:30

DR/BDR Election Process
DR/BDR Election

DR နဲ့ BDR ကို ေရြးခ်ယ္ဖို့
1. OSPF interface priority အျမင့္ဆံုးျဖစ္တဲ့ rouuter သည္ DR ျဖစ္မယ္။
2. OSPF interface priority ဒုတိယ အျမင့္ဆံုးျဖစ္တဲ့ router သည္ BDR ျဖစ္မယ္။
3. OSPF interface priority ေတြ တူညီေနရင္ router ID အျမင့္ဆံုးျဖစ္တဲ့ router သည္ DR ၊ router ID ဒုတိယ အျမင့္ဆံုး router သည္ BDR ျဖစ္မယ္။

ပံုမွာ default OSPF interface priority သည္ 1 ျဖစ္တယ္။ ဒါေၾကာင့္ RouterC သည္ DR နဲ့ routerB သည္ BDR ျဖစ္လာမယ္။ RouterAသည္ DR လည္း မဟုတ္၊ BDR လည္း မဟုတ္တဲ့ DROther ျဖစ္လာမယ္။ DROther ေတြသည္ DR ၊ BDR တို့နဲ့ full adjacency တည္ေဆာက္တယ္။ ဒါေပမယ့္ network အတြင္းရွိ အျခား DROther ေတြနဲ့လည္း neighbor adjacency တည္ေဆာက္တယ္။ ဒါေၾကာင့္ multiaccess network မွာ DROther router ေတြသည္ အျခား DROther router ေတြရဲ့ Hello packets ေတြ အားလံုးကိုလည္း လက္ခံရယူတယ္။

ဒီနည္းအားျဖင့္ သူတို့သည္ network အတြင္းရွိ အျခား router အားလံုးကို သိရွိေနတယ္။ DROther router 2 လံုး neighbor adjacency တည္ေဆာက္ထားတဲ့အခါ neighbor state ကို 2WAY လို့ ျပထားတယ္။ အျခား neighbor state ေတြနဲ့ ပက္သက္ျပီး CCNP မွာ ဆက္လက္ ေလ့လာရမယ္။

ပံုမွာ ျပထားတဲ့ command output မွာ multiaccess network ရဲ့ router အသီးသီးမွာ ရွိေနတဲ့ neighbor adjacency ျပထားတယ္။ RouterA မွာ RouterC (router ID 192.168.31.33) သည္ DR နဲ့ RouterB (192.168.31.22) သည္ BDR ျဖစ္တယ္လို့ ျပထားတာ သတိျပဳပါ။ RouterA သည္ သူ့ရဲ့ neighbor 2 ခုစလံုးကို DR နဲ့ BDR အျဖစ္ ျပထားတာမို့ RouterA သည္ DROther ျဖစ္မယ္။ ip ospf interface fastethernet 0/0 command ကို အသံုးျပဳျပီး ၄င္း အခ်က္ကို စစ္ေဆးႏိူင္တယ္။ ၄င္း command သည္ router ရဲ့ DR, BDR ဒါမွမဟုတ္ DROther အေျခအေနေတြကို router ID ေတြနဲ့ ျပသေပးတယ္။

OSPF (22)

2011-04-16T15:07:00.004+06:30

DR/BDR Election Process
Topology Change

point-to-point network မွာ DR/BDR election မျဖစ္ေပၚပါ။ ဒါေၾကာင့္ ပံုမွာ ျပထားတဲ့ router 3 လံုးပါတဲ့ topology မွာ R1, R2 နဲ့ R3 တို့သည္ DR နဲ့ BDR ေတြကို ေရြးခ်ယ္ဖို့ မလိုအပ္ပါဘူး။ ဘာေၾကာင့္လဲဆိုေတာ့ သူတို့ၾကားက link သည္ multiaccess network မဟုတ္တာမို့ ျဖစ္တယ္။

DR/BDR တို့နဲ့ ပက္သက္ျပီး ေဆြးေႏြးဖို့ ပံုမွာ ျပထားတဲ့ multiaccess topology ကို အသံုးျပဳမယ္။ ပံုမွာ router 3 လံုးသည္ Ethernet multiaccess network (192.168.1.0/24) ကို share လုပ္ထားၾကတယ္။ router တစ္လံုးစီရဲ့ Fast Ethernet interface မ်ားေပၚမွာ IP address ေတြ သတ္မွတ္ေပးထားျပီး router ID အတြတ္ loopback address တစ္ခုစီကိုလည္း သတ္မွတ္ေပးထားတယ္။

OSPF (21)

2011-04-16T14:36:00.004+06:30

Flooding of LSAs

topology အတြင္းမွာ အေျပာင္းအလဲ တစ္ခုခုျဖစ္တဲ့အခါ ဒါမွမဟုတ္ OSPF စတင္တဲ့အခါ link-state router ေတြသည္ သူတို့ရဲ့ link-state packets ေတြကို flood လုပ္တယ္။ multiaccess network မွာ ၄င္း flooding သည္ အလြန္အကြ်ံ မ်ားျပားလာႏိူင္တယ္။

ပံုမွာ R1 သည္ LSA တစ္ခုကို ထုတ္လႊတ္လိုက္တယ္။ ဒါ့ေၾကာင့္ အျခား router အသီးသီးသည္လည္း LSA ေတြကို ထုတ္လႊတ္ၾကတယ္။ LSA တစ္ခုကို လက္ခံရရွိတဲ့အခါ ၄င္းအတြတ္ acknowledgement တစ္ခု ျပန္လည္ေပးပို့ေပးဖို့ လိုအပ္တယ္။ အကယ္၍သာ multiaccess network တစ္ခုေပၚမွာ router အားလံုးသည္ LSA ေတြကို flood လုပ္ရမယ္၊ acknowledgement ေတြကို ျပန္လည္ေပးပို့ရမယ္ဆိုရင္ network traffic ေတြ အလြန္အကြ်ံ မ်ားျပားလာပါလိမ့္မယ္။

Solution: Designated Router

multiaccess network မွာ LSAs ကို flooding လုပ္တဲ့ အေရအတြတ္ ကို ထိန္းခ်ဳပ္ဖို့၊ adjacency အေရအတြတ္ကို ထိန္းခ်ဳပ္ဖို့ ေျဖရွင္းနည္းသည္ Designated Router (DR) ျဖစ္တယ္။ router ေတြၾကား အပို့အယူလုပ္ေနတဲ့ LSAa ေတြကို စုယူဖို့၊ ျပန္လည္ ခြဲေ၀ ေ၀မွ်ဖို့ point တစ္ခုအျဖစ္ Designated Router (DR) ကို အသံုးျပဳတယ္။ Designated Router တစ္ခုခု ခြ်က္ယြင္းသြားခဲ့ရင္ အစားထိုးႏိူင္ဖို့ Backup Designated Router (BDR) ကိုလည္း ေရြးခ်ယ္ထားတယ္။ DR နဲ့ BDR မဟုတ္တဲ့ အျခား router ေတြအားလံုးသည္ DROthers ေတြ ျဖစ္လာတယ္။

multiaccess network တစ္ခုေပၚမွာ router ေတြသည္ DR နဲ့ BDR ကို ေရြးခ်ယ္ သတ္မွတ္ၾကတယ္။ DROthers ေတြသည္သာ DR ၊ BDR တို့နဲ့full adjacency တည္ေဆာက္ေတာ့တယ္။ ဆိုလိုခ်င္တာက network အတြင္းရွိ router အားလံုးသို့ LSA ေတြ flood လုပ္မယ့္အစား DROther ေတြသည္ DR နဲ့ BDR သို့သာ multicast address (224.0.0.6) ကို အသံုးျပဳျပီး သူတို့ရဲ့ LSA ေတြကို ေပးပို့ၾကတယ္။ ပံုမွာ R1 သည္ DR သို့ LSA ေတြ ေပးပို့တယ္။ DR နဲ့ BDR တို့သည္ ၄င္း LSA ကို လက္ခံယူၾကတယ္။ DR သည္ R1 က ေပးပို့လိုက္တဲ့ LSA ေတြကို အျခား router အားလံုးသို့ multicast address (224.0.0.5) ကို အသံုးျပဳျပီး ေပးပို့လိုက္တယ္။ ရလဒ္အေနနဲ့ multiaccess network အတြင္းမွာ LSA အားလံုးကို flood လုပ္ေနတဲ့ router တစ္လံုးထည္းသာ ရွိေနေတာ့တယ္။

OSPF (20)

2011-04-16T14:31:00.001+06:30

Multiple Adjacencies

network အတြင္းရွိ router တစ္စံုစီရဲ့ ၾကားမွာ adjacency တစ္ခုစီ ဖန္တီးျခင္းသည္ မလိုအပ္တဲ့ adjacency မ်ားစြာ ျဖစ္ေပၚေစတယ္။ အက်ိဳးဆက္အေနနဲ့ network ထဲက router မ်ားၾကားမွာ ျဖတ္သန္းသြားလာတဲ့ LSA အေရအတြတ္ အလြန္အကြ်ံ မ်ားျပာေစတယ္။

adjacency မ်ားျပားတဲ့ ျပႆနာကို နားလည္ဖို့အတြတ္ formula တစ္ခုကို ေလ့လာဖို့ လိုအပ္တယ္။ multiaccess network တစ္ခုေပၚက router အေရအတြတ္ (n) အတြတ္ adjacency အေရအတြတ္ n (n-1)/2 ျဖစ္တယ္။ ပံုမွာ multiaccess Ethernet network မွာ ခ်ိတ္ဆက္ထားတဲ့ router 5 လံုးပါ၀င္တဲ့ topology တစ္ခုကို ျပသထားတယ္။ adjacency အေရအတြတ္ 5 (5-1)/2 = 10 ျဖစ္တယ္။ ေနာက္ထပ္ router ေတြ ထပ္ေပါင္းထည့္မယ္ဆိုရင္ adjacency အေရအတြတ္ တိုးလာမယ္။ router 5 လံုးအတြတ္ adjacency 10 ခုသာ လိုအပ္ေပမယ့္ router 10 လံုးအတြတ္ဆိုရင္ adjacency 45 ခု လိုအပ္လာမွာ ျဖစ္ျပီး၊ router 20 အတြတ္ဆိုရင္ adjacency 190 အထိ လိုအပ္လာမွာ ျဖစ္တယ္။

OSPF (19)

2011-04-16T14:15:00.002+06:30

OSPF and Multiaccess Networks
Challenges in Multiaccess Networks

media တစ္ခုေပၚမွာ device 2 ခုထက္ ပိုရွိေနတဲ့ network ကို multiaccess network လို့ ေခၚတယ္။ ပံုနဲ့ အေပၚပိုင္းမွာ R1 ရဲ့ Fa0/0 interface မွာ device မ်ားစြာ ခ်ိတ္ဆက္ထားတဲ့ Ethernet LAN ကို ေတြ့ရမယ္။ Ethernet LAN သည္ multiaccess network ရဲ့ ဥပမာပင္ ျဖစ္တယ္။ multiaccess network မွာ device အားလံုးသည္ network ေပၚက frame အားလံုးကို ျမင္ေတြ့ေနရတာေၾကာင့္ broadcast network ျဖစ္တယ္။ network ေပၚမွာ host ၊ printer ၊ router နဲ့ အျခား device မ်ားစြာ ရွိေနႏိူင္တာမို့ multiaccess network ျဖစ္တယ္။

point-to-point network မွာ device 2 ခုသာ ရွိေနျပီး၊ device တစ္ခုရဲ့ အဆံုးမွာ အျခား device တစ္ခုကို ခ်ိတ္ဆက္ထားတယ္။ ပံုမွာ R1 နဲ့ R23 ၾကားမွ WAN link သည္ point-to-point link ရဲ့ ဥပမာျဖစ္တယ္။ OSPF မွာ network အမ်ိဳးအစား 5 ခု သတ္မွတ္ထားတယ္ :

Point-to-point
Broadcast Multiaccess
Nonbroadcast Multiaccess (NBMA)
Point-to-multipoint
Virtual links

NBMA နဲ့ point-to-multipoint network မ်ားမွာ frame Relay, ATM, နဲ့ X.25 networks တို့ ပါ၀င္တယ္။ NBMA network အေၾကာင္းကို အျခား CCNA သင္ခန္းစာမ်ားမွာ ေဆြးေႏြးမယ္။ point-to-multipoint network အေၾကာင္းကို CCNP မွာ ေဆြးေႏြးမယ္။ virtual link သည္ multi-area OSPF မွာ အသံုးျပဳတဲ့ special type တစ္ခုျဖစ္တယ္။ OSPF virtual link အေၾကာင္း CCNP မွာ ေဆြးေႏြးမယ္။

multiaccess network မွာ OSPF သည္ LSAs flooging နဲ့ ပက္သက္တဲ့ စိန္ေခၚမွဳ ၂ ခုကို ရင္ဆိုင္ရတယ္ :

1. Router 2 လံုးမွာ adjacency တစ္ခု အျဖစ္ router မ်ားစြာမွာ Adjacency မ်ားစြာ ဖန္တီးတဲ့ ျပႆနာ
2. LSA ေတြကို အလြန္အကြ်ံ flood လုပ္တဲ့ ျပႆနာ

OSPF (18)

2011-04-16T14:05:00.003+06:30

The bandwidth Command vs. the ip ospf cost Command

OSPF cost ကို တြတ္ဖို့ bandwidth ကို အသံုးမျပဳဘဲ အျခား matric ကို အသံုးျပဳတဲ့ Cisco မဟုတ္တဲ့ အျခား router ေတြ ပါ၀င္ေနတဲ့ multi-vendor ပတ္၀န္းက်င္မွာ ip ospf cost command သည္ အသံုး၀င္တယ္။ ၄င္း command 2ခု ၾကား အဓိက ျခားနားခ်က္မွာ bandwidth command သည္ link ရဲ့ cost ကို ဆံုးျဖတ္ဖို့ cost calculation မွ ရလာတဲ့ ရလဒ္ကို အသံုးျပဳတယ္။ ip ospf cost command သည္ cost calculation မလုပ္ဘဲ link ရဲ့ cost ကို တန္ဖိုး တစ္ခုသို့ တိုက္ရိုက္ သတ္မွတ္တယ္။ ပံုမွာ topology အတြင္း serial link ေတြရဲ့ cost ကို သတ္မွတ္ဖို့ အသံုးျပဳႏိူင္တဲ့ အထက္က command 2 ခုကို ျပထားတယ္။

OSPF (17)

2011-04-16T13:59:00.002+06:30

Modifying the Cost of the Link

default T1 speed မွာ serial interface အလုပ္မလုပ္တဲ့အခါ ၄င္း interface ကို manual ျပဳျပင္ေပးဖို့ လိုအပ္လာတယ္။ ၄င္းအတြတ္ bandwidth interface ဒါမွမဟုတ္ ip ospf cost interface command ကို အသံုးျပဳျပီး best route ကို ဆံုးျဖတ္တဲ့ေနရာမွာ OSPF က အသံုးျပဳမယ့္ မွန္ကန္တဲ့ တန္ဖိုး တစ္ခုကို သတ္မွတ္ေပးႏိူင္တယ္။

OSPF cost metric ကို တြတ္ခ်က္ရာမွာ IOS က အသံုးျပဳမယ့္ bandwidth တန္ဖိုးကို bandwidth command နဲ့ သတ္မွတ္ႏိူင္တယ္။ ပံုမွာ topology အတြင္းရွိ serial interface အားလံုးရဲ့ cost ေတြကို ျပုျပင္ သတ္မွတ္ဖို့ bandwidth command ကို အသံုးျပဳထားတာ ေတြ့ရမယ္။ R1 မွာ show ip ospf interface command သည္ Serial 0/0/0 link ရဲ့ cost တန္ဖိုး 1562 ကို ျပသေနတယ္ (100, 000, 000/64,000) ။

bandwidth command ကို အသံုးမျပဳဘဲ ip ospf cost command ကို အသံုးျပဳျပီး interface ရဲ့ cost ကုိ သတ္မွတ္ႏိူင္တယ္။ ip ospf cost command သည္ interface ရဲ့ cost တန္ဖိုးကို တိုက္ရိုက္ သတ္မွတ္တယ္။ ဥပမာ၊ R1 ရဲ့ Serial 0/0/0 အေပၚ ေအာက္ပါအတိုင္း သတ္မွတ္မယ္ :
R1 (config)#interface serial 0/0/0
R1 (config-if)#ip ospf cost 1562

OSPF (16)

2011-04-16T13:47:00.003+06:30

Default Bandwidth on Serial Interfaces

interface တစ္ခုအတြတ္ အသံုးျပုထားတဲ့ bandwidth ကို show interface command ကို အသံုးျပဳျပီး ၾကည့္ႏိူင္တယ္။ Cisco router မ်ားမွာ serial interface ေတြရဲ့ default bandwidth တန္ဖိုးသည္ T1 (1.544 Mbps) ျဖစ္တယ္။ ဒါေပမယ့္ အခ်ိဳ့ serial interface မ်ားရဲ့ default တန္ဖိုးသည္ 128 kbps ျဖစ္ေနတတ္တယ္။ ဒါေၾကာင့္ show interface command ကို အသံုးျပဳျပီး interface မ်ားရဲ့ default တန္ဖိုးကို ၾကည့္ရွဳ စစ္ေဆးသင့္တယ္။

၄င္း bandwidth တန္ဖိုးသည္ link ရဲ့ speed အေပၚ အမွန္တကယ္ သက္ေရာက္မွဳ မျဖစ္ပါ။ routing protocol အခ်ိဳ့မွာ routing metric ကို တြတ္ခ်က္ဖို့ ၄င္း တန္ဖိုးကို အသံုးျပဳဖို့မွ်သာ ျဖစ္တယ္။ serial interface မ်ားရဲ့ တကယ့္အမွန္ link speed နဲ့ default bandwidth တို့ တူညီဖို့ဆိုတာ ျဖစ္ႏိူင္ေျခ အရမ္းနည္းပါတယ္။ routing table မွာ မွန္ကန္တိက်တဲ့ အေကာင္းဆံုး path ေတြ ရွိေနေစဖို့အတြတ္ bandwidth တန္ဖိုးသည္ link ရဲ့ အမွန္တကယ္ speed ကို ထင္ဟပ္ေနဖို့ အေရးၾကီးတယ္။ ဥပမာ service provider ရဲ့ T1 connection သည္ 384 kbps သာ ေပးထားတယ္ ဆိုပါစို့။ ဒါေပမယ့္ routing protocols မ်ားအတြတ္ metric ကို တြတ္တဲ့အခါ IOS သည္ T1 ရဲ့ default တန္ဖိုး 1.544 Mbps ကို အသံုးျပဳလိမ့္မယ္။

ပံုမွာ R1 ရဲ့ Serial 0/0/0 interface အတြတ္ output ကို ျပထားတယ္။ R1 ရဲ့ command output မွာ default bandwidth သည္ 1544 kbps ျဖစ္တယ္ဆိုတာ သတိျပဳပါ။ ဒါေပမယ့္ link ရဲ့ အမွန္တကယ္ တန္ဖိုးသည္ 64 kbps ျဖစ္တယ္။ ဒါေၾကာင့္ router မွာ ရွိေနတဲ့ routing information ေတြသည္ network topology ကို အမွန္တကယ္ မထင္ဟပ္၀ူးဆိုတာ သိႏိူင္တယ္။

ပံုမွာ R1 အတြတ္ routing table ကို ျပထားတယ္။ သူ့ရဲ့ serial interface 2 ခုစလံုးသည္ T1 link မ်ားသို့ ခ်ိတ္ဆက္ထားတယ္လို့ R1 သည္ ယံုၾကည္ေပမယ့္ link တစ္ခုသည္ 64 kbps နဲ့ အျခား link တစ္ခုသည္ 256 kbps ျဖစ္ေနတယ္။ ဒါေၾကာင့္ ရလဒ္အေနနဲ့ R1 ရဲ့ routing table မွာ 192.168.8.0/30 network သို့ ေရာက္ရွိတဲ့ equal-cost path 2 ခု ရွိေနတယ္။ အမွန္တကယ္မွာ Serial 0/0/1 သည္ ပိုေကာင္းတဲ့ path ျဖစ္တယ္။ interface တစ္ခုရဲ့ တြတ္ခ်က္ထားတဲ့ OSPF cost ကို show ip ospf interface command နဲ့ ၾကည့္ရွဳႏိူင္တယ္။

ပံုမွာ R1 သည္ Serial 0/0/0 interface သို့ cost တန္ဖိုး 64 ကို အမွန္တကယ္ assign လုပ္ထားတာ ေတြ့ရမယ္။ ၄င္း serial interface ကို 64 kbps link သို့ ခ်ိတ္ဆက္ထားတာမို့ cost တန္ဖိုး 64 ျဖစ္တယ္လို့ ထင္ရေပမယ့္ cost ကို cost formula နဲ့ တြတ္ယူတယ္ဆိုတာ သတိျပဳပါ။ 64 kbps link ရဲ့ cost သည္ 1562 (100, 000, 000/64, 000) ျဖစ္တယ္။

OSPF (15)

2011-04-16T13:32:00.002+06:30

OSPF Accumulates Costs

OSPF route တစ္ခုရဲ့ cost သည္ router မွ destination network သို့ စုစုေပါင္း တန္ဖိုးျဖစ္တယ္။ ဥပမာ၊ R1 ရဲ့ routing table မွာ R2 ရဲ့ 10.10.10.0/24 network သို့ ေရာက္ဖို့ cost တန္ဖိုး 65 လို့ ပံုမွာ ျပထားတယ္။ အဘယ္ေၾကာင့္ဆိုေသာ္ 10.10.10.0/24 သည္ FastEthernet interface မွာ ခ်ိတ္ဆက္ထားတာမို့၊ R2 သည္ 10.10.10.0/24 အတြတ္ cost ကို 1 အျဖစ္ သတ္မွတ္တယ္။ ၄င္းေနာက္မွာ R1 သည္ သူနဲ့ R2 ၾကားမွာ ရွိေနတဲ့ T1 link ကို ျဖတ္ျပီး data ကို ေပးပို့ဖို့ ၄င္း link ရဲ့ cost တန္ဖိုး 64 ကို ေနာက္ထပ္ ထပ္ေပါင္းထည့္တယ္။

OSPF (14)

2011-04-16T13:27:00.002+06:30

OSPF Metric

Ospf metric ကို cost လို့ ေခၚတယ္။ RFC 2328 မွာ “ cost သည္ router interface အသီးသီးရဲ့ အထြက္ နဲ့ သက္ဆိုင္တယ္။ ၄င္း cost ကို system administrators ေတြက configure လုပ္တယ္။ cost တန္ဖိုးနည္းေလ data ေတြကို forward လုပ္ဖို့ ၄င္း interface ကို အသံုးျပဳဖို့ အလားအလာ ပိုမ်ားေလ ျဖစ္တယ္။ “ လို့ ေဖာ္ျပထားတယ္။ သတိျပဳစရာ အခ်က္တစ္ခုမွာ RFC2328 သည္ cost ကို ဆံုးျဖတ္ဖို့ မည္သည့္ တန္ဖိုးကို အသံုးျပဳသင့္တယ္လို့ မသတ္မွတ္ျခင္း ျဖစ္တယ္။

Cisco IOS သည္ router ရဲ့ အထြက္ interface မွ destination network အထိ bandwidth စုစုေပါင္းကို cost တန္ဖိုးအျဖစ္ အသံုးျပဳတယ္။ router အသီးသီးမွာ interface တစ္ခုအတြတ္ cost တန္ဖိုးကို 10 ရဲ့ 8 ထပ္တန္ဖိုးကို bandwidth နဲ့ စားျပီး တြတ္ခ်က္တယ္။ ၄င္းကို reference bandwidth လို့ ေခၚတယ္။ 10 ရဲ့ 8 ထပ္ တန္ဖိုးကို interface ရဲ့ bandwidth နဲ့ စားျခင္းျဖင့္ bandwidth တန္ဖိုးျမင့္တဲ့ interface သည္ cost တန္ဖိုး နိမ့္ (နည္း) သြားမွာ ျဖစ္တယ္။

Reference Bandwidth

default မွာ reference bandwidth သည္ 10 ရဲ့ 8 ထပ္တန္ဖိုး (100, 000, 000 bps ဒါမွမဟုတ္ 100 Mbps) ျဖစ္တယ္။ bandwidth 100 Mbps နဲ့ အထက္ interfaces မ်ားမွာ OSPF cost တန္ဖိုး 1 ျဖစ္တယ္ (100 Mbps/ 100 Mbps) ။ reference bandwidth ကို 100, 000, 000 bps ထက္ျမန္တဲ့ links ေတြနဲ့ လိုက္ေလ်ာညီေထြျဖစ္ေစဖို့ auto-cost reference-bandwidth OSPF command ကို အသံုးျပဳျပီး ျပဳျပင္ႏိူင္တယ္။ ၄င္း command ကို အသံုးျပုတဲ့အခါ router အားလံုးမွာ OSPF routing metric ကို တေျပညီျဖစ္ေနေစဖို့ ဂရုျပဳရပါမယ္။

OSPF (13)

2011-04-16T13:19:00.002+06:30

Examining the Routing Table

OSPF convergence ကို စစ္ေဆးဖို့ အျမန္ဆံုး နည္းလမ္းမွာ topology အတြင္းရွိ router အသီးသီးရဲ့ routing table ေတြကို ၾကည့္ရွဳျခင္းပဲ ျဖစ္တယ္။ OSPF မွတဆင့္ routes ေတြ အပို့အယူ လုပ္ေနသလားဆိုတာ စစ္ေဆးဖို့ show ip route command ကို အသံုးျပဳႏိူင္တယ္။ route source သည္ OSPF ျဖစ္ေၾကာင္း route တစ္ခုစီရဲ့ ေရွ့မွာ ျပထားတဲ့ O သေကၤတ က ေျပာျပေနပါတယ္။ routing table နဲ့ OSPF ကို ေနာက္သင္ခန္းစာမွာ အေသးစိတ္ ေလ့လာမယ္။ ဒါေပမယ့္ ဒီေနရာမွာ OSPF routing table နဲ့ ပက္သက္ျပီး သတိျပဳသင့္တဲ့ အခ်က္ေတြကို ေျပာျပခ်င္တယ္။ ပထမအခ်က္အေနနဲ့ router အသီးသီးမွာ တိုက္ရိုက္ခ်ိတ္ဆက္ထားတဲ့ networks 4 ခု ရွိေနတယ္ဆိုတာပါပဲ။ အဘယ္ေၾကာင့္ဆိုေသာ္ loopback interface ကို စတုတၱေျမာက္ network အျဖစ္ ထည့္သြင္းေရတြတ္တာမို့ ျဖစ္တယ္။ ဒါေပမယ့္ ၄င္း loopback interfaces ေတြကို OSPF မွာ ထည့္သြင္း မေၾကညာပါ၀ူး။ ဒါေၾကာင့္ router အသီးသီးမွာ networks 7 ခုစီ ရွိေနတာ ေတြ့ရပါမယ္။ ဒုတိယအခ်က္အေနနဲ့ OSPF သည္ RIPv2 နဲ့ EIGRP တို့လို မဟုတ္ဘဲ network boundaries မ်ားမွာ summarization ကို အလိုအေလ်ာက္ မလုပ္ေဆာင္ပါ။

OSPF (12)

2011-04-16T12:46:00.006+06:30

Verifying OSPF

Show ip ospf neighbor command ကို အသံုးျပဳျပီး OSPF neightbor relationships ျပႆနာေတြကို ရွာေဖြေျဖရွင္း ႏူိင္တယ္။ ၄င္း command သည္ neighbor တစ္ခုစီအတြတ္ ေအာက္ပါ အခ်က္အလက္ေတြကို ျပသေပးတယ္ :

Neighbor ID
neighbor router ရဲ့ router ID ။
Pri
interface ရဲ့ OSPF priority
ေနာက္ပိုင္းနဲ့ ဒါနဲ့ ပက္သက္ျပီး ထပ္မံေဆြးေႏြးမယ္။
State
interface ရဲ့ OSPF state
“Full” state ဆိုတဲ့ အဓိပါယ္သည္ router နဲ့ သူ့ရဲ့ neighbor တုိ့မွာ တူညီတဲ့ link-state databases ေတြ ရရွိသြားျပီလို့ ဆိုလိုျခင္း ျဖစ္တယ္။ OSPF state ေတြနဲ့ ပက္သက္ျပီး CCNP မွာ ဆက္လက္ေဆြးေႏြးမယ္။
Dead Time
neighbor မွ ပို့လႊတ္လိုက္တဲ့့ OSPF Hello packet တစ္ခုကို လက္ခံရယူဖို့ router က ေစာင့္ဆိုင္းရတဲ့ အခ်ိန္ပမာဏ။
ဒီအခ်ိန္ ပမာဏ ကုန္ဆံုးသြားတဲ့အထိ OSPF Hello packet ေရာက္မလာ၀ူးဆိုရင္ ၄င္း neighbor ကို “down” သြားျပီလို့ သတ္မွတ္တယ္။ Hello packet ကို လက္ခံရရွိတဲ့အခါ အခ်ိန္ တန္ဖိုးကို reset ျပန္လုပ္တယ္။
Address
ဒီ router နဲ့ တိုက္ရိုက္ခ်ိတ္ဆက္ထားတဲ့ neighbor router`s interface ရဲ့ IP address ။
Interface
ဒီ interface ေပၚမွာ ဒီ router နဲ့ neighbor router တို့ adjacency တည္ေဆာက္ထားတယ္။
OSPF networks ေတြကို troubleshoot လုပ္တဲ့အခါ router နဲ့ သူ့ရဲ့ neighbors ေတြ adjancency တည္ေဆာက္ထားသလား စစ္ေဆးဖို့ show ip ospf neighbor command ကို အသံုးျပဳႏိူင္တယ္။ အကယ္၍ ၄င္း command ရဲ့ output မွာ neighbor router ရဲ့ router ID ကို မျပသ၀ူးဆိုရင္၊ ဒါမွမဟုတ္ “Full” state လို့ မျပသ၀ူးဆိုရင္ router 2 လံုးသည္ OSPF adjacency မတည္ေဆာက္ရေသး၀ူးလို့ သိႏိူင္တယ္။ router 2 လံုး adjacency မျဖစ္၀ူးဆိုရင္ link-state information ကို အခ်င္းခ်င္း ဖလွယ္ၾကလိမ့္မည္ မဟုတ္ပါ။
ျပည့္စံုမွန္ကန္မွဳ မရွိတဲ့ link-state database သည္ SPF trees နဲ့ routing tables ေတြကိုလည္းျပည့္စံုမွန္ကန္မွဳမရွိ ျဖစ္ေစတာေၾကာင့္ destination networks မ်ားသို့ သြားတဲ့ routes ေတြ မရွိတာ ဒါမွမဟုတ္ ရွိေနတဲ့ routes ေတြသည္ အေကာင္းဆံုး မျဖစ္တာ စတဲ့ ျပႆနာေတြ ျဖစ္ေစတယ္။

Note: Ethernet လို multiaccess networks မ်ားမွာ သူတို့ရဲ့ state ကို “2WAY” လို့ ျပသေနလိမ့္မယ္။ ဒါနဲ့ ပက္သက္ျပီး ေနာက္ပိုင္းမွာ ဆက္လက္ ေဆြးေႏြးမယ္။
router 2 လံုးသည္ ေအာက္ပါ အေျခအေနမ်ားမွာ OSPF adjancency အျဖစ္သို့ မေရာက္ရွိပါ :

subnet masks ေတြ မတူရင္
OSPF Hello ဒါမွမဟုတ္ Dead Timers ေတြ မတူရင္
OSPF Network Types မတူရင္
OSPF network command မွားယြင္းေနရင္ ဒါမွမဟုတ္ မျပည့္စံုရင္

OSPF ျပႆနာေတြကို ေျဖရွင္းရာမွာ အသံုး၀င္တဲ့ အျခား commands မ်ားမွာ : show ip protocols, show ip ospf, show ip ospf interface တို့ ျဖစ္တယ္။

ပံုမွာ ျပထားတဲ့အတိုင္း show ip protocols command ကို အသံုးျပဳျပီး OSPF process ID, router ID, router က advertise လုပ္ထားတဲ့ networks ေတြ ၊ router က update ေတြကို လက္ခံယူေနတဲ့ neighbor routers ေတြ၊ default administrative distance စတဲ့ အေရးၾကီးတဲ့ OSPF configuration information ေတြကို အလွ်င္အျမန္ ၾကည့္ရွဳႏိူင္တယ္။

show ip ospf command ကို OSPF process ID နဲ့ router ID ကို စစ္ေဆးရာမွာ အသံုးျပဳႏိူင္တယ္။ ဒါ့အျပင္ ဒီ command သည္ OSPF area information ေတြ၊ SPF algorithm ကို တြတ္ခ်က္ခဲ့တဲ့ ေနာက္ဆံုးအခ်ိန္တို့ကိုလည္း ျပသေပးတယ္။ ပံုမွာ ျပထားတဲ့ output ကို ၾကည့္ျခင္းအားျဖင့္ OSPF သည္ အလြန္ stable ျဖစ္တဲ့ routing protocol တစ္ခု ျဖစ္တယ္ဆိုတာ သိရွိႏိူင္တယ္။ လြန္ခဲ့တဲ့ 11 နာရီခြဲအတြင္း OSPF နဲ့ ပက္သက္ျပီး R1 လုပ္ေဆာင္ခဲ့တဲ့ လုပ္ေဆာင္ခ်က္သည္ neighbors မ်ားသို့ Hello packets ေတြ ေပးပို့ျခင္းမွသာ ျဖစ္တယ္။
Note: show ip ospf command output မွ အျခား information ေတြကို CCNP သင္ခန္းစာမ်ားမွာ ဆက္လက္ ေလ့လာရမယ္။

show ip ospf command output မွာ SPF schedule delay အပါအ၀င္ အျခား အေရးၾကီးတဲ့ SPF algorithm အခ်က္အလက္ေတြ ပါ၀င္တယ္။ (link တစ္ခု ထပ္တိုးလာျခင္း၊ ရွိေနတဲ့ link တစ္ခုကို ဖ်က္ျခင္း ဒါမွမဟုတ္ မြမ္းမံျခင္း စတဲ့) topology နဲ့ ပက္သက္တဲ့ information အသစ္ေတြ လက္ခံရရွိတဲ့အခါ router သည္ SPF algorithm ကို ျပန္ run ျပီး SPF tree အသစ္တစ္ခုကို ျပန္လည္ဖန္တီးရမယ္။ ျပီးတဲ့ေနာက္ routing table ကို update လုပ္ရမယ္။ SPF algorithm သည္ CPU-intensive ျဖစ္တယ္။ သူ့ကို တြတ္ခ်က္ဖို့ ၾကာမယ့္အခ်ိန္သည္ area အရြယ္အစားအေပၚမွာ မူတည္တယ္။ area အတြင္းမွာ ပါ၀င္ေနတဲ့ router အေရအတြတ္ နဲ့ link-state database ရဲ့ အရြယ္အစားအေပၚ မူတည္ျပီး ၄င္း area အရြယ္အစားကို တိုင္းတာတယ္။

“up” state နဲ့ “down” state ၾကား လွည့္ပတ္ေနတဲ့ network တစ္ခုကို flapping link အျဖစ္ ရည္ညႊန္းတယ္။ flapping link သည္ area အတြင္းရွိ OSPF routers ေတြကို SPF algorithm တြတ္ခ်က္မွဳေတြ မျပတ္ ျဖစ္ေပၚေစျပီး convergence ျပႆနာကို ဖန္တီးတယ္။ ၄င္း ျပႆနာ မျဖစ္ေစဖို့၊ router သည္ LSU ကို လက္ခံရရွိျပီးေနာက္ SPF algorithm ကို မ run မွီ 5 seconds (5000 msecs) ေစာင့္တယ္။ ၄င္းကို SPF schedule delay လို့ ေခၚတယ္။ SPF algorithm ကို အျမဲမျပတ္ run ေနျခင္းမွ router ကို တားဆီဖို့ ေနာက္ထပ္ 10 seconds (10000 msecs) ထပ္ေပါင္းထည့္ထားတယ္။ SPF algorithm ကို run ျပီးေနာက္၊ ေနာက္ထပ္ algorithm ကို ထပ္မံမ run မွီ router သည္ 10 seconds ေစာင့္ရတယ္။

Hello နဲ့ Dead intervals ေတြကို အလွ်င္အျမန္ ၾကည့္ႏိူင္ဖို့ show ip ospf interface command ကို အသံုးျပုတယ္။ ပံုမွာ ျပထားတဲ့အတိုင္း တိက်တဲ့ interface တစ္ခုအတြတ္ interface name နဲ့ number ကို command မွာ ထပ္ေပါင္းထည့္ေပးရမယ္။ routers ေတြၾကား ေပးပို့ေနတဲ့ OSPF Hello packets ေတြထဲမွာ ၄င္း intervals ေတြ ပါ၀င္တယ္။ OSPF interfaces မ်ားမွာ မတူညီတဲ့ Hello နဲ့ Dead intervals ေတြ ရွိေနႏိူင္တယ္။ ဒါေပမယ့္ routers ေတြ neighbors ျဖစ္ဖို့အတြတ္ သူတို့ရဲ့ OSPF Hello နဲ့ Dead intervals ေတြ တူညီရမယ္။ ဥပမာ၊ ပံုမွာ R1 သည္ Serial 0/0/0 interface ေပၚမွာ Hello interval 10 နဲ့ Dead interval 40 ကို အသံုးျပဳေနတယ္။ R2 သည္ သူ့ရဲ့ Serial 0/0/0 interface ေပၚမွာ တူညီတဲ့ intervals ေတြကို အသံုးျပဳရမွာျဖစ္ျပီး၊ အကယ္၍ ၄င္း intervals ေတြ မတူ၀ူးဆိုရင္ ၄င္း router 2 လံုးသည္ adjacency မျဖစ္ေတာ့ပါ။

OSPF (11)

2011-04-16T12:19:00.004+06:30

Duplicate Router IDs

OSPF တစ္ခုအတြင္းက router 2 လံုးမွာ router ID တူေနခဲ့ရင္ routing ကို မွန္ကန္စြာ လုပ္ေဆာင္ႏိူင္မည္ မဟုတ္ပါ။ neighboring router 2 လံုးမွာ router ID တူေနမယ္ဆိုရင္ neighbor establishment မျဖစ္ေပၚပါ။ OSPF router IDs ေတြ တူေနတဲ့အခါ IOS သည္ ေအာက္ပါ message နဲ့ သတိေပးပါလိမ့္မယ္ : %OSPF-4-DUP_RTRID1: Detected router with duplicate router ID ၄င္းအမွားကို ျပင္ဆင္ဖို့ router အသီးသီးမွာ မတူတဲ့ OSPF router IDs ေတြ စိစစ္ သတ္မွတ္ေပးပါ။ IOS version အခ်ိဳ့မွာ router-id command ကို support မလုပ္တာမို့ router ID ေတြ သတ္မွတ္ဖို့ loopback address နည္းလမ္းကို အသံုးျပဳၾကတယ္။ router ကို reload လုပ္ျပီးတဲ့ ေနာက္ loopback interface မွ IP address သည္ router ID အျဖစ္ အျမဲ ရွိေနပါလိမ့္မယ္။ ပံုမွာ router အားလံုးကို reload လုပ္ျပီးပါျပီ။ sh ip protocols command ကို အသံုးျပဳျပီး ယခုအခါ router အားလံုးမွာ router ID အတြတ္ loopback address ကို အသံုးျပဳေနျပီးျဖစ္ေၾကာင္း ၾကည့္ရွဳပါ။

OSPF (10)

2010-12-30T12:54:00.002+06:30

Loopback Address

အကယ္၍ OSPF router-id command ကို အသံုးမျပဳဘဲ loopback interface ေတြ သတ္မွတ္ထားတယ္ဆိုရင္ OSPF သည္ router ID အျဖစ္ သူ့ရဲ့ loopback interfaces မ်ားအနက္က အျမင့္ဆံုး IP address ကို ေရြးခ်ယ္လိမ့္မယ္။ loopback address သည္ virtual interface တစ္ခုျဖစ္ျပီး၊ ၄င္း ကို configure လုပ္တဲ့အခါ up state မွာ အလိုအေလ်ာက္ ရွိေနတယ္။ loopback interface ကို ေအာက္ပါ command နဲ့ configure လုပ္ႏိူင္တယ္ :

Router (config)#interface loopback number
Router (config-if)#ip address ip-address subnet-mask

ဥပမာ topology မွ router အားလံုးမွာ OSPF router IDs ေတြအျဖစ္ အသံုးျပဳႏိူင္ဖို့ loopback address ေတြ သတ္မွတ္ေပးထားတယ္။ loopback interface ကို အသံုးျပဳျခင္းရဲ့ အားသာခ်က္မွာ physical interface တစ္ခုမွာလို fail ျဖစ္တာမ်ိဳး မျဖစ္ႏိူင္ျခင္းပဲ ျဖစ္တယ္။ loopback interface သည္ configure လုပ္လိုက္ျပီဆိုထည္းက အျမဲတမ္း up ျဖစ္ေနတယ္။ ဒါ့အျပင္ သူ အျမဲ up ျဖစ္ေနဖို့ အျခား cables နဲ့ adjacent devices ေတြအေပၚ မွီွခိုေနရျခင္းမ်ိဳးလည္း မရွိပါ။ ဒါေၾကာင့္ router ID အတြတ္ loopback address ကို အသံုးျပဳျခင္းသည္ OSPF process ကို stable ျဖစ္ေစတယ္။ router-id command သည္ ေနာက္ပိုင္းမွ ထြက္ေပၚလာတဲ့ command အသစ္ျဖစ္တာမို့ ယခင္ ISO version အခ်ိဳ့မွာ support မလုပ္တာေၾကာင့္ OSPF router IDs ေတြ configure လုပ္ဖို့အတြတ္ loopback addrersses ေတြကို ပိုမို အသံုးျပဳၾကတယ္။

The OSPF router-id command

OSPF router-id command သည္ IOS 12.0(T) မွာ စတင္ ပါ၀င္လာျပီး router ID ကို ဆံုးျဖတ္တဲ့အခါ loopback နဲ့ physical interface IP address တို့အေပၚ အားသာခ်က္ ရယူတယ္။ ၄င္း command ရဲ့ syntax သည္ :

Router (config)#router ospf process-id
Router (config-router)#router-id ip-address

Modifying the Router ID

router ကို OSPF network command နဲ့ စတင္ configure လုပ္တဲ့အခါ router ID ကို ေရြးခ်ယ္တယ္။ အကယ္၍ OSPF router-id command ဒါမွမဟုတ္ loopback address ကို OSPF network command အျပီးမွာမွ configure လုပ္တယ္ဆိုရင္ physical interface တစ္ခုမွာ ရွိေနတဲ့ အျမင့္ဆံုး active IP address သည္ router ID ျဖစ္ေနလိမ့္မယ္။ ဒါေၾကာင့္ OSPF router-id command နဲ့ သတ္မွတ္ထားတဲ့ IP address ကို router ID အျဖစ္ modify လုပ္ဖို့ router ကို reload လုပ္လို့ျဖစ္ေစ ဒါမွမဟုတ္ ေအာက္ပါ command ကို အသံုးျပုလို့ ျဖစ္ေစ လုပ္ေဆာင္ရမယ္ :

Router#clear ip ospf process

Note: loopback interface ဒါမွမဟုတ္ physical interface IP အသစ္ နဲ့ router ID ကို modify လုပ္ဖို့ဆိုရင္ router ကို reload လုပ္ရမယ္။

OSPF (9)

2010-12-30T12:41:00.002+06:30

OSPF Router ID

Determining the Router ID

OSPF routing domain အတြင္းမွာ router တစ္ခုစီကို တိတိက်က် ခြဲျခားဖို့ OSPF router ID ကို အသံုးျပဳတယ္။ router ID သည္ IP address တစ္ခုသာ ျဖစ္တယ္။ Cisco သည္ router ID ကို အေနအထား 3 ခုအေပၚမွာ မူတည္ျပီး ေအာက္ပါ အစီအစဥ္အတိုင္း သတ္မွတ္တယ္ :

1. OSPF router-id command နဲ့ သတ္မွတ္ထားတဲ့ IP address ကို အသံုးျပဳတယ္။

2.router-id သတ္မွတ္မထား၀ူးဆိုရင္ router သည္ သူရဲ့ loopback interfaces မ်ားအနက္မွ အျမင့္ဆံုး IP address ကို ေရြးခ်ယ္တယ္။

3. အကယ္၍ loopback interfaces ေတြ သတ္မွတ္မထား၀ူးဆိုရင္ router သည္ သူ့ရဲ့ physical interfaces မ်ားမွာ သတ္မွတ္ထားတဲ့ IP address မ်ားအနက္မွ အျမင့္ဆံုး active IP address ကို ေရြးခ်ယ္တယ္။

Highest Active IP Address

အကယ္၍ OSPF router တစ္လံုးကို OSPF router-id command နဲ့ configure မလုပ္ထားသလို၊ loopback interfaces ေတြကိုလည္း configure မလုပ္ထား၀ူးဆိုရင္ သူ့ရဲ့ interface တစ္ခုေပၚက အျမင့္ဆံုး active IP address သည္ OSPF router ID ျဖစ္လာလိမ့္မယ္။ ၄င္း interface သည္ OSPF အတြတ္ enable လုပ္ေပးထားဖို့ မလိုအပ္ပါ။ ဆိုလိုတာက ၄င္း interface သည္ OSPF network commands မ်ားထဲမွာ ပါ၀င္ဖို့ မလိုအပ္ျခင္းပဲ ျဖစ္တယ္။ ဒါေပမယ့္ ၄င္း interface သည္ active ျဖစ္ေနရမယ္၊ up state ထဲမွာ ရွိေနရမွာ ျဖစ္တယ္။

အထက္မွာ ေဖာ္ျပခဲ့တဲ့အခ်က္ေတြကို နားလည္တယ္ဆိုရင္ R1, R2 နဲ့ R3 တို့ရဲ့ router ID ေတြကို မွန္းဆၾကည့္ပါ။

Verifying the Router ID

ဥပမာေပးထားတဲ့ router 3 ခုစလံုးမွာ router id ဒါမွမဟုတ္ loopback interface ေတြ သတ္မွတ္မေပးထားခဲ့တာမို့ ၊ router အသီးသီးအတြတ္ router id ကို ဆံုးျဖတ္ဖို့ router ရဲ့ physical interface တစ္ခုေပၚက အျမင့္ဆံုး active IP address သည္ router ID ဆိုတဲ့ နံပါတ္ 3 အခ်က္ကို အသံုးျပဳရမယ္။ ပံုမွာ ျပထားတဲ့အတိုင္းပါပဲ၊ router အသီးသီးအတြတ္ router ID မ်ားသည္ ေအာက္ပါအတိုင္း ျဖစ္တယ္ :

R1: 192.168.10.5
R2: 192.168.10.9
R3: 192.168.10.10

လက္ရွိ router ID ကို ၾကည့္ရွဳဖို့ အသံုးျပဳႏိူင္တဲ့ command တစ္ခုမွာ show ip protocols ျဖစ္တယ္။ IOS version အခ်ိဳ့မွာ ဒီ command သည္ router ID ကို မျပသပါ။ ၄င္းအေျခအေနမွာ show ip ospf ဒါမွမဟုတ္ show ospf interface command ေတြကို အသံုးျပဳျပီး router ID ကို ၾကည့္ရွဳႏိူင္တယ္။

OSPF (8)

2010-12-30T12:34:00.003+06:30

The network Command

EIGRP မွာ အသံုးျပဳတဲ့ network command သည္ အျခား IGP routing protocols မ်ားနဲ့ အသံုးျပဳတဲ့ network command နဲ့ လုပ္ေဆာင္ခ်က္ အတူတူပင္ျဖစ္တယ္ :

network command မွာ သတ္မွတ္ထားတဲ့ network address နဲ့ ကိုက္ညီတဲ့ router ရဲ့ interface အားလံုးသည္ OSPF packets ေတြကို ေပးပို့ဖို့၊ လက္ခံဖို့ enable ျဖစ္တယ္။
OSPF routing updates မ်ားမွာ ၄င္း network (subnet) ေတြ ပါ၀င္တယ္။

network command ကို router configuration mode ထဲမွာ အသံုးျပဳတယ္။

Router (config-router)#network network-address wildcard-mask area area-id

OSPF network command သည္ network-address နဲ့ wildcard-mask အတြဲကို အသံုးျပဳတယ္။ wildcard-mask ကို network address နဲ့ တြဲဖက္အသံုးျပဳျပီး OSPF အတြတ္ enable ျပဳလုပ္မယ့္ interface ဒါမွမဟုတ္ range of interfaces ေတြကို သတ္မွတ္တယ္။

wildcard mask ကို subnet mask ရဲ့ ေျပာင္းျပန္အျဖစ္ configure လုပ္ႏိူင္တယ္။ ဥပမာ R1 ရဲ့ FastEthernet 0/0 interface သည္ 172.16.1.16/28 network ေပၚမွာ ရွိတယ္။ ၄င္း interface အတြတ္ subnet mask သည္ /28 ဒါမွမဟုတ္ 255.255.255.240 ျဖစ္တယ္။ ၄င္း subnet mask ရဲ့ ေျပာင္းျပန္သည္ wildcard mask ျဖစ္တယ္။

255.255.255.255
255.255.255.240 Subtract the subnet mask
---------------------
0.0.0.15 Wildcard mask

Note: EIGRP မွာလိုပါပဲ၊ IOS version အခ်ိဳ့မွာ wildcard mask အစား subnet mask ကို ထည့္သြင္းႏိူင္တယ္။

IOS သည္ ၄င္း subnet mask ကို wildcard mask format သို့ ေျပာင္းလဲတယ္။
area area-id command သည္ OSPF area ကို ရည္ညႊန္းတယ္။ OSPF area သည္ link-state information ေတြကို share လုပ္ၾကတဲ့ router group တစ္ခုျဖစ္တယ္။ တူညီတဲ့ area အတြင္းက OSPF routers မ်ားအားလံုးရဲ့ link-state databases မ်ားထဲမွာ တူညီတဲ့ link-state information ေတြ ရွိေနရမယ္။ area အတြင္းရွိ အျခား routers မ်ားအားလံုးသို့ သူတို့ရဲ့ link-states ေတြကို flood ျပဳလုပ္ၾကျခင္းျဖင့္ အထက္ပါ ကိစၥကို ေျပလည္ေစတယ္။ ဒီသင္ခန္းစာမွာ single area တစ္ခုအတြင္းမွာ ရွိတဲ့ OSPF routers ေတြအားလံုးကို configure လုပ္မယ္။ ဒါကို single-area OSPF လို့ သိထားၾကတယ္။

OSPF network တစ္ခုကို multiple areas မ်ားစြာအျဖစ္ configure ျပုလုပ္ႏိူင္ေသးတယ္။ အရြယ္အစား ၾကီးမားတဲ့ OSPF network ကို multiple areas မ်ားအျဖစ္ configure လုပ္တဲ့အခါ အရြယ္အစား ပိုမို ေသးငယ္တဲ့ link-state databases မ်ား ရရွိျခင္း၊ unstable network ျပႆနာေတြကို isolate လုပ္ႏိူင္ျခင္း အပါအ၀င္ အျခား အားသာခ်က္မ်ားစြာ ရွိတယ္။ multi-area OSPF ကို CCNP မွာ ဆက္လက္ သင္ယူရမယ္။

router အားလံုး OSPF area တစ္ခုအတြင္းမွာ ရွိတဲ့အခါ၊ routers အားလံုးမွာ network command ကို တူညီတဲ့ area-id နဲ့ configure လုပ္ရမယ္။ area-id တစ္ခုခု ကို အသံုးျပုႏိူင္ေပမယ့္ single-area OSPF မွာ area-id 0 ကို အသံုးျပဳတာ ေကာင္းပါတယ္။ အကယ္၍ ေနာက္ပိုင္းမွာ multiple OSPF areas မ်ားစြာအျဖစ္ configure လုပ္တဲ့အခါ area 0 သည္ backbone area ျဖစ္လာျပီး configure လုပ္ရတာ ပိုမို လြယ္ကူေစတယ္။

ပံုမွာ router အားလံုးအတြတ္ network command ကို ျပသထားတယ္။ interfaces အားလံုးေပၚမွာ OSPF ကို enable လုပ္ထားတယ္။ ဒီအဆင့္အျပီးမွာ rouetr အားလံုးသည္ network အားလံုးသို့ ping ႏိူင္ ေနသင့္ပါတယ္။

OSPF (7)

2010-12-30T12:28:00.004+06:30

Lab Topology

ဒီသင္ခန္းစာအတြတ္ ဥပမာျပဳမယ့္ topology ကို ပံုမွာ ျပထားတယ္။ addressing schema သည္ discontiguous ျဖစ္တာ သတိျပဳပါ။ OSPF သည္ classless routing protocol ျဖစ္တယ္။ ဒါေၾကာင့္ OSPF ကို configure ကို လုပ္တဲ့အခါ mask ကိုလည္း configure လုပ္ရမယ္။ ဒီလိုလုပ္ေဆာင္ျခင္းျဖင့္ discontiguous addressing ျပႆနာေတြကို ေက်ာ္လႊားႏိူင္တယ္။ ဒီ topology မွာ serial links 3 ခုရဲ့ bandwidths ေတြ မတူညီတာကိုလည္း သတိျပဳပါ။ router အသီးသီးသည္ remote network အသီးသီးသို့ paths မ်ားစြာရွိေနတယ္။

The router ospf Command

OSPF ကို router ospf process-id global configuration command နဲ့ enable ျပဳလုပ္တယ္။ process-id သည္ 1 နဲ့ 65535 အတြင္း နံပါတ္တစ္ခု ျဖစ္ႏိူင္ျပီး ၄င္းကို network administrator က ေရြးခ်ယ္ သတ္မွတ္တယ္။ process-id သည္ local router အေပၚမွာသာ သက္ေရာက္မွဳ ျဖစ္တယ္၊ ဆိုလိုတာက neighbor routers မ်ားနဲ့ adjacencies establish လုပ္ဖို့ ၄င္း process-id တူညီဖို့ မလိုအပ္ပါ။ ၄င္းအခ်က္သည္ EIGRP နဲ့ ျခားနားတယ္။ EIGRP neighbors 2 ခု adjacent ျဖစ္ဖို့ EIGRP process ID ဒါမွမဟုတ္ autonomous system number တူညီဖို့ လိုအပ္တယ္။

ယခု ဥပမာ topology ရဲ့ router အားလံုးမွာ process id 1 ကို အသံုးျပဳျပီး OSPF ကို enable လုပ္ပါမယ္။ consistency အတြတ္ တူညီတဲ့ process ID ကို အသံုးျပဳျခင္းမွ်သာ ျဖစ္တယ္။ ၄င္းထက္ ပိုတဲ့ ရည္ရြယ္ခ်က္ မရွိပါ။

R1 (config)#router ospf 1
R1 (config-router)#

OSPF (6)

2010-12-30T12:20:00.003+06:30

Administrative Distance

administrative distance (AD) သည္ route source ရဲ့ trustworthiness (preference) ျဖစ္တယ္။ OSPF မွာ administrative distance 110 ျဖစ္တယ္။ ပံုမွာျပထားတဲ့အတိုင္း OSPF ကို အျခား interior gateway protocols (IGPs) ေတြနဲ့ ႏွိဳင္းယွဥ္တဲ့အခါ IS-IS နဲ့ RIP တို့ထက္ prefer ျဖစ္တာ ေတြ့ရမယ္။

Authentication

အျခား routing protocols မ်ားလိုပဲ OSPF ကို authentication အတြတ္ configure ျပဳလုပ္ႏိူင္တယ္။
transmit လုပ္မယ့္ routing information ေတြကို authenticate ျပဳလုပ္ျခင္းသည္ အေလ့အက်င့္ေကာင္း တစ္ခုျဖစ္တယ္။ RIPV2, EIGRP, OSPF, IS-IS နဲ့ BGP တို့သည္ သူတို့ရဲ့ routing information ေတြကို encrypt နဲ့ authenticate လုပ္ဖို့ configure ျပဳလုပ္ႏိူင္တယ္။ ၄င္း လုပ္ေဆာင္ခ်က္သည္ routers မ်ားကို တူညီတဲ့ password ဒါမွမဟုတ္ authentication information မ်ားနဲ့ configure လုပ္ထားတဲ့ အျခား routers မ်ားမွ routing information ေတြကိုသာ လက္ခံယူေစတယ္။

Note: authentication သည္ router ရဲ့ routing table ကို encrypt မလုပ္ပါ။

OSPF (5)

2010-12-30T11:52:00.003+06:30

Electing a DR and BDR

multi-access networks မ်ားေပၚမွာ OSPF traffic ပမာဏကို ေလ်ာ့ခ်ဖို့ OSPF သည္ Designated Router (DR) နဲ့ Backup Designated Router (BDR) ေတြကို elect လုပ္တယ္။ multi-access network အတြင္းမွာ အေျပာင္းအလဲ တစ္ခုျဖစ္ေပၚတဲ့အခါ DR သည္ အျခား router (DROthers) အားလံုးကို ၄င္း အေျပာင္းအလဲအတြတ္ update ျပုလုပ္ဖို့ တာ၀န္ယူ လုပ္ေဆာင္ရတယ္။ BDR သည္ DR ကို monitor လုပ္ေနျပီး အကယ္၍ DR “fail” ျဖစ္သြားတဲ့အခါ DR အျဖစ္ လုပ္ေဆာင္တယ္။

ပံုမွာ R1,R2 နဲ့ R3 တို့ကို point-to-point links နဲ့ ခ်ိတ္ဆက္ထားတယ္။ ဒါေၾကာင့္ DR/BDR election မျဖစ္ေပၚပါ။ DR/BDR election process ကို ေနာက္ပိုင္း သင္ခန္းစာမွာ ဆက္လက္ေဆြးေႏြးမယ္။
Note: Hello packet နဲ့ အျခား OSPF packets မ်ားအေၾကာင္း CCNP မွာ အေသးစိတ္ ဆက္လက္ ေဆြးေႏြးတယ္။

OSPF Link-state Updates
Link-state updates (LSUs) သည္ OSPF routing updates ေတြအတြတ္ အသံုးျပဳတဲ့ packets ေတြ ျဖစ္တယ္။ ပံုမွာ ျပထားတဲ့အတိုင္း LSU packet တစ္ခုမွာ Link-State Advertisements (LSAs) အမ်ိဳးအစားကြဲ 10 ခုအထိ ပါ၀င္ႏိူင္တယ္။ Link-State Advertisements (LSAs) နဲ့ Link-State Update (LSUs) အသံုးအႏွံဳးသည္ တစ္ခါတရံမွာ ေရာေထြးမွဳေတြ ျဖစ္ေစႏိူင္တယ္။ အေျခအေန အမ်ားစုမွာ ၄င္း အသံုးအႏွံဳး 2 ခုကို အျပန္အလွန္ ေျပာင္းလဲအသံုးျပဳႏိူင္တယ္။ LSU တစ္ခုမွာ LSAs တစ္ခုထက္မက ပါ၀င္ျပီး OSPF routers ေတြအၾကား လက္လႊဲရယူၾကတဲ့ link-state information ေတြကို ရည္ညႊန္း ေဖာ္ျပဖို့ မည္သည့္ အသံုးအနွံဳးကိုမဆို အသံုးျပုႏိူင္တယ္။

Note: LSAs အမ်ိဳးအစားမ်ားနဲ့ ပက္သက္ျပီး CCNP မွာ ဆက္လက္ သင္ယူရမယ္။

OSPF Algorithm

OSPF router အသီးသီးသည္ link-state database တစ္ခုစီကို maintain လုပ္ထားၾကတယ္။ ၄င္း link-state database မွာ အျခား routers အားလံုးမွ LSAs မ်ား ပါ၀င္တယ္။ router သည္ LSAs အားလံုးကို လက္ခံရယူျပီးတဲ့အခါ သူ့ရဲ့ local link-state database ကို တည္ေဆာက္တယ္၊ Diijkastra ရဲ့ short path first (SPF) alogorithm ကို အသံုးျပဳျပီး SPF tree တစ္ခုကို တည္ေဆာက္တယ္၊ ၄င္း SPF tree ကို အသံုးျပဳျပီး network အသီးသီးသို့ ေရာက္ရွိမယ့္ best paths ေတြ ပါ၀င္တဲ့ IP routing table ကို တည္ေဆာက္တယ္။

OSPF (4)

2010-12-30T11:41:00.003+06:30

Hello Protocol

Neighbor Establishment

OSPF router တစ္လံုးသည္ သူ့ရဲ့ link-ststes ေတြကို အျခား routers မ်ားသို့ flood မလုပ္မွီ၊ သူ့မွာ ရွိေနတဲ့ links ေတြေပၚမွာ အျခား OSPF neighbors ေတြ ရွိေနသလား ပထမ ဆံုးျဖတ္တယ္။ ပံုမွာ OSPF routers ေတြသည္ Hello packets ေတြကို OSPF-enabled interfaces မ်ားေပၚသို့ ပို့လႊတ္ျပီး ၄င္း links မ်ားေပၚမွာ neighbors ေတြ ရွိေနသလား ဆံုးျဖတ္တယ္။ OSPF Hello ထဲမွာ ပို့လႊတ္လိုက္တဲ့ router ရဲ့ OSPF Router ID ပါ၀င္တယ္။ OSPF Hello packet ကို interface တစ္ခုေပၚမွာ လက္ခံရရွိသြားတဲ့ router သည္ link ေပၚမွာ အျခား OSPF router ရွိေနတယ္လို့ သိရွိသြားတယ္။ ၄င္းေနာက္မွာ OSPF သည္ neighbor နဲ့ adjacency establish ျပုလုပ္တယ္။ ပံုမွာ R1 သည္ R2 နဲ့ R3 နဲ့အတူ adjancency establish ျပုလုပ္တယ္။

OSPF Hello and Dead Intervals

router 2 လံုး OSPF neighbor adjacency မျဖစ္မွီ အခ်က္ 3 ခ်က္အေပၚ လံုး၀ သေဘာတူရမယ္ : Hello interval, Dead interval နဲ့ network type ။ OSPF Hello interval သည္ OSPF router တစ္လံုးက သူ့ရဲ့ Hello packets ေတြကို အခ်ိန္ ဘယ္ေလာက္အၾကာမွာတစ္ခါ transmit လုပ္မလဲဆိုတာကို ေဖာ္ျပတယ္။ default အရ multi-access နဲ့ point-to-point segments ေတြေပၚမွာ 10 seconds တစ္ခါ transmit လုပ္ျပီး၊ Frame Relay,X.25 နဲ့ ATM တို့လို non-broadcast multi-access (NBMA) ေတြေပၚမွာ 30 seconds တစ္ခါ transmit လုပ္တယ္။

အေျခအေန အမ်ားစုမွာ OSPF Hello packets ေတြကို multicast (224.0.0.5) အျဖစ္ ထုတ္လႊတ္တယ္။ multicast address ကို အသံုးျပဳျခင္းျဖင့္ OSPF packets ေတြကို လက္ခံဖို့ enable မလုပ္ထားတဲ့ interfaces ေတြသည္ ၄င္း packet ကို ignore လုပ္ႏိူင္တာမို့ CPU processing အတြတ္ အခ်ိန္ကုန္ သက္သာေစတယ္။

Dead interval သည္ seconds နဲ့ သတ္မွတ္ေဖာ္ျပတဲ့ အခ်ိန္ အပိုင္းအျခား တစ္ခုျဖစ္တယ္။ neighbor တစ္ခု “Down” သြားေၾကာင္း declar မလုပ္မွီ Hello packet တစ္ခုကို လက္ခံရယူဖို့ router က ေစာင့္ရတဲ့အခ်ိန္ျဖစ္တယ္။ Cisco သည္ Hello interval ရဲ့ 4 ဆ ကို default Dead interval အျဖစ္ အသံုးျပဳတယ္။ multi-access နဲ့ point-to-point segments ေတြအတြတ္ 40 seconds ျဖစ္ျပီး NBMA networks မ်ားအတြတ္ 120 seconds ျဖစ္တယ္။

router သည္ Hello packet ကို လက္ခံမရရွိမွီ Dead interval ကုန္ဆံုးသြားတယ္ဆိုရင္ OSPF သည္ ၄င္း neighbor ကို link-state database မွ ဖယ္ရွားလိမ့္မယ္။ “down” သြားတဲ့ neighbor နဲ့ ပက္သက္တဲ့ link-state information ေတြကို router သည္ သူ့ရဲ့ OSPF enabled interfaces မ်ားသို့ flood လုပ္တယ္။

Network types မ်ားကို ေနာက္ သင္ခန္းစာမွာ ေဆြးေႏြးပါမယ္။

OSPF (3)

2010-12-30T11:29:00.003+06:30

Hello Protocol

ပံုမွာ OSPF packet header နဲ့ Hello packet တို့ကို ျပသထားတယ္။ အျပာေရာင္ခ်ယ္ထားတဲ့ အပိုင္းေတြကို ေနာက္ သင္ခန္းစာမ်ားမွာ အက်ယ္ ဆက္လက္ေဆြးေႏြးမွာျဖစ္ျပီး၊ ယခုေလာေလာဆယ္ Hello packet အသံုးျပဳပံုအေပၚမွာ focus လုပ္ၾကပါစို့။

OSPF packet Type 1 သည္ OSPF Hello packet ျဖစ္တယ္။ Hello packets ေတြကို :

OSPF neighbors ေတြကို discover လုပ္ဖို့ နဲ့ neighbor adjacencies ေတြ establish လုပ္ဖို့ အသံုးျပဳတယ္။
parameters ေတြကို advertise ျပဳလုပ္ဖို့ အသံုးျပဳတယ္။
၄င္း parameters မ်ားအေပၚမွာ လံုး၀ သေဘာတူညီမွသာ routers 2 လံုး neighbors ျဖစ္မယ္။
Ethernet နဲ့ Frame Relay တို့လို multi-access networks မ်ားမွာ DR (Designated Router ) နဲ့ BDR (Backup Designated Router) ေတြကို ေရြးခ်ယ္ဖို့ အသံုးျပဳတယ္။

ပံုမွာ ျပသထားတဲ့ အေရးၾကီးတဲ့ fields ေတြမွာ :

Type
OSPF Packet Type : Hello (1), DD (2), LS Request (3), LS Update (4), LS ACK (5)
Router ID
packet ကို ထုတ္လႊတ္တဲ့ router ရဲ့ ID
Area ID
packet ရဲ့ မူလ area
Network Mask
sending interface ရဲ့ subnet mask
Hello Interval
Hello တစ္ခု နဲ့ တစ္ခုၾကား ၾကာတဲ့ seconds အေရအတြတ္
Router Priority
DR/BDR ေရြးခ်ယ္ရာမွာ အသံုးျပဳတယ္ (ေနာက္ သင္ခန္းစာမ်ားမွာ ဆက္လက္ေဆြးေနြးမယ္)
Designated Router (DR)
DR ရဲ့ Router ID
Backup Designated Router (BDR)
BDR ရဲ့ Router ID
List of Neighbors
neighboring routers မ်ားရဲ့ OSPF Router ID

OSPF (2)

2010-12-30T11:22:00.001+06:30

OSPF Packet Types

OSPF LSPs အမ်ိဳးအစား 5 ခု ရွိတယ္။ ၄င္း packet အသီးသီးသည္ OSPF routing process မွာ တိက်တဲ့ လုပ္ေဆာင္ခ်က္ေတြ ကို ေဆာင္ရြက္တယ္ :

1. Hello
hello packets ေတြကို အျခား OSPF routers ေတြနဲ့ အဆက္အသြယ္လုပ္ဖို့၊ ၄င္း အဆက္အသြယ္ကို ထိန္းသိမ္းထားဖို့ အသံုးျပဳတယ္ (establish and maintain adjacency) ။ hello packet နဲ့ ပက္သက္ျပီး ေနာက္အပိုင္းမွာ အက်ယ္ ထပ္မံေဆြးေႏြးမယ္။

2. DBD
Database Description (DBD) packet မွာ ဒီ packet ကို ေပးပို့လိုက္တဲ့ router ရဲ့ link-state database အက်ဥ္းခ်ဳပ္ ပါ၀င္တယ္။ ၄င္း packet ကို လက္ခံရရွိတဲ့ router သည္ သူရဲ့ local link-state database နဲ့ တိုက္ဆိုင္ စစ္ေဆးတယ္။

3. LSR
လက္ခံရယူတဲ့ router သည္ DBD ထဲက entry တစ္ခုအတြတ္ ပိုမိုျပည့္စံုတဲ့ အခ်က္အလက္ေတြကို ေတာင္းခံဖို့ LSR (Link-State Request) ကို အသံုးျပဳတယ္။

4. LSU
LSRs ေတြကို reply လုပ္ဖို့ နဲ့ information အသစ္ေတြကို announce လုပ္ဖို့ LSU (Link-State Update) packets ေတြကို အသံုးျပဳတယ္။ LSU မွာ မတူျခားနားတဲ့ LSAs (Link-State Advertisements) types 7 ခုပါ၀င္တယ္။ LSUs နဲ့ LSAs တို့နဲ့ ပက္သက္ျပီး ေနာက္ သင္ခန္းစာမွာ အက်ဥ္းခ်ံု့ ေဆြးေႏြးမယ္။

5. LSAck
LSU ကို လက္ခံရရွိေၾကာင္း confirm လုပ္ဖို့ LSAck (Link-State Acknowledgement) ကို အသံုးျပဳတယ္။

OSPF (1)

2010-12-30T10:29:00.004+06:30

OSPF သည္ distance vector routing protocol ျဖစ္တဲ့ RIP ကို အစားထိုးဖို့အတြတ္ ထြက္ေပၚလာတဲ့ link-state routing protocol ျဖစ္တယ္။ အင္တာနက္ နဲ့ Network ေခတ္ဦးကာလမွာ RIP ကို အသံုးျပဳလို့ ေကာင္းခဲ့ေပမယ့္ ၊ best route ကို ေရြးခ်ယ္ဖို့ hop count တစ္ခုထည္းအေပၚမွာသာ လံုး၀မွီခိုတာေၾကာင့္ ေနာက္ပိုင္းကာလမွာ ထြက္ေပၚလာတဲ့ အရမ္းၾကီးတဲ့ networks ေတြမွာ RIP ကို အသံုးျပဳဖို့ အခက္အခဲေတြ ရွိလာတယ္။

OSPF သည္ scalability အတြတ္ area အယူအဆကို အသံုးျပဳထားတဲ့ classless routing protocol တစ္ခုျဖစ္တယ္။ OSPF မွာ metric ကို cost လို့ ေခၚေ၀ၚသတ္မွတ္ထားတယ္ (RFC 2328) ။ Cisco IOS သည္ bandwidth ကို OSPF cost metric အျဖစ္ အသံုးျပဳ တြတ္ခ်က္တယ္။

RIP အေပၚ OSPF ရဲ့ အဓိက အားသာခ်က္သည္ fast convergence ျဖစ္ျခင္းနဲ့ ၊ larger network implementations မ်ားမွာ scalability ျဖစ္ျခင္း တို့ ျဖစ္တယ္။ OSPF Message Encapsulation
OSPF message ရဲ့ data အပိုင္းကို packet တစ္ခုထဲမွာ encapsulate လုပ္ထားတယ္။ ၄င္း data field ထဲမွာ OSPF packet type တစ္ခု ပါ၀င္တယ္။ ေနာက္လာမယ့္ သင္ခန္းစာမွာ ဒီ packet types 5 ခုနဲ့ ပက္သက္ျပီး ဆက္လက္ေဆြးေႏြးမယ္။

OSPF packet တိုင္းမွာ packet hader ပါ၀င္တယ္။ ၄င္းေနာက္မွာ packet header နဲ့ packet type-specific data ေတြကို IP packet ထဲမွာ encapsulate လုပ္တယ္။ packet header ထဲမွာ protocol field သည္ OSPF ကို ရည္ညႊန္း ေဖာ္ျပတဲ့ 89 ျဖစ္မယ္။ destination address သည္ ေအာက္ပါ multicast address 2 ခု အနက္ တစ္ခုျဖစ္မယ္ : 224.0.0.5 ဒါမွမဟုတ္ 224.0.0.6။ အကယ္၍ OSPF packet ကို Ethernet frame ထဲမွာ encapsulate လုပ္မယ္ဆိုရင္ destination address သည္ 01-00-5E-00-00-05 ဒါမွမဟုတ္ 01-00-5E-00-00-06 ျဖစ္မယ္။ (ဒီအပိုင္းကို နားလည္ဖို့ OSI Reference Model ရဲ့ ေအာက္ ၄ လႊာကို နားလည္ေနဖို့ လိုအပ္ပါတယ္) ။

Chapter 22: Access Control Lists (13)

2010-09-11T23:11:00.004+06:30

Standard IP ACL Examples

ယခုအခါ standard numbered IP ACL တစ္ခုကို create ျပုလုပ္ဖို့ နဲ့ activate ျပုလုပ္ရာမွာ အသံုးျပဳတဲ့ အေျခခံ commands 2 ခုကို ေဆြးေႏြးခဲ့ျပီး ျပီ။ ပိုမို နားလည္သေဘာေပါက္ေစဖို့ ဥပမာအခ်ိဳ့ကို ၾကည့္ၾကပါဦးစို့ :

Router (config) # access-list 1 permit 192.169.1.1
Router (config) # access-list 1 deny 192.168.1.2
Router (config) # access-list 1 permit 192.168.1.0 0.0.0.255
Router (config) # access-list 1 deny any
Router (config) # interface serial 0
Router (config-if) # ip access-group 1 in

ဒီဥပမာမွာ ACL#1 ထဲက ပထမ statement သည္ ၊ permit action ကို execute လုပ္ဖို့အတြတ္ဆုိရင္ IP packet မွာ source address 192.168.1.1 ပါရွိရမယ္ လို့ ေျပာဆိုတယ္။ အကယ္၍ အဲလိုမွ မဟုတ္ရင္ IOS သည္ ဒုတိယ statement ကို proceed လုပ္တယ္။ အကယ္၍ standard ACL တစ္ခုမွာ wildcard mask ကို ခ်န္လွပ္မယ္ဆိုရင္ သူ့ရဲ့ default သည္ 0.0.0.0 ျဖစ္တယ္ ဆိုတာ သတိရပါ (ACL statement ထဲမွာ သတ္မွတ္ထားတဲ့ address နဲ့ အတိအက် ကိုက္ညီရမွာ ျဖစ္တယ္)။ ဒုတိယ ACL statement သည္ ၊ deny action ကို လုပ္ေဆာင္ဖို့ အတြတ္ဆိုရင္ IP packet မွာ source address 192.168.1.2 ပါရွိရမယ္ လို့ ေျပာဆိုတယ္။ အကယ္၍ မပါရွိခဲ့ရင္ IOS သည္ တတိယ statement ကို proceed လုပ္တယ္။ တတိယ ACL statement သည္ ၊ permit action ကို လုပ္ေဆာင္ဖို့အတြတ္ဆိုရင္ IP packet မွာ 192.198.1.0 နဲ့ 192.168.1.255 အၾကား source address တစ္ခု ပါရွိရမယ္ လို့ ေျပာဆိုတယ္။ အကယ္၍ မပါရွိခဲ့ရင္ စတုတၱ ACL statement ကို proceed လုပ္တယ္။ တကယ္တမ္းမွာ စတုတၱ statement မလိုအပ္ပါ၀ူး : ၄င္း statement သည္ မည္သည့္ packet ကိုမဆို drop လုပ္မွာျဖစ္တယ္။ ACL အသီးသီးရဲ့ အဆံုးမွာ invisible implicit deny statement တစ္ခု ျဖစ္ေပၚမွာမို့ စတုတၱ statement မလိုအပ္ပါ။ ACL ဥပမာအတြင္းမွ ေနာက္ဆံုး commands 2 ခုသည္ ACL#1 ကို serial0 ေပၚမွာ activate လုပ္တယ္။

တကယ္တမ္းမွာ အထက္မွာ ဥပမာျပခဲ့တဲ့ ACL ကို ေအာက္ပါအတိုင္း ေရးသားသင့္တယ္ :

Router (config) # access-list 1 deny 192.168.1.2
Router (config) # access-list 1 permit 192.168.1.0 0.0.0.255
Router (config) # interface serial 0
Router (config-if) # ip access-group 1 in

အထက္က ဒုတိယ ဥပမာသည္ ပထမ ဥပမာ မွ ACL statements 4 ခုကို 2 ခုသို့ ေလ်ာ့ခ်လိုက္တာ ေတြ့ရမယ္။

standard ACL ေနာက္ထပ္ ဥပမာတစ္ခုကို ၾကည့္ၾကပါဦးစို့ :

Router (config) # access-list 2 deny 192.168.1.0
Router (config) # access-list 2 deny 172.16.0.0
Router (config) # access-list 2 permit 192.168.1.1
Router (config) # access-list 2 permit 0.0.0.0 255.255.255.255
Router (config) # interface ethernet 0
Router (config-if) # ip access-group 1 out

ဒီဥပမာမွာ ျပႆနာအခ်ိဳ့ ရွိေနတယ္။ ေသေသခ်ာခ်ာ ၾကည့္ျပီး စစ္ေဆးၾကပါစို့။

ပထမ ACL statement သည္ 192.168.1.0/24 မွ traffic အားလံုးကို deny လုပ္မယ့္ဟန္ရွိတယ္။ တကယ္စင္စစ္မွာ ၄င္း statement သည္ မည္သည့္ လုပ္ေဆာင္ခ်က္ တစ္ခုကိုမွ ေဆာင္ရြက္ႏိူင္မည္ မဟုတ္ပါ။ address အတြတ္ wildcard mask ကို ခ်န္လွပ္မယ္ဆိုရင္ ၄င္းရဲ့ default သည္ 0.0.0.0 ျဖစ္တယ္ဆိုတာ သတိရပါ။ ျပႆနာမွာ source address 192.168.1.0 သည္ host address မဟုတ္ဘဲ network number တစ္ခုျဖစ္ေနတာမို့ source address 192.168.1.0 နဲ့ packet ဆိုတာ ဘယ္ေတာ့မွ ရွိလိမ့္မည္ မဟုတ္ပါ။ ဒုတိယ statement သည္လည္း ထိုနည္းတူပင္ျဖစ္တယ္။ တတိယ နဲ့ စတုတၱ statements မ်ားကေတာ့ ok ပါတယ္။

ACLs ေတြကို configure လုပ္ရာမွာ အလွည့္အေျပာင္းေလးေတြ ျပုလုပ္ႏိူင္တယ္။ ဒါေၾကာင့္ အထက္က ဥပမာ ရဲ့ configuration ကို ေအာက္ပါအတိုင္း update လုပ္ပါမယ္ :

Router (config) # access-list 2 deny 192.168.1.0 0.0.0.255
Router (c0nfig) # access-list 2 deny 172.16.0.0 0.0.255.255
Router (config) # access-list 2 permit 192.168.1.1
Router (config) # access-list 2 permit 0.0.0.0 255.255.255.255
Router (config) # interface ethernet 0
Router (c0nfig-if) # ip access-group 1 out

ဒီ ဥပမာမွာ ယခုအခါ ပထမ statement သည္ network 192.168.1.0/24 မွ source address တစ္ခုပါတဲ့ မည္သည့္ packet ကိုမဆို drop လုပ္ပါလို့ ေျပာတယ္။ ဒုတိယ statement သည္ class B network 172.16.0.0/16 မွ မည္သည့္ traffic ကိုမဆို drop လုပ္လိမ့္မယ္။ တတိယ statement သည္ 192.168.1.1 မွ traffic ကို permit လုပ္လိမ့္မယ္။ စတုတၱ statement သည္ မည္သည့္ address မွ traffic ကိုမဆို permit လုပ္လိမ့္မယ္။ အမွန္စင္စစ္ ဒီ configuration မွာ ျပႆနာတစ္ခု ရွိေနဆဲျဖစ္တယ္ : ပထမ နဲ့ တတိယ statement ကို ၾကည့္ပါ။ တတိယ statement သည္ မည္သည့္အခါမွ execute လုပ္ခံရလိမ့္မည္ မဟုတ္ပါ ဒီအေျခအေနမွာ ပိုမိုတိက်တဲ့ entry ကို တိက်မွဳ နည္းတဲ့ entry ရဲ့ အရင္ ၊ ေရွ့မွာ ေနရာခ်ဖို့ လိုအပ္တယ္။ အျခား ေသးေသးမႊားမႊား ျပႆနာတစ္ခုမွာ စတုတၱ statement ရဲ့ address ကို keyword any အျဖစ္ ကုိယ္စားျပဳ ေဖာ္ျပႏိူင္ျခင္း ျဖစ္တယ္။ ေအာက္မွာ update ျပုလုပ္လိုက္တဲ့ configuration ကို ေဖာ္ျပထားတယ္ :

Router (config) # access-list 2 permit 192.168.1.1
Router (config) # access-list 2 deny 192.168.1.0 0.0.0.255
Router (config) # access-list 2 deny 172.16.0.0 0.0.255.255
Router (config) # access-list 2 permit any
Router (config) # interface ethernet 0
Router (config-if) # ip access-group 1 out

ဒီမွာ ျပႆနာတစ္ခု ရွိေနပါေသးတယ္။ create လုပ္လိုက္တဲ့ ACL မွာ number 2 ျဖစ္ေနျပီး interface ေပၚမွာ activate လုပ္ထားတဲ့ ACL မွာ number 1 ျဖစ္ေနတာ သတိျပဳမိမယ္ ထင္ပါတယ္။ ဒါကို ေျဖရွင္းဖို့အတြတ္ ေအာက္ပါ configuration ကို အသံုးျပဳပါ :

Router (config) # interface ethernet 0
Router (config) # no ip access-group 1 out
Router (config) # ip access-group 2 out

ACL အသစ္ကို apply မလုပ္မွီ ၊ ပထမဦးစြာ ACL အေဟာင္းကို interface မွ ဖယ္ရွားရမယ္ ဆိုတာကို မွတ္သားပါ။

exam watch!
list အတြင္းရွိ statements အစီအစဥ္ကို စစ္ေဆးျခင္းျဖင့္ ACL configuration ကို troubleshoot လုပ္ႏိူင္ရမယ္။

Chapter 22: Access Control Lists (12)

2010-09-11T13:55:00.003+06:30

ACL Types

ဒီသင္ခန္းစာမွာ numbered နဲ့ named ACLs ႏွစ္ခုစလံုးရဲ့ configuration ကို ေဆြးေႏြးသြားမွာ ျဖစ္တယ္။ ပထမပိုင္းမွာ numbered standard နဲ့ extended ACLs ေတြ configuration ျပုလုပ္ျခင္း ကို ေဆြးေႏြးမွာ ျဖစ္ျပီး ဒုတိယပိုင္းမွာ named ACLs ေတြ configuration ျပုလုပ္ျခင္းကို ေဆြးေနြးပါမယ္။ ေနာက္ဆံုးမွာ IOS device ရဲ့ CLI မွတဆင့္ edit ျပုလုပ္ႏိူင္တဲ့ sequenced ACLs လို့ အမည္ရတဲ့ feature တစ္ခုအေၾကာင္းကို မိတ္ဆက္ေဆြးေႏြးသြားပါမယ္။

Standard Numbered ACLs

standard IP ACLs ေတြကို configure လုပ္ဖို့ ရိုးရွင္း လြယ္ကူတယ္။ standard IP ACLs ေတြသည္ IP packet တစ္ခုအတြင္းက source IP address အေပၚမွာသာ filter ျပုလုပ္တယ္။ standard numbered IP ACL တစ္ခုအတြင္း entry တစ္ခုကို create လုပ္ဖို့ ေအာက္ပါ command ကို အသံုးျပဳပါ :

Router (config) # access-list 1-99 | 1300-1999 permit | deny
source_IP_address
[wildcard_mask] [log]

standard numbered IP ACL တစ္ခုမွာ 1-99 နဲ့ 1300-1999 အထိ နံပါတ္ေတြကို အသံုးျပဳႏိူင္တယ္။ condition ေပၚမွာ match ျဖစ္တယ္ဆိုရင္ router လုပ္ေဆာင္ရမယ့္ action ကို access-list number ရဲ့ ေနာက္မွာ ထည့္သြင္းတယ္။ condition သည္ source IP address အေပၚမွာ လံုးလံုးလ်ားလ်ား အေျခခံတယ္။ condition ရဲ့ ေနာက္မွာ wildcard mask ကို လိုအပ္ပါက ထည့္သြင္းႏိူင္တယ္။ အကယ္၍ wildcard mask ကို မထည့္သြင္းဘဲ ခ်န္လွပ္ထားခဲ့မယ္ဆိုရင္ default သည္ 0.0.0.0 ျဖစ္မယ္ -- action ကို execute လုပ္ဖို့ တိက်တဲ့ match တစ္ခု လိုအပ္မယ္။

exam watch!
standard ACL တစ္ခုရဲ့ syntax ကို ကြ်မ္းက်င္ေနပါေစ။ packet ထဲက source addresses ေတြအေပၚမွာသာ filter ျပုလုပ္ႏိူင္တယ္ဆိုတာကိုလည္း မွတ္သားပါ။ standard ACL တစ္ခုအတြင္းမွာ wildcard mask ကို မထည့္သြင္းဘဲ ခ်န္လွပ္ခဲ့မယ္ဆိုရင္ default သည္ 0.0.0.0 ျဖစ္တယ္ (တိက်တဲ့ match တစ္ခု လိုအပ္တယ္)။

၄င္းရဲ့ ေနာက္မွာ log parameter ကို လိုအပ္တယ္ဆို ထည့္သြင္းႏိူင္တယ္။ ၄င္းသည္ IOS 12.0 မွာ ပါ၀င္လာတဲ့ standard ACLs ရဲ့ parameter အသစ္ျဖစ္တယ္။ ၄င္း parameter သည္ router ရဲ့ console port သို့ statement နဲ့ match ျဖစ္တာေတြကို print ျပုလုပ္တယ္။ ေအာက္ပါ command ကို execute မလုပ္လွ်င္ default မွာ ၄င္း messages ေတြသည္ IOS device သို့ ခ်ိတ္ဆက္ထားတဲ့ non-console port ေပၚမွာ မေပၚပါ :
Router# terminal monitor

on the job!
terminal monitor command သည္ current session အတြတ္သာ ျဖစ္တယ္ : log out လုပ္ျပီးေနာက္ IOS device သို့ log on ျပန္၀င္တဲ့အခါ ၊ VTY ဒါမွမဟုတ္ TYY session ေပၚမွာ output ကို ျမင္ေတြ့ရဖို့ ဒီ command ကို တဖန္ျပန္ execute လုပ္ေပးဖို့ လိုအပ္တယ္။

၄င္း ACL logging messages ေတြကို syslog server သို့လည္း forward ျပုလုပ္ႏိူင္တယ္။ ထိုသို့ ျပုလုပ္ျခင္းသည္ debugging နဲ့ security အတြတ္ အသံုး၀င္တယ္။ ACL ကို create လုပ္ျပီးတဲ့အခါ ip access-group ACL_# in|out command ကို အသံုးျပဳျပီး interface တစ္ခုအေပၚမွာ ၄င္းကို activate ျပဳလုပ္ႏိူင္တယ္။

Chapter 22: Access Control Lists (11)

2010-09-10T19:38:00.003+06:30

Activating an ACL

IP ACL ကို တည္ေဆာက္ျပီးတဲ့ေနာက္ IOS ရဲ့ process တစ္ခုသို့ apply ျပုလုပ္မွသာ ၄င္း ACL သက္၀င္ လွဳပ္ရွားပါတယ္။ ဒီသင္ခန္းစာမွာ interfaces မ်ားကို ျဖတ္သန္းတဲ့ traffic ေတြကို filtering ျပဳလုပ္ျခင္းအေပၚမွာ အဓိကထား ေဆြးေႏြးမွာ ျဖစ္တယ္။ ဒါေၾကာင့္ ၊ interfaces မ်ားအၾကား traffic ေတြကို IOS က filter ျပဳလုပ္ဖို့ ၊ သင့္ေလ်ာ္တဲ့ interface တစ္ခု ဒါမွမဟုတ္ interfaces မ်ားကို ထည့္သြင္းေပးရမွာျဖစ္ျပီး ၊ ACL ကို activate ျပုလုပ္ေပးရမွာျဖစ္တယ္။ interface တစ္ခုေပၚမွာ ACL ကို activate လုပ္ဖို့ ေအာက္ပါ command ကို အသံုးျပဳတယ္ :

Router (config) # interface type [slot_#]port_#
Router (config-if) # ip access-group ACL_# in|out

ip access-group command ရဲ့ အဆံုးမွာ မိမိ activate ျပုလုပ္လိုတဲ့ ACL နဲ့ ၊ ၄င္း ACL ကို မည္သည့္ direction အတြတ္ျဖစ္တယ္ ဆိုတာကို သတ္မွတ္ေပးရမယ္ :

in interface ထဲသို့ traffic ၀င္ေရာက္လာတဲ့အခါ
out interface မွ traffic ထြက္ခြာသြားတဲ့အခါ

ACL တစ္ခုကို router တစ္လံုးရဲ့ interfaces မ်ားစြာမွာ apply ျပုလုပ္ႏိူင္တယ္၊ ဒါမွမဟုတ္ ACL တစ္ခုကို interface တစ္ခုမွာ inbound နဲ့ outbound အျဖစ္ ၂ ၾကိမ္ activate ျပုလုပ္ႏိူင္တယ္ဆိုတာ မွတ္သားပါ။ statement တစ္ခုမွမပါရွိတဲ့ ACL အခြံတစ္ခုကိုေတာင္ interface တစ္ခုသို့ apply ျပုလုပ္ႏိူင္ပါတယ္။ statement တစ္ခုမွ မပါရွိတဲ့ ACL အခြံတစ္ခုသည္ traffic အားလံုးကို permit လုပ္လိမ့္မယ္။ ACL မွာ implicit deny ရွိဖို့အတြတ္ အနည္းဆံုး permit ဒါမွမဟုတ္ deny statement တစ္ခုရွိဖို့ လိုအပ္တယ္။ ACL အခြံတစ္ခုကို router ရဲ့ interface တစ္ခုသို့ apply မလုပ္ဖို့ တိတိက်က် အၾကံျပဳလိုပါတယ္။ ၄င္းအေျခအေနမွာ၊ list အတြင္း ပထမဦးဆံုး statement ကို create လုပ္လိုက္တဲ့အခါ implicit deny သည္ list ရဲ့ ေအာက္ဆံုးမွာ အလိုအေလ်ာက္ ရွိလာမွာျဖစ္ျပီး router အတြတ္ reachability ျပႆနာေတြ ျဖစ္ေစႏိူင္ပါတယ္။

ACL အခြံတစ္ခုပါရွိတဲ့ ဥပမာတစ္ခုကို ၾကည့္ျပီး ၄င္းမွာေတြ့ၾကံုရႏိူင္တဲ့ ျပႆနာေတြကို ဆန္းစစ္ၾကည့္ၾကပါစို့။ router တစ္လံုးရဲ့ ethernet0 interface သို့ ACL (#10) တစ္ခုကို apply ျပုလုပ္ထားျပီး ယခုေလာေလာဆယ္ ၄င္း ACL မွာ permit ဒါမွမဟုတ္ deny statements ေတြ တစ္ခုမွ မပါရွိ (အခြံ) ၀ူးလို့ ယူဆၾကည့္မယ္။ router ကို ၄င္း ethernet interface ေပၚမွာ telnet မွတဆင့္ ခ်ိတ္ဆက္ထားျပီး မိမိ PC ရဲ့ IP address သည္ 192.168.1.1 ျဖစ္တယ္လို့ ယူဆပါ။ ယခုအခါ ACL#10 အတြင္းမွာ 172.16.0.0/16 မွ traffic ေတြကို permit ျပုလုပ္တဲ့ entry တစ္ခုကို create လုပ္လိုက္တယ္။ create လုပ္လိုက္သည္နွင့္ တျပိုင္နက္ telnet connection ရပ္ဆိုင္းသြားတယ္။ implicit deny ေၾကာင့္ router သည္ telnet connection ကို drop လုပ္ပစ္လိုက္ျခင္းျဖစ္တယ္။ router မွာ statement တစ္ခုရွိလာသည္ႏွင့္ တျပိုင္နက္ implicit deny ကို ေအာက္ေျခမွာ ထပ္ေပါင္းထည့္တယ္။ ဒီဥပမာမွာ PC ရဲ့ address သည္ 192.168.1.1 ျဖစ္တာျပီး ၊ ၄င္းသည္ ပထမ statement အတြင္းမွာ မပါ၀င္ပါ။ ACL#10 အတြင္းမွာ ၄င္း address နဲ့ ကိုက္ညီတဲ့ statements တစ္ခုမွ မေတြ့တာေၾကာင့္ router သည္ connection ကို drop လုပ္လိုက္တယ္။

on the job!
ACL အခြံ (empty ACL) နဲ့ ပက္သက္ျပီး အမ်ိဳးမ်ိဳး ေျပာေနၾကတာေတြ ရွိပါတယ္ : empty ACL သည္ traffic အားလံုးကို drop လုပ္တယ္လို့ ေျပာတဲ့လူ ရွိသလို traffic အားလံုးကို permit လုပ္တယ္လို့ ေျပာတဲ့လူလည္း ရွိပါတယ္။ တခ်ိဳ့ကေတာ့လည္း IOS version အေပၚ မူတည္တယ္လို့ ေျပာၾကပါတယ္။ ACLs စတင္ထြက္ေပၚလာတဲ့ IOS version 7 မွသည္ ေနာက္ဆံုးထြက္ရွိတဲ့ 12.4T အထိ လုပ္ကိုင္ခဲ့တဲ့ အေတြ့အၾကံုအရ ၊ empty ACL တစ္ခုသည္ interface မွ ဒါမွမဟုတ္ interface ကို ျဖတ္သန္းတဲ့ traffic ကို အျမဲ allow လုပ္ပါတယ္။ router ရဲ့ interface တစ္ခုသို့ statement တစ္ခုမွ မပါရွိတဲ့ inbound ACL အခြံ တစ္ခုကို apply ျပုလုပ္ျပီး ၊ ၄င္း interface ကို ping လုပ္ျခင္းျဖင့္ ၄င္း အခ်က္ကို စမ္းသပ္ၾကည့္ဖို့ တိုက္တြန္းလိုပါတယ္ : ping လို့ ရေၾကာင္း ေတြ့ရပါလိမ့္မယ္။

exam watch!
interface တစ္ခုေပၚမွာ ACL တစ္ခုကို activate ျပုလုပ္ဖို့ ip access-group command ကို အသံုးျပဳပါ။ ACL number ဒါမွမဟုတ္ name နဲ့ direction (in ဒါမွမဟုတ္ out) ကို သတ္မွတ္ေပးရမယ္။ ACLs ေတြကို LAN (VLAN traffic) နဲ့ WAN subinterfaces မ်ားသို့လည္း apply ျပုလုပ္ႏိူင္ပါတယ္။

Chapter 22: Access Control Lists (10)

2010-09-10T09:39:00.001+06:30

Wildcard Mask Examples

Wildcard mask နဲ့ ပက္သက္တဲ့ concept မွာ ရွဳပ္ေထြးမွဳေတြ ရွိႏိူင္တာမို့ ၊ ဥပမာအခ်ိဳ့ကို ဆက္လက္ၾကည့္ၾကပါစို့။ Table 22-4 မွာ addresses နဲ့ wildcard masks မ်ားရဲ့ နမူနာအခ်ိဳ့ကို ျပသထားတယ္။

On the job!
0.0.1.255 လို wildcard masks အခ်ိဳ့မွာ ရွဳပ္ေထြးမွဳေတြ ျဖစ္ႏိူင္တယ္။ ၄င္း masks မ်ားအတြတ္၊ တစ္ခါတစ္ရံမွာ subnet mask ရွဳေထာင့္မွ ၾကည့္တာ ပိုမို လြယ္ကူတယ္။ ဒီဥပမာမွာ သက္ဆိုင္တဲ့ subnet mask သည္ 255.255.254.0 ျဖစ္လိမ့္မယ္။ wildcard mask ကို local broadcast address (255.255.255.255) နဲ့ ျခားနားျခင္းျဖင့္ မွန္ကန္တဲ့ wildcard mask ကို လြယ္ကူစြာ တြတ္ဆႏိူင္တယ္။ ၄င္းနည္းလမ္းေပၚမွာ အေျခခံျပီး Table 22-4 ရဲ့ စတုတၱ row သည္ addresses range 172.16.2.0 မွ 172.16.3.255 အထိ ဘာေၾကာင့္ match ျဖစ္ရသလဲဆိုတာကို လြယ္ကူစြာ ေတြ့ျမင္ႏိူင္တယ္။

exam watch!
wildcard masks မ်ားရဲ့ အလုပ္လုပ္ပံုကို ကြ်မ္းက်င္ပိုင္ႏိူင္ထားသင့္တယ္။ ထို့အတူ Table 22-4 မွာ ျပသထားတဲ့ host တစ္ခုအေပၚ၊ ဒါမွမဟုတ္ devices အားလံုးအေပၚ match ျဖစ္ေစဖို့ အသံုးျပဳတဲ့ Cisco ရဲ့ special notation ေတြကို သိထားသင့္တယ္။

Chapter 22: Access Control Lists (9)

2010-09-10T01:01:00.003+06:30

Special Wildcard Masks

Special wildcard masks 2 မ်ဳိးရွိတယ္ : 0.0.0.0 နဲ့ 255.255.255.255 ။ wildcard mask 0.0.0.0 သည္ IP packet အတြင္းမွာ ေတြ့ရတဲ့ address ရဲ့ 32 bits နဲ့ ACL statement ထဲက address ရဲ့ 32 bits အားလံုး တူညီရမယ္ လို့ IOS သို့ ေျပာဆိုတယ္။ 0.0.0.0 wildcard mask ကို host mask လို့ ေခၚတယ္။ 192.168.1.1 0.0.0.0 သည္ ရိုးရွင္းတဲ့ ACL statement ဥပမာ တစ္ခုျဖစ္တယ္။ ၄င္း statement သည္ IP packet အတြင္းမွာ လံုး၀ တူညီတိက်တဲ့ IP address (192.168.1.1) ကို ရွာေဖြဖို့ IOS ကို ေျပာဆိုတယ္။ IOS သည္ match တစ္ခုကို မေတြ့ရရင္ ေနာက္ ACL statement တစ္ခုသို့ သြားလိမ့္မယ္။ 192.168.1.1 ကို configure ျပုလုပ္လိုက္မယ္ဆိုရင္ IOS သည္ ၄င္းကို ေအာက္ပါ syntax သို့ ေျပာင္းလဲပါလိမ့္မယ္ : host 192.168.1.1 ။

Wildcard mask 255.255.255.255 သည္ wildcard mask 0.0.0.0 နဲ့ လံုး၀ ဆန့္က်င္ဘက္ ျဖစ္တယ္။ ၄င္း wildcard mask မွာ bit တန္ဖိုးအားလံုးသည္ 1s ေတြျဖစ္ျပီး၊ ACL statement နဲ့ ႏွိုင္းယွဥ္တဲ့ packet ထဲက မည္သည့္ address နဲ့မဆို match ျဖစ္ေၾကာင္း IOS သို့ ေျပာဆိုတယ္။ ပံုမွန္အားျဖင့္ wildcard mask 255.255.255.255 ကို IP address 0.0.0.0 နဲ့ တြဲဖက္ျပီး 0.0.0.0 255.255.255.255 အျဖစ္ configure ျပုလုပ္တယ္။ ၄င္းကို ထည့္သြင္းမယ္ဆိုရင္ IOS သည္ address နဲ့ mask ကို keyword “any” သို့ ေျပာင္းလဲ လိမ့္မယ္။ တကယ္တမ္းမွာ ဒီ wildcard mask နဲ့ အတူ ထည့္သြင္းလိုက္တဲ့ IP address သည္ အေရးပါေတာ့သည္ မဟုတ္ပါ၊ မည္သည့္ IP address ကိုမဆို ထည့္သြင္းႏိူင္တယ္။ ဥပမာ အကယ္၍ 192.168.1.1 255.255.255.255 ကို ထည့္သြင္းမယ္ဆိုရင္ ၄င္းသည္ မည္သည့္ IP address နဲ့မဆို match ျဖစ္ေနဆဲပင္ျဖစ္တယ္။ IP address ထဲက မည္သည့္ bits ေတြသည္ “interesting” ျဖစ္တယ္၊ “match” ျဖစ္သင့္တယ္ ဆိုတာကို အဆံုးအျဖတ္ေပးတာသည္ wildcard mask ျဖစ္တယ္ဆိုတာ မေမ့ပါနဲ့။

Chapter 22: Access Control Lists (8)

2010-09-09T22:37:00.005+06:30

Matching on Addresses:Wildcard Masks

ACL statements ေတြအတြင္းမွ IP addresses မ်ားကို ကုိင္တြယ္ရာမွာ၊ မိမိ match ျပုလုပ္လိုတဲ့ IP address ကို တစ္ခုခ်င္းစီ ရိုက္ထည့္ေနမယ့္အစား wildcard masks ေတြကို အသံုးျပဳျပီး range of addresses တစ္ခုအေပၚမွာ match ျပဳလုပ္ႏိူင္တယ္။

wildcard mask နဲ့ ပက္သက္ျပီး ပထမဦးဆံုး ေျပာခ်င္တာကေတာ့ wildcard mark သည္ subnet mask မဟုတ္၀ူး ဆိုတာပါပဲ။ ဒါေပမယ့္ IP address နဲ့ subnet mask ေတြလိုပဲ၊ wildcard mask ကိုလည္း 32-bits ပံုစံနဲ့ ဖြဲ့စည္းတည္ေဆာက္ထားတယ္။ Table 22-3 မွာ subnet mask နဲ့ wildcard mask တစ္ခုစီမွာ ပါ၀င္တဲ့ bit values ေတြကို ႏွိဳင္းယွဥ္ျပသထားတယ္။ Wildcard mask တစ္ခုမွာ bit position တစ္ခုအတြင္းက 0 တစ္လံုးသည္၊ exmine ျပုလုပ္ခံရတဲ့ packet ရဲ့ IP address အတြင္းမွ တူညီတဲ့ bit position နဲ့ လံုး၀ match ျဖစ္ရမယ့္ ACL statement ရဲ့ address အတြင္းရွိ သက္ဆိုင္တဲ့ bit position ကို ရည္ညႊန္းျခင္း ျဖစ္တယ္။ wildcard masks ရဲ့ bit position အတြင္းမွ 1 တစ္လံုးသည္၊ exmine ျပုလုပ္ခံရတဲ့ packet အတြင္းရွိ IP address ရဲ့ bit position နဲ့ ကိုက္ညီဖို့ မလိုအပ္တဲ့ ACL statement ရဲ့ address မွ သက္ဆိုင္တဲ့ bit position ကို ရည္ညႊန္းျခင္း ျဖစ္တယ္။ wildcard mask သည္ ACL ရဲ့ address အတြင္းမွ မည္သည့္ addressing bits မ်ားသည္ packet အတြင္းရွိ သူနဲ့ ႏွိုင္းယွဥ္တဲ့ bits မ်ားနဲ့ match ျဖစ္ရမယ္ ဆုိတာကို router သို့ ေျပာျပတယ္။

တကယ့္ အစစ္အမွန္မွာ wildcard mask သည္ subnet mask ရဲ့ ဆန့္က်င္ဘက္ ပံုစံ တစ္ခုနဲ့ ပိုမို ဆင္တူေနတယ္။ ဥပမာ network ဒါမွမဟုတ္ subnet တစ္ခုအတြင္းက address တစ္ခုခုနဲ့ match ျဖစ္ေစခ်င္တဲ့ဆိုရင္ ၄င္း subnet ရဲ့ bit values ေတြကို ေျပာင္းျပန္လွန္ (1s ေတြကို 0s သို့ ေျပာင္း၊ 0s ေတြကို 1s သို့ ေျပာင္း) လိုက္ျခင္းျဖင့္ သက္ဆိုင္တဲ့ wildcard mask ကို ရရွိမွာ ျဖစ္တယ္။

subnet mask မွ wildcard mask သို့ binary conversion ျပုလုပ္ျခင္းရဲ့ ရိုးရွင္းလြယ္ကူတဲ့ ဥပမာတစ္ခုကို ၾကည့္ၾကပါစို့။ subnet mask တန္ဖိုးသည္ 255.255.0.0 ျဖစ္တယ္ဆိုပါစို့။ သူ့ရဲ့ binary ပံုစံသည္ 11111111.11111111.00000000.00000000 ျဖစ္မယ္။ ၄င္းကို wildcard mask တစ္ခုအျဖစ္သို့ ေျပာင္းလဲတဲ့အခါ bits ေတြကို ေျပာင္းျပန္လွန္လိုက္ပါ : 00000000.00000000.11111111.11111111 ။ ျပီးတဲ့အခါ ၄င္းကို decimal သို့ ေျပာင္းလဲပါ : 0.0.255.255 ။ ၄င္းသည္ subnet mask 255.255.0.0 အတြတ္ သက္ဆိုင္တဲ့ wildcard mask ပါပဲ။ ဒီဥပမာမွာ wildcard mask သည္ ACL statement ထဲက သက္ဆိုင္တဲ့ IP address ရဲ့ ပထမ 16 bits သည္ exmine ျပုလုပ္ခံရတဲ့ packet ရဲ့ IP address ထဲက ပထမ 16 bits နဲ့ match ျဖစ္ရမယ္ လို့ router သို့ ေျပာဆိုပါတယ္။ ဒီလို match ျဖစ္မွသာလွ်င္ router သည္ statement ကို ဆက္လက္ process ျပုလုပ္ႏိူင္မွာျဖစ္ျပီး၊ အကယ္၍ match မျဖစ္၀ူးဆိုရင္ router သည္ ေနာက္ထပ္ အျခား ACL statement သို့ ကူးေျပာင္းသြားပါလိမ့္မယ္။

ပိုမို ခက္ခဲတဲ့ ေနာက္ထပ္ ဥပမာ တစ္ခုကို ၾကည့္ၾကပါဦးစို့။ subnet mask 255.255.240.0 ရွိတဲ့ subnet တစ္ခုအေပၚမွာ match ျဖစ္ခ်င္တယ္ ဆိုပါစို့။ ၄င္း subnet mask ရဲ့ binary သည္ 11111111.11111111.11110000.00000000 ျဖစ္တယ္။ ဒီဥပမာမွာ ပထမ၊ ဒုတိယ နဲ့ စတုတၱ octets ေတြသည္ ေျပာင္းလဲဖို့ လြယ္ကူေပမယ့္ တတိယ octet သည္ ခက္ခဲတာ ေတြ့ရမယ္။ subnet mask မွ wildcard mask သို့ ေျပာင္းလဲဖို့ bits အားလံုးကို ေျပာင္းျပန္လွန္လိုက္ပါ : 00000000.00000000.00001111.11111111 ။ ျပီးတဲ့အခါ ၄င္းကို decimal သို့ ျပန္ေျပာင္းပါ။ ေအာက္ပါ wildcard mask ကို ရရွိမွာ ျဖစ္တယ္ : 0.0.15.255 ။ ၄င္း အထက္ပါ ဥပမာ ၂ ခုကို ၾကည့္ျခင္းအားျဖင့္ subnet ရဲ့ octet သည္ 0 ျဖစ္တယ္ဆိုရင္ wildcard mask သည္ 255 ျဖစ္မွာ ျဖစ္ျပီး၊ subnet mask ရဲ့ octet သည္ 255 ျဖစ္တယ္ဆိုရင္ wildcard mask သည္ 0 ျဖစ္ပါမယ္။ ဒါေပမယ့္ ဒုတိယ ဥပမာရဲ့ တတိယ octet မွာ အေျပာင္းအလဲ ျပဳလုပ္ဖို့ ပိုမို ခက္ခဲတာ ေတြ့ရတယ္။

Subnet mask မွ wildcard သို့ အေျပာင္းအလဲအတြတ္ လြယ္ကူတဲ့ shortcut တစ္ခုကို ေျပာျပပါမယ္။ အေျပာင္းအလဲ ျပဳလုပ္တဲ့အခါ subnet mask ထဲက byte အသီးသီးကို 255 နဲ့ ျခားနားပါ။ ရလာတဲ့ အေျဖသည္ wildcard mask အတြတ္ သက္ဆိုင္တဲ့ byte တန္ဖိုး ျဖစ္ပါတယ္။ အထက္ပါ shortcut ကို အသံုးျပဳျပီး 255.255.240 ကို ေအာက္ပါအတိုင္း လြယ္ကူစြာ ေျပာင္းလဲႏိူင္တယ္ :

ပထမ byte : 255-255 (ပထမ subnet byte တန္ဖိုး) = 0 (wildcard mask တန္ဖိုး)
ဒုတိယ byte : 255-255 (ဒုတိယ subnet byte တန္ဖိုး) = 0 (wildcard mask တန္ဖိုး)
တတိယ byte : 255-240 (တတိယ subnet byte တန္ဖိုး) = 15 (wildcard mask တန္ဖိုး)
စတုတၱ byte : 255-0 (စတုတၱ subnet byte တန္ဖိုး) = 255 (wildcard mask တန္ဖိုး)

အထက္ပါအတိုင္း၊ ရလာတဲ့ wildcard mask တန္ဖိုးသည္ 0.0.15.240 ျဖစ္ေနတာ ေတြ့ရပါတယ္။ ဒါေၾကာင့္ ဒီရိုးရွင္းတဲ့ နည္းလမ္းေလးသည္ subnet masks မွ wildcard masks သို့ ေျပာင္းလဲျခင္းကို အလြန္ လြယ္ကူသြားေစပါတယ္။

Exam watch!
packet တစ္ခုအတြင္းက bits ေတြနဲ့ match လုပ္ဖို့ wildcard masks ေတြကို အသံုးျပဳတယ္။ bit position တစ္ခုရွိ 0 တစ္လံုးသည္ “match” ကို ရည္ညႊန္းလိုျခင္းျဖစ္ျပီး 1 သည္ “ignore” ကို ဆိုလိုျခင္းျဖစ္တယ္။ subnet တစ္ခုနဲ့ match ျပုလုပ္လိုတဲ့အခါ၊ သက္ဆိုင္တဲ့ subnet mask ကို ေျပာင္းျပန္ ေျပာင္းလဲပါ။ shortcut နည္းလမ္းမွာ subnet mask ထဲက octet အသီးသီးကို 255 နဲ့ ျခားနားျခင္းျဖစ္ျပီး၊ wildcard mask တန္ဖိုးရရွိမွာ ျဖစ္တယ္။ exam မွာ ACL questions ေတြ ေျဖဆိုဖို့ အထက္ပါ shortcut နည္းလမ္းကို အသံုးျပဳပါ။

Chapter 22 : Access Control Lists (7)

2010-08-18T01:25:00.004+06:30

Basic ACL Configuration

ဒီအပိုင္းမွာ IP ACLs ေတြကို configure ျပုလုပ္ဖို့ အသံုးျပုမယ့္ အေျခခံ commands 2 ခုကို အက်ဥ္းခ်ဳပ္ မိတ္ဆက္ ေဆြးေႏြးမွာ ျဖစ္ပါတယ္။ ေနာက္လာမယ့္ သင္ခန္းစာမ်ားမွာ numbered နဲ့ named ၊ standard နဲ့ extended ACLs မ်ားကို configure ျပုလုပ္ျခင္း နဲ့ ပက္သက္ျပီး အေသးစိတ္ ေဆြးေႏြးေဖာ္ျပသြားပါမယ္။

Creating an ACL

numbered ACL တစ္ခုကို create လုပ္ဖို့ ေအာက္ပါ syntax ကို အသံုးျပုပါ :

Router(config)# access-list ACL_# permit | deny conditions

IOS 11.2 မတိုင္ခင္အထိ ACL တစ္ခုမွာ identifier အျဖစ္ number ကိုသာ အသံုးျပဳခဲ့တယ္။ IOS 11.2 မွ အစျပု၍ ACL တစ္ခုကို number သို့မဟုတ္ name နဲ့ ရည္ညႊန္းလာႏိူင္တယ္။ ACL_# ရဲ့ ရည္ရြယ္ခ်က္သည္ statements ေတြကို list ဒါမွမဟုတ္ policy တစ္ခုအတြင္းသို့ အတူအကြ group ဖဲြ့ဖို့ ျဖစ္တယ္။ ACL တစ္ခုအတြတ္ number ကို မိမိႏွစ္သက္သလို အသံုးျပဳ၍ မရပါ။ layer 3 protocol အသီးသီး ကို သူတု့ိ ကိုယ္ပိုင္ range ဒါမွမဟုတ္ ranges of numbers ေတြနဲ့ assign ျပုလုပ္ထားတယ္။

Table 22-2 မွာ IP ACLs မ်ားအတြတ္ valid ACL numbers ေတြကို ျပသထားတယ္။ ၄င္း table မွာ ေတြ့ျမင္ရသလိုပါပဲ - numbered ACLs ေတြမွာ မိမိ ဖန္တီးအသံုးျပဳႏိူင္တဲ့ number of lists သည္ protocol type တစ္ခုသို့ assign ျပုလုပ္ထားတဲ့ range of numbers အေပၚမွာ အေျခခံျပီး အကန့္အသတ္နဲ့ ျဖစ္တယ္။ ဒါေပမယ့္ named ACLs မ်ားမွာ ၄င္း အကန့္အသတ္မရွိပါ။ အေျခခံအားျဖင့္ router တစ္လံုးမွာ named ACLs အေရအတြတ္ကို router မွာ ရွိတဲ့ RAM နဲ့ NVRAM ပမာဏ ကသာလွ်င္ အကန့္အသတ္ ျပုလုပ္ပါတယ္။

exam watch!
IP ACLs မ်ားအတြတ္ အသံုးျပဳႏိူင္တဲ့ numbers ေတြကို မွတ္သားပါ။ standard ACLs မ်ားသည္ 1 မွ 99 အထိ နဲ့ 1300 မွ 1999 အထိ numbers ေတြကို အသံုးျပဳႏိူင္ျပီး၊ extended ACLs မ်ားသည္ 100 မွ 199 နဲ့ 2000 မွ 2699 အထိ numbers ေတြကို အသံုးျပဳႏိူင္တယ္။

ACL statement တစ္ခုမွာ condition သည္ router ကို (permit သို့မဟုတ္ deny) action တစ္ခုကို လုပ္ေဆာင္ဖို့အတြတ္ packet ထဲက မည္သည့္ contents ေတြ match ျဖစ္ဖို့ လိုအပ္ေၾကာင္း ေျပာဆိုတယ္။ condition မွာ IP addresses အတြဲေတြ နဲ့ protocol information ေတြ ပါ၀င္ႏိူင္တယ္။ IOS က packet တစ္ခုကို condition နဲ့ compare ျပုလုပ္တဲ့အခါ၊ match တစ္ခုကို ေတြ့ရတယ္ဆိုရင္ ေနာက္ထပ္ အျခား ACL statements ေတြကို ဆက္လက္ process မလုပ္ေတာ့ပါ၊ အကယ္၍ match တစ္ခု မေတြ့ရ၀ူးဆိုရင္ IOS သည္ packet ကို list ထဲက ေနာက္ထပ္ ACL statement တစ္ခု နဲ့ ဆက္လက္ compare ျပုလုပ္တယ္။

Chapter 22 : Access Control Lists (6)

2010-08-15T12:52:00.002+06:30

Important Configuration Gidelines

ACL တစ္ခုကို configure ျပုလုပ္ဖို့ ရိုးရွင္း လြယ္ကူသည္ မဟုတ္ပါ။ configuration process ကို မွန္ကန္စြာ လုပ္ေဆာင္ႏိူင္ဖို့ ေအာက္ပါအခ်က္ေတြကို လိုက္နာပါ :

statements အစီအစဥ္သည္ အေရးၾကီးတယ္ : အတိက်ဆံုး statements ကို list ရဲ့ အေပၚဆံုးမွာ ထားရွိျပီး တိက်မွဳ အနည္းဆံုး statement ကို ေအာက္ဖက္မွာ ထားရွိပါ။
match တစ္ခု ေတြ့ရသည္အထိ ACL statements ေတြကို အထက္မွ ေအာက္သို့ ACL ရဲ့ အဆံုးအထိ process ျပဳလုပ္မယ္။
ACL အတြင္းမွာ match တစ္ခုမွ မေတြ့ရင္ packet ကို drop လုပ္ပစ္မယ္ (implicit deny) ။
group စုဖြဲ့ထားတဲ့ ACL statements ေတြအတြတ္ တိက်တဲ့ အမည္ ဒါမွမဟုတ္ တိက်တဲ့ နံပါတ္ တစ္ခု လိုအပ္တယ္။
router သည္ သူကိုယ္တိုင္မွ အစျပုတဲ့ traffic ကို filter မျပုလုပ္ႏိူင္ပါ။
interface တစ္ခုရဲ့ direction အသီးသီး (inbound နဲ့ outbound) သို့ IP ACL တစ္ခုကိုသာ apply လုပ္ႏိူင္တယ္။ (တကယ္တန္းမွာ interface တစ္ခုရဲ့ direction အသီးသီးမွာ protocol တစ္ခုစီအတြတ္ ACL တစ္ခုစီ apply ျပုလုပ္ႏိူင္ပါတယ္ (ဥပမာ IP နဲ့ IPX )။
interface တစ္ခုသို့ empty ACL တစ္ခု apply ျပုလုပ္ျခင္းသည္ default မွာ traffic အားလံုးကို permit လုပ္တယ္။ ACL တစ္ခုမွာ implicit deny statement တစ္ခု ရွိေစဖို့အတြတ္ ၄င္း ACL အတြင္းမွာ permit ဒါမွမဟုတ္ deny statement တစ္ခုကို အမွန္ကတယ္ သတ္မွတ္ေပးဖို့ လိုအပ္တယ္။

အထက္ပါ guidelines ေတြကို ၾကည့္ျခင္းအားျဖင့္ ACLs သည္ ရိုးရွင္း လြယ္ကူတဲ့ ကိစၥတစ္ခု မဟုတ္၀ူးဆိုတာ သိႏိူင္ပါတယ္။ ACLs ေတြသည္ IOS ရဲ့ အရွဳပ္ေထြးဆံုး၊ အစြမ္းထက္ဆံုး features ေတြထဲက တစ္ခုျဖစ္တယ္။ ACLs ေတြကို configure ၊ manage နဲ့ troubleshoot ျပုလုပ္ျခင္းသည္ အလြန္ ရွဳပ္ေထြးျပီး ေခါင္းကိုက္စရာ ျဖစ္တယ္။ ဒါေၾကာင့္ router သည္ packets ေတြကို ACLs မ်ားသို့ မည္သို့ မည္ပံု compare ျပုလုပ္တယ္ ၊ မည္သို့ မည္ပံု ဖန္တီးျပီး မည္သို့ မည္ပံု ထိန္းသိမ္းထားတယ္ ဆိုတာကို သိထားဖို့ အရမ္း အေရးၾကီးပါတယ္။ router တစ္လံုးေပၚမွာ ACLs ေတြကို basic configuration ျပဳလုပ္ျခင္း သင္ခန္းစာေတြကို ေနာက္လာမယ့္ အပိုင္းမွာ ေဆြးေႏြးပါမယ္။

exam watch!
အထက္မွာ ေဖာ္ျပထားတဲ့ ACL configuration အတြတ္ guidelines ေတြကို မွတ္သားပါ။

Chapter 22 : Access Control Lists (5)

2010-08-15T04:41:00.003+06:30

Implicit Deny

အထက္-ေအာက္ process ျပုလုပ္ျခင္း နဲ့ ပက္သက္တဲ့ အျခား အေရးၾကီးတဲ့ အခ်က္တစ္ခုမွာ အကယ္၍ router သည္ packet ကို list ထဲက statement အားလံုး နဲ့ compare ျပုလုပ္ျပီးတဲ့ေနာက္ match တစ္ခုမွ မေတြ့ရတဲ့အခါ packet ကို drop လုပ္ပစ္မယ္ ဆိုတဲ့ အခ်က္ပဲ ျဖစ္တယ္။ ဒီျဖစ္စဥ္ကို implicit deny လို့ ရည္ညႊန္းတယ္။ ACL တစ္ခုစီရဲ့ အဆံုးမွာ ၄င္း ACL အတြင္း သတ္မွတ္ထားတဲ့ statements အားလံုး နဲ့ match မျဖစ္တဲ့ traffic အားလံုးကို drop ျပုလုပ္မယ့္ invisible statement တစ္ခု ရွိေနပါတယ္။ implicit deny သည္ traffic အားလံုးကို drop ျပုလုပ္မွာမို့ deny statements ေတြသာ ပါ၀င္တဲ့ ACL list တစ္ခုကို ဖန္တီး သတ္မွတ္ျခင္းသည္ အက်ိဳးမဲ့သက္သက္သာ ျဖစ္ေစပါလိမ့္မယ္။ deny statements မ်ားသာ ပါရွိတဲ့ ACL တစ္ခုသည္ traffic အားလံုးကို drop ျပဳလုပ္မွာမို့ (မိမိသတ္မွတ္လိုက္တဲ့ deny statements + hidden အျဖစ္ ရွိေနတဲ့ implicit deny statement) ACL တစ္ခုစီမွာ permit statement တစ္ခုေတာ့ အနည္းဆံုး ပါရွိသင့္တယ္။

exam watch!
ACL တစ္ခုသည္ actions 2 ခုကို လုပ္ေဆာင္ႏိူင္တယ္ : permit ဒါမွမဟုတ္ deny ။ statements ေတြကို အထက္-ေအာက္ process ျပုလုပ္တယ္။ match တစ္ခုကို ေတြ့ရတဲ့အခါ ေနာက္ထပ္ statement တစ္ခုကို ဆက္လက္ process မျပုလုပ္ေတာ့တာမို့ statement order သည္ အလြန္ အေရးၾကီးတယ္။ အကယ္၍ match တစ္ခုကိုမွ မေတြ့ရတဲ့အခါ ACL ရဲ့ အဆံုးမွာ invisible အျဖစ္ရွိေနတဲ့ implicit deny statement သည္ packet ေတြကို drop လုပ္ပါလိမ့္မယ္။ ACL တစ္ခုမွာ permit statement တစ္ခုေတာ့ အနည္းဆံုး ပါရွိသင့္ပါတယ္၊ အဲလိုမွမဟုတ္ရင္ ACL အသီးသီးရဲ့ အဆံုးမွာ hidden အျဖစ္ရွိေနတဲ့ implicit deny statement ေၾကာင့္ traffic အားလံုး drop ျပုလုပ္ခံရပါလိမ့္မယ္။

Chapter 22 : Access Control Lists (4)

2010-08-15T04:01:00.001+06:30

Statement Ordering

statement တစ္ခုမွာ match တစ္ခု ေတြ့ရတဲ့အခါ အျခား statements ေတြကို ဆက္လက္ process မျပုလုပ္ေတာ့တာမို့ ACL တစ္ခုအတြင္းမွာ statement အစီအစဥ္ (order of statements) သည္ အရမ္း အေရးၾကီးပါတယ္။ အကယ္၍ မိမိမွာ statements 2 ခုရွိတယ္ဆိုပါစို့။ statement တစ္ခုသည္ host ကို deny လုပ္မွာျဖစ္ျပီး၊ အျခား statement တစ္ခုသည္ ၄င္း host ကို permit လုပ္မွာ ျဖစ္တယ္ လို့ ဆုိပါစို့။ ဒီအေျခအေနမွာ list ရဲ့ ပထမ ေနရာမွာ ရွိေနတဲ့ statement ကို execute လုပ္မွာျဖစ္ျပီး ၊ ဒုတိယေနရာ မွာ ရွိေနတဲ့ statement ကို ignore လုပ္ပါလိမ့္မယ္။ statement အစီအစဥ္ (order of statements) သည္ အရမ္းအေရးၾကီးတာမို့ အေရးၾကီးဆံုးျဖစ္တဲ့ ACL statements ေတြကို list ရဲ့ ထိပ္ဆံုးမွာ အျမဲ ေနရာခ်ထားသင့္ျပီး အရမ္း အေရးမၾကီးတဲ့ statements ေတြကို list ရဲ့ ေအာက္ေျခမွာ ေနရာခ်ထားသင့္ပါတယ္။

၄င္း process ကို သရုပ္ျပ ရွင္းလင္းဖို့အတြတ္ ေအာက္ပါ ဥပမာ တစ္ခုကို ၾကည့္ၾကပါစို့။ ဒီဥပမာမွာ router ရဲ့ ACL မွာ statements 2 ခု ပါ၀င္တယ္ :

1. Subnet 172.16.0.0/16 မွ traffic ေတြကို permit လုပ္ပါ။
2. Host 172.16.1.1/32 မွ traffic ေတြကို deny လုပ္ပါ။

router သည္ statements ေတြကို အထက္မွ ေအာက္သို့ process ျပဳလုပ္တယ္ဆိုတာကို သတိျပဳပါ။ source IP address 172.16.1.1 နဲ့ packet တစ္ခုကို router သည္ လက္ခံရရွိတယ္ ဆုိပါစို့။ အထက္ပါ ACL မွာ၊ router သည္ packet contents ေတြကို ပထမ statement နဲ့ compare ျပုလုပ္တယ္။ packet ရဲ့ source address သည္ network 172.16.0.0/16 မွ ျဖစ္သလား ? ဟုတ္ကဲ့၊ packet ရဲ့ source IP address 172.16.1.1 သည္ subnet 172.16.0.0/16 မွ ျဖစ္တယ္။ ဒါ့ေၾကာင့္ router သည္ packet ကို permit လုပ္ပါလိမ့္မယ္။ ပထမ statement မွာ match ျဖစ္တာ ေတြ့ရျပီမို့ router သည္ ေနာက္ statement ကို ဆက္လက္ process မျပဳလုပ္ေတာ့၀ူးဆိုတာ သတိျပဳပါ။ ဒီဥပမာမွာ 172.16.0.0/16 subnet မွ မည္သည့္ traffic ကိုမဆို permit ျပဳလုပ္ပါလိမ့္မယ္။

ယခုတဖန္ ACL ထဲက အထက္ပါ statements 2 ခုကို အထက္ေအာက္ ေျပာင္းျပန္စီ ျပီး traffic flow အေပၚမွာ ဘယ္လို သက္ေရာက္မွဳ ရွိမလဲ ၾကည့္ၾကပါစို့ :

1. Host 172.16.1.1 မွ traffic ေတြကို deny ျပဳလုပ္ပါ။
2. Subnet 172.16.0.0 မွ traffic ေတြကို permit ျပဳလုပ္ပါ။

172.16.1.1 သည္ router ကို ျဖတ္လ်က္ traffic ေတြ ေပးပို့တဲ့အခါ IOS သည္ ၄င္း packets ေတြကို ပထမ ACL statement နဲ့ တိုက္ဆိုင္ စစ္ေဆးတယ္။ source address သည္ 172.16.1.1 နဲ့ match ျဖစ္တာမို့ router သည္ packet ကို drop ျပဳလုပ္ျပီး statements processing ကိုလည္း ရပ္တန့္လိုက္တယ္။ ဒီဥပမာမွာ 172.16.1.1 မွ မည္သည့္ traffic ကို ေပးပို့သည္ျဖစ္ေစ drop လုပ္ခံရပါမယ္။ အကယ္၍ အျခား device တစ္ခုခု (ဆိုၾကပါစို့ 172.16.1.2) က router ကို ျဖတ္လ်က္ traffic ေတြ ေပးပို့လာတဲ့အခါ router သည္ ACL ထဲက ပထမ statement နဲ့ packet contents ေတြကို compare ျပုလုပ္တယ္။ packet ထဲက source address သည္ ACL statement ထဲက source address နဲ့ match မျဖစ္တာမို့ router သည္ list ထဲက ေနာက္ထပ္ statement ကို ဆက္လက္ process ျပုလုပ္တယ္။ packet contents ကို statement နဲ့ တုိက္ဆိုင္ စစ္ေဆးလိုက္တဲ့အခါ match ျဖစ္ေနတာမို့ router သည္ traffic ကို permit ျပုလုပ္ပါလိမ့္မယ္။ အထက္ပါ ACL ဥပမာ 2 ခုကို ၾကည့္ျခင္းအားျဖင့္ ACL အတြင္းမွာ statements အစီအစဥ္သည္ အရမ္း အေရးၾကီးေၾကာင္း နဲ့ traffic ကို permit ဒါမွမဟုတ္ deny ျပဳလုပ္မလားဆိုတဲ့အေပၚ အတိအက် သက္ေရာက္မွဳရွိေၾကာင္း သတိျပုမိပါလိမ့္မယ္။

Chapter 22 : Access Control Lists (3)

2010-08-07T10:22:00.003+06:30

Processing

အေျခခံအားျဖင့္ ACLs မ်ားသည္၊ name ဒါမွမဟုတ္ number တစ္ခုနဲ့ သတ္မွတ္ျပီး အတူအကြ group ျပဳလုပ္ထားတဲ့ statements ေတြျဖစ္တယ္။ packet တစ္ခုကို ACL တစ္ခုက process လုပ္တဲ့အခါ၊ IOS သည္ packet ကို ၄င္း statements group အတြင္းမွ ACL statements မ်ားနဲ့ တိုက္ဆိုင္စစ္ေဆးျပီး match တစ္ခုကို ရွာေဖြတယ္။ IOS သည္ ACLs ကို အထက္မွ ေအာက္သို့ (top-down) process ျပုလုပ္တယ္။ packet ကို ACL အတြင္းမွ ပထမ statement နဲ့ compare ျပဳလုပ္တယ္၊ အကယ္၍ packet နဲ့ statement အၾကား match တစ္ခုကို ရွာေဖြေတြ့ရွိတဲ့အခါ IOS သည္ statement မွာ ပါ၀င္တဲ့ actions 2 ခုအနက္ 1 ခုကို လုပ္ေဆာင္လိမ့္မယ္ : permit သို့မဟုတ္ deny ။

အကယ္၍ packet မွာ ပထမ statement နဲ့ match ျဖစ္တဲ့ contents ေတြ မေတြ့ရွိတဲ့အခါ၊ IOS သည္ list အတြင္းမွ ေနာက္ထပ္ statement နဲ့ matching process ကို ဆက္လက္ လုပ္ေဆာင္ပါလိမ့္မယ္။ အကယ္၍ ဒုတိယ statement နဲ့ packet contents ေတြ match ျဖစ္တယ္ဆိုရင္ IOS သည္ actions 2 ခုအနက္ 1 ခု ကို လုပ္ေဆာင္ပါလိမ့္မယ္။ အကယ္၍ ၄င္း ဒုတိယ statement နဲ့ match မျဖစ္၀ူးဆိုရင္ IOS သည္ match တစ္ခုကို ေတြ့ရွိသည္အထိ list အတိုင္း ဆက္လက္ လုပ္ေဆာင္ပါလိမ့္မယ္။ အကယ္၍ list တစ္ခုလံုး process ျပဳလုပ္ျပီးတဲ့ေနာက္၊ ACL statements မ်ားနဲ့ packet contents ေတြၾကား match မျဖစ္၀ူးဆိုရင္ router သည္ packet ကို drop လုပ္ပါလိမ့္မယ္။ ACLs ရဲ့ top-down processing သည္ ေအာက္ပါ အေရးၾကီး အခ်က္ေတြကို လုပ္ေဆာင္တယ္:

match တစ္ခုကို ေတြ့ရွိသည္ႏွင့္ တျပိုင္နက္ list အတြင္းရွိ အျခား statements မ်ားကို ဆက္လက္ process မျပုလုပ္ပါ။
ပထမ match ရရွိျပီးတဲ့ေနာက္ အျခား statements မ်ားကို process မျပဳလုပ္ေတာ့တာမို့ statements order (အထက္ေအာက္ အစီအစဥ္) သည္ အေရးၾကီးပါသည္။
list အတြင္းမွာ match တစ္ခုမွ မေတြ့ရတဲ့အခါ packet ကို drop လုပ္ပစ္တယ္။

Chapter 22 : Access Control Lists (2)

2010-08-07T09:30:00.004+06:30

Types

ACLs မွာ အသြင္ကြဲ 2 မ်ိဳးရွိတယ္ : numbered and named နဲ့ standard and extended ။ numbered and named ACLs သည္ router က ACLs ကို ဘယ္လို ရည္ညႊန္းမလဲဆိုတာကို define လုပ္တယ္။ index value တစ္ခု နဲ့ ဆင္ဆင္တူပါတယ္။ numbered ACL ကို တိက်တဲ့ number တစ္ခုနဲ့ assign လုပ္ထားျပီး၊ named ACL ကို တိက်တဲ့ အမည္နာမ တစ္ခုနဲ့ assign လုပ္ထားတယ္။ ျပီးတဲ့ေနာက္မွာ router သည္ သူတို့ကို အသံုးျပဳျပီး traffic ကို filter လုပ္တယ္။

အထက္ပါ numberd နဲ့ named ACLs မ်ားသည္ filtering types 2 ခုကို support လုပ္တယ္: Standard နဲ့ extended။ Standard IP ACLs မ်ားသည္ packet တစ္ခုအတြင္းက source IP address အေပၚမွာသာ filter ျပဳလုပ္ႏိူင္တယ္။ Extended IP ACLs မ်ားသည္ source နဲ့ destiantion IP addresses မ်ား၊ IP protocol (TCP,UDP,ICMP အစရွိသည္)၊ နဲ့ protocol information (ဥပမာ TCP or UDP source နဲ့ destination numbers မ်ား၊ ဒါမွမဟုတ္ ICMP message types မ်ား) ေတြအေပၚမွာ filter ျပဳလုပ္ႏိူင္တယ္။

extended ACL တစ္ခုကို အသံုးျပဳတဲ့အခါ filtering မွာ ပိုမို တိတိက်က် သတ္မွတ္ႏိူင္တယ္။ ဥပမာ user`s PC တစ္လံုးမွ remote telnet server သို့ တိက်တဲ့ telnet session တစ္ခုကို filter ျပဳလုပ္ႏိူင္တယ္။ standard ACLs မွာေတာ့ ၄င္း ပံုစံမ်ိဳး မရရွိႏိူင္ပါ။ standard ACL တစ္ခုကို အသံုးျပဳျပီး၊ source device တစ္ခုမွ traffic အားလံုးကို permit သို့မဟုတ္ deny တစ္ခုခုသာ သတ္မွတ္ႏိူင္ပါတယ္။ Table 22-1 မွာ IP traffic အတြတ္ ၄င္း filtering types 2 ခုကို ႏွိဳင္းယွဥ္ ျပသထားပါတယ္။

exam watch
Table 22-1 မွ standard နဲ့ extended ACLs မ်ားရဲ့ filtering လုပ္ႏိူင္စြမ္း ကို မွတ္သားပါ။

Chapter 22: Access Control Lists (1)

2010-06-09T10:33:00.003+06:30

ပံုမွန္အားျဖင့္ routing ကို set up ျပုလုပ္ျပီးတဲ့အခါ၊ router သည္ interface တစ္ခုမွ အျခား interface တစ္ခုသို့ packet ေတြကို flow လုပ္ပါလိမ့္မယ္။ security ဒါမွမဟုတ္ traffic policy မ်ားအတြတ္ flow of traffic ကို ကန့္သတ္ဖို့ policies ေတြ implement ျပဳလုပ္ဖို့ လုိအပ္ေကာင္း လိုအပ္လာပါလိမ့္မယ္။ Cisco သည္ access control lists (ACLs) ေတြကို အသံုးျပဳျပီး interface တစ္ခုမွ အျခား interface တစ္ခုသို့ flow of traffic ကို ထိန္းခ်ုပ္တယ္။ ACLs (အသံထြက္=ackles) သည္ Internetwork Operating System (IOS) ရဲ့ power feature တစ္ခုျဖစ္တယ္။ Cisco သည္ IP အျပင္ အျခား protocols မ်ားျဖစ္တဲ့ Internetwork Packet Exchange (IPX) ၊ AppleTalk ၊ layer 2 traffic မ်ားအတြတ္လည္း ACLs ကို support လုပ္တယ္။ ဒီသင္ခန္းစာမွာ IP ACLs ကို focus လုပ္ပါမယ္။

ACL Overview

Interface တစ္ခုသို့ ၀င္ေရာက္လာတဲ့၊ ဒါမွမဟုတ္၊ interface တစ္ခုမွ ထြက္ခြာသြားတဲ့ traffics ေတြကို filter ျပဳလုပ္ႏိူင္စြမ္းရွိတဲ့ ACLs ကို IOS devices ေတြသို့ remote access (virtual type terminal, or VTY) ကို အကန့္အသတ္ျပဳလုပ္ဖို့၊ routing information ေတြကို filtering ျပုလုပ္ဖို့၊ traffic ေတြကို queuing နဲ့အတူ prioritizing ျပုလုပ္ဖို့၊ dial-on-demand routing နဲ့အတူ phone calls ေတြ triggering ျပုလုပ္ဖို့၊ routes ေတြရဲ့ administrative distance ကို အေျပာင္းအလဲ ျပုလုပ္ဖုိ့၊ နဲ့ IPSec VPN ကို အသံုးျပဳျပီး အကာအကြယ္ေပးရမယ့္ traffic ေတြကို specifying ျပဳလုပ္ဖို့ စတဲ့စတဲ့ အျခား ရည္ရြယ္ခ်က္မ်ားစြာအတြတ္လည္း အသံုးျပဳႏိူင္ပါတယ္။ ဒီသင္ခန္းစာမွာ router ကို ျဖတ္သန္း စီးဆင္းမယ့္ traffic ေတြကို အကန့္အသတ္ျပဳလုပ္ျခင္း အေပၚမွာ focus လုပ္ပါမယ္။

Exam watch!
IOS device ကို ျဖတ္သန္းမယ့္ traffic ကို filtering ျပဳလုပ္ဖို့ ACLs ကို အသံုးျပဳႏိူင္သလို၊ IOS ရဲ့ VTY lines မ်ားသို့ access ျပလုပ္မယ့္ remote access traffic ေတြကို filtering ျပဳလုပ္ဖို့အတြတ္လည္း ACLs ကို အသံုးျပဳႏိူင္တယ္။

Defination

အေျခခံအားျဖင့္ ACLs ဆိုသည္မွာ interface တစ္ခုသို့ အ၀င္အထြက္ traffic ေတြကို filter ျပုလုပ္ရာမွာ အသံုးျပဳတဲ့ commands ေတြကို၊ အမည္ ဒါမွမဟုတ္ နံပါတ္ တစ္ခုနဲ့ group ျပုထားတဲ့ commands set တစ္ခုျဖစ္တယ္။ ACL commands မ်ားသည္ permit or deny ျပဳလုပ္ရမယ့္ traffic ကို အတိအက် သတ္မွတ္ပါတယ္။ ACLs ေတြကို Global Configuration mode မွာ create လုပ္ရပါမယ္။

ACL statements အစုတစ္ခုကို create လုပ္ျပီးတဲ့အခါ၊ သူတို့ကို activate ျပုလုပ္ေပးရမယ္။ interfaces မ်ားအၾကား traffic ကို filtering ျပုလုပ္ဖို့အတြတ္ Interface Subconfiguration mode မွာ ACL ကို activate ျပလုပ္ရပါမယ္။ ၄င္း interface သည္ physical (ဥပမာ ethernet 0 or serial0) ဒါမွမဟုတ္ logical (ဥပမာ ethernet0.1 or serial0.1) ျဖစ္ႏိူင္ပါတယ္။ interface တစ္ခုေပၚမွာ ACL ကို activate ျပဳလုပ္တဲ့အခါ၊ မည္သည့္ direction အတြင္းမွာ traffic ကို filter ျပဳလုပ္မည္ဆိုသည္ကို သတ္မွတ္ေပးရပါမယ္ :

Inbound (external source တစ္ခုမွ interface သို့ traffic ၀င္ေရာက္လာတဲ့အခါ)
Outbound (interface တစ္ခုမွ network သို့ traffic ထြက္ခြာသြားတဲ့အခါ)

Inbound ACLs မွာ IOS သည္ ၀င္ေရာက္လာတဲ့ traffic ကို အျခား interface တစ္ခုသို့ forward မျပုလုပ္မွီ၊ interface ACL နဲ့ compare ျပုလုပ္တယ္။ outbound ACLs မွာ packet ကို interface တစ္ခုမွာ လက္ခံရယူျပီး exit interface သို့ forward ျပုလုပ္တယ္၊ ျပီးမွ packet ကို ACL နဲ့ comapre ျပုလုပ္တယ္။

ACLs ရဲ့ အကန့္အသတ္တစ္ခုမွာ router ကိုယ္တိုင္မွ အစျပဳတဲ့ traffic ကို filter မလုပ္ႏိူင္ျခင္းပဲ ျဖစ္တယ္။ ဥပမာ router မွ ping or traceroute ျပဳလုပ္တဲ့အခါ၊ ဒါမွမဟုတ္ router မွ အျခား device တစ္ခုသို့ telnet ျပုလုပ္တဲ့အခါ၊ router ရဲ့ interfaces မ်ားမွာ apply ျပုလုပ္ထားတဲ့ ACLs မ်ားသည္ ၄င္း အထြက္ connections မ်ားကို filter မလုပ္ႏိူင္ပါ။ ဒါေပမယ့္ external device တစ္ခုသည္ router သို့ ၊ ဒါမွမဟုတ္ router ကို ျဖတ္လ်က္ remote destination တစ္ခုသို့ ၊ ping or traceroute or telnet လုပ္ဖို့ ၾကိဳးစားတဲ့အခါ ၊ router သည္ ၄င္း packets ေတြကို filter လုပ္ႏိူင္တယ္။

Exam watch!
Inbound ACLs မွာ IOS သည္ အျခား processing မ်ားမျပုလုပ္မွီ ACLs ကို ဦးစြာ process လုပ္တယ္။ outbound ACLs အတြတ္မူ packet ကို interface သို့ route ျပုလုပ္ျပီးေနာက္မွသာ ACL ကို process လုပ္တယ္။ interfaces မ်ားသို့ apply ျပုလုပ္ထားတဲ့ outbound ACLs မ်ားကို IOS ကိုယ္တိုင္မွ အစျပဳတဲ့ traffic ေတြကို filter လုပ္ဖို့ အသံုးမျပဳႏိူင္ပါ။

Chapter 8 : VLSM (11)

2010-05-28T21:12:00.005+06:30

The Routing Table

Route summarization ကို implement ျပုလုပ္တဲ့အခါ ၊ router သည္ IP packet header ထဲက destination IP address တစ္ခုလံုးအေပၚမွာ routing decisions ေတြ ျပဳလုပ္ရမယ္ဆိုတဲ့ အခ်က္ကိုလည္း ထည့္သြင္း စဥ္းစားရမယ္။ router သည္ သူ့ရဲ့ routing decision ကို လုပ္ေဆာင္ဖို့ routing table ထဲက longest matching prefix ကို အျမဲ အသံုးျပဳတယ္။ Table 8-2 မွ routing table ကို အသံုးျပဳျပီး router တစ္လံုးရဲ့ decision-making process ကို ရွင္းလင္းပါမယ္။

Router သည္ inbound packet တစ္ခုကို သူ့ရဲ့ interface တစ္ခုေပၚမွာ လက္ခံရယူျပီးေနာက္ packet header ထဲက destination IP address ကို examine လုပ္ပါတယ္ : ဒီဥပမာမွာ 172.16.17.65 ျဖစ္မယ္။ ၄င္းေနာက္မွာ router သည္ သူ့ရဲ့ routing table ကို examine လုပ္တယ္၊ packet အတြတ္ best match ကို ရွာေဖြတယ္၊ ျပီးတဲ့ေနာက္မွာ destination သို့ ေရာက္ရွိဖို့ သက္ဆိုင္တဲ့ interface မွာ packet ကို route လုပ္တယ္။ အေျခခံအားျဖင့္ router သည္ entries ေတြကို mask bits အေရအတြတ္ အမ်ားဆံုးမွသည္ bits အေရအတြတ္ အနည္းဆံုးသို့ sort လုပ္တယ္။

routing table မွာ entry 1 သည္ valid match မျဖစ္ပါ။ အဘယ္ေၾကာင့္ဆိုေသာ္ entry အတြတ္ mask သည္ 32-bit ျဖစ္ေနတာမို့ ျဖစ္တယ္ (host address)။ 172.16.17.66 ရဲ့ 32 bits ကို 172.16.17.65 ရဲ့ 32 bits နဲ့ compare လုပ္တဲ့အခါ match မျဖစ္ပါ။ ပံုမွန္အားျဖင့္ host တစ္ခုကို သူ့ရဲ့ မူလ network segment မွ အျခား segment သို့ ေရြ့ေျပာင္းတဲ့အခါတိုင္း host address routes ေတြကို routing table အတြင္းမွာ ေနရာခ်တယ္။ ဒါေပမယ့္ host ရဲ့ address ကို segment အသစ္နဲ့ ကိုက္ညီတဲ့ address သို့ မေျပာင္းလဲႏိူင္ပါ။ logistical purpose အတြတ္၊ host သည္ သူရဲ့ IP address အေဟာင္းကို ဆက္လက္ retain လုပ္ထားဖို့ လိုအပ္တယ္။

Routing table ထဲက entry 2 ကို compare လုပ္တဲ့အခါ၊ router သည္ 172.16.17.64 ရဲ့ ပထမ 27 bits ကို 172.16.17.65 ရဲ့ ပထမ 27 bits နဲ့ compare လုပ္တယ္။ match ျဖစ္တယ္။ entry 3 ကို compare လုပ္တဲ့အခါ၊ router သည္ 172.16.17.0 ရဲ့ ပထမ 24 bits ကို 172.16.17.64 ရဲ့ ပထမ 24 bits နဲ့ compare လုပ္တယ္။ match ျဖစ္တယ္။ entry 4 ကို compare လုပ္တဲ့အခါ၊ router သည္ 172.16.0.0 ရဲ့ ပထမ 16 bits ကို 172.16.17.65 ရဲ့ ပထမ 16 bits နဲ့ compare လုပ္တယ္။ match ျဖစ္တယ္။

Entry 5 ကို compare လုပ္တဲ့အခါ၊ ၄င္း entry သည္ default route တစ္ခုျဖစ္ျပီး packet အားလံုးနဲ့ match ျဖစ္ေၾကာင္း router က သိရွိတယ္။ ဒါေၾကာင့္ ဒီဥပမာမွာ ပထမ entry တစ္ခုသာ match မျဖစ္ဘဲ က်န္ entry 4 ခုစလံုး match ျဖစ္တယ္။ router သည္ route တစ္ခုကို ေရြးခ်ယ္ယူျပီး packet ကို destination သို့ route လုပ္ဖို့ အသံုးျပဳတယ္။ entry ကို ေရြးခ်ယ္တဲ့အခါ matching bits အေရအတြတ္ အမ်ားဆံုးျဖစ္တဲ့ best matches တစ္ခုကို အသံုးျပဳပါတယ္။ ဒါေၾကာင့္ router table ထဲက entry 2 ကို အသံုးျပဳျပီး ၄င္း packet ကို သူ့ရဲ့ သက္ဆိုင္တဲ့ destination သို့ route လုပ္ပါလိမ့္မယ္။

Exam watch!
ေပးထားတဲ့ destination IP address တစ္ခုအတြတ္ မွန္ကန္တဲ့ entry တစ္ခုကို မည္သို့ မည္ပံု ေရြးခ်ယ္ယူသလဲ ဆိုတာကို မွတ္သားပါ : destination address နဲ့ compare လုပ္တဲ့အခါ matching bits အေရအတြတ္ အမ်ားဆံုးျဖစ္တဲ့ entry ကို အသံုးျပဳတယ္။

Chapter 8 : VLSM (10)

2010-05-27T11:33:00.003+06:30

Routing and Subnet Masks

Route summarization ရဲ့ အားသာခ်က္ကို ရယူအသံုးခ်ဖို့ ဆိုရင္ routing protocol သည္ subnet mask နဲ့အတူ သူ့ရဲ့ သက္ဆိုင္တဲ့ network entries ေတြကို သယ္ယူရပါမယ္။ အဲလိုမွမဟုတ္ရင္ ၊ class network number တစ္ခုသို့ subnet mask တစ္ခုထက္ပိုျပီး apply ျပဳလုပ္ထားတဲ့အခါ ၊ destination တစ္ခုသို့ packet ကို routing ျပဳလုပ္ဖို့ router သည္ မည္သည့္ mask ကို အသံုးျပဳရမည္ဆိုသည္ကို မသိဘဲ ျဖစ္လိမ့္မယ္။

၄င္း ျပႆနာရဲ့ ဥပမာကို RIPv1 လို classful protocols မ်ားမွာ ေတြ့ႏိူင္တယ္။ classful protocols မ်ားမွာ routing updates ေတြကို network entries တစ္ခုထည္းနဲ့သာ ထုတ္လႊတ္တယ္ ၊ subnet masks မ်ား မပါ၀င္ပါ။ အျခား segments မ်ားေပၚမွ routers မ်ားသည္ တူညီတဲ့ class network သို့ ခ်ိတ္ဆက္ထားၾကျပီး သူတို့ရဲ့ interfaces မ်ားမွာ subnet mask ကို configure ျပဳလုပ္ထားျပီး ျဖစ္တာမို့ routers မ်ားသည္ subnet mask ကို သိရွိျပီး ျဖစ္တယ္လို့ ယူဆတယ္။

network number တစ္ခု class network တစ္ခုမွ အျခား တစ္ခုသို့ ျဖတ္သန္းတဲ့အခါ classful protocol သည္ ၄င္း network number ကို class address network number (Class A,B, or C) အျဖစ္သို့ အလိုအေလ်ာက္ summarize ျပဳလုပ္ပါလိမ့္မယ္ ၊ Figure 8-9 ရဲ့ အေပၚဘက္ပံုမွာ ျပသထားတယ္။ ၄င္းပံုမွာ ေတြ့ျမင္ရသလိုပါပဲ ၊ classful protocol သည္ subnet number မပါ၀င္ဘဲ network number (172.16.0.0) တစ္ခုထည္းကိုသာ advertise လုပ္တယ္။ ဒါ့အျပင္ network number သည္ class boundary (172.16.0.0 မွ 192.168.1.0) ကို ျဖတ္သန္းတဲ့အခါ subnet (172.16.1.0) ကို advertise မလုပ္ဘဲ class network number (172.16.0.0) ကိုသာ advertise လုပ္တယ္။ Figure 8-9 ရဲ့ ေအာက္ဘက္မွာ class boundary တစ္ခုကို ျဖတ္သန္းတဲ့အခါ classless protocols ေတြ ဘယ္လို တုန့္ျပန္သလဲဆိုတာကို ျပသထားတယ္။ အခ်က္ 2 ခ်က္ကို သတိျပုပါ : routing update မွာ subnet mask ပါ၀င္တယ္ ၊ routing update ကို class boundary တေလ်ာက္ အလိုအေလ်ာက္ summarize မလုပ္ပါ။

On the job!
RIPv@ နဲ့ EIGRP တို့သည္ default မွာ classful protocols အျဖစ္ လုပ္ေဆာင္တယ္။ ဒါေၾကာင့္ network class buondary တေလ်ာက္ အလိုအေလ်ာက္ summarize လုပ္လိမ့္မယ္။ ၄င္းကို manually disable ျပဳလုပ္ႏိူင္တယ္။ summariz ျပုလုပ္ရမယ့္ routes ေတြကိုလည္း တိတိက်က် သတ္မွတ္ေပးထားႏိူင္ပါတယ္။ OSPF သည္ default မွာ classless protocol အျဖစ္ လုပ္ေဆာင္တယ္။ မည္သည့္ routing information တစ္ခုကုိမွ အလိုအေလ်ာက္ summarize ျပဳလုပ္လိမ့္မည္ မဟုတ္ပါ။ ဒါေၾကာင့္ OSPF မွာ summarization ကို manually configure ျပဳလုပ္ရပါမယ္။

Classful protocols မ်ားရဲ့ routing behavior သည္ addressing designs အခ်ိဳ့မွာ ျပႆနာ ျဖစ္ေပၚေစတယ္။ Figure 8-10 ရဲ့ အေပၚဘက္ပံုကို ၾကည့္ပါ။ RIPv1 လို classful protocol နဲ့အတူ routers မ်ားသည္ class boundary တစ္ခုကို ျဖတ္သန္းျပီး networks ေတြကို advertise လုပ္တဲ့အခါ သူတို့ရဲ့ class boundary သို့ ျပန္လည္ summarize လုပ္တယ္။ ၄င္း ဥပမာမွာ RouterA နဲ့ RouterB ႏွစ္ခုစလံုးသည္ 172.16.0.0 ကို advertise လုပ္တယ္ : 172.16.0.0 အတြတ္ သူတို့ရဲ့ သီးျခား subnets ေတြကို advertise မလုပ္ပါ။ ၄င္းသည္ 172.16.0.0 အတြတ္ routes 2 ခု လက္ခံရရွိတဲ့ RouterC ကို ျပႆနာ ျဖစ္ေစတယ္။ RouterC သည္ 172.16.1.0/24 သို့ ေရာက္ရွိလိုတဲ့အခါ သူ့ရဲ့ packets ေတြကို (RouterA နဲ့ RouterB) မည္သည့္ router သို့ ေပးပို့ရမည္ဆိုသည္ကို မသိေတာ့ပါ။

တကယ့္လက္ေတြ့မွာ ျဖစ္စဥ္သည္ ၄င္းထက္ ပိုမိုရွဳပ္ေထြးတယ္။ အေျခခံ RIP implementation တစ္ခုမွာ ၊ RouterC သည္ လက္ခံရရွိတဲ့ ေနာက္ဆံုး update ကို သူ့ရဲ့ routing table ထဲမွာ ထည့္သြင္းမွာ ျဖစ္ျပီး packet ကို ၄င္း interface မွတဆင့္ ထို router သို့ deliver လုပ္မွာျဖစ္တယ္။ RouterA ဒါမွမဟုတ္ RouterB ႏွစ္ခုအနက္ မည္သည့္ router သို့ packet ကို ေပးပို့မည္ဆိုသည္မွာ route updates ကို RouterC က လက္ခံရရွိတဲ့ အခ်ိန္အေပၚမွာ မူတည္ေနပါတယ္။ အကယ္၍ EIGRP ကို routing protocol အျဖစ္ အသံုးျပဳမည္ဆိုလွ်င္ metric ကို အသံုးျပဳျပီး ပိုမို ေကာင္းမြန္တဲ့ route ကို ေရြးခ်ယ္ဆံုးျဖတ္မွာမို့ အေကာင္းဆံုး metric နဲ့ associate ျဖစ္တဲ့ route သို့ packet ေတြ သြားပါလိမ့္မယ္။

၄င္း network design ကို discontiguous subnet design အျဖစ္ ရည္ညႊန္းပါတယ္ : subnets အားလံုးကို အတူတကြ ခ်ိတ္ဆက္မထားပါ။ 172.16.1.0/24 နဲ့ 172.16.2.0/24 networks မ်ားကို 172.168.0.0 မွတဆင့္ ခ်ိတ္ဆက္ထားတယ္။ ၄င္းသည္ 172.16.0.0 network သို့ ခ်ိတ္ဆက္မထားတဲ့ အျခား routers မ်ားအတြတ္ routing ျပႆနာ ျဖစ္ေပၚေစတယ္။ ဒါေၾကာင့္ discontiguous subnet designs မ်ားကို classful protocols မ်ားနဲ့အတူ အသံုးမျပဳသင့္ပါ။

ဒါေပမယ့္ classless protocols မ်ားသည္ discontiguous subnets ေတြကို support လုပ္တယ္။ Figure 8-10 ရဲ့ ေအာက္ဘက္ပံုမွာ classless protocols ေတြသည္ routing updates ေတြထဲမွာ subnet mask ကို ထည့္သြင္းတယ္။ routing updates မ်ားအတြင္းမွာ mask ေတြ ပါရွိတာမို့ ၄င္း ဥပမာမွာ RouterC သည္ 172.16.1.0/24 နဲ့ 172.16.2.0/24 networks ေတြ ဘယ္ေနရာမွာ ရွိသလဲဆိုတာကို အတိအက် သိတယ္။ ဒါေပမယ့္ routing information ေတြကို အေကာင္းဆံုး အထိေရာက္ဆံုး ပံုစံနဲ့ summarize ျပဳလုပ္ႏိူင္ဖို့ အကန့္အသတ္ေတြ ရွိေနတာမို့ discontiguous subnets ေတြကို classless protocols မ်ားနဲ့ေတာင္ အတူအသံုးမျပဳဖို့ recommend လုပ္ၾကတယ္။ routing protocols မ်ားအေၾကာင္း နဲ့ routing tables ေတြ ဘယ္လို တည္ေဆာက္သလဲဆိုတာကို Chapters 15, 19, 20, နဲ့ 21 တို့မွာ ေဆြးေႏြးပါမယ္။ ယခု သင္ခန္းစာမွာ အဓိကအခ်က္ ကို မွတ္သားပါ : classful routing protocols ေတြသည္ network boundaries ေတြကို ျဖတ္လ်က္ classful network number ကို advertise ျပုလုပ္တယ္။

Exam watch!
discontiguous subnets မ်ားကို classful protocols မ်ားက support မလုပ္ပါ။ classless protocols မ်ားကသာ support လုပ္တယ္။ classful protocols မ်ားသည္ network နဲ့ subnet numbers မ်ားကို advertise ျပဳလုပ္တဲ့အခါ subnet mask ကို မထည့္သြင္းပါ။

Chapter 8 : VLSM (9)

2010-05-26T11:15:00.004+06:30

Hierarchical Addressing

Route summarization ျပုလုပ္ဖို့ မိမိရဲ့ addressing ကို hierarchical ပံုစံနဲ့ set up လုပ္ဖို့ လိုအပ္တယ္။ hierarchical addressing ျပဳလုပ္ျခင္းျဖင့္ ေအာက္ပါ အားသာခ်က္ေတြကို ရရွိမယ္ :

routing ကို ပိုမို efficient ျဖစ္ေစတယ္။
routing tables ေတြရဲ့ size ကို ေလ်ာ့ခ်ဖို့ route summarization ကို အသံုးျပဳတယ္။
အရြယ္အစား ပိုမို ေသးငယ္တဲ့ routing tables ေတြကို store ျပုလုပ္ဖို့ လိုအပ္တဲ့ memory ပမာဏ ကို ေလ်ာ့ခ်တယ္။
routing table ကို ျပန္လည္ တည္ေဆာက္ဖို့ လိုအပ္တဲ့အခါ router အေပၚ သက္ေရာက္မွဳ ကို ေလ်ာ့ခ်တယ္။
troubleshooting လုပ္ေဆာင္တဲ့အခါ ပိုမို ရွင္းလင္း လြယ္ကူေစတယ္။

Exam watch!
hierarchical addressing ရဲ့ အားသာခ်က္ေတြကို မွတ္သားပါ။

Figure 8-8 မွာ hierarchical addressing ရဲ့ ရိုးရွင္းတဲ့ ဥပမာ တစ္ခုကို ျပသထားတယ္။ ၄င္း ဥပမာမွာ network သည္ 10.0.0.0/8 ကို အသံုးျပဳထားတယ္။ ၄င္းသည္ အျခား network သို့ မေပးပို့မွီ summarize ျပုလုပ္ထားတဲ့ network number ျဖစ္တယ္။ ၄င္း addressing space သည္ 10.1.0.0/16 ၊ 10.2.0.0/16 နဲ့ 10.3.0.0/16 အျဖစ္ campus 3 ခုသို့ ခြဲျဖာသြားတယ္၊ campus မ်ားအၾကား routes ေတြကို share ျပုလုပ္တဲ့အခါ ၄င္း addresses sets အသီးသီးကို summarize ျပဳလုပ္တယ္။ campus တစ္ခုစီအတြင္းမွာ buildings 2 ခုအတြတ္ addressing ကို ထပ္မံ ခြဲျဖာပါတယ္ : 10.x.1.0/24 ၊ 10.x.2.0/24 ... စသည္ျဖင့္ ။

hierarchical addressing design ကို implement ျပလုပ္ဖို့ နဲ့ route summarization ရဲ့ အားသာခ်က္ကို ရယူအသံုးျပဳဖုိ့ VLSM ကို support လုပ္တဲ့ routing protocol တစ္ခု လိုအပ္တယ္: BGP ၊ EIGRP ၊ IS-IS ၊ OSPF or RIPv2 ။ route summarization ကို implement ျပုလုပ္တဲ့အခါ ေအာက္ပါအခ်က္ေတြကို ထည့္သြင္း စဥ္းစားဖို့ လိုအပ္တယ္ :

routing protocol သည္ advertising ျပဳလုပ္မယ့္ network entries နဲ့ သက္ဆိုင္တဲ့ subnet ကို သယ္ယူရမယ္။
destination IP address တစ္ခုလံုးအေပၚမွာ routing decision ကိုလုပ္ေဆာင္ရမယ္။
route entries ေတြကို summarize လုပ္ဖို့ ၊ သူတို့ အားလံုးမွာ တူညီတဲ့ highest order matching bits ေတြ ရွိေနရမယ္ (Table 8-1 ကို ၾကည့္ပါ) ။

Exam watch!
route summarization ျပဳလုပ္တဲ့အခါ အထက္ပါ အခ်က္ 3 ခ်က္ကုိ သတိရပါ။

Chapter 8 : VLSM (8)

2010-05-25T09:09:00.002+06:30

Classless Interdomain Routing

RFC 2050 မွာ specify ျပဳလုပ္ထားတဲ့ Classless Interdomain Routing (CIDR) သည္ VLSM နဲ့ route summarization တို့ရဲ့ extension တစ္ခုျဖစ္တယ္။ VLSM မွာ subnets ေတြကို Class A ၊ B ဒါမွမဟုတ္ C network boundary သို့ ျပန္လည္ summarize လုပ္ႏိူင္တယ္။ ဥပမာ Class C network 192.168.1.0/24 ကို 26-bit mask နဲ့ subnet ျပဳလုပ္တဲ့အခါ subnets 4 ခု ရရွိမွာ ျဖစ္တယ္။ VLSM နဲ့ summarization ကို အသံုးျပဳျခင္းျဖင့္ ၄င္း subnets 4 ခုကို 192.168.1.0/24 သို့ ျပန္လည္ summarize ျပဳလုပ္ႏိူင္တယ္။ CIDR သည္ ၄င္း လုပ္ေဆာင္ခ်က္ထက္ တစ္ဆင့္ပိုမို လုပ္ေဆာင္တယ္၊ တဆက္ထည္း ရွိေနတဲ့ Class A၊ B နဲ့ C network numbers အစုတစ္ခုကို summarize ျပဳလုပ္ႏိူင္တယ္။ ၄င္း လုပ္ေဆာင္ခ်က္ကို supernetting အျဖစ္ ရည္ညႊန္းၾကတယ္။ ဒီေန့ေခတ္ classless protocols အားလံုးသည္ supernetting ကို support လုပ္တယ္။ ဒါေပမယ့္ အမ်ားအားျဖင့္ BGP ကို routing protocol အျဖစ္ အသံုးျပဳတဲ့ ISP ကသာလွ်င္ supernetting ကို configure လုပ္ပါတယ္။

Figure 8-7 မွာ CIDR ဥပမာ တစ္ခုကို ျပသထားတယ္။ ၄င္း ဥပမာမွာ router သည္ Class C networks 4 ခုသို့ ခ်ိတ္ဆက္ထားတယ္ : 192.168.0.0/24 ၊ 192.168.1.0/24 ၊ 192.168.2.0/24 နဲ့ 192.168.3.0 ။ router သည္ ၄င္း routes မ်ားကို single entry တစ္ခုအျဖစ္ summarizing ျပုလုပ္ထားတယ္ : 192.168.0.0/22 ။

Table 8-1 မွာ networks 4 အခုအတြင္းရွိ common ျဖစ္တဲ့ bits ေတြကို ျပသထားတယ္။ networks 4 ခုရဲ့ ပထမ 2 bytes အားလံုး တူညီတယ္ : 192.168 ၊ တတိယ octet မွာ ပထမ 6 bits တူညီတယ္။ ဒါေၾကာင့္ စုစုေပါင္း bits အေရအတြတ္ 22 ခု တူညီတယ္။ ၄င္း summarization အတြတ္ subnet mask သည္ 255.255.252.0 ျဖစ္တယ္ဆုိတာ သတိျပဳပါ။ 192.168.0.0 network ကို ၄င္း mask နဲ့ တြဲစပ္ျခင္းျဖင့္ 192.168.0.0 မွသည္ 192.168.3.255 အထိ addresses အားလံုး ပါ၀င္သြားျပီး၊ ၄င္း addresses မ်ားအားလံုး router ရဲ့ ေနာက္မွာ ရွိေနမယ္။

Exam watch!
CIDR သည္ VLSM နဲ့ ဆင္တူတယ္။ CIDR သည္ တဆက္ထည္း ရွိေနတဲ့ class networks ေတြ အားလံုးကို အတူတကြ summarize ျပဳလုပ္ႏိူင္တယ္။ ၄င္းကို supernetting လို့လည္း ေခၚတယ္။

Chapter 8 : VLSM (7)

2010-05-23T15:04:00.004+06:30

Advantage of Summarization

Summarization သည္ ေအာက္ပါ အားသာခ်က္မ်ားကို provide ျပဳလုပ္ျခင္းျဖင့္ ပိုမို ေကာင္းမြန္တဲ့ routing enviroment တစ္ခုကို ဖန္တီးေပးတယ္ :

routing tables size ကို ေလ်ာ့ခ်ျခင္းျဖင့္ memory နဲ့ processing လိုအပ္ခ်က္ကို ေလ်ာ့နည္းေစတယ္။
routing updates size ကို ေလ်ာ့ခ်ျခင္းျဖင့္ bandwidth လိုအပ္ခ်က္ကို ေလ်ာ့နည္းေစတယ္။
routing flapping လိုမ်ိဳး network ျပႆနာမ်ား မေပၚေပါက္ေစဖို့ ထိန္းသိမ္း တားဆီးေပးတယ္။

Figure 8-6 မွာ ျပသထားတဲ့ design ကို ၾကည့္ျခင္းအားျဖင့္ routing table update အရြယ္အစားကို routers 4 ခု router 1 ခုသို့ ေလ်ာ့ခ်ထားေၾကာင္း ေတြ့ရမယ္။ ဒါေၾကာင့္ information ေတြကို လက္ခံရယူမယ့္ routers မ်ားအတြတ္ processing အနည္းငယ္မွ်သာ လိုအပ္ပါေတာ့မယ္။ ထို့အတူ update ကို advertise လုပ္ဖို့ bandwidth အနည္းငယ္သာ လိုအပ္မွာ ျဖစ္သလို လက္ခံရယူတဲ့ routers မ်ားမွာလည္း update ကို process လုပ္ဖို့ memory နဲ့ processing အနည္းငယ္သာ လိုအပ္မွာ ျဖစ္တယ္။

Route summarization ရဲ့ အျခား အားသာခ်က္တစ္ခုမွာ network ျပႆနာ အခ်ိဳ့ မျဖစ္ေပၚေစဖို့ ထိန္းသိမ္း ကာကြယ္ေပးႏိူင္ျခင္း ျဖစ္တယ္။ ဥပမာ 192.168.1.64/26 သည္ up and down ျဖစ္ေနတယ္ ဆိုပါစို့ (flapping route)။ ၄င္း အေျခအေနသည္ ခ်ိတ္ဆက္ထားတဲ့ router နဲ့ ၄င္း up and down ျဖစ္ေနတဲ့ subnet ကို သိတဲ့ အျခား routers မ်ားသို့ သက္ေရာက္မွဳ ျဖစ္ေစတယ္။ ၄င္း route .. up down ျဖစ္တဲ့ အၾကိမ္တိုင္းမွာ အျခား routers မ်ားသည္ ၄င္း အေျပာင္းအလဲကို သူတို့ရဲ့ routing tables မ်ားထဲမွာ incorporate လုပ္ၾကရတယ္။ ဒါေပမယ့္ summarized route ကိုသာ သိတဲ့ routers မ်ားသည္ flapping ျဖစ္ေနတဲ့ subnet ရဲ့ သက္ေရာက္မွဳ ကို မခံၾကရပါ။ ၄င္း routers ေတြအေပၚ သက္ေရာက္မွဳ ျဖစ္ေစလိုလွ်င္၊ subnets 4 ခုစလံုးကို fail ျဖစ္ေစျပီး summarization လုပ္ေဆာင္တဲ့ router ရဲ့ summarized route advertising ျပဳလုပ္ေနျခင္းကို ရပ္တန့္ပစ္ဖို့ လိုအပ္ပါမယ္။

၄င္းအခ်က္သည္ သိသာတဲ့ အားသာခ်က္ ျဖစ္သည္မွန္ေသာ္လည္း အားနည္းခ်က္ တစ္ခု ရွိေနတယ္။ route summarization သည္ network ရဲ့ complete picture ကို ဖုံးကြယ္ထားတယ္။ ၄င္း အခ်က္သည္ routers မ်ားကို ေကာက္ခ်က္ခ် လြဲမွားမွဴမ်ား (bad assumpations) မ်ား ျဖစ္ေစတယ္။ ဥပမာ 192.168.1.64/26 သည္ အမွန္ကတယ္ down ေနတယ္လို့ ယူဆၾကည့္ၾကမယ္။ ဒါေပမယ့္ networks ရဲ့ အျခား အစိတ္အပိုင္းမွာ ရွိေနတဲ့ routers မ်ားသည္ summarized route 192.168.1.0/24 နဲ့ ပက္သက္ေနတဲ့ updates ေတြကို ဆက္လက္ လက္ခံရရွိေနမွာ ျဖစ္တယ္။ ၄င္း routers မ်ားရဲ့ ရွဳေထာင့္မွ ၾကည့္မယ္ဆိုရင္ route summarization ျပဳလုပ္ေနတဲ့ router သည္ ၄င္း route ကို advertising ဆက္လက္ ျပုလုပ္ေနတာမို့ 192.168.1.0 မွသည္ 192.168.1.255 အထိ addresses အားလံုး available ျဖစ္ေနပါတယ္။ ဒါေၾကာင့္ ၄င္း routers မ်ားသည္ 192.168.1.64/26 သို့ reachable ျဖစ္တယ္လို့ ယူဆျပီး traffic ေတြ ဆက္လက္ ေပးပို့ေနမွာျဖစ္တယ္။

Chapter 8 : VLSM (6)

2010-05-16T23:33:00.002+06:30

Route Summarization

Route summarization သည္ routing table အတြင္းမွာ ရွိေနတဲ့ contiguous network numbers အစုတစ္ခုကို ယူျပီး ၊ ၄င္း contiguous routes ေတြကို summarized or aggregated route တစ္ခုထည္း အျဖစ္ advertise ျပဳလုပ္ႏိူင္စြမ္းတဲ့ ability ျဖစ္တယ္။ VLSM သည္ subnetted routes ေတြကို class boundary သို့ ျပန္လည္ summarize ျပဳလုပ္ႏိူင္ေစတယ္။ ဥပမာ အကယ္၍ မိမိမွာ 192.168.1.0/24 ရွိေနျပီး ၄င္းကို 192.168.1.0/26 သို့ subnetted ျပုလုပ္တဲ့အခါ networks 4 ခု ရရွိလာမွာျဖစ္ျပီး ၄င္း subnets ေတြကို မိမိရဲ့ routing table အတြင္းမွာ summarize ျပဳလုပ္ႏိူင္မွာျဖစ္ျပီး ၊ Class C network number 192.168.1.0/24 အျဖစ္ advertise ျပဳလုပ္ႏိူင္မွာ ျဖစ္တယ္။ Figure 8-6 မွာ ျပသထားပါတယ္။ ၄င္း ဥပမာမွာ မိမိရဲ့ routing updates အတြင္းမွာ routing entries ေတြကို 4 ခု 1 ခုအျဖစ္သို့ ေလ်ာ့ခ်ထားတာ ေတြ့ရမယ္။ ထို့အတူ ၄င္း ဥပမာမွာ 192.168.1.0 network တစ္ခုထည္းကို 255.255.255.192 ၊ 255.255.255.0 masks 2 ခုနဲ့ associated ျပုလုပ္ထားတာကို သတိျပဳပါ။

Summarization သည္ VLSM ရဲ့ သြင္ျပင္တစ္ခုပင္ ျဖစ္တယ္။ VLSM နဲ့အတူ subnet mask ကို ညာဖက္သို့ ခ်ဲ့ထြင္သြားႏိူင္ျပီး summarization နဲ့အတူ address ရဲ့ ဘယ္ဖက္သို့ ျပန္လည္ collasp လုပ္ယူႏိူင္ပါတယ္။

Chapter 8 : VLSM (5)

2010-05-16T23:03:00.002+06:30

VLSM Example 2

ေနာက္ထပ္ ဥပမာ တစ္ခု နဲ့ ထပ္မံ ေဆြးေႏြးမယ္။ Figure 8-4 ကို ၾကည့္ပါ။ Class C network: 192.168.3.0/24 တစ္ခု ရရွိထားမွာ ျဖစ္ျပီး addressing လိုအပ္ခ်က္ေတြကို ပံုမွာ ျပသထားတယ္။ Class C network တစ္ခုနဲ့အတူ network segments အားလံုးကို accommodate ျဖစ္ေစဖို့ VLSM ကို အသံုးျပဳ ေျဖရွင္းမယ္။

Host addresses 126 ခု လိုအပ္တဲ့ backbone router segment သည္ အၾကီးဆံုး ျဖစ္တာမို့ ၄င္း subnet ကို စတင္ ေဆာင္ရြက္မယ္။ hosts အေရအတြတ္ 126 ခုကို ေျပလည္ေစမယ့္ subnet mask တစ္ခုကို အသံုးျပဳဖို့ လိုအပ္မယ္ : 255.255.255.128 (/25) ျဖစ္ပါမယ္။ ၄င္း subnet mask မွာ subnets 2 ခု ရရွိမယ္ : 192.168.3.0/25 နဲ့ 192.168.3.128/25 တို့ ျဖစ္တယ္။ ပထမ subnet ကို backbone router သို့ assign ျပဳလုပ္ျပီး ဒုတိယ subnet ကို VLSM နဲ့အတူ ေနာက္ထပ္ subnetting ျပဳလုပ္ဖို့ ခ်န္ထားမယ္။

ေနာက္တစ္ဆင့္မွာ ဒုတိယအၾကီးဆံုး subnet ျဖစ္တဲ့ router LAN segments ေတြကို ကိုင္တြယ္ေျဖရွင္းမယ္။ ၄င္း location အသီးသီးမွာ hosts အေရအတြတ္ 30 ကို ေျပလည္ေစမယ့္ networks ေတြ လိုအပ္တယ္။ အေစာက က်န္ေနတဲ့ subnet 192.168.3.128/25 ကို ယူျပီး remote site`s addresses မ်ားကို provide လုပ္ႏိူင္မယ့္ mask တစ္ခု ကို သတ္မွတ္ပါမယ္။ 255.255.255.224 (/27) ျဖစ္ပါမယ္။ ေအာက္ပါ subnets ေတြ ရရွိမယ္ : 192.168.3.128/27 ၊ 192.168.3.160/27 ၊ 192.168.3.192/27 နဲ့ 192.168.3.224/27 ။

အခုအခါ hosts 30 စီ ပါ၀င္တဲ့ subnets 4 ခု ရွိေနမယ္။ ပထမ subnets 3 ခုကို router LAN segments မ်ားသို့ assign ျပဳလုပ္ပါ။ က်န္ရွိေနတဲ့ subnet တစ္ခုကို router-to-router connection အတြတ္ အသံုးျပဳမယ္။ ၄င္း links မ်ားမွာ host addresses 6 ခုစီ လိုအပ္တယ္။ 255.255.255.248 (/29) subnet mask သည္ လိုအပ္ခ်က္ ကို ေျပလည္ေစမယ္။ အေစာက က်န္ရွိေနတဲ့ 192.168.3.192/27 subnet သို့ apply ျပဳလုပ္ျခင္းျဖင့္ ေအာက္ပါ subnets ေတြ ရရွိမွာ ျဖစ္တယ္ : 192.168.3.224/29 ၊ 192.168.3.232/29 ၊ 192.168.3.240/29 နဲ့ 192.168.3.248/29 ။ ပထမ subnets 3 ခုကိုသာ အသံုးျပဳဖုိ့ လိုအပ္မွာ ျဖစ္ျပီး က်န္ရွိေနတဲ့ subnet တစ္ခုကို ေနာင္တစ္ခ်ိန္မွာ အသံုးျပဳဖို့ ခ်န္ထားႏိူင္တယ္။ Class C network တစ္ခုကို မတူညီတဲ့ subnet masks 3 ခု ျဖစ္တဲ့ 255.255.255.128 ၊ 255.255.255.224 နဲ့ 255.255.255.248 တို့နဲ့ အသံုးျပဳထားတဲ့ network design ကို Figure 8-5 မွာ ေတြ့ရမွာ ျဖစ္တယ္။

Chapter 8 : VLSM (4)

2010-05-15T12:12:00.002+06:30

VLSM Example 1

VLSM နဲ့ ပက္သက္တဲ့ အေျခခံကို နားလည္ျပီးတဲ့ေနာက္ ပိုမို ရွဳပ္ေထြးတဲ့ ဥပမာ တစ္ခုကို ၾကည့္ၾကပါစို့။ Figure 8-2 မွ network ကို ဥပမာ ျပဳပါမယ္။ ၄င္း ဥပမာ မွာ Class C network : 192.168.2.0/24 ရရွိထားတယ္။ VLSM ကို အသံုးျပဳျပီး ေအာက္ပါ လိုအပ္ခ်က္ေတြကို ေျပလည္ေစဖို့ လုပ္ေဆာင္ၾကည့္ၾကမယ္ : remote sites အေရအတြတ္ စုစုေပါင္း 7 ခု ရွိေနတယ္၊ site တစ္ခုစီမွာ ရွိတဲ့ hosts အေရအတြတ္ 30 ထက္မပိုပါ၊ ေနာက္ထပ္လည္း တိုးလာစရာ မရွိပါ။ central နဲ့ remote routers မ်ားအၾကား links ေတြသည္ point-to-point connections ေတြ ျဖစ္တယ္။

ပထမဦးစြာ hosts 30 စီရွိေနတဲ့ အၾကီးဆံုး segments ေတြကို စတင္ကိုင္တြယ္ဖို့ လိုအပ္တယ္။ hosts 30 ကို ကိုင္တြယ္ဖို့ 255.255.255.224 (/27) subnet mask လိုအပ္တယ္။ ၄င္း mask သည္ ေအာက္ပါ subnets ေတြကို ဖန္တီးတယ္ : 192.168.2.0/27 ၊ 192.168.2.32/27 ၊ 192.168.2.64/27 ၊ 192.168.2.96/27 ၊ 192.168.2.128/27 ၊ 192.168.2.160/27 ၊ 192.168.2.192/27 နဲ့ 192.168.2.224/27 ။

/27 mask နဲ့အတူ subnets 8 ခု ရရွိထားတယ္။ ဒါေပမယ့္ remote offices ေတြအတြတ္ 7 ခုသာ လိုအပ္တာမို့ subnet တစ္ခု အပိုက်န္ေနပါတယ္။ ဒါေပမယ့္ central နဲ့ remote routers မ်ားအၾကား point-to-point links မ်ားကို address ျပဳလုပ္ရပါဦးမယ္။

ပထမ subnets 7 ခုကို remote LAN segments မ်ားမွာ assign လုပ္ပါ။ က်န္ရွိေနတဲ့ ေနာက္ဆံုး subnet 192.168.2.224/27 ကို point-to-point နဲ့ VLSM အတြတ္ အသံုးျပဳပါမယ္။ point-to-point links ေတြကို ေျပလည္ေစဖို့အတြတ္ 255.255.255.252 (/30) subnet mask ကို အသံုးျပဳပါမယ္။ ေအာက္ပါ subneted subnets ေတြ ရရွိပါမယ္ : 192.168.2.224/30 ၊ 192.168.2.228/30 ၊ 192.168.2.232/30 ၊ 192.168.2.236/30 ၊ 192.168.2.240/30 ၊ 192.168.2.224/30 ၊ 192.168.2.248/30 နဲ့ 192.168.2.252/30 ။

192.168.2.224 subnet ေပၚမွာ /30 mask နဲ့အတူ hosts 2 ခုစီ ပါ၀င္တဲ့ subnets ငယ္ 8 ခု ရရွိပါမယ္။ point-to-point links ေတြအတြတ္ subnets 7 ခုသာ လိုအပ္တာမို့ subnet ငယ္ တစ္ခု အပို က်န္ရွိေနခဲ့ပါမယ္။ Figure 8-3 မွာ အထက္ပါ ဥပမာ ကို အေျခခံျပဳတဲ့ networking layout ကို ျပသထားတယ္။ ဒီဥပမာမွာ Class C network 192.168.2.0/24 ကို subnet mask values 2 ခု (255.255.255.224 ၊ 255.255.255.252) နဲ့အတူ အသံုးျပဳတယ္ဆိုတာ သတိျပဳပါ။

Chapter 8: VLSM (3)

2010-04-18T14:24:00.005+06:30

Addressing with VLSM

VLSM ကို အသံုးျပဳဖို့ အတြတ္ IP addressing နဲ့ normal subnetting ကို ကြ်မ္းက်င္ ပိုင္ႏိူင္ေနဖို့ လိုအပ္တယ္။ ၄င္း concepts မ်ားကို ေကာင္းစြာ နားလည္မထားရင္ VLSM နဲ့ ပက္သက္တဲ့ concepts ေတြကို နားလည္ႏိူင္မည္ မဟုတ္ပါ။ ဒါေၾကာင့္ VLSM ကို မေလ့လာမွီ IP addressing နဲ့ subnetting ကို ကြ်မ္းက်င္ဖို့ အရင္ ၾကိဳးစားသင့္ပါတယ္။ ျပီးခဲ့တဲ့ ဥပမာမွာ ေဖာ္ျပထားသလိုပါပဲ၊ VLSM သည္ အေျခခံအားျဖင့္ subnet တစ္ခုကို ယူျပီး ၄င္း subnet မွာ အျခား subnet တစ္ခုကို apply ျပုလုပ္ျခင္း ျဖစ္တယ္။ ဒီအပိုင္းမွာ VLSM ကို အသံုးျပဳျပီး ထိေရာက္တဲ့ addressing schema တစ္ခုကို ဘယ္လို create လုပ္မလဲဆိုသည္ကို ေဆြးေႏြးမယ္။

VLSM ကို လုပ္ေဆာင္တဲ့အခါ ေအာက္ပါ အခ်က္ေတြကို လိုက္နာသင့္တယ္ :

network address space ထဲမွ devices အေရအတြတ္ အမ်ားဆံုး ခ်ိတ္ဆက္ထားတဲ့ အၾကီးဆံုး segment ကို ရွာပါ။
၄င္း အၾကီးဆံုး network segment အတြတ္ သင့္ေလ်ာ္တဲ့ subnet ကို ရွာပါ။
subnet mask ကို fit လုပ္ဖို့ subnet numbers ေတြကို ေရးခ်ပါ။
ေသးငယ္တဲ့ segments မ်ားအတြတ္ အေစာက အသစ္ဖန္တီးလိုက္တဲ့ subnets ေတြထဲက တစ္ခုကို ယူျပီး ၄င္း segment အတြတ္ ပိုမို သင့္ေလ်ာ္တဲ့ different subnet တစ္ခုကို ဖန္တီး အသံုးျပဳပါ။
အသစ္ျပဳလုပ္လိုက္တဲ့ subnetted subnets ေတြကို ေရးခ်ပါ။
ပိုမို ေသးငယ္တဲ့ segments မ်ားအတြတ္ အဆင့္ 4 သို့ ျပန္သြားျပီး process ကုိ ျပန္လည္ လုပ္ေဆာင္ပါ။

တကယ္တမ္းမွာ subnetted subnet တစ္ခုကို ယူျပီး ေနာက္ထပ္တစ္ၾကိမ္ subnet ထပ္မံျပုလုပ္ျခင္းပင္ ျဖစ္တယ္။ ဒီနည္းအားျဖင့္ network ရဲ့ addressing လိုအပ္ခ်က္နဲ့ ကုိက္ညီတဲ့၊ ထိေရာက္ေကာင္းမြန္တဲ့ addressing schema တစ္ခုကို ရရွိပါမယ္။

ဥပမာ တစ္ခုနဲ့ ေဆြးေႏြးပါမယ္ : Class C network တစ္ခု (192.168.1.0/24) နဲ့ LAN segments 3 ခု ရွိေနျပီး ၄င္း LAN segment တစ္ခုစီမွာ hosts အေရအတြတ္ 120 ၊ 60 နဲ့ 30 အသီးသီး ရွိတယ္ ဆိုပါစို့။ subnet 0 ကို valid ျဖစ္တယ္လုိ့ ယူဆမယ္။ step 1 နဲ့ 2 မွာ အၾကီးဆံုး segment ကို ရွာေဖြျပီး သင့္ေလ်ာ္တဲ့ subnet mask တစ္ခု သတ္မွတ္ေပးမယ္။ hosts 120 နဲ့ segment သည္ အၾကီးဆံုး ျဖစ္တယ္။ 120 hosts ကို accommodate ျဖစ္ဖို့ subnet mask 192.168.1.0/25 လိုအပ္မယ္။ /25 subnet mask သည္ decimal အရ 255.255.255.128 ျဖစ္တယ္၊ subnets 1 ခုစီမွာ hosts 126 ခုပါ၀င္တဲ့ subnets 2 ခုကို provide လုပ္တယ္။ step 3 မွာ အသစ္ဖန္တီးလိုက္တဲ့ subnets ေတြကို ေရးခ်မယ္ : 192.168.1.0/25 နဲ့ 192.168.1.128/25 ။ ပထမ subnet ကို hosts 120 ပါ၀င္တဲ့ အၾကီးဆံုး LAN segment သို့ assign လုပ္မယ္။ အခု hosts 60 နဲ့ 30 ပါ၀င္တဲ့ segments 2 ခု က်န္ရွိေနတယ္။ ဒါေၾကာင့္ ပိုၾကီးတဲ့ segment နဲ့ ျပန္လည္ စတင္မယ္။ step 4 ကို လုပ္ေဆာင္ပါ။ devices 60 အတြတ္ မည္သည့္ subnet mask နဲ့ သင့္ေလ်ာ္မလဲ? /26 (255.255.255.192) ျဖစ္ပါမယ္။ ၄င္း subnet မွာ host addresses 62 ခု ပါ၀င္တယ္။ ဒါေၾကာင့္ ဒီ subnet mask ကို မူလ subnet သို့ apply လုပ္ပါ။ step 5 မွာ အသစ္ ဖန္တီးလိုက္တဲ့ subnetted subnets ေတြကို ေရးခ်မယ္ 192.168.1.128/25 : 192.168.1.128/26 နဲ့ 192.168.1.192/26 ။ ၄င္းေနာက္ 192.168.1.128/26 ကို devices 60 segment သို့ assign လုပ္ပါ။

အခု subnet အပိုတစ္ခု က်န္ရွိေနမယ္။ ၄င္း subnet ကို hosts 30 segment သို့ လြယ္လြယ္ကူကူ assign ျပဳလုပ္ႏိူင္တယ္။ ဒါေပမယ့္ ၄င္း segment မွာ hosts အေရအတြတ္ 30 မွ်သာ လိုအပ္ျပီး mask မွာ 62 hosts ရွိေနတယ္။ ဒါေၾကာင့္ ပိုမို ထိေရာက္ ေကာင္းမြန္တဲ့ mask တစ္ခု ဖန္တီးခ်င္တယ္ဆိုရင္ step 4 သို့ ျပန္သြားျပီး ဒီ subnet အတြတ္ process ကို ေနာက္တစ္ၾကိမ္ ျပန္လည္ စတင္ႏိူင္တယ္။ subnet mask /27 (255.255.255.224) မွာ host addresses 30 စီပါ၀င္တဲ့ မူလ 192.168.1.192/26 subnet ထက္ ပိုမို ေသးငယ္တဲ့ 192.168.1.192/27 နဲ့ 192.168.1.224/27 subnets 2 ခု ရရွိမယ္။ ဒီဥပမာမွာ subnet အပိုတစ္ခု က်န္ရွိေနတာမို့ ေနာင္အခ်ိန္ network တိုးခ်ဲ့တဲ့အခါ အသံုးျပဳႏိူင္တယ္။ ဒီနည္းအားျဖင့္ VLSM ကို အသံုးျပဳျပီး IP addressing design ကို ပိုမို ထိေရာက္ ေကာင္းမြန္ေအာင္ လုပ္ေဆာင္ႏိူင္ပါတယ္။

Chapter 8: VLSM (2)

2010-04-18T14:17:00.004+06:30

Features of VLSM

VLSM သည္ Class address တစ္ခုအတြတ္ mask တန္ဖိုး တစ္ခုထက္မက ရွိေနေစႏိူင္တယ္။ Routing Information Protocol (RIP) v1 လို classful protocol သည္ VLSM ကို support မလုပ္ပါ။ VLSM ကို deploy လုပ္ဖို့အတြတ္ Border Gateway Protocol (BGP) ၊ Enhanced Interior Gateway Routing Protocol (EIGRP) ၊ Intermediate System-Intermediate System (IS-IS) ၊ Open Short Path First (OSPF) ဒါမွမဟုတ္ RIPv2 စတဲ့ classless routing protocol တစ္ခု လိုအပ္တယ္။ VLSM သည္ အဓိက အားသာခ်က္ 2 ခုကို provide လုပ္တယ္ :

large-scale networks မ်ားမွာ addressing ကို ထိေရာက္မွန္ကန္စြာ အသံုးျပဳႏိူင္ေစတယ္။
route summarization ဒါမွမဟုတ္ route aggregation ကို ေဆာင္ရြက္ႏိူင္တာမို့ routers မ်ားရဲ့ routing tables အရြယ္အစားကို ေလ်ာ့ခ်ေပးတယ္။

exam watch!
VLSM သည္ class address တစ္ခုအတြတ္ subnet mask တစ္ခုထက္မက အသံုးျပဳႏိူင္ေစတယ္။ VLSM ရဲ့ အားသာခ်က္ 2 ခုျဖစ္တဲ့ addresses ေတြကို ထိေရာက္စြာ အသံုးျပဳႏိူင္ေစျခင္း နဲ့ route summarization/ aggregation ကို လုပ္ေဆာင္ႏိူင္ျခင္း ... စတဲ့အခ်က္ေတြကို မွတ္သားပါ။

Figure 8-1 မွာ VLSM ကို အသံုးမျပုမီ နဲ့ အသံုးျပဳျပီး ဥပမာ ကို ျပသထားတယ္။ corporate site မွာ ရွိေနတဲ့ RouterA မွာ remote office routers ေတြ ျဖစ္တဲ့ RouterB, RouterC နဲ့ RouterD သို့ point-to-point WAN connections ေတြ ရွိေနတယ္။ ၄င္း remote sites မ်ားရဲ့ LAN segments မ်ားမွာ devices အေရအတြတ္ 50 စီေလာက္ ရွိေနတယ္ (ဒါေၾကာင့္ /26 mask ျဖစ္တယ္)။ VLSM ကို အသံုးမျပဳမီ design မွာ subnet mask 255.255.255.192 တစ္ခုထည္းကို ေရြးခ်ယ္ အသံုးျပဳထားတာ ေတြ့ရမွာျဖစ္ျပီး subnet တစ္ခုမွာ hosts အေရအတြတ္ 62 ခုစီရွိေနမယ္။ segments အေရအတြတ္ေၾကာင့္ Class C networks 2 ခုလိုအပ္တယ္။ WAN segments မ်ားမွာ point-to-point link အတြတ္ host addresses အေရအတြတ္ 2 ခုသာ လိုအပ္တာမို့ addressing space အေျမာက္အမ်ား အလဟႆ ျဖစ္ေနတာ ေတြ့ရမယ္။

Figure 8-1 ရဲ့ ေအာက္ပံုမွာ VLSM ကို အသံုးျပဳထားတဲ့ ပိုမို ထိေရာက္ ေကာင္းမြန္တဲ့ addressing အသံုးျပဳမွဳ ဥပမာကို ျပသထားတယ္။ ၄င္း ဥပမာရဲ့ remote sites 3 ခုမွာ 255.255.255.192 mask ရွိေနတာ ေတြ့ရမယ္။ ဒါေပမယ့္ ေနာက္ဆံုး subnet ျဖစ္တဲ့ 192.168.1.192/26 မွာ အျခား subnet mask တစ္ခု assign ျပုလုပ္ထားတာ ေတြ့ရမယ္။ ဒါေၾကာင့္ ၄င္း subnetted subnets ေတြကို WAN connections မ်ားရဲ့ point-to-point links ေတြမွာ assign ျပဳလုပ္ထားတယ္။ ဒီ VLSM solution မွာ network သို့ addressing assign ျပဳလုပ္ဖို့ Class C network တစ္ခုသာ လိုအပ္တယ္။ VLSM ရဲ့ ဒုတိယအားသာခ်က္ျဖစ္တဲ့ route summerization ကို ဒီသင္ခန္းစာရဲ့ ေနာက္ပိုင္းမွာ ဆက္လက္ေဆြးေႏြးမယ္။

Chapter 8: VLSM (1)

2010-04-18T14:10:00.001+06:30

RFC 1812 မွာ define ျပဳလုပ္ထားတဲ့ VLSM သည္ same class address space သို့ different subnet masks မ်ား apply ျပုလုပ္ႏိူင္ေစတယ္။ ဥပမာ 255.255.255.252 သည္ point-to-point links မ်ားအတြတ္ ေကာင္းမြန္ သင့္ျမတ္တဲ့ mask တစ္ခုျဖစ္တယ္။ ၄င္း mask သည္ subnet အသီးသီးမွာ host addresses 2 ခုစီ provide လုပ္တယ္။ LAN connection တစ္ခုအတြတ္ 255.255.255.192 သည္ သင့္ျမတ္ ေကာင္းမြန္တဲ့ mask တစ္ခု ျဖစ္တယ္။ ၄င္း mask သည္ network segment အသီးသီးအတြတ္ host အေရအတြတ္ 62 ခုကို provide လုပ္တယ္။ 255.255.255.252 mask ကို LAN connection တစ္ခုအတြတ္ အသံုးျပဳလွ်င္ လိုအပ္တဲ့ host addresses ေတြ ရရွိႏိူင္မည္ မဟုတ္သလို၊ 255.255.255.192 mask ကို point-to-point connection အတြတ္ အသံုးျပဳလွ်င္လည္း addresses မ်ား အလဟႆ ျပုန္းတီးမယ္။ addresses ျပဳန္းတီးမွဳကို အကန့္အသတ္ ျပဳလုပ္ဖို့ ေျဖရွင္းနည္း တစ္ခုမွာ mask တန္ဖိုးကို အလယ္တည့္တည့္မွ ခြဲျခမ္းျခင္း ျဖစ္ေပမယ့္ ၄င္း နည္းလမ္းသည္ ျပည့္စံုေကာင္းမြန္တဲ့ ေျဖရွင္းနည္း မဟုတ္ပါ။ VLSM သည္ same address space ေပၚမွာ different subnet mask တန္ဖိုးကို အသံုးျပဳျခင္းျဖင့္ addresses မ်ား ျပဳန္းတီးျခင္း ျပႆနာကို ေျဖရွင္းေပးတယ္။ ေအာက္မွာ VLSM က provide လုပ္တဲ့ အားသာခ်က္ေတြကို ေဖာ္ျပမယ္၊ network မွာ VLSM ကို ဘယ္လို အသံုးျပဳရမလဲဆိုတာကို ေဆြးေႏြးမယ္။

exam watch!
Point-to-point links အတြတ္ အေကာင္းဆံုး subnet mask မွာ 255.255.255.252 (130) ျဖစ္တယ္ဆိုတာကို သတိရပါ။

Chapter 14: Switches and Redundancy (The End)

2010-04-11T17:55:00.003+06:30

Configuration Remedies

ျပႆနာကို ေျဖရွင္းရာမွာ ရိုးရွင္း လြယ္ကူမွဳ ရွိေစဖို့ features ေတြကို လိုအပ္သလို disable ျပဳလုပ္ပါ။ ဥပမာ အကယ္၍ EtherChannel ကို enable ျပဳလုပ္ထားတယ္ဆိုရင္ ၊ channel ကို disable ျပဳလုပ္ျခင္းျဖင့္ ၄င္း channel သည္ ျပႆနာရဲ့ အရင္းအျမစ္ ျဖစ္ေနသလားဆိုသည္ကို ဆံုးျဖတ္ႏိူင္တယ္။

မည္သည့္ switch သည္ root switch ျဖစ္ေၾကာင္း မေသခ်ာလွ်င္ logically အရ root ျဖစ္ႏိူင္တဲ့ switch သို့ log in ၀င္ေရာက္ျပီး spanning-tree vlan VLAN_# priority command ကို အသံုးျပဳလ်က္ သူ့ရဲ့ priority ကို 1 သို့ ေျပာင္းလဲေပးျခင္းျဖင့္ root switch ျဖစ္ေစႏိူင္တယ္။

on the job!
network topology diagram အတြင္းမွာ switch အသီးသီးရဲ့ MAC addresses ေတြ ထည့္သြင္းထားသင့္တယ္။ ဒီနည္းအားျဖင့္ ၊ loop ျပႆနာေတြကို ေျဖရွင္းတဲ့အခါ topology အတြင္းသို့ rogue switch တစ္လံုးကို ထည့္သြင္းမိသလား လြယ္ကူစြာ ဆံုးျဖတ္ႏိူင္ပါလိမ့္မယ္။

switches အားလံုးသည္ 802.1d ဒါမွမဟုတ္ 802.1w (RSTP) တစ္ခုခုကို run ေနေၾကာင္း ေသခ်ာပါေစ။ 802.1w (RSTP) သည္ ပိုမိုေကာင္းမြန္ပါတယ္။ ၄င္း အခ်က္ကို verify ျပဳလုပ္ဖို့ show spanning-tree command ကို အသံုးျပဳႏိူင္သလို VLAN အတြတ္ root switch ကို ရွာေဖြရာမွာလည္း ၄င္း command ကို အသံုးျပဳႏိူင္တယ္။

Technorati Tags: STP Configuration Remedies

Chapter 14: Switches and Redundancy (26)

2010-04-11T17:50:00.002+06:30

STP Troubleshooting

loops ေတြေၾကာင့္ ျဖစ္ေပၚတဲ့ ျပသနာမ်ားကို ေျဖရွင္းျခင္းသည္ ခက္ခဲတဲ့အလုပ္တစ္ခု ျဖစ္ႏိူင္တယ္။ ဒီအပိုင္းမွာ layer 2 loop ျပႆနာေတြကို ရွာေဖြ ေဖာ္ထုတ္ျပီး ျပဳျပင္ရာမွာ လုပ္ေဆာင္ႏိူင္တဲ့ simple steps အခ်ိဳ့ကို ေဆြးေႏြးမယ္။

Loop Identification

broadcast storm ရဲ့ သိသာတဲ့ လကၡဏတစ္ရပ္မွာ switches ေတြရဲ့ CPU နဲ့ port utilization အရမ္း ျမင့္မားေနျခင္း ျဖစ္တယ္။ layer 2 loop တစ္ခုကို identify လုပ္ဖို့ အေကာင္းဆံုး နည္းလမ္းမွာ packet တစ္ခုသည္ အၾကိမ္မ်ားစြာ ျဖစ္ေပၚေနသလား determine ျပဳလုပ္ဖို့ protocol analyzer တစ္ခုကို အသံုးျပဳျပီး traffic ေတြကုိ capture and analyze ျပဳလုပ္ျခင္းပင္ ျဖစ္တယ္။ ပံုမွန္အားျဖင့္ protocol analyzer ကို switch သို့ ခ်ိတ္ဆက္ျပီး ၄င္း switch ရဲ့ Switch Port Analyzer (SPAN) feature ကို အသံုးျပုကာ ၊ interface သို့မဟုတ္ VLAN တစ္ခုမွ SPAN port သို့ frames ေတြကို copy ကူးယူတယ္။ ေကာင္းမြန္တဲ့ protocol analyzer တစ္ခုသည္ loop ျဖစ္ေပၚေနေၾကာင္း ရွာေဖြ ေဖာ္ထုတ္ေပးျပီး ၊ ၄င္း ျပႆနာကို မိမိထံသို့ အသိေပး အေၾကာင္းၾကားႏိူင္တယ္။

loop ရွိေနေၾကာင္း identify လုပ္ျပီးတဲ့ေနာက္ connectivity ကို အလ်င္အျမန္ restore ျပဳလုပ္ဖို့ loop ရဲ့ အစိတ္အပိုင္းအျဖစ္ ရွိေနတဲ့ ports ေတြကို disable ျပဳလုပ္ဖို့ စတင္သင့္တယ္။ ၄င္းေနာက္ configuration ေၾကာင့္ ျဖစ္တဲ့ loop လား ဒါမွမဟုတ္ အသစ္ထပ္ထည့္လိုက္တဲ့ layer 2 device တစ္ခုေၾကာင့္ျဖစ္တဲ့ loop လားဆိုသည္ကို ဆံုးျဖတ္ဖို့ ျပႆနာကို diagnose လုပ္ပါ။ မည္သည့္အေၾကာင္းခ်က္ေၾကာင့္ loop ျဖစ္ေပၚေၾကာင္း identify လုပ္ႏိူင္တဲ့အခါ STP အတြတ္ debug ကို turn on လုပ္ပါ (debug spanning-tree events) ။

Technorati Tags: STP Troubleshooting, Loop Identification

Chapter 14: Switches and Redundancy (25)

2010-04-03T11:01:00.003+06:30

EtherChannel Configuration

ျပီးခဲ့တဲ့ သင္ခန္းစာေတြမွာ ေဆြးေႏြးခဲ့ျပီး ျဖစ္သလို channel အတြင္းမွာ interfaces အားလံုးကို တူညီစြာ configure ျပဳလုပ္ထားေၾကာင္း ေသခ်ာပါေစ။ အဲလိုမွမဟုတ္ရင္ channel တစ္ခု ျဖစ္ေပၚမည္ မဟုတ္ပါ။ EtherChannel တစ္ခုကို set up ျပဳလုပ္ဖို့ ေအာက္ပါအတိုင္း ေဆာင္ရြက္ပါ :

Switch (config) # interface type [slot_#] port_#
Switch (config-if) # channel-group group_# mode mode
Switch (config-if) # port-channel load-balance {dst-ip | dst-mac | src-dst-ip | src-dst-mac | src-ip | src- mac }

group_# သည္ channel group ကို သတ္မွတ္တယ္၊ 1 မွ 6 အထိ ျဖစ္ႏိူင္တယ္ ( switch တစ္လံုးမွာ EtherChannel 6 ခုအထိ ရွိႏိူင္တာ သတိရပါ)။ mode သည္ Table 14-4 မွာ ေဖာ္ျပထားတဲ့အထဲက 1 ခု ျဖစ္ႏိူင္တယ္။ PAgP ကို အသံုးျပုတဲ့အခါ side တစ္ဖက္ကို desirable အျဖစ္လည္းေကာင္း၊ အျခား side တစ္ဖက္ကို desirable ဒါမွမဟုတ္ auto အျဖစ္လည္းေကာင္း configure ျပုလုပ္ေပးဖို့ လိုအပ္တယ္။ LCAP ကို အသံုးျပဳတဲ့အခါ side တစ္ဖက္သည္ active ျဖစ္ဖို့ လိုအပ္ျပီး၊ အျခား side တစ္ဖက္သည္ active ဒါမွမဟုတ္ passive ျဖစ္ႏိူင္တယ္။ port-channel load-balance command သည္ channel ေပၚမွာ အသံုးျပုလိုတဲ့ load balancing အမ်ိဳးအစားကို configure ျပုလုပ္တယ္။ ၄င္း command ကို ခ်န္လွပ္ခဲ့မယ္ဆိုရင္ default ျဖစ္တဲ့ source MAC addresses (arc-mac) အေပၚမွာ အေျခခံျပီး load balancing ကို ေဆာင္ရြက္မယ္။

Technorati Tags: EtherChannel Configuration