הקו לא עמוס,
והכול עדיין איטי.
שתי שאלות שונות מתחבאות מאחורי ״הרשת איטית״: מי צורך, ולמה זה לוקח זמן. הן דורשות שתי שכבות מידע שונות — וזו הסיבה שהמנוע אוסף את שתיהן.
Net-Monitor אוסף NetFlow, sFlow ו-IPFIX לצד מוני SNMP ולצד הקלטת PACKETS, ומציג את שלושתם על אותו ציר זמן. רשומות ה-flow עונות עלמי צורך את רוחב הפס — איזו אפליקציה, איזה משתמש, מול איזה שרת. ה-PACKETS עונות על למה זה איטי כשאיש אינו צורך יותר מדי: שידורים חוזרים, זמן הלוך-חזור (RTT), ותגובות שרת שהתארכו.
״מי״ ו״למה״ הן לא אותה שאלה.
מי צורך את רוחב הפס?
רשומות flow סופרות שיחות: מקור, יעד, פרוטוקול ונפח. הן פותרות מצוין את המקרה שבו קו באמת עמוס ורוצים לדעת ממה. זו שאלה נפוצה, והיא גם השאלה הקלה.
למה זה לוקח זמן?
כשאף אחד לא צורך יותר מדי, ספירת בתים לא תעזור — צריך למדוד זמן. שידור חוזר, תור שהתמלא ל-50 מילישניות, handshake שנכשל. אלה דברים שרואים רק ב-PACKET.
שתי השכבות, מסך אחד.
אותם נתונים מתואמים מאחורי כל תצוגה, כך שלעולם אינכם משווים בין שני כלים שלא מסכימים ביניהם.
התקנים שהתגלו
| התקן | סוג | פורטים | עומס |
|---|---|---|---|
| core-1 | נתב | 48/48 | 62% |
| core-2 | נתב | 48/48 | 55% |
| dist-3 | סוויץ׳ | 96/96 | 71% |
| acc-3 | סוויץ׳ | 46/48 | 94% |
| acc-4 | סוויץ׳ | 48/48 | 38% |
מפה פיזית
עומס WAN-1
38%
עומס WAN-2
41%
זמן תגובה
480ms
שיחות על הקו הזה
הקו בשימוש של 38% בלבד
- שכפול גיבויים10.4.18.2234%
- שיתוף קבצים (SMB)10.4.2.5124%
- ועידות וידאו10.4.9.14017%
- סנכרון מסדי נתונים10.4.31.812%
- כל השאר—13%
- סופת שידורים חוזרים ב-Gi0/3acc-3
הקלטת PACKETS · +412% מול קו הבסיס · חשד לאי-התאמת דופלקס
9614:36 - שיחה פנימית חריגה10.4.18.22
NetFlow · צמד עמיתים חדש, 3.1 GB ב-20 דקות, מחוץ לשעות
7114:22 - סטיית השהיה ב-WAN-2core-2
SNMP והקלטת PACKETS · ה-RTT מטפס כבר שש שעות
6411:08 - קו הבסיס נלמד מחדשdist-3
המודל עודכן אחרי שינוי טופולוגיה מתמשך
1209:41
שינויי תצורה אחרונים
142 התקנים מגובים · 2 בסטייה
- סטייה מהתקן
interface Gi0/3 speed 100 ← auto
acc-3 · n.levi · 14:31
ACL 120 — נוספו 2 שורות
core-1 · automation · 11:55
נוצר VLAN 340
dist-2 · m.cohen · אתמול
- סטייה מהתקן
עודכן SNMP community
acc-5 · n.levi · אתמול
תצוגות להמחשה, המייצגות פלט של Net-Monitor.
מה זה עושה בפועל.
איסוף NetFlow, sFlow ו-IPFIX
רשומות ה-flow שהציוד כבר מייצר נאספות במקום אחד ומתורגמות לשמות: איזו אפליקציה, איזה משתמש, מול איזה שרת.
הצרכנים הגדולים (Top Talkers)
דירוג מארחים, שיחות ואפליקציות לפי נפח ולפי קצב — לכל ממשק ולכל חלון זמן, כולל השוואה לאותה שעה אתמול.
עומס ממשקים והיסטוריה
מוני SNMP לכל פורט: עומס, שגיאות, discards ושינויי סטטוס, עם היסטוריה שאפשר לחזור אליה ולא רק גרף של השעה האחרונה.
למה זה איטי, לא רק כמה עבר
כאן נכנסת ה-PACKET: זמן הלוך-חזור (RTT), אחוז שידורים חוזרים, זמן תגובת שרת ו-handshakes שנכשלו. אלה המספרים שמסבירים איטיות כשהקו לא עמוס.
אימות מדיניות QoS
בדיקה שהתעבורה באמת מסומנת ומטופלת לפי המדיניות שהוגדרה, ולא רק שהמדיניות קיימת בקונפיגורציה.
תעבורה פנימית (east-west)
לא רק מה יוצא החוצה. השיחות בין שרתים בתוך מרכז הנתונים הן לרוב הנפח הגדול יותר, והן כמעט תמיד הפחות מנוטרות.
תשובות קצרות.
איך מגלים מי צורך את רוחב הפס?
דרך רשומות flow שהנתבים והסוויצ׳ים כבר מייצרים. הן מתארות כל שיחה — מקור, יעד, פרוטוקול, פורט ונפח — וכשמצליבים אותן עם מידע ההתקנים מקבלים שם של משתמש ושל אפליקציה במקום כתובת IP. זה עונה על "מי" ועל "כמה" בדיוק מלא.
ואם אף אחד לא צורך יותר מדי והרשת עדיין איטית?
אז השאלה אינה "מי" אלא "למה", ורשומות flow לא יענו עליה — הן סופרות בתים ולא מודדות זמן. התשובה נמצאת ב-PACKETS: שידור חוזר, תור שהתמלא לרגע, תגובת שרת שהתארכה. זו הסיבה שאותו מנוע אוסף את שתי השכבות.
מה ההבדל בין SNMP, NetFlow והקלטת PACKETS?
SNMP סופר — כמה בתים עברו בממשק. NetFlow מפרט — מי דיבר עם מי וכמה. הקלטת PACKETS מראה — מה בדיוק היה על הקו ומתי. שלושתן מתארות את אותה תעבורה ברזולוציה עולה, וכל אחת עונה על שאלה אחרת. הבעיות הקשות נמצאות כמעט תמיד ברמה השלישית.
צריך להפעיל NetFlow על כל הציוד?
לא בהכרח. מפעילים אותו איפה שהוא מוסיף מידע — בדרך כלל על קווי ה-WAN ועל נקודות הצומת המרכזיות. יתר הכיסוי מגיע מ-SNMP, שעובד בכל מקרה, ומההקלטה בנקודות שבהן ממקמים סניפר.
תראו לנו את הקו שלא מסתדר לכם.
נכוון את Net-Monitor לסביבה שלכם ונעבור יחד על מה שהוא רואה — גם על מה שעובר וגם על מה שלוקח זמן.