מה זה NETCONF? המדריך לאוטומציית רשתות עם YANG ו־Cisco

תחשבו על מאה נתבים ושלוש מאות סוויצ׳ים. ביום שני בבוקר מגיעה בקשה פשוטה: להוסיף שרת NTP חדש ולעדכן את ה־SNMP community בכל הרשת. אפשר לפתוח מאות חלונות SSH ולהקליד. אפשר גם לכתוב סקריפט שמדביק פקודות CLI ומקווה שהפלט לא השתנה בגרסה האחרונה של ה־IOS. ויש דרך שלישית, זו שהרשתות הגדולות עובדות איתה היום: NETCONF.

במאמר הזה נסביר מה NETCONF עושה, למה הוא נבנה בכלל, איך הוא מתחבר ל־YANG, ואיך מפעילים אותו על ציוד Cisco תוך כמה דקות. בסוף מחכה לכם מבחנון קצר.

למה CLI כבר לא מספיק

ה־CLI נבנה לבני אדם. הפלט של show ip interface brief נראה מצוין על המסך, אבל סקריפט שמנסה לפרסר אותו נשבר ברגע שמשתנה רווח, עמודה או גרסת תוכנה. גם SNMP, שהיה במשך שנים הפתרון לניטור, לא באמת הצליח בתחום ההגדרות: כתיבה דרכו מסורבלת, ואין לו מושג של טרנזקציה.

ה־IETF הבינה את הבעיה כבר בתחילת שנות האלפיים, והתשובה הייתה NETCONF. הגרסה הראשונה יצאה ב־2006, והגרסה המעודכנת שכולם עובדים איתה היום פורסמה ב־2011 כ־RFC 6241.

איך NETCONF בנוי: ארבע שכבות

• ▸Transport: ערוץ מאובטח, לרוב SSH בפורט 830 (RFC 6242). קיימת גם תמיכה ב־TLS.
• ▸Messages: כל בקשה עטופה ב־rpc וכל תשובה ב־rpc-reply. כך הלקוח יודע איזו תשובה שייכת לאיזו בקשה.
• ▸Operations: הפעולות עצמן, כמו get-config, edit-config ו־commit.
• ▸Content: הנתונים, מעוצבים לפי מודל YANG שהציוד מפרסם.

בתחילת כל חיבור הלקוח והשרת מחליפים הודעת hello, ובה כל צד מפרסם את ה־capabilities שלו. מכאן הלקוח יודע אם הציוד תומך ב־candidate datastore, ב־validate, ובאילו מודלים של YANG.

הפעולות שחשוב להכיר

• ▸get: שליפת קונפיגורציה יחד עם מידע תפעולי, למשל מוני ממשקים.
• ▸get-config: שליפת הקונפיגורציה בלבד מ־datastore מסוים.
• ▸edit-config: שינוי הגדרות. אפשר למזג, להחליף או למחוק חלקים מהעץ.
• ▸copy-config ו־delete-config: העתקה ומחיקה של datastore שלם.
• ▸lock ו־unlock: נעילת ה־datastore כדי ששני מהנדסים או שתי מערכות לא ידרכו זה לזה על הרגליים.
• ▸commit ו־validate: אימות השינוי והפעלתו, בציוד שתומך ב־candidate.
• ▸close-session ו־kill-session: סגירה מסודרת של החיבור, או ניתוק של סשן תקוע.

Datastores: הרעיון שעושה את ההבדל

NETCONF מפריד בין כמה עותקים של הקונפיגורציה. running היא ההגדרה הפעילה כרגע. startup היא מה שייטען אחרי אתחול. candidate היא טיוטה: כותבים אליה, מריצים validate, ורק כשהכל תקין שולחים commit. אנשים שעבדו עם Juniper או עם IOS XR מכירים את הגישה הזו היטב.

המשמעות בשטח גדולה. אם אתם דוחפים שינוי של עשרים שורות ושורה אחת שגויה, הציוד דוחה את כל הטרנזקציה. אין מצב ביניים שבו חצי מה־ACL נכנס והחצי השני לא. מי שפעם נעל את עצמו מחוץ לנתב בגלל ACL חלקי יודע להעריך את זה.

