(1 Vote)

ติดตั้ง Policy-Based Routing บนเราเตอร์ Cisco Featured

ติดตั้ง Policy-Based Routing บนเราเตอร์ Cisco

               ท่ามกลางประสิทธิภาพการเชื่อมต่อสื่อสารระหว่างระบบเครือข่ายที่เพิ่มขึ้น องค์กรต่างๆมีความต้องการที่จะนำส่งข่าวสารในรูปแบบของ Packet ไปสู่จุดหมายปลายทางอย่างอิสระ และมีเป้าหมายของตนเองมากขึ้น โดยความต้องการเช่นนี้เอง ที่ทำให้ผู้ดูแลระบบเครือข่าย สามารถคาดการณ์หรือพยากรณ์การไหลของ Traffic บนเส้นทางต่างๆได้โดยง่าย ซึ่งสามารถทำได้โดยใช้วิธีการที่เรียกว่า Policy Based Routing (PBR)

               Cisco ได้นำเสนอวิธีการดังกล่าวบนระบบปฏิบัติการ IOS Release 11.0 ซึ่งจะช่วยให้เราเตอร์สามารถใช้วิธีการนี้สื่อสารบนเส้นทางต่างๆ และผู้ใช้งานสามารถเลือกเส้นทางที่จะนำส่ง Packet ไปสู่จุดหมายปลายทางได้ตามที่ต้องการ ซึ่งในการนี้ จะต้องมีเส้นทางไปสู่จุดหมายมากกว่าหนึ่งเส้นทางขึ้นไป

ภาพที่ 1 การติดตั้ง Policy Based Routing จะต้องมีเส้นทางอย่างน้อย 2 เส้น

 

               Policy Based Routing มีกลไกที่ให้บริการใส่ค่าลงไปไว้ใน IP Packet ดังนั้นใน Traffic ภายใต้ Application หนึ่งๆหรือมากกว่า จะได้รับการบริการเป็นพิเศษ เมื่อมีการทำงานร่วมกันกับเทคนิคการจัด Queuing ภายใต้ Cisco IOS เทคนิคการจัด Queuing นี้เป็นเครื่องมือที่มีความยืดหยุ่น สำหรับผู้จัดการะบบเครือข่ายในอันที่จะจัดตั้งนโยบายเกี่ยวกับ Routing ในเครือข่ายของเขา

               บทความต่อไปนี้จะได้กล่าวถึง ประสิทธิภาพการทำงานของ Policy Based Routing หรือ Routing เชิงนโยบายภายใต้การทำงานของระบบปฏิบัติการเครือข่ายของ Cisco

ประโยชน์ของ Policy Based Routing

  • ผู้ให้บริการ Internet และองค์กรทั่วไปสามารถใช้ Policy Based Routing เพื่อนำส่ง Traffic ไปตามเส้นทางต่างๆ โดยที่เป็น Traffic มาจาก ผู้ใช้งาน จาก Connection ต่างๆผ่าน Router ที่ติดตั้ง Policy Based Routing
  • คุณภาพการให้บริการ-  องค์กรสามารถใช้ QoS เพื่อแยกการให้บริการแบบต่างๆ 

             โดยเฉพาะ โดยการติดตั้งค่า Precedence หรือค่า Type of Service (TOS) บน IP Packet

              ก่อนที่จะดำเนินการ จัดลำดับความสำคัญของ Traffic ภายในแกนหลัก หรือ Core ของ

              เครือข่าย

  • ประหยัดค่าใช้จ่าย– องค์กรสามารถประหยัดค่าใช้จ่ายโดยการกระจาย Traffic ทั้งที่แบบ Interactive และแบบ Batch ไปบนเส้นทางที่มี Bandwidth ต่ำและเส้นทางที่มี Bandwidth สูงตามความสำคัญของ Application บน Traffic
  • ความสามารถในการทำ Load Sharing :  นอกเหนือจากมีขีดความสามารถในด้านการทำ Load Sharing แบบพลวัตรที่อาศัยแอดเดรสของจุดหมายปลายทางเป็นหลัก ซึ่ง IOS ของ Cisco ให้การสนับสนุน เมื่อเป็นเช่นนี้ผู้จัดการระบบเครือข่าย สามารถบังคับใช้นโยบาย เพื่อกระจาย Traffic ไปบนเส้นทางต่างๆตามที่ต้องการได้ โดยอาศัยลักษณะพิเศษของ Traffic

การส่งผ่าน Traffic ไปข้างหน้าภายใต้นโยบายการกำหนดเส้นทาง

               เป็นที่ทราบดีว่า Policy-Based Routing มีกลไกที่ช่วยให้นำเอานโยบายในการส่งผ่าน Traffic ไปข้างหน้ามาใช้งาน ภายใต้ข้อกำหนดของผู้จัดการระบบเครือข่าย เป็นกลไกที่มีความยืดหยุ่น สำหรับการส่ง Packet ไปบนเส้นทางโดยเราเตอร์ การทำงานดังกล่าวอยู่ภายใต้โปรโตคอลเลือกเส้นทางหรือ Routing Protocol

               เราเตอร์ สามารถส่งผ่าน Packet ไปข้างหน้าอาศัยข้อมูลข่าวสารจาก Static Routing หรือ Dynamic Routing Protocol เช่น RIP หรือ OSPF รวมทั้ง EIGRP แทนที่จะใช้เราติ้งเพื่ออาศัยแอดเดรสปลายทางเป็นหลัก แต่ Policy Based Routing จะช่วยให้ผู้จัดการระบบเครือข่าย สามารถใช้นโยบายที่กำหนดขึ้น เพื่อที่อนุญาตหรือปฏิเสธที่จะส่งผ่าน Traffic บนเส้นทางต่างๆโดยอาศัยข้อมูลดังนี้

  • ความมีตัวตนของระบบที่ปลายทาง
  • Application ที่ใช้
  • โปรโตคอลที่ใช้
  • ขนาดของ Packet

หลักการทำงานของ Policy Based Routing

               ท่านสามารถใช้ Policy Based Routing เพื่อใส่ค่าลงไปใน IP Packet เพื่อให้ Application mถูกกำหนดขึ้นโดยเฉพาะได้รับการบริการพิเศษโดยมีการจัดอันดับความสำคัญเหนือ Application อื่นๆ เพื่อให้สามารถส่งมันออกไปตามเส้นทางต่างๆที่ต้องการ การแบ่ง Class ของ Traffic สามารถทำได้โดยการใช้ Access Control List หรือ ACL ซึ่งอาจเป็น Standard หรือ Extended หรือแม้แต่ Name Access List ก็สามารถนำมาใช้ได้เช่นกัน

               เมื่อ Router ตรวจพบ IP Packet มันจะนำมาเปรียบเทียบกับกฎกติกาที่ตั้งไว้ จากนั้นตรวจสอบดูค่า Precedence หรือ TOS บน IP Packet ก่อนที่จะถูกส่งออกไปตามเส้นทางที่ผู้จัดการเครือข่าย จัดทำเป็นเงื่อนไขขึ้น ซึ่งในการนี้มีการใช้คำสั่ง Route Map เพื่อจัดตั้งกฎกติกา รวมทั้งคำสั่งที่เกี่ยวข้องเพื่อให้ได้ตามที่ต้องการ

