האם Cisco SD-WAN ינתק את הענף עליו יושב DMVPN?

מאז אוגוסט 2017, כאשר סיסקו רכשה את Viptela, הטכנולוגיה העיקרית המוצעת לארגון רשתות ארגוניות מבוזרות הפכה סיסקו SD-WAN. במהלך 3 השנים האחרונות, טכנולוגיית SD-WAN עברה שינויים רבים, איכותיים וכמותיים כאחד. לפיכך, הפונקציונליות התרחבה משמעותית והופיעה תמיכה בנתבים קלאסיים של הסדרה Cisco ISR 1000, ISR 4000, ASR 1000 ו-Virtual CSR 1000v. במקביל, לקוחות ושותפים רבים של סיסקו ממשיכים לתהות: מה ההבדלים בין Cisco SD-WAN לגישות מוכרות כבר המבוססות על טכנולוגיות כגון סיסקו DMVPN и ניתוב ביצועים של סיסקו ועד כמה ההבדלים הללו חשובים?

כאן עלינו להסתייג מיד שלפני הופעת SD-WAN בפורטפוליו של סיסקו, DMVPN יחד עם PfR היוו חלק מרכזי בארכיטקטורה Cisco IWAN (WAN אינטליגנטי), שבתורו היה קודמו של טכנולוגיית SD-WAN מלאה. למרות הדמיון הכללי הן של המשימות הנפתרות והן של השיטות לפתרונן, IWAN מעולם לא קיבלה את רמת האוטומציה, הגמישות והסקלביליות הדרושה ל-SD-WAN, ועם הזמן, התפתחות ה-IWAN ירדה משמעותית. יחד עם זאת, הטכנולוגיות המרכיבות את IWAN לא נעלמו, ולקוחות רבים ממשיכים להשתמש בהן בהצלחה, כולל בציוד מודרני. כתוצאה מכך נוצר מצב מעניין - אותו ציוד של סיסקו מאפשר לבחור את טכנולוגיית ה-WAN המתאימה ביותר (קלאסית, DMVPN+PfR או SD-WAN) בהתאם לדרישות וציפיות הלקוחות.

המאמר לא מתכוון לנתח בפירוט את כל התכונות של טכנולוגיות Cisco SD-WAN ו-DMVPN (עם או בלי ניתוב ביצועים) - יש כמות עצומה של מסמכים וחומרים זמינים לכך. המשימה העיקרית היא לנסות להעריך את ההבדלים העיקריים בין הטכנולוגיות הללו. אבל לפני שנמשיך לדון בהבדלים הללו, הבה נזכור בקצרה את הטכנולוגיות עצמן.

מהו Cisco DMVPN ומדוע הוא נחוץ?

Cisco DMVPN פותר את בעיית החיבור הדינמי (=ניתן להרחבה) של רשת סניפים מרוחקת לרשת המשרד המרכזי של הארגון בעת ​​שימוש בסוגים שרירותיים של ערוצי תקשורת, לרבות האינטרנט (=עם הצפנה של ערוץ התקשורת). מבחינה טכנית, זה ממומש על ידי יצירת רשת שכבת-על וירטואלית של מחלקת L3 VPN במצב נקודה לריבוי נקודות עם טופולוגיה לוגית מסוג "כוכב" (Hub-n-Spoke). כדי להשיג זאת, DMVPN משתמש בשילוב של הטכנולוגיות הבאות:

• ניתוב IP
• מנהרות GRE מרובות נקודות (mGRE)
• Next Hop Resolution Protocol (NHRP)
• פרופילי IPSec Crypto

מהם היתרונות העיקריים של Cisco DMVPN בהשוואה לניתוב קלאסי באמצעות ערוצי MPLS VPN?

• ליצירת רשת בין-סניפית אפשר להשתמש בכל ערוצי תקשורת - כל דבר שיכול לספק קישוריות IP בין סניפים מתאים, בעוד התעבורה תהיה מוצפנת (במידת הצורך) ומאוזנת (במידת האפשר)
• נוצרת אוטומטית טופולוגיה מחוברת מלאה בין ענפים. במקרה זה קיימות מנהרות סטטיות בין הסניף המרכזי למרוחק, ומנהרות דינמיות לפי דרישה בין הסניפים המרוחקים (אם יש תנועה)
• לנתבים של הסניף המרכזי והמרוחק יש אותה תצורה עד לכתובות ה-IP של הממשקים. על ידי שימוש ב-mGRE, אין צורך להגדיר בנפרד עשרות, מאות או אפילו אלפי מנהרות. כתוצאה מכך, מדרגיות הגונה עם העיצוב הנכון.

