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: The Many Modes Of Multicasting

PIM Sparse-Dense Mode

Many multicasting networks use a combination of these two methods, Sparse-Dense mode. A more accurate name would be “Sparse-Or-Dense” mode, since each multicast group will be using one or the other. If an RP has been designated for a group, that group will use Sparse Mode. If there’s no RP for a group, obviously Sparse Mode is out, so that group will default to Dense Mode.

RP Discovery Methods

It’s one thing to decide which router should be the RP, but it’s another to make sure all the other routers know where the RP is! The available methods depend on the PIM version in use.

  1. PIM Version 1: Static configuration or Auto-RP
  2. PIM Version 2: Static configuration, Auto-RP, or bootstrapping, the open standard method.
R1(config)#ip multicast-routing

R1(config)#ip pim rp-address 172.12.123.1

R1(config)#int s0

R1(config-if)#ip pim sparse

R1#show ip pim neighbor
 PIM Neighbor Table
 Neighbor Address Interface Uptime Expires Ver Mode
 172.12.123.3 Serial0 00:11:08 00:01:37 v2 (DR)
 172.12.123.2 Serial0 00:11:37 00:01:38 v2

R2#show ip pim rp
 Group: 224.0.1.40, RP: 172.12.123.1, v1, uptime 00:12:51, expires 00:03:11
 R3#show ip pim rp
 Group: 224.0.1.40, RP: 172.12.123.1, v1, uptime 00:12:43, expires 00:04:20

You don’t have to use the same router as the RP for every single multicasting group. An access-list can be written to name the specific groups that a router should serve as the RP for, and that access-list can be called in the ip pim rp-address command

R1(config)#access-list 14 permit 224.0.1.40

R1(config)#ip pim rp-address 172.12.123.1 ?
 <1-99> Access-list reference for group
 <1300-1999> Access-list reference for group (expanded range)
 WORD IP Named Standard Access list
 override Overrides Auto RP messages
 <cr>

R1(config)#ip pim rp-address 172.12.123.1 14

Configuring Auto-RP
Auto-RP will have one router acting as the mapping agent (MA), and it is
the job of this router to listen to the multicast address 224.0.1.39. It’s with
this address that routers announce themselves as candidate RPs (C-RP).
The MA listens to the candidate announcements, and then decides on a
RP for each multicast group. The MA then announces these RPs on
224.0.1.40 via RP-Announce messages.

Candidate RP:

R3(config)#ip pim send-rp-announce serial0 scope 5
 *The scope value sets the TTL of the RP-Announce messages

Mapping Agent:

R1(config)#ip pim send-rp-discovery serial 0 scope 5

As multicast groups are added to the network, both the C-RPs will contend to be the RP by sending their RP-Announce messages on 224.0.1.39. As the mapping agent will decide which router is the RP and will make that known via RP-Discovery messages sent on 224.0.1.40.

Bootstrapping method instead of Auto RP

The bootstrap method’s operation is much like Auto-RP, but the terminology is much different:

  1. Candidate Bootstrap Routers (C-BSRs) and Candidate Rendezvous Points (C-RPs) are configured.
  2. A Bootstrap Router (BSR) is chosen from the group of C-BSRs.
  3. The BSR sends a notification that the C-RPs will hear, and the C-RPs will send Candidate-RP-Advertisements to the BSR.
  4. The BSR takes the information contained in these advertisements and compiles the information into an RP-Set. The RP-Set is then advertised to all PIM speakers. The destination multicast address for bootstrap messages is 224.0.0.13.

To configure  a C-BSR:

R1(config)# ip pim bsr-candidate

To configure a C-RPs:

R2(config)# ip pim rp-candidate

Multicasting: More PIM Sparse..

More PIM Sparse

The shared tree creation begins in the same fashion that a source-based tree does – with a host sending a Membership Report to a router. If there is already an entry in the router’s multicast table for 224.1.1.1, the ethernet interface will be added as an outgoing interface for that group, and that’s it.

If there is no entry for 224.1.1.1, the router will send a Join message toward the RP. If the upstream router is the RP, it will add the interface that received the Join to the list of outgoing interfaces for that group; if the upstream router is not the RP, it will send a Join of its own toward the RP.

Hosts that want to join this particular multicast group, and we’re assuming that the multicast group is new, with no prior neighbors. Routers that have no hosts that want to join the group, will still send a Join message to the RP.

The RP eventually receives the Join message and adds the interface upon which the Join was received to the outgoing multicast list for 224.1.1.4.

Sparse Mode uses Join messages as keepalives as well. They are sent every 60 seconds, and the membership will be dropped if three hellos are missed. To avoid unnecessary transmission of multicast traffic, the multicast routers can send Prune messages to end their membership in a given multicast group.

PIM Sparse is much different to PIM Dense as there is no “flood-and-prune” operation – the resulting multicast tree is exactly the same.

Multicasting: PIM Sparse Overview

PIM Sparse Overview

PIM Sparse takes the opposite approach to PIM Dense.

PIM Sparse builds the multicast tree from the leaf nodes up. PIM Dense creates a source based multicast tree, since the tree is based around the location of the multicast traffic’s source. PIM Sparse creates a shared multicast tree, referring to the fact that multiple sources can share the same tree – “one tree, many groups”.

PIM Sparse Mode is best suited for the following situations:

  • The multicast routers are widely dispersed over the network
  • There are multiple, simultaneous multicast streams
  • There are few receivers in each group
  • The multicast traffic will be intermittent

The root of a PIM Sparse tree is not even necessarily the source of the multicasting traffic. A PIM Sparse tree has a Rendezvous Point (RP) for its root. The RP serves as a kind of “central distribution center”, meaning that a shared tree will create a single delivery tree for a multicast group.

  • The routers discover the location of the RP in one of three different fashions.
  • Statically configuring the RP’s location on each router
  • Using an industry-standard bootstrap protocol to designate an RP and advertise its location
  • Using the Cisco-proprietary protocol Auto-RP to designate an RP and advertise its location

Multicasting: PIM Dense

PIM Dense (Protocol Independent Multicast)

  • The multicast source and recipients are physically close
  • There will be few senders, but many recipients
  • All routers in the network have the capability to forward multicast traffic
  • There will be a great deal of multicast traffic
  • The multicast streams will be constant

When PIM Dense is first configured, a router will send a Hello message on every PIM-enabled interface to discover its neighbors. Once a multicast source begins transmitting, PIM Dense will use the prune-and-flood technique to build the multicasting tree. Flooding in fact comes first and Pruning second. The multicast packets will be flooded throughout the network until the packets reach the leaf routers.

If a leaf router has no hosts that need this multicast group’s traffic. the leaf router will send a Prune message to the upstream router.

The Prune message’s IP destination address is 224.0.0.13.

If the upstream router receiving the prune also has no hosts that need this multicast group’s traffic, that router will then send a Prune to its upstream neighbour as well.

What if one of the pruned routers later learns of a host that needs to join that group? The pruned router will then send a Join message to its upstream neighbour.

Where PIM Dense builds the multicasting tree from the root down to the branches, PIM Sparse takes the opposite approach. See next post for PIM Sparse..

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