סלקום 5000/1000 ציוד פרטי - בדיקת מהירות ושיהוי IPv4 לעומת IPv6

[Jabberwock]

הסיכום של קלוד לא כ"כ נכון, אולי כי המידע שהוזן לו היה לא מדוייק.

...

קלוד ביקש שאריץ פקודות. אני רק העברתי את הפלט בחזרה אליו.

[DanielGR]

חקרתי את הבעיה הזו. מסתבר שמה שיכול לפתור לחלוטין את בעיית הפרגמנטציה זה לדאוג לכך שה-MTU יהיה 1500, בדיוק הגודל הסטנדרטי של Ethernet frame, ואז ה- WAN וה- LAN יהיו עם אותו MTU. מכיוון ש-IPV6 רוכב על אותו Session של PPPOE אז זה ישים גם ל- IPV6.

ברירת המחדל לפחות של בזק שאליה אני מחובר היא 1492, שזה 1500-8 כאשר 8 היא התקורה של PPPOE.

קיים סטנדרט המגדיר יישום של MTU גבוה מ-1492:

קוד: בחירת הכל

https://datatracker.ietf.org/doc/html/rfc4638

הבדיקה ב- Mikrotik RouterOS היא פשוטה: (בבקשה להתעלם משמות הממשקים - זה ספציפי להתקן שלי)

קוד: בחירת הכל

/interface vlan set vlan-wan mtu=1508 
/interface pppoe-client set pppoe-wan max-mtu=1500 max-mru=1500

ואז הבדיקה - מקומית:

קוד: בחירת הכל

/interface pppoe-client monitor pppoe-wan once

תוצאה:

מעולה, התחבר על 1500. ועכשיו הבדיקה האולטימטיבית - קצה לקצה:

קוד: בחירת הכל

/ping 8.8.8.8 size=1500 do-not-fragment count=5

מעולה ביותר - אכן 1500 ללא פרגמנטציה לאורך כל הדרך.

מה שנותר לבדוק זה האם סלקום מממשים את RFC4638, בבזק התשובה חיובית בוודאות, וכמובן לנסות עם נתבים אחרים.

עריכה: אם רוצים לבדוק מ-Client ברשת המריץ Windows הפקודה היא:

קוד: בחירת הכל

ping 8.8.8.8 -l 1472 -f

הסיבה היא שב-Windows הפרמטר של הגודל מגדיר את ה- Payload, וההפרש הוא ה- Headers, כלומר: 1472 +20 +8 = 1500. פרמטר -f משמעו - Do not fragment

[OMRIJ]

unifi הוסיפו אפשרות לMTU 1500 ב PPPOE בגירסה 10.5.54

[DanielGR]

יפה, רק בבדיקה צריכים להוסיף flag של Do not fragment

-M

עריכה: ההודעות הצטלבו, (ב-IPV6 אין פרגמנטציה, יש ב- IPV4) ושם צריך לבדוק , יפה

@Jabberwock @whatevernevermind תוכלו לבדוק?

[OMRIJ]

[DanielGR]

יפה, מי הספקית שלך?

[OMRIJ]

בזק תשתית וספק

[Jabberwock]

בדקתי.
ב-IPv4 זה עובד. ניתן לעבוד עם 1500 MTU.
ב-IPv6 אין שינוי.

סיכום של קלוד:

MTU Findings Summary — PPPoE Fiber Connection (UCG-Fiber)
IPv4: Full 1500 MTU

ping 8.8.8.8 -l 1472 -f succeeds → 1472 payload + 8 ICMP + 20 IPv4 = 1500 bytes, unfragmented.
The PPPoE link negotiated 1500 MTU (RFC 4638 "baby jumbo frames" — the ISP absorbs the 8-byte PPPoE overhead at layer 2).
IPv4 traffic therefore runs at the full standard MTU with no restrictions.

IPv6: Limited to 1280 MTU
Despite riding the same 1500-MTU ppp0 link, IPv6 is capped at 1280 (the IPv6 protocol minimum):

The ISP's Router Advertisements explicitly set it. tcpdump on ppp0 captured the RA containing mtu option (5): 1280. The router honors this (accept_ra_mtu = 1), installing mtu 1280 on the IPv6 default route. All IPv6 destinations are affected (Google, Cloudflare, etc.).
The limit is real, not just conservative. A test host route with mtu 1500 allowed 1452-byte pings out onto the wire — and they were silently dropped: no replies, no ICMPv6 "Packet Too Big." Something inside the ISP's IPv6 network (likely a tunnel/encapsulation hop) cannot carry packets larger than 1280.
It's a PMTU black hole. The limiting hop fails to send the required Packet Too Big messages. The ISP's 1280 RA is evidently a workaround for this: by forcing all customer traffic to ≤1280 preemptively, broken path-MTU discovery never gets triggered.

Why IPv4 and IPv6 differ on the same link
The bottleneck is not the PPPoE link — it's in how the ISP transports IPv6 internally. IPv4 takes a native 1500-clean path; IPv6 apparently traverses additional encapsulation on the ISP side, eating ~220 bytes of headroom (or simply routed through equipment configured at the 1280 floor).
Resulting configuration (correct as-is)

