สรุปลำดับการทำงานของ ACL (Access Control List) ก่อนที่ท่านจะศึกษาเรื่อง ACL (Access Control List) นั้นท่านควรมีความรู้เรื่อง TCP/IP ในระดับ TCP/UDP port สักหน่อย โดยท่านสามารถเข้าไปศึกษาได้ตาม link นี้ครับ //www.bloggang.com/viewblog.php?id=likecisco&date=10-02-2015&group=3&gblog=29 ============================================= ตัวอย่าง ACL Command: access-list 100 permit tcp host 10.1.1.1 host 20.1.1.1 eq 80 access-list 100 permit tcp host 10.1.1.2 30.1.1.0 0.0.0.255 eq 23 ACL สามารถใส่มุมมองของ programming ได้ในลักษณะนี้ครับ สิ่งแรกที่ท่านต้องจำไว้คือ ACL ทำงานจากบรรทัดบน ลงบรรทัดล่างเสมอ if < condition > then < action permit/deny > (ACLStatement ที่ 1) else if < condition > then < action permit/deny > (ACL Statement ที่ 2) else if < condition > then < action permit/deny > (ACL Statement ที่ 3) - if < condition > หมายถึง เมื่อ < condition > ประกอบไปด้วย conditionย่อยๆ คือ - Protocol อะไรที่สนใจ (TCP, UDP, ICMP หรืออืนๆ) - Source IP address ที่สนใจเป็น IP address อะไร หรือมี rangeของ source IP address เป็นเบอร์อะไร (การใช้งานปกติทั่วๆไป ที่ไม่ได้ประยุกต์แล้ว ปกติ source IP address จะเป็น IP address ของ client ที่จะไปขอใช้บริการ server) - Source Port (กรณีสนใจ protocol TCP/UDP) เป็น port อะไรหากสนใจ แต่ปกติจะไม่กำหนด เพราะเมื่อ client ไปติดต่อกับ server แล้ว มันจะ random source port และเมื่อไม่กำหนด source port แล้ว จะหมายถึง source port = any - Destination IP address ที่สนใจ เป็น IP address อะไร หรือมี range ของ destination IP address เป็นเบอร์อะไร (การใช้งานปกติทั่วๆไป ที่ไม่ได้ประยุกต์แล้ว ปกติ destination IP address จะเป็น IP address ของ server ที่จะถูกใช้บริการจาก client) - Destination Port (กรณีสนใจ protocol TCP/UDP) เป็น port อะไร โดยปกติทั่วๆ ไปแล้ว (ในกรณีที่ไม่ได้ประยุกต์) destination port จะเป็น port ที่ client จะระบุเพื่อบอกกับ server ว่าต้องการใช้บริการ application อะไร เพราะ server 1 ตัว สามารถให้บริการ service ได้มากกว่า 1 service หรือกล่าวอีกนัยหนึ่ง คือ server หนึ่งตัวอาจจะเปิด TCP/UDP port ไว้มากกว่าหนึ่ง port (TCP/UDP port จะเป็นมาตรฐานที่ถูกผูกไว้กับ Application) โดยท่านสามารถเข้าไปดูได้ตาม link นี้ครับ //en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers ------------------------------------------------- โดย ACL Statement นั้นๆ จะถือว่า match หรือเป็นจริง ทั้ง statement ก็ต่อเมื่อ condition ย่อยทั้งหมดจะต้องเป็นจริง เพราะ condition ย่อยต่างๆ ใน ACL statement นั้นๆ จะเชื่อมกันด้วย AND Logic < condition > = < Protocol AND source IP AND source port AND destination IP AND destination port> ------------------------------------------------ ตัวอย่างที่ 1 ของ < condition > access-list 100 permit tcp host 10.1.1.1 host 20.1.1.1 eq 80 < condition > คือ - Protocol: TCP - Source IP address: host 10.1.1.1 - Source TCP Port: Any port (เพราะไม่ได้ระบุว่าให้ใช้ port อะไร หรือไม่มี command eq ตามหลัง source IP address) - Destination IP address: host 20.1.1.1 - Destination TCP Port: eq 80 (หรือ TCP port 80 หรือ Web Application) ความหมายคือ: เรากำลังสนใจ traffic จาก client เครื่องใดเครื่องหนึ่งที่มี IP address 10.1.1.1 ไปยัง server เครื่องใดเครื่องหนึ่งที่มี IP address 20.1.1.1 โดยไม่สนใจว่า client จะใช้ source TCP port เป็นหมายเลขอะไร (any port) แต่สนใจ traffic ที่ไปหา server 20.1.1.1 เพื่อไปติดต่อ server ขอใช้บริการ Web Application (www หรือ TCP port 80) สิ่งที่ขอให้ท่านจำไว้ให้ขึ้นใจ คือ  หลักการเขียน ACL จะเขียนเน้นในลักษณะทิศทางจาก Client-to-Server เป็นหลัก เพราะ service ต่างๆ จะเริ่มต้นการสื่อสารจาก Client เป็นคนร้องขอ หรือ request เสมอ (ไม่นิยมเขียนกลับจาก Server-to-Client แต่หากต้องการ ก็สามารถเขียนได้ แต่จะต้องเข้าใจเรื่อง flow ของ traffic ให้ดีก่อน) และจากที่ Client เป็นผู้เริ่มต้นของการสื่อสาร (ส่ง request หรือ sync) ดังนั้น Client จะใช้ source port ที่เป็น random ดังข้อมูลข้างล่าง - สำหรับ Windows XP และ version ที่ต่ำกว่า จะใช้ source port ที่เป็น Dynamic portrange สำหรับ TCP/IP ตั้งแต่ 1,025 ไปจนถึง 5,000 - สำหรับ Windows Vista และ Windows Server 2008 เป็นต้นไป จะใช้ sourceport ที่เป็น Dynamic port range สำหรับ TCP/IP ตั้งแต่ 49,152 ไปจนถึง 65,535 นั่นก็คือ ในการเขียน ACL โดยเน้นทิศทางจาก Client-to-Server แล้ว เราจะไม่สามารถบอกได้อย่างชัดเจนว่า Client กำลังใช้ Source Port เลขอะไร ดังนั้น เราจะสังเกตเห็นได้จาก ACL โดยทั่วๆ ไปว่า จะไม่การกำหนด Source Port ใน ACL เลย (ไม่มี command "eq" ตามหลัง Source IP address) Note: หากมีการเขียน ACL ในทิศทาง return traffic จาก Server-to-Client แล้ว เราจะเห็นการเขียนที่มีความแตกต่างออกไปจากปกติทั้่วๆ ไป แต่ผมขออนุญาติไม่อธิบายในรายละเอียดนะครับ เพื่อไม่ให้ท่านเกิดความสับสน เพราะมันเป็นส่วนน้อยที่ท่านแทบจะไม่เจอเลย หากท่านใดต้องการอ่านข้อมุลเพิ่มเติมเกี่ยวกับ "Default dynamic port range สำหรับ TCP/IP" แล้ว ท่านสามารถไปตามอ่านได้ตาม link นี้ครับ //www.bloggang.com/viewblog.php?id=likecisco&date=10-02-2015&group=3&gblog=29 ------------------------------------------------- ตัวอย่างที่ 2 ของ < condition > access-list 100 permit tcp host 10.1.1.2 30.1.1.0 0.0.0.255 eq 23 < condition > คือ - Protocol: TCP - Source IP address: host 10.1.1.2 - Source TCP Port: Any port (เพราะไม่ได้ระบุว่าให้ใช้ port อะไร หรือไม่มี command eq ตามหลัง source IP address) - Destination IP address: host ตั้งแต่ IP address 30.1.1.0 ไปจนถึง IP address 30.1.1.255 (แต่ในความเป็นจริงแล้ว IP address ที่ใสามารถช้ได้จริงคือ IP address 30.1.1.1 จนถึง IP address 30.1.1.254 เท่านั้น) - Destination TCP Port: eq 23 (หรือ TCP port 23 หรือ Telnet Application) ความหมายคือ: เรากำลังสนใจ traffic จาก client เครื่องใดเครื่องหนึ่งที่มี IP address 10.1.1.2 ไปยัง server IP address ใด address หนึ่งจาก 30.1.1.1 ถึง 30.1.1.254 โดยไม่สนใจว่า client จะใช้ source TCP port เป็นหมายเลขอะไร (any port) แต่สนใจ traffic ที่ไปหา server 30.1.1.1 ถึง 30.1.1.254 เพื่อไปติดต่อ server ขอใช้บริการ Telnet Application (หรือ TCP port 23) ------------------------------------------------- หาก ACL Statement นั้นๆ match หรือเป็นจริงทั้ง statement แล้ว then < action permit/deny > จากนั้นมันจะไปดู Action ที่ได้กำหนดเอาไว้ว่า เป็น permit หรือ deny โดย permit และ deny จะมีความหมายอยู่ 2 แบบคือ: - ถ้า ACL ใช้เป็น Filtering หรือ Firewall แล้ว:  - Permit = ปล่อยผ่าน - Deny = Drop ทิ้งไป - ถ้า ACL ใช้เป็น Classification เช่น ใช้กับ QoS, IPsec VPN, NAT และอื่นๆ แล้ว: - Permit = สนใจ เอาไปใช้กับเรื่องที่ ACL นี้ผูกอยู่ - Deny = ไม่สนใจ เอาไปใช้กับเรื่องที่ ACL นี้ผูกอยู่ หาก ACL statement นั้นๆ เป็นจริงทั้ง statement หาก ACL statement นั้นๆ เป็นจริงทั้ง statement และได้กระทำ action permit หรือ deny ไปแล้ว จะถือว่าเป็นการจบการไล่ ACL แต่ถ้าไม่ match condition แรกแล้ว else if  < condition > then < action permit/deny > else if ก็คือ ให้ไปดู  < condition >  บรรทัดถัดไป แล้วไล่ลงไปเรื่อยๆ เหมือนที่อธิบายไว้ในตอนแรก ถ้าไม่ match ซัก condition ในบรรทัดใดๆ เลย ก็จะมี implicit deny all statement ดักที่ท้ายสุด เพราะว่าเราไม่สามารถกำหนด condition ได้ทุกรณี หรือทุกเงื่อนไขครับ สำหรับการนำ ACL ที่เขียนเสร็จแล้วไป Apply ที่ Interface นั้น ท่านจะต้องกำหนดทิศทางของ ACL บน Interface ให้ถูกต้องด้วย มิฉะนั้นอาจจะเกิดโศกนาฏกรรมกับท่านได้นะครับ เพราะ packet จะไม่เข้าเงื่อนไขที่ท่านเขียนเลย แต่ไปลงที่ implicit deny all statement ทั้งหมดได้นะครับ  สำหรับการกำหนดทิศทางของ ACL บน Interface นั้น ท่านสามารถเข้าไปดูแนวทางได้ตาม link นี้ครับ //www.bloggang.com/viewblog.php?id=likecisco&date=19-05-2015&group=3&gblog=41 สำหรับ Wildcard Mask ระดับ Advance ท่านสามารถเข้าไปดูได้ตาม link นี้ครับ //www.bloggang.com/viewblog.php?id=likecisco&date=15-04-2015&group=3&gblog=39 บทความนี้ไม่ได้เขียนละเอียดนัก แต่เขียนเพื่อเป็นไอเดียร์ หรือ concept ให้ท่านได้ศึกษาเป็นแนวทางครับ หากมีเวลาจะมาปรับปรุงพร้อมยกตัวอย่างครับ KoChaiwat (โก้-ชัยวัฒน์)   Create Date : 10 เมษายน 2558     25 comment Last Update : 2 กุมภาพันธ์ 2559 18:46:28 น.     Counter : 20018 Pageviews.   Share Tweet