מהו Cisco Performance Routing ולמה הוא נחוץ?

בעת שימוש ב-DMVPN ברשת בין-ענפית, נותרה שאלה חשובה ביותר לא פתורה - כיצד להעריך באופן דינמי את המצב של כל אחת ממנהרות ה-DMVPN לצורך עמידה בדרישות התעבורה הקריטיות לארגון שלנו, ושוב, בהתבסס על הערכה כזו, לבצע באופן דינמי החלטה על שינוי מסלול? העובדה היא ש-DMVPN בחלק זה שונה מעט מהניתוב הקלאסי - הדבר הטוב ביותר שניתן לעשות הוא להגדיר מנגנוני QoS שיאפשרו לך לתעדף את התעבורה בכיוון היוצא, אך אינם מסוגלים בשום אופן לקחת בחשבון את המצב של את כל הדרך בזמן זה או אחר.

ומה לעשות אם הערוץ מתדרדר באופן חלקי ולא לגמרי - איך לזהות ולהעריך זאת? DMVPN עצמו לא יכול לעשות זאת. בהתחשב בכך שהערוצים המחברים בין סניפים יכולים לעבור דרך מפעילי טלקום שונים לחלוטין, תוך שימוש בטכנולוגיות שונות לחלוטין, משימה זו הופכת להיות מאוד לא טריוויאלית. וכאן באה להציל את טכנולוגיית Cisco Performance Routing, שעד אז כבר עברה כמה שלבי פיתוח.

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

לפיכך, ניתן לתאר בקצרה את המשימה של שילוב DMVPN/PfR באופן הבא:

• אפשר ללקוח להשתמש בכל ערוצי תקשורת ברשת ה-WAN
• הבטח את האיכות הגבוהה ביותר האפשרית של יישומים קריטיים בערוצים אלה

מה זה סיסקו SD-WAN?

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

במקרה של SD-WAN, המשימה של שימוש בכל סוגי הערוצים והבטחת פעולת האפליקציות העסקיות נשארת זהה, אך במקביל, הדרישות לאוטומציה, מדרגיות, אבטחה וגמישות של רשת כזו מתרחבות.

דיון בהבדלים

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

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

מהם ההבדלים האדריכליים והאם הם חשובים?

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

בואו נסתכל על ההיבטים השונים של הארכיטקטורה ביתר פירוט:

מישור נתונים – חלק מהפתרון האחראי על העברת תעבורת משתמשים בין המקור לנמען. DMVPN ו-SD-WAN מיושמים בדרך כלל באופן זהה על הנתבים עצמם בהתבסס על מנהרות Multipoint GRE. ההבדל הוא כיצד נוצר סט הפרמטרים הנחוץ עבור המנהרות הללו:

• в DMVPN/PfR הוא היררכיה דו-מפלסית בלבד של צמתים עם טופולוגיה של Star או Hub-n-Spoke. נדרשות תצורה סטטית של ה-Hub וקשירה סטטית של Spoke ל-Hub, כמו גם אינטראקציה באמצעות פרוטוקול NHRP ליצירת קישוריות במישור נתונים. כתוצאה מכך, מה שמקשה משמעותית על השינויים ב-Hubקשור, למשל, לשינוי/חיבור ערוצי WAN חדשים או שינוי פרמטרים של ערוצי WAN קיימים.
• в SD-WAN הוא מודל דינמי לחלוטין לאיתור פרמטרים של מנהרות מותקנות המבוסס על מטוס שליטה (פרוטוקול OMP) ומישור תזמור (אינטראקציה עם בקר vBond לזיהוי בקר ומשימות חציית NAT). במקרה זה, ניתן להשתמש בכל טופולוגיות מועלות, כולל היררכיות. בתוך טופולוגיית מנהרת השכבה המבוססת, אפשרית תצורה גמישה של הטופולוגיה הלוגית בכל VPN(VRF) בנפרד.

