OVERVIEW :
FIRST OF ALL UNDERSTAND THERE ARE THREE FUNDAMENTAL TYPES OF IPv4 ADDRESSES:
--- > A Unicast Address Is Designed To Transmit A Packet To A Single Destination.
In Unicast, Applications Can Send One Copy Of Each Packet To Each Member Of The Multicast Group. Unicast Is Simple To Implement But Difficult To Scale If The Group Is Large. Unicast Applications Also Require Extra Bandwidth, Because The Same Information Has To Be Carried Multiple Times, Even On Shared Links.
--- > A Broadcast Address Is Used To Send A Datagram To An Entire Subnet Work.
In Broadcast Applications Can Send One Copy Of Each Packet And Address It To A Broadcast Address. Broadcast Is Simpler To Implement Than Unicast, But It Is More Difficult To Route, Especially Over A Wide Area. The Network Must Either Stop Broadcasts At The LAN Boundary (Often Done To Prevent Broadcast Storms) Or Send The Broadcast Everywhere—A Significant Burden On Network Resources If Only A Few Users Want To Receive The Packets. It Is Nearly Impossible To Send Broadcast Packets To Members Of A Multicast Group That Are Not Within Your Enterprise Network, Such As Across The Internet. Broadcast Packets Must Be Processed By Each Host On The Network, Even Those Not Interested In The Data, Which Places A Burden On Those Hosts.
--- > A Multicast Address Is Designed To Enable The Delivery Of Datagrams To A Set Of Hosts That Have Been Configured As Members Of A Multicast Group In Various Scattered Subnet works.
In IP Multicast, Applications Send One Copy Of A Packet And Address It To A Group Of Receivers (At The Multicast Address) That Want To Receive It Rather Than To A Single Receiver (For Example, At A Unicast Address). Multicast Depends On The Network To Forward The Packets To Only Those Networks And Hosts That Need To Receive Them, Therefore Controlling Network Traffic And Reducing The Amount Of Processing That Hosts Have To Do. Multicast Applications Are Not Limited By Domain Boundaries But Can Be Used Throughout The Entire Internet.
MULTICAST ADDRESSING :
IP Multicast Addresses Are Reserved And Assigned From Within The Class D Address Range From 224.0.0.0 Through 239.255.255.255. The Following Table Is A Partial List Of Well-Known Class D Addresses That Are Reserved For IP Multicasting And Registered With The Internet Assigned Numbers Authority (IANA).
The Only Difference Between A Multicast Ip Packet And A Unicast Ip Packet Is The Presence Of A “Group Address” In The Destination Address Field Of The IP Header. Instead Of A Class A, B, Or C IP Address, Multicasting Employs A Class D Destination Address Format (224.0.0.0 - 239.255.255.255).
A Single IP Address Within The Class D Reserved Range Identifies Each Multicast Group. Each Group's Reserved IP Address Is Shared By All Host Members Of The Group Who Listen And Receive Any IP Messages Sent To The Group's IP Address.
IP Multicast Addresses Are Mapped To A Reserved Set Of Media Access Control Multicast Addresses.
MULTICAST OVERVIEW :
Multicast Is A Point To Multi-Point (P2MP) Data Transmission Mode. During Data Transmission, Multicast Can Ensure The Security Of Information. Multicast Consumes Limited Network Bandwidth.
The Multicast Technology Applied To IPv4 And IPv6 Is Called IP Multicast. The Internet Services Implemented Through IP Multicast Include IPTV, Video And Audio Conferences, E-Learning, And Remote Medicine.
WHAT IS IP MULTICASTING?
Multicast (Point-To-Multipoint) Is A Communication Pattern In Which A Source Host Sends A Message To A Group Of Destination Hosts. Although, This Can Be Done By Sending Different Unicast (Point-To Point) Messages To Each Of The Destination Hosts, There Are Many Reasons, Which Make Having The Multicasting Capability Desirable.
Most High-Level Network Protocols Only Provide A Unicast Transmission Service. That Is, Nodes Of The Network Only Have The Ability To Send To One Other Node At A Time: All Transmission With A Unicast Service Is Inherently Point-To-Point. If A Node Wants To Send The Same Information To Many Destinations Using A Unicast Transport Service, It Must Perform A Replicated Unicast And Send N Copies Of The Data To Each Destination In Turn.
A Better Way To Transmit Data From One Source To Many Destinations Is To Provide A Multicast Transport Service. With A Multicast Transport Service, A Single Node Can Send Data To Many Destinations By Making Just A Single Call On The Transport Service: For Those Applications Which Involve A Single Node Sending To Many Recipients, A Multicast Facility Is Clearly A More Natural Programming Paradigm Than Unicast. However, The Benefits Of Multicast Are More Than Just Logical:
Many Underlying Transmission Media Provide Support For Multicast And Broadcast At The Hardware And Media-Access Level. When A Multicast Service Is Implemented Over Such A Network, There Is A Huge Improvement In Performance: If The Hardware Supports Multicast, A Packet, Which Is Destined For N Recipients, Can Be Sent As Just A Single Packet!
Multicast Is Useful Because It Allows The Construction Of Truly Distributed Applications, And Provides Important Performance Optimizations Over Unicast Transmission.
IP Multicast Is A Protocol For Transmitting IP Datagrams From One Source To Many Destinations In A Local Or Wide-Area Network Of Hosts, Which Run The TCP/IP Suite Of Protocols. The Basic Facility Provided By The IP Protocol Is A Unicast Transmission Service: That Is, The Current Standard For IP Provides Only Unreliable Transmission Of Datagrams From A Single Source Host To A Single Destination Host. The Resulting IP Multicast Routing Protocol Provides Efficient Delivery Of Datagrams From One Source To An Arbitrary Number Of Destinations Throughout A Large, Heterogeneous Network Such As The Internet.
MANY NEW MULTI-POINT APPLICATIONS ARE EMERGING AS DEMAND FOR MULTICASTING CONTENT GROWS. WE CAN DIVIDE THESE APPLICATIONS INTO TWO MAJOR AREAS:
The IP Multicast Protocol Is A Standard Extension To The IP Protocol. The Ietf-Recommended Standard, Rfc 1112, Defines Extensions To The IP Protocol. This Standard Specifies The Extensions Required Of A Host Implementation Of The Internet Protocol (IP) To Support Multicasting. It Also Specifies The Format, Addressing And Routing Of Messages On The Internet.
IP Multicast Allows A Sender To Send A Single Message To A Group Address. Any Receiver That Joins The Network Under This Group Address Receives The Message. Routers Within The Network Handle The Replication And Forwarding Of The Message To The Appropriate Receivers Intelligently. All Major Router Vendors Support IP Multicast.
AN IP MULTICAST-ENABLED NETWORK REQUIRES TWO ESSENTIAL PROTOCOL COMPONENTS :
IP Multicasting Is Defined As The Transmission Of An IP Datagram To A "Host Group", A Set Of Zero Or More Hosts Identified By A Single IP Destination Address. A Multicast Datagram Is Delivered To All Members Of Its Destination Host Group With The Same "Best-Efforts" Reliability As Regular Unicast IP Datagrams, I.E. The Datagram Is Not Guaranteed To Arrive At All Members Of The Destination Group Or In The Same Order Relative To Other Datagrams.
The Membership Of A Host Group Is Dynamic; That Is, Hosts May Join And Leave Groups At Any Time. There Is No Restriction On The Location Or Number Of Members In A Host Group, But Membership In A Group May Be Restricted To Only Those Hosts Possessing A Private Access Key. A Host May Be A Member Of More Than One Group At A Time. A Host Need Not Be A Member Of A Group To Send Datagrams To It.
A Host Group May Be Permanent Or Transient. A Permanent Group Has A Well-Known, Administratively Assigned IP Address. It Is The Address, Not The Membership Of The Group, That Is Permanent; At Any Time A Permanent Group May Have Any Number Of Members, Even Zero. A Transient Group, On The Other Hand, Is Assigned An Address Dynamically When The Group Is Created, At The Request Of A Host. A Transient Group Ceases To Exist, And Its Address Becomes Eligible For Reassignment, When Its Membership Drops To Zero.
The Creation Of Transient Groups And The Maintenance Of Group Membership Information Is The Responsibility Of "Multicast Agents", Entities That Reside In Internet Gateways Or Other Special-Purpose Hosts. There Is At Least One Multicast Agent Directly Attached To Every Ip Network Or Sub Network That Supports Ip Multicasting. A Host Requests The Creation Of New Groups, And Joins Or Leaves Existing Groups, By Exchanging Messages With A Neighboring Agent.
Multicast Agents Are Also Responsible For Internetwork Delivery Of Multicast IP Datagrams. When Sending A Multicast IP Datagram, A Host Transmits It To A Local Network Multicast Address Which Identifies All Neighboring Members Of The Destination Host Group. If The Group Has Members On Other Networks, A Multicast Agent Becomes An Additional Recipient Of The Local Multicast And Relays The Datagram To Agents On Each Of Those Other Networks, Via The Internet Gateway System.
Finally, The Agents On The Other Networks Each Transmit The Datagram As A Local Multicast To Their Own Neighboring Members Of The Destination Group.
Level 2: Full Support For Ip Multicasting, Allows A Host To Create, Join And Leave Host Groups, As Well As Send Ip Datagrams To Host Groups. It Requires Implementation Of The Internet Group Management Protocol (IGMP) And Extension Of The Ip And Local Network Service Interfaces Within The Host. All Of The Following Sections Of This Memo Are Applicable To Level 2 Implementations.
Within The IP Module, The Membership Management Operations Are Supported By The Internet Group Management Protocol (IGMP). As Well As Having Messages Corresponding To Each Of The Operations Specified Above, IGMP Also Specifies A "Dead Man Timer" Procedure Whereby Hosts Periodically Confirm Their Memberships With The Multicast Agents.
The IP Module Must Maintain A Data Structure Listing The IP Addresses Of All Host Groups To Which The Host Currently Belongs, Along With Each Group's Loopback Policy, Access Key, And Timer Variables. This Data Structure Is Used By The IP Multicast Transmission Service To Know Which Outgoing Datagrams To Loop Back, And By The Reception Service To Know Which Incoming Datagrams To Accept. The Purpose Of IGMP And The Management Interface Operations Is To Maintain This Data Structure.
The Internet Group Management Protocol (IGMP) Is Used Between IP Hosts And Their Immediate Neighbor Multicast Agents To Support The Creation Of Transient Groups, The Addition And Deletion Of Members Of A Group, And The Periodic Confirmation Of Group Membership. IGMP Is An Asymmetric Protocol And Is Specified Here From The Point Of View Of A Host, Rather Than A Multicast Agent.
The Most Common Low-Level Protocol To Use Multicast Addressing Is User Datagram Protocol (UDP). By Its Nature, UDP Is Not Reliable—Messages May Be Lost Or Delivered Out Of Order. Reliable Multicast Protocols Such As Pragmatic General Multicast (PGM) Have Been Developed To Add Loss Detection And Retransmission On Top Of IP Multicast.
FEATURES OF IP MULTICAST :
The Primary Difference Between Multicast And Unicast Applications Lies In The Relationships Between Sender And Receiver. There Are Three General Categories Of Multicast Applications:
OTHER IMPORTANT ASPECTS OF IP MULTICASTING INCLUDE THE FOLLOWING :
Multicasting Is Not Connection Oriented. A Multicast Datagram Is Delivered To Destination Group Members With The Same “Best-Effort” Reliability As A Standard Unicast IP Datagram.
This Means That A Multicast Datagram Is Not Guaranteed To Reach All Members Of The Group, Or Arrive In The Same Order Relative To The Transmission Of Other Packets.
MULTICAST OVER IP NETWORKS
IP Multicast Is A Protocol For Transmitting IP Datagrams From One Source To Many Destinations In A Local Or Wide-Area Network Of Hosts Which Run The TCP/IP Suite Of Protocols. The Basic Facility Provided By The IP Protocol Is A Unicast Transmission Service: That Is, The Current Standard For IP Provides Only Unreliable Transmission Of Datagrams From A Single Source Host To A Single Destination Host.
IP Multicast Is A Bandwidth-Conserving Technology That Reduces Traffic By Delivering A Single Stream Of Information Simultaneously To Potentially Thousands Of Corporate Businesses And Homes.
Applications That Take Advantage Of Multicast Include Video Conferencing, Corporate Communications, Distance Learning, And Distribution Of Software, Stock Quotes, And News.
The Sending Host Inserts The Multicast Group Address Into The IP Destination Address Field Of The Packet, And IP Multicast Routers And Multilayer Switches Forward Incoming IP Multicast Packets Out All Interfaces That Lead To Members Of The Multicast Group.
Any Host, Regardless Of Whether It Is A Member Of A Group, Can Send To A Group. However, Only The Members Of A Group Receive The Message
ADVANTAGES OF IP MULTICASTING :
The Hope For Successful Deployment Of Multi-Media Applications Over The Internet Lies In The Popularity Of IP Multicasting And High Bandwidth Internet Connectivity To The Home.
IP Multicasting Solves The Problems Presented By Both Bandwidth-Consuming Point-To Point Communication And By Broadcasting Content From One-To-All.
IP Multicasting Reduces The Number Of Hops A Packet Uses To Get To Its Destination By Approximately 45% And Reaches Only Those Clients Who Have Requested The Multicast.
BENEFITS OF IP MULTICAST :
1. Optimizes Internet Performance - > Saves Bandwidth By Enhancing Network Efficiency In Distribution Of Data.
2. Supports Distributed Applications - > Enables Next Generation Multimedia Applications Such As Distance Learning And Videoconferencing On The Network In A Scalable, Reliable And Efficient Manner.
3. Reduces The Cost To Deploy Applications - > Reduces The Cost Of Network Resources By Conserving Bandwidth And Server And Network Processing.
4. Increases Productivity - > Opens New Ways To Work Through Collaboration And Conferencing, Saving Valuable Travel Time And Money. Multicasting Also Enables The Simultaneous Delivery Of Information To Many Receivers, Especially Beneficial For Delivering News And Financial Information.
5. Increases Competitiveness - > Increases Competitiveness By Extending Market Reach And Opening New Business And Revenue Opportunities. It Allows Both Enterprises And Isps To Offer New Services That Are Not Feasible Using Unicast Transport.
6. Eases Scalability - > Scales Well As The Number Of Participants And Collaborations Expand And Greatly Reduces The Load On The Sending Server.
7. Increased Application Availability - > Alleviates Network Congestion Caused By Existing Applications That Are Inefficiently Transmitting To Groups Of Recipients, Thus Allowing More Recipients Simultaneous Access To The Application.
PHASING :
Cisco Recommends A Phased Implementation Approach, As With Any New Technology Introduction. Begin With Low-Risk, Low-Bandwidth Applications And Establish A Test bed On A Selected Subnet With Management Visibility. Subsequently Expand Deployment To The Campus Intranet, Private Wan Links, And Finally To The Internet.
Unicast "Islands" Can Be Upgraded To Native Ip Multicast As Implementation Progresses. It Is Not Recommended To Try To Connect These Islands With Any Kind Of A Tunnel. There Is Little Or No Cost In Configuring Ip Multicast On A Router If There Is No Application Traffic To Forward. Therefore, Once You Understand How Multicast Works, It Is Best If You Deploy It Throughout Your Network.
COSTS :
In Unicast, As You Increase The Number Of Clients, You Linearly Increase The Network Bandwidth Used And Cost Since You Generate A Separate Copy Of Data To Each Recipient. The Extra Bandwidth Required May Be In Excess Of Some Of Your Communication Links. This Means Unicast Does Not Easily Scale To Large Numbers Of Recipients. Broadcast Transmissions Forward Data Packets To All Portions Of The Network Wasting Bandwidth When There Are Few Intended Recipients.
Multicast Transmission Sends A Single Multicast Packet Addressed To All Recipients. It Provides Efficient Communication And Transmission, Optimizes Performance, And Enables Truly Distributed Applications.
The Cost Of Deploying IP Multicast As A Cisco Customer Is Minimal. Since Cisco Routers And The Cisco IOS (Internetwork Operating System) Are Already Running, You Only Need To Turn On The Multicast Features In Your Software. IP Multicast Has Been Supported In IOS By The PIM Protocol Since 10.2. Inter Domain Multicast Is Efficiently Supported In 11.1CC And 12.0 Images. It Is Recommended That You Use 12.0 And Later Images If You Are Deploying PIM For The First Time. To Download The Most Current Image, Go To The Cisco CCO (Customer Connection Online) Web Page (Www.Cisco.Com/Cco).
Multicast Is Currently Available Across All Cisco IOS-Based Routing Platforms Including The Following:
TIME TO DEPLOY :
Once You Have Completed Your Planning And Read This Guide, The Time To Turn On The Commands And Provide The Service Should Be Minimal (About 10 Minutes Per Router). There Is One Global Command And One Interface Command That Must Be Configured On Each Router. In Addition, One Router Should Be Identified As The Rendezvous Point (RP) For Your Network, Which Requires Two Configuration Commands.
MULTICAST APPLICATIONS :
Multicast Is Is Useful Because It Allows The Construction Of Truly Distributed Applications, And Provides Important Performance Optimizations Over Unicast Transmission. There Are A Number Of Exciting New Applications For Real-Time Audio And Video Conferencing Which Can Make Good Use Of A Multicast Service When It Is Available. There Is Currently An Experimental Multicast Backbone, Called The MBONE, Which Is Exploring Applications Of IP Mulicast.
MULTICAST AND ATM NETWORKS :
Audio And Video Conferencing Applications Are Very Bandwidth-Intensive, And Require Extremely Low Latency From The Underlying Network Multicast Service. IP Can Be Run Over Increasingly Fast Links To Solve The Bandwidth Problem, But There Still Remains A Serious Latency Problem With IP Networks. Stated Simply, Because IP Can Support Very Large Packets, It Is Possible For A Small, Time-Critical Packet To Get "Stuck" Behind A Large Packet. To Help Redress This Problem, Lots Of Research Is Focusing On ATM Networks. One Aspect Of This Research Is Support For Multicast Over ATM Networks.
RELIABLE MULTICAST OVER IP :
The Basic Service Provided By IP Multicast Is An Unreliable Datagram Multicast Service. With An Unreliable Multicast Service, There Is No Guarantee That A Given Packet Reached All Intended Recipients Which Belong To The Multicast Group. This Is Useful For Certain Applications, Such As Those Developed For The MBONE, Which Are More Concerned With Performance Than Reliability.
However, A Reliable Multicast Protocol For IP Has Been Developed. This Protocol, Called Multicast Transport Protocol (MTP) Gives Application Programs Guarantees Of Atomicity And Reliability. The MTP Protocol Would Be Useful For Developing Applications Such As Distributed Databases Which Need To Be Certain That All Members Of A Multicast Group Agree On Which Packets Have Been Received.
MULTICAST GROUPS :
Individual Hosts Are Free To Join Or Leave A Multicast Group At Any Time. There Are No Restrictions On The Physical Location Or The Number Of Members In A Multicast Group. A Host May Be A Member Of More Than One Multicast Group At Any Given Time And Does Not Have To Belong To A Group To Send Messages To Members Of A Group.
GROUP MEMBERSHIP PROTOCOL :
A Group Membership Protocol Is Employed By Routers To Learn About The Presence Of Group Members On Their Directly Attached Subnet Works. When A Host Joins A Multicast Group, It Transmits A Group Membership Protocol Message For The Group(S) That It Wishes To Receive, And Sets Its IP Process And Network Interface Card To Receive Frames Addressed To The Multicast Group.
This Receiver-Initiated Join Process Has Excellent Scaling Properties Since, As The Multicast Group Increases In Size, It Becomes Ever More Likely That A New Group Member Will Be Able To Locate A Nearby Branch Of The Multicast Distribution Tree.
To Support IP Multicast, The Sending And Receiving Nodes, Intermediate Routers And The Network Infrastructure Between Them Must Be Multicast-Enabled. In Deploying IP Multicast As An End-To-End Solution.
YOU WILL NEED TO CONSIDER THE FOLLOWING AREAS :
ADDRESSING :
You Must Have An IP Multicast Address To Communicate With A Group Of Receivers Rather Than A Single Receiver, And You Must Have A Mechanism For Mapping This Address Onto MAC Layer Multicast Addresses Where They Exist. End Node Hosts Must Have Network Interface Cards (NIC) That Efficiently Filter For LAN Data Link Layer Addresses Which Are Mapped Back To The Network Layer IP Multicast Addresses.
IP Address Space Is Divided Into Four Sections-Classes A, B, C And D. The First Three Classes Are Used For Unicast Traffic. Class D Addresses Are Reserved For Multicast Traffic And Are Allocated Dynamically.
DYNAMIC HOST REGISTRATION :
The End Node Host Must Have Software Supporting Internet Group Management Protocol (IGMP-Defined In RFC 2236) To Communicate Requests To Join A Multicast Group And Receive Multicast Traffic. IGMP Specifies How The Host Should Inform The Network That It Is A Member Of A Particular Multicast Group.
MULTICAST ROUTING :
The Network Must Be Able To Build Packet Distribution Trees That Allow Sources To Send Packets To All Receivers. These Trees Ensure That Only One Copy Of A Packet Exists On Any Given Network. There Are Several Standards For Routing IP Multicast Traffic. The Cisco-Recommended Solution Is Protocol Independent Multicast (PIM), A Multicast Protocol That Can Be Used With All Unicast IP Routing Protocols.
MULTICAST APPLICATIONS :
End Node Hosts Must Have IP Multicast Application Software Such As Video Conferencing And Must Be Able To Support IP Multicast Transmission And Reception In The TCP/IP Protocol Stack.
IP MULTICAST GROUP ADDRESSING :
Unlike Class A, B, And C IP Addresses, The Last 28 Bits Of A Class D Address Have No Structure. The Multicast Group Address Is The Combination Of The High-Order 4 Bits Of 1110 And The Multicast Group ID. These Are Typically Written As Dotted-Decimal Numbers And Are In The Range 224.0.0.0 Through 239.255.255.255. Note That The High-Order Bits Are 1110. If The Bits In The First Octet Are 0, This Yields The 224 Portion Of The Address.
The Set Of Hosts That Responds To A Particular IP Multicast Address Is Called A Host Group. A Host Group Can Span Multiple Networks. Membership In A Host Group Is Dynamic-Hosts Can Join And Leave Host Groups. For A Discussion Of IP Multicast Registration, See The Section Called "Internet Group Management Protocol."
Some Multicast Group Addresses Are Assigned As Well-Known Addresses By The Internet Assigned Numbers Authority (IANA). These Multicast Group Addresses Are Called Permanent Host Groups And Are Similar In Concept To The Well-Known TCP And UDP Port Numbers. Address 224.0.0.1 Means "All Systems On This Subnet," And 224.0.0.2 Means "All Routers On This Subnet." Groups In The Range Of 224.0.0.Xxx Are Always Sent With A TTL Of 1. Groups In The Range Of 224.0.1.Xxx Are Reserved For Protocol Operations And Sent With Normal TTLs.
The IANA owns a block of Ethernet addresses that in hexadecimal is 00:00:5e. This is the high-order 24 bits of the Ethernet address, meaning that this block includes addresses in the range 00:00:5e:00:00:00 to 00:00:5e:ff:ff:ff. The IANA allocates half of this block for multicast addresses. Given that the first byte of any Ethernet address must be 01 to specify a multicast address, the Ethernet addresses corresponding to IP multicasting are in the range 01:00:5e:00:00:00 through 01:00:5e:7f:ff:ff.
Multicasting On A Single Physical Network Is Simple. The Sending Process Specifies A Destination IP Address That Is A Multicast Address, And The Device Driver Converts This To The Corresponding Ethernet Address And Sends It. The Receiving Processes Must Notify Their IP Layers That They Want To Receive Datagrams Destined For A Given Multicast Address, And The Device Driver Must Somehow Enable Reception Of These Multicast Frames. This Process Is Handled By Joining A Multicast Group.
When A Host Receives A Multicast Datagram, It Must Deliver A Copy To All The Processes That Belong To That Group. This Is Different From UDP Where A Single Process Receives An Incoming Unicast UDP Datagram. With Multicast, Multiple Processes On A Given Host Can Belong To The Same Multicast Group.
Complications Arise When Multicasting Is Extended Beyond A Single Physical Network And Multicast Packets Pass Through Routers. A Protocol Is Needed For Routers To Know If Any Hosts On A Given Physical Network Belong To A Given Multicast Group. The Internet Group Management Protocol (IGMP) Handles This Function.
PROTOCOLS AND APPLICATIONS :
IP Multicast Is Widely Deployed In Enterprises, Commercial Stock Exchanges, And Multimedia Content Delivery Networks. A Common Enterprise Use Of IP Multicast Is For IPTV Applications Such As Distance Learning And Televised Company Meetings.
Since Multicast Is A Different Transmission Mode From Unicast, Only Protocols Designed For Multicast Can Be Sensibly Used With Multicast.
Most Of The Existing Application Protocols That Use Multicast Run On Top Of The User Datagram Protocol (UDP). In Many Applications, The Real-Time Transport Protocol (RTP) Is Used For Framing Of Multimedia Content Over Multicast; The Resource Reservation Protocol (RSVP) May Be Used For Bandwidth Reservation In A Network Supporting Multicast Distribution.
On The Local Network, Multicast Delivery Is Controlled By IGMP (On Ipv4 Network) And MLD (On Ipv6 Network); Inside A Routing Domain, PIM Or MOSPF Are Used; Between Routing Domains, One Uses Inter-Domain Multicast Routing Protocols, Such As MBGP.
A Number Of Errors Can Happen If Packets Intended For Unicast Are Accidentally Sent To A Multicast Address; In Particular, Sending ICMP Packets To A Multicast Address Has Been Used In The Context Of Dos Attacks As A Way Of Achieving Packet Amplification.
IP MULTICAST PROTOCOLS
IP MULTICAST PROTOCOLS :
HOW IP MULTICAST PACKETS WORKS :
Many Multimedia Applications Involve Multiple Participants. IP Multicast Is Naturally Suitable For This Communication Paradigm.
INTERNET GROUP MANAGEMENT PROTOCOL (IGMP) IN MULTICASTING :
The INTERNET GROUP MANAGEMENT PROTOCOL (IGMP) Is A Communications Protocol Used By Hosts And Adjacent Routers On IP Networks To Establish Multicast Group Memberships.
IGMP Is Used On IPv4 Networks. Multicast Management On IPv6 Networks Is Handled By Multicast Listener Discovery (MLD) Which Uses Icmpv6 Messaging Contrary To IGMP's Bare IP Encapsulation.
IGMP Is An Integral Part Of The IP Multicast Specification. It Is Analogous To ICMP For Unicast Connections. IGMP Can Be Used For Online Streaming Video And Gaming, And IGMP Is Part Of The IP Layer And Uses IP Datagrams (Consisting Of A 20-Byte IP Header And An 8-Byte IGRP Message) To Transmit Information About Multicast Groups. IGMP Messages Are Specified In The IP Datagram With A Protocol Value Of 2.
NOTE :
The Operating System (OS) Of A Host Determines Which Version Of IGMP Is Supported By The Host. All Hosts That Participate In Multicast Transmission Must Be Enabled With IGMP. Hosts Can Randomly Join Or Leave The Related Multicast Groups, And The Number Of Hosts Is Not Limited.
Through IGMP, A Multicast Router Can Know Whether There Is A Member Of A Certain Group In The Network Segment To Which Each Interface Of The Router Is Connected. Hosts Store Information Only About The Multicast Groups They Join.
Multicast Routers Use IGMP Messages To Keep Track Of Group Membership On Each Of The Networks That Are Physically Attached To The Router. The Following Rules Apply:
Using Queries And Reports, A Multicast Router Keeps A Table Of Its Interfaces That Have At Least One Host In A Multicast Group. When The Router Receives A Multicast Datagram To Forward, It Forwards The Datagram (Using The Corresponding Multicast OSI Layer 2 Address) On Only Those Interfaces That Still Have Hosts With Processes Belonging To That Group. The Multicast Datagram Is Forwarded According To The Multicast Routing Protocol Running On The Router. IGMP Does Not Determine How Packets Are Forwarded.
The Time To Live (TTL) Field In The IP Header Of Reports And Queries Is Set To 1. A Multicast Datagram With A TTL Of 0 Is Restricted To The Same Host. By Default, A Multicast Datagram With A TTL Of 1 Is Restricted To The Same Subnet. Higher TTL Field Values Can Be Forwarded By The Router. By Increasing The TTL, An Application Can Perform An Expanding Ring Search For A Particular Server. The First Multicast Datagram Is Sent With A TTL Of 1. If No Response Is Received, A TTL Of 2 Is Tried, And Then 3, And So On. In This Way, The Application Locates The Server That Is Closest In Terms Of Hops.
The Special Range Of Addresses 224.0.0.0 Through 224.0.0.255 Is Intended For Applications That Never Need To Multicast Further Than One Hop. A Multicast Router Should Never Forward A Datagram With One Of These Addresses As The Destination, Regardless Of The TTL.
MULTICAST IN THE LAYER 2 SWITCHING ENVIRONMENT :
It Is Clear That There Is A Well-Defined Mechanism For Distributing IP Multicast Traffic In Cisco Routed Environments Thanks To The Class D Addressing Scheme, IGMP, And PIM, But This Mechanism Is Predicated On A Distributed Layer 3 Framework. With Distributed Layer 3 Devices, There Is A Variety Of Layer 3 Mechanisms To Control IP Multicast Transmissions. Simply Disabling Multicasting On A Particular Router Interface, For Example, Helps To Contain A Multicast Transmission. Similarly, Configuring A Particular Router Interface To Only Forward Packets With A TTL Above A Certain Number Can Also Help To Contain Multicast Transmission.
At Some Point, However, It Is Inevitable That The IP Multicast Traffic Will Traverse A Layer 2 Switch, Especially In Campus Environments. And, As We Learned Earlier, IP Multicast Traffic Maps To A Corresponding Layer 2 Multicast Address, Causing The Traffic To Be Delivered To All Ports Of A Layer 2 Switches.
CISCO GROUP MANAGEMENT PROTOCOL (CGMP):
Cisco Group Management Protocol (CGMP) Is A Cisco-Developed Protocol That Allows Catalyst Switches To Leverage IGMP Information On Cisco Routers To Make Layer 2 Forwarding Decisions. The Net Result Is That With CGMP, IP Multicast Traffic Is Delivered Only To Those Catalyst Switch Ports That Are Interested In The Traffic. All Other Ports That Have Not Explicitly Requested The Traffic Will Not Receive It.
IGMP CONFIGURATION EXAMPLE ;
No Configuration Is Required To Enable IGMP, Except To Enable Ip Multicast Routing (Ip Multicast-Routing). We Can Change The Version Of IGMP Running On A Particular Interface (By Default, It Is Version 2):
Switch(Config-If)# Ip Igmp Version 1
To View Which Multicast Groups The Router Is Aware Of:
Switch# Show Ip Igmp Groups
We Can Join A Router Interface To A Specific Multicast Group (Forcing The Router To Respond To ICMP Requests To This Multicast Group):
Switch(Config-If)# Ip Igmp Join-Group 226.1.5.10
We Can Also Simply Force A Router Interface To Always Forward The Traffic Of A Specific Multicast Group Out An Interface:
Switch(Config-If)# Ip Igmp Static-Group 226.1.5.10
We Can Also Restrict Which Multicast Groups A Host, Off Of A Particular Interface, Can Join:
Switch(Config)# Access-List 10 Permit 226.1.5.10
Switch(Config)# Access-List 10 Permit 226.1.5.11
Switch(Config-If)# Ip Igmp Access-Group 10
MULTICAST ROUTING PROTOCOLS :
There Are Two General Types Multicast Routing Protocols, Called Dense And Sparse Mode. Dense Mode Means That Every Multicast Router Receives Every Multicast Packet Unless And Until It Explicitly Says That It Doesn't Want It.
Sparse Mode, On The Other Hand, Means (Loosely) That No Router Will Receive A Multicast Group Unless It Explicitly Requests It. It Is Important To Note That End Devices, Whether Multicast Servers Or Group Members, Are Completely Unaware Of Which Mode Their Network Uses, Or Even Which Multicast Routing Protocol. Indeed It Is Possible To Run A Network Where The Routers Use A Combination Of These Modes.
There Are Many Examples Of Dense-Mode Protocols Such As:
There Are Fewer Sparse-Mode Protocols, With The Best Examples Being Protocol Independent Multicast Sparse Mode (PIM-SM) And Core-Based Trees (CBT).
There Are Two Other General Categories Of Multicast Routing Protocols:
The Difference Has To Do With The Interaction With An Underlying Routing Protocol, And Not With The Ability To Handle Non IP Multicast Traffic.
For Example:
MOSPF Is Protocol-Dependent Because It Relies On OSPF And Uses A Special OSPF LSA Type To Carry Information About Multicast Routing.
PIM And CBT, On The Other Hand, Both Use The Multicast Traffic Itself, Along With The Standard Unicast IP Routing Table And IGMP Requests To Build The Multicast Forwarding Trees. Since They Don't Care How The Router Got Its Unicast IP Routing Table, They Are Called Protocol Independent.
PROTOCOL INDEPENDENT MULTICAST (PIM) OVERVIEW:
PROTOCOL INDEPENDENT MULTICAST (PIM) Is A Collection Of Multicast Routing Protocols, Each Optimized For A Different Environment.
There Are Two Main PIM Protocols :
Typically, Either PIM Sparse Mode Or PIM Dense Mode Will Be Used Throughout A Multicast Domain.
However, They May Also Be Used Together Within A Single Domain, Using Sparse Mode For Some Groups And Dense Mode For Others.
This Mixed-Mode Configuration Is Known As Sparse-Dense Mode. Similarly, Bi-Directional PIM May Be Used On Its Own, Or It May Be Used In Conjunction With One Or Both Of PIM Sparse Mode And PIM Dense Mode.
All PIM Protocols Share A Common Control Message Format. PIM Control Messages Are Sent As Raw IP Datagrams (Protocol Number 103), Either Multicast To The Link-Local All Pim Routers Multicast Group, Or Unicast To A Specific Destination.
PIM SPARSE MODE :
PIM Sparse Mode (PIM-SM) Is A Multicast Routing Protocol Designed On The Assumption That Recipients For Any Particular Multicast Group Will Be Sparsely Distributed Throughout The Network. In Other Words, It Is Assumed That Most Subnets In The Network Will Not Want Any Given Multicast Packet. In Order To Receive Multicast Data, Routers Must Explicitly Tell Their Upstream Neighbors About Their Interest In Particular Groups And Sources. Routers Use PIM Join And Prune Messages To Join And Leave Multicast Distribution Trees.
PIM-SM By Default Uses Shared Trees, Which Are Multicast Distribution Trees Rooted At Some Selected Node (In PIM, This Router Is Called The Rendezvous Point, Or RP) And Used By All Sources Sending To The Multicast Group. To Send To The RP, Sources Must Encapsulate Data In PIM Control Messages And Send It By Unicast To The RP. This Is Done By The Source's Designated Router (DR), Which Is A Router On The Source's Local Network. A Single Dr Is Elected From All PIM Routers On A Network, So That Unnecessary Control Messages Are Not Sent.
One Of The Important Requirements Of PIM Sparse Mode, And BI-Directional PIM, Is The Ability To Discover The Address Of A RP For A Multicast Group Using A Shared Tree. Various RP Discovery Mechanisms Are Used, Including Static Configuration, Bootstrap Router, Auto-RP, Anycast RP, And Embedded RP.
PIM-SM Also Supports The Use Of Source-Based Trees, In Which A Separate Multicast Distribution Tree Is Built For Each Source Sending Data To A Multicast Group. Each Tree Is Rooted At A Router Adjacent To The Source, And Sources Send Data Directly To The Root Of The Tree. Source-Based Trees Enable The Use Of Source-Specific Multicast (SSM), Which Allows Hosts To Specify The Source From Which They Wish To Receive Data, As Well As The Multicast Group They Wish To Join. With SSM, A Host Identifies A Multicast Data Stream With A Source And Group Address Pair (S,G), Rather Than By Group Address Alone (*,G).
PIM-SM MAY USE SOURCE-BASED TREES IN THE FOLLOWING CIRCUMSTANCES.
PIM-SM Is A Soft-State Protocol. That Is, All State Is Timed-Out A While After Receiving The Control Message That Instantiated It. To Keep The State Alive, All Pim Join Messages Are Periodically Retransmitted.
Version 1 Of PIM-SM Was Created In 1995, But Was Never Standardized By The Ietf. It Is Now Considered Obsolete, Though It Is Still Supported By Cisco And Juniper Routers. Version 2 Of PIM-SM Was Standardized In Rfc 2117 (In 1997) And Updated By Rfc 2362 (In 1998). Version 2 Is Significantly Different From And Incompatible With Version 1. However, There Were A Number Of Problems With Rfc 2362, And A New Specification Of Pim-Sm Version 2 Is Currently Being Produced By The Ietf. There Have Been Many Implementations Of PIM-SM And It Is Widely Used.
PIM DENSE MODE :
PIM Dense Mode (PIM-DM) Is A Multicast Routing Protocol Designed With The Opposite Assumption To PIM-SM, Namely That The Receivers For Any Multicast Group Are Distributed Densely Throughout The Network. That Is, It Is Assumed That Most (Or At Least Many) Subnets In The Network Will Want Any Given Multicast Packet. Multicast Data Is Initially Sent To All Hosts In The Network. Routers That Do Not Have Any Interested Hosts Then Send PIM Prune Messages To Remove Themselves From The Tree.
When A Source First Starts Sending Data, Each Router On The Source's Lan Receives The Data And Forwards It To All Its PIM Neighbors And To All Links With Directly Attached Receivers For The Data. Each Router That Receives A Forwarded Packet Also Forwards It Likewise, But Only After Checking That The Packet Arrived On Its Upstream Interface. If Not, The Packet Is Dropped. This Mechanism Prevents Forwarding Loops From Occurring. In This Way, The Data Is Flooded To All Parts Of The Network.
Some Routers Will Have No Need Of The Data, Either For Directly Connected Receivers Or For Other PIM Neighbors. These Routers Respond To Receipt Of The Data By Sending A PIM Prune Message Upstream, Which Instantiates Prune State In The Upstream Router, Causing It To Stop Forwarding The Data To Its Downstream Neighbor. In Turn, This May Cause The Upstream Router To Have No Need Of The Data, Triggering It To Send A Prune Message To Its Upstream Neighbor. This 'Broadcast And Prune' Behavior Means That Eventually The Data Is Only Sent To Those Parts Of The Network That Require It.
Eventually, The Prune State At Each Router Will Time Out, And Data Will Begin To Flow Back Into The Parts Of The Network That Were Previously Pruned. This Will Trigger Further Prune Messages To Be Sent, And The Prune State Will Be Instantiated Once More.
PIM-DM Only Uses Source-Based Trees. As A Result, It Does Not Use RPS, Which Makes It Simpler Than PIM-SM To Implement And Deploy. It Is An Efficient Protocol When Most Receivers Are Interested In The Multicast Data, But Does Not Scale Well Across Larger Domains In Which Most Receivers Are Not Interested In The Data.
The Development Of PIM-DM Has Paralleled That Of PIM-SM. Version 1 Was Created In 1995, But Was Never Standardized. It Is Now Considered Obsolete, Though It Is Still Supported By Cisco And Juniper Routers. Version 2 Of PIM-DM Is Currently Being Standardized By The Ietf. As With PIM-SM, Version 2 Of PIM-DM Is Significantly Different From And Incompatible With Version 1. Pim Dense Mode (PIM DM) Is Less Common Than Pim-Sm, And Is Mostly Used For Individual Small Domains.
BI-DIRECTIONAL PIM:
Bi-Directional PIM (BIDIR-PIM) Is A Third PIM Protocol, Based On PIM-SM. The Main Way BIDIR-PIM Differs From PIM-SM Is In The Method Used To Send Data From A Source To The RP. Whereas In PIM-SM Data Is Sent Using Either Encapsulation Or A Source-Based Tree, In BIDIR-PIM The Data Flows To The RP Along The Shared Tree, Which Is Bi-Directional - Data Flows In Both Directions Along Any Given Branch.
BIDIR-PIM'S MAJOR DIFFERENCES FROM PIM-SM ARE AS FOLLOWS:
The Main Advantage Of BIDIR-PIM Is That It Scales Very Well When There Are Many Sources For Each Group. However, The Lack Of Source-Based Trees Means That Traffic Is Forced To Remain On The Possibly Inefficient Shared Tree.
There Have Been Two Proposed Specifications For BI-Directional PIM. The First Was Described In Draft-Farinacci-BIDIR-PIM, Which Dates From 1999. The Protocol Described Here Is A Replacement, Simpler Than And With Some Improvements Over The First. It Is Described In Draft-Ietf-PIM-BIDIR.
MIXED-MODE PIM CONFIGURATIONS :
Typically, PIM-SM, PIM-DM Or BIDIR-PIM Would Be Used Alone Throughout A Multicast Domain. However It Is Possible To Use A Combination Of The Three By Distributing Multicast Groups Between The Different Protocols. Each Group Must Operate In Either Sparse, Dense Or Bi-Directional Mode; It Is Not Possible To Use A Single Group In More Than One Mode At Once. Given Such A Division, The Protocols Coexist Largely Independent Of One Another.
ss The One Way In Which The Protocols Interact Is That The Same PIM Hello Protocol Is Used By Each, And Is Only Run Once On Each Link. The Information Learned From The Hello Message Exchange Must Be Shared Among The Three Routing Protocols.
The Method Used To Distribute Groups Between The Three Protocols Is Outside The Scope Of The PIM Protocols And Is A Matter Of Local Configuration.
Note: That It Is Important That Every Router In The Domain Has The Same Assignment Of Groups To Protocols. The Following Techniques Are Used.
CONFIGURING MANUAL PIMv1 :
Two Versions Of PIM Exist (PIMv1 And PIMv2), Though Both Are Very Similar. PIM Must Be Enabled On Each Participating Interface In The Multicast Tree.
To Enable PIM And Specify Its Mode On An Interface: Switch(Config)# Interface Fa0/10
Switch(Config-If)# No Switchport
Switch(Config-If)# Ip Pim Dense-Mode
Switch(Config-If)# Ip Pim Sparse-Mode
Switch(Config-If)# Ip Pim Sparse-Dense-Mode
When Utilizing PIM-SM, We Must Configure A Rendezvous Point (RP). RP’s Can Be Identified Manually, Or Dynamically Chosen Using A Process Called Auto-RP (Cisco-Proprietary). To Manually Specify An RP On A Router:
Switch(Config)# Ip Pim Rp-Address 192.168.1.1
The Above Command Must Be Configured On Every Router In The Multicast Tree, Including The RP Itself.
To Restrict The RP To A Specific Set Of Multicast Groups:
Switch(Config)# Access-List 10 Permit 226.10.10.1
Switch(Config)# Access-List 10 Permit 226.10.10.2
Switch(Config)# Ip Pim Rp-Address 192.168.1.1 10
The First Two Commands Create An Access-List 10 Specifying The Multicast Groups This RP Will Support. The Third Command Identifies The RP, And Applies Access-List 10 To The RP.
CONFIGURING DYNAMIC PIMv1:
When Using Cisco’s Auto-RP, One Router Is Designated As A Mapping Agent. To Configure A Router As A Mapping Agent:
Switch(Config)# Ip Pim Send-Rp-Discovery Scope 10
The 10 Parameter In The Above Command Is A TTL (Time To Live) Setting, Indicating That This Router Will Serve As A Mapping Agent For Up To 10 Hops Away.
Mapping Agents Listen For Candidate RP’s Over Multicast Address 224.0.1.39 (Cisco RP Announce). To Configure A Router As A Candidate RP:
Switch(Config)# Access-List 10 Permit 226.10.10.1
Switch(Config)# Access-List 10 Permit 226.10.10.2
Switch(Config)# Ip Pim Send-Rp-Announce Fa0/10 Scope 4 Group-List 10
The First Two Commands Create An Access-List 10 Specifying The Multicast Groups This RP Will Support.
The Third Command Identifies This Router As A Candidate RP For The Multicast Groups Specified In Group-List 10. This RP’s Address Will Be Based On The IP Address Configured On Fa0/10.
The Scope 4 Parameter Indicates The Maximum Number Of Hops This Router Will Advertise It Self For.
The Above Commands Essentially Create A “Mapping” Of Specific RP’s To Specific Multicast Groups. Once A Mapping Agent Learns Of These Mappings From Candidate Rps, It Sends The Information To All PIM Routers Over Multicast Address 224.0.1.40 (Cisco RP Discovery).
CONFIGURING DYNAMIC PIMv2:
Configuring PIMv2 Is Very Similar To PIMv1, Except That PIMv2 Is A Standards-Based Protocol. Also, There Are Terminology Differences. Instead Of Mapping Agents, Pimv2 Uses Bootstrap Routers (BSR), Which Performs The Same Function.
To Configure A Router As A BSR:
Switch(Config)# Ip Pim Bsr-Candidate Fa0/10
To Configure Candidate RP’s In Pimv2:
Switch(Config)# Access-List 10 Permit 226.10.10.1
Switch(Config)# Access-List 10 Permit 226.10.10.2
Switch(Config)# Ip Pim Rp-Candidate Fa0/10 4 Group-List 10
The First Two Commands Create An Access-List 10 Specifying The Multicast Groups This RP Will Support.
The Third Command Identifies This Router As A Candidate RP For The Multicast Groups Specified In Group-List 10. This RP’s Address Will Be Based On The IP Address Configured On Fa0/10.
The 4 Parameter Indicates The Maximum Number Of Hops This Router Will Advertise It Self For.
With PIMv2, We Can Create Border Routers To Prevent PIM Advertisements (From The BSR Or Candidate Rps) From Passing A Specific Point.
To Configure A Router As A PIM Border Router:
Switch(Config)# Ip Pim Border
MULTICASTS AND LAYER 2 SWITCHES :
Up To This Point, We’ve Discussed How Multicasts Interact With Routers Or Multilayer Switches.
By Default, A Layer 2 Switch Will Forward A Multicast Out All Ports, Excluding The Port It Received The Multicast On. To Eliminate The Need Of “Flooding” Multicast Traffic, Two Mechanisms Have Been Developed For Layer 2 Switches:
IGMP Snooping Allows A Layer 2 Switch To “Learn” The Multicast MAC Address Of Multicast Groups. It Does This By Eavesdropping On IGMP Membership Reports Sent From Multicast Hosts To PIM Routers. The Layer 2 Switch Then Adds A Multicast MAC Entry In The CAM For The Specific Port That Needs The Multicast Traffic.
IGMP Snooping Is Enabled By Default On The Catalyst 2950 And 3550. If Disabled, It Can Be Enabled With The Following Command:
Switch(Config)# IP Igmp Snooping
If A Layer 2 Switch Does Not Support IGMP Snooping, Cisco Group Membership Protocol (CGMP) Can Be Used. Three Guesses As To Whether This Is Cisco-Proprietary Or Not.
Instead Of The Layer 2 Switch “Snooping” The IGMP Membership Reports, CGMP Allows The PIM Router To Actually Inform The Layer 2 Switch Of The Multicast MAC Address, And The MAC Of The Host Joining The Group. The Layer 2 Switch Can Then Add This Information To The CAM.
CGMP Must Be Configured On The PIM Router (Or Multilayer Switch). It Is Disabled By Default On All PIM Routers. To Enable CGMP:
Switch(Config-If)# Ip Cgmp
No Configuration Needs To Occur On The Layer 2 Switch.
TROUBLESHOOTING MULTICASTING :
To View The Multicast Routing Table :
Switch# Show Ip Mroute
To View IGMP Groups And Current Members : Switch# Show Ip Igmp Groups
To View The IGMP Snooping Status :
Switch# Show Ip Igmp Snooping
To View PIM “Neighbors” :
Switch# Show Ip Pim Neighbor
To View PIM Rps :
Switch# Show Ip Pim Rp
To View PIM RP-To-Group Mappings :
Switch# Show Ip Pim Rp Mapping
To View The Status Of Pimv1 Auto-RP :
Switch# Show Ip Pim Autorp
To View Pimv2 Bsrs:
Switch# Show Ip Pim Bsr-Router
We Can Also Debug Multicasting Protocols :
Switch# Debug Ip Igmp
Switch# Debug Ip Pim
FIRST TO ENABLE MULTICAST ROUTING ON A ROUTER :
1. Issue The Ip Multicast-Routing Command Globally On The Router.
2. Enable PIM Sparse Or Dense Mode, By Issuing The Ip Pim Sparse-Dense-Mode Command On All The Multicast Interfaces.
3. In The Case Of Sparse Mode, A Rendezvous Point (RP) Is To Be Configured. These Are Options To Configure The RP In PIM Sparse Mode Multicast Networks:
If An RP Is Not Known, Then The Group Defaults To Dense Mode. RP Information Is Conveyed To The Routers By The Auto-RP Mechanism, Which Uses Two Well Known Groups: 224.0.1.39 And 224.0.1.40. The Advantage Of This Is That Any Change To The RP Designation Needs To Be Configured Only On The RP Routers, And Not On The Leaf Routers, As In The Static Configuration.
MULTICAST WITH PIM-DM:
In A Small Network With Few Routers And Relatively Light Multicast Application Bandwidth Requirements, The Easiest Way To Implement Multicast Routing Is To Use PIM-DM. This Example Shows The Configurations For Two Routers That Are Connected Through A Serial Connection, Both With Fastethernet Interfaces To Represent The LAN Connections. It Is Important To Enable Multicast Routing On All Interfaces That Connect To Other Multicast-Enabled Routers Or To Multicast User Or Server Segments.
THE FIRST ROUTER LOOKS LIKE THIS :
Router1#Configure Terminal
Enter Configuration Commands, One Per Line. End With CNTL/Z.
Router1(Config)#Ip Multicast-Routing
Router1(Config)#Interface Fastethernet0/0
Router1(Config-If)#Ip Address 192.168.1.1 255.255.255.0
Router1(Config-If)#Ip Pim Dense-Mode
Router1(Config-If)#Exit
Router1(Config)#Interface Serial1/0
Router1(Config-If)#Ip Address 192.168.2.5 255.255.255.252
Router1(Config-If)#Ip Pim Dense-Mode
Router1(Config-If)#End
Router1#
AND THE SECOND ROUTER LOOKS LIKE THIS:
Router2#Configure Terminal
Enter Configuration Commands, One Per Line. End With CNTL/Z.
Router2(Config)#Ip Multicast-Routing
Router2(Config)#Interface Fastethernet0/0
Router2(Config-If)#Ip Address 192.168.3.1 255.255.255.0
Router2(Config-If)#Ip Pim Dense-Mode
Router2(Config-If)#Exit
Router2(Config)#Interface Serial1/0
Router2(Config-If)#Ip Address 192.168.2.6 255.255.255.252
Router2(Config-If)#Ip Pim Dense-Mode
Router2(Config-If)#End
Router2#
DISCUSSION :
With This Simple Configuration, You Get All Of The Basic Multicast Functionality. The Routers Will Distribute Multicast Packets Properly, They Will Listen For End Devices To Join And Leave Groups With IGMP (Version 1, 2, Or 3), And They Will Update One Another With Information About What Multicast Groups Are Currently In Use As Well As Where The Servers And Group Members Are. For Many Types Of Multicast Applications, This Is All You Need. But It Is Important To Remember That The PIM-DM Protocol Is Only Appropriate For Certain Types Of Networks With Relatively Specific Multicast Routing Requirements.
First, PIM-DM Works Best In Relatively Small Networks With No More Than A Few Hops Between The Sender And The Most Remote Receiver. Second, The Number Of Multicast Servers Should Be Small, And The Receivers Should Be Scattered Throughout The Network In Relatively Large Numbers. And Third, Because PIM-DM Uses The Multicast Traffic Itself To Gather Information About Where The Servers Are, It Needs A Steady Flow Of Traffic. In Particular, It's A Bad Idea To Use PIM-DM With Multicast Applications That Can Pause More Than Three Minutes Between Packets Because The Routers Will Flush The Routing Information Out Of Their Tables And Have To Rebuild These Tables When The Next Packet Is Received.
If One Or More Of These Conditions Is Not True For Any Of Your Multicast Applications Then You Should Probably Consider One Of The Other Routing Protocols, Particularly PIM-SM.
One Final Point To Consider In Any Sort Of Routing Is How The Router Will Switch The Packets. As We Discussed In, You Want To Avoid Process Switching Anything Unless It's Absolutely Necessary. Fortunately, Multicast Packets Are Fast Switched By Default. However, In Many Configurations, It Is Customary To Disable Multicast Fast Switching. So It Is A Good Idea To Look At Your Router Configurations And Make Sure That You Don't Have Any Multicast Interfaces That Include The Statement No Ip Mroute-Cache. If Any Interfaces Do Have This Command, Then You Should Re-Enable The Preferred Default Fast Switching Behavior By Using The Interface Level Command Ip Mroute-Cache. This Is True Regardless Of Which Multicast Routing Protocol You Use.
MULTICAST TRAFFIC WITH PIM-SM AND BSR:
We've Already Discussed How PIM-SM Requires A Rendezvous Point (RP) Router. The Most Reliable Way To Achieve This Is To Have The Network Automatically Discover The RP. This Way, If The RP Fails, Another Can Automatically Take Over For It. We Recommend Using The Bootstrap Router (BSR) Mechanism To Dynamically Distribute RP Information.
There Are Two Different Types Of Router Configurations For This Type Of Network. Most Of The Routers Will Support End Devices, Both Group Members And Servers. But A Small Number Are Configured To Act As Candidate RP's And Candidate Bootstrap Routers (BSR). In The Example, We Show The RP And BSR Configuration In The Same Router. This Isn't Actually Necessary, But It Is Convenient.
Router1 Is An Example Of A "Normal" Multicast Router. It Forwards Multicasts, Takes Part In PIM-SM, And May Support Group Members Or Multicast Servers As Required:
Router1#Configure Terminal
Enter Configuration Commands, One Per Line. End With CNTL/Z.
Router1(Config)#Ip Multicast-Routing
Router1(Config)#Ip Pim Rp-Address 192.168.15.5
Router1(Config)#Interface Fastethernet0/0
Router1(Config-If)#Ip Address 192.168.1.1 255.255.255.0
Router1(Config-If)#Ip Pim Sparse-Mode
Router1(Config-If)#Interface Serial1/0
Router1(Config-If)#Ip Address 192.168.2.5 255.255.255.252
Router1(Config-If)#Ip Pim Sparse-Mode
Router1(Config-If)#End
Router1#
Router RP1 Is One Of The Candidate RP's, And It Is Also Configured As A Candidate BSR. It May Also Support Multicast Group Members Or Servers, If Required. It Is A Good Idea To Configure Two Or More Routers As Rps And Bsrs In Each Multicast Domain Like This To Provide Redundancy:
Router-RP1#Configure Terminal
Enter Configuration Commands, One Per Line. End With CNTL/Z.
Router-RP1(Config)#Ip Multicast-Routing
Router-RP1(Config)#Interface Loopback0
Router-RP1(Config-If)#Ip Address 192.168.12.1 255.255.255.255
Router-RP1(Config-If)# Ip Pim Sparse-Mode
Router-RP1(Config-If)#Exit
Router-RP1(Config)#Interface Fastethernet0/0
Router-RP1(Config-If)#Ip Address 192.168.1.1 255.255.255.0
Router-RP1(Config-If)#Ip Pim Sparse-Mode
Router-RP1(Config-If)#Exit
Router-RP1(Config)#Interface Serial1/0
Router-RP1(Config-If)#Ip Address 192.168.2.5 255.255.255.252
Router-RP1(Config-If)#Ip Pim Sparse-Mode
Router-RP1(Config-If)#Exit
Router-RP1(Config)#Ip Pim Rp-Address 192.168.12.1 15
Router-RP1(Config)#Ip Pim Rp-Candidate Loopback0 Group-List 15
Router-RP1(Config)#Ip Pim Bsr-Candidate Loopback0 1
Router-RP1(Config)#Access-List 15 Permit 239.5.5.0 0.0.0.255
Router-RP1(Config)#Access-List 15 Deny Any
Router-RP1(Config)#End
Router-RP1#
DISCUSSION :
In Larger Networks, Particularly Networks With WAN Links, The PIM-DM Approach Of Forwarding All Multicasts To All Routers Until They Explicitly Opt Out Of The Group Tends To Be Inefficient With Network Resources. So It Is Useful To Configure A Sparse Mode Multicast Routing Protocol Such As PIM-SM. The Basic Configuration For Most Of The Routers Is Similar To What We Did In First Lab Example. The Difference Is That PIM-SM Allows You To Set Up A Rendezvous Point (RP) Router To Act As The Root Of The Multicast Shortest Path Trees (SPT).
There Are Two Ways To Configure The Routers To Use An RP. The Conceptually Simpler Method Is To Explicitly Define The RP In The Other Routers, Using The Ip Pim Rp-Address Command, As Shown In The Configuration For Router1 Above:
Router1(Config)#Ip Pim Rp-Address 192.168.15.5
This Method Has Two Important Administrative Problems. If You Ever Want To Change The RP To Another Router, You Have To Change It Separately In Every Router, And It Lacks The Ability To Automatically Switch To A Backup RP In Case Of Failure. However, It Is Statically Configured In The Example For A Different Reason, Which We Will Explain In A Moment.
The Alternative Is To Configure The Network To Discover The RP Dynamically, Which Is Also Shown In The Solution. This Is Preferable In Most Cases. In Fact, There Are Two Ways To Accomplish This. One Uses A Cisco Proprietary Method Called Auto-RP, And The Other Called The Bootstrap Router Method, Which Is Part Of The Open PIM-SM Standard Defined In RFC 4601. This Recipe Shows The Bootstrap Router Method, Which We Generally Prefer For Interoperability Reasons. The Auto-RP, Which Will Only Work In An All-Cisco Network, Is Discussed In 3rd Example.
In Router-RP1, There Are Two Important Commands That Define How It Will Advertise Itself. The First Is Ip Pim Rp-Candidate, Which Allows The Router To Advertise Itself As A Possible RP:
Router-RP1(Config)#Ip Pim Rp-Candidate Loopback0 Group-List 15
There Are Two Modifiers On This Command. The First, Loopback0, Tells The Network To Use The Loopback Interface As The RP Address. If There Are Several Candidate RP Routers, The PIM-SM Algorithm Prefers The One With The Highest IP Address. So Be Careful If You Want A Particular Router To Be The Default.
This Command Also Includes The Group-List Tag. In This Case, It Associates The RP Functions For This Router With Access-List Number 15, Which Specifies That This Router Will Be RP For Any Multicast Group Between 239.5.5.0 And 239.5.5.255. You Can Specify That The RP Router Can Support Any Set Of Multicast Group Addresses. If You Want It To Support All Multicast Groups, Then Simply Eliminate The Group-List Keyword As Follows:
Router-RP1(Config)#Ip Pim Rp-Candidate Loopback0
Using The Group-List Option Is Most Useful If You Have An Extremely Large Number Of Multicast Groups To Distribute And The Load Is Too Heavy For One Router. Some Network Administrators May Also Decide To Use A Different RP For A Few Specific Local Groups For Ease Of Management As Well. But In Most Networks There Is Relatively Little Benefit To Breaking Up The RP Functions By Group This Way. We Have Just Included The Option Here To Show How It Works In Case You Do Need It. If You Decide To Break Up The RP Responsibilities Among Many Routers, Be Careful To Ensure That All Possible Groups Have An RP Available.
The Next Important Command In Router-RP1 Is Ip Pim Bsr-Candidate:
Router-RP1(Config)#Ip Pim Bsr-Candidate Loopback0 1
This Allows The Router To Act As A Bootstrap Router (BSR). Bsrs Are Responsible For Distributing Information About All Of The Known Candidate Rps Throughout The Network. In This Example, We Use The Loopback Interface To Define The IP Address That This Router Will Use When Advertising Itself As A BSR Candidate. The Protocol Uses This Address In The Election Process To Select The BSR From All Of The Possible Candidates. This Command Also Accepts A Priority Keyword That You Can Use To Help Bias The Election Process To Prefer One BSR Candidate.
The Last Number In The Example's Bsr-Candidate Command, 1, Is A Hash Value That Helps To Select Different RP's For Different Ranges Of Multicast Group Addresses. Because The Example Uses A Range Of Addresses From 239.5.5.0 To 239.5.5.255, We Could Have Configured The Candidate BSR To Allow Rps To Control A Similar Range Of Multicast Addresses. There Are 8 Bits Of Freedom In This Range, Which Would Give A Hash Value Of 8. If You're Not Sure What To Use Here, It Is Safest To Just Use A Value Of 1 Bit. This Will Allow The Network To Select The Best Rps On A Group-By-Group Basis. In Fact This Option Is Really Only Useful When You Have Several Rps, Each Supporting Different Ranges Of Multicast Group Addresses. When In Doubt, It Is Safe To Use A Value Of 1. There Is A Slight Performance Advantage To Using Larger Hash Values, However.
We Note In Passing That The RP Router's Configuration In Our Example Also Includes A Static Rp-Address Configuration Command, Pointing To Itself And Including The Same Access-List Defining The Multicast Groups Served By This RP:
Router-RP1(Config)#Ip Pim Rp-Address 192.168.12.1 15
This Command Is Completely Redundant In Most IOS Releases, But Appears To Have Suddenly Become Necessary In IOS Version 12.3, As It Ensures That The RP Router Is Aware That It Is The RP For These Groups. We Don't Understand Why This Change Was Made, As The Ip Pim Rp-Candidate Command Would Appear To Perform The Same Function. In Any Case, It Doesn't Hurt Anything To Include This Command, So We Recommend Including It.
We Have One Final Comment On The Configuration Of The Candidate RP/BSR Router. Since We Are Using The Loopback Interface As The Source For Both RP And BSR Functions, It Is Important That This Interface Be Configured For PIM-SM. This Seems Counter-Intuitive Because A Loopback Interface Can't Have Any Neighbors By Definition. But The BSR Function In Particular Will Not Work Properly Without This Configuration, Because We Use The Loopback Interface To Define This Router As A BSR Candidate.
We Use The Loopback Interface For This Purpose Because It Can't Go Down. If There Is Any Path To This Router, It Will Retain The RP Role. This May Not Always Be Desirable, Of Course. If This Is A WAN Router, For Example, We Certainly Wouldn't Want All Multicast Traffic To Have To Cross The WAN Twice Just Because An Ethernet Interface Went Down. In Such Cases, It Would Be Better To Use The Ethernet Port For The BSR And RP Addresses.
In General, It Is A Good Practice To Set Up Several BSR's To Spread The Word About Several Rps With Overlapping Group Ranges For Redundancy. This Gives A Much More Reliable Network. And, If It Ever Happens That No Rps Are Available, The Router Will Revert To The Statically Configured RP Address, Which We Have Configured Using The Following Command:
Router1(Config)#Ip Pim Rp-Address 192.168.15.5
Note That The Address Specified Is Not The Same As Routerrp1. The Static RP Value Is Only Needed When None Of The Usual Rps Is Available. So A Good Choice For This Last Resort RP Would Be One Of Your Central Core Routers. Naturally, You Must Make Sure That The Router You Specify Is Configured To Act As An RP.
If You Are Going To Use This BSR Method For RP Discovery, You Need To Take Certain Network Design Precautions. Sometimes You Will Want An RP To Serve A Particular Section Of The Network. In Smaller Networks, You May Have Rps Serve The Entire Physical Expanse Of The Network, But With Different Rps Serving Different Multicast Groups. However, In Larger Networks, Or When Two Or More Networks Adjoin, It Is Necessary To Limit The Region Of The Network Served By Any RP.
The BSR Works By Sending Out Information To All Of The Adjacent PIM Routers. These Routers Record All Of The Information, And Then Relay The Same Information To All Of The Adjacent Routers, Except The One Where This Information Came From In The First Place. Because This Process Is Repeated At Each Hop, It Could Expand Indefinitely. In Fact, The Process Is Not Even Bounded By The Usual IP TTL Limit Of 255 Hops Because A New Packet Is Created At Each Hop. So It Is Possible To Have The Network Choose An RP That Some Devices Cannot Reach, Particularly If You Use TTL To Control Multicast Scope.
To Define Distinct Regions Of A Network Served By Different Groups Of Rps, First You Need To Decide Where The Boundaries Of These Regions Will Be, And Then You Configure The Routers Along The Boundary So That They Will Neither Transmit Nor Receive Any BSR Information On Those Interfaces:
Router-Border1#Configure Terminal
Enter Configuration Commands, One Per Line. End With CNTL/Z.
Router-Border1(Config)#Ip Multicast-Routing
Router-Border1(Config-If)#Interface Fastethernet0/0
Router-Border1(Config-If)#Ip Pim Sparse-Mode
Router-Border1(Config-If)#Ip Pim Border
Router-Border1(Config-If)#End
Router-Border1#
Note That The Ip Pim Border Command Affects Only The Exchange Of BSR Information. Multicast Traffic Can Still Flow Across The Interface, And PIM Will Still Form SPT Trees That Cross The Interface.
MULTICAST TRAFFIC WITH PIM-SM AND AUTO-RP:
His Recipe Accomplishes The Same Basic Tasks As Example 2, But Using A Different Method. If You Are Unfamiliar With PIM-SM, Please Read That Recipe First. There Are Two Different Types Of Router Configurations For Auto-RP Configuration, Just As There Are For BSR. Router1 Represents A Regular Multicast-Enabled Router Anywhere In The Network. This Router Supports End Devices As Group Members Or Servers, As Well As Routing Multicast Traffic For Other Routers:
Router1#Configure Terminal
Enter Configuration Commands, One Per Line. End With CNTL/Z.
Router1(Config)#Ip Multicast-Routing
Router1(Config)#Ip Pim Rp-Address 192.168.15.5
Router1(Config)#Interface Fastethernet0/0
Router1(Config-If)#Ip Address 192.168.1.1 255.255.255.0
Router1(Config-If)#Ip Pim Sparse-Dense-Mode
Router1(Config-If)#Exit
Router1(Config)#Interface Serial1/0
Router1(Config-If)#Ip Address 192.168.2.5 255.255.255.252
Router1(Config-If)#Ip Pim Sparse-Dense-Mode
Router1(Config-If)#End
Router1#
The Second Type Of Configuration Is For A Candidate RP Router, Called Router RP1. This Router May Also Support Group Members Or Servers. As In The Previous Recipe, It Is A Good Idea To Configure Two Or More Routers In Each Multicast Domain Like This To Provide Redundancy:
Router-RP1#Configure Terminal
Enter Configuration Commands, One Per Line. End With CNTL/Z.
Router-RP1(Config)#Ip Multicast-Routing
Router-RP1(Config)#Interface Loopback0
Router-RP1(Config-If)#Ip Address 192.168.12.1 255.255.255.255
Router-RP1(Config-If)#Ip Pim Sparse-Dense-Mode
Router-RP1(Config-If)#Exit
Router-RP1(Config)#Interface Fastethernet0/0
Router-RP1(Config-If)#Ip Address 192.168.1.1 255.255.255.0
Router-RP1(Config-If)#Ip Pim Sparse-Dense-Mode
Router-RP1(Config-If)#Exit
Router-RP1(Config)#Interface Serial1/0
Router-RP1(Config-If)#Ip Address 192.168.2.5 255.255.255.252
Router-RP1(Config-If)#Ip Pim Sparse-Dense-Mode
Router-RP1(Config-If)#Exit
Router-RP1(Config)#Ip Pim Send-Rp-Announce Loopback0 Scope 16 Group-List 15
Router-RP1(Config)#Ip Pim Send-Rp-Discovery Scope 16
Router-RP1(Config)#Access-List 15 Permit 239.5.5.0 0.0.0.255
Router-RP1(Config)#Access-List 15 Deny Any
Router-RP1(Config)#End
Router-RP1#
DISCUSSION:
Discussed One Way Of Discovering The Rps In A PIM-SM Network Using The Bootstrap Router (BSR) Method. This Recipe Shows An Alternative Method. The BSR Method Requires Version 2 Of The PIM-SM Protocol. Cisco Started Supporting This In IOS 11.3T. So If You Have Earlier IOS Versions In Your Multicast Network, You Will Need Auto-RP, Perhaps Used In Parallel With BSR. As Long As Both Systems Select The Same Rps, There Should Be No Problems With Running Both Methods Simultaneously. If You Do Run Into Interoperability Problems, However, You Can Disable The Version 2 Functionality On Newer Routers Using The Following Command:
Router1#Configure Terminal
Enter Configuration Commands, One Per Line. End With CNTL/Z.
Router1(Config)#Ip Pim Version 1
Router1(Config)#End
Router1#
Auto-RP Distributes Information About The Multicast Rendezvous Points Using The Globally Registered Multicast Group Addresses 224.0.1.39 And 224.0.1.40. This Is An Elegant Solution To The Problem Of How To Tell The Network Where The Rps Are. But It Presents A Bit Of A Paradox To The Routers: How Can They Distribute Multicast Information Using PIM-SM If They Don't Yet Have An RP? Cisco Solved This Problem By Creating A New Hybrid PIM Mode Called Sparse-Dense Mode. This Means That The Routers Should Use Sparse Mode If There Is A Known RP, And Dense Mode If There Isn't. So The Only Difference In Router1's Configuration Between This Recipe And The Previous One Is That All Of The Interfaces Are Configured With The Command: Ip Pim Sparse-Dense-Mode:
Router1(Config-If)#Ip Pim Sparse-Dense-Mode
There Are Two Important Differences Between Router RP1's Configuration In This Example And Example 2. To Advertise Its Willingness To Become An RP Using Auto-RP, This Router Includes The Global Configuration Command Ip Pim Send-Rp-Announce:
Router-RP1(Config)#Ip Pim Send-Rp-Announce Loopback0 Scope 16 Group-List 15
The Interface Specified In This Command, Loopback0, Has The Address That Other Routers Will Use For All Of Their Interactions With The RP. We Have Used A Loopback Interface To Ensure As Long As There Is An Active Path To This Router, It Can Continue To Act As The RP.
As Mentioned In The Example 2, However, This May Not Always Be Desirable. For Example, If This Router Has A LAN Interface And A WAN Interface, You Certainly Don't Want All Of Your Multicast Traffic To Have To Loop Through The WAN If The LAN Interface Goes Down. In Such Failure Modes, You Would Probably Want To Stop Using This RP And Switch To A Different Candidate RP. You Can Do This By Simply Specifying The LAN Interface In The Send-Rp-Announce Command.
The Second Difference In Router RP1's Configuration Is The Command Ip Pim Send-Rp-Discovery:
Router-RP1(Config)#Ip Pim Send-Rp-Discovery Scope 16
This Instructs The Router To Act Not Only As A Candidate RP, But Also As An RP Mapping Agent. The Mapping Agent Function Is Similar To The BSR Function That We Discussed In Example 2. This Is The Router That Is Responsible For Distributing Information About All Of The Rps Throughout The Network. Although You Could Make The Mapping Agent A Different Router, We Have Combined The Functions On The Candidate RP Router For The Same Reasons As In The BSR Case.
Note That For Both The Send-Rp-Announce And Send-Rp-Discovery Commands There Is A Scope Keyword That Sets The TTL Scope For These Functions To 16. Because Auto-RP Uses Multicasts To Distribute Its Information, You Can Specify A Particular Initial TTL Value. This Controls The Network Area That Will Be Able To Use This Particular RP.
Finally, In The Send-Rp-Announce Command We Have Specified A Group-List Keyword. This Is Identical To The Group-List In The BSR Configuration Of Example 2. It Defines Which Groups This Particular Router Is Willing To Act As RP For. As We Mentioned In Example 2, Most Networks Can Easily Support All Of Their Multicast Traffic On A Single Active RP. Having Different RP's For Different Multicast Groups Is Primarily Useful For Administrative Reasons, And For Rare Networks That Have Too Many Multicast Groups For One RP To Support.
If You Want One RP For All Groups, Simply Leave Out The Group-List Keyword And Its Arguments:
Router-RP1#Configure Terminal
Enter Configuration Commands, One Per Line. End With CNTL/Z.
Router-RP1(Config)#Ip Pim Send-Rp-Announce Loopback0 Scope 16
Router-RP1(Config)#Ip Pim Send-Rp-Discovery Scope 16
Router-RP1(Config)#End
Router-RP1#
FILTERING PIM NEIGHBORS:
In This Example, We Will Configure A Neighbor Filter On Router1's Fastethernet Interface, Which It Uses To Connect To A Foreign Router Called Router2:
Router1#Configure Terminal
Enter Configuration Commands, One Per Line. End With CNTL/Z.
Router1(Config)#Ip Multicast-Routing
Router1(Config)#Interface Fastethernet0/0
Router1(Config-If)#Ip Address 192.168.1.1 255.255.255.0
Router1(Config-If)#Ip Pim Sparse-Mode
Router1(Config-If)#Ip Pim Neighbor-Filter 18
Router1(Config-If)#Exit
Router1(Config)#Access-List 18 Deny Any
Router1(Config)#End
Router1#
Then, On The Foreign Router, We Must Configure An Igmp Helper-Address:
Router2#Configure Terminal
Enter Configuration Commands, One Per Line. End With CNTL/Z.
Router2(Config)#Ip Multicast-Routing
Router2(Config)#Interface Fastethernet0/0
Router2(Config-If)#Ip Address 192.168.1.2 255.255.255.0
Router2(Config-If)#Ip Pim Dense-Mode
Router2(Config-If)#Ip Igmp Helper-Address 192.168.1.1
Router2(Config-If)#End
Router2#
DISCUSSION:
There Are Two Main Reasons For Configuring A PIM Neighbor Filter. The First And Most Obvious Reason Is Security. If You Don't Control All Of The Routers On A Network Segment, But You Want To Maintain Administrative Control Over Your Multicast Routing Trees, You Might Want To Prevent The Foreign Devices From Taking Part In PIM. In Particular, Since PIM Elects A Designated Router (DR) To Handle Multicast Forwarding For Each Network Segment, You Can Use Neighbor Filtering To Ensure That You Control The DR. Furthermore, Preventing Foreign Routers From Joining Your PIM Domain Also Prevents These Routers From Discovering And Using Your Rps, And It Also Prevents Those Foreign Routers From Advertising Their Own Rps Into Your Domain.
The Second Reason For Using This Feature Is To Create The Multicast Equivalent Of "Stub Routing." In Stub Routing, The Foreign Routers Are Still Able To Take Part In The Forwarding Of Multicast Packets, But They Must Do So By Exchanging IGMP Join And Leave Packets With Your Routers.
Multicast Stub Routing Conserves Resources By Allowing Routers To Keep Track Of Fewer PIM Neighbors. And Because The Stub Region Uses PIM-DM, It Conserves Resources On Your Rps.
There Are Two Parts To The Configuration. On Our Edge Router, You Configure The Neighbor-Filter Command By Using An Access-List:
Router1(Config)#Interface Fastethernet0/0
Router1(Config-If)#Ip Pim Sparse-Mode
Router1(Config-If)#Ip Pim Neighbor-Filter 18
Router1(Config-If)#Exit
Router1(Config)#Access-List 18 Deny Any
If There Are Some Routers On This Segment That You Do Want To Include In Your PIM Domain, You Can Simply Define A More Precise Access-List, Such As:
Router1(Config)#Access-List 18 Deny 192.168.1.2
Router1(Config)#Access-List 18 Permit Any
In This Example, We Allow Any PIM Neighbors Except For Router2. You Could Similarly Construct A More Complicated Filter To Have A More Complicated Mixture Of Allowed And Denied Neighbors.
The Second Part Of The Configuration Is The Igmp-Helper Configuration On The Foreign Router:
Router2(Config-If)#Ip Igmp Helper-Address 192.168.1.1
This Command Is Important, As It Ensures That Router2 Will Forward All Of The Appropriate IGMP Join And Leave Messages To The Internal PIM Router. Without This Command, Router2 Doesn't Know That There Is An Adjoining Multicast Network That Might Be Able To Service These IGMP Requests.
Finally, We Would Like To Point Out That The Stub Domain, Router2 In Our Example, Runs PIM-DM. This Is Necessary Because This Router Doesn't Have Access To The Usual PIM-SM Mechanisms For Joining A Multicast Tree. Instead, It Must Rely On The Simpler PIM-DM Flood And Prune Mechanism. Router1, On The Other Hand, Can Run PIM-SM, PIM-DM, Or Even Bidirectional PIM, As Required.
Configuring Routing For A Low-Frequency Multicast Application
PIM-SM Is Best Suited To This Type Of Application. The Configurations Of The RP And BSR Or Auto-RP Routers For This Example Are Identical To Those Shown In Example 2 And 3.
The Differences Appear On The Other Routers In The Network. So This Recipe Shows Only The Configurations For These Other Routers:
Router1#Configure Terminal
Enter Configuration Commands, One Per Line. End With CNTL/Z.
Router1(Config)#Ip Multicast-Routing
Router1(Config)#Ip Pim Spt-Threshold 10 Group-List 15
Router1(Config)#Access-List 15 Permit 239.5.5.55
Router1(Config)#Access-List 15 Deny Any
Router1(Config)#Interface Fastethernet0/0
Router1(Config-If)#Ip Address 192.168.1.1 255.255.255.0
Router1(Config-If)#Ip Pim Sparse-Dense-Mode
Router1(Config-If)#Exit
Router1(Config)#Interface Serial1/0
Router1(Config-If)#Ip Address 192.168.2.5 255.255.255.252
Router1(Config-If)#Ip Pim Sparse-Mode
Router1(Config-If)#End
Router1#
DISCUSSION
Discussion Of Multicast Applications Usually Focuses On High-Bandwidth Applications. But Some Multicast Applications Have The Opposite Behavior. For Example, Some News Broadcast Type Applications Allow Message Servers To Send Short Messages To A Large Group Of Users. This Sort Of Service Might Be Used For Administrative Purposes ("The Server Is Going Down In Five Minutes") Or For Business Purposes ("Stop Selling Widgets, The Warehouse Is Empty," Or "Buy More Cisco Stock"). In Either Case, All Of The Users In The Group Need To Receive The Message.
But There Are Three Problems. First, In This Sort Of Application You Can't Afford To Waste The First Packet While Setting Up Your Multicast Distribution Trees Because It May Be The Only Packet Sent. Second, You Don't Want To Worry About Finding A More Optimal Tree After You've Delivered The First Packet Because There Isn't Going To Be Another Packet For A Long Time. And Third, By The Time The Next Packet Comes Along, All Of The Routing That The Network Set Up For The First Packet May Have Timed Out.
There Are Many Possible Solutions To This Problem. You Could Statically Configure The Entire Multicast Network Using Static Multicast Routes And Group Memberships, And Not Use A Multicast Routing Protocol At All. But This Is Clearly An Administrative Nightmare To Keep Updated, And It Would Make It Difficult To Use The Same Network For Other Multicast Applications. So The Recipe Shows A Better Solution.
It Is Useful To Step Through The Network From Group Member To Sender And Back To See All Of The Places Where A Low-Frequency Multicast Application Can Cause Problems. A Router Will Assume That There Are No Group Members On A Network Segment If It Doesn't Receive Any IGMP Messages For A Defined Period Of Time. However, The Devices On The Segment Are Responsible For Sending Periodic IGMP Reports To Ensure That This Doesn't Happen Unless There Really Aren't Any More Members For A Given Group On The Segment. So Unless The Timers Are Not Configured Properly On The End Devices, The Low-Frequency Multicast Application Should Not Represent A Problem Here. In Particular, It Should Not Be Necessary To Configure A Static IGMP Statement On The Router Interface.
At This Point, It Is Useful To Think About Whether You Should Use A Dense Mode Or Sparse Mode Multicast Routing Protocol. Recall That The Difference Between These Modes Is That A Dense Mode Protocol Forwards All Multicast Packets To All Neighboring Routers Until They Announce That They Don't Want To Be Members. In Sparse Mode, On The Other Hand, Routers Must Explicitly Join A Group Before They Can Receive It.
If You Were To Use PIM-DM In This Network, The Multicast Packets Themselves Would Help To Establish The Multicast Tree Structure. If A Router Didn't Receive Any Packets For A Group Within A Standard Timeout Period Of Three Minutes, It Would Tear Down This Tree Structure. So This Is The First Important Place Where The Low-Frequency Application Can Cause Problems. The Network Either Has To Be Constructed So That It Can Build And Tear Down This Forwarding Tree For Every Individual Multicast Packet, Or It Has To Keep The Tree Up.
All Of The End Devices In The Low-Frequency Application Pre-Join The Group, So Before The First Packet Is Sent, It Is Already Clear Where It Should Be Delivered. If You Used Dense Mode, The Routers That Did Not Have Members Would Respond To The First Packet With A Round Of Prune Messages Asking To Be Removed From The Tree. Since We Don't Expect Another Packet Anytime Soon, These Prune Messages Are Really Just A Waste Of Network Resources. The Entire Tree Structure Will Have Been Removed Before The Next Packet Arrives. So, All Things Considered, It Is Better To Use PIM-SM Than PIM-DM For This Type Of Application. Note That The Example Actually Uses "Sparse-Dense" Mode So That It Can Function In Dense Mode If An RP Is Not Available. This Is Discussed In Example 3.
As Discussed In The Introduction To This Chapter, Every PIM-SM Router Sends A Fresh Join Up The Tree Toward The RP Once Per Minute. This Ensures That The Tree To The RP Stays Up Even If There Is No Traffic. When The Source Device Is Finally Ready To Send A Packet, It Sends This Packet To Its First-Hop Router. The First-Hop Router Encapsulates The Multicast Packet In A Unicast Registration Packet That It Sends To The RP. The RP Pulls The Multicast Packet Back Out Of The Encapsulation And Forwards It Down The Multicast Tree To All Of The Group Members. It Then Extends The Tree For This Group Over To The Source So That It Can Use Multicast All The Way On Subsequent Packets.
The Only Impact Of The Low-Frequency Nature Of The Application Here Is That The Extension Of The Tree From The RP Over To The Source Will Eventually Be Torn Down Because Of Lack Of Data. But We Do Need To Be Careful That The Last-Hop Routers Don't Try To Build A New Multicast-Forwarding Tree Rooted At The Source. To Prevent This, The Recipe Example Shows How To Set The SPT Threshold Value So That Only High-Traffic Multicast Streams Will Rebuild The Tree Like This.
This Threshold Is Set By The Command Ip Pim Spt-Threshold:
Router1(Config)#Ip Pim Spt-Threshold 10 Group-List 15
In The Example, We Set The Threshold To 10 Kbps For The Groups Defined By Access-List 15. All Other Groups Will Continue To Use The Default Threshold Of Zero. If You Instead Wanted To Have This Command Affect All Multicast Groups, You Could Simply Leave Out The Group-List:
Router1(Config)#Ip Pim Spt-Threshold 10
You Can Also Use This Command To Tell The Routers To Always Use The RP, And Never Switch Over To The Source-Based SPT By Using The Keyword Infinity For The Threshold Value:
Router1(Config)#Ip Pim Spt-Threshold Infinity
Or, You Could Use This Option With A Group-List Statement To Prevent The Router From Building A Source-Based STP Just For A Specific Set Of Groups:
Router1(Config)#Ip Pim Spt-Threshold Infinity Group-List 15
CONCLUSION:
The Goal Of This Article Is To Give An Easy Way To Understand The “Cisco - Configuring IP Multicast Routing ”.Hope This Article Will Help Every Beginners Who Are Going To Start Cisco Lab Practice Without Any Doubts. Thank You And Best Of Luck.
This Article Written Author By: Premakumar Thevathasan. CCNA, CCNP, CCIP, MCSE, MCSA, MCSA - MSG, CIW Security Analyst, CompTIA Certified A+.
DISCLAIMER:
This Document Carries No Explicit Or Implied Warranty. Nor Is There Any Guarantee That The Information Contained In This Document Is Accurate. Every Effort Has Been Made To Make All Articles As Complete And As Accurate As Possible.
It Is Offered In The Hopes Of Helping Others, But You Use It At Your Own Risk. The Author Will Not Be Liable For Any Special, Incidental, Consequential Or Indirect Any Damages Due To Loss Of Data Or Any Other Reason That Occur As A Result Of Using This Document. But No Warranty Or Fitness Is Implied. The Information Provided Is On An "As Is" Basic. All Use Is Completely At Your Own Risk.
The School Of Cisco Networking (SCN)
2 comments:
IP Multicast
1. Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#ip multicast-routing
2. Create a new GRE Tunnel interface on the Cisco 2610.
2610(config)# int tunnel 5
2610(config-if)# tunnel source e0/0
2610(config-if)# tunnel destination 193.1.70.5
2610(config-if)# tunnel mode gre ip
2610(config-if)# ip address 193.1.70.33 255.255.255.252
3. Enable IP Multicast Routing on the Cisco 2610
2610(config-if)# exit
2610(config)# ip multicast-routing
4. Enable PIM Sparse Mode on the Tunnel Interface.
2610(config)# int tunnel 5
2610(config-if)# ip pim sparse-mode
5. Enable PIM Sparse Mode on E0/0
2610(config)# int e0/0
2610(config-if)# ip pim sparse-mode
6. Configure the PIM Rendezvous Point on the Cisco 2610
2610(config-if)# exit
2610(config)# ip pim rp-address 193.1.195.68
7. Create a Static Default Mroute that uses Tunnel 5 as the next hop
2610(config)# ip mroute 0.0.0.0 0.0.0.0.0 193.1.70.34
1. Router1(config)#ip multicast-routing
2.
Create a new GRE Tunnel interface on the Cisco 2610.
2610(config)# int tunnel 5
2610(config-if)# tunnel source e0/0
2610(config-if)# tunnel destination 193.1.70.5
2610(config-if)# tunnel mode gre ip
2610(config-if)# ip address 193.1.70.33 255.255.255.252
3.
Enable IP Multicast Routing on the Cisco 2610
2610(config-if)# exit
2610(config)# ip multicast-routing
4.
Enable PIM Sparse Mode on the Tunnel Interface.
2610(config)# int tunnel 5
2610(config-if)# ip pim sparse-mode
5.
Enable PIM Sparse Mode on E0/0
2610(config)# int e0/0
2610(config-if)# ip pim sparse-mode
6.
Configure the PIM Rendezvous Point on the Cisco 2610
2610(config-if)# exit
2610(config)# ip pim rp-address 193.1.195.68
7.
Create a Static Default Mroute that uses Tunnel 5 as the next hop
2610(config)# ip mroute 0.0.0.0 0.0.0.0.0 193.1.70.34
Post a Comment