IPv6: Link Local Address ที่มี % และตัวเลขตามหลัง fe80:: address คืออะไร เนื่องจากประสบการณ์ที่ผมได้ศึกษา, ทำ Lab และเคยสอน IPv6 มาแล้ว และมีบางอย่างที่หลายๆ ท่านยังไม่ทราบ นั่นก็คือ ตัวเลขที่ตามหลัง % ใน IPv6 Link Local Address คืออะไร ก่อนอื่น เราควรจะเข้าใจคำว่า link local address ใน IPv6 กันสักหน่อยนะครับ IPv6 Link Local Address จะเป็น address ที่ขึ้นต้นด้วย fe80:: (64 bit) แล้วตามด้วย Interface ID (ใน IPv4 เรียก host ID) อีก 64 bit และ address นี้จะเป็น address ที่เกิดขึ้นมาเองบน card Ethernet LAN adapter หรือ Wireless adapter  โดย IPv6 Link Local Address นี้จะมี prefix (bit ที่เป็น network) ขนาด 64 bit จากตัวอย่างตามรูปข้างบน เช่น  fe80::3128:da8e:47a7:5672%12  IPv6 Link Local Address:  fe80::3128:da8e:47a7:5672/64 Prefix (Network ID ใน IPv4):    fe80::/64 Interface ID (Host ID ใน IPv4):    ::3128:da8e:47a7:5672 Zone ID หรือ Scope ID หรือ Interface Index: %12 สำหรับ Link-Local Address นั้น โดยปกติแล้ว Zone ID ก็คือ Interface Index ของ Interface ที่ถูกใช้อ้างอิงในการส่ง IPv6 packet ที่มี destination เป็น Link-Local address ให้สังเกตจากรูปข้างบน จะเห็นว่า Wireless LAN adapter และ Ethernet adapter ต่างก็ใช้ IPv6 Link Local ที่มี Prefix (Network ID) เหมือนกัน คือ fe80::/64 Wireless LAN adapter: fe80::3128:da8e:47a7:5672%12  (Interface Index 12) Ethernet adapter: fe80::e526:8aa3:3236:519b%11  (Interface Index 11) ดังนั้น เมื่อเวลาเรา ping ไปยังปลายทาง fe80::X:X:X:X:X:X ใดๆ แล้ว Windows จะไม่สามารถตัดสินใจได้ ว่าเราต้องการให้ ICMP request นี้ออก  Wireless adapter หรือว่าให้ออก Ethernet adapter เนื่องจาก โดยปกติแล้ว Windows จะเปรียบเทียบ Destination Network กับ Network ID ที่อยู่บน LAN adapter ว่าตรงกับ LAN adapter ตัวไหน แต่ปัญหาคือ LAN adapter ทั้งสองใช้ Prefix หรือ Network ID หมายเลขเดียวกัน นั่นคือ fe80::/64 ดังนั้นเวลาเรา ping ไปยัง IPv6 Link Local address ปลายทางแล้ว เราจึงจำเป็นที่จะต้องช่วยบอกกับ Windows ว่า "ICMP request" นี้ต้องการให้ออกไปยัง LAN adapter card ไหน ด้วยการระบุ Interface Index ตามท้ายทุกครั้ง  เช่น ให้ดูรูปด้านบนประกอบ - ถ้า IPv6 Link Local address: fe80::A:B:C อยู่บน Wireless Network เราก็จะต้อง ping ดังนี้ C:> ping fe80::A:B:C%12 - ถ้า IPv6 Link Local address: fe80::5:6:7 อยู่บน Ethernet LAN Network เราก็จะต้อง ping ดังนี้ C:> ping fe80::5:6:7%11 บทความนี้ยังไม่ได้เขียนอย่างละเอียดนัก เพียงแค่เป็น Guideline ให้สามารถศึกษาต่อได้นะครับ หากมีเวลา จะมาปรับปรุงให้ละเอียดขึ้ัน พร้อมแสดงตัวอย่างให้ดูครับ Link อ้างอิงจาก Microsoft: https://technet.microsoft.com/en-us/library/bb726952.aspx   Create Date : 04 เมษายน 2558     9 comment Last Update : 12 เมษายน 2558 15:43:57 น.     Counter : 20069 Pageviews.   Share Tweet

