יחידת שידור מקסימלית

יחידת השידור המקסימלית (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) של מכונת Compute Engine כך שיתאים ל-MTU של רשת ה-VPC שאליה הוא מחובר. מידע נוסף זמין במאמר מופעי מחשוב והגדרות MTU.

תקשורת בין מופעי מחשוב ברשתות VPC

אפשר לשלוח מנות IP בגודל של עד MTU בין שני מופעי Compute, אם מתקיימים התנאים הבאים:

  • שתי המכונות השולחת והמקבלת משתמשות באותה רשת VPC, או ברשתות VPC מקושרות עם ערכי MTU זהים.
  • הממשקים של שתי המכונות מוגדרים לשימוש ב-MTU של רשת ה-VPC.

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

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

  • כתובת IPv4 פנימית אזורית בטווח כתובות IPv4 ראשי של רשת משנה או בטווח כתובות IPv4 משני של רשת משנה, כולל טווחי כתובות IPv4 פרטיים וטווחי כתובות IPv4 ציבוריים בשימוש פרטי, שמשמשים את משאבי היעד הבאים:
    • כתובת ה-IPv4 הפנימית הראשית של ממשק הרשת (NIC) של מכונת היעד.
    • כתובת IPv4 פנימית בטווח כתובות IP חלופיות של כרטיס רשת של מכונה מקבלת.
    • כתובת IPv4 פנימית של כלל העברה פנימי להעברת פרוטוקול או למאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי.
  • טווחים של כתובות IPv6 של רשתות משנה פנימיות שמשמשים את משאבי היעד הבאים:
    • כתובת IPv6 מטווח כתובות ה-IPv6 שהוקצה ל-NIC של מכונת היעד./96
    • כתובת IPv6 מטווח כתובות IPv6 של כלל העברה פנימי עבור העברת פרוטוקול או עבור מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי./96
  • טווחים של כתובות IPv6 חיצוניות של תת-רשתות שבהם משתמשים משאבי היעד האלה כשחבילות מנותבות באמצעות נתיבי תת-רשת או נתיבי תת-רשת של קישור בין רשתות VPC שכנות (peering) בתוך רשת ה-VPC:
    • כתובת IPv6 מטווח כתובות ה-IPv6 שהוקצה ל-NIC של מכונת היעד./96
    • כתובת IPv6 מטווח כתובות ה-IPv6 של /96 כלל העברה חיצוני להעברת פרוטוקול או למאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי.

הנתיבים הבאים ממכונה למכונה מטופלים באותו אופן כמו תקשורת ליעדים מחוץ לרשת VPC:

  • אם היעד של החבילה הוא כתובת IPv4 חיצונית של כרטיס רשת של מכונה מקבלת.
  • אם יעד החבילה הוא כתובת IPv4 חיצונית של מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי.
  • אם היעד של החבילה הוא כתובת IPv4 חיצונית של כלל העברה להעברת פרוטוקול
  • אם היעד של החבילה הוא כתובת IPv6 חיצונית של כרטיס רשת של מכונה, מאזן עומסי רשת חיצוני להעברת סיגנל ללא שינוי או כלל העברה להעברת פרוטוקול חיצוני וגם המסלול הרלוונטי ברשת ה-VPC משתמש בנקודת קפיצה הבאה של שער אינטרנט שמוגדר כברירת מחדל. בתרחיש הזה, המכונות שמקבלות את התעבורה לא נמצאות באותה רשת VPC כמו המכונה ששולחת את התעבורה, וגם לא ברשת VPC שמקושרת לרשת ה-VPC של המכונה השולחת באמצעות קישור בין רשתות VPC שכנות (peering).

תקשורת ליעדים מחוץ לרשת VPC

Google Cloud מעבד חבילות שנשלחות ממופעי מחשוב ליעדים מחוץ לרשת ה-VPC של המופע השולח, כפי שמוצג בטבלה הבאה. יעדים מחוץ לרשת ה-VPC של מופע ששולח הודעות כוללים כתובות IP שאפשר לנתב באופן ציבורי למשאבים מחוץ ל-Google Cloud וכתובות IP חיצוניות שניתנות לשימוש על ידי הלקוח בתוך 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 משמיט את החבילה ושולח הודעה מסוג Fragmentation Needed (ICMP over IPv4) או Packet Too Big (ICMPv6) גם כשהביט DF מופעל וגם כשהוא מושבת.

