שלום חברים..
הפעם קצת על IPV6..
Link Local Addressing:
כתובות IPv6 Link
Local מקבלות משמעות רק בסגמנט המקומי על גבי
קישור בודד.
מה שזה אומר שתעבורה עם כתובות Link Local אינן יכולות לעבור בין
סגמנטים (Routed), וכתובות Link Local יכולות להיות חופפות כל
עוד הם קיימות על ממשקים שונים.
פורמט הכתובות של IPv6 Link Local הוא:
FE80::/10
והם בעלי משמעות נרדפת לכתובות ה-169.254.0.0/16
ב-IPv4.
פקטות עם כתובת מקור או יעד של Link Local בדרך כלל נמצאות בשימוש
על ידי נתבים לטובת פרוטוקולי ה-Control Plane, כגון פרוטוקולי ניתוב IPv6.
עבור סגמנטים של broadcast כגון: Ethernet, הקישוריות המקומית היא מוחלטת זאת בעקבות
השימוש האוטומטי בפרוטוקול ICMPND (ICMP
Neighbor Discovery)
אך יחד עם זאת מכיוון שענני Multipoint NBMA אינם תומכים ב-ICMP ND הפוך, יש צורך לוודא
קישוריות ב-Link Local על גבי כתובות IPv6 על גבי קישורים אלו באמצעות הגדרת מיפויים
סטטיים.
ללא הגדרת מיפויים אלו, פרוטוקולי הניתוב אינם יכולים ליצור קשרי
שכנות, או לבצע אנקפסולציה בהתאם.
ההגדרות לביצוע מיפויים והגדרת כתובות IP מבוצע באופן הבא:
ipv6 address fe80::5
link-local
frame-relay map ipv6
fe80::1 501 broadcast
Unique
Local Addressing:
כתובות Unique-Local ב-IPv6
או ULA, מוגדרות ב-RFC שמספרו 4193, שהוא מגיע
והחליף את התקן הקודם שהגדיר את כתובות ה-
Unique-Local ככתובות (FEC0::/10 ).
כתובות ULA ב- IPv6 מוגדרות בהקבלה לכתובות
בתקן RFC 1918 אשר מגדיר את כתובות ה-IP הפרטיות ב- IPv4, לדוגמא כתובות - 10.0.0.0/8 או 172.16.0.0/12
או
לחילופין 192.168.0.0/16.
כתובות ULA אינן ניתנות לניתוב על
גבי האינטרנט.
הפורמט של ULA הוא באופן הבא:
FC00 (7 bits) + Unique ID (41 bits) + Link ID (16 bits) +
Interface ID (64 bits)
יצירת ה-Unique ID באופן אקראי עוזרת להמנע
מהתנגשויות בכתובות.
מעבר לפורמט הכתובות, פורמט ה-ULA מפגין לא אחר מאשר התנהגות כתובות IPv6 אשר ניתן לבצע בהם ניתוב על גבי האינטרנט.
ההגדרה תחת הממשק מבוצעת באופן הבא:
ipv6 address
fc00:1:0:37::3/64
IPv6 Global
Aggregateable Addressing:
כתובות ה-Globally Aggregateable ידועות גם בשם
Global Unicast Address אשר מתחילות עם ערך
בינארי של 001 (2000::/3), ואי לכך תופס את הטווח
של 2000:: - 3FFF::
להלן
טבלת המרות מ-Hexadecimal ל-בינארי ולדצימלי:
IPv6 EUI-64:
כתובות ה-Extended Unique Identifier הוא ערך של 64 ביטים אשר
מוצמדים לממשק הפיזי.
ה-EUI הוא דומה מאוד לכתובת ה- IEEE MAC על ידי הזהות של הממשק הפיזי, אך ה-EUI תוכנן על מנת להיות בשימוש אוניברסלי ולא רק
לטובת כתובות חומרה.
כתובות IPv6 משתמשות ב-EUI-64 על מנת לבנות כתובת Host ייחודית על גבי סגמנט
משותף בצורה אוטומטית.
כאשר אנחנו משתמשים במילת ה-eui-64, ה-IOS משתמש ב-48 bit של הממשק החומרתי כבסיס לבניית הכתובת
הייחודית של ה-64 של כתובת ה-IPv6.
במיוחד דבר זה מושג על ידי המרה של הביט ה-7 שהוא MSB מתוך ה-MAC Address, שנקרא Universal/Local (U/L bit) ואז להכניס 16 ביטים
בפורמט של FFFE באמצע.
הגדרת כתובת IPv6 בפורמט של EUI-64 מבוצע באופן הבא:
ipv6 address
2001:1:0:146::/64 eui-64
IPv6 Auto
Configuration:
לפרוטוקול IPv6 ישנה פונקציה מיוחדת
שנקראת Auto-Configuration.
היא מחליפה שימושים רבים שנמצאים בשירות על ידי DHCP ברשתות IPv4 ( עדיין קיימת גרסה מיוחדת של DHCPv6 בתוך פרוטוקול DHCP).
יחד עם IPv6 Auto-Configuration, מחשב שהוא מוגדר לעבוד ב-IPv6 יכול בצורה אוטו' ללמוד
ניתובים שהוקצו בסגמנט המקומי, ובנוסף גם לקבוע את ה-DG עבור אותו סגמנט.
סוג מיוחד של כתובת IPv6 Link-Local וסוג מיוחד של פרוטוקול ICMPv6 ND (Neighbor Discovery) נמצאים בשימוש לטובת
השגת מטרה זו.
הודעת פרסום נתב (Router Advertisement) יכולה להישלח בתזמון
ספציפי או שניתן לדחוק את ההודעה בצורה מלאה (פונקציית ה-Suppress-ra מופעלת כברירת מחדל על גבי ממשקי Ethernet, התנהגות זו יכולה להשתנות על ידי פקודת
no ipv6 nd suppress-ra
כמובן שכל זאת תלוי כיצד אנחנו מגדירים את הנתב להתנהג.
** שים לב שחובה להפעיל IPv6
Unicast-Routing על
מנת לשלוח הודעות Router Advertisement.
הפקודות הבאות שולטות על הודעות ה-IPv6 RA:
הודעה זו שולטת על התזמון המחזורי של שליחת ההודעות:
ipv6 nd ra-interval
הודעה זו שולטת על התוקף של כתובת ה-IPv6 של הנתב:
ipv6 nd ra-lifetime
הודעה זו מבצעת מניפולציות על הכתובות הרלוונטיות שיכללו בתוך הודעת
ה-RA,
כברירת מחדל כל הניתובים נכללים ב-RA:
ipv6 nd prefix
אנחנו יכולים לכוונן את החלון זמן שבו הניתוב תקף ומועדף.
בנוסף אנחנו יכולים להורות ל-Hostים שלא
להשתמש בניתוב זה עבור Auto Configuration על ידי שימוש במילה
no-autoconfig
ההגדרות שיש לבצע הם:
DHCP SERVER:
ipv6 nd prefix
fc00:1:0:58::/64 14400 14400 no-autoconfig
ipv6 nd prefix
fc00:1:0:85::/64 14400 14400
ipv6 nd ra-interval
40
ipv6 nd ra-lifetime
60
no ipv6 nd
suppress-ra
DHCP CLIENT:
ipv6 address autoconfig default
IPv6 NAT-PT:
אופציית ה-IPv6 NAT PT מאפשר לדומיינים של -IPv6 ול-IPv4 לתקשר על ידי שכתוב של ה-
Packet Header והחלפת כתובות ה-IP.
בניגוד ל-NAT ב-IPv4 גם כתובת המקור וגם היעד
של כל פקטה חייבת להיות משוכתבת מחדש.
במיוחד, IPv6 NAT-PT עובד באופן הבא:
קבוצה של כתובות IPv6 מייצגות טווח כתובות IPv4.
לקבוצה הזו בדרך כלל יש אורך מסכה של 96/, על מנת לכסות את כל ה- 2^32 כתובות של IPv4, אבל אחרת זה יכול להיות
מספר שרירותי.
במידת הצורך אנחנו יכולים למפות כתובות IPv4 נבחרות לכתובות IPv6 בהתאמה, זאת באמצעות חוקי תרגום סטטיים.
כאשר מחשב IPv6 צריך לתקשר עם מחשב IPv4, הוא שולח פקטת IPv6 אל הכתובת שנמצאת בטווח
של ה- /96.
הנתב המתרגם מיירט את הפקטה שהולכת אל הניתוב של ה- 96/, ומחליפה את
ה-IPv6 Header עם IPv4 Header, משכתבת מחדש גם את כתובת
המקור וגם את כתובת היעד של ה-IPv6 עם זה של IPv4.
כאשר תגובת IPv4 חוזרת הנתב מבצע תרגום
הפוך.
על מנת להגדיר NAT-PT אנחנו צריכים לציין את
הדברים הבאים:
1. חוקים לתרגום כתובת המקור ב- IPv4 לכתובות IPv6.
2. חוקים לתרגום כתובת המקור ב- IPv6 לכתובות IPv4.
3. ניתוב ה- /96 למיפוי טווח כתובות ה-IPv4.
ההגדרות של NAT-PT מבוצעות באופן הבא:
ipv6 nat
!
ipv6 nat v6v4 source fc00:1:0:67::7 155.1.146.7
ipv6 nat v4v6 source 150.1.4.4 2000::9601:0404
!
ipv6 nat prefix 2000::/96
IPv6 MP-BGP:
התוספת של MP-BGP מוסיפה תמיכה לטובת IPv6 באמצעות שימוש ב-Address-Family, מה שאומר באופן עקרוני
הוא שניתובי IPv6 ומאפייניו יכולים לעבור על גבי קישור TCP רגיל בהתבסס על קשרי BGP.
אנחנו הגדרנו קשרי שכנות BGP באמצעות IPv6 תחת תהליך ה-BGP באמצעות הפקודה:
address-family
ipv6 unicast
לאחר מכן צריך לבצע Activate/ Enable על מנת להפעיל את השכן.
טכנית זהו אותו אופן בו אנחנו משתמשים לטובת הקמת קשרי שכנות ב-IPv4, אבל התהליך הגלובלי הרגיל מתייחס באופן
אוטומטי ל- Address-Family ipv4 unicast,
והפקודה bgp default ipv4-unicast מופעלת
כברירת מחדל, מה שאומר שכל שכני ה- IPv4 Unicast פעילים כברירת מחדל.
ההגדרות של כל האופציות הרלוונטיות ל-IPv6 לוקחות שליטה תחת ה- Address-Family , כגון הגדרות Network, או שיוך מאפיינים לשכנים
כגון: Route-Maps, Prefix-Lists, Filter-List וכו'..
חשוב לזכור שכל שאר פעולות ה- BGP ממשיכות לפעול באותו
האופן, כגון- חוקי פרסום רשתות Route-Reflection, בחירת הנתיב הטוב ביותר,
Confederation, וכו'...
בעיקר הדבר היחיד שהשתנה הוא הפורמט של הניתובים ופרסום ה-Next-Hop שמופצים בתוך עדכון BGP.
שים לב שבקשרי שכנות מסוג EBGP ערך ה-Next-Hop משוייך לכתובת ה-Link
Local בתוך טבלת הניתוב, משמע שאשר אנחנו מקימים
קשרי שכנות על גבי NBMA Multipoint, אנחנו חייבים למפות את
כתובת ה-IPv6 של ה-Link Local .
ביצוע סיכום ניתובים (Summarization) נשאר אם אותה הפקודה ועם
אותו אורך של חישוב ה-Mask.
אלו הפקודות להקמת קשרי שכנות MP-BGP:
address-family ipv6
unicast ------- IPV6 MP-BGP
neighbor
2001:1:0:1234::5 remote-as 500
neighbor
2001:1:0:1234::5 activate
network
2003:1:0:1::/64
network
2003:1:0:10::/61
aggregate-address
2003:1::/59 summary-only
סיכום הניתובים בוצע בצורה כזו שלקחנו את כל הביטים הדומים,
אם נזכור, כל 4 מספרים שווים ל-16 ביטים, אזי השוני שלנו קיים באוקטט
השלישי (חשוב לשים לב שה-MASK שלנו בכתובת השניה הוא
61/ ולא 64/)
IPv6 PIM
& MLD:
ב-IPv4 ישנו טווח ספציפי של
כתובות השמור לטובת שימוש Multicast (224.0.0.0
-239.255.255.255).
ב-IPv6 כתובות Multicast הם כל הכתובות שנמצאות בטווח של רשת FF00::/8.
במילים אחרות, כתובת IPv6 היא כתובת Multicast, אך ורק אם ה-Byte הראשון הוא FF (שווה ל-255 בדצימלי).
כתובת IPv6 היא באורך של 128 bit וביטים אלו מחולקים לקבוצות אשר מיועדות
לציין דברים ספציפיים.
אחרי שמונת הביטים (שמציין את כתובת ה-Multicast), ישנם 4 ביטים כל אחד
אשר מציינים דגל וקבוצה.
מה שמשאיר אותנו עם 112 ביטים לטובת ה-Group ID, ובגלל הטווח המאוד רחב
של IPv6 טווח הכתובות הוא מאסיבי בהשוואה לכתובות IPv4.
כעת אנחנו נסתכל על דגלי הביטים.
נכון לעכשיו, שלושת הביטים הראשונים מתוך הארבעה ללא שימוש.
הדגל בביט הרביעי נקרא "ביט ארעי" (Transient), מטרתו היא לציין בין אם
הכתובת היא קבועה או זמנית.
אם הכתובת היא מוקצית באופן קבוע (מוגדר על ידי IANA), אזי הביט הזה שווה ל-0.
אך לעומת זאת אם הביט הארעי הוא שווה ל-1 אזי הכתובת היא זמנית (או
ארעית) .
דוגמא מושלמת של כתובות קבועות יכולות להיות:
FF02::2
- All Routers.
FF02::6
– OSPF DR Routers.
ארבעת הביטים הנותרים שמעניינים אותנו בכתובת ה-Multicast ידועים כ- Scope ID bits.
ישנם 16 קומבינציות שונות שיכולים להיווצר באמצעות ארבעת הביטים הללו.
לא כל ה-16 נמצאים כעת בשימוש, אך שבעה מהם נמצאים בשימוש על מנת
לקבוע את טווח הכתובות.
כדוגמא, אם טווח הכתובות הוא 1110 או גלובלי, אזי הכתובת היא ברת תוקף
להיות מנותבת על גבי האינטרנט.
אלו הם הטווחים שמוגדרים כעת:
Decimal
Value Binary Value Address Scope
0
0000 Reserved
1 0001 Node-Local Scope
2
0010 Link-Local
Scope
5
0101 Site-Local
Scope
8
1000
Organization Local Scope
14
1110 Global
Scope
15
1111 Reserved
חשוב מאוד לציין שכפייה של דגלים מסויימים והצפה של טווחים אינה תופסת
מקום ברמת תוכנתית בשום מצב.
בנוסף לכך, הצפת טווח כתובות בכפייה צריכה להיות מוגדרת על ידי מנהל
הרשת באמצעות Multicast Filtering.
רוב השימוש ב-Multicast ב-IPv6 דומה מאוד לזו שקיימת ב-IPv4, עם מספר שינויים.
גרסת PIMv2 עבור IPv6 דומה מאוד לתקן הסטנדרטי של PIMv2, רק שכאן הוא תומך רק בשיטת Sparse-Mode.
אין אפשרות להשתמש בגרסאות Dense-Mode על מנת להפיץ את מידע ה-Multicast.
פקודות רבות מתוך ה-IPv4 PIMv2 והקונספטים זהים לאלו של IPv6 כולל DR, ASSERT ו- RP.
פרוטוקול IPv6 משתמש בטבלת ה-unicast routing table (RIB) לטובת ביצוע בדיקות RPF אל מול מקורות Multicast.
משמע שהפצת תעבורת Multicast עבור IPv6 לוקחת פיקוד באותה צורה שבה היה מבוצע ב-IPv4.
ברגע שאנחנו מקלידים את הפקודה:
ipv6 multicast-routing
פרוטוקול PIMv6 הופך להיות פעיל עבור על
הממשקים שעליהם פועל IPv6.
אנחנו יכולים לבטל את פונקציה זו על ידי שימוש בפקודה תחת הממשקים
הרלוונטיים:
no ipv6 pim
כרגיל, כל הממשקים שמופעל עליהם PIM מתחילים להציף תעבורת Multicast על מנת ליצור עצים.
פרוטוקול MLD:
או - Multicast
Listener Discovery , מבוסס על פרוטוקול ICMPv6 ומחליף את פרוטוקול IGMP.
פרוטוקול IGMP הוא פרוטוקול סימון
לקבוצה אשר נמצא בשימוש ב-IPv4 לטובת Multicast.
גרסת MLDv1 מתורגמת ל- IGMPv2 ו-MLDv2 מתורגמת לגרסת IGMPv3, מאפשרת לציין מקור מסויים עבור תעבורת IPv6 Multicast.
פרוטוקול MLD תומך בשלושה סוגי הודעות
בדומה מאוד להודעות IGMP[ והם:
·
Query.
·
Report.
·
Done – שהודעה
זו זהה במהות שלה להודעת Leave ב-IGMPv2.
הגדרת MLD מאוד דומה להגדרת IGMP – אנחנו יכולים לציין מספר
מקסימלי של קבוצות שהצטרפו על ידי מחשב מסויים על גבי ממשק באמצעות פקודה:
ipv6 mld limit
או להצטרף לקבוצה באמצעות פקודה:
ipv6 mld join-group
עוד אנחנו יכולים לציין פקודות רלוונטיות ל-MLD אשר מתייחסות לתשאול של
השכנים באמצעות:
ipv6 mld query-interval
ipv6 mld query-timeout
ipv6 mld query-max-response-time
זמני ה-MLD הם זהים לאלו שהיו ב-IGMPv2 או IGMPv3.
שימו לב לשימוש ב-IPv6 ACL מטה על מנת לשלוט בקבוצות
שמחשב יכול להצטרף אליהם.
רשומת ה-ACL:
מאפשר גם לסנן גם SSM וגם קבוצת Multicast רגילה.
אם אנחנו רוצים לפלטר רק הודעות Join של MLDv1, יש להשאיר את ה- <part 1> ב-Any משמע זה מציין כל מקור.
הפרמטר שמוגדר ב- Part 2 אחראי על קבוצות ה-Multicast שמצטרפות.
אזי אפשרי עם פילטר זה לאפשר או לחסום לאילו קבוצות Multicast ספציפיות יכולות להצטרף על ידי אילו Hosts.
ההגדרות של PIM והגדרות ה-MLD באופן הבא:
ipv6 access-list MLD_FILTER
permit ipv6 any
ff08:;/64
!
ipv6 mld access-group MLD_FILTER
ipv6 mld join-group ff08::8
ipv6 mld query-interval 10
IPv6 PIM
BSR:
פרוטוקול IPv6 RP ו-BSR מאוד זהים לאלו שהיו להם
ב-IPv4.
אך יחד עם זאת ישנם מספר שינויים בהגדרות .
הפקודה שהנתב מודיע על עצמו כ-RP האמצעות פרוטוקול BSR היא:
ipv6 pim bsr candidate rp (NOT THE
INTERFACE NAME)
הפקודה שבאמצעותה אנחנו גורמים לנתב להתחיל להפיץ הודעות RP Bootstrap ולהשתתף בבחירות ה-BSR היא:
ipv6 pim bsr candidate bsr
כרגיל אנחנו יכולים להגדיר נתב אחד בודד שישמש כ-BSR וגם כ-RP.
פונקציה נוספת שקיימת ב-IPv6 BSR היא שאנחנו יכולים להגדיר BSR עם רשימה של Candidate RP's באמצעות הפקודה:
ipv6 pim bsr announce rp
בכך אנחנו מגבילים את הצורך בהודעות דינמיות שנשלחות על ידי Candidates.
ההבדל היחיד המהותי בין IPv4 PIM ו- IPv6
PIM הוא תהליך רישום המקור.
כאשר מקור מסויים מתחיל לשדר Multicast, ה-DR על גבי אותו סגמנט אמור
להירשם אל מול ה-RP.
תהליך זה בדרך כלל מבוצע על ידי שליחת הודעת PIM
Register אל ה-RP וביצוע אנקפסולציה של
המידע המקורי בתוך הפקטה.
ברגע שנתב IPv6 בעל יכולות Multicast לומד את כתובת ה-IP של ה-RP הוא יוצר ממשק TUNNEL ומקשר את הנתב אל
ה-RP.
על גבי ה-TUNNEL מופעל באופן אוטו' Multicast כך
שתעבורת Multicast נשלחת מטה במורד העץ פשוט
מועברת על גבי הצינור לכיוון ה-RP.
ה-TUNNEL בשימוש רק לטובת תהליך
הרישום, ולאחר מכן ה-Receivers הולכים אל הנתיב
האופטימלי, שאינו חוצה את הצינור.
השימוש ב-Tunnel זה מאפשר הפצת תעבורה Multicast בצורה אחידה באמצעות שימוש באותו הקוד
ושימוש בצינור לטובת הודעות הרישום של PIM אל מול ה-RP.
אנחנו יכולים לראות את הרשימה של ה-Tunnelים הפעילים באמצעות פקודה:
show ipv6 pim tunnel
אנחנו יכולים לוודא הגדרות ה-BSR ומי הוא ה-RP באמצעות פקודה:
show ipv6 pim bsr election
או לחילופין להשתמש בפקודה
הבאה על מנת לצפות במיפוי של ה-RP לרשימת הקבוצות:
show ipv6 pim bsr election
IPv6
Embedded RP:
ישנה פונקציה אחת שזמינה ב-IPv4 Multicast ואינה זמינה נכון לעכשיו
ב- IPv6.
פונקציית ה-Auto-RP היא טכנולוגיה אשר נתבים
יכולים להיות מוגדרים כ- Candidate RP, עבור כל קבוצות ה-Multicast שנבחרו.
הם מפיצים את עצמם באמצעות כתובת Multicast 224.0.1.39.
נכון לעכשיו Auto-RP אינו זמין בגרסת IPv6.
בנוסף אין שום דבר שדומה ל- Multicast Source
Discovery Protocol (MSDP) בגרסת IPv6 .
גרסת IPv6 Embedded RP היא פתרון אחד שאנחנו
יכולים להשתמש כאשר אנחנו נדרשים לתמוך במודל ה-PIM SM דרך מספר דומיינים.
קודם לכן, דנו בדגלי הביטים בתוך כתובות IPv6.
הסברנו שתחת נסיבות הרגילות שלושת הביטים הראשונים תמיד היו 000.
כאשר אנחנו משתמשים בפונקציית ה- Embedded RP מצב זה משתנה, ואז הביט
השני, השלישי והרביעי הופכים להיות 1.
הסברנו גם את התפקוד של הביט הרביעי
(הארעי) , כעת אנחנו מסתכלים על הביט השני והשלישי.
הביט השני הוא R ביט וכאשר הוא מוצב עם
ערך של 1, הוא מציין שה- 4-Bit RP Interface ID למעשה נעוץ בתוך כתובת
הקבוצה.
הביט השלישי הוא P ביט וכאשר הוא מוצב עם
ערך של 1 הוא מציין ש- 64 ביטים של כתובת ה- RP נעוצים בתוך כתובת
ה-Multicast.
כעת עם P, R ו- T ביטים מוצבים לערך של 1,
במקום להישען על המידע שמופץ מה-BSR , השולחים והמקבלים
מסכימים לנעוץ את כתובת ה-RP IPv6 לתוך כתובת ה-Multicast עצמה.
הכתובת לוקחת את הצורה הבאה:
FF7x:0yLL:PPPP:PPPP:PPPP:PPPP:
<32 bit-group-id="bit-group-id">
כאשר אנחנו מסתכלים על ערך ה- FF7 במספר הקסדצימלי הוא ערך
של 1111 1111 0111 , וה-x הוא ה-4 ביטים של
ה-Scope, ערך ה-y הוא ה- 4 bit RP Interface ID, ערך ה-LL הוא 8 bit prefix וה- PPPP:PPPP:PPPP:PPPP הם 64 ביטים של ה-RP Prefix.
כתובת ה-RP עצמה נלקחת על ידי לקיחה
של ה-Prefix, ולהסתיר אותה באמצעות ה-LL.
ה-Interface-ID אינו יכול להיות 0, אזי
הוא כל ערך מ-0 ועד F (כל המספרים הם ב-HEX).
אזי הנתב שאמור להיות ה-RP עם הכתובת הזו חייב
להחזיק ממשק Loopback עם הכתובת הזו ולהפיץ אותה אל תוך הפרוטוקול ,
כך שכל הנתבים יוכלו להגיע אליה.
במקרה שלנו בחרנו את כתובת הקבוצה
FF76:0640:2001:CC1E::8 אשר
מקבילה לכתובת ה-RP של 2001:CC1E::6/64.
שאותה הפצנו מנתב R6.
ההגדרות של Embedded RP מבוצעות באופן הבא:
R5:
ipv6 mld join-group
ff76:0640:2001:CC1E::8
!
R6:
ipv6 address 2001:CC1E::6/128
ipv6 eigrp 100
ipv6 rip RIPNG enable
IPv6 SSM:
פרוטוקול SSM או Source Specific
Multicast הוא הצורה הפשוטה ביותר של Multicasting .
המקבל מציין רשימה של מקורות שמהם הוא מעוניין לקבל תעבורת Multicast בנוסף לקבוצות באמצעות הודעות MLD Report.
נתב ה-Multicast בונה את העץ הקצר ביותר
אל עבר המקור שמשדר את ה-Multicast אשר צוין בתוך הודעת ה-Report, והשולח יתחיל להעביר תעבורה.
אין צורך ב-RP בעת שימוש ב-SSM.
למעשה קבוצות בתוך טווח IPv6 SSM לעולם לא ימפו אליהם RP.
ישנו טווח מיוחד ל-SSM שהוא FF3x::/96.
שהוא מאפשר 2^32 קבוצות Multicast פר שולח.
אנחנו יכולים לסנן את המקורות שהמאזין יכול להצטרף אליהם באמצעות
הפקודה תחת ה-MLD:
ipv6 mld access-group
כאשר אנחנו משתמשים ב-ACL על מנת לתחום את המקורות
ואת טווחי הקבוצות.
הגדרות ה-SSM מבוצעות באופן הבא:
ipv6 mld join-group
ff36::8 2001:1:0:146:21A:2FFF:FE78:4678
IPv6
Tunneling:
אנחנו יכולים להעביר תעבורת IPv6 על גבי ענן IPv4 באמצעות מספר טכנולוגיות Tunneling שונות.
השיטה הנפוצה ביותר היא שימוש באמצעות Point-To-Point
Tunnels, או באמצעות שימוש ב-GRE או לחילופין ביצוע
אנקפסולציה של IPv6 in IPv4 (סוג פרוטוקול מיוחד
שתוכנן לשאת פקטות IPv6 בלבד).
זהו צינור שמוגדר עם כתובת מקור וכתובת יעד ב-IPv4 אבל נושא כתובות IPv6.
הגדרות ה-tunneling הם באופן הבא:
R2 – R6:
ipv6 unicast-routing
!
ipv6 address
2001:1:0:2::2/64
!
tunnel source
loopback 0
tunnel destination
150.1.6.6
ipv6 address
2001:1:0:26::2/64
!
ipv6 route ::/0 tunnel 26
R5 – R6:
ipv6 unicast-routing
!
ipv6 address
2001:1:0:5::5/64
!
tunnel source
loopback 0
tunnel destination
150.1.6.6
ipv6 address
2001:1:0:56::5/64
TUNNEL MODE IPV6IP
!
ipv6 route ::/0 tunnel 26
בהצלחה!
מקווה שעזרתי,
אבי
