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
Advertisements

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..