Tuesday, 14 February 2012

Multicast LAN Protocol Summary


IP multicast addresses range from - The first 4 bits of the first octet for a class D address are always 1110. In CIDR notation the address range is 

IP Address Range Assigned Use IANA assigned for LAN segment use. Packets sent to these address are not forwarded off this LAN (ie like broadcasts) IANA assigned for network use. Packets sent to these addresses are forwarded by routers - Reserved - Reserved
Used for Source Specific Multicast (SSM) GLOP - Reserved Private Multicast (administratively scoped). Like RFC1918 addresses, used internally as you like
Note: Referring to multicast addresses using CIDR notation is generally not use. However I find it an easier concept because it allows for a natural group of subnets and their purpose.



IGMP - used between IPv4 hosts on a LAN and the routers on that LAN to track the multicast groups of which hosts are members.

Because a switch is, by essence, not capable of looking at L3 packets, it cannot distinguish an IGMP packet. The switch cannot dynamically build a L2 forwarding table for the multicast streams. In other words, the switch floods the multicast streams.

MLD - used between IPv6 hosts on a LAN and the routers on the LAN

CGMP - implemented by Cisco to restrain multicast traffic in a L2 network. With CGMP, the router provides the interface between the hosts. The routers "talk" IGMP, with the hosts and based on this it "tells" the switches using CGMP which ports to limit the traffic to.

IGMP Snooping (MLD Snooping) - When a switch is running snooping, it intercepts the IGMP packets and populates the static Layer 2 (L2) forwarding table based on the content of the intercepted packets. When there are IGMPv1 or v2 hosts on the network, the switch reads the IGMP Joins and Leaves to determine which hosts wants to receive which multicast stream, or stop receiving the multicast stream. IGMPv3 is more complicated, because it uses not only the group address (multicast address), but also the sources from which traffic is expected.

RGMP - used with IGMP snooping to constrain multicast traffic to layers where it is really needed. IGMP snooping sends multicast traffic to all router ports. With RGMP, multicast traffic is only sent to ports that need to receive it. RGMP is designed to run on the backbone of the multicast network;

IGMP Versions

IGMP messages are used primarily by multicast hosts to signal their interest in joining a specific multicast group and to begin receiving group traffic.

IGMP Version 1

There are two types of IGMP messages
  • Membership Report 
    • Membership reports are issued by hosts that want to receive a specific multicast group or in response to a membership query. 
    •  L2 Information
        • Source MAC: Host MAC address
        • Destination MAC: Destination MAC for the multicast group
    •  L3 Information
        • Source IP: IP address of the host
        • Destination IP: Specific multicast group
  •  Membership Query (generic query)
    • Membership queries are issued by routers at regular intervals to check whether there is still a host interested in the specified multicast on that segment.
    •  L2 Information
      • Source MAC: Router MAC address
      • Destination MAC: Destination MAC for multicast group
    •  L3 Information
        • Source IP: IP address of the router
        • Destination IP: (all multicast devices)
The DR and querier router are the same and selected based on the highest ip address. The DR function is to send and receive multicast traffic on the network. The querier funtion keeps a list of active hosts on the network.

IGMP Version 2

Extends IGMP allowing such features as the IGMP leave process, group-specific queries, and an explicit maximum query response time. IGMP Version 2 also adds the capability for routers to elect the IGMP querier without dependence on the multicast protocol to perform this task

Type of messages
  • Version 1 Membership Query (generic)
    • Same as IGMP v1
  • Version 1 Membership Report 
    • Same as IGMP v1
  • Version 2 Membership Query (specific group)
    • Send a group specific query
    •  L2 Information
      • Source MAC: Router MAC address
      • Destination MAC: Destination MAC for multicast group
    •  L3 Information
      • Source IP: IP address of the router
      • Destination IP:Group multicast address
  • Version 2 Leave Group 
    •  L2 Information
      • Source MAC: Router MAC address
      • Destination MAC: Destination MAC for multicast group
    •  L3 Information
      • Source IP: IP address of the router
      • Destination IP:
IGMP Version 3 

Provides for "source filtering" which enables a multicast receiver host to signal to a router which groups it wants to receive multicast traffic from, and from which sources this traffic is expected

RFC 3376 (Section 4.2.14).  It's for IGMPv3 member reports.  All v3-capable devices will listen on this report.  It keeps more things away from the older (All Routers) group that used to be used.

Source: here


Enabling PIM on an interface also enables IGMP operation on that interface. An interface can be configured to be in dense mode, sparse mode, or sparse-dense mode. The mode determines how the router populates its multicast routing table and how the router forwards multicast packets it receives from its directly connected LANs.

In populating the multicast routing table:
  • Dense mode interfaces are always added to the table
  • Sparse mode interfaces are added to the table only when periodic join messages are received from downstream routers, or when a directly connected member is on the interface.