YANG: השפה שמתארת את הרשת

NETCONF הוא הצינור, ו־YANG הוא מה שעובר בתוכו. YANG (RFC 7950) היא שפת מידול שמגדירה איך נראה עץ הנתונים של הציוד: אילו ממשקים יש, אילו שדות יש לכל ממשק, ומה הטיפוס והטווח של כל שדה. כשמודל אומר ש־mtu הוא מספר בין 64 ל־9216, הציוד ידחה ערך אחר עוד לפני שהוא נוגע בקונפיגורציה.

יש שלושה סוגי מודלים עיקריים: מודלים של ה־IETF כמו ietf-interfaces, מודלים של OpenConfig שנבנו בהובלת ספקיות ענן גדולות כדי לקבל ממשק אחיד בין יצרנים, ומודלים Native של כל יצרן, כמו Cisco-IOS-XE-native, שמכסים את כל היכולות של הציוד.

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <get-config>
    <source><running/></source>
    <filter type="subtree">
      <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"/>
    </filter>
  </get-config>
</rpc>

הפעלת NETCONF על Cisco IOS XE

על נתבים וסוויצ׳ים מודרניים של Cisco כמו Catalyst 9000 או ISR 4000 ההפעלה קצרה. צריך משתמש עם privilege 15, AAA פעיל, ופקודה אחת שמעלה את השירות:

conf t
 aaa new-model
 aaa authentication login default local
 aaa authorization exec default local
 username netops privilege 15 secret StrongPass!23
 netconf-yang
end

show netconf-yang status
show platform software yang-management process

אחרי דקה או שתיים התהליכים עולים, ואפשר לבדוק ידנית עם ssh netops@10.0.0.1 -p 830 -s netconf. אם קיבלתם הודעת hello ארוכה עם רשימת capabilities, השירות עובד.

ומה עם Python?

אף אחד לא כותב XML ביד בעבודה היומיומית. הספרייה הנפוצה היא ncclient: מתחברים לציוד, שולחים get_config או edit_config, ומקבלים XML שאפשר להמיר למילון עם xmltodict. Ansible עובד מול NETCONF דרך מודול netconf_config, וכלים כמו Cisco NSO ו־Terraform נשענים עליו מאחורי הקלעים.

from ncclient import manager

with manager.connect(host="10.0.0.1", port=830,
                     username="netops", password="StrongPass!23",
                     hostkey_verify=False) as m:
    reply = m.get_config(source="running")
    print(reply.xml[:500])

NETCONF, RESTCONF ו־gNMI: מי זה מי

• ▸NETCONF: מעל SSH, הודעות XML, תמיכה מלאה ב־datastores, נעילות וטרנזקציות. הבחירה הטבעית לשינויי קונפיגורציה רציניים.
• ▸RESTCONF (RFC 8040): אותם מודלים של YANG, אבל דרך HTTPS עם GET, PUT, PATCH ו־DELETE, ותומך גם ב־JSON. נוח למפתחים שרגילים ל־REST API.
• ▸gNMI: פרוטוקול מבוסס gRPC שהתפתח בקהילת OpenConfig, חזק במיוחד ב־Streaming Telemetry.

שלושתם חולקים את אותו בסיס, YANG. מי שמבין את המודל ואת NETCONF יעבור לשניים האחרים בלי קושי.

איפה זה פוגש את CCNA

בחינת CCNA 200-301 כוללת פרק שלם של Automation and Programmability: ההבדל בין רשת מסורתית לרשת מבוססת בקר, SDN, REST API, JSON וכלי ניהול תצורה. NETCONF ו־YANG הם ההמשך הטבעי של הפרק הזה, ומי שמגיע לראיון כשהוא יודע להסביר datastore או לכתוב get-config בסיסי בולט מיד מול מועמדים שמכירים רק CLI.

חשוב לומר ביושר: אוטומציה לא מחליפה הבנה של רשת. סקריפט שדוחף הגדרת OSPF שגויה למאה נתבים פשוט מפיל מאה נתבים מהר יותר. לכן הסדר הנכון הוא קודם יסודות חזקים: VLAN, STP, ניתוב ו־Subnetting, ורק אחר כך אוטומציה מעליהם.

מקורות להעמקה