Multicasting: Multicasting Lab Configuration

Basics

  • 1. Enable ip multicast routing globally
  • 2. Set nominated RP
  • 3. Enable PIM mode (Dense, Sparse etc)

We’ll verify the neighbor relationships with show ip pim neighbor.

R1#show ip pim neighbor
PIM Neighbor Table
Neighbor Address Interface Uptime Expires Ver Mode
172.12.123.2 Serial0 00:00:37 00:01:37 v2
172.12.123.3 Serial0 00:00:40 00:01:35 v2

Ever wonder how you can test whether routers have correctly joined a multicast group? Here’s an old CCIE lab trick – ping the multicast IP address of the group with the extended ping command.

R1#ping
Protocol [ip]:
Target IP address: 239.1.1.1
Repeat count [1]: 100
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:
............................

R1’s pings to 239.1.1.1 are failing because there are no members of that multicast group. Let’s fix that by making R2 and R3 members.

R2(config)#int s0
R2(config-if)#ip igmp join-group 239.1.1.1
R3(config)#int s0
R3(config-if)#ip igmp join-group 239.1.1.1

Let’s take a look at the multicasting route table on R2 with show ip mroute

R2#show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C -
Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report
Outgoing interface flags: H - Hardware switched
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.0.1.40), 00:07:40/00:00:00, RP 172.12.123.1, flags: SJPCL
Incoming interface: Serial0, RPF nbr 172.12.123.1
Outgoing interface list: Null
(*, 239.1.1.1), 00:04:16/00:00:00, RP 172.12.123.1, flags: SJPCLF
Incoming interface: Serial0, RPF nbr 172.12.123.1
Outgoing interface list: Null
(172.12.123.1, 239.1.1.1), 00:04:16/00:01:13, flags: PCLFT
Incoming interface: Serial0, RPF nbr 0.0.0.0
Outgoing interface list: Null

This table is quite different from the IP routing table we’re used to..

Note that there are two entries for 239.1.1.1. The first is a “star, group” entry. The star (“*”) represents all source addresses, while the “group” indicates the destination multicast group address. This entry is usually referred to as *, G in Cisco documentation. The second entry is a “Source,Group” entry, usually abbreviated as S,G in technical documentation. The Source value is the actual source address of the group, while the Group is again the multicast group address itself.

When spoken, the G entry is called a “star comma G” entry; the S,G entry is called a “S comma G” entry.

Note the RPF neighbor entry 0.0.0.0 for the 172.12.123.1,239.1.1.1 entry. That will always be 0.0.0.0 when you’re running sparse mode, as we are here.

Flags

D - Dense Mode entry
S - Sparse Mode entry
C - Connected, referring a member of the group being on the directly connected network
L - Local Router, meaning this router itself is a member of the group
P - Pruned, indicates the route has been pruned.
T - Shortest Path Tree, indicates packets have been received on the tree.

To test this configuration. We’ll send pings to 239.1.1.1 and see what the result is…

R1#ping
Protocol [ip]:
Target IP address: 239.1.1.1
Repeat count [1]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:
Reply to request 0 from 172.12.123.3, 116 ms
Reply to request 0 from 172.12.123.2, 128 ms

Both downstream members of the multicast group 239.1.1.1 responded to the ping.

There are some other commands you can use to verify and troubleshoot multicasting, one being show ip pim interface

R1#show ip pim interface
Address Interface Version/Mode Nbr Query DR
Count Intvl
172.12.123.1 Serial0 v2/Sparse 2 30 172.12.123.3

Note the “DR” entry. On multiaccess segments like the one we’ve got ere, a PIM Designated Router will be elected. The router with the highest IP will be the DR. The DR election is really more for Ethernet segments with more than one router than for NBMA networks like this fame relay network. The PIM DR has two major responsibilities.

  • 1. Send IGMP queries to the LAN
  • 2. If Sparse Mode is running, transmit PIM join and register messages to the RP.

You can verify IGMP group memberships with show ip igmp groups.

R2#show ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter
224.0.1.40 Serial0 00:58:20 00:02:49 172.12.123.1
239.1.1.1 Serial0 00:52:13 00:02:46 172.12.123.2

Multicasting: Layer 2 Multicasting, IGMP Snooping and CGMP

Layer 2 Multicasting

Routers and Layer 3 switches have the capability to make intelligent decisions regarding multicast traffic, enabling them to create multicast trees and avoid unnecessary transmission of multicast streams. Layer 2 switches do not. Switches multicast traffic in the exact same way they handle broadcasts – by flooding that traffic out every single port except the one the traffic came in on.

