Failure Detection ရဲ့ အရေးပါမှုနှင့် BFD

Failure Detection ဟာ Network တခုအတွက် ဘယ်လောက် အရေးပါလည်း ဆိုတာနဲ့ Bidirectional Forwarding Detection (BFD) ဆိုတာ ဘာလဲ။ ဘယ်လို အခြေအနေမျိုးမှာ ဘာကြောင့် သုံးကြ တယ်ဆိုတာ လေ့လာ ကြည့်ရအောင်။ ကိုယ်တာဝန်ယူထားရတဲ့ Network တခုမှာ တခုခုပြဿနာဖြစ်ပီ ဆိုရင် ဘယ် နေရာမှာ ဘာဖြစ်နေတယ်ဆိုတာကို အရင်ဆုံးသိဖို့က အရေးကြီးပါတယ်။ ဒါမှသာ ဘာဆက်လုပ်သင့်တယ်၊ ဘယ်နေရာတွေ ပြင်ရမယ်ဆိုတာ သိမှာပါ။ ဘယ်နေရာက ဘာဖြစ်နေမှန်းမသိဘူးဆိုရင် ဖြေရှင်းဖို့မလွယ်ကူသလို၊ ဖြေရှင်းရမဲ့ အချိန်ကိုပါ ကြာမြင့်စေပါတယ်။ တနည်းအားဖြင့်ပြောရရင် ပြတ်တောက်ချိန် Outage ကိုကြာမြင့်စေတဲ့အတွက် မလိုလားအပ်တဲ့ ကိစ္စတွေ ပေါ်ပေါက်နိုင်စေပါတယ်။

ဒီနေရာမှာ အချက် ၂ ချက်က အရေးကြီးပါတယ်။ ပထမတခုက Failure detection နဲ့ ဒုတိယတခုက Time ပါ။ ပထမ အချက်က အဓိကပေမဲ့ အချိန်ကလဲ အရေးကြီးပါတယ်။ ကိုယ်ရဲ့ Network နဲ့ SLA အပေါ်မူတည်ပါတယ်။ Failure Detection အတွက် NMS တွေ၊ Devices' syslog တွေ၊ traps တွေတခြားလိုအပ်တဲ့ အချက်အလက် တွေနဲ့ Admin တယောက်အတွက် မြင်သာအောင် စီစဉ်ထားရပါတယ်။ အဲဒါတွေကလည်း ကိုယ်အသုံးပြုနေတဲ့ Device/Link/Protocols တွေရဲ့ သဘာဝအပေါ်မူတည်ပါတယ်။ သူတို့က ပေးပို့တာ နောက်ကျရင် NMS နဲ့ Syslog ကသိတာလည်း နောက်ကျပါတယ်။ Poll Method ဖြစ်ဖြစ်၊ Push Method ဖြစ်ဖြစ် အတူတူပါပဲ။

နောက်တခုက Network outage တွေမှာ ပြဿနာဖြစ်ရင် Admin/user fault ရယ်၊ Links/ Circuits outage က equipment/device failure ကပိုပါတယ်။ တော်ရုံ Device တွေဟာ Power ကြောင့်ကလွဲရင် hardwar ကြောင့်   ဖြစ်တာ နဲပါတယ်။ ဒီတော့ အများအားဖြင့် Link/Circuit တွေ၊ Configuration error တွေကိုအဓိက စောင့်ကြည့်ရတာများပါတယ်။ Link/Circuit တွေရဲ့ အခြေအနေကိုကြည့်ပြီး အပေါ်က Protocol တွေက Neighbor တွေဆောက် ၊ Routing တွေ ဖလှယ်ကြပါတယ်။ အဲဒီနေရာမှာ Protocol တွေရဲ့ Hello တို့ Hold time တို့က အဓိက အလုပ် လုပ်တယ်။ Protocol တခုနဲ့တခု၊ Link အမျိုးအစား တခုနဲ့တခု Hold time တွေမတူကြပါဘူး။ အဲဒီ Hello ပျောက်သွားပြီ Hold time ကျော်သွားပြီဆိုတော့မှ Neighbor ပျောက်ပီဆိုပြီးတော့ Failover ကိစ္စတွေ စလုပ်ပါတယ်။ အဲဒီ Hold time အတွင်းမှာ traffic တွေဟာ black hole အထဲကို ရောက်သွားပါတယ်။ ပြန်ကောင်းသွားလို့ပဲဖြစ်ဖြစ် Failover ကအလုပ်လုပ်သွားတာပဲ ဖြစ်ဖြစ် ရတော့မှ ပြန်အဆင်ပြေသွားပါတယ်။ ပြန်မကောင်းခင် အချိန်အတွင်းမှာ ဖြစ်သွားတာကတော့ Packet loss ပေါ့။ Convergence time နှေးလေ Outage ကြာချိန်များလေပါပဲ။

