רשתות "חושבות" – אמת או דמיון (ומתי זה יקרה ברשתות ארגוניות)

 

מבוא

בשנים האחרונות אנחנו שומעים על רשתות חכמות, אוטומציה ברשתות, אינטליגנציה מלאכותית (AI), מערכות למידה (Deep Learning) וגם על מונחים שבאים מיצרנים שונים כמו Cisco IBN (Intent based Networking),  בינה מלאכותי ברשתות אלחוטיות של Juniper ועוד. יש כאן הרבה חידושים, אבל זה גם קצת מזכיר לי שלפני 15 שנה כולם דיברו על "רשתות הדור הבא" (Next Generation Networks), וכששאלתי את אחד מספקי התקשורת למה הם מתכוונים ב"רשת הדור הבא", הם ענו לי שקווי טלפון…

מה נדרש לעשות ברשת תקשורת

קודם כל, אם ניגש לפעולות ברשת תקשורת, לפי המודל הישן והטוב של FCAPS הן:

  • Fault – ניהול ותפעול תקלות
  • Configuration – ניהול ושינויי תצורה
  • Accounting – נתוני שימוש במשאבי הרשת
  • Performance – ניטור ווידוי שביצועי הרשת עומדים בנדרש
  • Security – בקרת גישה למשאבי הרשת

שנית, נסווג את הפעולות לפי הרמה הנדרשת:

  • רמת רכיב הרשת (Network Element Level) – נתב, מתג, רכיבי אבטחה וכד'
  • רמת הרשת (Network Level) – מבט על הרשת כולה, מקצה לקצה, כולל כל הרכיבים שבה
  • רמת השירות שהרשת נותנת (Service Level) – רוחב פס מקצה לקצה וכד'

אז מה אנחנו רוצים שיתבצע באופן אוטומטי ומה נעדיף שלא? ונדבר על איסוף הנתונים (Monitoring), ניתוח (Analysis) ותגובה/תפעול (Operation).

העולם הישן (והטוב?)

בעולם הישן והטוב, ברשתות ארגוניות, דיברנו על 3 נושאים עיקריים – ניהול תקלות, תצורה וביצועי.

ניהול תקלות

אם אנחנו מדברים על ניהול תקלות (Fault Management) – כבר הרבה שנים שתקלות ברמה מסוימת מטופלות על ידי הרשת. נתב תקול מגובה על ידי HSRP/VRRP ברמת הרכיב, קו תקשורת תקול מגובה תוך שניות על ידי פרוטוקול ניתוב ברמת הרשת, ורוחב פס שמוקצה לנו מקצה לקצה על ידי ספק התקשורת יכול להיות קבוע גם בזמן תקלה על ידי מנגנונים כמו MPLS-TE  ואחרים.

ניהול תצורה

