NETCONF คืออะไร?

What is NETCONF?

— — — — — — — — — — — — — — —
สารบัญเนื้อหาทั้งหมด (My Contents)
— — — — — — — — — — — — — — —

NETCONF คือ network management protocol ที่ถูกพัฒนาและกำหนดขึ้นมาเป็นมาตรฐานโดย IETF ตั้งแต่ปี 2006 เพื่อมาแทนที่ SNMP สำหรับใช้ในการติดตั้ง, จัดการ หรือลบ configuration รวมถึงใช้ในการ monitor อุปกรณ์ network

แต่ถ้าพูดให้ชัดเจนกว่านั้นก็ต้องบอกว่า NETCONF เป็นเพียง transport protocol ที่ใช้ในการรับส่ง payload ระหว่าง NETCONF client และ NETCONF server เพื่อทำเรื่อง configuring และ monitoring โดยเฉพาะ

รูปแสดงการทำงานร่วมกันของ Protocol ต่าง ๆ ใน NETCONF

โดย NETCONF นั้นทำงานอยู่บน Remote Procedure Call (RPC) ซึ่งใช้ XML เป็น data format ในการรับส่งข้อมูลไปยังอุปกรณ์ผ่านทาง SSH port 830 (by default)

— — — — — — — — — — — — — — — — — — — — — — — -

ฝากคอร์ส Python for Network Automation ผมด้วยครับ

คอร์ส Python for Network Automation (3 วัน)

— — — — — — — — — — — — — — — — — — — — — — — -

หลัก ๆ แล้วการเกิดมาของ NETCONF ก็เพื่อจะมาแทนที่การใช้ CLI (Command Line Interface)ในการทำเรื่อง configuring และ monitoring โดยมีจุดประสงค์เพื่อให้การทำ network automation นั้นง่ายมากขึ้น แต่กระนั้นเองด้วย NETCONF เพียงตัวเดียวก็ยังไม่สมบูรณ์นัก(เพราะมันทำแค่ในส่วน transport เท่านั้น) จนกระทั่งปี 2010 ที่ YANG ได้ถูกพัฒนาและปล่อยออกมา ทั้งสองตัวจึงถูกนำมาใช้งานร่วมกัน

บทบาทหน้าที่และการรับส่งข้อมูลของ NETCONF

ก่อนที่จะไปทำความเข้าใจเกี่ยวกับการรับส่งข้อมูลของ NETCONF นั้น เราจะต้องรู้จักกับบทบาทหน้าที่ของอุปกรณ์ในมุมของ NETCONF ก่อนดังนี้

1. NETCONF Client เราจะเรียกว่า network manager ซึ่งอาจเป็น NMS หรือคอมพิวเตอร์ของเราที่ต้องการจะ configure หรือ monitor อุปกรณ์
2. NETCONF Server โดยทั่วไปก็คืออุปกรณ์ network ที่ทำการเปิดใช้ NETCONF เอาไว้บนตัวมันเพื่อรอรับการ configure หรือ monitor

ซึ่ง NETCONF client จะทำหน้าที่ในการส่ง set of operations ไปยัง NETCONF server เพื่อทำการ configure หรือ monitor อุปกรณ์ network

สำหรับการรับส่งข้อมูลของ NETCONF นั้นจะต้องใช้ YANG มาร่วมด้วยเพื่อให้ NETCONF client รู้ว่าจะต้องรับส่งข้อมูลเหล่านั้นในรูปแบบใดเพื่อให้สามารถ configure หรือ monitor อุปกรณ์ network ตัวดังกล่าวได้ (ตอนส่งจะต้องส่งข้อมูลไปยังไง และตอนรับมาจะต้องอ่านแบบไหน)

ซึ่ง network vendor เป็นผู้มีหน้าที่ในการกำหนด data model สำหรับอุปกรณ์ของตัวเองด้วยการใช้ YANG เขียนมันขึ้นมา และจะปล่อย YANG model เหล่านั้นให้กับพวกเราเพื่อนำมาใช้งานต่ออีกทีหนึ่ง (ใช้ร่วมกับ NETCONF หรือ RESTCONF ก็ได้)

NETCONF Datastore

เชื่อว่า network engineer ทุกคนน่าจะคุ้นเคยกับ running configuration และ startup configuration อยู่แล้วใช่มั้ยครับ ทีนี้ในมุมของ NETCONF เองก็ได้มีการแบ่ง configuration ออกเป็น datastore หลาย ๆ ชนิดเช่นกัน ได้แก่

1. Running ใช้สำหรับเก็บ configuration ปัจจุบันที่อุปกรณ์กำลังใช้งานอยู่
2. Startup ใช้สำหรับเก็บ configuration ซึ่งถูกบันทึกเอาไว้ และจะถูกเรียกใช้งานเมื่ออุปกรณ์ถูก power on ขึ้นมา (กลายเป็น running configuration)
3. Candidate ใช้สำหรับเก็บ configuration ที่ยังไม่ได้ถูก implement ลงในอุปกรณ์โดยทันที แต่จะต้องมีการ commit ก่อนเพื่อเป็นการยืนยัน อุปกรณ์จึงจะทำการเขียน candidate configuration ไปยัง running configuration