Failure detect ဖြစ်တယ် dynamic Failover အလုပ်လုပ်တယ်ဆိုရင် ပြည့်စုံပြီလို့ ဆိုလို့ရပေမယ့် အဲဒီ protocol တွေရဲ့ တမိနစ်လောက်ရှိတဲ့ hold time ကို မစောင့်နိုင်တဲ့ အခြေအနေတွေရှိပါတယ်။ နောက်တခါ multiple protocols တွေရှိနေတဲ့ အချိန်မျိုးမှာ Failure detection ကိုတတ်နိုင်သလောက် တူညီအောင် Circuit/Link တွေကို စောင့်ကြည့်မယ်ဆိုရင်တော့ protocol တခုစီရဲ့ hello နဲ့ hold time တွေကို လိုက်ညှိရပါလိမ့်မယ်။ OSPF fast hello မျိုးပေါ့။ ဒါပေမယ့် တကယ့်လက်တွေ့မှာ သိပ်မလွယ်ပါဘူး။ နောက်တခါ dynamic protocol မသုံးထားတဲ့လင့်မျိုးမှာ hello မရှိရင် Layer 2 ရဲ့ hardware alarm ကိုပဲအားထားရပါတယ် ဒါပေမဲ့ Ethernet လိုမျိုး interface အတွက် အဆင် မပြေပြန်ဘူး။ အထူး သဖြင့် Metro Ethernet Link တွေမှာ MUX/MC/Switch က ခံနေတဲ့ အတွက် interface down stage ကိုဘယ်တော့မှ မရောက်ပါဘူး။ Interface down မဖြစ်တဲ့အတွက် Failover ကလဲ အလုပ်မလုပ်ပါဘူး။

ဒီကိစ္စကိုဖြေရှင်းဖို့အတွက် IP LSA တို့ EEM တို့သုံးပြီး Failure detection ရအောင်လုပ်ကြပါတယ်။ Point to point link တွေအတွက်တော့ ပေါ့ပါးပီး မြန်ဆန်တဲ့ Bidirectional Forwarding Detection ခေါ် BFD ကိုလည်းသုံးကြပါတယ်။ BFD ရဲ့ timer ဟာ msec အထိဆင်းပြီး လုပ်ဆောင်နိုင်တဲ့အတွက် IGP hello တွေ လုပ်ဆောင်နိုင်တဲ့ အချိန်နဲ့ အများကြီး ကွာပါတယ်။ နောက် dynamic protocol မရှိတဲ့ နေရာမျိုးအတွက်လည်း overhead နဲနဲနဲ့ Failure detection ကို လုပ်ဆောင်ပေးပါတယ်။ Interface level နဲ့ routing protocols level မှာ အသုံးပြုရပါတယ်။ ဒါပေမဲ့ ကိုယ်အသုံးပြုနေတဲ့ IOS က support လုပ်ဖို့တော့လိုပါတယ်။

သူ့ရဲ့အလုပ်လုပ်ပုံကလည်း ရှင်းရှင်းလေးပါ။ Timer တွေပါတဲ့ BFD control packet ကို တဖက်ကနေ တဖက်ပို့ပေးရင်း Neighbor ရှိနေသေးလားကြည့်ပေးတာပါ။ packet ရောက်မလာရင် Down ပေါ့။ Operations mode အနေနဲ့ ၂ မျိုးရှိတယ်။ Asynchronous mode ရယ် Demand mode ရယ်။ Primary mode ဖြစ်တဲ့ Asynchronous mode က ၂ ဖက်စလုံးက peer တွေက control packet ကို ပုံမှန်ပေးပို့ပြီး စောင့်ကြည့်တယ်။ Demand mode ကတော့ neighbor ဖြစ်ပြီးသွားရင် ပုံမှန်မပို့ပဲ လိုအပ်တယ်လို့ထင်မှ ထပ်ပို့ကြတယ်။ သူတို့တွဲသုံးတဲ့ လုပ်ဆောင်ချက်တခုကတော့ Echo function လို့ခေါ်တယ်။ သူကတော့ ဒီဖက်ကပို့လိုက်တဲ့ Control packet က Loop ပေးသလိုမျိုး Echo ပြန်ရောက်လာတဲ့ ပုံစံမျိုး။ ဘယ် Mode ကိုသုံးရမလဲဆိုတာကတော့ ကိုယ့် Network အခြေအနေ ကိုယ်သုံးတဲ့ Device နဲ့ OS အပေါ်မှမူတည်ပါတယ်။ Aggressive detection အတွက်တော့ Asynchronous နဲ့ Echo သုံးကြပြီး Overhead လျော့ချင်ရင်တော့ Demand mode ကိုသုံးကြပါတယ်။