בניהול תצורה (Configuration Management) המצב קצת יותר מורכב. ברשתות ארגוניות כיום המצב פשוט. ברוב המקרים, אם רק ניתן מספיק רוחב פס (בד"כ מאוד בזול), יהיה מספיק לכולם. אבל מה קורה כאשר הרשתות נהיות מורכבות וקריטיות יותר? כיום אנחנו מדברים על שדות תעופה, נמלי ים, ארגוני בטחון וכד', ובשנים הקרובות נעבור לטכנולוגיות IoT כאשר כמעט כל דבר שנעשה תלוי ברשת. כאן זה יהיה מסובך יותר. מצד אחד, לסמוך באופן מלא על אוטומציה, ומצד שני אנחנו לא יכולים להגיב מספיק מהר כמו שמכונה יכולה. נדבר על זה בהמשך.

ניהול ביצועים

ניהול ביצועים משמעותו איך ננטר, נקבע ונבטיח את הביצועים הנדרשים לעובדה תקינה של מערכות המיחשוב המחוברות לרשת התקשורת. במקרה של הרשתות כיום, המצב פשוט. מספר כרטיסים של 10Gbps  לכל שרת, כרטיס 1Gbps לכל תחנה, רוחב פס מספיק בקווי התקשורת לאתרים מרוחקים, וכמעט תמיד הכול יעבוד. אבל מה קורה כאשר נצטרך יותר גמישות? למשל אלפי או עשרות אלפי רכיבי IoT  בנמל ימי או בשדה תעופה, שצריכים Delay נמוך וקבוע, ולאו דווקא רוחב פס? ומה יקרה כאשר לתפעול של מערכות ה- IoT  נצטרך מאות ואלפי מצלמות ברזולוציה של 8K  ומעלה, עם דרישה לרוחב פס של עשרות Mbps ו- Delay של מילי-שניה או פחות? כאן ל"זרוק רוחב פס על הבעיה" (Through bandwidth on the problem) לא בטוח יספיק. כאן צריכים הפעלת נתיבים ברשת באופן אוטומטי, בדרישות איכות מסוימות, לעיתים עם אבטחה ברמה גבוהה ועוד. אותן הבעיות שאיתן מתמודדים היום ברשתות סלולריות בדור החמישי ומעלה.

חזרה ל- SDN?

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

ב- SDN הרעיון הוא להפריד חומרתית בין ה- Control plane  ל- Data plane, כאשר את ה- Control plane מממשים באמצעות בקר (SDN Controller), שיקבל את ההחלטות איך להעביר את המידע (או לא להעביר אותו), וייתן הוראות למתגים פשוטים שכל מה שהם יעשו זה להעביר את המידע, מהר ככל האפשר.

החוכמה ב- SDN היא שהבקר מקבל את החלטות ההעברה. בלומר, בקר חכם יכול לקבל החלטות ברמה 3 (של OSI  כמובן) ואד מימנו נתב, ברמה 4 ואז מימשנו Route maps, או ברמות 5-7 ואז מימשנו Firewall. באופו זה אנחנו גם יכולים לממש Load balancer, אבטחת מידע ברמה הגבוהה ביותר ועוד. חשוב להגיד שבזמן שמאמר זה נכתב אנחנו עוד לא שם (מרץ 2020), אבל זה לא רחוק.

בהקשר של אוטומציה חשוב להזכיר גם רכיב נוסף, Orchestrator, שמממש את ה- Management plane, כלומר תוכנה שמנהלת את כל רכיבי הרשת ואת השירותים שהם נותנים. מאמר מפורט על כך אפרסם בהמשך.

כלומר, כבר לפני כעשר שנים, עם היישומים הראשונים של SDN, דובר על רשת אוטומטית, כאשר בקר מרכזי מקבל דרישות מאפליקציות, ולפי דרישות אלו הוא מקצה את משאבי הרשת (ויש כאן גם הרבה יותר מזה. אכנס לזה בפרק על הנושא). כאן ניתן לראות יישומים  של יצרנים שונים:

  1. סיסקו עם  Intent-Based Networks ועם  SDN-Controllers – ACI לניהול Data Centers, DNA-Center לניהול הקמפוס ו- V-Manage (של חברת Viptela שנרכשה על ידי Cisco) לניהול ה- WAN (SD-WAN)
  2. ג'וניפר עם בקר Contrail ויישום Contrail Enterprise Multicloud לניהול ה-DC, Contrail SD-WAN לניהול ה- WAN, Contrail Cloud לספקי שירות (Service Providers), ו- Contrail Edge Cloud לניהול רשתות גישה.
  3. Arista Networks עם הרכישה של Big Switch Networks, פלטפורמת CloudVision ויישומים שונים

מה שמעניין גם זה הכניסה של החברות הגדולות לפתרונות של Visibility, כלומר נטור של המידע העובר על הרשת באמצעות Packet Analysis, נושא שכתבתי עליו לפני כשנתיים, אבל העולם השתנה מאז. מערכות של Extreme Networks, Arista Networks ויצרנים נוספים עם פלטפורמות ייחודיות, בצד מערכות Open Source קיימות, שמורידים את המחירים לרמות שכל ארגון בינוני יכול לקחת בחשבון. אכנס לזה במאמר מפורט בהמשך.

רשתות לומדות ואינטליגנציה מלאכותית

רשתות לומדות ורשתות העובדות באמצעות אינטליגנציה מלאכותי קיימות ברמה כזאת או אחרת כבר מספר שנים. כך למשל Google במצגת “The Zero Touch Network” מכנס CNSM-2016 משנת 2016, מתארים את הרשת הגלובלית שלהם שעבדה כבר לפני כ- 10 שנים, כרשת עצמאית לחלוטין המגיבה באופן עצמאי לתקלות ושינויים נדרשים.

במצגת זו, מתאר Bikash Koley ארבעה תנאים לרשת עצמאית (Zero-Touch Network):

  1. כל פעולות הרשת הן אוטומטיות, ואינן דורשות התערבות כלשהי של המפעיל
  2. כל השינויים ברכיבי הרשת (ה- Network Elements), גם של יצרנים שונים, יהיו ממערכת מרכזית, והשינויים יהיו מתוך הגדרת הדרישות
  3. כל השינויים המתבצעים ברשת ניתנים לחזרה לאחור (Roll-back), והחזרה לאחור תבוצע אוטומטית אם הרשת תראה התנהגות לא תקינה לאחר שינוי שבוצע
  4. תשתיות הרשת לא יאפשרו פעולות שמפרות את מדיניות הרשת (Network Policy)

האם רשת תקשורת יכולה לעשות את זה לבד?

התשובה היא כן, אבל. ואני מתייחס לשאלה האם תהיו מוכנים לסמוך על פעולות אוטומטיות שיחברו או ינתקו פעולות ברשת, וזה כמובן מתבסס על אמינות פעולות אלו, והאם תאפשרו למערכות לבצע פעולות או רק להמליץ לכם ואתם תבצעו. קחו למשל פעולה פשוטה כמו ניתוק מבוא במתג כאשר עברנו סף שגיאות מסוים (Errdisable לדוברי Cisco IOS). כנראה שהפעלתם את זה על מבואות רגילים במתגים. על מבוא של שרת קריטי ברשת קריטית, לגמרי לא בטוח.

וכאן אנחנו גם נכנסים לעולם של בינה מלאכותית (AI). וכאן נכנסות כמה רמות של אוטומציה. שימוש בבינה מלאכותית אומר זיהוי התנהגות על ידי הרשת, ולפי זה הרשת מגיבה. זיהוי התנהגות (Behavior Anaysis) הינו תחום מרתק בפני עצמו, ואדון בו במאמר נפרד. מוצרים כאן התחילו לצאת לשוק לפני כ- 3 שנים, למשל SteathWatch  של סיסקו או לאחרונה  PaloAlto עם Cortex XDR באבטחת מידע, ג'וניפר עם מערכת בקרה חכמה לרשתות אלחוטיות ועוד.

בתקשורת המצב קצת שונה, ואת מה שיש היום אפשר לחלק לכמה רמות.

ברמה הראשונה, וכבר הרבה שנים, אפשר היום בכל מערכת בקרה להגדיר שכאשר קורה אירוע מסויים שהמערכת מגלה, למשל עומד על קו מסוים, יופעל Script שיתחבר לציוד התקשורת וייתן פקודה לביצוע. יש כאן מספר בעיות, והעיקריות הן האם התגובה תעבוד (למשל אם ניתן פקודה להעביר את הונעה לקו אחר האם הוא זמין), ובעיה נוספת האם לאחר שביצענו את הפעולה הכול יעבוד תקין. בקיצור אפשרי אבל מסורבל ולפעמים מסוכן.   

ברמה השנייה, ניתן היום לגשת לרוב סוגי הציוד בתוכנה, לקרוא נתונים ולהגיב לנתונים אלו. ברמה זאת, ניגש לציוד בתוכנה, בד"כ ב- Python עם ספריות כגון ncclient, netmiko וכד' שיכולות גם "לדבר" עם הציוד בשפתו, כלומר לשלוח פקודות ב- Cisco-IOS/NXOS, Juniper-JuNOS  וכד', לשלוח פקודות לקבלת נתונים, לקבל אתראות, לעבד את המידע ולשלוח פקודות חזרה. חומר על אוטומציה ב- Python יש בשפע. מומלץ למשל אתר בשם Packetpushers.net שבו יש הסברים יפים גם על נושא זה וגם על נושאים אחרים. רוב סוגי הציוד מכירים גם מבני מידע אחידים, למשל JSON או YAML (בדומה ל- SMI שהוא מבנה המידע ב- SNMP), ואז ניתן גם להשתמש בהם ולגשת לציוד בקלות רבה יותר. הרצאות מצוינות בנושא יש ניתן למצוא בסיסקו.

ברמה השלישית אנחנו מדברים על SDN מלא, כאשר קיים Orchestrator ששולט על השרותים ברשת, SDN Controllers שמערכות הבקרה והיישומים מדברים איתו בממשקים סטנדרטיים, REST למשל, וכאשר ה- Controller מקבל למשל בקשה מיישום מסויים להקצות לו רשמת שירות מסויימת, הוא מעביר את הדרישה למתגים באמצעות OpenFlow ורמת השירות מוגדרת. בזמן כתיבת המאמר אנחנו עוד לא שם, אבל זה יגיע.

במאמרים הקרובים אכנס יותר לעומק ל- SDN, לנושא של Network Behavior בהיבטים של תקשורת ואבטחת מידע (מה שאנחנו עושים בהדרכות Wireshark), מערכות בקרה עם דגש על Visibility  ו- Packet analysis שניתן כבר לרכוש במחירים שפויים ועוד.