NAT

הי,

לאחרונה גדי עסק בנושא NAT וסיכם את הנושא למסמך.

המסמך מופיע במאמרי האורח בבלוג.

לשימושכם.

BFD

הי,

BFD הינו מנגנון המאפשר זיהוי מהיר של כשלים ב Data Plan ודיווח מיידי ל Control Plan לטובת עדכון טבלאות ניתוב וכו'.

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

המסמך נכתב על ידי גדי בלכמן ומופיע במאמרי האורח בבלוג.

להלן קישור ישיר למסמך.

לשימושכם.

שיקולים בבחירת מנגנון RP

מספר שיקולים בבחירת מנגנון ה RP בתכנון רשת Multicast:

• פשטות - לדעתי BSR פשוט יותר להבנה, מימוש וטיפול בתקלה.
• זמן שיקום - BSR משתקם (בחירת RP חדש) בברירת מחדל תוך מספר דקות מרגע נפילת ה RP. זכור לי ערך של 150 שניות.
  בנוסף, אם BSR נפל ואין כרגע RP בכלל, ניתן לעבור ל dense mode fallback לעומת anycast שאם שני ה RP-ים נפלו אז אין fallback.
• תקינה - auto rp פרוטוקול קנייני של סיסקו. BSR ו MSDP הינם תקנים.
• גמישות לשינויים - ב-BSR אני לא צריך להגדיר את ה-RP בכל שאר הנתבים, הם לומדים בצורה דינאמית כאשר ב-anycast זה נדרש. במקרה ואני צריך לשנות את כתובת ה-RP, זה יוצר סירבול סתמי וסוג של שלב מעבר בו יש שני RP-ים שונים ברשת.
• גמישות בניתוב המידע - ב-BSR נבחר להיות נתב אחד שמשמש כ-RP עבור קבוצה מסוימת או חלק מהקבוצות וברשת גדולה בה לא בוצע מעבר ל-source tree כל העומס נופל על אותו ה-RP. ב-anycast אפשר לחלק את העומס על פי קירבה של ה-receiver ל-RP וכך לייצר סוג של LB .

אשמח לשמוע שיקולים נוספים.

תודה לגדי שיזם פוסט זה ותרם מנסיונו.

דרך אגב, המידע הוכנס למסמך Multicast, מוזמנים לעיין שם בסוגיה זו ואחרות.

איך עובד RSPAN?

לאחרונה גדי חקר קצת את נושא ה RSPAN והגיע לתובנות מענייניות.
התובנות שולבו במסמך הקיים בנושא Session Monitor בחלק של RSPAN.

לשימושכם.

תודה לגדי על השיתוף.