שיחה במרכזייה בענן צורכת כ-0.1 מגה-ביט לשנייה, ובכל זאת היא הראשונה שנקטעת כשמישהו במשרד מעלה קובץ גדול. בדיקת תעבורת רשת לעסק נועדה לגלות בדיוק את זה: לא כמה מהיר הקו, אלא מה קורה להשהיה (Latency) ולריצוד (Jitter) כשהקו עמוס, ואיפה במסלול נוצרת התקלה. הבדיקה למטה רצה בדפדפן ונותנת תשובה תוך דקה. אחריה מפורט איך מאבחנים את המקור: הקו, הנתב, הרשת הפנימית או הספק.
בדיקת מוכנות הרשת למרכזייה בענן
האינטרנט "עובד", אבל השיחות מגמגמות או נקטעות? הבדיקה מודדת בדפדפן את מה שקובע איכות שיחה: השהיה (Latency), ריצוד (Jitter) וקצב העלאה, גם במצב רגיל וגם כשהקו עמוס. משך הבדיקה: כ-30 עד 60 שניות.
1. מה המצב אצלכם היום?
לתוצאה מדויקת: הריצו ממחשב במשרד שמחובר בכבל רשת, כשאף אחד לא מוריד קבצים גדולים. לא מומלץ להריץ בגלישה סלולרית (הבדיקה מורידה ומעלה עשרות עד מאות מגה-בייט).
מתחילים...
איך מחושבת התוצאה (לשקיפות מלאה)
המדידה רצה בדפדפן מול שרת Cloudflare שהספק שלכם מנתב אליו (בחלק מהספקים בישראל זה שרת באירופה, והתוצאה מציינת את מיקומו), עם רכיב הקוד הפתוח של Cloudflare למדידת מהירות. התוצאות לא נשלחות ל-Cloudflare ולא נשמרות אצלנו, אלא אם תבחרו לשלוח אותן בוואטסאפ.
| מדד | טוב | גבולי | בעייתי | בסיס |
|---|---|---|---|---|
| השהיה הלוך-חזור (RTT) | עד 100ms | 100-200ms | מעל 200ms | ITU-T G.114: עד 150ms בכיוון אחד מקובל לשיחה |
| ריצוד (Jitter) | עד 15ms | 15-30ms | מעל 30ms | המלצת Cisco לתעבורת קול: עד 30ms |
| קפיצת השהיה בעומס | עד 50ms | 50-100ms | מעל 100ms | הערכה הנדסית: עומס תורים בנתב (Bufferbloat) |
| ציון איכות שיחה משוער (MOS) | 4.0 ומעלה | 3.6-4.0 | מתחת ל-3.6 | ITU-T G.107 (מודל E): R=80 ≈ MOS 4.0, R=70 ≈ MOS 3.6 |
חישוב MOS: השהיה אפקטיבית = השהיה + 2×ריצוד + 10ms; R = 93.2 − השהיה אפקטיבית/40 (מעל 160ms: 93.2 − (השהיה−120)/10); MOS = 1 + 0.035R + 0.000007R(R−60)(100−R). זהו הקירוב המקובל של מודל E לקודק G.711. הציון "בעומס" מחושב מההשהיה והריצוד שנמדדו בזמן הורדה והעלאה. ריצוד מעל 30ms או קפיצת השהיה מעל 100ms בעומס מורידים את המסקנה לפחות ל"גבולית", גם כשהציון גבוה.
קיבולת שיחות: כ-0.1Mbps לשיחה בכל כיוון (G.711 עם תקורת IP ואתרנט, כ-87kbps). זו קיבולת תיאורטית בלי שאר התעבורה במשרד; לחישוב מלא של רוחב הפס הנדרש ראו את מחשבון רוחב הפס לעסק.
מה הבדיקה לא מודדת: אובדן חבילות (Packet Loss), ואת הדרך עד השרת של ספק המרכזייה הספציפי. רשת Wi-Fi חלשה במחשב הבודק תוריד את התוצאה גם כשהקו עצמו תקין. לאבחון מלא, מהנדס בודק גם את הנתב, הגדרות QoS וה-SIP ALG.
מה בודקת בדיקת תעבורת רשת, ומה בדיקת מהירות רגילה לא רואה
בדיקת מהירות של ספק אינטרנט מודדת דבר אחד: כמה מגה-ביט עוברים בשנייה כשהקו פנוי. לגלישה ולהורדות זה מספיק. לשיחות, לשולחן עבודה מרוחק ולתוכנות שעובדות מול שרת בענן זה כמעט לא רלוונטי, משום שהן צורכות מעט רוחב פס ורגישות מאוד לעיכובים.
אלה המדדים שקובעים אם הרשת מתאימה לשיחות ולעבודה בזמן אמת:
| מדד | מה הוא אומר | מתי הוא הבעיה |
|---|---|---|
| השהיה (Latency) | כמה זמן לוקח לחבילה להגיע ליעד ולחזור | מעל 150 אלפיות שנייה בכיוון אחד, הדובר מתחיל לדבר על השני |
| ריצוד (Jitter) | כמה ההשהיה משתנה בין חבילה לחבילה | מעל 30 אלפיות שנייה, הקול נשמע מקוטע או "רובוטי" |
| השהיה בעומס | כמה ההשהיה קופצת כשמורידים או מעלים קבצים | קפיצה של מעל 100 אלפיות שנייה: הנתב מחזיק תורים ארוכים מדי |
| אובדן חבילות (Packet Loss) | כמה חבילות לא מגיעות בכלל | מעל 1%, מילים שלמות נעלמות מהשיחה |
| קצב העלאה | כמה מידע יוצא מהמשרד בשנייה | כשגיבוי לענן, מצלמות ושיחות מתחרים על קו אסימטרי |
ספי ההשהיה מבוססים על המלצת ITU-T G.114, שקובעת עד 150 אלפיות שנייה בכיוון אחד כגבול לשיחה טבעית. ציון איכות השיחה (MOS) בבדיקה מחושב לפי מודל E של ה-ITU. שים לב לשורה השלישית בטבלה. היא הסיבה, שבגללה רוב הבדיקות המוכרות מחזירות "הכול תקין" לעסק, שהשיחות שלו נקטעות כל יום.
למה השיחות נקטעות כשהאינטרנט נראה תקין?
הנתב במשרד מחזיק תור של חבילות שממתינות לצאת לקו. כשמישהו מעלה קובץ גדול, מסנכרן תיקייה לענן או כשגיבוי לילי נמשך עד הבוקר, התור מתמלא. חבילת קול, שצריכה לצאת תוך עשרות אלפיות שנייה, נתקעת מאחורי מאות חבילות של הקובץ. התופעה נקראת Bufferbloat (תורים מנופחים בנתב), והיא לא מופיעה בבדיקת מהירות רגילה, משום שזו נמדדת על קו פנוי.
התוצאה בשטח מוכרת: בבוקר השיחות תקינות, בצהריים הלקוח שומע רק חצי משפט, וטכנאי הספק מגיע, מריץ בדיקת מהירות ומודיע שהקו תקין. הוא צודק. הקו באמת תקין.
מהשיחות שאנו מקבלים עולה תבנית חוזרת: עסק מחליף לקו מהיר יותר, והקטיעות נמשכות. שיחת IP תופסת אחוזים בודדים מקו של 100 מגה, ולכן קו מהיר לא פותר תור מנופח. מה שפותר הוא תעדוף תעבורת קול בנתב (QoS), ניהול תורים שמונע מהקבצים לחסום את הקול, ותזמון גיבויים כבדים מחוץ לשעות העבודה. בקו אסימטרי עם העלאה נמוכה הבעיה חריפה במיוחד, כי ההעלאה נגמרת הרבה לפני ההורדה.
הבדיקה בראש העמוד מודדת את ההשהיה והריצוד פעמיים: כשהקו פנוי, ובזמן הורדה והעלאה. אם הריצוד קופץ מ-3 ל-60 אלפיות שנייה בעומס, מצאת את מקור הקטיעות.
זיהוי ואבחון תקלות רשת: הקו, הנתב, הרשת הפנימית או הספק
אבחון נכון מתקדם מהקרוב אל הרחוק. כל שלב מוציא מהמשחק חלק אחד של המסלול, וחוסך את הוויכוח הקבוע בין ספק התשתית, ספק האינטרנט וספק המרכזייה.
1. המחשב והרשת האלחוטית. מריצים את הבדיקה פעם אחת ב-WiFi ופעם בכבל רשת, מאותה נקודה. אם הריצוד נעלם בכבל, הבעיה ברשת האלחוטית ולא בקו. זה המצב בפניות רבות על "אינטרנט שנופל" במשרדים, ובמיוחד כשהנתב של הספק משמש גם כנקודת הגישה היחידה למשרד שלם.
2. שעה שקטה מול שעת עומס. בדיקה בשבע בבוקר ובדיקה באחת עשרה, באותם תנאים. הבדל גדול בהשהיה בעומס מצביע על תורים בנתב או על קו שהעלאה שלו לא מספיקה.
3. הנתב. כאן מתגלות רוב התקלות שספקים לא רואים. שתי הגדרות חוזרות בבירור: SIP ALG, פונקציה בנתבים רבים שמנסה "לעזור" לשיחות IP ובפועל משבשת אותן (לרוב מכבים אותה), והיעדר תעדוף לקול. מקרה מיוחד הוא ציוד מנוהל, שספק האינטרנט מחזיק את הסיסמאות שלו: הלקוח לא מגיע להגדרות, ובחלק מהמקרים הספק לא פותח את הפורטים, שהמרכזייה בענן צריכה.
4. ההתאוששות אחרי נפילה. מרכזייה, שחוזרת לעבוד בשיחות פנימיות אחרי נפילת אינטרנט ולא חוזרת לשיחות חוץ, מצביעה בדרך כלל על הגדרות הנתב ועל רישום (Registration) שלא מתחדש אוטומטית. לפני שמאשימים את ספק ה-SIP, בודקים את זה.
5. הספק. רק אחרי שהשלבים הקודמים נקיים. אם הבדיקה בכבל, בשעה שקטה ומול נתב מוגדר נכון עדיין מראה השהיה גבוהה או ריצוד, זה עניין של התשתית או של הניתוב אצל הספק. במקרה כזה מתעדים: צילום של כמה בדיקות בשעות שונות, עם תאריך. פנייה עם נתונים מקבלת טיפול אחר מפנייה עם "השיחות לא טובות".
יודגש, שבמשרד עם חוזה נפרד לתשתית ולגישה לאינטרנט כל ספק נוטה להחריג את תקלות השני. מדידה מתועדת היא הדרך היחידה לצאת מהלולאה הזו.
בדיקת תעבורת רשת לעסק בודקת ארבעה מדדים: השהיה (עד 150 אלפיות שנייה בכיוון אחד), ריצוד (עד 30), קפיצת השהיה בעומס (עד 100) ואובדן חבילות (עד 1%). אבחון תקלה מתקדם מהקרוב אל הרחוק: WiFi מול כבל, שעה שקטה מול שעת עומס, הגדרות הנתב, ההתאוששות אחרי נפילה, ורק בסוף הספק.
מערכות לניטור תעבורת רשת: מה מתאים לעסק בגודל שלך
בדיקה חד פעמית מאבחנת תקלה שקורה עכשיו. תקלה שחוזרת פעם בשבוע דורשת ניטור רציף. יש ארבע שכבות של כלים, והן לא מחליפות זו את זו.
- ניטור זמינות ועומס (SNMP). הנתב, המתגים והשרתים מדווחים על עומס בממשקים, שגיאות וזמינות. זו השכבה הבסיסית, והיא מתאימה גם למשרד של עשרה עובדים.
- ניטור זרימות (NetFlow, sFlow), שמראה מי צורך את הקו ובאיזה יישום. מתאים כשהשאלה היא "מי חונק את ההעלאה בצהריים".
- לכידת חבילות. כלי כמו Wireshark שומר כל חבילה שעוברת במקטע הנבדק ומאפשר לראות איפה שיחה מסוימת השתבשה. זה כלי של מהנדס לתקלה ספציפית, לא מערכת שמשאירים פועלת.
- ניטור סינתטי של קול: מכשיר או תוכנה שמבצעים שיחות בדיקה קבועות ומדווחים על ציון איכות. בעסק שהטלפון הוא ערוץ המכירה העיקרי, זה הכלי שמתריע לפני שהלקוחות מתלוננים.
לעסק של 5 עד 50 עובדים בלי מנהל רשת, שכבה ראשונה בנתב עם יכולות ניטור, יחד עם בדיקה כמו זו שבעמוד בזמן תקלה, פותרות את רוב המקרים. ארגון עם כמה סניפים ומוקד טלפוני צריך כבר ניטור רציף של איכות הקול. כמו כל רכישה בעסק, גם כאן מתחילים מבחינת הצרכים של המשתמשים והתשתית הקיימת, ולא מרשימת היכולות של המערכת.
מה לבדוק מול הספק לפני שחותמים
רוב התקלות שתוארו כאן מתחילות בחוזה, הרבה לפני שהן מגיעות לנתב. לפני שחותמים על קו אינטרנט או על מרכזייה בענן, כדאי לברר:
- מי מחזיק את הסיסמאות לנתב, ובאיזה זמן הספק מבצע שינוי הגדרות שביקשת.
- האם הנתב תומך בתעדוף קול (QoS) וברשת וירטואלית נפרדת לטלפונים (VLAN).
- על מה חל ה-SLA (התחייבות לרמת שירות). ברוב החוזים הוא מתחייב לזמינות הקו ולזמן תיקון, לא להשהיה או לריצוד. קו "זמין" עם ריצוד של 80 אלפיות שנייה עומד בחוזה.
- מה קורה כשהקו נופל: הפניה אוטומטית של שיחות לניידים, נתב עם גיבוי סלולרי, או שניהם.
- UPS (אל-פסק). לא רק למחשב. לכל שרשרת הקול: הנתב, המתג שמזין את הטלפונים בחשמל (PoE) והמודם.
אם אתה מתכנן מעבר למרכזייה בענן, כדאי להריץ את הבדיקה לפני המעבר ולא אחריו. הסבר על מרכזיות בענן לעסקים ועל מה שהן דורשות מהרשת נמצא בעמוד נפרד. לחישוב של רוחב הפס הנדרש לכל מה שרץ במשרד, ולא רק לשיחות, השתמש במחשבון רוחב הפס לעסק.
שורה תחתונה: בדיקת תעבורת רשת לפני שמחליפים קו או ספק
רוב העסקים שמתלוננים על שיחות שנקטעות לא צריכים קו מהיר יותר. הם צריכים נתב מוגדר נכון, תעדוף לקול ותזמון של התעבורה הכבדה. החלפת ספק בלי אבחון היא דרך יקרה לגלות, שהבעיה עברה איתך לקו החדש.
הרץ את הבדיקה בראש העמוד בשעת עומס ושלח לי את התוצאות בוואטסאפ, ואגיד לך איפה הבעיה ומה צריך לתקן: בנתב, ברשת הפנימית או בקו. אפשר גם להתקשר: 077-8123111. לפרויקט רחב יותר של תכנון והקמת תשתיות תקשורת ומחשוב במשרד, אנו מלווים מהאפיון ועד ההתקנה.
תשובות לשאלות נפוצות
בודקים את התעבורה קצה לקצה, מהמכשיר ברשת הפנימית ועד השירות בענן, ולא רק את הקו של הספק. ספקי התשתית מנטרים ומתקנים רק את הרשתות שלהם, ולא מודדים את הכבילה המקומית ואת מה שקורה בתוך הענן. מדידה בכמה נקודות לאורך המסלול מראה איפה נוצרים איבוד מנות, השהיה או ניתוקים, ומאפשרת לפנות לגורם הנכון עם נתונים ביד.
ניטור זרימות (NetFlow, sFlow) מסכם מי מדבר עם מי, באיזה נפח ובאיזה פרוטוקול, והוא מתאים למעקב רציף בעומס נמוך. לכידת חבילות ב-Wireshark שומרת כל מנה שעוברת ברשת ומאפשרת לראות בדיוק מה השתבש, אבל דורשת יותר אחסון ומשאבים. בפועל משתמשים בניטור זרימות לתמונה הכללית ולהתראות, ובלכידת חבילות לאבחון ממוקד של תקלה מסוימת.
מזהים את המשתמשים והיישומים הכבדים בעזרת כלי ניטור שתומכים ב-NetFlow, sFlow או SNMP, ומציגים דוח של צרכני התעבורה הגדולים. כשצריך לדעת איזה יישום או אתר בדיוק יוצר את העומס, משלימים בלכידת חבילות על המקטע הרלוונטי. אחרי שמזהים תעבורה לא עסקית, כמו צפייה בווידאו או רדיו, אפשר להגביל אותה בחומת האש ולתעדף יישומים קריטיים כמו טלפוניה.
ניטור זרימות כמעט לא מעמיס ואינו מורגש אצל המשתמשים. לכידה ארוכה של חבילות או בדיקות חודרניות עלולות ליצור עומס, ולכן מתכננים אותן מראש, מגבילים את משך הלכידה ומשתמשים ביציאת שיקוף (SPAN) או בדגימה. יש גם מערכות שבהן הניתוח עצמו מתבצע בענן, בלי להתקין תוכנה במחשבי העסק או במרכזיה, כך שהן לא מכבידות על התעבורה הקיימת.
מנטרים את תעבורת הקול לאורך המסלול ובודקים איבוד מנות, השהיה ורעד (Jitter) בין הטלפון, הנתב, קו האינטרנט ושרת המרכזיה. מערכות ניטור ייעודיות מודדות את איכות השיחות באופן קבוע ומתריעות כשהיא יורדת. במקרים רבים המקור הוא קו אינטרנט עמוס או ציוד ישן ברשת הפנימית, ולא המרכזיה עצמה, ולכן בודקים קודם את הרשת המקומית ואת הקו.
כדאי לרכוש ציוד שתומך בניטור ושליטה מרחוק לפי תקנים מוכרים, למשל TR-069 לניהול נתבים מרחוק, ושמגיע עם יכולות הגדרה אוטומטית ותיקון עצמי (Self-Healing). ציוד כזה מאפשר לזהות ולתקן תקלות לפני שהמשתמשים מרגישים בהן, וגם לטפל בהן בלי ביקור טכנאי. בנוסף חשוב לבקש מהספק הסכם SLA, במיוחד כשספק אחד מספק את כל שירותי התקשורת.