ตัวอย่างการติดตั้ง Policy Based Routing พร้อมการทำงานของ IP SLA Monitoring

               ต่อไปนี้เป็นตัวอย่างการติดตั้ง Policy Based Routing พร้อมด้วย IP SLA Monitoring สำหรับเครือข่าย ที่ต้องการระบบทดแทนโดยอัตโนมัติ โดยจะมีการใช้ Policy Based Routing เพื่อติดตั้งค่าลงบน IP Packet ตัวอย่างเช่น การใช้ HTTP และมีการ Redirect มันไปที่ Web Proxy (ปกติใช้ Squid ของ Linux) เพื่อให้ Web Traffic ทั้งหมดของเครือข่าย ผ่านการกลั่นกรองโดย Proxy

               ภายใต้การติดตั้งนี้ สมมตว่าผู้ใช้งานเครือข่ายไม่มีข้อมูลหรือรู้ว่า Proxy มีตัวตนหรือไม่ โดยที่ไม่ต้องคอนฟิกให้ Web Browser ได้รับการจัดตั้ง เพื่อให้สามารถใช้ Proxy และโดยที่ Traffic ทั้งหมดถูกส่งออกไปที่เกตเวย์ เดียวกัน เช่น Cisco ASA Firewall และจากที่นั่น ส่งต่อไปที่เราเตอร์(R1) อีกทีหนึ่ง นี่เป็นตัวอย่างที่ดีแบบหนึ่งสำหรับการจัดตั้ง Transparent Proxy พร้อมด้วยระบบทดแทนโดยอัตโนมัติ

ภาพที่ 2 แสดงตัวอย่างการเชื่อมต่อที่ Redirect Traffic ไปที่ Web Proxy

 

               ภายในตัวเราเตอร์ R1 ด้วยการช่วยเหลือของ Policy Based Routing ท่านสามารถติดตั้งค่าลงบน IP Packet ที่เกี่ยวข้องกับ HTTP Traffic จากนั้นดำเนินการบางอย่างด้วยคำสั่ง “Set” ซึ่งมีไว้สำหรับ นำส่ง Traffic ที่เลือกสรรแล้วไปที่ Linux Proxy ด้วยแอดเดรส 192.168.150.2

               ตัว Linux Proxy ได้รับเอา Traffic นี้เข้ามา จากนั้นมีการตรวจสอบกฎกติกาที่กำหนดขึ้นโดยผู้จัดการระบบเครือข่าย จากนั้นจัดส่งมันไปที่อินเตอรเนตผ่านทางเราเตอร์ R2

               เพื่อที่จะเพิ่มประสิทธิภาพเกี่ยวกับเส้นทางทดแทน จึงมีการเพิ่มการทำงานที่เรียกว่า IP SLA Monitoring เข้าไปเพื่อให้มีการตรวจสอบสถานะของการเชื่อมต่อ เมื่อเป็นเช่นนี้ R1 จะสามารถตรวจสอบสถานะ การทำงานของ Linux Server เพื่อให้แน่ใจว่ามันไม่ได้ทำงานล้มเหลว หรือหยุดทำงาน และไม่ว่าเหตุผลใดก็ตามที่เราเตอร์ R1 สูญเสียการเชื่อมต่อกับ Linux Server เกิดขึ้น ตัว IP SLA และกลไกการทำงานของ Policy Based Routing จะหยุดดำเนินการ Redirect HTTP Traffic ไปที่ Linux Server แต่จะส่งตรงไปที่อินเตอรเนตผ่านทางเราเตอร์ R2 และบายพาสเส้นทางสู่ Proxy Server ที่ทำงานล้มเหลว

               ภาพต่อไปเป็นตัวอย่างที่แสดงให้เห็นว่าเราเตอร์ R1 จะตอบสนองต่อความล้มเหลวในการทำงานของ Linux Server ได้อย่างไร

                             

ภาพที่ 3 แสดงการ Redirect Traffic ไปที่อื่นหลังจาก Proxy มีปัญหา

 

               ตัวอย่างนี้เป็นการรวมเอา Policy Based Routing ของ Cisco พร้อมด้วย IP SLA Tracking ซึ่งให้ประโยชน์มากมายหลายประการ เช่น

  • ดำเนินการ Redirect HTTP Traffic ที่ผ่านการเลือกสรรแล้วไปที่ Linux Server
  • ปล่อยผ่าน Web Traffic ผ่านบนเครือข่าย ด้วยการส่งไปที่ Web Filtering ตามนโยบายที่จัดตั้งขึ้นโดยผู้จัดการระบบเครือข่าย
  • สามารถตรวจพบการทำงานที่ล้มเหลวของ Proxy Server และจัดส่ง Traffic ไปบนเส้นทางอื่นแทนโดยอัตโนมัติ
  • สามารถกลับคืนเส้นทางสู่ปกติเส้นทางเดิม หาก Proxy Server กลับคืนสู่ภาวะปกติ

วิธีการจัดคอนฟิก IP SLA Tracking สำหรับ Host

               ประการแรกท่านจะต้องจัดตั้ง IP SLA Tracking สำหรับ Host ที่ท่านต้องการ เพื่อให้แน่ใจว่าเราเตอร์ R1 สามารถดำเนินการเฝ้าดู Linux Proxy อย่างต่อเนื่องและหยุดการ Redirect HTTP Traffic ไปที่ Linux Server นี้ หากตรวจพบว่าเกิดความล้มเหลวในการทำงาน

