დღეს-დღეობით როცა ინტენეტი თითქმის ყველა ორგანიზააციისთვის არის საარსებო წყარო , თავისთავად ჩნდება მოთხვონილება ინტერნეტის მაღალი საიმედოობის. ამის გადასაწყვეთად ქსელის დონეზე არსებობს რამდენიმე ნორმალური გადაწყვეტილება (რაც ჩემთვის არის ცნობილი). ამ პოსტში მინდა დავწერო როგორ შეიძლება ორ პროვაიდერთან IP SLA-ით და Policy Based Routing-ით ინტერნეტის მაღალი საიმედოობის უზრუნველყოფბა და ასევე დატვირთვის გადანაწილება (Load Sharing) . ამისთვის გავაკეთე შემდეგი LAB-ი.
Tasks:
Host1-იდან მომვალი ტრაფიკი Edge-მა უნდა გაიაროს ISP1-ის გავლით, მხოლოდ იმ შემთხვევაში თუ ISP1 გაითიშება ISP2-ის გავლით.
Host2-იდან მომავალი ტრაფიკი Edge-მა უნდა გაიაროს ISP2-ის გავლით, მხოლოდ იმ შემთხვევაში თუ ISP2 გაითიშება ISP1-ის გავლით.
იმაზე არ ვისაუბრებ თუ როგორ არის დაკონფიგურირებული როუტინგი უბრალოდ იმას გეტყვით რომ მაქსიმალურად შევეცადე რეალური 2 პროვაიდერის სცენარი გამეკეთებინა მარტივად. ISP1 ვერ ხედავს 192.168.3.0/24 და 192.168.5.0/24, შესაბამისად ISP2 ვერ ხედავს 192.168.2.0/24 და ასევე 192.168.4.0/24-ს.
პირველ რიგში Edge-ზე უნდა დავაკონფიგურიროთ NAT-ი, იქედან გამომდინარე, რომ INSIDE ინტერფეისი ერთი გვაქვს და OUTSIDE ინტერფეისი ორი გვაქვს, მე პირადად ვარჩევ რომ NAT-ი გავაკეთო route-map-ის დახმარებით.
NAT-ის კონფიგურაცია დავიწყოთ იმით რომ განვსაზღვროთ inside და outside ინტერფეისები.
interface FastEthernet1/0 ip address 192.168.1.1 255.255.255.0 ip nat inside interface Serial0/0 ip address 192.168.2.2 255.255.255.0 |
ამის შემდეგ დავწეროთ შემდეგი Route-map-ი NAT-ისთვის და NAT წესები. თუ Source-ი დაემთხვა host-ების IP მისამართებს და გამავლი Interface-ი დაემთხვა serial0/0 მაშინ შესრულდეს NAT და გადაითარგმნოს serial0/0-ის IP მისამართში, მხოლოდ თუ Srource-ი დაემთხვა host-ების IP მისამართებს და გამავალი Interface-ის დაემთხვა serial0/1 ამ შემთხვევაშიც შესრულდეს NAT-ი მაგრამ გავიდეს serial0/1 ის IP მისამართით. | ip access-list standard NAT permit 192.168.1.0 0.0.0.255
route-map NAT-ISP1 permit 10 match ip address NAT match interface Serial0/0
route-map NAT-ISP2 permit 10 match ip address NAT match interface Serial0/1
ip nat inside source route-map NAT-ISP1 interface Serial0/0 overload ip nat inside source route-map NAT-ISP2 interface Serial0/1 overload |
ეხლა კიდევ გადავიდეთ ყველაზე საინტერესო დეტალების კონფიგურაციაზე. მოკლედ გავაკეთოთ შემდგეი policy-ი თუ souce-ი იქნება Host1-ი მაშინ ინტერნეტისკენ მიმავალი ტრაფიკი წავიდეს ISP1-ის გავლით, მხოლოდ თუ Source-იქნება Host2 მაშინ ტრაფიკის წავიდეს ISP2-ის გავლით. მაგრამ თუ ISP1-ი გაითიშა (ჩვენს შემთხვევაში ვთქვათ ISP1 LO 1.1.1.1 მისამართი Edge-იდან მიუწვდომელი გახდა) მაშინ Host1-ის ტრაფიკი გავიდეს ISP2-ით და როცა კავშირი აღდგება მაშინ პირველად მგომარეობაში დაბრუნდეს ანუ HOST1-მა ისევ დაიწყოს სიარული ISP1-ით. შესაბამისად Host2-თვისაც იგივე გავაკეთოთ ანუ თუ ISP2 გაითიშა (ჩვენს შემთხვეაში ვთქვათ რომ Edge-იდან ISP2 LO 2.2.2.2 მიუწვდომადი გახდა) მაშინ Host2-მა დაიწყოს სიარული ISP2-ის გავლით.
ეს ყველაფერი რომ გავაკეთოთ და ავამუშაოთ პირველ რიგში უნდა შევქმნათ SLA monitor-ი რომლიც გარკვეულ პერიოდში გაპინგავს პროვაიდერების მისამრთებს ჩვენს მეთხვევაში ISP1-ის მხარეს გაპინფავს 1.1.1.1 და ISP2-ის მხარეს 2.2.2.2-ს. რეალურ სიტუაციში ესეთი მ��სამართი შერჩევა ცოტა არ იყოს რთულია და ამიტომ ჩემი აზრით ჯობია პროვიდერს ვკითხოთ თუ რომელი IP ვპინგოთ. თუ ვერ გაიპინგა ამის შესახებაც შეგვატყობინებს. ამის მერე უნდა გავაკეთოთ track object-ები სადაც მივაბავთ უკვე არსებულ SLA monitor-ებს და მოგვცემს საშუალებას მივაბათ track object-ები ზემოთ ხსნებებულ policy Route-ს. უი რაც მთავარი კინაღამ გამომრჩა edge-ზე უნდა გავწეროთ სტატიკური მარშუტები 1.1.1.1-ისკენ და 2.2.2.2-სკენ. SLA monitor 11 ამოწმებს კავშირს ISP1-თან და SLA monitor 22 ამოწმებს კავშირს ISP2-თან. შესაბამის ნომრებით მიბმულია Track object-ებთან
| ip route 1.1.1.1 255.255.255.255 192.168.2.1 ip route 2.2.2.2 255.255.255.255 192.168.3.1
ip sla monitor 11 type echo protocol ipIcmpEcho 1.1.1.1 source-ipaddr 192.168.2.2 frequency 5 ip sla monitor schedule 11 life forever start-time now
ip sla monitor 22 type echo protocol ipIcmpEcho 2.2.2.2 source-ipaddr 192.168.3.2 ip sla monitor schedule 22 life forever start-time now
track 11 rtr 11 reachability track 22 rtr 22 reachability |
შევამოწმოთ რაც გავაკეთეთ ხომ მუშაობას.| edge#ping 1.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/34/100 ms
edge#ping 2.2.2.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 12/68/148 ms
edge#show ip sla monitor statistics 11 Round trip time (RTT) Index 11 Latest RTT: 48 ms Latest operation start time: *18:30:04.425 UTC Sat Mar 2 2002 Latest operation return code: OK Number of successes: 358 Number of failures: 0 Operation time to live: Forever edge#show ip sla monitor statistics 22 Round trip time (RTT) Index 22 Latest RTT: 52 ms Latest operation start time: *18:30:14.429 UTC Sat Mar 2 2002 Latest operation return code: OK Number of successes: 30 Number of failures: 0 Operation time to live: Forever edge#show track 11 Track 11 Response Time Reporter 11 reachability Reachability is Up 2 changes, last change 1d18h Latest operation return code: OK Latest RTT (millisecs) 120 Tracked by: ROUTE-MAP 0 edge#show track 22 Track 22 Response Time Reporter 22 reachability Reachability is Up 2 changes, last change 1d18h Latest operation return code: OK Latest RTT (millisecs) 52 Tracked by: ROUTE-MAP 0 |
ყველაფერი წესრიგშია ეხლა გადავიდეთ route-map-ის კონფიგურაციაზე და შესაბამისად შემოწმებაზე. ასევე დაგვჭირდება Access-list-ები რომლიც მოგვცემს საშუალებს განვასხვავოთ HOST1 და HOST2-ი. Route-map-ი რომ გამოვიყენოთ PBR-ისთვის (policy Based Routing) უნდა დავადოთ შემომავალ ინტერფეისზე. ჩვენს შემთხვევაში Fa1/0-ზე
ოღოდ გასათავლისწინებელია ის ფაქთი რომ როუტერის მიერ გენერირებული ტრაფიკმა რომ შეხედოს Route-map-ს გლობალური კონფიგურაციის რეჟიმში უნდა დავამატოთ ბრძანება ip local policy route-map <route-map NAME>
| route-map PBR permit 10 description Host 1 Policy match ip address HOST1 set ip next-hop verify-availability 192.168.2.1 10 track 11 set ip next-hop verify-availability 192.168.3.1 20 track 22 route-map PBR permit 20 description Host 2 policy match ip address HOST2 set ip next-hop verify-availability 192.168.3.1 10 track 22 set ip next-hop verify-availability 192.168.2.1 20 track 11 interface FastEthernet1/0
ip address 192.168.1.1 255.255.255.0
ip nat inside
ip virtual-reassembly
ip policy route-map PBR
duplex auto
speed auto edge#show route-map PBR
route-map PBR, permit, sequence 10
Match clauses:
ip address (access-lists): HOST1
Set clauses:
ip next-hop verify-availability 192.168.2.1 10 track 11 [up]
ip next-hop verify-availability 192.168.3.1 20 track 22 [up]
Policy routing matches: 34 packets, 3876 bytes
route-map PBR, permit, sequence 20
Match clauses:
ip address (access-lists): HOST2
Set clauses:
ip next-hop verify-availability 192.168.3.1 10 track 22 [up]
ip next-hop verify-availability 192.168.2.1 20 track 11 [up]
Policy routing matches: 0 packets, 0 bytes |
ყველაფრის კონფიგურაციას მოვრჩით და შეიძლება უკვე შემოწმებაზე გადავიდეთ. Host1-იდან გავპინგოთ 10.10.10.10 და შევამოწმოთ traceroute-ი როგორ დადის Host1-ი ინტერნეტში და ასევე Host2-იდანაც იგივე უნდა გავაკეთოთ.
| host1#ping 1.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 28/52/108 ms host1#traceroute 10.10.10.1
Type escape sequence to abort. Tracing the route to 10.10.10.10 1 192.168.1.1 68 msec 92 msec 40 msec 2 192.168.2.1 128 msec 80 msec 16 msec 3 192.168.4.1 80 msec * 96 msec host2#ping 10.10.10.10 Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 32/83/136 ms
host2#traceroute 10.10.10.10 Type escape sequence to abort.
Tracing the route to 10.10.10.10 1 192.168.1.1 60 msec 72 msec 16 msec
2 192.168.3.1 52 msec 96 msec 32 msec
3 192.168.5.1 60 msec * 136 msec |
ვხედავთ რომ ტრაფიკი როგორც ზემოთ გვაქვს აღწერილი ისე დადის ანუ Host1 დადის ISP1-ის გავლით და Host2-ი დადის ISP2-ის გავლით. მოდით ეხლა გავთიშავ ISP1-ის s0/0 და თუ მოხდება Host1-ის გადართვა ISP2-ზე.
| edge#show route-map PBR route-map PBR, permit, sequence 10 Match clauses: ip address (access-lists): HOST1 Set clauses: ip next-hop verify-availability 192.168.2.1 10 track 11 [down] ip next-hop verify-availability 192.168.3.1 20 track 22 [up] Policy routing matches: 45 packets, 4806 bytes route-map PBR, permit, sequence 20 Match clauses: ip address (access-lists): HOST2 Set clauses: ip next-hop verify-availability 192.168.3.1 10 track 22 [up] ip next-hop verify-availability 192.168.2.1 20 track 11 [down] Policy routing matches: 10 packets, 816 bytes host1#traceroute 10.10.10.10 Type escape sequence to abort. Tracing the route to 10.10.10.10 1 192.168.1.1 120 msec 48 msec 40 msec 2 192.168.3.1 64 msec 64 msec 48 msec 3 192.168.5.1 176 msec * 112 msec |
Route-map-ში ჩანს რომ SLA monitor-ი 11 არის Down-ში და traceroute-ი რომ გავუშვით Host1-იდან გავიდა ISP2-ის გავლით. ანუ როგორც ჩვენ გვინდოდა და წინასწარ როგროც იყო განსაზღვრული ისე მოხდა.
config and Dynamips FilesTags:
LAB ,
Routing,
PBR,
IP SLA
Filter by APML
Subscribe