IS-IS - Intermediate System to Intermediate System
  • Vote Up0Vote Down plawansaiplawansai
    • IS-IS เหมาะสำหรับ เครือข่ายขนาดใหญ่ อย่างพวก Service Provider

    • ข้อแตกต่างระหว่าง OSPF และ IS-IS:
      www2.thaiadmin.org/board/index.php?topic=37492



    • In OSI Terminology, a router = an intermediate system (IS). A router is a member of only 1 Area.

    • IS-IS was the routing protocol created for OSI:
      • OSPF = TCP/IP
      • IS-IS = OSI

    • Requires an OSI Address, called a ConnectionLess Network Services (CLNS) address, to function.

    • Uses SPF.

    • More Tunable, Efficient, and Flexible than OSPF

    • L1: member of only 1 area
      L2: backbone router. They know the backbone but not their own area. It represents the Core Network.
      L1/L2: member of an area and of the backbone. They summarize route of their own area to the backbone.
      An L1 router contacts an L2 router to go to another area.

    Cr: www.nemako.net/dc2/?post/ISIS

    • Configuring Integrated IS-IS, IS-IS Configuration Task List, Enable IS-IS, Configure IS-IS Interface Parameters, Miscellaneous IS-IS
      www.cisco.com/en/US/docs/ios/11_3/np1/configuration/guide/1cisis.html

    • Network entity title (NET), NSAP Address:
      www.ciscoclub.in.th/index.php?topic=961

    IS-IS Terminology
    http://sites.google.com/site/amitsciscozone/home/is-is/is-is-termin


    Configuration
    • [li]interface mtu ต้องเท่ากัน[/li]
      [li]clns mtu ต้องเท่ากัน[/li]

    key chain Area1 -> Key-Chain Name = Area1
    key 1 -> Key-ID "1"
      key-string cisco123 -> Password = cisco123
    !
    interface TenGigabitEthernet1/1
    ip router isis
    isis authentication mode md5 -> Authentication Mode = Message Digest
    isis authentication key-chain Area1 -> Authentication = Hello Packet Authentication
    !
    router isis
    net 49.0001.0000.0000.0011.00
    is-type level-2-only -> IS-Type = Level 2 Only
    metric-style wide -> Metric Style = Wide
    passive-interface Loopback0
    !

    Troubleshoot:

    • %CLNS-5-ADJCHANGE: ISIS: Adjacency to xxx (GigabitEthernet1/1/2) Down, neighbor forgot us: Configure "isis network point-to-point" แล้วสามารถแก้ปัญหาได้

    • %CLNS-4-AUTH_FAIL: ISIS: Serial IIH authentication failed: ตรวจสอบขาที่ isis neighbor ไม่ up ใส่ authentication ให้ถูกต้อง

      R1#deb isi adj
      061163: Oct  5 16:34:05.565 bkk: ISIS-Adj: Rec serial IIH from 4562.882a.4b5a (TenGigabitEthernet1/3), cir type L2, cir id 00, length 1496
      061164: Oct  5 16:34:05.565 bkk: ISIS-Adj: Authentication failed
      or
      061228: Oct  5 16:34:14.649 bkk: ISIS-Adj: Rec serial IIH from 4562.882a.4b5a (TenGigabitEthernet1/3), cir type L2, cir id 00, length 1496
      061229: Oct  5 16:34:14.649 bkk: %CLNS-4-AUTH_FAIL: ISIS: Serial IIH authentication failed

      R1#un all

      R1#sho isis neighbor | inc 1/3
      R1#

      Compare isis interface configuration both side. If the configuration is corrected, re-configure int te1/3.
      Cr: P'Teng@AIT

    • Init State:

      • XR# debug isis adjacencies interface x
        RP/0/RSP0/CPU0:Oct 11 11:28:12.170 BKK: isis[1014]: SEND P2P IIH (L2) on Bundle-Ether9: Holdtime 30s, Length 9199
        RP/0/RSP0/CPU0:Oct 11 11:28:12.357 BKK: isis[1014]: RECV P2P IIH (L2) from Bundle-Ether9 SNPA 40ce.2418.9b52: System ID PN2, Holdtime 30, length 9198

      • Nokia# debug router isis packet ptop-hello "Interface-Name"
        configure log log-id 1 from debug-trace
        configure log log-id 1 to session
        * ptop-hello = p2p link - hello packet

    การออกแบบ Network Topology และ IGP Area เปรียบเทียบ IS-IS กับ OSPF:

    เท่าที่เห็นมาเป็นเรื่องปกติ ที่ไม่ปกติ คือ การคิด Network Topology และการเลือกอุปกรณ์ที่จะใช้ในแต่ละตำแหน่ง ก็ไปทางหนึ่ง จบแล้วจะเลือกใช้ IGP เป็น Protocol OSPF หรือ IS-IS ก็จัดไปตามใจชอบ แล้วผลมันก็ออกมาแบบชุลมุนวุ่นวายเสียด้วย

    ถ้าเลือกจะใช้ OSPF แล้ว มักไม่ค่อยมีปัญหาว่าจะจัด Topology ยังไง แต่ถ้าเลือกใช้ IS-IS ควรจะต้องกลับไปคิดใหม่ว่าจะจัดยังไงให้มันไม่ยุ่ง หลักๆ ก็จะต้องไปเกี่ยวกับเรื่อง Area ID และการแบ่ง Instance (Process)

    ตัวอย่างที่ 1 เป็นรูปแบบที่เหมาะสมสำหรับ IS-IS คือ Area ที่ทำ L1 Adjacency ต่าง Area กันไม่มาชนกัน แยกขาดกันโดยสิ้นเชิง (มีกรอบสีเขียวให้เห็นว่าจะ Apply ใช้ในชีวิตจริงอย่างไร)

    สิ่งที่ต้องคำนึงคือ:
    1. ความสามารถของอุปกรณ์แต่ละตัวรองรับจำนวน Router, จำนวน Tunnel, จำนวน Service ได้เท่าไหร่
    2. การแบ่งพื้นที่ตามภูมิศาสตร์ และ Commercial Opportunity

    สองปัจจัยนี้ต้องเอามา Balance กันให้ดี จึงจะได้ Network ที่ราคาถูก ตอบโจทย์ได้ดี และ Operate ง่าย ยิ่งถ้างบจำกัด ไม่สามารถเลือกซื้ออุปกรณ์ที่มี Performance สูงๆ ได้เยอะ ก็ยิ่งต้องคิดเยอะๆ

    แต่การออกแบบแบบนี้ พบเห็นได้เฉพาะในตำรา ในชีวิตจริงไม่เคยเห็นเลย คือ คนจำนวนมากคิดว่าอยากใช้ IS-IS แต่แนวคิดในการวาง Topology ไม่ได้รับเอารูปแบบที่เหมาะกับ IS-IS เข้ามาใช้เลย
    imageจากตัวอย่างแรก ปรับเปลี่ยนมาเป็นอีกแบบ คือให้ Area ที่ทำ L1 Adjacency กัน มา Share L1/L2 Router ตัวเดียวกัน อันนี้เจอตลอดๆ ซึ่งมันก็นำมาซึ่งปัญหาคือ จะต้องแยก Instance (หรือบาง Vendor เรียก Process) ไม่งั้น 2 Area (จากตัวอย่าง) จะมี Link State ไหลถึงกันเสมือนเป็น Area เดียวกัน

    Area ID ของ IS-IS ใช้เพื่อควบคุมการสร้าง Adjacency เท่านั้น แต่ไม่ได้ควบคุมไม่ให้ Link State ไหลข้ามกัน การทำให้ L1/L2 Router สามารถเชื่อมต่อกับทั้งสอง Area ได้ ก็จะต้องใส่ Area ID ลงไปทั้งสอง Area ซึ่ง IS-IS ของ Router ต่างๆ ส่วนใหญ่น่าจะใส่ได้ถึง 3 Area
    image
    พอการออกแบบมาเป็นแบบรูปที่สองแล้ว ก็เลี่ยงไม่ได้ที่จะต้องทำการแบ่งแยก Instance ปัญหาของการแบ่งแยก Instance คือ:
    1. ต้องทำ Redistribute (Import/Export) เพื่อให้ Route แลกเปลี่ยนข้าม Instance เพื่อให้ Route Traffic ข้ามกันได้ เป็นความยุ่งยากที่เพิ่มมาขั้นที่ 1

    2. กลไกการป้องกัน Loop ของ Protocol ต่างๆ ทำงานได้เฉพาะภายใน Domain หรือ Instance เดียวกันเท่านั้น ถ้าข้าม Domain หรือข้าม Instance กลไกนั้นก็ไม่สามารถครอบคลุมถึงได้ ผลก็คือ ถ้าทำ Redistribute อย่างไม่รัดกุมก็จะเกิด Loop ได้

    ปัญหามันก็คงจะไม่เท่าไหร่ ถ้าทำ Policy ไม่เหมาะสมแล้ว มัน Loop ให้เห็นทันที ปัญหาประเภทที่พบเห็นได้ทันทีนี้จะถูกพบและปรับปรุงได้ตั้งแต่ตอนออกแบบ แต่ส่วนใหญ่แล้ว Network ที่ถูก Deploy ไปมีความเสี่ยงที่จะเกิด Loop เมื่อมีปัจจัยมากกว่า 1 อย่างมาบรรจบกัน แล้ว Network ก็เละเป็น KoKoKrunch คนที่จะออกแบบ Network แบบนี้แล้วรอด จะต้องมี Awareness เรื่องของ Routing Loop เป็นอย่างดี และออกแบบ Route Policy ที่รัดกุม อย่างน้อยก็ตาม Best Practice
    Cr:P'Pae@Nokia B-)
  • 1 Comment sorted by
  • Vote Up0Vote Down plawansaiplawansai
    ข้อแนะนำสำหรับการออกแบบ Network ครั้งต่อไป:

    1. ถ้ารักจะใช้ IS-IS โปรดคิดแบบ IS-IS ในการออกแบบ Topology และ Make Sure ว่าเบื้องบนจะให้งบประมาณเพียงพอที่จะใส่ Router ที่มี Spec ตามเกณฑ์ที่จำเป็น สำหรับ Topology ดังกล่าว

    2. ถ้ามีข้อจำกัดด้านงบประมาณหรือ Spec อุปกรณ์แล้ว ผลมันจะต้องออกมาตามแบบรูปที่ 2 (มี Router ตัวใหญ่ได้ไม่กี่ตัว เลยต้องเอาตัวเล็กๆ หลายๆ Area เล็กๆ ไปเกาะรวมกันที่ตัวใหญ่ตัวเดียวกัน จะทำ Area ใหญ่ก็ไม่ได้ เพราะจะเกิน Scaling Limit ของตัวเล็ก) จะต้องคิดเรื่อง Redistribute Policy ให้รอบคอบ และต้องแน่ใจว่าทีมงานที่เกี่ยวข้องทั้งหมดมีความเข้าใจ และระมัดระวังเป็นอย่างดี เวลาติดตั้ง Router และ Link เพิ่มเติม มันก็เคยมีเหตุมาแล้วที่ Router ที่ติดตั้งใหม่ Configure ผิดไปจากที่ออกแบบไว้แล้วทำให้ Network IS-IS L1 รวมเป็นเนื้อเดียวกัน ทำให้เกิดผลที่ไม่คาดคิด Service ระหว่าง Area คู่นั้นล่มไปเลย

    3. ลองคิดดูว่า OSPF ตอบโจทย์หรือเปล่า?

    ถ้าห่วงเรื่อง Scalabiltiy ก็ Check กับ Spec ของ Vendor ดู อย่างของ Nokia จะมี Scaling Guide ซึ่งโดยปกติแล้วจะคิดแบบ Conservative แต่ผู้ใช้ก็ต้องตีความให้ถูกต้องด้วย

    เรื่อง Scalability ของ IS-IS บางคนก็เหมาเอาว่าพอเป็น IS-IS แล้วจะ Stable หรือ Scale ได้ดีกว่า OSPF แต่ก็ไม่เสมอไป ถ้าไม่รู้ว่าอะไรที่ทำให้มัน Scalable และปรับแต่งสิ่งเหล่านั้นอย่างเหมาะสม รวมถึงบางเรื่องก็ขึ้นอยู่กับการ Implement ของ Vendor อีกด้วย

    ในกรณีที่มีจำนวน Link State PDU (LSP) มากๆ สามารถปรับค่า Refresh Timer ให้นานขึ้นได้ แต่ OSPF จะเป็นค่าตายตัว (ไม่แน่ใจว่ามีการ Implement ของ OSPF ที่ปรับได้หรือยัง) ตรงนี้ก็จะช่วยลดภาระของ Router ได้ ถ้า Router ไม่เยอะ หรือเยอะแต่ไม่ปรับแต่ง ปล่อยเป็นค่า Default ก็ไม่ได้ช่วย

    และเคยเจอการ Implement ของ OS ของ Router บางตัว ที่มีการนำ Route มาจัดเรียงกันก่อน Pack ลงใน LSP จะมีปัญหาในกรณีที่ Router ตัวนั้นมีจำนวนข้อมูลเยอะ (เช่น Interface, มีการทำ TE, มีจำนวน Route ที่ Redistribute เยอะ) ก็จะมีหลาย LSP แล้วถ้า Route ที่มาใหม่ถูกเรียงแล้วอยู่ใน LSP แรก ข้อมูลที่เคยจัดอยู่ในหลายๆ LSP ก็จะต้องถูกดันให้ขยับออกไปทั้งขบวน ผลก็คือต้องส่ง Link State Update ออกไปทุกๆ LSP แทนที่จะส่งแค่ LSP เดียว อันนี้ก็ไม่เป็นผลดีต่อ Scalability และการที่ข้อมูล Route บาง Route จะต้องย้ายจากที่เคยอยู่บน LSP หนึ่ง ไปอยู่บนอีก LSP หนึ่ง ก็อาจส่งผลให้ Route นั้น Flap ได้ ซึ่งเป็นไปตามที่เขียนไว้ในมาตรฐานของโปรโตคอล IS-IS การป้องกัน Route Flap ในกรณีนี้ก็มีการกำหนดวิธีการไว้เหมือนกัน ทั้งการป้องกันโดยไม่ให้ Route จะต้องถูกโยกย้ายจาก LSP หนึ่งไป LSP อื่น หรือถ้าจะต้องถูกโยกย้ายแล้วจะต้องทำอย่างไรไม่ให้ Route Flap แต่ก็เคยเจอกรณีที่ Route Flap จากการนี้ ก็ไม่รู้ว่าฝั่งไหน Implement อะไรไม่ครบ

    ปล. ข้อแนะนำที่ว่าใน 1 Area ควรมี Router ไม่เกิน 50-100 ตัว หรืออะไรทำนองนั้นมันตกยุคไปแล้ว

    ข้อแนะนำที่ยังไงก็ไม่ผิด ก็คือแนวๆ พวก ดูจาก Topology, CPU Performance ของ Router อะไรพวกนี้ (ถ้าเป็น MPLS Router หรือพวก Switch, Performance ของ Control Plane กับ Data Plane ก็คนละเรื่องกัน ที่ Forward Traffic Rate สูงๆ ก็ไม่ได้แปลว่า CPU จะแรงกว่าเสมอไป)

    นอกจากนี้ก็อยู่ที่การปรับแต่ง Timer ต่างๆ ที่จะ Trade-off ระหว่างความรวดเร็วในการ Update กับความสามารถในการรองรับจำนวน Router หรือ Route ได้มากๆ, การทำ Route Summarization, การ Filter Route หรือเลือก Advertise เท่าที่จำเป็นก็ช่วยเพิ่ม Scalability ของ Network
    Cr:P'Pae@Nokia B-)
Add a Comment