NETCONF Message กับ RPC (Remote Procedure Call)

NETCONF จะใช้ RPC เพื่อช่วยในการส่ง message ระหว่าง client ไปยัง server สำหรับ request เพื่อร้องขอ execute operation ต่าง ๆ และกลับกันทางฝั่ง server เมื่อทำการ execute เสร็จเรียบร้อยก็จะตอบกลับผลมาด้วย rpc-reply นั่นเอง

ตัวอย่างของ Request Message จาก NETCONF Client

<rpc message-id="101">
     <!-- rest of request as XML... -->
</rpc>

ตัวอย่างของ Reply Message จาก NETCONF Server

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
   <data>
     <!-- XML content/response... -->
   </data>
 </rpc-reply>

NETCONF Operations

1. <hello> ถูกใช้เพื่อส่ง hello message ระหว่าง NETCONF client และ NETCONF server เพื่อแลกเปลี่ยนข้อมูลเกี่ยวกับ capability กันว่าใครทำอะไรได้บ้าง โดยสิ่งที่แลกเปลี่ยนกันก็คือ list ของ YANG model นั่นเอง
2. <get> ใช้สำหรับดึงค่า operational state ต่าง ๆ จากอุปกรณ์ เช่น packet in, packet out, packet error จาก interface หรืออื่น ๆ อะไรทำนองนี้ โดยสามารถเขียน filter เป็น subtree หรือ XPath เข้าไปใน payload เพื่อเลือกดึงเฉพาะข้อมูลที่เราต้องการได้
3. <get-config> ใช้สำหรับดึง configuration ของอุปกรณ์ และสามารถใช้ filter เพื่อเลือกดึง configuration เฉพาะบางส่วนได้เหมือนกับ <get>
4. <copy-config> ใช้สำหรับ copy configuration จาก datastore หนึ่งไปยังอีก datastore หนึ่ง
5. <delete-config> ใช้สำหรับลบ configuration ใน datastore ที่กำหนด
6. <commit> ใช้สำหรับ commit เพื่อเปลี่ยน candidate configuration ให้เป็น running configuration
7. <validate> ใช้สำหรับตรวจสอบ configuration ใน datastore ที่กำหนดก่อนที่จะ apply ไปยังอุปกรณ์

ที่จริง NETCONF operations ยังมีอีกประมาณนึงเลยแต่ผมไม่ได้เขียนซึ่งไม่ได้สำคัญอะไรสำหรับการใช้งานเบื้องต้น และบางตัวก็ไม่ได้ support กับทุกอุปกรณ์ด้วย เช่น <commit> และ <validate>

ตัวอย่างของ Get Message ที่ถูกส่งจาก NETCONF Client

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <get>
    <!-- XML content/response... -->
  </get>
</rpc>

ตัวอย่างของ Get Message ที่มีการใช้ Filter ร่วมด้วย

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <get>
      <filter>
        <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
         <interface>
          <name>GigabitEthernet1</name>
         </interface>
        </interfaces>
      </filter>
  </get>
</rpc>

ตัวอย่างของ Edit Config Message ในการสร้าง Loopback1

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <edit-config>
    <target>
      <running/>
    </target>
    <config>
      <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
        <interface>
          <name>Loopback1</name>
          <description>Loopback1 (Created by NETCONF)</description>
           <type xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">ianaift:softwareLoopback</type>
           <enabled>true</enabled>
           <ipv4 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
             <address>
               <ip>1.1.1.1</ip>
               <netmask>255.255.255.255</netmask>
             </address>
           </ipv4>
        </interface>
      </interfaces>
    <config>
  </edit-config>
</rpc>

การเชื่อมต่อระหว่าง NETCONF Client และ NETCONF Server

NETCONF สามารถใช้ SSH channel มากกว่าหนึ่ง channel ภายใต้ SSH connection เดียวกันเพื่อแยกการส่งข้อมูลที่มีจุดประสงค์แตกต่างกันได้ เช่น

• Channel 1 ใช้สำหรับรับส่งข้อมูลในการทำเรื่อง configuring
• Channel 2 ใช้สำหรับรับส่งข้อมูลจากการอ่านค่า operational status
• Channel 3 ใช้สำหรับ subscribe เพื่อรับข้อมูลจาก changes บางอย่างแบบเจาะจงบนอุปกรณ์ เช่น BGP neighbor เป็นต้น

สรุปส่งท้าย

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

ในบทความถัดไปเกี่ยวกับ NETCONF ผมได้เขียนถึงการใช้งานในการ configure และ monitor อุปกรณ์ network ซึ่งจะเป็นตัวอย่างการนำ NETCONF ไปใช้งานจริงแล้วครับ ตามมาดูได้ที่นี่เลย

การใช้ NETCONF บน Cisco Router (CSR 1000V)

— — — — — — — — — — — — — — —
สารบัญเนื้อหาทั้งหมด (My Contents)
— — — — — — — — — — — — — — —