Keep the RA-learned 1280 MTU — overriding it (accept_ra_mtu=0) would cause hung connections due to the silent black hole.
Keep the ip6tables TCPMSS --clamp-mss-to-pmtu rules on ppp0 — they clamp forwarded TCP to MSS 1220, protecting LAN clients from servers with broken PMTUD. On this connection they are essential, not optional.

For the ISP
"Your IPv6 path drops packets >1280 bytes without returning ICMPv6 Packet Too Big, and your RAs advertise MTU 1280 accordingly — while IPv4 on the same PPPoE session passes 1500 cleanly. Can IPv6 be brought to full 1500 MTU?" — likely a BNG/tunnel-concentrator config issue rather than a hardware limit.

...

קוד: בחירת הכל

root@UCG-Fiber:~# tcpdump -i ppp0 -vv icmp6 and 'ip6[40] == 134' -c 1
tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes
11:38:19.215361 IP6 (class 0xe0, hlim 255, next-header ICMPv6 (58) payload length: 64) fe80::5249:21ff:feb4:3333 > ip6-allnodes: [icmp6 sum ok] ICMP6, router advertisement, length 64
        hop limit 64, Flags [other stateful], pref medium, router lifetime 1800s, reachable time 0ms, retrans timer 0ms
          source link-address option (1), length 8 (1): 50:49:21:b4:33:33
            0x0000:  5049 21b4 3333
          mtu option (5), length 8 (1):  1280
            0x0000:  0000 0000 0500
          prefix info option (3), length 32 (4): 2001:4df3:27:53ee::/64, Flags [onlink, auto], valid time 2592000s, pref. time 604800s
            0x0000:  40c0 0027 8d00 0009 3a80 0000 0000 2001
            0x0010:  4df3 0027 53ee 0000 0000 0000 0000
1 packet captured
1 packet received by filter
0 packets dropped by kernel

[DanielGR]

חלק ממה שכתוב פשוט לא נכון.

IPV6 הוא לא Capped at 1280, בפירוש המינימום הוא 1280, לא התקרה. שימוש בהגדרות האלו מוריד נקודה שיכולה להיות בעייתית עם MTU ו- PPPOE מכיוון שהרשת הפנימית היא על 1500 וה-WAN היא על 1492.

אם השרת בצד השני מחובר גם דרך Tunnel או PPPOE אז עדיין קצה לקצה תהיה בעיה אך ההסתברות לכך לא גבוהה. לכן המנגנון של PMTU discovery לא מתייתר לחלוטין, אבל יהיו פחות מצבים שתלויים בו, ומכאן הסתברות נמוכה יותר לבעיות כתוצאה מכשל ב- PMTU Discovery

ראה את הבדיקה שביצע @OMRIJ ב-IPV6

[OMRIJ]

@jabberwock
תנסה להגדיר בwan שהipv6 יתקבל בdhcpv6 ולא slaac

[Jabberwock]

תנסה להגדיר בwan שהipv6 יתקבל בdhcpv6 ולא slaac

...

שיניתי, אבל מה אני בדיוק צריך לבדוק?
רק זה עובד:

קוד: בחירת הכל

ping -6 -l 1232 google.com

אני צריך לבטל את ההגדרה של PMTU?

[DanielGR]

להריץ את הבדיקה השניה שבדק Omrij כאן:

viewtopic.php?t=402679&start=20#p3407472+

[Jabberwock]

קוד: בחירת הכל

root@UCG-Fiber:~# ping -s 1452 -M do 2001:4860:4860:8888
ping: 2001:4860:4860:8888: Name or service not known
root@UCG-Fiber:~# ping -s 1452 -M do google.com
PING google.com(tztlva-ac-in-x0e.1e100.net (2a00:1450:4028:800::200e)) 1452 data bytes
ping: local error: message too long, mtu: 1280
ping: local error: message too long, mtu: 1280
ping: local error: message too long, mtu: 1280
^C
--- google.com ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2099ms

[DanielGR]

המממ, מה שעובד אצל @OMRIJ על אותו ציוד - לא עובד אצלך, ההבדל היחיד הוא הספקית, ואולי אופן הגדרת IPV6 שצריך להיות DHCP.

אני מניח שבדקת את IPV4 עם ה פרמטר של Do not fragment וזה עובד, ולכן מוזר כי V6 ו-V4 חולקים את אותו Layer 2.

[Jabberwock]

בדקתי הכול, גם SLAAC וגם DHCPv6. שניהם עובדים עם סלקום. אבל אני מעדיף את SLAAC כי בממשק של Unifi רואים שהראוטר עצמו מקבל כתובת IPv6 שהוא לוקח לעצמו, לא ברור לי מה ההשפעה של זה אבל זה מציק בעין לראות את זה ריק כש-DHCPv6 מוגדר.

השתמשתי גם ב-ChatGPT, הוא אומר בדיוק את מה שקלוד כותב. אבל הוא יותר חופר. אולי בגלל שאני לא משלם על מנוי Pro, אני על מנוי Go הזול.

