למאמרים קשורים ששיתפו אותי בנושא אוטומציה של רשתות, עיין בקטלוג "NetDevOps מאפס"
בשנים האחרונות, עם ההתפתחות המתמשכת של תחום מחשוב הענן העולמי והצמיחה המתמשכת של העסק, גם טכנולוגיית הרשת המשיכה להתפתח, וטכנולוגיית SDN צמחה. מרעיון הליבה המקורי של הפרדת העברה ובקרה על בסיס Openflow, אנשים ממשיכים להתרחב בהרחבה של SDN, אנשים יכולים כיום להגיע לקונצנזוס ש-Openflow אינו עוד תנאי הכרחי (אבל ההפרדה בין העברה לשליטה היא עדיין תנאי ליבה), ותכנות הרשת הפכה לאט לאט לאחד הקריטריונים החשובים למדידת ארכיטקטורת SDN.
פעולות הניתנות לתכנות של ציוד רשת מסורתי מבוססות בדרך כלל על פרוטוקולי CLI ו-SNMP. בין אם סקריפטים ובין אם תוכנות לניהול רשת, כולם פותחו על בסיס זה כדי להשיג את הטווח הרחב של תכנות רשת שעליו נדבר היום. יכולות, ובכך לממש את האוטומציה של תרחישים רבים. חלק מהמכשירים תומכים בתצורה של ממשקי אינטרנט מסוימים ובהחלפת התצורה הכוללת באמצעות xml. אלה נדירים מאוד ולא יתוארו בפירוט במאמר זה.
CLI
CLI (ממשק שורת פקודה) מממש אינטראקציה בין אדם למחשב באמצעות שורת הפקודה. זוהי מיומנות הכרחית לעובדי רשת. אנשים פותחים את התוכנה SSH או Telnet למכשיר כל יום, ואז מדביקים תצורה, שומרים אותה ונכנסים לתוקף. יום אחד, אנשים התעייפו מחזרות מסוג זה, והשתמשו בתוכנה כדי ליצור אוטומטית סקריפטים של תצורה, להתחבר למכשיר באצווה ולהנפיק תצורות שייכנסו לתוקף, תוך מימוש אוטומציה. זוהי שיטה הניתנת לתכנות ברשת. בואו נדבר על היתרונות, שהם מאוד עקביים עם החשיבה, הרעיונות והמערכות הטכניות הקיימות של אנשים. אבל בסופו של דבר, גישה זו מעדיפה אנשים על פני התקני רשת. יש לו את החסרונות הבאים:
-יש הבדלים עצומים בערכות פקודות בין יצרנים. לא רק ליצרנים, אלא לגרסאות תוכנה שונות של אותו דגם עשויות להיות הבדלים שונים מאוד.
-מפתחים חייבים להכיר את ערכת הפקודות ואת אופן השימוש בה. ישנם סיכוני אבטחה ברמת התצורה. לדוגמה, בהינף יד, היציאה שרציתי לפתוח הפכה לסגירת היציאה...
-אין דרישות חובה לפרוטוקולי שידור (SSH ו-Telnet), ויש סיכוני אבטחה בייצור.
-תהליך ניתוח ויצירת תצורות הוא מסובך ביותר. במקרים רבים, הכללים הרגילים שנכתבו יכולים להיות רק קרובים לאין שיעור ל"אמת", אך לא ל"אמת" כולה.
-אין עסקאות, ותצורה עשויה להיכנס לתוקף חלקית וחלקה לא להיכנס לתוקף.
-אין מנגנון בדיקה אוטומטי והוא תלוי לחלוטין באנשים. לדוגמה, אני רוצה לבדוק אם הסקריפט שנוצר נכון. יש דרך, אבל היא מאוד קשה ולרוב קשה ליישם אותה בקלות.
-אין מושג במודל נתונים
CLI היא תמיד דרך לאינטראקציה בין אדם למחשב. זה יכול לתת לרשת יכולות תכנות מסוימות באמצעות תוכניות, אבל אחרי הכל, זו לא שיטה הניתנת לתכנות ברשת מטבעה. תחת הגל הנוכחי של מחשוב ענן ו-SDN, הוא אינו מתאים לפריסה אוטומטית בקנה מידה גדול ברשת, ויכולת התכנות שלו מוגבלת. קשה לאנשים מבחוץ להבין את הקושי בהתפתחות.
SNMP
SNMP (SNMP, Simple Network Management Protocol), פרוטוקול זה יכול לתמוך במערכות ניהול רשת כדי לפקח אם להתקנים המחוברים לרשת יש מצב כלשהו שגורם לתשומת לב ההנהלה. הוא מורכב מקבוצה של תקני ניהול רשת, כולל פרוטוקול שכבת יישומים, סכימת מסד נתונים וקבוצה של אובייקטי נתונים.
עבור פיסת תוכן בוויקיפדיה, אנו מדגישים אובייקטי ניהול, ניטור ומידע של רשתות. הוא משמש לניהול הרשת, ניתן להגדיר ולאסוף, ומשמש בעיקר לניטור. יש לו מידול נתונים כדי לבנות כמה מודולים, מאפיינים ונתוני מצב של ציוד רשת. הוא משמש בעיקר למערכות ניהול רשת (בעיקר ניטור). אז בואו נדבר על החסרונות שלו:
-קריאות לקויה. הוא מעדיף את ה"מכונה" באדם-מכונה. הוא אינו קריא בעת שימוש, וגם נתוני הדוגמנות אינם ניתנים לקריאה. הוא משתמש בערכת-על של ASN.1.
-האבטחה מוגבלת. ישנן שלוש גרסאות: v1, v2c ו-v3, והאבטחה משופרת ברצף. עם זאת, הנפוץ ביותר הוא v2c, שיש לו אבטחה מוגבלת. גרסת v3 מאוד בטוחה בעיצובה, אבל היא לא אוניברסלית. . .
-אין מנגנון גיבוי, שחזור או החזרה. יש לנו גם show run ושיטות אחרות לגיבוי שורת הפקודה, אבל snmp. . .
-מעט מאוד כותבים. קורא הרבה, כתוב מעט, משמש בעיקר לניטור.
-פריטי הנתונים שניתן לאסוף מוגבלים, ולא ניתן להשיג את התצורה של המכשיר כולו. פעמים רבות אנו מגלים שאנו יכולים להשתמש ב-cli כדי לאסוף אותו, אך איננו יכולים להשתמש ב-snmp כדי לאסוף אותו.
-יש צוואר בקבוק בביצועים. הגבול העליון של נתונים שנאספו הוא 64K, ורמת האיסוף גדולה מדי. ברשתות גדולות ומורכבות, זה עשוי לקחת דקות או יותר. זה גם מדגיש את הנקודה החשובה. גם הדרישות שלנו לפירוט מחמירות מאוד. פעמים רבות אנו מקווים לאסוף תעבורת נמל כל כמה שניות. ברשתות גדולות, אני חושב שתוכנת ניהול רשתות מסורתית היא... כדי להרחיב על משפט אחד נוסף, השיטה הנוכחית היא טלמטריה (כגון gRPC) שיכולה להגיע לרמה של מיקרו-שנייה, וחלקן דורשות שילוב של תוכנה וחומרה. זה עדיין לא פופולרי, אבל בעתיד זה חייב להיות טרנד. לגבי מתי זה יגיע בעתיד...
-מאז לידתו נעשה שימוש רב ב-SNMP בתחום ניטור הרשת להשגת נתונים לניטור. היעדר ומורכבות יכולות התצורה הובילו לשימוש מועט בה בתצורת רשת. רשת לקריאה בלבד ניתנת לתכנות.
פרוטוקול Netconf ומודל YANG
מול הדור הבא של רשתות, איזה סוג של פרוטוקולי ניהול רשתות אנחנו צריכים כדי לממש טוב יותר את יכולת התכנות של הרשת ולשפר את רמת האוטומציה?
ה-IETF הציע את הרעיונות הבאים ב-RFC3535 בשנת 2002 (למעשה ישנם 33 מהם. בהתבסס על מידע מקוון והידע של המחבר, כתבתי את הרעיונות הבאים):
1. יש ממשק שניתן לתכנות לתצורת רשת
2. ניתן להשתמש באותה תצורה בין יצרנים ודגמים
3. צריך לאחד שפת דוגמנות עם קריאה טובה
4. השלם פונקציות בדיקת שגיאות ושחזור
5. עסקה
אם יש לך רעיון, פשוט ליישם אותו. בשנת 2006, ה-IETF הציע את פרוטוקול Netconf, שפתר את הבעיות שהעלה RFC3535. ה-Netconf הראשוני רק קבע את המסגרת והפעולות הבסיסיות של הפרוטוקול, והגדיר פתרונות שלקחו בחשבון כמה בעיות של RFC3535. זה לא קבע שפת דוגמנות מאוחדת. לכן, חלק מהציוד של יצרנים מוקדמים תמך רק בכמה פעולות בסיסיות של Netconf, ולא השתמש בשכבה תחתונה מאוחדת. שפת מודלים של נתונים.
RFC6020 שוחרר בשנת 2010, ומציע את שפת המודלים של YANG Model ושיטה לשילובה עם NETCONF. הגדרה אחת היא שפת מידול נתונים המאחדת את לוגיקית המשאבים הבסיסית בין יצרנים, וההגדרה השנייה היא ערכת פקודות מאוחדת לפעולות של כל יצרן על נתוני תצורה ונתוני סטטוס. מופעי הנתונים שנוצרו על ידי מודל YANG עטופים בפרוטוקול Netconf. שידור, השניים משולבים זה בזה כדי לבנות סט חדש של ממשקים ניתנים לתכנות רשת עבור העידן החדש המבוסס על מודל YANG ומונע על ידי פרוטוקול Netconf.
לאחר 2016, פרוטוקול Netconf השתלב באופן הדוק עם מודל YANG והפך לפופולרי. עד כה, כאשר אנו מסתכלים על כמה היבטי תוכנת ארכיטקטורת SDN, שמענו את שני המונחים הללו פחות או יותר.
YANG ו-Netconf, האחד סטטי והשני דינמי, בדיוק כמו יין ויאנג. השניים גזרו את העולם הניתן לתכנות ברשת של העידן הבא. (כשנסתכל על מחסן YANG ב-github, נגלה גם שהאייקון שלו הוא טאי צ'י, והחיבור בין שמו ל"יאנג" חושף במידת מה את רעיונות העיצוב של המעצב המקורי).
לאחר מכן, נדבר בקצרה על מודל YANG ופרוטוקול Netconf. בואו נדבר תחילה על שפת מודל הנתונים YANG כדי לראות כיצד היא מתארת את התאום הדיגיטלי של עולם הרשת הזה.
דגם YANG
במסמך RFC6020, פרק הפתיחה מציין בבירור, YANG, A Data Modeling Language for the Network Configuration Protocol. זהו הקיצור של Yet Another Next Generation (Yang) Data Modeling Language. זוהי שפת מודלים המשמשת לתיאור מושגי רשת.
תומך בהגדרה של רשימות, מילונים ומבני נתונים מורכבים אף יותר, תומך באילוצים, ספירות, ייבוא הפניות, ניהול גרסאות ומרחבי שמות. מפאת מקום, ניתן הסבר קצר. למידע מפורט, אתה יכול לפנות אל:
זה יכול לתאר את התקן הרשת הזה בפשטות רבה בשפה מובנית. לדוגמה, להגדרה של נמל:
כאנשי תפעול ותחזוקה מקצועיים, עם קצת יסודות רשת וקצת יסודות תכנות, אתה יכול להבין את ההגדרה של נמל בצורה ברורה יחסית. זהו מבנה רשימה, ויכולים להיות מרובים. אחת התכונות שלו היא ממשק-שם (גם מפתח). , ייחודי, שאינו ניתן לחזרה), כמו גם תכונת המהירות ותכונת הדופלקס, שתיהן מחרוזות.
תכונות רבות של התקן רשת מתוארות על ידי דגם YANG, כולל מצב תצורה ומצב הפעלה.
בדרך זו, YANG Model מתאר את העולם המקוון באמצעות שפה מובנית. אם אתה מעוניין, אתה יכול לקרוא את הפוסט בבלוג האינטרנט לעיל, שיש לו תיאור מעמיק מאוד.
ניתן להמיר אותו לנתוני XML בצורה טובה מאוד ולעטוף אותו בפרוטוקול Netconf לשידור (נסביר זאת בהמשך):
במקביל, על מנת ליישר את ההבדלים בין הספקים, חברת Openconfig, בהובלת גוגל, תיקנה את מודל הנתונים. מהאתר הרשמי, אנו רואים את הסלוגן "ניהול רשתות מונעת על ידי ספקים, מונעת על ידי דגמים, מתוכנן על ידי משתמשים", אשר עוצב על ידי משתמשים וחוצה פלטפורמות. תכנות רשת משותף, מונחי דגמים של ספקים (בוא נתרגם את זה קודם כל כך). במילים פשוטות, זה להפוך את הדוגמנות בין יצרנים שונים לזהות, כך שכאשר אתה מגדיר נתונים מסוימים, אתה לא צריך לעיין בדגם היאנג הפרטי של כל יצרן אחד אחד. אבל לאינטרנט תמיד יש פרוטוקולים פרטיים, ויצרנים שונים תמיד ייצרו פרוטוקולים פרטיים חדשים וטובים יותר ל"חווית משתמש טובה יותר" ו"אסטרטגיה עסקית טובה יותר" (זה באמת החטא הקדמון של יצרני הרשתות). התמונה מציגה כמה מימושי מודל ה-openconfig yang הנפוצים יותר.
אם לשפוט מהתמונה, אני חושב שיש די הרבה מהם, והתצורות הנפוצות שלמות יחסית. אבל בפועל, זה תלוי אם היצרן תומך גם בדגמי היאנג הללו. חלק מהמכשירים בגרסה גבוהה יותר של נושא מסוים נתמכים בעיקרון. עדיין לא הסתכלתי מקרוב על אלה הביתיים.
רשתות לא יכולות להיות זהות לחלוטין. למהנדס העוסק בפיתוח תפעול ותחזוקה של הרשת, מבורך להצליח להשיג את אותה מטרה!
ניתן למצוא את openconfig ב-https://github.com/openconfig/public/tree/master/release/models
אתה יכול למצוא דגמי יאנג פרטיים באתרים רשמיים שונים.
פרוטוקול Netconf
אחרי שדיברנו על מודל היאנג, בואו נדבר על פרוטוקול Netconf. מודל היאנג מגדיר את התיאור הדיגיטלי של עולם הרשת, ו-Netconf מגדיר את הרכישה (get) וההתאמה (config) של נתונים.
Netconf מקפלת את נתוני העולם המתוארים על ידי מודל היאנג כדי לממש את ניהול עולם הרשת.
נתוני Yang מובלעים ב-xml ולאחר מכן מנוהלים באמצעות פרוטוקול Netconf. זהו פרוטוקול עם רעיון רב-שכבתי נהדר, המתאר כמה פרטים של הפרוטוקול בצורה היררכית. בואו נסתכל על התמונה למעלה.
-שידור: Netconf מועבר באמצעות פרוטוקול SSH, הוא מכוון חיבור, ויש לו ערבויות אבטחה.
-הודעה: בצע שיחה מרחוק למכשיר הרשת דרך RPC, מנהל הרשת מוציא בקשת rpc, והתקן הרשת חוזר ל-rpc-reply.
-פעולה: זו הנשמה של Netconf. הוא תומך ב-get (נתוני תצורה והרצה), get-config (קבלת נתוני תצורה, ומכשיר יכול לכלול נתוני תצורה מרובים, אחד פועל, אתחול אחד, מספר מועמדים מועמדים), edit -config (הגדר פרמטרים של התקן רשת, תומך בהוספה, מחיקה ושינוי), delete-config, copy-config (העתק את התצורה ליעד, היעד יכול להיות ftp, קובץ או תצורה פועלת וכו'), lock\unlock (נעל את התצורה כדי למנוע התנגשויות תצורה או כשלים שנגרמו על ידי פעולות מרובות תהליכים) וכן הלאה.
-נתונים: הנתונים הם נתוני יאנג עטופים ב-xml. כמו היציאה שתיארנו לעיל, קל לתכנת נתונים מובנים. משמש לתיאור הנתונים שיש להגדיר או למחוק או לקבל.
אלו הן ארבע השכבות של Netconf. קצה הבקרה והתקן הרשת מתקשרים דרך Netconf, דרך פרוטוקול ה-ssh המסורתי, באמצעות מערכת המשנה Netconf, ויציאת ברירת המחדל היא 830. כפי שמוצג להלן:
נתון זה מדגים את האינטראקציה באמצעות ssh גולמי, אך למעשה אנו מיישמים תהליך זה באמצעות תכנות. את שיטת יישום התכנות אדגים לך מאוחר יותר.
Netconf מגדיר התקני רשת. תהליך האינטראקציה הוא בערך כדלקמן:
התמונה הזו כל כך נמוכה, אתה יכול גם לראות שהיא צוירה על ידי... ההבנה שלי של Netconf היא כמו לעיל. אני חושב שיש הרבה תמונות באינטרנט שאינן נכונות, והתנהגויות רבות של סוכן השרת אינן נכונות. זה מה שאני מרגיש באופן אינטואיטיבי כשאני נכנס למכשיר, וזה כמובן מתכתב אחד על אחד עם התיעוד הרשמי.
אנו יכולים להסתכל על כמה דוגמאות של Netconf:
שלום, בנה קישור.
ראינו מספר מילות מפתח, גרסת Netconf, מודל YANG נתמך, מזהה הפעלה. יחד עם זאת, hello מציין באיזה מרחב שמות אנו פועלים. במקרה זה, זוהי הגרסה המקבילה של Netconf.
קבל תצורה
פרמטר אחד של get-cofig הוא source, וזה המקום שבו מתקבלים נתוני התצורה (הפעלה, הפעלה או אחר). פרמטר נוסף הוא פילטר, כלומר אילו נתונים מתקבלים ממודל הנתונים המתואר על ידי איזה מודל יאנג. זה מתאים ליכולת שנשלחה במקור על ידי התקן הרשת. אם תצליח, נתוני התצורה המתאימים יוחזרו.
קבל נתוני תצורה או הפעלה
דומה ל-get-config, אבל מה שמתקבל הוא הפעלת תצורה (הבנה אישית) או הפעלת נתונים. ניתן לציין מסנן.
העתק תצורה
לפעולת ההעתקה יש שני פרמטרים, מקור ויעד. התשובה המוצלחת היא עם התג ok.
ערוך תצורה
בעת עריכת התצורה, ציין את פריט הנתונים שיש לערוך, את מרחב השמות של היכולת והתווית המתאימה. לדוגמה, זה כדי להגדיר את dhcp, שמתואר על ידי מודל היאנג http://tail-f.com/ns/example/dhcp.
סגור את הפגישה בחן
זה סוג זה של מסר שמועבר הלוך ושוב ב-ssh. אנחנו רק מחלצים חלק מהמסר כדי להקל על ההבנה של כולם.
לאחר מכן פשוט הוסף קצת תוכן לעיון.
-Netconf מבוסס על הפעלה, ולכל הצלחה יהיה מזהה הפעלה.
-לכל בקשה יש מזהה הודעה, כל עוד הוא גדל בהדרגה
-תצורת הנתונים יכולה להיות נעולה, בלעדית ומופעלת באמצעות נעילה.
-Netconf הוא טרנזקציונלי, והפעולות מיושמות או אף אחת. יחד עם זאת, על פי התיעוד הרשמי של האתר, טרנזקציונליות זו מיועדת לתצורה של N התקני רשת, כלומר, פולימורפיזם תצורה חד פעמי יכול לתמוך בטרנזקציות. אבל עוד לא עשיתי את זה…
-Netconf תומך במנוי. מבחינת ביצועי המכשיר, סדר הגודל הוא כ-5 מפגשים. אני יכול להירשם לפריט נתונים מסוים והמכשיר יודיע לי כאשר הוא ישתנה.
-יכולת, כך אני מבין את זה. התקן הרשת שולח את הגרסה של Netconf ו-YANG Model, ומסוף הבקרה שולח את הגרסה של Netconf. רק כאשר גרסת Netconf מתאימה לשניים נוכל להמשיך. זו התחושה האינטואיטיבית שלי. כל עצה תתקבל בברכה.
-פעולות כגון get edit יציינו את הנתונים שיש לשנות, אותם ניתן לסנן באמצעות פילטר.
-copy-config תומך בהעתקת סט שלם של תצורות ממקום כלשהו למקום. היכן שהוא יכול להיות קובץ FTP, הפעלה, הפעלה ותצורות מועמדות במכשיר.
-Netconf תומך גם באימות התצורה, באמצעות פעולת האימות.
מאמר זה עדיין מקווה להפוך את המדע לפופולרי, ואני לא אכנס לפרטים. אתה יכול לקרוא את הפרוטוקולים הרלוונטיים של RFC, שהוא למעשה לא ארוך במיוחד.
בפועל, בהתבסס על תוכנות קוד פתוח מסוימות, כמו ncclient של python, נוכל בקלות להגדיר התקני רשת באופן אוטומטי ולהשיג יכולת תכנות ברשת. זו המשימה של Netconf ו-YANG Model.
אנשי הרשת קוראים את הגדרות מודל YANG המעוצבות היטב ומשתמשים בשפות תכנות רלוונטיות לביצוע פעולות הניתנות לתכנות בהתקני רשת בהתבסס על הפעולות שהוגדרו על ידי Netconf. בדרך זו, הנתיב לתכנות הרשת נרקם.
בואו נרחיב ונדמיין שמודל YANG הגדיר את מבנה הנתונים של התקן הרשת. אנחנו יכולים להפעיל אותו דרך Netconf. האם ניתן להפעיל אותו גם באמצעות פרוטוקולים אחרים?
התשובה היא כן. למעשה, פרוטוקולים רבים אחרים נגזרו מ-Netconf, כמו RESTConf. כפי שמוצג מטה,
מודל YANG (ציבורי ומקורי) מגדיר את מבנה הנתונים, מעליו פרוטוקולי ניהול רשת חדשים, Netconf, RESTCon, gRPC וכו'. בדרך זו, נוכל להפעיל התקני רשת דרך RESTConf המבוססים על HTTP RESTful API, נוכל גם להפעיל רשת מכשירים באמצעות Netconf המבוססים על SSH, או שאנו יכולים להפעיל התקני רשת באמצעות gRPC המבוססים על HTTP2.0. כולם מבוססים על YANG עם מבנה נתונים טוב. דגם, כתוב את הנתונים המתאימים, עטוף אותם ב-xml או json כדי לתכנת התקני רשת. זהו העתיד של תכנות הרשת. ליתר דיוק, מדובר ב-Model Driven Program, יכולת תכנות רשת מבוססת מודלים. מהנדסי רשת מתמקדים בהדרגה בפרמטרים של המכשיר במקום בערכת הפקודות, ומגדירים את פרמטרי הרשת על ידי קריאת מודל הנתונים המתאים.
בסוף אני כותב, למה לי לפתוח את החשבון הציבורי הזה. למדתי מדעי המחשב וטכנולוגיה כשהייתי בבית הספר. לאחר כניסתי למקום העבודה עסקתי בעבודות תפעול ותחזוקה של הרשת. כשחושבים על זה, הסיבה שבגללה חולקתי לצוותים עשויה להיות בגלל שהייתי סטודנט לתואר שני במכון המחקר הטכנולוגי ברשת (ידנית מצחיק). מההתחלה עסקתי בתפעול רשתות. בשלב מאוחר יותר של תפעול ותחזוקה נעשה שימוש בכלים לפישוט העבודה ושיפור היעילות על בסיס CLI. מאוחר יותר, הכלים פותחו בהדרגה ליישומי אינטרנט במבנה BS. הם נחשפו כל הזמן לטכנולוגיות חדשות והמשיכו להעשיר פונקציות חדשות.
למרבה המזל, הם הדביקו את הפיתוח של טכנולוגיית קוד פתוח ו-SDN, ובהדרגה עברתי לעבודת NetDevOps והשתמשתי בכישורי התכנות שלי כדי לשפר את יכולות התפעול והתחזוקה של הצוות. נהניתי גם לכתוב את שורת הקוד הזו. ככל שהכתיבה מתקדמת, מתגלה בהדרגה ש-NetDevOps צריכה להיות מיומנות שכל מהנדס רשת צריך להיות לו בעתיד (כולם מוסיפים שמן למדורה), כדי שיוכלו להגיע גם לתכנון ברמה גבוהה וגם ליישום מהיר. כשמסתכלים אחורה על קצת מידע באינטרנט, למען האמת, יש מעט מאוד בסין, והאווירה הביתית לא מאוד חזקה. תוכנות מקומיות רבות מבוססות על ה-CLI וה-snmp הישנים, וכולם עדיין משתמשים בכלי טקסט ובכלי SSH לעבודה. אז אני מקווה שאנייכול ללמד אחרים איך לדוג, לחלוק את הניסיון שלי (בורות) ומיומנויות עם יותר מהנדסי תפעול ותחזוקה של הרשת, ולעשות כמיטב יכולתי. Xiao Chu אמר שאתה יכול ללמוד משהו כדי להפחית את עומס העבודה שלך, ועל ידי התמקדות בעתיד הרחוק, תפעול ותחזוקה של הרשת המקומית יכול באמת להתפתח לעבר אוטומציה.
בעתיד אקליט כמה סרטונים ואכתוב כמה מאמרים. זה מרגיש ממש מתאמץ לכתוב מסמך. אתם מוזמנים להירשם, לאסוף, ללחוץ לייק ולצפות.
נספח: פעולות נפוצות של Netconf
עיצוב פתרון DWDM OTN והצעת מחיר, בבקשה פנה אליי, טיילור הואנג