R1(config)# ip sla 1
R1(config-ip-sla)# icmp-echo 192.168.150.2
R1(config-ip-sla)# frequency 4
R1(config-ip-sla)# timeout 2000
R1(config-ip-sla)# threshold 100
R1(config-ip-sla)# ip sla schedule 1 life forever start-time now

               ค่าคอนฟิกที่กล่าวมานี้ เป็นการติดตั้งระบบตรวจสอบ IP SLA บนเราเตอร์ R1 การทำงานเกิดขึ้นโดยการใช้ ICMP Echo (Ping) ไปที่ 192.168.150.2 ในทุกๆ 4 วินาที โดยการใช้คำสั่ง Frequency

               ส่วนคำว่า Timeout เป็นการตั้งค่าจำนวนเวลาคิดเป็นวินาที ที่เราเตอร์ของ Cisco รอการตอบสนอง จาก Host โดยใช้ IP SLA ในการนี้ มีการตั้งค่าอยู่ที่ 2000 มิลลิวินาที หรือ 2 วินาที ซึ่งให้โอกาสที่ Host จะต้องตอบสนอง

               ค่า Threshold ถูกตั้งไว้เพื่อตรวจสอบดูว่า การทำงานนั้นเกินกว่าค่าที่ตั้งไว้หรือไม่ หากเกินก็จะดำเนินการอย่างใดอย่างหนึ่งต่อไป และจัดเก็บไว้เป็นข้อมูลในระบบ

               หลังจากที่ได้กำหนดวิธีการทำงานของ IP SLA แล้ว ขั้นตอนต่อไปคือการนิยามวัตถุที่ SLA ติดตามดูอยู่ ซึ่งสามารถทำได้โดยใช้ Track ดังตัวอย่าง

R1(config)# track 1 ip sla 1 reachability

               คำสั่งที่กล่าวมานี้ จะติดตามดูสถานะ การทำงานของ IP SLA หากไม่มีการตอบสนองต่อการส่ง Ping จาก ไอพีแอดเดรส 192.168.150.2 ระบบจะเปลี่ยนเส้นทางใหม่ หรือจนกว่าจะได้รับการตอบสนองอีกครั้งหนึ่ง

               เพื่อที่จะตรวจสอบการทำงานของ IP SLA ใช้คำสั่ง show track ดังตัวอย่าง

R1# show track 1
Track 1
  IP SLA 1 reachability
  Reachability is Up
    30 changes, last change 1d08h
  Latest operation return code: OK
  Latest RTT (millisecs) 1
  Tracked by:
    ROUTE-MAP 0

               คำสั่ง output เป็นการตรวจสอบว่าวัตถุที่กำลังติดตามอยู่ที่กำลังอยู่ในสถานะ Up ตามปกติ และได้รับการสนองตอบภายใน 1 ms และจากการสังเกตอย่างใกล้ชิดจะพบว่า ห้วงเวลาของการติดตามดู พบอีกว่า มีการเปลี่ยนแปลงถึง 30 ครั้ง และการเปลี่ยนแปลงครั้งล่าสุดคือ เมื่อ 1 วันกับ 8 ชั่วโมงที่ผ่านมา ข้อมูลข่าวสารนี้มีความสำคัญ เนื่องจากท่านสามารถ Troubleshoot ปัญหาการเชื่อมต่อแบบ ติดๆดับๆได้

ตัวอย่างการจัดคอนฟิก Policy Based Routing เพื่อ Redirect HTTP Traffic

               หลังจากที่ได้จัดคอนฟิก Policy Based Routing เสร็จแล้ว ขั้นตอนต่อไปได้แก่การจัดคอนฟิก PBR เพื่อที่จะดำเนินการ Redirect HTTP Traffic

               ประการแรก ท่านจะต้องติดตั้ง Access Control List (ACL) เพื่อเลือก Traffic ที่จะถูก Redirect ข้อหนึ่งที่ท่านจะต้องตระหนักคือ Policy based Routing ไม่สนใจว่าท่านจะใช้ Access List แบบใด ท่านจึงมีอิสระที่จะใช้ ACL หมายความว่า ท่านสามารถใช้ named ACL หรือ Standard ACL รวมทั้ง Extended ACL จากตัวอย่างต่อไปนี้ จะขอใช้ IP Named ACL เป็นตัวอย่าง

R1(config)# ip access-list extended http-traffic
R1(config)# permit tcp 192.168.5.0 0.0.0.255 any eq www

               ในการนี้สมมตว่า เราจะใช้ชื่อของ Name ACL ว่า “http-traffic” และชื่อนี้จะถูกนำมาใช้ต่อไปใน Route map โดยการเปลี่ยนแปลงข้อความที่เหมาะสมใน ACL ท่านจะสามารถนิยาม Traffic ชนิดต่างๆ ที่จะถูก Redirect ออกไป ตัวอย่างในที่นี้ จะกำหนดให้ http traffic จากเครือข่าย 192.168.5.0 สามารถถูกส่งออกไปที่ใดก็ได้ในอินเตอรเนต จากนั้น ให้จัดสร้าง route map ที่จะเลือกใช้ Traffic ที่ปรากฏอยู่ใน ACL เพื่อที่จะบอกให้เราเตอร์ทำการ Redirect http traffic ไปที่ Linux proxy

R1(config)# route-map linux-proxy permit 1
R1(config-route-map)# match ip address http-traffic
R1(config-route-map)# set ip next-hop verify-availability 192.168.150.2 1 track 1

               คำสั่งที่ได้กล่าวมาแล้วนี้ สามารถให้อำนาจแก่ Route map ที่มีชื่อว่า Linux-proxy ส่วน Parameter ที่ชื่อ match IP address ที่อยู่ภายในตัว Route map จะทำการบอกให้เราเตอร์ ที่ได้ถูกตั้งค่าด้วยชุดคำสั่งใน ACL เพื่อกำหนด Traffic ที่จะใช้ควบคุมการส่งออก และเนื่องจากเรามีการใช้ IP Named ACL ดังนั้นสิ่งที่เราต้องทำคือ อ้างอิงชื่อของ IP Named ACL ดังที่เราได้จัดสร้างก่อนหน้านี้

               คำสั่งสุดท้ายที่คอนฟิกตัว Route map เพื่อที่จะตรวจสอบการเข้าถึง วัตถุที่มีไอพีแอดเดรสเป็น 192.168.150.2 โดยหากวัตถุนี้สามารถเข้าถึงได้ (IP SLA รายงานว่าวัตถุนี้ สามารถติดต่อได้) แล้ว Policy Routing ของเราจะดำเนินการ redirect Traffic ตามที่ต้องการ แต่หาก IP SLA รายงานว่า วัตถุนี้ไม่สามารถเข้าถึงได้ ดังนั้น Policy Routing ของเราจะหยุดทำการ Redirect traffic ในทันที

การใช้งาน Policy Based Route

               มาถึงตรงนี้ งานที่ตั้งใจทำ ก็เกือบจะเสร็จสิ้นแล้ว ดังนั้นในขั้นตอนสุดท้ายได้แก่การ Enable และพิสูจน์แสดงการทำงานของ Route map เพื่อที่จะนำมาใช้กับ Policy Routing ที่ท่านตั้งใจจะใช้ ในการนี้ ท่านจะต้องเลือก Interface ของ Router ที่ซึ่งเราจะให้ Routing Policy ทำงานที่นั่น โดยการติดตั้ง Policy Route ดังต่อไปนี้