עוד באג מעצבן מאוד עם Unifi, ברגע שאני משנה מצבים ב-IPv6 ומקבל כתובת חדשה, הכרטיס Mellanox או הוינדוס (תלוי את מי מאשימים) לא מוחק את הכתובת הישנה אלא רק מוסיף אותה. מה שוגרם לזה שאני צריך להפעיל מחדש את המחשב כי החיבור IPv6 מפסיק לעבוד.

או שאני מריץ סקריפט:

קוד: בחירת הכל

Get-NetIPAddress -AddressFamily IPv6 |
Where-Object {
    $_.PrefixOrigin -eq "RouterAdvertisement" -and
    $_.IPAddress -notlike "fe80:*"
} |
Remove-NetIPAddress -Confirm:$false

זה מוחק את הכתובות ואני מחכה ל-Router Advertisement הבא שמחזיר לי את החיבור.

[DanielGR]

גייסתי את ה- UCG-Fiber למילואים ובדקתי. ההתקן מעודכן ל-Release העדכני, הספקית היא בזק.

הקונפיגורציה כאמור:

IPV4:

והערה ל-@OMRIJ : שורת הפקודה המתאימה היא -M dont, על מנת לא לבצע PMTU Discovery והבדיקה אמורה להצליח גם ללא PMTU Discovery כאשר ה-MTU הוא 1500. לכן:

קוד: בחירת הכל

 ping -6 -s 1452 -M dont 2001:4860:4860::8888

והתוצאה:

כלומר עובד גם ללא PMTU Discovery מה שאומר ש-MTU 1500 מיושם ועובד בשני הפרוטוקולים. הקונפיגורציה שהשתמשתי היא SLAAC בלי בעיה.

אם אצל @Jabberwock הגדרות זהות לא עובדות כנראה שסלקום לא מממשת את RFC4638 כמו שצריך או בעיה אחרת (ברמת הספקית)

[Jabberwock]

בדקתי שוב עם הפקודות שלך.
כאמור, IPV4 עובד.
ב-IPV6 מצליח רק עד 1232.

[DanielGR]

בדקתי שוב עם הפקודות שלך.
כאמור, IPV4 עובד.
ב-IPV6 מצליח רק עד 1232.

...

המסקנה למיטב הבנתי שהבעיה בסלקום.

במאמר מוסגר - זה מחזק את תחושתי שרשת בזק (ספק ותשתית) מבחינה טכנית היא הסולידית ביותר. הקונפיגורציה עקבית - כלומר אין איזורים שצריך VLAN ואיזורים שלא וכל זה תורה שבע"פ, כל נציג יכול להוציא מ-CGNAT לכתובת קבועה (אם כי זה עולה כסף), אין ניתוקים ב-PPPOE ויש פחות או אין בכלל מקרי קצה שלא עובדים כמו שצריך (כמו המתואר - אם כי צריך להודות ביושר שמקרי הקצה רלוונטים למספר מאד מצומצם של משתמשים)

[OMRIJ]

עוד באג מעצבן מאוד עם Unifi, ברגע שאני משנה מצבים ב-IPv6 ומקבל כתובת חדשה, הכרטיס Mellanox או הוינדוס (תלוי את מי מאשימים) לא מוחק את הכתובת הישנה אלא רק מוסיף אותה. מה שוגרם לזה שאני צריך להפעיל מחדש את המחשב כי החיבור IPv6 מפסיק לעבוד.
או שאני מריץ סקריפט:

קוד: בחירת הכל

קוד: בחירת הכל

Get-NetIPAddress -AddressFamily IPv6 |Where-Object {    $_.PrefixOrigin -eq "RouterAdvertisement" -and    $_.IPAddress -notlike "fe80:*"} |Remove-NetIPAddress -Confirm:$false

זה מוחק את הכתובות ואני מחכה ל-Router Advertisement הבא שמחזיר לי את החיבור.

...

זה לא באג בUNIFI
זה ההגדרות ברירת מחדל של SLAAC
בOPNSENSE למשל אפשר לקצר את הVALIDLIFETIME וכו'
אבל בכל מקרה, הכתובת הישנה לא אמורה להפריע לשום דבר
היא אמורה להיות בסטטוס deprecated
/home/omri/Desktop/ללא שם.png

[OMRIJ]

במאמר מוסגר - זה מחזק את תחושתי שרשת בזק (ספק ותשתית) מבחינה טכנית היא הסולידית ביותר. הקונפיגורציה עקבית - כלומר אין איזורים שצריך VLAN ואיזורים שלא וכל זה תורה שבע"פ, כל נציג יכול להוציא מ-CGNAT לכתובת קבועה (אם כי זה עולה כסף), אין ניתוקים ב-PPPOE ויש פחות או אין בכלל מקרי קצה שלא עובדים כמו שצריך (כמו המתואר - אם כי צריך להודות ביושר שמקרי הקצה רלוונטים למספר מאד מצומצם של משתמשים)

...

לגמרי מסכים
שווה מבחינתי את הפרמיה הנוספת בתשלום