The Bryant Advantage CCNP SWITCH Study Guide

Chris Bryant, CCIE #12933 --- www.thebryantadvantage.com

Back To Index
Multicasting
Overview

Ever since you picked up your first CCNA book, you've heard about
multicasting, gotten a fair idea of what it is, and you've memorized a
couple of reserved multicasting IP addresses.
Now as you prepare to become a CCNP, you've got to take that
What Is Multicasting?
Multicast Address Ranges
IGMP
PIM Dense Mode
PIM Sparse Mode
PIM Sparse-Dense Mode
Rendezvous Point Discovery Methods
Configuring Auto-RP
Bootstrapping And Multicasting
IGMP Snooping
CGMP
The RPF Check
knowledge to the next level and gain a true understanding of multicasting.
Those of you with an eye on the CCIE will truly have to become
multicasting experts!
Having said that, we're going to briefly review the basics of multicasting
first, and then look at the different ways in which multicasting can be
configured on Cisco routers and switches.
What Is Multicasting?
A unicast is data that is sent from one host directly to another, while a
broadcast is data sent from a host that is destined for "all" host
addresses. By "all", we can mean all hosts on a subnet, or truly all hosts
on a network.
There's a bit of a middle ground there! A multicast is that middle ground,
as 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.

Some other basic multicasting facts:
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 actual addresses are beyond
the scope of the CCNP SWITCH exam, but you can find them easily using
your favorite search engine.
The RPF Check
A fundamental difference between unicasting and multicasting is that a
unicast is routed by sending it toward the destination, while a multicast is
routed by sending it away from its source.
"toward the destination" and "away from its source" sound like the same
thing, but they're not. A unicast is going to follow a single path from
source to destination. The only factor the routers care about is the
destination IP address - the source IP address isn't a factor.
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.
Since we have multicast IP addresses and multicast MAC addresses, it
follows that we're going to be routing and switching multicast traffic. We'll
first take a look at multicasting from the router's perspective.
Just as there are different routing protocols, there are different
multicasting protocols. The BSCI test focuses on Protocol Independent
Multicast (PIM), so we'll stick with that one.
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.

In the above illustration, there are three multicast group members, each
labeled "MG". A multicasting protocol will prevent a router from sending
multicast traffic on a branch where it's not needed. The middle branch of
this multicast tree has no member of the multicast group, so multicast
traffic shouldn't be sent down that branch.
The left branch does have a member at the edge, as does the right
branch, so traffic for that multicast group will flow all the way down those
two branches. The routers on the multicast tree branches that receive
this traffic are referred to as leaf nodes.
That's all fine - but how does a device join a multicast group in the first
place? That job is performed by IGMP, the Internet Group Management
Protocol. There are three versions of IGMP in today's networks, and
these three versions have dramatic differences in the way they work.
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
The process for a host leaving a multicast group isn't much more
efficient. 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.