Layer 2 Multicasting Options

  1.  IGMP Snooping
  2. CGMP (Cisco Group Membership Protocol)

IGMP Snooping

IGMP Snooping “snoops” the IGMP reports being sent from a host to a multicast router. The switch listens to these reports and records the multicast group’s MAC address and the switch port upon which the IGMP report was received. This allows the switch to learn which ports actually need the multicast traffic, and will send it only to those particular ports instead of flooding the traffic.

SW1#show ip igmp snooping
Global IGMP Snooping configuration:
-----------------------------------
IGMP snooping : Enabled
IGMPv3 snooping (minimal) : Enabled
Report suppression : Enabled
TCN solicit query : Disabled
TCN flood query count : 2
Vlan 1:
--------
IGMP snooping : Enabled
Immediate leave : Disabled
Multicast router learning mode : pim-dvmrp
Source only learning age timer : 10
CGMP interoperability mode : IGMP_ONLY

IGMP Snooping is best suited for high-end switches with CPU to spare. If CPU is an issue, consider using CGMP.

Cisco Group Membership Protocol (CGMP)

CGMP allows the multicast router to work with the Layer Two switch to eliminate unnecessary multicast forwarding. CGMP will be enabled on both the multicast router and the switch, but the router’s going to do all the work. The router will be sending Join and Leave messages to the switch as needed. (PIM must be running on the router interface facing the switch before enabling CGMP)

R1(config)#int e0
R1(config-if)#ip cgmp
WARNING: CGMP requires PIM enabled on interface
R1(config-if)#ip pim sparse
R1(config-if)#ip cgmp

When CGMP is first enabled on both the multicast router and switch, the router will send a CGMP Join message, informing the switch that a multicast router is now connected to it. This particular CGMP Join will contain a Group Destination Address (GDA) of 0000.0000.0000 and the MAC address of the sending interface.

The GDA is used to identify the multicast group, so when this is set to all zeroes, the switch knows this is an introductory CGMP Join. This GDA lets the switch know that the multicast router is online.

The switch makes an entry in its MAC table that a multicast router can be found off the port that the CGMP Join came in on. The router will send this CGMP Join to the switch every minute to serve as a keepalive.

CGMP Leaves

CGMP Leaves work much the same way, but the router and switch have to allow for the possibility that there are still other members on the switch that still need that multicast group’s traffic.

A host will send an CGMP Leave. The multicast router receives this request, and in return sends a group-specific CGMP query back to the switch. The switch will then flood this frame so hosts on every other port receives a copy. Any host that wishes to continue to receive this group’s traffic must respond to this query.

The remaining host will send such a response, and the router in turn will send a CGMP Leave to the switch, telling the switch to delete only the host that originally sent the CGMP Leave from the group.

On Layer 3 switches, CGMP is disabled. CGMP is enabled at the interface level with the following command:

SW1(config)#int fast 0/5
SW1(config-if)#ip cgmp

On Layer 2 switches, CGMP is enabled by default.

Multicasting: Multicast Fundamentals + IGMP Versions

Multicasting

A multicast is data that is sent to a logical group of hosts, called a multicast group. Hosts that are not part of the multicast group will not receive the data.

  • There’s no limit on how many multicast groups a single host can belong to. The sender is usually unaware of what host devices belong to the multicast group. Multicast traffic is unidirectional. If the members of the multicast group need to respond, that reply will generally be a unicast.
  • Expressed in binary, the first four bits of a multicast IP address are 1110.
  • The range of IP addresses reserved for multicasting is the Class D range, 224.0.0.0 – 239.255.255.255.
  • The overall range of Class D addresses contains several other reserved address ranges.
  • The 224.0.0.0 – 224.0.0.255 range is reserved for network protocols. Packets in this range will not be forwarded by routers, so these packets cannot leave the local segment. This block of addresses is the local network control block.
  • Just as Class A, Class B, and Class C networks have private address ranges, so does Class D. The Class D private address range is 239.0.0.0 – 239.255.255.255. Like the other private ranges, these addresses can’t be routed, so they can be reused from one network to another. This block of addresses is the administratively scoped block. These addresses are also called limited scope addresses.
  • The 224.0.1.0 – 238.255.255.255 range is the globally scoped address range, and these addresses are acceptable to assign to internet-based hosts – with a lot of exceptions.

