מה צריך להיות מיושר לפני ש-MX יכול לסיים IPsec
Commit שמקבל את התצורה מוכיח את המנתח, לא את הנתיב. חמישה חלקים של טאפל הפלטפורמה קובעים אם השירות באמת רץ.
התצורה מתבצעת ב-commit נקי, הממשקים עולים, והמנהרה עדיין מסרבת להיווצר. שום שורה ביומן לא אומרת שהפלטפורמה לא יכולה לעשות זאת; היא פשוט לא עושה זאת. ב-Junos, IPsec הוא שירות שרק שילוב מסוים של שאסי, חומרת שירות או נתיב תוכנה, וגרסה יכול לבצע, ועמוד תכונה מתאר את היכולת של התוכנה, לא את שלכם. את הטאפל יש לבדוק חלק אחר חלק, כי תוצאת commit מוכיחה רק את המנתח.
לאן החבילה באמת הולכת
התעבורה שנבחרה ל-IPsec חייבת להגיע לרכיב שמצפין אותה. בפלטפורמות עם מודול שירותים, הזרימה הנבחרת מנותבת למודול הזה ואז חוזרת לנתיב ההעברה. אם המודול חסר, קטן מדי או לא מחובר לממשק, התצורה קיימת ואף חבילה לא מעובדת. שום דבר בפלט ה-commit לא מבדיל בין המקרה הזה למקרה תקין.
מימושים המתארחים בתוכנה משאירים את העבודה על מנוע הניתוב או בחומרה מוטמעת, עם מגבלות משאבים שונים מאוד. מנהרה שנראית בתצורה לא אומרת לכם איזה מן הנתיבים האלה באמת נושא אותה.
חמשת חלקי הטאפל
רשמו את השילוב לפני שאתם קוראים המלצה כלשהי, כי חלק אחד יכול לבטל את האחרים. מספר חלק שתמך בשירות לפני שלוש שנים לא אומר דבר על הכרטיס והגרסה בשאסי הזה. קראו את השורות שלמטה כרשימת בדיקה, ואז מלאו את הערכים שהתצורה לא יכולה להראות לכם.
| Part | What to record | Where it fails quietly |
|---|---|---|
| Chassis and service hardware | Model plus the installed PIC, MPC or MIC | Card absent or not bound to the interface |
| Implementation | Services card, inline or software path | Configuration accepted, no processing |
| Release | Exact Junos version | The feature arrives in a later build |
| Address families and mode | Outer and inner family, tunnel mode, peer authentication | Half the traffic silently unprotected |
| Entitlement and capacity | Licence state and the workload profile | Ceiling reached only under load |
משפחות הכתובות ועומס העבודה הם שתי השורות שאנשים מדלגים עליהן, ושתיהן זולות לבדיקה ויקרות לגילוי מאוחר. קראו את הטאפל מהמכשיר ולא מגיליון אלקטרוני, כי תצורה מדווחת מה ביקשתם, לא מה שמותקן. שתי פקודות נושאות את רוב המידע: show chassis hardware מציין את הכרטיס שבאמת מותקן, ו-show version נותן את הגרסה המדויקת. אף אחת מהן לא תלויה בכך שהתצורה נכונה, וזו בדיוק הנקודה.
show chassis hardware
show versionספי גרסה הם ספים אמיתיים
פרט הגרסה אינו פורמליות. סקירת IPsec של Juniper מתארכת את התמיכה ב-AES-GCM לכרטיסים מרובי שירותים ל-Junos 17.3R1, כאשר מצב FIPS מתחיל ב-17.4R1. לכן לאותה תכונה יש שני ספים בהתאם לאופן שבו הפלטפורמה מופעלת, והמצב שאתם מריצים קובע איזה מהם חל. בדקו את המצב לפני שתבדקו את רשימת התכונות.
קראו את הערות הגרסה עבור הגרסה המותקנת במדויק, לא עבור החדשה ביותר המתועדת. יכולת שהגיעה ב-build מאוחר יותר לא ניתן להניח שהיא קיימת בקודמת, והצהרה שנכתבה עבור כרטיס אחד לא עוברת לאחר. העתיקו את השורה מהערות הגרסה לרשומת התכנון כדי שהטענה תישא את המקור שלה, כי הצהרת תמיכה שנכתבה עבור משפחת פלטפורמות אינה הצהרה על המצב שאתם מריצים או על הכרטיס שיש לכם.
קיבולת היא עומס עבודה, לא כותרת
מספר תפוקה בכותרת בלי תנאי המדידה שלו הוא מספר שיווקי. חבילות קטנות עולות הרבה יותר לביט מחבילות גדולות, אסוציאציות במקביל צורכות זיכרון, וכל שירות אחר שחולק את הכרטיס מקטין את מה שנשאר.
העריכו מהתעבורה שאתם מצפים לה: גדלי חבילה טיפוסיים וגרועים ביותר, מספר העמיתים, והאם הכרטיס הזה מסיים גם NAT או שירות אחר. אחר כך השאירו מרווח ליום שבו נתיב אחד יישא עומס גדול ממה שהתכנון הניח. תוכנית קיבולת שמניחה חומרה לא פעילה היא משאלה, לא תוכנית. אם המספר חשוב למקרה העסקי, מדדו אותו פעם אחת במכשיר תחת עומס מייצג ושמרו את המדידה יחד עם התכנון.
כתבו את הרשומה לפני התכנון
לכל יכולת שהתכנון צריך, החזיקו את הפניה לפלטפורמה, את התיעוד המתאים לגרסה וכל הגבלה לא פתורה במקום אחד. כאשר שורה של הטאפל נכשלת, השוו שער אחר שאושר במקום לבנות מחדש את התכנון סביב רשימת קניות מיושנת. הרשומה צריכה לומר איזו מערכת בדיוק מבצעת את העבודה ובאילו גבולות.
רק אחר כך בדקו את העמית, כי תאימות פרוטוקול עם הקצה המרוחק היא השאלה הבאה ולעולם אינה מחליפה תמיכה מקומית. עמית שמסכים על ההצעות עדיין לא יכול לעזור לשאסי שלעולם אינו מצפין חבילה.