R1(config)# interface Vlan1
R1(config-int)# ip policy route-map linux-proxy

จากในตัวอย่างของเรา สมมตว่า VLAN1 ของ R1 เชื่อมต่อเข้ากับ 192.168.150.0/24 ซึ่งมีการติดตั้ง ASA Firewall และ Linux Proxy Server อยู่ที่นั่น

Route-Map กับสถิติการทำงานของ IP SLA

               หากจะจับตาดูการทำงานของ Route Map บนเราเตอร์อย่างใกล้ชิด รวมทั้งประสิทธิภาพการทำงานของ IP SLA สามารถทำได้โดยการใช้คำสั่งง่ายๆ และการเฝ้าดูการทำงานในช่วง 2-3 วันแรกเป็นสิ่งที่ควรทำ จุดประสงค์ก็เพื่อตรวจสอบดูว่า Traffic ยังถูกส่งออกไปที่ Linux Server Host อยู่หรือไม่

               ในอีกมุมมองหนึ่ง การมองดูสถิติการทำงานของ IP SLA จะช่วยให้ท่านสามารถพิสูจน์ทราบการเกิดปัญหาล้มเหลวในการทำงาน ซึ่งจะมีการแจ้งเตือนให้ทุกคนได้รับทราบ

               คำสั่ง show route-map จะให้ข้อมูลมากเพียงพอ ที่จะตรวจสอบดูว่า ทุกสิ่งทุกอย่างเป็นไปตามปกติหรือไม่ ดังตัวอย่างเช่น

R1# show route-map

route-map linux-proxy, permit, sequence 1

  Match clauses:

    ip address (access-lists): http-traffic

  Set clauses:

    ip next-hop verify-availability 192.168.150.10 1 track 1  [up]

  Policy routing matches: 3864291 packets, 511957007 bytes

               ตัวเลขที่แสดง หลังจากการใช้คำสั่ง show route-map ได้แก่ข้อมูลที่แสดงให้เห็นว่า สามารถเข้าถึงตัว host ได้ โดยมีสถานะ Up และ R1 ได้มีการ Redirect traffic ไปที่ Proxy Server มากว่า 510 MB แล้ว ส่วนคำสั่ง show IP SLA statistics ให้ข้อมูลที่คล้ายคลึงกัน โดยแสดงข้อมูลข่าวสารที่มีประโยชน์ ที่จะช่วยให้สามารถตรวจสอบและพิสูจน์ว่าระบบการติดตามวัตถุ กำลังทำงานได้ตามปกติและ ระบบการทำงานอยู่ในสถานะ Up

R1# show ip sla statistics
IPSLAs Latest Operation Statistics

IPSLA operation id: 1
Latest RTT: 1 milliseconds
Latest operation start time: *21:36:47.855 UTC Tue Apr 3 2012
Latest operation return code: OK
Number of successes: 16
Number of failures: 0
Operation time to live: Forever

ภาพที่ 4 การใช้งาน IP SLA จำเป็นต้องมีเส้นทางการเชื่อมต่ออย่างน้อย 2 เส้นทาง

 

ตัวอย่างการติดตั้ง ระบบการติดตามดูการทำงานภายใต้ IP SLA

               เราได้รู้จักกับ Policy based Routing รวมทั้ง IP SLA เป็นที่เรียบร้อยแล้ว ต่อไปนี้เรามาลองติดตั้ง Static Route Tracking โดยใช้ IP SLA ขั้นพื้นฐานกัน

               อย่างที่เราได้ทราบกันดีแล้วว่า ระบบทดแทนเป็นสิ่งสำคัญยิ่งสำหรับระบบเครือข่าย ไม่ว่าจะเป็นบนระบบ LAN หรือบน WAN ก็ตาม หัวข้อต่อไปนี้ จะขอนำเสนอการสร้างเส้นทางทดแทน สำหรับ WAN ที่มีการเชื่อมต่อหลายเส้นทาง ที่มีปลายทางไปสู่เราเตอร์ตัวหนึ่ง

               วิธีการที่ง่ายที่สุด ที่จะให้ได้เส้นทางทดแทนบน WAN ได้แก่การกำหนดเส้นทาง Static Route เพื่อใช้เป็นเส้นทางสำรองนั่นเอง

               ต่อไปนี่เป็นตัวอย่างการติดตั้งระบบทดแทนสำหรับการเชื่อมต่อบน WAN ขั้นพื้นฐาน ดังภาพตัวอย่าง

ภาพที่ 5 ตัวอย่างการเชื่อมต่อ 2 ISP พร้อมด้วย IP SLA Tracking

 

               จากภาพตัวอย่าง แสดงให้เห็นว่า เราเตอร์ของ Cisco มีการเชื่อมต่อไปที่ WAN จำนวน 2 เส้นทาง ได้แก่ ISP1 และ ISP2 และเราติ้งที่เราใช้จริงในชีวิตประจำวันทั่วไปได้แก่ การใช้ Default Routing ดังตัวอย่างต่อไปนี้

R1(config)# ip route 0.0.0.0 0.0.0.0 2.2.2.2
R1(config)# ip route 0.0.0.0 0.0.0.0 3.3.3.3 10

               จากค่าคอนฟิก ท่านสามารถสังเกตดูค่า AD ที่อยู่หลังประโยคที่สอง ในที่นี้คือหมายเลข 10 ซึ่งเป็นเส้นทางที่เชื่อมต่อไปที่ ISP2 ถูกกำหนดว่าเป็นเส้นทางสำรอง โดยเส้นทางนี้ จะยังไม่ทำงาน เนื่องจากมีค่า AD สูงกว่า เส้นแรกที่มีค่า Default เป็น 1 ซึ่งเป็นเส้นทางหลัก และเมื่อใดที่เส้นทางหลักเกิดล้มเหลว ค่า AD จะถูกเปลี่ยนไปเป็น 255 ซึ่งสูงกว่าเส้นทางที่สอง ดังนั้นเส้นทางที่สองจะทำงานแทน

               รูปแบบที่กล่าวมานี้ เราเรียกว่า Floating Static Route ถูกนำมาใช้กับสถานการณ์เกิด Up หรือ Down ของ Interface ที่เชื่อมต่อกับ WAN แต่ในสถานการณ์จริง ท่านอาจจะเห็นการเชื่อมต่อยังเป็นไปตามปกติ แต่ก็ยังไม่สามารถเชื่อมต่อไปที่เกตเวย์ได้อยู่ดี ซึ่งปัญหานี้เกิดขึ้นที่ฝั่งของ ISP โดยลักษณะและเหตุการณ์นี้ IP SLA จึงดูเหมือนว่าเป็นเพื่อนที่ดีของเราในยามยาก

               การใช้ IP SLA บนอุปกรณ์ของ Cisco และ IOS ทำให้มีการใช้ Internet Control Message Protocol หรือ ICMP เพื่อให้มีการส่ง Echo ไปตรวจสอบสถานการณ์เชื่อมต่อ และหากมีปัญหาการเกิด Down ที่อีกฟากหนึ่งของการเชื่อมต่อ ระบบจะเปิดทางให้เส้นทางสำรอง สามารถทำงานแทนได้ในทันที ซึ่งการใช้ระบบติดตามดูวัตถุ (ในที่นี้หมายถึงตัว Router) สามารถให้หลักประกันว่า หากมีปัญหาใดเกิดขึ้นบนเส้นทางหลัก เส้นทางสำรองสามารถทำงานได้อย่างแน่นอน