מטוס בקרה - פונקציות של החלפה, סינון ושינוי של ניתוב ומידע אחר בין רכיבי הפתרון.

• в DMVPN/PfR - מבוצע רק בין נתבי Hub ו- Spoke. החלפה ישירה של מידע ניתוב בין דוברות אינה אפשרית. כתוצאה מכך, ללא רכזת מתפקדת, מישור הבקרה ומישור הנתונים אינם יכולים לתפקד, מה שמטיל על ה-Hub דרישות נוספות של זמינות גבוהה שלא תמיד ניתן לעמוד בהן.
• в SD-WAN – מטוס שליטה לעולם לא מתבצע ישירות בין נתבים – אינטראקציה מתרחשת על בסיס פרוטוקול OMP ומתבצעת בהכרח באמצעות סוג מיוחד נפרד של בקר vSmart, המספק אפשרות לאיזון, שמירה גיאוגרפית ובקרה מרוכזת של עומס אות. מאפיין נוסף של פרוטוקול OMP הוא עמידותו המשמעותית להפסדים ואי תלות ממהירות ערוץ התקשורת עם בקרים (בגבולות הסבירים, כמובן). מה שמאפשר באותה מידה בהצלחה למקם בקרי SD-WAN בעננים ציבוריים או פרטיים עם גישה דרך האינטרנט.

מישור מדיניות – חלק מהפתרון האחראי על הגדרה, הפצה ויישום מדיניות ניהול תעבורה ברשת מבוזרת.

• DMVPN - מוגבלת למעשה על ידי מדיניות איכות השירות (QoS) המוגדרת בנפרד בכל נתב באמצעות תבניות CLI או Prime Infrastructure.
• DMVPN/PfR – מדיניות PfR נוצרת בנתב ה-Master Controller (MC) המרכזי דרך ה-CLI ולאחר מכן מופצת אוטומטית ל-MCs סניפים. במקרה זה, נעשה שימוש באותם נתיבים להעברת מדיניות כמו עבור מישור הנתונים. אין אפשרות להפריד בין חילופי מדיניות, מידע ניתוב ונתוני משתמשים. הפצת מדיניות דורשת נוכחות של קישוריות IP בין ה-Hub ל-Speak. במקרה זה, ניתן לשלב את פונקציית MC במידת הצורך עם נתב DMVPN. אפשר (אך לא חובה) להשתמש בתבניות Prime Infrastructure ליצירת מדיניות מרוכזת. תכונה חשובה היא שהמדיניות נוצרת ברחבי הרשת באותו אופן - אין תמיכה במדיניות פרטנית עבור פלחים בודדים.
• SD-WAN – מדיניות ניהול התעבורה ואיכות השירות נקבעת באופן מרכזי באמצעות הממשק הגרפי של Cisco vManage, הנגיש גם דרך האינטרנט (במידת הצורך). הם מופצים דרך ערוצי איתות באופן ישיר או עקיף באמצעות בקרי vSmart (בהתאם לסוג המדיניות). הם אינם תלויים בקישוריות מטוס נתונים בין נתבים, כי השתמש בכל נתיבי התעבורה הזמינים בין הבקר לנתב.

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

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

• в DMVPN/PfR גילוי הדדי בין נתבים מבוסס על התצורה הסטטית של התקני Hub ועל התצורה המתאימה של התקני Spoke. גילוי דינמי מתרחש רק עבור Spoke, אשר מדווח על פרמטרי החיבור של Hub למכשיר, אשר בתורו מוגדר מראש עם Spoke. ללא קישוריות IP בין Spoke לרכזת אחת לפחות, אי אפשר ליצור מישור נתונים או מישור בקרה.
• в SD-WAN תזמור של רכיבי פתרון מתרחש באמצעות בקר vBond, איתו כל רכיב (נתבים ובקרי vManage/vSmart) חייב ליצור תחילה קישוריות IP.

  בתחילה, הרכיבים אינם יודעים על פרמטרי החיבור של זה - לשם כך הם צריכים את מתזמר המתווך vBond. העיקרון הכללי הוא כדלקמן - כל רכיב בשלב הראשוני לומד (אוטומטי או סטטי) רק על פרמטרי החיבור ל-vBond, לאחר מכן vBond מודיע לנתב על בקרי vManage ו-vSmart (שנתגלו קודם), מה שמאפשר להקים אוטומטית כל חיבורי האיתות הדרושים.

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

