מאמרים אחרונים

שתף בפייסבוק שיתוף בפייסבוק
RSS - מאמריםמאמרים
RSS - פורומיםפורומים
דווח למנהל דיווח למנהל
קישור לעמוד זה קישור לעמוד זה
עוד בקבוצת HT



פרוטוקול RSTP מופעל גם בראוטר וגם ב Switch במקביל.


   פורומים > HTPC ומחשוב > אינטרנט - ספקים, תשתית, סיבים fiber
מחבר הודעה
rain
חבר פעיל
חבר פעיל

הצטרף בתאריך:
  Jan 06, 2008
מספר הודעות: 83

 #1  נשלח: א' 18/08/2019 16:01
פרוטוקול RSTP מופעל גם בראוטר וגם ב Switch במקביל.

הי חברים,

ברשותי Switch מנוהל של MikroTik ( כל שאר ה Switch-ים לא מנוהלים)
אני מעוניין לבטלאת פרוטוקול ה RSTP מה Switch המנוהל, כי ראיתי שגם אצלי בראוטר ה RSTP פעיל במקביל.
האם קיים חשש מקונפליקט ברגע שה RSTP מופעל גם בראוטר וגם ב Switch, או שמה אלי לבטל את ה RSTP להיות פעיל על ה Switch או רק על הראוטר?
לעונים תודה!
| פרופיל | שלח הודעה | חפש
sys_admin
חבר ותיק
חבר ותיק

הצטרף בתאריך:
  Jan 06, 2014

מיקום: גליל מערבי
הבעות תודה: 389
מספר הודעות: 2071

 #2  נשלח: א' 18/08/2019 19:54

דבר ראשון אתה צריך להבין למה אתה משתמש ב RSTP ואחרי זה כבר אתה יכול להחליט, אם לבטל אותו. בכל מקרה, ברגע שפרוטוקול זה פעיל, הוא צריך להיות מוגדר ומוגדר נכון על כל רכיבי רשת שמבצעים מיתוג בה. דרך אגב, בציוד של MikroTik , הוא פשוט לא שמיש ולא מתפקד בצורה הגיונית. ואם בטלת את ה RSTP מומלץ שבכל הציוד שמצע מיתוג יוגדר פרוטוקול אחר שמבצע את הפעולות אלה, עם עדיפות ל MSTP , שגם הוא צריך להיות מוגדר נכון, אחרת בכל חיבור בעיתי של כבילה הרשת פשוט תקרוס ולא יהיה ניתן למצוא את הסיבה לזה, כי BPDU בה יטיילו לכל מקום ויצרו כאוס.
כך יכול להיראות פלט של מתג אחרי שמוגדר עליו פרוטוקול זה בצורה תקינה בפורט UPLINK מסויים:



| פרופיל | שלח הודעה | חפש
rain
חבר פעיל
חבר פעיל

הצטרף בתאריך:
  Jan 06, 2008
מספר הודעות: 83

 #3  נשלח: א' 18/08/2019 21:48

sys_admin
·
וואי איזו תשובה מקצועית!!!
האמת שהכל התחיל לפני מספר שבועות ששידרתי את הראוטר ל Mikroatik ואני לא מצטער לרגע. (ממליץ בחום! )
העניין הוא שהוא מחובר ל Switch מנוהל של MikroTik ועוד שניים של NetGear (לא מנוהלים)
אל כל אחד מהם מחובר Access Point של Ubiquti.

התחלתי להציץ מידי פעם על הלוגים של הראוטר ואז ראיתי שמידי פעם אני מקבל מה DHCP ” Lease without success
וזה התחיל לבאס אותי ומחפירה ברשת הייתה המלצה לבטל את ה RSTP אז כשלב ראשוני ראיתי שהוא מופיע ב Switch המנוהל, אז פשוט ביטלתי אותו והשארתי אותו רק הראוטר. ( היה ברמת Default ) והעסק נראה הרבה יותר טוב מזה מספר ימים.
השאלה שאני מנסה למצוא לה תשובה כבר מספר שבועות, האם זה באמת הכיוון והאם אני באמת צריך לעבוד עם ה RSTP
או שאולי אני צריך לבטל את האופציה הזאת גם מכיוון הראוטר?
עוד גם אני מנסה להבין למה הוא ממש תורם לי?
אשמח שוב לקבל את תשובתך המקצועית.
המון תודה!!!
| פרופיל | שלח הודעה | חפש
sys_admin
חבר ותיק
חבר ותיק

הצטרף בתאריך:
  Jan 06, 2014

מיקום: גליל מערבי
הבעות תודה: 389
מספר הודעות: 2071

 #4  נשלח: ב' 19/08/2019 0:16