เปรียบเทียบ Outgoing Interface กับ Next-Hop ใน command "static route"   เปรียบเทียบ Outgoing Interface กับ Next-Hop ใน command "static route"     ก่อนจะอ่านบทความนี้ขอให้ไปดู VDO เรื่อง "หลักการทำงานของ Switch ที่เกี่ยวข้องกับ MAC address และเรื่อง ARP และ Gateway" ใน Pre CCNA KoChaiwat Vol. 2-2 ก่อนนะครับ    https://www.bloggang.com/viewblog.php?id=likecisco&date=04-06-2016&group=11&gblog=1   สำหรับเรื่อง "Default Route" หรือ "Gateway of last resort" แล้ว ขอให้ไปดูตาม link นี้ครับ: https://www.bloggang.com/viewblog.php?id=likecisco&date=26-03-2015&group=3&gblog=33   =================================================   1. ก่อนจะกล่าวถึง Outgoing Interface เทียบกับ Next Hop แล้ว เราควรจะมีความเข้าใจการทำงานพื้นฐานของการ forwarding IP packet กันสักหน่อยดังนี้ครับ   1.1. เมื่อ router ได้รับ Ethernet frame ที่มี destination MAC address ที่ตรงกับ incoming interface ของมันแล้ว มันจะทำการ De-Encapsulation Ethernet frame header (Layer 2 header) และ trailer (Layer 2 ในส่วนที่เป็น FCS หรือ Frame Check Sequence) ออก จากนั้นมันจะเข้าไปอ่าน destination IP address ที่อยู่ใน IP header เทียบกับรายการของ routes (routing entries) ใน routing table ของมัน (ใช้หลักการ longest match ซึ่งผมจะขออนุญาติไม่กล่าวในรายละเอียด)   1.2. หลังจากที่ router ตรวจพบรายการของ route ใน routing table ที่ match กับ destination IP address แล้ว มันจะทำการตรวจสอบต่อไปว่า route นั้นๆ ถูกชี้เป็น outgoing interface หรือ next hop IP address 1.2.1 ถ้าชี้เป็น outgoing interface router จะพิจารณาต่อไปว่า IP packet ที่จะถูก forward ออกไปยัง interface นี้ จะต้อง encapsulation เป็น Layer 2 header protocol อะไร  - ถ้า Layer 2 protocol เป็นพวก Point-to-Point protocol อย่างเช่น HDLC หรือ PPP ก็ forward ออกไปอย่างง่ายดาย โดยไม่ต้องสนใจในเรื่องของ Layer 2 address เพราะอะไรน่ะหรือ??? ---> เพราะว่า point-to-point protocol อย่าง HDLC และ PPP จะเป็น protocol ที่บังคับว่า จะต้องมีต้นทาง 1 host และมีปลายทางได้เพียงแค่ 1 host เท่านั้น ตามชื่อของมัน คือ point-to-point protocol ดังนั้น เมื่อผู้ส่งต้องการส่ง Layer 2 frame ออกไป มันจะไม่ต้องสนใจ หรือกังวลเลยว่า ปลายทางจะเป็นใคร เพราะว่าปลายทางมีแค่เพียง 1 เดียวเท่านั้น ดังนั้นใน Layer 2 protocol ที่เป็น point-to-point protocol อย่างเช่น HDLC และ PPP จึงไม่ต้องมี Layer 2 address เข้ามาให้กังวล และไม่ต้องมาสนใจในเรื่องของการทำ ARP เพื่อ mapping Layer 2 address กับ Layer 3 address (IP address) แต่อย่างใด ดังนั้นการใช้ option outgoing interface ใน static route จึงเหมาะกับ Physical Interface แบบ Serial ที่มีการ encapsulation แบบ HDLC และ PPP  - ถ้า Layer 2 protocol เป็น Ethernet Protocol แล้วล่ะก็ router จะต้องเข้าไปเกี่ยวข้องกับ ARP protocol เพราะอะไรน่ะหรือ??? ---> เพราะว่า Physical interface ประเภท Ethernet ที่ซึ่งต้องใช้คู่กับ Layer 2 protocol แบบ Ethernet จะเป็น interface และ protocol แบบ Multi-Access ซึ่งหมายถึง ต้นทาง 1 host สามารถติดต่อกับปลายทางได้หลายๆ host ดังนั้นเมื่อต้นทางต้องการติดต่อกับปลายทาง ซึ่งมีได้หลายๆ host แล้ว เมื่อต้นทางทำการส่ง Layer 2 Frame แบบ Ethernet ออกไปยัง Switch ต้นทางจะต้องระบุ destination MAC address เอาไว้ใน Ethernet Header เพื่อให้ Switch ที่อยู่ตรงกลางสามารถอ่าน และ forward Ethernet frame นั้นๆ ต่อไปยังปลายทางได้  แต่สิ่งที่ตามมาคือ ต้นทางจะต้องรู้ให้ได้ว่า Layer 2 header (Ethernet Header) ควรใส่ destination MAC address เป็นเบอร์อะไร ดังนั้นจึงหนีไม่พ้นที่ต้นทางจะต้องทำกระบวนการ ARP เพื่อทำการ learn destination MAC มาให้จงได้ ซึ่งรายละเอียดจะอยู่ในหัวข้อที่ 3 "การ configure static route โดยการชี้ไปยัง outgoing interface" ข้างล่างครับ 1.2.2 ถ้าชี้ไปยัง next hop IP address router จะต้องทำ "recursive lookup" หรือ "การค้นหาแบบเรียกซ้ำ" เนื่องจาก parameter เพียงแค่ next hop นั้น มันยังไม่เพียงพอต่อการตัดสินใจในการ forward IP packet ไปบน Layer 2 Frame Header เพราะมันไม่รู้ว่าจะต้องจับเจ้า IP packet นี้มา encapsulation ด้วย Layer 2 protocol อะไร ดังนั้นมันจะทำ recursive lookup ดังนี้ Step 1: ตรวจสอบ next hop IP address ว่าเป็นเบอร์อะไร Step 2: นำ next hop IP address เบอร์นั้นๆ มาเทียบกับ directly connected subnet ว่าตรงกับ subnet ไหน แล้วจึงรู้ว่า outgoing interface คือ interface อะไร และ interface นั้นๆ ใช้ Layer 2 protocol อะไร จากนั้นจึงตัดสินใจในการ forward IP packet นี้ไปบน Layer 2 protocol ได้อย่างถูกต้อง (encapsulation)   Note: ถ้าชี้เป็น next hop IP address และ next hop IP address นั้นๆ อยู่บน interface ประเภท Ethernet แล้ว, router จะพิจารณาว่า next hop IP address นั้นๆ ถูก mapping กับ MAC address อะไร เพื่อที่จะนำมาใช้เป็น destination MAC address ใน Ethernet Frame Header ซึ่งก็หนีไม่พ้นที่จะต้องใช้ ARP protocol   2. การ configure static route โดยการชี้ไปยัง next hop IP address (ให้สังเกตที่ router R1)   การระบุเป็น next hop บน directly connected interface จะสามารถป้องกัน router จากการดำเนินการ ARP สำหรับ destination ทุกๆ destination ได้   จากภาพตัวอย่างข้างบน ให้สังเกตที่ router R1 Note: จากตัวอย่างในภาพ เป็นการเปรียบเทียบปัญหาของ outgoing interface กับ next-hop ดังนั้น IP address ในภาพ จะไม่ได้เน้นในเรื่องของ public / private IP address นะครับ   Step 1: R2 ทำตัวเป็นเสมือน router ของ ISP และ learn routes 10.1.1.0/24, 20.1.1.0, และ 30.1.1.0/24 มาจากที่อื่นๆ และทำการบันทึก routes เหล่านี้ลงใน routing table ของ R2 เอง (routes 10.1.1.0/24, 20.1.1.0/24 และ 30.1.1.0/24 ไม่ใช่ routes ของ R2 เอง)    Step 2: R1 มีการ configure static route ไปยัง destination ต่างๆ โดยชี้ผ่านไปยัง R2 ด้วยการใช้ option ที่เป็น next hop IP address (11.1.1.2) ซึ่งเป็น IP address ของ interface Fa0/0 บน R2   Note: R1 ทำการ configure static route สำหรับ 10.1.1.0/24, 20.1.1.0, และ 30.1.1.0/24 เป็นแบบ next hop IP address ซึ่งทุกๆ routes ดังกล่าว ถูก configure ไว้ให้ใช้ next hop IP address เดียวกัน คือ 11.1.1.2  [R1 มอง IP address 11.1.1.2 เป็น Gateway address] Note: next hop address = gateway address   Step 3: R1 ping ไปยัง 10.1.1.1 ซึ่งอยู่ใน subnet 10.1.1.0/24    Step 4: ในการส่ง ICMP request packet ไปยัง 10.1.1.1  นั้น R1 จะต้องตรวจสอบว่า ICMP request packet ที่มี destination 10.1.1.1 จะต้องผ่าน next hop address หรือ gateway เบอร์อะไร? ซึ่งจาก static route (ip route 10.1.1.0 255.255.255.0 11.1.1.2) บน R1 แล้ว R1 พบว่ามันจะต้อง forward ICMP request packet นี้ออกไปยัง next hop (gateway) เบอร์ 11.1.1.2 Step 5: แต่เพราะว่า R1 ไม่เคยมีข้อมูล mapping ระหว่าง Layer 3 address (IP address [11.1.1.2] ของ F0/0 บน R2) กับ Layer 2 address (MAC address [cc04.0c40.0000] ของ Fa0/0 บน R2) ใน ARP Table ของ R1 เลย ดังนั้น R1 จึงต้องหยุดพักการส่ง ICMP request ไว้ชั่วคราว และทำการส่ง ARP request เพื่อค้นหาว่า next-hop (gateway) 11.1.1.2 จะต้องจับคู่กับ MAC address เบอร์อะไร   Step 6: R1 ส่ง ARP request สำหรับ next hop (gateway) 11.1.1.2 แบบ Broadcast Step 7: R2 ได้รับ ARP request จาก R1 ที่มีการระบุเป้าหมาย ใน ARP request message เป็น 11.1.1.2 และเพราะว่า R2 เป็นเจ้าของ IP address เบอร์ 11.1.1.2 เอง ดังนั้นมันจึงทำการตอบกลับไปยัง R1 ด้วย ARP reply ประมาณว่า "11.1.1.2 map กับ cc04.0c40.0000 นะจ๊ะ"   Step 8: เมื่อ R1 ได้รับ ARP reply จาก R2 แล้ว R1 จะทำการ บันทึก/จัดเก็บ การ mapping ระหว่าง  11.1.1.2 กับ cc04.0c40.0000 ไว้ใน ARP table ของมัน เพื่อไว้ใช้ในครั้งถัดไป   Step 9: จากนั้น R1 จึงนำ ICMP request packet ที่มี destination 10.1.1.1 ที่ได้หยุดไว้ชั่วคราว ใน step 5 มาทำการ forward ออกไปยัง next hop/gateway 11.1.1.2 โดยมี destination MAC address เป็น cc04.0c40.0000 Note สำหรับ Step 9 นี้ ถ้าใครไม่เข้าใจ ขอให้ท่านไปดู VDO  ตาม link ข้างล่าง Vol 1, Vol 2-1 และ Vol 2-2 มาก่อนนะครับ แล้วกลับมาอ่านบทความนี้ต่อ https://www.bloggang.com/viewblog.php?id=likecisco&date=04-06-2016&group=11&gblog=1   Step 10: (เริ่มเข้าสู่จุดสำคัญ) R1 ping ไปยัง 20.1.1.1 ซึ่งอยู่ใน subnet 20.1.1.0/24    Step 11: ในการส่ง ICMP request packet ไปยัง 20.1.1.1  นั้น R1 จะต้องตรวจสอบว่า ICMP request packet ที่มี destination 20.1.1.1 จะต้องผ่าน next hop address หรือ gateway เบอร์อะไร? ซึ่งจาก static route (ip route 20.1.1.0 255.255.255.0 11.1.1.2) บน R1 แล้ว R1 พบว่ามันจะต้อง forward ICMP request packet นี้ออกไปยัง next hop (gateway) เบอร์ 11.1.1.2   Step 12: เพราะว่า R1 เคยมีข้อมูล mapping ระหว่าง Layer 3 address (IP address [11.1.1.2] ของ F0/0 บน R2) กับ Layer 2 address (MAC address [cc04.0c40.0000] ของ Fa0/0 บน R2) ใน ARP Table ของ R1 ไว้แล้ว (จาก step 5 ถึง step 8)  ดังนั้น R1 จึงไม่ต้องส่ง ARP request อีกสำหรับ next hop/gateway 11.1.1.2 แต่สามารถนำข้อมูลใน ARP table ที่มีอยู่แล้วมาใช้ในการ forwarding ICMP request packet ที่มี destination 20.1.1.1 ได้อย่างทันทีทันใดเลย   Step 13: R1 ping ไปยัง 30.1.1.1 ซึ่งอยู่ใน subnet 30.1.1.0/24 ก็จะดำเนินการในลักษณะเดียวกันกับ step 10 ถึง step 12     ณ. จุดๆ นี้ เราอาจจะยังไม่เห็นความสำคัญของการใช้ option next hop แต่เมื่อท่านได้อ่านในหัวข้อถัดไป ที่เป็นการใช้ option outgoing interface ท่านจะรู้ว่า option next hop มีความปลอดภัยกว่า outgoing interface อย่างแน่นอน       3. การ configure static route โดยการชี้ไปยัง outgoing interface (ให้สังเกตที่ router R5)   ถ้าเราชี้ (point)  "static route" ไปยัง broadcast interface หรือระบุ outgoing interface เป็น broadcast interface แล้ว route จะถูกใส่เข้าไปใน routing table ก็ต่อเมื่อ broadcast interface นั้นๆ อยู่ในสถานะ "up" เท่านั้น ซึ่งผมไม่แนะนำอย่างเด็ดขาด เพราะอะไรนะหรือ เรามาดูกันครับ   Default Route ที่ระบุด้วย Outgoing Interface เช่น:   ip route 0.0.0.0 0.0.0.0 FastEthernet0/0    จากการ configure แบบนี้แล้ว router จะดำเนินการ ARP (Address Resolution Protocol) บน FastEthernet 0/0 สำหรับ destination ทุกๆ destination ของ IP packet ที่ router ค้นพบผ่านทาง default route เนื่องจาก router จะพิจารณา destination เหล่านี้ทั้งหมดเป็น directly connected บน FastEthernet 0/0   การ configure default route แบบนี้ โดยเฉพาะอย่างยิ่ง ในกรณีที่มี IP packet จำนวนมากๆ ที่มี destination subnet ที่แตกต่างกันแล้ว จะสามารถเป็นเหตุให้เกิดอาเพศได้ดังนี้: - CPU utilization ขึ้นสูง - เกิด ARP cache ที่มีขนาดใหญ่ เพราะต้องเก็บ destination IP address ทั้งหมด - และก็จะตามมาด้วยปัญหา ความล้มเหลวในการจัดสรร memory     จากภาพตัวอย่างข้างล่าง ให้สังเกตที่ router R5 Note: จากตัวอย่างในภาพ เป็นการเปรียบเทียบปัญหาของ outgoing interface กับ next-hop ดังนั้น IP address ในภาพ จะไม่ได้เน้นในเรื่องของ public / private IP address นะครับ   Step 1: R2 ทำตัวเป็นเสมือน router ของ ISP และ learn routes 10.1.1.0/24, 20.1.1.0, และ 30.1.1.0/24 มาจากที่อื่นๆ และทำการบันทึก routes เหล่านี้ลงใน routing table ของ R2 เอง (routes 10.1.1.0/24, 20.1.1.0/24 และ 30.1.1.0/24 ไม่ใช่ routes ของ R2 เอง)    Step 2: R5 มีการ configure static route ไปยัง destination ต่างๆ โดยชี้ผ่านไปยัง R2 ด้วยการใช้ option ที่เป็น outgoing interface (FastEthernet0/0) ซึ่งเป็น Interface Fa0/0 ของ R5 เอง   Note: R5 ทำการ configure static route สำหรับ 10.1.1.0/24, 20.1.1.0, และ 30.1.1.0/24 เป็นแบบ outgoing interface ซึ่งทุกๆ routes ดังกล่าว ถูก configure ไว้ให้ R5 ทำการ forward IP packet ที่มี destination 10.1.1.0/24, 20.1.1.0/24 และ 30.1.1.0/24 ให้ออกทาง Interface Fa0/0 ของ R5 เอง   [R5 ไม่ได้มีการ configure Gateway เหมือนอย่างหัวข้อ next hop address]     Step 3: R5 ping ไปยัง 10.1.1.1 ซึ่งอยู่ใน subnet 10.1.1.0/24    Step 4: ในการส่ง ICMP request packet ไปยัง 10.1.1.1  นั้น R5 จะต้องตรวจสอบว่า ICMP request packet ที่มี destination 10.1.1.1 จะต้องผ่าน next hop address หรือ gateway เบอร์อะไร? และเพราะว่า R5 ไม่ได้ทำการ configure next hop/gateway สำหรับ destination 10.1.1.1 (subnet 10.1.1.0/24) ไว้    Note เพราะ R5 configure static route สำหรับ 10.1.1.0/24 ไว้เป็นแบบ outgoing interface คือ ip route 10.1.1.0 255.255.255.0 FastEthernet0/0   อย่างไรก็ตาม R5 ก็จะต้องรู้ให้ได้ว่าในการ forward ICMP request ที่มี destination 10.1.1.1 (subnet 10.1.1.0/24) นี้ใช้ destination MAC address ใน Ethernet Header เป็นเบอร์อะไร    Key ของปัญหาเริ่มจาก ณ. จุดนี้ ดังนั้นแทนที่ R5 จะส่ง ARP request สำหรับ next hop/gateway (ซี่งไม่ได้ configure เอาไว้) แต่ R5 จะส่ง ARP request สำหรับ destination IP address 10.1.1.1 แทน   Step 5: R5 หยุดการส่ง ICMP request packet เป็นการชั่วคราว และส่ง ARP request สำหรับ 10.1.1.1 แบบ ฺBroadcast เพื่อขอ MAC address ของ router ที่จะเป็น Gateway สำหรับการ forward ICMP request packet ที่มี destination 10.1.1.1   Step ุ6: R2 ได้รับ ARP request จาก R5 ที่มีการระบุเป้าหมาย ใน ARP request message เป็น 10.1.1.1 แต่ทว่า R2 ไม่ได้เป็นเจ้าของ IP address เบอร์ 10.1.1.1 เอง ดังนั้นมันจึงต้องไปดูต่อว่า ตัวมันเองได้มีการ enable feature Proxy ARP หรือไม่ (feature ที่ทำให้ router ทำหน้าที่เป็นตัวแทนในการตอบกลับ ARP reply) ซึ่งถ้าหาก R2 ได้มีการ enable feature Proxy ARP เอาไว้แล้ว R2 ก็จะทำการพิจารณาต่อไปว่า มันควรจะตอบกลับ ARP reply สำหรับ 10.1.1.1 หรือไม่ โดย R2 จะนำ 10.1.1.1 ใน ARP request message ไปตรวจสอบใน routing table ของมันเอง ว่า ตัวมันเองรู้จัก หรือสามารถ forward IP packet ที่มี destination 10.1.1.1 ได้หรือไม่  - ถ้ารู้จัก หรือสามารถ forward ต่อไปได้ มันจะตอบกลับ ARP reply ด้วย MAC address ของมัน  - ถ้าไม่รู้จัก หรือไม่สามารถ forward ต่อไปได้ มันก็จะ drop ARP request นั้นทิ้งไป และไม่ตอบกลับ ARP reply   ซึ่งจากตัวอย่างดังภาพข้างล่างแล้ว R2 รู้จัก network 10.1.1.0/24 ใน routing table ของมัน ดังนั้นมันจึงตอบกลับ ARP reply ประมาณว่า "10.1.1.1 map กับ cc04.0c40.0000 นะจ๊ะ"   Step 7: เมื่อ R5 ได้รับ ARP reply จาก R2 แล้ว R5 จะทำการ บันทึก/จัดเก็บ การ mapping ระหว่าง  10.1.1.1 กับ cc04.0c40.0000 ไว้ใน ARP table ของมัน เพื่อไว้ใช้ในครั้งถัดไป   Step 8: จากนั้น R5 จึงนำ ICMP request packet ที่มี destination 10.1.1.1 ที่ได้หยุดไว้ชั่วคราวใน step 5 มาทำการ forward ออกไปยัง R2 ที่มี destination MAC address เป็น cc04.0c40.0000   Step 9: (เริ่มเข้าสู่จุดสำคัญที่สร้างปัญหา) R5 ping ไปยัง 20.1.1.1 ซึ่งอยู่ใน subnet 20.1.1.0/24    Step 10: ในการส่ง ICMP request packet ไปยัง 20.1.1.1  นั้น R5 จะต้องตรวจสอบว่า ICMP request packet ที่มี destination 20.1.1.1 จะต้องผ่าน next hop address หรือ gateway เบอร์อะไร? และเพราะว่า R5 ไม่ได้ทำการ configure next hop/gateway สำหรับ destination 20.1.1.1 (subnet 20.1.1.0/24) ไว้    Note เพราะ R5 configure static route สำหรับ 20.1.1.0/24 ไว้เป็นแบบ outgoing interface คือ ip route 20.1.1.0 255.255.255.0 FastEthernet0/0   อย่างไรก็ตาม R5 ก็จะต้องรู้ให้ได้ว่าในการ forward ICMP request ที่มี destination 20.1.1.1 (subnet 20.1.1.0/24) นี้ใช้ destination MAC address ใน Ethernet Header เป็นเบอร์อะไร    ดังนั้นแทนที่ R5 จะส่ง ARP request สำหรับ next hop/gateway (ซี่งไม่ได้ configure เอาไว้) แต่ R5 จะส่ง ARP request สำหรับ destination IP address 20.1.1.1 แทน   Step 11: R5 หยุดการส่ง ICMP request packet เป็นการชั่วคราว และส่ง ARP request สำหรับ 20.1.1.1 แบบ ฺBroadcast เพื่อขอ MAC address ของ router ที่จะเป็น Gateway สำหรับการ forward ICMP request packet ที่มี destination 20.1.1.1   Step ุ12: R2 ได้รับ ARP request จาก R5 ที่มีการระบุเป้าหมาย ใน ARP request message เป็น 20.1.1.1 แต่ทว่า R2 ไม่ได้เป็นเจ้าของ IP address เบอร์ 20.1.1.1 เอง ดังนั้นมันจึงต้องไปดูต่อว่า ตัวมันเองได้มีการ enable feature Proxy ARP หรือไม่ (feature ที่ทำให้ router ทำหน้าที่เป็นตัวแทนในการตอบกลับ ARP reply)   ซึ่งจากตัวอย่างดังภาพข้างล่างแล้ว R2 ได้มีการ enable feature Proxy ARP เอาไว้ และมันรู้จัก network 20.1.1.0/24 ใน routing table ของมัน ดังนั้นมันจึงตอบกลับ ARP reply ประมาณว่า "20.1.1.1 map กับ cc04.0c40.0000 นะจ๊ะ"   ================================== NOTE: จุดสำคัญตรงนี้คือ   R5 จะต้องมีการส่ง ARP request สำหรับ ICMP request packet ที่มี destination 10.1.1.1 และ 20.1.1.1 ถึงสองครั้ง และก็ได้ ARP reply ประมาณว่า   "10.1.1.1 map กับ cc04.0c40.0000 นะจ๊ะ"  --> สำหรับ ARP request 10.1.1.1   "20.1.1.1 map กับ cc04.0c40.0000 นะจ๊ะ" --> สำหรับ ARP request 20.1.1.1   ซึ่งจะเห็นได้ว่า MAC address ของ ARP reply ทั้งสองครั้งจะเป็น MAC address เบอร์เดียวกัน ซึ่งเป็น MAC address ของ Fa0/0 บน R2   ซึ่งถ้าเทียบกับการ configure static route ที่ใช้ option next hop แล้ว จะเป็นการส่ง ARP request เพียงแค่ครั้งเดียวสำหรับ next hop หรือ Gateway ที่เป็นเบอร์ 11.1.1.2 (เบอร์เดียวกันสำหรับทุกๆ routes)   ==================================   Step 13: เมื่อ R5 ได้รับ ARP reply จาก R2 แล้ว R5 จะทำการ บันทึก/จัดเก็บ การ mapping ระหว่าง  20.1.1.1 กับ cc04.0c40.0000 ไว้ใน ARP table ของมัน เพื่อไว้ใช้ในครั้งถัดไป   Step 14: จากนั้น R5 จึงนำ ICMP request packet ที่มี destination 20.1.1.1 ที่ได้หยุดไว้ชั่วคราว มาทำการ forward ออกไปยัง R2 ที่มี destination MAC address เป็น cc04.0c40.0000   Step 15: R5 ping ไปยัง 30.1.1.1 ซึ่งอยู่ใน subnet 30.1.1.0/24 และเหตุการณ์ก็จะดำเนินเหมือนๆ กันตอน ping ไปยัง 10.1.1.1 และ 20.1.1.1     ========================================= ซึ่งจากตรงนี้ก็จะเห็นแล้วว่า Router R5 จะต้องใช้ CPU ในการ process destination IP address ทั้งหมด เพื่อทำการ mapping Layer 2 address (MAC address) กับ Layer 3 address (IP address) ผ่าน ARP protocol และจะต้องมีรายการ (entries) มากมายใน ARP table ท้ายสุด การจัดสรร memory ก็จะ failure ลงไป เพราะ memory เต็ม โดยเฉพาะ การ configure default routes แบบ outgoing interface (เช่น ip route 0.0.0.0 0.0.0.0 FastEthernet0/0) ระวังให้ดี ในกรณีของ Default Route แล้ว ห้าม configure default route ด้วย option outgoing interface เพียง option เดียวโดยเด็ดขาด หากจะใช้ option outgoing interface แล้ว ควรจะใส่ option next hop เข้าไปด้วย (configure คู่กันระหว่าง outgoing interface กับ next hop)           คำถามต่อมา แล้วเมื่อไหร่จึงควรใช้ outgoing interface ล่ะ  คำตอบคือ ควรใช้ outgoing interface กับ interface ที่เป็น Layer 2 protocol ประเภท Point-to-Point อย่างเช่น Serial Interface ที่ encapsulation เป็น HDLC หรือ PPP นั่นเอง   Best Practice หรือแนวทางปฏิบัติที่ดีที่สุด ในการ configure static route ผมขอเสนอให้ทำการระบุทั้ง outgoing interface และ next hop IP address คู่กันดังตัวอย่าง configuration ข้างล่างนะครับเพราะมันจะทำให้ประสิทธิภาพโดยรวมของการ forwarding ดีขึ้นคือ Router มันจะลดกระบวนการการทำ recursive lookup เพราะมันสามารถที่จะรู้ได้อย่างทันทีจากconfiguration ว่า next hop IP address ต้องส่งออกทาง interface ไหน ip route 0.0.0.00.0.0.0  11.1.1.2  FastEthernet0/0 หวังว่าจะมีประโยชน์กับพี่ๆ น้องๆ นะครับ 18/06/2017 - 23.50: ขอขอบคุณน้อง Mine (Makara Sakolvaree) ที่พบจุดบกพร่องบางจุดในบทความ และแนะนำมานะครับ  ปล. สิ่งที่ผมกลัวมากๆ คือ การถ่ายทอดความรู้ที่ผิดให้กับพี่ๆ น้องๆ ดังนั้น หากท่านพบจุดผิด หรือจุดบกพร่องในบทความแล้ว ท่านสามารถเสนอความคิดเห็น หรือ Inbox มาได้นะครับ ผมยินดีรับฟัง และพร้อมจะปรับปรุงจุดที่ผิดครับ  Facebook: Chaiwat Amornhirunwong    ขอบคุณครับ โก้-ชัยวัฒน์ (KoChiawat)     Create Date : 31 มีนาคม 2558     8 comment Last Update : 16 มิถุนายน 2565 9:44:50 น.     Counter : 18882 Pageviews.   Share Tweet