R1(config)# ip sla 1
R1(config)# icmp-echo 2.2.2.2 source-interface FastEthernet0/0
R1(config)# timeout 1000
R1(config)# threshold 2
R1(config)# frequency 3
R1(config)# ip sla schedule 1 life forever start-time now

               คำสั่งที่ใช้งานสำหรับ IP SLA นั้นจะต้องมาจาก IOS version 12.4(4) รวมทั้ง 15.(0)1M หรือ Version ที่สูงกว่า ชุดคำสั่งที่กล่าวมานี้ เป็นการกำหนดให้มีการทำงานของ IP SLA Probe ซึ่งใช้ตรวจสอบสถานะ การเชื่อมต่อของ WAN โดย IP SLA จะมีการจัดส่ง ICMP Echo Probe ไปที่ IP ใน Hop ต่อไปซึ่งในที่นี้คือ 2.2.2.2 ในทุกๆ 3 วินาที ด้วยคำสั่ง Frequency และมีการจัดตั้งค่า Timeout 1000 มิลลิวินาที หรือ 1 วินาที เพื่อรอการตอบสนองจากเราเตอร์ของอีกฟากหนึ่ง นอกจากนี้ยังมีการตั้งค่า Threshold ที่จะมีการทำงานเกิดขึ้น หากไม่มีการตอบสนองกลับมาหลังจากที่ส่งการร้องขอติดต่อไปที่ เราเตอร์ปลายทางเกินกว่า 2 ครั้ง

               และเมื่อมีการกำหนดหน้าที่การทำงานของ IP SLA เป็นที่เรียบร้อยแล้ว ต่อไปเป็นการกำหนดให้มีการติดตามดูสถานะ ของการเชื่อมต่อ โดยการใช้คำสั่ง Track ดังตัวอย่าง

R1(config)# track 1 ip sla 1 reachability

               คำสั่งที่กล่าวมาทั้งหมดนี้ จะทำให้เกิดการติดตามดูสถานการณ์ทำงานของ IP SLA หากไม่มีการตอบสนองหลังจากส่ง Ping ไปที่เราเตอร์ปลายทาง เกินกว่าค่าที่กำหนดแล้ว Track จะเกิดการ Down และจะ Up อีกครั้งหนึ่งหากการเชื่อมต่อกลับคืนสู่ภาวะปกติ

               และเพื่อที่จะตรวจสอบสถานะของการทำงาน ท่านสามารถใช้คำสั่ง “show track” ดังตัวอย่างต่อไปนี้

R1# show track
Track 1
IP SLA 1 reachability
Reachability is Down
1 change, last change 00:03:19
Latest operation return code: Unknown

               ข้อมูลที่แสดงบนหน้าจอบ่งบอกว่า สถานะของ การติดตาม คือ Down และการทำงานของ IP SLA มีการดูแลรักษาค่า Return Code เสมอ โดยค่า Return Code นี้ จะถูกแปลโดยกระบวนการติดตาม โดยค่า Return Code อาจแสดงสถานะ OK รวมทั้ง Over Threshold และอื่นๆ ดังนั้นการปฏิบัติงานที่แตกต่างกัน จะมีค่า Return Code ที่แตกต่างเช่นกัน

               ขั้นตอนสุดท้ายในการติดตั้ง Static Route IP SLA ได้แก่ เพิ่มคำสั่ง Track พร้อมด้วย Default Route ดังตัวอย่าง ที่เคยอธิบายไว้ก่อนหน้านี้

  

R1(config)# ip route 0.0.0.0 0.0.0.0 2.2.2.2 track 1
R1(config)# ip route 0.0.0.0 0.0.0.0 3.3.3.3 10

ตัวอย่างการเชื่อมต่ออินเตอรเนต ด้วยการใช้ Policy Based Routing และ IP SLA พร้อม NAT

               NAT (network Address Translation) เป็นวิธีการที่ถูกนำมาใช้เพื่อแก้ปัญหาเกี่ยวกับ  IP Address ที่ไม่เพียงพอ รวมทั้งความต้องการเกี่ยวกับเครือข่ายบางอย่าง เช่น การเชื่อมต่อ อินเตอรเนตและเครือข่ายเหลื่อมซ้อนกัน

ความต้องการ

               สมมติว่าบริษัท XYZ.com เพิ่งติดตั้งการเชื่อมต่อกับอินเตอรเนตเส้นที่สอง จากเดิมที่มีอยู่แล้วเส้นหนึ่ง ความต้องการคือจัดทำ Load Sharing ไปบนเส้นทางทั้งสองเส้น มีการกำหนดว่าจะให้ Web traffic และ Telnet traffic จะต้องใช้เส้นทางที่สอง ซึ่งเชื่อมต่อไปที่ ISP2 ส่วน Traffic อื่นๆให้วิ่งบนเส้นทางที่หนึ่ง หรือเส้นทางเดิมไปยัง ISP1 ในกรณีที่เส้นทางใดเส้นทางหนึ่งเกิดล้มเหลว ก็สามารถใช้เส้นทางที่เหลือต่อไปได้

ภาพที่ 6 แสดงตัวอย่างการเชื่อมต่อกับ 2 ISP ด้วย IP SLA Tracking

 

