יחידת שידור מקסימלית
יחידת השידור המקסימלית (MTU) היא הגודל, בבייטים, של מנת ה-IP הגדולה ביותר האפשרית, כולל כותרות IP, כותרות פרוטוקול של שכבה 4 ונתונים של שכבה 4, שיכולה להיכנס למסגרת Ethernet.
גדלי MTU תקינים של רשתות VPC
ברשתות של ענן וירטואלי פרטי (VPC) נעשה שימוש ב-MTU של 1,460 בייט כברירת מחדל. אפשר להגדיר את ה-MTU של רשת VPC לכל ערך בין 1,300 בייט ל-8,896 בייט (כולל). גודלי MTU מותאמים אישית נפוצים הם 1,500 בייטים (Ethernet רגיל) או 8,896 בייטים (הגודל המקסימלי האפשרי). מומלץ להגדיר את ה-MTU של כל ממשק רשת (NIC) של מכונה וירטואלית (VM) כך שיתאים ל-MTU של רשת ה-VPC שאליה הוא מחובר. מידע נוסף זמין במאמר מכונות וירטואליות והגדרות MTU.
תקשורת בין Google Cloud מכונות וירטואליות ברשתות VPC
כששולחים ומקבלים מכונות וירטואליות שמשתמשות באותה רשת VPC או ברשתות VPC מקושרות עם MTU זהה, אפשר לשלוח מנות IP עד לגודל ה-MTU בין שתי המכונות הווירטואליות, אם הממשקים של שתי המכונות הווירטואליות מוגדרים לשימוש ב-MTU של רשת ה-VPC.
כדי למנוע בעיות של חוסר התאמה ב-MTU, מומלץ להשתמש באותו MTU בכל רשתות ה-VPC המחוברות. זוהי השיטה המומלצת, אבל אתם לא חייבים להגדיר ערכי MTU זהים ברשתות VPC מחוברות. לפרטים על האופן שבו פרוטוקולים מטפלים במצבים שבהם יש חוסר התאמה של MTU בין רשתות VPC, אפשר לעיין במאמר חוסר התאמה של MTU, הידוק MSS, גילוי MTU של נתיב.
מנקודת המבט של מכונה וירטואלית ששולחת נתונים, הנתיבים ליעדים הבאים מייצגים תעבורת נתונים מ-VM ל-VM שמנותבת בתוך רשת VPC:
- כתובת IPv4 פנימית אזורית בטווח כתובות IPv4 ראשי של רשת משנה או בטווח כתובות IPv4 משני של רשת משנה, כולל טווחי כתובות IPv4 פרטיים וטווחי כתובות IPv4 ציבוריים בשימוש פרטי, שמשמשים את משאבי היעד הבאים:
- כתובת ה-IPv4 הפנימית הראשית של ממשק הרשת (NIC) של מכונה וירטואלית מקבלת.
- כתובת IPv4 פנימית בטווח כתובות IP של כינוי של כרטיס רשת של מכונה וירטואלית מקבלת.
- כתובת IPv4 פנימית של כלל העברה פנימי להעברת פרוטוקול או למאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי.
- טווחים של כתובות IPv6 פנימיות של רשתות משנה שמשמשים את משאבי היעד האלה:
- כתובת IPv6 מטווח כתובות ה-IPv6 שמוקצה לכרטיס הרשת של מכונה וירטואלית מקבלת.
/96 - כתובת IPv6 מטווח כתובות IPv6 של כלל העברה פנימי עבור העברת פרוטוקול או עבור מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי.
/96
- כתובת IPv6 מטווח כתובות ה-IPv6 שמוקצה לכרטיס הרשת של מכונה וירטואלית מקבלת.
- טווח כתובות של תת-רשתות IPv6 חיצוניות שמשמשות את משאבי היעד האלה כשמנתבים מנות באמצעות נתיבי תת-רשתות או נתיבי תת-רשתות של שירותי Peering ברשת ה-VPC:
- כתובת IPv6 מטווח כתובות ה-IPv6 שמוקצה לכרטיס הרשת של מכונה וירטואלית מקבלת.
/96 - כתובת IPv6 מטווח כתובות ה-IPv6 של כלל העברה חיצוני להעברת פרוטוקולים או למאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי.
/96
- כתובת IPv6 מטווח כתובות ה-IPv6 שמוקצה לכרטיס הרשת של מכונה וירטואלית מקבלת.
הנתיבים הבאים מ-VM ל-VM מטופלים באותו אופן כמו תקשורת ליעדים מחוץ לרשת VPC:
- אם יעד החבילה הוא כתובת IPv4 חיצונית של כרטיס רשת של מכונה וירטואלית מקבלתGoogle Cloud .
- אם יעד החבילה הוא כתובת IPv4 חיצונית של מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי.
- אם היעד של החבילה הוא כתובת IPv4 חיצונית של כלל העברה להעברת פרוטוקול
- אם יעד החבילה הוא כתובת IPv6 חיצונית של Google Cloud כרטיס רשת של מכונה וירטואלית, מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי או כלל העברה להעברת פרוטוקול חיצוני וגם המסלול הרלוונטי ברשת ה-VPC משתמש ב-next hop של שער אינטרנט שמוגדר כברירת מחדל. בתרחיש הזה, המכונות הווירטואליות המקבלות לא נמצאות באותה רשת VPC כמו המכונה הווירטואלית השולחת, ולא ברשת VPC שמקושרת לרשת ה-VPC של המכונה הווירטואלית השולחת באמצעות קישור בין רשתות VPC שכנות (peering).
תקשורת ליעדים מחוץ לרשת VPC
Google Cloud מעבד מנות שנשלחות ליעדים מחוץ לרשת ה-VPC של המכונה הווירטואלית השולחת, כפי שמוצג בטבלה הבאה. יעדים מחוץ לרשת ה-VPC של מכונת ה-VM השולחת כוללים כתובות IP שאפשר לנתב באופן ציבורי למשאבים מחוץ ל- Google Cloud וכתובות IP חיצוניות שזמינות לשימוש הלקוח בתוךGoogle Cloud.
Google Cloudבדרך כלל, האינטרנט משתמש ב-MTU של 1,500 בייט, ולכן שמירה על גודל מנות ה-IP של 1,500 בייט או פחות בדרך כלל מונעת אובדן מנות שקשור ל-MTU.
| מצב | התנהגות |
|---|---|
| מנות TCP SYN ו-SYN-ACK | Google Cloud מבצעת הידוק של ה-MSS אם צריך, ומשנה את ה-MSS כדי לוודא שהמנות מתאימות ל-MTU. |
| MTU של מנות IP בין 1,300 בייט ל-1,600 בייט (כולל) | Google Cloud לא מבצע שינויים במנות, למעט מנות SYN ומנות SYN-ACK, כפי שמתואר בשורה הראשונה. |
| חבילת IP גדולה מ-1,600 בייט | Google Cloud drops the packet and sends a Fragmentation Needed (ICMP over IPv4) or Packet Too Big (ICMPv6) message both when the DF bit is on and also when the DF bit is off. |
תקשורת עם ממשקי API ושירותים של Google
מכונות וירטואליות שמשתמשות בגודל MTU חוקי של רשת VPC יכולות לשלוח חבילות ל-Google APIs ולשירותים של Google, כולל שימוש בגישה פרטית ל-Google וב-Private Service Connect ל-Google APIs. הפרטים שבקטע הזה רלוונטיים גם למשאבים מקומיים ששולחים מנות לממשקי API ולשירותים של Google באמצעות גישה פרטית ל-Google למארחים מקומיים.
נתיב התעבורה לממשקי ה-API ולשירותים של Google שמתואר בקטע הזה מיושם על ידי ממשקי קצה של Google (GFE). ה-GFE האלה משתמשים ב-MTU קבוע שלא ניתן להגדרה. התנועה מ-Google APIs ושירותים אל Google Cloud תמיד משתמשת בפרוטוקול TCP: אם מכונה וירטואלית מתחברת ל-Google APIs ולשירותים מרשת VPC שה-MTU שלה לא תואם ל-MTU של GFE, גודל הפלח נקבע באמצעות פרסום TCP MSS, כפי שמתואר במאמר Mismatched MTUs, MSS clamping, path MTU discovery.
| מקור החבילה | יעד החבילה |
|---|---|
כל כתובת IPv4 פנימית: כתובת IPv4 פנימית ראשית או כתובת IPv4 פנימית מטווח כתובות IP של כינוי של כרטיס ה-NIC של מכונת ה-VM כתובת IPv4 חיצונית שהוקצתה ל-NIC של ה-VM באמצעות הגדרת גישה של NAT מסוג 1:1: במצב הזה, Google Cloud מבצע NAT מסוג 1:1 בתעבורת נתונים יוצאת (egress), וממיר כתובת IPv4 פנימית ראשית מקורית לכתובת IPv4 חיצונית של המקור שצוינה בהגדרת הגישה. |
|
| כתובת IPv6 חיצונית או פנימית, למכונות וירטואליות עם תמיכה כפולה או עם IPv6 בלבד |
|
תקשורת דרך מנהרות Cloud VPN
ל-Cloud VPN יש MTU של שער למנות שעברו אנקפסולציה וMTU של מטען ייעודי למנות לפני ואחרי האנקפסולציה.
לערכי MTU מדויקים של מטען ייעודי (payload) ומידע נוסף על MTU של Cloud VPN, ראו שיקולים לגבי MTU במאמרי העזרה של Cloud VPN.
תקשורת דרך צירופים ל-VLAN ב-Cloud Interconnect
מומלץ להשתמש באותו MTU לכל קבצים מצורפים של VLAN שמחוברים לאותה רשת VPC, ולהגדיר את ה-MTU של רשת ה-VPC לאותו ערך. פרטים על יחידות ה-MTU של צירופי VLAN ב-Cloud Interconnect זמינים במאמר יחידות ה-MTU של Cloud Interconnect.
תקשורת דרך נקודות קצה של חומת אש
אם אתם משתמשים בנקודות קצה של חומת אש, צריך להגדיר MTU מתאים לרשת ה-VPC. אם הגדרת ה-MTU של רשת ה-VPC גדולה מגודל המנה שהנקודה של חומת האש תומכת בה, Cloud Next Generation Firewall לא יכולה לבצע בדיקה בשכבה 7 בהצלחה. מידע נוסף זמין במאמר בנושא גודל מנות נתונים נתמך.
תמיכה במסגרות ג'מבו
פריימים גדולים הם פריימים עם מטען ייעודי (payload) בגודל של יותר מ-1,460 בייטים. בטבלה הבאה מפורט סיכום של התמיכה ב-jumbo frame במוצרים ובתכונות של Google Cloud :
| מוצר או תכונה | תמיכה במסגרות ג'מבו |
|---|---|
| Compute Engine | כן |
| Cloud Interconnect | כן |
| נקודות קצה של חומת אש | כן |
| Cloud VPN | לא |
| Google APIs | לא |
מכונות וירטואליות והגדרות MTU
מומלץ להתאים את ה-MTU של כרטיס ה-NIC של מכונה וירטואלית ל-MTU של רשת ה-VPC שאליה מחובר כרטיס ה-NIC:
כל MTU של כרטיס רשת (NIC) במכונה וירטואלית של Linux שמבוססת על קובץ אימג' של מערכת הפעלה ציבורית מוגדר באופן אוטומטי ל-MTU של רשת ה-VPC המתאימה באמצעות DHCP Option 26.
כל MTU של כרטיס רשת במכונה וירטואלית של Windows שמבוססת על תמונה של מערכת הפעלה ציבורית מוגדר עם MTU קבוע של
1,460בייט. אם משנים את ה-MTU של רשת VPC שמכילה מכונות וירטואליות של Windows שמבוססות על תמונות של מערכת הפעלה ציבורית, צריך לשנות את הגדרת ה-MTU של מכונה וירטואלית של Windows.אם אתם משתמשים באימג'ים מותאמים אישית של מערכת הפעלה לאורח, אתם צריכים להגדיר את ערכי ה-MTU של כרטיסי הרשת או לוודא שמערכת ההפעלה לאורח מקבלת את ערך ה-MTU של רשת ה-VPC באמצעות אפשרות DHCP מספר 26.
אם למכונה וירטואלית יש כמה ממשקי רשת, צריך להגדיר את ה-MTU של כל NIC ל-MTU של רשת ה-VPC המתאימה.
אם ה-MTU של כרטיס ה-NIC צריך להיות שונה מה-MTU של רשת ה-VPC, צריך להגדיר את ה-MTU של כרטיס ה-NIC כך שיהיה נמוך מה-MTU של רשת ה-VPC. הקטנה כפויה של ה-MTU של כרטיס ה-NIC מועילה בתרחישים מסוימים של רשתות מתקדמות.
שינוי ה-MTU של רשת VPC
אם משנים את ה-MTU של רשת VPC עם מכונות וירטואליות פעילות, חשוב לזכור את הנקודות הבאות:
אם מקטינים את ה-MTU של רשת ה-VPC, חייבים לעצור ולהפעיל כל מכונה וירטואלית. הפעלה מחדש של מכונה וירטואלית מתוך מערכת ההפעלה האורחת שלה לא מעדכנת את ה-MTU שלה.
אם מגדילים את ה-MTU של רשת ה-VPC, מכונות וירטואליות שפועלות באמצעות רשת ה-VPC לא ינצלו את ה-MTU המוגדל של רשת ה-VPC עד שיפסיקו את הפעולה של המכונות הווירטואליות ויפעילו אותן מחדש. עד שמפסיקים ומפעילים מחדש כל מכונה וירטואלית, המכונה הווירטואלית ממשיכה להשתמש בערך ה-MTU הקודם (הנמוך יותר).
הוראות מפורטות מופיעות במאמר שינוי הגדרת MTU ברשת VPC.
הגדרות GKE ו-MTU
ה-MTU שנבחר לממשק Pod תלוי בממשק רשת הקונטיינרים (CNI) שבו משתמשים צמתי האשכול ובהגדרת ה-MTU של ה-VPC הבסיסי. מידע נוסף זמין במאמר בנושא Pods.
ערך ה-MTU של ממשק ה-Pod הוא 1460 או שהוא עובר בירושה מהממשק הראשי של הצומת.
| CNI | MTU | GKE Standard |
|---|---|---|
| kubenet | 1460 | ברירת מחדל |
|
kubenet (GKE גרסה 1.26.1 ואילך) |
עבר בירושה | ברירת מחדל |
| Calico | 1460 |
הופעל באמצעות פרטים נוספים זמינים במאמר שליטה בתקשורת בין Pods ושירותים באמצעות מדיניות רשת. |
| netd | עבר בירושה | הופעל באמצעות אחת מהאפשרויות הבאות: |
| GKE Dataplane V2 | עבר בירושה |
הופעל באמצעות פרטים נוספים זמינים במאמר שימוש ב-GKE Dataplane V2. |
ערכי MTU לא תואמים, הידוק MSS, גילוי MTU של נתיב
בקטע הזה מוסבר איך פרוטוקולי TCP ופרוטוקולים שאינם TCP מטפלים בערכי MTU לא תואמים.פרוטוקול TCP
פרוטוקול ה-TCP מטפל באופן אוטומטי בחוסר התאמה של MTU. גם הלקוח וגם השרת מחשבים בנפרד את הערכים שלהם של גודל מקטע TCP מקסימלי (MSS) בכל פעם שחיבור TCP נפתח. הלקוח והשרת לא צריכים להסכים על ערך MSS אפקטיבי זהה.
גודל מקטע TCP מקסימלי (MSS) אפקטיבי של הלקוח: הכמות הגדולה ביותר של נתונים שניתן להעביר במקטע TCP שנשלח מלקוח לשרת היא המינימום מבין שני הערכים הבאים:
הערך של שדה ה-MSS בחבילת ה-SYN-ACK שהלקוח מקבל מהשרת במהלך יצירת חיבור TCP.
ה-MTU של ממשק הרשת של הלקוח, פחות 40 בייטים. ה-40 בייטים שהופחתו כוללים 20 בייטים לכותרת ה-IP ו-20 בייטים לכותרת ה-TCP הבסיסית.
גודל הפלח המקסימלי (MSS) של TCP בשרת: הכמות הגדולה ביותר של נתונים שניתנים להעברה בפלח TCP שנשלח משרת ללקוח היא המינימום מבין שני הערכים הבאים:
הערך של שדה ה-MSS בחבילת ה-SYN שהתקבלה בשרת מהלקוח במהלך יצירת חיבור TCP.
ערך ה-MTU של ממשק הרשת של השרת, פחות 40 בייטים. ה-40 בייטים שהופחתו כוללים 20 בייטים לכותרת ה-IP ו-20 בייטים לכותרת ה-TCP הבסיסית.
אכיפת מינימום על TCP MSS
הידוק MSS של TCP הוא תהליך שבו מכשיר רשת בין לקוח לשרת משנה את ערכי ה-MSS בחבילות SYN ו-SYN-ACK כשהוא מנתב את החבילות בין הלקוח לשרת. Google Cloud משתמש בהידוק MSS בכל פעם שהוא שולח חבילות ליעדים מחוץ לרשת VPC.
גם מנהרות Cloud VPN וקבצים מצורפים של VLAN ב-Cloud Interconnect משתמשים בהגבלת MSS. מידע נוסף זמין במאמר Packet encapsulation and processing במסמכי התיעוד של Cloud VPN ובמאמר Cloud Interconnect MTU.
ברשתות VPC לא מתבצעת הצמדה של MSS לחבילות שמנותבות על ידי הניתורים הבאים בתוך רשת VPC, כי פרוטוקול ה-TCP עצמו מספיק.
פרוטוקולים שאינם TCP
פרוטוקולים אחרים, כמו UDP, דורשים טיפול מיוחד כשמעורבים שני ערכי MTU שונים של רשתות VPC. באחריות המערכת השולחת להפיק חבילות שמתאימות ל-MTU של ממשק הרשת שלה, ל-MTU של ממשק הרשת של המערכת המקבלת ול-MTU של כל הרשתות שביניהן. Google Cloud לא מתבצעת פיצול IP לחבילות שמנותבות על ידי הניתובים הבאים ברשת VPC.
כשחבילת IP גדולה מדי בשביל להימסר – למשל, כשהחבילה חורגת מה-MTU של רשת ה-VPC שבה נמצא כרטיס ה-NIC של מכונת ה-VM המקבלת – Google Cloud משמיט את החבילה. אם הביט DF מוגדר בחבילה, Google Cloud הנתב שולח גם הודעה מסוג Fragmentation Needed (ICMP over IPv4) או Packet Too Big (ICMPv6) בחזרה לשולח.
Google Cloud שולח הודעה על הצורך בפיצול או על חבילה גדולה מדי בנסיבות הבאות, גם כשביט DF מושבת:
- אם ה-MTU של רשת ה-VPC קטן מ-1,600 בייט, והחבילה שנשלחת גדולה מה-MTU של רשת ה-VPC.
- אם ה-MTU של רשת ה-VPC הוא 1,600 בייט או יותר, והחבילה שנשלחת גדולה מ-1,600 בייט.
הודעות ICMP Fragmentation Needed או Packet Too Big נחוצות למכונה וירטואלית ששולחת חבילות כדי להשתמש ב-Path MTU discovery (PMTUD). כדי להמחיש את אופן הפעולה של PMTUD, נשתמש בדוגמה הבאה עם שתי מכונות וירטואליות ברשתות VPC שונות שמחוברות באמצעות קישור בין רשתות שכנות (peering) של VPC:
- למכונה הווירטואלית השולחת יש כרטיס רשת ברשת VPC עם MTU של 8,896 בייט.
- למכונה הווירטואלית המקבלת יש כרטיס רשת ברשת VPC עם MTU של 1,460 בייט.
- המכונה הווירטואלית השולחת פולטת חבילת IP בגודל 8,000 בייט, שהביט Don't Fragment (
DF) שלה מוגדר. מכיוון שהחבילה גדולה מדי כדי להימסר למכונה הווירטואלית המקבלת, המכונה הווירטואליתGoogle Cloud שולחת הודעה מסוג Fragmentation Required או Packet Too Big למכונה הווירטואלית השולחת. ההודעה הזו מציינת את הגודל המקסימלי האפשרי של מנות IP שהשולח יכול להשתמש בהן כשהוא מנסה לשלוח מחדש מנות לחיבור. - מערכת ההפעלה של המכונה הווירטואלית השולחת משתמשת במידע הזה כדי להקטין את גודל חבילת ה-IP כששולחים חבילות עוקבות למכונה הווירטואלית המקבלת.
ל-PMTUD יש את הדרישות הנוספות הבאות, כי חבילות נתונים מסוג Fragmentation Needed או Packet Too Big שנוצרות על ידי PMTUD משתמשות בפרוטוקול ICMP, והמקורות שלהן תואמים ליעד של חבילת נתונים מקורית:
- צריך להגדיר כללי חומת אש של VPC המאפשרים תעבורת נתונים נכנסת או כללים במדיניות חומת האש כדי לאפשר תעבורת ICMP (עבור IPv4) או ICMPv6 (עבור IPv6) ממקורות שתואמים ליעדים המקוריים של החבילות. כדי לפשט את הגדרת חומת האש, כדאי לאפשר ICMP ו-ICMPv6 מכל המקורות.
- כללי העברה למאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי ולהעברת פרוטוקול פנימית חייבים להשתמש בפרוטוקול
L3_DEFAULTכדי לעבד גם ICMP ל-PMTUD וגם את הפרוטוקול שבו נעשה שימוש בחבילה המקורית.
המאמרים הבאים
- כדי לראות MTU אחר שפועל, אפשר לקרוא איך יוצרים ומאמתים רשת MTU של מסגרת ג'מבו.
- יצירת רשת VPC עם MTU מוגדר.
- שינוי הגדרת ה-MTU של רשת VPC.
נסו בעצמכם
אנחנו ממליצים למשתמשים חדשים ב-Google Cloud ליצור חשבון כדי שיוכלו להעריך את הביצועים של VPC בתרחישים מהעולם האמיתי. לקוחות חדשים מקבלים בחינם גם קרדיט בשווי 300 $להרצה, לבדיקה ולפריסה של עומסי העבודה.
אני רוצה לנסות את VPC בחינם