نمایش نتایج: از شماره 1 تا 10 , از مجموع 10

موضوع: هفته ۱۴ - IP Multicast

  1. #1
    Member Shafagh آواتار ها
    تاریخ عضویت
    May 2010
    نوشته ها
    566
    Thanked: 5028

    هفته ۱۴ - IP Multicast

    برای پرسش یا رفع اشکال از موضوع بعدی استفاده کنید.
    ویرایش توسط Shafagh : 01-01-2013 در ساعت 12:33 AM

  2. The Following 9 Users Say Thank You to Shafagh For This Useful Post:


  3. #2
    Super Moderator Saeed Alkhamis آواتار ها
    تاریخ عضویت
    Jul 2010
    محل سکونت
    Ahvaz
    نوشته ها
    811
    Thanked: 2151
    بصورت پیش فرض Multicast Routing غیر فعال است باید با دستور IP Multicast-Routing آنرا فعال کنیم

    روتر بصورت پیش فرض ترافیک Multicast را forward نمی کند مگر اینکه Muliticasting Routing فعال باشد.

    نکته :برای انتخاب DR اگر همه روتر ها دارای Priority یکسانی باشند بزرگترین IP انتخاب می شود

    RPF Failure: دارای دو نوع RPF هستیم یکی Unicast و Multicast که در Unicast بصورت پیش فرض غیر فعال است

    ولی در Multicast فعال است و نمی توانیم آنرا غیر فعال کنیم .زمانی که ترافیک multicast

    به روتر میرسد source ip را با Mroute table چک میکند اگر ترافیک ورودی موجود بود ترافیک را Forward میکند اما

    اگر برای source ip در جدول mroute مسیری پیدا نکرد به IP routing table مراجعه میکند

    باید source ip ترافیک وردی multicast نزدیک به اینترفیسی باشد که قرار است از آن پاسخ داده شود در غیر اینصورت ترافیک Drop می شود

    نکته : برای کانفیگ Auto-RP باید از Sparse-dense-mode استفاده کنیم ولی سوال پیش می آید که چرا باید از Sparse-dense-mode استفاده کنیم ؟

    چون 224.0.1.39 و 224.0.1.40 فقط در حالت dense-mode کار میکنند و اگر از sparse-mode استفاده کنیم کار نمی کنند

    بنابراین برای auto-rp نیاز به Sparse-dense-mode داریم .سوال دیگری پیش می آید که چرا این دو گروه 224.0.1.39 و 224.0.1.40 در حالت dense-mode کار می کنند ؟

    در auto-rp ترافیک multicast بصورت shared tree ارسال می شوند به این معنا است که روتر نیاز دارد که از RP مطلع باشد .

    روتر به 224.0.1.40 گوش می دهد و باید اعلام کند به RP که می خواهد عضو گروه 224.0.1.40 شود .

    و اما سوال دیگری پیش می آید چگونه می تواند روتر از محل RP با خبر شود اگر آن پیغام RP-Discovery را دریافت نکند ؟

    به عبارت دیگر وقتی که روتر برای عضو شدن به گروه ها نیاز دارند که مطلع باشد کدام روتر RP است و برای دانستن اینکه کدام روتر RP است نیاز است

    که عضو گروه باشد ؟! بنابراین ip pim sparse-dense-mode این مشکل را برای گروه های 224.0.1.40 و 224.0.1.39 حل کرده است به اینصورت که

    اگر RP برای گروهای 224.0.1.39 و 224.0.1.40 شناخته شده بود از sparse-mode استفاده می شود در غیر اینصورت از dense-mode استفاده می شود .

    اگر چندین روتر در یک segment باشند تمام روترها ترافیک multicast یکسانی را Flood می کنند برای مثال در این شکل

    pim.png

    اگر R1 و R4 ترافیک multicast دریافت کنند به همسایه خود R6 می فرستند بنابراین در روتر 6 Traffic Duplication رخ می دهد

    برای جلوگیری از این اتفاق فقط یک روتر اجازه دارد که ترافیک را Flood کند در segment

    زمانی که روتر تشخیص دهدیکی در segment برای گروهی با source ip /destination گروه یکسانی در segment در حال فرستادن ترافیک است

    روتر سریعا یک پیغام Pim Assert می فرستد که این پیغام شامل source ip and group and path cost به مبدا است

    Path cost شامل administrative distance و metric است اگر AD یکسان بود سپس metric را مقایسه می کند اگر metric هم یکسان بود روتری

    که دارای ip بزرگتری است انتخاب می شود

    سوال : چه اتفاقی می افتد اگر روتری که بعنوان pim assert انتخاب شده fail شود ؟

    در واقع راهی نیست که بتوان تشخیص داد باید به مدت سه دقیقه صبر کنیم تا pim assert روتر دوباره انتخاب شود










    ویرایش توسط Saeed Alkhamis : 01-02-2013 در ساعت 10:31 AM

  4. The Following 9 Users Say Thank You to Saeed Alkhamis For This Useful Post:


  5. #3
    Senior Member saeedbabaei24 آواتار ها
    تاریخ عضویت
    Dec 2011
    نوشته ها
    134
    Thanked: 276
    اگر به ما بگویند که نباید در شبکه حجم ترافیک زیاد شود از Sparse-mode استفاده میکنیم. چرا که dense-mode پهنای باند را هدر میدهد.

    در Sparse-dense-mode
    اگر در گروه RP باشد sparse-mode و اگر نباشد Dense-mode کار خواهد کرد.

    وقتی روترRP چند اینترفیس دارد که ترافیک Multicast را عبور میدهند. از Loop-back برای آدرس دهی RP استفاده میکنیم.( چون امکان دارد اینترفیس Down شود)
    روی loop-back نیز باید pim تنظیم شود.


    در shared-segment ها یکی از روتر ها (ip بزرگتر) DR میشود و مسئولیت هدایت پیام های پرس و جو (Queries) را بر عهده می گیرد. با تنظیم priority اینترفیس میتوان روترمورد نظر را DR کرد.
    Ip pim dr-priority priority-value


    در شبکه frame-relay روتر Spoke نمیتواند به گروه های Multicast که در spoke دیگر تنظیم شده است دسترسی داشته باشد چون روتر Hub پیام های Multicast ی را که از یک اینترفیس میگیرد به همان اینترفیس ارسال نمیکند.

    راه حل این مشکل: یا باید از Sub-interface روی روتر Hub استفاده کنیم و یا یک تونل بین spoke ها تنظیم کنیم.

    راه حل دیگر: استفاده از دستور ip pim nbma-mode روی اینترفیس HUB است. این دستور باعث میشود به ازای هر همسایه Multicast یک جدول مجزا شکل گیرد.
    نکته: این راه حل فقط برای sparse-mode است. و اگر بخواهیم از Auto-RP استفاده کنیم، این راه حل جواب نمیدهد چون Auto-RP از dense-mode استفاده میکند و اگر RP کاندیدا یا Agent سمت Spoke ها باشند به مشکل برمی خوریم.
    راه حل این هم این است که Agent سمت Hub باشد، (اگر RP سمت Spoke باشد مشکلی پیش نمی آید).



    میتوان با دستور ip pim accept-rp address-of-rp groups access-list روی RP روتر را برای گروههایی که میخواهیم به عنوان RP باشد، تنظیم کنیم.

    اگر مابین روتر های Multicast، روترهایی باشد که multicast را پشتیبانی نمیکند، میتوان از تونل بین دو روتر استفاده کرد. و pim را روی تونل تنظیم کرد. (IGP را روی تونل غیر فعال میکنیم یا اگر از IGP استفاده میکنیم، Metric آن را زیاد میکنیم.)

    مشکلی که اینجا به وجود می آید این است که روتر بسته های Multicast را به روتری که Multicast را پشتیبانی نمیکند ارسال میکند! برای حل این مشکل روی روتر هایی که تونل را در آن ها تنظیم کردیم، یک Mroute استاتیک مینویسیم تا ترافیک Multicast از تونل عبور کند.


    برای تعیین RP یا باید به صورت دستی IP آن را روی روتر ها تنظیم کنیم، یا به کمک Auto-RP روتر های کاندید را با
    Ip pim rp-announce interface scop ttl group-lista access-list
    و روتر عامل را با:
    IP pim rp-discovery scop ttl
    مشخص کنیم.

    و یا به کمک Bootstrap روتر BSR را با:
    ip pim bsr-candidate interface hash-mask-length priority

    priority هر کدام بیشتر باشد، به عنوان BSR مشخص میشود. (اگر برابر شد، IP بزرگتر)

    و روترهای کاندیدرا با دستور:
    ip pim rp-candidate interface group-list ACL
    مشخص کنیم.



    در Auto-RP:
    اگر دو کاندیدا با Group-range برابر به Agent درخواست دهند، RP انتخواب خواهد شد که IP بزرگتری دارد.
    اگر دو کاندیدا درخواست دهند ولی Group-range یکی زیر مجموعه دیگری باشد Agent هر دو را ارسال میکند ولی روتر آن RP را انتخاب خواهد کرد که Group-range مشخص تری دارد.
    روتر ابتدا آدرس های Multicast ی را که در group-list در وضعیت Deny هستند، و بعد لیست Permit شده ها را جستجو میکند. اگر آدرس را در لیست Deny پیدا کند به شکل Dense-mode عمل خواهد کرد.



    اینترفیس ها باید در وضعیت sparse-dense-mode باشند تا Auto-RP کار کند.
    در غیر این صورت( اگر اجازه نداشته باشیم) میتوانیم از دستور ip pim Auto-rp listener روی اینترفیس ها استفاده کنیم.


    در حالتی که چند RP در دومین باشد:
    اگر بخواهیم Load-balance داشته باشیم، یکی از RP ها را برای یک Range ودیگری را برای Range دیگر تنظیم میکنیم.
    اگر بخواهیم Redundancy داشته باشیم هر دو RP را برای Range یکسان تنظیم میکنیم. هر کدام از RP ها که IP بزرگتری داشته باشد توسط Agent تبلیغ خواهد شد.
    نکته اینجاست:
    اگر بخواهیم Load-balance و Redundancy هر دو را با هم داشته باشیم:
    از چند Access-list استفاده میکنیم، بدین صورت که یکAcce-list برای Range مورد نظر و یک Access-list برای کل Range ها مینویسیم. در این حالت Agent هر دو را تبلیغ خواهد کرد و این روتر Multicast است که بر اساس longest-prefix روتر RP خود را انتخاب میکند.

    برای محدود کردن محدوده ترافیک Multicast:
    استفاده از TTL در انتهای دستور IP pim rp-discovery scop ttl
    استفاده از دستور filter-autorp ip multicast boundary access-list روی اینترفیس است.
    اگر Access-list استاندارد باشد به گروه اشاره میکند. برای اشاره کردن به گروه در Extended-access-list آدرس اول را 0.0.0.0 قرار میدهیم.

    filter-autorp نیز از ارسال پیام های announces و discovery برای گروه های Permit شده جلوگیری میکند. حتی اگر بخشی از گروه ها Permit شده باشند.
    و در BSR با استفاده از دستور ip pim bsr-border روی اینترفیس از عبور پیغام های BSR جلوگیری میکنیم.

    دستورات Show :

    show ip pim rp
    show ip pim interfase
    show ip mroute
    sh ip pim rp mapping
    show ip pim neighbor
    ویرایش توسط saeedbabaei24 : 01-03-2013 در ساعت 09:06 PM دلیل: دستورات Show

  6. The Following 8 Users Say Thank You to saeedbabaei24 For This Useful Post:


  7. #4
    مدیر CCNP Club moghaddas آواتار ها
    تاریخ عضویت
    Sep 2010
    محل سکونت
    Internet
    نوشته ها
    422
    Thanked: 1277
    - یکی از ایرادهایی که می توان نسبت به Multicast قائل شد استفاده از UDP است، چرا که عدم وجود windowing و slow-start ممکن است باعث congestion گردد.

    - دستور ip pim spt threshold زمان تغییر حالت روتر از G,* به S,G را تعیین می کند.

    - در تمامی modeها، روی Interface که بعنوان RP تبلیغ می شود، می بایست PIM فعال گردد.

    - در شبکه های Frame-Relay با توجه به عدم امکان Broadcast و Multicast می بایست از دستور ip pim nbma-mode که تنها برای sparse mode کاربرد دارد استفاده کرد. (تبدیل به unicast)

    - در شبکه های Frame-Relay در حالت پیشفرض گذردهی ترافیک multicast، بصورت process-switching انجام می شود.

    - در حالت Bidirectional PIM می بایست دستور ip pim bidir-enable روی تمام Interfaceهای PIM تنظیم شود. در انتهای اغلب دستورات RP نیز کلکه ی کلیدی bidr اضافه می شود.

    - Multicast در IPv6 تنها بصورت Sparse-mode قابل پیاده سازی است.

    - هنگام فعال سازی توسط دستور Ipv6 multicast-routing، روی تمام interfaceها multicast فعال می شود. جهت غیرفعال کردن آن روی Interface خاص، می بایست دستور no ipv6 pim تنظیم شود.

    - اگر IGP درحال انجام توزیع بار روی pathهای مختلف است، می توان ترافیک multicast را نیز توسط دستور ip multicast multipath روی مسیرهای مختلف load-balance کرد. این مورد باعث می شود RFP Checkها نیز fail نشوند.
    Network Consultant/Solutions Architect
    mohammad [at] moghaddas [dot] com
    [Only registered and activated users can see links. ]

  8. The Following 8 Users Say Thank You to moghaddas For This Useful Post:


  9. #5
    Moderator Alireza.mohammadi آواتار ها
    تاریخ عضویت
    Jul 2010
    محل سکونت
    iran.tehran
    نوشته ها
    1,156
    Thanked: 4555
    • IP های Multicast از آدرس های کلاس D برای برقراری ارتباط استفاده می کنند، این آدرس ها از رنج ۲۲۴٫۰٫۰٫۰ تا ۲۳۹٫۲۵۵٫۲۵۵٫۲۵۵ قرار دارند.



    • دسته بندی این IP ها به دو شکل می باشد :


    1- IP آدرس هایی می باشند که قبلا رزور شده اند و عضویت در این گروه ها دائمی نمی باشد :


    • 224.0.0.0 : آدرس پایه رزرو شده
    • 224.0.0.1 : تمام سیستم ها ی زیر شبکه آدرس ذکر شده
    • 224.0.0.2 : تمام روتر ها آدرس ذکر شده
    • 224.0.0.5 :OSPF
    • 224.0.0.9 : RIP2
    • 224.0.0.6 : روتر های مختص به OSPF
    • 224.0.0.10: EIGRP routers
    • 224.0.0.13: PIM routers
    • 224.0.0.22:IGMPv3
    • 224.0.0.25: RGMP
    • 224.0.1.39: Cisco-RP-Announce
    • 224.0.1.40: Cisco-RP-Discovery



    2- آدرسهای آزاد برای رزرو های دائمی در شبکه که برای Application های مختلف آزاد می باشد.


    • Multicast Application ها باید بر روی تمامی Host های شبکه به منظور دریافت ترافیک Multicast باید نصب گردد.
    ویرایش توسط Alireza.mohammadi : 01-07-2013 در ساعت 01:15 PM
    تا ابد آب شرمنده عباس ماند...

    [Only registered and activated users can see links. ]


    دوستانی که سوال میپرسند در نحوه بیان مشکل دقت کنند تا من و سایر دوستان بتوانیم سریع مشکل را متوجه شویم.
    مشاوره از طریق پیام خصوصی انجام می شود.

  10. The Following 8 Users Say Thank You to Alireza.mohammadi For This Useful Post:


  11. #6
    Member
    تاریخ عضویت
    Sep 2010
    محل سکونت
    اهواز
    نوشته ها
    34
    Thanked: 69
    توضیحات کلی:

    -گیرنده ترافیک multicast گروهی از host های هستند که در گروه join شده اند.
    -اعضا برای ارتباط با فرستنده از unicast استفاده می کنند.
    -multicast بصورت connectionless و از udp استقاده می کند.
    -host ها برای عضو شدن در گروه از پروتکل IGMP استفاده می کنند.
    -از کلاس D برای آدرس دهی در شبکه های multicast استفاده می شود( از رنج 224.0.0.0 تا 239.255.255.255)
    -برای route کردن ترافیک multicast از یکی از پروتکلهای زیر استفاده می شود:
    PIM,DVMRP,MOSPF
    (protocol Independent multicast)PIMیکی از مهمترین پروتکلهای روتینگ multicast
    می باشد.از unicast routing table موجود برای چک کردن Reverse Path forwarding
    استفاده میکند .از آنجائیکه جدول مجرایی نظیر MOSPF ,وِDVMRP ندارد لذا ترافیک حاصل از ارسال و دریافت update route ها راندارد .در نتیچه همین موضوع باعث شده که سرباری این پروتکل نسبت به دو پروتکل دیگر بسیار کمتر باشد.این پروتکل دارای
    3 مد می باشد.PIM-DM,PIM-SMوBi-directional PIM

    گزارش تمرینات :

    PIM-DM:1

    این پروتکل برای شبکه های کوچک که بسیاری از subnet های آن متقاضی دریافت Multicast هستند مناسب می باشد.مکانیزم کاری آن بر اساس مدل Push میباشد یعنی ترافیک multicastرا برای کلیه روترهای همسایه PIM-DM و اینترفیسهای directly connected که بر روی آنها PIM-DM فعال شده باشد Flood می نماید.اگر روتر یا اینترفیسی نیازی به این ترافیک نداشته باشد با ارسال prune message از دریافت
    ترافیک جلوگیری می کند.پروسه flood-prune هر سه دقیقه یکبار تکرار می شود.در نتیجه پهنای باند زیادی را اشغال می نماید.config آن ساده است و به عبارتی plug-and-play می باشد.از source tree استفاده می نماید و در نتیجه RP نیاز ندارد.
    در state *,G تمامی OIL ها لیست می شوند و در state S,G اینترفیس خروجی source مشخص می گردد.اگر اینترفیس خروجی null باشد یعنی دستیابی به source مقدور نمی باشد.و RPF neighbor of 0.0.0.0 معنای این است که source به همین router که بر که خروجی دستور show ip mroute را مشاهده می کنیم connect شده است.

    Multicast RPF Failure-2
    RPF Failure در موارد رخ می دهد:
    1-ترافیک از اینترفیس خروجی اشتباهی Flood می گردد که در این صورت نتیجه آن خوب است زیرا از loop جلوگیری می کند.
    2- در جدول mroute مسیری برای رسیدن به source وجود نداشته باشد.که این مورد در نتیجه مواردی نظیر وجود چندین IGP وعدم فعال بودن multicast بر روی لینک انتخاب شده پیش می آید که کلا ناشی از خطاهای مربوط به config کردن multicast routing است و با تصحیح config برطرف خواهد شد.
    یکی از ساده ترین راهها برای برطرف سازی این مشکل استفاده از Ip mroute است تا اطلاعات لازم برای RPF بصورت دستی وارد جدول گردد.
    - وقتی تغییراتی در توپولوژی شبکه ایجاد میگردد این تغییرات با تاخیر انجام می گیرد زیرا در این زمان عملیات مربوط به چک نمودن RFP مجددا انجام می گیرد. برای تنظیم این مدت زمان از دستورmulticast rpf backoff <min-delay ms> <max-delay
    استفاده می شود.

    3- PIM-SM
    این پروتکل برای شبکه های بزرگ که درخواست کنندگان در نقاط مختلف پراکنده می باشند مناسب می باشد.در این پروتکل ترافیک multicast فقط برای نقاطی که تقاضا
    کنند ارسال می نماید. در این پروتکل source,receiver با روش داینامک یکدیگر را پیدا می کنند که برای همین منظوراز RP استفاده می شود که یکی از روترها این نقش را برعهده میگیرد که به سبب آن receiver علاقه مندی خود را به گروه خاصی در RP join می نمایدوsource نیز گروه خود رادر RP ثبت می نماید.
    RP را می توان به صورت دستی بر روی کلیه روترها تعریف نمود ویا با استفاده از پروتکلهای دینامیک نظیر auto-rp و یاbsr تعیین نمود.
    وقتی برای تعیین RP بصورت static و دینامیک استفاده شود برای force نمودن RP تعیین شده در دستور ip pim rp-address باید overrideقید گردد.

    PIM Sparse-Dense Mode-4
    این مد قادر است ترافیک DM و SM را ارسال نماید برای گروهای که RP دارند ترافیک بصورت SM و برای سایر گروها ترافیک بصورت DM ارسال خواهد شد.

    PIM Assert-5
    وقتی در یک segment چندین روتر ترافیک مربوط به یک source و گروه را ارسال کنند این موضوع باعٍث ایجاد dublication می شود در این صورت یکی از روترها پیغام َassert که حاوی source,group ,AD,metric است به همه روترهاارسال می گردد .روتر برنده پیغام supperior assert ارسال میکند وبه بفیه روترها اعلام می کند که ارسال به این source,group را متوقف نمایند. بر این اساس فقط روتر برنده ارسال ترافیک برای این گروه را بر عهده می گیرد.معیار انتخاب روتر برنده بصورت زیر است :
    1-َروتری که AD کمتری دارد.2-درصورت AD مساوی متریک کمتر 3-در غیر اینصورت روتری که ip address بزرگتری دارد.
    چنانچه روتری که بدین ترتیب انتخاب شده باشد مورد نظر ما نباشد با تغییر مقدار AD می توانیم نظر خود را اعمال نمایم.

    PIM Accept RP-6
    با استفاده از این ویژگی می توانیم یک RP را فقط مسئول دریافت پیا مهای Join/prune گروهای که در asscess list هستند قرار دهیم بدین ترتیب ترافیک گروهای دیگر را ارسال نمی کند.

    7-PIM DR Election
    در یک multi-access segment یک روتر که ip-address بزرگترو priority بالاتری نسبت به سایر روترهای در آن segment دارند
    بعنوان DR انتخاب می شود بدین ترتیب receiver ها پیامهای که باید به RP برسانند تحویل DR داده و DR به RP می رساند.

    8- PIM Accept Register
    با ایستفاده از این امکان امنیتی می توانیم RP را محدود بهregister کردن source های که در access-list هستند بنمائیم. بدین ترتیب RP از register کردن سایر source ها جلوگیری خواهد کرد.

    Multicast Tunneling-9
    یکی از روشهای انتقال ترافیک multicast در شبکه های که قابلیت ارسال ترافیک multicast را ندارند استفاده می شود.برای انتقال ترافیک در تونل می توان از یکی از پروتکلهای IGP استفاده نمود در غیر اینصورت باید از static mroutes استفاده نمود.

    Auto-RP-10
    auto-rp اجازه می دهد که روترها بصورت اتوماتیک group-to-rp mapping رایاد بگیرند.برای پیاده سازی آن نیاز cRP و MA داریم.Multicast برای توزیع Group-to-RP mapping از دو آدرس زیر استفاده می کند
    Cisco-Announce Group - 224.0.1.39
    • Cisco-Discovery Group - 224.0.1.40
    از آنجائیکه این آدرسها باید توزیع شوند لذا برای توزیع این گروهها از ِDense mode استفاده می شود.
    ویرایش توسط sima : 01-07-2013 در ساعت 10:39 PM

  12. The Following 6 Users Say Thank You to sima For This Useful Post:


  13. #7
    Moderator farhadnia آواتار ها
    تاریخ عضویت
    Jul 2010
    محل سکونت
    خرم آباد
    نوشته ها
    1,550
    Thanked: 4429
    آدرس های Multicast در رنج 239.255.255.255 - 224.0.0.0 دسته بندی شده اند این دسته با عدد باینری 1110 شروع می شوند. در آدرس های Multicast نیاز به مشخص کردن Subnet Mask نمی باشد چون این آدرس ها ساختار سلسله مراتبی ندارند.

    آدرس های Multicast در چهار گروه توسط IANA به شرح زیر طبقه بندی شده اند:

    گروه آدرس های ثابت : 224.0.1.255-224.0.0.0 که در این گروه آدرس های 224.0.0.255-224.0.0.0 غیر قابل روت و آدرس های 224.0.1.255-224.0.1.0 قابل روت هستند.

    گروه آدرس های SSM : 232.0.0.0-232.255.255.255 که در IGMPV3 جهت بالا بردن امنیت مورد استفاده قرار می گیرند.

    گروه آدرس های GLOP :شامل 233.255.255.255-233.0.0.0 که این رنج به کسانی اختصاص داده می شود که یک AS Number معتبر اخذ کنند و آدرس Multicast این AS برابر آدرس 233.AS-Number.1-255 می شود مثال: فرض شود که یک ASN به شماره 9999 توسط یک شرکت رجیستر شده است تعداد 255 آدرس Multicast به آدرس 233.39.15.0 تا 233.39.15.255 به این شرکت اختصاص داده می شود.

    گروه چهار Private Multicast آدرس :239.255.255.255 - 239.0.0.0 که برای استفاده Private در شبکه ها در نظر گرفته شده است.

    در لایه دوم جهت شناسایی HOST هایی که نیاز به دریافت بسته های Multicast دارند یک MAC آدرس به صورت زیر برای هر آدرس Multicast ساخته می شود:


    پروتکل IGMP جهت مشخص کردن HOST هایی که تمایل به دریافت بسته های Multicast دارند مورد استفاده قرار می گیرد ، IGMP از IP Protocol به شماره 2 و TTL یک در بسته های خود استفاده می کند. دلیل استفاده از TTL یک ، این است که پیام های IGMP فقط در محدوده یک LAN معتبر می باشند و نباید از روتر عبور کنند.

    پروتکل IGMP دو هدف اصلی به قرار زیر را دنبال می کند:

    یک) مطلع کردن روتر محلی از وجود HOST هایی در شبکه که مایل به دریافت ترافیک Multicast می باشند.

    دو) مطلع کردن روتر محلی از اینکه HOST ای در شبکه دیگر خواهان دریافت ترافیک Multicast نیست.

    IGMP در سه نسخه در حال حاضر موجود است که در این بین نسخه شماره دو به صورت گسترده مورد استفاده است.

    روتری که در مجموعه وظیفه دعوت به الحاق به یک گروه مالتی کست را دارد Querier Router نامیده می شود. روتری که کوچکترین IP آدرس را دارا می باشد به عنوان Querier Router انتخاب می شود. QR در هر شصت ثانیه به صورت ئیش فرض یک پیام دعوت جهت الحاق به گروه مالتی کست را به LAN ارسال می کند.

    از آنجایی که آدرس های Multicast هیچگاه به عنوان source بسته ها قرار نمی گیرند سویچ های لایه دوم هیچ گونه اطلاعی از نحوه ارسال بسته های Multicast نخواهند داشت و بسته های Multicast را همانند بسته های Broadcast بر روی همه ی پورت های خود ارسال می کنند. برای رفع این مشکل پروتکل های IGMP Snooping,CGMP,RGMP معرفی شده اند.

    به صورت کلی دو نوع پروتکل Routing جهت انتقال Multicast در شبکه ها وجود دارد: Dense Mode و Sparse Mode که از DM در حالتی استفاده می شود که اکثر HOST های موجود در شبکه خواهان دریافت ترافیک مالتی کست باشند یعنی اینکه ترافیک مالتی کست در شبکه عمومیت داشته باشد و حال SM در مواردی مورد استفاده قرار می گیرد که بخشی از شبکه نیاز مند دریافت ترافیک مالتی کست باشند. از پروتکل های Routing مالتی کست که در حالت DM کار می کنند می توان به DVMRP,MOSPF,PIM-DM را نام برد و پروتکل PIM-SM در حالت Sparse کار می کند.

    جهت جلوگیری از LOOP در پروتکل های روتینگ( RPF ) Multicast از Reverse Path Forwarding استفاده می شود ، این مکانیزم بدین گونه عمل می کند که Source بسته دریافتی را با Routing Table مطابقت می دهد در صورتی که بسته از همان اینترفیسی دریافت شده باشد که جهت ارسال اطلاعات به آن آدرس مورد استفاده قرار می گیرد ، بسته دریافتی مورد قبول واقع می شود در غیر این صورت بسته حذف می شود و یک پیام Prune Message از روی اینترفیس مورد نظر به روتر Upstream ارسال می کند.

    در شبکه های Multi-Access جهت مدیریت بسته های Multicast یک روتر جهت DR انتخاب می شود که روتری که دارای بزرگترین IP-Address باشد این وظیفه را به عهده می گیرد.

    در IGMPV1 روتری جهت Querier انتخاب نمی شود و روتر DR وظیفه ارسال Query ها را نیز بر عهده دارد ،د ر IGMPv2 چون بزرگترین IP روتر DR می شود و کوچکترین Router وظیفه ارسال Query را به عهده دارد ، در شبکه ای که بیش از یک روتر موجود است ، وظایف بین روتر ها تقسیم می شوند.

    در PIN-DM پیام هایی به شرح زیر استفاده می شود:

    Hello Message : جهت ایجاد همسایگی و حفظ آن بین روتر ها که به صورت Default هر 30 ثانیه ارسال می شود . این پیام همچنین جهت انتخاب روتر DR هم مورد استفاده قرار می گیرد.

    Prune Message: در صورتی که هیچ Host ای در شبکه تمایل به دریافت ترافیک مالتی کست نداشته باشد و یا روتر downstream ای برای دریافت پیام ها داوطلب نباشد روتر به روتر Upstream خود که ترافیک مالتی کست را ارسال می کند یک پیام Prune Message ارسال می کند و از دریافت ترافیک انصراف می دهد. این پیام تا سه دقیقه برای روتر بالا دستی معتبر خواهد بود.

    State Refresh : جهت حفظ وضعیت Prune یک لینک ، روتر پایین دستی موظف است قبل از تمام شدن زمان Expire پیام Prune یک State Refresh به روتر بالادستی ارسال کند.

    Assert : در این مکانیزم در شبکه ای که بیش از دو روتر موجود است جهت مشخص کردن روتر انتقال دهنده پیام های مالتی کست ( Forwarder ) یک رویه انتخاب به شرح زیر صورت می پذیرد:

    الف) روتری که کوچکترین مقدار AD را برای پروتکل مسیر یابی دارد که مسیر دسترسی به Source اطلاعات از آن استفاده می کند.
    ب) کوچکترین مقدار متریک روتی که مسیر دسترسی به Source بسته های مالتی کست دارد.
    ج) در صورت شکسته نشدن گره روتری برنده روال Assert خواهد شد که بزرگترین IP آدرس را در بین روتر های شبکه دارد .

    توجه شود که روتر Querier میتوان متفاوت از روتر Forwarder باشد.

    Prune Override : در شبکه ها Multiaccess در صورتی که یک روتر پیام Prune را صادر کند ممکن است ارتباط روتر های دیگر متصل به شبکه قطع شود در این مورد روتر های دیگر موظف هستند به محض دریافت یک Prune در شبکه یک پیام Prune Override به روتر DR ارسال کنند تا روتر DR اشتباها ارتباط مابقی روتر ها را قطع نکند. در واقع این پیام چیزی جز یک پیام join نیست.

    Graft : زمانی که یک روتر که قبلا در شبکه لینک ارتباطی خود را Prune کرده باشد مایل به دریافت مجدد اطلاعات مالتی کست باشد نیاز به ارسال یک پیام Graft از لینکRPF به روتر بالا دستی خود دارد.

    در واقع تفاوتی بین ساختار پیام های Prune Message و Join Message در پروتکل های PIM-DM و PIM-SM وجود ندارد و تنها در Prune Message در فیلد Prune آدرس گروه ذکر می شود و در Join Message در فیلد join آدرس گروه نوشته می شود ، به همین دلیل به این نوع پیام Join/Prune Message گفته می شود.

    MOSPF توسط روتر های سیسکو پشتیبانی نمی شود. و DVMRP در IOS به صورت کامل پیاده سازی نشده است و روتر های سیسکو تنها قابلیت اتصال به شبکه هایی که از این پروتکل استفاده می کنند را دارا است.

    برای فعال سازی قابلیت ارسال و دریافت پیام های مالتی کست در روتر های سیسکو باید دستور ip multicast-routing در مود Global Config وارد شود.

    جهت فعال سازی PIM-DM در مود کانفیگ اینترفیس دستور ip pim dense-mode را وارد می کنیم و همینطور برای فعال سازی PIM-SM از دستور ip pim sparse-mode استفاده می شود.

    جهت مشخص کردن نسخه IGMP مورد نیاز در کانفیگ اینترفیس دستور ip igmp version را وارد می کنیم.

    برای تغییر زمان 60 ثانیه ای ارسال پیام های Query در شبکه می توانی در مود کانفیگ اینترفیس دستور ip igmp query-interval SECOUNDs را وارد کنیم.

    TTL Threshold مکانیزم امنیتی است جهت مشخص کردن حوزه گسترش پیام های مالتی کست ، این مکانیزم بدین گونه عمل می کند که در صورت دریافت یک بسته Multicast مقدار TTL این بسته با مقدار مشخص شده برای TTL Threshold مقایسه می شود در صورت کوچتر یا مساوی بودن این مقدار بسته انتقال داده می شود و در غیر این صورت بسته حذف می گردد برای تنظیم این مقدار در مود کانفیگ اینترفیس دستور ip multicast ttl-thershold را وارد می کنیم. این مقدار به صورت پیش فرض برابر صفر است.

    برای مشاهده جدول مسیر های Multicast از دستور show ip mroute استفاده می شود.

  14. The Following 8 Users Say Thank You to farhadnia For This Useful Post:


  15. #8
    مدیر بخش نشر دانش Yousef Naimi آواتار ها
    تاریخ عضویت
    Aug 2010
    محل سکونت
    Tehran
    نوشته ها
    788
    Thanked: 3844

    Lightbulb

    • PRF failure در دو حالت کلی رخ می دهد :
      یکی اینکه پکت ها از اینترفیس اشتباه flood out بشوند . این حالت مطلوب است و باعث جلوگیری از ایجاد لوپ می شود .
      دیگر اینکه کوتاهترین مسیرهای unicast با درخت های multicast distribution همخوانی نداشته باشند . این حالت نامطلوب است وبه خاطر تنظیمات اشتباه multicast routing است .



    • عیبها و نقص های موقتی RPF ممکن است در شرایطی که شبکه unstable است و روترها در حال تغییر دادن جداول کوتاهترین مسیر هستند رخ دهد .
      بهترین راه برای پیدا کردن و ایزوله نمودن مسایل RPF در شبکه ، اینست که روی تمام روتر ها دستور debug ip mpacket زده شود ؛ از نزدیکترین روتر به مقصد شروع می کنیم و به سمت مبدا حرکت می کنیم ؛ این دستور پکت های مالتی کست process-switched را نشان می دهد و مسایل مربوط به RPF را مشخص می کند .

      توجه داشته باشید که باید دستور no ip-mroute-chache را روی تمام اینترفیس هایی که پکت های multicast دریافت می شوند زد ؛ این دستور fast-switching یا پکت های مالتی کست را disable می کند .



    • استفاده از tunneling یک اشکال دارد و آن هم پنهان کردن توپولوژی شبکه واقعی است و لذا بیشتر مواقع از تکرار موثر مالتی کست جلوگیری می کند .
      هنگام تنظیم یک تانل ، می توان IGPرا روی اینترفیس تانل enable یا disable کرد .
      اگر تصمیم دارید که از تانل برای traffic delivery استفاده کنید ، لازم است که PIM را روی همان اینترفیس فعال کنید .

      به دلیل این دو عامل زیر ، ممکن است به سادگی موارد RPF failure رخ دهد :
      1- اگر هیچ IGP روی تانل فعال نیست ، شما ممکن است نیاز داشته باشید static mroute را برای تصحیح هر RPF check فراهم کنید .
      2- اگر IGP روی اینترفیس تانل فعال است ، هزینه ی عبور تانل ممکن است بیشتر از هزینه ی عبور شبکه ی زیرین باشد . بطور کلی بهتر است IGP یکسانی روی شبکه ی زیرین و روی تانل تنظیم نشود .
      ممکن است نیاز داشته باشید متریک ها را تنظیم کنید یا static mroute فراهم آورید تا مشکلات حاصله را تصحیح نمایید .
    It's OK to fail, as long as you keep trying

    CCNA - CCNA Security - CCNP R&S - CCNP Security

  16. The Following 7 Users Say Thank You to Yousef Naimi For This Useful Post:


  17. #9
    Member
    تاریخ عضویت
    Apr 2011
    نوشته ها
    52
    Thanked: 97
    برای فعال سازی multicast در global config دستور ip multicast-routing را می زنیم

    ترافیک Multicast به دو صورت SPT,RPF تعریف می شود

    PIM هم به صورت Dense mode , Sparse mode کار می کند

    در تمام روترها Pim version و mode روی تمامی interface ها یکی باشد

    RPF در دو حالت Failed می شود 1- اینترفیش اشتباه انتخاب کنیم 2 – Unicast برای short path یکی نباشد و بهترین دستور برای چک کردن debug ip mpacket می باشد

    شما می توانید با دستور ip mroute <IP> <mask> یک جدول درست می کند برای RPF وقتی یک multicast packet می آید روتر اولین جایی که می ببیند جدول mroute table است و وقتی یک روت هم در جدول mroute باشد هم در جدول unicast روتر جدول mroute را ترجیح می دهد

    برای مشاهد جدول mroute دستور show ip mroute را می زنیم

    PIM spares mode برای شبکه های بزرگ استفاده نمی شود

    Multicast در IPV6 بصورت spare mode کار می کند

  18. The Following 6 Users Say Thank You to alimor For This Useful Post:


  19. #10
    Member Sepide آواتار ها
    تاریخ عضویت
    Sep 2010
    محل سکونت
    Tehran
    نوشته ها
    61
    Thanked: 130
    Dense mode routing protocol :
    DVMRP : Distance vector multicast routing protocol
    PIM-DM : Protocol independent multicast Dense mode
    MOSPF : Multicast open shortest path first
    روترهای مالتیکست با استفاده از Reverse Path Forwarding از ایجاد loop جلوگیری میکند تا RPF روی پکتهای مالتی کست چک نشود پکت ارسال نمیشود .
    برای جلوگیری از هدر رفتن منابع شبکه از Spare-mode استفاده میکنیم .
    Dense-mode : ترافیک ارسال میشوند مگر اینکه از downstream router پیامی دریافت کند که ترافیک را ارسال نکند .
    Spare-mode : ترافیک را به هر روتری ارسال نمیکند مگر اینکه پیامی دریافت کند .
    Multicast Scoping :
    TTL Scoping : روتر ttl پکت را با ttl کانفیگ شده مقایسه میکند ، اگر کوچکتر یا مساوی بود پکت ارسال میشود .
    Administrative Scoping : رنج 239.0.0.0 تا 239.255.255.255
    ویرایش توسط Sepide : 01-07-2013 در ساعت 08:12 AM

  20. The Following 8 Users Say Thank You to Sepide For This Useful Post:


موضوعات مشابه

  1. هفته ۱۴ - IP Multicast - طرح سوال / مشکلات
    توسط Shafagh در انجمن CCIE Room
    پاسخ ها: 7
    آخرين نوشته: 01-07-2013, 11:41 PM
  2. ارسال فریم Multicast توسط سوئیچ
    توسط perspolis در انجمن CCNP Club
    پاسخ ها: 2
    آخرين نوشته: 10-08-2012, 10:28 AM
  3. مشکل با Multicast در سوئچ 2960 و 3560
    توسط pashaei در انجمن Routing & Switching به پارسی
    پاسخ ها: 5
    آخرين نوشته: 11-20-2011, 12:15 PM
  4. آشنایی با Multicast در شبکه
    توسط Shafagh در انجمن Routing & Switching به پارسی
    پاسخ ها: 0
    آخرين نوشته: 01-01-2011, 03:42 AM

مجوز های ارسال و ویرایش

  • شما نمیتوانید موضوع جدیدی ارسال کنید
  • شما امکان ارسال پاسخ را ندارید
  • شما نمیتوانید فایل پیوست کنید.
  • شما نمیتوانید پست های خود را ویرایش کنید
  •