איתור תקלות ברשתות תקשורת ארגוניות
לכל אחד מאיתנו, מנהל מערכות מידע או מנהל מחשוב, ידועה התופעה של משתמשים המתלוננים על "הרשת שאינה עובדת". תלונות על "ניתוקים", "עבודה איטית", "אפליקציה שלא זזה" ורבות אחרות, מדירות לא מעט שינה מעיננו. מצד שני, כשאנו פונים לפתרון הבעיה, יציעו לנו "בדיקת סניפר", "הקמת מערכת בקרה (במחיר אסטרונומי)", ועוד. סדרת מאמרים זו, שבא אנו פותחים, באה לתת כלים בסיסיים לכל מנהל רשת ומחשוב לאיתו תקלות בארגונו. בהמשך הסדרה יובאו גם מאמרים בנושאי תכנון רשתות.
מה השיטות הקיימות לאיתור תקלות? איך לנטר רשת בצורה יעילה וזולה? איך לקבל אינדיקציה ראשונית היכן הבעיה ברשת, והאם צריך לקרוא למומחה? מטרת מאמר זה הינה לתת סקירה ראשונית של האמצעים הקיימים, שיטות ודרכי בדיקה. במאמרים בהמשך הסדרה, יינתנו סקירות מעמיקות יותר על כל כלי בנפרד, כולל כלי שליטה ובקרה ו- SNMP, נתחי פרוטוקולים (Wireshark), ניטור באמצעות ציודי התקשורת עצמם ועוד.
קודם כל, בואו נבהיר דבר אחד חשוב, שאולי יישמע לרובינו מוזר: הבעיה בד"כ אינה ברשת התקשורת. מניסיוננו אנו יודעים, כי אם ניקח מאה תקלות של ניתוקים, עבודה איטית, או כל תופעת "הרשת לא עובדת" אחרת, בסביבות 50-60% מהבעיות יהיו בעיות אפליקטיביות, 30-40% בעיות מחשוב, ורק בסביבות 10-20% מהבעיות יהיו בעיות תקשורת. למרות זאת, הרבה מהבעיות הינן בעיות משולבות, בהן אפליקציה לא עובדת בצורה יעילה עם המשאבים של הרשת, חוסר זיכרון או מעבד איטי בשרת גורמים לעומס על הרשת וכד'.
והדוגמאות לכך הם רבות. לדוגמא, באחת ממערכות הבחירות המקדימות האחרונות למפלגות, הייתה עבודה איטית מאוד מול שרת הבחירות, באופן שעיכב בצורה משמעותית את ההצבעה. בבדיקת רשת שנערכה באמצעות נתח פרוטוקולים, התברר כי מערכת ההצבעה (המחשב בעמדת הקלפי) שולח ומקבל כ- 60 מנות (Packets) מולל השרת, עבור כל בוחר שמגיע לקלפי. לכשעצמה, זוהי כמות מידע זניחה, שלא אמורה להשפיע על הרשת, ואכן לפי חישובי רוחב פס שנעשו, לא הייתה אמורה להשפיע. הבעיה הייתה, שבאתרים שחוברו במודם סלולארי בטכנולוגיית cdma1x, ה- Delay (RTT) על הקו היה כ- 300mS, מה שגרם ל- 60 מנות לעבור ברשת ב- 60*300mS, כלומר 18 שניות באופן תיאורטי, שמעשית לקח יותר מפי שניים מזה, ומצביעים נתקעו בתורים עקב כך. התקלה תוקנה תוך כדי עבודה, והחל משעות אחה"צ ביום הבחירות, מהירות העבודה שופרה משמעותית. תקלה זו למשל, הינה דוגמא למערכת בסיס נתונים שתוכננה לעבוד ברשתות קוויות, בהן נבדקה ועבדה בצורה תקינה, אבל ברשת סלולארית, מדור 2.5, העבודה השתבשה לחלוטין.
לפני שאנו באים לבדוק רשת תקשורת, מספר מילים על מתודולוגיית הבדיקה. המתודולוגיה שבא אנו משתמשים, פשוטה מאוד, ומתבססת על מודל בדיקות, כלים, והבנה מעמיקה של אופן פעולת רשת תקשורת,.
מודל הבדיקה:
מודל הבדיקה בו אנו משתמשים, מתבסס על:
- מודל OSI הישן והטוב
- תכנון הגישה לפתרון, תיעוד וניתוח שיטתי ובידוד הבעיה
כלי הבדיקה:
כלי הבדיקה, מחולקים ל- 6 קטגוריות שונות:
- כלי CLI סטנדרטיים – Ping, Trace, וכד'
- קריאת נתונים מתוך ציודי התקשורת – מתגים, נתבים, FWs וכד
- נתחי פרוטוקולים – Wireshark, Sniffer וכד'
- כלי SNMP – לניטור נקודתי ומתמשך – SNMPc, HPOV וכד'
- כלים ייעודיים – Netfllow לניתוח תנועה ברמת המשתמש והיישום, Solarwinds כחבילה של כלים הנדסיים וכד'
- צידי בדיקה וסימולציה, לניתוח חקלות ומצבים מורכבים – Spirent, Agilent וכד'
מודל הבדיקה לפי OSI
במודל OSI, שפורסם כבר לפני למעלה מ- 30 שנה, מתואר המבנה של הרשת בצורת שכבות, שזוהי בדיוק הדרך לאיתור תקלות ברשת
בבדיקת רשת, נבצע התהליך הבא:
- בדיקה של הרמה הפיסית – כבלי נחושת, תווך אלחוטי וכד',
- בדיקות ברמה 2 – כלומר שגיאות ברמת המתגים המקומיים, לולאות, Broadcast storms וכד.
- בדיקות ברמה 3 – בעיות ניתוב, כתובות כפולות וכד'
- בדיקות ברמה 4 – את אופן בעבודה בין יישומי קצה, תופעות איטיות ב- TCP, Retransmissions. Duplicate ACKs, Zero Windows וכד'.
- ברמות הגבוהות, 5 עד 7, נבדוק בעיות אפליקטיביות כמו תקלות התחברות ב- VoIP, בעיות ביצועים בבסיסי הנתונים וכד
תכנון הגישה לפתרון, תיעוד וניתוח שיטתי ובידוד הבעיה
באיתור תקלות, אנו נדרשים לידע בתקשורת ומערכות, כלי עבודה נכונים, ותהליך עבודה מסודר. תהליך העבודה חייב לכלול מיפוי מדייק של הרשת, כולל תרשימי תנועה (Flows), וכן תיעוד של כל אחת מהפעולות שעשינו, ושאנו עומדים לעשות.
בתמונה אנו רואים את התהליך המסודר לפתרון תקלה. דילוג על אחד שלבים, יכול להכניס אותנו ללולאה שלא נצא ממנה.
- הגדרת הבעיה – האם הבעיה קוראת תמיד או לפעמים? האם בכל היישומים או רק בחלק מהם? כאשר הבעיה קוראת ביישום מסוים, האם תמיד או רק במסכים מסוימים וכד'
- איסוף העובדות – בצורה מדויקת, לאסוף את כל הנתונים, לשרטט את הרשת, לראיין את המשתמשים, וכד'
- לשקול את אפשרויות הבדיקה – האם נפעיל מערכת SNMP לניטור ארוך טווח? האם נשתמש ב- Wireshark מול שרת מסוים? האם אנו נדרשים לסימולציה של הבעיה וכד'
- יצירת תוכנית עבודה – לכתוב בצורה מסודרת מה אנו הולכים לעשות, מה אנו מצפים לקבל מכל שלב בבדיקה, ומה מעשה עם תוצאה שנקבל
- ביצוע הבדיקה, ותיעוד מדויק של כל שלב
- ניתוח התוצאות, בדיקה האם תפרנו או איתרנו את הבעיה, והמשך לשלב הבא אם לא
- תיעוד מדויק של הבעיה ופתרונה, וזאת כמובן שלא נבצע את אותם כשלים בעתיד
כלי הבדיקה:
כלי הבדיקה הראשון שבו נשתמש, הינו כלי המחשב הבסיסיים – Ping, Tracert וכד'. כלים אלו הם הסטטוסקופ שבו ישתמש רופא טוב לקבל אינדיקציה ראשונית על הבעיה ממנה אנו סובלים.
בכלים אלו נשתמש לקבלת "תחושה" ראשונית של הבעיה ברשת.כך למשל נוכל באמצעות Tracert לאתר לולאות ניתוב, באמצעות Ping לגלות זמני תגובה לא הגיוניים, באמצעות Arp כתובות כפולות וכד'. אם למשל קווי WAN ידוע לנו שצריך להתקבל RTT של mSec בודדים (בד"כ 1 עד 5), ואנו מקבלים עשרות mSec, נדע ללכת ולבדוק האם הקו עמוס, האם הוא לא תקין, האם קיבלנו רוחב פס נמוך מזה שהובטח לנו או אולי אפילו הקצה של קווי ה- MPLS החדשים שקנינו מיושם ברשת FR איטית יותר.
כלי בדיקה נוסף, הזמין לנו תמיד, ובתנאי שציוד התקשורת בארגון מנוהל, זה גישה לציוד התקשורת. הגישה יכולה להיות ב- Telnet, גישה ב- HTTP, או תוכנה ייעודית (נורטל JDM וכד').
באמצעות גישה לציוד התקשורת, נוכל לראות נתונים רבים נוספים. כך למשל, נוכל לראות שגיאות על כל ממשקי הציוד, Interface resets שיהיו למשל אינדיקציה לניתוקים, וכן עומס על הציוד עצמו, למשל עומס על ה- CPU שיכול להאט את העבודה של המידע העובר דרכו.
כלי אחר העומד לרשותנו הינו נתח הפרוטוקולים. הכלי הנפוץ ביותר הינו Wireshark (לשעבר Ethereal), שהינו כלי קוד פתוח, נוח וידידותי לעבודה. כלים נוספים הינם Sniffer® של חברת NAI, Netscout ואחרים. הטעות הנפוצה שאני שומע בקשר לכלי זה היא שהלקוח מזמין "בדיקת Sniffer", ולא חשוב מה הבעיה. חשוב להדגיש – נתח הפרוטוקולים הינו כלי מתוך סוגים רבים ומגוונים של כלים, שבא לתת לנו פתרון נקודתי של ניתוח רשת לעומק, הוא לא מכשיר פלא שיפתור את כל בעיותינו.
באמצעות נתח הפרוטוקולים, נוכל להתחבר במקביל לרכיבים ברשת, לדוגמא במקביל לשרתים קריטיים, לנתב המחבר אותנו לסניפים, ל- FW המחבר אותנו לאינטרנט וכד'. באמצעותו, נוכל לנתח תופעול של איטיות ברשת, באפליקציה מסוימת, ואפילו בסוג עבודה מסוים באותה האפליקציה. באמצעות כלים אלו נוכל לראות האם היישום הינו יעיל (כדוגמת היישום בבחירות בתחילת מאמר זה), האם TCP עובד בצורה יעילה, ועוד.
כלי חשוב נוסף שישמש אותנו לבדיקות נקודתיות ורציפות של הרשת הינם כלי SNMP. כלים אלו, באם נגדיר אותם בצורה טובה, יתנו לו אינדיקציה על הקורה ברשת, נקודתית ולאורך זמן. כלים אלו גם יכולים להיות בשימוש עבור אתראות, מפות רשת ועוד.
באמצעות כלי SNMP, נוכל לבדוק לאורך זמן עומס על קווים ברשת, שגיאות מסוגים שונים, עומס על משאבי רשת, ניסיונות גישה לרשת, וכן נתונים רבים נוספים. כך למשל נוכל לראות האם יש קצב שגיאות על ממשק מסוים שמוביל לאיטיות, האם יש עומס על קווים מסוימים, מספר שיחות טלפון שעוברות ברשת, ועוד. חשוב להדגיש – כלי SNMP היום ברובם פשוטים, זולים וקלים לתפעול.
משפחה נוספת של כלים אלו הם הכלים המיוחדים, שנועדו לתת פתרון לצרכים מיוחדים. כך למשל יהיה כלים שיאשרו לנו לבדוק מי מחובר לאיזה מבוא במתג, כלים שיאפשרו לנו לבדוק TCP Ports, כלי סימולציה פשוטים – למשל i-perf לדימוי עומס ברשת ועוד.
משפחה חשובה של כלים כאן היא ה- Netflow, המאפשרים לנו לקבל דוחו"ת סטטיסטיים על המשתמשים ברשת, מי מחובר לאן, באיזה יישומים, מה רוחב הפס שהוא צורך ועוד. כלי זה מאפשר לנו ניתוח עומסים ברת דיוק גבוהה, לניטור "שודדי משאבים" למיניהם.
אחרון ברשימה, והמורכבים מכולם הינם כלי בדיקה ייעודיים, לדוגמא כלי סימולציה, בדיקת אפליקציות וכד'. כלים אלו ישמשו אותנו לבדיקת בעיות רשת ואפליקציה מורכבות, עם סיבוכיות גבוהה.
כלים מסוג זה הינם כלים יקרים מאוד, וישמשו למשל לבדיקת אתרי WEB בעומס גבוהה, סימולציה של קווי תקשורת תחת סוגי עומסים שונים וכד'.
סיכום:
דיברנו על כלים רבים ושונים, וחשוב להדגיש – כל הכלים כולם לא יחליפו את הצורך בידע, עבודה מסודרת ושיטתית, והגיון פשוט. כמו שמישהו פעם אמר שלרופא טוב יספיק הסטטוסקופ לאיתור רבות מהמחלות, כך לאיש תקשורת טוב יספיקו ברוב המקרים כלי הבדיקה הבסיסיים, והבנת אופן העבודה של רשת תקשורת.
רבות מהבעיות בהן נתקלנו במשך השנים נפתרו באמצעות הגיון פשוט. לדוגמא כתובות IP כפולות (Duplicate Address), ומשולשות שנובעות בד"כ מציוד שמגיע מוגדר מראש עם כתובת לא נכונה, או מציוד שמישהו שם ברשת ומחלק כתובות מבלי שידוע לנו על כך. לדוגמא קווי תקשורת עמוסים שהתבררו בבדיקת Wireshark פשוטה כתולעת (Worm) שמעמיסה את הקווים. למשל בעיות בסיסי נתונים שבבידוד נכון של מתי קוראת התקלה מסתבר שמסך מסוים בתוכנה פשוט "נתקע", או Client ששולח ל- Server ומקבל ממנו אלפי מנות שה- Delay של הקו פשוט גבוהה מדי לאופן העבודה. במקרים אחרים, אותרו קווי תקשורת שנראו כאיטיים, אולם בבדיקה פשוטה נמצע כי פשוט, השרתים אינם חזקים מספיק, ולכם קו התקשורת פשוט אינו מנוצל.
אפשרויות נוספות שלא דנו בהם במאמר זה הינן בדיקות משולבות של מספר Probs באתרים שונים, כלי סימולציה ועוד. נשתדל לדון בכך באחד מהמאמרים הבאים. נושאים נוספים שנדון בהם הינם עבודה בכלים השונים, איתור תקלות ברשתות VoIP, ועוד.
כותב המאמר הינו מנהל טכני בחברת NDI תקשורת.
052-4899699