In the above scenario, the host was a member of a multicast group, but
stopped sending Membership Reports two minutes ago. The problem is
that the router will not age that membership out for a total of three
minutes, so not only has the router been unnecessarily sending multicast
traffic onto this segment for the last two minutes, but will continue doing
so for another minute before finally aging out the multicast group
membership.
If it occurs to you that IGMPv1 could be a great deal more efficient, you're
right. That's why IGMPv2 was developed!
A major difference between the two is that 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.
An IGMPv2 Querier will send out General Queries, just as IGRPv1
Queriers do.
Another major difference between IGMPv1 and v2 is that there is a one-
step 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.
As you'd expect, there are some issues that arise when you've got some
hosts on a segment running IGMPv1 and others running IGMPv2, or one
router running IGMPv1 and another router running IGMPv2. The different
scenarios are beyond the scope of the exam, but for those of you who'd
like to learn more about the interoperability of the IGMP versions (and
especially if you'd like to be a CCIE one day), get a copy of RFC 2236 off
the Internet and start reading!
IGMP Version 3 is also now available on many Cisco devices. The major
improvement in IGMPv3 is 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:
"I will accept multicast traffic from source x"
"I will accept multicast traffic from any source except source x"
If you'd like to do some additional reading on any IGMP version, here are
the RFC numbers:
IGMP v1: RFC 1112
IGMP v2: RFC 2236
IGMP v3: RFC 3376
Now that the hosts are using IGMP to join the desired multicast group,
we've got to get that traffic to them. For that, we'll use PIM - Protocol
Independent Multicast. There are three modes of PIM you must be fluent
with to pass the CCNP exams as well as two different PIM versions. You'll
see all these modes and versions in production networks as well, so it's
vital to understand the concepts of all of them.
PIM Dense Mode Operation
The first decision to make when implementing a multicasting protocol is
which one to choose. PIM Dense is more suited for the following
situations:
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. Despite the name, the flooding
actually comes first. The multicast packets will be flooded throughout the
network until the packets reach the leaf routers.

The initial flooding ensures that every router has a chance to continue to
receive multicast traffic for that specific group. 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.
The routers with hosts who belong to this multicast group are marked with
"MG". Since none of the leaf routers know of hosts who need this
multicast group's traffic, they will all send a Prune message to 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
neighbor as well. Here, the router in the right-hand column that is
receiving a Prune from its downstream neighbor knows of no hosts that
need the traffic, so that router will send a Prune upstream. In the other
two columns, the routers receiving the Prune do have a need for the
multicast traffic, so the pruning in those branches stops there.

The router receiving that Prune also knows of no hosts that are members
of this multicast group, so -- you guessed it -- that router will send a Prune
to the upstream router.

Logically, the multicast tree now looks like this:


One branch of the tree has been completely pruned, while the leaf routers
on the other two branches have been pruned. This group's multicast
traffic will now only be seen by these five routers.
The other routers were pruned to prevent sending multicast traffic to
routers that didn't need that traffic flow, but 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 neighbor.


Where PIM Dense builds the multicasting tree from the root down to the
branches, PIM Sparse takes the opposite approach. 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
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 shown here 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.
The three routers marked MG have hosts that want to join this particular
multicast group, and we're assuming that the multicast group is new, with
no prior neighbors. Note that one router in the left column has no hosts
that want to join the group, but it's still sending a Join message.

R2 has hosts that want to join the multicast group 224.1.1.4. R2 has no
entry in its multicasting table for this group, so it sends a Join toward the
RP. R1 receives the Join, checks its multicast table, and sees it has no
entries for 224.1.1.4. Even though R1 has no hosts that need to join this
group, R1 will send a Join of its own toward the RP. The RP 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.
Using the same network setup we used for the PIM Dense example, we
see that while the operation of PIM Sparse is much different - there is no
"flood-and-prune" operation - the resulting multicast tree is exactly the
same.


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.
PIM Version 1: Static configuration or Auto-RP
PIM Version 2: Static configuration, Auto-RP, or bootstrapping, the open
standard method.
Let's take a closer look at these methods using the following hub-and-
spoke network, beginning with the static configuration method. All routers
are using their Serial0 interfaces on the 172.12.123.0 /24 network, with
their router number as the fourth octet.


Each router will have multicast routing enabled with the ip multicast-
routing command. Under the assumption that we will not have many
recipients, we'll configure these routers for sparse mode. (If we had many
recipients, we'd use dense mode.) All three routers will have R1
configured as the RP.
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
R2(config)#ip multicast-routing
R2(config)#ip pim rp-address 172.12.123.1
R2(config)#int s0
R2(config-if)#ip pim sparse
R3(config)#ip multicast-routing
R3(config)#ip pim rp-address 172.12.123.1
R3(config)#int s0
R3(config-if)#ip pim sparse
The command show ip pim neighbor verifies that PIM is running and in
Version 2 on all interfaces.
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
Both R2 and R3 show R1 as the RP for the multicast group 224.0.1.40,
which is the RP-Discovery multicast group.
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. You'll see this limitation
configured on R1 only, but it would be needed on R2 and R3 as well.
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
There's one more option in the ip pim rp-address command you should
note. See the override option in the above IOS Help readout? Using that
option will allow this static RP configuration to override any
announcement made by Auto-RP, Cisco's proprietary method of
announcing RPs to multicast routers running Sparse Mode. (Auto-RP is
now supported by some non-Cisco vendors.)
And how do you configure Auto-RP? Glad you asked!
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.
We'll first configure R2 and R3 as candidate RPs. PIM Sparse is already
running on all three routers' serial interfaces and multicasting has been
enabled on all three routers as well.
R2(config)#ip pim send-rp-announce ?
BRI ISDN Basic Rate Interface
Ethernet IEEE 802.3
Null Null interface
Serial Serial
R2(config)#ip pim send-rp-announce serial0 ?
scope RP announcement scope
R2(config)#ip pim send-rp-announce serial0 scope 5
R3(config)#ip pim send-rp-announce serial0 scope 5
The scope value sets the TTL of the RP-Announce messages.
Now that the candidate RPs are configured, R1 will be configured as the
mapping agent.
R1(config)#ip pim send-rp-discovery serial 0 scope 5
As multicast groups are added to the network, both R2 and R3 will
contend to be the RP by sending their RP-Announce messages on
224.0.1.39. As the mapping agent, R1 will decide which router is the RP,
and will make that known via RP-Discovery messages sent on 224.0.1.40.
Using The Bootstrapping Method
PIM Version 2 offers a open-standard, dynamic method of RP selection. If
you're working in a multivendor environment and want to avoid writing a
standard configuration, you may need to use this method.
In the real world, I use Auto-RP every chance I get. It's just a little more
straightforward in my opinion, but as I always say, it's a really good idea to
know more than one way to get something done!
The bootstrap method's operation is much like Auto-RP, but the
terminology is much different.
Candidate Bootstrap Routers (C-BSRs) and Candidate Rendezvous
Points (C-RPs) are configured.
A Bootstrap Router (BSR) is chosen from the group of C-BSRs.
The BSR sends a notification that the C-RPs will hear, and the C-RPs
will send Candidate-RP-Advertisements to the BSR.
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 R1 as a C-BSR:
R1(config)# ip pim bsr-candidate
To configure R2 and R3 as C-RPs:
R2(config)# ip pim rp-candidate

Handling Multicast Traffic At Layer 2
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. One of the first things you learn about Layer 2 switches
in your CCNA studies is that they handle 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.
That's a very inefficient manner of handling multicasting, so two different
methods of helping Layer 2 switches with multicasting have been
developed: IGMP Snooping and CGMP, the Cisco Group Membership
Protocol.
So what is IGMP Snooping "snooping" on? 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.


IGMP Snooping is not supported by all Cisco switch hardware platforms,
but is supported by the 2950 and 3550 families by default, as shown here
on a 2950:
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
To turn IGMP snooping off, run the command no ip igmp snooping.
SW1(config)#no ip igmp snooping
SW1#show ip igmp snooping
Global IGMP Snooping configuration:
-----------------------------------
IGMP snooping : Disabled
IGMPv3 snooping (minimal) : Enabled
Report suppression : Enabled
TCN solicit query : Disabled
TCN flood query count : 2
Vlan 1:
--------
IGMP snooping : Disabled
Immediate leave : Disabled
Multicast router learning mode : pim-dvmrp
Source only learning age timer : 10
From experience, I can tell you that one deciding factor between IGMP
Snooping and CGMP is the switch's processor power. 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)
If a Layer Two switch doesn't have the capabilities to run IGMP Snooping,
it will be able to run CGMP - Cisco Group Membership Protocol. (As long
as it's a Cisco switch, that is - CGMP is CIsco-proprietary!) 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, as you can see:
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
Let's look at two examples of when CGMP Join and Leave messages will
be sent, and to where.

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.



A workstation connected to port 0/5 now wishes to join multicast group
225.1.1.1. The Join message is sent to the multicast router, but first it will
pass through the switch. The switch will do what you'd expect it to do -
read the source MAC address and make an entry for it in the MAC
address table as being off port fast 0/5 if there's not an entry already
there. (Don't forget that the MAC address table is also referred to as the
CAM table or the bridging table.)

The router will then receive the Join request, and send a CGMP Join back
to the switch. This CGMP Join will contain both the multicast group's
MAC address and the requesting host's MAC address. Now the switch
knows about the multicast group 225.1.1.1 and that a member of that
group is found off port fast 0/5.
In the future, when the switch receives frames destined for that multicast
group, the switch will not flood the frame as it would an unknown multicast
- the switch will forward a copy of the frame to each port that it knows
leads to a member of the multicast group.
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. In the following example, two
hosts that are receiving traffic from the multicast group 225.1.1.1 are
connected to the same switch.
One of the hosts is sending 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.
As shown below, 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.

If no other host responds to the Group-Specific Query, the router will still
send a CGMP Leave to the switch. However, the CGMP Leave will tell
the switch to remove the entire group listing from the MAC table.
You may be wondering how the switch differentiates CGMP Joins and
Leaves from all the other frames it processes. The switch recognizes
both of those by their destination address of 01-00-0c-dd-dd-dd, a
reserved Layer 2 address used only for this purpose.
Enabling CGMP
The additional configuration needed to run CGMP depends on the switch
model.
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.

Joining A Multicast Group - Or Not!
After all this talk about dense, sparse, and sparse-dense mode, we need
to get some routers to actually join a multicasting group! Before we do,
there are two command that are close in syntax but far apart in meaning,
and we need to have these two commands in mind before starting the
next configuration.
The interface-level command ip igmp join-group allows a router to join a
multicast group.
The interface-level command ip igmp static-group allows a router to
forward packets for a given multicast group, but the router doesn't actually
accept the packets.
In the following configuration, R1 is the hub router of a hub-and-spoke
configuration and the RP for the multicast group 239.1.1.1. R2 and R3
will be made members of this group.


We'll configure R1 as the RP for the group 239.1.1.1. Don't forget to
enable multicasting on the router before you begin the interface
configuration - the router will tell you to do so, but the exam probably will
not!
R1(config)#int s0
R1(config-if)#ip pim sparse
WARNING: "ip multicast-routing" is not configured, IP Multicast packets
will not be forwarded
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
R2(config)#ip multicast-routing
R2(config)#ip pim rp-address 172.12.123.1
R2(config)#int s0
R2(config-if)#ip pim sparse
R3(config)#ip multicast-routing
R3(config)#ip pim rp-address 172.12.123.1
R3(config)#int s0
R3(config-if)#ip pim sparse
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
We'll also verify that R2 and R3 see R1 as the RP for 239.1.1.1 with show
ip pim rp.
R2#show ip pim rp
Group: 224.0.1.40, RP: 172.12.123.1, v2, uptime 00:55:58, expires never
Group: 239.1.1.1, RP: 172.12.123.1, v2, uptime 00:52:34, expires 00:03:01
R3#show ip pim rp
Group: 224.0.1.40, RP: 172.12.123.1, v2, uptime 00:55:39, expires never
Group: 239.1.1.1, RP: 172.12.123.1, v2, uptime 00:52:40, expires 00:04:25
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, so let's
take a few minutes to examine this table.
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.
Also note that each entry has some flags set. It couldn't hurt to know the
meanings of some of the more often-set 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, well, pruned. :)
T - Shortest Path Tree, indicates packets have been received on the tree.
To wrap this up, let's go back to R1 and 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
here, 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
frame relay network. The PIM DR has two major responsibilities:
Send IGMP queries onto the LAN
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
With video and voice traffic becoming more and more popular in today's
networks, multicasting and Quality Of Service (QoS) are going to become
more and more important. I urge you to continue your multicasting
studies after you earn your CCNP, and for those of you with your eyes on
the big prize - the CCIE - you'll truly have to become a multicasting
master!

Copyright 2010 The Bryant Advantage. All Rights Reserved.