BFD ဟာ Failure Detection အတွက် အထောက်အကူပြုတဲ့ Protocol ဖြစ်ပါတယ် ဒါပေမဲ့ သေချာစဉ်းစားပြီး ကိုယ့် Network အတွက် တကယ်လိုအပ်မှသာ အသုံးပြုသင့်ပါတယ်။ Failure Detection ဟာ မြန်နိုင်သလောက်ကောင်းလေ ဆိုပေမယ့် တဖက်မှာတော့ Network stability ကိုလည်း ပြန်ကြည့် ရပါတယ်။ Convergence time ဟာ Protocol default setting တွေနဲ့လုံလောက်တယ်ဆိုရင်တော့ Network Stability အတွက်ပိုပြီး ဦးစားပေး စဉ်းစားသင့်ပါတယ်။ အခုလောက်ဆို Failure Detection ဟာ ဘယ်လောက်အရေးပါလည်းဆိုတာ ကိုသိလောက်ပါပြီ။ ဒါနဲ့အတူ BFD ဆိုတဲ့ Protocol အကြောင်းကိုပါ တီးမိခေါက်မိ ရှိလောက်ပြီလို့ထင်ပါတယ်။ BFD ရဲ့ အသေးစိတ်ကိုထပ်ဖတ်မယ်ဆိုရင်တော့ RFC 5880 မှာဖတ်ကြည့်ပါ။ Configuration အတွက်ကတော့ ကိုယ်သုံးတဲ့ Device နဲ့ OS ပေါ်မူတည်ပြီး Cisco Documentation မှာရှာကြည့်ပါ။

ကိုဖြိုး

Dynamic ACL

Lock and Key ခေါ် Dynamic ACL လို့ခေါ်တဲ့ ACL နောက်တမျိုးကိုထပ်ကြည့်ကြတာပေါ့။ လုပ်ငန်းခွင်အနေနဲ့တော့ သိပ်ပြီးအသုံးပြုလေ့မရှိပါဘူး၊ ဒါပေမယ့် အရေးကြုံလို့လိုအပ်လာတဲ့အချိန်၊ စာမေးပွဲဖြေတဲ့ အချိန်တွေမှာ သုံးတတ်အောင်လို့တော့ သိထားသင့်ပါတယ်။ အသုံးမပြုကြဘူးဆိုတာက သူ့ရဲ့ လုပ်ဆောင်ပုံဟာ VPN အသုံးပြုပုံနဲ့သွားတူနေတာကြောင့်လည်းဖြစ်ပါတယ်။ VPN အထိ အသုံးပြု ရအောင် လည်း မရပါဘူး။ VPN သုံးတဲ့အခါမှာ Mobile users VPN အနေနဲ့Client သုံးပြီး VPN Login ဝင်၊ ပြီးရင် အတွင်းက Network/ Resource ကိုအသုံးပြုရသလိုမျိုး၊ ACL ကိုဖွင့်ပေးဖို့အတွက် Authentication အရင်လုပ်၊ Login ရပြီးမှ ACL ကို Dynamic ဖွင့်ပေးပြီး အတွင်းက Network/ Resource ကိုအသုံးပြု ခွင့်ပေးတာမျိုးပါ။

