מאמרי אורח

שלום לכולם,

בעקבות רעיון של גדי בלכמן נפתח מדור חדש בבלוג - מאמרי אורח.

מדובר במאמרים שכל אחד מכם יכול לכתוב / כתב ולשתף עם הקהילה.

המאמר הראשון הינו פרי עטו של גדי ועוסק בשיטות מיתוג בנתבי סיסקו.

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

רצוי לשתף בפורמט של Google Docs כיוון שמאפשר שינויים בעתיד ללא עדכון הקישור וזמין לקריאה גם בפלטפורמות ניידות.

ושוב - תודה לגדי על היוזמה! מקווים לראות מאמרים נוספים בקרוב...

Multicast ברשתות L2

להלן סיכום קצר של אופן עבודת Multicast ב L2. 

1. כתובות בתחום 224.0.0.0 עד 224.0.0.255 אינן דורשות רישום ולכן מופצות לכל הפורטים ב VLAN
2. הגדרה של igmp סטטי בפורט כך שיקבל כתובת mac ספציפית. יש לזכור שכתובת ip multicast אינה ממופה 1:1 לכתובת mac אלא כל 32 כתובות ip multicast ממופות לאותה כתובת mac. לא מדובר ב 32 כתובות רצופות אלא בקפיצות של חצי class A. תחת הגדרות הפורט:
3. מיפוי כתובת IP Multicast לכתובת MAC Multicast אינו 1:1 ולכן כל קפיצה של חצי class A (דהיינו 128 כתובות ב octet השני או כתובת 1 ב octet הראשון) מתמפה לאותה כתובת MAC Multicast. כל כתובת MAC Multicast מייצגת 32 כתובות IP Multicast. ראה דוגמא.
4. mrouter port זה פורט שמחובר לנתב שמוציא הודעות PIM, MOSPF וכו
5. אם המתג לא מזהה mrouter port, ה igmp snooping אינו פעיל אפילו אם מוגדר [ראה הערות מטה]. הנ"ל מאפשר ל reciever להמשיך לקבל multicast למרות שלא מוציא הודעות IGMP Join מחזוריות כי אין נתב שמזכיר לו לעשות זאת
6. אם יש mrouter port ומופעל igmp snooping, רק פורטים מהם התקבלה בקשה יקבלו את ה multicast
7. אם קיים אלמנט ברשת שלא מסוגל להוציא בקשות IGMP Join מסיבה כלשהיא, יש להגדיר הצטרפות ידנית לפורט זה. ניתן לעשות זאת בשני אופנים:
1. הגדרת הפורט כ mrouter port. במקרה כזה יקבל את כל קבוצות ה multicast הקיימות ב VLAN של הפורט. ב global config מגדירים: ip igmp snooping vlan vlanid mrouter interface if
2. הגדרה של igmp סטטי בפורט כך שיקבל כתובת mac ספציפית. יש לזכור שכתובת ip multicast אינה ממופה 1:1 לכתובת mac אלא כל 32 כתובות ip multicast ממופות לאותה כתובת mac. לא מדובר ב 32 כתובות רצופות אלא בקפיצות של חצי class A. תחת הגדרות הפורט: ip igmp snooping vlan vlanid static macaddr interface if

אמולציה של ASA 8.4 ב gns

הי,

לאחרונה גדי ביצע תיכנון לתצורה מעניינת של asa שרידה בתצורת active-active ללא cluster תוך שימוש ב NAT לטובת שמירה על מעבר קבוע באותה ה ASA בכל session. כחלק מתהליך הבדיקות, נתקל באתגר להריץ את גרסא 8.4 ב gns והסתייע בקישור הבא למימוש הבדיקה.http://www.xerunetworks.com/2012/02/cisco-asa-84-on-gns3/ לשימושכם.

OSPF External Type 1 Vs External Type 2

