יחידת שידור מקסימלית (MTU)

יחידת השידור המקסימלית (MTU) היא הגודל בבייטים של חבילת ה-IP הגדולה ביותר, כולל כותרות IP, כותרות פרוטוקול של שכבה 4 ונתונים של שכבה 4, שיכולה להיכנס למסגרת אתרנט.

גדלים תקינים של MTU ברשת VPC

ברשתות VPC, ערך ברירת המחדל של MTU הוא 1,460 בייטים. אפשר להגדיר את ה-MTU של רשת VPC לכל ערך בין 1,300 בייטים ל-8,896 בייטים (כולל). הגדלים הנפוצים של MTU בהתאמה אישית הם 1,500 בייטים (Ethernet רגיל) או 8,896 בייטים (המקסימום האפשרי). מומלץ להגדיר את ה-MTU לכל ממשק רשת (NIC) של מכונת Compute Engine כך שיתאים ל-MTU של רשת ה-VPC שאליה הוא מחובר. למידע נוסף, קראו את המאמר מכונות Compute והגדרות MTU.

תקשורת בין מכונות ברשתות VPC

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

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

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

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

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

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

  • אם יעד החבילה הוא כתובת IPv4 חיצונית של כרטיס רשת (NIC) במכונה המקבלת.
  • אם יעד החבילה הוא כתובת IPv4 חיצונית של מאזן עומסי רשת אזורי חיצוני להעברת סיגנל ללא שינוי.
  • אם יעד החבילה הוא כתובת IPv4 חיצונית של כלל העברה להעברת פרוטוקול
  • אם יעד החבילה הוא כתובת IPv6 חיצונית של NIC של מכונה, מאזן עומסי רשת אזורי חיצוני להעברת סיגנל ללא שינוי או כלל העברה להעברת פרוטוקול חיצוני, וגם המסלול הרלוונטי ברשת ה-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 API ולשירותי Google, כולל שימוש בגישה פרטית ל-Google ובPrivate Service Connect לממשקי Google API. הפרטים בקטע הזה רלוונטיים גם למשאבים מקומיים ששולחים חבילות ל-Google APIs ולשירותים של Google באמצעות גישה פרטית ל-Google למארחים מקומיים.

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

מקור חבילת הנתונים יעד החבילה

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

כתובת IPv4 חיצונית שמוקצית ל-NIC של המכונה באמצעות הגדרת גישה של 1-1 NAT: במצב הזה, Google Cloud מבצע 1-1 NAT בתעבורת נתונים יוצאת, וממיר כתובת IPv4 פנימית ראשית מקורית לכתובת IPv4 חיצונית שצוינה בהגדרת הגישה.
  • כתובות IPv4 של Google APIs ושירותים לדומיינים שמוגדרים כברירת מחדל
  • 199.36.153.4/30 (מוגבל.googleapis.com)
  • 199.36.153.8/30 (private.googleapis.com)
  • נקודת קצה מסוג Private Service Connect לממשקי API ולשירותים של Google
כתובת IPv6 חיצונית או פנימית, למכונות עם מחסנית כפולה או למכונות IPv6 בלבד

תקשורת דרך מנהרות Cloud VPN

ל-Cloud VPN יש שער MTU לחבילות שעברו אנקפסולציה ומטען ייעודי (payload) של MTU לחבילות לפני ואחרי אנקפסולציה.

לערכים מדויקים של MTU של מטען ייעודי (payload) ומידע נוסף על MTU של Cloud VPN, קראו את השיקולים בנוגע ל-MTU במסמכי התיעוד של Cloud VPN.

תקשורת באמצעות חיבורי Cloud Interconnect (VLAN)

מומלץ להשתמש באותו MTU לכל הקישורים ל-VLAN שמחוברים לאותה רשת VPC, וגם להגדיר את ה-MTU של רשת ה-VPC לאותו ערך. לפרטים על יחידות MTU של צירוף ל-VLAN ב-Cloud Interconnect, קראו את המאמר יחידת MTU ב-Cloud Interconnect.