Dynamic ACL ကို လက်ရှိအသုံးပြုနေတဲ့ Extended ACL နဲ့ တွဲသုံးပြီး ကိုယ်ဖွင့်ပေးချင်တဲ့ Protocol/ Destination ကိုခွင့်ပြုထားရပါတယ်၊ ဒါပေမဲ့ အဲ့ဒီ Dynamic Entry ဟာ Authentication/ Login ဝင်လို့ရတဲ့ Source အတွက်သာ ယာယီဖွင့်ပေးပါတယ်။ သူရဲ့သတ်မှတ်တဲ့ အချိန် Timeout ဖြစ်သွားရင် သူ့အလိုလို ပြန်ပိတ်သွားပါတယ်။ ထပ်သုံးချင်ရင်တော့ Login ထပ်ဝင်ရပါတယ်။ Show run configuration အနေနဲ့ ကြည့်ရင် အသေးစိတ်မမြင်ရပဲ၊ Dynamic ACL active ဖြစ်နေတဲ့ အချိန်မှသာ ဘာကိုဖွင့်ထားတယ်ဆိုတာကို Show access-list ကနေကြည့်လို့ရပါတယ်။ Dynamic ACL တစ်ကြောင်းသာ Extended ACL အောက်မှာ ရေးလို့ရတဲ့ အတွက် များသောအားဖြင့် General အနေနဲ့သာ ရေးလေ့ရှိပါတယ်။ ဥပမာ permit IP any any ဆိုတာမျိုး။ Permit any ဆိုပေမဲ့ Authentication ထပ်ခံထားတဲ့အတွက် ကြောက်စရာမလိုပါဘူး။ ဒီနေရာမှာ အရေးကြီးတာက Timeout ပါ။ Absolute Timeout နဲ့ idle timeout ဆိုပြီးရှိပါတယ်။ Timeout မရှိရင် တခါဝင်ထားတဲ့ Login user ဟာအမြဲတမ်း ဝင်ခွင့်ရနေပြီး လုံခြုံရေးအရ ACL ရဲ့ အနှစ်သာရကို ပျက်ဆီး စေပါတယ်။

အသုံးပြုတဲ့ နမူနာနဲ့ တွဲမကြည့်ရင် သိပ်မရှင်းပဲ နားလည်ရခက်နိုင်ပါတယ်။ ဥပမာ တစ်ခုနဲ့ကြည့်ရအောင်။ ကိုယ်အတွင်းမှာရှိတဲ့ Server/ Application တစ်ခုကို တခြား Network ကနေ ယာယီအသုံးပြုဖို့ တောင်းဆိုလာတယ်ဆိုပါတော့။ အသုံးပြုချင်တဲ့ သူရဲ့ Source IP က အတိအကျမသိရဘူး။ DHCP ကနေချပေးတဲ့ IP ဆိုတော့ ဒီနေ့ တမျိုး၊ နောက်တနေ့ တမျိုးဖြစ်နေတယ်။ Subnet တစ်ခုလုံး ဖွင့်ပေးဖို့ ကြတော့လဲ သိပ်အဆင်မပြေပြန်ဘူး၊ သုံးမည့်သူက တစ်ယောက်တည်း။ VPN ပေးသုံးဖို့ကလည်း Firewall နဲ့ VPN Gateway ကမရှိ။ ရှိရင်လည်း သူအတွက် ယာယီ အသုံးပြုဖို့အတွက် AD မှာ User ထည့်ဖို့၊ Token ပေးဖို့အတွက်ကလည်း Resource တွေသုံးရမှာ သိပ်မတန် ဖြစ်နေတယ်။ ဒီလိုအခြေနေမျိုးမှာ Border router ရဲ့ အဝင်မှာ သုံးထားတဲ့ Extended ACL မှာ Dynamic ACL ဝင်ထည့်ပြီး Local user တစ်ခုဝင်ရေးပြီး ပေးလိုက်တာက အမြန်ဆုံးနဲ့ အဆင်ပြေဆုံးဖြစ်ပါလိမ်မယ်။ Local user တင်မကပဲ Authentication server တွေဖြစ်တဲ့ TACACS+ တို့နဲ့လည်း သုံးလို့ရပါတယ်။ ဒါပေမဲ့ အပေါ်မှာ ပြောခဲ့သလိုပဲ Timeout ကတော့ အရေးကြီးပါတယ်။ အဲဒါမပါရင် ကိုယ့် Network ကိုလာဖို့Tunnel ဖောက်ပေးလိုက်သလိုဖြစ်သွားပါလိမ့်မယ်။