แนวทางการติดตั้งใช้งาน

               แนวทางการติดตั้งคือให้ใช้ Policy Based Routing เพื่อควบคุมการทำงานของ LAN ที่จะเดินทางไปสู่อินเตอรเนต และกำหนดว่าจะให้ใช้เส้นทางใดบ้าง ในการนี้ เรากำหนดให้ Traffic จาก LAN ที่มีไอพีแอดเดรส 10.1.1.0/24 ที่ใช้ TCP Port 23 และ 80 รวมทั้ง 443 ให้ใช้เส้นทางที่สอง โดยออกไปที่ ISP 2 และกำหนดให้มี Hop ต่อไปคือ 192.168.1.2 และเนื่องจากในตัวอย่างนี้ ไม่ได้กำหนด Subnet หรือพิกัด (range) ของไอพีที่จะใช้บนอินเตอรเนต เราจะใช้กระบวนการ NAT แบบ Overload เพื่อใช้ กับการเชื่อมต่อกับ ISP

               ตัวอย่างเช่น Traffic ที่จะวิ่งผ่านไปยัง ISP1 ใช้ไอพีแอดเดรสเป็น 192.168.1.1 แต่ถ้าหากจะเดินทางไปที่ ISP2 ให้ใช้ไอพีแอดเดรสเป็น 172.16.1.1 ในกรณีนี้ หากเส้นทางใดเส้นทางหนึ่งมีปัญหาให้ใช้เส้นทางที่เหลือแทน วิธีนี้สามารถทำได้โดยการใช้ IP SLA พร้อมด้วย ICMP Echo ที่มีการจัดส่งออกไปยังเส้นทางทั้งสอง โดยมีปลายทางที่ 192.168.2 และ 172.16.1.2 และกำหนดให้มีการจัดส่ง ICMP Echo ออกไปยังเส้นทางทั้งสองในทุกๆ 1 วินาที โดยกำหนดค่า Timeout ไว้ที่ 500 msec

               หากไม่ได้รับการตอบรับจาก ISP ไม่ว่าจะเป็นฝั่งใดฝั่งหนึ่ง ภายใน 1 วินาที ก็จะพิจารณาว่า เส้นทางนั้น ไม่สามารถเข้าถึงได้ และ Default Route ของเส้นทางนั้น จะถูกยกเลิกในตารางเราติ้ง และจะดำเนินการชี้ไปยังเส้นทางที่เหลืออยู่แทน

การติดตั้ง

interface FastEthernet1/0

description LAN interface
ip address 10.1.1.1 255.255.255.0
ip nat inside
ip policy route-map PBR    <---- นี่เป็น policy based routing

interface FastEthernet1/1

description To ISP 1
ip address 192.168.1.1 255.255.255.0
ip nat outside
!
interface FastEthernet2/0

description To ISP 2
ip address 172.16.1.1 255.255.255.0
ip nat outside

               อย่างที่ได้เห็นว่า Interface ได้ถูกติดตั้งด้วย NAT และมีการใช้ Policy Based Routing พร้อมด้วยชื่อ PBR ถูกนำมาติดตั้งที่ Interface ด้วย นอกจากนี้มีการติดตั้ง NAT ที่ Interface ซึ่งเชื่อมต่อกับ ISP

การติดตั้ง IP SLA

ip sla 1
icmp-echo 192.168.1.2
timeout 500
frequency 1
ip sla schedule 1 life forever start-time now


ip sla 2
icmp-echo 172.16.1.2
timeout 500
frequency 1
ip sla schedule 2 life forever start-time now

จากตัวอย่าง จะเห็นว่า IP SLA1 สามารถส่ง ICMP Echo ไปที่ ISP1 ในทุกๆ 1 วินาที และIP SLA 2 มีการส่ง ICMP Echo ไปที่ ISP2 เช่นกัน

track 10 rtr 1 reachability
delay down 1 up 1
!
track 20 rtr 2 reachability
delay down 1 up 1
!

               จากตัวอย่าง หาก IP SLA1 ไม่ได้รับการตอบสนองจาก ISP1 ภายในเวลา 1 วินาที Track 10 ซึ่งเป็นระบบติดตามดูสถานะเชื่อมต่อของ IP SLA1 จะถือว่า ISP1 ไม่สามารถติดต่อได้ ส่วน Track 20 มีการทำงานเช่นเดียวกับ Track 10

ip route 0.0.0.0 0.0.0.0 192.168.1.2 track 10
ip route 0.0.0.0 0.0.0.0 172.16.1.2 track 20

               ติดตั้ง Default Route บนเส้นทางทั้งสอง โดยกำหนดให้มีเกตเวย์ชี้ไปที่ ไอพีแอดเดรสของ ISP แต่ละราย นอกจากนี้ ในแต่ละ Static Default Route ก็ยังเกี่ยวพันกับ IP SLA Track ต่างๆอีกด้วย จากตัวอย่าง มีการกำหนดไว้ว่า หากเส้นทางแรกเกิดมีปัญหา ข้อมูลของ Default Route ในตาราง จะหลุดออกจากตารางเราติ้ง

access-list 10 permit 10.1.1.0 0.0.0.255
access-list 100 permit tcp 10.1.1.0 0.0.0.255 any eq telnet
access-list 100 permit tcp 10.1.1.0 0.0.0.255 any eq www
access-list 100 permit tcp 10.1.1.0 0.0.0.255 any eq 443
access-list 101 permit ip any any

โดย ACLs เหล่านี้จะถูกนำมาใช้กับ PBR และการทำ NAT

route-map PBR permit 10
match ip address 100
set ip next-hop verify-availability 172.16.1.2 1 track 20
!
route-map PBR permit 30
match ip address 101
set ip next-hop verify-availability 192.168.1.2 2 track 10
!

               จากตัวอย่าง จะเห็นว่า ชื่อของ Route Map คือ PBR ที่มีการตรวจสอบ Traffic ที่มาจาก LAN Interface และต้องการมุ่งสู่อินเตอรเนต การตรวจสอบอันแรกคือ ACL หาก Traffic ที่มีต้นทางจาก LAN ซึ่งเป็นเครือข่าย 10.1.1.0/24 และมีปลายทางใดก็ได้ โดยใช้ Port TCP 23 และ 80 รวมทั้ง 443 ให้ Traffic นี้ Match กับ ACL 100 ที่เหลืออื่นๆให้ Match กับ ACL 101 ในกรณีที่มีการใช้ Telnet Traffic ให้มีการ Match กับ ACL 100 โดยมี Sequence การทำงานหมายเลข 10

               แต่ใน Sequence นี้ เรายังมีการตรวจสอบอื่นๆก่อนที่จะมีการส่ง traffic ไปที่ Hop ต่อไปคือ 172.16.1.2 เราต้องการให้แน่ใจว่า next Hop oกำลังอยู่ในสถานะ Up และสามารถเข้าถึงได้ ซึ่งในกรณีนี้สามารถทำได้โดยใช้ IP SLA /Track 20 ที่เราได้จัดสร้างขึ้น ซึ่งหาก track นี้มีสถานะ Up แล้ว Traffic จะถูกส่งออกไป ที่ ISP2 ด้วย Hop ต่อไปคือ 172.16.1.2

               แต่หาก Track 20 เกิด Down แล้ว ข้อมูลเส้นทาง Default Static Route ซึ่งชี้ไปที่ ISP2 จะถูกถอดถอนออกไปจากตารางเราติ้ง และ Traffic ที่ Match กับ ACL 100 ภายใต้ Sequence Number หมายเลข 10 ของ Route-map จะถูกส่งออกไปบนเส้นทางซึ่งเชื่อมต่อกับ ISP1 ส่วน Traffic อื่นๆที่ไม่ได้ Match กันกับ ACL 100 จะใช้ Route Map ที่มี Sequence 30

