אז למה לא בעצם פרטנר?
אני כן מעוניין בכתובות מתחלפות.
אגב, רק בסלקום יש 1,000 מגה העלאה...
והמחיר הוגן. 149 ש"ח
סלקום 5000/1000 ציוד פרטי - בדיקת מהירות ושיהוי IPv4 לעומת IPv6
- Jabberwock
-
- חבר ותיק
- תגובות: 1301
- הצטרף: יולי 2024
- נתן תודות: 68 פעמים
- קיבל תודות: 157 פעמים
לכו חזו מפעלות יהוה אשר שם שמות בארץ. משבית מלחמות עד קצה הארץ קשת ישבר וקצץ חנית עגלות ישרף באש.
- DanielGR
-
- גורו רשתות
- תגובות: 1447
- הצטרף: יולי 2023
- שם מלא: DanielG
- מיקום: Israel
- נתן תודות: 217 פעמים
- קיבל תודות: 279 פעמים
פרטנר למיטב ידיעתי חברה טובה מאד, וחיבור שלהם על גבי תשתית בזק זו אלטרנטיבה ראויה.Jabberwock כתב: אז למה לא בעצם פרטנר?
אני כן מעוניין בכתובות מתחלפות.
אגב, רק בסלקום יש 1,000 מגה העלאה...
והמחיר הוגן. 149 ש"ח...
העלאה של 1000mbps יש רק על תשתית IBC עם כל המשמעויות הנלוות.
לידיעה כללית,DanielGR כתב: המסקנה למיטב הבנתי שהבעיה בסלקום.
במאמר מוסגר - זה מחזק את תחושתי שרשת בזק (ספק ותשתית) מבחינה טכנית היא הסולידית ביותר. הקונפיגורציה עקבית - כלומר אין איזורים שצריך VLAN ואיזורים שלא וכל זה תורה שבע"פ, כל נציג יכול להוציא מ-CGNAT לכתובת קבועה (אם כי זה עולה כסף), אין ניתוקים ב-PPPOE ויש פחות או אין בכלל מקרי קצה שלא עובדים כמו שצריך (כמו המתואר - אם כי צריך להודות ביושר שמקרי הקצה רלוונטים למספר מאד מצומצם של משתמשים)...
כל הבלאגן בהוט ובסלקום - זה כי הם נשענים על IBC.
יש פריסת סיבים של סלקום, יש פריסה של IBC, ובשנתיים-שלוש האחרונות - גם הוט עצמה התחילה לפרוס סיבים.
זה כל העניין עם אזורים שהם DASAN ואזורים שהם NOKIA.
כל אחד בנה מערך בשיטה שונה ואז מיזגו הכל ביחד.
יש מקומות שזה משתנה אפילו על פי שכונה.
אצל בזק אין משחקים - כי היחידה שפורסת היא בזק.
-
whatevernevermind
-
- חבר פעיל מאוד
- תגובות: 125
- הצטרף: אפריל 2025
- נתן תודות: 0
- קיבל תודות: 37 פעמים
כפי שכתבתי שפוסט בתחילת השרשור, כבר ניסיתי את זה קודם. הmru עלה ל1500 אבל הmtu נותר 1492. זה לא הספיק כדי לפתור את התקיעה בIPv6 ועדיין נדרש mss clamp.DanielGR כתב: יפה, רק בבדיקה צריכים להוסיף flag של Do not fragment
-M
עריכה: ההודעות הצטלבו, (ב-IPV6 אין פרגמנטציה, יש ב- IPV4) ושם צריך לבדוק , יפה
@Jabberwock @whatevernevermind תוכלו לבדוק?...
גם הגדלה מלאכותית של הmtu אינה הפתרון בכל מקרה, כי הבעיה היא מן הסתם רק בIPv6 (המנגנון של IPv4 ממילא עובד אחרת), ובעיית השורש היא ההתעלמות/חסימה/מניעה של ICMPv6 Packet Too Big של אחד הצדדים. זה הדבר שמנוגד לתקן שקורה פה.
ספקיות לא מחוייבות לתמוך בMTU מסויים אך כן מחוייבות לתמוך בתקן IPv6 וכאן זה קורה רק חלקית - שוב, לא יודע בלי בדיקה נוספת לקבוע אם זה בצד סלקום שחוסם לכיוון Azure או של Azure שמסרב לקבל מסלקום את ה-Packet Too Big.
בעניין בזק - הרי שגם לבזק היו בעיות הגדרה בזמנו. בפרט זכורה לרעה הגדרת מיפוי הdscp-to-pbit התקולה בפרופיל של G-010S-A, שגרמה לכך שכל dscp>7 היה נחסם, ובפרט שיחות voip ווידאו כולל זום ו-WhatsApp... המיפוי שבזק עצמה הגדירה גרם לתרגום dscp>7 ל pbit>0 בעוד תשתית בזק עצמה באותו זמן חסמה pbit>0...
- DanielGR
-
- גורו רשתות
- תגובות: 1447
- הצטרף: יולי 2023
- שם מלא: DanielG
- מיקום: Israel
- נתן תודות: 217 פעמים
- קיבל תודות: 279 פעמים
הרשתות שלנו מתנהגות אחרת - כפי שכתבתי בפוסט קודם - גם ה- MTU וגם ה-MRU הם על 1500:כפי שכתבתי שפוסט בתחילת השרשור, כבר ניסיתי את זה קודם. הmru עלה ל1500 אבל הmtu נותר 1492. זה לא הספיק כדי לפתור את התקיעה בIPv6 ועדיין נדרש mss clamp....
בחרתי די בקפידה את הניסוח:
בוודאי שעצם העובדה שמנגנון ה- PMTU Discovery נכשל זה לא בהתאם לסטנדרט ולא רצוי. כל המטרה בדיון היא לראות האם קיימת אפשרות לעקוף (חלק) מהבעיה מבלי לשנות משהו אצל הספקית שזה לא אפשרי בפועל....לכן המנגנון של PMTU discovery לא מתייתר לחלוטין, אבל יהיו פחות מצבים שתלויים בו, ומכאן הסתברות נמוכה יותר לבעיות כתוצאה מכשל ב- PMTU Discovery...
האפקטיביות של השינוי ניתנת לבדיקה באופן הבא (ברשתות שהמנגנון עובד):
ראו את שורת הפקודה הבאה: (ב- UCG Fiber)
קוד: בחירת הכל
ping -6 -s 1452 -M dont 2001:4860:4860::8888- Jabberwock
-
- חבר ותיק
- תגובות: 1301
- הצטרף: יולי 2024
- נתן תודות: 68 פעמים
- קיבל תודות: 157 פעמים
המחיר 289 ש"ח....
פרטנר רצו לחבר אותי דרך IBC. אבל טענו שהעלאה 500 מגה על התשתית הזאת דרכם. ולטענתם יש לקוחות שהם הצליחו לחבר על תשתית זו. למרות שאותי לא הצליחו לחבר.DanielGR כתב: העלאה של 1000mbps יש רק על תשתית IBC עם כל המשמעויות הנלוות....
בינתיים ה-MTU על 1500 אצלי. האם זה משפר לי את החיבור? (ב-IPV4 בכל אופן)
לכו חזו מפעלות יהוה אשר שם שמות בארץ. משבית מלחמות עד קצה הארץ קשת ישבר וקצץ חנית עגלות ישרף באש.
- DanielGR
-
- גורו רשתות
- תגובות: 1447
- הצטרף: יולי 2023
- שם מלא: DanielG
- מיקום: Israel
- נתן תודות: 217 פעמים
- קיבל תודות: 279 פעמים
Ethernet Frame סטנדרטי הוא 1500 בייט. בהנחה שרוב השרתים מחוברים באופן סטנדרטי (כלומר לא דרך Tunnel למיניהם) ונתבים לאורך המסלול לא מגבילים את גודל ה-Frame אז הבעיה היחידה שנותרת היא נקודת הקצה של המשתמש שמחובר עם PPPOE כאשר מתוך ה-Frame הסטנדרטי יורדים 8 בייט שהן התקורה של PPPOE, כלומר נותר 1492, זה יגרום לפרגמנטציה.
השינוי הזה ב- MTU ו-MRU מאפשר לקליינט המחובר ב-PPPOE להיראות ברשת מבחינת MTU כאילו הוא מחובר ב-Ethernet סטנדרטי, ויהיו פחות מקרים בהם צריך לבצע Clamping. זה לא מייתר את מנגנון ה-PMTU Discovery.
התקורה ביחס ל-Payload תהיה יותר נמוכה אבל זה ממש זניח.
להבנתי אם RFC-4638 נתמך על ידי הנתב ועל ידי הספקית - עדיף להשתמש בזה. ממה שידוע לי כרגע באופן וודאי, MikroTik routerOS וכן UCG-Fiber תומכים בזה, וכן רשת בזק (כתשתית + ספק). לגבי השאר - אינני יודע - צריך משוב מהקהילה.
הסיבה שהנתב צריך לתמוך בזה ברורה מהתיאור ב- RFC:
PPPoE Discovery Stage
If a PPPoE client wants to use an MTU/MRU higher than 1492 octets,
then it MUST include an optional PPP-Max-Payload Tag in the PADI and
PADR packets. If the PPPoE server can support an MTU/MRU higher than
1492 octets, it MUST respond with an echo of the clients tag in the
PADO and PADS packets when the PPP-Max-Payload tag is received from
the client.
Tag-name: PPP-Max-Payload
Tag-value: 0x0120
Tag-length: 2 octets
Tag-value: binary encoded value (max PPP payload in octets)
Tag-description:
This TAG indicates that the client and server are capable of
supporting a given maximum PPP payload greater than 1492 octets for
both the sending and receiving directions. Note that this value
represents the PPP payload; therefore it is directly comparable with
the value used in the PPP MRU negotiation.
השינוי הזה ב- MTU ו-MRU מאפשר לקליינט המחובר ב-PPPOE להיראות ברשת מבחינת MTU כאילו הוא מחובר ב-Ethernet סטנדרטי, ויהיו פחות מקרים בהם צריך לבצע Clamping. זה לא מייתר את מנגנון ה-PMTU Discovery.
התקורה ביחס ל-Payload תהיה יותר נמוכה אבל זה ממש זניח.
להבנתי אם RFC-4638 נתמך על ידי הנתב ועל ידי הספקית - עדיף להשתמש בזה. ממה שידוע לי כרגע באופן וודאי, MikroTik routerOS וכן UCG-Fiber תומכים בזה, וכן רשת בזק (כתשתית + ספק). לגבי השאר - אינני יודע - צריך משוב מהקהילה.
הסיבה שהנתב צריך לתמוך בזה ברורה מהתיאור ב- RFC:
PPPoE Discovery Stage
If a PPPoE client wants to use an MTU/MRU higher than 1492 octets,
then it MUST include an optional PPP-Max-Payload Tag in the PADI and
PADR packets. If the PPPoE server can support an MTU/MRU higher than
1492 octets, it MUST respond with an echo of the clients tag in the
PADO and PADS packets when the PPP-Max-Payload tag is received from
the client.
Tag-name: PPP-Max-Payload
Tag-value: 0x0120
Tag-length: 2 octets
Tag-value: binary encoded value (max PPP payload in octets)
Tag-description:
This TAG indicates that the client and server are capable of
supporting a given maximum PPP payload greater than 1492 octets for
both the sending and receiving directions. Note that this value
represents the PPP payload; therefore it is directly comparable with
the value used in the PPP MRU negotiation.
- Jabberwock
-
- חבר ותיק
- תגובות: 1301
- הצטרף: יולי 2024
- נתן תודות: 68 פעמים
- קיבל תודות: 157 פעמים
טוב, בדקתי את טענת פותח הדיון שבחיבור IPv6 יש שיהוי נמוך יותר מאשר IPv4. מסתבר שלפחות בבדיקות שלי, הטענה הזאת לא נכונה.
להלן התוצאות:
אקצר:
נצפה 3ms הפרש לטובת IPv4 עבור:
גוגל, פייסבוק, fastly.com.
עבור cloudflare יש תיקו.
עבור microsoft לא הצלחתי לבדוק, יש חסימה.
להלן התוצאות:
קוד: בחירת הכל
ping -4 google.com
Pinging google.com [142.250.75.206] with 32 bytes of data:
Reply from 142.250.75.206: bytes=32 time=2ms TTL=117
Reply from 142.250.75.206: bytes=32 time=2ms TTL=117
Reply from 142.250.75.206: bytes=32 time=2ms TTL=117
Reply from 142.250.75.206: bytes=32 time=2ms TTL=117
Ping statistics for 142.250.75.206:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 2ms, Maximum = 2ms, Average = 2msקוד: בחירת הכל
ping -6 google.com
Pinging google.com [2a00:1450:4028:80b::200e] with 32 bytes of data:
Reply from 2a00:1450:4028:80b::200e: time=5ms
Reply from 2a00:1450:4028:80b::200e: time=5ms
Reply from 2a00:1450:4028:80b::200e: time=5ms
Reply from 2a00:1450:4028:80b::200e: time=5ms
Ping statistics for 2a00:1450:4028:80b::200e:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 5ms, Maximum = 5ms, Average = 5msנצפה 3ms הפרש לטובת IPv4 עבור:
גוגל, פייסבוק, fastly.com.
עבור cloudflare יש תיקו.
עבור microsoft לא הצלחתי לבדוק, יש חסימה.
לכו חזו מפעלות יהוה אשר שם שמות בארץ. משבית מלחמות עד קצה הארץ קשת ישבר וקצץ חנית עגלות ישרף באש.
- Jabberwock
-
- חבר ותיק
- תגובות: 1301
- הצטרף: יולי 2024
- נתן תודות: 68 פעמים
- קיבל תודות: 157 פעמים
פרטנר הציעו לי את החבילה 5000 מגה ב-200 ש"ח.
מהירות העלאה 500 מגה בלבד גם על התשתית IBC.
טוענים שהמהירות לחו"ל יותר טובה משל סלקום.
מהירות העלאה 500 מגה בלבד גם על התשתית IBC.
טוענים שהמהירות לחו"ל יותר טובה משל סלקום.
לכו חזו מפעלות יהוה אשר שם שמות בארץ. משבית מלחמות עד קצה הארץ קשת ישבר וקצץ חנית עגלות ישרף באש.
- Jabberwock
-
- חבר ותיק
- תגובות: 1301
- הצטרף: יולי 2024
- נתן תודות: 68 פעמים
- קיבל תודות: 157 פעמים
זכור לי על פי מה שאמרו פה חברים בפורום ששניתן לשמר את מחיר המבצע של 179 ש"ח גם לאחר שנה בבזק.
לכו חזו מפעלות יהוה אשר שם שמות בארץ. משבית מלחמות עד קצה הארץ קשת ישבר וקצץ חנית עגלות ישרף באש.
- amdr1
-
- חבר פעיל במיוחד
- תגובות: 731
- הצטרף: מאי 2013
- מיקום: אופקים
- נתן תודות: 52 פעמים
- קיבל תודות: 59 פעמים
בעניין בזק - הרי שגם לבזק היו בעיות הגדרה בזמנו. בפרט זכורה לרעה הגדרת מיפוי הdscp-to-pbit התקולה בפרופיל של G-010S-A, שגרמה לכך שכל dscp>7 היה נחסם, ובפרט שיחות voip ווידאו כולל זום ו-WhatsApp... המיפוי שבזק עצמה הגדירה גרם לתרגום dscp>7 ל pbit>0 בעוד תשתית בזק עצמה באותו זמן חסמה pbit>0......
אני שנתיים עם G-010-SA
לא היו שום בעיות עם voip/וידאו/whatsupp
- DanielGR
-
- גורו רשתות
- תגובות: 1447
- הצטרף: יולי 2023
- שם מלא: DanielG
- מיקום: Israel
- נתן תודות: 217 פעמים
- קיבל תודות: 279 פעמים
