שאלת ראיון למהנדס רשתות: הגדרתי Port-channel עם ארבעה ממשקי 10G. האם אפשר להעביר עכשיו 40G?

אתם בראיון לתפקיד מהנדס רשתות תקשורת. המראיין מצייר שני סוויצ׳ים, וביניהם ארבעה קישורים של 10G. כולם הוגדרו בתוך Port-channel אחד. הוא מצביע על השרטוט ושואל: עכשיו יש לי 40G? אפשר לענות כן, אפשר לענות לא, ואפשר להסביר במדויק למה שתי התשובות לבדן אינן מספיקות.

המראיין בודק כאן אם אתם מבחינים בין הקיבולת של הקישור הלוגי לבין הקצב שתעבורה מסוימת באמת תקבל. אחרי התשובה הקצרה, סביר שהוא ימשיך: אם זה 40G, למה בדיקת הביצועים שלי נעצרת סביב 10G?

ארבעה קישורים אינם ממשק פיזי אחד של 40G

EtherChannel הוא המונח של Cisco לאיגוד קישורים, ו־Port-channel הוא הממשק הלוגי שמייצג את האיגוד. Link Aggregation מאפשר להשתמש בכמה קישורים פיזיים כקישור לוגי אחד, במיתוג או בניתוב בהתאם להגדרה. מבחינת STP, חבילת שכבה שנייה תקינה נתפסת כקישור לוגי אחד, במקום ארבעה קישורים נפרדים ש־STP עשוי לחסום כדי למנוע לולאה.

ארבעה ממשקי 10GbE פעילים נותנים קיבולת קו מצרפית נומינלית של 40Gbps לשידור ו־40Gbps לקליטה, כי הקישורים עובדים ב־Full Duplex. לא אומרים שליישום יש ממשק של 80G: זה חיבור של קיבולת שני הכיוונים. גם 40G בכל כיוון אינם הבטחה לקצב נתוני היישום. יש תקורת Ethernet, IP ו־TCP, ולפעמים גם מגבלות של שרת, אחסון, חומת אש או קיבולת המיתוג.

איך הסוויץ׳ מחליט על איזה ממשק לשלוח?

במנגנון נפוץ של איזון עומסים, הסוויץ׳ מחשב Hash משדות בכותרת החבילה וממפה את התוצאה לחבר פעיל ב־Port-channel. בהתאם לציוד ולהגדרה, השדות עשויים לכלול כתובות MAC, כתובות IP של מקור ויעד, ולעיתים גם פורטי TCP או UDP. ה־Hash אינו מד עומס שבוחר בכל רגע את הממשק הכי פנוי.

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

למה גם ארבעה זרמים לא מבטיחים ארבע פעמים 10G?

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

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

מה LACP עושה, ומה הוא לא עושה?

LACP, קיצור של Link Aggregation Control Protocol, הוא פרוטוקול תקני לאיגוד קישורים במסגרת IEEE 802.1AX. תראו גם את השם ההיסטורי 802.3ad. הוא מאפשר לשני הצדדים להחליף מידע ולתאם אילו קישורים שייכים לאותה חבילה. הוא אינו מפצל אוטומטית זרם של 40G לארבעה זרמים, ואינו מבצע את ה־Hash במקום מנגנון העברת התעבורה של הסוויץ׳.

• ▸במצב active, הצד יוזם חילופי הודעות LACP.
• ▸במצב passive, הצד מגיב להודעות LACP אך אינו יוזם את המשא ומתן.
• ▸השילוב active מול active יכול להקים חבילה תקינה, וכך גם active מול passive, אם שאר התנאים מתאימים.
• ▸השילוב passive מול passive לא יקים חבילה דרך משא ומתן LACP, כי אין צד שיוזם.

מצבי active ו־passive מתייחסים למשא ומתן, לא לתפקידים של ראשי וגיבוי בהעברת הנתונים. חבר שנכלל בחבילה פעילה יכול להעביר תעבורה גם אם הצד המקומי מוגדר passive. בנוסף, בהתאם לציוד ולמגבלות החבילה, קישור פיזי עשוי להיות מחובר אך להישאר Standby או Suspended ולא להוסיף קיבולת פעילה.

ומה לגבי PAgP והמצבים desirable ו־auto?

PAgP, קיצור של Port Aggregation Protocol, הוא פרוטוקול קנייני של Cisco למשא ומתן על EtherChannel. הוא רלוונטי ללימודי רשתות ולציוד שתומך בו, אבל לא מניחים שכל דגם Cisco או כל מערכת הפעלה תומכים בו. בסביבה עם ציוד של כמה יצרנים, LACP הוא בדרך כלל הבחירה התקנית, לאחר בדיקת תמיכה ותאימות.