Timeout และ Destination Host Unreachable บน Cisco Router ผมได้ไปตอบคำถามใน Fan Page: CCNA Hunter Group และคิดว่าน่าจะเป็นประโยชน์กับหลายๆ ท่านครับ ก่อนอื่นขอแจ้งไว้ก่อนนะครับว่า คำอธิบายนี้เป็นกรณีที่เราไม่มี Firewall หรือ ACL นะครับ แต่ถ้ามี ก็ต้องพิจารณาด้วยนะครับ ผลการ ping บน router เป็น: 1. Unreachable หรือ "u.u.u.u" หมายถึง router ตัวนี้ได้ส่ง "ICMP echo request" ออกไปแล้ว และได้รับการตอบกลับจากอุปกรณ์ network ตรงกลางว่า "destination host unreachable" หรือ "ฉันไม่สามารถ forward "ICMP echo request" ของนายไปยังปลายทางได้นะจ๊ะ เพราะฉันไม่มี route ไปยัง destination จ้า" ซึ่งอุปกรณ์ network ตรงกลางที่เป็นคน reply "ICMP destination host unreachable" messages นี้ จะเป็นอุปกรณ์ตัวสุดท้ายที่เรา traceroute เจอ โดยอุปกรณ์ network ตรงกลางตัวนี้มันจะทำการ drop "ICMP echo request" messages ทิ้งไปก่อน แล้วจึงตอบกลับด้วย "ICMP destination unreachable" message กลับไปยัง source ดังนั้นในกรณีที่เรา ping แล้วได้รับ u.u.u.u หรือ UUUUU (ในกรณีที่ ping โดย router) หรือได้รับ "Reply from x.x.x.x: destination host unreachable" เมื่อ x.x.x.x คือ IP address บนอุปกรณ์ network ที่อยู่ตรงกลาง (ในกรณีที่ ping โดย MS-Windows) แล้ว ให้เราลอง traceroute ไปยัง destination IP address นั้นๆ อีกครั้งหนึ่ง แล้วสังเกต IP address เบอร์สุดท้ายจากผลการ traceroute ว่าเป็น IP address เบอร์อะไร จากนั้นให้ telnet เข้าไปยัง IP address นั้น แล้วลอง show ip route เพื่อแสดง routing table ของอุปกรณ์นั้นๆ ดู ก็จะพบว่าอุปกรณ์ตัวนั้นๆ ไม่มี route ไปยัง destination ปลายทาง ก็อาจจะเป็นเรื่องของ link failure หรือเรื่องของ routing ที่ configure ไม่สมบูรณ์ ก็ให้แก้ซะ 2. Timeoute หรือ "...." หมายถึง router ตัวนี้ได้ส่ง "ICMP echo request" massages ออกไปแล้ว และรอการตอบกลับจากปลายทาง แต่ไม่ได้รับการตอบกลับอะไรมาทั้งสิ้น เมื่อถึงระยะเวลาหนึ่งที่เครื่อง หรือ OS ได้ตั้งค่าเอาไว้ (ช่วงเวลา timeout) แล้ว มันก็จะแสดง output ออกมาให้เราเห็นเป็น .... เพื่อแสดงให้ admin อย่างเราๆ ทราบว่า "ฉันไม่ได้รับการตอบกลับใดๆ นะจ๊ะ" ซึ่งความเป็นไปได้มีดังนี้ คือ 2.1 มีความเป็นไปได้ "ICMP echo request" messages ได้เดินทางไปจนถึงอุปกรณ์ปลายทาง หรือเป้าหมายแล้ว แต่เป้าหมายไม่ได้ส่ง "ICMP echco reply" message กลับ เพราะตัวมันเองดันไม่ได้ set default gateway หรือ ถ้าอุปกรณ์ปลายทางนั้นๆ มีการ set default gateway แล้ว และตอบกลับ "ICMP echo reply" messages แล้ว แต่ router ระหว่างทางดันไม่มี route หรือ "ไม่รู้ว่าจะ forward "ICMP echo reply" messages กลับไปยัง source ได้อย่างไร" จึงทำให้ "ICMP echo reply" messages นี้โดน drop ทิ้งระหว่างทาง และต้นทางก็รอเก้อจนต้องตะโกนบอก admin ออกมาว่า timeout 2.2 หรือ มีความเป็นไปได้ว่า "ICMP echo request" messages ได้ถูกส่งออกไปแล้ว แต่อุปกรณ์ network ระหว่างทางดันไม่มี route ไปยัง destination network จึงทำการ drop "ICMP echo request" messages ทิ้งไป และพยายามที่จะตอบกลับไปยังต้นทางด้วย "ICMP destination host unreachable" messages แต่ปัญหาอาจจะอยู่ที่อุปกรณ์ network ตัวนี้ดันไม่มี route กลับไปยัง source อีกด้วย (ไม่มี route ไปยัง ทั้ง destination และ source) หรืออาจจะเป็นไปได้ว่า router ตัวนี้ เป็น router ที่ไม่มี route ไปยัง destination network นั้นๆ แต่มันมี route กลับไปยัง source ดังนั้นหลังจากที่มัน drop "ICMP echo request" messages แล้ว มันจะตอบกลับไปยัง source ด้วย "ICMP destination host unreachable" messages แต่ในระหว่างทางที่มีการ forward "ICMP destination host unreachable" messages กลับไปยัง source นั้น ได้มี router ระหว่างทางที่อยู่ในเส้นทางการของ forward "ICMP destination host unreachable" messages กลับไปยัง source นั้น ดันไม่มี route กลับไปยัง source หรือ "ไม่รู้ว่าจะ forward "ICMP destination host unreachable" messages กลับไปยัง source ได้อย่างไร" จึงทำให้ "ICMP destination host unreachable" messages ถูก drop ทิ้งระหว่างทาง และต้นทางก็รอเก้อจนเกินเวลา time out ที่กำหนด จนต้องตะโกนบอก admin ออกมาว่า timeout นะจ๊ะ ปัญหายังอาจจะมีอย่างอื่นอีกก็ได้นะครับ แต่หลักๆ แล้วก็มีประมาณนี้นะครับ เชื่อว่าน่าจะเป็นประโยชน์กับหลายๆ ท่านครับ ขอบคุณครับ โก้-ชัยวัฒน์   Create Date : 28 มีนาคม 2558     5 comment Last Update : 2 กุมภาพันธ์ 2559 16:38:50 น.     Counter : 20863 Pageviews.   Share Tweet

