SDN בעברית: המדריך המלא ל-Software Defined Networking, אוטומציה רשתית ו-JSON — עם מבחנון בסטייל CCNA

במשך שנים ניהלנו רשתות בדיוק אותו דבר: מתחברים ב-SSH לראוטר, מקלידים פקודות, שומרים, עוברים לראוטר הבא. עשרה מכשירים? נסבל. מאתיים מכשירים בעשרה אתרים? זו כבר עבודה שמייצרת טעויות אנוש, חוסר אחידות וימים שלמים של Troubleshooting. SDN — Software Defined Networking — נולד בדיוק כדי לפתור את זה, והיום הוא נושא רשמי במבחן CCNA 200-301. במדריך הזה של מכללת נטמי נפרק את SDN לחתיכות פשוטות בעברית, נראה איך זה נראה בפועל, ובסוף תוכלו לבחון את עצמכם במבחנון קצר.

הבסיס: Control Plane, Data Plane ו-Management Plane

כדי להבין SDN חייבים קודם להבין שכל מכשיר רשת מחולק לשלושה "מישורים" (Planes). ה-Control Plane הוא המוח: הוא מריץ פרוטוקולי ניתוב כמו OSPF ו-BGP, בונה את טבלת הניתוב, לומד כתובות MAC ומחשב STP. ה-Data Plane (או Forwarding Plane) הוא השריר: הוא מקבל חבילה, מסתכל בטבלה שה-Control Plane בנה, ומעביר אותה הלאה — במהירות חומרה. ה-Management Plane הוא הדלת שדרכה אנחנו נכנסים: SSH, Telnet, SNMP, Syslog.

• ▸Control Plane — מחליט לאן תלך התעבורה (OSPF, EIGRP, BGP, STP, ARP)
• ▸Data Plane — מבצע את ההעברה בפועל, בדרך כלל בחומרה ייעודית (ASIC)
• ▸Management Plane — ניהול וגישה למכשיר (SSH, SNMP, NETCONF, Syslog)

ברשת מסורתית הארכיטקטורה היא Distributed: לכל מכשיר יש Control Plane משלו, וכל מכשיר מקבל החלטות בעצמו. כדי שהם יסתדרו ביניהם הם מחליפים הודעות — Hello של OSPF, BPDU של STP וכן הלאה. זה עובד, זה עמיד, אבל זה לא ניתן לניהול מרכזי ולא ניתן לתכנות בקלות.

מה זה SDN? מלך אחד לכל הממלכה

SDN לוקח את ה-Control Plane מהמכשירים ומרכז אותו ביישום אחד שנקרא SDN Controller. המכשירים נשארים עם ה-Data Plane בלבד — הם ממשיכים להעביר חבילות במהירות מלאה, אבל את ההוראות מי מדבר עם מי הם מקבלים מהבקר. במקום להגדיר 200 מכשירים אחד-אחד, אתם מגדירים מדיניות אחת בבקר, והוא דוחף אותה לכל הרשת.

המשפט שכדאי לזכור למבחן: ב-SDN ה-Control Plane מרוכז בבקר, בעוד שה-Data Plane נשאר על המכשירים עצמם.

Northbound ו-Southbound: שני הכיוונים של הבקר

לבקר יש שני ממשקים, וההבדל ביניהם הוא אחת השאלות הכי נפוצות במבחן. ה-Southbound Interface (SBI) פונה כלפי מטה — אל מכשירי הרשת. דרכו הבקר מתקשר עם הסוויצ׳ים והראוטרים ומתכנת אצלם את טבלאות ההעברה. ה-Northbound Interface (NBI) פונה כלפי מעלה — אל האפליקציות ואל מנהלי הרשת. דרכו אפליקציה יכולה לבקש מהבקר "תפתח לי מסלול בין A ל-B" או "תראה לי את כל הפורטים שעמוסים מעל 80%".