תקשורת עם ממשקי API ושירותים של Google

מכונות Compute עם גודל MTU חוקי ברשת VPC יכולות לשלוח חבילות ל-Google APIs ולשירותים של Google, כולל שימוש בגישה פרטית ל-Google וב-Private Service Connect ל-Google APIs. הפרטים שבקטע הזה רלוונטיים גם למשאבים מקומיים ששולחים מנות לממשקי API ולשירותים של Google באמצעות גישה פרטית ל-Google למארחים מקומיים.

נתיב התעבורה לממשקי ה-API ולשירותים של Google שמתואר בקטע הזה מיושם על ידי ממשקי קצה של Google‏ (GFE). ה-GFE האלה משתמשים ב-MTU קבוע שלא ניתן להגדרה. תעבורת נתונים מ- Google Cloud אל Google APIs ושירותים של Google תמיד משתמשת בפרוטוקול TCP: אם מופעל חיבור של מופע חישוב לממשקי API ולשירותים של Google מרשת VPC שה-MTU שלה לא תואם ל-MTU של GFE, גודל הפלח נקבע באמצעות פרסום של TCP MSS, כפי שמתואר במאמר Mismatched MTUs, MSS clamping, path MTU discovery.

מקור החבילה יעד החבילה

כל כתובת IPv4 פנימית: כתובת IPv4 פנימית ראשית או כתובת IPv4 פנימית מטווח כתובות IP של כינוי של כרטיס ה-NIC של המכונה

כתובת IPv4 חיצונית שהוקצתה ל-NIC של המכונה באמצעות הגדרת גישה של NAT 1:1: במצב הזה, Google Cloud מבצע NAT 1:1 ביציאה, וממיר כתובת IPv4 פנימית ראשית מקורית לכתובת IPv4 חיצונית של המקור שצוינה בהגדרת הגישה.

  • כתובות IPv4 של שירותים ו-Google APIs עבור דומייני ברירת המחדל
  • 199.36.153.4/30 (מוגבל.googleapis.com)
  • 199.36.153.8/30 (פרטי.googleapis.com)
  • נקודת קצה של Private Service Connect לממשקי Google APIs ולשירותים
כתובת IPv6 חיצונית או פנימית, למכונות עם תמיכה כפולה או למכונות עם IPv6 בלבד
  • כתובות IPv6 של שירותים ו-Google APIs עבור דומייני ברירת המחדל
  • 2600:2d00:0002:1000::/56 (מוגבל.googleapis.com)
  • 2600:2d00:0002:2000::/56 (פרטי.googleapis.com)

תקשורת דרך מנהרות 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 בייטים. בטבלה הבאה מפורטים המוצרים והתכונות של Google Cloud שבהם יש תמיכה ב-jumbo frame:

מוצר או תכונה תמיכה במסגרות ג'אמבו
Compute Engine כן
Cloud Interconnect כן
נקודות קצה של חומת אש כן
Cloud VPN לא
Google APIs לא

מכונות וירטואליות והגדרות MTU

מומלץ להתאים את ה-MTU של כרטיס הרשת של מופע Compute ל-MTU של רשת ה-VPC שאליה מחובר כרטיס הרשת. ההגדרה של ה-MTU של כרטיס ה-NIC משתנה בהתאם למערכת ההפעלה ולהגדרה:

  • מופעי Linux שמבוססים על תמונת מערכת הפעלה ציבורית: כל MTU של כרטיס רשת מוגדר אוטומטית ל-MTU המתאים של רשת ה-VPC באמצעות DHCP Option 26.

  • מכונות Windows שמבוססות על קובץ אימג' של מערכת הפעלה ציבורית: כברירת מחדל, כל MTU של כרטיס רשת מוגדר עם MTU קבוע של 1,460 בייט. אם משנים את ה-MTU של רשת VPC שמכילה מופעי Windows שמבוססים על תמונות של מערכת הפעלה ציבורית, צריך לשנות את הגדרת ה-MTU של מופעי Windows.

  • תמונות מותאמות אישית של מערכת הפעלה אורחת: צריך להגדיר את ה-MTU של כרטיס הרשת או לוודא שמערכת ההפעלה האורחת מקבלת את ה-MTU של רשת ה-VPC באמצעות DHCP Option 26.

  • מכונות עם מספר ממשקי רשת: צריך להגדיר את ה-MTU של כל NIC ל-MTU של רשת ה-VPC המתאימה.

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

