L2VPN, VPLS ו-EVPN: השם אינו השירות
הראשי תיבות בטופס ההזמנה נותן שם למשפחה, להתנהגות העברה או למישור בקרה. ארבע שאלות מפרידות ביניהם לפני שתשווה שתי הצעות.
אתם קוראים «L2VPN» בהצעה, אחר כך «VPLS» בגיליון התצורה, ומניחים שהמילה השנייה מצמצמת את הראשונה. לפעמים היא כן, ולפעמים שתי השורות עונות על שאלות לא קשורות. הטעות היא להתייחס לשמות האלה כשלבים בסולם מהבסיסי למתקדם. L2VPN היא משפחה, VPWS ו-VPLS הן שתי התנהגויות שירות בתוכה, ו-EVPN הוא מנגנון של מישור בקרה שיכול לשאת כל אחת מהן.
כל ראשי תיבות עונה על שאלה אחרת
התחילו במה שחיבור הלקוח צריך לעשות, כי זו השאלה היחידה שמודל השירות עונה עליה. מעגל מנקודה לנקודה בין שני אתרים וקטע Ethernet משותף על פני עשרה אתרים הם מוצרים שונים, גם כאשר שניהם נמכרים כקישוריות בשכבה 2.
| Name | Question it answers | What it does not tell you |
|---|---|---|
| L2VPN | Which family of services carries Ethernet frames | Point-to-point or multipoint |
| VPWS | A pair of attachment circuits behaves as one wire | Which control plane builds it |
| VPLS | Many attachments share a bridged broadcast domain | Whether MAC learning is limited or flooded |
| EVPN | BGP distributes MAC and IP reachability | Which service model it is being used for |
הטבלה הזו אינה היררכיה, וקריאה שלה כהיררכיה יוצרת את טעות הרכש הרגילה: להשוות הצעת VPWS להצעת VPLS כאילו השנייה היא הגרסה המלאה יותר של הראשונה. הן פותרות בעיות שונות, ואף אחת מהן אינה על-קבוצה במובן שהקונים מניחים.
VPWS ו-VPLS נפרדות בהחלטת ההעברה
בשירות חוט פרטי וירטואלי, החיבור בוחר את נקודת הקצה המרוחקת. תעבורה שמגיעה לאותו פורט יוצאת אל הפורט המזווג, וקצה הספק אינו צריך ללמוד אילו כתובות MAC נמצאות מאחוריו לצורך החלטת ההעברה הבסיסית.
ב-VPLS, קצה הספק מגשר. הוא בוחן את כתובת MAC היעד של כל פריים, לומד כתובות מקור לכל חיבור, ומציף יעדים לא מוכרים בתוך ה-LAN המדומה. זה מה שגורם לשירות להתנהג כמו LAN, ומשם גם מגיעים המגבלות התפעוליות.
תרשים שנראה רב-נקודתי אינו מוכיח שכל האתרים חולקים תחום שידור אחד. שני ספקים יכולים לצייר את אותו ענן ולמכור תחום מגושר אחד או כמה מעגלים מנקודה לנקודה, וההבדל נראה רק כאשר שידור, פריים unicast לא מוכר או מעבר MAC חוצים גבול אתר. פינג שידור בין שני אתרים עונה על השאלה מהר יותר מכל שקופית ארכיטקטורה. אם התשובות מגיעות מכל אתר אחר, יש לכם גשר אחד; אם רק הזוג עונה, יש לכם חוט.
EVPN הוא מישור בקרה, לא טופולוגיה
מפרט הבסיס של EVPN, RFC 7432, מגדיר נהלי Ethernet VPN מבוססי BGP MPLS: נגישות MAC מוכרזת ב-BGP במקום להילמד רק בהצפה במישור הנתונים. לאחר מכן RFC 8214 מפרט תמיכת VPWS באמצעות EVPN, וזו הנקודה ששוברת את מודל הסולם. אותו מישור בקרה משרת שירות מנקודה לנקודה ושירות רב-נקודתי.
לכן «אנחנו מריצים EVPN» אינה תשובה ל«מה קנינו». הספק עדיין חייב לומר אם השירות הוא זוג חיבורים או גשר משותף, ואם התעבורה היא MPLS, VXLAN או משהו אחר. הבחירות האלה חיות במסמכים שונים ובחלקים שונים של התצורה.
עבור מפעיל, התוצאה המעשית היא שבחירה מוקדמת ב-EVPN מוזילה שינויים עתידיים בשירות, משום שהנגישות כבר מסומנת ולא מוצפת. היא אינה מסירה את הצורך להחליט תחילה על מודל השירות, ואינה מתקנת גשר שהוגדר לא נכון.
MPLS הוא נתיב נתונים, לא ההגדרה
מסמכי המסגרת מתארים את המשפחה ואת דרישותיה; הם אינם דורשים עטיפה אחת. ערימת תוויות MPLS היא תחבורה נפוצה לשירותים האלה, והיא אינה היחידה. שירות שמסומן ב-BGP ונתיב העברה ב-MPLS הם החלטות תכנון נפרדות שרק לעתים קרובות מופיעות יחד.
כשמוכר אומר «MPLS L2VPN», שאלו איזה חצי מתואר. אם התשובה היא רק התחבורה, מודל השירות עדיין לא מוגדר, והתנהגות החיבור עדיין לא ידועה.
ארבע שאלות שהופכות שם לחוזה
שאלו מהי המסירה: פורט, VLAN או צרור VLAN, ומי מהם רשאי לדבר זה עם זה. שאלו אם האתרים חולקים תחום שידור אחד, כי התשובה האחת הזו קובעת הצפה, מגבלות MAC ואיך תתנהג לולאה.
בקשו את תקציב גודל הפריים מקצה לקצה, ואז הוסיפו בעצמכם את תקורת העטיפה. שאלו מה קורה כשחיבור אחד נכשל, אם האחרים ממשיכים להעביר, ואם הספק מושך את הנגישות או משאיר אותה עד שפג טיימר.
כתבו את ארבע התשובות האלה לצד שם המוצר ברשומה שלכם. כשההצעה הבאה מגיעה עם ראשי תיבות אחרים ואותו מחיר, ההשוואה הופכת להשוואה של התנהגות, והיא היחידה שמנבאת מה הרשת תעשה ביום רע.