Configuration နဲ့တွဲကြည့်လိုက်ပြီး Lab တစ်ခုလောက်လုပ်လိုက်ရင်တော့ ပိုပြီး နားလည်သွားပါလိမ့်မယ်။ Cisco ရဲ့ Config ကို ဆက်လေ့လာကြည့်ပါ။

Lock-and-Key with Local Authentication Example

This example shows how to configure lock-and-key access, with authentication occurring locally at the router. Lock-and-key is configured on the Ethernet 0 interface.

username user-name password password

interface ethernet0
 ip address 172.18.23.9 255.255.255.0
 ip access-group 101 in

access-list 101 permit tcp any host 172.18.21.2 eq telnet
access-list 101 dynamic mytestlist timeout 120 permit ip any any

line vty 0
login local
autocommand access-enable timeout 5

The first access-list entry allows only Telnet into the router. The second access-list entry is always ignored until lock-and-key is triggered.
In the access-list command, the timeout is the absolute timeout. In this example, the lifetime of the mytestlist ACL is 120 minutes; that is, when a user logs in and enable the access-enable command, a dynamic ACL is created for 120 minutes (the maximum absolute time). The session is closed after 120 minutes, whether or not anyone is using it.
In the autocommand command, the timeout is the idle timeout. In this example, each time the user logs in or authenticates there is a 5-minute session. If there is no activity, the session closes in 5 minutes and the user has to reauthenticate. If the user uses the connection, the absolute time takes affect and the session closes in 120 minutes.
After a user opens a Telnet session into the router, the router will attempt to authenticate the user. If authentication is successful, the autocommand executes and the Telnet session terminates. The autocommand creates a temporary inbound access list entry at the Ethernet 0 interface, based on the second access-list entry (mytestlist). This temporary entry will expire after 5 minutes, as specified by the timeout.

ကိုဖြိုး

Time-Based ACL

ACL အကြောင်းထပ်ဆက်ရမယ်ဆိုရင် အချိန်နဲ့အလုပ်လုပ်တဲ့ Time-Based ACL အကြောင်းကို ဆက်လေ့လာကြည့်တာပေါ့။ တကယ်တော့ Time-Based ACL ဟာ ထူးထူးခြားခြားမဟုတ်ပါဘူး။ ACL ကို Time-Range လို့ခေါ်တဲ့ အချိန်အပိုင်းအခြားကိုထည့်ပေါင်းပြီး အသုံးပြုလိုက်တာပါပဲ။ အပြင်မှာ တကယ် အသုံးပြုလားဆိုရင်တော့ သိပ်ပြီးအသုံးပြုလေ့မရှိပါဘူး ဒါပေမယ့် တခါတလေမှာ လိုအပ်ချက်ကြောင့် ထည့်ပြီးအသုံးပြုလို့ရအောင် သိထားသင့်ဖို့တော့လိုအပ်ပါတယ်။ နမူနာ အနေနဲ့ပြောရရင် ရုံးမှာရှိတဲ့ အင်တာနက်လင့်က သေးတယ် Bandwidth ကသိပ်မရှိဘူး၊ ရုံးချိန်အတွင်းမှာ ဝန်ထမ်းတွေက အလုပ်နဲ့ မသက်ဆိုင်တဲ့ အင်တာနက်ကြည့်နေတာကြောင့် အဓိက ရုံးလုပ်ငန်းအတွက်သုံးရမည့် လုပ်ငန်းဆိုင်ရာ Business Application တွေကိုနှေးစေတယ်။ တဖက်ကလည်း ကိုယ့်ရဲ့ဝန်ထမ်းတွေကို ထမင်းစားချိန်၊ အားလပ်ချိန်နဲ့ အလုပ်ပြီးချိန်တွေမှာတော့ ကြိုက်သလို အသုံးပြုဖို့ခွင့်ပြုထားချင်တယ်။ ဒီလိုအခြေအနေမျိုးမှာ Network Admin ကသူကိုယ်တိုင် အဖွင့်အပိတ် လုပ်ပေးနေမည့်အစား အချိန်ပေါ်မူတည်ပြီး အဖွင့်အပိတ်လုပ်ပေးနိုင်တဲ့ Time-Based ACL ကို အသုံးပြုသင့်ပါတယ်။

