Local Preference အကြောင်း နည်းနည်းပွားထားတာပါ။ :D :D :D
What is Forwarding Address in OSPF and how it is works?
CCIE အတွက်OSPF
ကိုလေ့လာတဲ့အခါမှာ Forwarding Address ဟာ နားလည်ရခက်တဲ့ ခေါင်းစဉ်တွေထဲမှာ ပါပါတယ်။
သူ့ကို အဓိက သုံးရခြင်းကတော့
sub-optimal routing ဆိုတဲ့ အခြေအနေကို ကျော်လွှားဖို့ နဲ့ ၊
Multiple ABR Router
တွေကနေ တူညီတဲ့ LSA Update တွေကို တခြား OSPF Router တွေဆီကို ထပ်ခါထပ်ခါ ပြန်ပို့တာကနေ
ရှောင်လွှဲချင်လို့ပဲ ဖြစ်ပါတယ်။
(Sub-optimal
routing ဆိုတာ တခြားမဟုတ်ပါဘူး… သွားချင်တဲ့နေရာကို အတိုဆုံးလမ်းကြောင်းကနေသွားလို့ရပါလျက်နဲ့
မသွားပဲ တခြားနေရာက ပတ်သွားတာကို sub-optimal routing လို့ခေါ်တာပဲ ဖြစ်ပါတယ်။)
Forwarding
Address ကို ASBR က တခြား OSPF Router တွေဆီကို ပုံစံ (၂) မျိုးနဲ့ Announce လုပ်ပါတယ်။
Zero
Address “0.0.0.0” နဲ့ Non-zero address ဆိုပြီးတော့ပါ။
ပိုရှင်းသွားအောင်
အောက်က ပုံကိုကြည့်ပါ။
ပုံမှာ RIP
ကနေ OSPF နဲ့ OSPF ကနေ RIP ကို အပြန်အလှန် Redistribute လုပ်ထားတယ်။ ဒီမှာတော့ R3 တလုံးထဲကနေပဲ
ASBR အလုပ်ကို လုပ်ခိုင်းထားပါတယ်။
(Configuration
တွေကိုတော့ ကိုယ့်ဖာသာပဲ လုပ်ကြည့်ပါ။ ဒီမှာ ကျတော်မတင်ပေးတော့ပါဘူး ပို့စ်အရမ်းရှည်သွားမှာစိုးလို့ပါ။)
အခု ကျတော်တို့
OSPF ရဲ့ Forwarding Address အကြောင်းကို ပြောမှာဖြစ်လို့ OSPF Area ဖက်က Route တွေအကြောင်းကိုပြောရအောင်။
ASBR က သူ့တာဝန်အတိုင်း
သူ့ဆီဝင်လာတဲ့ Redistributed External Route တွေ (ဒီမှာတော့ RIP Route တွေပေါ့) ကို
OSPF Domain ထဲကို flooding လုပ်တာပေါ့။
R2 နဲ့ R4 ကနေ R1 ရဲ့ Loopback ဖြစ်တဲ့
1.1.1.0 ကို သွားတဲ့ လမ်းကြောင်း နဲ့ Forwarding Address ကိုကြည့်ပါမယ်။
R2#show ip route 1.1.1.0
Routing entry for 1.1.1.0/24
Known via "ospf 1", distance 110, metric 20, type extern 2,
forward metric 1
Last update from 192.168.23.3 on FastEthernet1/1, 00:04:59 ago
Routing Descriptor Blocks:
* 192.168.23.3, from
0.0.0.3, 00:04:59 ago, via FastEthernet1/1
Route metric is 20, traffic share count
is 1
R2#
R2#show ip ospf database external 1.1.1.0
OSPF Router with ID (0.0.0.2)
(Process ID 1)
Type-5 AS External Link States
Routing Bit Set on this LSA in topology Base
with MTID 0
LS age: 142
Options: (No TOS-capability, DC, Upward)
LS Type: AS External Link
Link State ID: 1.1.1.0
(External Network Number )
Advertising Router: 0.0.0.3
LS Seq Number: 80000001
Checksum: 0xB1E8
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link
state path)
MTID: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 0
R2#
R2#traceroute 1.1.1.1
Type escape
sequence to abort.
Tracing the route
to 1.1.1.1
VRF info: (vrf in
name/id, vrf out name/id)
1 192.168.23.3 20 msec 8 msec 16 msec
2 172.16.123.1 4 msec 28
msec 8 msec
R2#
R4#show ip route 1.1.1.0
Routing entry for 1.1.1.0/24
Known via "ospf 1", distance 110, metric 20, type extern 2,
forward metric 2
Last update from 192.168.24.2 on GigabitEthernet0/0, 00:04:14 ago
Routing Descriptor Blocks:
* 192.168.24.2, from
0.0.0.3, 00:04:14 ago, via GigabitEthernet0/0
Route metric is 20, traffic share count
is 1
R4#
R4#show ip ospf database external 1.1.1.0
OSPF Router with ID (0.0.0.4)
(Process ID 1)
Type-5 AS External Link States
Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 400
Options: (No TOS-capability, DC, Upward)
LS Type: AS External Link
Link State ID: 1.1.1.0
(External Network Number )
Advertising Router: 0.0.0.3
LS Seq Number: 80000001
Checksum: 0xB1E8
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link
state path)
MTID: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 0
R4#
R4#traceroute 1.1.1.1
Type escape sequence to abort.
Tracing the route to 1.1.1.1
VRF info: (vrf in name/id, vrf
out name/id)
1
192.168.24.2 8 msec 20 msec 8 msec
2 192.168.23.3 16 msec 24
msec 28 msec
3 172.16.123.1 48 msec 40
msec 12 msec
R4#
R2 နဲ့ R4 ရဲ့ Output တွေကို ကြည့်တာနဲ့
R1 loopback ကို ရောက်ဖို့ R3 ကိုဖြတ်သွားနေရတာကို တွေ့ရမှာပါ။
တကယ်တော့ ဒါဟာ Optimal Routing မဟုတ်ပါဘူး။
တကယ်ဆိုရင် R2 ကဖြတ်သွားရင် လမ်းကြောင်းပိုတိုမှာပဲဖြစ်ပါတယ်။
ဒီတော့ ပိုတိုတဲ့လမ်းကြောင်းကို ရွေးဖို့ အတွက် ကျတော်တို့ Forwarding
Address ကို Zero Forwarding Address “0.0.0.0” ကနေ Non-zero Forwarding Address ဖြစ်အောင်
လုပ်ယူရပါမယ်။
ဒီမှာ ပြောစရာရှိလာပါတယ်။
Non-zero Forwarding Address ဖြစ်ဖို့အတွက်
အောက်ပါအချက်တွေနဲ့ ကိုက်ညီဖို့လိုပါတယ်။
၁)
ASBR ရဲ့ next hop interface ဟာ OSPF process enable လုပ်ထားရပါမယ်။
၂)
Passive interface မဖြစ်ရပါဘူး။
၃)
Point-to-point interface လည်းမဟုတ်ရပါဘူး။
၄)
Point-to-multipoint လည်းမဟုတ်ရပါဘူး။
၅)
Interface ရဲ့ IP address ဟာ OSPF network process ရဲ့ range ထဲမှာ ပါရပါမယ်။
ဒီအချက်
(၅) ချက်လုံးနဲ့ ကိုက်ညီမှ non-zero forwarding address ကို set လုပ်လို့ရပါတယ်။
မကိုက်ညီခဲ့ရင်တော့
zero forwarding address “0.0.0.0” ကိုပဲ ရနေမှာပါ။
ကဲ… ဒီတော့ ကျတော် ASBR R3 ရဲ့
Fa1/0 interface ကို OSPF Area 0 ထဲ ထည့်ကြည့်ပြီး R2 နဲ့ R4 တို့ရဲ့ Routing
table ကို ပြန်ကြည့်ကြည့်မယ်ဗျာ။
R3(config)#int fa1/0
R3(config-if)#ip ospf 1 area 0
R2#show ip route 1.1.1.1
Routing entry for 1.1.1.0/24
Known via "rip", distance 120, metric 1
Redistributing via rip
Last update from 172.16.123.1 on FastEthernet1/0, 00:00:02 ago
Routing Descriptor Blocks:
*
172.16.123.1, from 172.16.123.1, 00:00:02 ago, via FastEthernet1/0
Route metric is 1, traffic share count is
1
R2#
R2#show ip ospf database external 1.1.1.0
OSPF Router with ID (0.0.0.2) (Process
ID 1)
Type-5 AS External Link States
LS age: 1203
Options: (No TOS-capability, DC, Upward)
LS Type: AS External Link
Link State ID: 1.1.1.0
(External Network Number )
Advertising Router: 0.0.0.3
LS Seq Number: 80000007
Checksum: 0x2536
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link
state path)
MTID: 0
Metric: 20
Forward Address:
172.16.123.1
External Route Tag: 0
R2#
R2#traceroute 1.1.1.1
Type escape sequence to abort.
Tracing the route to 1.1.1.1
VRF info: (vrf in name/id, vrf
out name/id)
1
172.16.123.1 16 msec 28 msec 40 msec
R2#
R4#show ip route 1.1.1.1
Routing entry for 1.1.1.0/24
Known via "ospf 1", distance 110, metric 20, type extern 2,
forward metric 3
Last update from 192.168.24.2 on GigabitEthernet0/0, 03:10:32 ago
Routing Descriptor Blocks:
*
192.168.24.2, from 0.0.0.3, 03:10:32 ago, via GigabitEthernet0/0
Route metric is 20, traffic share count
is 1
R4#
R4#
R4#show ip ospf database external 1.1.1.0
OSPF Router with ID (0.0.0.4)
(Process ID 1)
Type-5 AS External Link States
Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 1307
Options: (No TOS-capability, DC, Upward)
LS Type: AS External Link
Link
State ID: 1.1.1.0 (External Network Number )
Advertising Router: 0.0.0.3
LS Seq Number: 80000007
Checksum: 0x2536
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link
state path)
MTID: 0
Metric: 20
Forward Address: 172.16.123.1
External Route Tag: 0
R4#
R4#traceroute 1.1.1.1
Type escape sequence to abort.
Tracing the route to 1.1.1.1
VRF info: (vrf in name/id, vrf
out name/id)
1 192.168.24.2 12 msec 28
msec 40 msec
2 172.16.123.1 68 msec 72
msec 76 msec
R4#
Non-Zero Forwarding Address ကိုတွေ့ရမှာဖြစ်ပြီး
R2 ကနေ R1 loopback ကို တိုက်ရိုက်သွားနိုင်သလို၊ R4 ကနေ R1 loopback ကိုသွားရင်လည်း
အရင်လို R3 ကနေဖြတ်စရာမလိုပဲ R2 ကနေသွားနိုင်တာကို တွေ့ရပါမယ်။
Forwarding Address အကြောင်းပြောတဲ့အခါ
NSSA Forwarding Address နဲ့ Non-NSSA Forwarding Addrssing ဆိုပြီး (၂) မျိုးပြောမှ
ပြည့်စုံမှာပါ။
NSSA Forwarding Address ကတော့ သူ့ရဲ့
Type-7 LSA ထဲမှာ Non-zero Forwarding Address ကို အမြဲထည့်ပြီး Announce လုပ်မှာဖြစ်ပြီး၊
ABR ကနေ type 7
translate suppress-fa ဆိုတဲ့ command နဲ့ Forwarding Addressing ကို
suppress လုပ်လိုက်မှ zero forwarding address ကို ပြောင်းသွားမှာဖြစ်ပါတယ်။
Non-NSSA Forwarding Address ကတော့
အပေါ်က ကျတော်ရှင်းပြတဲ့ Lab ကိုပြောတာပါပဲ။
ကဲ…ဒါပါပဲဗျာ။
ပျော်ရွှင်ပါစေဗျာ။
(Be knowledgeable, pass it on
then)
Capability Transit to prevent Virtual-Links Routing Loops in OSPF
ပြီးခဲ့တဲ့
ပို့စ်မှာ Capability Transit ဆိုတာ ဘာလဲ ဆိုတာနဲ့ Virtual Link တွေနဲ့ တွဲသုံးပုံကို
ရှင်းပြပြီးပါပြီ။
ဒီတခါ
Capability Transit ကို Disable လုပ်လိုက်တဲ့အခါ Virtual Link Route တွေမှာ Loop ဖြစ်တာကို
နည်းနည်းဝေမျှချင်ပါတယ်။
အောက်ကပုံကိုကြည့်ပါ။
R2 ကနေ
R4 ရဲ့ loopback ကို သွားတဲ့ Route ကိုကြည့်ပါမယ်။ Traceroute လုပ်ကြည့်ပါမယ်။
ဒီမှာ ကျတော်
R2 ရဲ့ Capability Transit ကို Disable လုပ်ထားပါမယ်။ ကျန်တဲ့ Router တွေ(Virtual
Link ထိုးထားတဲ့ R1 , R3) မှာတော့ Default အတိုင်းပဲ Enable လုပ်ထားပါမယ်။
R2(config)#router
ospf 1
R2(config-router)#no
capability transit
R2(config-router)#end
R2#show
ip route 4.4.4.4
Routing
entry for 4.4.4.4/32
Known via "ospf 1", distance 110,
metric 129, type inter area
Last update from 172.16.23.3 on Serial2/1,
00:00:48 ago
Routing Descriptor Blocks:
* 172.16.23.3, from 3.3.3.3, 00:00:48 ago,
via Serial2/1
Route metric is 129, traffic share count
is 1
R2#
R2#trace
4.4.4.4
Type
escape sequence to abort.
Tracing
the route to 4.4.4.4
VRF
info: (vrf in name/id, vrf out name/id)
1 172.16.23.3 36 msec 28 msec 32 msec
2 172.16.34.4 56 msec 64 msec 60 msec
ပုံမှန်ပါပဲ။
R2 က R4 loopback ကိုသွားဖို့ R3 ကနေဖြတ်သွားတယ်။
ကဲ… အခု လိုအပ်ချက်အရ
R2 မှာ Loopback Interface တခုထပ်ထည့်ပြီး Area 2 ထဲကို ထည့်မယ်။
Area 2 ကို
isolated area ဖြစ်မနေဖို့အတွက် Backbone Area (Area 0) နဲ့ ချိတ်ရမယ်။ ဒီတော့ R2 နဲ့
R1 ကို Virtual Link ထိုးရမယ်။ အောက်ကပုံမှာကြည့်ပါ။
R2#config
t
Enter
configuration commands, one per line.
End with CNTL/Z.
R2(config)#int
lo0
R2(config-if)#
*Aug 22
10:51:10.975: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to up
R2(config-if)#ip
add 2.2.2.2 255.255.255.0
R2(config-if)#ip
ospf 1 area 2
R2(config-if)#exit
R2(config)#router
ospf 1
R2(config-router)#area
123 virtual-link 1.1.1.1
R2(config-router)#end
R2#
*Aug 22
10:51:51.667: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on OSPF_VL1 fr
om LOADING to FULL, Loading Done
*Aug 22
10:51:52.607: %SYS-5-CONFIG_I: Configured from console by console
R2#
ပြီးတာနဲ့
R4 Loopback ကို သွားတဲ့ လမ်းကြောင်းကို ပြန်ကြည့်ကြည့်ရအောင်။
R2#show
ip route 4.4.4.4
Routing
entry for 4.4.4.4/32
Known via "ospf 1", distance 110,
metric 257, type inter area
Last update from 172.16.12.1 on Serial2/0,
00:00:18 ago
Routing Descriptor Blocks:
* 172.16.12.1, from 3.3.3.3, 00:00:18 ago, via Serial2/0
Route metric is 257, traffic share count
is 1
R2#
R3 ကနေသွားရမယ့်
Route က R1 ကနေသွားနေတာကို မြင်လားမသိဘူး။ ဇာတ်လမ်းက စပါပြီ။ အဲဒီတော့ ဘာဖြစ်မယ်ထင်လဲ
R2 ကနေ R1 ကို ပို့ ၊ R1 ကနေ R2 ကိုပို့ နဲ့ loop ဖြစ်နေပါပြီ။ မယုံရင် R4
loopback ကို traceroute လုပ်ကြည့်ကြည့်ပါ။
R2#trace
4.4.4.4
Type
escape sequence to abort.
Tracing
the route to 4.4.4.4
VRF
info: (vrf in name/id, vrf out name/id)
1 172.16.12.1 8 msec 56 msec 32 msec
2 172.16.12.2 40 msec 60 msec 44 msec
3 172.16.12.1 40 msec 56 msec 52 msec
4 172.16.12.2 88 msec 100 msec 60 msec
5 172.16.12.1 92 msec 52 msec 96 msec
6 172.16.12.2 120 msec 72 msec 92 msec
7 172.16.12.1 92 msec 92 msec 92 msec
8 172.16.12.2 160 msec 140 msec 156 msec
ဒါပါပဲ။ ဒါကြောင့်
Default မှာ Enable လုပ်ထားတဲ့ Capability Transit ဆိုတာ Virtual Link Route မှာ ဖြစ်တတ်တဲ့
loop တွေကို ကာကွယ်ဖို့ပါ။ loop မဖြစ်စေချင်ရင်တော့ R2 ရဲ့ ospf process အောက်မှာ capability transit ဆိုတာလေး ထည့်ပေးလိုက်တာနဲ့ ရပါတယ်။
တကယ်တော့
OSPF Equal Cost Load Balancing အကြောင်းနဲ့ OSPF LSA Type အကြောင်းတွေ ကောင်းကောင်းနားလည်တဲ့အခါ
ကျရင် Capability Transit ကို တခါတရံမှာ Disable လုပ်ပေးဖို့လိုတဲ့အခါတွေလဲ ရှိပါသေးတယ်။
ဒါတွေကိုတော့ အသေးစိတ်မရေးတော့ပါဘူး။
Expert တွေကတော့
Virtual Link ကို အတတ်နိုင်ဆုံး မိမိ Network Design မှာ မသုံးဖို့နဲ့ မဖြစ်မနေ ယာယီအနေနဲ့
သုံးဖို့လိုလာရင်လည်း ယာယီကနေ အမြဲတမ်း ဖြစ်မသွားစေဖို့ ဂရုစိုက်ဖို့လိုကြောင်းပြောလေ့ရှိကြပါတယ်။
ပျော်ရွှင်ပါစေဗျာ။
(Be
knowledgeable, pass it on then)
Capability Transit in OSPF
CCIE အတွက်လေ့လာရင်း Study Partner သူငယ်ချင်းတွေနဲ့ ငြင်းကြခုံကြ ရတဲ့ Topic တခုပေါ့ဗျာ။
Capability Transit ဆိုတာ Cisco IOS တွေမှာ Default အနေနဲ့ Enable လုပ်ထားပြီးသားပါ။
သူ့ကို Cisco ကရှင်းပြထားတာကတော့ Route တခုက သူသွားချင်တဲ့ နေရာကို သွားဖို့ အနည်းဆုံး လမ်း ၂ လမ်းရှိပြီး အတိုဆုံးလမ်းက Non-Backbone Area (Area 0 မဟုတ်တဲ့ Standard Area) ကို ဖြတ်သွားတယ်ဆိုရင် အဲ့ဒီ လမ်းကနေပဲသွားဖို့သုံးတာပါတဲ့။ ရှုပ်သွားလားမသိဘူး။
အောက်က ပုံကိုကြည့်ကြည့်ပါ။
Area 2 ရဲ့ R4 ကနေ Area 0 မှာရှိတဲ့ R3 ရဲ့ Network 1 နဲ့ Network 2 တွေကိုသွားတာပါ။
ဒီပုံထဲက Interface တွေနဲ့ IP Address, OSPF Area တွေကို Router တွေမှာ ကျတော် Configure လုပ်ထားပါတယ်။
နောက်ပြီး R1 နဲ့ R4 ကို Virtual Link ထိုးထားပါသေးတယ်။ ဒီ Capability Transit ဆိုတာကို လျှာရှည်ချင်လို့ပါ။
(မိတ်ဆွေတို့လည်း စိတ်ပါရင် ကိုယ်တိုင်လုပ်ကြည့်နိုင်ပါတယ်။)
စလိုက်ကြရအောင်...
Configuration တွေဘာမှ မပြောင်းသေးပဲ R4 ရဲ့ OSPF Routing Table ကိုကြည့်ရအောင်...
R4#show ip route ospf
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 4 subnets, 3 masks
O 10.1.13.0/29 [110/74] via 10.1.124.1, 00:00:32, Ethernet0/0
O 10.1.23.0/29 [110/74] via 10.1.124.2, 00:00:32, Ethernet0/0
172.16.0.0/16 is variably subnetted, 8 subnets, 2 masks
O 172.16.101.1/32 [110/11] via 10.1.124.1, 00:00:42, Ethernet0/0
O 172.16.101.2/32 [110/11] via 10.1.124.2, 00:00:42, Ethernet0/0
O 172.16.103.3/32 [110/75] via 10.1.124.2, 00:00:32, Ethernet0/0
[110/75] via 10.1.124.1, 00:00:32, Ethernet0/0
O 172.16.133.3/32 [110/75] via 10.1.124.2, 00:00:32, Ethernet0/0
[110/75] via 10.1.124.1, 00:00:32, Ethernet0/0
R4#
R3 ရဲ့ Network 1 , Network 2 တွေကို R4 ကနေသွားဖို့ R1 နဲ့ R4 ကို Virtual Link ထိုးထားပေမယ့်၊ R1 , R2 ၂ ခုစလုံးဆီကနေ သွားနိုင်တာကိုတွေ့ရမှာပါ။
ဒီတော့ Cisco IOS တွေမှာ Capability Transit ဆိုတာကို Default အနေနဲ့ Enable (on) ထားပြီးသားဖြစ်နေတဲ့အတွက် Virtual Link ပေါ်ကနေသွားလို့ရနေတာကို မရတော့အောင် ကျတော် R2 ရဲ့ Cost ကို ပြင်လိုက်မယ်ဗျာ။
!
interface Serial2/1
ip address 10.1.23.2 255.255.255.248
ip ospf 1 area 0
ip ospf cost 1
serial restart-delay 0
!
ပြင်ပြီးတာနဲ့ R4 ရဲ့ OSPF Routing Table ကိုပြန်ကြည့်ရအောင်...
R4#show ip route ospf
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 4 subnets, 3 masks
O 10.1.13.0/29 [110/74] via 10.1.124.1, 00:32:04, Ethernet0/0
O 10.1.23.0/29 [110/11] via 10.1.124.2, 00:01:45, Ethernet0/0
172.16.0.0/16 is variably subnetted, 8 subnets, 2 masks
O 172.16.101.1/32 [110/11] via 10.1.124.1, 00:32:14, Ethernet0/0
O 172.16.101.2/32 [110/11] via 10.1.124.2, 00:32:14, Ethernet0/0
O 172.16.103.3/32 [110/12] via 10.1.124.2, 00:01:45, Ethernet0/0
O 172.16.133.3/32 [110/12] via 10.1.124.2, 00:01:45, Ethernet0/0
R4#
R1 ကို မသုံးတော့ပဲ R2 ကိုပဲသုံးတော့တာကို တွေ့ရမှာပါ။ ဒါဘာကြောင့်လဲ အပေါ်မှာ ပြောခဲ့သလိုပါပဲ Capability Transit ကို Enable (on) ထားလို့ပါ။
ဒီတခါ... အပေါ်က R2 ရဲ့ Cost Value 1 အတိုင်းကို မပြောင်းပဲ Capability Transit ကိုပဲ Disable (off) ကြည့်ပြီး ထွက်လာတဲ့ Result ကိုကြည့်ပါမယ်။
R1(config)#router ospf 1
R1(config-router)#no capability transit
R1(config-router)#end
R4(config)#router ospf 1
R4(config-router)#no capability transit
R4(config-router)#end
R4#show ip route ospf
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 4 subnets, 3 masks
O 10.1.13.0/29 [110/74] via 10.1.124.1, 00:00:05, Ethernet0/0
O 10.1.23.0/29 [110/138] via 10.1.124.1, 00:00:05, Ethernet0/0
172.16.0.0/16 is variably subnetted, 8 subnets, 2 masks
O 172.16.101.1/32 [110/11] via 10.1.124.1, 00:00:05, Ethernet0/0
O 172.16.101.2/32 [110/11] via 10.1.124.2, 00:00:05, Ethernet0/0
O 172.16.103.3/32 [110/75] via 10.1.124.1, 00:00:05, Ethernet0/0
O 172.16.133.3/32 [110/75] via 10.1.124.1, 00:00:05, Ethernet0/0
R4#
ဒီတခါတော့ R2 အစား R1 ကိုရွေးသွားတာကို တွေ့ရမှာပါ။
ကဲ… Capability Transit ဆိုတာ ဒါပါပဲ။
သူ့ကို Virtual Link တွေနဲ့ သုံးတဲ့အခါ On မထားရင် Routing Loop ဖြစ်နိုင်တဲ့အတွက် သတိထားဖို့လိုအပ်ပါတယ်။
ဘယ်လိုမျိုး loop ဖြစ်နိုင်လဲ ဆိုတာ နောက်ပို့စ်တခုအနေနဲ့ ရေးပါအုံးမယ်။
ပျော်ရွှင်ပါစေဗျာ။
(Be knowledgeable, pass it on then)
Tool Command Language Simple Shell (TCLSH) in HP Switch
ဒီတခါတော့ (Hub and Spoke) လို Network မှာ Spoke Network Node တွေအများကြီးကို Hub ဖက်ကနေ IP Connectivity Test လုပ်ပုံလေး ပြန်ဝေမျှချင်ပါတယ်။
Cisco Router တွေ Switch တွေမှာတော့ သုံးနေတာကြာပါပြီ။ အခု HP Device တွေကို လက်ရှိ Project မှာ သုံးနေတော့မှ ပဲ လိုအပ်ချက်ရ IP Connectivity Test လုပ်ရတဲ့အခါ Node တွေအများကြီးကို PING Test လုပ်ရတာ အတော် လက်ဝင်ပါတယ်။
ဒီတော့မှ ထုံးစံအတိုင်း ငပျင်းကျတော် ရှာရင်းဖွေရင်း TCLSH ကို HP မှာလည်း သုံးလို့ရတာသွားတွေ့ပါတယ်။
သုံးပုံက လွယ်ပါတယ်။
Device ထဲ console/remote shell ကနေဝင်ပြီးတာနဲ့ user view mode မှာတင် အောက်မှာ နမူနာ ပြထားသလို ရိုက်ထည့်လိုက်ရုံပါပဲ။ IP Address တွေနေရာမှာတော့ ကိုယ့် Node IP Address တွေကိုထည့်ပေါ့။
tclsh
foreach address {
192.168.5.1
192.168.5.2
192.168.5.3
192.168.5.4
192.168.5.5
192.168.5.6
192.168.5.7
192.168.5.8
} { ping $address }
နောက်ဆုံး တကြောင်းရိုက်ထည့်ပြီး Enter နှိပ်လိုက်တာနဲ့ PING result တွေထွက်လာပါလိမ့်မယ်။
Test လုပ်ချင်တာတွေလုပ်ပြီးရင်တော့ tclshquit ဆိုတာလေးရိုက်ပြီး ထွက်လိုက်ရုံပါပဲ။
အသေးစိတ် သိချင်ရင်တော့ အောက်ကလင့်မှာ သွားဖတ်နိုင်ပါတယ်။
ပျော်ရွှင်ပါစေဗျာ။
(Be knowledgeable, pass it on then)
Multilink Point to Point (MLPPP) in Cisco Router
စာမရေးဖြစ်တာကြာပါပြီ။
ဒီတခါတော့ CCNA Version အသစ်မှာ ပါလာတဲ့ Multilink Point to Point ကိုဘယ်လို Configure လုပ်လဲ ဆိုတာ နည်းနည်းပြောမှာပါ။
အပြင်မှာလည်း အသုံးများတဲ့ တခုဖြစ်ပါတယ်။ ကျတော်ကိုယ်တိုင်လည်း လက်ရှိ Project မှာ ဒါကိုသုံးနေရပါတယ်။
နမူနာအနေနဲ့ အောက်က Topology ကိုသုံးပါမယ်။
လုပ်ရမှာကတော့ Router ၂ လုံးကို Serial Link ၂ ခု၊ IP Address တခုတည်းနဲ့ သုံးမှာပါ။
ဒီလိုလုပ်ခြင်းအားဖြင့် Bandwidth ပိုရစေတယ်။ Link Redundancy (ဒီအတွက်တော့ ပိုမိုရှုပ်ထွေးတဲ့ Configuration လိုပါတယ်) ရပြီးသားဖြစ်ပါတယ်။
ကဲ စလိုက်ရအောင်
ပထမဆုံး Multilink Bundle ကို အောက်ပါအတိုင်း Router ၂ လုံးစလုံးမှာ Configure လုပ်ပါ။ IP Address တော့မတူရဘူးပေါ့။ Bundle create လုပ်ပြီးတာနဲ့ loopback create လုပ်သလိုမျိုး virtual interface တခုပေါ်လာတာကို တွေ့ရပါလိမ့်မယ်။ အောက်မှာ နမူနာပြထားပါတယ်။
For Router 1
interface multilink 1
ip address 172.16.12.1 255.255.255.252
encapsulation ppp
ppp multilink
ppp multilink group 1 (ဒါကတော့ Serial Interface တွေအများကြီးသုံးချင်တဲ့အခါ Group ခွဲပြီးသုံးဖို့ပါ။)
For Router 2
interface multilink 1
ip address 172.16.12.2 255.255.255.252
encapsulation ppp
ppp multilink
ppp multilink group 1
ပြီးရင် Serial Interface တွေကို အောက်ပါအတိုင်း Router ၂ လုံးစလုံးမှာ Configure လုပ်ပါ။
For Router 1
interface serial0/1
no ip address
encapsulation ppp
ppp multilink
ppp multilink group 1
interface serial0/2
no ip address
encapsulation ppp
ppp multilink
ppp multilink group 1
For Router 2
interface serial0/1
no ip address
encapsulation ppp
ppp multilink
ppp multilink group 1
interface serial0/2
no ip address
encapsulation ppp
ppp multilink
ppp multilink group 1
ကျတော် GNS3 မှာ Configure လုပ်ပြထားတာကို အောက်မှာ နမူနာပြထားပါတယ်။
တခုမမေ့ဖို့က Default မှာ shutdown ဖြစ်နေတဲ့ Serial Interface တွေကို no shutdown လုပ်ပေးဖို့ပါ။
R1#config t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#
R1(config)#interface multilink 1
R1(config-if)#ip address 172.16.12.1 255.255.255.252
R1(config-if)#encapsulation ppp
R1(config-if)#ppp multilink
R1(config-if)#ppp multilink group 1
R1(config-if)#
*Mar 1 00:11:40.995: %LINEPROTO-5-UPDOWN: Line protocol on Interface Multilink1, changed state to down
R1(config-if)#exit
R1(config)#
R1(config)#interface serial0/1
R1(config-if)#no ip address
R1(config-if)#encapsulation ppp
R1(config-if)#ppp multilink
R1(config-if)#ppp multilink group 1
R1(config-if)#exit
R1(config)#
R1(config)#interface serial0/2
R1(config-if)#no ip address
R1(config-if)#encapsulation ppp
R1(config-if)#ppp multilink
R1(config-if)#ppp multilink group 1
R1(config-if)#
R1(config-if)#exit
R1(config)#exit
R2#config t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#interface multilink 1
R2(config-if)#ip address 172.16.12.2 255.255.255.252
R2(config-if)#encapsulation ppp
R2(config-if)#ppp multilink
R2(config-if)#ppp multilink group 1
R2(config-if)#exit
R2(config)#
*Mar 1 00:14:52.131: %LINEPROTO-5-UPDOWN: Line protocol on Interface Multilink1, changed state to down
R2(config)#
R2(config)#
R2(config)#interface serial0/1
R2(config-if)#no ip address
R2(config-if)#encapsulation ppp
R2(config-if)#ppp multilink
R2(config-if)#ppp multilink group 1
R2(config-if)#exit
R2(config)#
R2(config)#interface serial0/2
R2(config-if)#no ip address
R2(config-if)#encapsulation ppp
R2(config-if)#ppp multilink
R2(config-if)#ppp multilink group 1
R2(config-if)#
R2(config-if)#exit
R2(config)#
ပြီးရင် ကိုယ်လုပ်ထားတာ မှန် မမှန် အောက်ပါအတိုင်း စစ်ကြည့်ပါ။
R1#show ppp multilink
Multilink1, bundle name is R2
Endpoint discriminator is R2
Bundle up for 00:15:58, total bandwidth 3088, load 1/255
Receive buffer limit 24000 bytes, frag timeout 1000 ms
0/0 fragments/bytes in reassembly list
0 lost fragments, 0 reordered
0/0 discarded fragments/bytes, 0 lost received
0x36 received sequence, 0x36 sent sequence
Member links: 2 active, 0 inactive (max not set, min not set)
Se0/1, since 00:15:58
Se0/2, since 00:15:54
No inactive multilink interfaces
R1#
R2#show ppp multilink
Multilink1, bundle name is R1
Endpoint discriminator is R1
Bundle up for 00:16:13, total bandwidth 3088, load 1/255
Receive buffer limit 24000 bytes, frag timeout 1000 ms
0/0 fragments/bytes in reassembly list
0 lost fragments, 0 reordered
0/0 discarded fragments/bytes, 0 lost received
0x38 received sequence, 0x38 sent sequence
Member links: 2 active, 0 inactive (max not set, min not set)
Se0/1, since 00:16:13
Se0/2, since 00:16:10
No inactive multilink interfaces
R2#
မှန်ပြီဆိုရင် PING ကြည့်ပါ။ Reply ရပြီဆိုရင် Multilink Point to Point Configuration အောင်မြင်စွာနဲ့ ပြီးဆုံးပါပြီ။
R1#ping 172.16.12.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.12.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/19/56 ms
R1#
R2#ping 172.16.12.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.12.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/22/68 ms
R2#
ဒါပါပဲ။ သုံးပြထားတာကတော့ GNS3 နဲ့ Cisco 3640 , IOS Version 12.4(16) ပါ။
တကယ်တော့ MLPPP ဟာ တကယ့် environment မှာ လိုအပ်ချက်ပေါ်လိုက်ပြီး အခု ကျတော်ပြောတာထက် ပိုအသေးစိတ်ကျကျ Configure လုပ်ရပါတယ်။
အသေးစိတ်သိချင်ရင်တော့ အောက်က Cisco Link မှာ သွားလေ့လာနိုင်ပါတယ်။
Reference : http://www.cisco.com/c/en/us/td/docs/ios/ios_xe/wan/configuration/guide/xe_3s/wan_xe_3s_book/wan_cfg_mlppp_conn_xe.html
ပျော်ရွှင်ပါစေဗျာ။
(Be knowledgeable, pass it on then)
You Might Not Know You Are Still Using SSLv2.0
၁၉၉၄ ခုနှစ်မှာ
Secure Sockets Layer (SSL) Protocol ဆိုတာကို Netscape Communications က တီထွင်ခဲ့ပါတယ်။
အဲဒီအချိန်တည်းက
SSL ဆိုတာ နေရာယူလာခဲ့တာ နှစ်ပေါင်းအတော်ကြာပါပဲ။
နှစ်တွေကြာလာတာနဲ့အမျှ
Protocol က ပြောင်းလဲ လာလိုက်တာ SSLv2.0 -> SSLv3.0 -> TLSv1.0 ->
TLSv1.1 -> TLSv1.2 တွေအထိဖြစ်လာပါပြီ။
ဒီလိုပြောင်းလာပေမယ့်
ခုထိ SSLv2.0 ကို အသုံးများနေကြတာကို တွေ့နေရတုန်းပါ။
ဒီဖက်ခေတ်မှာ
SSLv2.0 ဟာ လုံလောက်တဲ့ လုံခြုံရေး စနစ်တခုမဟုတ်တော့ပါဘူး။ သူ့မှာ အောက်မှာ ပြောထားတဲ့
အားနည်းချက်တွေရှိပါတယ်။
- Client – Server Message Authentication အတွက် MD5 ဆိုတာကိုသုံးပါတယ်။ MD5 ဟာ မလုံခြုံတော့ပါဘူး။
- Connection စဖို့ Handshake Message တွေပို့တဲ့အခါ Protection မလုပ်ပါဘူး။ ဒီအချက်ကပဲ attacker တွေဟာ man-in-the-middle attack ကိုသုံးပြီး client တွေကို အားနည်းတဲ့ cipher suite ကို ရွေးစေခြင်းဖြင့် အချက်အလက်လုံခြုံရေးကို ခြိမ်းခြောက်လာစေပါတယ်။
- Message Integrity, Message Encryption တွေအတွက် တူညီတဲ့ Key တွေကို အသုံးပြုပါတယ်။ ဒီအချက်ဟာလည်းပဲ အားနည်းတဲ့ Encryption Algorithm ကို Negotiatation အတွက်သုံးတဲ့ Client – Server တွေရဲ့ အချက်အလက် လုံခြုံရေးကို ခြိမ်းခြောက်လာစေပါတယ်။
- Client – Server တွေရဲ့ Session တွေကို လွယ်လွယ်ကူကူပဲ Terminate လုပ်နိုင်ပါတယ်။ ဒီအချက်ကတော့ man-in-the-middle attacker အနေနဲ့ TCP FIN packet တခုထည့်ပြီး session ကို Terminate လုပ်လိုက်နိုင်ပါတယ်။ အဲဒီလိုလုပ်လိုက်တာကို Client – Server တွေအနေနဲ့ ပုံမှန် Session Terminate ဟုတ်တယ် မဟုတ်ဘူး ဆိုတာ မခွဲခြားနိုင်တာက ပြဿနာပါ။
SSLv2.0
ပေါ်လာတာ နှစ် ၂၀ ကျော်ကြာခဲ့ပါပြီ။ သူ့ရဲ့ အားနည်းချက်တွေကိုလဲ RFC 6176 နဲ့ လွန်ခဲ့တဲ့
၅ နှစ်ကျော်ကတည်းက ထောက်ပြပြီးပါပြီ။ ဒါပေမယ့် ဒီအားနည်းချက်ရှိတဲ့ SSLv2.0 ကို လူတော်တော်များများ
အသုံးပြုနေကြပါသေးတယ်။
ပြီးခဲ့တဲ့
ဇွန်လ ( ဇွန် ၊ ၂၀၁၆) မှာ ၂% ထက်နည်းတဲ့ SSLv2.0 Server Hello message တွေကို
Firewall တွေမှာ လက်ခံရရှိနေသေးပြီး ၄၀% ထက်များတဲ့ SSLv2.0 Client Hello message တွေကိုလည်း
Firewall တွေမှာ လက်ခံရရှိနေပါသေးတယ်တဲ့။
အပေါ်မှာပြောခဲ့သလိုပဲ
SSLv2.0 ဟာ လုံခြုံရေး အားနည်းချက်တွေ ရှိနေပြီဖြစ်တဲ့အတွက် သင့်ရဲ့ System တွေအတွက်
အန္တရာယ်နေပါပြီ။ ဒီအတွက် Client/Server Software Setting တွေကို ပြန်လည်စစ်ဆေးဖို့လိုအပ်နေပြီး၊
SSLv2.0 အသုံးပြုနေခြင်းကိုလဲ ရပ်ပြီး TLS1.2 ကိုသုံးသင့်ကြောင်း အသိပေးလိုက်ရပါတယ်။
Source
: Dell SonicWall Security Center
ပျော်ရွှင်ပါစေဗျာ။
(Be
knowledgeable, pass it on then)
Quality of Service – Classification with Network-Based Application Recognition
ပြီးခဲ့တဲ့ ပို့စ်မှာ Access-List ကိုသုံးပြီး Traffic ကို Classify လုပ်ပြခဲ့ပါတယ်။
အခုတခါတော့ Network-Based
Application Recognition (NBAR) ကိုသုံးပြီး Traffic ကို Classify လုပ်ပုံကိုရှင်းပြပါအုံးမယ်။
အောက်က Topology ကိုပဲ သုံးပြီး
Router 1 ရဲ့ Fa1/0 interface ကို ဝင်လာမယ့်
Traffic တွေကိုထဲက Telnet ကို Classify လုပ်ကြည့်ပါမယ်။
(IP Address , Interface
Configuration တွေကိုတော့ မိမိဖာသာပဲ Configure လုပ်ကြည့်ပါ။)
QoS ကို configure မလုပ်ခင် ကျတော်
Router 1 ရဲ့ Fa1/0 ကို ဝင်လာတဲ့ Traffic ကို စစ်ပြပါမယ်။ အောက်မှာ ကြည့်ပါ။ ပထမဆုံး
အနေနဲ့ nbar protocol-discovery ကို configure လုပ်ပေးဖို့လိုပါတယ်။
R1(config)#interface fastEthernet
1/0
R1(config-if)#ip nbar
protocol-discovery
ပြီးတာနဲ့ အောက်ကလို စစ်နိုင်ပါတယ်။
R1#show ip nbar
protocol-discovery
လောလောဆယ် တော့ protocl နေရာမှာ
ping တခုပဲ ရှိနေတာကိုတွေ့ရမှာပါ။
တခြားဘယ်လို traffic, protocol တွေ
ကိုယ့် router interface မှာ သွားနေတယ်ဆိုတာကို စစ်ဖို့ အတော်လေးကောင်းမွန်တဲ့နည်းလမ်းပေါ့ဗျာ။
ဒါပေမယ့် ဘယ် Traffic, Protocol ဆိုရင်တော့
ဘာလုပ်ဖို့ဆိုတဲ့ အလုပ်မျိုးလုပ်ဖို့အတွက် QoS ကို configure
လုပ်မယ်ဆိုရင်တော့ nbar ကို
class-map အနေနဲ့ configure လုပ်ပေးရပါမယ်။
အောက်မှာကြည့်ပါ။
R1(config)#
R1(config)#class-map NBAR-Telnet
R1(config-cmap)#match protocol
telnet
NBAR-Telnet ဆိုတဲ့ class-map တခုဖန်တီးပြီး
match protocol ကိုတော့ telnet protocol ကိုသုံးတဲ့ traffic တွေကို classify လုပ်ဖို့အတွက်
telnet ကို ပေးထားပါတယ်။
ပြီးတာနဲ့ policy-map ဆောက်ပေးရပါမယ်။
R1(config)#policy-map Restricted
R1(config-pmap)#class NBAR-Telnet
နောက်ဆုံးအနေနဲ့ ကိုယ်လိုချင်တဲ့
interface မှာ service-policy ကို attach လုပ်ပါမယ်။
ဒီမှာတော့ Fa1/0 ပေါ့။ ကျတော်
traffic in ရော traffic out ရောကိုပါ စစ်ပါမယ်။
R1#config t
R1(config)#int fa1/0
R1(config-if)#service-policy
input Restricted
R1(config-if)#service-policy
output Restricted
ဒါဆို configuration လုပ်တာပြီးပါပြီ။
မှန်မမှန်စစ်ဖို့အတွက် R2 ကနေ R1 ကို
Ping နဲ့ Telnet တွေသုံးပြီး traffic တွေပို့ကြည့်ပါ။
R2#ping 172.16.21.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to
172.16.21.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent
(5/5), round-trip min/avg/max = 24/36/72 ms
R2#
R2#telnet 172.16.21.1
Trying 172.16.21.1 ... Open
ပြီးတာနဲ့ service-policy မှာ
match ဖြစ်တဲ့ traffic တွေကိုအောက်မှာပြထားသလို စစ်ကြည့်ပါ။ ကျတော် highlight လုပ်ပြထားတာကိုကြည့်ရင်
policy အလုပ်လုပ်တာကိုတွေ့ရမှာပါ။
R1#show policy-map interface
fa1/0
FastEthernet1/0
Service-policy input: Restricted
Class-map: NBAR-Telnet (match-all)
7 packets, 423 bytes
5 minute offered rate 0000 bps
Match: protocol telnet
Class-map: class-default (match-any)
9 packets, 816 bytes
5 minute offered rate 0000 bps, drop rate
0000 bps
Match: any
Service-policy output: Restricted
Class-map: NBAR-Telnet (match-all)
5 packets, 331 bytes
5 minute offered rate 0000 bps
Match: protocol
telnet
Class-map: class-default (match-any)
21 packets, 2202 bytes
5 minute offered rate 0000 bps, drop rate
0000 bps
Match: any
R1#
R1#show ip nbar
protocol-discovery
ကဲ… ဒီလောက်ဆို Network-Based
Application Recognition (NBAR) ကို QoS နဲ့သုံးပြီး Traffic တွေကို ဘယ်လို Classify
လုပ်လဲ ဆိုတာကိုသိပြီလို့ထင်ပါတယ်။
ပျော်ရွှင်ပါစေဗျာ။
(Be knowledgeable, pass it on
then)
Subscribe to:
Posts
(
Atom
)