route-map ISP2 permit 10
match ip address 10
match interface FastEthernet2/0
!
route-map ISP1 permit 10
match ip address 10
match interface FastEthernet1/1

               Route map ทั้งสองจากข้อความที่กล่าวมานี้ จะถูกนำมาใช้กับ คำสั่ง NAT โปรดสังเกตว่า เรามี Route map แต่ละชุดที่ Match กับ Interface ขาออก โดย Interface ขาออกทุก Interface จะมีการติดตั้ง NAT ไว้ 

ip nat inside source route-map ISP1 interface FastEthernet1/1 overload
ip nat inside source route-map ISP2 interface FastEthernet2/0 overload

               นี่เป็นคำสั่ง NAT แบบง่ายที่ถูกติดตั้งให้เข้ากับ Interface และ Route Map แต่ละอย่าง

ทดสอบการทำงาน

               ในการทดสอบ เราจะใช้ Loopback Interface ที่ถูกสร้างบน ISP Router ทั้งสอง ในตัวอย่างนี้ เราใช้เพื่อแสดงจุดหมายปลายทางในอินเตอรเนต ซึ่งได้แก่ไอพี 100.100.100.100

show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via "static", distance 1, metric 0, candidate default path
  Routing Descriptor Blocks:
    192.168.1.2
      Route metric is 0, traffic share count is 1
  * 172.16.1.2
      Route metric is 0, traffic share count is 1

               จากข้อความที่ปรากฏบนหน้าจอ จะเห็นว่าเราเตอร์ ISP ทั้งมีไอพีแอดเดรสที่สามารถเข้าถึงได้โดย SLA ICMP Echo     

Router# show route-map PBR
route-map PBR, permit, sequence 10
  Match clauses:
    ip address (access-lists): 100
  Set clauses:
    ip next-hop verify-availability 172.16.1.2 1 track 20 [up]
  Policy routing matches: 24 packets, 1446 bytes
  route-map PBR, permit, sequence 30
  Match clauses:
    ip address (access-lists): 101
  Set clauses:
    ip next-hop verify-availability 192.168.1.2 2 track 10  [up]
  Policy routing matches: 60 packets, 6840 bytes

               จากตัวอย่างที่ปรากฏบนหน้าจอนี้ ชี้ให้เห็นว่า SLA Track 10 และ 20 มีสถานะ UP ปรากฏอยู่ใน คำสั่ง show Route Map

               คราวนี้ เราทดสอบโดยการ Ping ไปที่ 100.100.100.100 โดยให้ Ping จากภายในเครือข่าย 10.1.1.0/24 และให้ Enable Debug สำหรับการทำงานของ NAT บนเราเตอร์ที่เชื่อมต่อกับ ISP เพื่อดูการทำงานของ NAT

Router# ping 100.100.100.100

*Dec 19 20:24:44.103: NAT*: s=10.1.1.10->192.168.1.1, d=100.100.100.100 [80]
*Dec 19 20:24:44.371: NAT*: s=100.100.100.100, d=192.168.1.1->10.1.1.10 [80]

               ซึ่งจะแสดงให้เห็นว่า มีการแปล ICMP Traffic ไปเป็น - > 192.168.1.1 ข้อความเหล่านี้ แสดงให้เห็นว่า ICMP Traffic นั้น Match กันกับ ACL 101 และเนื่องจาก Track 10 มีสถานะ Up ดังนั้น Traffic ที่ส่งออกไปที่ 192.168.1.1 จะถูกแปลโดยการใช้ NAT ข้อความต่อไปนี้ แสดงให้การทำงานของ PBR หรือ Policy Based routing ที่ทำงานโดยคำสั่ง Ping และแสดงผลหลังจากใช้คำสั่ง debug

*Dec 19 20:25:12.247: IP: s=10.1.1.10 (FastEthernet1/0), d=100.100.100.100, len 100, FIB policy match
*Dec 19 20:25:12.251: IP: s=10.1.1.10 (FastEthernet1/0), d=100.100.100.100, g=192.168.1.2, len 100, FIB policy routed
*Dec 19 20:25:12.259: NAT*: s=10.1.1.10->192.168.1.1, d=100.100.100.100 [81]
*Dec 19 20:25:12.623: NAT*: s=100.100.100.100, d=192.168.1.1->10.1.1.10 [81]

               ตอนนี้เรามาดูผลลัพธ์ หากมีการใช้ Telnet Session จากเครือข่ายภายใน

telnet 100.100.100.100

*Dec 19 20:26:00.375: IP: s=10.1.1.10 (FastEthernet1/0), d=100.100.100.100, len 44, FIB policy match
*Dec 19 20:26:00.375: IP: s=10.1.1.10 (FastEthernet1/0), d=100.100.100.100, g=172.16.1.2, len 44, FIB policy routed
*Dec 19 20:26:00.383: NAT*: s=10.1.1.10->172.16.1.1, d=100.100.100.100 [57504]     

*Dec 19 20:26:01.159: NAT*: s=100.100.100.100, d=172.16.1.1->10.1.1.10 [25782]

               คราวนี้สมมติว่า เรามา Shutdown การเชื่อมต่อกับ ISP1 เพื่อจำลองว่า Link เกิด Down และจะมาดูว่า IP SLA จะทำอย่างไร ภายใต้สถานการณ์ เช่นนี้

ping 100.100.100.100

*Dec 19 20:27:54.139: %TRACKING-5-STATE: 10 rtr 1 reachability Up->Down
*Dec 19 20:27:57.895: NAT*: s=10.1.1.10->172.16.1.1, d=100.100.100.100 [82]
*Dec 19 20:27:58.099: NAT*: s=100.100.100.100, d=172.16.1.1->10.1.1.10 [82]

               จะเห็นว่า ICMP Traffic ที่ Match กับ ACL 101 จะใช้เส้นทางการเชื่อมต่อกับ ISP2 ด้วยเส้นทางที่มีไอพีแอดเดรส 172.16.1.1 เป็น IP ต้นทาง

               เราจะเห็นว่า Interface ที่เชื่อมต่อกับ ISP1 ยังมีสถานะ Up อยู่ แต่เนื่องจาก next Hop เป็น Hop ที่ไม่สามารถติดต่อด้วย ICMP ดังนั้น IP SLA จะถอดถอน ข้อมูลเส้นทาง Default Route ที่ใช้ ISP1 เป็น Hop ต่อไป ออกไปจากตารางเราติ้ง