ဒီလိုအဖြစ်မျိုး တကယ်ရှိရဲ့လားဆိုရင် ရှိတယ်လို့ပြောရမှာပဲ။ Bandwidth တစ်ခုတည်းကြောင့်မဟုတ်ပဲ ရုံးရဲ့ စည်းကမ်းပိုင်းအရလည်း အသုံးပြုတာမျိုးဖြစ်ပါတယ်။ ဒါမျိုးကို Firewall တွေမှာလည်း အသုံးပြုလေ့ ရှိပါ တယ်။ URL Control တွေ၊ Content Filter တွေပါတဲ့ Firewall တွေမှာ ပိုပြီးအသုံးဝင်ပါတယ်။ တကယ်လို့ ကိုယ့်မှာ FW မရှိဘူး၊ အထက်ကလည်း ဒါမျိုးကို လုပ်ခိုင်းလာတဲ့ အချိန်မျိုးမှာ Router ကနေ Time-Based ACL နဲ့အဆင်ပြေအောင် လုပ်ပေးထားလို့ရပါတယ်။ ဒါဟာ CCNA Level ဖြစ်တဲ့အတွက် စာမေးပွဲဖြေမည့် သူများအနေနဲ့လည်းသိထားသင့်ပါတယ်။

ဘာကိုသိထားသင့်သလဲဆိုရင်တော့ အချိန်နဲ့ အလုပ်လုပ်မှာ ဖြစ်တဲ့အတွက် ကိုယ့်ရဲ့ Router ဟာ အချိန်မှန် ရဲ့လား၊ ကိုယ်သုံးနေတဲ့ Time-Zone နဲ့ကိုက်ရဲ့လား စစ်ဆေးသင့်ပါတယ်။ Time-zone လွဲရင်လည်း ကိုယ်ရေး မည့်အချိန်နဲ့ လွဲတတ်တာ ကြောင့် သတိထားသင့်ပါတယ်။ NTP သုံးထားရင်လည်း Sync ဖြစ်မဖြစ် သေချာ ကြည့်ပါ။ ပြီးရင် ကိုယ့်ရဲ့ လိုအပ်ချက်အရ အချိန်အတိအကျနဲ့တစ်ကြိမ်သာ လိုအပ်တာလား၊ အထက်က ပြောခဲ့သလို ပုံမှန် အချိန်အပိုင်းနဲ့အမြဲတမ်းသုံးမှာလား ဆိုပြီး Time-Range ကိုရေးရပါတယ်။ သတ်မှတ်ချိန် အတိအကျနဲ့သုံးမယ်ဆိုရင် absolute ကိုသုံးပြီး အချိန်အပိုင်းအခြားအလိုက် recurring time ဆိုရင်တော့ Periodic ကိုသုံးရပါတယ်။ Time-range ရပြီဆိုရင် လိုအပ်တဲ့ ACL ကိုရေးပါ။ ရေးတဲ့ အချိန်မှာ အနောက် ကနေ Time-Range     ဆိုပြီးတော့ ကိုယ်ရေးထားတဲ့ Time-range ကိုပေါင်းပေးလိုက်ရင် Time-based ACL တစ်ခုရပါပြီ။ နောက်ဆုံးအဆင့်အနေနဲ့ ဘယ်နေရာမှာ သုံးမယ်ဆိုတာ တွဲပေးလိုက်ရင် ပြီးပါပြီ။

Configuration အနေနဲ့လည်းရိုးရှင်းပါတယ်။ Cisco ကပေးထားတဲ့ နမူနာကို ကြည့် ကြည့်ပါ။

!--- Defines a named time range.

time-range time-range-name

!--- Defines the periodic times.

periodic days-of-the-week hh:mm to [days-of-the-week] hh:mm
      

!--- Or, defines the absolute times.

absolute [start time date] [end time date]

!--- The time range used in the actual ACL.

ip access-list name|number <extended_definition>time-rangename_of_time-range 

In this example, a Telnet connection is permitted from the inside to outside network on Monday, Wednesday, and Friday during business hours:

interface Ethernet0/0
ip address 10.1.1.1 255.255.255.0
ip access-group 101 in     

access-list 101 permit tcp 10.1.1.0 0.0.0.255 172.16.1.0 0.0.0.255       
eq telnet time-range EVERYOTHERDAY 

time-range EVERYOTHERDAY
periodic Monday Wednesday Friday 8:00 to 17:00

ကိုဖြိုး