When forwarding from a LAN, sparse mode operation occurs if an RP is known for the group. If so, the packets are encapsulated and sent toward the RP. When no RP is known, the packet is flooded in a dense mode fashion. If the multicast traffic from a specific source is sufficient, the first hop router of the receiver may send join messages toward the source to build a source-based distribution tree.

There is no default mode setting. By default, multicast routing is disabled on an interface.

An alternative to enabling only dense mode or only sparse mode is to enable sparse-dense mode. In this case, the interface is treated as dense mode if the group is in dense mode; the interface is treated in sparse mode if the group is in sparse mode.

PIM-DM builds source-based multicast distribution trees that operate on a "flood and prune" principle. Multicast packets from a source are flooded to all areas of a PIM-DM network. PIM routers that receive multicast packets and have no directly connected multicast group members or PIM neighbors send a prune message back up the source-based distribution tree toward the source of the packets. As a result, subsequent multicast packets are not flooded to pruned branches of the distribution tree. However, the pruned state in PIM-DM times out approximately every 3 minutes and the entire PIM-DM network is reflooded with multicast packets and prune messages.

By default, all PIM routers that are running a Cisco IOS software release that supports the PIM Dense Mode State Refresh feature automatically process and forward state refresh control messages. To disable the processing and forwarding of state refresh control messages on a PIM router, use the ip pim state-refresh disable global configuration command.  

PIM-SM requires that a RP is configured in the network. A RP is a router (or a set of routers) which are used as the centre point of a PM-SM tree. The source builds a sparse tree to the RP and the RP build a sparce tree to the destination. The complexity of PM-SM originates from the various ways of assigning and advertising the RP. Additional complexity is how the protcol jumps from the above mentioned tree to a sparce tree directly between the source and destination.

It is possible to statically configure an RP for a multicast group range. The address of the RP must be configured on every router in the domain. Configuring static RPs is relatively easy and can be done with one or two lines of configuration on each router.

Bootstrap Router
The Bootstrap Router (BSR) is a mechanism for a router to learn RP information. It ensures that all routers in the PIM domain have the same RP cache as the BSR. It is possible to configure the BSR to help select an RP set from BSR candidate RPs. The function of the BSR is to broadcast the RP set to all routers in the domain.

The BSR mechanism is a nonproprietary method of defining RPs that can be used with third-party routers (which support the BSR mechanism). There is no configuration necessary on every router separately (except on candidate-BSRs and candidate-RPs). 

 The Auto-RP mechanism operates using two basic components, the candidate RPs and the RP mapping agents.

• Candidate RPs advertize their willingness to be an RP via "RP-announcement" messages. These messages are periodically sent to a reserved well-known group (CISCO-RP-ANNOUNCE).
• RP mapping agents join group and map the RPs to the associated groups. The RP mapping agents advertise the authoritative RP-mappings to another well-known group address (CISCO-RP-DISCOVERY). All PIM routers join and store the RP-mappings in their private cache.

Auto-RP is not supported for IPv6 Multicast. Auto-RP is a Cisco proprietary mechanism.

Two or more RPs are configured with the same IP address on loopback interfaces. All the downstream routers are configured to "know" (ie statically) that the Anycast RP loopback address is the IP address of their RP. When an RP fails, IP routing converges and the other RP assumes the RP role. 

If all RPs are active then potentially they have subscribers / sources on their tree which want to share the same multicast stream. These RPs use MSDP to talk and pass on information about their trees.

Multicast Source Discovery Protocol (MSDP) 

MSDP is the protocol RPs use to share information about active sources. With Anycast RP, the RPs are configured to establish MSDP peering sessions using a TCP connection. Group participants use the closest RP that is favored by the IP unicast route table. 

This protocol can also be used by RPs in different domains to share information. 

Table 1. Comparison of RP Mechanisms

Static RP
Embedded RP
Must be configured on every router
No (except on candidate-BSRs and candidate-RPs)
No (except on candidate RPs and mapping agents)
No (except RP routers)
Supports IPv4 addresses
Supports IPv6 addresses
RP redundancy
No (unless used with Anycast RP)

Source: here 

BiDir_PIM (Bidirectional PIM)
Bidir-PIM purely uses shared trees to forward traffic. Any client attached to the tree can originate traffic which will be sent to everyone else.

Phantom-RP is a technique like anycast RP where two RPs have the same ip address. However rather than let the IGP pick the closest one due to metric, it picks one based on the longest subnet mask.

This basically means that there will only be one active RP in the domain and if this dies, the next one will take over complete. Also by the nature of route selection this is "premptive" ie when the original router returns it will become the RP.

The multiple RPs defined in Phantom-RP can only be used for redundancy. As there is no concept of a mapping agent you cannot load balance the traffic.

No comments:

Post a Comment