FastEthernet1/0            10.1.1.1        YES NVRAM  up                    up

FastEthernet1/1            192.168.1.1     YES NVRAM  up                 up

FastEthernet2/0            172.16.1.1      YES manual up                    up

Router# show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via "static", distance 1, metric 0, candidate default path
  Routing Descriptor Blocks:
  * 172.16.1.2
      Route metric is 0, traffic share count is 1

สมมติว่า เราจะทำให้การเชื่อมต่อมีสถานะ Up เพื่อดูว่าเกิดอะไรขึ้น จะเห็นว่า

*Dec 19 20:31:29.143: %TRACKING-5-STATE: 10 rtr 1 reachability Down->Up

Routing entry for 0.0.0.0/0, supernet
  Known via "static", distance 1, metric 0, candidate default path
  Routing Descriptor Blocks:
  * 192.168.1.2
      Route metric is 0, traffic share count is 1
    172.16.1.2
      Route metric is 0, traffic share count is 1

ทดสอบ Ping ไปที่  100.100.100.100 อีกครั้ง จะปรากฏหน้าจอดังนี้

*Dec 19 20:32:15.559: NAT*: s=10.1.1.10->192.168.1.1, d=100.100.100.100 [183]
*Dec 19 20:32:16.071: NAT*: s=100.100.100.100, d=192.168.1.1->10.1.1.10 [183]

               มาถึงตรงนี้ สมมติว่า เราเอาคำสั่ง match interface ออกไปจาก NAT route-map เราจะเห็นผลลัพธ์ต่อไปนี้

(config)#route-map ISP1
(config-route-map)#no ma
(config-route-map)#no match in
(config-route-map)#no match interface fa1/1
(config-route-map)#route-map ISP2
(config-route-map)#no ma
(config-route-map)#no match int fa2/0
(config-route-map)#

Router#clear ip nat translation *

               จากนั้นให้ลอง Ping และดำเนินการ Telnet เราจะเห็นว่า Traffic ถูกแปลไปเป็น 192.168.1.1 โดยไม่สนใจว่า traffic จะออกไปทางใด

Router #ping 100.100.100.100

*Dec 19 20:33:47.615: NAT*: s=10.1.1.10->192.168.1.1, d=100.100.100.100 [184]
*Dec 19 20:33:48.067: NAT*: s=100.100.100.100, d=192.168.1.1->10.1.1.10 [184]

*Dec 19 20:34:51.675: NAT*: i: tcp (10.1.1.10, 21603) -> (100.100.100.100, 23) [64704]
*Dec 19 20:34:51.679: NAT*: i: tcp (10.1.1.10, 21603) -> (100.100.100.100, 23) [64704]
*Dec 19 20:34:51.683: NAT*: s=10.1.1.10->192.168.1.1, d=100.100.100.100 [64704]
*Dec 19 20:34:51.847: NAT*: o: tcp (100.100.100.100, 23) -> (192.168.1.1, 21603) [52374]
*Dec 19 20:34:51.847: NAT*: s=100.100.100.100, d=192.168.1.1->10.1.1.10 [52374]
*Dec 19 20:34:52.123: NAT*: i: tcp (10.1.1.10, 21603) -> (100.100.100.100, 23) [64705]

คราวนี้ลองติดตั้งคำสั่ง match interface กลับคืนเข้าไปที่แต่ละ Route map

*Dec 19 20:36:23.379: NAT*: i: icmp (10.1.1.10, 16) -> (100.100.100.100, 16) [185]
*Dec 19 20:36:23.383: NAT*: i: icmp (10.1.1.10, 16) -> (100.100.100.100, 16) [185]
*Dec 19 20:36:23.387: NAT*: s=10.1.1.10->192.168.1.1, d=100.100.100.100 [185]
*Dec 19 20:36:23.827: NAT*: o: icmp (100.100.100.100, 16) -> (192.168.1.1, 16) [185]
*Dec 19 20:36:23.827: NAT*: s=100.100.100.100, d=192.168.1.1->10.1.1.10 [185]


Router# telnet 100.100.100.100

*Dec 19 20:36:52.099: NAT*: i: tcp (10.1.1.10, 16305) -> (100.100.100.100, 23) [46655]
*Dec 19 20:36:52.099: NAT*: i: tcp (10.1.1.10, 16305) -> (100.100.100.100, 23) [46655]
*Dec 19 20:36:52.103: NAT*: s=10.1.1.10->172.16.1.1, d=100.100.100.100 [46655]
*Dec 19 20:36:52.259: NAT*: o: tcp (100.100.100.100, 23) -> (172.16.1.1, 16305) [41145]
*Dec 19 20:36:52.259: NAT*: s=100.100.100.100, d=172.16.1.1->10.1.1.10 [41145]
*Dec 19 20:36:52.355: NAT*: i: tcp (10.1.1.10, 16305) -> (100.100.100.100, 23) [46656]
*Dec 19 20:36:52.359: NAT*: s=10.1.1.10->172.16.1.1, d=100.100.100.100 [46656]
*Dec 19 20:36:52.375: NAT*: i: tcp (10.1.1.10, 16305) -> (100.100.100.100, 23) [46657]

สรุป : Policy Base Routing และ IPSLA Tracking เป็นเครื่องมือและกลไกสำคัญ ที่ช่วยให้ผู้จัดการระบบเครือข่าย มีทางเลือก ในการเลือกเส้นทาง แทนที่ทุกอย่างจะต้องขึ้นอยู่กับการตัดสินใจเลือกเส้นทางแต่อย่างเดียว แต่อย่างไรก็ตาม ท่านจะต้องมีเส้นทางเชื่อมต่อไปยังภายนอกมากกว่า 1 เส้นทาง นอกจากนี้ IP SLA Tracking ยังช่วยให้ท่านสามารถได้หลักประกันว่า หากเส้นทางหลักเกิดปัญหาการเชื่อมต่อก็สามารถใช้เส้นทางสำรองแทน โดยอัตโนมัติ นำเป็นความยืดหยุ่นที่ Cisco มอบให้กับท่านที่ใช้อุปกรณ์เครือข่ายของ Cisco

Read 18879 times Last modified on วันพุธ, 17 พฤษภาคม 2560 05:45
ChalermPun

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nos exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum.

Leave a comment

Make sure you enter all the required information, indicated by an asterisk (*). HTML code is not allowed.