שינוי ה-MTU של רשת VPC

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

מידע נוסף על שינוי ה-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

הופעל באמצעות --enable-network-policy.

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

netd עבר בירושה הופעל באמצעות אחת מהאפשרויות הבאות:
GKE Dataplane V2 עבר בירושה

הופעל באמצעות --enable-dataplane-v2.

פרטים נוספים זמינים במאמר בנושא שימוש ב-GKE Dataplane V2.

ערכי MTU לא תואמים, הידוק MSS, גילוי MTU של נתיב

בקטע הזה מוסבר איך פרוטוקולי TCP ופרוטוקולים אחרים מטפלים בערכי MTU לא תואמים.

פרוטוקול TCP

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

  • גודל הפלח המקסימלי (MSS) של הלקוח ב-TCP: הכמות הגדולה ביותר של נתונים שניתן להעביר בפלח 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 לחבילות שמנותבות על ידי ה-next hops בתוך רשת VPC, כי פרוטוקול TCP עצמו מספיק.

פרוטוקולים שאינם TCP

פרוטוקולים אחרים, כמו UDP, דורשים טיפול מיוחד כשמעורבים שני ערכי MTU שונים ברשתות VPC. באחריות המערכת השולחת לפלוט חבילות שמתאימות ל-MTU של ממשק הרשת שלה, ל-MTU של ממשק הרשת של המערכת המקבלת ול-MTU של כל הרשתות שביניהן. Google Cloud לא מתבצעת חלוקת IP לחבילות שמועברות על ידי הניתובים הבאים בתוך רשת VPC.

כשחבילת IP גדולה מדי בשביל להעביר אותה – למשל, כשהחבילה חורגת מה-MTU של רשת ה-VPC שבה נמצא כרטיס ה-NIC של מופע ה-Compute שמקבל את החבילה – 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 שונות שמחוברים באמצעות קישור בין רשתות VPC:

  • למופע השולח יש כרטיס רשת ברשת VPC עם MTU של 8,896 בייט.
  • למופע המקבל יש כרטיס רשת ברשת VPC עם MTU של 1,460 בייט.
  • המופע השולח פולט חבילת IP בגודל 8,000 בייט, שהביט Don't Fragment (DF) שלה מוגדר. מכיוון שהמנה גדולה מדי מכדי להימסר למופע הקבלה, Google Cloud שולח הודעה על הצורך בפיצול או על כך שהמנה גדולה מדי למופע השליחה. ההודעה הזו מציינת את הגודל המקסימלי האפשרי של מנות IP שהשולח יכול להשתמש בהן כשהוא מנסה לשלוח מחדש מנות לחיבור.
  • מערכת ההפעלה של מופע השליחה משתמשת במידע הזה כדי להקטין את גודל מנות ה-IP כששולחים מנות עוקבות למופע המקבל.

ל-PMTUD יש דרישות נוספות כי חבילות נתונים מסוג Fragmentation Needed או Packet Too Big שנוצרות על ידי PMTUD משתמשות בפרוטוקול ICMP והמקורות שלהן תואמים ליעד של חבילת נתונים מקורית:

  • צריך להגדיר כללי חומת אש של VPC או כללים במדיניות חומת האש כדי לאפשר תעבורת ICMP (עבור IPv4) או ICMPv6 (עבור IPv6) ממקורות שתואמים ליעדים המקוריים של החבילות. כדי לפשט את הגדרת חומת האש, כדאי לאפשר ICMP ו-ICMPv6 מכל המקורות.
  • כללי העברה למאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי ולהעברת פרוטוקול פנימית חייבים להשתמש בפרוטוקול L3_DEFAULT כדי לעבד גם ICMP ל-PMTUD וגם את הפרוטוקול שבו נעשה שימוש בחבילה המקורית.

המאמרים הבאים

נסו בעצמכם

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

אני רוצה לנסות את VPC בחינם