Here are some other individual reserved multicast addresses:

  • 224.0.0.5 – All OSPF Routers
  • 224.0.0.6 – All OSPF DRs
  • 224.0.0.9 – All RIPv2 routers
  • 224.0.0.10 – All EIGRP routers
  • 224.0.0.12 – HSRPv2
  • 224.0.1.1 – Network Time Protocol (NTP)
  • 224.0.0.1 – “All hosts”
  • 224.0.0.2 – “All multicast routers”

There are some individual addresses in the Class D range that you should not use. Called unusable multicast addresses or unstable multicast addresses, there’s quite a few of these and you should be aware of them when planning a multicast deployment.

The RPF Check

A unicast is routed by sending it toward the destination, while a multicast is routed by sending it away from its source.

With multicast routing, the destination is a multicast IP group address. It’s the multicast router’s job to decide which paths will lead back to the source (upstream) and which paths are downstream from the source.

Reverse Path Forwarding refers to the router’s behavior of sending multicast packets away from the source rather than toward a specific destination.

The RPF Check is run against any incoming multicast packet. The multicast router examines the interface that the packet arrived on. If the packet comes in on an upstream interface – that is, an interface found on the reverse path that leads back to the source – the packet passes the check and will be forwarded.

If the packet comes in on any other interface, the packet is dropped.

Multicasting Protocol =  Protocol Independent Multicast (PIM)

High Level Overview of Multicasting:

When a router runs a multicasting protocol, a multicast tree will be created. The source sits at the top of the tree, sending the multicast stream out to the network. The recipients are on logical branches, and these routers need to know if a downstream router is part of the multicast group. If there are no downstream routers that need the multicast stream, that router will not forward the traffic. This prevents the network from being overcome with multicast traffic.

  • A multicasting protocol will prevent a router from sending multicast traffic on a branch where it’s not needed.
  • The routers on the multicast tree branches that receive this traffic are referred to as leaf nodes.

IGMP Version 1

A host running IGMP v1 will send a Membership Report message to its local router, indicating what multicast group the host wishes to join. This Membership Report’s destination IP address will reflect the multicasting group the host wishes to join. (This message is occasionally called a Host Membership Report as well.)

A router on every network segment will be elected IGMPv1 Querier, and that router will send a General Query onto the segment every 60 seconds.

If there are multiple routers on the segment, only one router will fill this role, as there’s no need for two routers to forward the same multicast traffic onto a segment. (Different protocols elect an IGMPv1 querier in different ways, so there’s no one way to make sure a given router becomes the Querier with v1.)

This query is basically asking every host on the segment if they’d like to join a multicast group. These queries are sent to the reserved multicast address 224.0.0.1, the “all-hosts on this subnet” address. A host must respond to this query with a Membership Request under one of two conditions:

  • The host would like to join a group, OR
  • The host would like to continue its membership in a multicast group it has already joined.

That second bullet point means that a host, in effect, must renew a multicast group membership every minute. That’s a lot of renewing, and a lot of Membership Requests taking up valuable bandwidth on that segment. In effect, IGMPv1 gives a host two ways to join a multicast group:

  • Send a Membership Report
  • Respond to a Membership Request

There is no explicit “quit” message that a host running IGMP v1 can send to the router. Instead, the host’s group membership will time out when the router sees no Membership Report for three minutes.

IGMPv1 is not overly efficient..

IGMP Version 2

IGMPv2 hosts that wish to leave a group do not just stop sending Membership Reports, and there’s no three-minute wait to have the membership age out. IGMPv2 hosts send a Leave Group message to the reserved multicast address 224.0.0.2, the “all routers on this segment” address.

In return, the Querier will send a group-specific query, which will be seen by all hosts on the segment. This query specifically asks all hosts on the segment if they would like to receive multicast traffic destined for the group the initial host left. If another host wants to continue to receive that traffic, that host must send a Membership Report back to the Querier.

If the Querier sends that group-specific query and gets no response, the Querier will stop forwarding multicast traffic for that group onto that segment.

Another major difference between IGMPv1 and v2 is that there is a onestep way to make a certain IGMPv2 router become the Querier, and that’s to make sure it has the lowest IP address on the shared segment.

IGMP Version 3

Source filtering, meaning that the host joining a multicast group not only indicates the group it wants to join, but also chooses the source of the multicast traffic. Multicast group members sent IGMP v3 messages to 224.0.0.22. When a host makes that choice regarding the source of the multicast stream, it can take one of two forms:

  1. “I will accept multicast traffic from source x”
  2. “I will accept multicast traffic from any source except source x”

RFC numbers:

  • IGMP v1: RFC 1112
  • IGMP v2: RFC 2236
  • IGMP v3: RFC 3376