• ▸Southbound APIs: OpenFlow, NETCONF, RESTCONF, OpFlex — הבקר הוא ה-Server והמכשירים הם ה-Clients
• ▸Northbound APIs: בעיקר REST על גבי HTTP/HTTPS, לעיתים גם SOAP — האפליקציה היא ה-Server והבקר הוא ה-Client
• ▸OpenFlow מתכנת ישירות את טבלאות ההעברה (Flow Tables) של הסוויץ׳
• ▸NETCONF עובד מעל SSH ומשתמש ב-XML; RESTCONF עובד מעל HTTP ומחזיר JSON או XML
• ▸OpFlex שולח "מדיניות מסוכמת" למכשיר, והמכשיר מתרגם אותה בעצמו לקונפיגורציה

דוגמה מוחשית ל-Northbound API: בקשת REST פשוטה שמושכת רשימת מכשירים מהבקר. שימו לב שהתשובה חוזרת ב-JSON — בדיוק הפורמט שנדבר עליו בהמשך.

$ curl -k -X GET \
    -H "Content-Type: application/json" \
    -H "X-Auth-Token: 9f3c1a7e-netme" \
    https://sdn-controller.netme.local/api/v1/network-device

{
  "response": [
    {
      "hostname": "NETME-SW-CORE-01",
      "managementIpAddress": "10.10.10.11",
      "platformId": "C9300-48P",
      "softwareVersion": "17.12.3",
      "reachabilityStatus": "Reachable"
    },
    {
      "hostname": "NETME-SW-ACCESS-07",
      "managementIpAddress": "10.10.10.27",
      "platformId": "C9200-24T",
      "softwareVersion": "17.12.3",
      "reachabilityStatus": "Reachable"
    }
  ]
}

היתרונות האמיתיים של SDN (ולא רק בברושור)

• ▸ניהול מרכזי — מדיניות אחת במקום קונפיגורציה ידנית מכשיר-מכשיר
• ▸תכנות ואוטומציה — הרשת הופכת לקוד, וכל שינוי הוא קריאת API
• ▸נראות מלאה — הבקר רואה את הטופולוגיה כולה ולא רק את מה שהמכשיר המקומי יודע
• ▸סקיילביליות — הוספת אתר או מאה מכשירים חדשים היא תהליך מתוזמר ולא פרויקט
• ▸סביבה ניטרלית ליצרן — פחות תלות בחומרה קניינית אחת
• ▸אבטחה — נקודת אכיפה אחת למדיניות, זיהוי חריגות ותגובה אוטומטית

וכן, יש גם חסרונות שחשוב להכיר: הבקר הוא Single Point of Failure (ולכן בפרודקשן מריצים אותו בקלאסטר), נדרש ידע בתכנות ו-APIs שלא כל איש רשת מגיע איתו, והתלות בבקר מחייבת תכנון של מצב "מה קורה אם הבקר נופל".

מכאן לאוטומציה: Ansible, Puppet ו-Chef

SDN הוא הדרך לרכז את השליטה. כלי אוטומציית קונפיגורציה הם הדרך לאכוף מצב רצוי על מאות מכשירים ושרתים. שלושת השמות שמופיעים במבחן CCNA הם Ansible, Puppet ו-Chef, וההבדלים ביניהם פשוטים ברגע שמסדרים אותם.

• ▸Ansible — Agentless, עובד מעל SSH, מודל Push, נכתב ב-YAML. קבצים: Playbooks, Inventory, Templates (Jinja2), Variables
• ▸Puppet — דורש Agent על כל Node, מודל Pull (כל 1800 שניות), נכתב ב-Ruby, TCP 8140. קבצים: Manifests (.pp), Modules, Catalogs, Facts
• ▸Chef — דורש Agent, מודל Pull, נכתב ב-Ruby, TCP 10002. קבצים: Recipes, Cookbooks, Run-list
• ▸Ansible הוא הכי קל להתחלה כי אין מה להתקין על המכשירים — רק SSH פתוח
• ▸Puppet ו-Chef חזקים בסביבות ענק שדורשות אכיפת Compliance מתמשכת

כך נראה Playbook אמיתי ב-Ansible שמושך פלט משני ראוטרים של סיסקו. שימו לב למבנה: Inventory מגדיר את המכשירים, ה-Playbook מגדיר את המשימות, וכל משימה מפעילה Module.

# hosts (inventory)
[ios_devices]
NETME-R1 ansible_host=10.10.10.1
NETME-R2 ansible_host=10.10.10.2

[ios_devices:vars]
ansible_network_os=ios
ansible_user=netme_admin