מטוס ניהול – חלק מהפתרון המספק ניהול וניטור מרכזי.

• DMVPN/PfR - לא מסופק פתרון מטוס ניהול מיוחד. עבור אוטומציה וניטור בסיסיים, ניתן להשתמש במוצרים כגון Cisco Prime Infrastructure. לכל נתב יש יכולת שליטה באמצעות שורת הפקודה CLI. אינטגרציה עם מערכות חיצוניות באמצעות API אינה מסופקת.
• SD-WAN - כל האינטראקציה והניטור הרגילים מתבצעים באופן מרכזי באמצעות הממשק הגרפי של בקר vManage. כל התכונות של הפתרון, ללא יוצא מן הכלל, זמינות להגדרה דרך vManage, כמו גם דרך ספריית REST API מתועדת במלואה.

  כל הגדרות רשת SD-WAN ב-vManage מסתכמות בשני מבנים עיקריים - היווצרות תבניות מכשיר (Device Template) ויצירת מדיניות הקובעת את ההיגיון של פעולת הרשת ועיבוד התעבורה. במקביל, vManage, המשדרת את המדיניות שנוצרה על ידי המנהל, בוחרת אוטומטית אילו שינויים ובאילו מכשירים/בקרים בודדים צריכים להתבצע, מה שמגביר משמעותית את היעילות והסקלביליות של הפתרון.

  דרך ממשק vManage זמינה לא רק תצורה של פתרון Cisco SD-WAN, אלא גם ניטור מלא של המצב של כל מרכיבי הפתרון, עד למצב הנוכחי של מדדים עבור מנהרות בודדות וסטטיסטיקה על השימוש באפליקציות שונות. מבוסס על ניתוח DPI.

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

אבטחה משולבת - כאן אנחנו צריכים לדבר לא רק על ההגנה על נתוני משתמש בעת שידור בערוצים פתוחים, אלא גם על האבטחה הכוללת של רשת ה-WAN המבוססת על הטכנולוגיה שנבחרה.

• в DMVPN/PfR אפשר להצפין נתוני משתמש ופרוטוקולי איתות. בעת שימוש בדגמי נתב מסוימים, פונקציות חומת אש עם בדיקת תנועה, IPS/IDS זמינות בנוסף. ניתן לפלח רשתות סניפים באמצעות VRF. אפשר לאמת פרוטוקולי בקרה (חד פקטור).

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