כאשר מכניסים ניתוב חיצוני ל OSPF, מוגדר cost (ברירת מחדל 20) לניתוב עצמו בנתב שמבצע את פעולת ה redistribute. בהפצת הניתוב, מצוין מי נתב ה ASBR שהכניס את הניתוב לרשת. לגבי שאר הנתבים ברשת, ה Cost נקבע על פי סוג הניתוב.

ישנם שני סוגי ניתובים חיצוניים: 

• Type 1 - בנוסף לערך Cost של הניתוב עצמו, יש להוסיף את המרחק בתוך רשת ה OSPF אל נתב ה ASBR שביצע את פעולת ה Redistribute.
• Type 2 - לא מוסיפים לערך Cost של הניתוב עצמו שום תוספת. כל הנתבים ברשת רואים את הניתוב באותו ה Cost. כיוון שהנתבים ברשת יודעים מי נתב ה ASBR, הם מנתבים את המידע אליו.

מתי נשתמש בכל סוג?

כאשר רוצים להגדיר נקודת יציאה אבסולוטית מרשת ה OSPF לעולם החיצון, ללא קשר ב Cost-ים בתוך רשת ה OSPF, נעדיף להשתמש ב Type 2. בצורה כזו, נניח ויש שני נתבי ASBR, האחד יכניס את הניתוב עם Cost גבוה והשני ב Cost נמוך ונוכל להגדיר לכל הנתבים ברשת שלא משנה מהם ה Cost-ים הפנימיים ברשת ה OSPF, תמיד יש להעדיף את המסלול לנתב השני.

כאשר אין העדפה מאיזו נקודת יציאה לצאת אל העולם החיצון, יש להעדיף Type 1 כיוון שמתחשב גם ב Cost-ים הפנימיים ובהגדרה מייצר ניתוב יותר יעיל ונכון. בנוסף, מאפשר להשתמש בשתי היציאות בו זמנית. במקרה כזה, חשוב לשים לב לסוגיות של Asymetric Routing מול העולם החיצון.

להלן קישור ל

מסמך OSPF.

Multicast PIM Assert

להלן הסבר קצר בנוגע למנגנון ה Assert ב Multicast

כאשר שני נתבים פותחים stream multicast לסגמנט משותף, המידע מתקבל פעמיים. על מנת להימנע ממצב זה, פותח מנגנון שתפקידו להחליט מי מהנתבים יפתח את המידע לסגמנט וזאת על בסיס טבלת ניתוב ה Unicast. כאשר נתב מזהה שהוא מקבל (S,G) מסוים דרך ממשק שמבחינתו הוא outgoing list, הוא מייצר הודעת Assert שנשלחת לכתובת 224.0.0.13 שמכילה את הנתונים הבאים:

• קבוצת ה (S,G) שבגינה מבוצע ה Assert

• ערך ה Admin Distance של פרוטוקול הניתוב Unicast אותו הוא מריץ
• ערך ה Cost של הנתב ל S בפרוטוקול הניתוב Unicast אותו הוא מריץ.

הנתב שמרחקו קטן יותר ל S, הוא שיבחר לפתוח את המידע לסגמנט. את ההחלטה חייבים לכבד גם נתבים נוספים בסגמנט, ובפרט כאלו שמהווים downstream עבור ה (S,G). בדרך כלל נראה מצבים כאלו כאשר מול זוג נתבים קיים נתב או FW וכו' שלא משתתף איתם ב Dynamic Routing. המשמעות היא שאותו נתב downstream, נדרש לשלוח בקשת PIM Join לנתב שניצח ב Assert ולהוציא PIM Prune לנתב שהפסיד ב Assert.

תהליך זה רלוונטי בעיקר ב PIM DM כי שם מתרחש בהגדרה בכל מקום בו יש שרידות של הרשת, אך גם ב PIM SM במקומות בהם יש נתבים שלא משתתפים ב Dynamic Routing.

ניתן להעמיק בנושא Multicast במסמך המופיע ברשימת המאמרים.