---
# show_ios.yml (playbook)
- name: NetMe - IOS Show Commands
  hosts: ios_devices
  gather_facts: false
  connection: network_cli
  tasks:
    - name: Collect version and hostname
      ios_command:
        commands:
          - show version | include IOS
          - show run | include hostname
      register: output

    - name: Print output
      debug:
        var: output.stdout_lines

$ ansible-playbook -i hosts show_ios.yml

# /etc/puppet/manifests/vlan.pp
node 'NETME-SW-CORE-01' {
  cisco_vlan { '10':
    ensure    => present,
    vlan_name => 'NETME-USERS',
    shutdown  => false,
  }
}

$ puppet apply /etc/puppet/manifests/vlan.pp

JSON: השפה שבה הרשת מדברת היום

כל ה-APIs שדיברנו עליהם מחזירים ומקבלים דאטה, וברוב המוחלט של המקרים הפורמט הוא JSON. זו הסיבה ש-JSON נמצא בסילבוס של CCNA 200-301. הכללים פשוטים: הדאטה נכתב כזוגות של key/value, המפתח תמיד מחרוזת בגרשיים כפולים, אחריו נקודתיים ואז הערך. אובייקט עטוף בסוגריים מסולסלים {} ומערך בסוגריים מרובעים [].

• ▸מפתח חייב להיות מחרוזת בגרשיים כפולים, וייחודי בתוך אותו אובייקט
• ▸ערכים אפשריים: string, number, boolean, null, object, array
• ▸פסיק מפריד בין זוגות — אבל אסור פסיק אחרי האיבר האחרון
• ▸{} = אובייקט (Dictionary ב-Python), [] = מערך (List ב-Python)
• ▸JSON הוא Case Sensitive — "Status" ו-"status" הם שני מפתחות שונים

>>> import json
>>> raw = '{ "hostname": "NETME-R1", "model": "ISR4331", "uptime_days": 187, "is_core": true, "interfaces": ["Gi0/0/0", "Gi0/0/1", "Lo0"] }'
>>>
>>> data = json.loads(raw)      # JSON string -> Python dict
>>> type(data)
<class 'dict'>
>>> data["hostname"]
'NETME-R1'
>>> data["interfaces"][0]
'Gi0/0/0'
>>> len(data["interfaces"])
3
>>> print(json.dumps(data, indent=2))   # Python dict -> JSON string

איך זה נראה בשטח בישראל

בפועל, רוב הארגונים בישראל לא קופצים ליום אחד לרשת SDN מלאה. המסלול הנפוץ הוא הדרגתי: קודם מוסיפים בקר לניהול הקמפוס (Cisco Catalyst Center, Meraki Dashboard או פתרון SD-WAN), במקביל מתחילים לאסוף מלאי ולבצע בדיקות דרך REST API, ואז מעבירים משימות חוזרות — פתיחת VLAN, שינוי ACL, גיבוי קונפיגורציה — ל-Playbooks של Ansible. השילוב הזה הוא בדיוק מה שמעסיקים מחפשים היום ב-Job Description של איש רשת ג׳וניור.

איש רשת שיודע רק להקליק פקודות ב-CLI עדיין ימצא עבודה. איש רשת שיודע גם למשוך JSON מ-API ולהריץ Playbook — יבחר איפה לעבוד.

לסיכום — ומה השלב הבא

SDN הוא לא באזזוורד. הוא הכיוון שאליו כל רשת ארגונית רצינית הולכת, והוא הסיבה שהמבחן 200-301 כולל היום Controllers, APIs, JSON וכלי אוטומציה לצד VLANs ו-OSPF. מי שמבין את שלושת ה-Planes, יודע להסביר Northbound מול Southbound, ומרגיש בנוח לקרוא JSON — נמצא צעד לפני רוב המועמדים בראיון.

בקורס CCNA של מכללת נטמי אנחנו לוקחים בדיוק את הנושאים האלה ומורידים אותם לקרקע: מעבדות מעשיות, הסברים בעברית פשוטה, תרגול שאלות בסגנון המבחן וליווי עד לתעודה. אם המבחנון למעלה גילה לכם פערים — זה בדיוק המקום לסגור אותם.