תקשורת דרך נקודות קצה של חומת אש

אם אתם משתמשים בנקודות קצה של חומת אש, הגדירו MTU שמתאים לרשת ה-VPC. אם הגדרת ה-MTU של רשת ה-VPC חורגת מגודל החבילה שנתמך בנקודת הקצה של חומת האש, Cloud Next Generation Firewall לא יכול לבצע בדיקה של שכבה 7. מידע נוסף זמין במאמר גודל חבילה נתמך.

תמיכה ב-Jumbo frame

מסגרות ג'מבו הן מסגרות עם מטען ייעודי (payload) בגודל של יותר מ-1,460 בייטים. בטבלה הבאה מפורטת התמיכה במסגרות ענק במוצרים ובתכונות של Google Cloud :

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

מכונות Compute והגדרות MTU

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

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

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

  • אימג'ים מותאמים אישית של מערכת ההפעלה של האורח: צריך להגדיר את ה-MTU של ה-NIC או לוודא שמערכת ההפעלה של האורח מקבלת את ה-MTU של רשת ה-VPC באמצעות אפשרות 26 של DHCP.

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

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

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

כדי למנוע בעיות בקישוריות, לפני שמשנים את ה-MTU של רשת ה-VPC, צריך קודם לעצור כל מכונה. הפעלה מחדש של מכונה ממערכת ההפעלה של האורח לא מעדכנת את ה-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
(גרסה 1.26.1 של GKE ואילך) 		עבר בירושה ברירת מחדל
Calico 1460

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

לפרטים, ראו שליטה בתקשורת בין Pods לבין שירותים באמצעות מדיניות רשת ב-Kubernetes.
netd עבר בירושה הופעל באמצעות אחת מהאפשרויות הבאות:
GKE Dataplane V2 עבר בירושה

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

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

חוסר התאמה בין יחידות MTU, הידוק MSS, גילוי נתיב MTU

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

פרוטוקול TCP

פרוטוקול TCP מטפל בחוסר התאמה של MTU באופן אוטומטי. הלקוח והשרת מחשבים כל אחד בנפרד את ערכי גודל הפלח המקסימלי (MSS) של TCP בכל פעם שחיבור 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. למידע נוסף, קראו את המאמר אנקפסולציה ועיבוד של חבילות במסמכי התיעוד של Cloud VPN ואת המאמר Cloud Interconnect MTU.

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

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

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

אם חבילת IP גדולה מדי ואי אפשר לשלוח אותה, למשל אם החבילה חורגת מה-MTU של רשת ה-VPC שבה נמצא ה-NIC של המכונה המקבלת, Google Cloud משמיטה את החבילה. אם בחבילה מוגדר הביט DF, Google Cloud נשלחת גם הודעת Fragmentation Needed (ICMP over IPv4) או Packet Too Big (ICMPv6) בחזרה לשולח.

‫Google Cloud שולח הודעה מסוג Fragmentation Needed או Packet Too Big בנסיבות הבאות, גם כשביט DF מושבת:

  • אם ה-MTU של רשת ה-VPC קטן מ-1,600 בייטים, והחבילה שנשלחת גדולה מ-1,600 בייטים.
  • אם ה-MTU של רשת ה-VPC הוא 1,600 בייטים או יותר, והחבילה שנשלחת חורגת מה-MTU של רשת ה-VPC.

הודעות מסוג ICMP Fragmentation Needed או Packet Too Big נדרשות למכונה ששולחת חבילות כדי להשתמש ב-Path MTU discovery‏ (PMTUD). כדי להמחיש איך PMTUD פועל, נשתמש בדוגמה הבאה עם שתי מכונות ברשתות VPC שונות שמחוברות באמצעות VPC Network Peering:

  • למכונה השולחת יש NIC ברשת VPC עם MTU של 8,896 בייטים.
  • למכונה המקבלת יש NIC ברשת 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 וגם את הפרוטוקול שבו משתמשת חבילת הנתונים המקורית.

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

נסו בעצמכם

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

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