rain
·
מנגנון RSTP נועד בין היתר בכדי ליצור מצב ברשת שלא יהיו LOOPS , שמשביתים אותה, למשל אם מתגים מחוברים ביניהם בכמה מסלולים, מנגנון זה ינתק מסלול מיותר וישאיר רק את הנדרש, במקרה שהמסלול זה יתנתק, הוא יחזיר את אחד המסלולים האפשריים. בשביל שמנגנון זה יעבוד, נדרש שכל הרכיבי רשת שמבצעים מיתוג בה יתמכו בו והוא יוגדר בהם בצורה תקינה. זו אחת הסיבות שבגללן ברשת אסור להשתמש במתגים לא מנוהלים. בנוסף לזה, בציוד של MIKROTIK מנגנון זה ( כמו רבים אחרים ) לא מתפקד בצורה תקינה. מכאן אפשר להסיק שאפשר לכבות אותו, אבל להבין שבלי מנגנון הגנה זה שפועל בצורה תקינה מכל LOOP שיוצר רשת כזו תושבת. צירפתי תרשים שממחיש את הפעולה של המנגנון בצורה פשוטה.



(1) הבעות תודה: mescaline
| פרופיל | שלח הודעה | חפש
mescaline (עדן שחף)
חבר פעיל במיוחד
חבר פעיל במיוחד

הצטרף בתאריך:
  Sep 27, 2018
הבעות תודה: 78
מספר הודעות: 916

 #5  נשלח: ב' 19/08/2019 0:32

ומתוך סקרנות, מה קורה במצב שיש לופ בין שני פורטים באותו סויטש?
| פרופיל | שלח הודעה | חפש
sys_admin
חבר ותיק
חבר ותיק

הצטרף בתאריך:
  Jan 06, 2014

מיקום: גליל מערבי
הבעות תודה: 389
מספר הודעות: 2071

 #6  נשלח: ב' 19/08/2019 0:57

מה שקורה במקרה כזה, זה שהנתונים באותה הרשת מפסיקים לעבור בין ההתקנים וגם ה LOOP זה לא נעצר במתג זה, אלה שהוא מתפשט לכל שאר המתגים ומשבית את כל הרשת כולה. בכל מתג מנוהל דבר ראשון זה מגדירים את ההגנה זו ובמקרה שנוצר LOOP בין שני פורטים מתג כזה מכבה אחד מהם ושולח התראות עם כל הפרטים של הבעיה, למקום שהוגדר, למשל לשרת SYSLOG או לדואר אלקטרוני, לצורך זה שאפשר יהיה לדעת היכן הייתה בעיה ולפתור אותה. תוך כדי כך, הרשת כלל לא סובלת ממצב זה. כך נראה מסך דיאגנוסטיקה רלוונטי:


(1) הבעות תודה: mescaline
| פרופיל | שלח הודעה | חפש
nir11
חבר ותיק
חבר ותיק

הצטרף בתאריך:
  Apr 21, 2007
הבעות תודה: 114
מספר הודעות: 2342

 #7  נשלח: ב' 19/08/2019 10:22

mescaline כתב:
ומתוך סקרנות, מה קורה במצב שיש לופ בין שני פורטים באותו סויטש?
·