• в SD-WAN באנלוגיה ל-DMVPN, ניתנת היכולת להצפין נתוני משתמש, אך עם אבטחת רשת מורחבת משמעותית ופונקציות פילוח L3/VRF (חומת אש, IPS/IDS, סינון כתובת URL, סינון DNS, AMP/TG, SASE, TLS/SSL proxy, וכו') ד.). במקביל, החלפת מפתחות ההצפנה מתבצעת בצורה יעילה יותר באמצעות בקרי vSmart (ולא ישירות), באמצעות ערוצי איתות שהוגדרו מראש המוגנים על ידי הצפנת DTLS/TLS המבוססת על תעודות אבטחה. מה שבתורו מבטיח את האבטחה של מרכזיות כאלה ומבטיח מדרגיות טובה יותר של הפתרון עד לעשרות אלפי מכשירים באותה רשת.

  כל חיבורי האיתות (בקר-בקר, בקר-נתב) מוגנים גם הם על בסיס DTLS/TLS. נתבים מצוידים בתעודות בטיחות במהלך הייצור עם אפשרות להחלפה/הרחבה. אימות דו-גורמי מושג באמצעות מילוי חובה ובו-זמנית של שני תנאים עבור הנתב/בקר לתפקד ברשת SD-WAN:

  • תעודת אבטחה תקפה
  • הכללה מפורשת ומודעת על ידי המנהל של כל רכיב ברשימה ה"לבנה" של המכשירים המותרים.

הבדלים תפקודיים בין SD-WAN ו-DMVPN/PfR

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

AppQ (Application Quality) - פונקציות כדי להבטיח את איכות השידור של תעבורת יישומים עסקיים

פונקציות המפתח של הטכנולוגיות הנחשבות מכוונות לשיפור חווית המשתמש ככל האפשר בעת שימוש ביישומים קריטיים לעסקים ברשת מבוזרת. זה חשוב במיוחד בתנאים שבהם חלק מהתשתית אינו נשלט על ידי IT או אפילו אינו מבטיח העברת נתונים מוצלחת.

DMVPN אינו מספק בעצמו מנגנונים כאלה. הטוב ביותר שניתן לעשות ברשת DMVPN קלאסית הוא לסווג תעבורה יוצאת לפי אפליקציה ולתעדף אותה כאשר היא משודרת לעבר ערוץ ה-WAN. הבחירה במנהרת DMVPN נקבעת במקרה זה רק על פי זמינותה והתוצאה של פעולת פרוטוקולי הניתוב. יחד עם זאת, המצב מקצה לקצה של הנתיב/מנהרה והשפלה החלקית האפשרית שלו אינם נלקחים בחשבון מבחינת מדדי מפתח משמעותיים עבור יישומי רשת - השהיה, וריאציה של עיכוב (ריצוד) והפסדים (% ). בהקשר זה, השוואה ישירה של DMVPN קלאסי עם SD-WAN במונחים של פתרון בעיות AppQ מאבדת כל משמעות - DMVPN לא יכול לפתור בעיה זו. כאשר אתה מוסיף את טכנולוגיית Cisco Performance Routing (PfR) להקשר זה, המצב משתנה וההשוואה עם Cisco SD-WAN הופכת למשמעותית יותר.

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

• יש מנגנון המאפשר לך להעריך באופן דינמי את המצב של כל מנהרה שהוקמה במונחים של מדדים מסוימים - לכל הפחות, עיכוב, שינוי עיכוב ואובדן מנות (%)
• השתמש בסט ספציפי של כלים כדי ליצור, להפיץ ולהחיל כללי ניהול תנועה (מדיניות), תוך התחשבות בתוצאות של מדידת מצב מדדי המנהרה העיקריים.
• סיווג תעבורת יישומים ברמות L3-L4 (DSCP) של מודל OSI או לפי חתימות אפליקציות L7 המבוססות על מנגנוני DPI המובנים בנתב
• עבור יישומים משמעותיים, הם מאפשרים לך לקבוע ערכי סף מקובלים של מדדים, כללים להעברת תעבורה כברירת מחדל, וכללים לניתוב מחדש של תעבורה כאשר ערכי הסף חורגים.
• כאשר מקפלים תעבורה ב-GRE/IPSec, הם משתמשים במנגנון שכבר הוקם בתעשייה להעברת סימון DSCP פנימי לכותרת החבילה החיצונית של GRE/IPSEC, המאפשרת סנכרון של מדיניות ה-QoS של הארגון ושל מפעיל הטלקום (אם יש SLA מתאים) .

כיצד נבדלים מדדי SD-WAN ו-DMVPN/PfR מקצה לקצה?

DMVPN/PfR

• הן חיישני תוכנה אקטיביים והן פסיביים (Probes) משמשים להערכת מדדי בריאות סטנדרטיים של המנהרה. הפעילים מבוססים על תעבורת משתמשים, הפסיביים מחקים תעבורה כזו (בהיעדרה).
• אין כוונון עדין של טיימרים ותנאי זיהוי השפלה - האלגוריתם קבוע.
• בנוסף, זמינה מדידה של רוחב הפס בשימוש בכיוון היוצא. מה שמוסיף גמישות נוספת לניהול תעבורה ל-DMVPN/PfR.
• יחד עם זאת, חלק ממנגנוני ה-PfR, כאשר חורגים מדדים, מסתמכים על איתות משוב בצורה של הודעות TCA מיוחדות (Threshold Crossing Alert) שצריכות להגיע מנמען התעבורה לכיוון המקור, אשר בתורו מניח שמצב ערוצים נמדדים צריכים להספיק לפחות לשידור של הודעות TCA כאלה. מה שברוב המקרים אינו מהווה בעיה, אך ברור שלא ניתן להבטיח זאת.

SD-WAN

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

  

• בזמן כתיבת שורות אלה, יש רק מפגש BFD אחד בכל מנהרה. זה עשוי ליצור פחות פירוט בניתוח מצב המנהרה. במציאות, זה יכול להפוך למגבלה רק אם אתה משתמש בחיבור WAN המבוסס על MPLS L2/L3 VPN עם SLA QoS מוסכם - אם סימון DSCP של תעבורת BFD (לאחר אנקפסולציה ב-IPSec/GRE) תואם לתור בעדיפות גבוהה ב הרשת של מפעיל הטלקום, אז זה עשוי להשפיע על הדיוק ומהירות זיהוי השפלה עבור תעבורה בעדיפות נמוכה. במקביל, ניתן לשנות את תווית ברירת המחדל של BFD כדי להפחית את הסיכון למצבים כאלה. בגרסאות עתידיות של תוכנת Cisco SD-WAN, צפויות הגדרות BFD מכוונות יותר, כמו גם יכולת להפעיל מספר הפעלות BFD בתוך אותה מנהרה עם ערכי DSCP בודדים (עבור יישומים שונים).
• BFD מאפשר לך בנוסף להעריך את גודל החבילה המקסימלי שניתן להעביר דרך מנהרה מסוימת ללא פיצול. זה מאפשר ל-SD-WAN להתאים באופן דינמי פרמטרים כגון MTU ו-TCP MSS Adjust כדי להפיק את המרב מרוחב הפס הזמין בכל קישור.
• ב-SD-WAN זמינה גם אפשרות לסנכרון QoS ממפעילי טלקום, לא רק על בסיס שדות L3 DSCP, אלא גם על בסיס ערכי L2 CoS, אותם ניתן להפיק אוטומטית ברשת הסניפים על ידי מכשירים מיוחדים - למשל, IP טלפונים

במה שונות היכולות, השיטות להגדרה ויישום של מדיניות AppQ?

מדיניות DMVPN/PfR:

• מוגדר בנתב/ים הסניף המרכזי באמצעות שורת הפקודה של CLI או תבניות תצורת CLI. יצירת תבניות CLI דורשת הכנה וידע בתחביר המדיניות.

  

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

מדיניות SD-WAN:

• מוגדר ב-vManage GUI באמצעות אשף התבניות האינטראקטיביות.
• תומך ביצירת פוליסות מרובות, העתקה, הורשת, מעבר בין פוליסות בזמן אמת.
• תומך בהגדרות מדיניות בודדות עבור מקטעי רשת שונים (סניפים)
• הם מופצים באמצעות כל ערוץ אות זמין בין הבקר לנתב ו/או vSmart - אינם תלויים ישירות בקישוריות מישור הנתונים בין הנתבים. זה, כמובן, מצריך קישוריות IP בין הנתב עצמו לבקרים.

  

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

    

  • שכפול של זרמי נתונים – בנוסף ל-FEC, הפוליסה יכולה לספק שכפול אוטומטי של תעבורה של אפליקציות נבחרות במקרה של רמה חמורה עוד יותר של הפסדים שלא ניתן לפצות על ידי FEC. במקרה זה, הנתונים שנבחרו ישודרו דרך כל המנהרות לעבר הסניף המקבל עם ביטול כפילויות לאחר מכן (השמטת עותקים נוספים של מנות). המנגנון מגביר משמעותית את ניצול הערוצים, אך גם מעלה משמעותית את אמינות השידור.

יכולות SD-WAN של Cisco, ללא אנלוגים ישירים ב-DMVPN/PfR

הארכיטקטורה של פתרון Cisco SD-WAN מאפשרת במקרים מסוימים להשיג יכולות שקשה מאוד ליישם בתוך DMVPN/PfR, או שאינן מעשיות עקב עלויות העבודה הנדרשות, או שהן בלתי אפשריות לחלוטין. בואו נסתכל על המעניין שבהם:

הנדסת תנועה (TE)

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

הקושי ביישום TE טמון בצורך לחשב ולשריין (לבדוק) נתיב חלופי מראש. ברשתות MPLS של מפעילי טלקום, בעיה זו נפתרת באמצעות טכנולוגיות כמו MPLS Traffic-Engineering עם הרחבות של פרוטוקולי IGP ופרוטוקול RSVP. כמו כן, לאחרונה, טכנולוגיית Segment Routing, אשר מותאמת יותר לתצורה ותזמור מרכזיים, הפכה לפופולרית יותר ויותר. ברשתות WAN קלאסיות, טכנולוגיות אלו בדרך כלל אינן מיוצגות או מופחתות לשימוש במנגנוני הופ-אחר-הופ כמו ניתוב מבוסס-מדיניות (PBR), אשר מסוגלים להסיע תעבורה, אך מיישמים זאת על כל נתב בנפרד - מבלי לקחת לקחת בחשבון את המצב הכללי של הרשת או תוצאת PBR בשלבים הקודמים או הבאים. התוצאה של שימוש באפשרויות TE אלה מאכזבת - MPLS TE, בשל מורכבות התצורה והתפעול, משמש, ככלל, רק בחלק הקריטי ביותר של הרשת (הליבה), ו-PBR משמש בנתבים בודדים ללא היכולת ליצור מדיניות PBR מאוחדת עבור הרשת כולה. ברור שזה חל גם על רשתות מבוססות DMVPN.

SD-WAN בהקשר זה מציע פתרון הרבה יותר אלגנטי שלא רק קל להגדיר, אלא גם קנה מידה הרבה יותר טוב. זו תוצאה של ארכיטקטורות מישור הבקרה והמדיניות בשימוש. יישום מישור מדיניות ב-SD-WAN מאפשר לך להגדיר באופן מרכזי את מדיניות TE - איזו תעבורה מעניינת? עבור אילו VPNs? דרך אילו צמתים/מנהרות יש צורך או להיפך, אסור ליצור מסלול חלופי? בתורו, הריכוזיות של ניהול מטוסי בקרה המבוססת על בקרי vSmart מאפשרת לך לשנות את תוצאות הניתוב מבלי להזדקק להגדרות של מכשירים בודדים - נתבים כבר רואים רק את התוצאה של ההיגיון שנוצר בממשק vManage והועבר לשימוש ל vSmart.

שרשרת שירות

יצירת רשתות שירות היא משימה עתירת עבודה אפילו יותר בניתוב קלאסי מאשר מנגנון הנדסת תנועה שתואר כבר. ואכן, במקרה זה, יש צורך לא רק ליצור מסלול מיוחד עבור יישום רשת ספציפי, אלא גם להבטיח את היכולת להסיר תעבורה מהרשת על צמתים מסוימים (או כל) של רשת SD-WAN לעיבוד על ידי יישום או שירות מיוחד (חומת אש, איזון, מטמון, תעבורת בדיקה וכו'). יחד עם זאת, יש צורך להיות מסוגל לשלוט במצב השירותים החיצוניים הללו על מנת למנוע מצבי חורים שחורים, ויש צורך גם במנגנונים המאפשרים להציב שירותים חיצוניים מסוג זה במיקומים גיאוגרפיים שונים. עם היכולת של הרשת לבחור אוטומטית את צומת השירות האופטימלי ביותר לעיבוד התעבורה של סניף מסוים. במקרה של Cisco SD-WAN, זה די קל להשיג על ידי יצירת מדיניות מרוכזת מתאימה ש"מדביקה" את כל ההיבטים של שרשרת שירות היעד למכלול אחד ומשנה אוטומטית את הלוגיקה של מישור הנתונים ומישור הבקרה רק כאשר ובעת הצורך.

היכולת ליצור עיבוד גיאוגרפי של תעבורה של סוגי יישומים נבחרים ברצף מסוים על ציוד מיוחד (אך לא קשור לרשת SD-WAN עצמה) היא אולי ההדגמה הברורה ביותר של היתרונות של Cisco SD-WAN על פני קלאסי טכנולוגיות ואפילו כמה פתרונות SD חלופיים -WAN מיצרנים אחרים.

התוצאה?

ברור, גם DMVPN (עם או בלי ניתוב ביצועים) וגם של Cisco SD-WAN בסופו של דבר פותרים בעיות מאוד דומות ביחס לרשת ה-WAN המבוזרת של הארגון. במקביל, הבדלים ארכיטקטוניים ותפקודיים משמעותיים בטכנולוגיית Cisco SD-WAN מובילים לתהליך פתרון הבעיות הללו לרמת איכות אחרת. לסיכום, אנו יכולים לציין את ההבדלים המשמעותיים הבאים בין טכנולוגיות SD-WAN ו-DMVPN/PfR:

• DMVPN/PfR משתמשים באופן כללי בטכנולוגיות שנבדקו בזמן לבניית רשתות VPN שכבת על, ומבחינת מישור הנתונים, דומים לטכנולוגיית SD-WAN המודרנית יותר, עם זאת, ישנן מספר מגבלות בצורה של תצורה סטטית חובה של נתבים והבחירה בטופולוגיות מוגבלת ל- Hub-n-Spoke. מצד שני, ל-DMVPN/PfR יש פונקציונליות כלשהי שעדיין לא זמינה בתוך SD-WAN (אנחנו מדברים על BFD לכל אפליקציה).
• בתוך מישור הבקרה, הטכנולוגיות שונות מהותית. בהתחשב בעיבוד הריכוזי של פרוטוקולי איתות, SD-WAN מאפשר, בפרט, לצמצם משמעותית תחומי כשל ו"לנתק" את תהליך העברת תעבורת המשתמש מאינטראקציית איתות - חוסר זמינות זמנית של בקרים אינה משפיעה על היכולת להעביר תעבורת משתמשים . יחד עם זאת, חוסר הזמינות הזמנית של סניף כלשהו (כולל המרכזי) אינה משפיעה בשום אופן על יכולתם של סניפים אחרים לקיים אינטראקציה זה עם זה ועם בקרים.
• הארכיטקטורה להיווצרות ויישום של מדיניות ניהול תעבורה במקרה של SD-WAN עדיפה גם על זו ב-DMVPN/PfR - שמירה גיאוגרפית מיושמת הרבה יותר טוב, אין קשר ל-Hub, יש יותר הזדמנויות לקנס -כוונון מדיניות, רשימת תרחישי ניהול התעבורה המיושמים היא גם הרבה יותר גדולה.
• גם תהליך תזמור הפתרונות שונה באופן משמעותי. DMVPN מניח נוכחות של פרמטרים ידועים בעבר שחייבים לבוא לידי ביטוי איכשהו בתצורה, מה שמגביל במידה מסוימת את הגמישות של הפתרון ואת האפשרות לשינויים דינמיים. בתורו, SD-WAN מבוסס על הפרדיגמה שברגע החיבור הראשוני, הנתב "לא יודע כלום" על הבקרים שלו, אבל יודע "את מי אתה יכול לשאול" - זה מספיק לא רק כדי ליצור תקשורת אוטומטית עם הבקרים, אלא גם ליצירת אוטומטית של טופולוגיית מישור נתונים מחוברת במלואה, שאותה ניתן להגדיר/לשנות בצורה גמישה באמצעות מדיניות.
• במונחים של ניהול מרכזי, אוטומציה וניטור, SD-WAN צפוי לעלות על היכולות של DMVPN/PfR, שהתפתחו מטכנולוגיות קלאסיות ונשענות יותר על שורת הפקודה CLI ועל השימוש במערכות NMS מבוססות תבניות.
• ב-SD-WAN, בהשוואה ל-DMVPN, דרישות האבטחה הגיעו לרמה איכותית שונה. העקרונות העיקריים הם אפס אמון, מדרגיות ואימות דו-גורמי.

המסקנות הפשוטות הללו עשויות ליצור רושם מוטעה שיצירת רשת המבוססת על DMVPN/PfR איבדה כל רלוונטיות כיום. זה כמובן לא לגמרי נכון. לדוגמה, במקרים בהם הרשת משתמשת בציוד רב מיושן ואין דרך להחליף אותו, DMVPN יכול לאפשר לך לשלב התקנים "ישנים" ו"חדשים" לרשת אחת מבוזרת גיאוגרפית עם רבים מהיתרונות שתוארו מֵעַל.

מצד שני, צריך לזכור שכל הנתבים הארגוניים הנוכחיים של סיסקו המבוססים על IOS XE (ISR 1000, ISR 4000, ASR 1000, CSR 1000v) תומכים היום בכל מצב הפעלה - גם ניתוב קלאסי וגם DMVPN ו-SD-WAN - הבחירה נקבעת על פי הצרכים הנוכחיים וההבנה שבכל רגע, באמצעות אותו ציוד, ניתן להתחיל להתקדם לעבר טכנולוגיה מתקדמת יותר.

מקור: www.habr.com