• ▸במצב desirable, הצד יוזם משא ומתן PAgP.
• ▸במצב auto, הצד מגיב למשא ומתן PAgP.
• ▸השילוב desirable מול desirable או desirable מול auto יכול להקים חבילה, אם ההגדרות תואמות.
• ▸השילוב auto מול auto אינו יוזם משא ומתן ולכן לא מקים חבילה באמצעות PAgP.
• ▸המצבים active ו־passive שייכים ל־LACP; המצבים desirable ו־auto שייכים ל־PAgP. ערבוב ביניהם אינו משא ומתן תואם.

מה עושה channel-group mode on?

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

דוגמת Cisco: ארבעה ממשקי 10G עם LACP

בדוגמה הבאה בונים EtherChannel בשכבה שנייה בין שני סוויצ׳ים במעבדה. בודקים מראש שהממשקים אכן תומכים ב־10Gbps, ושהמהירות, סוג הממשק, מצב המיתוג, ה־VLANs ויתר הפרמטרים הנדרשים תואמים. שמות הממשקים, התחביר ודרך הפצת ההגדרות בין החברים לממשק הלוגי תלויים בפלטפורמה ובגרסה.

interface range TenGigabitEthernet1/0/1 - 4
 switchport mode trunk
 switchport trunk allowed vlan 10,20,30
 channel-group 10 mode active
 no shutdown
!
interface Port-channel10
 switchport mode trunk
 switchport trunk allowed vlan 10,20,30
 no shutdown

אפשר לבנות גם Routed Port-channel עם no switchport וכתובת IP על הממשק הלוגי, בציוד שתומך בכך. אין מערבבים חברי שכבה שנייה ושכבה שלישית באותה חבילה. העיקרון של קיבולת מצרפית לעומת מגבלת זרם אינו משתנה רק משום שה־Port-channel משתתף בניתוב.

איך מוכיחים שכל ארבעת הממשקים באמת עובדים?

show etherchannel summary
show etherchannel 10 detail
show etherchannel load-balance
show lacp neighbor
show interfaces Port-channel10
show interfaces TenGigabitEthernet1/0/1
show interfaces TenGigabitEthernet1/0/2
show interfaces TenGigabitEthernet1/0/3
show interfaces TenGigabitEthernet1/0/4

ב־show etherchannel summary, בפלטי IOS XE נפוצים, הסימון P ליד ממשק פיזי מציין שהוא מאוגד ב־Port-channel. הסימון SU עשוי לתאר ממשק לוגי בשכבה שנייה שנמצא בשימוש; בחבילת שכבה שלישית עשוי להופיע RU. קוראים תמיד את מקרא הסימונים של הפלט. ממשק עם Link Up אינו בהכרח חבר פעיל בחבילה.

הפקודה show etherchannel load-balance מציגה את שיטת האיזון המוגדרת. היא אינה מציגה הוכחה שכל ממשק מקבל בדיוק רבע מהתעבורה. בודקים קצבי כניסה ויציאה של החברים, שגיאות, Drops ועומס תורים, תוך הבנה שממוצע לאורך כמה דקות עלול להסתיר Microbursts. בודקים גם את השרתים ואת שאר המסלול, ולא מסיקים שכל צוואר בקבוק נמצא ב־Port-channel.

אם ממשק אחד נופל, נשארים עם 30G?

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

יש עוד תנאי שמועמד מנוסה צריך להזכיר: הגדרת Minimum Links. אם המדיניות דורשת לפחות ארבעה חברים פעילים, אובדן חבר אחד יכול להוריד את כל ה־Port-channel במקום להשאירו עם שלושה. בודקים את ההגדרה ואת התמיכה בציוד, וגם מה קורה לניתוב או ל־STP כשהממשק הלוגי יורד.

שלוש שאלות המשך שכדאי להיות מוכנים אליהן

איך השאלה הזו מתחברת לעבודת רשתות ואבטחת מידע?

בארגון, אותה החלטה פוגשת uplinks בין סוויצ׳ים, חיבורי שרתים וחיבורים לפיירוולים. גם אם החיבור הפיזי מציע קיבולת גדולה, הפעלת IPS, בדיקת תעבורה מוצפנת או מגבלות עיבוד של חומת האש עשויות לשנות את התפוקה. תמיכת Link Aggregation והאופן שבו היא משתלבת ב־HA משתנים בין מוצרים. איש רשתות צריך להבין גם את הקישור וגם את השירות שעובר עליו.

אם המראיין חוזר בסוף לשאלה המקורית, אל תסתבכו: יש עד 40G מצרפיים, לא 40G לזרם יחיד. אחר כך הסבירו מה בדקתם כדי לדעת שהחבילה באמת מספקת את הקיבולת הזו. זו תשובה קצרה שאפשר להגן עליה גם כשממשיכים לשאול.

מקורות מקצועיים: תיעוד Cisco