Gateway of last resort ใน routing table ของ Cisco router คืออะไร "Gateway of Last Resort" ใน routing table ของ Cisco router คืออะไร และสัมพันธ์กับ default route "ip route 0.0.0.0 0.0.0.0" อย่างไร Resort = แหล่งพึ่งพิง ดังนั้น Last Resort ก็หมายถึง แหล่งพึ่งพิงสุดท้าย เวลาเรา show routing table ด้วย command "show ip route" ใน Cisco router เราจะพบคำว่า "Gateway of Last Resort" เคยสงสัยมั๊ยว่ามันคืออะไร ซึ่งมันจะเกี่ยวกับหลักการ forwarding IP packet ดังนี้ Router เมื่อได้รับ IP packet เข้ามา มันจะพิจารณา destination IP address ใน IP header แล้วนำไปเทียบกับรายการ (entries) ใน routing table ด้วยหลักการ longest match คือ entries ไหน หรือ รายการไหนใน routing table มี bit ที่ match กับ destination IP address มากที่สุด entries นั้นจะถูกเลือกใช้ แล้ว packet จะถูก forward ไปตาม next-hop หรือ outgoing interface ของ entries นั้นๆ (พิจารณาจาก Major Network เป็นหลัก แล้วย่อยลงมาหา subnet ที่ match ที่สุด)  แต่หากไม่พบ entries ไหนเลยที่ match แล้ว packet จะถูก drop ทิ้ง (ไม่ flood เหมือน switch นะครับ เพราะ router เกิดมาเพื่อกั้น broadcast domain) ในกรณีที่ router ตัวนี้ต่ออยู่กับ Internet แล้ว ใน routing table จะมี routing (subnet) ของบริษัทอยู่ครบ แต่จะไม่มี routing (subnet) ของ Internet (ในกรณี router รุ่นไม่ได้ใหญ่มาก) ดังนั้นหาก router ตัวนี้ได้รับ IP packet ที่มี destination เป็น IP address ที่อยู่ใน Internet แล้ว router ตัวนี้ก็จะ drop IP packet นั้นทิ้งไป  เหตุผลว่าทำไม router ตัวนี้จึงไม่มี routing (subnet) ของ Internet คำตอบคือ เพราะ router ตัวนี้เป็นรุ่นเล็ก มี resource เช่น CPU ต่ำ และ Memory ที่น้อย หาก router ตัวนี้ต้องบรรจุ Internet route ที่มีขนาด 500,000 routes แล้ว router ถึงตายได้ ผมจะเรียกเหตุการณ์นี้ว่า "ลูกหมาลากซุง" คือเอาลูกหมามาทำงานช้าง ดังนั้นวิธีที่จะทำให้ router ตัวนี้สามารถ forward IP packet ที่มี destination IP address เป็น Internet address ได้นั้น เราจะต้องใส่ default route ให้กับมัน ด้วย command "ip route 0.0.0.0 0.0.0.0 x.x.x.x" เมื่อ x.x.x.x คือ IP address ขา WAN ของ ISP หลังจากที่ configure command นี้ให้กับ router แล้ว address 0.0.0.0/0 นี้จะไปปรากฎอยู่ใน routing table (จากการใช้ command "show ip route") ดังนี้ S*   0.0.0.0/0 [1/0] via x.x.x.x  ( * คือ candidate default หรือ แสดงให้เราทราบว่า route นี้เป็น default route นะ) และที่ตำแหน่ง "Gateway of last resort" จะขึ้นประมาณนี้ Gateway of last resort is x.x.x.x to network 0.0.0.0 เมื่อ x.x.x.x คือ IP address ของ ISP นั่นก็คือ จากนี้ไป หาก IP packet ที่มี destination IP address ที่ไม่ match ใน routing table มันจะไม่ถูก drop อีกแล้ว เพราะมันมี "แหล่งพึ่งพิงสุดท้าย" แล้ว นั่นก็คือ packet นี้จะถูก forward ไปยัง ISP ที่ IP address x.x.x.x นี้แทน ยังมีอีกหลายเรื่องที่อยากจะแบ่งปัน และเชื่อว่าหลายๆ คนคงอยากรู้: - Command "ip default-gateway" คืออะไร? - Command "ip default-network" คืออะไร? - Command "ip route 0.0.0.0 0.0.0.0" ต่างจาก "default-gateway" กับ "default-network" อย่างไร? โดยเฉพาะ Command "ip default-network" ซึ่ง command นี้เป็น command ที่เข้าใจได้ยาก กว่าที่ผมจะเข้าใจก็ศึกษาอยู่ 3 ปี ปีละ 1 นาที ล้อเล่งอ่ะ ^^" อย่างไรก็ตาม จะพยายามหาเวลามาแชร์ให้นะครับ และหวังว่าข้อมูลนี้จะมีประโยชน์กับทุกๆ ท่าน KoChaiwat (โก้-ชัยวัฒน์)   Create Date : 26 มีนาคม 2558     3 comment Last Update : 30 มีนาคม 2558 12:23:35 น.     Counter : 8818 Pageviews.   Share Tweet