ההסבר המלא לשאלה הזו דורש טיפה הבנה באיך עובדים מתגים.
מתג עושה דבר מאוד פשוט - הוא ממתג. כדי לעשות את זה הוא מחזיק טבלה שממפה בין מספר פורט פיזי (נניח מ 1 עד 24, תלוי כמה פורטים יש במתג), לבין כתובת MAC.
כשמחשב פונה למחשב אחר בתוך הרשת, הוא פונה לפי כתובת IP, אבל הוא צריך לדעת איזה כתובת MAC שייכת לאותו IP, ולכן הוא שולח הודעת broadcast (יש כתובת MAC מוסכמת ושמורה שמציינת ברודקאסט). הודעה זו נשלחת לכל הצרכנים ברשת (או ב VLAN, אם מוגדרים כאלה). ופה מתחילה הבעיה. המתג מעביר את ההודעה הזו, מסוג broadcast, לכל הפורטים שלו. אם על אחד הפורטים משורשר עוד מתג - הוא יעשה אותו דבר בדיוק. אם יש מעגל ברשת, ההודעה פשוט תחזור אל המתג דרך המעגל, והוא יעביר אותה הלאה. ככה המעגל בעצם מזין את עצמו. זה קצת דומה לכדור שלג, ואכן התופעה נקראת avalanche. בסוף זה נגמר בזה שהרשת מוצפת בפקטות מידע והיא קורסת. מה זה אומר קורסת?
המתג הוא בעצמו מחשב. יש לו CPU (שאולי נקרא אחרת, אבל זה צ'יפ שאחראי על עיבוד הנתונים). הצ'יפ הזה יכול לטפל בכמות מוגבלת של פקטות, ובלופ לעיתים עוברים את הכמות הזאת - ואז המתג נתקע או עושה לעצמו reboot.
כל זה קורה כאמור רק כשיש לופ, ויש כל מני מנגנונים למנוע את זה, כמו שתואר למעלה.
לי יצא לראות כמה פעמים לופ במעבדה, מעבר לקריסת המתג, גם מחשבים יכולים לקרוס, מאותן סיבות - עומס יתר על כרטיס הרשת...

הערה אחרונה, הודעות broadcast הן דבר נפוץ מאוד ברשת, אם תשים סניפר על המחשב שלך תוכל לראות אותן, גם ברשת ביתית קטנה.
| פרופיל | שלח הודעה | חפש
rain
חבר פעיל
חבר פעיל

הצטרף בתאריך:
  Jan 06, 2008
מספר הודעות: 83

 #8  נשלח: ב' 19/08/2019 11:32

sys_admin
·

כל כך כיף לקרוא את התשובות המקצועיות שלך! שאפו שיש אנשים כאלה באתר!!!

בפועל כמו שציינתי בפניך כיביתי את מנגנון ה RSTP רק ב Switch המרכזי המנוהל ( הוא ניזון מהראוטר ומפצל את הרשת לשאר ה Switch-ים שנמצאים בחדרים, רק שהם לא מנוהלים)

עכשיו עולות לי שוב שאלות:

האם נכון הדבר לבטל את ה RSTP רק ב Switch או שמה עלי לבטל את ה RSTP גם מהראוטר המרכזי.
או שאולי כדי לי בככל לוותר על ה Switch המנוהל ולהחילפו ב Switch איכותי רגיל?

כל הסיפור התחיל מהודאות ה Warning שקיבלתי מה DHCP "offering lease without success"

לשימחתי יש שיפור, אבל אולי יכול להיות שאני לא בכיוון?

לתשובתך אודה !
| פרופיל | שלח הודעה | חפש
sys_admin
חבר ותיק
חבר ותיק

הצטרף בתאריך:
  Jan 06, 2014

מיקום: גליל מערבי
הבעות תודה: 389
מספר הודעות: 2071

 #9  נשלח: ב' 19/08/2019 12:46

rain
·
בגדול, אם במתג פרוטוקול זה מכובה, אז גם בנתב אין שום צורך להשאיר אותו פעיל, כי מנגנון זה צריך לפעול בכל הרכיבי רשת שמבצעים בה מיתוג ואם ברכיב המרכזי, שזה המתג, הפרוטוקול זה מכובה או לא מוגדר כמו שנדרש, גם בשאר הרכיבים כבר אין שום היגיון להשאיר אותו פועל.
בקשר לההחלפה של המתג במתג יותר היגיוני, אז הכל תלוי במקרה פרטי ובצרכים. למשל אני בטוח שלא הייתי לרגע משאיר מתג כזה בעיתי של MIKROTIK וגם הייתי דואג לרכז את כל הנקודות תקשורת לריכוז אחד, שבו יהיה מותקן מתג אחד שישרת את כל הבית. ברשת ביתית יציבה מבחינת המיתוג אחת היסודות המרכזיים, זה שכל הנקודות יתנקזו בריכוז תקשורת אחד ובו יהיה מותקן מתג אחד בלבד. מתגים ביתיים קיימים עם מספר פורטים שמספיקים לכל בית. בדרך כלל המתג לבית פרטי יחסית גדול יהיה עם 52 פורטים. מתג כזה יכול לשרת את כל ההקנים, מהמחשבים, מדפסות, מצלמות אבטחה בבית ובחוץ, אינטרקום, טלפונים IP , ציוד IOT וכו'.
בקשר לבעיה המקורית של "offering lease without success", היא באמת יכולה להיות קשורה למיתוג ברשת הביתית, אבל יכולה להיות גם קשורה לנתב עצמו או לאחד הלקוחות, אם היא מתרחשת רק בהתקן בודד.
| פרופיל | שלח הודעה | חפש
כל הזמנים הם שעון קיץ - ישראל (GMT+3) הצג הודעות קודמות:    
פורומים > אינטרנט - ספקים, תשתית, סיבים fiber


  
    שם משתמש:
נתוני כניסה לכל אתרי HT:

  סיסמא:
 

  


 | 

קפוץ אל: 
לא ניתן לשלוח הודעות בפורום זה
לא ניתן להגיב להודעות בפורום זה
לא ניתן לערוך את הודעותיך בפורום זה
לא ניתן למחוק את הודעותיך בפורום זה
לא ניתן להצביע לסקרים בפורום זה
לא ניתן לצרף קבצים בפורום זה
לא ניתן להוריד קבצים בפורום זה

תקנון / תנאי השימוש באתר צור קשר / contact us כל הזכויות שמורות לקבוצת ht