Documente Academic
Documente Profesional
Documente Cultură
Before
We
Begin
This
product
is
part
of
the
IPexpert
suite
of
materials
that
provide
CCIE
candidates
and
network
engineers
with
a
comprehensive
training
program.
For
information
about
the
full
solution,
contact
an
IPexpert
Training
Advisor
today.
Telephone:
+1.810.326.1444
Email:
sales@ipexpert.com
Congratulations!
You
now
possess
one
of
the
ULTIMATE
CCIETM
Lab
preparation
and
network
operation
resources
available
today!
Senior
engineers,
technical
instructors,
and
authors
boasting
decades
of
internetworking
experience
produced
this
resource.
In
order
to
enjoy
technical
support
from
IPexpert
and
your
CCIE
community,
be
sure
to
visit
the
following
Internet
resources:
http://blog.ipexpert.com
http://onlinestudylist.com
IPexpert
is
proud
to
lead
the
industry
with
multiple
support
options
at
your
disposal
free
of
charge.
Our
online
communities
have
attracted
a
membership
of
over
20,000
of
your
peers
from
around
the
world!
At
blog.ipexpert.com,
you
can
keep
up
to
date
with
everything
IPexpert
does
and
read
the
latest
in
technical
articles
from
word-renowned
IPexpert
instructors.
At
OnlineStudyList.com,
you
may
subscribe
to
multiple
SPAM-free,
moderated
CCIE-focused
email
lists.
Feedback
Do
you
have
a
suggestion
or
other
feedback
regarding
this
book
or
other
IPexpert
products?
At
IPexpert,
we
look
to
you
our
valued
clients
for
the
real
world,
frontline
evaluation
that
we
believe
is
necessary
so
that
we
may
always
improve.
Please
send
an
email
with
your
thoughts
to
feedback@ipexpert.com
or
call
1.866.225.8064
(international
callers
dial
+1.810.326.1444).
In
addition,
for
those
using
this
book
as
CCIETM
preparation,
when
you
pass
the
CCIETM
Lab
exam,
we
want
to
hear
about
it!
Email
your
CCIETM
number
to
success@ipexpert.com
and
let
us
know
how
IPexpert
helped
you
succeed.
We
would
like
to
send
you
a
gift
of
thanks
and
congratulations.
II
This
is
a
legally
binding
agreement
between
you
and
IPEXPERT,
the
Licensor,
from
whom
you
have
licensed
the
IPEXPERT
training
materials
(the
Training
Materials).
By
using
the
Training
Materials,
you
agree
to
be
bound
by
the
terms
of
this
License,
except
to
the
extent
these
terms
have
been
modified
by
a
written
agreement
(the
Governing
Agreement)
signed
by
you
(or
the
party
that
has
licensed
the
Training
Materials
for
your
use)
and
an
executive
officer
of
Licensor.
If
you
do
not
agree
to
the
License
terms,
the
Licensor
is
unwilling
to
license
the
Training
Materials
to
you.
In
this
event,
you
may
not
use
the
Training
Materials,
and
you
should
promptly
contact
the
Licensor
for
return
instructions.
The
Training
Materials
shall
be
used
by
only
ONE
(1)
INDIVIDUAL
who
shall
be
the
sole
individual
authorized
to
use
the
Training
Materials
throughout
the
term
of
this
License.
III
Exclusions
of
Warranties
THE
TRAINING
MATERIALS
AND
DOCUMENTATION
ARE
PROVIDED
AS
IS.
LICENSOR
HEREBY
DISCLAIMS
ALL
OTHER
WARRANTIES,
EXPRESS,
IMPLIED,
OR
STATUTORY,
INCLUDING
WITHOUT
LIMITATION,
THE
IMPLIED
WARRANTIES
OF
MERCHANTABILITY
AND
FITNESS
FOR
A
PARTICULAR
PURPOSE.
SOME
STATES
DO
NOT
ALLOW
THE
LIMITATION
OF
INCIDENTAL
DAMAGES
OR
LIMITATIONS
ON
HOW
LONG
AN
IMPLIED
WARRANTY
LASTS,
SO
THE
ABOVE
LIMITATIONS
OR
EXCLUSIONS
MAY
NOT
APPLY
TO
YOU.
This
agreement
gives
you
specific
legal
rights,
and
you
may
have
other
rights
that
vary
from
state
to
state.
Choice
of
Law
and
Jurisdiction
This
Agreement
shall
be
governed
by
and
construed
in
accordance
with
the
laws
of
the
State
of
Michigan,
without
reference
to
any
conflict
of
law
principles.
You
agree
that
any
litigation
or
other
proceeding
between
you
and
Licensor
in
connection
with
the
Training
Materials
shall
be
brought
in
the
Michigan
state
or
courts
located
in
Port
Huron,
Michigan,
and
you
consent
to
the
jurisdiction
of
such
courts
to
decide
the
matter.
The
parties
agree
that
the
United
Nations
Convention
on
Contracts
for
the
International
Sale
of
Goods
shall
not
apply
to
this
License.
If
any
provision
of
this
Agreement
is
held
invalid,
the
remainder
of
this
License
shall
continue
in
full
force
and
effect.
Entire
Agreement
This
is
the
entire
agreement
between
the
parties
and
may
not
be
modified
except
in
writing
signed
by
both
parties.
IV
Table
of
Contents
Before
We
Begin
......................................................................................................................................
1
Feedback
..................................................................................................................................................
1
Additional
CCIETM
Preparation
Material
..................................................................................................
2
IPEXPERT
END-USER
LICENSE
AGREEMENT
.............................................................................................
3
Copyright
and
Proprietary
Rights
............................................................................................................
3
Exclusions
of
Warranties
.........................................................................................................................
4
Choice
of
Law
and
Jurisdiction
.................................................................................................................
4
Limitation
of
Claims
and
Liability
.............................................................................................................
4
Entire
Agreement
....................................................................................................................................
4
U.S.
Government
-
Restricted
Rights
.......................................................................................................
5
Chapter
1:
Introduction
to
IPv4/6
Multicast
Operation
and
Troubleshooting
.........................................
1-1
About
the
Authors
................................................................................................................................
1-2
About
the
Technical
Editors
..................................................................................................................
1-2
About
the
Technical
Consultant
...........................................................................................................
1-2
About
the
Editor
...................................................................................................................................
1-3
Who
Should
Read
this
Book?
................................................................................................................
1-3
How
to
Use
this
Book
...........................................................................................................................
1-3
An
Introduction
to
IPv4/6
Multicast
.....................................................................................................
1-4
An
Introduction
to
IPv4/6
Multicast
Troubleshooting
..........................................................................
1-5
Chapter
2:
Internet
Group
Management
Protocol
(IGMP)
.......................................................................
2-1
IGMP
Technology
Review
.....................................................................................................................
2-2
IGMP
Version
1
.................................................................................................................................
2-3
IGMP
Version
2
.................................................................................................................................
2-4
IGMP
Version
3
.................................................................................................................................
2-5
IGMP
Leave
Process
..........................................................................................................................
2-6
The
Operation
and
Troubleshooting
of
IGMP
......................................................................................
2-7
IGMP
Version
1
.................................................................................................................................
2-8
VI
VII
VIII
IX
XI
XII
XIII
XIV
XV
Chapter
1:
Introduction
to
IPv4/6
Multicast
Operation
and
Troubleshooting
Chapter
1:
Introduction
to
IPv4/6
Multicast
Operation
and
Troubleshooting
introduces
the
team
of
authors,
consultants,
and
editors
that
completed
this
book
and
describes
the
books
purpose.
This
chapter
also
provides
suggestions
for
the
usage
of
this
written
work.
This
introductory
chapter
also
covers
a
basic
overview
of
multicasts
operations
and
troubleshooting
concerns.
Readers
who
are
very
familiar
with
basic
multicast
principles
may
safely
skip
this
section.
1-1
1-2
1-3
www.proctorlabs.com.
These
sample
Trouble
Tickets
allow
students
to
build
confidence
and
expertise
by
actually
troubleshooting
issues
in
the
multicast
domain
presented
in
the
chapter.
Students
are
encouraged
to
follow
along
on
a
rack
of
equipment
for
every
section
of
every
chapter.
This
really
enhances
and
strengthens
the
learning
process.
1-4
The
Protocol
Independent
Multicast
(PIM)
protocol
is
responsible
for
routing
multicast
traffic
through
the
network
infrastructure.
As
the
name
of
this
protocol
conveys,
it
is
not
dependent
on
a
specific
unicast
routing
protocol;
it
is
IP
routing
protocol
independent
and
can
leverage
the
unicast
routing
protocol
used
to
populate
the
unicast
routing
table,
including
simple
static
routes.
PIM
relies
upon
this
unicast
routing
information
to
perform
the
multicast
forwarding
function.
PIM
uses
the
unicast
routing
table
to
perform
the
reverse
path
forwarding
(RPF)
check
function
instead
of
building
up
a
completely
independent
multicast
routing
table.
The
RPF
process
is
a
key
in
the
operation
and
subsequent
troubleshooting
of
multicast
As
such,
this
book
covers
the
RPF
process
in
depth
throughout
its
chapters.
Unlike
other
routing
protocols,
PIM
does
not
send
and
receive
routing
updates
between
routers.
PIM
can
operate
in
dense
mode
or
sparse
mode.
The
mode
determines
how
the
router
populates
its
multicast
routing
table
and
how
the
router
forwards
multicast
packets
it
receives
from
its
directly
connected
LANs.
1-5
Chapter
2:
Internet
Group
Management
Protocol
(IGMP)
In
this
chapter
of
IPv4/6
Multicast
Operation
and
Troubleshooting,
the
processes
and
functionality
of
the
Internet
Group
Management
Protocol
(IGMP)
are
examined
in
great
depth.
Once
the
operational
characteristics
of
this
important
protocol
are
detailed
completely,
the
focus
becomes
that
of
troubleshooting.
This
includes
the
careful
examination
of
symptoms,
a
fault
isolation
methodology,
and
the
implementation
of
repairs
for
the
Internet
Group
Management
Protocol
(IGMP).
The
chapter
begins
with
a
thorough
review
of
IGMP,
and
then
quickly
launches
in
to
an
exhaustive
analysis
of
the
art
of
troubleshooting
this
multicast
support
protocol.
This
important
chapter
concludes
with
sample
troubleshooting
scenarios,
reference
materials
for
the
most
important
show
and
debug
commands,
and
exciting
challenges
that
allow
readers
to
practice
implementing
the
troubleshooting
skills
they
have
obtained.
2-1
Figure
2-1:
A
Sample
IGMP
Topology
IGMP
version
1
-
provides
a
basic
query-response
mechanism
that
allows
the
multicast
router
to
determine
which
multicast
groups
are
active;
also
enables
hosts
to
join
and
leave
a
multicast
group
2-2
IGMP
version
2
introduces
the
IGMP
leave
process,
group
specific
queries,
and
an
explicit
maximum
response
time
field;
also
adds
the
capability
for
routers
to
elect
the
IGMP
querier
without
dependence
on
the
multicast
protocol
to
perform
this
task
IGMP
version
3
-
provides
source
filtering;
supports
the
link
local
address
224.0.0.22,
which
is
the
destination
IP
address
for
IGMP
version
3
membership
reports
Note:
By
default,
enabling
PIM
on
an
interface
enables
IGMP
version
2
on
that
interface.
IGMP
version
2
was
designed
to
be
as
backward
compatible
with
IGMP
version
1
as
possible.
IGMP
Version
1
IGMP
version
1
routers
send
IGMP
queries
to
the
"all-hosts"
multicast
address
of
224.0.0.1
to
solicit
multicast
groups
with
active
multicast
receivers.
The
multicast
receivers
also
send
IGMP
reports
to
the
router
to
notify
it
that
they
are
interested
in
receiving
a
particular
multicast
stream.
Hosts
can
send
the
report
independently
or
in
response
to
the
IGMP
queries
sent
by
the
router.
If
more
than
one
multicast
receiver
exists
for
the
same
multicast
group,
only
one
of
these
hosts
sends
an
IGMP
report
message;
the
other
hosts
suppress
their
report
messages.
In
IGMP
version
1,
there
is
no
election
of
an
IGMP
querier.
If
more
than
one
router
on
the
segment
exists,
all
the
routers
send
periodic
IGMP
queries.
IGMP
version
1
has
no
special
mechanism
by
which
the
hosts
can
leave
the
group.
If
the
hosts
are
no
longer
interested
in
receiving
multicast
packets
for
a
particular
group,
they
simply
do
not
reply
to
the
IGMP
query
packets
sent
from
the
router.
The
router
continues
sending
query
packets.
If
the
router
does
not
hear
a
response
in
three
IGMP
queries,
the
group
times
out
and
the
router
stops
sending
multicast
packets
on
the
segment
for
the
group.
If
there
are
multiple
routers
on
a
LAN,
a
designated
router
(DR)
must
be
elected
to
avoid
duplicating
multicast
traffic
for
connected
hosts.
PIM
routers
follow
an
election
process
to
select
a
DR.
The
PIM
router
with
the
highest
IP
address
becomes
the
DR.
The
DR
is
responsible
for
the
following
tasks:
Sending
PIM
register,
PIM
Join,
and
Prune
messages
toward
the
rendezvous
point
(RP)
to
inform
it
about
host
group
memberships
Sending
IGMP
host-query
messages
Sending
host-query
messages
in
order
to
keep
the
IGMP
overhead
on
hosts
and
networks
very
low
2-3
IGMP
Version
2
IGMP
version
2
improves
the
query
messaging
capabilities
of
IGMP
version
1.
The
query
and
membership
report
messages
in
IGMP
version
2
are
identical
to
the
IGMP
version
1
messages
with
two
exceptions:
IGMP
version
2
query
messages
are
broken
into
two
categories:
general
queries
(identical
to
IGMP
version
1
queries)
and
group-specific
queries
IGMP
version
1
membership
reports
and
IGMP
version
2
membership
reports
have
different
IGMP
type
codes
IGMP version 2 also enhances IGMP by providing support for the following capabilities:
Querier
election
processIGMP
version
2
routers
can
elect
the
IGMP
querier
without
having
to
rely
on
the
multicast
routing
protocol
to
perform
the
process
Maximum
Response
Time
fielda
new
field
in
query
messages
permits
the
IGMP
querier
to
specify
the
maximum
query-response
time;
this
feature
permits
the
tuning
of
the
query-
response
process
to
control
response
burstiness
and
to
fine-tune
leave
latencies
Group-Specific
Query
messagespermits
the
IGMP
querier
to
perform
the
query
operation
on
a
specific
group
instead
of
all
groups
Leave-Group
messagesprovides
hosts
with
a
method
of
notifying
routers
on
the
network
that
they
wish
to
leave
the
group
Unlike
IGMP
version
1,
in
which
the
DR
and
the
IGMP
querier
are
typically
the
same
router,
in
IGMP
version
2
the
two
functions
are
decoupled.
The
DR
and
the
IGMP
querier
are
selected
based
on
different
criteria
and
may
be
different
routers
on
the
same
subnet.
The
DR
is
the
router
with
the
highest
IP
address
on
the
subnet,
whereas
the
IGMP
querier
is
the
router
with
the
lowest
IP
address.
Query
messages
are
used
to
elect
the
IGMP
querier
as
follows:
Step
1
-
when
an
IGMP
version
2
router
starts,
they
each
multicast
a
general
query
message
to
the
all-
systems
group
address
of
224.0.0.1
with
their
interface
address
in
the
source
IP
address
field
of
the
message.
Step
2
-
when
an
IGMP
version
2
router
receives
a
general
query
message,
the
router
compares
the
source
IP
address
in
the
message
with
its
own
interface
address.
The
router
with
the
lowest
IP
address
on
the
subnet
is
elected
the
IGMP
querier.
Step
3
-
all
routers
(excluding
the
querier)
start
the
query
timer,
which
is
reset
whenever
a
general
query
message
is
received
from
the
IGMP
querier.
If
the
query
timer
expires,
it
is
assumed
that
the
IGMP
querier
has
gone
down,
and
the
election
process
is
performed
again
to
elect
a
new
IGMP
querier.
2-4
INCLUDE
mode
the
receiver
announces
membership
to
a
group
and
provides
a
list
of
IP
addresses
(the
INCLUDE
list)
from
which
it
wants
to
receive
traffic
EXCLUDE
modethe
receiver
announces
membership
to
a
group
and
provides
a
list
of
IP
addresses
(the
EXCLUDE
list)
from
which
it
does
not
want
to
receive
traffic;
to
receive
traffic
from
all
sources,
like
in
the
case
of
the
Internet
Standard
Multicast
(ISM)
service
model,
a
host
expresses
EXCLUDE
mode
membership
with
an
empty
EXCLUDE
list
IGMP
version
3
is
the
industry-designated
standard
protocol
for
hosts
to
signal
channel
subscriptions
in
a
Source
Specific
Multicast
(SSM)
network.
For
SSM
to
rely
on
IGMP
version
3,
IGMP
version
3
must
be
available
in
the
network
stack
portion
of
the
operating
systems
running
on
the
last
hop
routers,
hosts
and
be
used
by
the
applications
running
on
those
hosts.
In
IGMP
version
3,
hosts
send
their
membership
reports
to
224.0.0.22;
all
IGMP
version
3
routers,
therefore,
must
listen
to
this
address.
Hosts,
however,
do
not
listen
or
respond
to
224.0.0.22;
they
only
send
their
reports
to
that
address.
In
addition,
in
IGMP
version
3,
there
is
no
membership
report
suppression
because
IGMP
version
3
hosts
do
not
listen
to
the
reports
sent
by
other
hosts.
Therefore,
when
a
general
query
is
sent
out,
all
hosts
on
the
wire
respond.
When
a
host
wants
to
join
a
multicast
group,
the
host
sends
one
or
more
unsolicited
membership
reports
for
the
multicast
group
it
wants
to
join.
The
IGMP
join
process
is
the
same
for
IGMP
version
1
and
IGMP
version
2
hosts.
In
IGMP
version
3,
the
join
process
for
hosts
proceeds
as
follows:
When
a
hosts
wants
to
join
a
group,
it
sends
an
IGMP
version
3
membership
report
to
224.0.0.22
with
an
empty
EXCLUDE
list
When
a
host
wants
to
join
a
specific
channel,
it
sends
an
IGMP
version
3
membership
report
to
224.0.0.22
with
the
address
of
the
specific
source
included
in
the
INCLUDE
list
2-5
When
a
host
wants
to
join
a
group
excluding
particular
sources,
it
sends
an
IGMP
version
3
membership
report
to
224.0.0.22
excluding
those
sources
in
the
EXCLUDE
list
2-6
IP
multicast
environments
propagate
membership
information
via
Internet
Group
Management
Protocol
(IGMP).
IGMP
propagates
membership
information
from
the
host
toward
the
routers
attached
to
discreet
sources.
This
is
odd
behavior
when
compared
to
the
typical
unicast
routing
model.
So
odd,
in
fact,
that
many
phrases
exist
to
describe
this
process
including
"upside-down
routing"
or
"bottoms-up
routing.
It
is
important
to
understand
this
concept
early
on.
Multicasting
routes
packets
away
from
the
source
(toward
the
receivers)
not
toward
a
given
destination.
Understanding
this
one
concept
will
make
deploying
and
troubleshooting
IP
multicast
much
simpler.
In
summary,
routers
attached
to
multicast
sources
learn
about
group
members
via
IGMP.
This
section
will
take
an
exhaustive
look
at
the
operation
and
troubleshooting
of
the
three
versions
of
IGMP
protocol
by
using
the
topology
in
the
Figure
2-2.
2-7
IGMP
Version
1
A
critical
analysis
of
the
inner
working
of
IGMP
version
1
must
begin
with
the
protocol
message
types
it
supports:
IGMPv1
Membership
Query
Messages
-
Generated
by
the
IGMP
querier
-
One
multicast
router
per
LAN
must
periodically
transmit
host
"membership
query
messages".
These
messages
identify
which
groups
have
members
on
a
directly
connected
network.
Query
Messages
use
an
address
of
224.0.0.1.
An
adjacent
router
does
not
forward
query
messages
to
any
other
multicast
enabled
router.
IGMPv1
Membership
Report
Messages
-
Generated
by
the
hosts
-
When
a
host
receives
an
IGMP
query
message
it
responds
with
a
membership
report.
The
membership
report
identifies
the
groups
that
a
host
has
joined.
These
two
message
types
are
part
of
a
two-phase
mechanism
where,
an
IGMP
version
1
host
sends
a
report
when
it
joins
a
multicast
group.
In
order
to
configure
a
router
to
utilize
IGMP
version
1
protocol
it
is
necessary
to
apply
the
ip
igmp
version
1
command
at
the
interface
level:
interface FastEthernet0/0
ip address 172.16.100.2 255.255.255.0
ip igmp version 1
An
IGMP
version
1
router
(known
as
a
querier)
queries
periodically
using
query
messages
to
dynamically
identify
active
members
of
groups.
Whenever
a
host
receives
a
query
message,
it
responds
with
membership
report
messages
for
all
its
associated
multicast
groups.
The
host
sends
an
individual
membership
report
for
each
multicast
group
it
has
joined
to
the
querier.
A
host
will
wait
a
random
2-8
period
between
responses
to
queries
(no
more
than
10
seconds)
for
each
group
it
has
joined.
This
delay
affords
the
host
time
to
receive
a
valid
report
sent
by
another
device
on
the
segment.
If
a
host
does
not
receive
a
report
from
another
host
on
the
same
segment
during
the
delay
period,
it
will
generate
a
membership
report
itself.
If
a
host
does
receive
a
membership
report
from
another
host
for
one
of
its
multicast
group
associations,
it
will
suppress
its
own
membership
report
for
that
group.
This
process
prevents
a
"storm"
of
membership
report
messages.
Observe
this
behavior
in
the
output
provided
by
the
debug
ip
igmp
command
on
R2:
R2#
IGMP(0): Received v1 Query on GigabitEthernet0/0 from 172.16.100.1
IGMP(0): Set report delay time to 0.2 seconds for 224.7.7.7 on GigabitEthernet0/0
IGMP(0): Send v1 Report for 224.7.7.7 on GigabitEthernet0/0
On
R1
we
can
see
the
report
for
the
group
address
224.0.1.40
being
canceled.
R1#
IGMP(0): Received v2 Report on FastEthernet0/0 from 172.16.100.5 for 224.0.1.40
IGMP(0): Received Group record for group 224.0.1.40, mode 2 from 172.16.100.5 for 0
sources
IGMP(0): Cancel report for 224.0.1.40 on FastEthernet0/0
When
the
querier
receives
a
membership
report
for
a
given
group,
it
will
start
an
EXCLUDE
Group
timer.
The
querier
will
remove
group
membership
information
not
refreshed
by
a
subsequent
membership
report
sent
in
response
to
periodic
general
queries,
within
the
configured
EXCLUDE
group
timer.
First,
we
see
the
EXCLUDE
timer
update
in
the
output
of
the
debug
ip
igmp
command
on
R4
when
the
membership
report
arrives:
R4#
IGMP(0): Received v1 Report on FastEthernet0/0 from 172.16.100.2 for 224.7.7.7
IGMP(0): Received Group record for group 224.7.7.7, mode 2 from 172.16.100.2 for 0
sources
IGMP(0): Updating EXCLUDE group timer for 224.7.7.7
This
output
clearly
illustrates
the
process
we
have
just
described.
The
querier
received
the
IGMP
version
1
membership
report
from
172.16.100.2
for
the
group
224.7.7.7.
The
router
in
question
has
no
knowledge
of
an
active
source,
but
it
still
resets
the
EXCLUDE
group
timer.
At
first
blush,
the
IGMP
version
1
protocol
seems
to
accomplish
all
the
goals
we
have
discussed
to
date.
However,
this
version
IGMP
does
have
one
huge
Achilles
heel.
Hosts
have
no
special
mechanism
to
allow
them
to
leave
a
group.
As
stated
earlier
in
the
IGMP
Technology
Review,
in
IGMP
version
1
a
host
that
no
longer
needs
to
receive
multicast
packets
for
a
particular
group,
simply
stops
replying
to
the
IGMP
query
packets
sent
from
the
router.
2-9
The
router
will
continue
sending
queries
and
only
stops
sending
queries
on
the
network
for
the
group
after
three
consecutive
query
messages
go
unanswered.
If
a
host
on
the
segment
wants
to
receive
multicast
packets
after
this
timeout
period,
it
simply
sends
a
new
IGMP
join
to
the
router,
and
the
router
will
begin
forwarding
the
packets
once
more.
Some
call
this
long
period
needed
to
identify
the
loss
of
an
active
multicast
member
"leave
latency".
IGMP
Version
2
IGMP
version
2
introduced
a
number
of
critical
changes
to
IGMP.
These
modifications
made
IGMP
more
efficient
by
adding
a
new
operational
mechanism,
and
two
additional
message
types.
The
new
operational
mechanism
involves
the
election
of
the
IGMP
querier.
In
IGMP
version
1
more
than
one
device
on
a
segment
could
and
often
does
send
IGMP
version
1
queries
as
illustrated
by
the
following
debug
ip
igmp
output
on
R2:
R2#show logging |
IGMP(0): Received
IGMP(0): Received
IGMP(0): Received
This
output
demonstrates
that
R2
has
received
IGMP
version
1
Query
messages
on
GigabitEthernet0/0
from
each
of
its
neighbors
on
the
VLAN
1245
segment.
Recognizing
that
having
more
than
one
device
on
a
segment
constantly
sending
query
messages
was
less
than
ideal;
this
behavior
in
IGMP
version
2
was
changed.
Once
we
execute
the
ip
igmp
version
2
commands
at
the
interface
level
on
R1,
R2,
R4
and
R5
the
devices
will
now
elect
a
single
querier
for
the
VLAN
1245
segment.
The
router
with
the
lowest
IP
address
on
the
segment
becomes
the
querier.
In
the
case
of
this
topology,
the
process
chooses
R1.
Verify
this
with
show
ip
igmp
interface
on
any
device
connected
to
VLAN
1245:
R2#show ip igmp interface
GigabitEthernet0/0 is up, line protocol is up
Internet address is 172.16.100.2/24
IGMP is enabled on interface
Current IGMP host version is 2
Current IGMP router version is 2
IGMP query interval is 60 seconds
IGMP querier timeout is 120 seconds
IGMP max query response time is 10 seconds
Last member query count is 2
Last member query response interval is 1000 ms
Inbound IGMP access group is not set
IGMP activity: 4 joins, 1 leaves
Multicast routing is enabled on interface
Multicast TTL threshold is 0
Multicast designated router (DR) is 172.16.100.5
IGMP querying router is 172.16.100.1
Multicast groups joined by this system (number of users):
2-10
224.0.1.40(1)
224.7.7.7(1)
This
command
provides
a
lot
of
output.
The
third
line
from
the
bottom
identifies
R1
as
the
IGMP
querying
router
by
its
IP
address
172.16.100.1.
Note
that
the
output
notifies
us
that
the
current
IGMP
host
version
is
2,
and
that
the
current
IGMP
router
version
is
2.
IGMP
version
2
is
backwards
compatible
with
IGMP
version
1.
This
is
possible
because
IGMP
version
2
still
supports
IGMP
version
1
query
and
report
messages.
Where
IGMP
version
1
had
2
types
of
messages,
IGMP
version
2
has
three:
query
messages,
report
messages
and
leave
group
messages.
IGMP
version
2
-
Query
Messages
An
IGMP
version
2
querier
sends
two
types
of
query
messages:
IGMPv2
General
Query
Messages
-
Created
by
the
querier
-
Allows
dynamic
discovery
of
all
multicast
group
members
on
a
segment.
IGMPv2
Group-Specific
Query
Messages
-
Created
by
the
querier
-
Used
to
identify
the
existence
of
any
members
for
a
specific
group.
We
see
that
R1
has
sent
a
IGMP
version
2
general
Query.
Removing
the
group
membership
to
224.7.7.7
from
the
GigabitEthernet0/0
interface
of
R2
will
force
R1
to
send
a
group-specific
query:
R2(config)#interface GigabitEthernet0/0
R2(config-if)#no ip igmp join-group 224.7.7.7
Note
that
R1
sent
an
IGMP
version
2
query
specifically
for
the
group
224.7.7.7.
IGMP
version
2
-
Report
Messages
An
IGMP
version
2
host
will
send
IGMP
version
2
report
messages
under
the
following
circumstances:
2-11
On
joining
a
multicast
group
-
the
host
will
immediately
notify
the
elected
querier
that
it
has
actively
joined
a
multicast
group.
Upon
receiving
a
General
Query
-
the
host
will
send
a
report
after
a
random
delay
in
the
same
fashion
employed
in
IGMP
version
1
in
response
to
a
general
query.
Upon
receiving
a
Group-Specific
Query
-
the
host
will
send
a
report
in
response
to
a
group-
specific
query
if
it
is
a
member
of
the
group
queried.
R2
deletes
the
group,
sends
the
leave
message,
and
adjusts
the
expiration
timer
for
its
224.7.7.7
entry
to
2
secs.
This
results
in
an
efficient
leave
process
and
the
IGMP
version
2
router
will
stop
forwarding
the
multicast
packets
for
this
group.
IGMP
Version
3
This
enhancement
to
IGMP
introduced
the
concept
of
Group-Source
Report
messages.
As
stated
earlier
in
the
IGMP
Technology
Review,
these
messages
allow
a
host
to
elect
to
receive
traffic
from
specific
2-12
sources
of
a
multicast
group;
a
concept
referred
to
as
Source
Specific
Multicast
(SSM).
Chapter
13:
Multicast
Security
and
Advanced
Features
will
cover
this
topic
in
depth.
IGMP
and
Multicast
Forwarding
IGMP
is
part
of
the
last
leg
of
multicast
packet
delivery.
This
is
because
IGMP
is
only
concerned
with
forwarding
multicast
traffic
from
the
local
router
to
a
group
of
members
that
share
a
common
network.
IGMP
is
a
host-to-router
communications
protocol.
For
router-to-router
delivery
of
multicast
services,
it
is
mandatory
to
define
multicast
routing
protocols.
These
protocols
are
outside
the
scope
of
this
chapter,
but
IGMP
is
an
integral
component
to
these
protocols.
The
role
of
IGMP
is
to
notify
the
querier/IGMP
router,
of
the
existence
of
devices
that
have
joined
multicast
groups
or
group
ranges.
We
have
thoroughly
examined
the
operational
mechanisms
for
each
version
of
IGMP
in
the
previous
sections
of
this
chapter.
Now
we
will
look
at
the
general
operational
process
of
IGMP
as
it
relates
to
the
overall
multicast
process:
Step
One
-
The
client/host
sends
an
IGMP
join
message
to
a
designated
multicast
router.
The
destination
MAC
address
maps
to
the
Class
D
address
of
the
group
being
joined
not
to
the
MAC
address
of
the
router.
The
body
of
the
IGMP
datagram
also
includes
the
Class
D
group
address.
Step
Two
-
The
IGMP
router
logs
the
join
message
and
uses
a
multicast
routing
protocol
(covered
later
in
this
document)
to
add
this
segment
to
the
multicast
distribution
tree.
Step
Three
-
IP
multicast
traffic
is
then
transmitted
from
the
server
via
the
designated
router.
The
designated
router
manages
the
distribution
of
multicast
packets
to
the
host's
subnet.
The
destination
MAC
address
that
is
used
corresponds
to
the
Class
D
address
of
the
multicast
group.
Step
Four
-
The
switch
receives
the
multicast
packet
and
examines
its
forwarding
table.
If
no
entry
exists
for
the
MAC
address,
the
packet
will
be
flooded
to
all
ports
within
the
broadcast
domain.
If
an
entry
does
exist
in
the
switch
table,
only
the
designated
ports
will
forward
packets.
Step
Five
-
With
IGMP
version
2,
the
client
can
end
a
group
membership
by
sending
an
IGMP
leave
message
to
the
router.
With
IGMP
version
1,
the
client
remains
a
member
of
the
group
until
it
fails
to
send
a
join
message
in
response
to
a
query
from
the
router.
Multicast
routers
also
periodically
send
an
IGMP
query
to
the
"all
multicast
hosts"
group
(224.0.0.1)
or
if
using
IGMP
version
2,
to
a
specific
multicast
group
on
the
subnet
to
determine
which
groups
are
still
active
within
the
subnet.
Each
host
delays
its
response
to
a
query
for
a
small
random
period
and
will
only
respond
if
no
other
hosts
in
the
group
have
already
responded.
This
mechanism
prevents
multiple
hosts
from
congesting
the
network
with
simultaneous
reports.
2-13
2-14
host,
it
removes
the
host
port
from
the
table
entry.
It
also
periodically
deletes
entries
if
it
does
not
receive
IGMP
membership
reports
from
any
multicast
clients.
The
most
common
issue
that
can
cause
problems
where
a
switch
does
not
forward
IGMP
messages
are
where
IGMP
Filtering
and
Throttling
have
been
erroneously
configured,
or
previous
configurations
have
not
been
completely
removed.
IGMP
Filtering
-
filters
multicast
joins
on
a
per-port
basis
by
configuring
IP
multicast
profiles
and
associating
them
with
individual
switch
ports.
IGMP
filtering
controls
only
group-specific
query
and
membership
reports,
including
join
and
leave
reports
and
does
not
control
general
IGMP
queries.
IGMP
filtering
is
applicable
only
to
the
dynamic
learning
of
IP
multicast
group
addresses,
not
static
configuration.
IGMP
Throttling
-
throttling
sets
the
maximum
number
of
IGMP
groups
that
Layer
2
interfaces
can
join.
Utilization
of
this
technique
can
cause
a
switch
to
drop
IGMP
membership
reports.
Apply
IGMP
Filtering
using
the
ip
igmp
filter
command.
Apply
IGMP
Throttling
using
the
ip
igmp
max-
groups
command.
Both
are
interface
level
commands.
IGMP
Packet
Filtering
IGMP
Throttling
and
Filtering
deal
with
IGMP
packets
at
Layer
2
on
a
switch.
There
are
versions
of
the
same
concepts
designed
to
function
at
Layer
3.
On
routers,
the
ip
igmp
access-group
and
ip
igmp
limit
commands
accomplish
these
same
goals:
ip
igmp
access-group
-
used
to
filter
groups
from
IGMP
membership
reports
by
applying
a
standard
access
list.
This
command
restricts
hosts
on
a
subnet
to
joining
only
multicast
groups
permitted
by
the
configured
standard
IP
access
list.
ip
igmp
limit
-
used
to
configure
a
limit
on
the
number
of
mroute
states
that
are
created
as
a
result
of
IGMP
membership
reports
(IGMP
joins).
Membership
reports
exceeding
the
configured
limits
do
not
enter
the
IGMP
cache.
The
most
common
issue
that
can
cause
problems
where
a
router
does
not
accept
IGMP
join
messages
are
where
IGMP
Filtering
or
limiting
have
been
erroneously
configured,
or
previous
configurations
have
not
been
completely
removed.
In
the
IGMP
Sample
Troubleshooting
Scenarios
section
that
follows,
troubleshooting
of
these
issues
are
demonstrated.
For
each
problem,
the
text
demonstrates
how
to
quickly
and
efficiently
verify
each
symptom,
isolate
the
cause,
and
remediate
the
issue.
2-15
In
the
Common
Issues
with
IGMP
section,
three
primary
types
of
problems
were
identified:
Host
Fails
to
Send
IGMP
joins;
Switch
Fails
to
Forward
IGMP
Packets,
and
IGMP
Packet
Filtering.
This
section
explores
these
three
categories
of
failure,
by
directing
our
attention
to
the
commands
necessary
to
identify
that
a
problems
exists.
There
are
three
types
of
devices
in
this
topology:
Hosts
(R2,
R4
and
R5),
FastEthernet
Switch
(CAT1),
and
an
IGMP
router
(R1).
Host
Fails
To
Send
IGMP
Joins
This
situation
is
where
a
host
does
not
send
membership
reports
for
a
specific
multicast
group
address.
The
best
tool
available
in
our
troubleshooting
arsenal
to
verify
the
existence
of
this
type
of
problem
is
the
debug
ip
igmp
command:
R2#debug ip igmp
IGMP debugging is on
R2#
IGMP(0): Received v2 Query on GigabitEthernet0/0 from 172.16.100.1
IGMP(0): Set report delay time to 3.1 seconds for 224.0.1.40 on GigabitEthernet0/0
R2#
IGMP(0): Received v2 Report on GigabitEthernet0/0 from 172.16.100.1 for 224.0.1.40
2-16
IGMP(0):
sources
IGMP(0):
IGMP(0):
IGMP(0):
Received Group record for group 224.0.1.40, mode 2 from 172.16.100.1 for 0
Cancel report for 224.0.1.40 on GigabitEthernet0/0
Updating EXCLUDE group timer for 224.0.1.40
MRT Add/Update GigabitEthernet0/0 for (*,224.0.1.40) by 0
R2
is
receiving
IGMP
membership
reports,
but
it
is
not
sending
any
for
224.2.2.2.
Based
on
Figure
2-3,
R2's
GigabitEthernet0/0
interface
should
have
joined
the
group
224.2.2.2.
The
quickest
and
simplest
way
to
determine
what
multicast
groups
a
device
has
joined
on
an
interface-by-interface
basis
is
to
execute
the
show
ip
igmp
interface
command:
R2#show ip igmp interface
GigabitEthernet0/0 is up, line protocol is up
Internet address is 172.16.100.2/24
IGMP is enabled on interface
Current IGMP host version is 2
Current IGMP router version is 2
IGMP query interval is 60 seconds
IGMP querier timeout is 120 seconds
IGMP max query response time is 10 seconds
Last member query count is 2
Last member query response interval is 1000 ms
Inbound IGMP access group is not set
IGMP activity: 9 joins, 7 leaves
Multicast routing is enabled on interface
Multicast TTL threshold is 0
Multicast designated router (DR) is 172.16.100.5
IGMP querying router is 172.16.100.1
Multicast groups joined by this system (number of users):
224.0.1.40(1)
This
output
indicates
that
R2
has
only
joined
the
multicast
group
224.0.1.40
on
GigabitEthernet0/0.
There
is
no
listing
for
224.2.2.2.
According
to
Figure
2-3,
this
address
should
appear
here.
To
verify
why,
the
next
step
would
be
to
look
for
an
ip
igmp
join-group
command
under
GigabitEthernet0/0
for
the
group
224.2.2.2:
R2#show run interface GigabitEthernet0/0
Building configuration...
Current configuration : 116 bytes
!
interface GigabitEthernet0/0
ip address 172.16.100.2 255.255.255.0
ip pim dense-mode
duplex auto
speed auto
end
2-17
The
join
command
is
missing.
Applying
the
ip
igmp
join-group
224.2.2.2
command
on
the
GigabitEthernet0/0
interface
of
R2
will
force
R2
to
begin
sending
IGMP
version
2
membership
reports
on
the
VLAN
1245
segment
for
224.2.2.2.
R2(config)#interface GigabitEthernet0/0
R2(config-if)#ip igmp join-group 224.2.2.2
R2(config-if)#end
%SYS-5-CONFIG_I: Configured from console by console
R2#debug ip igmp
IGMP debugging is on
IGMP(0): Send v2 Report for 224.2.2.2 on GigabitEthernet0/0
IGMP(0): Received v2 Report on GigabitEthernet0/0 from 172.16.100.2 for 224.2.2.2
IGMP(0): Received Group record for group 224.2.2.2, mode 2 from 172.16.100.2 for 0
sources
IGMP(0): Updating EXCLUDE group timer for 224.2.2.2
IGMP(0): MRT Add/Update GigabitEthernet0/0 for (*,224.2.2.2) by 0
The
IGMP
membership
reports
are
being
transmitted
for
the
group
224.4.4.4,
based
on
the
debug
output.
What
device
is
acting
as
the
querier
on
the
VLAN
1245
segment?
This
can
be
determined
with
the
show
ip
igmp
interface
command:
R4#show ip igmp interface FastEthernet0/0
FastEthernet0/0 is up, line protocol is up
Internet address is 172.16.100.4/24
2-18
The
third
line
from
the
bottom
of
this
show
output
indicates
that
the
membership
reports
are
being
sent
to
R1
(172.16.100.1).
Step
2:
Are
the
IGMP
version
2
membership
reports
making
it
to
the
querier?
The
answer
to
this
question
is
best
provided
by
the
output
of
the
show
ip
igmp
groups
command:
R1#show ip igmp groups
IGMP Connected Group Membership
Group Address
Interface
Accounted
224.4.4.4
FastEthernet0/0
224.5.5.5
FastEthernet0/0
224.2.2.2
FastEthernet0/0
224.0.1.40
FastEthernet0/1
224.0.1.40
FastEthernet0/0
Uptime
Expires
Last Reporter
00:11:12
01:05:44
00:37:20
1d02h
1d02h
00:02:19
00:02:21
00:02:14
00:02:21
00:02:13
172.16.100.4
172.16.100.5
172.16.100.2
172.16.17.7
172.16.100.4
Group
The
output
indicates
that
R1
does
indeed
know
about
the
multicast
group
224.4.4.4,
and
it
did
indeed
learn
about
the
Group
Address
membership
from
the
"Last
Reporter"
R4
(172.16.100.4).
In
a
situation
where
the
host
is
sending
the
membership
report
and
the
IGMP
router
is
not
receiving
it,
a
logical
assumption
is
that
the
switch
is
blocking
it.
Step
Three:
Is
the
switch
blocking
or
limiting
the
IGMP
traffic?
The
switch
in
this
topology
is
CAT1.
The
easiest
way
to
learn
what
multicast
enabled
IGMP
devices
are
connected
to
the
switch
is
by
using
the
show
ip
igmp
snooping
mrouter
command:
CAT1#show ip igmp snooping mrouter
Vlan
ports
2-19
---1245
After
identifying
what
ports
are
connected
to
IGMP
enabled
routers
on
the
catalyst
switch,
the
next
step
is
to
verify
if
there
are
any
commands
configured
on
the
switch
that
will
alter
the
forwarding
of
IGMP
packets.
The
first
thing
to
look
for
is
if
the
ip
igmp
filter
and/or
ip
igmp
max-groups
command(s)
have
been
applied
to
any
of
these
interfaces:
CAT1#show run interface FastEthernet0/5
Building configuration...
Current configuration : 150 bytes
!
interface FastEthernet0/5
switchport access vlan 1245
switchport mode access
spanning-tree portfast
ip igmp max-groups 5
ip igmp filter 1
end
The
output
of
this
command
on
CAT1
for
the
interface
connected
to
R5
illustrates
examples
of
the
commands
we
are
looking
for.
In
this
particular
instance,
the
configured
commands
are
not
effecting
the
current
environment.
IGMP
Packet
Filtering
This
situation
occurs
when
a
host
transmits
a
membership
report
for
a
given
multicast
group,
but
the
Layer
3
router
drops
or
fails
to
forward
these
packets.
The
quickest
method
to
isolate
this
type
of
problem
is
to
look
for
Inbound
IGMP
access
groups
or
Interface
IGMP
State
Limits
configured
on
the
IGMP
router
via
the
show
ip
igmp
interface
command:
R1#show ip igmp interface FastEthernet0/0
FastEthernet0/0 is up, line protocol is up
Internet address is 172.16.100.1/24
IGMP is enabled on interface
Current IGMP host version is 2
Current IGMP router version is 2
IGMP query interval is 60 seconds
IGMP querier timeout is 120 seconds
IGMP max query response time is 10 seconds
Last member query count is 2
Last member query response interval is 1000 ms
Inbound IGMP access group is 1
IGMP activity: 14 joins, 10 leaves
Interface IGMP State Limit : 4 active out of 10 max
Multicast routing is enabled on interface
Multicast TTL threshold is 0
Multicast designated router (DR) is 172.16.100.5
IGMP querying router is 172.16.100.1 (this system)
Multicast groups joined by this system (number of users):
224.0.1.40(1)
2-20
Note
that
the
seventh
line
up
from
the
bottom
notifies
us
that
the
interface
will
support
only
10
maximum
IGMP
groups.
The
ninth
line
up
from
the
bottom
identifies
a
standard
access-list
has
been
applied
to
the
interface.
In
this
environment,
there
are
no
issues
on
R1,
but
if
there
were;
a
closer
examination
of
the
access-list
or
the
maximum
IGMP
state
limit
could
isolate
a
fault.
show
COMMAND:
show
ip
igmp
[vrf
vrf-name]
interface
[interface-type
interface-number]
This
command
displays
multicast-related
information
about
an
interface.
Where:
EXAMPLE
OUTPUT:
R2#show ip igmp interface GigabitEthernet0/0
GigabitEthernet0/0 is up, line protocol is up
Internet address is 172.16.100.2/24
IGMP is enabled on interface
Current IGMP host version is 2
Current IGMP router version is 2
2-21
show
COMMAND:
show
ip
igmp
[vrf
vrf-name]
groups
[group-name
|
group-address
|
interface-type
interface-number]
[detail]
This
command
displays
the
multicast
groups
with
receivers
directly
connected
to
the
router
and
learned
through
IGMP.
Where:
EXAMPLE
OUTPUT:
R1#show ip igmp groups
IGMP Connected Group Membership
Group Address
Interface
Accounted
224.4.4.4
FastEthernet0/0
224.5.5.5
FastEthernet0/0
224.2.2.2
FastEthernet0/0
224.0.1.40
FastEthernet0/1
224.0.1.40
FastEthernet0/0
Uptime
Expires
Last Reporter
Group
02:04:36
00:00:24
02:04:31
1d06h
1d06h
00:02:38
00:02:35
00:02:34
00:02:37
00:02:35
172.16.100.4
172.16.100.5
172.16.100.2
172.16.17.7
172.16.100.4
Ac
Ac
Ac
Ac
2-22
show
COMMAND:
show
ip
igmp
snooping
[groups
[count
|
vlan
vlan-id
[ip-address
|
count]]
|
mrouter
[[vlan
vlan-id]
|
[bd
bd-id]]
|
querier
|
vlan
vlan-id
|
bd
bd-id]
This
command
displays
the
IGMP
snooping
configuration
of
a
device.
Where:
EXAMPLE
OUTPUT:
CAT1#show ip igmp snooping mrouter
Vlan
ports
-------1245
Gi0/2(dynamic), Fa0/1(dynamic), Fa0/4(dynamic),
Fa0/5(dynamic)
2-23
debug
COMMAND:
debug
ip
igmp
[vrf
vrf-name]
[group-address]
This
command
displays
IGMP
packets
received
and
sent,
and
IGMP-host
related
events.
Where:
EXAMPLE
OUTPUT:
IGMP(0):
IGMP(0):
IGMP(0):
IGMP(0):
IGMP(0):
sources
IGMP(0):
IGMP(0):
IGMP(0):
2-24
debug
COMMAND:
debug
ip
igmp
snooping
{group
|
management
|
router
|
timer}
This
command
displays
the
mappings
for
the
PIM
group
to
the
active
Rendezvous
Point(s).
Where:
EXAMPLE
OUTPUT:
CAT1#debug ip igmp snooping router
IGMPSN: router: Received IGMP pak on Vlan 1245, port Fa0/1
IGMPSN: router: Is a router port on Vlan 1245, port Fa0/1
IGMPSN: router: Learning port: Fa0/1 as rport on Vlan 1245
2-25
Trouble
Ticket
#1
Your
supervisor
has
brought
to
your
attention
that
R2
is
not
generating
IGMP
version
2
membership
reports
for
the
multicast
group
224.2.2.2.
Correct
this
issue.
Trouble
Ticket
#2
After
solving
Trouble
Ticket
#1,
your
supervisor
has
observed
that
membership
reports
generated
by
R4
for
the
multicast
group
224.4.4.4
are
not
making
it
to
the
IGMP
router.
Correct
this
issue.
Trouble
Ticket
#3
Your
supervisor
has
notified
you
that
membership
reports
generated
by
R2
for
the
multicast
group
224.2.2.2
are
not
making
it
into
the
IGMP
Groups
table
on
R1.
Correct
this
issue
without
the
removal
of
existing
configurations.
2-26
Figure
2-7:
IGMP
Quick
Fire
Troubleshooting
Flowchart
Trouble
Ticket
#1
Solution
Your
supervisor
has
brought
to
your
attention
that
R2
is
not
generating
IGMP
version
2
membership
reports
for
the
multicast
group
224.2.2.2.
Correct
this
issue.
Step
1
-
Fault
Verification:
Is
R2
generating
IGMP
version
2
membership
reports?
R2#debug ip igmp
IGMP debugging is on
R2#
IGMP(0): Received v2 Query on GigabitEthernet0/0 from 172.16.100.1
IGMP(0): Set report delay time to 3.8 seconds for 224.0.1.40 on GigabitEthernet0/0
2-27
R2#
IGMP(0):
IGMP(0):
sources
IGMP(0):
IGMP(0):
IGMP(0):
R2
is
receiving
reports
and
queries
but
is
not
sending
reports
for
224.2.2.2.
This
verifies
that
the
problem
actually
exists.
Step
2
-
Fault
Isolation:
The
next
course
of
action
is
to
use
the
show
ip
igmp
interface
command
on
R2.
R2#show ip igmp interface
GigabitEthernet0/0 is up, line protocol is up
Internet address is 172.16.100.2/24
IGMP is enabled on interface
Current IGMP host version is 2
Current IGMP router version is 2
IGMP query interval is 60 seconds
IGMP querier timeout is 120 seconds
IGMP max query response time is 10 seconds
Last member query count is 2
Last member query response interval is 1000 ms
Inbound IGMP access group is not set
IGMP activity: 11 joins, 9 leaves
Multicast routing is enabled on interface
Multicast TTL threshold is 0
Multicast designated router (DR) is 172.16.100.5
IGMP querying router is 172.16.100.1
Multicast groups joined by this system (number of users):
224.0.1.40(1)
The
last
line
of
the
output
does
not
list
224.2.2.2
as
a
group
that
R2
has
joined.
This
is
most
likely
a
missing
or
erroneous
configuration
of
the
ip
igmp
join-group
command
under
the
GigabitEthernet0/0
interface.
This
is
verified
with
the
show
run
interface
command
on
R2:
R2#show run interface GigabitEthernet0/0
Building configuration...
Current configuration : 116 bytes
!
interface GigabitEthernet0/0
ip address 172.16.100.2 255.255.255.0
ip pim dense-mode
2-28
duplex auto
speed auto
end
This
isolates
the
fault.
Step
3
-
Fault
Remediation:
In
this
scenario,
the
ip
igmp
join-group
224.2.2.2
command
needs
to
be
applied
to
the
GigabitEthernet0/0
interface
of
R2.
R2(config)#interface GigabitEthernet0/0
R2(config-if)#ip igmp join-group 224.2.2.2
R2(config-if)#end
R2
is
now
sending
membership
reports
for
the
group
224.2.2.2.
The
solution
has
successfully
remediated
the
problem.
Trouble
Ticket
#2
Solution
After
solving
Trouble
Ticket
#1,
your
supervisor
has
observed
that
membership
reports
generated
by
R4
for
the
multicast
group
224.4.4.4
are
not
making
it
to
the
IGMP
router.
Correct
this
issue.
Step
1
-
Fault
Verification:
Does
R1
have
a
record
of
the
IGMP
joins
for
the
group
224.4.4.4?
R1#show ip igmp groups
IGMP Connected Group Membership
Group Address
Interface
Accounted
224.5.5.5
FastEthernet0/0
224.0.1.40
FastEthernet0/1
Uptime
Expires
Last Reporter
Group
00:47:43
1d06h
00:02:37
00:02:16
172.16.100.5
172.16.17.7
Ac
2-29
224.0.1.40
FastEthernet0/0
1d06h
00:02:30
172.16.100.2
Ac
R1
has
no
record
of
the
group
224.4.4.4.
Thus
proving
the
problem
exists.
Step
2
-
Fault
Isolation:
Now,
the
first
step
is
to
determine
if
R1
even
receives
the
membership
reports
from
R4
at
all.
R1#debug ip igmp
IGMP debugging is on
R1#
IGMP(0): Received v2 Report on FastEthernet0/0 from 172.16.100.2 for 224.2.2.2
IGMP(*): Group 224.2.2.2 access denied on FastEthernet0/0
IGMP(0): Received v2 Report on FastEthernet0/0 from 172.16.100.5 for 224.5.5.5
IGMP(0): Received Group record for group 224.5.5.5, mode 2 from 172.16.100.5 for 0
sources
IGMP(0): Updating EXCLUDE group timer for 224.5.5.5
IGMP(0): MRT Add/Update FastEthernet0/0 for (*,224.5.5.5) by 0
R1
receives
membership
reports
for
the
groups
224.2.2.2
and
224.5.5.5
but
not
224.4.4.4.
This
means
that
the
next
step
of
the
verification
needs
to
be
on
CAT1.
Use
the
debug
ip
igmp
filter
command
on
CAT1
to
identify
any
interfaces
that
may
have
profiles
filtering
specific
multicast
groups:
CAT1#debug ip igmp filter
event debugging is on
CAT1#
IGMPFILTER: igmp_filter_process_pkt() checking group from Gi0/2 : no profile attached
CAT1#
IGMPFILTER: igmp_filter_process_pkt(): checking group 224.4.4.4 from Fa0/4: deny
CAT1
has
an
igmp-filter
applied
on
interface
FastEthernet0/4
that
denies
the
multicast
group
224.4.4.4.
The
actual
parameters
of
the
profile
can
be
seen
via
the
show
ip
igmp
profile
command:
CAT1#show ip igmp profile
IGMP Profile 1
range 224.4.4.4 224.4.4.4
2-30
Uptime
Expires
Last Reporter
Group
00:00:28
01:06:49
1d07h
1d07h
00:02:31
00:02:24
00:02:17
00:02:22
172.16.100.4
172.16.100.5
172.16.17.7
172.16.100.1
Ac
Ac
Ac
R1,
the
IGMP
router,
now
sees
the
group
224.4.4.4.
Thus
verifying
that
the
error
has
been
corrected.
Trouble
Ticket
#3
Solution
Your
supervisor
has
notified
you
that
membership
reports
generated
by
R2
for
the
multicast
group
224.2.2.2
are
not
making
it
into
the
IGMP
Groups
table
on
R1.
Correct
this
issue
without
the
removal
of
existing
configurations.
Step
1
-
Fault
Verification:
Are
membership
reports
from
R2
for
the
group
224.2.2.2
making
it
to
R1?
R1#debug ip igmp
IGMP debugging is on
R1#
IGMP(0): Received v2 Report on FastEthernet0/0 from 172.16.100.2 for 224.2.2.2
IGMP(*): Group 224.2.2.2 access denied on FastEthernet0/0
R1#
R1
is
receiving
the
membership
reports
from
R2
but
they
are
being
actively
denied
on
FastEthernet0/0,
thus
verifying
the
validity
of
the
trouble
ticket.
Step
2
-
Fault
Isolation:
To
determine
why
the
IGMP
packets
for
the
group
224.2.2.2
are
being
dropped
use
the
show
ip
igmp
interface
command.
R1#show ip igmp interface FastEthernet0/0
FastEthernet0/0 is up, line protocol is up
Internet address is 172.16.100.1/24
IGMP is enabled on interface
Current IGMP host version is 2
Current IGMP router version is 2
IGMP query interval is 60 seconds
2-31
We
see
that
we
have
a
IGMP
State
limit
of
10
maximum
groups,
but
we
only
have
3
active.
This
rules
the
max-groups
setting
out
as
a
cause.
However,
we
also
notice
that
there
is
an
access-group
applied
to
the
interface.
This
access-group
references
the
standard
numbered
access-list
1.
At
this
point,
the
contents
of
that
access-list
are
significant
and
can
be
viewed
with
the
show
ip
access-list
1
command:
R1#show ip access-list 1
Standard IP access list 1
10 deny
224.2.2.2 (39 matches)
20 permit any (139 matches)
Looking
at
this
output,
we
see
that
the
multicast
group
224.2.2.2
is
being
denied
by
access-list
1.
Additionally,
the
output
tells
us
that
IGMP
report
messages
are
arriving
on
R1,
but
we
have
denied
39
of
them.
This
is
the
problem
with
the
configuration.
Step
3
-
Fault
Remediation:
In
this
scenario,
access-list
1
should
be
edited
such
that
line
10
is
removed.
R1(config)#ip access-list standard 1
R1(config-std-nacl)#no 10
R1(config-std-nacl)#exit
To
verify
that
the
editing
worked
we
use
the
show
ip
access-list
command:
R1(config)#do show ip access-list 1
Standard IP access list 1
20 permit any (151 matches)
R1(config)#
2-32
Once
the
error
has
been
isolated
and
remediated,
it
is
highly
recommended
to
verify
that
the
Trouble
Ticket
has
been
repaired
using
the
same
method
used
to
verify
the
fault
initially.
R1#debug ip igmp
IGMP debugging is on
R1#
IGMP(0): Send v2 general Query on FastEthernet0/0
IGMP(0): Set report delay time to 1.1 seconds for 224.0.1.40 on FastEthernet0/0
R1#
IGMP(0): Received v2 Report on FastEthernet0/0 from 172.16.100.2 for 224.2.2.2
IGMP(0): Received Group record for group 224.2.2.2, mode 2 from 172.16.100.2 for 0
sources
IGMP(0): Updating EXCLUDE group timer for 224.2.2.2
IGMP(0): MRT Add/Update FastEthernet0/0 for (*,224.2.2.2) by 0
R1
is
no
longer
denying
the
membership
report
from
R2
for
the
group
224.2.2.2.
As
a
final
verification
this
group
should
now
appear
in
the
output
of
the
show
ip
igmp
groups
command:
R1#show ip igmp groups
IGMP Connected Group Membership
Group Address
Interface
Accounted
224.4.4.4
FastEthernet0/0
224.5.5.5
FastEthernet0/0
224.2.2.2
FastEthernet0/0
224.0.1.40
FastEthernet0/1
224.0.1.40
FastEthernet0/0
Uptime
Expires
Last Reporter
Group
00:22:48
01:29:10
00:03:54
1d07h
1d07h
00:02:09
00:02:04
00:02:05
00:02:50
00:02:01
172.16.100.4
172.16.100.5
172.16.100.2
172.16.17.7
172.16.100.5
Ac
Ac
Ac
Ac
R1 now has 224.2.2.2 in the list of active IGMP groups. Thus verifying that the issue has been corrected.
2-33
Chapter
3:
Protocol
Independent
Multicast
-
Dense
Mode
(PIM-DM)
This
chapter
of
IPv4/6
Multicast
Operation
and
Troubleshooting
examines
the
processes
and
the
functionality
of
the
PIM
dense-mode
(PIM-DM)
protocol
in
great
depth.
Once
the
operational
characteristics
of
this
important
protocol
are
detailed
completely,
the
focus
becomes
that
of
troubleshooting.
This
includes
the
careful
examination
of
symptoms,
a
fault
isolation
methodology,
and
the
implementation
of
repairs
for
the
PIM
dense-mode
(PIM-DM)
protocol.
The
chapter
begins
with
a
thorough
review
of
PIM-DM,
and
then
quickly
launches
into
an
exhaustive
analysis
of
the
art
of
troubleshooting
this
multicast
routing
protocol.
This
important
chapter
concludes
with
sample
troubleshooting
scenarios,
reference
materials
for
the
most
important
show
and
debug
commands,
and
exciting
challenges
that
allow
readers
to
practice
implementing
the
troubleshooting
skills
they
have
obtained.
3-1
3-2
prune
messages,
as
well
as
a
robust
and
flexible
Hello
Packet
format
that
replaces
the
old
Query
packet
operation
adopted
from
IGMP.
To
better
understand
the
operation
of
multicast
in
IP
networks,
it
is
best
to
separate
the
construction
of
the
PIM
control
plane
from
the
actual
forwarding
of
multicast
data
(the
data
plane).
Once
the
control
plane
protocols
have
actually
constructed
the
multicast
tree
the
actual
forwarding
of
multicast
packets
will
take
place
in
the
data
plane.
The
data
plane
uses
Reverse
Path
Forwarding
(RPF)
to
ensure
traffic
is
not
forwarded
in
a
fashion
that
results
in
a
loop
of
the
multicast
stream.
We
mentioned
briefly
the
fact
that
the
multicast
tree
is
built
with
no
concern
for
loops
in
the
tree.
In
fact,
it
is
worth
mentioning
that
commonly
there
will
be
valid
deployments
where
the
tree
is
built
as
a
looped
topology.
Realizing
this
fact,
PIM
was
created
to
use
RPF
at
all
times
for
all
multicast
traffic.
Specifically,
the
reverse
path
forwarding
check
is
going
to
ensure
that
multicast
packets
will
only
be
forwarded
when
they
arrive
on
interfaces
that
are
designated
as
being
loop-free
unicast
paths
back
to
the
source
of
the
multicast
stream.
The
main
goal
of
the
reverse
path
forwarding
check
is
every
time
a
device
receives
a
multicast
packet
on
an
interface
the
router
will
perform
a
lookup
based
on
the
source
IP
address.
This
lookup
recurses
to
the
interface
used
by
the
underlying
routing
protocol
to
reach
the
source
of
the
packet.
This
interface
will
be
compared
to
the
interface
the
packet
actually
arrived
on.
If
the
interfaces
match
then
the
RPF
check
passes.
If
the
interfaces
do
not
match
then
the
RPF
check
fails
and
the
packet
is
dropped.
It
is
important
to
understand
that
these
RPF
checks
are
a
data
plane
protection
process,
separate
and
apart
from
the
control
plane
and
they
are
performed
against
each
and
every
multicast
packet
a
device
receives.
So
in
the
event
of
a
loop
in
the
IGP
topology
or
if
PIM
was
not
able
to
create
a
loop-free
tree,
it
is
assured
that
multicast
packets
will
not
loop
as
they
are
forwarded.
Essentially
guaranteeing
that
even
if
a
looped
tree
is
built
the
data
plane
will
determine
which
interfaces
should
or
should
not
be
used
in
forwarding.
All
this
is
based
on
the
underlying
unicast
routing
table.
The
majority
of
problems
encountered
when
deploying
or
troubleshooting
PIM
will
actually
result
in
some
part
of
the
physical
network
design
failing
the
RPF
check
mechanism.
This
means
that
most
multicast
issues
are
going
to
be
related
to
RPF
check
failures
that
will
need
to
be
remediated
either
by
changing
the
underlying
unicast
routing,
implementing
static
multicast
routes,
deploying
tunnels
or
by
using
multicast
BGP.
The
last
stage
of
data
plane
forwarding
is
going
to
be
the
creation
of
the
multicast
routing
table
for
a
particular
device.
PIM
neighbors
exchange
messages,
specifically
join
and
prune
messages
that
are
used
to
create
the
multicast
tree,
these
messages
are
also
used
in
the
creation
of
the
multicast
routing
table.
The
role
of
the
multicast
routing
table
is
to
keep
track
of
what
interfaces
point
to
multicast
sources,
and
what
interfaces
lead
to
multicast
receivers.
This
table
can
at
first
seem
confusing
and
difficult
to
3-3
interpret,
but
a
short
amount
of
time
looking
at
how
the
information
is
organize
will
reveal
just
how
powerful
this
table
is
when
trying
to
troubleshoot
any
multicast
routing
problem.
Two
classifications
of
information
found
in
the
multicast
routing
table
correspond
to
the
interface
classification
mentioned
previously.
Interfaces
that
point
toward
the
source
of
a
multicast
feed
(upstream
facing)
are
classified
as
incoming
interfaces.
These
interfaces
are
placed
in
the
section
of
the
multicast
routing
table
called
the
"incoming
interface
list".
The
remaining
links
(downstream
facing)
lead
toward
any
possible
multicast
receivers.
These
interfaces
compose
what
is
called
the
Outgoing
Interface
List
or
"OIL".
At
this
point
it
is
important
to
note
that
there
is
a
"split-horizon-like"
behavior
that
multicast
follows.
This
behavior
prevents
an
interface
from
being
able
to
be
classified
as
both
incoming
and
outgoing
for
a
given
multicast
group
simultaneously.
This
behavior
can
be
disabled
in
some
categories
of
PIM,
but
not
in
others.
For
troubleshooting
purposes,
it
is
important
to
remember
this
behavior
as
it
can
cause
significant
issues
in
network
designs
that
have
multipoint
non-broadcast
interfaces
like
some
deployments
of
frame
relay.
It
should
also
be
noted
that
this
behavior
could
also
result
in
some
network
designs
that
make
it
impossible
to
deploy
some
modes
of
PIM.
As
a
rule,
it
is
best
to
run
multicast
over
a
Layer
2
technology
such
as
frame-relay
using
point-to-point
PIM
enabled
links
everywhere.
Once
the
multicast
tree
has
been
created
using
the
associated
PIM
join
and
prune
messages,
and
assuming
the
RPF
checks
pass,
multicast
routes
(mroutes)
will
begin
to
populate
the
multicast
routing
table.
These
routes
utilize
an
annotation
scheme
unique
to
multicast.
This
annotation
format
follows
the
model
of
(S,G)
where
"S"
is
the
source
and
"G"
is
the
group.
This
means
that
the
router
knows
the
identity
of
the
source
for
a
specific
group
as
opposed
to
the
(*,G)
entry.
The
*,G
entry
means
that
the
device
knows
the
group
but
not
the
identity
of
the
source.
The
(S,G)
is
often
referred
to
as
the
"Source
Tree",
where
the
(*,G)
is
known
as
the
"Shared
Tree".
Multicast
routing
has
one
other
thing
in
common
with
unicast
routing.
The
most
specific
route
or
"longest
match"
will
always
be
preferred.
This
means
that
a
*,G
entry
will
always
be
less
specific
than
a
S,G
entry
in
the
multicast
routing
table.
This
being
the
case,
once
a
multicast
packet
arrives
on
an
interface
the
router
will
switch
the
packet
from
the
incoming
interface,
to
all
interfaces
in
the
OIL.
The
mechanism
being
described
here
is
one
where
a
"single"
packet
arrives
on
an
interface,
and
a
layer
three
replication
of
that
single
packet
takes
place
and
it
is
forwarded
out
all
the
interfaces
in
the
OIL.
PIM
Dense
Mode
We
have
discussed
the
basic
operation
of
PIM.
The
next
step
in
this
critical
analysis
of
the
protocol
is
to
look
at
different
modes
of
PIM
operation.
There
are
three
modes
to
this
essential
multicast
routing
protocol:
dense-mode
(PIM-DM),
sparse-mode
(PIM-SM),
and
sparse-dense-mode
(PIM-SM-DM).
3-4
The
mode
that
this
chapter
will
explore
is
PIM-DM.
The
remaining
operational
modes
each
will
have
their
own
dedicated
chapters.
It
was
decided
to
start
with
PIM-DM
because
the
protocol
is
the
simplest
of
the
three,
and
affords
a
very
streamline
technology
to
introduce
the
basic
and
advanced
verification
commands,
tools
and
processes
associated
with
troubleshooting
all
of
the
PIM
mode
types.
Figure
3-1
demonstrates
a
sample
PIM-DM
topology.
Figure
3-1:
A
Sample
PIM-DM
Topology
In
this
chapter,
we
are
going
to
look
critically
at
the
specifics
of
PIM-DM
to
include
the
different
verification
techniques
used
to
validate
its
operation,
as
well
as
the
commands
used
to
isolate
faults
in
the
protocol.
PIM-DM
operates
via
an
implicit
join
paradigm.
This
implicit
join
model
is
often
called
a
"push
model"
because
the
routers
are
going
to
flood
all
multicast
traffic
they
receive
out
every
single
interface
running
PIM-DM
(except
the
interface
the
packet
arrived
on).
This
means
that
the
individual
adjacent
routers
are
responsible
for
deciding
if
they
are
interested
in
the
multicast
feed
or
not.
If
the
router
has
no
interest
in
the
multicast
feed,
it
will
send
a
PIM
Prune
message.
This
message
is
the
equivalent
of
an
un-join
instruction
sent
out
the
originating
link.
This
"flood
and
prune"
behavior
makes
PIM-DM
operation
unwieldy
due
to
the
sheer
volume
of
state
information
it
must
maintain.
The
larger
the
network
the
more
state
information
that
needs
to
be
maintained,
therefore
PIM-DM's
biggest
detractor
is
its
lack
of
scalability.
3-5
Looking
at
the
output
of
debug
ip
packet
on
any
of
these
devices
after
we
apply
the
ip
multicast-routing
and
the
ip
pim
dense-mode
commands
we
will
see
the
underlying
process
take
place
on
the
console.
In
order
to
filter
out
traffic
associated
with
our
internal
routing
protocol
we
will
apply
an
ACL
to
the
debug
ip
packet
command
that
will
prevent
EIGRP's
locally
process
switched
traffic
from
cluttering
the
console
messages.
Also,
note
that
like
other
chapters
in
this
text
we
have
disabled
the
service
timestamps
feature,
again
in
an
effort
to
reduce
any
possible
confusion
regarding
the
interpretation
of
the
debug
output.
R1(config)#access-list 101 deny eigrp any any
R1(config)#access-list 101 permit ip any any
3-6
R1(config)#end
R1#
R1#debug ip packet detail 101
IP packet debugging is on (detailed) for access list 101
With
this
accomplished
our
next
task
is
to
enable
ip
multicast-routing
and
apply
the
ip
pim
dense-mode
command
under
the
FastEthernet0/0
interface
of
R1.
Once
completed,
we
will
observe
the
output
of
the
debug
ip
packet
command:
R1#conf t
Enter configuration commands, one per line.
R1(config)#ip multicast-routing
R1(config)#interface FastEthernet0/0
R1(config-if)#ip pim dense-mode
R1(config-if)#end
Almost
immediately,
debug
output
begins
to
appear
on
the
console
of
R1.
It
is
this
output
we
need
to
interpret
in
order
to
understand
the
process
that
is
taking
place.
Specifically,
we
need
to
look
at
these
three
samples
of
output.
Notice
that
each
represents
an
instance
where
R1
is
sending
a
broadcast/multicast
packet,
but
there
are
two
different
protocol
types,
and
three
different
destination
addresses
used.
IP: s=172.16.15.1 (local), d=224.0.0.13 (FastEthernet0/0), len 54, sending
broad/multicast, proto=103
IP: s=172.16.15.1 (local), d=224.0.0.1 (FastEthernet0/0), len 28, sending
broad/multicast, proto=2
IP: s=172.16.15.1 (local), d=224.0.1.40 (FastEthernet0/0), len 28, sending
broad/multicast, proto=2
First,
we
will
look
at
the
protocol
types.
In
the
sample
output
above,
we
see
protocols
103
and
2.
What
are
these
protocol
types?
It
is
simple
enough
to
find
out
by
creating
an
extended
access-list
using
the
IP
protocol
number.
The
default
behavior
of
Cisco
IOS
is
to
translate
these
protocol
numbers
into
a
human
readable
form.
Taking
advantage
of
this
feature
is
a
handy
tool
to
identify
the
protocol
types
without
needing
external
resources
or
materials.
R1(config)#access-list 100 permit 103 any any
R1(config)#access-list 100 permit 2 any any
R1(config)#end
%SYS-5-CONFIG_I: Configured from console by console
R1#show ip access-list 100
Extended IP access list 100
10 permit pim any any
20 permit igmp any any
3-7
The
output
of
the
show
ip
access-list
100
command
reveals
that
the
protocol
types
in
question
are
PIM
(type
103)
and
IGMP
(type
2)
messages
respectively.
Now
that
we
know,
what
type
of
messages
R1
is
sending
the
next
logical
step
is
to
look
at
where
the
messages
are
going.
The
type
103
or
PIM
messages
are
being
sent
to
the
link-local
multicast
group
224.0.0.13.
The
type
2
messages
are
actually
being
sent
to
two
different
destination
groups.
The
first
group
is
224.0.0.1,
a
link-local
multicast
group
employed
by
all
multicast
hosts.
This
means
that
by
virtue
of
enabling
PIM
on
the
interface
R1
is
now
sending
IGMP
query
messages
to
all
hosts
on
the
VLAN
15
segment.
However,
it
is
also
observed
that
R1
is
sending
type
two
protocol
messages
to
a
new
multicast
destination
address
that
has
not
been
discussed
as
of
yet;
the
multicast
group
224.0.1.40.
This
address
is
used
in
the
process
of
Auto-RP
that
was
discussed
briefly
in
Chapter
2:
Internet
Group
Management
Protocol
(IGMP).
Auto-RP
will
be
discussed
in
detail
in
Chapter
8:
AutoRP.
At
this
point,
it
is
enough
to
know
that
the
group
224.0.1.40
is
the
multicast
group
that
the
Auto-RP
mapping
agent
will
use
to
disseminate
Auto-RP
information,
but
the
important
thing
to
note
is
that
as
soon
as
the
multicast
routing
process
is
enabled,
the
router
will
automatically
join
the
group
224.0.1.40.
Regardless
of
what
PIM
mode
we
are
running,
the
router
will
attempt
to
dynamically
learn
the
identity
of
a
rendezvous
point
(RP).
PIM-DM
does
not
utilize
an
RP
as
part
of
the
multicast
routing
process
but
none-the-less
the
router
will
join
the
group.
This
behavior
affords
us
an
ideal
opportunity
to
look
at
the
multicast
routing
table
while
it
has
only
one
entry.
R1#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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.0.1.40), 00:42:27/00:01:54, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Dense, 00:42:27/00:00:00
Observe
the
(*,
224.0.1.40)
entry.
This
entry
is
referred
to
as
a
"star
comma
gee",
and
fits
the
annotation
model
of
(*,G).
This
means
that
the
router
has
joined
this
multicast
group,
but
there
are
no
3-8
known
sources
for
it
at
this
time.
How
can
we
actually
tell
the
router
has
joined
this
group?
Remember
the
behavior
of
IGMP.
An
IGMP
host
records
all
the
groups
it
has
joined
in
an
IGMP
membership
list.
The
contents
of
this
list
can
be
viewed
with
the
show
ip
igmp
membership
command.
R1#show ip igmp membership
Flags: A - aggregate, T - tracked
L - Local, S - static, V - virtual, R - Reported through v3
I - v3lite, U - Urd, M - SSM (S,G) channel
1,2,3 - The version of IGMP the group is in
Channel/Group-Flags:
/ - Filtering entry (Exclude mode (S,G), Include mode (*,G))
Reporter:
<mac-or-ip-address> - last reporter if group is not explicitly tracked
<n>/<m>
- <n> reporter in include mode, <m> reporter in exclude
Channel/Group
*,224.0.1.40
Reporter
172.16.15.1
Uptime
Exp. Flags
00:48:30 02:59 2LA
Interface
Fa0/0
The
output
verifies
that
R1
has
actually
joined
the
multicast
group
224.0.1.40
on
Interface
FastEthernet0/0.
These
two
show
commands
show
ip
mroute
and
show
ip
igmp
membership,
demonstrate
that
we
have
IP
multicast-routing
enabled
globally,
and
at
the
interface
level
we
are
running
PIM-DM.
Also
based
on
the
output
we
have
observed
we
know
that
R1
is
sending
PIM
messages
to
224.0.0.13
with
a
protocol
number
of
103,
and
IGMP
messages
related
to
the
group
224.0.1.40.
In
fact,
R1
has
actually
become
an
IGMP
client
for
the
Auto-RP
mapping
agent
group.
Step
Two:
PIM-DM
on
the
remaining
routers
Now
that
we
have
observed
the
behavior
of
PIM-DM
critically
on
one
device
and
have
an
understanding
of
how
it
operates
it
is
time
to
enable
ip
multicast-routing
and
PIM-DM
on
every
router
interface
with
an
ip
address
in
the
topology.
At
this
point
in
our
critical
analysis,
we
will
enable
PIM-DM
on
all
interfaces
in
an
effort
to
prevent
any
failures
in
the
reverse
path
forwarding
mechanism.
Once
this
is
accomplished,
it
is
very
simple
to
identify
and
map
the
multicast
routing
topology
based
on
the
output
of
a
single
show
command:
show
ip
pim
neighbors.
Using
this
command
on
all
the
routers
in
this
topology
will
quickly
allow
us
to
construct
a
logical
drawing
of
the
multicast
routing
topology.
Beginning
on
R1:
R1#show ip pim nei
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
S - State Refresh Capable
3-9
Neighbor
Address
172.16.15.5
Interface
Uptime/Expires
Ver
FastEthernet0/0
00:07:26/00:01:41 v2
DR
Prio/Mode
1 / DR S
We
see
that
R1
has
formed
a
PIM
neighbor
relationship
with
R5.
The
same
command
on
R5
informs
us
that
R5
is
neighbored
with
R1
and
R4:
R5#show ip pim neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default
S - State Refresh Capable
Neighbor
Interface
Uptime/Expires
Address
172.16.15.1
FastEthernet0/0
00:08:28/00:01:38
172.16.45.4
FastEthernet0/1
00:08:47/00:01:18
DR Priority,
Ver
v2
v2
DR
Prio/Mode
1 / S
1 / S
Consistently
repeating
this
command
on
all
the
routers
in
the
topology
will
produce
a
topology
drawing
matching
Figure
3-3.
Note:
When
using
the
show
ip
pim
neighbor
command
be
sure
to
check
for
adjacencies
on
both
ends
of
a
link.
There
are
scenarios
where
the
PIM
neighbor
can
show
up
on
one
side
and
not
the
other.
Now
that
we
see
the
topology,
there
are
issues
that
need
discussion.
Observe
that
the
PIM
neighbor
relationships
between
R4,
R2
and
R6
form
a
distinct
loop.
At
first
glance,
this
will
seem
extremely
odd,
but
remember
the
control
plane
is
formed
with
no
thought
toward
possible
loops.
This
is
where
the
RFP
check
mechanism
will
come
into
play.
Later
in
this
section,
this
entire
process
will
be
laid
out
and
dissected
step-by-step,
but
for
now
it
is
time
to
move
to
the
next
stage
of
the
process.
Step
Three:
A
host
joins
a
multicast
group
3-10
We
have
reviewed
the
nature
and
purpose
of
the
PIM
and
IGMP
messages
that
sent
between
PIM-DM
enabled
devices,
now
it
is
time
to
look
at
the
IGMP
join
process.
In
Chapter
2:
Internet
Group
Management
Protocol
(IGMP)
we
saw
the
inner
workings
of
this
protocol
and
we
know
that
to
force
a
router
to
join
a
multicast
group
we
can
employ
a
number
of
commands
at
the
interface
level.
In
this
explanation,
the
FastEthernet0/1
interface
of
R9
will
use
the
ip
igmp
join-group
command
to
join
the
multicast
group
224.9.9.9.
R9(config)#interface FastEthernet0/1
R9(config-if)#ip igmp join-group 224.9.9.9
R9(config-if)#end
Once
this
is
accomplished,
the
show
ip
mroute
or
show
ip
igmp
membership
commands
will
tell
us
if
the
router's
interface
has
indeed
joined
the
group
224.9.9.9.
In
order
to
develop
more
familiarity
with
the
show
ip
mroute
command,
we
use
it
below.
R9#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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.9.9.9), 00:42:21/00:02:33, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/1, Forward/Dense, 00:42:21/00:00:00
(*, 224.0.1.40), 00:42:22/00:02:38, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/1, Forward/Dense, 00:42:22/00:00:00
The
output
reveals
that
the
router
has
in
fact
joined
the
group
224.9.9.9
as
well
as
the
group
224.0.1.40.
Note
that
there
is
a
(*,G)
entry
for
each
of
these
groups.
In
this
instance,
R9
is
acting
like
a
host
and
as
a
result
will
send
its
IGMP
membership
reports
to
R7.
This
can
be
observed
via
the
show
ip
igmp
membership
command.
R7#show ip igmp membership
Flags: A - aggregate, T - tracked
3-11
Reporter
172.16.79.9
172.16.79.9
172.16.67.7
Uptime
00:52:19
00:52:03
00:52:29
Exp.
02:53
02:58
02:30
Flags
2A
2A
2LA
Interface
Fa0/1
Fa0/1
Fa0/0
R9
has
notified
the
IGMP
router
R7
that
it
is
interested
in
the
multicast
group
224.9.9.9.
Does
R7
forward
any
of
this
information
to
adjacent
devices?
No,
R7
has
no
mechanism
or
requirement
to
forward
these
IGMP
report
messages
to
any
of
its
adjacent
neighbors
in
PIM-DM.
This
can
be
seen
with
either
the
show
ip
igmp
membership
or
show
ip
mroute
commands
on
R6.
R6#show ip mroute 224.9.9.9
Group 224.9.9.9 not found
There
is
no
entry
for
a
(*,
224.9.9.9)
on
R6,
nor
is
there
an
entry
for
that
group
in
the
IGMP
membership
list.
R6#show ip igmp membership 224.9.9.9
Flags: A - aggregate, T - tracked
L - Local, S - static, V - virtual, R - Reported through v3
I - v3lite, U - Urd, M - SSM (S,G) channel
1,2,3 - The version of IGMP the group is in
Channel/Group-Flags:
/ - Filtering entry (Exclude mode (S,G), Include mode (*,G))
Reporter:
<mac-or-ip-address> - last reporter if group is not explicitly tracked
<n>/<m>
- <n> reporter in include mode, <m> reporter in exclude
Channel/Group
Reporter
Uptime
Exp.
Flags
Interface
This
clearly
illustrates
that
the
IGMP
router
is
not
forwarding
any
of
the
information
learned
from
R9.
The
reason
for
this
behavior
is
that
PIM-DM
uses
an
implicit
join
methodology
where
the
protocol
assumes
all
devices
are
interested
in
receiving
the
multicast
feed.
So
rather
than
notifying
any
of
its
neighbors
that
R9
has
joined
a
specific
group,
R7
instead
will
assume
that
any
multicast
feed
for
the
group
224.9.9.9
will
be
flooded
to
it.
This
means
that
in
PIM-DM,
R4
will
be
listening
for
the
multicast
traffic
to
arrive
on
any
of
its
interfaces,
but
it
will
not
notify
any
other
routers
that
it
has
an
adjacent
3-12
host
that
has
joined
any
particular
group.
This
is
the
flooding
portion
of
the
PIM-DM
"Flood
and
Prune"
behavior.
Step
Four:
Flooding
of
a
Multicast
Feed
The
previous
step
outlined
the
relationship
between
the
IGMP
host
and
the
IGMP
router.
The
previous
chapter
described
the
IGMP
mechanism
as
the
protocol
that
encompasses
the
last
leg
of
the
multicast
routing
tree.
We
have
observed
that
only
the
host
and
its
adjacent
IGMP
router
knows
about
the
join-
group
command
under
the
FastEthernet0/1
interface
of
R9.
The
next
step
is
to
emulate
a
multicast
source
and
observe
how
PIM-DM
will
flood
the
multicast
stream.
The
source
in
our
topology
is
R1,
and
to
emulate
a
multicast
feed
we
will
initiate
a
ping
destined
to
a
multicast
group.
For
testing
purposes,
this
ping
will
not
match
the
multicast
group
that
R9
has
joined.
No
host
being
interested
in
the
multicast
feed
will
result
in
the
pings
on
R1
failing.
Nevertheless,
the
object
of
this
exercise
is
to
follow
the
multicast
feed
through
the
network,
observe
its
behavior,
and
note
any
related
characteristics.
We
will
use
a
very
high
repeat
count
on
R1
to
make
sure
that
the
multicast
feed
remains
active
throughout
our
testing.
R1#ping 224.1.1.1 repeat 100000000
Type escape sequence to abort.
Sending 100000000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
................................... <output omitted>
The
pings
are
not
successful
as
we
expected,
but
what
about
the
multicast-routing
tables
on
all
the
routers
in
the
topology.
We
will
look
at
R5
first:
R5#show ip mroute 224.1.1.1
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.1.1.1), 00:02:43/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/1, Forward/Dense, 00:02:43/00:00:00
FastEthernet0/0, Forward/Dense, 00:02:43/00:00:00
3-13
Now
we
observe
something
new.
For
the
multicast
group
224.1.1.1
there
are
two
entries,
a
(*,G)
entry
and
a
(S,G)
entry.
This
affords
us
an
ideal
opportunity
to
look
closely
at
the
"more
specific"
match
rule
that
we
discussed
earlier.
The
output
of
this
show
command
illustrates
that
R5
knows
about
both
the
group
and
the
source
for
that
group.
This
constitutes
the
creation
of
the
(S,G)
entry.
Observe
that
the
(*,G)
entry
is
stopped,
and
that
each
of
R5's
PIM-DM
enabled
interfaces
are
in
the
OIL.
The
more
specific
(S,G)
entry
is
different.
We
see
that
there
is
now
an
expiration
timer
00:00:16
in
this
output
capture,
and
that
FastEthernet0/0
is
in
the
Incoming
Interface
List
and
FastEthernet0/1
is
in
the
OIL.
Based
on
the
multicast
"flooding"
model
used
by
PIM-DM,
we
can
expect
to
see
this
(*,G),
(S,G)
pair
on
each
router
in
our
topology.
To
reduce
this
output
in
this
verification
this
test
will
only
be
done
on
R6
and
R9,
and
the
output
will
be
filtered
to
reduce
the
amount
of
output
to
a
more
manageable
level.
R6#show ip mroute 224.1.1.1 | sec 224.1.1.1
(*, 224.1.1.1), 00:28:36/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial0/1/0.1, Forward/Dense, 00:28:36/00:00:00
FastEthernet0/1, Forward/Dense, 00:28:36/00:00:00
FastEthernet0/0, Forward/Dense, 00:28:36/00:00:00
(172.16.15.1, 224.1.1.1), 00:28:36/00:01:52, flags: T
Incoming interface: FastEthernet0/1, RPF nbr 172.16.26.2
Outgoing interface list:
FastEthernet0/0, Forward/Dense, 00:01:08/00:00:00
Serial0/1/0.1, Prune/Dense, 00:13:18/00:01:52, A
R9#show ip mroute 224.1.1.1 | sec 224.1.1.1
(*, 224.1.1.1), 00:14:15/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/1, Forward/Dense, 00:14:15/00:00:00
(172.16.15.1, 224.1.1.1), 00:02:11/00:00:48, flags: PT
Incoming interface: FastEthernet0/1, RPF nbr 172.16.79.7
Outgoing interface list: Null
Remember
the
traffic
will
be
flooded
throughout
the
multicast
domain,
because
of
the
flood
and
prune
model
employed
by
PIM-DM.
So
all
PIM-DM
routers
will
receive
the
multicast
feed
whether
they
want
it
or
not.
This
covers
the
flood
portion
of
PIM-DM.
What
about
the
"prune"
aspect
of
PIM-DM?
We
need
to
look
at
the
output
of
the
show
ip
mroute
command
on
R9
once
more.
3-14
Now
there
is
only
a
(*,G)
entry
in
the
multicast
routing
table
where
before
there
was
both
a
(*,G)
and
an
(S,G).
What
happened?
We
need
to
repeat
the
command.
R9#show ip mroute 224.1.1.1 | sec 224.1.1.1
(*, 224.1.1.1), 00:21:08/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/1, Forward/Dense, 00:21:08/00:00:00
(172.16.15.1, 224.1.1.1), 00:00:04/00:02:55, flags: PT
Incoming interface: FastEthernet0/1, RPF nbr 172.16.79.7
Outgoing interface list: Null
Now
both
the
(*,G)
and
the
(S,G)
entries
are
back.
Is
there
a
problem
with
our
configuration?
No.
We
are
observing
the
normal
flood
and
prune
behavior
of
PIM-DM.
When
all
PIM-DM
enabled
routers
receive
a
multicast
feed
and
they
do
not
have
an
IGMP
join
state
for
that
feed,
or
they
do
not
have
a
neighbor
with
a
join
state
for
that
feed
they
will
send
a
prune
message
back
toward
the
source.
Evidenced
by
the
output
of
the
debug
ip
pim
command
on
R9.
R9#debug ip pim
PIM debugging is on
R9#
PIM(0): Insert (172.16.15.1,224.1.1.1) prune in nbr 172.16.79.7's queue
PIM(0): Building Join/Prune packet for nbr 172.16.79.7
PIM(0): Adding v2 (172.16.15.1/32, 224.1.1.1) Prune
PIM(0): Send v2 join/prune to 172.16.79.7 (FastEthernet0/1)
Looking
critically
at
the
output
of
the
debug
command
we
see
that
R9
built
a
Join/Prune
packet.
The
router
then
added
a
Prune
state
to
its
own
multicast
routing
table,
and
then
sent
the
join/prune
packet
to
its
neighbor
172.16.79.7.
This
entire
mechanism
is
known
as
a
pruning.
Without
employing
the
debug
commands
we
can
see
in
the
multicast
routing
table
if
a
multicast
feed
is
in
a
pruned
state
or
not.
R9#show ip mroute 224.1.1.1 | sec 224.1.1.1
(*, 224.1.1.1), 02:09:53/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/1, Forward/Dense, 02:09:53/00:00:00
(172.16.15.1, 224.1.1.1), 00:01:53/00:01:06, flags: PT
Incoming interface: FastEthernet0/1, RPF nbr 172.16.79.7
Outgoing interface list: Null
3-15
In
this
output,
we
see
there
is
a
field
called
"flags".
For
the
(S,G)
entry
for
224.1.1.1
these
flags
are
PT.
The
index
for
the
show
command
tells
us
that
the
"P"
flag
means
this
multicast
feed
has
been
pruned.
Since
there
are
no
interested
receivers
in
this
topology,
we
expect
the
status
of
this
feed
to
be
pruned
on
all
routers
between
R1
and
R9.
R7#show ip mroute 224.1.1.1 | sec 224.1.1.1
(*, 224.1.1.1), 04:27:39/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/1, Forward/Dense, 04:27:39/00:00:00
FastEthernet0/0, Forward/Dense, 04:27:39/00:00:00
(172.16.15.1, 224.1.1.1), 00:03:25/00:02:42, flags: PT
Incoming interface: FastEthernet0/0, RPF nbr 172.16.67.6
Outgoing interface list:
FastEthernet0/1, Prune/Dense, 00:00:21/00:02:48
R6#show ip mroute 224.1.1.1 | sec 224.1.1.1
(*, 224.1.1.1), 04:28:18/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial0/1/0.1, Forward/Dense, 04:28:18/00:00:00
FastEthernet0/1, Forward/Dense, 04:28:18/00:00:00
FastEthernet0/0, Forward/Dense, 04:28:18/00:00:00
(172.16.15.1, 224.1.1.1), 04:28:18/00:02:03, flags: PT
Incoming interface: FastEthernet0/1, RPF nbr 172.16.26.2
Outgoing interface list:
FastEthernet0/0, Prune/Dense, 00:01:00/00:01:59
Serial0/1/0.1, Prune/Dense, 00:01:04/00:01:58
R2#show ip mroute 224.1.1.1 | sec 224.1.1.1
(*, 224.1.1.1), 04:28:44/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet0/1, Forward/Dense, 04:28:44/00:00:00
GigabitEthernet0/0, Forward/Dense, 04:28:44/00:00:00
(172.16.15.1, 224.1.1.1), 00:16:30/00:01:40, flags: PT
Incoming interface: GigabitEthernet0/0, RPF nbr 172.16.24.4
Outgoing interface list:
GigabitEthernet0/1, Prune/Dense, 00:01:26/00:01:33
R4#show ip mroute 224.1.1.1 | sec 224.1.1.1
(*, 224.1.1.1), 04:29:13/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/1, Forward/Dense, 04:29:13/00:00:00
FastEthernet0/0, Forward/Dense, 04:29:13/00:00:00
Serial0/0/0.1, Forward/Dense, 04:29:13/00:00:00
(172.16.15.1, 224.1.1.1), 00:22:59/00:01:09, flags: PT
3-16
Notice
that
the
flags
for
each
of
these
multicast
routing
table
entries
are
P
for
pruned.
Additionally,
observe
that
the
interfaces
in
the
OIL
all
have
a
state/mode
of
Prune/Dense.
This
indicated
by
looking
at
the
value
after
the
interface
designator.
This
output
tells
us
that
the
adjacent
router
on
the
segment
has
sent
us
a
prune
message.
In
effect,
informing
the
router
that
there
are
no
interested
devices
on
or
beyond
this
segment.
As
an
additional
test,
we
will
have
the
FastEthernet0/1
interface
of
R6
join
the
multicast
group
224.1.1.1.
R6(config)#interface FastEthernet0/1
R6(config-if)#ip igmp join-group 224.1.1.1
R6(config-if)#end
After
implementing
this
command
on
R6
there
will
be
a
significant
change
in
the
multicast
routing
table
of
the
devices
in
the
path
from
R1
to
R6.
Most
notably
the
state/mode
value
will
change
to
forward/dense.
This
means
that
the
these
devices
are
actively
forwarding
the
multicast
feed
to
R6
this
can
be
seen
by
observing
the
contents
of
the
multicast
routing
tables
on
R5,
R4,
R2
and
R6.
R5#show ip mroute 224.1.1.1 | sec 224.1.1.1
(*, 224.1.1.1), 04:42:45/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/1, Forward/Dense, 04:42:45/00:00:00
FastEthernet0/0, Forward/Dense, 04:42:45/00:00:00
(172.16.15.1, 224.1.1.1), 00:06:21/00:02:57, flags: T
Incoming interface: FastEthernet0/0, RPF nbr 172.16.15.1
Outgoing interface list:
FastEthernet0/1, Forward/Dense, 00:03:54/00:00:00
R4#show ip mroute 224.1.1.1 | sec 224.1.1.1
(*, 224.1.1.1), 04:44:55/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/1, Forward/Dense, 04:44:55/00:00:00
FastEthernet0/0, Forward/Dense, 04:44:55/00:00:00
Serial0/0/0.1, Forward/Dense, 04:44:55/00:00:00
(172.16.15.1, 224.1.1.1), 00:11:31/00:02:57, flags: T
Incoming interface: FastEthernet0/1, RPF nbr 172.16.45.5
Outgoing interface list:
Serial0/0/0.1, Prune/Dense, 00:02:19/00:00:41, A
FastEthernet0/0, Forward/Dense, 00:06:05/00:00:00
3-17
Once
the
multicast
feed
reaches
R6
we
will
see
that
it
is
not
forwarded
beyond
R6
because
there
are
no
devices
beyond
R6
that
have
joined
the
multicast
group
224.1.1.1.
This
is
reflected
by
the
flag
of
"P"
and
the
state/mode
value
of
Prune/Dense
found
in
the
multicast
routing
table
for
the
(S,G)
pair.
R6#show ip mroute 224.1.1.1 | sec 224.1.1.1
(*, 224.1.1.1), 04:46:57/stopped, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial0/1/0.1, Forward/Dense, 04:46:57/00:00:00
FastEthernet0/1, Forward/Dense, 04:46:57/00:00:00
FastEthernet0/0, Forward/Dense, 04:46:57/00:00:00
(172.16.15.1, 224.1.1.1), 04:46:57/00:02:58, flags: PLTX
Incoming interface: FastEthernet0/1, RPF nbr 172.16.26.2
Outgoing interface list:
FastEthernet0/0, Prune/Dense, 00:01:08/00:01:50
Serial0/1/0.1, Prune/Dense, 00:01:17/00:01:45
to
to
to
to
to
to
to
to
to
to
to
to
to
to
to
to
request
request
request
request
request
request
request
request
request
request
request
request
request
request
request
request
8837
8838
8839
8840
8841
8842
8843
8844
8845
8846
8847
8848
8849
8850
8851
8852
from
from
from
from
from
from
from
from
from
from
from
from
from
from
from
from
172.16.26.6,
172.16.26.6,
172.16.26.6,
172.16.26.6,
172.16.26.6,
172.16.26.6,
172.16.26.6,
172.16.26.6,
172.16.26.6,
172.16.26.6,
172.16.26.6,
172.16.26.6,
172.16.26.6,
172.16.26.6,
172.16.26.6,
172.16.26.6,
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
3-18
<output omitted>
This
tells
us
that
everything
is
working,
but
it
is
important
to
note
that
successful
ICMP
echo
replies
may
always
tell
us
that
the
test
is
working,
but
not
getting
echo
replies
back
may
not
mean
that
the
tests
are
failing.
Keep
in
mind
that
normal
multicast
operations
are
unidirectional
in
nature.
Specifically,
they
will
be
unidirectional
UDP
packet
flows
travelling
from
the
sender
down
to
the
receivers.
This
process
being
UDP
takes
place
without
any
explicit
acknowledgement
from
any
device
in
the
multicast
path.
This
means
in
a
normal
multicast
feed
the
multicast
application
at
the
hosts
will
never
reply
to
the
source
of
the
multicast
stream.
Though
using
pings
and
looking
for
echo
replies
is
a
useful
tool,
the
important
thing
to
observe
is
whether
the
multicast
packets
are
actually
arriving
at
the
host,
by
using
debug
ip
mpacket
at
the
host.
For
instance
on
R6
we
see
the
packets
arriving.
R6(config)#access-list 101 deny eigrp any any
R6(config)#access-list 101 permit ip any any
R6(config)#exit
R6#
%SYS-5-CONFIG_I: Configured from console by console
R6#
R6#debug ip mpacket detail list 101
IP multicast packets debugging is on (detailed) for access list 101
R6#
IP(0): MAC sa=000f.8f4a.1061 (FastEthernet0/1)
IP(0): IP tos=0x0, len=100, id=9132, ttl=251, prot=1
IP(0): s=172.16.15.1 (FastEthernet0/1) d=224.1.1.1 (FastEthernet0/0)
prot=1, len=100(100), mforward
R6#
IP(0): MAC sa=000f.8f4a.1061 (FastEthernet0/1)
IP(0): IP tos=0x0, len=100, id=9133, ttl=251, prot=1
IP(0): s=172.16.15.1 (FastEthernet0/1) d=224.1.1.1 (FastEthernet0/0)
prot=1, len=100(100), mforward
R6#
IP(0): MAC sa=000f.8f4a.1061 (FastEthernet0/1)
IP(0): IP tos=0x0, len=100, id=9138, ttl=251, prot=1
IP(0): s=172.16.15.1 (FastEthernet0/1) d=224.1.1.1 id=9138, ttl=251,
len=114(100), mroute olist null
R6#
IP(0): MAC sa=000f.8f4a.1061 (FastEthernet0/1)
IP(0): IP tos=0x0, len=100, id=9139, ttl=251, prot=1
IP(0): s=172.16.15.1 (FastEthernet0/1) d=224.1.1.1 id=9139, ttl=251,
len=114(100), mroute olist null
R6#
IP(0): MAC sa=000f.8f4a.1061 (FastEthernet0/1)
IP(0): IP tos=0x0, len=100, id=9140, ttl=251, prot=1
IP(0): s=172.16.15.1 (FastEthernet0/1) d=224.1.1.1 id=9140, ttl=251,
len=114(100), mroute olist null
R6#undebug all
id=9132, ttl=251,
id=9133, ttl=251,
prot=1,
prot=1,
prot=1,
3-19
This
output
demonstrates
that
multicast
packets
are
arriving
on
R6
via
the
FastEthernet0/1
interface
sourced
from
the
IP
address
172.16.15.1
and
destined
to
the
multicast
group
224.1.1.1.
Also,
observe
the
statement
that
reads
"mroute
olist
null".
The
mroute
olist
null
states
that
there
are
interfaces
interested
in
this
feed.
This
leads
us
to
the
next
question.
What
does
the
output
of
this
command
look
like
on
a
device
in
the
transit
path
where
there
should
be
an
outbound
interface
in
the
OIL?
We
can
see
this
by
using
debug
ip
mpacket
on
a
router
in
the
path
like
R4.
R4(config)#access-list 101 deny eigrp any any
R4(config)#access-list 101 permit ip any any
R4(config)#end
%SYS-5-CONFIG_I: Configured from console by console
R4#debug ip mpacket detail list 101
IP multicast packets debugging is on (detailed) for access list 101
Oddly
enough,
no
matter
how
long
we
wait,
we
see
no
output
on
this
device,
but
we
know
the
multicast
feed
is
transiting
R4
to
get
to
R6.
Verified
with
the
show
ip
mroute
command.
R4#show ip mroute 224.1.1.1 | sec 224.1.1.1
(*, 224.1.1.1), 05:16:16/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/1, Forward/Dense, 05:16:16/00:00:00
FastEthernet0/0, Forward/Dense, 05:16:16/00:00:00
Serial0/0/0.1, Forward/Dense, 05:16:16/00:00:00
(172.16.15.1, 224.1.1.1), 00:42:52/00:02:56, flags: T
Incoming interface: FastEthernet0/1, RPF nbr 172.16.45.5
Outgoing interface list:
Serial0/0/0.1, Prune/Dense, 00:03:00/00:00:00, A
FastEthernet0/0, Forward/Dense, 00:37:26/00:00:00
This
confirms
our
expectation.
The
output
verifies
the
forwarding
of
the
multicast
feed
for
224.1.1.1
out
the
FastEthernet0/0
interface
of
R4.
What
is
blocking
the
results
of
the
debug
ip
mpacket
command?
We
cannot
see
the
packets
transit
through
R4
because
they
are
not
being
process
switched.
Only
traffic
destined
to
or
from
a
multicast
enabled
router
will
be
process
switched
by
default.
Currently,
multicast
traffic
on
the
FastEthernet
interfaces
of
R4
is
fast
switched
made
evident
via
the
show
ip
interface
FastEthernet
command.
R4#show ip interface FastEthernet0/0 | inc multicast
IP multicast fast switching is enabled
IP multicast distributed fast switching is disabled
3-20
Note
that
the
output
tells
us
that
the
router
has
enabled
fast
switching,
and
disabled
distributed
fast
switching.
Distributed
fast
switching
is
hardware
based
where
regular
fast
switching
is
software
based.
The
Cisco
routers
used
in
this
topology
do
not
support
hardware
switching.
What
can
we
do
to
change
this
behavior?
In
order
to
disable
multicast
fast
switching
we
will
need
to
disable
the
multicast
routing
cache
feature
that
is
on
by
default
on
all
interfaces.
Doing
so
will
force
the
router
to
process
switch
multicast
packets.
R4(config)#interface FastEthernet0/0
R4(config-if)#no ip mroute-cache
R4(config-if)#interface FastEthernet0/1
R4(config-if)#no ip mroute-cache
R4(config-if)#end
Once
this
is
accomplished,
we
will
immediately
begin
to
see
output
from
the
debug
ip
mpacket
command.
R4#
IP(0): MAC sa=0017.9486.c711 (FastEthernet0/1)
IP(0): IP tos=0x0, len=100, id=10022, ttl=253, prot=1
IP(0): s=172.16.15.1 (FastEthernet0/1) d=224.1.1.1 (FastEthernet0/0)
ttl=253, prot=1, len=100(100), mforward
R4#
IP(0): MAC sa=0017.9486.c711 (FastEthernet0/1)
IP(0): IP tos=0x0, len=100, id=10023, ttl=253, prot=1
IP(0): s=172.16.15.1 (FastEthernet0/1) d=224.1.1.1 (FastEthernet0/0)
ttl=253, prot=1, len=100(100), mforward
R4#
IP(0): MAC sa=0017.9486.c711 (FastEthernet0/1)
IP(0): IP tos=0x0, len=100, id=10024, ttl=253, prot=1
IP(0): s=172.16.15.1 (FastEthernet0/1) d=224.1.1.1 (FastEthernet0/0)
ttl=253, prot=1, len=100(100), mforward
R4#
IP(0): MAC sa=0017.9486.c711 (FastEthernet0/1)
IP(0): IP tos=0x0, len=100, id=10025, ttl=253, prot=1
IP(0): s=172.16.15.1 (FastEthernet0/1) d=224.1.1.1 (FastEthernet0/0)
ttl=253, prot=1, len=100(100), mforward
id=10022,
id=10023,
id=10024,
id=10025,
Now
that
the
traffic
is
being
process
switched,
we
can
see
the
multicast
packets
enter
and
leave
R4.
The
multicast
feed
is
entering
the
FastEthernet0/1
interface
and
being
multicast
forwarded
out
the
3-21
FastEthernet0/0
interface.
We
can
verify
that
we
are
process
switching
the
multicast
traffic
with
the
show
ip
interface
command.
R4#show ip interface FastEthernet0/0 | inc multicast
IP multicast fast switching is disabled
IP multicast distributed fast switching is disabled
R4#show ip interface FastEthernet0/1 | inc multicast
IP multicast fast switching is disabled
IP multicast distributed fast switching is disabled
Notice
that
the
router
has
now
disabled
multicast
fast
switching.
In
this
analysis
of
PIM-DM
multicast
operation,
we
have
observed
the
flood
and
prune
behavior
used
to
propagate
multicast
packets.
We
have
looked
at
the
valuable
troubleshooting
tools
used
to
isolate
specific
behaviors
with
the
multicast
tree.
This
leaves
only
one
aspect
of
PIM-DM
to
explore.
Reverse
Path
Forwarding
We
have
not
introduced
any
errors
or
configuration
issues
into
this
topology.
However,
it
is
important
to
point
out
that
there
are
currently
RPF
check
failures
occurring
in
the
topology.
We
will
observe
this
occurring
by
re-enabling
the
ip
mroute-cache
capabilities
of
R4's
interfaces.
Once
this
is
accomplished,
we
will
execute
the
debug
ip
mpacket
command,
wait
for
the
flood,
and
prune
process
to
run
a
few
times.
We
will
then
analyze
the
output
of
the
debug
command.
R4(config)#interface FastEthernet0/0
R4(config-if)#ip mroute-cache
R4(config-if)#interface FastEthernet0/1
R4(config-if)#ip mroute-cache
R4(config-if)#end
R4#
%SYS-5-CONFIG_I: Configured from console by console
R4#debug ip mpacket detail list 101
IP multicast packets debugging is on (detailed) for access list 101
It
may
take
up
to
five
minutes
to
get
the
following
output.
R4#
IP(0): MAC sa=DLCI 406 (Serial0/0/0.1)
IP(0): IP tos=0x0, len=100, id=10599, ttl=250, prot=1
IP(0): s=172.16.15.1 (Serial0/0/0.1) d=224.1.1.1 id=10599, ttl=250, prot=1,
len=104(100), not RPF interface
3-22
After
the
flood
and
prune
has
run,
we
get
this
message.
Why
do
we
get
output
for
transit
traffic
when
we
just
discussed
the
necessity
to
disable
fast
switching?
In
multicast
fast
switching
the
first
packet
of
a
feed
will
be
processes
switched.
Therefore,
we
will
see
the
first
packet
that
arrives
during
each
flood
refresh.
The
issue
with
this
output
is
the
"not
RPF
interface"
value.
We
have
discussed
the
fact
that
the
PIM
multicast
routing
topology
forms
with
no
concern
for
multicast
routing
loops.
Instead,
PIM,
in
this
instance
PIM-DM,
relies
on
the
RPF
check
to
prevent
loops
in
the
multicast
data
plane.
Here
R4
is
receiving
an
mpacket
from
R6
because
there
is
a
loop
in
the
multicast
topology,
but
RPF
prevents
the
looping
of
multicast
packets
by
dropping
packets
that
arrive
on
interfaces
that
are
not
in
the
unicast
path
back
to
the
source.
The
RPF
check
takes
place
as
follows.
Once
a
multicast
packet
arrives
on
a
given
interface,
the
router
immediately
knows
two
things
based
on
the
information
in
the
packet:
the
source
and
group.
This
comprises
the
(S,G)
entry
in
the
multicast
routing
table
as
illustrated
by
the
show
ip
mroute
command.
R4#show ip mroute 224.1.1.1 | sec 1, 224
(172.16.15.1, 224.1.1.1), 01:31:14/00:02:54, flags: T
Incoming interface: FastEthernet0/1, RPF nbr 172.16.45.5
Outgoing interface list:
FastEthernet0/0, Forward/Dense, 01:25:48/00:00:00
Serial0/0/0.1, Prune/Dense, 00:02:18/00:00:42, A
Using
this
information
the
router
will
perform
a
recursive
lookup
on
the
source
IP
address
until
it
determines
the
interface
that
would
be
used
to
reach
the
IP
address
of
the
source
in
its
routing
table.
R4#show ip route 172.16.15.1
Routing entry for 172.16.15.0/24
Known via "eigrp 100", distance 90, metric 30720, type internal
Redistributing via eigrp 100
Last update from 172.16.45.5 on FastEthernet0/1, 08:38:53 ago
Routing Descriptor Blocks:
* 172.16.45.5, from 172.16.45.5, 08:38:53 ago, via FastEthernet0/1
Route metric is 30720, traffic share count is 1
Total delay is 200 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
The
route
172.16.15.1
is
reachable
via
the
IP
address
172.16.45.5.
How
will
R4
reach
172.16.45.5?
R4#show ip route 172.16.45.5
Routing entry for 172.16.45.0/24
Known via "connected", distance 0, metric 0 (connected, via interface)
Redistributing via eigrp 100
Routing Descriptor Blocks:
3-23
This
finally
recurses
to
the
physical
interface
FastEthernet0/1.
This
means
that
R4
will
expect
to
receive
multicast
packets
inbound
on
the
FastEthernet0/1
interface
from
a
PIM
neighbor
with
an
IP
address
of
172.16.45.5.
The
router
will
drop
any
mpackets
sourced
from
172.16.15.1
not
arriving
on
FastEthernet0/1
as
part
of
the
multicast
routing
loop
prevention
mechanism.
The
reverse
path
forwarding
check
is
a
normal
part
of
the
multicast
environment.
The
important
thing
to
learn
when
troubleshooting
multicast
issues
is
how
to
determine
when
an
RPF
check
failure
is
the
cause
of
a
problem
or
a
normal
part
of
the
multicast
routing
process.
On
R4,
a
simple
check
to
determine
the
RPF
interface
for
a
given
source
would
be
to
use
the
show
ip
rpf
command.
R4#show ip rpf 172.16.15.1
RPF information for ? (172.16.15.1)
RPF interface: FastEthernet0/1
RPF neighbor: ? (172.16.45.5)
RPF route/mask: 172.16.15.0/24
RPF type: unicast (eigrp 100)
RPF recursion count: 0
Doing distance-preferred lookups across tables
The
output
of
this
simple
command
provides
us
with
a
wealth
of
information.
We
see
the
multicast
source,
the
RPF
interface
for
that
source,
as
well
as
the
IP
address
of
the
neighbor
the
router
expects
to
send
the
multicast
packets.
The
output
even
tells
us
the
unicast
routing
protocol
used
to
perform
the
RPF
check.
3-24
Control
Plane
-
The
PIM-DM
control
plan
uses
PIM
messages
in
its
creation.
PIM
sends
messages
via
the
link-local
multicast
group
224.0.0.13,
and
are
therefore
subject
to
RPF
checks.
It
is
important
to
note
that
RPF
checks
in
the
control
plane
are
against
the
source
IP
address
encapsulated
into
each
PIM
packet
as
they
arrive.
More
often
than
not,
this
will
be
the
IP
address
of
the
adjacent
neighbor.
Data
Plane
-
PIM-DM
will
perform
RPF
checks
on
each
individual
multicast
packet
before
deciding
to
forward
it.
This
means
that
the
source
IP
address
of
each
multicast
packet
a
router
receives
must
be
reachable
out
the
receiving
interface
before
the
router
will
forward
it
to
an
adjacent
neighbor.
In
PIM-DM,
RPF
always
performs
checks
against
the
source
of
the
multicast
feed.
The
RPF
check
mechanism
can
result
in
scenarios
where
the
control
plane
fails
to
form
correctly,
or
multicast
packets
fail
to
transit
the
multicast
tree.
When
only
a
few
packets
or
no
packets
reach
the
receivers,
RPF
failures
will
normally
be
the
cause.
We
will
perform
a
walk
through
for
each
of
these
RPF
issues
in
the
PIM-DM
Sample
Troubleshooting
Scenarios
section
that
follows.
Hub
and
Spoke
Designs
It
is
important
to
remember
the
"split-horizon-like"
behavior
of
PIM-DM.
This
rule
states
that
an
interface
cannot
exist
in
both
the
incoming
interface
list
and
the
outgoing
interface
list
(OIL)
for
the
same
multicast
S,G
pair
at
the
same
time.
There
are
no
commands
in
PIM-DM
that
will
allow
the
3-25
deactivation
of
this
behavior.
So
in
order
to
facilitate
the
forwarding
of
multicast
packets
in
scenarios
like
multicast
hub-and-spoke
designs
it
will
be
necessary
to
utilize
other
solutions.
Solutions
for
these
situations
include,
but
are
not
limited
to
Tunnel
Interfaces
or
M-BGP.
Multicast
Threshold
Problems
Every
multicast
packet
has
a
TTL
value,
just
like
their
unicast
IP
counterparts.
In
many
environments,
using
PIM-DM,
this
fact
is
used
as
a
method
to
scope
or
contain
multicast
packets
to
the
internal
network.
Multicast-threshold
is
effectively
employed
to
keep
multicast
packets
from
leaking
into
any
internetwork
space.
However,
it
is
possible
to
create
a
multicast
routing
fault
by
setting
the
multicast
threshold
on
a
given
router
interface.
If
the
packet's
TTL
is
higher
than
the
multicast
threshold
configured
on
an
interface
(and
it
passes
the
RPF
check),
the
packet
will
be
forwarded.
If
the
TTL
of
the
packet
is
lower
than
the
multicast
threshold,
the
router
drops
the
packet.
The
possible
range
for
a
multicast
threshold
value
is
0
to
255,
with
0
meaning
all
packets
will
be
forwarded
verses
255
where
virtually
no
packets
will
be
forwarded.
In
the
PIM-DM
Sample
Troubleshooting
Scenarios
section
that
follows,
troubleshooting
of
these
issues
are
demonstrated.
For
each
problem,
the
text
demonstrates
how
to
quickly
and
efficiently
verify
each
symptom,
isolate
the
cause,
and
remediate
the
issue.
3-26
In
the
Common
Issues
with
PIM-DM
section,
three
primary
types
of
problems
were
identified:
RPF
failures,
Hub
and
Spoke
Designs,
and
Multicast
Threshold
problems.
This
section
explores
these
three
categories
of
failure
by
directing
our
attention
to
the
commands
necessary
to
verify
a
problem,
isolate
it
and
remediate
it.
Fault
isolation
in
PIM-DM
Setting
the
stage:
R9
will
join
the
multicast
group
224.9.9.9.
R9(config)#interface FastEthernet0/1
R9(config-if)#ip igmp join-group 224.9.9.9
R9(config-if)#end
Emulating
a
multicast
feed:
Can
R1
successfully
source
a
multicast
stream
from
172.16.15.1
to
the
group
224.9.9.9?
By
generating
a
ping
on
R1
to
the
group
224.9.9.9
R1
can
emulate
a
multicast
feed:
R1#ping 224.9.9.9 repeat 100000000
3-27
Are
there
interfaces
in
the
OIL
for
the
(172.16.15.1,
224.9.9.9)
group?
The
output
indicates
that
there
are
no
interfaces
in
the
output
list
with
the
value
of
"Null".
Looking
at
the
output
for
the
show
ip
mroute
count
command
for
the
group
224.9.9.9
we
see
what
is
happening:
R5#show ip mroute 224.9.9.9 count
IP Multicast Statistics
3 routes using 1548 bytes of memory
2 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts(neg(-) = Drops) per second/Avg Pkt Size/Kilobits per
second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 224.9.9.9, Source count: 1, Packets forwarded: 0, Packets received: 86
Source: 172.16.15.1/32, Forwarding: 0/-1/0/0, Other: 86/0/86
3-28
This
output
tells
us
many
things;
first,
we
know
we
are
dropping
about
1
packet
per
second.
This
can
be
seen
under
the
Forwarding
Counts
based
on
the
value
-1.
Next,
we
know
that
we
do
not
have
an
RPF
check
issue
because
the
second
field
in
the
Other
Counts
category
is
0.
Lastly,
we
see
that
we
have
received
86
multicast
packets
for
the
group
224.9.9.9
and
we
have
dropped
86
packets
for
"Other"
reasons.
The
command
even
points
out
some
common
issues.
Interpreting
this
output
is
simple.
We
have
no
interfaces
in
the
OIL
for
this
group.
The
reason
will
be
revealed
when
we
look
at
the
output
of
show
ip
pim
neighbors
on
R5.
R5#show ip pim neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
S - State Refresh Capable
Neighbor
Interface
Uptime/Expires
Ver
DR
Address
Prio/Mode
172.16.15.1
FastEthernet0/0
01:06:25/00:01:16 v2
1 / S
Immediately,
we
can
see
there
is
no
PIM-DM
neighbor
relationship
with
R4.
Logically
the
next
step
would
be
to
verify
what
interfaces
are
participating
in
PIM-DM
on
R4:
R5#show ip pim interface
Address
Interface
172.16.15.5
172.16.45.5
FastEthernet0/0
FastEthernet0/1
Ver/
Mode
v2/D
v2/D
Nbr
Count
1
0
Query
Intvl
30
30
DR
Prior
1
1
DR
172.16.15.5
172.16.45.5
R5
is
running
PIM-DM
on
the
FastEthernet0/1
interface
toward
R4.
What
about
R4
is
it
running
the
PIM-
DM
on
the
interface
toward
R4?
R4#show ip pim neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
S - State Refresh Capable
Neighbor
Interface
Uptime/Expires
Ver
DR
Address
Prio/Mode
172.16.24.2
FastEthernet0/0
01:53:26/00:01:26 v2
1 / S
172.16.46.6
Serial0/0/0.1
01:52:41/00:01:43 v2
1 / S
R4
is
not
running
PIM-DM
on
its
FastEthernet0/1
interface.
To
correct
this
issue
the
ip
pim
dense-mode
command
will
be
applied:
R4(config)#interface FastEthernet0/1
R4(config-if)#ip pim dense-mode
3-29
R4(config-if)#end
R4#
%PIM-5-NBRCHG: neighbor 172.16.45.5 UP on interface FastEthernet0/1
%PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 172.16.45.5 on interface
FastEthernet0/1
%SYS-5-CONFIG_I: Configured from console by console
It
is
not
successful.
Are
there
interfaces
in
the
OIL
for
the
224.9.9.9
S,G
pair
on
R5
now?
R5#show ip mroute 224.9.9.9
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.9.9.9), 01:08:25/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/1, Forward/Dense, 00:05:16/00:00:00
FastEthernet0/0, Forward/Dense, 01:08:25/00:00:00
(172.16.15.1, 224.9.9.9), 00:05:25/00:02:59, flags: T
Incoming interface: FastEthernet0/0, RPF nbr 172.16.15.1
Outgoing interface list:
FastEthernet0/1, Forward/Dense, 00:05:17/00:00:00
R5
now
has
FastEthernet0/1
in
OIL
of
the
entry.
Are
multicast
packets
being
forwarded
to
R4?
We
will
clear
the
multicast
routing
table
to
before
we
take
a
look
at
the
counters.
R5#clear ip mroute *
3-30
We
see
the
S,G
entry
for
the
pair.
There
are
two
interfaces
in
the
OIL.
It
is
important
to
observe
that
FastEthernet0/0
and
Serial0/0/0.1
both
have
different
Interface
states.
FastEthernet0/0
is
operating
in
3-31
PIM-DM
mode,
but
has
a
state
of
Pruned.
We
know
this
means
no
device
on
this
segment
has
joined
or
knows
of
a
member
of
the
group
224.9.9.9.
However,
the
interface
Serial0/0/0.1
is
in
PIM-DM
and
in
a
forwarding
state.
Seeing
that
R4
is
forwarding
out
this
interface
the
next
logical
step
will
be
to
follow
this
link
to
the
next
adjacent
PIM-DM
neighbor.
We
can
find
that
by
with
show
ip
pim
neighbor:
R4#show ip pim neighbor Serial0/0/0.1
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
S - State Refresh Capable
Neighbor
Interface
Uptime/Expires
Ver
DR
Address
Prio/Mode
172.16.46.6
Serial0/0/0.1
02:18:56/00:01:32 v2
1 / S
The
next
device
we
need
to
look
at
is
R6
(172.16.46.6)
according
to
this
output.
We
need
to
look
at
the
multicast
routing
table
on
this
router
now:
R6#show ip mroute 224.9.9.9
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.9.9.9), 00:26:29/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial0/1/0.1, Forward/Dense, 00:26:29/00:00:00
FastEthernet0/0, Forward/Dense, 00:26:29/00:00:00
(172.16.15.1, 224.9.9.9), 00:02:29/00:00:30, flags:
Incoming interface: Null, RPF nbr 172.16.26.2
Outgoing interface list:
FastEthernet0/0, Forward/Dense, 00:02:30/00:00:00
Serial0/1/0.1, Forward/Dense, 00:02:30/00:00:00
We
have
interfaces
in
the
OIL
for
the
224.9.9.9
S,G
pair
and
they
are
both
operating
in
PIM-DM
and
are
in
the
forwarding
state.
However,
something
very
important
is
missing
in
this
output.
The
incoming
interface
list
is
NULL.
This
means
R6
is
learning
the
S,G
entry
for
224.9.9.9
but
it
is
not
learning
it
from
its
3-32
RPF
neighbor.
What
is
the
RPF
neighbor?
The
output
demonstrates
that
R6
expects
to
learn
about
this
multicast
source
from
R2
(172.16.26.2).
This
means
that
R6
is
expecting
to
receive
the
multicast
stream
sourced
from
R1's
172.16.15.1
unicast
address
on
what
interface?
R6#show ip route 172.16.15.1
Routing entry for 172.16.15.0/24
Known via "eigrp 100", distance 90, metric 35840, type internal
Redistributing via eigrp 100
Last update from 172.16.26.2 on FastEthernet0/1, 02:59:16 ago
Routing Descriptor Blocks:
* 172.16.26.2, from 172.16.26.2, 02:59:16 ago, via FastEthernet0/1
Route metric is 35840, traffic share count is 1
Total delay is 400 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 3
Notice
that
172.16.15.1
is
reachable
via
the
ip
address
172.16.26.2
on
FastEthernet0/1.
This
is
the
interface
that
R6
expects
to
receive
the
stream
on.
Is
R6
forwarding
multicast
packets
for
the
group
224.9.9.9?
R6#show ip mroute 224.9.9.9 count
IP Multicast Statistics
3 routes using 2170 bytes of memory
2 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts(neg(-) = Drops) per second/Avg Pkt Size/Kilobits per
second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 224.9.9.9, Source count: 1, Packets forwarded: 0, Packets received: 87
Source: 172.16.15.1/32, Forwarding: 0/0/0/0, Other: 87/87/0
R6
is
not
forwarding
packets.
Observe
the
Other
Count
section
of
the
output.
This
tells
us
that
87
packets
have
arrived
and
that
87
packets
were
dropped
because
they
failed
the
RPF
check.
At
this
point,
we
know
that
the
RPF
interface
should
be
FastEthernet0/1.
Are
multicast
packets
arriving
on
this
interface?
R6#show ip mroute interface FastEthernet0/1
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
3-33
There
are
no
packets
arriving
on
this
interface.
Are
there
any
PIM
neighbors
on
out
this
interface?
R6#show ip pim neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
S - State Refresh Capable
Neighbor
Interface
Uptime/Expires
Ver
DR
Address
Prio/Mode
172.16.67.7
FastEthernet0/0
10:05:05/00:01:35 v2
1 / DR S
172.16.46.4
Serial0/1/0.1
10:05:21/00:01:38 v2
1 / S
Interface
172.16.67.6
172.16.46.6
FastEthernet0/0
Serial0/1/0.1
Ver/
Nbr
Mode
Count
v2/D
1
v2/D
1
Query
Intvl
30
30
DR
Prior
1
1
DR
172.16.67.7
0.0.0.0
Observe
that
the
neighbor
172.16.26.2
has
come
"UP".
If
this
has
corrected
the
issue
on
R6
we
should
now
see
FastEthernet0/1
in
the
incoming
interface
list
for
the
224.9.9.9
(S,G)
pair.
R6#show ip mroute 224.9.9.9
3-34
Observe
that
the
interface
is
in
the
Incoming
interface
list
as
we
expected.
We
see
that
the
FastEthernet0/0
interface
is
in
the
OIL
and
that
it
is
operating
in
PIM-DM
mode
and
in
the
forwarding
state.
Are
packets
being
forwarded?
R6#clear ip mroute *
R6#show ip mroute 224.9.9.9 count
IP Multicast Statistics
3 routes using 2554 bytes of memory
2 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts(neg(-) = Drops) per second/Avg Pkt Size/Kilobits per
second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 224.9.9.9, Source count: 1, Packets forwarded: 16, Packets received: 16
Source: 172.16.15.1/32, Forwarding: 16/1/100/0, Other: 16/0/0
This
output
tells
us
that
each
of
the
16
packets
R6
has
received
have
been
forwarded.
We
used
the
clear
ip
mroute
*
command
to
clear
the
counters.
The
multicast
issues
on
R6
have
been
remediated.
Are
the
pings
from
R1
working
now?
R1#
3-35
Reply to request
Reply to request
Reply to request
Reply to request
Reply to request
Reply to request
Reply to request
Reply to request
Reply to request
Reply to request
<output omitted>
17230
17231
17232
17233
17234
17235
17236
17237
17238
17239
from
from
from
from
from
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
1
1
1
1
1
1
1
1
1
1
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
This
output
demonstrates
that
R9
is
now
receiving
the
multicast
feed
sent
from
R1.
This
configuration
had
multiple
issues
that
required
the
hop-by-hop
verification.
Other
methods
exist
for
isolating
the
problematic
areas
in
a
multicast
routing
topology.
Troubleshooting
Method
Two:
Using
mtrace
to
isolate
the
location
of
a
single
fault
The
hop-by-hop
method
of
fault
isolation
lends
itself
readily
to
environments
where
there
may
be
multiple
issues
associated
with
the
multicast
topology
failing
to
operate.
There
are
two
primary
tools
that
can
be
used
to
quickly
identify
the
location
where
a
multicast
fault
may
exist.
In
this
section
the
mtrace
utility
will
be
used
to
isolate
a
fault.
In
this
section
R9
is
still
joined
to
the
group
224.9.9.9,
and
R1
has
failed
to
successfully
send
pings
to
that
address.
This
test
can
be
done
with
any
multicast
group
and
does
not
require
the
receiver
to
have
actually
joined
the
group
used.
Step
One:
Use
mtrace
on
R1
to
isolate
the
place
in
the
topology
where
the
multicast
stream
fails.
R1#mtrace 172.16.15.1 172.16.79.9 224.1.1.1
Type escape sequence to abort.
Mtrace from 172.16.15.1 to 172.16.79.9 via group 224.1.1.1
From source (?) to destination (?)
Querying full reverse path... * switching to hop-by-hop:
0 172.16.79.9
-1 * 172.16.79.9 PIM [172.16.15.0/24]
-2 * 172.16.79.7 None Multicast disabled [172.16.15.0/24]
This
output
demonstrates
that
the
issue
exists
on
R7.
Specifically,
the
command
notifies
us
that
PIM
is
not
enabled
on
the
interface
with
the
IP
address
of
172.16.79.7.
This
indicates
where
to
begin
troubleshooting.
The
next
step
is
to
go
to
R7
and
look
to
see
if
it
is
running
the
interface
connected
to
R9
in
PIM-DM.
This
can
be
verified
by
running
show
ip
pim
neighbors.
R7#show ip pim neighbor
PIM Neighbor Table
3-36
The
interface
connected
to
R9
is
not
running
PIM-DM.
This
can
be
remediated
by
applying
the
command
under
the
FastEthernet0/1.
R7(config)#interface FastEthernet0/1
R7(config-if)#ip pim dense-mode
R7(config-if)#end
%PIM-5-NBRCHG: neighbor 172.16.79.9 UP on interface FastEthernet0/1
%PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 172.16.79.9 on interface
FastEthernet0/1
The
PIM-DM
neighbor
comes
up.
As
verification,
the
mtrace
command
will
be
used
again
on
R1.
R1#mtrace 172.16.15.1 172.16.79.9 224.1.1.1
Type escape sequence to abort.
Mtrace from 172.16.15.1 to 172.16.79.9 via group 224.1.1.1
From source (?) to destination (?)
Querying full reverse path... * switching to hop-by-hop:
0 172.16.79.9
-1 * 172.16.79.9 PIM [172.16.15.0/24]
-2 * 172.16.79.7 PIM [172.16.15.0/24]
-3 * 172.16.67.6 PIM [172.16.15.0/24]
-4 * 172.16.26.2 PIM [172.16.15.0/24]
-5 * 172.16.24.4 PIM [172.16.15.0/24]
-6 * 172.16.45.5 PIM [172.16.15.0/24]
-7 * 172.16.15.1 PIM [172.16.15.0/24]
The
output
clearly
demonstrates
that
the
path
between
R1
and
R9
no
longer
has
any
issues.
As
a
final
verification,
the
ping
test
will
be
repeated.
R1#ping 224.9.9.9 repeat 5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 224.9.9.9, timeout is 2 seconds:
Reply to request 0 from 172.16.79.9, 8 ms
Reply to request 1 from 172.16.79.9, 1 ms
Reply to request 2 from 172.16.79.9, 1 ms
Reply to request 3 from 172.16.79.9, 1 ms
Reply to request 4 from 172.16.79.9, 1 ms
3-37
show
COMMAND:
show
ip
igmp
membership
[group-address
|
group-name]
[tracked]
[all]
This
command
displays
Internet
Group
Management
Protocol
(IGMP)
membership
information
for
multicast
groups
and
(S,
G)
channels.
Where:
EXAMPLE
OUTPUT:
R9#show ip igmp membership
Flags: A - aggregate, T - tracked
L - Local, S - static, V - virtual, R - Reported through v3
I - v3lite, U - Urd, M - SSM (S,G) channel
1,2,3 - The version of IGMP the group is in
Channel/Group-Flags:
/ - Filtering entry (Exclude mode (S,G), Include mode (*,G))
Reporter:
<mac-or-ip-address> - last reporter if group is not explicitly tracked
<n>/<m>
- <n> reporter in include mode, <m> reporter in exclude
3-38
Channel/Group
*,224.9.9.9
*,224.0.1.40
Reporter
172.16.79.9
172.16.79.9
Uptime
Exp. Flags
00:24:29 02:25 2LA
00:24:29 02:31 2LA
Interface
Fa0/1
Fa0/1
show
COMMAND:
show
ip
mroute
This
command
displays
the
contents
of
the
multicast
routing
(mroute)
table.
EXAMPLE
OUTPUT:
R7#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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.9.9.9), 00:54:11/stopped, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Dense, 00:16:16/00:00:00
FastEthernet0/1, Forward/Dense, 00:54:11/00:00:00
(172.16.79.7, 224.9.9.9), 00:00:06/00:02:53, flags: PT
Incoming interface: FastEthernet0/1, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Prune/Dense, 00:00:07/00:02:52
(*, 224.0.1.40), 00:54:15/00:02:50,
Incoming interface: Null, RPF nbr
Outgoing interface list:
FastEthernet0/1, Forward/Dense,
FastEthernet0/0, Forward/Dense,
show
COMMAND:
show
ip
pim
interface
3-39
This
command
displays
information
about
interfaces
configured
for
Protocol
Independent
Multicast
(PIM).
EXAMPLE
OUTPUT:
R7#show ip pim interface
Address
Interface
172.16.67.7
172.16.79.7
FastEthernet0/0
FastEthernet0/1
Ver/
Mode
v2/D
v2/D
Nbr
Count
1
1
Query
Intvl
30
30
DR
Prior
1
1
DR
172.16.67.7
172.16.79.9
show
COMMAND:
show
ip
pim
[vrf
vrf-name]
neighbor
[interface-type
interface-number]
This
command
displays
information
about
Protocol
Independent
Multicast
(PIM)
neighbors
discovered
by
PIM
version
1
router
query
messages
or
PIM
version
2
hello
messages.
Where:
EXAMPLE
OUTPUT:
R5#show ip pim neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default
S - State Refresh Capable
Neighbor
Interface
Uptime/Expires
Address
172.16.15.1
FastEthernet0/0
00:26:04/00:01:16
172.16.45.4
FastEthernet0/1
00:22:39/00:01:43
DR Priority,
Ver
v2
v2
DR
Prio/Mode
1 / S
1 / S
show
COMMAND:
show
ip
rpf
[vrf
vrf-name]
{route-distinguisher
|
source-address
[group-address]
[rd
route-
distinguisher]}
[metric]
This
command
displays
information
that
IP
multicast
routing
uses
to
perform
the
Reverse
Path
Forwarding
(RPF)
check
for
a
multicast
source
Where:
3-40
EXAMPLE
OUTPUT:
R5#show ip rpf 192.1.2.2
RPF information for ? (192.1.2.2)
RPF interface: FastEthernet0/1
RPF neighbor: ? (172.16.45.4)
RPF route/mask: 192.1.2.0/24
RPF type: unicast (eigrp 100)
RPF recursion count: 0
Doing distance-preferred lookups across tables
debug
COMMAND:
debug
ip
mpacket
[vrf
vrf-name]
[detail
|
fastswitch]
[access-list]
[group]
3-41
This
command
displays
multicast
packets
that
are
received
and
sent
on
the
device.
Where:
EXAMPLE
OUTPUT:
IP(0): s=172.16.24.4
len=114(100), mroute
IP(0): s=172.16.24.4
len=114(100), mroute
IP(0): s=172.16.24.4
len=114(100), mroute
debug
COMMAND:
debug
ip
pim
[vrf
vrf-name]
[bsr]
This
command
displays
Protocol
Independent
Multicast
(PIM)
packets
received
and
sent
and
displays
PIM-related
events
Where:
EXAMPLE
OUTPUT:
R7#debug ip pim
PIM debugging is on
PIM(0): Received v2 Join/Prune on FastEthernet0/0 from 172.16.67.6, to us
PIM(0): Prune-list: (172.16.79.7/32, 224.9.9.9)
PIM(0): Prune FastEthernet0/0/224.9.9.9 from (172.16.79.7/32, 224.9.9.9)
IP(0): s=172.16.79.7 (FastEthernet0/1) d=224.9.9.9 id=8, ttl=254, prot=1,
len=114(100), mroute olist null
3-42
Trouble
Ticket
#1
Your
supervisor
has
brought
to
your
attention
that
users
on
the
192.1.2.0/24
network
cannot
receive
the
multicast
feed
from
the
source
R1.
The
feed
should
be
destined
to
the
multicast
address
224.2.2.2.
You
must
correct
the
issue.
Trouble
Ticket
#2
After
solving
Trouble
Ticket
#1,
your
supervisor
has
observed
that
users
on
the
network
192.1.6.0/24
cannot
receive
traffic
destined
to
the
multicast
group
224.6.6.6.
You
must
correct
this
issue.
Trouble
Ticket
#3
Your
supervisor
has
notified
you
that
users
on
the
network
172.16.79.0/24
are
not
receiving
multicast
feeds.
Use
the
multicast
group
224.9.9.9
to
verify
this
task.
You
must
correct
this
issue.
3-43
Figure
3-8:
PIM-DM
Quick
Fire
Troubleshooting
Flowchart
Trouble
Ticket
#1
Solution
Your
supervisor
has
brought
to
your
attention
that
users
on
the
192.1.2.0/24
network
cannot
receive
the
multicast
feed
from
the
source
R1.
The
feed
should
be
destined
to
the
multicast
address
224.2.2.2.
You
must
correct
the
issue.
Step
1
-
Fault
Verification:
Does
R2
reply
to
pings
to
the
multicast
group
224.2.2.2:
R1#ping 224.2.2.2 repeat 5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 224.2.2.2, timeout is 2 seconds:
.....
3-44
The
pings
are
not
successful.
This
verifies
that
the
problem
actually
exists.
Step
2
-
Fault
Isolation:
The
next
course
of
action
is
to
use
the
mtrace
utility
to
rule
out
the
possibility
of
an
RPF
issue.
Make
certain
to
perform
this
process
in
both
directions,
first
from
R2
toward
R7,
then
from
R7
toward
R2.
R1#mtrace 172.16.15.1 192.1.2.2
Type escape sequence to abort.
Mtrace from 172.16.15.1 to 192.1.2.2 via RPF
From source (?) to destination (?)
Querying full reverse path...
0 192.1.2.2
-1 172.16.24.2 PIM [172.16.15.0/24]
-2 172.16.24.4 None No route
This
output
indicates
that
the
multicast
traffic
is
stopping
on
R4.
The
show
ip
pim
neighbor
command
will
tell
us
whether
or
not
we
have
PIM-DM
relationships
with
the
neighboring
PIM-DM
enabled
routers.
R4#show ip pim neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
S - State Refresh Capable
Neighbor
Interface
Uptime/Expires
Ver
DR
Address
Prio/Mode
172.16.24.2
FastEthernet0/0
1d09h/00:01:15
v2
1 / S
172.16.46.6
Serial0/0/0.1
1d09h/00:01:30
v2
1 / S
The
verification
clearly
demonstrates
that
R4
has
not
neighbor
relationship
with
R5
via
FastEthernet0/1.
This
most
likely
means
that
the
ip
pim
dense-mode
is
missing
either
on
R4
or
R5.
The
show
ip
pim
interface
will
quickly
reveal
which
device.
R4#show ip pim interface
Address
Interface
172.16.24.4
172.16.46.4
FastEthernet0/0
Serial0/0/0.1
Ver/
Mode
v2/D
v2/D
Nbr
Count
1
1
Query
Intvl
30
30
DR
Prior
1
1
DR
172.16.24.4
0.0.0.0
The
ip
pim
dense-mode
command
is
missing
under
FastEthernet0/1
interface
thus
blocking
the
multicast
traffic.
This
has
unquestionably
isolated
our
fault.
Step
3
-
Fault
Remediation:
3-45
In
this
scenario,
the
ip
pim
dense-mode
command
should
be
applied
under
the
interface
as
we
have
in
the
past.
R4#conf t
Enter configuration commands, one per line.
R4(config)#interface FastEthernet0/1
R4(config-if)#ip pim dense-mode
R4(config-if)#end
Step
4
-
Verification
of
Remediation
Once
the
error
has
been
isolated
and
remediated
it
is
highly
recommended
to
verify
that
the
Trouble
Ticket
has
been
repaired
using
the
same
method
of
the
initial
fault
verification.
R1#ping 224.2.2.2 repeat 5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 224.2.2.2, timeout is 2 seconds:
Reply
Reply
Reply
Reply
Reply
to
to
to
to
to
request
request
request
request
request
0
1
2
3
4
from
from
from
from
from
172.16.24.2,
172.16.24.2,
172.16.24.2,
172.16.24.2,
172.16.24.2,
4
4
1
1
1
ms
ms
ms
ms
ms
The
issue
has
been
corrected.
Trouble
Ticket
#2
Solution
After
solving
Trouble
Ticket
#1,
your
supervisor
has
observed
that
users
on
the
network
192.1.6.0/24
cannot
receive
traffic
destined
to
the
multicast
group
224.6.6.6.You
must
correct
this
issue.
Step
1
-
Fault
Verification:
Can
R1
ping
the
group
224.6.6.6
successfully:
R1#ping 224.6.6.6 repeat 5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 224.6.6.6, timeout is 2 seconds:
.....
The
ping
test
to
the
multicast
group
224.6.6.6
fails.
This
verifies
that
the
problem
actually
exists.
Step
2
-
Fault
Isolation:
In
order
to
verify
that
RPF
issues
are
not
at
fault,
use
the
mtrace
utility.
3-46
R1#mtrace 172.16.15.1 192.1.6.6
Type escape sequence to abort.
Mtrace from 172.16.15.1 to 192.1.6.6 via RPF
From source (?) to destination (?)
Querying full reverse path...
0 192.1.6.6
-1 172.16.26.6 PIM [172.16.15.0/24]
-2 172.16.26.2 PIM [172.16.15.0/24]
-3 172.16.24.4 PIM [172.16.15.1/32]
-4 172.16.45.5 PIM [172.16.15.0/24]
-5 172.16.15.1
There
seems
to
be
no
issues
involving
multicast
RPF
failures.
With
this
observation,
we
can
next
look
to
see
if
the
issue
may
be
TTL-Threshold
induced
with
the
mstat
command:
R1#mstat 172.16.15.1 192.1.6.6
Type escape sequence to abort.
Mtrace from 172.16.15.1 to 192.1.6.6 via RPF
From source (?) to destination (?)
Waiting to accumulate statistics......
Results after 10 seconds:
Source
Response Dest
172.16.15.1
172.16.15.1
|
__/ rtt 0
ms
v
/
hop 169 s
172.16.15.5
172.16.45.5
?
|
^
ttl
0
v
|
hop -213 s
172.16.45.4
172.16.24.4
?
|
^
ttl
1
v
|
hop -244 s
172.16.24.2
172.16.26.2
?
|
^
ttl
255
v
|
hop -66 s
172.16.26.6
?
|
\__
ttl
256
v
\ hop -169 s
192.1.6.6
172.16.15.1
Receiver
Query Source
-2/0 = --%
0 pps
0/0 = --%
0 pps
-3/0 = --%
0 pps
0/0 = --%
0 pps
-2/0 = --%
0 pps
0/0 = --%
0 pps
0 pps
0 pps
Observe
that
the
output
indicates
that
the
TTL
values
progress
in
the
following
pattern
0,1,255,256.
We
can
see
that
the
TTL
count
jumps
massively
on
R2.
Specifically
this
happens
on
the
interface
with
the
IP
address
172.16.26.2
(GigabitEthernet0/1).
Show
run
interface
GigabitEthernet
0/1
will
reveal
any
interface
specific
commands
that
may
cause
this.
3-47
We
see
the
ip
multicast
ttl-threshold
255
command.
This
command
causes
the
issue
associated
with
this
trouble
ticket.
This
has
isolated
our
fault.
Step
3
-
Fault
Remediation:
In
this
scenario,
the
ip
multicast
ttl-theshold
255
command
needs
removed
from
R2's
GigabitEthernet0/1
interface:
R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#interface GigabitEthernet0/1
R2(config-if)#no ip multicast ttl-threshold 255
R2(config-if)#end
Step
4
-
Verification
of
Remediation
Once
the
error
has
been
isolated
and
remediated,
it
is
highly
recommended
to
verify
that
the
Trouble
Ticket
has
been
repaired
using
the
same
method
used
to
verify
the
fault
initially:
R1#ping 224.6.6.6 repeat 5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 224.6.6.6, timeout is 2 seconds:
Reply
Reply
Reply
Reply
Reply
to
to
to
to
to
request
request
request
request
request
0
1
2
3
4
from
from
from
from
from
172.16.26.6,
172.16.26.6,
172.16.26.6,
172.16.26.6,
172.16.26.6,
4
1
1
1
1
ms
ms
ms
ms
ms
The
issue
has
been
corrected.
3-48
The
pings
are
not
successful.
This
verifies
that
the
problem
actually
exists.
Step
2
-
Fault
Isolation:
To
ensure
that
the
issue
is
not
RPF
related,
use
the
mtrace
utility.
R1#mtrace 172.16.15.1 172.16.79.9
Type escape sequence to abort.
Mtrace from 172.16.15.1 to 172.16.79.9 via RPF
From source (?) to destination (?)
Querying full reverse path...
0 172.16.79.9
-1 172.16.79.9 PIM [172.16.15.0/24]
-2 172.16.79.7 PIM [172.16.15.0/24]
-3 172.16.67.6 PIM [172.16.15.0/24]
-4 172.16.26.2 PIM [172.16.15.0/24]
-5 172.16.24.4.5 PIM [172.16.15.0/24]
-6 172.16.45PIM [172.16.15.0/24]
-7 172.16.15.1
There
are
no
RPF
issues
in
the
multicast
routing
path.
Now
use
the
mstat
utility
to
verify
that
the
issue
is
not
a
TTL-Threshold
problem:
R1#mstat 172.16.15.1 172.16.79.9
Type escape sequence to abort.
Mtrace from 172.16.15.1 to 172.16.79.9 via RPF
From source (?) to destination (?)
Waiting to accumulate statistics......
Results after 10 seconds:
3-49
Source
Response Dest
172.16.15.1
172.16.15.1
|
__/ rtt 3
ms
v
/
hop 244 s
172.16.15.5
172.16.45.5
?
|
^
ttl
0
v
|
hop 235 s
172.16.45.4
172.16.24.4
?
|
^
ttl
1
v
|
hop -244 s
172.16.24.2
172.16.26.2
?
|
^
ttl
2
v
|
hop -66 s
172.16.26.6
172.16.67.6
?
|
^
ttl
3
v
|
hop 85
s
172.16.67.7
172.16.79.7
?
|
^
ttl
4
v
|
hop -9
s
172.16.79.9
?
|
\__
ttl
5
v
\ hop -244 s
172.16.79.9
172.16.15.1
Receiver
Query Source
-2/0 = --%
0 pps
0/0 = --%
0 pps
-2/0 = --%
0 pps
0/0 = --%
0 pps
-2/0 = --%
0 pps
0/0 = --%
0 pps
-3/0 = --%
0 pps
0/0 = --%
0 pps
-2/0 = --%
0 pps
0/0 = --%
0 pps
0 pps
0 pps
The
TTL
values
increment
normally
(0,1,2,3,4
and
5).
This
means
that
there
are
no
TTL-Threshold
issues.
Having
ruled
this
out
the
only
tool
left
to
us
is
to
use
the
hop-by-hop
technique.
Ping
the
multicast
group
224.9.9.9
with
a
very
high
repeat
count:
R1#ping 224.9.9.9 repeat 500000
Type escape sequence to abort.
Sending 500000, 100-byte ICMP Echos to 224.9.9.9, timeout is 2 seconds:
........... <output omitted>
To
demonstrate
how
to
streamline
the
hop-by-hop
process
we
will
use
show
ip
mroute
on
all
devices
between
R1
and
R9,
looking
to
see
if
the
(S,G)
entry
for
(172.16.15.1,
224.9.9.9)
has
incoming
interfaces,
and
outgoing
interfaces
in
the
foward/dense
state
beginning
with
R5:
R5#show ip 9.9 | mroute 224.9.sec .1, 224.9
(172.16.15.1, 224.9.9.9), 00:03:03/00:02:51, flags: T
Incoming interface: FastEthernet0/0, RPF nbr 172.16.15.1
Outgoing interface list:
FastEthernet0/1, Forward/Dense, 00:03:03/00:00:00
3-50
Now
R4:
R4#show ip mroute 224.9.9.9 | sec .1, 224.9
(172.16.15.1, 224.9.9.9), 00:04:00/00:02:56, flags: T
Incoming interface: FastEthernet0/1, RPF nbr 172.16.45.5
Outgoing interface list:
Serial0/0/0.1, Prune/Dense, 00:00:55/00:02:04, A
FastEthernet0/0, Forward/Dense, 00:04:00/00:00:00
Now
R2:
R2#show ip mroute 224.9.9.9 | sec .1, 224.9
(172.16.15.1, 224.9.9.9), 00:04:00/00:02:55, flags: T
Incoming interface: GigabitEthernet0/0, RPF nbr 172.16.24.4
Outgoing interface list:
GigabitEthernet0/1, Forward/Dense, 00:04:00/00:00:00
Now
R6:
R6#show ip mroute 224.9.9.9 | sec .1, 224.9
(172.16.15.1, 224.9.9.9), 00:04:00/00:03:02, flags: T
Incoming interface: FastEthernet0/1, RPF nbr 172.16.26.2
Outgoing interface list:
FastEthernet0/0, Forward/Dense, 00:04:00/00:00:00
Serial0/1/0.1, Prune/Dense, 00:00:56/00:02:06
Then
R7:
R7#show ip mroute 224.9.9.9 | sec .1, 224.9
(172.16.15.1, 224.9.9.9), 00:01:00/00:01:59, flags: T
Incoming interface: FastEthernet0/0, RPF nbr 172.16.67.6
Int Limit 0 kbps
Outgoing interface list:
FastEthernet0/1, Forward/Dense, 00:01:00/00:00:00
We
see
that
the
routers
between
R1
and
R9
are
all
forwarding
the
multicast
traffic
for
the
group
224.9.9.9.
However,
on
R7
we
see
something
new
in
the
show
ip
mroute
output.
Observe
that
the
incoming
interface
for
the
S,G
pair
states
that
multicast
rate-limiting
has
been
applied.
The
interface
is
configured
to
allow
0
kbps
of
multicast
traffic.
This
can
be
confirmed
via
show
run
interface
FastEthernet0/0:
R7#show run interface FastEthernet0/0
Building configuration...
Current configuration : 145 bytes
3-51
!
interface FastEthernet0/0
ip address 172.16.67.7 255.255.255.0
ip pim dense-mode
ip multicast rate-limit in 0
duplex auto
speed auto
end
Looking
carefully
at
this
output
on
R7,
leads
us
to
believe
that
the
router
is
not
going
to
allow
any
multicast
traffic
to
enter
this
interface.
This
has
isolated
the
design
fault.
Step
3
-
Fault
Remediation:
In
this
scenario,
the
ip
multicast
rate-limit
command
on
FastEthernet0/0
should
be
removed.
R7#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R7(config)#interface FastEthernet0/0
R7(config-if)#no ip multicast rate-limit in 0
R7(config-if)#end
Step
4
-
Verification
of
Remediation
Once
the
error
has
been
isolated
and
remediated,
it
is
highly
recommended
to
verify
that
the
Trouble
Ticket
has
been
repaired
using
the
same
method
used
to
verify
the
fault
initially.
R1#ping 224.9.9.9 repeat 5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 224.9.9.9, timeout is 2 seconds:
Reply
Reply
Reply
Reply
Reply
to
to
to
to
to
request
request
request
request
request
0
1
2
3
4
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
1
1
1
1
1
ms
ms
ms
ms
ms
The
pings
to
the
group
from
R1
are
now
successful.
3-52
Chapter
4:
Protocol
Independent
Multicast
-
Sparse
Mode
(PIM-SM)
In
this
chapter
of
IPv4/6
Multicast
Operation
and
Troubleshooting,
the
processes
and
the
functionality
of
the
Protocol
Independent
Multicast
-
Spare-Mode
(PIM-SM)
protocol
are
examined
in
great
depth.
Once
the
operational
characteristics
of
this
important
protocol
are
detailed
completely,
the
focus
becomes
that
of
troubleshooting.
This
includes
the
careful
examination
of
symptoms,
a
fault
isolation
methodology,
and
the
implementation
of
repairs
for
PIM-SM.
The
chapter
begins
with
a
thorough
review
of
PIM-SM,
and
then
quickly
launches
in
to
an
exhaustive
analysis
of
the
art
of
troubleshooting
this
multicast
protocol.
This
important
chapter
concludes
with
sample
troubleshooting
scenarios,
reference
materials
for
the
most
important
show
and
debug
commands,
and
exciting
challenges
that
allow
readers
to
practice
implementing
the
troubleshooting
skills
they
have
obtained.
4-1
4-2
4-3
We
will
statically
assign
R2
to
be
the
RP
in
this
network.
Beginning
with
R9
and
working
our
way
to
R2
initially.
R9(config)#ip
R7(config)#ip
R6(config)#ip
R2(config)#ip
pim
pim
pim
pim
rp-address
rp-address
rp-address
rp-address
192.1.2.2
192.1.2.2
192.1.2.2
192.1.2.2
All
the
interfaces
between
each
of
these
devices
are
running
ip
pim
sparse-mode,
and
we
have
statically
assigned
the
RP
on
each
device.
The
output
of
show
ip
pim
rp
mapping
will
demonstrate
that
these
4
devices
agree
on
the
identity
of
the
RP.
R9#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s): 224.0.0.0/4, Static
RP: 192.1.2.2 (?)
R7#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s): 224.0.0.0/4, Static
RP: 192.1.2.2 (?)
R6#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s): 224.0.0.0/4, Static
RP: 192.1.2.2 (?)
4-4
All
four
devices
agree
that
R2
(192.1.2.2)
is
the
RP
for
the
entire
multicast
range
of
224.0.0.0/4.
Now
that
this
has
been
configured
and
verified,
we
will
have
the
FastEthernet0/1
interface
of
R9
join
the
multicast
group
224.9.9.9.
R9#conf t
Enter configuration commands, one per line.
R9(config)#interface FastEthernet0/1
R9(config-if)#ip igmp join-group 224.9.9.9
R9(config-if)#end
Once
this
is
accomplished,
we
will
use
the
show
ip
mroute
to
follow
the
formation
of
the
tree
that
forms
between
R9
and
the
R2
(the
RP).
There
is
the
systematic
process:
R9
has
joined
the
group
224.9.9.9
as
evidenced
by
that
group
appearing
in
the
output
of
show
ip
igmp
groups.
R9#show ip igmp groups
IGMP Connected Group Membership
Group Address
Interface
Accounted
224.9.9.9
FastEthernet0/1
224.0.1.40
FastEthernet0/1
Uptime
Expires
Last Reporter
00:08:30
03:14:04
00:02:28
00:02:31
172.16.79.9
172.16.79.9
Group
R9
has
the
group
in
the
list
as
expected.
Now
R6
will
send
an
IGMP
join
to
R7,
this
join
packet
will
arrive
on
the
FastEthernet0/1
interface
of
that
router.
Illustrated
by
the
output
of
debug
ip
igmp:
R7#
IGMP(0):
IGMP(0):
sources
IGMP(0):
IGMP(0):
Having
received
this
message
R7
will
create
a
(*,
224.9.9.9)
entry
in
its
multicast
routing
table,
with
the
FastEthernet0/1
interface
in
the
OIL,
as
evidenced
by
a
show
ip
mroute:
R7#show ip mroute 224.9.9.9
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,
4-5
As
expected,
the
FastEthernet0/1
interface
is
in
the
OIL
and
the
incoming
interface
is
the
FastEthernet0/0.
This
interface
is
the
one
used
to
reach
the
RP.
Now
R7
will
send
PIM
version
2
Join/Prune
packets
to
its
neighbor
172.16.67.6.
Evidenced
by
the
results
of
debug
ip
pim
on
R7:
R7#debug ip pim
PIM debugging is on
R7#
PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 224.9.9.9
PIM(0): Insert (*,224.9.9.9) join in nbr 172.16.67.6's queue
PIM(0): Building Join/Prune packet for nbr 172.16.67.6
PIM(0): Adding v2 (192.1.2.2/32, 224.9.9.9), WC-bit, RPT-bit, S-bit Join
PIM(0): Send v2 join/prune to 172.16.67.6 (FastEthernet0/0)
R7#
This
join
packet
arrives
on
the
FastEthernet0/0
of
R6.
Seeing
this
packet
R6
will
create
a
*,G
entry
in
the
multicast
routing
table
for
the
group
224.9.9.9,
and
place
FastEthernet0/0
in
the
OIL.
As
evidenced
by
the
output
of
show
ip
mroute.
R6#show ip mroute 224.9.9.9
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.9.9.9), 00:36:23/00:02:30, RP 192.1.2.2, flags: S
Incoming interface: FastEthernet0/1, RPF nbr 172.16.26.2
4-6
R6
has
FastEthernet0/0
in
the
OIL
and
FastEthernet0/1
in
the
incoming
as
expected.
Now
R6
will
actively
begin
to
send
PIM
join/prune
messages
to
R2.
These
messages
will
arrive
on
the
GigabitEthernet0/1
interface
of
R2.
Seeing
this
R2
will
create
the
same
*,G
entry
for
the
group
224.9.9.9
with
GigabitEthernet0/1
in
the
OIL.
Again,
evidenced
by
show
ip
mroute:
R2#show ip mroute 224.9.9.9
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.9.9.9), 00:40:31/00:03:15, RP 192.1.2.2, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/1, Forward/Sparse, 00:40:31/00:03:15
We
have
just
observed
the
creation
of
the
Rendezvous
Point
Tree
(RPT),
sometimes
referred
to
as
the
shared
tree.
In
a
working
deployment
of
PIM-SM
there
will
always
be
a
series
of
(*,G)
entries
in
the
multicast
routing
tables
of
the
RP
and
the
hosts,
and
in
the
tables
of
the
devices
between
them.
This
condition
is
unique
to
PIM-SM
and
does
not
occur
in
PIM-DM.
PIM-SM
reliance
on
both
a
shared
and
source
base
tree
make
it
more
flexible
and
scalable
than
PIM-DM.
This
begs
the
question,
"How
is
the
source
base
tree
built?"
That
takes
us
to
the
next
role
based
device
in
the
PIM-SM
model.
PIM
Designated
Router
(PIM-DR)
In
PIM,
there
is
an
election
process
between
two
or
more
devices
when
they
become
PIM
neighbors.
This
election
process
determines
which
device
on
the
segment
is
responsible
for
sending
multicast
PIM
Register
Messages
to
the
RP.
When
the
PIM-DR
connected
to
a
sender
sees
multicast
traffic,
it
will
send
a
unicast
PIM
register
message
to
the
RP.
However,
before
this
process
can
work
the
devices
in
the
source
based
tree
(SPT)
will
need
to
know
the
identity
of
the
RP.
We
will
statically
assign
R2
to
be
the
RP
in
this
network.
Beginning
with
R1
and
working
our
up
to
R2.
R1(config)#ip pim rp-address 192.1.2.2
R5(config)#ip pim rp-address 192.1.2.2
R4(config)#ip pim rp-address 192.1.2.2
4-7
All
the
interfaces
between
each
of
these
devices
are
running
ip
pim
sparse-mode,
and
we
have
statically
assigned
the
RP
on
each
device.
The
output
of
show
ip
pim
rp
mapping
will
demonstrate
that
these
four
devices
agree
on
the
identity
of
the
RP.
R1#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s): 224.0.0.0/4, Static
RP: 192.1.2.2 (?)
R5#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s): 224.0.0.0/4, Static
RP: 192.1.2.2 (?)
R4#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s): 224.0.0.0/4, Static
RP: 192.1.2.2 (?)
R2#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s): 224.0.0.0/4, Static
RP: 192.1.2.2 (?)
Now
PIM-SM
messages
can
be
sent
because
the
identity
of
the
RP
has
been
established.
Now
if
a
source
where
to
appear
the
PIM-DR
can
sent
the
PIM
register
message.
If
the
RP
accepts
the
PIM
register
message
it
will
send
an
acknowledgement
to
the
PIM-DR
known
as
a
Register
Stop.
The
Register
Stop
informs
the
PIM-DR
that
the
RP
has
received
the
PIM
register
message,
created
an
(S,G)
entry
for
the
group
identified
in
the
message,
and
tells
the
PIM-DR
to
stop
sending
register
messages.
To
illustrate
this
process
R1
will
send
multicast
traffic
to
the
group
224.1.1.1.
R1#ping 224.1.1.1 repeat 100000000
Type escape sequence to abort.
Sending 100000000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
.............................. <output omitted>
4-8
It
should
come
as
no
surprise
that
the
ping
fails.
No
hosts
have
joined
this
particular
group.
We
will
observe
the
exchange
of
information
between
the
PIM-DR
and
the
RP.
First,
the
PIM-DR
sends
the
PIM
register
message
to
the
RP
via
unicast:
R5#debug ip pim
PIM debugging is on
R5#
PIM(0): Send v2 Data-header Register to 192.1.2.2 for 172.16.15.1, group 224.1.1.1
We
see
that
R5
sends
the
Register
message
to
192.1.2.2
for
the
group
224.1.1.1.
This
is
a
unicast
packet.
R2
will
then
receive
this
message
and
send
a
register
stop
as
evidence
by
the
output
of
debug
ip
pim:
R2#debug ip pim
PIM debugging is on
R2#
PIM(0): Received v2 Register on FastEthernet0/0 from 172.16.45.5
(Data-header) for 172.16.15.1, group 224.1.1.1
PIM(0): Send v2 Register-Stop to 172.16.45.5 for 172.16.15.1, group 224.1.1.1
The
output
demonstrates
that
R2
receives
the
Register
message
for
the
group
224.1.1.1
and
responds
by
sending
the
Register-Stop
for
the
group
224.1.1.1.
Observe
that
this
process
is
taking
place
via
unicast.
Before
we
look
to
see
if
the
Register-Stop
made
it
to
R5
we
will
want
to
see
if
the
(S,G)
entry
for
the
multicast
group
224.1.1.1
was
created
in
R2's
multicast
routing
table.
Use
show
ip
mroute
to
accomplish
this:
R2#show ip mroute 224.1.1.1
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.1.1.1), 00:12:27/stopped, RP 192.1.2.2, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
(172.16.15.1, 224.1.1.1), 00:12:27/00:02:32, flags: P
Incoming interface: GigabitEthernet0/0, RPF nbr 172.16.24.4
4-9
The
S,G
pair
is
clearly
installed.
Note
that
there
are
no
interfaces
in
the
OIL
at
this
time.
Now
back
to
R5
to
check
for
the
Register-Stop:
R5#debug ip pim
PIM debugging is on
R5#
PIM(0): Received v2 Register-Stop on FastEthernet0/1 from 192.1.2.2
PIM(0):
for source 172.16.15.1, group 224.1.1.1
PIM(0): Clear Registering flag to 192.1.2.2 for (172.16.15.1/32, 224.1.1.1)
The
Register-Stop
was
received
for
the
group
224.1.1.1
from
the
RP
(192.1.2.2),
and
the
register
flag
for
the
S,G
pair
(172.16.15,1,
224.1.1.1)
was
cleared.
There
will
be
an
entry
for
this
S,G
pair
in
the
multicast
routing
table
of
R5:
R5#show ip mroute 224.1.1.1
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.1.1.1), 00:19:36/stopped, RP 192.1.2.2, flags: SPF
Incoming interface: FastEthernet0/1, RPF nbr 172.16.45.4
Outgoing interface list: Null
(172.16.15.1, 224.1.1.1), 00:19:36/00:02:56, flags: PFT
Incoming interface: FastEthernet0/0, RPF nbr 172.16.15.1
Outgoing interface list: Null
We
see
the
S,G
entry.
As
part
of
our
critical
analysis,
we
need
to
look
at
the
flags.
"P"
indicates
that
group
has
been
pruned
(there
are
no
interested
hosts).
"F"
indicates
the
register
flag
(which
we
saw
being
cleared).
"T"
indicates
that
the
SPT-bit
is
set
(we
will
look
at
this
later
in
this
chapter).
When
we
looked
at
the
formation
of
the
shared
or
RP
tree
we
observed
that
there
where
(*,G)
entries
on
each
device
from
R9
to
R2.
The
shared
tree
was
created
purely
via
multicast
messages
on
a
hop-by-hop
basis.
Thus
far,
the
source
or
SPT
has
been
build
using
unicast
messages.
This
means
that
the
an
entry
for
the
multicast
S,G
pair
for
224.1.1.1
will
only
exist
on
R5
and
R2
as
evidenced
by
show
ip
mroute:
4-10
R5#show ip mroute 224.1.1.1
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.1.1.1), 00:26:42/stopped, RP 192.1.2.2, flags: SPF
Incoming interface: FastEthernet0/1, RPF nbr 172.16.45.4
Outgoing interface list: Null
(172.16.15.1, 224.1.1.1), 00:26:42/00:02:50, flags: PFT
Incoming interface: FastEthernet0/0, RPF nbr 172.16.15.1
Outgoing interface list: Null
R4#show ip mroute 224.1.1.1
Group 224.1.1.1 not found
R2#show ip mroute 224.1.1.1
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.1.1.1), 00:27:29/stopped, RP 192.1.2.2, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
(172.16.15.1, 224.1.1.1), 00:27:29/00:01:30, flags: P
Incoming interface: GigabitEthernet0/0, RPF nbr 172.16.24.4
Outgoing interface list: Null
This
behavior
will
change
once
a
receiver
appears
for
the
group
224.1.1.1.
4-11
Wait
for
the
multicast
routing
table
entry
for
224.1.1.1
to
expire
on
R2:
R2#show ip mroute 224.1.1.1
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.1.1.1), 00:44:19/stopped, RP 192.1.2.2, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
(172.16.15.1, 224.1.1.1), 00:44:19/00:00:39, flags: P
Incoming interface: GigabitEthernet0/0, RPF nbr 172.16.24.4
Outgoing interface list: Null
4-12
Note:
This
process
could
easily
be
facilitated
with
the
clear
ip
mroute
*
command,
but
we
wanted
to
take
the
time
to
make
the
point
that
the
expiration
timers
in
multicast
are
long.
This
fact
can
create
anomalous
behavior,
compound
troubleshooting,
or
delay
multicast
security
measures.
Now
that
the
224.1.1.1
pair
is
gone
we
only
have
the
224.9.9.9
(*,G)
entry
remaining
on
R2:
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.9.9.9), 03:55:26/00:03:27, RP 192.1.2.2, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
4-13
Enable
debug
ip
pim
on
R2:
R2#debug ip pim
PIM debugging is on
R2#
On
R1,
generate
the
multicast
pings
for
the
group
224.9.9.9
with
a
repeat
count
of
1.
R1#ping 224.9.9.9 repeat 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 224.9.9.9, timeout is 2 seconds:
Reply to request 0 from 172.16.79.9, 32 ms
Observe
that
R9
replied
to
the
ping.
We
need
to
look
at
the
debug
output
on
R2
to
see
what
has
happened
at
the
RP
thus
far.
PIM(0): Received v2 Register on GigabitEthernet0/0 from 172.16.45.5
for 172.16.15.1, group 224.9.9.9
PIM(0): Send v2 Register-Stop to 172.16.45.5 for 172.16.15.1, group 224.9.9.9
The
RP
sent
the
Register-Stop.
This
seems
strange
given
the
fact
that
we
have
a
host
that
wants
to
receive
this
multicast
group.
The
things
we
need
to
point
out
are
as
follows:
R2
will
now
have
the
(*,G)
and
(S,G)
entry
in
its
multicast
routing
table:
R2#show ip mroute 224.9.9.9
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
4-14
This
output
tells
us
that
the
RP
has
learned
the
identity
of
the
source,
so
now
once
a
PIM
join
message
for
this
source
arrives
on
the
RP
it
will
send
a
PIM
join
up
the
reverse
path
tree
toward
the
source.
As
evidenced
by
the
debug
ip
pim
output
on
R2:
R2#
PIM(0): Received v2 Join/Prune on GigabitEthernet0/1 from 172.16.26.6, to us
PIM(0): Join-list: (*, 224.9.9.9), RPT-bit set, WC-bit set, S-bit set
PIM(0): Update GigabitEthernet0/1/172.16.26.6 to (*, 224.9.9.9), Forward state, by PIM
*G Join
PIM(0): Update GigabitEthernet0/1/172.16.26.6 to (172.16.15.1, 224.9.9.9), Forward
state, by PIM *G Join
We
see
join
arrive
from
R6,
and
then
the
RP
builds
and
sends
its
own
join
to
R4
toward
the
source:
R2#
PIM(0): Building Join/Prune packet for nbr 172.16.24.4
PIM(0): Adding v2 (172.16.15.1/32, 224.9.9.9), S-bit Join
PIM(0): Send v2 join/prune to 172.16.24.4 (GigabitEthernet0/0)
This
PIM
join
creates
a
(*,G)
entry
in
all
the
devices
between
the
RP
and
the
source.
R4#show ip mroute 224.9.9.9
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
4-15
Right
now
we
are
only
interested
in
the
(*,G)
entry
in
the
multicast
routing
table.
Notice
that
the
RPF
address
on
R4
is
the
ip
address
used
to
reach
the
RP
(172.16.24.2).
R5#show ip mroute 224.9.9.9
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.9.9.9), 00:01:51/stopped, RP 192.1.2.2, flags: SPF
Incoming interface: FastEthernet0/1, RPF nbr 172.16.45.4
Outgoing interface list: Null
(172.16.15.1, 224.9.9.9), 00:01:51/00:01:40, flags: FT
Incoming interface: FastEthernet0/0, RPF nbr 172.16.15.1, Registering
Outgoing interface list:
FastEthernet0/1, Forward/Sparse, 00:01:51/00:02:38
R5
has
the
(*,G)
entry
in
the
multicast
routing
table.
This
entry
was
created
as
a
result
of
a
PIM
join
arriving
on
the
FastEthernet0/1
interface,
and
the
RPF
neighbor
is
172.16.45.4.
Also
note
that
we
have
(S,G)
entries
on
these
routers
as
well.
The
appearance
of
both
the
(*,G)
and
(S,G)
values
in
the
table
tells
us
that
the
router
has
passed
some
packets.
Following
the
pattern
that
we
see
in
the
show
command
output
above,
we
see
that
initially
the
multicast
tree
is
built
end-to-end
through
the
RP.
4-16
We
see
that
the
(S,G)
entry
is
inserted
into
R2's
multicast
routing
table.
The
RP
builds
a
Join
packet
for
R4.
This
join
is
forward
via
the
link-local
multicast
address
224.0.0.13,
and
once
it
arrives
on
R5
the
PIM-
DR,
the
PIM
register
message
will
be
sent
back
toward
the
RP.
Observe
that
this
time
R2
does
not
send
a
Register
Stop.
Instead,
R2
begins
to
forward
multicast
packets.
Once
the
first
packet
arrives
at
R7,
the
source
ip
address
is
learned
and
R7
will
send
a
PIM
Prune
message
to
the
RP
once
it
determines
that
there
is
a
shorter
path
toward
the
source.
This
prune
message
is
propagated
in
a
hop-by-hop
manner
using
the
link-local
multicast
address
224.0.0.13.
Once
this
messages
arrives
at
the
RP
it
will
stop
forwarding
multicast
packets,
create
its
own
prune
message
and
sent
that
to
its
next
hop
neighbor
toward
the
source.
4-17
PIM(0):
PIM(0):
PIM(0):
PIM(0):
PIM(0):
PIM(0):
PIM(0):
R2#
In
the
output
provided
we
see
the
"S-bit
Prune"
value
for
the
(S,G)
pair.
This
indicates
that
the
status
of
the
pair
(172.16.15.1,
224.9.9.9)
will
transition
to
pruned:
R2#show ip mroute 224.9.9.9
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.9.9.9), 00:21:02/00:03:07, RP 192.1.2.2, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet0/1, Forward/Sparse, 00:21:02/00:03:07
(172.16.15.1, 224.9.9.9), 00:00:53/00:02:43, flags: PT
Incoming interface: GigabitEthernet0/0, RPF nbr 172.16.24.4
Outgoing interface list: Null
Observe
that
the
status
for
the
pair
is
pruned;
as
indicated
by
the
P
flag.
Note
also
that
there
are
no
interfaces
in
the
OIL
(Null).
R2
is
no
longer
participating
in
the
multicast
data
plane.
As
a
final
verification,
we
can
see
that
R6
is
receiving
the
multicast
traffic
directly
from
R4
via
the
S0/1/0.1
interface.
R6#show ip mroute 224.9.9.9
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,
4-18
The
incoming
interface
list
for
the
(S,G)
pair
has
Serial0/1/0.1
as
expected.
Though
this
process
of
switching
from
the
RPT
to
the
SPT
is
default
behavior,
it
is
possible
to
change
this
behavior
with
the
ip
pim
spt-threshold
infinity
command
on
the
IGMP
router.
R7#conf t
Enter configuration commands, one per line.
R7(config)#ip pim spt-threshold infinity
R7(config)#end
Once
this
command
has
been
applied
to
the
IGMP
router,
the
multicast
tree
will
always
be
formed
end-
to-end
through
the
RP.
We
will
demonstrate
this
by
issuing
pings
from
R1
for
the
group
224.9.9.9,
and
observing
the
output
of
the
debug
ip
pim
on
R2:
R2#
PIM(0): Received v2 Register on GigabitEthernet0/0 from 172.16.45.5
PIM(0): Send v2 Register-Stop to 172.16.45.5 for 0.0.0.0, group 0.0.0.0
PIM(0): Received v2 Register on GigabitEthernet0/0 from 172.16.45.5
for 172.16.15.1, group 224.9.9.9
PIM(0): Forward decapsulated data packet for 224.9.9.9 on GigabitEthernet0/1
PIM(0): Insert (172.16.15.1,224.9.9.9) join in nbr 172.16.24.4's queue
PIM(0): Building Join/Prune packet for nbr 172.16.24.4
PIM(0): Adding v2 (172.16.15.1/32, 224.9.9.9), S-bit Join
PIM(0): Send v2 join/prune to 172.16.24.4 (GigabitEthernet0/0)
R2#
In
this
instance,
R2
receives
and
forwards
the
"S-Bit
Join"
to
its
next
hop
neighbor
toward
the
source.
But,
R2
never
receives
a
PIM
Prune
from
the
IGMP
router,
thus
the
multicast
tree
remains
rooted
to
the
4-19
RP.
This
can
also
be
verified
via
show
ip
mroute
on
R6.
This
output
will
show
that
the
incoming
interface
on
R6
will
be
the
FastEthernet0/1
interface:
R6#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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.9.9.9), 00:06:44/00:03:20, RP 192.1.2.2, flags: S
Incoming interface: FastEthernet0/1, RPF nbr 172.16.26.2
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:06:44/00:02:39
(*, 224.0.1.40), 00:06:44/00:02:40, RP 192.1.2.2, flags: SJCL
Incoming interface: FastEthernet0/1, RPF nbr 172.16.26.2
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:06:44/00:02:40
This
output
demonstrates
two
things.
First,
the
incoming
interface
for
the
group
224.9.9.9
is
FastEthernet0/1
as
we
expected.
Second,
we
have
no
(S,G)
entries
in
the
multicast
routing
table
of
R6.
There
will
be
no
(S,G)
entries
on
R6,
R7
or
R9
because
all
of
these
routers
will
send
their
multicast
packets
to
the
RP,
rather
than
the
unicast
ip
address
of
the
source.
4-20
RP
is
not
learning
the
(*,G)
entries
for
some
or
all
multicast
groups.
RP
fails
to
notify
the
PIM-DR
to
begin
forwarding
multicast
packets.
We
will
perform
a
walk
through
for
each
of
these
RPF
issues
in
the
PIM-SM
Sample
Troubleshooting
Scenarios
section
that
follows.
Unicast
Routing
and
Forwarding
Problems
From
earlier
portions
of
this
chapter,
it
is
clear
that
the
ability
of
the
PIM-DR
to
register
an
active
source
with
the
RP
is
dependent
on
its
ability
to
unicast
to
the
RP.
Of
course,
since
this
reachability
is
unicast,
it
is
not
subject
to
RPF
checks.
As
a
result,
common
issues
are:
This
is
a
situation
where
it
will
be
necessary
to
look
at
the
underlying
routing
protocols
used
in
the
network.
Typically,
this
would
be
an
issue
of
asynchronous
routing,
and
should
be
something
obvious
once
the
routing
tables
of
the
source
and
transit
devices
are
analyzed.
4-21
In
the
PIM-SM
Sample
Troubleshooting
Scenarios
section
that
follows,
troubleshooting
these
issues
are
demonstrated.
For
each
problem,
the
text
demonstrates
how
to
quickly
and
efficiently
verify
each
symptom,
isolate
the
cause,
and
remediate
the
issue.
4-22
In
the
Common
Issues
with
PIM-SM
section,
three
primary
types
of
problems
were
identified:
RPF
failures,
unicast
routing
failures,
and
multicast
forwarding
and
routing
failures.
This
section
explores
these
three
categories
of
failure,
by
directing
our
attention
to
the
commands
necessary
to
identify
that
a
problems
exists.
There
are
four
types
of
devices
in
this
topology:
RP,
Host/Receiver,
Source
and
transit
devices
(PIM
enabled
routers).
Step
One:
Do
all
devices
agree
on
the
identity
of
the
RP?
R1#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s): 224.0.0.0/4, Static
RP: 192.1.2.2 (?)
R5#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s): 224.0.0.0/4, Static
RP: 192.1.2.2 (?)
4-23
All
the
routers
in
the
multicast
domain
agree
that
R2
is
the
RP
for
the
entire
multicast
range
224.0.0.0/4,
additionally
we
can
see
that
this
determination
was
made
by
static
assignment.
It
is
essential
that
all
devices
in
the
topology
agree
on
the
identity
of
the
RP
on
a
group-by-group
basis.
If
not
there
is
no
way
possible
for
the
PIM-SM
control
plane
to
form
correctly.
Step
Two:
Does
the
shared
or
RPT
tree
form
from
the
IGMP
router
to
the
RP?
This
step
is
verified
by
having
the
host
join
the
multicast
group
of
interest.
R9(config)#interface FastEthernet0/1
R9(config-if)#ip igmp join-group 224.99.99.99
R9(config-if)#end
Now that R9 has joined the group 224.99.99.99 where does it send the IGMP Join message?
4-24
R9#show ip igmp interface FastEthernet0/1
FastEthernet0/1 is up, line protocol is up
Internet address is 172.16.79.9/24
IGMP is enabled on interface
Current IGMP host version is 2
Current IGMP router version is 2
IGMP query interval is 60 seconds
IGMP querier timeout is 120 seconds
IGMP max query response time is 10 seconds
Last member query count is 2
Last member query response interval is 1000 ms
Inbound IGMP access group is not set
IGMP activity: 3 joins, 1 leaves
Multicast routing is enabled on interface
Multicast TTL threshold is 0
Multicast designated router (DR) is 172.16.79.9 (this system)
IGMP querying router is 172.16.79.7
Multicast groups joined by this system (number of users):
224.0.1.40(1) 224.99.99.99(1)
R9#
The
identity
of
the
IGMP
querying
router
is
172.16.79.7,
R7.
This
router
will
have
a
record
of
the
IGMP
report
sent
by
R9:
R7#show ip igmp groups
IGMP Connected Group Membership
Group Address
Interface
Accounted
224.99.99.99
FastEthernet0/1
224.0.1.40
FastEthernet0/1
224.0.1.40
FastEthernet0/0
Uptime
Expires
Last Reporter
00:03:59
04:02:58
04:03:53
00:02:57
00:02:59
00:02:58
172.16.79.9
172.16.79.9
172.16.67.6
Group
In
this
output,
R7
has
recorded
the
IGMP
Report
sent
by
R9
for
the
multicast
group
224.99.99.99.
Now
R7
will
use
link-local
multicast
messages
to
form
the
PIM-SM
RPT.
Evidenced
by
the
output
of
show
ip
mroute
on
the
devices
leading
to
the
RP.
R7#show ip mroute 224.99.99.99
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,
Z - Multicast Tunnel, z - MDT-data group sender,
4-25
Based
on
the
output
we
see
that
R7
is
forwarding
the
PIM
Report
messages
to
R6
via
its
FastEthernet0/0,
the
interface
used
to
reach
the
RP.
If
these
messages
arrive
on
R6
there
will
be
a
(*,G)
entry
in
its
multicast
routing
table
for
the
group
and
FastEthernet0/1
should
be
in
the
incoming
interface
list.
This
can
be
verified
via
show
ip
mroute:
R6#show ip mroute 224.99.99.99
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.99.99.99), 00:00:41/00:02:48, RP 192.1.2.2, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:00:41/00:02:48
Observe
the
(*,G)
is
present
but
there
are
no
interfaces
in
the
incoming
interface
list:
Null.
Additionally,
the
RPF
neighbor
address
is
0.0.0.0.
Something
is
preventing
the
FastEthernet0/1
address
from
being
assigned
to
the
incoming
interface
list.
The
RPF
value
of
0.0.0.0
usually
indicates
that
the
RP
cannot
be
recognized,
and
commonly
occurs
because
of
an
RPF
error.
What
interface
is
the
RPF
interface
for
the
RP?
R6#show ip rpf 192.1.2.2
RPF information for ? (192.1.2.2) failed, no route exists
This
output
indicates
that
there
is
no
multicast
route
to
the
RP.
What
interface
would
R6
use
to
reach
192.1.2.2?
4-26
Interface
172.16.67.6
172.16.46.6
FastEthernet0/0
Serial0/1/0.1
Ver/
Mode
v2/S
v2/S
Nbr
Count
1
1
Query
Intvl
30
30
DR
Prior
1
1
DR
172.16.67.7
0.0.0.0
FastEthernet0/1
is
not
running
PIM-SM.
Corrected
this
by
applying
ip
pim
sparse-mode
under
the
interface.
R6#conf t
Enter configuration commands, one per line.
R6(config)#interface FastEthernet0/1
R6(config-if)#ip pim sparse-mode
R6(config-if)#end
Now
we
will
use
show
ip
mroute
to
determine
if
R6
can
now
resolve
the
identity
of
the
RP,
and
place
FastEthernet0/1
into
the
incoming
interface
list:
R6#show ip mroute 224.99.99.99
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.99.99.99), 00:26:03/00:03:04, RP 192.1.2.2, flags: S
Incoming interface: FastEthernet0/1, RPF nbr 172.16.26.2
4-27
As
part
of
the
final
verification
of
the
correct
creation
of
the
multicast
shared
tree,
we
will
use
show
ip
mroute
to
look
for
the
(*,G)
entry
for
the
group
224.99.99.99.
R2#show ip mroute 224.99.99.99
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.99.99.99), 00:09:00/00:02:52, RP 192.1.2.2, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet0/1, Forward/Sparse, 00:09:00/00:02:52
In
this
situation,
we
may
initially
think
that
there
is
an
issue
with
RPF
like
on
R6.
The
RPF
value
0.0.0.0
can
mean
one
of
two
things.
The
identity
of
the
RPF
cannot
be
recognized
or
the
router
is
the
RP.
In
this
instance,
R2
is
the
RP.
We
see
no
interface
in
the
incoming
interface
list
because
we
have
not
emulated
a
multicast
source.
Step
Three:
Does
the
PIM-DR
send
the
PIM
Register
message
to
the
RP?
This
process
is
accomplished
via
unicast,
and
as
such
is
not
subjected
to
the
RPF
check
mechanism.
The
initiation
of
a
multicast
source
on
R1
will
allow
us
to
confirm
whether
the
PIM
Register
message
is
sent.
R1#ping 224.99.99.99 r 5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 224.99.99.99, timeout is 2 seconds:
.....
The
ping
was
not
successful.
Was
a
(S,G)
record
created
on
R2
for
the
group
224.99.99.99?
R2#show ip mroute 224.99.99.99
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
4-28
R2
has
no
record
of
the
(S,G)
group.
Does
R5
send
the
PIM
Register
message?
R2#debug ip pim
PIM debugging is on
R2#
PIM(0): Send RP-reachability for 224.0.1.40 on GigabitEthernet0/0
PIM(0): Send RP-reachability for 224.0.1.40 on GigabitEthernet0/1
R2#
PIM(0): Received v2 Join/Prune on GigabitEthernet0/1 from 172.16.26.6, to us
PIM(0): Join-list: (*, 224.0.1.40), RPT-bit set, WC-bit set, S-bit set
PIM(0): Update GigabitEthernet0/1/172.16.26.6 to (*, 224.0.1.40), Forward state, by
PIM *G Join
R2#
R2
is
not
receiving
a
PIM
Register
from
R5.
Does
R5
have
a
(S,G)
entry
for
the
group
224.99.99.99?
R5#show ip mroute 224.99.99.99
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.99.99.99), 00:00:06/00:02:53, RP 192.1.2.2, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
4-29
Observe
that
again
we
have
an
RPF
neighbor
value
of
0.0.0.0.
R5
is
not
the
RP,
so
this
means
that
R5
cannot
recognize
the
RP.
The
next
most
logical
consideration
is,
"Is
there
an
RPF
error?"
R5#show ip rpf 192.1.2.2
RPF information for ? (192.1.2.2) failed, no route exists
Once
again,
we
see
that
there
is
no
route
to
the
RP.
Are
all
the
interfaces
running
PIM-SM?
R5#show ip pim interface
Address
Interface
172.16.15.5
172.16.45.5
FastEthernet0/0
FastEthernet0/1
Ver/
Mode
v2/S
v2/S
Nbr
Count
1
1
Query
Intvl
30
30
DR
Prior
1
1
DR
172.16.15.5
172.16.45.5
Observe
that
both
interfaces
are
running
PIM-SM.
What
is
the
next
step
in
this
part
of
the
PIM-SM
operational
mechanism?
R5
should
now
unicast
the
PIM
Register
message
to
the
RP.
Can
R5
reach
the
RP?
R5#ping 192.1.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.1.2.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R5
cannot
ping
the
ip
address
of
the
RP.
Is
this
prefix
in
the
unicast
routing
table?
R5#show ip route 192.1.2.2
Routing entry for 192.1.2.2/32
Known via "static", distance 1, metric 0 (connected)
Routing Descriptor Blocks:
* directly connected, via Null0
Route metric is 0, traffic share count is 1
Observe
that
the
prefix
is
being
routed
to
Null0
via
a
"static"
route.
This
can
be
corrected
by
removing
the
static
route
for
the
loopback
of
R2.
R5(config)#no ip route 192.1.2.2 255.255.255.255 Null0
Now
we
can
verify
that
that
the
ping
from
R1
is
successful
now:
R1#ping 224.99.99.99 repeat 10
Type escape sequence to abort.
4-30
to
to
to
to
to
to
to
to
to
to
request
request
request
request
request
request
request
request
request
request
0
1
2
3
4
5
6
7
8
9
from
from
from
from
from
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
32
28
28
28
28
28
28
28
44
28
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
We
see
that
the
ping
is
now
successful.
4-31
show
COMMAND:
show
ip
igmp
membership
[group-address
|
group-name]
[tracked]
[all]
This
command
displays
Internet
Group
Management
Protocol
(IGMP)
membership
information
for
multicast
groups
and
(S,
G)
channels.
Where:
EXAMPLE
OUTPUT:
R9#show ip igmp membership
Flags: A - aggregate, T - tracked
L - Local, S - static, V - virtual, R - Reported through v3
I - v3lite, U - Urd, M - SSM (S,G) channel
1,2,3 - The version of IGMP the group is in
Channel/Group-Flags:
/ - Filtering entry (Exclude mode (S,G), Include mode (*,G))
Reporter:
<mac-or-ip-address> - last reporter if group is not explicitly tracked
<n>/<m>
- <n> reporter in include mode, <m> reporter in exclude
4-32
Channel/Group
*,224.9.9.9
*,239.9.9.9
*,224.0.1.40
R9#
Reporter
172.16.79.9
172.16.79.9
172.16.79.9
Uptime
00:36:54
00:36:54
00:36:54
Exp.
02:06
02:09
02:05
Flags
2LA
2LA
2LA
Interface
Fa0/1
Fa0/1
Fa0/1
show
COMMAND:
show
ip
mroute
This
command
displays
the
contents
of
the
multicast
routing
(mroute)
table.
EXAMPLE
OUTPUT:
R6#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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.9.9.9), 00:01:36/stopped, RP 192.1.7.7, flags: SP
Incoming interface: FastEthernet0/0, RPF nbr 172.16.67.7
Outgoing interface list: Null
(172.16.15.1, 239.9.9.9), 00:01:36/00:03:01, flags: T
Incoming interface: FastEthernet0/1, RPF nbr 172.16.26.2
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:01:36/00:03:01
(*, 224.0.1.40), 00:38:26/00:02:35, RP 192.1.2.2, flags: SJCL
Incoming interface: FastEthernet0/1, RPF nbr 172.16.26.2
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:38:26/00:02:34
R6#
show
COMMAND:
show
ip
pim
interface
This
command
displays
information
about
interfaces
configured
for
Protocol
Independent
Multicast
(PIM).
4-33
EXAMPLE
OUTPUT:
R6#show ip pim interface
Address
Interface
172.16.67.6
172.16.46.6
172.16.26.6
R6#
FastEthernet0/0
Serial0/0/0.1
FastEthernet0/1
Ver/
Mode
v2/S
v2/S
v2/S
Nbr
Count
1
1
1
Query
Intvl
30
30
30
DR
Prior
1
1
1
DR
172.16.67.7
0.0.0.0
172.16.26.6
show
COMMAND:
show
ip
pim
rp
mapping
This
command
displays
information
about
Protocol
Independent
Multicast
(PIM)
RP
mappings.
EXAMPLE
OUTPUT:
R6#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 192.1.7.7 (?), v2
Info source: 192.1.2.2 (?), via
Uptime: 00:40:34, expires:
RP 192.1.5.5 (?), v2
Info source: 192.1.2.2 (?), via
Uptime: 00:40:36, expires:
Group(s): 224.0.0.0/4, Static
RP: 192.1.2.2 (?)
R6#
show
COMMAND:
show
ip
pim
[vrf
vrf-name]
neighbor
[interface-type
interface-number]
This
command
displays
information
about
Protocol
Independent
Multicast
(PIM)
neighbors
discovered
by
PIM
version
1
router
query
messages
or
PIM
version
2
hello
messages.
Where:
EXAMPLE
OUTPUT:
R6#show ip pim neighbor
PIM Neighbor Table
4-34
DR Priority,
Ver
v2
v2
v2
DR
Prio/Mode
1 / DR S
1 / S
1 / S
show
COMMAND:
show
ip
rpf
[vrf
vrf-name]
{route-distinguisher
|
source-address
[group-address]
[rd
route-
distinguisher]}
[metric]
This
command
displays
information
that
IP
multicast
routing
uses
to
perform
the
Reverse
Path
Forwarding
(RPF)
check
for
a
multicast
source
Where:
EXAMPLE
OUTPUT:
R6#show ip rpf 192.1.2.2
RPF information for ? (192.1.2.2)
RPF interface: FastEthernet0/1
RPF neighbor: ? (172.16.26.2)
RPF route/mask: 192.1.2.0/24
RPF type: unicast (eigrp 100)
RPF recursion count: 0
Doing distance-preferred lookups across tables
R6#
4-35
debug
COMMAND:
debug
ip
mpacket
[vrf
vrf-name]
[detail
|
fastswitch]
[access-list]
[group]
This
command
displays
multicast
packets
that
are
received
and
sent
on
the
device.
Where:
EXAMPLE
OUTPUT:
IP(0): s=172.16.26.6 (FastEthernet0/1) d=239.9.9.9 (FastEthernet0/0) id=1, ttl=254,
prot=1, len=100(100), mforward
debug
COMMAND:
debug
ip
pim
[vrf
vrf-name]
[bsr]
This
command
displays
Protocol
Independent
Multicast
(PIM)
packets
received
and
sent
and
displays
PIM-related
events
4-36
Where:
EXAMPLE
OUTPUT:
R6#
PIM(0): Received v2 Join/Prune on FastEthernet0/0 from 172.16.67.7, to us
PIM(0): Join-list: (*, 224.0.1.40), RPT-bit set, WC-bit set, S-bit set
PIM(0): Update FastEthernet0/0/172.16.67.7 to (*, 224.0.1.40), Forward state, by PIM
*G Join
PIM(0): Received v2 Join/Prune on FastEthernet0/0 from 172.16.67.7, to us
PIM(0): Join-list: (172.16.46.6/32, 239.9.9.9), S-bit set
PIM(0): Update FastEthernet0/0/172.16.67.7 to (172.16.46.6, 239.9.9.9), Forward state,
by PIM SG Join
R6#
PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 239.9.9.9
PIM(0): Send v2 Null Register to 192.1.7.7
PIM(0): Received v2 Register-Stop on FastEthernet0/0 from 192.1.7.7
PIM(0):
for source 0.0.0.0, group 0.0.0.0
R6#
PIM(0): Insert (172.16.15.1,239.9.9.9) join in nbr 172.16.26.2's queue
PIM(0): Building Join/Prune packet for nbr 172.16.26.2
PIM(0): Adding v2 (172.16.15.1/32, 239.9.9.9), S-bit Join
PIM(0): Send v2 join/prune to 172.16.26.2 (FastEthernet0/1)
R6#
PIM(0): Received v2 Bootstrap on FastEthernet0/1 from 172.16.26.2
PIM(0): Update (224.0.0.0/4, RP:192.1.7.7), PIMv2
PIM(0): Update (224.0.0.0/4, RP:192.1.5.5), PIMv2
PIM(0): Received v2 Bootstrap on Serial0/0/0.1 from 172.16.46.4
R6#
PIM(0): Received v2 Join/Prune on FastEthernet0/0 from 172.16.67.7, to us
PIM(0): Join-list: (172.16.15.1/32, 239.9.9.9), S-bit set
PIM(0): Update FastEthernet0/0/172.16.67.7 to (172.16.15.1, 239.9.9.9), Forward state,
by PIM SG Join
R6#
PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 224.0.1.40
PIM(0): Insert (*,224.0.1.40) join in nbr 172.16.26.2's queue
PIM(0): Building Join/Prune packet for nbr 172.16.26.2
PIM(0): Adding v2 (192.1.2.2/32, 224.0.1.40), WC-bit, RPT-bit, S-bit Join
PIM(0): Send v2 join/prune to 172.16.26.2 (FastEthernet0/1)
R6#
PIM(0): Received v2 Join/Prune on FastEthernet0/0 from 172.16.67.7, to us
PIM(0): Join-list: (*, 224.0.1.40), RPT-bit set, WC-bit set, S-bit set
PIM(0): Update FastEthernet0/0/172.16.67.7 to (*, 224.0.1.40), Forward state, by PIM
*G Join
R6#
4-37
Trouble
Ticket
#1
Your
supervisor
has
brought
to
your
attention
that
the
RP
in
this
topology
is
not
learning
about
the
multicast
group
224.9.9.9
that
R9
has
joined.
You
must
correct
the
issue.
Trouble
Ticket
#2
After
solving
Trouble
Ticket
#1,
your
supervisor
has
observed
that
the
RP
is
not
creating
the
S,G
entry
for
the
group
224.9.9.9
and
any
pings
sent
to
this
group
from
R1
fail.
Correct
this
issue.
Trouble
Ticket
#3
Your
supervisor
has
instructed
you
to
prevent
any
multicast
traffic
associated
with
the
group
224.9.9.9
from
traversing
the
point-to-point
frame-relay
circuit
between
R4
and
R6.
You
are
not
allowed
to
change
or
remove
any
pim
sparse-mode
commands
at
the
interface
level
to
accomplish
this.
4-38
Figure
4-6:
PIM-SM
Quick
Fire
Troubleshooting
Flowchart
Trouble
Ticket
#1
Solution
Your
supervisor
has
brought
to
your
attention
that
the
RP
in
this
topology
is
not
learning
about
the
multicast
group
224.9.9.9
that
R9
has
joined.
You
must
correct
the
issue.
Step
1
-
Fault
Verification:
R9
has
joined
the
multicast
group
224.9.9.9
does
the
RP
(R2)
have
a
(*,G)
entry
for
this
multicast
group?
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,
Z - Multicast Tunnel, z - MDT-data group sender,
4-39
There
is
no
(*,
224.9.9.9)
entry
in
the
multicast
routing
table.
This
verifies
that
the
problem
actually
exists.
Step
2
-
Fault
Isolation:
The
next
course
of
action
is
to
use
the
mtrace
utility
to
rule
out
the
possibility
of
an
RPF
issue
between
the
IGMP
R9
and
the
RP.
R9#mtrace 172.16.79.9 192.1.2.2
Type escape sequence to abort.
Mtrace from 172.16.79.9 to 192.1.2.2 via RPF
From source (?) to destination (?)
Querying full reverse path... * switching to hop-by-hop:
0 192.1.2.2
-1 172.16.26.2 PIM [172.16.79.0/24]
-2 172.16.26.6 None No route
We
see
that
there
is
no
multicast
route
on
R6
for
the
next
hop
toward
the
host.
This
output
indicates
that
there
is
a
Reverse
Path
Forwarding
error
in
the
path
from
R2
to
R9.
With
this
confirmed,
the
next
step
in
the
process
is
to
look
use
show
ip
rpf
on
R6.
R6#show ip rpf 172.16.79.9
RPF information for ? (172.16.79.9) failed, no route exists
R6#
There
is
no
RPF
interface
that
can
be
used
to
reach
R9.
Using
the
show
ip
pim
neighbors
we
need
to
verify
that
PIM-SM
is
running
on
the
interface
that
would
be
used
to
reach
R9.
The
quickest
method
to
verify
this
is
to
execute
the
show
ip
pim
interface
command
on
R6:
R6#show ip pim interface
4-40
Address
Interface
172.16.26.6
172.16.46.6
FastEthernet0/1
Serial0/1/0.1
Ver/
Mode
v2/S
v2/S
Nbr
Count
1
1
Query
Intvl
30
30
DR
Prior
1
1
DR
172.16.26.6
0.0.0.0
The
ip
pim
sparse-mode
is
not
configured
on
the
FastEthernet0/0
interface.
This
has
unquestionably
isolated
our
fault.
Step
3
-
Fault
Remediation:
In
this
scenario,
the
ip
pim
sparse-mode
command
needs
to
be
added
to
FastEthernet0/0.
R6(config)#interface FastEthernet0/0
R6(config-if)#ip pim sparse-mode
Step
4
-
Verification
of
Remediation
Once
the
error
has
been
isolated
and
remediated
it
is
highly
recommended
to
verify
that
the
Trouble
Ticket
has
been
repaired
using
the
same
method
of
the
initial
fault
verification.
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.9.9.9), 00:00:22/00:03:07, RP 192.1.2.2, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet0/1, Forward/Sparse, 00:00:22/00:03:07
(*, 224.0.1.40), 00:21:40/00:03:18, RP 192.1.2.2, flags: SJCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet0/1, Forward/Sparse, 00:20:51/00:03:18
GigabitEthernet0/0, Forward/Sparse, 00:21:36/00:02:36
Loopback0, Forward/Sparse, 00:21:41/00:02:43
The
(*,
224.9.9.9)
entry
now
appears
in
the
multicast
routing
table
of
the
RP.
4-41
Does
the
(S,G)
entry
for
the
multicast
group
224.9.9.9
appear
in
the
multicast
routing
table
of
the
RP?
R2#show ip mroute 224.9.9.9
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.9.9.9), 00:09:20/00:03:00, RP 192.1.2.2, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet0/1, Forward/Sparse, 00:09:20/00:03:00
We
see
that
the
fault
does
exist.
Step
2
-
Fault
Isolation:
In
order
to
verify
that
RPF
issues
are
not
at
fault,
use
the
mtrace
utility
from
R2
toward
the
multicast
source.
We
will
perform
this
test
in
both
directions.
R2#mtrace 192.1.2.2 172.16.15.1
Type escape sequence to abort.
Mtrace from 192.1.2.2 to 172.16.15.1 via RPF
From source (?) to destination (?)
Querying full reverse path...
4-42
0
-1
-2
-3
-4
-5
172.16.15.1
172.16.15.1
172.16.15.5
172.16.45.4
172.16.24.2
192.1.2.2
PIM
PIM
PIM
PIM
[192.1.2.0/24]
[192.1.2.0/24]
[192.1.2.0/24]
[192.1.2.0/24]
Next
we
will
reverse
the
direction
of
the
check:
R2#mtrace 172.16.15.1 192.1.2.2
Type escape sequence to abort.
Mtrace from 172.16.15.1 to 192.1.2.2 via RPF
From source (?) to destination (?)
Querying full reverse path...
0 192.1.2.2
-1 192.1.2.2 PIM [172.16.15.0/24]
-2 172.16.24.4 PIM [172.16.15.0/24]
-3 172.16.45.5 PIM [172.16.15.0/24]
-4 172.16.15.1
There
are
no
RPF
issues
between
R1
and
R2.
However
during
this
test
the
following
console
messages
appeared:
%PIM-4-INVALID_SRC_REG: Received Register from 172.16.45.5 for (172.16.15.1,
224.9.9.9), not willing to be RP
R2
is
refusing
to
be
the
RP
when
it
receives
the
PIM
Register
message
from
172.16.45.5.
Two
issues
can
cause
a
device
to
refuse
to
become
the
RP.
A
missing
PIM-SM
configuration
on
the
loopback
used
as
the
IP
by
the
RP,
or
an
incorrectly
applied
accept-register
command.
First,
will
verify
that
the
interface
with
the
ip
address
192.1.2.2
is
operating
in
PIM-SM.
R2#show run interface loopback 0
Building configuration...
Current configuration : 83 bytes
!
interface Loopback0
ip address 192.1.2.2 255.255.255.0
ip pim sparse-mode
end
We
see
that
Loopback0
is
running
PIM-SM.
Therefore,
this
lead
to
a
filtering
or
security
issue
associated
with
PIM-SM.
To
see
all
the
configuration
entries
dealing
with
pim
or
interfaces
use
the
following
show
run
command
and
filter:
4-43
R2#show run | inc interface | pim
interface Loopback0
ip pim sparse-mode
interface GigabitEthernet0/0
ip pim sparse-mode
interface GigabitEthernet0/1
ip pim sparse-mode
interface Serial0/1/0
interface Serial0/2/0
ip pim rp-address 192.1.2.2
ip pim accept-register list 100
Note
that
the
last
line
of
this
output
shows
that
a
pim
accept-register
command
has
been
applied
to
the
RP.
The
access-list
being
called
by
this
configuration
is
extended
access-list
100.
What
does
this
access-
list
permit
or
deny?
R2#show ip access-list 100
Extended IP access list 100
10 deny ip any any (12 matches)
The
access-list
denies
all
ip
traffic.
This
explains
why
the
R2
(the
RP)
is
refusing
to
accept
the
Register
Messages
being
sent
by
R5:
Step
3
-
Fault
Remediation:
In
this
scenario,
access-list
100
needs
to
be
configured
to
allow
pim
register
messages
from
R5:
R2#conf t
R2(config)#ip access-list extended 100
R2(config-ext-nacl)#5 permit ip host 172.16.15.1 any
R2(config-ext-nacl)#end
Step
4
-
Verification
of
Remediation
Once
the
error
has
been
isolated
and
remediated,
it
is
highly
recommended
to
verify
that
the
Trouble
Ticket
has
been
repaired
using
the
same
method
used
to
verify
the
fault
initially:
R1#ping 224.9.9.9 r 1000
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 224.9.9.9, timeout is 2 seconds:
Reply to request 0 from 172.16.79.9, 28 ms
Reply to request 1 from 172.16.79.9, 28 ms
Reply to request 2 from 172.16.79.9, 28 ms
4-44
The
pings
are
successful.
So
the
RP
is
now
accepting
the
Register
Messages.
We
know
the
pings
work
but
it
would
still
be
worthwhile
to
verify
that
the
RP
has
created
the
(S,G)
entry
for
224.9.9.9
now:
R2#show ip mroute 224.9.9.9
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.9.9.9), 00:35:58/00:02:59, RP 192.1.2.2, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet0/1, Forward/Sparse, 00:35:58/00:02:59
(172.16.15.1, 224.9.9.9), 00:03:06/00:03:21, flags: T
Incoming interface: GigabitEthernet0/0, RPF nbr 172.16.24.4
Outgoing interface list:
GigabitEthernet0/1, Forward/Sparse, 00:03:06/00:02:59
The
entry
has
been
created.
Thus
demonstrating
that
the
fault
has
been
corrected.
Trouble
Ticket
#3
Solution
Your
supervisor
has
instructed
you
to
prevent
any
multicast
traffic
associated
with
the
group
224.9.9.9
from
traversing
the
point-to-point
frame-relay
circuit
between
R4
and
R6.
You
are
not
allowed
to
change
or
remove
any
pim
sparse-mode
commands
at
the
interface
level
to
accomplish
this.
Step
1
-
Fault
Verification:
Generate
multicast
traffic
destined
to
the
group
224.9.9.9
on
R1
and
verify
if
it
is
transiting
the
point-to-
point
frame
relay
link
between
R4
and
R6.
R1#ping 224.9.9.9 r 1000
Type escape sequence to abort.
4-45
0
1
2
3
4
5
from
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
28
28
28
28
28
28
ms
ms
ms
ms
ms
ms
Is
the
traffic
traversing
the
frame
circuit?
This
can
be
determined
using
show
ip
mroute
on
R6:
R6#show ip mroute 224.9.9.9
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.9.9.9), 00:43:57/00:03:17, RP 192.1.2.2, flags: S
Incoming interface: FastEthernet0/1, RPF nbr 172.16.26.2
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:43:57/00:03:17
(172.16.15.1, 224.9.9.9), 00:01:31/00:03:27, flags: T
Incoming interface: Serial0/1/0.1, RPF nbr 172.16.46.4
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:01:31/00:03:17
R6
is
receiving
this
multicast
feed
via
its
Serial0/1/0.1
interface.
This
demonstrates
that
the
fault
does
indeed
exist.
Step
2
-
Fault
Isolation:
What
is
the
shortest
path
from
R9
to
R1's
FastEthernet0/0
interface?
R9#traceroute 172.16.15.1
Type escape sequence to abort.
Tracing the route to 172.16.15.1
4-46
1
2
3
4
5
172.16.79.7
172.16.67.6
172.16.46.4
172.16.45.5
172.16.15.1
This
output
tells
us
that
the
shortest
path
to
R1
from
R9
will
be
through
the
172.16.46.0/24
network.
This
is
the
point-to-point
interface.
Knowing
that
the
default
behavior
of
PIM-SM
is
to
revert
to
the
Source
based
tree,
we
know
that
is
normal
behavior.
Behavior
that
can
be
stopped
using
the
ip
pim
spt-
threshold
command.
Step
3
-
Fault
Remediation:
In
this
scenario,
the
ip
pim
spt-threshold
command
needs
to
be
configured
on
R7.
R7(config)#ip pim spt-threshold infinity group-list 1
R7(config)#access-list 1 permit 224.9.9.9 0.0.0.0
R7(config)#end
Note:
After
making
this
configuration
we
should
clear
ip
mroute
*
on
all
devices
Step
4
-
Verification
of
Remediation
Once
the
error
has
been
isolated
and
remediated,
it
is
highly
recommended
to
verify
that
the
Trouble
Ticket
has
been
repaired
using
the
same
method
used
to
verify
the
fault
initially.
R1#ping 224.9.9.9 r 1000
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 224.9.9.9, timeout is 2 seconds:
Reply to request
Reply to request
Reply to request
Reply to request
Reply to request
<output omitted>
0
1
2
3
4
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
32
28
28
28
28
ms
ms
ms
ms
ms
Is
the
incoming
interface
for
the
group
224.9.9.9
on
R6
still
the
frame
relay
link?
R6#show ip mroute 224.9.9.9
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,
4-47
The incoming interface is now FastEthernet0/1 toward R2 as expected. This fault has been corrected.
4-48
Chapter
5:
Protocol
Independent
Multicast
Sparse-
Dense
Mode
(PIM-S-
DM)
This
chapter
of
IPv4/6
Multicast
Operation
and
Troubleshooting
details
the
processes
and
functionality
of
the
PIM
sparse-dense
mode
(PIM-S-DM)
protocol.
Following
the
coverage
of
the
operational
characteristics
of
the
protocol,
the
focus
becomes
that
of
troubleshooting.
This
includes
the
careful
examination
of
symptoms,
a
fault
isolation
methodology,
and
the
implementation
of
repairs
for
the
PIM
sparse-dense
mode
(PIM-S-DM)
protocol.
The
chapter
begins
with
a
thorough
review
of
PIM-S-DM,
and
then
quickly
launches
in
to
an
exhaustive
analysis
of
the
art
of
troubleshooting
this
multicast
routing
protocol.
This
important
chapter
concludes
with
sample
troubleshooting
scenarios,
reference
materials
for
the
most
important
show
and
debug
commands,
and
exciting
challenges
that
allow
readers
to
practice
implementing
the
troubleshooting
skills
they
have
obtained.
5-1
When
an
interface
operates
in
sparse
mode,
it
will
be
populated
into
the
outgoing
interface
list
of
a
multicast
routing
table
entry
when
either
of
the
following
conditions
are
true:
5-2
Reporter
172.16.79.9
Uptime
Exp. Flags
01:30:33 02:51 2LA
Interface
Fa0/1
5-3
*,239.9.9.9
*,224.0.1.40
172.16.79.9
172.16.79.9
Fa0/1
Fa0/1
By
using
the
ping
utility
on
R1
we
can
verify
that
R9
will
receive
both
of
these
multicast
groups.
R1#ping 224.9.9.9 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 224.9.9.9, timeout is 2 seconds:
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
to
to
to
to
to
to
to
to
to
to
request
request
request
request
request
request
request
request
request
request
0
1
2
3
4
5
6
7
8
9
from
from
from
from
from
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
1
1
1
1
1
1
1
1
1
1
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
to
to
to
to
to
to
to
to
to
to
request
request
request
request
request
request
request
request
request
request
0
1
2
3
4
5
6
7
8
9
from
from
from
from
from
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
8
1
1
1
1
1
1
1
1
1
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
This
output
on
R1
clearly
illustrates
the
multicast
pings
are
successful
but
have
they
been
routed
in
dense
or
sparse
mode?
The
show
ip
mroute
command
will
tell
us
how
traffic
has
been
routed
on
any
given
device:
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,
5-4
Observe
that
the
traffic
sent
to
224.9.9.9
was
flagged
as
"S"
(sparse)
whereas
the
traffic
to
the
group
239.9.9.9
was
flagged
as
"D"
(dense).
What
determines
whether
a
group
is
treated
as
either
sparse
or
dense
mode
traffic?
Simply
put,
if
a
device
knows
of
an
RP
for
a
given
multicast
address
or
scope
of
addresses
that
group
or
scope
is
treated
as
sparse
mode
traffic.
If
a
device
does
not
have
an
RP
mapping
for
a
given
group
or
scope
of
addresses
then
this
traffic
will
be
forwarded
in
dense
mode.
Observe
in
this
topology
that
the
first
half
of
the
multicast
range
has
been
assigned
to
the
RP
192.1.2.2.
This
can
be
discovered
using
show
ip
pim
rp
mapping:
R1#show ip pim rp mapping
PIM Group-to-RP Mappings
Acl: 1, Static
RP: 192.1.2.2 (?)
This
tells
us
that
an
access-list
was
used
to
assign
groups
to
an
RP
(192.1.2.2)
this
is
often
referred
to
as
a
group-to-RP
mapping.
What
multicast
groups
are
defined
in
the
access-list?
5-5
R1#show access-list 1
Standard IP access list 1
10 permit 224.0.0.0, wildcard bits 7.255.255.255 (978 matches)
As
we
can
see
this
means
that
any
multicast
address
between
224.0.0.0
and
231.255.255.255
will
have
an
RP
assigned,
and
therefore
be
forwarded
in
sparse-mode.
Verified
by
with
the
mtrace
utility:
R1#mtrace 172.16.15.1 172.16.79.9 224.1.1.1
Type escape sequence to abort.
Mtrace from 172.16.15.1 to 172.16.79.9 via group 224.1.1.1
From source (?) to destination (?)
Querying full reverse path... * switching to hop-by-hop:
0 172.16.79.9
-1 * 172.16.79.9 PIM [172.16.15.0/24]
-2 * 172.16.79.7 PIM [172.16.15.0/24]
-3 * 172.16.67.6 PIM [172.16.15.0/24]
-4 * 172.16.26.2 PIM Reached RP/Core [172.16.15.0/24]
-5 * 172.16.24.4 PIM [172.16.15.0/24]
-6 * 172.16.45.5 PIM Prune sent upstream [172.16.15.0/24]
-7 * 172.16.15.1 PIM [172.16.15.0/24]
Observe
that
the
-4
hop
arrives
at
R2.
R2
is
designated
as
the
RP
or
"Core"
router.
This
means
that
this
traffic
will
be
forwarded
in
sparse
mode.
As
evidenced
by
the
output
on
R2:
R2#show ip mroute 224.1.1.1
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.1.1.1), 00:05:11/stopped, RP 192.1.2.2, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
(172.16.15.1, 224.1.1.1), 00:00:11/00:02:48, flags: P
Incoming interface: GigabitEthernet0/0, RPF nbr 172.16.24.4
Outgoing interface list: Null
5-6
Observe
the
*,G
flag
is
"S"
for
sparse.
Now
we
will
look
at
the
last
group
in
the
range
that
will
have
an
RP
assigned.
R1#mtrace 172.16.15.1 172.16.79.9 231.255.255.255
Type escape sequence to abort.
Mtrace from 172.16.15.1 to 172.16.79.9 via group 231.255.255.255
From source (?) to destination (?)
Querying full reverse path... * switching to hop-by-hop:
0 172.16.79.9
-1 * 172.16.79.9 PIM [172.16.15.0/24]
-2 * 172.16.79.7 PIM [172.16.15.0/24]
-3 * 172.16.67.6 PIM [172.16.15.0/24]
-4 * 172.16.26.2 PIM Reached RP/Core [172.16.15.0/24]
-5 * 172.16.24.4 PIM [172.16.15.0/24]
-6 * 172.16.45.5 PIM Prune sent upstream [172.16.15.0/24]
-7 * 172.16.15.1 PIM [172.16.15.0/24]
Observe
that
the
-4
hop
arrives
at
R2.
R2
is
designated
as
the
RP
or
"Core"
router.
This
means
that
this
traffic
will
be
forwarded
in
sparse
mode.
As
evidenced
by
the
output
on
R2:
R2#show ip mroute 231.255.255.255
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 231.255.255.255), 00:00:35/stopped, RP 192.1.2.2, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
(172.16.15.1, 231.255.255.255), 00:00:35/00:02:24, flags: P
Incoming interface: GigabitEthernet0/0, RPF nbr 172.16.24.4
Outgoing interface list: Null
Observe
the
*,G
flag
is
"S"
for
sparse.
Now
we
will
look
at
the
first
group
in
the
range
that
will
not
have
an
RP
assigned.
R1#mtrace 172.16.15.1 172.16.79.9 232.0.0.1
Type escape sequence to abort.
Mtrace from 172.16.15.1 to 172.16.79.9 via group 232.0.0.1
5-7
Observe
that
the
-4
hop
arrives
at
R2.
R2
is
not
designated
as
the
RP
or
"Core"
router.
This
means
that
this
traffic
will
be
forwarded
in
dense
mode.
As
evidenced
by
the
output
on
R2:
R2#show ip mroute 232.0.0.1
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 232.0.0.1), 00:00:08/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet0/1, Forward/Sparse-Dense, 00:00:08/00:00:00
(172.16.15.1, 232.0.0.1), 00:00:08/00:02:55, flags: T
Incoming interface: FastEthernet0/0, RPF nbr 172.16.24.4
Outgoing interface list:
GigabitEthernet0/1, Forward/Sparse-Dense, 00:00:08/00:00:00
5-8
PIM-S-DM
seems
to
be
the
most
flexible
of
the
PIM
modes
we
have
discussed
thus
far.
However,
there
is
one
behavior
of
PIM-S-DM
that
makes
it
less
than
attractive
as
a
PIM
deployment
option.
Remember,
any
group
that
does
not
have
an
RP
defined
is
forwarded
in
dense
mode.
Take
the
situation
where
significant
amounts
of
multicast
traffic
is
forwarded
in
the
topology
toward
a
handful
of
interested
hosts.
Assume
now
that
the
RP
fails.
In
this
situation,
the
routers
will
begin
treating
all
traffic
as
dense
and
begin
flooding
the
network
with
the
multicast
traffic.
This
means
that
all
PIM
enabled
devices
will
receive
all
multicast
traffic.
Additionally,
the
prune
process
we
discussed
in
Chapter
3:
Protocol
Independent
Multicast
-
Dense
Mode
(PIM-DM)
will
add
further
to
the
network
congestion.
The
environment
we
are
currently
working
with
uses
static
RP
assignment.
This
fallback
to
PIM-DM
behavior
only
takes
place
when
the
RP
has
been
dynamically
defined
in
AutoRP
and
will
be
covered
in
depth
in
Chapter
8:
AutoRP.
It
is
odd
that
the
unwanted
behavior
of
PIM-S-DM
only
takes
place
while
using
the
very
protocol
it
was
meant
to
facilitate.
This
behavior
can
be
stopped
in
a
number
of
ways
to
include
the
"sink
RP"
mentioned
in
the
Technology
Review
section,
or
the
more
commonly
used
no
ip
pim
dm-
fallback
command
on
all
PIM-S-DM
enabled
routers.
5-9
Control
Plane
-
PIM-S-DM
control
plane
uses
PIM
messages
in
its
creation.
PIM
sends
messages
via
the
link-local
multicast
group
224.0.0.13,
and
are
therefore
subject
to
RPF
checks.
It
is
important
to
note
that
RPF
checks
in
the
control
plane
are
against
the
source
IP
address
encapsulated
into
each
PIM
packet
as
they
arrive.
More
often
than
not,
this
will
be
the
IP
address
of
the
adjacent
neighbor.
Data
Plane
-
PIM-S-DM
will
perform
RPF
checks
on
each
individual
multicast
packet
before
deciding
to
forward
it.
This
means
that
the
source
IP
address
of
each
multicast
packet
a
router
receives
must
be
reachable
out
the
receiving
interface
before
the
router
will
forward
it
to
an
adjacent
neighbor.
In
instances
when
traffic
is
forwarded
as
PIM-DM,
RPF
always
performs
checks
against
the
source
of
the
multicast
feed.
In
instances
where
the
traffic
is
treated
as
PIM-
SM
RPF
checks
will
first
be
done
toward
the
RP
and
then
toward
the
source
as
part
of
the
shortest
path
tree
failover
process.
The
RPF
check
mechanism
can
result
in
scenarios
where
the
control
plane
fails
to
form
correctly,
or
multicast
packets
fail
to
transit
the
multicast
tree.
When
only
a
few
packets
or
no
packets
reach
the
receivers
RPF
failures
will
normally
be
the
cause.
We
will
perform
a
walk
through
for
each
of
these
RPF
issues
in
the
PIM-S-DM
Sample
Troubleshooting
Scenarios
section
that
follows.
5-10
This
is
a
situation
where
it
will
be
necessary
to
look
at
the
underlying
routing
protocols
used
in
the
network.
Typically,
this
would
be
an
issue
of
asynchronous
routing,
and
should
be
something
obvious
once
the
routing
tables
of
the
source
and
transit
devices
are
analyzed.
Multicast
Routing
and
Forwarding
Problems
These
problems
manifest
themselves
in
more
subtle
ways
when
compared
to
the
previous
points.
As
discussed
earlier,
the
majority
of
PIM-S-DM's
operational
mechanisms
involve
the
formation
of
the
control
plane.
When
traffic
will
be
forwarded
as
sparse
the
RP
manages
the
multicast
domain
and
helps
maintain
the
multicast
routing
tables.
When
sparse
mode
forwarding
is
being
used,
situations
like
the
following
normally
exist
when
information
fails
to
propagate
to
any
or
all
devices,
but
RPF
checks
and
unicast
routing
seem
to
be
functioning
correctly:
In
instances
when
dense
mode
forwarding
is
being
used
it
is
important
to
keep
in
mind
that
every
multicast
packet
has
a
TTL
value,
just
like
their
unicast
IP
counterparts.
In
many
environments,
using
PIM-DM
this
fact
is
used
as
a
method
to
scope
or
contain
multicast
packets
to
the
internal
network.
Multicast-threshold,
is
effectively
employed
to
keep
multicast
packets
from
leaking
into
any
internetwork
space.
However,
it
is
possible
to
create
a
multicast
routing
fault
by
setting
the
multicast
threshold
on
a
given
router
interface.
If
the
packet's
TTL
is
higher
than
the
multicast
threshold
configured
on
an
interface
(and
it
pass
the
RPF
check),
the
packet
will
be
forwarded.
If
the
TTL
of
the
packet
is
lower
than
the
multicast
threshold,
the
router
drops
the
packet.
The
possible
range
for
a
multicast
threshold
value
is
0
to
255,
with
0
meaning
all
packets
will
be
forwarded
verses
255
where
virtually
no
packets
will
be
forwarded
5-11
In
the
PIM-S-DM
Sample
Troubleshooting
Scenarios
section
that
follows,
troubleshooting
these
issues
are
demonstrated.
For
each
problem,
the
text
demonstrates
how
to
quickly
and
efficiently
verify
each
symptom,
isolate
the
cause,
and
remediate
the
issue.
5-12
In
the
Common
Issues
with
PIM-S-DM
section,
three
primary
types
of
problems
were
identified:
RPF
failures,
Unicast
Routing
and
Forwarding
Problems,
and
Multicast
Routing
and
Forwarding
Problems.
This
section
explores
these
three
categories
of
failure,
by
directing
our
attention
to
the
commands
necessary
to
verify
a
problem,
isolate
it
and
remediate
it.
RPF
Fault
Isolation
in
PIM-S-DM
(for
Sparse
Mode
Traffic)
Setting
the
stage:
R9
will
join
the
multicast
group
224.9.9.9.
R9(config)#interface FastEthernet0/1
R9(config-if)#ip igmp join-group 224.9.9.9
R9(config-if)#end
Emulating
a
multicast
feed:
Can
R1
successfully
source
a
multicast
stream
from
172.16.15.1
to
the
group
224.9.9.9?
By
generating
a
ping
on
R1
to
the
group
224.9.9.9,
R1
can
emulate
a
multicast
feed
that
will
be
forwarded
as
sparse
mode:
R1#ping 224.9.9.9 repeat 10
5-13
There
are
no
issues
in
either
direction.
Step
Two:
Verify
RPF
issues
in
the
path
between
the
RP
and
host
bi-directionally.
R9#mtrace 192.1.2.2 172.16.79.9 224.9.9.9
Type escape sequence to abort.
Mtrace from 192.1.2.2 to 172.16.79.9 via group 224.9.9.9
From source (?) to destination (?)
Querying full reverse path... * switching to hop-by-hop:
0 172.16.79.9
-1 172.16.79.9 PIM [192.1.2.0/24]
-2 172.16.79.7 None No route
5-14
The
trace
from
R9
to
the
RP
reveals
that
the
interface
with
the
ip
address
172.16.67.7
on
R7
is
not
running
PIM.
Logically
the
next
step
would
be
to
verify
this
on
R7:
R7#show run interface FastEthernet0/0
Building configuration...
Current configuration : 96 bytes
!
interface FastEthernet0/0
ip address 172.16.67.7 255.255.255.0
duplex auto
speed auto
end
This
interface
is
not
running
PIM-S-DM.
To
correct
this
issue
the
ip
pim
sparse-dense-mode
command
will
be
applied:
R7#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R7(config)#interface FastEthernet0/0
R7(config-if)#ip pim sparse-dense-mode
R7(config-if)#end
R7#
%PIM-5-NBRCHG: neighbor 172.16.67.6 UP on interface FastEthernet0/0
%SYS-5-CONFIG_I: Configured from console by console
R7#
%PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 172.16.67.7 on interface
FastEthernet0/0
The
PIM
neighbor
relationship
comes
up
with
R6.
Is
the
ping
successful
on
R1?
R1#ping 224.9.9.9 repeat 10
5-15
to
to
to
to
to
to
to
to
to
to
to
request
request
request
request
request
request
request
request
request
request
request
0
1
1
2
3
4
5
6
7
8
9
from
from
from
from
from
from
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
8
1
4
1
1
1
1
1
1
1
1
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
RPF
Fault
isolation
in
PIM-S-DM
(for
Dense
Mode
Traffic)
Setting
the
stage:
R9
will
join
the
multicast
group
239.9.9.9.
R9(config)#interface FastEthernet0/1
R9(config-if)#ip igmp join-group 239.9.9.9
R9(config-if)#end
Emulating
a
multicast
feed:
Can
R1
successfully
source
a
multicast
stream
from
172.16.15.1
to
the
group
239.9.9.9?
By
generating
a
ping
on
R1
to
the
group
239.9.9.9,
R1
can
emulate
a
multicast
feed
that
will
be
forwarded
as
dense
mode:
R1#ping 239.9.9.9 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 239.9.9.9, timeout is 2 seconds:
..........
5-16
-1
-2
-3
-4
-5
-6
*
*
*
*
*
*
172.16.79.9
172.16.79.7
172.16.67.6
172.16.26.2
172.16.24.4
172.16.45.5
In
this
instance,
it
is
not
necessary
to
run
the
command
bi-directionally
because
we
see
the
value
of
None.
This
tells
us
that
the
interface
with
IP
address
172.16.45.5
is
not
PIM
enabled.
This
can
be
verified
with
show
run
interface
on
R5:
R5#show run interface fa0/1
Building configuration...
Current configuration : 96 bytes
!
interface FastEthernet0/1
ip address 172.16.45.5 255.255.255.0
duplex auto
speed auto
end
The
PIM
neighbor
relationship
comes
up
with
R4.
Is
the
ping
successful
on
R1?
R1#ping 239.9.9.9 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 239.9.9.9, timeout is 2 seconds:
Reply to request 0 from 172.16.79.9, 4 ms
5-17
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
to
to
to
to
to
to
to
to
to
request
request
request
request
request
request
request
request
request
1
2
3
4
5
6
7
8
9
from
from
from
from
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
1
1
1
1
1
1
1
1
1
ms
ms
ms
ms
ms
ms
ms
ms
ms
Unicast
Routing
and
Forwarding
Problems
Unicast
routing
issues
can
only
affect
PIM-S-DM
traffic
that
is
being
forwarded
as
sparse.
Typified
by
the
RP
failing
to
receive
a
PIM
Register
either
because
the
message
is
not
generated
by
the
PIM-DR,
or
the
RP
never
receives
the
message.
This
means
that
the
(S,G)
entry
for
the
group
in
question
will
never
appear
in
the
multicast
routing
table
of
the
RP.
Setting
the
stage:
R9
will
join
the
multicast
group
224.9.9.9.
R9(config)#interface FastEthernet0/1
R9(config-if)#ip igmp join-group 224.9.9.9
R9(config-if)#end
Emulating
a
multicast
feed:
Can
R1
successfully
source
a
multicast
stream
from
172.16.15.1
to
the
group
224.9.9.9?
By
generating
a
ping
on
R1
to
the
group
224.9.9.9,
R1
can
emulate
a
multicast
feed
that
will
be
forwarded
as
sparse
mode:
R1#ping 224.9.9.9 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 224.9.9.9, timeout is 2 seconds:
..........
5-18
The
entry
for
172.16.15.1,
224.9.9.9
tells
us
clearly
that
R5
is
actively
Registering
the
source
with
the
RP.
Is
the
RP
getting
the
Register
Message?
R2#show ip mroute 224.9.9.9
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.9.9.9), 00:06:31/00:02:52, RP 192.1.2.2, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet0/1, Forward/Sparse-Dense, 00:06:31/00:02:52
We
see
no
(S,G)
for
the
group
and
the
(*,G)
entry
is
not
"stopped".
This
means
something
happened
to
the
unicast
Register
message.
The
quickest
way
to
identify
what
has
happened
in
this
scenario
will
be
to
use
traceroute:
R5#traceroute 192.1.2.2
Type escape sequence to abort.
Tracing the route to 192.1.2.2
5-19
When
we
see
the
value
"A"
in
the
output
of
a
traceroute
the
IOS
is
telling
us
that
the
packets
are
being
administratively
blocked.
This
is
usually
the
direct
result
of
an
access-list.
The
traceroute
indicates
that
the
interface
with
the
ip
address
172.16.24.2
is
where
the
ACL
may
be
applied.
This
can
be
verified
with
show
run
interface
on
R2:
R2#show run interface GigabitEthernet0/0
Building configuration...
Current configuration : 140 bytes
!
interface GigabitEthernet0/0
ip address 172.16.24.2 255.255.255.0
ip access-group 100 in
ip pim sparse-mode
duplex auto
speed auto
end
The
access-group
command
under
this
interface
is
referencing
the
extended
access-list
100.
What
is
being
denied
by
this
ACL?
R2#show access-list 100
Extended IP access list 100
10 deny ip host 172.16.45.5 host 192.1.2.2 (417 matches)
20 permit ip any any (113 matches)
Any
traffic
sourced
from
the
FastEthernet0/1
interface
of
R5
destined
to
the
Loopback0
interface
of
R2
is
being
blocked.
This
will
include
any
PIM
Register
messages
arriving
from
R5.
This
can
be
corrected
by
modifying
the
ACL
on
R2.
We
will
remove
line
10.
R2(config)#ip access-list extended 100
R2(config-ext-nacl)#no 10
R2(config-ext-nacl)#end
%SYS-5-CONFIG_I: Configured from console by console
R2#show access-list 100
Extended IP access list 100
20 permit ip any any (139 matches)
Now
are
pings
successful
from
R1?
R1#ping 224.9.9.9 repeat 10
5-20
to
to
to
to
to
to
to
to
to
to
to
request
request
request
request
request
request
request
request
request
request
request
0
1
1
2
3
4
5
6
7
8
9
from
from
from
from
from
from
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
4
1
1
1
1
1
1
1
1
1
1
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
This
tells
us
that
the
multicast
stream
is
reaching
R9.
As
a
final
verification
we
can
see
on
R2
that
the
(S,G)
entry
is
created
and
the
(*,G)
entry
is
indeed
sparse
mode
as
designated
by
the
flag
of
"S".
R2#show ip mroute 224.9.9.9
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.9.9.9), 00:24:08/00:02:59, RP 192.1.2.2, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet0/1, Forward/Sparse-Dense, 00:24:08/00:02:59
(172.16.15.1, 224.9.9.9), 00:02:08/00:03:21, flags: T
Incoming interface: GigabitEthernet0/0, RPF nbr 172.16.24.4
Outgoing interface list:
GigabitEthernet0/1, Forward/Sparse-Dense, 00:02:08/00:03:20
The
configuration
is
working
as
expected.
5-21
Emulating
a
multicast
feed:
Can
R1
successfully
source
a
multicast
stream
from
172.16.15.1
to
the
group
224.9.9.9?
By
generating
a
ping
on
R1
to
the
group
224.9.9.9,
R1
can
emulate
a
multicast
feed
that
will
be
forwarded
as
sparse
mode:
R1#ping 224.9.9.9 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 224.9.9.9, timeout is 2 seconds:
..........
5-22
Step
Three:
Verify
the
(*,G)
and
(S,G)
entries
for
the
group
224.9.9.9
on
the
RP
(R2):
R2#show ip mroute 224.9.9.9
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.9.9.9), 00:14:48/stopped, RP 192.1.2.2, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
(172.16.15.1, 224.9.9.9), 00:05:09/00:02:50, flags: P
Incoming interface: GigabitEthernet0/0, RPF nbr 172.16.24.4
Outgoing interface list: Null
Step
Four:
Enable
debug
ip
pim
on
all
devices
in
the
path
for
the
multicast
tree.
Wait
to
see
any
unique
messages
regarding
the
group
224.9.9.9.
R7#debug ip pim
PIM debugging is on
R7#
PIM(0): Received v2 Join/Prune on FastEthernet0/1 from 172.16.79.9, to us
PIM(0): No addition to olist at scoped boundaryrpt-bit src 192.1.2.2 grp 224.9.9.9
R7#
This
tells
us
that
there
is
a
"scoped
boundary"
assigned
on
the
FastEthernet0/1
interface
of
R7;
verified
with
show
run
interface:
R7#show run interface FastEthernet0/1
Building configuration...
Current configuration : 151 bytes
!
interface FastEthernet0/1
5-23
This
can
be
corrected
by
removing
the
ip
multicast
boundary
command:
R7#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R7(config)#interface FastEthernet0/1
R7(config-if)#no ip multicast boundary 2 out
R7(config-if)#end
Are
pings
from
R1
successful
now?
R1#ping 224.9.9.9 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 224.9.9.9, timeout is 2 seconds:
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
to
to
to
to
to
to
to
to
to
to
request
request
request
request
request
request
request
request
request
request
0
1
2
3
4
5
6
7
8
9
from
from
from
from
from
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
1
1
1
1
1
1
1
1
1
1
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
They
are
successful.
Dense
Mode
Multicast
Routing
and
Forwarding
Problem
Setting
the
stage:
R9
will
join
the
multicast
group
239.9.9.9.
R9(config)#interface FastEthernet0/1
R9(config-if)#ip igmp join-group 239.9.9.9
R9(config-if)#end
Emulating
a
multicast
feed:
Can
R1
successfully
source
a
multicast
stream
from
172.16.15.1
to
the
group
239.9.9.9?
5-24
By
generating
a
ping
on
R1
to
the
group
239.9.9.9,
R1
can
emulate
a
multicast
feed
that
will
be
forwarded
as
dense
mode
traffic:
R1#ping 239.9.9.9 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 239.9.9.9, timeout is 2 seconds:
..........
This
indicates
there
or
no
evident
RPF
failures.
Step
Two:
Initiate
a
ping
with
a
high
repeat
count
from
R1:
R1#ping 239.9.9.9 repeat 50000
5-25
Step
Three:
Verify
the
(*,G)
and
(S,G)
entries
for
the
group
239.9.9.9
on
all
devices
between
R1
and
R9.
We
will
start
with
R9:
R9#sh ip mroute 239.9.9.9
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.9.9.9), 00:10:47/00:02:28, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/1, Forward/Sparse-Dense, 00:10:47/00:00:00
We
see
that
the
(S,G)
is
missing
from
R9.
This
is
not
a
surprise
because
R9
is
not
receiving
the
multicast
feed.
Moving
one
hop
closer
to
the
source
we
will
look
at
R7:
R7#show ip mroute 239.9.9.9
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.9.9.9), 00:10:59/stopped, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Sparse-Dense, 00:10:59/00:00:00
FastEthernet0/1, Forward/Sparse-Dense, 00:10:59/00:00:00, limit 0 kbps
5-26
We
see
that
the
R7
has
both
the
(*,G)
and
(S,G)
entries,
but
we
also
see
the
interface
FastEthernet0/1
in
the
OIL
has
a
rate
limit
of
0
applied.
This
is
confirmed
with
show
run
interface:
R7#show run interface FastEthernet0/1
Building configuration...
Current configuration : 166 bytes
!
interface FastEthernet0/1
ip address 172.16.79.7 255.255.255.0
ip pim sparse-dense-mode
ip multicast rate-limit out group-list 2 0
duplex auto
speed auto
end
This
is
most
quickly
corrected
by
removing
the
ip
multicast
rate-limit
configuration:
R7#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R7(config)#interface FastEthernet0/1
R7(config-if)#no ip multicast rate-limit out group-list 2 0
R7(config-if)#end
Are
the
pings
successful
from
R1?
R1#ping 239.9.9.9 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 239.9.9.9, timeout is 2 seconds:
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
to
to
to
to
to
to
to
to
to
request
request
request
request
request
request
request
request
request
0
1
2
3
4
5
6
7
8
from
from
from
from
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
1
1
1
1
1
1
1
1
1
ms
ms
ms
ms
ms
ms
ms
ms
ms
5-27
They
are
successful.
show
COMMAND:
show
ip
igmp
membership
[group-address
|
group-name]
[tracked]
[all]
This
command
displays
Internet
Group
Management
Protocol
(IGMP)
membership
information
for
multicast
groups
and
(S,
G)
channels.
Where:
EXAMPLE
OUTPUT:
R9#show ip igmp membership
Flags: A - aggregate, T - tracked
L - Local, S - static, V - virtual, R - Reported through v3
I - v3lite, U - Urd, M - SSM (S,G) channel
5-28
Reporter
172.16.79.9
172.16.79.9
172.16.79.9
Uptime
00:12:33
00:12:33
00:12:33
Exp.
02:31
02:28
02:35
Flags
2LA
2LA
2LA
Interface
Fa0/1
Fa0/1
Fa0/1
show
COMMAND:
show
ip
mroute
This
command
displays
the
contents
of
the
multicast
routing
(mroute)
table.
EXAMPLE
OUTPUT:
R7#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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.9.9.9), 00:13:45/00:03:12, RP 192.1.7.7, flags: SJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/1, Forward/Sparse-Dense, 00:05:29/00:03:12
(*, 239.9.9.9), 00:13:45/00:03:12, RP 192.1.7.7, flags: SJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/1, Forward/Sparse-Dense, 00:05:29/00:03:12
(172.16.15.1, 239.9.9.9), 00:00:19/00:02:40, flags:
Incoming interface: FastEthernet0/0, RPF nbr 172.16.67.6
Outgoing interface list:
FastEthernet0/1, Forward/Sparse-Dense, 00:00:19/00:03:11
5-29
show
COMMAND:
show
ip
pim
interface
This
command
displays
information
about
interfaces
configured
for
Protocol
Independent
Multicast
(PIM).
EXAMPLE
OUTPUT:
R7#show ip pim interface
Address
Interface
192.1.7.7
172.16.67.7
172.16.79.7
R7#
Loopback0
FastEthernet0/0
FastEthernet0/1
Ver/
Mode
v2/SD
v2/SD
v2/SD
Nbr
Count
0
1
1
Query
Intvl
30
30
30
DR
Prior
1
1
1
DR
192.1.7.7
172.16.67.7
172.16.79.9
show
COMMAND:
show
ip
pim
rp
mapping
This
command
displays
information
about
Protocol
Independent
Multicast
(PIM)
RP
mappings.
EXAMPLE
OUTPUT:
R7#show ip pim rp mapping
PIM Group-to-RP Mappings
This system is a candidate RP (v2)
Group(s) 224.0.0.0/4
RP 192.1.7.7 (?), v2
Info source: 192.1.2.2 (?), via
Uptime: 00:13:30, expires:
RP 192.1.5.5 (?), v2
Info source: 192.1.2.2 (?), via
Uptime: 00:13:30, expires:
Group(s): 224.0.0.0/4, Static
RP: 192.1.2.2 (?)
R7#
show
COMMAND:
5-30
EXAMPLE
OUTPUT:
R7#show ip pim neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default
S - State Refresh Capable
Neighbor
Interface
Uptime/Expires
Address
172.16.67.6
FastEthernet0/0
00:07:58/00:01:37
172.16.79.9
FastEthernet0/1
00:07:49/00:01:17
R7#
DR Priority,
Ver
v2
v2
DR
Prio/Mode
1 / S
1 / DR S
show
COMMAND:
show
ip
rpf
[vrf
vrf-name]
{route-distinguisher
|
source-address
[group-address]
[rd
route-
distinguisher]}
[metric]
This
command
displays
information
that
IP
multicast
routing
uses
to
perform
the
Reverse
Path
Forwarding
(RPF)
check
for
a
multicast
source
Where:
5-31
EXAMPLE
OUTPUT:
R7#show ip rpf 172.16.15.1
RPF information for ? (172.16.15.1)
RPF interface: FastEthernet0/0
RPF neighbor: ? (172.16.67.6)
RPF route/mask: 172.16.15.0/24
RPF type: unicast (eigrp 100)
RPF recursion count: 0
Doing distance-preferred lookups across tables
R7#
debug
COMMAND:
debug
ip
mpacket
[vrf
vrf-name]
[detail
|
fastswitch]
[access-list]
[group]
This
command
displays
multicast
packets
that
are
received
and
sent
on
the
device.
Where:
5-32
EXAMPLE
OUTPUT:
IP(0): s=172.16.26.6 (FastEthernet0/1) d=239.9.9.9 (FastEthernet0/0) id=1, ttl=254,
prot=1, len=100(100), mforward
debug
COMMAND:
debug
ip
pim
[vrf
vrf-name]
[bsr]
This
command
displays
Protocol
Independent
Multicast
(PIM)
packets
received
and
sent
and
displays
PIM-related
events
Where:
EXAMPLE
OUTPUT:
R7#debug ip pim
PIM debugging is on
R7#
PIM(0): Received v2 Register on FastEthernet0/0 from 172.16.45.5
for 172.16.15.1, group 239.9.9.9
PIM(0): Insert (172.16.15.1,239.9.9.9) join in nbr 172.16.67.6's queue
PIM(0): Forward decapsulated data packet for 239.9.9.9 on FastEthernet0/1
PIM(0): Building Join/Prune packet for nbr 172.16.67.6
PIM(0): Adding v2 (172.16.15.1/32, 239.9.9.9), S-bit Join
PIM(0): Send v2 join/prune to 172.16.67.6 (FastEthernet0/0)
R7#
PIM(0): Received v2 Join/Prune on FastEthernet0/1 from 172.16.79.9, to us
PIM(0): Join-list: (*, 224.9.9.9), RPT-bit set, WC-bit set, S-bit set
PIM(0): Update FastEthernet0/1/172.16.79.9 to (*, 224.9.9.9), Forward state, by PIM *G
Join
R7#
PIM(0): Received v2 Join/Prune on FastEthernet0/1 from 172.16.79.9, to us
PIM(0): Join-list: (*, 239.9.9.9), RPT-bit set, WC-bit set, S-bit set
PIM(0): Update FastEthernet0/1/172.16.79.9 to (*, 239.9.9.9), Forward state, by PIM *G
Join
PIM(0): Update FastEthernet0/1/172.16.79.9 to (172.16.15.1, 239.9.9.9), Forward state,
by PIM *G Join
R7#
PIM(0): Send RP-reachability for 239.9.9.9 on FastEthernet0/1
PIM(0): Send RP-reachability for 224.9.9.9 on FastEthernet0/1
R7#
PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 224.9.9.9
R7#
PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 224.0.1.40
PIM(0): Insert (*,224.0.1.40) join in nbr 172.16.67.6's queue
5-33
PIM(0):
PIM(0):
PIM(0):
R7#
PIM(0):
R7#
Trouble
Ticket
#1
Your
supervisor
has
brought
to
your
attention
that
users
on
the
VLAN79
segment
connecting
R7
and
R9
cannot
receive
the
multicast
feed
for
233.99.99.99.
You
have
been
instructed
to
use
R9
and
R1
for
any
testing.
You
must
correct
the
issue.
Trouble
Ticket
#2
After
solving
Trouble
Ticket
#1,
your
supervisor
has
observed
that
users
on
the
VLAN79
segment
connecting
R7
and
R9
cannot
receive
traffic
destined
to
any
sparse
mode
forwarded
multicast
traffic.
Again,
you
are
to
use
R1
as
the
source
and
R9
as
a
simulated
host.
You
have
been
assigned
the
multicast
group
224.99.99.99
for
all
testing.
Correct
this
issue.
5-34
The
pings
are
not
successful.
This
verifies
that
the
problem
actually
exists.
Step
2
-
Fault
Isolation:
The
next
course
of
action
is
to
use
the
mtrace
utility
to
rule
out
the
possibility
of
an
RPF
issue.
Make
certain
to
perform
this
process
in
both
directions,
first
from
R1
toward
R9,
then
from
R9
toward
R1.
R1#mtrace 172.16.15.1 172.16.79.9 233.99.99.99
Type escape sequence to abort.
Mtrace from 172.16.15.1 to 172.16.79.9 via group 233.99.99.99
From source (?) to destination (?)
Querying full reverse path... * switching to hop-by-hop:
0 172.16.79.9
-1 * 172.16.79.9 PIM [172.16.15.0/24]
-2 * 172.16.79.7 PIM [172.16.15.0/24]
-3 * 172.16.67.6 PIM [172.16.15.0/24]
-4 * 172.16.26.2 PIM [172.16.15.0/24]
-5 * 172.16.24.4 PIM [172.16.15.0/24]
-6 * 172.16.45.5 PIM [172.16.15.0/24]
-7 * 172.16.15.1 PIM [172.16.15.0/24]
R1#mtrace 172.16.79.9 172.16.15.1 233.99.99.99
Type escape sequence to abort.
Mtrace from 172.16.79.9 to 172.16.15.1 via group 233.99.99.99
From source (?) to destination (?)
5-35
This
output
indicates
that
there
are
no
evident
RPF
issues
in
the
path
between
R1
and
R9.
This
means
that
we
will
need
to
check
the
status
of
the
(S,G)
pairs
for
this
group
on
all
devices
between
R1
and
R9.
Use
a
ping
with
a
high
repeat
count
on
R1
for
this
process:
R1#ping 233.99.99.99 repeat 5000
Type escape sequence to abort.
Sending 5000, 100-byte ICMP Echos to 233.99.99.99, timeout is 2 seconds:
.............................<output omitted>
Now
use
show
ip
mroute
on
all
the
devices
and
observe
the
output
for
the
(S,G)
pair
172.16.15.1,
233.99.99.99
on
the
transit
devices.
R5#sh ip mroute 233.99.99.99
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 233.99.99.99), 00:01:41/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/1, Forward/Sparse-Dense, 00:01:41/00:00:00
FastEthernet0/0, Forward/Sparse-Dense, 00:01:41/00:00:00
(172.16.15.1, 233.99.99.99), 00:01:41/00:01:18, flags: PT
Incoming interface: FastEthernet0/0, RPF nbr 172.16.15.1
Outgoing interface list:
FastEthernet0/1, Prune/Sparse-Dense, 00:01:42/00:01:17
5-36
R5
has
the
(S,G)
pair,
but
it
is
in
the
Prune
state
for
the
interface
in
the
OIL.
We
will
now
look
at
R4:
R4#show ip mroute 233.99.99.99
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 233.99.99.99), 00:11:57/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/1, Forward/Sparse-Dense, 00:11:57/00:00:00
FastEthernet0/0, Forward/Sparse-Dense, 00:11:57/00:00:00
(172.16.15.1, 233.99.99.99), 00:02:05/00:00:56, flags: PT
Incoming interface: FastEthernet0/1, RPF nbr 172.16.45.5
Outgoing interface list:
FastEthernet0/0, Prune/Sparse-Dense, 00:02:06/00:00:53
R4
has
the
(S,G)
pair,
but
it
is
in
the
Prune
state
for
the
interface
in
the
OIL.
We
will
now
look
at
R2:
R2#sh ip mroute 233.99.99.99
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 233.99.99.99), 00:02:23/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet0/1, Forward/Sparse-Dense, 00:02:23/00:00:00
GigabitEthernet0/0, Forward/Sparse-Dense, 00:02:23/00:00:00
5-37
R2
has
the
(S,G)
pair,
and
it
is
in
the
Prune
state
for
the
interface
in
the
OIL.
We
will
now
look
at
R6:
R6#show ip mroute 233.99.99.99
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 233.99.99.99), 00:02:43/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/1, Forward/Sparse-Dense, 00:02:43/00:00:00
(172.16.15.1, 233.99.99.99), 00:02:43/00:00:16, flags: PT
Incoming interface: FastEthernet0/1, RPF nbr 172.16.26.2
Outgoing interface list: Null
R6
has
the
(S,G)
pair,
but
there
are
no
interfaces
in
the
OIL.
We
need
to
examine
the
nature
of
the
PIM-
S-DM
configuration
on
R6:
R6#show ip pim interface
Address
Interface
172.16.67.6
172.16.26.6
FastEthernet0/0
FastEthernet0/1
Ver/
Mode
v2/S
v2/SD
Nbr
Count
1
1
Query
Intvl
30
30
DR
Prior
1
1
DR
172.16.67.7
172.16.26.6
Observe
that
the
FastEthernet0/0
interface
is
running
PIM
version
2,
but
it
is
in
sparse
mode
as
indicated
by
the
value
of
"S".
In
this
lab
this
flag
should
be
SD
for
sparse-dense.
This
can
be
confirmed
further
by
looking
at
the
configuration
under
this
interface:
R6#show run interface FastEthernet0/0
Building configuration...
5-38
This
interface
cannot
forward
traffic
in
dense
mode
with
the
current
configuration.
This
has
isolated
the
cause
of
the
problem.
Step
3
-
Fault
Remediation:
In
this
scenario,
the
ip
pim
sparse-dense-mode
command
should
be
applied
under
the
interface
as
we
have
in
the
past.
R6#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R6(config)#interface FastEthernet0/0
R6(config-if)#no ip pim sparse-mode
R6(config-if)#ip pim sparse-dense-mode
R6(config-if)#end
R6#
%PIM-5-NBRCHG: neighbor 172.16.67.7 UP on interface FastEthernet0/0
%PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 172.16.67.7 on interface
FastEthernet0/0
%SYS-5-CONFIG_I: Configured from console by console
Step
4
-
Verification
of
Remediation
Once
the
error
has
been
isolated
and
remediated
it
is
highly
recommended
to
verify
that
the
Trouble
Ticket
has
been
repaired
using
the
same
method
of
the
initial
fault
verification.
R1#ping 233.99.99.99 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 233.99.99.99, timeout is 2 seconds:
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
to
to
to
to
to
to
to
to
request
request
request
request
request
request
request
request
0
1
2
3
4
5
6
7
from
from
from
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
1
1
1
1
1
1
1
1
ms
ms
ms
ms
ms
ms
ms
ms
5-39
The
issue
has
been
corrected.
Trouble
Ticket
#2
Solution
After
solving
Trouble
Ticket
#1,
your
supervisor
has
observed
that
users
on
the
VLAN79
segment
connecting
R7
and
R9
cannot
receive
traffic
destined
to
any
sparse
mode
forwarded
multicast
traffic.
Again,
you
are
to
use
R1
as
the
source
and
R9
as
a
simulated
host.
You
have
been
assigned
the
multicast
group
224.99.99.99
for
all
testing.
Correct
this
issue.
Step
1
-
Fault
Verification:
Can
R1
ping
the
group
224.99.99.99
successfully:
R1#ping 224.99.99.99 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 224.99.99.99, timeout is 2 seconds:
..........
The
ping
test
to
the
multicast
group
224.99.99.99
fails.
This
verifies
that
the
problem
actually
exists.
Step
2
-
Fault
Isolation:
In
order
to
verify
that
RPF
issues
are
not
at
fault,
use
the
mtrace
utility
between
the
RP
and
the
host,
and
the
RP
and
Source.
R2#mtrace 192.1.2.2 172.16.79.9 224.99.99.99
Type escape sequence to abort.
Mtrace from 192.1.2.2 to 172.16.79.9 via group 224.99.99.99
From source (?) to destination (?)
Querying full reverse path... * switching to hop-by-hop:
0 172.16.79.9
-1 * 172.16.79.9 PIM Prune sent upstream [192.1.2.0/24]
-2 * 172.16.79.7 PIM [192.1.2.0/24]
-3 * 172.16.67.6 PIM [192.1.2.0/24]
-4 * 172.16.26.2 PIM Reached RP/Core [192.1.2.0/24]
There
are
no
issues
between
the
RP
and
the
host,
what
about
the
RP
and
the
source:
R2#mtrace 192.1.2.2 172.16.15.1 224.99.99.99
Type escape sequence to abort.
Mtrace from 192.1.2.2 to 172.16.15.1 via group 224.99.99.99
From source (?) to destination (?)
Querying full reverse path... * switching to hop-by-hop:
5-40
0
-1
-2
-3
-4
172.16.15.1
* 172.16.15.1
* 172.16.15.5
* 172.16.45.4
* 172.16.24.2
PIM
PIM
PIM
PIM
There
are
no
issues
in
the
creation
of
the
control
plane
between
the
RP
and
the
source.
Initiate
a
ping
from
R1
with
a
high
repeat
count
and
see
if
the
next
hop
router
and
the
RP
create
(S,G)
entries
for
224.99.99.99
after
enabling
debug
ip
pim
on
R2:
R2#debug ip pim
PIM debugging is on
Now
on
R1:
R1#ping 224.99.99.99 repeat 1000
We
see
that
R2
is
receiving
the
PIM
Register
message
from
R5,
but
the
router
is
refusing
to
be
the
RP
for
this
group
claiming
the
Registration
is
coming
from
an
"INVALID_SRC".
This
is
most
commonly
caused
by
a
filter
or
security
configuration.
These
commands
are
best
located
with
show
run:
R2#show run | inc interface | pim
interface Loopback0
ip pim sparse-dense-mode
interface GigabitEthernet0/0
ip pim sparse-dense-mode
interface GigabitEthernet0/1
ip pim sparse-dense-mode
interface Serial0/1/0
interface Serial0/2/0
5-41
We
see
the
ip
pim
accept-register
command.
This
command
references
the
extended
access-list
199.
What
is
permitted
and
denied
in
this
ACL?
R2#show access-list 199
Extended IP access list 199
10 deny ip any any (2 matches)
Any
PIM
Register
messages
from
any
device
will
be
denied.
This
isolates
the
cause
of
our
fault.
Step
3
-
Fault
Remediation:
In
this
scenario,
the
ip
pim
accept-register
command
needs
removed
from
R2:
R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#no ip pim accept-register list 199
R2(config)#end
Step
4
-
Verification
of
Remediation
Once
the
error
has
been
isolated
and
remediated,
it
is
highly
recommended
to
verify
that
the
Trouble
Ticket
has
been
repaired
using
the
same
method
used
to
verify
the
fault
initially:
R1#ping 224.99.99.99 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 224.99.99.99, timeout is 2 seconds:
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
to
to
to
to
to
to
to
to
to
to
to
request
request
request
request
request
request
request
request
request
request
request
0
1
1
2
3
4
5
6
7
8
9
from
from
from
from
from
from
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
4
1
1
1
1
1
1
1
1
1
1
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
The
issue
has
been
corrected.
5-42
Chapter
6:
Bidirectional
Protocol
Independent
Multicast
(BIDIR-
PIM)
In
this
chapter
of
IPv4/6
Multicast
Operation
and
Troubleshooting,
the
processes
and
the
functionality
of
Bidirectional
PIM
(BIDIR-PIM)
protocol
are
examined
in
great
depth.
Once
the
operational
characteristics
of
this
important
protocol
are
detailed
completely,
the
focus
becomes
that
of
troubleshooting.
This
includes
the
careful
examination
of
symptoms,
a
fault
isolation
methodology,
and
the
implementation
of
repairs
for
the
Bidirectional
PIM
protocol.
The
chapter
begins
with
a
thorough
6-1
review
of
BIDIR-PIM,
and
then
quickly
launches
in
to
an
exhaustive
analysis
of
the
art
of
troubleshooting
this
multicast
routing
protocol.
This
important
chapter
concludes
with
sample
troubleshooting
scenarios,
reference
materials
for
the
most
important
show
and
debug
commands,
and
exciting
challenges
that
allow
readers
to
practice
implementing
the
troubleshooting
skills
they
have
obtained.
6-2
6-3
Another
unique
property
of
BIDIR-PIM
is
that
there
is
no
need
to
send
PIM
assert
messages.
This
is
because
the
DF
election
procedure
eliminates
parallel
downstream
paths
from
any
RP.
An
RP
never
joins
a
path
back
to
the
source,
nor
will
it
send
any
register
stops.
The
configuration
of
BIDIR-PIM
on
the
router
is
very
simple.
First,
configure
PIM
sparse-mode
on
the
appropriate
interfaces
using
the
command
ip
pim
sparse-mode.
Then,
use
the
global
configuration
mode
command
for
BIDIR-PIM:
ip
pim
bidir-enable
Finally,
to
configure
the
BIDIR-PIM
RP,
use
the
command:
ip
pim
rp-address
rp-address
[access-list]
[override]
bidir
Where:
6-4
In
this
topology,
R2
is
the
RP;
all
devices
are
running
BIDIR-PIM.
Evidenced
by
using
show
ip
pim
rp
mapping
on
all
devices:
R1#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s): 224.0.0.0/4, Static, Bidir Mode
RP: 192.1.2.255 (?)
6-5
In
this
instance,
all
devices
agree
that
the
RP
for
the
entire
multicast
range
of
224.0.0.0/4
will
be
R2.
The
interesting
thing
however,
is
that
the
address
of
the
RP
is
192.1.2.255.
It
should
be
pointed
out
that
this
address
does
not
exist
in
the
network
as
evidenced
with
the
ping
utility
on
R1.
R1#ping 192.1.2.255
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.1.2.255, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
6-6
Can
we
successfully
reach
a
host
using
this
ip
address
for
the
RP?
To
find
out
we
will
have
R9
join
the
multicast
group
224.9.9.9.
R9#conf t
Enter configuration commands, one per line.
R9(config)#interface FastEthernet0/1
R9(config-if)#ip igmp join-group 224.9.9.9
R9(config-if)#end
With
this
accomplished
we
will
then
ping
this
group
from
R1:
R1#ping 224.9.9.9 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 224.9.9.9, timeout is 2 seconds:
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
to
to
to
to
to
to
to
to
to
to
request
request
request
request
request
request
request
request
request
request
0
1
2
3
4
5
6
7
8
9
from
from
from
from
from
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
28
28
28
28
28
28
28
28
28
28
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
The
pings
are
successful.
This
illustrates
that
the
RP
address
is
not
required
to
exist
on
a
physical
interface,
and
to
illustrate
the
concept
that
in
BIDIR-PM
the
RP
is
more
like
a
destination
vector
as
mentioned
previously.
So
in
BIDIR-PM
the
RP
is
not
required
to
be
a
physical
router
like
in
PIM-SM.
Understanding
this
vector
idea
my
prove
useful
in
troubleshooting
BIDIR-PIM
problems.
Host-to-RP
Shared
Tree
Just
like
in
PIM-SM,
joins
are
processed
toward
the
RP
in
the
creation
of
the
customary
shared
tree.
During
this
process
the
host
sends
an
IGMP
join,
which
triggers
the
creation
of
(*,G)
entries
in
the
multicast
routing
tables
of
the
routers
in
the
transit
path
from
the
IGMP
router
to
the
RP.
In
this
demonstration,
R9
has
joined
the
multicast
group
224.9.9.9.
This
means
that
it
has
sent
an
IGMP
join
to
R7,
the
IGMP
router
on
its
VLAN79
segment.
The
fact
that
this
IGMP
membership
report
has
made
it
to
R7
as
evidenced
by
the
output
of
show
ip
igmp
groups:
R7#show ip igmp groups
IGMP Connected Group Membership
Group Address
Interface
Accounted
Uptime
Expires
Last Reporter
Group
6-7
224.9.9.9
224.0.1.40
224.0.1.40
FastEthernet0/1
FastEthernet0/1
FastEthernet0/0
01:19:18
01:19:14
01:20:06
00:02:39
00:02:46
00:02:28
172.16.79.9
172.16.79.9
172.16.67.6
We
see
that
172.16.79.9
was
the
last
reporter
for
the
group
224.9.9.9.
Now
that
R7
has
this
IGMP
membership
message
from
the
host,
the
router
will
send
PIM
joins
toward
the
RP
for
this
group.
These
joins
will
be
propagated
hop-by-hop
using
the
link-local
address
224.0.0.13.
We
verify
this
process
by
looking
for
the
creation
of
the
(*,
224.9.9.9)
entries
in
the
multicast
routing
tables
of
R7,
R6,
and
R2
as
evidenced
by
show
ip
mroute:
R7#show ip mroute 224.9.9.9
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.9.9.9), 01:18:25/00:02:37, RP 192.1.2.255, flags: BC
Bidir-Upstream: FastEthernet0/0, RPF nbr 172.16.67.6
Outgoing interface list:
FastEthernet0/1, Forward/Sparse, 01:12:14/00:02:50
FastEthernet0/0, Bidir-Upstream/Sparse, 01:12:14/00:00:00
The
(S,G)
entry
is
on
R7
for
the
group
224.9.9.9.
Observe
the
flag
of
B
for
the
pair.
Also,
observe
that
the
is
no
incoming
interface
list
in
the
output.
This
has
been
replaced
with
the
entry
Bidir-Upstream.
The
interface
found
in
this
section
(FastEthernet0/0)
is
the
RPF
interface
used
to
reach
the
RP.
This
means
any
traffic
received
on
this
"upstream"
interface
will
be
forwarded
"downstream"
to
any
receivers
on
the
shared-tree.
R6#show ip mroute 224.9.9.9
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
6-8
6-9
Next
we
will
look
at
the
contents
of
the
multicast
routing
table
on
the
next
hop
router
using
show
ip
mroute:
R5#show ip mroute 224.9.9.9
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.9.9.9), 00:00:37/00:02:50, RP 192.1.2.255, flags: BP
Bidir-Upstream: FastEthernet0/1, RPF nbr 172.16.45.4
Outgoing interface list:
FastEthernet0/1, Bidir-Upstream/Sparse, 00:00:37/00:00:00
Observe
that
we
have
the
entry
for
224.9.9.9,
again
note
the
absence
of
the
Incoming
Interface
List,
replaced
with
the
Bidir-Upstream
interface
toward
the
RP.
Next
look
at
R4:
R4#show ip mroute 224.9.9.9
Group 224.9.9.9 not found
R4#show ip mroute 224.9.9.9
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.9.9.9), 00:01:00/00:02:51, RP 192.1.2.255, flags: BP
Bidir-Upstream: FastEthernet0/0, RPF nbr 172.16.24.2
Outgoing interface list:
6-10
Observe
that
the
RP
has
only
the
single
entry
for
the
group
224.9.9.9.
As
mentioned
in
the
Technology
Review,
BIDIR-PIM
does
not
utilize
(S,G)
entries,
nor
do
we
need
to
be
concerned
with
the
multicast
stream
reverting
to
the
shortest
path.
In
BIDIR-PIM,
this
behavior
simply
does
not
take
place.
The
RP
will
remain
the
root
of
the
BIDIR-PIM
environment
and
traffic
will
always
travel
upstream
toward
the
RP
or
downstream
away
from
the
RP.
Another
deviation
from
typical
PIM-SM
behavior
is
how
multicast
packets
are
forwarded;
this
process,
as
discussed,
involves
the
election
of
a
Designated
Forwarder.
BIDIR-PIM
Neighbors
and
Designated
Forwarder
Election
The
good
news
is
BIDIR-PIM
does
not
use
RPF
checks
for
multicast
traffic.
BIDIR-PIM
relies
on
another
mechanism
for
loop
prevention.
PIM
neighbors
exchange
PIM
Hello
messages
on
adjacent
links.
If
a
router
is
BIDIR-PIM
enabled
that
fact
is
communicated
inside
the
Hello
messages
it
sends
to
its
neighbors.
These
messages
and
the
BIDIR
enabled
status
they
contain
is
essential
for
the
BIDIR-PIM
control
plane
to
form
properly.
In
order
for
BIDIR-PIM
to
operate,
a
single
device
on
each
network
segment
must
be
elected
to
be
the
Designated
Forwarder
(DF)
for
a
given
group-to-RP
mapping,
on
a
segment-by-segment
basis.
It
is
the
purpose
of
this
DF
to
create
a
loop
free
shared-tree
to
the
RP
and
a
DF
will
be
elected
for
every
BIDIR-RP
group
for
each
segment
carrying
BIDIR-PIM
traffic.
This
mechanism
eliminates
the
need
for
RPF
6-11
checks.
The
ultimate
role
of
the
DF
is
to
forward
multicast
traffic
received
on
its
segment.
The
role
of
DF
is
assigned
based
on
the
lowest
metric
to
reach
the
RP,
and
in
the
event
of
a
tie
in
these
values
the
highest
IP
address
is
the
selection
criteria.
This
can
be
observed
based
on
the
output
of
debug
ip
pim
df
on
R1:
R1#debug ip pim df
PIM RP DF debugging is on
R1#clear ip route *
R1#
PIM(0): RP(192.1.2.255) metric changed from (NULL, unicast, 2147483647, -1)
PIM(0): to (FastEthernet0/0, unicast, 119, 3)
PIM(0): Elect DF for FastEthernet0/0, new RP 192.1.2.255
PIM(0): Send v2 Offer on FastEthernet0/0 (Non-DF) for RP 192.1.2.255
PIM(0): Sender 172.16.15.1, pref 2147483647, metric 2147483647
PIM(0): Receive DF Winner message from 172.16.15.5 on FastEthernet0/0 (Non-DF)
PIM(0): RP 192.1.2.255, pref 120, metric 2
PIM(0): Metric is better
When
troubleshooting
this
protocol
it
is
important
to
note
that
if
adjacent
routers
are
not
both
BIDIR-
PIM
enabled
then
the
DF
election
process
will
not
take
place.
This
fact
is
evident
when
a
router
receives
a
PIM
Hello
message
that
does
not
contain
the
BIDIR
flag.
If
the
designated
forwarder
cannot
be
elected
then
no
BIDIR-PIM
traffic
can
be
forwarded
to
or
from
the
segment.
This
process
is
designed
to
protect
the
network
from
possible
multicast
routing
loops.
The
fact
that
BIDIR-PIM
uses
nothing
but
shared-trees,
eliminates
the
PIM
Register
process
and
works
bi-directionally,
makes
it
a
very
attractive
version
of
PIM
to
utilize
in
environments
that
require
applications
like
video
conferencing.
However,
to
reduce
operational
overhead
by
eliminating
possibly
hundreds
of
multicast
routing
states,
BIDIR-PIM
has
eliminated
the
source
state
(S,G)
entries
from
the
multicast
routing
table.
The
most
used
tool
in
troubleshooting
multicast
issues
to
date
has
been
these
source
state
entries.
Therefore,
the
very
thing
that
makes
BIDIR-PIM
more
efficient
also
makes
it
more
difficult
to
troubleshoot.
6-12
6-13
In
the
BIDIR-PIM
Sample
Troubleshooting
Scenarios
section
that
follows,
troubleshooting
these
issues
are
demonstrated.
For
each
problem,
the
text
demonstrates
how
to
quickly
and
efficiently
verify
each
symptom,
isolate
the
cause,
and
remediate
the
issue.
6-14
In
the
Common
Issues
with
BIDIR-PIM
section,
two
primary
types
of
problems
were
identified:
RP
and
DF
failures,
and
Multicast
Routing
and
Forwarding
Problems.
This
section
explores
these
two
categories
of
failure,
by
directing
our
attention
to
the
commands
necessary
to
verify
a
problem,
isolate
it
and
remediate
it.
RP
Failure
in
BIDIR-PIM
Setting
the
stage:
R9
will
join
the
multicast
group
224.9.9.9.
R9(config)#interface FastEthernet0/1
R9(config-if)#ip igmp join-group 224.9.9.9
R9(config-if)#end
Emulating
a
multicast
feed:
Can
R1
successfully
source
a
multicast
stream
from
172.16.15.1
to
the
group
224.9.9.9?
By
generating
a
ping
on
R1
to
the
group
224.9.9.9
R1
can
emulate
a
multicast
feed:
R1#ping 224.9.9.9 repeat 100000000
Type escape sequence to abort.
6-15
Are
there
interfaces
in
the
OIL
for
the
(*,
224.9.9.9)
group?
The
output
indicates
that
there
are
no
interfaces
in
the
output
list
with
the
value
of
"Null".
Observe
that
the
RP
192.2.2.255
and
the
RPF
nbr
0.0.0.0
do
not
match.
This
tells
us
something
is
wrong
with
the
RP.
Step
Two:
Identify
the
RP
network
and
verify
reachability
to
it?
Find
the
configured
RP
address
with
show
ip
pim
rp:
R5#show ip pim rp
Group: 224.9.9.9, RP: 192.2.2.255, uptime 00:01:01, expires never
Group: 224.0.1.40, RP: 192.2.2.255, uptime 00:07:42, expires never
This
output
tells
us
that
the
Group-to-RP
mapping
on
R5
for
224.9.9.9
is
for
192.2.2.255.
Is
this
even
reachable
in
our
topology?
R5#show ip route 192.2.2.255
% Network not in table
6-16
Immediately,
we
can
see
there
is
no
route
on
R5
for
this
address.
The
drawing
tells
us
that
the
RP
is
supposed
to
be
192.1.2.255.
To
correct
this
issue
use
the
correct
ip
pim
rp-address
command:
R5#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R5(config)#ip pim rp-address 192.1.2.2 bidir
R5(config)#end
to
to
to
to
to
to
to
to
to
to
request
request
request
request
request
request
request
request
request
request
0
1
2
3
4
5
6
7
8
9
from
from
from
from
from
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
28
28
28
28
28
28
28
28
28
28
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
DF
Failure
in
BIDIR-PIM
Setting
the
stage:
R9
will
join
the
multicast
group
224.9.9.9.
R9(config)#interface FastEthernet0/1
R9(config-if)#ip igmp join-group 224.9.9.9
R9(config-if)#end
Emulating
a
multicast
feed:
Can
R1
successfully
source
a
multicast
stream
from
172.16.15.1
to
the
group
224.9.9.9?
By
generating
a
ping
on
R1
to
the
group
224.9.9.9
R1
can
emulate
a
multicast
feed:
R1#ping 224.9.9.9 repeat 100000000
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 224.9.9.9, timeout is 2 seconds:
.......... <output omitted>
6-17
Observe
that
the
RPF
nbr
is
0.0.0.0.
This
means
either
this
device
is
the
RP,
or
the
device
believes
the
RP
address
is
invalid.
This
device
has
no
interface
in
the
network
192.1.2.0/24,
so
it
cannot
be
the
RP.
This
leaves
the
later
problem.
Step
Two:
Verify
the
identity
of
the
designated
forward
for
all
interfaces.
On
R5
us
show
ip
pim
interface
df
command:
R5#show ip pim interface
* implies this system is
Interface
FastEthernet0/0
df
the DF
RP
192.1.2.255
DF Winner
*172.16.15.5
Metric
2
Uptime
00:11:05
This
output
indicates
that
no
designated
forwarder
has
been
elected
on
the
FastEthernet0/0
interface
of
R5.
Use
show
ip
pim
interface
to
see
if
both
interfaces
are
running
sparse-mode.
R5#show ip pim interface
Address
Interface
172.16.15.5
172.16.45.5
FastEthernet0/0
FastEthernet0/1
Ver/
Mode
v2/S
v2/S
Nbr
Count
1
1
Query
Intvl
30
30
DR
Prior
1
1
DR
172.16.15.5
172.16.45.5
This output indicates that neighbor relationships exit out both interfaces.
6-18
Step
Three:
Check
the
next
hop
router
in
the
multicast
path
for
the
(*,G).
Use
show
ip
mroute
on
R4:
R4#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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.0.1.40), 00:30:07/00:02:32, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:30:07/00:02:21
There
is
no
record
in
the
multicast
routing
table
for
the
group
224.9.9.9.
If
the
group
was
created
on
R5
that
means
R5
was
participating
in
BIDIR-PIM.
Also,
remember
that
R5
considered
the
identity
of
the
RP
to
be
invalid.
This
could
be
caused
by
a
router
in
the
transit
path
not
being
able
to
participate
in
BIDIR-
PIM
or
a
lack
of
end-to-end
PIM
communication
between
R5
and
the
RP.
Observe
that
the
show
ip
mroute
output
indicates
that
there
is
an
Incoming
Interface
List;
something
that
does
not
exist
in
BIDIR-
PIM.
Use
show
run
to
see
if
the
router
is
enabled
for
BIDIR-PIM:
R4#show run | inc bidir
R4#
We
can
see
that
R4
has
not
been
configured
with
BIDIR-PIM,
without
this
command
the
router
cannot
participate
in
the
DF
election
and
as
such
breaks
the
connectivity
to
the
RP.
Correct
this
issue
by
applying
the
ip
pim
bidir-enable
and
ip
pim
rp-address
commands:
R4#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)#ip pim bidir-enable
R4(config)#ip pim rp-address 192.1.2.255 bidir
R4(config)#end
6-19
to
to
to
to
to
to
to
to
to
to
request
request
request
request
request
request
request
request
request
request
0
1
2
3
4
5
6
7
8
9
from
from
from
from
from
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
28
28
28
28
28
28
28
28
28
28
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
Emulating
a
multicast
feed:
Can
R1
successfully
source
a
multicast
stream
from
172.16.15.1
to
the
group
224.9.9.9?
By
generating
a
ping
on
R1
to
the
group
224.9.9.9
R1
can
emulate
a
multicast
feed:
R1#ping 224.9.9.9 repeat 100000000
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 224.9.9.9, timeout is 2 seconds:
.......... <output omitted>
6-20
R4
has
no
issues.
We
see
the
RP,
the
RPF
nbr
used
to
reach
the
RP,
and
the
FastEthernet0/0
interface
pointing
to
R2.
Try
the
next
hop:
R2#show ip mroute 224.9.9.9
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
6-21
No
issues
exist
on
R2
either.
Note
that
the
RP
and
the
RPF
nbr
values
match,
meaning
that
this
device
is
the
RP
for
this
group.
R6#show ip mroute 224.9.9.9
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.9.9.9), 07:14:41/00:03:27, RP 192.1.2.255, flags: B
Bidir-Upstream: FastEthernet0/1, RPF nbr 172.16.26.2
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 07:08:31/00:02:47
FastEthernet0/1, Bidir-Upstream/Sparse, 07:08:31/00:00:00
6-22
Note
that
R7
has
FastEthernet0/1
in
the
OIL,
and
we
can
see
that
it
will
limit
any
outbound
traffic
to
0
kbps.
This
will
effectively
block
all
outbound
traffic
to
R9.
We
can
verify
this
with
the
show
run
command:
R7#show run interface FastEthernet0/1
Building configuration...
Current configuration : 147 bytes
!
interface FastEthernet0/1
ip address 172.16.79.7 255.255.255.0
ip pim sparse-mode
ip multicast rate-limit out 0
duplex auto
speed auto
end
to
to
to
to
to
to
to
to
to
to
request
request
request
request
request
request
request
request
request
request
0
1
2
3
4
5
6
7
8
9
from
from
from
from
from
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
28
28
28
28
28
28
28
28
28
28
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
6-23
show
COMMAND:
show
ip
igmp
membership
[group-address
|
group-name]
[tracked]
[all]
This
command
displays
Internet
Group
Management
Protocol
(IGMP)
membership
information
for
multicast
groups
and
(S,
G)
channels.
Where:
EXAMPLE
OUTPUT:
R9#show ip igmp membership
Flags: A - aggregate, T - tracked
L - Local, S - static, V - virtual, R - Reported through v3
I - v3lite, U - Urd, M - SSM (S,G) channel
1,2,3 - The version of IGMP the group is in
Channel/Group-Flags:
/ - Filtering entry (Exclude mode (S,G), Include mode (*,G))
Reporter:
<mac-or-ip-address> - last reporter if group is not explicitly tracked
<n>/<m>
- <n> reporter in include mode, <m> reporter in exclude
6-24
Channel/Group
*,224.9.9.9
*,239.9.9.9
*,224.0.1.40
R9#
Reporter
172.16.79.9
172.16.79.9
172.16.79.9
Uptime
00:12:33
00:12:33
00:12:33
Exp.
02:31
02:28
02:35
Flags
2LA
2LA
2LA
Interface
Fa0/1
Fa0/1
Fa0/1
show
COMMAND:
show
ip
mroute
This
command
displays
the
contents
of
the
multicast
routing
(mroute)
table.
EXAMPLE
OUTPUT:
R7#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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.9.9.9), 00:01:07/00:02:07, RP 192.1.2.255, flags: BP
Bidir-Upstream: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
(*, 224.0.1.40), 00:01:28/00:02:50, RP 192.1.2.255, flags: BPL
Bidir-Upstream: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
show
COMMAND:
show
ip
pim
interface
This
command
displays
information
about
interfaces
configured
for
Protocol
Independent
Multicast
(PIM).
EXAMPLE
OUTPUT:
R7#show ip pim interface
Address
Interface
172.16.67.7
FastEthernet0/0
Ver/
Mode
v2/S
Nbr
Count
1
Query
Intvl
30
DR
Prior
1
DR
172.16.67.7
6-25
172.16.79.7
R7#
FastEthernet0/1
v2/S
30
172.16.79.9
show
COMMAND:
show
ip
pim
rp
mapping
This
command
displays
information
about
Protocol
Independent
Multicast
(PIM)
RP
mappings.
EXAMPLE
OUTPUT:
R7#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s): 224.0.0.0/4, Static, Bidir Mode
RP: 192.1.2.255 (?)
R7#
show
COMMAND:
show
ip
pim
[vrf
vrf-name]
neighbor
[interface-type
interface-number]
This
command
displays
information
about
Protocol
Independent
Multicast
(PIM)
neighbors
discovered
by
PIM
version
1
router
query
messages
or
PIM
version
2
hello
messages.
Where:
EXAMPLE
OUTPUT:
R7#show ip pim neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default
S - State Refresh Capable
Neighbor
Interface
Uptime/Expires
Address
172.16.67.6
FastEthernet0/0
00:03:33/00:01:37
172.16.79.9
FastEthernet0/1
00:03:15/00:01:28
R7#
DR Priority,
Ver
v2
v2
DR
Prio/Mode
1 / B S
1 / DR B S
show
COMMAND:
show
ip
rpf
[vrf
vrf-name]
{route-distinguisher
|
source-address
[group-address]
[rd
route-
distinguisher]}
[metric]
6-26
This
command
displays
information
that
IP
multicast
routing
uses
to
perform
the
Reverse
Path
Forwarding
(RPF)
check
for
a
multicast
source
Where:
EXAMPLE
OUTPUT:
R7#show ip rpf 172.16.15.1
RPF information for ? (172.16.15.1)
RPF interface: FastEthernet0/0
RPF neighbor: ? (0.0.0.0)
RPF route/mask: 172.16.15.0/24
RPF type: unicast (rip)
RPF recursion count: 0
Doing distance-preferred lookups across tables
R7#
6-27
debug
COMMAND:
debug
ip
mpacket
[vrf
vrf-name]
[detail
|
fastswitch]
[access-list]
[group]
This
command
displays
multicast
packets
that
are
received
and
sent
on
the
device.
Where:
EXAMPLE
OUTPUT:
IP(0): s=172.16.26.6 (FastEthernet0/1) d=239.9.9.9 (FastEthernet0/0) id=1, ttl=254,
prot=1, len=100(100), mforward
debug
COMMAND:
debug
ip
pim
[vrf
vrf-name]
[bsr]
This
command
displays
Protocol
Independent
Multicast
(PIM)
packets
received
and
sent
and
displays
PIM-related
events
6-28
Where:
EXAMPLE
OUTPUT:
R2#debug ip pim
PIM debugging is on
R2#
R2#
R2#
R2#
PIM(0): Received v2 Join/Prune on GigabitEthernet0/1 from 172.16.26.6, to
PIM(0): Join-list: (*, 224.0.1.40), RPT-bit set, WC-bit set, S-bit set
PIM(0): Update GigabitEthernet0/1/172.16.26.6 to (*, 224.0.1.40), Forward
PIM *G Join
R2#
PIM(0): Received v2 Join/Prune on GigabitEthernet0/0 from 172.16.24.4, to
PIM(0): Join-list: (*, 224.0.1.40), RPT-bit set, WC-bit set, S-bit set
PIM(0): Update GigabitEthernet0/0/172.16.24.4 to (*, 224.0.1.40), Forward
PIM *G Join
R2#
PIM(0): Building Periodic Join/Prune message for 224.0.1.40
R2#
PIM(0): Received v2 Join/Prune on GigabitEthernet0/1 from 172.16.26.6, to
PIM(0): Join-list: (*, 224.0.1.40), RPT-bit set, WC-bit set, S-bit set
PIM(0): Update GigabitEthernet0/1/172.16.26.6 to (*, 224.0.1.40), Forward
PIM *G Join
R2#
PIM(0): Received v2 Join/Prune on GigabitEthernet0/0 from 172.16.24.4, to
PIM(0): Join-list: (*, 224.0.1.40), RPT-bit set, WC-bit set, S-bit set
PIM(0): Update GigabitEthernet0/0/172.16.24.4 to (*, 224.0.1.40), Forward
PIM *G Join
R2#
PIM(0): Building Periodic Join/Prune message for 224.0.1.40
R2#
PIM(0): Received v2 Join/Prune on GigabitEthernet0/1 from 172.16.26.6, to
PIM(0): Join-list: (*, 224.0.1.40), RPT-bit set, WC-bit set, S-bit set
PIM(0): Update GigabitEthernet0/1/172.16.26.6 to (*, 224.0.1.40), Forward
PIM *G Join
us
state, by
us
state, by
us
state, by
us
state, by
us
state, by
6-29
Trouble
Ticket
#1
Your
supervisor
has
been
experimenting
to
deploy
BIDIR-PIM
on
the
network
in
Figure
3-6.
During
testing
over
the
weekend
he
discovered
that
when
hosts
on
the
VLAN79
segment
between
R7
and
R9
join
multicast
groups,
these
group
memberships
are
not
propagated
to
the
RP.
You
have
been
instructed
to
use
the
multicast
address
224.9.9.9
on
R9
to
isolate
the
problem.
Once
the
fault
has
been
found
correct
this
issue.
Trouble
Ticket
#2
After
solving
Trouble
Ticket
#1,
your
supervisor
while
doing
more
testing
has
observed
that
multicast
sources
generated
by
R1
never
reach
the
RP.
You
have
been
instructed
to
use
the
group
224.9.9.9
on
R1
to
isolate
this
issue.
Once
the
fault
has
been
isolated
correct
the
issue.
6-30
Chapter
Challenge:
PIM-DM
Sample
Trouble
Tickets
Solutions
The
following
section
includes
the
solutions
to
the
two
Trouble
Tickets
presented
in
the
previous
section.
Trouble
Ticket
#1
Solution
Your
supervisor
has
been
experimenting
to
deploy
BIDIR-PIM
on
the
network
in
Figure
3-6.
During
testing
over
the
weekend
he
discovered
that
when
hosts
on
the
VLAN79
segment
between
R7
and
R9
join
multicast
groups,
these
group
memberships
are
not
propagated
to
the
RP.
You
have
been
instructed
to
use
the
multicast
address
224.9.9.9
on
R9
to
isolate
the
problem.
Once
the
fault
has
been
found
correct
this
issue.
Step
1
-
Fault
Verification:
Does
R2
create
the
(*,
224.9.9.9)
entry
in
its
multicast
routing
table?
R2#show ip mroute 224.9.9.9
Group 224.9.9.9 not found
The
*,G
pair
is
not
created.
This
verifies
that
the
problem
actually
exists.
Step
2
-
Fault
Isolation:
The
next
course
of
action
is
to
use
the
show
ip
mroute
command
to
see
where
the
(*,G)
entry
appears.
R6#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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.0.1.40), 00:13:45/00:02:31, RP 192.1.2.255, flags: SJPL
Incoming interface: FastEthernet0/1, RPF nbr 172.16.26.2
Outgoing interface list: Null
6-31
The
verification
clearly
demonstrates
that
R6
is
not
using
BIDIR-PIM
to
communicate
with
the
RP.
Observe
that
there
is
an
Incoming
interface
lists
in
the
output.
This
can
be
verified
with
show
ip
pim
rp
mapping,
we
see
there
is
no
Bidir
Mode
after
the
Static:
R6#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s): 224.0.0.0/4, Static
RP: 192.1.2.255 (?)
Step
4
-
Verification
of
Remediation
Once
the
error
has
been
isolated
and
remediated
it
is
highly
recommended
to
verify
that
the
Trouble
Ticket
has
been
repaired
using
the
same
method
of
the
initial
fault
verification.
R2#show ip mroute 224.9.9.9
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.9.9.9), 00:00:18/00:03:11, RP 192.1.2.255, flags: B
Bidir-Upstream: Loopback0, RPF nbr 192.1.2.255
Outgoing interface list:
GigabitEthernet0/1, Forward/Sparse, 00:00:18/00:03:11
Loopback0, Bidir-Upstream/Sparse, 00:00:18/00:00:00
The
issue
has
been
corrected.
6-32
The
ping
test
to
the
multicast
group
224.9.9.9
fails.
This
verifies
that
the
problem
actually
exists.
Step
2
-
Fault
Isolation:
The
next
course
of
action
is
to
use
the
show
ip
mroute
command
to
see
where
the
(*,G)
entry
appears
or
to
observe
the
nature
of
the
multicast
routing
table.
R5#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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.9.9.9), 00:00:23/00:02:36, RP 0.0.0.0, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
(*, 224.0.1.40), 00:32:52/00:02:09, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:32:52/00:02:09
6-33
The
verification
clearly
demonstrates
that
R6
is
not
using
BIDIR-PIM
to
communicate
with
the
RP.
Observe
that
there
is
an
Incoming
interface
list
in
the
output.
This
can
be
verified
with
show
ip
pim
rp
mapping:
R5#show ip pim rp mapping
PIM Group-to-RP Mappings
Observe
that
the
output
indicates
there
is
no
RP
for
any
multicast
groups.
This
isolates
our
problem.
Step
3
-
Fault
Remediation:
In
this
scenario,
the
ip
pim
bidir-enable
and
ip
pim
rp-address
command
needs
to
be
applied
to
R5:
R5#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R5(config)#ip pim bidir-enable
R5(config)#ip pim rp-address 192.1.2.255 bidir
R5(config)#end
Step
4
-
Verification
of
Remediation
Once
the
error
has
been
isolated
and
remediated,
it
is
highly
recommended
to
verify
that
the
Trouble
Ticket
has
been
repaired
using
the
same
method
used
to
verify
the
fault
initially:
R1#ping 224.9.9.9 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 224.9.9.9, timeout is 2 seconds:
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
to
to
to
to
to
to
to
to
to
to
request
request
request
request
request
request
request
request
request
request
0
1
2
3
4
5
6
7
8
9
from
from
from
from
from
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
32
28
28
28
28
28
28
28
28
28
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
The
issue
has
been
corrected.
6-34
Chapter
7:
Static
Rendezvous
Points
(RPs)
In
this
chapter
of
IPv4/6
Multicast
Operation
and
Troubleshooting,
the
processes
and
the
functionality
of
static
Rendezvous
Points
(RPs)
are
examined
in
great
depth.
Once
the
operational
characteristics
of
static
RPs
are
detailed
completely,
the
focus
becomes
that
of
troubleshooting.
This
includes
the
careful
examination
of
symptoms,
a
fault
isolation
methodology,
and
the
implementation
of
repairs
for
static
RP
assignments.
The
chapter
begins
with
a
thorough
review
of
static
RP
assignment,
and
then
quickly
launches
in
to
an
exhaustive
analysis
of
the
art
of
troubleshooting.
This
important
chapter
concludes
with
sample
troubleshooting
scenarios,
reference
materials
for
the
most
important
show
and
debug
commands,
and
exciting
challenges
that
allow
readers
to
practice
implementing
the
troubleshooting
skills
they
have
obtained.
7-1
vrf
optional;
specifies
that
the
static
group-to-RP
mapping
be
associated
with
the
Multicast
Virtual
Private
Network
VRF
instance
listed
rp-address
the
IP
address
of
the
RP
to
be
used
for
the
static
group-to-RP
mapping
access-list
optional;
the
standard
access
list
that
defines
the
multicast
groups
to
be
statically
mapped
to
the
RP;
if
no
access
list
is
defined,
the
RP
will
map
to
all
multicast
groups,
224/4
override
optional;
specifies
that
if
dynamic
and
static
group-to-RP
mappings
are
used
together
and
there
is
an
RP
address
conflict,
the
RP
address
configured
for
a
static
group-to-RP
mapping
will
take
precedence
bidir
optional;
specifies
that
the
static
group-to-RP
mapping
be
applied
to
a
bidirectional
PIM
RP;
Chapter
6:
Bidirectional
Protocol
Independent
Multicast
(BIDIR-PIM)
details
bidirectional
PIM
in
detail
7-2
In
this
topology,
R4
will
perform
the
duties
of
RP
for
the
multicast
groups
ranging
from
224.0.0.1
to
231.255.255.255,
and
R6
will
be
the
RP
for
the
groups
ranging
from
232.0.0.1
to
239.255.255.255.
In
a
working
environment,
we
can
see
how
this
is
configured
by
looking
at
the
commands
used
on
any
single
device:
R2#show run | inc access-list | rp-address
ip pim rp-address 192.1.4.4 1
ip pim rp-address 192.1.6.6 2
access-list 1 permit 224.0.0.0 7.255.255.255
7-3
In
this
situation
we
see
that
any
groups
matching
the
standard
access-list
1
will
be
mapped
to
R4's
loopback0
interface,
and
that
any
matching
standard
access-list
2
will
be
mapped
to
R6.
These
define
the
group-to-RP
mappings
we
have
been
discussing.
The
nature
of
these
mappings
can
be
viewed
on
all
devices
in
the
topology
with
show
ip
pim
rp
mapping:
R1#show ip pim rp mapping
PIM Group-to-RP Mappings
Acl: 1,
RP:
Acl: 2,
RP:
Static
192.1.4.4 (?)
Static
192.1.6.6 (?)
We
see
that
R1
has
two
mappings
defined
by
ACL1
and
ACL2.
We
can
see
what
each
ACL
matches
by
using
show
ip
access-list:
R1#show ip access-list
Standard IP access list 1
10 permit 224.0.0.0, wildcard bits 7.255.255.255
Standard IP access list 2
10 permit 232.0.0.0, wildcard bits 7.255.255.255
This
means
that
R1
will
use
R4
as
the
RP
for
all
groups
matched
by
the
standard
access-list
1.
This
can
be
tested
using
mtrace:
R1#mtrace 172.16.15.1 172.16.79.9 224.1.1.1
Type escape sequence to abort.
Mtrace from 172.16.15.1 to 172.16.79.9 via group 224.1.1.1
From source (?) to destination (?)
Querying full reverse path... * switching to hop-by-hop:
0 172.16.79.9
-1 * 172.16.79.9 PIM [172.16.15.0/24]
-2 * 172.16.79.7 PIM [172.16.15.0/24]
-3 * 172.16.67.6 PIM [172.16.15.0/24]
-4 * 172.16.46.4 PIM Reached RP/Core [172.16.15.0/24]
-5 * 172.16.45.5 PIM Prune sent upstream [172.16.15.0/24]
-6 * 172.16.15.1 PIM [172.16.15.0/24]
By
specifying
the
group
address
for
224.1.1.1
we
know
that
based
on
the
access-lists
available
that
R4
will
chose
as
the
RP
for
this
group.
We
can
repeat
this
test
using
the
group
231.255.255.255.
This
group
represents
the
highest
address
in
the
range
matched
by
ACL1.
Thus,
this
group
should
use
R4
as
the
RP.
7-4
The
multicast
stream
for
232.0.0.1
matches
ACL2
so
the
RP
for
this
group
becomes
R6
as
specified
by
the
"Reached
RP/Core"
entry
in
the
mtrace
output.
From
a
troubleshooting
point
of
view,
what
would
happen
if
the
Loopback0
interface
of
R6
goes
down?
Will
232.0.0.1
be
forwarded
using
R4
rather
than
R6?
R6(config)#interface Loopback0
R6(config-if)#shut
R6(config-if)#end
7-5
-2
-3
-4
-5
*
*
*
*
172.16.79.7
172.16.67.6
172.16.46.4
172.16.45.5
PIM
PIM
PIM
PIM
[172.16.15.0/24]
[172.16.15.0/24]
[172.16.15.0/24]
[172.16.15.0/24]
This
output
may
seem
confusing
at
first,
but
it
is
important
to
look
carefully.
The
mtrace
utility
verifies
the
multicast
path
hop-by-hop.
The
most
important
part
of
the
is
output
is
what
we
do
not
see.
Observe
that
there
are
no
entries
for
a
"RP/Core".
This
tells
us
that
R4
does
not
take
over
as
the
RP
for
this
group.
This
can
be
tested
by
having
R9
join
the
group
232.0.0.1:
R9(config)#interface FastEthernet0/1
R9(config-if)#ip igmp join-group 232.0.0.1
R9(config-if)#end
Observe
the
test
fails.
This
is
because
there
is
no
RP
mapped
to
the
group
232.0.0.1.
7-6
7-7
In
the
Common
Issues
with
Static
RP
section,
two
primary
types
of
problems
were
identified:
Incorrect
RP
Assignment
or
ACL
Issues.
This
section
explores
these
two
categories
of
failure,
by
directing
our
attention
to
the
commands
necessary
to
verify
a
problem,
isolate
it
and
remediate
it.
Incorrect
RP
Assignment
Setting
the
stage:
R9
will
join
the
multicast
group
224.9.9.9.
R9(config)#interface FastEthernet0/1
R9(config-if)#ip igmp join-group 224.9.9.9
R9(config-if)#end
Emulating
a
multicast
feed:
Can
R1
successfully
source
a
multicast
stream
from
172.16.15.1
to
the
group
224.9.9.9?
By
generating
a
ping
on
R1
to
the
group
224.9.9.9
R1
can
emulate
a
multicast
feed:
R1#ping 224.9.9.9 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 224.9.9.9, timeout is 2 seconds:
7-8
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
to
to
to
to
to
to
to
to
to
to
request
request
request
request
request
request
request
request
request
request
0
1
2
3
4
5
6
7
8
9
from
from
from
from
from
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
56
56
56
56
56
56
56
68
56
56
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
The
output
from
the
ping
command
is
successful,
what
if
we
ping
another
address.
This
time
we
will
use
239.9.9.9
in
the
second
multicast
range.
R1#ping 239.9.9.9 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 239.9.9.9, timeout is 2 seconds:
..........
Look
to
see
what
RP
has
been
assigned
for
the
group
239.9.9.9
on
all
devices
in
the
topology.
Keep
in
mind
that
the
group
239.9.9.9
should
use
R6:
R5#show ip pim rp 239.9.9.9
Group: 239.9.9.9, RP: 192.1.5.5, next RP-reachable in 00:00:36
This
output
indicates
that
R5
is
being
used
as
the
RP
for
the
group
rather
than
R6.
This
means
that
the
incorrect
address
was
used
on
R5
for
the
second
RP
address.
This
can
be
confirmed
with
show
run:
R5#show run | inc rp-address
ip pim rp-address 192.1.4.4 1
ip pim rp-address 192.1.5.5 2
7-9
R5#conf t
Enter configuration commands, one per line.
R5(config)#no ip pim rp-address 192.1.5.5 2
R5(config)#ip pim rp-address 192.1.6.6 2
R5(config)#end
Verify
that
the
correction
has
worked
by
repeating
the
multicast
ping
test
from
R1:
R1#ping 239.9.9.9 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 239.9.9.9, timeout is 2 seconds:
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
to
to
to
to
to
to
to
to
to
to
to
request
request
request
request
request
request
request
request
request
request
request
0
1
1
2
3
4
5
6
7
8
9
from
from
from
from
from
from
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
68
64
80
76
56
56
56
56
56
56
56
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
ACL
Issue
Setting
the
stage:
R9
will
join
the
multicast
group
224.9.9.9.
R9(config)#interface FastEthernet0/1
R9(config-if)#ip igmp join-group 224.9.9.9
R9(config-if)#end
Emulating
a
multicast
feed:
Can
R1
successfully
source
a
multicast
stream
from
172.16.15.1
to
the
group
224.9.9.9?
By
generating
a
ping
on
R1
to
the
group
224.9.9.9
R1
can
emulate
a
multicast
feed:
R1#ping 224.9.9.9 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 224.9.9.9, timeout is 2 seconds:
..........
The
output
from
the
ping
command
is
unsuccessful,
what
if
we
ping
another
address.
This
time
we
will
use
239.9.9.9
in
the
second
multicast
range.
R1#ping 239.9.9.9 repeat 10
7-10
to
to
to
to
to
to
to
to
to
to
request
request
request
request
request
request
request
request
request
request
0
1
2
3
4
5
6
7
8
9
from
from
from
from
from
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
56
56
56
56
56
56
56
56
56
56
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
Now
we
will
verify
the
identity
of
the
RP
elected
for
224.9.9.9
on
all
devices.
Remember
that
R4
should
be
selected
for
this
group
up
to
the
RP.
R5#show ip pim rp 224.9.9.9
Group: 224.9.9.9, RP: 192.1.4.4, v2, uptime 00:05:41, expires never
R4#show ip pim rp 224.9.9.9
Group: 224.9.9.9, RP: 192.1.6.6, uptime 00:45:31, expires never
Of
the
routers
between
R1
and
R4,
it
is
clear
that
R4
is
not
in
agreement
with
the
rest
of
the
network,
because
it
identifies
the
RP
as
192.1.6.6
rather
than
192.1.4.4.
R4
is
making
the
incorrect
decision
regarding
the
RP.
The
question
is
why?
R4#sh ip pim rp mapping
PIM Group-to-RP Mappings
Acl: 1, Static
RP: 192.1.4.4 (?)
Group(s): 224.0.0.0/4, Static
RP: 192.1.6.6 (?)
7-11
We
see
that
we
have
an
ACL
applied
to
the
first
static
entry,
but
there
is
no
ACL
assigned
to
the
second.
Observe
that
the
second
group-to-RP
mapping
is
for
the
entire
224.0.0.0/4
range.
This
means
that
on
R4
there
is
an
overlap
between
the
static
assignments.
In
instances
like
this
when
static
RP
is
used
and
a
single
group
has
been
erroneously
assigned
to
more
than
one
RP,
the
RP
with
the
highest
IP
address
will
assume
the
role
of
RP.
This
can
be
corrected
by
applying
the
standard
access-list
2
to
the
second
ip
pim
rp-address
statement:
R4#conf t
Enter configuration commands, one per line.
R4(config)#no ip pim rp-address 192.1.6.6
R4(config)#ip pim rp-address 192.1.6.6 2
R4(config)#end
to
to
to
to
to
to
to
to
to
to
request
request
request
request
request
request
request
request
request
request
0
1
2
3
4
5
6
7
8
9
from
from
from
from
from
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
60
56
56
56
56
56
56
56
56
56
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
7-12
show
COMMAND:
show
ip
igmp
membership
[group-address
|
group-name]
[tracked]
[all]
This
command
displays
Internet
Group
Management
Protocol
(IGMP)
membership
information
for
multicast
groups
and
(S,
G)
channels.
Where:
EXAMPLE
OUTPUT:
R9#show ip igmp membership
Flags: A - aggregate, T - tracked
L - Local, S - static, V - virtual, R - Reported through v3
I - v3lite, U - Urd, M - SSM (S,G) channel
1,2,3 - The version of IGMP the group is in
Channel/Group-Flags:
/ - Filtering entry (Exclude mode (S,G), Include mode (*,G))
Reporter:
<mac-or-ip-address> - last reporter if group is not explicitly tracked
<n>/<m>
- <n> reporter in include mode, <m> reporter in exclude
7-13
Channel/Group
*,224.9.9.9
*,239.9.9.9
*,224.0.1.40
R9#
Reporter
172.16.79.9
172.16.79.9
172.16.79.9
Uptime
00:09:54
00:09:54
00:09:54
Exp.
02:23
02:23
02:23
Flags
2LA
2LA
2LA
Interface
Fa0/1
Fa0/1
Fa0/1
show
COMMAND:
show
ip
mroute
This
command
displays
the
contents
of
the
multicast
routing
(mroute)
table.
EXAMPLE
OUTPUT:
R7#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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.9.9.9), 00:01:41/00:03:06, RP 192.1.2.2, flags: SJC
Incoming interface: FastEthernet0/0, RPF nbr 172.16.67.6
Outgoing interface list:
FastEthernet0/1, Forward/Sparse, 00:01:24/00:03:06
(*, 239.9.9.9), 00:01:41/stopped, RP 192.1.2.2, flags: SJC
Incoming interface: FastEthernet0/0, RPF nbr 172.16.67.6
Outgoing interface list:
FastEthernet0/1, Forward/Sparse, 00:01:24/00:03:05
(172.16.15.1, 239.9.9.9), 00:00:18/00:02:43, flags: JT
Incoming interface: FastEthernet0/0, RPF nbr 172.16.67.6
Outgoing interface list:
FastEthernet0/1, Forward/Sparse, 00:00:18/00:02:41
(*, 224.0.1.40), 00:02:17/00:03:04, RP 192.1.2.2, flags: SJCL
Incoming interface: FastEthernet0/0, RPF nbr 172.16.67.6
Outgoing interface list:
FastEthernet0/1, Forward/Sparse, 00:01:25/00:03:04
Loopback0, Forward/Sparse, 00:02:18/00:02:19
7-14
R7#
show
COMMAND:
show
ip
pim
interface
This
command
displays
information
about
interfaces
configured
for
Protocol
Independent
Multicast
(PIM).
EXAMPLE
OUTPUT:
R7#show ip pim interface
Address
Interface
192.1.7.7
172.16.67.7
172.16.79.7
R7#
Loopback0
FastEthernet0/0
FastEthernet0/1
Ver/
Mode
v2/S
v2/S
v2/S
Nbr
Count
0
1
1
Query
Intvl
30
30
30
DR
Prior
1
1
1
DR
192.1.7.7
172.16.67.7
172.16.79.9
show
COMMAND:
show
ip
pim
rp
mapping
This
command
displays
information
about
Protocol
Independent
Multicast
(PIM)
RP
mappings.
EXAMPLE
OUTPUT:
R7#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s): 224.0.0.0/4, Static
RP: 192.1.2.2 (?)
R7#
show
COMMAND:
show
ip
pim
[vrf
vrf-name]
neighbor
[interface-type
interface-number]
This
command
displays
information
about
Protocol
Independent
Multicast
(PIM)
neighbors
discovered
by
PIM
version
1
router
query
messages
or
PIM
version
2
hello
messages.
Where:
7-15
EXAMPLE
OUTPUT:
R7#show ip pim neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default
S - State Refresh Capable
Neighbor
Interface
Uptime/Expires
Address
172.16.67.6
FastEthernet0/0
00:11:57/00:01:38
172.16.79.9
FastEthernet0/1
00:11:57/00:01:35
R7#
DR Priority,
Ver
v2
v2
DR
Prio/Mode
1 / S
1 / DR S
show
COMMAND:
show
ip
rpf
[vrf
vrf-name]
{route-distinguisher
|
source-address
[group-address]
[rd
route-
distinguisher]}
[metric]
This
command
displays
information
that
IP
multicast
routing
uses
to
perform
the
Reverse
Path
Forwarding
(RPF)
check
for
a
multicast
source
Where:
EXAMPLE
OUTPUT:
R7#show ip rpf 192.1.2.2
RPF information for ? (192.1.2.2)
RPF interface: FastEthernet0/0
RPF neighbor: ? (172.16.67.6)
RPF route/mask: 192.1.2.0/24
RPF type: unicast (eigrp 100)
RPF recursion count: 0
Doing distance-preferred lookups across tables
R7#
7-16
debug
COMMAND:
debug
ip
mpacket
[vrf
vrf-name]
[detail
|
fastswitch]
[access-list]
[group]
This
command
displays
multicast
packets
that
are
received
and
sent
on
the
device.
Where:
EXAMPLE
OUTPUT:
IP(0): s=172.16.26.6 (FastEthernet0/1) d=239.9.9.9 (FastEthernet0/0) id=1, ttl=254,
prot=1, len=100(100), mforward
debug
COMMAND:
debug
ip
pim
[vrf
vrf-name]
[bsr]
This
command
displays
Protocol
Independent
Multicast
(PIM)
packets
received
and
sent
and
displays
PIM-related
events
7-17
Where:
EXAMPLE
OUTPUT:
R7#
PIM(0): Received v2 Join/Prune on FastEthernet0/1 from 172.16.79.9, to us
PIM(0): Join-list: (172.16.15.1/32, 239.9.9.9), S-bit set
PIM(0): Update FastEthernet0/1/172.16.79.9 to (172.16.15.1, 239.9.9.9), Forward state,
by PIM SG Join
R7#
PIM(0): Received v2 Join/Prune on FastEthernet0/1 from 172.16.79.9, to us
PIM(0): Join-list: (*, 239.9.9.9), RPT-bit set, WC-bit set, S-bit set
PIM(0): Update FastEthernet0/1/172.16.79.9 to (*, 239.9.9.9), Forward state, by PIM *G
Join
PIM(0): Update FastEthernet0/1/172.16.79.9 to (172.16.15.1, 239.9.9.9), Forward state,
by PIM *G Join
R7#
PIM(0): Received v2 Join/Prune on FastEthernet0/1 from 172.16.79.9, to us
PIM(0): Join-list: (*, 224.0.1.40), RPT-bit set, WC-bit set, S-bit set
PIM(0): Update FastEthernet0/1/172.16.79.9 to (*, 224.0.1.40), Forward state, by PIM
*G Join
R7#
PIM(0): Received v2 Join/Prune on FastEthernet0/1 from 172.16.79.9, to us
PIM(0): Join-list: (*, 224.9.9.9), RPT-bit set, WC-bit set, S-bit set
PIM(0): Update FastEthernet0/1/172.16.79.9 to (*, 224.9.9.9), Forward state, by PIM *G
Join
R7#
PIM(0): Insert (172.16.15.1,239.9.9.9) join in nbr 172.16.67.6's queue
PIM(0): Building Join/Prune packet for nbr 172.16.67.6
PIM(0): Adding v2 (172.16.15.1/32, 239.9.9.9), S-bit Join
PIM(0): Send v2 join/prune to 172.16.67.6 (FastEthernet0/0)
PIM(0): Received v2 Join/Prune on FastEthernet0/1 from 172.16.79.9, to us
PIM(0): Join-list: (172.16.15.1/32, 239.9.9.9), S-bit set
PIM(0): Update FastEthernet0/1/172.16.79.9 to (172.16.15.1, 239.9.9.9), Forward state,
by PIM SG Join
R7#
PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 224.0.1.40
PIM(0): Insert (*,224.0.1.40) join in nbr 172.16.67.6's queue
PIM(0): Building Join/Prune packet for nbr 172.16.67.6
PIM(0): Adding v2 (192.1.2.2/32, 224.0.1.40), WC-bit, RPT-bit, S-bit Join
PIM(0): Send v2 join/prune to 172.16.67.6 (FastEthernet0/0)
R7#
7-18
Trouble
Ticket
#1
Your
supervisor
has
informed
you
that
multicast
traffic
sourced
from
the
VLAN15
segment
to
the
group
224.9.9.9
never
reach
the
PIM-SM
RP.
There
are
two
RPs
in
this
topology;
R4
for
the
multicast
range
224.0.0.1
-
231.255.255.255,
and
R6
for
the
range
232.0.0.1
-
239.255.255.255.
You
have
been
instructed
to
use
the
multicast
group
224.9.9.9
to
isolate
this
issue.
You
must
correct
the
problem.
7-19
The
ping
test
to
the
multicast
group
224.9.9.9
fails.
The
next
question
is,
"does
R4
create
a
S,G
entry
for
224.9.9.9?"
R4#show ip mroute 224.9.9.9
Group 224.9.9.9 not found
There
is
no
S,G
entry.
This
verifies
that
the
problem
actually
exists.
Step
2
-
Fault
Isolation:
The
next
course
of
action
is
to
use
show
ip
pim
rp
on
all
devices
between
R1
and
R4.
R5#show ip pim rp 224.9.9.9
Group: 224.9.9.9, RP: 192.1.4.5, uptime 00:00:54, expires never
The
verification
clearly
demonstrates
that
R5
is
not
using
the
correct
IP
address
from
the
RP.
This
can
be
verified
using
show
run
on
R5:
R5#show run | inc access-list | rp-address
7-20
The
first
ip
pim
rp-address
command
is
not
using
the
correct
ip
address.
This
has
unquestionably
isolated
our
fault.
Step
3
-
Fault
Remediation:
In
this
scenario,
the
ip
pim
rp-address
command
will
need
to
be
corrected.
R5#conf t
Enter configuration commands, one per line.
R5(config)#no ip pim rp-address 192.1.4.5 1
R5(config)#ip pim rp-address 192.1.4.4 1
R5(config)#end
Step
4
-
Verification
of
Remediation
Once
the
error
has
been
isolated
and
remediated
it
is
highly
recommended
to
verify
that
the
Trouble
Ticket
has
been
repaired
using
the
same
method
of
the
initial
fault
verification.
Ensure
that
the
ping
is
still
running
on
R1
and
verify
if
the
S,G
entry
is
now
created:
R4#show ip mroute 224.9.9.9
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.9.9.9), 00:01:03/stopped, RP 192.1.4.4, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
(172.16.15.1, 224.9.9.9), 00:01:03/00:01:56, flags: P
Incoming interface: FastEthernet0/1, RPF nbr 172.16.45.5
Outgoing interface list: Null
The S,G entry has been created. The issue has been corrected.
7-21
Chapter 8: AutoRP
Chapter
8:
AutoRP
In
this
chapter
of
IPv4/6
Multicast
Operation
and
Troubleshooting,
the
processes
and
the
functionality
of
the
AutoRP
protocol
are
examined
in
great
depth.
Once
the
operational
characteristics
of
this
important
protocol
are
detailed
completely,
the
focus
becomes
that
of
troubleshooting.
This
includes
the
careful
examination
of
symptoms,
a
fault
isolation
methodology,
and
the
implementation
of
repairs
for
the
AutoRP
protocol.
The
chapter
begins
with
a
thorough
review
of
AutoRP,
and
then
quickly
launches
in
to
an
exhaustive
analysis
of
the
art
of
troubleshooting
this
multicast
support
protocol.
This
important
chapter
concludes
with
sample
troubleshooting
scenarios,
reference
materials
for
the
most
important
show
and
debug
commands,
and
exciting
challenges
that
allow
readers
to
practice
implementing
the
troubleshooting
skills
they
have
obtained.
8-1
Chapter 8: AutoRP
8-2
Chapter 8: AutoRP
bidir
specifies
the
groups
are
to
function
as
bidirectional;
bidirectional
PIM
is
detailed
in
Chapter
6:
Bidirectional
Protocol
Independent
Multicast
(BIDIR-PIM)
8-3
Chapter 8: AutoRP
In
this
network
R2
will
be
the
Auto-RP
Mapping
Agent
(covered
later
in
this
chapter)
and
both
R4
and
R6
will
be
configured
to
be
C-RPs
which
we
will
concern
ourselves
with
in
this
section.
As
mentioned
in
the
Technology
Overview
C-RPs
are
configured
by
using
the
ip
pim
send-rp-announce
command.
We
will
configure
R4
and
R6
using
this
command.
Once
we
do
this,
we
will
monitor
their
behavior.
To
accomplish
this
we
will
use
debug
ip
packet
on
both
R4
and
R6:
R4(config)#access-list 101 deny eigrp any any
8-4
Chapter 8: AutoRP
Now
we
will
enable
ip
pim
send-rp-announce
on
R4:
R4(config)#interface Loopback0
R4(config-if)#ip pim sparse-dense-mode
%PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 192.1.4.4 on interface Loopback0
R4(config-if)#exit
R4(config)#ip pim send-rp-announce loopback 0 scope 16
R4(config)#end
Immediately
after
the
command
is
applied
this
C-RP
tries
to
notify
the
Auto-RP
Mapping
Agent
that
is
has
been
configured
as
a
C-RP.
IP: s=192.1.4.4 (Null0),
broad/multicast
UDP src=496, dst=496
IP: s=192.1.4.4 (Null0),
broad/multicast
UDP src=496, dst=496
IP: s=192.1.4.4 (Null0),
UDP src=496, dst=496
IP: s=192.1.4.4 (local),
UDP src=496, dst=496
Observe
that
the
packets
now
generated
on
R4
are
sourced
from
the
Loopback0
address
and
destined
to
the
multicast
group
224.0.1.39.
The
role-based
behavior
of
a
C-RP
is
to
send
information
to
the
MA.
What
information
does
a
C-RP
send
when
it
is
configured
to
operate
in
Auto-RP?
We
can
find
out
with
debug
ip
pim
auto-rp:
R4#debug ip
PIM Auto-RP
R4#
Auto-RP(0):
Auto-RP(0):
Auto-RP(0):
Auto-RP(0):
Auto-RP(0):
Auto-RP(0):
pim auto-rp
debugging is on
Build RP-Announce for 192.1.4.4, PIMv2/v1, ttl 16, ht 181
Build announce entry for (224.0.0.0/4)
Send RP-Announce packet of length 48 on FastEthernet0/0
Send RP-Announce packet of length 48 on FastEthernet0/1
Send RP-Announce packet of length 48 on Serial0/0/0.1
Send RP-Announce packet of length 48 on Loopback0(*)
Observe
that
the
RP-announce
messages
for
192.1.4.4
are
being
sent
out
all
PIM-S-DM
enabled
interfaces,
and
the
messages
state
that
R4
is
configured
to
offer
RP
services
for
the
entire
multicast
8-5
Chapter 8: AutoRP
range
(224.0.0.0/4).
Before
we
enable
R6
to
act
as
a
C-RP
in
this
topology
we
need
to
look
at
the
multicast
routing
table
of
R2,
R6,
R7
and
R9:
R2#show ip mroute 224.0.1.39
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.0.1.39), 00:25:55/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet0/1, Forward/Sparse-Dense, 00:25:55/00:00:00
GigabitEthernet0/0, Forward/Sparse-Dense, 00:25:55/00:00:00
(192.1.4.4, 224.0.1.39), 00:01:03/00:02:05, flags: PT
Incoming interface: FastEthernet0/0, RPF nbr 172.16.24.4
Outgoing interface list:
GigabitEthernet0/1, Prune/Sparse-Dense, 00:01:04/00:01:55
R2
is
actually
routing
this
multicast
traffic.
It
is
being
sent
to
R6
via
GigabitEthernet0/1.
R6
will
also
route
this
multicast
traffic:
R6#show ip mroute 224.0.1.39
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.0.1.39), 00:26:20/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial0/1/0.1, Forward/Sparse-Dense, 00:26:20/00:00:00
GigabitEthernet0/1, Forward/Sparse-Dense, 00:26:20/00:00:00
8-6
Chapter 8: AutoRP
R6
is
routing
the
traffic
to
R7
via
FastEthernet0/0
and
R4
via
Serial0/1/0.1.
On
R7
we
see
that
it
to
routes
the
traffic.
R7#show ip mroute 224.0.1.39
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.0.1.39), 00:26:36/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/1, Forward/Sparse-Dense, 00:26:36/00:00:00
FastEthernet0/0, Forward/Sparse-Dense, 00:26:36/00:00:00
(192.1.4.4, 224.0.1.39), 00:01:45/00:01:23, flags: PT
Incoming interface: FastEthernet0/0, RPF nbr 172.16.67.6
Outgoing interface list:
FastEthernet0/1, Prune/Sparse-Dense, 00:01:46/00:01:16
8-7
Chapter 8: AutoRP
What
this
process
illustrates
is
how
the
multicast
traffic
destined
to
the
group
224.0.1.39
is
being
actually
routed
throughout
the
multicast
domain
in
order
to
reach
the
Auto-RP
MA.
Currently,
in
this
topology
R2
is
not
the
MA.
We
will
get
to
that
part
after
both
R4
and
R6
have
been
configured
to
be
C-
RPs
R6#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R6(config)#ip pim send-rp-announce loopback 0 scope 16
R6(config)#end
Again
to
drive
home
the
point
that
this
traffic
is
being
multicast
routed
we
will
look
at
the
multicast
routing
table
on
R2:
R2#show ip mroute 224.0.1.39
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.0.1.39), 00:35:49/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet0/1, Forward/Sparse-Dense, 00:35:49/00:00:00
GigabitEthernet0/0, Forward/Sparse-Dense, 00:35:49/00:00:00
(192.1.6.6, 224.0.1.39), 00:00:39/00:02:21, flags: PT
Incoming interface: GigabitEthernet0/1, RPF nbr 172.16.26.6
Outgoing interface list:
GigabitEthernet0/0, Prune/Sparse-Dense, 00:00:40/00:02:19
8-8
Chapter 8: AutoRP
Note
now
that
there
is
a
(S,G)
entry
for
the
group
224.0.1.39.
Mapping
Agent
Assignment
and
Placement
As
currently
configured,
the
topology
has
no
MA.
This
means
multicast
packets
are
being
forwarded
throughout
the
domain
each
time
the
C-RPs
send
an
RP
announcement
message.
We
will
now
configure
R2
to
assume
the
role
of
Mapping
Agent.
Before
doing
so
we
will
enable
debug
ip
pim
auto-rp:
R2#debug ip pim auto-rp
PIM Auto-RP debugging is on
R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#ip pim send-rp-discovery loopback 0 scope 16
R2(config)#end
Observe
that
R2
is
now
receiving
the
individual
RP-announcement
packets
from
both
R4
and
R6.
The
last
portion
of
the
screen
capture
illustrates
that
the
Mapping
Agent
builds
an
RP-Discovery
Packet
that
defines
the
group-to-RP
mapping
for
use
by
all
devices
in
the
multicast
topology.
Here
R4
and
R6
are
both
announcing
their
candidacy
to
be
the
RP
for
the
range
224.0.0.0/4.
R6
is
elected
by
the
MA
because
it
has
the
highest
IP
address.
We
can
demonstrate
this
by
changing
the
IP
address
used
on
R4
to
a
higher
value
than
that
used
on
R6:
8-9
Chapter 8: AutoRP
R4(config)#interface Loopback0
R4(config-if)#ip address 192.1.44.44 255.255.255.0
R4(config-if)#end
Now
we
will
see
that
the
MA
will
elect
to
use
R4
rather
than
R6
because
of
the
higher
IP
address:
R2#
Auto-RP(0): Build RP-Discovery packet
Auto-RP: Build mapping (224.0.0.0/4, RP:192.1.44.44), PIMv2 v1,
Auto-RP(0): Send RP-discovery packet of length 48 on GigabitEthernet0/0 (1 RP entries)
Auto-RP(0): Send RP-discovery packet of length 48 on GigabitEthernet0/1 (1 RP entries)
Auto-RP(0): Send RP-discovery packet of length 48 on Loopback0(*) (1 RP entries)
This
process
is
very
simple
to
see.
Now
we
need
to
look
at
the
traffic
leaving
R2
for
the
rest
of
the
network.
What
IP
address
is
it
using?
R2(config)#access-list 101 deny eigrp any any
R2(config)#access-list 101 permit ip any host 224.0.1.39
R2(config)#access-list 101 permit ip any host 224.0.1.40
R2(config)#end
R2#
%SYS-5-CONFIG_I: Configured from console by console
R2#debug ip packet detail 101
IP packet debugging is on (detailed) for access list 101
They
are
destined
to
the
multicast
address
224.0.1.40.
Again
this
group
is
going
to
be
multicast
forwarded
throughout
the
multicast
domain
in
order
to
allow
all
multicast
speakers
to
learn
the
identity
of
the
elected
RP
from
the
MA.
All
routers
running
current
version
of
Cisco
IOS
automatically
join
the
multicast
group
224.0.1.40
once
you
enable
multicast
routing.
This
default
behavior
was
created
to
facilitate
the
deployment
of
Auto-RP.
We
will
use
show
ip
mroute
on
all
devices
in
the
topology
to
illustrate
that
the
multicast
group
224.0.1.40
is
being
multicast
forwarded.
As
such
we
will
expect
to
see
a
(*,G)
and
a
(S,G)
entry
on
each
of
these
devices
for
the
group
224.0.1.40.
8-10
Chapter 8: AutoRP
R1
has
joined
the
group
224.0.1.40
from
192.1.2.2
via
interface
FastEthernet0/0
toward
R5:
R5#show ip mroute 224.0.1.40
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.0.1.40), 01:20:00/stopped, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/1, Forward/Sparse-Dense, 01:19:42/00:00:00
FastEthernet0/0, Forward/Sparse, 01:19:56/00:02:57
Loopback0, Forward/Sparse-Dense, 01:20:00/00:00:00
(192.1.2.2, 224.0.1.40), 00:25:13/00:02:39, flags: LT
Incoming interface: FastEthernet0/1, RPF nbr 172.16.45.4
Outgoing interface list:
Loopback0, Forward/Sparse-Dense, 00:25:14/00:00:00
FastEthernet0/0, Forward/Sparse, 00:25:14/00:02:56
8-11
Chapter 8: AutoRP
R4
has
joined
224.0.1.40
sourced
from
192.1.2.2
sourced
from
FastEthernet0/0
pointing
to
R2:
R2#show ip mroute 224.0.1.40
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.0.1.40), 01:18:34/stopped, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet0/1, Forward/Sparse-Dense, 01:14:17/00:00:00
GigabitEthernet0/0, Forward/Sparse-Dense, 01:18:31/00:00:00
8-12
Chapter 8: AutoRP
R2
is
the
MA
agent
in
this
equation.
Note
that
the
incoming
interface
is
the
loopback0
interface,
and
that
both
GigabitEthernet0/0
and
GigabitEthernet0/1
are
in
the
OIL
for
that
S,G
pair.
R6#show ip mroute 224.0.1.40
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.0.1.40), 01:14:20/stopped, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial0/1/0.1, Forward/Sparse-Dense, 01:13:54/00:00:00
FastEthernet0/1, Forward/Sparse-Dense, 01:14:17/00:00:00
FastEthernet0/0, Forward/Sparse-Dense, 01:14:20/00:00:00
(192.1.2.2, 224.0.1.40), 00:25:13/00:02:38, flags: LT
Incoming interface: FastEthernet0/1, RPF nbr 172.16.26.2
Outgoing interface list:
FastEthernet0/0, Forward/Sparse-Dense, 00:25:14/00:00:00
Serial0/1/0.1, Prune/Sparse-Dense, 00:02:22/00:00:38, A
R6
has
joined
the
group
and
the
incoming
interface
is
via
FastEthernet0/1
pointing
to
R2:
R7#show ip mroute 224.0.1.40
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
8-13
Chapter 8: AutoRP
R7
has
joined
224.0.1.40,
and
is
receiving
the
group
via
FastEthernet0/0
pointing
toward
R2:
R9#show ip mroute 224.0.1.40
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.0.1.40), 01:13:20/stopped, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/1, Forward/Sparse-Dense, 01:13:20/00:00:00
(192.1.2.2, 224.0.1.40), 00:25:13/00:02:37, flags: PLTX
Incoming interface: FastEthernet0/1, RPF nbr 172.16.79.7
Outgoing interface list: Null
Lastly,
R9
is
receiving
the
multicast
information
for
224.0.1.40
via
FastEthernet0/1.
Again
all
this
is
actually
being
forwarded
throughout
the
domain
using
routed
multicast
packets.
Multicast
Routing
Topology
The
previous
sections
exposed
the
fact
that
Auto-RP
utilizes
multicast
packets
that
require
routing
throughout
the
topology.
More
to
the
point,
the
multicast
routing
addresses
used
by
the
C-RP
and
the
8-14
Chapter 8: AutoRP
MA
to
communicate
group-to-RP
information
are
all
routed
in
PIM-DM
by
default.
We
discussed
the
use
of
an
RP
for
these
multicast
groups
to
avoid
this
behavior
in
the
Technology
Review
section.
We
can
illustrate
this
point
by
using
show
ip
mroute
dense:
R2#show ip mroute dense
(*, 224.0.1.39), 02:14:16/stopped, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Loopback0, Forward/Sparse-Dense, 01:31:06/00:00:00
GigabitEthernet0/1, Forward/Sparse-Dense, 02:14:16/00:00:00
GigabitEthernet0/0, Forward/Sparse-Dense, 02:14:16/00:00:00
(192.1.44.44, 224.0.1.39), 01:19:21/00:02:44, flags: LT
Incoming interface: GigabitEthernet0/0, RPF nbr 172.16.24.4
Outgoing interface list:
GigabitEthernet0/1, Forward/Sparse-Dense, 01:19:21/00:00:00
Loopback0, Forward/Sparse-Dense, 01:19:21/00:00:00
(192.1.6.6, 224.0.1.39), 01:35:06/00:02:54, flags: LT
Incoming interface: GigabitEthernet0/1, RPF nbr 172.16.26.6
Outgoing interface list:
Loopback0, Forward/Sparse-Dense, 01:31:06/00:00:00
GigabitEthernet0/0, Forward/Sparse-Dense, 01:31:06/00:00:00
(*, 224.0.1.40), 02:25:45/stopped, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet0/1, Forward/Sparse-Dense, 02:21:29/00:00:00
GigabitEthernet0/0, Forward/Sparse-Dense, 02:25:43/00:00:00
Loopback0, Forward/Sparse-Dense, 02:25:48/00:00:00
(192.1.2.2, 224.0.1.40), 01:32:27/00:02:56, flags: LT
Incoming interface: Loopback0, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet0/0, Forward/Sparse-Dense, 01:32:27/00:00:00
GigabitEthernet0/1, Forward/Sparse-Dense, 01:32:27/00:00:00
The
output
of
this
command
reveals
that
only
the
group
224.0.1.39
and
224.0.1.40
are
operating
in
PIM-
DM.
This
works
because
we
are
currently
using
the
Cisco
Proprietary
PIM
mode
PIM-S-DM.
PIM-S-DM
was
initially
created
to
overcome
this
operational
paradox
where
Auto-RP
uses
dense
mode
traffic
to
elect
an
RP.
Based
on
the
current
topology
if
traffic
where
sourced
from
R1
for
the
multicast
group
224.9.9.9
that
traffic
will
be
forwarded
via
PIM-SM
evidenced
by
show
ip
mroute
sparse:
R1#ping 224.9.9.9 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 224.9.9.9, timeout is 2 seconds:
8-15
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
to
to
to
to
to
to
to
to
to
to
request
request
request
request
request
request
request
request
request
request
0
1
2
3
4
5
6
7
8
9
from
from
from
from
from
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
Chapter 8: AutoRP
4
1
1
1
1
1
1
1
1
1
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
We
see
that
traffic
to
224.9.9.9
is
PIM-SM
forwarded.
This
is
because
there
is
a
group-to-RP
mapping
for
224.9.9.9:
R2#show ip pim rp
Group: 224.9.9.9, RP: 192.1.44.44, v2, v1, uptime 01:26:42, expires 00:02:14
Neither
R4
or
R6
can
be
the
RP
any
longer.
How
will
traffic
to
224.9.9.9
be
forwarded
now?
R1#show ip mroute 224.9.9.9
8-16
Chapter 8: AutoRP
to
to
to
to
to
to
to
to
to
to
request
request
request
request
request
request
request
request
request
request
0
1
2
3
4
5
6
7
8
9
from
from
from
from
from
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
4
1
1
1
1
1
1
1
1
1
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
Recognizing
that
this
was
less
than
efficient,
Cisco
created
the
no
ip
dm-fallback
command.
This
command
when
applied
to
all
PIM-S-DM
speaking
routers
will
stop
this
resorting
dense
mode
behavior
(here
we
illustrate
the
command
just
on
R1):
Enter configuration commands, one per line.
8-17
Chapter 8: AutoRP
Now
when
traffic
is
generated
from
R1
to
the
group
224.9.9.9
the
traffic
will
no
longer
use
PIM-DM:
R1#ping 224.9.9.9 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 224.9.9.9, timeout is 2 seconds:
..........
Now
we
will
look
to
see
if
the
traffic
is
still
dense
mode
forwarded.
R5#show ip mroute 224.9.9.9
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.9.9.9), 00:01:41/00:01:18, RP 0.0.0.0, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
Based
on
this
output
it
is
obvious
that
R5
is
not
forwarding
the
traffic
because
there
are
not
interfaces
in
the
OIL.
There
are
no
interfaces
for
this
group
because
R5
has
no
valid
RP
address
to
use
for
the
group
as
typified
by
the
RP
0.0.0.0,
and
based
on
the
flag
for
the
*,G
entry
we
know
the
group
is
PIM-SM
forwarded.
Auto-RP
Listener
Auto-RP
listener
was
created
as
a
better
solution
than
the
no
ip
dm-fallback
command.
Auto-RP
allows
the
network
to
use
pure
PIM-SM,
by
making
on
simple
modification
to
the
operational
mechanism
that
protocol
uses.
Without
the
ip
pim
autorp
listener
command,
PIM-SM
will
attempt
to
forward
traffic
for
all
multicast
group
address
using
PIM-SM.
However,
with
the
command
ip
pim
autorp
listener
Cisco
IOS
affords
us
a
hack
on
this
process.
Once
the
command
is
deployed
all
multicast
groups
except
224.0.1.39
and
224.0.1.40
are
PIM-SM.
These
two
groups,
and
only
these
two
groups
will
be
PIM-DM.
In
the
following
topology
illustrated
in
Figure
8-2
where
all
interfaces
on
all
devices
are
running
ip
pim
sparse-mode
we
will
observe
the
application
and
operation
of
ip
pim
autorp
listener:
8-18
Chapter 8: AutoRP
8-19
Chapter 8: AutoRP
This
output
indicates
the
two
sources
are
active
for
the
group
224.0.1.39.
Many
aspiring
students
see
this
behavior
and
think
that
the
show
ip
pim
rp-listener
command
is
not
necessary.
Can
you
imagine
why
R2
is
learning
the
information
generated
on
these
two
C-RPs?
We
will
look
closer
at
this
process
by
using
debug
ip
auto-rp:
R2#debug ip pim auto-rp
PIM Auto-RP debugging is on
R2#
Auto-RP(0): Received RP-announce packet of length 48, from 192.1.6.6, RP_cnt 1, ht 181
Auto-RP(0): Update (224.0.0.0/4, RP:192.1.6.6), PIMv2 v1
Auto-RP(0): Received RP-announce packet of length 48, from 192.1.6.6, RP_cnt 1, ht 181
Auto-RP(0): Update (224.0.0.0/4, RP:192.1.6.6), PIMv2 v1
R2#
Auto-RP(0): Received RP-announce packet of length 48, from 192.1.4.4, RP_cnt 1, ht 181
Auto-RP(0): Update (224.0.0.0/4, RP:192.1.4.4), PIMv2 v1
Auto-RP(0): Received RP-announce packet of length 48, from 192.1.4.4, RP_cnt 1, ht 181
Auto-RP(0): Update (224.0.0.0/4, RP:192.1.4.4), PIMv2 v1
R2#
Auto-RP(0): Build RP-Discovery packet
Auto-RP: Build mapping (224.0.0.0/4, RP:192.1.6.6), PIMv2 v1,
Auto-RP(0): Send RP-discovery packet of length 48 on GigabitEthernet0/0 (1 RP entries)
Auto-RP(0): Send RP-discovery packet of length 48 on GigabitEthernet0/1 (1 RP entries)
Auto-RP(0): Send RP-discovery packet of length 48 on Loopback0(*) (1 RP entries)
R2
is
actually
receiving
the
messages
from
the
two
C-RP,
and
building
the
RP-Discovery
packet.
In
this
scenario,
messages
from
R4
and
R6
are
making
it
to
R2
because
they
are
adjacent,
and
the
RP-discovery
packets
are
making
it
to
R4
and
R6
for
the
same
reason.
To
better
illustrate
this
point
we
will
disable
the
point-to-point
link
between
R4
and
R6.
R4#conf t
Enter configuration commands, one per line.
R4(config)#interface Serial0/0/0.1
R4(config-subif)#shut
R4(config-subif)#end
With
this
accomplished
we
will
use
show
ip
mroute
to
get
a
snapshot
of
what
information
has
been
propagated.
8-20
Chapter 8: AutoRP
This
means
that
R2
has
learned
about
the
224.0.1.39
group
from
both
R4
and
R6.
Now
we
will
look
at
R4
and
R6
respectively:
R4#show ip mroute 224.0.1.39
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.0.1.39), 00:00:14/stopped, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:00:14/00:02:45
8-21
Chapter 8: AutoRP
8-22
Chapter 8: AutoRP
Because
the
information
for
the
C-RP
is
generated
by
R4
and
R6,
we
see
in
Figure
8-3
that
R2
and
R5
learn
the
source
and
destination
address
from
R4
and
R2
while,
R7
learns
about
the
source
and
destination
address
from
R6.
The
next
question
is
will
R5
and
R7
forward
these
multicast
packets?
R5#show ip mroute 224.0.1.39
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.0.1.39), 00:44:19/stopped, RP 0.0.0.0, flags: DP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
(192.1.4.4, 224.0.1.39), 00:02:19/00:00:40, flags: PT
Incoming interface: FastEthernet0/1, RPF nbr 172.16.45.4
Outgoing interface list: Null
This
output
lets
us
know
that
R5
will
not
forward
any
information
for
this
S,G
pair,
this
can
be
verified
on
R1
with
show
ip
mroute:
R1#show ip mroute 224.0.1.39
Group 224.0.1.39 not found
8-23
Chapter 8: AutoRP
Again
there
are
no
interfaces
in
the
OIL
for
the
S,G
pair,
thus
there
will
be
no
knowledge
of
the
group
224.0.1.39
on
R9:
R9#show ip mroute 224.0.1.39
Group 224.0.1.39 not found
In Figure 8-4 we will apply this information to our drawing to better illustrate the issues at hand:
Figure
8-4:
Incomplete
Propagation
of
(S,G)
entries
for
224.0.1.39
based
on
adjacency
Figure
8-4
makes
it
very
clear
that
the
information
regarding
the
possible
C-RPs
are
not
being
properly
propagated
through
the
network.
We
have
looked
at
the
multicast
group
224.0.1.39,
and
admittedly,
in
this
topology
there
is
only
one
MA
so
this
issue
may
not
affect
us.
But
now
we
need
to
look
at
the
address
224.0.1.40
that
is
used
to
propagate
the
Auto-RP
Discovery
messages.
Starting
at
R2
where
these
messages
are
originiated
we
will
follow
the
multicast
stream
from
R2
to
R1:
R4#show ip mroute 224.0.1.40
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,
8-24
Chapter 8: AutoRP
R4
is
learning
the
S,G
for
224.0.1.40
from
R2,
but
we
can
see
that
it
is
not
forwarding
the
traffic
from
that
source
out
any
interfaces.
This
means
that
R5
will
not
have
an
S,G
entry
as
evidenced
by
show
ip
mroute:
R5#show ip mroute 224.0.1.40
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.0.1.40), 01:18:11/00:02:53, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 01:18:11/00:02:53
Loopback0, Forward/Sparse-Dense, 01:18:11/00:00:00
We
will
see
that
this
process
repeats
itself
between
R6
and
R7:
R6#show ip mroute 224.0.1.40
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,
8-25
Chapter 8: AutoRP
No
interfaces
in
the
OIL
means
R6
will
not
forward
the
multicast
stream
from
R2:
R7#show ip mroute 224.0.1.40
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.0.1.40), 01:18:38/00:02:32, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 01:18:38/00:02:29
Loopback0, Forward/Sparse-Dense, 01:18:38/00:00:00
Placing
all
this
information
in
the
drawing
will
allow
us
to
get
a
better
understanding
of
where
the
configuration
has
failed.
Figure
8-5
has
all
this
information
8-26
Chapter 8: AutoRP
Figure
8-5:
Incomplete
Propagation
of
(S,G)
entries
for
224.0.1.39
and
224.0.1.40
based
on
adjacency
Based
on
this
illustration
we
can
assume
that
only
R4
and
R6
will
have
knowledge
of
any
group-to-RP
mappings.
As
evidenced
by
show
ip
pim
rp
mapping
on
R4
and
R7:
R4#show ip pim rp mapping
PIM Group-to-RP Mappings
This system is an RP (Auto-RP)
Group(s) 224.0.0.0/4
RP 192.1.6.6 (?), v2v1
Info source: 192.1.2.2 (?), elected via Auto-RP
Uptime: 03:55:32, expires: 00:02:33
R6#show ip pim rp mapping
PIM Group-to-RP Mappings
This system is an RP (Auto-RP)
Group(s) 224.0.0.0/4
RP 192.1.6.6 (?), v2v1
Info source: 192.1.2.2 (?), elected via Auto-RP
Uptime: 03:55:32, expires: 00:02:33
But
no
other
devices
beyond
R4
and
R6
will
have
this
information
because
the
necessary
groups
to
propagate
the
Auto-RP
information
is
being
dropped
in
this
topology:
R5#show ip pim rp mapping
PIM Group-to-RP Mappings
R1#show ip pim rp mapping
PIM Group-to-RP Mappings
R7#show ip pim rp mapping
8-27
Chapter 8: AutoRP
The
method
best
able
to
correct
this
issue
will
be
to
execute
ip
pim
autorp
listener
on
all
devices
(we
demonstrate
this
on
R1):
R1#conf t
Enter configuration commands, one per line.
R1(config)#ip pim autorp listener
R1(config)#end
Now
that
this
has
been
accomplished
we
will
look
at
the
topology
again
for
the
multicast
group
224.0.1.40,
and
verify
that
each
router
in
the
topology
agrees
on
the
identity
of
the
RP.
We
will
start
with
R1
and
work
our
way
to
R2:
R1#show ip mroute 224.0.1.40
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.0.1.40), 00:02:26/stopped, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:02:26/00:00:00
(192.1.2.2, 224.0.1.40), 00:01:36/00:02:22, flags: PLT
Incoming interface: FastEthernet0/0, RPF nbr 172.16.15.5
Outgoing interface list: Null
R1
knows
now
knows
the
S,G
entry
from
192.1.2.2,
and
therefore
can
receive
the
Group-to-RP
mappings
from
the
MA:
R1#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 192.1.6.6 (?), v2v1
8-28
Chapter 8: AutoRP
8-29
Chapter 8: AutoRP
8-30
Chapter 8: AutoRP
Observe
that
the
MA
knows
the
identity
of
both
C-RPs,
but
it
is
only
propagating
information
about
the
RP
that
it
has
selected
for
the
topology.
One
Last
Step
Now
that
we
have
verified
half
the
topology,
we
will
check
everything
by
initiating
an
mtrace
from
R1
to
the
172.16.79.0/24
interface
of
R9:
R1#mtrace 172.16.15.1 172.16.79.9 224.9.9.9
Type escape sequence to abort.
Mtrace from 172.16.15.1 to 172.16.79.9 via group 224.9.9.9
From source (?) to destination (?)
Querying full reverse path...
0 172.16.79.9
-1 172.16.67.7 PIM [172.16.15.0/24]
-2 172.16.67.6 PIM Reached RP/Core [172.16.15.0/24]
-3 172.16.26.2 PIM [172.16.15.0/24]
-4 172.16.24.4 PIM [172.16.15.0/24]
-5 172.16.45.5 PIM [172.16.15.0/24]
-6 172.16.15.1 PIM Prune sent upstream [172.16.15.0/24]
We
see
exactly
what
we
would
expect.
The
multicast
path
forms
with
R6
as
the
RP/Core.
Verification
would
be
to
a
have
R9
join
the
multicast
group
224.9.9.9,
and
generate
a
multicast
feed
for
that
address
on
R1:
R9#conf t
Enter configuration commands, one per line.
R9(config)#interface FastEthernet0/1
R9(config-if)#ip igmp join-group 224.9.9.9
R9(config-if)#end
8-31
Chapter 8: AutoRP
to
to
to
to
to
to
to
to
to
to
to
request
request
request
request
request
request
request
request
request
request
request
0
0
1
2
3
4
5
6
7
8
9
from
from
from
from
from
from
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
4
4
1
1
1
1
1
1
1
1
1
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
This
demonstrates
that
the
topology
is
fully
functional
after
the
application
of
the
ip
pim
autorp
listener
command.
8-32
Chapter 8: AutoRP
We
will
perform
a
walk
through
for
each
of
these
RPF
issues
in
the
Auto-RP
Sample
Troubleshooting
Scenarios
section
that
follows.
Multicast
Routing
and
Forwarding
Problems
These
problems
manifest
themselves
in
more
subtle
ways
when
compared
to
the
previous
points.
As
discussed
earlier,
the
majority
of
the
Auto-RP
operational
mechanisms
involve
the
formation
of
the
control
plane
so
that
a
device
can
be
assigned
as
the
MA,
and
so
that
C-RP
group-to-RP
mappings
can
be
communicated
to
the
MA.
From
that
point,
the
elected
group-to-RP
mapping
can
be
propagated
throughout
the
multicast
domain
by
the
MA.
Situations
like
the
following
exist
when
information
fails
to
propagate
to
any
or
all
devices,
but
RPF
checks
and
unicast
routing
seem
to
be
functioning
correctly:
One or more devices fail to receive the elected group-to-RP-set information from the MA.
8-33
Chapter 8: AutoRP
One
or
more
C-RP
fails
to
communicate
with
the
its
candidacy
as
a
C-RP
for
a
given
group
or
scope.
In
the
Auto-RP
Sample
Troubleshooting
Scenarios
section
that
follows,
troubleshooting
these
issues
are
demonstrated.
For
each
problem,
the
text
demonstrates
how
to
quickly
and
efficiently
verify
each
symptom,
isolate
the
cause,
and
remediate
the
issue.
8-34
Chapter 8: AutoRP
In
the
Common
Issues
with
Auto-RP
section,
two
primary
types
of
problems
were
identified:
RPF
failures,
and
multicast
forwarding
and
routing
failures.
This
section
explores
these
categories
of
failure,
by
directing
our
attention
to
the
commands
necessary
to
identify
that
a
problem
exists.
There
are
three
types
of
devices
in
this
topology:
C-RP(s),
a
MA,
and
PIM
enabled
routers.
We
will
verify
that
this
environment
is
operating
correctly
by
checking
that
the
topology
agrees
with
Figure
8-6.
Step
One:
Is
R2
the
Mapping
Agent?
The
fastest
way
to
verify
that
R2
is
the
Mapping
Agent
would
be
show
ip
pim
autorp:
R2#show ip pim autorp
AutoRP Information:
AutoRP is enabled.
AutoRP groups over sparse mode interface is enabled
PIM AutoRP Statistics: Sent/Received
RP Announce: 0/54, RP Discovery: 45/0
8-35
Chapter 8: AutoRP
The
output
indicates
that
R2
is
sending
Discovery
messages.
Only
the
MA
will
do
this
in
an
Auto-RP
configuration.
Step
Two:
Are
R4
and
R6
configured
as
C-RPs?
The
fastest
way
to
verify
that
R4
and
R6
are
Candidate-RPs
would
be
show
ip
pim
autorp:
R4#show ip pim autorp
AutoRP Information:
AutoRP is enabled.
AutoRP groups over sparse mode interface is enabled
PIM AutoRP Statistics: Sent/Received
RP Announce: 68/0, RP Discovery: 0/18
R6#show ip pim autorp
AutoRP Information:
AutoRP is enabled.
AutoRP groups over sparse mode interface is enabled
PIM AutoRP Statistics: Sent/Received
RP Announce: 68/0, RP Discovery: 0/18
With
this
accomplished
are
pings
to
this
group
successful
from
R1?
R1#ping 224.9.9.9 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 224.9.9.9, timeout is 2 seconds:
Reply to request 0 from 172.16.79.9, 4 ms
Reply to request 1 from 172.16.79.9, 1 ms
Reply to request 1 from 172.16.79.9, 1 ms
8-36
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
to
to
to
to
to
to
to
to
request
request
request
request
request
request
request
request
2
3
4
5
6
7
8
9
from
from
from
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
Chapter 8: AutoRP
1
1
1
1
1
1
1
1
ms
ms
ms
ms
ms
ms
ms
ms
Step
Four:
Which
of
the
two
possible
C-RPs
were
elected
to
serve
as
the
RP
for
the
group
224.9.9.9?
Verified
with
show
ip
pim
rp:
R1#show ip pim rp
Group: 224.9.9.9, RP: 192.1.6.6, v2, v1, uptime 00:21:42, expires 00:02:07
R5#show ip pim rp
Group: 224.9.9.9, RP: 192.1.6.6, v2, uptime 00:21:42, expires 00:02:06
R4#show ip pim rp
Group: 224.9.9.9, RP: 192.1.6.6, v2, v1, uptime 00:21:42, expires 00:02:04
R2#show ip pim rp
Group: 224.9.9.9, RP: 192.1.6.6, v2, v1, uptime 00:21:42, expires 00:02:16
R6#show ip pim rp
Group: 224.9.9.9, RP: 192.1.6.6, v2, v1, next RP-reachable in 00:00:47
R7#show ip pim rp
Group: 224.9.9.9, RP: 192.1.6.6, v2, v1, uptime 00:21:42, expires 00:02:06
R9#show ip pim rp
Group: 224.9.9.9, RP: 192.1.6.6, v2, v1, uptime 00:21:42, expires 00:02:04
This
output
clearly
identifies
R6
as
the
RP
for
the
group
224.9.9.9.
All
things
being
equal
in
the
configuration
between
R4
and
R6
we
would
expect
this
based
on
R6's
higher
IP
address.
RPF
failures
Pings
to
the
group
224.9.9.9
are
no
longer
successful
from
R1:
R1#ping 224.9.9.9 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 224.9.9.9, timeout is 2 seconds:
..........
8-37
Chapter 8: AutoRP
There
are
a
number
of
reasons
why
this
may
be
happening,
a
logical
approach
would
be
to
determine
if
R1
has
a
RP
mapping
for
the
group
224.9.9.9:
R1#show ip pim rp mapping
PIM Group-to-RP Mappings
R1#
R1
has
no
mapping
for
this
or
any
group.
Are
RP
Discovery
messages
arriving
on
R1
from
the
MA?
R1#show ip pim autorp
AutoRP Information:
AutoRP is enabled.
AutoRP groups over sparse mode interface is enabled
PIM AutoRP Statistics: Sent/Received
RP Announce: 0/0, RP Discovery: 0/32
We
see
that
32
RP
Discovery
messages
have
arrived.
We
know
that
these
messages
will
be
send
at
periodic
intervals.
So
logically,
we
would
expect
this
value
to
increment
over
time.
After
2
minutes
we
will
execute
the
command
again.
R1#show ip pim autorp
AutoRP Information:
AutoRP is enabled.
AutoRP groups over sparse mode interface is enabled
PIM AutoRP Statistics: Sent/Received
RP Announce: 0/0, RP Discovery: 0/32
The
value
is
not
incrementing.
We
know
that
these
messages
are
subjected
to
RPF
checks,
and
that
they
are
sourced
from
the
loopback0
interface
of
R2.
To
verify
the
multicast
path
between
R2
and
R1
we
will
us
mtrace:
R1#mtrace 192.1.2.2
Type escape sequence to abort.
Mtrace from 192.1.2.2 to 172.16.15.1 via RPF
From source (?) to destination (?)
Querying full reverse path...
0 172.16.15.1
-1 172.16.15.1 PIM [192.1.2.0/24]
-2 172.16.15.5 PIM [192.1.2.0/24]
-3 172.16.45.4 PIM Multicast disabled [192.1.2.0/24]
-4 172.16.24.2 PIM [192.1.2.0/24]
8-38
Chapter 8: AutoRP
The
output
of
mtrace
shows
us
that
multicast
PIM
is
disabled
on
the
172.16.45.4
interface
of
R4
as
evidenced
with
show
run
on
that
device:
R4#show run interface FastEthernet0/1
Building configuration...
Current configuration : 96 bytes
!
interface FastEthernet0/1
ip address 172.16.45.4 255.255.255.0
duplex auto
speed auto
end
This
can
be
corrected
by
applying
the
ip
pim
sparse-mode
command
under
this
interface:
R4#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)#interface FastEthernet0/1
R4(config-if)#ip pim sparse-mode
R4(config-if)#end
R4#
%PIM-5-NBRCHG: neighbor 172.16.45.5 UP on interface FastEthernet0/1
%PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 172.16.45.5 on interface
FastEthernet0/1
We
see
the
PIM
neighbor
come
up
with
R5.
Now
do
we
see
any
group-to-RP
mappings
on
R1?
R1#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 192.1.6.6 (?), v2v1
Info source: 192.1.2.2 (?), elected via Auto-RP
Uptime: 00:01:26, expires: 00:02:31
We
see
the
mapping.
Are
pings
to
the
group
224.9.9.9
successful
now?
R1#ping 224.9.9.9 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 224.9.9.9, timeout is 2 seconds:
Reply
Reply
Reply
Reply
Reply
to
to
to
to
to
request
request
request
request
request
0
1
1
2
3
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
4
1
1
1
1
ms
ms
ms
ms
ms
8-39
Reply
Reply
Reply
Reply
Reply
Reply
to
to
to
to
to
to
request
request
request
request
request
request
4
5
6
7
8
9
from
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
Chapter 8: AutoRP
1
1
1
1
1
1
ms
ms
ms
ms
ms
ms
There
are
a
number
of
reasons
why
this
may
be
happening,
a
logical
approach
would
be
to
determine
if
R1
has
a
RP
mapping
for
the
group
224.9.9.9:
R1#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 192.1.6.6 (?), v2v1
Info source: 192.1.2.2 (?), elected via Auto-RP
Uptime: 00:17:24, expires: 00:02:22
8-40
Chapter 8: AutoRP
No,
they
do
not.
R9
has
no
RP
mappings
assigned.
This
could
be
an
RPF
error
between
R9
and
the
MA.
If
so,
this
can
be
identified
via
mtrace:
R9#mtrace 192.1.2.2
Type escape sequence to abort.
Mtrace from 192.1.2.2 to 172.16.79.9 via RPF
From source (?) to destination (?)
Querying full reverse path...
0 172.16.79.9
-1 172.16.79.9 PIM [192.1.2.0/24]
-2 172.16.79.7 PIM [192.1.2.0/24]
-3 172.16.67.6 PIM [192.1.2.0/24]
-4 172.16.26.2 PIM [192.1.2.0/24]
-5 192.1.2.2
8-41
Chapter 8: AutoRP
There
does
not
appear
to
be
an
RPF
issue.
That
leaves
a
multicast
routing
and
forwarding
issue
somewhere
in
the
path.
By
looking
at
the
multicast
routing
table
on
R9
we
can
see
if
it
is
learning
any
information
from
the
MA
192.1.2.2
for
the
group
224.0.1.40:
R9#show ip mroute 224.0.1.40
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.0.1.40), 00:20:14/00:02:37, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/1, Forward/Sparse, 00:20:14/00:00:00
This
output
demonstrates
that
R9
has
only
the
*,G
entry
for
the
group
224.0.1.40,
and
has
no
incoming
interface.
This
means
that
R9
is
not
receiving
any
multicast
packets
for
this
group.
Logically,
by
looking
at
Figure
8-6,
we
know
that
R9
should
receive
these
packets
from
R7.
We
need
to
look
at
the
multicast
routing
table
on
R7
now:
R7#show ip mroute 224.0.1.40
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.0.1.40), 00:21:28/stopped, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:21:28/00:02:09
(192.1.2.2, 224.0.1.40), 00:20:51/00:02:10, flags: PLTX
Incoming interface: FastEthernet0/0, RPF nbr 172.16.67.6
8-42
Chapter 8: AutoRP
We
see
that
R7
has
both
the
*,G
and
the
S,G
entry
for
the
group
224.0.1.40,
but
we
also
see
that
the
OIL
is
empty
(Null).
Note
again
the
flag
of
"D"
for
this
traffic.
This
means
that
the
packets
are
dense
mode
forwarded.
We
are
running
pim
sparse-mode
under
both
interfaces
on
R7,
as
evidenced
by
show
run:
R7#show run interface FastEthernet0/0
Building configuration...
Current configuration : 116 bytes
!
interface FastEthernet0/0
ip address 172.16.67.7 255.255.255.0
ip pim sparse-mode
duplex auto
speed auto
end
R7#show run interface FastEthernet0/1
Building configuration...
Current configuration : 116 bytes
!
interface FastEthernet0/1
ip address 172.16.79.7 255.255.255.0
ip pim sparse-mode
duplex auto
speed auto
end
We
know
that
we
need
the
ip
pim
autorp
listener
command
to
allow
R7
to
forward
the
multicast
group
224.0.1.39
and
224.0.1.40
in
dense
mode.
We
can
see
if
this
command
is
configured
on
R7
with
show
run:
R7#show run | inc listener
R7#
The
command
is
not
configured.
This
can
be
corrected
by
adding
the
command
on
R7:
R7#conf t
Enter configuration commands, one per line.
R7(config)#ip pim autorp listener
R7(config)#end
8-43
Chapter 8: AutoRP
to
to
to
to
to
to
to
to
to
to
to
request
request
request
request
request
request
request
request
request
request
request
0
1
1
2
3
4
5
6
7
8
9
from
from
from
from
from
from
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
4
1
1
1
1
1
1
1
1
1
1
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
8-44
Chapter 8: AutoRP
show
COMMAND:
show
ip
igmp
membership
[group-address
|
group-name]
[tracked]
[all]
This
command
displays
Internet
Group
Management
Protocol
(IGMP)
membership
information
for
multicast
groups
and
(S,
G)
channels.
Where:
EXAMPLE
OUTPUT:
R9#show ip igmp membership
Flags: A - aggregate, T - tracked
L - Local, S - static, V - virtual, R - Reported through v3
I - v3lite, U - Urd, M - SSM (S,G) channel
1,2,3 - The version of IGMP the group is in
Channel/Group-Flags:
/ - Filtering entry (Exclude mode (S,G), Include mode (*,G))
Reporter:
<mac-or-ip-address> - last reporter if group is not explicitly tracked
<n>/<m>
- <n> reporter in include mode, <m> reporter in exclude
8-45
Channel/Group
*,224.9.9.9
*,239.9.9.9
*,224.0.1.40
R9#
Reporter
172.16.79.9
172.16.79.9
172.16.79.9
Chapter 8: AutoRP
Uptime
00:20:07
00:20:07
00:20:07
Exp.
02:22
02:22
02:22
Flags
2LA
2LA
2LA
Interface
Fa0/1
Fa0/1
Fa0/1
show
COMMAND:
show
ip
mroute
This
command
displays
the
contents
of
the
multicast
routing
(mroute)
table.
EXAMPLE
OUTPUT:
R7#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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.9.9.9), 00:21:15/00:02:38, RP 192.1.6.6, flags: SJC
Incoming interface: FastEthernet0/0, RPF nbr 172.16.67.6
Outgoing interface list:
FastEthernet0/1, Forward/Sparse, 00:01:05/00:03:01
(*, 239.9.9.9), 00:21:15/00:03:04, RP 192.1.6.6, flags: SJC
Incoming interface: FastEthernet0/0, RPF nbr 172.16.67.6
Outgoing interface list:
FastEthernet0/1, Forward/Sparse, 00:01:05/00:03:04
(172.16.15.1, 239.9.9.9), 00:01:00/00:02:03, flags: T
Incoming interface: FastEthernet0/0, RPF nbr 172.16.67.6
Outgoing interface list:
FastEthernet0/1, Forward/Sparse, 00:01:00/00:03:28
(*, 224.0.1.39), 00:03:07/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/1, Forward/Sparse, 00:03:07/00:00:00
FastEthernet0/0, Forward/Sparse, 00:03:09/00:00:00
8-46
Chapter 8: AutoRP
show
COMMAND:
show
ip
pim
interface
This
command
displays
information
about
interfaces
configured
for
Protocol
Independent
Multicast
(PIM).
EXAMPLE
OUTPUT:
R7#show ip pim interface
Address
Interface
192.1.7.7
172.16.67.7
172.16.79.7
R7#
Loopback0
FastEthernet0/0
FastEthernet0/1
Ver/
Mode
v2/S
v2/S
v2/S
Nbr
Count
0
1
1
Query
Intvl
30
30
30
DR
Prior
1
1
1
DR
192.1.7.7
172.16.67.7
172.16.79.9
show
COMMAND:
show
ip
pim
rp
mapping
This
command
displays
information
about
Protocol
Independent
Multicast
(PIM)
RP
mappings.
EXAMPLE
OUTPUT:
R7#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
8-47
Chapter 8: AutoRP
show
COMMAND:
show
ip
pim
[vrf
vrf-name]
neighbor
[interface-type
interface-number]
This
command
displays
information
about
Protocol
Independent
Multicast
(PIM)
neighbors
discovered
by
PIM
version
1
router
query
messages
or
PIM
version
2
hello
messages.
Where:
EXAMPLE
OUTPUT:
R7#show ip pim neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default
S - State Refresh Capable
Neighbor
Interface
Uptime/Expires
Address
172.16.67.6
FastEthernet0/0
00:22:16/00:01:36
172.16.79.9
FastEthernet0/1
00:22:40/00:01:23
R7#
DR Priority,
Ver
v2
v2
DR
Prio/Mode
1 / S
1 / DR S
show
COMMAND:
show
ip
rpf
[vrf
vrf-name]
{route-distinguisher
|
source-address
[group-address]
[rd
route-
distinguisher]}
[metric]
This
command
displays
information
that
IP
multicast
routing
uses
to
perform
the
Reverse
Path
Forwarding
(RPF)
check
for
a
multicast
source
Where:
8-48
Chapter 8: AutoRP
group-address
-
optional;
IP
address
or
name
of
a
multicast
group
for
which
to
display
RPF
information
rd
route-distinguisher
-
optional;
displays
the
Border
Gateway
Protocol
(BGP)
RPF
next
hop
for
the
VPN
route
associated
with
the
RD
specified
for
the
route-distinguisher
argument
metric
-
optional;
displays
the
unicast
routing
metric
EXAMPLE
OUTPUT:
R7#show ip rpf 192.1.2.2
RPF information for ? (192.1.2.2)
RPF interface: FastEthernet0/0
RPF neighbor: ? (172.16.67.6)
RPF route/mask: 192.1.2.0/24
RPF type: unicast (eigrp 100)
RPF recursion count: 0
Doing distance-preferred lookups across tables
R7#
8-49
Chapter 8: AutoRP
debug
COMMAND:
debug
ip
mpacket
[vrf
vrf-name]
[detail
|
fastswitch]
[access-list]
[group]
This
command
displays
multicast
packets
that
are
received
and
sent
on
the
device.
Where:
EXAMPLE
OUTPUT:
IP(0): s=172.16.26.6 (FastEthernet0/1) d=239.9.9.9 (FastEthernet0/0) id=1, ttl=254,
prot=1, len=100(100), mforward
debug
COMMAND:
debug
ip
pim
[vrf
vrf-name]
[bsr]
This
command
displays
Protocol
Independent
Multicast
(PIM)
packets
received
and
sent
and
displays
PIM-related
events
8-50
Chapter 8: AutoRP
Where:
EXAMPLE
OUTPUT:
R7#debug ip pim
PIM debugging is on
R7#
PIM(0): Insert (172.16.15.1,239.9.9.9) join in nbr 172.16.67.6's queue
PIM(0): Building Join/Prune packet for nbr 172.16.67.6
PIM(0): Adding v2 (172.16.15.1/32, 239.9.9.9), S-bit Join
PIM(0): Send v2 join/prune to 172.16.67.6 (FastEthernet0/0)
R7#
PIM(0): Received v2 Join/Prune on FastEthernet0/1 from 172.16.79.9, to us
PIM(0): Prune-list: (192.1.4.4/32, 224.0.1.39)
PIM(0): Prune FastEthernet0/1/224.0.1.39 from (192.1.4.4/32, 224.0.1.39)
PIM(0): Insert (192.1.4.4,224.0.1.39) prune in nbr 172.16.67.6's queue
PIM(0): Building Join/Prune packet for nbr 172.16.67.6
PIM(0): Adding v2 (192.1.4.4/32, 224.0.1.39) Prune
PIM(0): Send v2 join/prune to 172.16.67.6 (FastEthernet0/0)
R7#
PIM(0): Received v2 Join/Prune on FastEthernet0/1 from 172.16.79.9, to us
PIM(0): Prune-list: (192.1.4.4/32, 224.0.1.39)
R7#
8-51
Chapter 8: AutoRP
Trouble
Ticket
#1
Your
supervisor
has
brought
to
your
attention
that
the
router
R5
refuses
to
use
R6
as
the
RP
for
any
multicast
group.
This
behavior
is
not
acceptable
and
is
resulting
in
R9
from
being
able
to
receive
multicast
traffic.
You
have
been
instructed
to
isolate
this
issue
with
the
multicast
group
224.9.9.9.
You
must
correct
the
issue
once
is
it
identified.
Trouble
Ticket
#2
After
solving
Trouble
Ticket
#1,
your
supervisor
has
observed
that
the
MA
(R2)
is
only
recording
RP
Announcements
from
R6
in
the
group-to-RP
mapping
table.
R2
needs
to
be
configured
such
that
it
accepts
RP
announcements
from
R5
and
R4
only.
Be
advised
that
this
task
was
previously
in
the
hands
of
a
junior
technician.
Correct
this
issue.
Trouble
Ticket
#3
Your
supervisor
has
notified
you
that
R7
will
be
assuming
the
role
of
RP
for
all
multicast
groups
in
this
topology.
Previous
testing
has
been
performed
using
R7
after
business
hours
as
the
RP.
You
have
been
instructed
place
R7
into
operation
immediately.
8-52
Chapter 8: AutoRP
Figure
8-10:
Auto-RP
Quick
Fire
Troubleshooting
Flowchart
Trouble
Ticket
#1
Solution
Your
supervisor
has
brought
to
your
attention
that
the
router
R5
refuses
to
use
R6
as
the
RP
for
any
multicast
group.
This
behavior
is
not
acceptable
and
is
resulting
in
R9
from
being
able
to
receive
multicast
traffic.
You
have
been
instructed
to
isolate
this
issue
with
the
multicast
group
224.9.9.9.
You
must
correct
the
issue
once
is
it
identified.
Step
1
-
Fault
Verification:
Initiate
a
ping
test
from
R1
to
the
group
224.9.9.9
with
a
high
repeat
count:
R1#ping 224.9.9.9 repeat 100000
8-53
Chapter 8: AutoRP
These
pings
are
not
successful.
What
RP
is
in
use
on
R5?
R5#show ip pim rp
Group: 224.9.9.9, RP: 192.1.5.5, next RP-reachable in 00:00:22
R5
does
not
choose
R6
as
RP
for
this
group
thus
verifying
the
problem.
Step
2
-
Fault
Isolation:
The
next
course
of
action
is
to
use
the
show
ip
pim
rp
mapping
to
determine
what
R5
is
learning
as
possible
candidate
RPs:
R5#show ip pim rp mapping 224.9.9.9
PIM Group-to-RP Mappings
This system is an RP (Auto-RP)
Group(s) 224.0.0.0/4
RP 192.1.6.6 (?), v2v1
Info source: 192.1.2.2 (?), elected via Auto-RP
Uptime: 00:45:18, expires: 00:02:44
Group(s): 224.0.0.0/4, Static-Override
RP: 192.1.5.5 (?)
We
see
that
R5
is
learning
about
R6's
desire
to
be
the
RP,
but
it
is
not
choosing
it
as
the
RP
because
of
a
static
RP
assignment.
Note
that
this
output
tells
us
that
the
static-override
option
has
been
used.
This
means
that
the
static
route
that
has
been
assigned
will
always
override
any
dynamically
learned
RP
information.
We
can
see
this
via
show
run:
R5#show run | inc override
ip pim rp-address 192.1.5.5 override
The
override
option
will
prevent
R5
from
using
the
dynamic
RP
assignment
via
Auto-RP.
This
has
unquestionably
isolated
our
fault.
Step
3
-
Fault
Remediation:
In
this
scenario,
the
ip
pim
rp-address
command
needs
to
be
removed.
R5#conf t
8-54
Chapter 8: AutoRP
Step
4
-
Verification
of
Remediation
Once
the
error
has
been
isolated
and
remediated
it
is
highly
recommended
to
verify
that
the
Trouble
Ticket
has
been
repaired
using
the
same
method
of
the
initial
fault
verification.
Initiate
a
ping
test
from
R1
to
the
group
224.9.9.9:
R1#ping 224.9.9.9 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 224.9.9.9, timeout is 2 seconds:
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
to
to
to
to
to
to
to
to
to
to
request
request
request
request
request
request
request
request
request
request
0
1
2
3
4
5
6
7
8
9
from
from
from
from
from
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
4
1
1
1
1
1
1
1
1
1
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
These
pings
are
successful.
What
RP
is
in
use
on
R5?
R5#show ip pim rp
Group: 224.9.9.9, RP: 192.1.6.6, v2, uptime 00:56:01, expires 00:02:55
R5
now
chooses
R6
as
the
RP,
demonstrating
that
the
issue
has
been
corrected.
Trouble
Ticket
#2
Solution
After
solving
Trouble
Ticket
#1,
your
supervisor
has
observed
that
the
MA
(R2)
is
only
recording
RP
Announcements
from
R6
in
the
group-to-RP
mapping
table.
R2
needs
to
be
configured
such
that
it
accepts
RP
announcements
from
R5
and
R4
only.
Be
advised
that
this
task
was
previously
in
the
hands
of
a
junior
technician.
Correct
this
issue.
Step
1
-
Fault
Verification:
Is
R2
only
learning
the
information
from
R6?
R2#show ip pim rp mapping
PIM Group-to-RP Mappings
8-55
Chapter 8: AutoRP
The
MA
is
only
learning
of
R6's
desire
to
be
considered
as
a
C-RP
thus
verifying
the
problem
exists.
Step
2
-
Fault
Isolation:
Are
R4
and
R5
advertising
RP
Announcement
messages?
R4#show ip pim autorp
AutoRP Information:
AutoRP is enabled.
AutoRP groups over sparse mode interface is enabled
PIM AutoRP Statistics: Sent/Received
RP Announce: 769/0, RP Discovery: 0/200
Note
that
R4
is
sending
RP
Announcements.
This
is
confirmed
by
the
fact
that
the
counter
increments
over
time:
R4#show ip pim autorp
AutoRP Information:
AutoRP is enabled.
AutoRP groups over sparse mode interface is enabled
PIM AutoRP Statistics: Sent/Received
RP Announce: 773/0, RP Discovery: 0/200
The
same
test
will
be
repeated
on
R5:
R5#show ip pim autorp
AutoRP Information:
AutoRP is enabled.
AutoRP groups over sparse mode interface is enabled
PIM AutoRP Statistics: Sent/Received
RP Announce: 201/0, RP Discovery: 0/183
Note
that
R5
is
also
sending
RP
Announcements.
This
is
confirmed
by
the
fact
that
the
counter
increments
over
time:
R5#show ip pim autorp
8-56
Chapter 8: AutoRP
AutoRP Information:
AutoRP is enabled.
AutoRP groups over sparse mode interface is enabled
PIM AutoRP Statistics: Sent/Received
RP Announce: 204/0, RP Discovery: 0/185
This
means
either
messages
are
not
reaching
R2
or
they
are
being
ignored
by
R2.
An
RPF
error
could
cause
this
issue.
We
will
verify
if
this
is
the
case
via
mtrace:
R4#mtrace 192.1.2.2
Type escape sequence to abort.
Mtrace from 192.1.2.2 to 172.16.24.4 via RPF
From source (?) to destination (?)
Querying full reverse path...
0 172.16.24.4
-1 172.16.24.4 PIM [192.1.2.0/24]
-2 172.16.24.2 PIM [192.1.2.0/24]
-3 192.1.2.2
R5#mtrace 192.1.2.2
Type escape sequence to abort.
Mtrace from 192.1.2.2 to 172.16.45.5 via RPF
From source (?) to destination (?)
Querying full reverse path...
0 172.16.45.5
-1 172.16.45.5 PIM [192.1.2.0/24]
-2 172.16.45.4 PIM [192.1.2.0/24]
-3 172.16.24.2 PIM [192.1.2.0/24]
-4 192.1.2.2
The
output
does
not
seem
to
indicate
an
RPF
issue.
Now
we
will
look
to
see
if
the
messages
are
arriving
on
R2
(MA)
via
debug
ip
pim
auto-rp:
R2#debug ip
PIM Auto-RP
R2#
Auto-RP(0):
Auto-RP(0):
Auto-RP(0):
Auto-RP(0):
pim auto-rp
debugging is on
Received RP-announce
Update (224.0.0.0/4,
Received RP-announce
Update (224.0.0.0/4,
Here
we
see
the
RP-announcement
arrive
from
R6,
but
look
closely
at
the
messages
for
R4
and
R5:
R2#
Auto-RP(0): Received RP-announce packet of length 48, from 192.1.4.4, RP_cnt 1, ht 181
Auto-RP(0): Filtered 224.0.0.0/4 for RP 192.1.4.4
8-57
Auto-RP(0):
Auto-RP(0):
R2#
Auto-RP(0):
Auto-RP(0):
Auto-RP(0):
Auto-RP(0):
Chapter 8: AutoRP
RP-announce
224.0.0.0/4
RP-announce
224.0.0.0/4
packet
for RP
packet
for RP
These
messages
are
being
filtered
and
therefore
dropped.
This
is
not
a
default
situation
and
must
be
related
to
a
filter
of
some
kind
as
evidenced
by
show
run:
R2#show run | inc filter
ip pim rp-announce-filter rp-list 1
This
command
references
an
access-list.
What
is
being
permitted
and
denied
by
the
standard
access-list
1:
R2#show ip access-list 1
Standard IP access list 1
10 deny
192.1.6.6 (146 matches)
20 permit any (296 matches)
This
access-list
has
been
incorrectly
configured.
Line
10
specifically
states
that
RP
Announcements
sourced
from
the
ip
address
192.1.6.6
are
not
allowed
to
filtered.
Therefore
any
line
matching
sequence
number
20
will
be
filtered.
The
junior
technician
should
have
implicitly
permitted
192.1.6.6
and
denied
all
other
traffic
sources.
This
has
isolated
our
fault.
Step
3
-
Fault
Remediation:
In
this
scenario,
access-list
1
needs
to
be
rewritten
to
permit
192.1.6.6
and
deny
all
other
traffic.
The
implicit
deny
at
the
end
an
access-list
will
accomplish
this
normally
but
we
will
make
it
implicit
so
that
we
can
see
the
packet
count
for
those
packets
being
denied.
R2#conf t
Enter configuration commands, one per line.
R2(config)#no access-list 1
R2(config)#access-list 1 permit 192.1.6.6
R2(config)#access-list 1 deny any
R2(config)#end
Step
4
-
Verification
of
Remediation
Once
the
error
has
been
isolated
and
remediated,
it
is
highly
recommended
to
verify
that
the
Trouble
Ticket
has
been
repaired
using
the
same
method
used
to
verify
the
fault
initially:
8-58
Chapter 8: AutoRP
R2#show ip pim rp mapping
PIM Group-to-RP Mappings
This system is an RP-mapping agent (Loopback0)
Group(s) 224.0.0.0/4
RP 192.1.6.6 (?), v2v1
Info source: 192.1.6.6
Uptime: 03:36:03,
RP 192.1.5.5 (?), v2v1
Info source: 192.1.5.5
Uptime: 00:00:24,
RP 192.1.4.4 (?), v2v1
Info source: 192.1.4.4
Uptime: 00:00:30,
Now
the
MA
is
learning
about
R5
and
R4,
we
still
see
the
entry
for
192.1.6.6
but
notice
that
the
expiration
timer
only
has
53
seconds
remaining.
After
waiting
a
minute
R6
should
age
out
leaving
only
R4
and
R5:
R2#show ip pim rp mapping
PIM Group-to-RP Mappings
This system is an RP-mapping agent (Loopback0)
Group(s) 224.0.0.0/4
RP 192.1.5.5 (?), v2v1
Info source: 192.1.5.5
Uptime: 00:02:14,
RP 192.1.4.4 (?), v2v1
Info source: 192.1.4.4
Uptime: 00:02:20,
This
is
the
desired
behavior
thus
proving
the
issue
has
been
corrected.
Trouble
Ticket
#3
Solution
Your
supervisor
has
notified
you
that
R7
will
be
assuming
the
role
of
RP
for
all
multicast
groups
in
this
topology.
Previous
testing
has
been
performed
using
R7
after
business
hours
as
the
RP.
You
have
been
instructed
place
R7
into
operation
immediately.
Step
1
-
Fault
Verification:
Is
R2
learning
anything
from
R7?
8-59
Chapter 8: AutoRP
This
output
notifies
us
that
the
MA
does
not
know
about
R7's
C-RP
status.
Is
R7
sending
RP
Announcement
messages?
R7#show ip pim autorp
AutoRP Information:
AutoRP is enabled.
AutoRP groups over sparse mode interface is enabled
PIM AutoRP Statistics: Sent/Received
RP Announce: 276/0, RP Discovery: 0/228
R7
has
send
276
RP
Announce
messages,
if
we
wait
and
repeat
the
verification
this
number
should
increment:
R7#show ip pim autorp
AutoRP Information:
AutoRP is enabled.
AutoRP groups over sparse mode interface is enabled
PIM AutoRP Statistics: Sent/Received
RP Announce: 279/0, RP Discovery: 0/229
We
see
279
messages
now
after
about
a
minute
or
so.
This
tells
us
that
R7
is
configured
to
act
as
C-RP,
but
the
MA
is
not
learning
this
fact.
This
verifies
the
issue
exists.
Step
2
-
Fault
Isolation:
Realizing
that
these
messages
are
subjected
to
RPF
checks
we
will
need
to
verify
any
possible
RPF
issues
via
mtrace:
R2#mtrace 192.1.7.7
Type escape sequence to abort.
Mtrace from 192.1.7.7 to 172.16.26.2 via RPF
8-60
Chapter 8: AutoRP
Now
we
will
check
the
reverse
direction
from
R7:
R7#mtrace 192.1.2.2
Type escape sequence to abort.
Mtrace from 192.1.2.2 to 172.16.67.7 via RPF
From source (?) to destination (?)
Querying full reverse path...
0 172.16.67.7
-1 172.16.67.7 PIM [192.1.2.0/24]
-2 172.16.67.6 PIM [192.1.2.0/24]
-3 172.16.26.2 PIM [192.1.2.0/24]
-4 192.1.2.2
The
packets
take
the
same
path
in
both
directions.
This
seems
to
eliminate
the
possibility
of
an
RPF
check
failure.
This
means
that
something
non-RPF
related
is
stopping
the
packets
from
arriving
at
R2.
We
will
monitor
these
packets
as
the
leave
R7
and
make
their
way
to
R2
by
using
the
debug
ip
pim
auto-
rp
command:
R7#debug ip
PIM Auto-RP
R7#
Auto-RP(0):
Auto-RP(0):
Auto-RP(0):
Auto-RP(0):
Auto-RP(0):
R7#
pim auto-rp
debugging is on
Build RP-Announce for 192.1.7.7, PIMv2/v1, ttl 1, ht 181
Build announce entry for (224.0.0.0/4)
Send RP-Announce packet of length 48 on FastEthernet0/0
Send RP-Announce packet of length 48 on FastEthernet0/1
Send RP-Announce packet of length 48 on Loopback0(*)
If
we
are
not
careful,
we
could
miss
some
very
critical
information
in
this
debug
output.
Note
that
we
are
sending
an
announcement
for
192.1.7.7,
but
note
the
value
of
the
TTL.
Time-to-Live
has
been
set
to
a
value
of
1
on
this
device.
This
means
that
this
packet
will
expire
after
making
one
"hop".
As
mentioned
in
the
Technology
Review
section
of
this
chapter.
The
scope
command
can
be
used
to
"bound"
Auto-RP
information.
In
this
instance
the
value
has
been
set
to
low
for
the
packet
to
reach
the
MA
as
evidenced
by
show
run:
R7#sh run | inc send-rp-announce
8-61
Chapter 8: AutoRP
This
value
is
inadequate
to
allow
packets
to
reach
the
MA.
This
has
isolated
our
issue.
Step
3
-
Fault
Remediation:
In
this
scenario,
ip
pim
send-rp-announce
needs
to
be
configured
to
allow
enough
hops
to
reach
the
MA.
7#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R7(config)#ip pim send-rp-announce loopback 0 scope 2
R7(config)#end
Step
4
-
Verification
of
Remediation
Once
the
error
has
been
isolated
and
remediated,
it
is
highly
recommended
to
verify
that
the
Trouble
Ticket
has
been
repaired
using
the
same
method
used
to
verify
the
fault
initially.
R2#show ip pim rp mapping
PIM Group-to-RP Mappings
This system is an RP-mapping agent (Loopback0)
Group(s) 224.0.0.0/4
RP 192.1.7.7 (?), v2v1
Info source: 192.1.7.7
Uptime: 00:00:07,
RP 192.1.5.5 (?), v2v1
Info source: 192.1.5.5
Uptime: 00:26:05,
RP 192.1.4.4 (?), v2v1
Info source: 192.1.4.4
Uptime: 00:26:11,
The
MA
is
now
learning
the
information
from
R7.
Based
on
R7's
higher
IP
address
it
is
being
elected
by
the
MA
as
the
RP
for
the
range
224.0.0.0/4.
This
should
mean
that
an
mtrace
from
R1
to
the
FastEthernet0/1
interface
of
R9
using
the
multicast
group
224.9.9.9
should
show
R7
as
the
RP/Core
device:
R1#mtrace 172.16.15.1 172.16.79.9 224.9.9.9
Type escape sequence to abort.
Mtrace from 172.16.15.1 to 172.16.79.9 via group 224.9.9.9
From source (?) to destination (?)
Querying full reverse path... * switching to hop-by-hop:
0 172.16.79.9
-1 * 172.16.79.9 PIM Prune sent upstream [172.16.15.0/24]
8-62
-2
-3
-4
-5
-6
-7
*
*
*
*
*
*
172.16.79.7
172.16.67.6
172.16.26.2
172.16.24.4
172.16.45.5
172.16.15.1
Chapter 8: AutoRP
We see this is indeed the case demonstrating that the fault has been corrected.
8-63
Chapter
9:
Bootstrap
Router
(BSR)
Protocol
In
this
chapter
of
IPv4/6
Multicast
Operation
and
Troubleshooting,
the
processes
and
the
functionality
of
the
Bootstrap
Router
(BSR)
protocol
are
examined
in
great
depth.
Once
the
operational
characteristics
of
this
important
protocol
are
detailed
completely,
the
focus
becomes
that
of
troubleshooting.
This
includes
the
careful
examination
of
symptoms,
a
fault
isolation
methodology,
and
the
implementation
of
repairs
for
the
Bootstrap
Routing
(BSR)
protocol.
The
chapter
begins
with
a
thorough
review
of
BSR,
and
then
quickly
launches
in
to
an
exhaustive
analysis
of
the
art
of
troubleshooting
this
multicast
support
protocol.
This
important
chapter
concludes
with
sample
troubleshooting
scenarios,
reference
materials
for
the
most
important
show
and
debug
commands,
and
exciting
challenges
that
allow
readers
to
practice
implementing
the
troubleshooting
skills
they
have
obtained.
9-1
Figure
9-1:
A
Sample
BSR
Topology
9-2
A
major
design
improvement
over
Ciscos
AutoRP
is
the
fact
that
BSR
requires
no
dense
mode
operation
whatsoever.
Rendezvous
Point
(RP)
information
is
within
BSR
messages,
which
are
carried
inside
of
Protocol
Independent
Multicast
(PIM)
messages
themselves.
These
PIM
messages
are
link-local
multicast
messages.
When
a
router
receives
a
BSR
message
containing
RP
information,
the
router
applies
the
Reverse
Path
Forwarding
(RPF)
check
and
then
floods
the
message
out
all
of
the
PIM-enabled
interfaces.
Remember,
the
link-local
multicast
address
used
for
PIM
messages
is
224.0.0.13.
Since
the
PIM
messages
that
carry
the
BSR
information
are
link-local
in
scope,
notice
that
there
is
no
Time
to
Live
(TTL)
scoping
that
can
be
used
with
BSR.
Note:
BSR
and
AutoRP
cannot
interoperate
directly
with
each
other.
Obviously,
a
key
element
to
the
BSR
process
is
the
device
or
devices
that
want
to
serve
as
the
Rendezvous
Point
for
multicast
groups
in
the
Sparse
Mode
domain.
To
configure
a
candidate-RP
in
BSR,
use
the
following
command:
ip
pim
[vrf
vrf-name]
rp-candidate
interface-type
interface-number
[bidir]
[group-list
access-
list]
[interval
seconds]
[priority
value]
Where:
vrf
-
configures
the
router
to
advertise
itself
as
the
candidate-RP
to
the
Bootstrap
Router
for
the
Virtual
Routing
and
Forwarding
(VRF)
instance
specified
for
the
vrf-name
argument
interface-type
interface-number
-
the
interface
bound
to
the
IP
address
to
serve
as
the
candidate-RP
IP
address;
for
availability
purposes,
consider
the
use
of
a
loopback
interface;
this
interface
needs
to
be
PIM
enabled
bidir
-
optional
-
indicates
that
the
multicast
groups
specified
by
the
access-list
argument
are
to
operate
in
PIM
bidirectional
mode;
PIM
bidirectional
mode
is
covered
in
Chapter
6:
Bidirectional
PIM
group-list
-
optional
-
specifies
the
prefixes
that
are
advertised
in
association
with
the
RP
address;
note
that
unlike
AutoRP,
this
list
cannot
contain
DENY
entries
interval
-
optional
-
specifies
the
candidate-RP
advertisement
interval,
in
seconds;
the
range
is
from
1
to
16383
with
a
default
value
of
60
seconds
priority
-
optional
-
specifies
the
priority
for
the
candidate-RP;
the
range
is
from
0
to
255;
with
a
default
priority
value
of
0;
the
BSR
candidate-RP
with
the
lowest
priority
value
is
preferred;
be
aware
that
other
vendor
implementations
of
BSR
might
default
priority
to
192
as
this
is
the
recommended
default
priority
by
the
IETF
9-3
As
stated
earlier,
the
Bootstrap
Router
itself
in
the
topology
is
similar
to
the
Mapping
Agent
in
AutoRP
with
some
subtle
differences.
Like
the
AutoRP
Mapping
Agent,
the
BSR
listens
to
the
candidate-RP
announcements,
but
the
BSR
does
not
actually
select
the
best
RP
for
every
group
range.
Instead,
the
BSR
builds
a
set
of
candidate-RPs
for
each
group
range
and
disseminates
this
information
to
the
topology
using
PIM.
Multicast
routers
that
receive
these
BSR
messages
select
the
preferred
candidate-RP
using
a
special
hash
function.
To
configure
the
BSR
router
itself,
use
the
following
command:
ip
pim
[vrf
vrf-name]
bsr-candidate
interface-type
interface-number
[hash-mask-length
[priority]
]
Where:
vrf
-
configures
the
router
to
advertise
itself
as
the
Bootstrap
Router
for
the
Virtual
Routing
and
Forwarding
(VRF)
instance
specified
for
the
vrf-name
argument
interface-type
interface-number
-
the
interface
bound
to
the
IP
address
to
serve
as
the
BSR
device
IP
address;
for
availability
purposes,
consider
the
use
of
a
loopback
interface;
this
interface
needs
to
be
PIM
enabled
and
the
IP
address
is
sent
in
BSR
messages
as
the
BSR
IP
address
hash-mask-length
-
optional
-
the
length
of
the
mask
to
be
ANDed
with
the
group
address
before
the
PIMv2
hash
function;
all
groups
with
the
same
seed
hash
correspond
to
the
same
RP;
the
hash
mask
length
allows
one
RP
to
be
used
for
multiple
groups;
the
default
length
is
0
priority
-
priority
of
the
candidate-BSR;
the
range
is
from
0
to
255
with
a
default
priority
of
0;
the
candidate-BSR
with
the
highest
priority
value
is
preferred;
RFC
5059
specifies
that
64
be
used
as
the
default
priority
value
It
is
important
to
remember
that
in
BSR,
the
multicast
routers
determine
the
RP
to
use
based
on
RP-set
information
received
from
the
BSR
itself.
The
RP
selection
process
for
a
particular
multicast
group
is
as
follows:
Step
1
-
a
longest
match
lookup
is
performed
on
the
group
prefix
that
is
announced
by
the
BSR
candidate-RPs
Step
2
-
if
more
than
one
candidate-RP
is
found
by
the
longest
match
lookup,
the
candidate-RP
with
the
lowest
priority
(configured
with
the
ip
pim
rp-candidate
command)
is
preferred
Step
3
-
if
more
than
one
candidate-RP
have
the
same
priority,
the
BSR
hash
function
is
used
to
select
the
RP
for
a
group;
this
hash
function
is
covered
in
detail
in
the
Operation
and
Troubleshooting
BSR
section
of
this
chapter
9-4
Step
4
-
if
more
than
one
candidate-RP
return
the
same
hash
value
derived
from
the
BSR
hash
function,
the
candidate-RP
with
the
highest
IP
address
is
preferred
Note:
RFC
2362
does
not
specify
the
longest
match
lookup
step,
to
ensure
compatibility
with
this
standard,
configure
the
same
group
prefix
length
for
redundant
candidate-RPs.
9-5
9-6
Clearly,
BSR
can
only
be
employed
between
PIM
version
2
enabled
devices.
It
is
important
to
note
that
because
of
this;
BSR
is
not
compatible
with
PIM-SM
version
1.
The
primary
difference
between
PIM-SM
versions
1
and
2
is
that
in
version
2,
messages
are
no
longer
encapsulated
inside
IGMP.
PIM
version
2
messages
are
encapsulated
in
IP
packets
with
a
protocol
number
of
103.
Another
significant
difference
is
that
PIM-SM
version
2
messages
are
propagated
throughout
the
domain
via
the
link-local
multicast
group
224.0.0.13
(ALL-PIM-ROUTERS).
As
described
in
the
BSR
Technology
Review
section,
this
means
that
BSR
does
not
require
any
legacy
dense
mode
functionality
to
announce
its
presence
throughout
the
multicast
domain
as
is
the
case
with
AutoRP.
Fortunately,
these
distinctions
reduce
the
level
of
difficulty
associated
with
troubleshooting
all
phases
of
the
BSR
operational
process.
Placement
of
the
BSR
is
no
longer
as
sensitive
an
issue
as
with
its
AutoRP
counterpart,
the
Mapping
Agent
(MA).
Furthermore,
the
use
of
a
link-local
multicast
address
for
hop-by-hop
flooding
of
BSR
announcements
creates
fewer
overall
issues
compared
to
AutoRP
in
general.
The
fact
that
BSR
uses
a
multicast
address
to
communicate
its
identity
and
presence
to
the
multicast
domain
means
that
this
phase
of
BSR
is
subjected
to
Reverse
Path
Forwarding
(RPF)
checks.
Specifically,
any
messages
destined
for
PIM
speakers
in
the
domain
will
need
to
pass
the
RPF
check
toward
the
IP
address
of
the
BSR
from
the
C-RP.
The
multicast
process
drops
messages
that
fail
this
check.
The
fastest
method
to
determine
that
BSR
announcements
are
being
propagated
successfully
is
to
execute
the
show
ip
pim
bsr-router
command
on
each
of
the
respective
candidate-RPs.
In
a
working
environment,
like
that
shown
in
Figure
9-3,
we
would
expect
to
see
output
similar
to
the
following
for
this
command:
9-7
9-8
Note
that
R4
knows
the
identity
of
the
BSR,
but
has
no
candidate-RP
information
to
communicate.
This
is
a
normal
condition
for
this
stage
of
the
BSR
operation.
It
is
time
to
take
a
closer
look
at
the
second
stage
of
BSR.
Candidate-Rendezvous
Point
Announcement
In
the
previous
section,
the
election
of
the
BSR
was
observed,
and
the
process
of
PIM-SM
version
2
announcements
were
monitored.
This
resulted
in
the
C-RPs
and
other
PIM
devices
participating
in
the
multicast
domain
learning
the
identity
of
the
BSR.
This
section
focuses
on
how
the
BSR
dynamically
learns
the
identity
of
all
devices
configured
as
RP
candidates.
After
a
C-RP
discovers
the
BSR
it
will
immediately
begin
to
send
periodic
C-RP
advertisements
directly
to
the
BSR
every
60
seconds
via
unicast.
This
is
the
default
advertisement
interval
and
can
be
changed.
The
default
holdtime
is
150
seconds.
In
addition
to
notifying
the
BSR
of
its
identity,
the
RP
candidates
also
communicate
what
group-to-RP
mappings
they
possess.
Figure
9-4
illustrates
this
unicast
process.
Let
us
examine
the
BSR
to
see
if
it
is
receiving
the
information
unicast
by
the
individual
C-RPs.
Use
the
show
ip
pim
rp
mapping
command
on
the
BSR
itself
to
accomplish
this:
9-9
9-10
perform
likewise.
Figure
9-5
illustrates
the
hop-by-hop
flooding
process
employed
to
propagate
the
RP-
set
information.
Remember,
this
process
uses
the
PIM-SM
version
2
multicast
address
of
224.0.0.13
to
communicate
with
the
PIM
enabled
devices
in
the
network
on
a
hop-by-hop
basis.
This
process,
because
it
employs
multicast,
is
susceptible
to
the
RPF
check.
The
most
efficient
method
employed
to
test
whether
or
not
the
BSR
has
successfully
communicated
the
RP-set
information
to
each
of
the
devices
in
the
topology
is
to
execute
the
show
ip
pim
rp
mapping
command
on
each
device
participating
in
the
multicast
domain.
This
should
produce
identical
output
on
all
devices
similar
to
the
following:
R4#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 192.1.7.7 (?), v2
Info source: 192.1.2.2
150
Uptime: 01:41:24,
RP 192.1.5.5 (?), v2
Info source: 192.1.2.2
150
Uptime: 01:19:31,
The
critical
component
here
is
that
all
devices
should
have
the
same
group-to-RP
mappings.
Note
that
both
RP
candidates
are
mapped
to
provide
RP
services
to
the
entire
multicast
group
range
of
224.0.0.0/4.
9-11
Which
C-RP
will
assume
the
role
of
RP
if
a
multicast
source
is
introduced
to
the
topology?
Emulate
a
multicast
source
destined
to
the
group
address
of
224.9.9.9
on
the
FastEthernet
interface
of
R1
and
examine
where
the
source-based
tree
terminates:
R1#ping 224.9.9.9 repeat 100000
This
ping
will
not
be
successful
because
there
are
no
multicast
receivers
for
this
group
in
the
topology,
but
it
provides
a
way
to
verify
what
C-RP
will
assume
the
role
of
RP
for
the
group
224.9.9.9.
This
is
proven
using
the
show
ip
pim
rp
command
on
both
R5
and
R7:
R5#show ip pim rp
Group: 224.9.9.9, RP: 192.1.7.7, v2, uptime 01:34:58, expires 00:01:30
R7#show ip pim rp
Group: 224.9.9.9, RP: 192.1.7.7, v2, next RP-reachable in 00:00:16
The
output
indicates
that
the
RP
is
R7
(192.1.7.7).
The
BSR
process
selects
R7
as
the
RP
because
the
assigned
priority
for
each
of
the
candidates
is
the
same.
In
this
topology,
the
Cisco
default
of
priority
of
0
is
used.
In
instances
where
the
priority
is
a
tie,
the
determining
factor
for
RP
selection
is
the
highest
IP
address
as
described
in
the
BSR
Technology
Review
section.
Once
again,
it
is
critical
to
note
that
this
process
of
RP
selection
is
not
performed
by
the
BSR.
Unlike
the
mapping
agent
in
AutoRP,
the
Bootstrap
Router
communicates
the
entire
RP-set
to
the
devices
in
the
multicast
domain.
The
individual
devices
accept
the
RP-set
and
then
make
logical
decisions
as
to
which
C-RP
they
select.
Network
administrators
can
manipulate
or
influence
this
election
process
through
the
use
of
hashes,
priorities,
filters,
and
message
constraints.
Load
Balancing
Between
Candidate-RPs
It
is
possible
to
distribute
RP
functionality
between
multiple
C-RPs
when
configuring
BSR.
This
load
balancing
is
not
always
a
perfectly
balanced
approach
between
individual
RPs.
However,
using
factors
like
the
total
number
of
available
C-RPs
and
an
optional
value
known
as
the
hash
mask
length
can
provide
an
approximation
of
load
balancing.
Assigning
a
value
to
the
hash
mask
length
greater
than
the
default
of
"0"
directly
affects
the
normal
RP
selection
algorithm
that
runs
on
all
PIM-SM
version
2
enabled
devices.
Hash
mask
length
is
communicated
to
all
devices
inside
the
BSR
announcements.
Generally,
the
longer
the
hash
length,
the
more
evenly
the
BSR
process
will
try
to
assign
groups
to
individual
RPs
in
the
candidate
RP-Set.
The
assumptions
are
that
the
same
hash
mask
length
is
communicated
to
each
PIM-SM
version
2
device
by
the
BSR,
and
that
each
of
those
devices
has
the
same
candidate
RP-set.
As
a
result,
each
PIM
device
runs
the
same
algorithm
and
makes
the
same
RP
selection
for
each
multicast
group.
9-12
There
are
three
values
used
by
this
mathematical
function
in
BSR:
the
candidate-RP
address,
a
multicast
group
address,
and
the
hash
mask
length.
These
values
are
all
hashed
together
on
a
group-by-group
basis
in
order
to
approximate
the
load
balancing.
This
process
can
be
summarized
as
follows:
1
-
A
hashing
algorithm
is
run
for
each
multicast
group
address
for
each
C-RP
in
the
RP-set
and
a
hash
value
is
obtained.
2
-
The
C-RP
with
the
highest
calculated
hash
value
becomes
the
RP
for
that
particular
multicast
group.
3
-
There
is
the
possibility
that
the
hashing
algorithm
will
result
in
equal
hash
values
for
different
C-RPs.
In
this
case,
the
C-RP
with
the
highest
IP
address
will
become
the
RP
for
that
group.
With
all
this
taken
into
account,
the
outcome
should
be
predicable:
2(32
-
hash
length)
=
#
of
RPs
that
will
be
used
in
load
balancing*
*
This
assumes
that
there
are
enough
C-RPs
in
the
RP-set
to
allow
an
even
distribution.
Figure
9-6
shows
a
sample
topology
for
load
balancing.
In
this
example,
there
are
two
candidate-RPs.
In
order
to
achieve
the
most
even
distribution
between
these
devices
apply
a
hash
mask
length
of
31
to
the
ip
pim
bsr-candidate
command
on
R2:
R2(config)#ip pim bsr-candidate Loopback0 31
Now
verify
what
RP
each
device
in
the
topology
will
use
for
any
given
group
through
the
use
of
the
show
ip
pim
rp-hash
command.
Here
is
such
a
test
on
R4
using
the
multicast
group
addresses
of
224.1.1.1
and
224.1.1.2:
9-13
9-14
to
to
to
to
request
request
request
request
0
1
2
3
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
4
1
1
1
ms
ms
ms
ms
9-15
Candidate-BSRs
do
not
agree
on
the
identity
of
the
BSR
for
the
multicast
domain.
All
or
some
of
the
PIM-SM
version
2
enabled
devices
in
the
multicast
domain
do
not
receive
any
candidate
RP-set
information
from
the
elected
BSR.
We
will
perform
a
walk
through
for
each
of
these
RPF
issues
in
the
BSR
Sample
Troubleshooting
Scenarios
section
that
follows.
Unicast
Routing
and
Forwarding
Problems
From
earlier
portions
of
this
chapter,
it
is
clear
that
the
ability
of
the
RP
candidates
to
communicate
their
candidate
group-to-RP
mapping
information
directly
to
the
BSR
is
dependent
on
their
ability
to
unicast
to
the
advertised
IP
address
of
the
BSR.
Of
course,
since
this
reachability
is
unicast,
it
is
not
subject
to
RPF
checks.
As
a
result,
a
common
issue
is:
An
elected
BSR
fails
to
learn
candidate
group-to-RP
mappings
from
all
or
some
of
the
C-RPs
in
the
topology
and
the
IP
address
of
the
candidate
RP(s)
are
not
reachable
when
ICMP
echoes
are
sourced
from
the
IP
address
of
the
BSR.
9-16
This
is
a
situation
where
it
will
be
necessary
to
look
at
the
underlying
routing
protocols
used
in
the
network.
Typically,
this
would
be
an
issue
of
asynchronous
routing,
and
should
be
something
obvious
once
the
routing
tables
of
the
source
and
transit
devices
are
analyzed.
Multicast
Routing
and
Forwarding
Problems
These
problems
manifest
themselves
in
more
subtle
ways
when
compared
to
the
previous
points.
As
discussed
earlier,
the
majority
of
the
BSR
operational
mechanisms
involve
the
formation
of
the
control
plane
so
that
a
device
can
be
assigned
as
the
BSR,
and
so
that
C-RP
group-to-RP
mappings
can
be
communicated
to
the
BSR.
From
that
point,
the
candidate
RP-set
information
can
be
propagated
throughout
the
multicast
domain.
Situations
like
the
following
exist
when
information
fails
to
propagate
to
any
or
all
devices,
but
RPF
checks
and
unicast
routing
seem
to
be
functioning
correctly:
One
or
more
candidate-RP(s)
fail
to
receive
any
c-RP-set
information
from
the
BSR.
One
or
more
candidate-BSR
fails
to
participate
in
the
BSR
election
process
resulting
in
the
assignment
of
more
than
one
BSR.
In
the
BSR
Sample
Troubleshooting
Scenarios
section
that
follows,
troubleshooting
these
issues
are
demonstrated.
For
each
problem,
the
text
demonstrates
how
to
quickly
and
efficiently
verify
each
symptom,
isolate
the
cause,
and
remediate
the
issue.
9-17
In
the
Common
Issues
with
BSR
section,
three
primary
types
of
problems
were
identified:
RPF
failures,
unicast
routing
failures,
and
multicast
forwarding
and
routing
failures.
This
section
explores
these
three
categories
of
failure,
by
directing
our
attention
to
the
commands
necessary
to
identify
that
a
problems
exists.
There
are
three
types
of
devices
in
this
topology:
C-RP(s),
C-BSR(s),
and
transit
devices
(PIM
enabled
routers).
Step
One:
Which
device
won
the
BSR
election
-
R5
or
R7?
R5#show ip pim bsr-router
PIMv2 Bootstrap information
This system is the Bootstrap Router (BSR)
BSR address: 192.1.5.5 (?)
Uptime:
00:01:35, BSR Priority: 0, Hash mask length: 0
Next bootstrap message in 00:00:25
R5
believes
that
it
is
the
PIM
version
2
Bootstrap
Router.
Given
that
the
priority
is
zero,
this
seems
odd,
because
R7
has
a
higher
IP
address.
Issue
the
same
show
command
on
R7:
9-18
R7
has
also
elected
itself
as
the
Bootstrap
Router.
It
is
not
possible
for
this
to
happen
in
a
correctly
configured
BSR
environment.
This
issue
seems
to
indicate
that
the
two
candidate-BSR
devices
have
failed
to
exchange
their
BSR
announcement
messages.
How
are
those
BSR
announcement
messages
exchanged?
As
discussed
previously,
PIM-SM
version
2
messages
exchange
the
BSR
information,
and
these
Bootstrap
messages
are
how
the
C-BSRs
discover
each
other
and
decide
which
assumes
the
role
of
the
BSR.
The
link-local
multicast
group
224.0.0.13
accomplishes
this
process
and
is
subject
to
the
RPF
check
mechanism.
There
are
a
number
of
ways
to
isolate
RPF
issues
(mstat,
mtrace,
show
ip
rpf,
debug
ip
pim
bsr),
but
mstat
and
mtrace
cannot
be
used
with
link-local
multicast
as
they
result
in
a
"%
bad
IP
group
address"
message.
Eliminating
the
mstat
and
mtrace
commands
leaves
either
show
ip
rpf
or
debug
ip
pim
bsr,
or
some
combination
of
both.
However,
this
brings
up
an
issue
that
should
be
considered.
The
BSR
advertisement
interval
is
fixed
at
60
seconds
and
cannot
be
changed.
This
means
valuable
time
could
be
wasted
waiting
for
results
using
debug
ip
pim
bsr
on
all
devices
in
the
multicast
path.
This
leaves
show
ip
rpf
as
the
best
option
to
isolate
this
issue.
Does
R5
have
any
RPF
issues
reaching
R7's
Loopback0
interface?
R5#show ip rpf 192.1.7.7
RPF information for ? (192.1.7.7)
RPF interface: FastEthernet0/1
RPF neighbor: ? (172.16.45.4)
RPF route/mask: 192.1.7.0/24
RPF type: unicast (eigrp 100)
RPF recursion count: 0
Doing distance-preferred lookups across tables
No,
it
does
not.
Does
R7
have
any
issues
reaching
R5's
Loopback0
interface?
9-19
R7
does
in
fact
have
an
issue
related
to
RPF
failure.
How
would
R7
reach
the
IP
address
of
192.1.5.5:
R7#show ip route 192.1.5.5
Routing entry for 192.1.5.0/24
Known via "eigrp 100", distance 90, metric 163840, type internal
Redistributing via eigrp 100
Last update from 172.16.67.6 on FastEthernet0/0, 01:59:59 ago
Routing Descriptor Blocks:
* 172.16.67.6, from 172.16.67.6, 01:59:59 ago, via FastEthernet0/0
Route metric is 163840, traffic share count is 1
Total delay is 5400 microseconds, minimum bandwidth is 100000
Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 4
R7
will
use
FastEthernet0/0
as
the
RPF
interface.
An
RPF
interface
must
be
configured
to
participate
in
PIM-SM
version
2
for
BSR
messages
to
be
exchanged
successfully.
Use
the
show
ip
pim
interface
command
to
most
quickly
verify
if
this
is
taking
place.
R7#show ip pim interface
FastEthernet0/0
is
not
in
the
interface
list.
To
remediate
this,
enable
PIM-SM
version
2
on
R7's
FastEthernet0/0
interface.
R7(config)#int FastEthernet0/0
R7(config-if)#ip pim sparse-mode
Note
the
PIM
neighborship
between
R7
and
R6
immediately
comes
up.
R7(config-if)#
%PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 172.16.67.7 on
interface FastEthernet0/0
9-20
Verification
in
now
necessary
to
determine
if
one
BSR
has
been
elected.
Based
on
the
equal
priority
values,
R7
should
be
elected
as
the
BSR.
R7#show ip pim bsr-router
PIMv2 Bootstrap information
This system is the Bootstrap Router (BSR)
BSR address: 192.1.7.7 (?)
Uptime:
00:47:31, BSR Priority: 0, Hash mask length: 0
Next bootstrap message in 00:00:29
And
R5
should
agree:
R5#show ip pim bsr
PIMv2 Bootstrap information
BSR address: 192.1.7.7 (?)
Uptime:
00:03:15, BSR Priority: 0, Hash mask length: 0
Expires:
00:01:54
This system is a candidate BSR
Candidate BSR address: 192.1.5.5, priority: 0, hash mask length: 0
This
output
indicates
that
both
R5
and
R7
agree
that
R7
(192.1.7.7)
is
the
BSR.
Note
that
R5
maintains
its
Candidate-BSR
status;
it
will
opt
to
elect
itself
BSR
should
R7
stop
functioning.
This
is
part
of
the
normal
Active/Passive
failover
mechanism
employed
by
BSR.
Having
corrected
the
issue
related
to
the
actual
election
of
the
BSR,
the
next
step
is
to
determine
whether
or
not
the
BSR
is
learning
each
of
the
C-RP
RP-sets.
This
is
best
accomplished
with
the
show
ip
rp
mapping
command
on
the
BSR
itself.
9-21
The
BSR
is
only
learning
about
R6's
RP-Set
information
for
the
multicast
scope
of
224.0.0.0/4.
How
are
the
C-RPs
communicating
this
information
to
the
BSR?
Unicast
routing
is
used
to
deliver
this
information
from
the
C-RP,
but
multicast
is
used
by
the
BSR
to
communicate
its
presence
to
the
individual
C-RPs.
Has
the
BSR
successfully
communicated
its
existence
to
both
C-RPs?
R4#show ip pim bsr-router
PIMv2 Bootstrap information
BSR address: 192.1.7.7 (?)
Uptime:
00:03:21, BSR Priority: 0, Hash mask length: 0
Expires:
00:01:48
Candidate RP: 192.1.4.4(Loopback0)
Holdtime 150 seconds
Advertisement interval 60 seconds
Next advertisement in 00:00:35
R6#show ip pim bsr-router
PIMv2 Bootstrap information
BSR address: 192.1.7.7 (?)
Uptime:
00:54:57, BSR Priority: 0, Hash mask length: 0
Expires:
00:01:12
Candidate RP: 192.1.6.6(Loopback0)
Holdtime 150 seconds
Advertisement interval 60 seconds
Next advertisement in 00:00:22
R4
and
R6
know
that
R7
is
the
BSR.
These
C-RPs
now
unicast
their
RP-Set
information
to
the
BSR
for
dissemination
throughout
the
multicast
domain.
Knowing
that
this
is
a
unicast
problem,
the
most
9-22
effective
tool
now
is
ping.
Remember,
the
unicast
of
the
RP-Set
information
will
be
sourced
and
destined
to
specific
IP
addresses,
and
the
easiest
method
of
testing
reachability
is
to
verify
from
the
BSR.
Specifically,
pings
should
be
sourced
from
the
IP
address
of
the
BSR
to
the
IP
address
of
each
C-RP.
R7#ping 192.1.6.6 source 192.1.7.7
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.1.6.6, timeout is 2 seconds:
Packet sent with a source address of 192.1.7.7
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
Based
on
the
fact
that
the
BSR
learned
the
RP-set
information
for
R6,
it
should
come
as
no
surprise
that
unicast
reachability
exists.
R4,
however,
is
the
C-RP
in
question:
R7#ping 192.1.4.4 source 192.1.7.7
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.1.4.4, timeout is 2 seconds:
Packet sent with a source address of 192.1.7.7
.....
Success rate is 0 percent (0/5)
This
output
is
proof
of
a
unicast
routing
problem
between
R7
and
R4.
Now,
several
options
can
be
used
including
pinging
almost
every
interface
between
the
two
devices.
The
best
course
of
action
in
this
scenario
would
be
to
utilize
the
traceroute
command
from
the
BSR
using
the
same
source
and
destination
used
in
the
ping
test:
9-23
This
output
clearly
illustrates
the
fact
that
the
unicast
issue
exits
on
the
router
immediately
after
R2.
According
to
the
topology,
this
is
R4
itself.
Go
to
R4
and
verify
the
contents
of
the
routing
table.
Specifically,
the
IP
address
of
interest
is
the
Loopback0
interface
of
R7
(192.1.7.7):
R4#show ip route 192.1.7.7
Routing entry for 192.1.7.7/32
Known via "static", distance 1, metric 0 (connected)
Routing Descriptor Blocks:
* directly connected, via Null0
Route metric is 0, traffic share count is 1
Based
on
this
output,
any
traffic
destined
to
R7's
Loopback0
interface
is
immediately
forwarded
to
the
Null0
interface
via
the
static
route
configured.
To
remediate
this
problem,
the
best
course
of
action
is
to
remove
this
static
route,
and
then
check
if
R7
begins
to
learn
RP-sets
from
both
R4
and
R6.
R4(config)#no ip route 192.1.7.7 255.255.255.255 null 0
Verification
on
R7
should
show
that
both
R4
and
R6
are
now
sending
their
respective
RP-Set
information
to
the
BSR:
9-24
R6
(192.1.6.6)
and
R4
(192.1.4.4)
have
actually
succeeded
in
communicating
their
RP-sets
to
the
BSR.
Now
that
the
BSR
has
learned
each
of
these
sets,
the
BSR
will
communicate
this
information
to
all
PIM-
SM
version
2
enabled
devices
in
the
multicast
domain.
This
is
observed
by
issuing
the
show
ip
pim
rp
mapping
command
on
each
device:
R1#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 192.1.6.6 (?), v2
Info source: 192.1.7.7
150
Uptime: 00:12:33,
RP 192.1.4.4 (?), v2
Info source: 192.1.7.7
150
Uptime: 01:11:37,
9-25
R5#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 192.1.6.6 (?), v2
Info source: 192.1.7.7
150
Uptime: 00:12:33,
RP 192.1.4.4 (?), v2
Info source: 192.1.7.7
150
Uptime: 01:11:37,
9-26
R7#show ip pim rp mapping
PIM Group-to-RP Mappings
This system is the Bootstrap Router (v2)
Group(s) 224.0.0.0/4
RP 192.1.6.6 (?), v2
Info source: 172.16.67.6 (?), via bootstrap, priority 0, holdtime
150
Uptime: 02:10:14, expires: 00:02:14
RP 192.1.4.4 (?), v2
Info source: 172.16.24.4 (?), via bootstrap, priority 0, holdtime
150
Uptime: 00:11:37, expires: 00:01:49
R9#show ip pim rp mapping
PIM Group-to-RP Mappings
R9
has
not
received
any
RP-Set
information
from
the
BSR.
How
is
this
information
being
communicated?
Recall
that
BSR
announcements
are
sent
via
multicast.
Multicast
traffic
is
susceptible
to
RPF
checks.
Failure
of
the
multicast
traffic
to
pass
the
RPF
check
can
be
verified
via
the
show
ip
rpf
command
on
R9.
This
test
should
be
done
toward
the
IP
address
of
the
BSR.
9-27
This
output
indicates
that
there
are
no
RPF
issues.
This
begs
the
question,
"If
there
are
no
RPF
failures,
what
else
can
cause
problems
with
multicast
traffic?"
The
answer
-
issues
related
to
the
forwarding,
routing,
and
filtering
of
multicast
traffic.
debug
ip
pim
bsr
is
the
best
tool
for
troubleshooting
issues
on
one
device
associated
with
multicast
forwarding
and
how
this
can
specifically
effect
BSR
messages:
R9#debug ip pim bsr
PIM-BSR debugging is on
R9#
PIM-BSR(0): bootstrap dropped
In
this
particular
instance,
the
output
of
the
debug
command
states
specifically
that
the
bootstrap
packets
are
being
dropped.
This
message
will
appear
every
60
seconds,
as
new
BSR
announcements
arrive
from
R7.
Why
are
the
packets
being
dropped?
Careful
observation
will
show
that
under
the
FastEthernet0/1
interface
of
R9
someone
has
configured
the
ip
pim
bsr-border
command.
9-28
9-29
As
a
final
verification,
a
simulated
source
generated
on
R1
bound
for
the
multicast
group
224.9.9.9
can
successfully
reach
R9's
FastEthernet0/1
interface:
R1#ping 224.9.9.9 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 224.9.9.9, timeout is 2 seconds:
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
to
to
to
to
to
to
to
to
to
to
request
request
request
request
request
request
request
request
request
request
0
1
2
3
4
5
6
7
8
9
from
from
from
from
from
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
1
1
1
1
1
1
1
1
1
1
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
9-30
show
COMMAND:
show
ip
pim
[vrf
vrf-name]
bsr-router
This
command
displays
information
about
a
bootstrap
router
(BSR)
Where:
EXAMPLE
OUTPUT:
R1#show ip pim bsr-router
PIMv2 Bootstrap information
BSR address: 192.1.2.2 (?)
Uptime:
00:26:57, BSR Priority: 0, Hash mask length: 0
Expires:
00:01:12
9-31
show
COMMAND:
show
ip
pim
[vrf
vrf-name]
rp-hash
{group-address
|
group-name}
This
command
displays
the
mappings
for
the
PIM
group
to
the
active
Rendezvous
Point(s).
Where:
EXAMPLE
OUTPUT:
R4#show ip pim rp-hash 224.9.9.9
RP 192.1.7.7 (?), v2
Info source: 192.1.2.2 (?), via bootstrap, priority 0, holdtime
150
Uptime: 03:32:33, expires: 00:01:27
PIMv2 Hash Value (mask 0.0.0.0)
RP 192.1.7.7, via bootstrap, priority 0, hash value 390961567
RP 192.1.5.5, via bootstrap, priority 0, hash value 119808709
show
COMMAND:
show
ip
pim
[vrf
vrf-name]
rp
mapping
[rp-address]
This
command
displays
the
mappings
for
the
PIM
group
to
the
active
Rendezvous
Point(s).
Where:
EXAMPLE
OUTPUT:
R4#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 192.1.7.7 (?), v2
Info source: 192.1.2.2 (?), via bootstrap, priority 0, holdtime
150
Uptime: 03:45:33, expires: 00:01:29
RP 192.1.5.5 (?), v2
9-32
EXAMPLE
OUTPUT:
R5#show ip rpf 192.1.2.2
RPF information for ? (192.1.2.2)
RPF interface: FastEthernet0/1
RPF neighbor: ? (172.16.45.4)
RPF route/mask: 192.1.2.0/24
RPF type: unicast (eigrp 100)
RPF recursion count: 0
Doing distance-preferred lookups across tables
show
COMMAND:
show
ip
pim
[vrf
vrf-name]
neighbor
[interface-type
interface-number]
This
command
displays
information
about
Protocol
Independent
Multicast
(PIM)
neighbors
discovered
by
PIM
version
1
router
query
messages
or
PIM
version
2
hello
messages.
9-33
Where:
EXAMPLE
OUTPUT:
R4#show ip pim neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR
Priority,
S - State Refresh Capable
Neighbor
Interface Uptime/Expires
Ver
DR Address
Prio/Mode
172.16.45.5 FastEthernet0/1 01:17:41/00:01:25 v2
1 / DR S
172.16.46.6 Serial0/0/0.1
01:16:39/00:01:19 v2
1 / S
9-34
debug
COMMAND:
debug
ip
mpacket
[vrf
vrf-name]
[detail
|
fastswitch]
[access-list]
[group]
This
command
displays
multicast
packets
that
are
received
and
sent
on
the
device.
Where:
EXAMPLE
OUTPUT:
IP(0): s=172.16.24.4 (FastEthernet0/0) d=224.9.9.9 id=7, ttl=254,
prot=1, len=114(100), mroute olist null
IP(0): s=172.16.24.4 (FastEthernet0/0) d=224.9.9.9 id=8, ttl=254,
prot=1, len=114(100), mroute olist null
IP(0): s=172.16.24.4 (FastEthernet0/0) d=224.9.9.9 id=9, ttl=254,
prot=1, len=114(100), mroute olist null
9-35
debug
COMMAND:
debug
ip
pim
[vrf
vrf-name]
[bsr]
This
command
displays
the
mappings
for
the
PIM
group
to
the
active
Rendezvous
Point(s).
Where:
EXAMPLE
OUTPUT:
R4#debug ip pim bsr
PIM-BSR debugging is on
R4#
PIM-BSR(0): 192.1.2.2
PIM-BSR(0): 192.1.2.2
PIM-BSR(0): bootstrap
from non-RPF neighbor
0
0
Holdtime 150
Holdtime 150
pim bsr
Build v2 Candidate-RP advertisement for 192.1.5.5 priority
150
Candidate RP's group prefix 224.0.0.0/4
Send Candidate RP Advertisement to 192.1.2.2
9-36
Trouble
Ticket
#1
Your
supervisor
has
brought
to
your
attention
that
the
C-BSR
routers
R2
and
R7
do
not
agree
on
the
identity
of
the
BSR.
You
must
correct
the
issue.
Trouble
Ticket
#2
After
solving
Trouble
Ticket
#1,
your
supervisor
has
observed
that
a
new
C-BSR
(R5)
that
has
just
been
introduced
in
the
network
does
not
agree
with
R2
and
R7
regarding
the
identity
of
the
Bootstrap
Router.
Correct
this
issue.
Trouble
Ticket
#3
Your
supervisor
has
notified
you
that
R1
is
not
receiving
any
RP-set
information
from
the
BSR.
You
must
correct
this
issue.
9-37
Figure
9-11:
BSR
Quick
Fire
Troubleshooting
Flowchart
Trouble
Ticket
#1
Solution
Your
supervisor
has
brought
to
your
attention
that
the
C-BSR
routers
R2
and
R7
do
not
agree
on
the
identity
of
the
BSR.
You
must
correct
the
issue.
9-38
9-39
9-40
9-41
9-42
R2
and
R7
agree
that
R7
is
the
BSR,
but
R5
is
reporting
itself
as
the
BSR
in
the
topology.
This
verifies
that
the
problem
actually
exists.
Step
2
-
Fault
Isolation:
In
order
to
verify
that
RPF
issues
are
not
at
fault,
use
the
mtrace
utility.
Perform
this
check
in
both
directions,
first
from
R2
toward
R5,
and
then
in
reverse.
R2#mtrace 192.1.2.2 192.1.7.7
Type escape sequence to abort.
Mtrace from 192.1.2.2 to 192.1.7.7 via RPF
From source (?) to destination (?)
Querying full reverse path...
0 192.1.7.7
-1 172.16.67.7 PIM [192.1.2.0/24]
-2 172.16.67.6 PIM [192.1.2.0/24]
-3 172.16.26.2 PIM [192.1.2.0/24]
-4 192.1.2.2
R5#mtrace 192.1.5.5 192.1.2.2
Type escape sequence to abort.
Mtrace from 192.1.5.5 to 192.1.2.2 via RPF
From source (?) to destination (?)
Querying full reverse path...
0 192.1.2.2
-1 172.16.24.2 PIM [192.1.5.0/24]
-2 172.16.24.4 PIM [192.1.5.0/24]
-3 172.16.45.5 PIM [192.1.5.0/24]
-4 192.1.5.5
Next
is
the
verification
of
the
BSR
messaging.
Use
the
debug
ip
pim
bsr
command
on
R2,
R4
and
R5:
R2#debug ip pim bsr
PIM-BSR debugging is on
R2#
PIM-BSR(0): 192.1.7.7 bootstrap forwarded on Loopback0
PIM-BSR(0): 192.1.7.7 bootstrap forwarded on GigabitEthernet0/0
R2
is
sending
BSR
announcements
out
the
Gi0/0
interface
directed
to
R4.
9-43
9-44
Once
the
error
has
been
isolated
and
remediated,
it
is
highly
recommended
to
verify
that
the
Trouble
Ticket
has
been
repaired
using
the
same
method
used
to
verify
the
fault
initially:
R2#show ip pim bsr-router
PIMv2 Bootstrap information
BSR address: 192.1.7.7 (?)
Uptime:
00:36:11, BSR Priority: 255, Hash mask length: 0
Expires:
00:01:58
This system is a candidate BSR
Candidate BSR address: 192.1.2.2, priority: 200, hash mask length: 0
R7#show ip pim bsr-router
PIMv2 Bootstrap information
This system is the Bootstrap Router (BSR)
BSR address: 192.1.7.7 (?)
Uptime:
04:48:37, BSR Priority: 255, Hash mask length: 0
Next bootstrap message in 00:00:23
R5#show ip pim bsr-router
PIMv2 Bootstrap information
BSR address: 192.1.7.7 (?)
Uptime:
00:02:06, BSR Priority: 255, Hash mask length: 0
Expires:
00:02:03
This system is a candidate BSR
Candidate BSR address: 192.1.5.5, priority: 250, hash mask length: 0
All
three
C-BSRs
agree
that
R7
is
the
BSR.
Trouble
Ticket
#3
Solution
Your
supervisor
has
notified
you
that
R1
is
not
receiving
any
RP-set
information
from
the
BSR.
You
must
correct
this
issue.
Step
1
-
Fault
Verification:
R1
is
the
router
of
interest
in
this
trouble
ticket:
9-45
9-46
9-47
9-48
Chapter
10:
Multicast
Source
Discovery
Protocol
(MSDP)
In
this
chapter
of
IPv4/6
Multicast
Operation
and
Troubleshooting,
the
processes
and
functionality
of
the
Multicast
Source
Discovery
Protocol
(MSDP)
are
examined
in
great
depth.
Once
the
operational
characteristics
of
this
important
protocol
are
detailed
completely,
the
focus
becomes
that
of
troubleshooting.
This
includes
the
careful
examination
of
symptoms,
a
fault
isolation
methodology,
and
the
implementation
of
repairs
for
the
Multicast
Source
Discovery
Protocol
(MSDP).
The
chapter
begins
with
a
thorough
review
of
MSDP,
and
then
quickly
launches
in
to
an
exhaustive
analysis
of
the
art
of
troubleshooting
this
multicast
support
protocol.
This
important
chapter
concludes
with
sample
troubleshooting
scenarios,
reference
materials
for
the
most
important
show
and
debug
commands,
and
exciting
challenges
that
allow
readers
to
practice
implementing
the
troubleshooting
skills
they
have
obtained.
10-1
10-2
The
originating
RP
continues
to
send
periodic
SA
messages
for
the
(S,
G)
state
every
60
seconds
for
as
long
as
the
source
is
sending
packets
to
the
group.
When
an
RP
receives
an
SA
message,
it
caches
the
SA
message.
There
are
four
basic
MSDP
message
types,
each
encoded
in
their
own
Type,
Length,
and
Value
(TLV)
data
format.
These
messages
are:
SA
Messages
SA
Request
Messages
SA
Response
Messages
Keepalive
Messages
SA
messages
are
used
to
advertise
active
sources
in
a
domain.
In
addition,
these
SA
messages
may
contain
the
initial
multicast
data
packet
that
was
sent
by
the
source.
SA
messages
contain
the
IP
address
of
the
originating
RP
and
one
or
more
(S,
G)
pairs
being
advertised.
In
addition,
the
SA
message
may
contain
an
encapsulated
data
packet.
SA
request
messages
are
used
to
request
a
list
of
active
sources
for
a
specific
group.
These
messages
are
sent
to
an
MSDP
SA
cache
that
maintains
a
list
of
active
(S,
G)
pairs
in
its
SA
cache.
Join
latency
can
be
reduced
by
using
SA
request
messages
to
request
the
list
of
active
sources
for
a
group
instead
of
having
to
wait
up
to
60
seconds
for
all
active
sources
in
the
group
to
be
readvertised
by
originating
RPs.
SA
response
messages
are
sent
by
the
MSDP
peer
in
response
to
an
SA
request
message.
SA
response
messages
contain
the
IP
address
of
the
originating
RP
and
one
or
more
(S,
G)
pairs
of
the
active
sources
in
the
originating
RP's
domain
that
are
stored
in
the
cache.
Keepalive
messages
are
sent
every
60
seconds
in
order
to
keep
the
MSDP
session
active.
If
no
keepalive
messages
or
SA
messages
are
received
for
75
seconds,
the
MSDP
session
is
reset.
10-3
10-4
These
SA
messages
are
forwarded
away
from
the
RP
address
using
what
is
referred
to
as
a
peer-RPF
flooding
process.
In
this
method
of
flooding
the
multicast
routing
table
is
used
to
determine
which
peer
would
be
used
to
reach
the
originating
RP
of
a
given
SA
message;
this
peer
is
called
an
MSDP
"RPF
Peer".
MSDP
RPF
Failure
There
can
be
situation
where
an
MSDP
peer
receives
an
SA
message
from
what
it
would
consider
a
non-
RPF
MSDP
peer.
This
means
that
this
peer
would
not
be
used
to
reach
the
originating
RP.
In
this
situation,
the
receiving
peer
will
drop
the
SA
message.
If
the
message
arrives
from
an
RPF-Peer
toward
the
originating
RP,
then
that
SA
message
will
be
forwarded
to
all
the
devices
MSDP
peers.
Note
that
this
forwarding
process
will
be
not
be
performed
out
the
interface
the
SA
message
arrived
on;
in
order
to
prevent
looping
of
the
SA
messages.
SA
Message
Arrives
on
the
RP
in
the
Other
Multicast
Domain
As
a
result
of
the
peer-RPF
flooding
process
an
SA
message
will
ultimately
arrive
on
the
actual
RP
in
another
multicast
domain.
At
this
time
this
RP
will
determine
if
there
are
any
group
members
in
the
domain
that
are
interested
in
receiving
any
group
defined
by
the
particular
S,G
pair
associated
with
the
particular
SA
message.
This
process
takes
place
by
the
router
looking
for
a
*,G
entry
in
the
multicast
routing
table
for
the
group
with
any
interface
in
the
OIL.
The
fact
that
the
OIL
has
any
other
value
than
"Null"
implies
that
there
is
a
host
in
the
domain
interested
in
the
particular
group.
In
this
situation
the
RP
will
trigger
a
S,G
join
message
that
will
be
set
toward
the
multicast
source.
This
process
is
emulates
the
exact
mechanism
used
when
a
Join/Prune
message
is
received
that
is
addressed
to
the
RP
itself.
This
process
is
how
the
source-based
tree
is
created
to
reach
this
domain.
Any
data
packets
that
subsequently
arrive
at
the
RP
via
this
source-based
tree
will
be
forwarded
down
the
shared
tree
inside
the
domain
toward
the
receivers.
At
this
point
if
any
leaf
routers
choose
to
join
the
source-based
tree
they
can
do
so
using
the
standard
PIM-SM
mechanisms
described
in
previous
chapters.
With
this
in
mind
it
is
useful
to
note
that
if
an
RP
in
a
domain
receives
a
PIM
Join
message
for
a
new
group
(G),
the
RP
should
trigger
a
PIM
Join/Prune
message
for
each
active
S,G
entry
it
learns
from
its
MSDP
Peers
via
the
SA
messages.
This
process
is
often
times
referred
to
as
flood-and-join,
a
parody
of
flood
and
prune.
However,
in
flood-and-join,
if
an
RP
is
not
interested
in
a
group
it
can
ignore
any
SA
messages
for
that
group.
10-5
SA
Cache
An
MSDP
speaker
caches
SA
messages.
This
caching
process
allows
MSDP
messages
to
be
stored
locally.
This
mechanism
reduces
join
latency
for
new
receivers
of
a
particular
multicast
group
of
an
originating
RP
which
has
an
existing
MSDP
(S,G)
state
for
that
group.
This
process
paces
the
replication
of
SA
messages
between
MSDP
peers.
An
additional
benefit
to
this
process
is
that
it
makes
diagnosis,
and
debugging
of
various
problems
easier.
10-6
Beware
of
issues
where
these
have
been
deployed
incorrectly
or
in
situations
where
previous
configurations
have
not
been
completely
removed.
10-7
In
the
Common
Issues
with
MSDP
section,
three
primary
types
of
problems
were
identified:
Incorrect
Peering
Configuration,
No
PIM
Enabled
Path
Between
MSDP
Peers,
and
MSDP
Passwords
and
Filters.
This
section
explores
these
three
categories
of
failure,
by
directing
our
attention
to
the
commands
necessary
to
identify
that
a
problems
exists.
There
are
three
types
of
devices
in
this
topology:
Sources
(R1),
Hosts
(R9),
and
MSDP
peered
Static
RPs
(R5
and
R7).
Incorrect
Peering
Configuration
This
situation
is
where
an
MSDP
enabled
RP
is
not
peering
correctly.
This
situation
is
very
common.
Setting
the
Stage:
Generate
a
multicast
ping
from
R1
for
the
multicast
group
224.1.1.1
with
high
repeat
count:
R1#ping 224.1.1.1 repeat 10000
Type escape sequence to abort.
Sending 10000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
................ <output omitted>
10-8
Now
that
R1
is
generating
the
multicast
stream,
we
need
to
see
if
R5
is
sending
an
SA
message
to
its
MSDP
peer.
This
is
accomplished
via
show
ip
msdp
peer:
R5#show ip msdp peer 192.1.7.7 advertised-SAs
MSDP SA advertised to peer 192.1.7.7 (?) from mroute table
224.1.1.1
172.16.15.1 (?)
MSDP SA advertised to peer 192.1.7.7 (?) from SA cache
This
output
indicates
that
R5
is
advertising
an
SA
message
for
the
S,G
pair
of
224.1.1.1,
172.16.15.1
to
the
peer
located
at
192.1.7.7.
What
is
the
status
of
the
TCP
session
to
this
MSDP
Peer?
R5#show ip msdp peer 192.1.7.7
MSDP Peer 192.1.7.7 (?), AS ?
Connection status:
State: Down, Resets: 0, Connection source: Loopback0 (192.1.5.5)
Uptime(Downtime): 00:04:03, Messages sent/received: 0/0
Output messages discarded: 0
Connection and counters cleared 00:04:03 ago
SA Filtering:
Input (S,G) filter: none, route-map: none
Input RP filter: none, route-map: none
Output (S,G) filter: none, route-map: none
Output RP filter: none, route-map: none
SA-Requests:
Input filter: none
Peer ttl threshold: 0
SAs learned from this peer: 0
Input queue size: 0, Output queue size: 0
MD5 signature protection on MSDP TCP connection: not enabled
This
output
indicates
that
the
status
of
the
connection
is:
Down.
We
also
see
that
R5
is
using
the
connection
source
192.1.5.5.
It
would
be
worthwhile
to
see
the
status
of
the
output
of
the
command
on
R7:
R7#show ip msdp peer 192.1.5.5
MSDP Peer 192.1.5.5 (?), AS ?
Connection status:
State: Down, Resets: 0, Connection source: none configured
Uptime(Downtime): 00:06:55, Messages sent/received: 0/0
Output messages discarded: 0
Connection and counters cleared 00:06:55 ago
SA Filtering:
Input (S,G) filter: none, route-map: none
Input RP filter: none, route-map: none
Output (S,G) filter: none, route-map: none
Output RP filter: none, route-map: none
10-9
SA-Requests:
Input filter: none
Peer ttl threshold: 0
SAs learned from this peer: 0
Input queue size: 0, Output queue size: 0
MD5 signature protection on MSDP TCP connection: not enabled
The
status
on
this
MSDP
RP
is
also
down
but
observe
that
the
connection
source
is
not
configured.
This
can
be
confirmed
with
show
run:
R7#show run | inc msdp
ip msdp peer 192.1.5.5
This
indicates
that
R7
is
not
using
the
correct
source
for
the
MSDP
peering.
It
is
corrected
by
adding
connection-source
key
word:
R7#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R7(config)#ip msdp peer 192.1.5.5 connect-source loopback0
%MSDP-5-PEER_UPDOWN: Session to peer 192.1.5.5 going up
R7(config)#end
We
see
that
R7
now
has
a
peering
with
192.1.5.5
(R5).
Is
R7
receiving
the
SA
Message
for
the
group
224.1.1.1,
172.16.15.1
now?
R7#show ip msdp peer 192.1.5.5 accepted-SAs
MSDP SA accepted from peer 192.1.5.5 (?)
224.1.1.1
The
SA
Message
has
been
learned.
The
question
now
is,
"Is
the
S,G
pair
added
to
the
multicast
routing
table
of
R7?
R7#show ip mroute 224.1.1.1
Group 224.1.1.1 not found
This
behavior
is
normal
based
on
our
discussion
of
the
mechanisms
used
by
MSDP.
The
S,G
will
only
be
added
to
the
multicast
routing
table
if
a
host
joins
the
multicast
group
224.1.1.1:
R9#conf t
Enter configuration commands, one per line.
R9(config)#interface FastEthernet0/1
R9(config-if)#ip igmp join-group 224.1.1.1
R9(config-if)#end
10-10
to
to
to
to
to
to
to
to
to
to
request
request
request
request
request
request
request
request
request
request
0
1
2
3
4
5
6
7
8
9
from
from
from
from
from
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
1
1
1
1
1
1
1
1
1
1
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
10-11
We
see
that
the
first
packet
actually
succeeds
but
all
after
that
fail.
Is
R5
sending
the
SA
Message?
This
is
accomplished
via
show
ip
msdp
peer:
R5#show ip msdp peer 192.1.7.7 advertised-SAs
MSDP SA advertised to peer 192.1.7.7 (?) from mroute table
224.9.9.9
172.16.15.1 (?)
MSDP SA advertised to peer 192.1.7.7 (?) from SA cache
This
output
indicates
that
R5
is
advertising
an
SA
message
for
the
S,G
pair
of
224.9.9.9,
172.16.15.1
to
the
peer
located
at
192.1.7.7.
What
is
the
status
of
the
TCP
session
to
this
MSDP
Peer?
R5#show ip msdp peer 192.1.7.7
MSDP Peer 192.1.7.7 (?), AS ?
Connection status:
State: Up, Resets: 0, Connection source: Loopback0 (192.1.5.5)
Uptime(Downtime): 00:16:55, Messages sent/received: 20/16
Output messages discarded: 0
Connection and counters cleared 00:26:50 ago
SA Filtering:
Input (S,G) filter: none, route-map: none
Input RP filter: none, route-map: none
Output (S,G) filter: none, route-map: none
Output RP filter: none, route-map: none
SA-Requests:
Input filter: none
Peer ttl threshold: 0
SAs learned from this peer: 0
Input queue size: 0, Output queue size: 0
MD5 signature protection on MSDP TCP connection: not enabled
10-12
This
output
indicates
that
the
status
of
the
connection
is:
Up.
We
also
see
that
R5
is
using
the
connection
source
192.1.5.5.
It
would
be
worthwhile
to
see
the
status
of
the
output
of
the
command
on
R7:
R7#show ip msdp peer 192.1.5.5
MSDP Peer 192.1.5.5 (?), AS ?
Connection status:
State: Up, Resets: 0, Connection source: Loopback0 (192.1.7.7)
Uptime(Downtime): 00:17:48, Messages sent/received: 17/21
Output messages discarded: 0
Connection and counters cleared 00:17:49 ago
SA Filtering:
Input (S,G) filter: none, route-map: none
Input RP filter: none, route-map: none
Output (S,G) filter: none, route-map: none
Output RP filter: none, route-map: none
SA-Requests:
Input filter: none
Peer ttl threshold: 0
SAs learned from this peer: 2
Input queue size: 0, Output queue size: 0
MD5 signature protection on MSDP TCP connection: not enabledd
The
status
on
this
MSDP
RP
is
also:
Up
and
the
connection
source
is
correctly
configured.
Is
R7
receiving
the
SA
Message?
R7#show ip msdp peer 192.1.5.5 accepted-SAs
MSDP SA accepted from peer 192.1.5.5 (?)
224.9.9.9
Is
the
S,G
entry
making
it
into
the
multicast
routing
table
on
R7?
R7#show ip mroute 224.9.9.9
Group 224.9.9.9 not found
10-13
Reporter:
<mac-or-ip-address> - last reporter if group is not explicitly tracked
<n>/<m>
- <n> reporter in include mode, <m> reporter in exclude
Channel/Group
*,224.0.1.40
Reporter
172.16.79.9
Uptime
Exp. Flags
04:11:11 02:53 2LA
Interface
Fa0/1
The
S,G
entry
is
not
made
to
the
multicast
routing
table
of
R7
because
R9
is
not
a
member
of
the
group.
This
can
be
corrected
via
ip
igmp
join-group
on
R9:
R9#conf t
Enter configuration commands, one per line.
R9(config)#interface FastEthernet0/1
R9(config-if)#ip igmp join-group 224.9.9.9
R9(config-if)#end
10-14
This
means
that
the
packets
are
not
making
it
from
R5
to
R7.
This
situation
is
most
likely
associated
with
a
problem
in
the
multicast
routing
and
forwarding
plane.
This
could
be
an
RPF
issue,
and
asynchronous
routing
issue,
or
a
corrupt
multicast
routing
table
between
the
MSDP
peers.
All
of
these
issues
can
be
isolated
via
mtrace
(used
bidirectionally):
R5#mtrace 192.1.5.5 192.1.7.7
Type escape sequence to abort.
Mtrace from 192.1.5.5 to 192.1.7.7 via RPF
From source (?) to destination (?)
Querying full reverse path...
0 192.1.7.7
-1 172.16.67.7 PIM [192.1.5.0/24]
-2 172.16.67.6 PIM [192.1.5.0/24]
-3 172.16.26.2 PIM Multicast disabled [192.1.5.0/24]
-4 172.16.24.4 PIM [192.1.5.0/24]
-5 172.16.45.5 PIM [192.1.5.0/24]
This
output
informs
us
that
R2
the
interface
with
the
ip
address
172.16.26.2
is
not
enabled
with
ip
pim
sparse-mode,
as
evidenced
with
show
run
interface:
R2#show run interface GigabitEthernet0/1
Building configuration...
Current configuration : 116 bytes
!
interface GigabitEthernet0/1
ip address 172.16.26.2 255.255.255.0
no ip mroute-cache
duplex auto
speed auto
end
To correct this problem we will apply ip pim sparse-mode under the GigabitEthernet0/1 interface of R2:
10-15
R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#interface GigabitEthernet0/1
R2(config-if)#ip pim sparse-mode
R2(config-if)#end
R2#
%PIM-5-NBRCHG: neighbor 172.16.26.6 UP on interface GigabitEthernet0/1
%PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 172.16.26.6 on interface
GigabitEthernet0/1
We
see
the
PIM
neighbor
come
up
on
FastEthernet0/1.
Are
the
pings
successful
from
R1?
R1#ping 224.9.9.9 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 224.9.9.9, timeout is 2 seconds:
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
to
to
to
to
to
to
to
to
to
to
request
request
request
request
request
request
request
request
request
request
0
1
2
3
4
5
6
7
8
9
from
from
from
from
from
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
1
1
1
1
1
1
1
1
1
1
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
The
pings
are
successful
thus
demonstrating
the
issue
has
been
corrected.
MSDP
Passwords
and
Filters
This
situation
is
where
SA
Messages
are
either
not
sent
as
a
result
of
failed
authentication
protocols
or
messages
are
dropped
as
a
result
of
message
filters.
Setting
the
Stage:
Generate
a
multicast
ping
from
R1
for
the
multicast
group
224.3.3.3
with
high
repeat
count:
R1#ping 224.3.3.3 repeat 10000
Type escape sequence to abort.
Sending 10000, 100-byte ICMP Echos to 224.3.3.3, timeout is 2 seconds:
......... <output omitted>
10-16
This
output
indicates
that
R5
is
advertising
an
SA
message
for
the
S,G
pair
of
224.3.3.3,
172.16.15.1
to
the
peer
located
at
192.1.7.7.
What
is
the
status
of
the
TCP
session
to
this
MSDP
Peer?
R5#show ip msdp peer 192.1.7.7
MSDP Peer 192.1.7.7 (?), AS ?
Connection status:
State: Up, Resets: 0, Connection source: Loopback0 (192.1.5.5)
Uptime(Downtime): 00:16:55, Messages sent/received: 20/16
Output messages discarded: 0
Connection and counters cleared 00:26:50 ago
SA Filtering:
Input (S,G) filter: none, route-map: none
Input RP filter: none, route-map: none
Output (S,G) filter: none, route-map: none
Output RP filter: none, route-map: none
SA-Requests:
Input filter: none
Peer ttl threshold: 0
SAs learned from this peer: 0
Input queue size: 0, Output queue size: 0
MD5 signature protection on MSDP TCP connection: not enabled
This
output
indicates
that
the
status
of
the
connection
is:
Up.
We
also
see
that
R5
is
using
the
connection
source
192.1.5.5.
It
would
be
worthwhile
to
see
the
status
of
the
output
of
the
command
on
R7:
R7#show ip msdp peer 192.1.5.5
MSDP Peer 192.1.5.5 (?), AS ?
Connection status:
State: Up, Resets: 0, Connection source: Loopback0 (192.1.7.7)
Uptime(Downtime): 00:07:08, Messages sent/received: 8/9
Output messages discarded: 0
Connection and counters cleared 00:07:09 ago
SA Filtering:
Input (S,G) filter: everything, route-map: none
Input RP filter: none, route-map: none
Output (S,G) filter: none, route-map: none
Output RP filter: none, route-map: none
SA-Requests:
Input filter: none
Peer ttl threshold: 0
SAs learned from this peer: 0
10-17
The
status
on
this
MSDP
RP
is
also:
Up,
and
the
connection
source
is
correctly
configured.
However,
we
have
to
note
that
there
is
an
S,G
filter
applied
on
R7
that
is
filtering
everything.
Is
R7
receiving
the
SA
Message?
R7#show ip msdp peer 192.1.5.5 accepted-SAs
MSDP SA accepted from peer 192.1.5.5 (?)
An
MSDP
sa-filter
is
blocking
all
inbound
SA
messages
sourced
from
192.1.5.5,
to
correct
this
issue
the
filter
should
be
removed:
R7#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R7(config)#no ip msdp sa-filter in 192.1.5.5
R7(config)#end
Has
the
pair
been
added
to
the
multicast
routing
table
of
R7?
R7#show ip mroute 224.3.3.3
Group 224.3.3.3 not found
10-18
Reporter
172.16.79.9
Uptime
Exp. Flags
04:44:23 02:41 2LA
Interface
Fa0/1
There
is
no
member
of
this
group.
To
correct
this
issue
have
R9's
interface
FastEthernet0/1
join
the
group:
R9#conf t
Enter configuration commands, one per line.
R9(config)#interface FastEthernet0/1
R9(config-if)#ip igmp join-group 224.3.3.3
R9(config-if)#end
Has
the
S,G
pair
been
added
to
the
multicast
routing
table
on
R7
now?
R7#show ip mroute 224.3.3.3
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.3.3.3), 00:00:54/stopped, RP 192.1.7.7, flags: SJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/1, Forward/Sparse, 00:00:54/00:02:35
(172.16.15.1, 224.3.3.3), 00:00:54/00:03:20, flags: MT
Incoming interface: FastEthernet0/0, RPF nbr 172.16.67.6
Outgoing interface list:
FastEthernet0/1, Forward/Sparse, 00:00:54/00:03:03
10-19
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
to
to
to
to
to
to
to
to
to
request
request
request
request
request
request
request
request
request
1
2
3
4
5
6
7
8
9
from
from
from
from
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
1
1
1
1
1
1
1
1
1
ms
ms
ms
ms
ms
ms
ms
ms
ms
10-20
show
COMMAND:
show
ip
msdp
peer
ip_address
This
command
displays
detailed
information
about
Multicast
Source
Discovery
Protocol
(MSDP)
peers.
Where:
EXAMPLE
OUTPUT:
R7#show ip msdp peer 192.1.5.5
MSDP Peer 192.1.5.5 (?), AS ?
Connection status:
State: Up, Resets: 0, Connection source: Loopback0 (192.1.7.7)
Uptime(Downtime): 00:07:19, Messages sent/received: 7/10
Output messages discarded: 0
Connection and counters cleared 00:07:28 ago
SA Filtering:
Input (S,G) filter: none, route-map: none
Input RP filter: none, route-map: none
Output (S,G) filter: none, route-map: none
Output RP filter: none, route-map: none
SA-Requests:
Input filter: none
Peer ttl threshold: 0
10-21
show
COMMAND:
show
ip
msdp
peer
ip_address
advertised-SAs
This
command
displays
detailed
information
about
Multicast
Source
Discovery
Protocol
(MSDP)
peers.
Where:
EXAMPLE
OUTPUT:
R5#show ip msdp peer 192.1.7.7 advertised-SAs
MSDP SA advertised to peer 192.1.7.7 (?) from mroute table
224.1.1.1
172.16.15.1 (?)
MSDP SA advertised to peer 192.1.7.7 (?) from SA cache
R5#
10-22
debug
COMMAND:
debug
ip
msdp
detail
This
command
displays
detailed
information
regarding
MSDP
operations.
EXAMPLE
OUTPUT:
R5#debug ip msdp detail
MSDP Detail debugging is on
R5#
MSDP(0): Received 3-byte TCP segment from 192.1.7.7
MSDP(0): Append 3 bytes to 0-byte msg 12 from 192.1.7.7, qs 1
R5#
MSDP(0): Sent entire mroute table, mroute_cache_index = 0, Qlen = 0
MSDP(0): start_index = 0, sa_cache_index = 0, Qlen = 0
MSDP(0): Sent entire sa-cache, sa_cache_index = 0, Qlen = 0
R5#
MSDP(0): Received 3-byte TCP segment from 192.1.7.7
MSDP(0): Append 3 bytes to 0-byte msg 13 from 192.1.7.7, qs 1
R5#
10-23
Trouble
Ticket
#1
Your
supervisor
has
brought
to
your
attention
that
the
RP
in
Multicast
Domain
"A"
is
not
forming
an
MSDP
peering
relationship
with
the
RP
in
Multicast
Domain
"B".
You
have
been
instructed
to
correct
the
issue
causing
this
problem.
You
must
use
the
most
secure
method
possible
to
accomplish
this
task.
Trouble
Ticket
#2
After
solving
Trouble
Ticket
#1,
your
supervisor
has
observed
that
R7
is
failing
to
accept
SA
Messages
from
R5
for
the
multicast
group
224.1.1.1.
10-24
The
output
clearly
indicates
that
the
connection
status
with
the
peer
is
down
thus
verifying
the
problem
exists.
Step
2
-
Fault
Isolation:
The
next
course
of
action
is
to
use
the
show
ip
msdp
peer
command
on
R7
and
compare
the
results
with
those
seem
on
R5.
R7#show ip msdp peer 192.1.5.5
MSDP Peer 192.1.5.5 (?), AS ?
Connection status:
State: Listen, Resets: 0, Connection source: Loopback0 (192.1.7.7)
10-25
Looking
at
this
output
we
can
see
that
both
R5
and
R7
are
using
their
loopbacks
to
form
the
connection.
Both
devices
have
specified
the
correct
connection
source.
However,
we
can
see
that
R7
has
enabled
MD5
signature
protection
for
the
TCP
connection
where
R5
has
not.
We
can
see
the
nature
of
the
authentication
configuration
with
show
run
on
each
of
these
MSDP
RPs:
R5#show run | inc msdp password
R5#
R7#show run | inc msdp password
ip msdp password peer 192.1.5.5 CISCO
We
see
that
R5
is
not
using
password
protection
for
the
TCP
session.
This
isolates
the
fault.
Step
3
-
Fault
Remediation:
In
this
scenario,
the
ip
msdp
password
peer
command
needs
to
be
applied
to
R5.
R5#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R5(config)#ip msdp password peer 192.1.7.7 CISCO
R5(config)#end
10-26
We
see
that
the
MSDP
peer
connection
with
192.1.7.7
is
now
up,
additionally
we
see
a
console
message
notifying
us
that:
%MSDP-5-PEER_UPDOWN: Session to peer 192.1.7.7 going up
Does
R7
accept
the
SA
Message
for
the
group
224.1.1.1?
R7#show ip msdp peer 192.1.5.5 accepted-SAs
MSDP SA accepted from peer 192.1.5.5 (?)
R7#
R7
has
no
record
of
accepting
the
SA
for
224.1.1.1.
Thus
proving
the
problem
exists.
10-27
R5
is
sending
the
SA
Messages.
We
can
use
show
ip
msdp
peer
on
R7
to
see
what
is
happening
to
these
messages:
R7#show ip msdp peer
MSDP Peer 192.1.5.5 (?), AS ?
Connection status:
State: Up, Resets: 0, Connection source: Loopback0 (192.1.7.7)
Uptime(Downtime): 00:29:08, Messages sent/received: 30/34
Output messages discarded: 0
Connection and counters cleared 00:56:48 ago
Elapsed time since last message: 00:00:06
Local Address of connection: 192.1.7.7
Local Port: 639, Remote Port: 23779
SA Filtering:
Input (S,G) filter: 100, route-map: none
Input RP filter: none, route-map: none
Output (S,G) filter: none, route-map: none
Output RP filter: none, route-map: none
SA-Requests:
Input filter: none
Peer ttl threshold: 0
SAs learned from this peer: 0
Input queue size: 0, Output queue size: 0
MD5 signature protection on MSDP TCP connection: enabled
Message counters:
RPF Failure count: 0
SA Messages in/out: 21/0
SA Requests in: 0
SA Responses out: 0
Data Packets in/out: 2/0
Note
that
SA
Filtering
is
taking
place
on
R7.
Specifically
an
Input
S,G
filter
has
been
applied
using
the
extended
access-list
100.
What
is
the
nature
of
the
access-list
being
called?
R7#show access-list 100
Extended IP access list 100
10 deny ip any host 224.1.1.1 (18 matches)
20 permit ip any any
10-28
This
ACL
is
blocking
any
SA
Messages
for
the
group
224.1.1.1
sourced
from
any
sender.
This
has
isolated
our
fault.
Step
3
-
Fault
Remediation:
In
this
scenario,
the
ip
access-list
extended
100
command
needs
to
be
used
to
remove
sequence
number
10
from
the
access-list:
R7#conf t
Enter configuration commands, one per line.
R7(config)#ip access-list extended 100
R7(config-ext-nacl)#no 10
R7(config-ext-nacl)#end
R7
is
now
accepting
the
SA
Messages
for
the
group
224.1.1.1.
Thus
verifying
that
the
error
has
been
corrected.
Additionally,
we
see
that
pings
from
R1
are
now
successful:
R1#ping 224.1.1.1 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
to
to
to
to
to
to
to
to
request
request
request
request
request
request
request
request
0
1
2
3
4
5
6
7
from
from
from
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
1
1
1
1
1
1
1
1
ms
ms
ms
ms
ms
ms
ms
ms
10-29
10-30
11-1
11-2
Figure
11-1:
Anycast-RP
11-3
This
process
as
mention
earlier
in
this
section
is
the
same
as
that
used
in
inter-domain
multicast.
Step
One
-
First-hop
router
unicasts
a
PIM
Register
Message
(containing
an
encapsulated
multicast
packet)
to
the
closest
RP,
in
this
case
R5.
This
process
can
be
observed
by
generating
a
ping
from
R1
to
a
multicast
group,
and
observing
the
output
of
the
debug
ip
pim
on
R4:
R4#debug ip pim
PIM debugging is on
R4#
Now
we
will
look
at
R4
to
see
the
Register
Message
arrive
from
R5:
R4#
PIM(0): Received v2 Register on FastEthernet0/1 from 172.16.45.5
for 172.16.15.1, group 224.10.10.10
PIM(0): Check RP 192.1.100.100 into the (*, 224.10.10.10) entry
PIM(0): Send v2 Register-Stop to 172.16.45.5 for 172.16.15.1, group 224.10.10.10
Step
Three
-
If
R6
receives
the
SA
messages
and
it
has
a
receiver
for
that
particular
group,
it
joins
SPT
toward
the
source
by
sending
an
(S,G)
join.
11-4
We
can
see
if
the
SA
Message
arrives
by
using
the
show
ip
msdp
peer
command
on
R6:
R6#show ip msdp peer 192.1.4.4 accepted-SAs
MSDP SA accepted from peer 192.1.4.4 (?)
224.10.10.10
We
see
that
the
SA
message
arrives,
and
as
a
result
of
R9
having
joined
the
multicast
group
224.10.10.10
we
see
the
following
Join
Message
go
out
with
the
Shortest
Path
Bit
set:
R6#
PIM(0):
PIM(0):
PIM(0):
PIM(0):
Step
Four
-
R4
will
forward
via
the
shared
tree
to
the
hosts
the
multicast
packet
it
receives
in
the
SA
message
As
demonstrated
by
the
output
of
the
show
ip
mroute
command
on
R6:
R6#show ip mroute 224.10.10.10
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.10.10.10), 00:04:54/stopped, RP 192.1.100.100, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:04:54/00:02:31
(172.16.15.1, 224.10.10.10), 00:00:04/00:02:55, flags: MT
Incoming interface: FastEthernet0/1, RPF nbr 172.16.26.2
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:00:04/00:03:25
Step
Five
-
when
last-hop
router
receives
the
multicast
packet,
it
joins
the
SPT
unless
it
is
configured
not
to
do
so
(ip
pim
spt-threshhold
infinity)
11-5
In
a
MSDP
environment
the
behavior
is
the
same
when
the
first
encapsulated
multicast
packet
arrives
in
the
SA
Message.
After
receiving
the
SA
message,
the
RP
extracts
the
multicast
data
and
sends
the
multicast
data
down
the
RPT
to
the
DRs
at
the
receiver
side.
The
MSDP
RP
acts
as
a
transfer
station
for
all
multicast
packets.
The
whole
process
involves
the
following
issues:
Multicast
packets
could
be
delivered
via
the
MSDP
peering
relationship
along
a
path
that
might
not
be
the
shortest
path.
An
increase
in
multicast
traffic
could
add
a
potential
congestion
on
the
RP,
increasing
the
risk
of
failure.
To
solve
these
issues,
MSDP
permits
the
normal
PIM-SM
process
of
allowing
the
DR
at
the
receiver
side
to
initiate
the
SPT
switchover
process.
After
receiving
the
first
multicast
packet,
the
receiver-side
DR
initiates
an
SPT
switchover
process,
as
follows:
The
receiver-side
DR
sends
an
(S,
G)
join
message
hop
by
hop
toward
the
multicast
source.
When
the
join
message
reaches
the
source-side
DR,
all
the
routers
on
the
path
have
installed
the
(S,
G)
entry
in
their
forwarding
table,
and
thus
an
SPT
branch
is
established.
When
the
multicast
packets
travel
to
the
router
where
the
RPT
and
the
SPT
deviate,
the
router
drops
the
multicast
packets
received
from
the
RPT
and
sends
an
RP-bit
prune
message
hop
by
hop
to
the
RP.
After
receiving
this
prune
message,
the
RP
sends
a
prune
message
toward
the
multicast
source
(suppose
only
one
receiver
exists).
Thus,
SPT
switchover
is
completed.
Multicast
data
is
directly
sent
from
the
source
to
the
receivers
along
the
SPT.
11-6
11-7
Beware
of
issues
where
these
have
been
deployed
incorrectly
or
in
situations
where
previous
configurations
have
not
been
completely
removed.
Unicast
Routing
Problems
Individual
multicast
enabled
routers
will
utilize
their
own
unicast
routing
table
to
determine
which
RP
is
the
closet.
The
same
set
of
selection
rules
are
used
to
create
the
multicast
routing
trees
that
are
used
by
the
unicast
routing
protocol.
This
means
that
a
router
will
always
take
the
longest
match
over
Administrative
distance.
Ties
are
broken
by
using
the
actual
routing
metric
to
the
respective
RPs.
The
process
explained
above,
is
intended
to
make
you
aware
of
the
fact
that
the
routers
in
your
domain
may
select
RPs
that
you
do
not
expect
them
to
choose
based
on
the
dynamic
nature
of
the
routing
protocols
you
employ
on
the
network.
Three
such
circumstances
that
are
commonly
encountered
are:
More
Than
One
Routing
Protocol
-
Different
administrative
distances
can
have
unexpected
effects
on
the
RP
selection
process.
Matching
Metrics
To
Each
Of
The
RPs
-
This
will
result
in
a
router
alternating
between
the
RPs.
(A
less
than
favorable
situation.)
Unequal
Cost
Load
Balancing
-
This
situation
will
introduce
a
complex
weighted
round
robin
selection
process
that
can
make
troubleshooting
exceedingly
difficult.
The
MSDP
protocol
will
always
forward
Join/Prune
messages
to
the
appropriate
RP,
but
if
you
do
not
know
the
identity
of
the
RP
in
use,
you
will
have
issues
troubleshooting
any
protocol
faults.
In
the
Anycast-RP
Sample
Troubleshooting
Scenarios
section
that
follows,
troubleshooting
these
issues
are
demonstrated.
For
each
problem,
the
text
demonstrates
how
to
quickly
and
efficiently
verify
each
symptom,
isolate
the
cause,
and
remediate
the
issue.
11-8
In
the
Common
Issues
with
Anycast-RP
section,
two
primary
types
of
problems
were
identified:
MSDP
Peering
Issues
and
Unicast
Routing
Problems.
This
section
explores
these
three
categories
of
failure,
by
directing
our
attention
to
the
commands
necessary
to
identify
that
a
problems
exists.
MSDP
Peering
Issues
This
situation
is
were
two
or
more
MSDP
peers
fail
to
successfully
negotiate
a
TCP
Session
this
situation
is
most
commonly
verified
via
the
use
of
show
ip
msdp
peer:
R4#show ip msdp peer
MSDP Peer 192.1.6.6 (?), AS ?
Connection status:
State: Down, Resets: 0, Connection source: Loopback0 (192.1.4.4)
Uptime(Downtime): 00:00:13, Messages sent/received: 0/0
Output messages discarded: 0
Connection and counters cleared 00:00:13 ago
SA Filtering:
Input (S,G) filter: none, route-map: none
Input RP filter: none, route-map: none
Output (S,G) filter: none, route-map: none
Output RP filter: none, route-map: none
11-9
SA-Requests:
Input filter: none
Peer ttl threshold: 0
SAs learned from this peer: 0
Input queue size: 0, Output queue size: 0
MD5 signature protection on MSDP TCP connection: enabled
Observe
the
output
of
this
command
indicates
that
the
connection
state
is:
Down.
More
often
than
not,
a
direct
comparison
between
the
two
RPs
in
a
domain
will
reveal
the
cause
of
this
type
of
issue:
R6#show ip msdp peer
MSDP Peer 192.1.4.4 (?), AS ?
Connection status:
State: Listen, Resets: 1, Connection source: Loopback0 (192.1.6.6)
Uptime(Downtime): 00:02:10, Messages sent/received: 0/0
Output messages discarded: 0
Connection and counters cleared 05:27:55 ago
SA Filtering:
Input (S,G) filter: none, route-map: none
Input RP filter: none, route-map: none
Output (S,G) filter: none, route-map: none
Output RP filter: none, route-map: none
SA-Requests:
Input filter: none
Peer ttl threshold: 0
SAs learned from this peer: 0
Input queue size: 0, Output queue size: 0
MD5 signature protection on MSDP TCP connection: not enabled
Note
that
R6
is
running
MD5
authentication
and
R4
is
not.
This
can
be
verified
via
show
run:
R4#sh run | inc msdp password
ip msdp password peer 192.1.6.6 CISCO
R6#show run | inc msdp password
R6#
Applying
a
password
to
R6
will
correct
this
issue:
R6(config)#ip msdp password peer 192.1.4.4 CISCO
R6(config)#end
R6#
%MSDP-5-PEER_UPDOWN: Session to peer 192.1.4.4 going up
Repeating the show mspd peer command will now tell us that the connection is up:
11-10
The
ping
is
not
successful.
We
need
to
determine
if
R4
is
sending
the
SA
Messages
to
its
peer:
R4#show ip msdp peer 192.1.6.6 advertised-sa
MSDP SA advertised to peer 192.1.6.6 (?) from mroute table
224.9.9.9
172.16.15.1 (?)
MSDP SA advertised to peer 192.1.6.6 (?) from SA cache
11-11
The
SA
messages
are
accepted
by
R6.
Is
the
S,G
entry
addred
to
R6s
multicast
routing
table?
R6#show ip mroute 224.9.9.9
Group 224.9.9.9 not found
The
entry
is
not
added.
Oddly
enough
we
do
not
even
see
a
*,G
for
the
group.
Has
R9
joined
224.9.9.9?
R9#show ip igmp membership
Flags: A - aggregate, T - tracked
L - Local, S - static, V - virtual, R - Reported through v3
I - v3lite, U - Urd, M - SSM (S,G) channel
1,2,3 - The version of IGMP the group is in
Channel/Group-Flags:
/ - Filtering entry (Exclude mode (S,G), Include mode (*,G))
Reporter:
<mac-or-ip-address> - last reporter if group is not explicitly tracked
<n>/<m>
- <n> reporter in include mode, <m> reporter in exclude
Channel/Group
*,224.9.9.9
*,224.0.1.40
Reporter
172.16.79.9
172.16.79.9
Uptime
Exp. Flags
00:26:33 02:29 2LA
00:26:31 02:28 2LA
Interface
Fa0/1
Fa0/1
11-12
R7
is
learning
the
that
R9
has
joined
the
group
is
has
also
added
the
*,G
entry
with
the
interface
facing
R9
to
the
OIL
for
this
entry.
The
odd
thing
is
that
the
RPF
nbr
is
0.0.0.0.
We
know
from
past
experience
that
this
indicates
that
the
router
either
thinks
that
it
is
the
RP
or
that
the
addressed
for
the
RP
is
invalid.
We
know
that
R7
should
not
be
the
RP,
but
we
still
need
to
verify:
R7#show ip pim rp
Group: 224.9.9.9, RP: 192.1.100.100, next RP-reachable in 00:00:03
Group: 224.0.1.40, RP: 192.1.100.100, next RP-reachable in 00:00:02
We
see
that
the
RP
is
192.1.100.100
which
is
correct.
Can
R7
reach
this
address?
R7#ping 192.1.100.100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.1.100.100, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
We
see
the
address
is
reachable.
But
what
route
will
R7
take
to
reach
this
address.
R7#show ip route 192.1.100.100
Routing entry for 192.1.100.0/24
Known via "connected", distance 0, metric 0 (connected, via interface)
Redistributing via eigrp 100
Routing Descriptor Blocks:
* directly connected, via Loopback100
Route metric is 0, traffic share count is 1
We
see
that
R7
thinks
the
prefix
192.1.100.100
is
reachable
via
its
loopback100
interface.
This
means
that
the
address
resides
on
this
router
as
evidenced
by
show
run:
R7#show run interface loopback 100
Building configuration...
Current configuration : 69 bytes
!
interface Loopback100
ip address 192.1.100.100 255.255.255.0
end
This
interface
needs
to
be
removed
because
it
is
causing
an
issue
with
the
unicast
reachability
to
the
RP.
R7#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R7(config)#no interface loopback 100
% Not all config may be removed and may reappear after reactivating the logicalinterface/sub-interfaces
11-13
R7(config)#
%LINK-5-CHANGED: Interface Loopback100, changed state to administratively down
%LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback100, changed state to down
R7(config)#end
to
to
to
to
to
to
to
to
to
to
request
request
request
request
request
request
request
request
request
request
0
1
2
3
4
5
6
7
8
9
from
from
from
from
from
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
1
1
1
1
1
1
1
1
1
1
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
11-14
show
COMMAND:
show
ip
msdp
peer
ip_address
This
command
displays
detailed
information
about
Multicast
Source
Discovery
Protocol
(MSDP)
peers.
Where:
EXAMPLE OUTPUT:
R6#show ip msdp peer 192.1.5.5
MSDP peer 192.1.5.5 not found
R6#show ip msdp peer 192.1.4.4
MSDP Peer 192.1.4.4 (?), AS ?
Connection status:
State: Up, Resets: 0, Connection source: Loopback0 (192.1.6.6)
Uptime(Downtime): 01:17:18, Messages sent/received: 77/86
Output messages discarded: 0
Connection and counters cleared 01:17:49 ago
SA Filtering:
Input (S,G) filter: none, route-map: none
Input RP filter: none, route-map: none
Output (S,G) filter: none, route-map: none
Output RP filter: none, route-map: none
SA-Requests:
Input filter: none
11-15
show
COMMAND:
show
ip
msdp
peer
ip_address
advertised-SAs
This
command
displays
detailed
information
about
Multicast
Source
Discovery
Protocol
(MSDP)
peers.
Where:
EXAMPLE OUTPUT:
R4#show ip msdp peer 192.1.6.6 advertised-SAs
MSDP SA advertised to peer 192.1.6.6 (?) from mroute table
224.9.9.9
172.16.15.1 (?)
MSDP SA advertised to peer 192.1.6.6 (?) from SA cache
R4#
11-16
debug
COMMAND:
debug
ip
msdp
detail
This
command
displays
detailed
information
regarding
MSDP
operations.
EXAMPLE OUTPUT:
R4#debug ip msdp detail
MSDP Detail debugging is on
R4#
MSDP(0): Received 3-byte TCP segment from 192.1.6.6
MSDP(0): Append 3 bytes to 0-byte msg 92 from 192.1.6.6, qs 1
R4#
MSDP(0): Sent entire mroute table, mroute_cache_index = 0, Qlen = 0
MSDP(0): start_index = 0, sa_cache_index = 0, Qlen = 0
MSDP(0): Sent entire sa-cache, sa_cache_index = 0, Qlen = 0
R4#
MSDP(0): Received 3-byte TCP segment from 192.1.6.6
MSDP(0): Append 3 bytes to 0-byte msg 93 from 192.1.6.6, qs 1
R4#
11-17
Trouble
Ticket
#1
Your
supervisor
has
brought
to
your
attention
that
ping
sourced
from
the
FastEthernet0/0
interface
of
R1
for
the
group
224.9.9.9
is
not
reaching
receivers
on
R9s
VLAN79
segment.
Using
this
group
you
have
been
instructed
to
isolate
and
correct
this
issue.
11-18
The
pings
are
not
successful.
This
verifies
that
the
problem
actually
exists.
Step
2
-
Fault
Isolation:
The
next
course
of
action
is
to
verify
that
R4
is
sending
SA
messages
to
R6.
R4#show ip msdp peer 192.1.6.6 advertised-SAs
MSDP SA advertised to peer 192.1.6.6 (?) from mroute table
224.9.9.9
172.16.15.1 (?)
MSDP SA advertised to peer 192.1.6.6 (?) from SA cache
The
SA
messages
are
being
sent.
Are
they
being
accepted
by
the
MSDP
peer:
R6#show ip msdp peer 192.1.4.4 accepted-SAs
MSDP SA accepted from peer 192.1.4.4 (?)
224.9.9.9
R6#
R6
is
accepting
the
SA
messages.
Is
the
S,G
pair
being
added
to
the
multicast
routing
table
for
the
group
(172.16.15.1,
224.9.9.9)
on
R6?
R6#show ip mroute 224.9.9.9
Group 224.9.9.9 not found
11-19
We
know
that
we
will
not
add
the
S,G
entry
unless
we
have
a
*,G
for
the
particular
group.
This
*,G
is
missing.
Has
R9
joined
the
group?
R9#show ip igmp interface Fa0/1
FastEthernet0/1 is up, line protocol is up
Internet address is 172.16.79.9/24
IGMP is enabled on interface
Current IGMP host version is 2
Current IGMP router version is 2
IGMP query interval is 60 seconds
IGMP querier timeout is 120 seconds
IGMP max query response time is 10 seconds
Last member query count is 2
Last member query response interval is 1000 ms
Inbound IGMP access group is not set
IGMP activity: 2 joins, 0 leaves
Multicast routing is enabled on interface
Multicast TTL threshold is 0
Multicast designated router (DR) is 172.16.79.9 (this system)
IGMP querying router is 172.16.79.7
Multicast groups joined by this system (number of users):
224.9.9.9(1) 224.0.1.40(1)
We
see
that
R9
has
joined
the
group
224.9.9.9,
this
IGMP
version
2
join
information
should
be
sent
to
the
IGMP
Querying
router
(172.16.79.7).
This
means
that
R7
should
have
the
*,G
entry:
R7#show ip mroute 224.9.9.9
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.9.9.9), 00:12:07/00:03:12, RP 192.1.100.100, flags: SJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/1, Forward/Sparse, 00:12:07/00:03:12
11-20
Note
that
we
see
the
*,G
entry
for
the
group.
However,
observe
the
RPF
nbr
of
0.0.0.0.
This
means
the
router
thinks
it
is
the
RP
or
that
the
RP
address
is
invalid.
What
RPF
interface
will
be
used
to
check
the
multicast
traffic
learned
from
this
RP
address?
R7#show ip rpf 192.1.100.100
RPF information for ? (192.1.100.100) failed, no route exists
This
output
tells
us
that
no
route
exists.
We
need
to
take
a
closer
look
at
the
routing
table
of
R7:
R7#show ip route 192.1.100.100
Routing entry for 192.1.100.0/24
Known via "connected", distance 0, metric 0 (connected, via interface)
Redistributing via eigrp 100
Routing Descriptor Blocks:
* directly connected, via Loopback100
Route metric is 0, traffic share count is 1
This
tells
us
that
the
network
192.1.100.0/24
resides
on
this
router
on
interface
Loopback100,
as
evidenced
by
show
run:
R7#show run int loopback 100
Building configuration...
Current configuration : 69 bytes
!
interface Loopback100
ip address 192.1.100.100 255.255.255.0
end
This
interface
should
not
exist
in
the
topology
on
this
router.
This
isolates
the
fault.
Step
3
-
Fault
Remediation:
In
this
scenario,
the
no
interface
loopback100
command
needs
to
be
applied
on
R7
to
eliminate
the
configuration
artifact
from
a
previous
lab.
R7#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R7(config)#no interface loopback100
% Not all config may be removed and may reappear after reactivating the logicalinterface/sub-interfaces
R7(config)#end
11-21
to
to
to
to
to
to
to
to
to
to
request
request
request
request
request
request
request
request
request
request
0
1
2
3
4
5
6
7
8
9
from
from
from
from
from
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
4
1
1
1
4
1
1
1
1
1
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
Pings
from
R1
are
now
successful.
The
solution
has
successfully
remediated
the
problem.
11-22
Chapter
12:
Multiprotocol-BGP
(MP-BGP)
and
Interdomain
Multicast
In
this
chapter
of
IPv4/6
Multicast
Operation
and
Troubleshooting,
the
processes
and
functionality
of
the
Multiprotocol-BGP
(MP-BGP)
protocol
are
examined
in
great
depth.
Once
the
operational
characteristics
of
this
important
protocol
are
detailed
completely,
the
focus
becomes
that
of
troubleshooting.
This
includes
the
careful
examination
of
symptoms,
a
fault
isolation
methodology,
and
the
implementation
of
repairs
for
the
Multiprotocol-BGP.
The
chapter
begins
with
a
thorough
review
of
Multiprotocol-BGP,
and
then
quickly
launches
in
to
an
exhaustive
analysis
of
the
art
of
troubleshooting
this
multicast
support
protocol.
This
important
chapter
concludes
with
sample
troubleshooting
scenarios,
reference
materials
for
the
most
important
show
and
debug
commands,
and
12-1
exciting
challenges
that
allow
readers
to
practice
implementing
the
troubleshooting
skills
they
have
obtained.
12-2
12-3
In
this
situation
both
MP-BGP
and
MSDP
will
connect
the
individual
PIM-SM
domains.
MP-BGP
in
this
scenario
provides
a
unique
capability.
MP-BGP
serves
as
a
policy-based
inter-domain
routing
protocol.
This
means
that
the
MP-BGP
protocol
will
be
used
for
choosing
best
paths
through
an
IP
internetwork.
As
discussed
in
Chapter
10:
MSDP,
MSDP
is
the
protocol
that
enables
RPs
from
different
domains
to
exchange
information
about
active
sources.
Having
spent
an
entire
chapter
covering
the
operation
and
troubleshooting
of
MSDP
we
will
not
go
into
any
detail
regarding
the
capabilities
or
deployment
of
that
protocol
here.
However,
MP-BGP
is
new
to
us
and
will
need
to
be
discussed
to
obtain
a
better
understanding
of
what
capabilities
it
brings
to
the
inter-
domain
multicast
topology
that
we
will
be
referencing
in
Figure
12-2.
12-4
MP-BGP
The
biggest
advantage
that
MP-BGP
brings
to
an
inter-domain
multicast
deployment
is
the
ability
for
a
Service
Provider
to
selectively
determine
what
prefixes
they
will
use
for
RPF
checks
in
the
multicast
environment.
We
have
discussed
in
many
of
the
previous
chapters
the
importance
of
the
RPF
mechanism
that
devices
use
to
create
multicast
forwarding
trees
in
a
loop
free
and
efficient
manner.
This
process
determines
what
trees
will
be
used
to
successfully
route
multicast
packets
between
sources
and
receivers.
MP-BGP
defines
Multiprotocol
Extensions
for
BGP
version
4.
As
such
it
is
an
extension
of
BGP
protocol
itself
that
defines
all
the
administrative
mechanisms
necessary
to
allow
service
providers
and
customers
to
independently
manipulate
their
inter-domain
routing
environment.
MP-BGP
allows
tools
traditionally
used
in
unicast
BGP
to
now
be
employed
for
the
benefit
of
inter-domain
multicast
needs.
These
tools
include
inter-AS
mechanisms
that
filter
and
control
routing
like
route-maps.
This
means
that
any
network
running
iBGP
or
eBGP
protocols
can
now
use
MP-BGP
to
apply
multiple
policy
control
mechanisms
traditionally
used
in
BGP
to
specify
routing
and
forwarding
policies
for
multicast.
The
two
primary
attributes
that
we
will
discuss
in
this
the
chapter
will
be:
MP_REACH_NLRI
and
MP_UNREACH_NLRI.
These
two
attributes
were
introduced
in
BGP
version
4
to
create
a
simple
way
for
the
protocol
to
carry
two
categories
of
routing
informationunicast
routing
and
multicast
routing.
This
means
that
the
routes
communicated
via
MP-BGP
that
are
associated
with
multicast
routing
are
the
routes
used
for
RPF
checking
at
the
inter-domain
borders.
This
extension
to
the
traditional
BGP
version
4
protocol
has
one
huge
advantage.
MP-BGP
allows
an
inter-domain
network
to
support
non-congruent
unicast
and
multicast
topologies.
However,
almost
as
importantly
when
the
unicast
and
multicast
topologies
are
congruent,
MP-BGP
can
support
different
policies
for
each.
This
provides
unparalleled
policy-based
inter-domain
scalability
for
our
multicast
and
unicast
routing
protocols.
The
operational
deployment
of
MP-BGP
for
the
purpose
of
allowing
inter-domain
multicast
functionality
follows
a
simple
five
step
approach.
This
approach
provides
not
only
an
organized
method
for
deploying
the
protocol,
but
also
a
controlled
and
optimized
technique
for
isolation
and
troubleshooting
issues
when
MP-BGP
is
used
in
unison
with
MSDP.
Step
1
-
Configure
MP-BGP
to
exchange
unicast
and
multicast
routing
information
This
process
means
that
we
will
need
to
configure
all
BGP
speaking
devices
in
the
topology
to
utilize
the
MP-BGP
multicast
extensions.
Specifically,
we
will
need
to
use
the
multicast
Address
Family
Identifier:
12-5
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#router bgp 154
R1(config-router)#address-family ipv4 multicast
R1(config-router-af)#neighbor 172.16.15.5 activate
R1(config-router-af)#end
R5#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R5(config)#router bgp 154
R5(config-router)#address-family ipv4 multicast
R5(config-router-af)#neighbor 172.16.15.1 activate
R5(config-router-af)#neighbor 172.16.45.4 activate
R5(config-router-af)#neighbor 172.16.15.1 next-hop-self
R5(config-router-af)#neighbor 172.16.45.4 next-hop-self
R5(config-router-af)#neighbor 172.16.15.1 route-reflector-client
R5(config-router-af)#neighbor 172.16.45.4 route-reflector-client
R5(config-router-af)#end
R4#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)#router bgp 154
R4(config-router)# address-family ipv4
R4(config-router-af)# redistribute ospf 1
R4(config-router-af)#exit
R4(config-router)#address-family ipv4 multicast
R4(config-router-af)#neighbor 172.16.45.5 activate
R4(config-router-af)#neighbor 172.16.45.5 next-hop-self
R4(config-router-af)#redistribute ospf 1
R4(config-router-af)#neighbor 172.16.46.6 activate
R4(config-router-af)#end
Observe
that
R4
in
our
topology
is
the
boundary
device
between
AS154
and
AS679.
Additionally,
this
device
is
the
RP
for
the
AS154
domain.
This
means
that
R4
will
require
NLRI
for
the
other
RP
located
in
AS679.
To
accomplish
this
we
will
redistribute
OSPF
1
into
both
the
ipv4
unicast
and
multicast
address
families.
This
will
propagate
the
reachability
information
from
one
AS
to
the
other.
Now
we
will
repeat
this
process
in
AS679.
R6#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R6(config)#router bgp 679
R6(config-router)# address-family ipv4
R6(config-router-af)#redistribute eigrp 100
R6(config-router-af)#exit
R6(config-router)#address-family ipv4 multicast
R6(config-router-af)#neighbor 172.16.67.7 activate
12-6
Once
MP-BGP
has
been
enabled
throughout
the
domain
we
need
to
verify
that
information
is
being
exchanged
for
both
the
AFIs,
this
is
done
by
using
show
ip
bgp
ipv4
for
each
AFI:
R4#show ip bgp ipv4 multicast regexp ^679_
BGP table version is 11, local router ID is 192.1.100.100
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
*>
*>
*>
*>
Network
172.16.79.0/24
192.1.6.0
192.1.7.0
192.1.9.0
Next Hop
172.16.46.6
172.16.46.6
172.16.46.6
172.16.46.6
We
clearly
see
that
R4
is
learning
about
all
the
addresses
in
AS679,
now
we
need
to
see
if
R6
is
learning
all
four
of
the
prefixes
from
AS154:
R6#show ip bgp ipv4 multicast regexp ^154_
BGP table version is 9, local router ID is 192.1.6.6
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
12-7
Network
172.16.24.0/24
172.16.45.0/24
172.16.46.0/24
192.1.4.0
*>
*>
*>
*>
Next Hop
172.16.46.4
172.16.46.4
172.16.46.4
172.16.46.4
We
see
that
the
multicast
AFI
is
working
correctly
but,
we
need
to
keep
in
mind
that
this
is
the
multicast
AFI
that
is
used
for
RPF
checks,
not
the
unicast
AFI
that
is
used
for
reachability
and
routing.
To
verify
that
we
have
reachability
between
the
two
domains
we
will
perform
tests
at
each
of
the
most
distant
ends.
First,
we
will
use
show
ip
bpg
ipv4
unicast
then
we
will
use
traceroute:
R1#show ip bgp ipv4 unicast regexp ^679_
BGP table version is 21, local router ID is 192.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network
*>i172.16.26.0/24
*>i172.16.67.0/24
*>i172.16.79.0/24
*>i192.1.6.0
*>i192.1.7.0
*>i192.1.9.0
Next Hop
172.16.45.4
172.16.45.4
172.16.45.4
172.16.45.4
172.16.45.4
172.16.45.4
172.16.15.5
172.16.45.4
172.16.46.6
172.16.67.7
172.16.79.9
It
is
clear
that
the
unicast
AFI
has
learned
all
the
information
needed
for
reachability
and
forwarding.
However,
to
be
thorough
we
will
repeat
this
test
from
R9:
R9#show ip bgp ipv4 unicast regexp ^154_
BGP table version is 22, local router ID is 192.1.9.9
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network
Next Hop
12-8
*>i172.16.15.0/24
*>i172.16.24.0/24
*>i172.16.45.0/24
*>i192.1.1.0
*>i192.1.4.0
*>i192.1.5.0
172.16.67.6
172.16.67.6
172.16.67.6
172.16.67.6
172.16.67.6
172.16.67.6
2
0
0
3
0
2
100
100
100
100
100
100
0
0
0
0
0
0
154
154
154
154
154
154
?
?
?
?
?
?
172.16.79.7
172.16.67.6
172.16.46.4
172.16.45.5
172.16.15.1
This
configuration
can
easily
be
verified
using
the
show
ip
msdp
peer
command:
R4#show ip msdp peer
MSDP Peer 172.16.46.6 (?), AS 679 (configured AS)
Connection status:
State: Up, Resets: 0, Connection source: none configured
Uptime(Downtime): 00:01:39, Messages sent/received: 2/2
Output messages discarded: 0
Connection and counters cleared 00:02:39 ago
SA Filtering:
Input (S,G) filter: none, route-map: none
Input RP filter: none, route-map: none
12-9
12-10
12-11
12-12
In
the
Common
Issues
with
MP-BGP
section,
three
primary
types
of
problems
were
identified:
Peer
Rejects
all
MSDP
SA
Messages,
Failure
to
Advertise
the
MSDP
Peer
Network,
and
Using
the
Incorrect
Address
to
Form
MSDP
Peers.
This
section
explores
these
three
categories
of
failure,
by
directing
our
attention
to
the
commands
necessary
to
identify
that
a
problems
exists.
Peer
Rejects
all
MSDP
SA
Messages
As
explained
this
is
a
situation
where
a
MSDP
peer
in
another
autonomous
system
refuses
to
accept
MSDP
SA
messages.
This
situation
can
be
verified
by
generation
a
ping
to
a
test
multicast
address
to
see
if
SA
messages
are
sent
to
a
peer.
We
will
do
this
by
staring
the
ping
from
R1:
R1#ping 224.9.9.9 repeat 10000
Type escape sequence to abort.
Sending 10000, 100-byte ICMP Echos to 224.9.9.9, timeout is 2 seconds:
................ <output omitted>
Now
we
will
check
to
see
of
R4
is
sending
an
SA
message
toward
its
MSDP
peer:
R4#show ip msdp peer 172.16.46.6 advertised-SAs
12-13
This
output
indicates
that
R4
is
sending
the
SA
messages;
we
next
need
to
verify
if
they
arrive
at
R6:
R6#show ip msdp peer 172.16.46.4 accepted-SAs
MSDP SA accepted from peer 172.16.46.4 (?)
R6#
R6
is
not
accepting
any
of
the
SA
messages
from
R4.
The
first
method
employed
to
ascertain
why
will
be
to
look
at
the
MDSP
peering
arrangement
between
R4
and
R6.
This
is
done
with
the
show
ip
msdp
peer
command:
R4#show ip msdp peer
MSDP Peer 172.16.46.6 (?), AS 679 (configured AS)
Connection status:
State: Up, Resets: 2, Connection source: none configured
Uptime(Downtime): 00:26:09, Messages sent/received: 31/27
Output messages discarded: 0
Connection and counters cleared 01:02:39 ago
SA Filtering:
Input (S,G) filter: none, route-map: none
Input RP filter: none, route-map: none
Output (S,G) filter: none, route-map: none
Output RP filter: none, route-map: none
SA-Requests:
Input filter: none
Peer ttl threshold: 0
SAs learned from this peer: 0
Input queue size: 0, Output queue size: 0
MD5 signature protection on MSDP TCP connection: not enabled
R6#show ip msdp peer
MSDP Peer 172.16.46.4 (?), AS 154 (configured AS)
Connection status:
State: Up, Resets: 0, Connection source: none configured
Uptime(Downtime): 00:26:55, Messages sent/received: 27/31
Output messages discarded: 0
Connection and counters cleared 00:27:48 ago
SA Filtering:
Input (S,G) filter: everything, route-map: none
Input RP filter: none, route-map: none
Output (S,G) filter: none, route-map: none
Output RP filter: none, route-map: none
SA-Requests:
12-14
The
output
on
R6
indicates
that
an
input
S,G
filter
has
been
applied
that
blocks
"everything".
Removing
this
filter
will
correct
the
issue
we
have
encounted.
R6#conf t
Enter configuration commands, one per line.
to
to
to
to
to
to
to
to
to
to
request
request
request
request
request
request
request
request
request
request
0
1
2
3
4
5
6
7
8
9
from
from
from
from
from
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
56
56
56
56
56
56
56
56
56
56
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
12-15
Now
we
will
check
to
see
of
R4
is
sending
an
SA
message
toward
its
MSDP
peer:
R4#show ip msdp peer 172.16.46.6 advertised-SAs
MSDP SA advertised to peer 172.16.46.6 (?) from mroute table
224.9.9.9
172.16.15.1 (?)
MSDP SA advertised to peer 172.16.46.6 (?) from SA cache
This
output
indicates
that
R4
is
sending
the
SA
messages;
we
next
need
to
verify
if
they
arrive
at
R6:
R6#show ip msdp peer 172.16.46.4 accepted-SAs
MSDP SA accepted from peer 172.16.46.4 (?)
224.9.9.9
R6
is
accepting
the
SA
messages.
The
next
step
is
to
determine
if
the
S,G
pair
for
the
group
we
see
in
the
SA
message
is
added
to
the
multicast
routing
table:
R6#show ip mroute 224.9.9.9
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.9.9.9), 00:31:48/00:03:08, RP 192.1.6.6, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:31:48/00:03:08
This
output
tells
us
that
the
S,G
group
is
not
added.
Knowing
that
we
have
the
*,G
entry
for
the
group
the
S,G
should
have
been
added.
Perhaps
there
is
a
filter
applied
on
either
R4
or
R6:
R4#show ip msdp peer
MSDP Peer 172.16.46.6 (?), AS 679 (configured AS)
Connection status:
State: Up, Resets: 2, Connection source: none configured
Uptime(Downtime): 00:46:57, Messages sent/received: 54/47
Output messages discarded: 0
Connection and counters cleared 01:23:27 ago
12-16
SA Filtering:
Input (S,G) filter: none, route-map: none
Input RP filter: none, route-map: none
Output (S,G) filter: none, route-map: none
Output RP filter: none, route-map: none
SA-Requests:
Input filter: none
Peer ttl threshold: 0
SAs learned from this peer: 0
Input queue size: 0, Output queue size: 0
MD5 signature protection on MSDP TCP connection: not enabled
R6#show ip msdp peer
MSDP Peer 172.16.46.4 (?), AS 154 (configured AS)
Connection status:
State: Up, Resets: 0, Connection source: none configured
Uptime(Downtime): 00:47:18, Messages sent/received: 48/54
Output messages discarded: 0
Connection and counters cleared 00:48:11 ago
SA Filtering:
Input (S,G) filter: none, route-map: none
Input RP filter: none, route-map: none
Output (S,G) filter: none, route-map: none
Output RP filter: none, route-map: none
SA-Requests:
Input filter: none
Peer ttl threshold: 0
SAs learned from this peer: 1
Input queue size: 0, Output queue size: 0
MD5 signature protection on MSDP TCP connection: not enabled
There
are
no
filters
applied
and
the
MSDP
peering
between
the
RPs
is
working
as
expected.
The
issue
we
are
looking
at
is
definitely
looking
like
an
RP
failure.
Knowing
that
the
group
224.9.9.9
is
being
sourced
from
172.16.15.1
we
can
verify
the
RPF
status
by
using
the
show
ip
rpf
command:
R6#show ip rpf 172.16.15.1
RPF information for ? (172.16.15.1) failed, no route exists
There
is
no
RPF
interface
toward
this
source
address.
We
know
that
we
should
be
learning
this
prefix
via
MP-BGP,
so
we
will
look
at
the
routing
tables
for
the
AFIs
we
have
running
in
this
topology.
First
we
know
that
RPF
information
is
exchanged
using
the
ipv4
multicast
AFI
so
we
will
look
there
first:
R6#show ip bgp ipv4 multicast
BGP table version is 39, local router ID is 192.1.6.6
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
12-17
*>
*>
*>
*>
Network
172.16.79.0/24
192.1.6.0
192.1.7.0
192.1.9.0
Next Hop
172.16.67.7
0.0.0.0
172.16.67.7
172.16.67.7
We
only
see
the
address
originating
in
our
own
AS
as
indicated
by
the
Weight
Attribute
of
32768
we
know
these
routes
are
redistributed
into
the
MP-BGP
process
because
of
the
incomplete
(?)
Origin
code.
What
about
the
unicast
AFI?
R6#show ip bgp ipv4 unicast
R6#
There
are
no
routes
at
all
in
the
ipv4
unicast
AFI.
Are
any
prefixes
being
advertised
to
us
from
R4?
R4#show ip bgp ipv4 unicast neighbors 172.16.46.6 advertised-routes
Total number of prefixes 0
R4#show ip bgp ipv4 multicast neighbors 172.16.46.6 advertised-routes
Total number of prefixes 0
Nothing
is
being
advertised
from
R4
for
either
of
the
AFIs.
We
can
look
at
the
BGP
configuration
via
the
show
run
command:
R4#show run | sec bgp
router bgp 154
bgp log-neighbor-changes
neighbor 172.16.45.5 remote-as 154
neighbor 172.16.46.6 remote-as 679
!
address-family ipv4
neighbor 172.16.45.5 activate
neighbor 172.16.45.5 next-hop-self
neighbor 172.16.46.6 activate
no auto-summary
no synchronization
exit-address-family
!
address-family ipv4 multicast
redistribute ospf 1 match internal
neighbor 172.16.45.5 activate
neighbor 172.16.45.5 next-hop-self
neighbor 172.16.46.6 activate
12-18
no auto-summary
no synchronization
exit-address-family
We
see
that
OSPF
routes
are
not
being
redistributed
into
the
unicast
AFI.
This
can
be
corrected
via:
R4#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)#router bgp 154
R4(config-router)#address-family ipv4 unicast
R4(config-router-af)#redistribute ospf 1
R4(config-router-af)#end
to
to
to
to
to
to
to
to
to
to
request
request
request
request
request
request
request
request
request
request
0
1
2
3
4
5
6
7
8
9
from
from
from
from
from
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
56
56
56
56
56
56
56
56
56
56
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
12-19
SA-Requests:
Input filter: none
Peer ttl threshold: 0
SAs learned from this peer: 0
Input queue size: 0, Output queue size: 0
MD5 signature protection on MSDP TCP connection: not enabled
R6#show ip msdp peer
MSDP Peer 192.1.4.4 (?), AS 154 (configured AS)
Connection status:
State: Down, Resets: 0, Connection source: none configured
Uptime(Downtime): 00:03:52, Messages sent/received: 0/0
Output messages discarded: 0
Connection and counters cleared 00:03:52 ago
SA Filtering:
Input (S,G) filter: none, route-map: none
Input RP filter: none, route-map: none
Output (S,G) filter: none, route-map: none
Output RP filter: none, route-map: none
SA-Requests:
Input filter: none
Peer ttl threshold: 0
SAs learned from this peer: 0
Input queue size: 0, Output queue size: 0
MD5 signature protection on MSDP TCP connection: not enabled
This
output
informs
us
that
the
MSDP
peering
is
down.
We
see
that
authentication
is
not
configured,
and
we
see
that
the
MSDP
peering
addresses
used
were
the
Loopback0
interfaces.
But
we
see
that
no
connection
source
was
specified.
This
might
initially
look
like
our
problem
but
closer
examination
of
the
output
tells
us
that
we
are
using
a
remote
AS.
Knowing
that
the
MSDP
must
use
the
same
ip
address
used
to
form
the
MP-BGP
peering
we
will
need
to
change
this
configuration.
What
address
was
used
to
form
the
MP-BGP
peering
session
between
R4
and
R6?
R4#show ip bgp ipv4 unicast summary
BGP router identifier 192.1.4.4, local AS number 154
BGP table version is 8, main routing table version 8
7 network entries using 840 bytes of memory
7 path entries using 364 bytes of memory
8/3 BGP path/bestpath attribute entries using 992 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
Bitfield cache entries: current 2 (at peak 2) using 64 bytes of memory
BGP using 2284 total bytes of memory
BGP activity 73/55 prefixes, 83/65 paths, scan interval 60 secs
Neighbor
AS MsgRcvd MsgSent
TblVer
State/PfxRcd
12-20
172.16.45.5
172.16.46.6
4
4
154
679
193
144
188
164
8
8
0
0
0 00:18:57
0 00:18:57
0
0
The
frame
relay
point-to-point
interface
was
used,
so
we
will
need
to
use
those
addresses
for
the
MSDP
peering:
R4#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)#no ip msdp peer 192.1.6.6 remote-as 679
R4(config)#ip msdp peer 172.16.46.6 remote-as 679
R4(config)#end
R6#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R6(config)#no ip msdp peer 192.1.4.4 remote-as 154
R6(config)#ip msdp peer 172.16.46.4 remote-as 154
R6(config)#end
R6#
%MSDP-5-PEER_UPDOWN: Session to peer 172.16.46.4 going up
The
console
messages
tell
us
the
MSDP
session
has
been
formed.
As
final
test
are
ping
from
R1
successful?
R1#ping 224.9.9.9 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 224.9.9.9, timeout is 2 seconds:
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
to
to
to
to
to
to
to
to
to
to
request
request
request
request
request
request
request
request
request
request
0
1
2
3
4
5
6
7
8
9
from
from
from
from
from
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
76
56
56
56
56
56
56
56
56
56
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
12-21
show
COMMAND:
show
ip
msdp
peer
ip_address
This
command
displays
detailed
information
about
Multicast
Source
Discovery
Protocol
(MSDP)
peers.
Where:
EXAMPLE OUTPUT:
R6#show ip msdp peer 192.1.5.5
MSDP peer 192.1.5.5 not found
R6#show ip msdp peer 192.1.4.4
MSDP Peer 192.1.4.4 (?), AS ?
Connection status:
State: Up, Resets: 0, Connection source: Loopback0 (192.1.6.6)
Uptime(Downtime): 01:17:18, Messages sent/received: 77/86
Output messages discarded: 0
Connection and counters cleared 01:17:49 ago
SA Filtering:
Input (S,G) filter: none, route-map: none
Input RP filter: none, route-map: none
Output (S,G) filter: none, route-map: none
Output RP filter: none, route-map: none
SA-Requests:
12-22
show
COMMAND:
show
ip
msdp
peer
ip_address
advertised-SAs
This
command
displays
detailed
information
about
Multicast
Source
Discovery
Protocol
(MSDP)
peers.
Where:
EXAMPLE OUTPUT:
R4#show ip msdp peer 192.1.6.6 advertised-SAs
MSDP SA advertised to peer 192.1.6.6 (?) from mroute table
224.9.9.9
172.16.15.1 (?)
MSDP SA advertised to peer 192.1.6.6 (?) from SA cache
R4#
show
COMMAND:
show
ip
bgp
ipv4
multicast
summary
This
command
displays
IPv4
multicast
database
information.
EXAMPLE OUTPUT:
R4#show ip bgp ipv4 multicast summary
BGP router identifier 192.1.4.4, local AS number 154
BGP table version is 12, main routing table version 12
9 network entries using 1188 bytes of memory
9 path entries using 432 bytes of memory
7/6 BGP path/bestpath attribute entries using 1176 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
Bitfield cache entries: current 2 (at peak 2) using 64 bytes of memory
12-23
V
4
4
AS MsgRcvd MsgSent
154
14
13
679
7
12
TblVer
12
12
State/PfxRcd
0
3
show
COMMAND:
show
ip
bgp
ipv4
multicast
This
command
displays
detailed
information
about
ipv4
multicast
learned
prefixes.
EXAMPLE OUTPUT:
R4#show ip bgp ipv4 multicast
BGP table version is 12, local router ID is 192.1.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
*>
*>
*>
*>
*>
*>
*>
*>
*>
Network
172.16.15.0/24
172.16.45.0/24
172.16.46.0/24
172.16.79.0/24
192.1.1.1/32
192.1.4.0
192.1.5.5/32
192.1.7.0
192.1.9.0
Next Hop
172.16.45.5
0.0.0.0
0.0.0.0
172.16.46.6
172.16.45.5
0.0.0.0
172.16.45.5
172.16.46.6
172.16.46.6
12-24
debug
COMMAND:
debug
ip
msdp
detail
This
command
displays
detailed
information
regarding
MSDP
operations.
EXAMPLE OUTPUT:
R4#debug ip msdp detail
MSDP Detail debugging is on
R4#
MSDP(0): Received 3-byte TCP segment from 192.1.6.6
MSDP(0): Append 3 bytes to 0-byte msg 92 from 192.1.6.6, qs 1
R4#
MSDP(0): Sent entire mroute table, mroute_cache_index = 0, Qlen = 0
MSDP(0): start_index = 0, sa_cache_index = 0, Qlen = 0
MSDP(0): Sent entire sa-cache, sa_cache_index = 0, Qlen = 0
R4#
MSDP(0): Received 3-byte TCP segment from 192.1.6.6
MSDP(0): Append 3 bytes to 0-byte msg 93 from 192.1.6.6, qs 1
R4#
debug
COMMAND:
debug
ip
bgp
ipv4
multicast
This
command
displays
detailed
information
regarding
bgp
ipv4
multicast
operations.
12-25
EXAMPLE OUTPUT:
R4#debug ip bgp ipv4 multicast
BGP debugging is on for address family: IPv4 Multicast
BGPNSF state: 172.16.46.6 went from nsf_not_active to nsf_not_active
BGP: 172.16.46.6 went from Established to Idle
%BGP-5-ADJCHANGE: neighbor 172.16.46.6 Down User reset
R4#
BGP: 172.16.46.6 closing
R4#
BGP: 172.16.46.6 went from Idle to Active
BGP: 172.16.46.6 open active, local address 172.16.46.4
BGP: 172.16.46.6 read request no-op
BGP: 172.16.46.6 went from Active to OpenSent
BGP: 172.16.46.6 sending OPEN, version 4, my as: 154, holdtime 180 seconds
BGP: 172.16.46.6 send message type 1, length (incl. header) 61
BGP: 172.16.46.6 rcv message type 1, length (excl. header) 42
BGP: 172.16.46.6 rcv OPEN, version 4, holdtime 180 seconds
BGP: 172.16.46.6 rcv OPEN w/ OPTION parameter len: 32
BGP: 172.16.46.6 rcvd OPEN w/ optional parameter type 2 (Capability) len 6
BGP: 172.16.46.6 OPEN has CAPABILITY code: 1, length 4
BGP: 172.16.46.6 OPEN has MP_EXT CAP for afi/safi: 1/1
BGP: 172.16.46.6 rcvd OPEN w/ optional parameter type 2 (Capability) len 6
BGP: 172.16.46.6 OPEN has CAPABILITY code: 1, length 4
BGP: 172.16.46.6 OPEN has MP_EXT CAP for afi/safi: 1/2
BGP: 172.16.46.6 rcvd OPEN w/ optional parameter type 2 (Capability) len 2
BGP: 172.16.46.6 OPEN has CAPABILITY code:
R4#128, length 0
BGP: 172.16.46.6 OPEN has ROUTE-REFRESH capability(old) for all address-families
BGP: 172.16.46.6 rcvd OPEN w/ optional parameter type 2 (Capability) len 2
BGP: 172.16.46.6 OPEN has CAPABILITY code: 2, length 0
BGP: 172.16.46.6 OPEN has ROUTE-REFRESH capability(new) for all address-families
BGP: 172.16.46.6 rcvd OPEN w/ optional parameter type 2 (Capability) len 6
BGP: 172.16.46.6 OPEN has CAPABILITY code: 65, length 4
BGP: 172.16.46.6 OPEN has 4-byte ASN CAP for: 679
BGP: 172.16.46.6 rcvd OPEN w/ remote AS 679, 4-byte remote AS 679
BGP: 172.16.46.6 went from OpenSent to OpenConfirm
BGP: 172.16.46.6 went from OpenConfirm to Established
%BGP-5-ADJCHANGE: neighbor 172.16.46.6 Up
R4#
12-26
Trouble
Ticket
#1
Your
supervisor
has
brought
to
your
attention
that
R4
and
R6
are
not
successfully
forming
a
MSDP
peering
relationship.
Correct
this
issue.
Trouble
Ticket
#2
After
solving
Trouble
Ticket
#1,
your
supervisor
has
observed
that
multicast
pings
from
R1
to
the
group
224.9.9.9
do
not
reach
test
clients
on
R9
VLAN79
segment.
Correct
this
issue.
12-27
The
status
of
the
peering
relation
to
172.16.46.6
is
Down.
This
verifies
that
the
problem
actually
exists.
Step
2
-
Fault
Isolation:
Failure
of
MSDP
peers
to
form
are
either
caused
by
misconfiguration
or
unicast
routing
failures.
We
will
rule
out
misconfiguration
by
comparing
the
output
of
the
show
ip
msdp
peer
command
on
R6:
R6#sh ip msdp peer
MSDP Peer 172.16.46.4 (?), AS 154 (configured AS)
Connection status:
State: Listen, Resets: 0, Connection source: none configured
Uptime(Downtime): 00:06:10, Messages sent/received: 0/0
Output messages discarded: 0
Connection and counters cleared 00:06:10 ago
SA Filtering:
12-28
The
last
line
of
the
output
on
R6
says
that
MD5
authentication
is
enabled.
Authentication
is
not
enabled
on
R4,
this
has
isolated
our
problem.
Step
3
-
Fault
Remediation:
In
this
scenario,
the
ip
msdp
password
command
needs
to
be
applied
to
R4:
R4#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)#ip msdp password peer 172.16.46.6 CISCO
R4(config)#end
R4#
%MSDP-5-PEER_UPDOWN: Session to peer 172.16.46.6 going up
12-29
The
MSDP
peering
session
status
is:
Up.
The
solution
has
successfully
remediated
the
problem.
Trouble
Ticket
#2
Solution
After
solving
Trouble
Ticket
#1,
your
supervisor
has
observed
that
multicast
pings
from
R1
to
the
group
224.9.9.9
do
not
reach
test
clients
on
R9
VLAN79
segment.
Correct
this
issue.
Step
1
-
Fault
Verification:
Are
pings
from
R1
to
224.9.9.9
successful?
R1#ping 224.9.9.9 repeat 10000
Type escape sequence to abort.
Sending 10000, 100-byte ICMP Echos to 224.9.9.9, timeout is 2 seconds:
................. <output omitted>
The
pings
fail,
thus
proving
the
problem
exists.
Step
2
-
Fault
Isolation:
The
first
step
is
to
see
if
R4
generates
SA
messages
for
the
group
224.9.9.9
and
sends
them
to
its
peer.
R4#show ip msdp peer 172.16.46.6 advertised-SAs
MSDP SA advertised to peer 172.16.46.6 (?) from mroute table
224.9.9.9
172.16.15.1 (?)
MSDP SA advertised to peer 172.16.46.6 (?) from SA cache
R6
accepts
the
SA
messages.
Under
normal
circumstances
R6
should
add
a
S,G
pair
to
its
multicast
routing
table
for
this
group,
if
there
is
a
*,G
learned
from
an
interested
source.
This
can
be
verified
with
show
ip
mroute:
R6#show ip mroute 224.9.9.9
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,
Z - Multicast Tunnel, z - MDT-data group sender,
12-30
The
*,G
entry
is
in
the
table
but
not
the
S,G
for
the
source
172.16.15.1.
This
could
be
a
reachability
issues
or
an
RPF
issue.
We
will
check
the
RPF
status
first.
R6#show ip rpf 172.16.15.1
RPF information for ? (172.16.15.1) failed, no route exists
This
clearly
tells
us
that
we
have
an
RPF
issue.
Remember
that
RPF
checks
in
MP-BGP
are
performed
against
the
contents
of
the
ipv4
multicast
AFI.
We
can
look
at
the
contents
of
this
table
via
show
ip
bgp
ipv4
multicast:
R6#show ip bgp ipv4 multicast
BGP table version is 53, local router ID is 192.1.6.6
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
*>
*>
*>
*>
Network
172.16.79.0/24
192.1.6.0
192.1.7.0
192.1.9.0
Next Hop
172.16.67.7
0.0.0.0
172.16.67.7
172.16.67.7
This
output
reflects
that
we
only
see
prefixes
redistributed
(?)
into
our
AS
on
R6
(based
on
the
weight
value
of
32768).
Where
are
the
routes
learned
from
AS154?
R4#show ip bgp ipv4 multicast neighbors 172.16.46.6 advertised-routes
Total number of prefixes 0
R4
is
not
advertising
any
ipv4
multicast
prefixes
additionally
it
is
not
advertising
any
ipv4
unicast
routes
either:
R4#show ip bgp ipv4 unicast neighbors 172.16.46.6 advertised-routes
Total number of prefixes 0
12-31
A
show
run
will
reveal
that
R4
is
not
redistributing
ospf
information
into
the
address-family
ipv4
unicast:
R4#show run | sec bgp
router bgp 154
bgp log-neighbor-changes
neighbor 172.16.45.5 remote-as 154
neighbor 172.16.46.6 remote-as 679
!
address-family ipv4
neighbor 172.16.45.5 activate
neighbor 172.16.45.5 next-hop-self
neighbor 172.16.46.6 activate
no auto-summary
no synchronization
exit-address-family
!
address-family ipv4 multicast
redistribute ospf
neighbor 172.16.45.5 activate
neighbor 172.16.45.5 next-hop-self
neighbor 172.16.46.6 activate
no auto-summary
no synchronization
exit-address-family
Without
unicast
reachability
this
configuration
cannot
work.
This
has
isolated
our
fault.
Step
3
-
Fault
Remediation:
In
this
scenario,
the
redistribute
ospf
1
command
needs
to
applied
under
the
ipv4
unicast
AFI
on
R4:
R4(config)#router bgp 154
R4(config-router)#address-family ipv4 unicast
R4(config-router-af)#redistribute ospf 1
R4(config-router-af)#end
12-32
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
to
to
to
to
to
to
to
to
request
request
request
request
request
request
request
request
2
3
4
5
6
7
8
9
from
from
from
from
from
from
from
from
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
172.16.79.9,
56
56
56
56
56
56
56
56
ms
ms
ms
ms
ms
ms
ms
ms
Pings
are
now
successful,
thus
verifying
that
the
error
has
been
corrected.
12-33
Chapter
13:
Multicast
Security
and
Advanced
Features
This
chapter
of
IPv4/6
Multicast
Operation
and
Troubleshooting
details
the
security
features
of
Multicast
technologies
in
great
depth.
This
chapter
also
covers
several
advanced
multicast
features.
This
chapter
includes
the
careful
examination
of
symptoms,
a
fault
isolation
methodology,
and
the
implementation
of
repairs
for
these
various
features.
The
chapter
begins
with
a
thorough
review
of
these
various
features,
and
then
quickly
launches
in
to
an
exhaustive
analysis
of
the
art
of
troubleshooting.
This
important
chapter
concludes
with
sample
troubleshooting
scenarios
and
exciting
challenges
that
allow
readers
to
practice
implementing
the
troubleshooting
skills
they
have
obtained.
13-1
Using
the
topology
outlined
in
figure
13-2
this
chapter
will
take
an
intuitive
approach
to
describing
the
operation
and
troubleshooting
issues
associated
with
the
following
multicast
security
topics:
Multicast
Filtering
on
a
Cisco
Catalyst
Switch
This
section
details
the
two
primary
tools
used
to
filter
multicast
packets.
In
this
instance
we
are
using
the
term
multicast
packets
to
describe
control
plane
packets.
This
means
we
are
looking
at
both
IGMP
and
PIM
messages.
However,
most
specifically
this
section
will
deal
with
IGMP.
Using
either
a
static
IGMP
join
filter
or
the
more
dynamic
IGMP
snooping
protocol
certain
multicast
security
processes
can
be
put
into
place.
We
will
begin
with
the
filtering
IGMP
Join
messages.
13-2
We
can
clearly
see
that
both
devices
have
joined
the
multicast
group
224.9.9.9
by
looking
at
the
output
of
generating
a
ping
from
R5
for
the
group
224.9.9.9.
We
will
expect
based
on
the
fact
that
this
topology
is
running
PIM-DM
that
we
should
obtain
echo
replies
from
both
R8
and
R9:
R5#ping 224.9.9.9 r 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 224.9.9.9, timeout is 2 seconds:
Reply to request
Reply to request
Reply to request
Reply to request
Reply to request
Reply to request
<output omitted>
0
0
1
1
2
2
from
from
from
from
from
from
172.16.200.8,
172.16.200.9,
172.16.200.9,
172.16.200.8,
172.16.200.9,
172.16.200.8,
4
4
1
1
1
1
ms
ms
ms
ms
ms
ms
We
see
the
results
match
what
we
expected.
However,
in
the
situation
where
we
would
not
want
R9
to
join
the
multicast
group
224.9.9.9,
we
would
apply
an
IGMP
profile
like
this:
CAT2(config)#ip igmp profile 1
CAT2(config-igmp-profile)#deny
CAT2(config-igmp-profile)#range 224.9.9.9 224.9.9.9
13-3
CAT2(config-igmp-profile)#exit
CAT2(config)#interface FastEthernet0/9
CAT2(config-if)#ip igmp filter 1
CAT2(config-if)#end
The
most
common
issue
associated
with
IGMP
filtering
is
a
failure
to
create
the
profile,
or
the
miss
application
of
the
igmp
filter
command.
Issues
associated
with
this
process
can
best
be
isolated
using
debug
ip
igmp
filter
on
the
switch
where
the
process
has
been
applied:
CAT2#show ip igmp filter
IGMP filter enabled
CAT2#
IGMPFILTER: igmp_filter_process_pkt() checking group from Fa0/7 : no profile attached
CAT2#
IGMPFILTER: igmp_filter_process_pkt(): checking group 224.9.9.9 from Fa0/9: deny
CAT2#
IGMPFILTER: igmp_filter_process_pkt() checking group from Fa0/8 : no profile attached
13-4
from
being
sent
to
the
multicast
devices
and
in
effect
is
filtering
IGMP
messages
for
the
purpose
of
bandwidth
and
processor
conservation.
There
are
no
commands
to
activate
this
protocol,
but
it
can
be
turned
off
via
the
no
ip
igmp
snooping.
BSR-Border
Filter
In
situations
where
there
are
two
or
more
multicast
domains
it
is
often
desirable
to
bound
or
scope
multicast
control
plane
protocols
to
their
respective
domains.
This
is
accomplished
with
regard
to
BSR
environments
by
applying
the
ip
pim
bsr-border
command
at
the
multicast
domain
boundaries.
When
this
command
is
used
on
a
interface,
no
PIM
BSR
messages
will
be
allowed
to
enter
or
be
sent
out
the
interface.
This
prevents
BSR
information
from
being
exchanged
between
multicast
inter
domain
neighbors.
Typically,
this
is
to
prevent
the
accidental
election
of
an
RP
not
found
in
a
particular
multicast
domain.
Common
issues
associated
with
the
use
of
this
command
are
incorrect
placement.
This
command
can
in
effect
split
what
should
be
an
otherwise
contiguous
domain
into
two
dysfunctional
domains.
PIM
Neighbor
Filter
Two
primary
factors
will
facilitate
the
need
or
desire
to
use
a
PIM
neighbor
filter.
The
first
reason
is
for
security
purposes.
There
are
circumstances
where
all
devices
on
a
WAN
or
LAN
are
not
under
a
single
administrative
control.
In
order
to
manage
what
multicast
trees
are
formed
over
the
network
it
is
necessary
to
prevent
any
devices
that
you
do
not
manage
from
being
able
to
participate
in
your
PIM
environment.
This
more
often
than
not
means
that
a
network
administrator
will
take
all
necessary
steps
to
ensure
that
no
device
can
become
the
DR
for
a
given
segment,
or
prevent
any
undesirable
devices
from
discovering
the
identity
of
or
using
any
RPs
designated
in
our
domain.
The
second
most
common
rationale
for
this
feature
is
to
create
a
multicast
"stub
routing
environment."
In
stub
routing,
the
all
routers,
even
those
we
do
not
manage,
are
still
able
to
take
part
in
the
forwarding
of
multicast
packets,
but
they
must
do
so
by
exchanging
IGMP
Join
and
Leave
packets
with
designated
devices
in
our
managed
domain.
In
this
scenario,
it
is
possible
to
conserve
resources
by
reducing
the
number
of
PIM
neighbor
states
to
track.
Typically,
multicast
stub
networks
use
PIM-DM
and
therefore
conserve
resources
on
your
RPs.
In
our
topology
we
create
a
multicast
stub
environment
by
prevent
R1
from
accepting
PIM
joins
from
R7
via
the
VLAN17
segment
connecting
them:
R1#conf t
Enter configuration commands, one per line.
R1(config)#interface FastEthernet0/1
R1(config-if)#ip pim neighbor-filter 1
R1(config-if)#exit
R1(config)#access-list 1 deny 172.16.17.7
13-5
R1(config)#end
Keep
in
mind
that
this
PIM
relationship
will
have
to
expire
before
we
see
visible
results:
R1#
%PIM-5-NBRCHG: neighbor 172.16.17.7 DOWN on interface FastEthernet0/1 DR
%PIM-5-DRCHG: DR change from neighbor 172.16.17.7 to 172.16.17.1 on interface
FastEthernet0/1
This
issue
now
is
the
fact
that
we
do
not
have
a
peering
relationship
between
R1
and
R7.
Multicast
Helper
Address
There
are
situations
where
limitations
in
the
network
or
applications
running
on
the
network
necessitate
the
need
to
convert
multicast
traffic
into
broadcast
traffic.
Assumptions
that
suggest
all
devices
on
a
segment
may
require
the
packets
associated
with
a
multicast
stream,
or
issues
where
applications
need
the
packet
and
do
not
support
multicast
protocol
lead
to
the
necessity
to
deploy
the
multicast
helper
command.
In
this
scenario,
we
will
remove
the
PIM
neighbor
relationship
between
R1
and
R7:
R1(config)#interface FastEthernet0/1
R1(config-if)#no ip pim dense
R1(config-if)#no ip pim dense-mode
R1(config-if)#end
R7#conf t
Enter configuration commands, one per line.
R7(config)#interface FastEthernet0/1
R7(config-if)#no ip pim dense-mode
R7(config-if)#end
This
deployment
facilitates
the
conversion
of
multicast
traffic
to
some
method
of
transfer
that
will
be
able
to
reach
host
across
the
now
PIM
disabled
connection.
We
will
illustrate
the
issue
by
having
R8
join
the
multicast
group
224.9.9.9
and
then
test
from
R5
using
that
group:
R8#conf t
Enter configuration commands, one per line.
R8(config)#interface FastEthernet0/0
R8(config-if)#ip igmp join-group 224.9.9.9
R8(config-if)#end
13-6
The
pings
are
unsuccessful.
Nevertheless,
if
we
utilize
the
multicast
address-helper
command
to
use
broadcast
traffic
to
overcome
this
configuration
issue.
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#interface FastEthernet0/0
R1(config-if)# ip multicast helper-map 224.9.9.9 172.16.100.5 100
R1(config-if)#!
R1(config-if)#interface FastEthernet0/1
R1(config-if)# ip directed-broadcast
R1(config-if)#!
R1(config-if)#ip forward-protocol udp 5001
R1(config)#!
R1(config)#access-list 100 permit udp any any eq 5001
At
this
point,
the
modification
to
R1
is
going
to
take
any
traffic
sourced
from
the
ip
address
172.16.100.5
for
the
group
224.9.9.9
and
translate
it
to
udp
broadcast
traffic
destined
to
port
5001.
The
next
portion
will
be
to
go
to
R7
and
translate
it
back
to
multicast
so
that
it
can
be
multicast
forwarded
the
rest
of
the
way
toward
the
hosts.
R7#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R7(config)#interface FastEthernet0/1
R7(config-if)# ip multicast helper-map broadcast 239.1.1.1 100
R7(config-if)#!
R7(config-if)#ip forward-protocol udp 5001
R7(config)#!
R7(config)#access-list 100 permit udp any any eq 5001
This
configuration
can
now
be
tested
on
R5
by
repeating
the
multicast
ping.
R5#ping 224.9.9.9 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 224.9.9.9, timeout is 2 seconds:
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
to
to
to
to
to
to
to
to
to
to
request
request
request
request
request
request
request
request
request
request
0
1
2
3
4
5
6
7
8
9
from
from
from
from
from
from
from
from
from
from
172.16.100.1,
172.16.100.1,
172.16.100.1,
172.16.100.1,
172.16.100.1,
172.16.100.1,
172.16.100.1,
172.16.100.1,
172.16.100.1,
172.16.100.1,
4
1
1
1
1
1
1
1
1
1
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
13-7
This
configuration
is
working
perfectly.
In
scenarios
where
the
traffic
can
remain
broadcast
in
nature
it
is
not
necessary
to
translate
it
back
to
multicast.
Common
issues
impacting
the
deployment
of
this
solution
include
failure
to
enable
directed
broadcast,
use
of
the
wrong
udp
port
number,
or
incorrectly
configured
access-lists.
Multicast
Route
Limiting
In
certain
situations,
it
is
deem
necessary
or
important
to
restrict
the
number
of
routes
that
are
added
to
a
multicast
routing
table.
The
use
of
the
command
ip
multicast
route-limit
accomplishes
the
establishment
of
this
upper
threshold.
The
fact
that
this
command
will
generate
messages
that
continue
to
occur
so
long
as
configured
limit
is
being
exceeded.
We
will
configure
R1
such
that
it
will
attempt
to
limit
the
number
of
routes
in
the
multicast
routing
table
to
2:
R1#conf t
Enter configuration commands, one per line.
R1(config)#ip multicast route-limit 2
The
most
common
issue
that
causes
problems
in
the
deployment
of
this
configuration
is
the
failure
to
take
multicast
groups
like
224.0.1.40
that
all
routers
will
join
in
account.
But
the
router
will
send
messages
explaining
that
an
issue
exists
so
long
as
the
route-limit
is
exceeded.
R1#
%MROUTE-4-ROUTELIMIT_ATTEMPT: Attempt to exceed multicast route-limit of 2 -Process=
"IGMP Input", ipl= 0, pid= 250
13-8
R1(config)#interface FastEthernet0/0
R1(config-if)#ip multicast rate-limit in group-list 1 source-list 2 0
R1(config-if)#end
If
the
command
has
worked
as
anticipated,
the
ping
will
work
for
the
same
group
from
R2:
R2#ping 224.9.9.9 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 224.9.9.9, timeout is 2 seconds:
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Reply
to
to
to
to
to
to
to
to
to
to
request
request
request
request
request
request
request
request
request
request
0
1
2
3
4
5
6
7
8
9
from
from
from
from
from
from
from
from
from
from
172.16.200.8,
172.16.200.8,
172.16.200.8,
172.16.200.8,
172.16.200.8,
172.16.200.8,
172.16.200.8,
172.16.200.8,
172.16.200.8,
172.16.200.8,
1
1
1
1
1
1
1
1
1
1
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
13-9
to
use
a
multicast
static
route
to
correct
any
RFP
issues.
We
will
remove
the
PIM
relationship
between
R1
and
R7
once
more
but
this
time
we
will
create
GRE
tunnel
between
R1
and
R7.
R1(config)#interface FastEthernet0/1
R1(config-if)#no ip pim dense-mode
R1(config-if)#end
R7(config)#interface FastEthernet0/1
R7(config-if)#no ip pim dense-mode
R7(config-if)#end
We
can
look
at
the
status
of
the
tunnel
and
test
that
it
works
via
pings:
R7#show ip int brief tunnel 17
Interface
IP-Address
Tunnel17
17.17.17.7
Protocol
up
R7#ping 17.17.17.1
13-10
This
can
be
corrected
by
applying
an
ip
mroute
for
the
source
172.16.100.5
that
specifies
the
tunnel
17
interface:
R7(config)#ip mroute 172.16.100.5 255.255.255.255 tunnel 17
to
to
to
to
to
to
to
to
to
to
request
request
request
request
request
request
request
request
request
request
0
1
2
3
4
5
6
7
8
9
from
from
from
from
from
from
from
from
from
from
172.16.200.8,
172.16.200.8,
172.16.200.8,
172.16.200.8,
172.16.200.8,
172.16.200.8,
172.16.200.8,
172.16.200.8,
172.16.200.8,
172.16.200.8,
4
1
1
1
1
1
1
1
1
1
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
Most
notably
this
demonstration
illustrates
the
need
to
account
for
the
fact
that
the
GRE
tunnel
will
not
appear
in
the
unicast
routing
table,
and
thus
cannot
be
employed
to
reach
any
source.
Source-Specific
Multicast
RFC
3569
describes
source-specific
multicast
(SSM).
It
is
a
datagram
delivery
model
that
best
supports
audio
and
video-based
one-to-many
applications.
SSM
depends
on
Protocol
Independent
Multicast
source-specific
mode
(PIM-SSM)
and
Internet
Group
Management
Protocol
Version
3
(IGMPv3)
for
its
implementation.
PIM-SSM
is
based
on
PIM
sparse
mode
(PIM-SM).
Review
Chapter
4:
Protocol
13-11
Independent
Multicast
-
Sparse
Mode
(PIM-SM)
should
you
need
more
information
on
this
important
protocol.
A
multicast
network
must
maintain
knowledge
about
which
hosts
in
the
network
are
actively
sending
multicast
traffic.
With
source-specific
multicast,
this
information
is
provided
by
receivers
through
the
source
addresses
relayed
to
the
last-hop
routers
using
IGMPv3.
In
SSM,
receivers
must
subscribe
or
unsubscribe
to
(S,
G)
channels
to
receive
or
not
receive
traffic
from
specific
sources.
The
proposed
standard
approach
for
channel
subscription
signaling
utilizes
IGMP
INCLUDE
mode
membership
reports,
which
are
supported
only
in
IGMP
Version
3.
SSM
coexists
with
normal
PIM
and
IGMP
operations
by
applying
the
SSM
delivery
model
to
a
configured
subset
of
the
IP
multicast
group
address
range.
The
Internet
Assigned
Numbers
Authority
(IANA)
has
reserved
the
address
range
from
232.0.0.0
through
232.255.255.255
for
SSM
applications
and
protocols.
When
an
SSM
range
is
defined,
an
existing
IP
multicast
receiver
application
will
not
receive
any
traffic
when
it
tries
to
use
addresses
in
the
SSM
range
unless
the
application
is
modified
to
use
explicit
(S,
G)
channel
subscription
or
is
SSM-enabled
through
a
URL
Rendezvous
Directory
(URD).
SSM
can
be
deployed
alone
in
a
network
without
the
full
range
of
protocols
that
are
required
for
interdomain
PIM-SM.
In
other
words,
SSM
does
not
require
a
rendezvous
point
(RP),
so
there
is
no
need
for
an
RP
mechanism
such
as
Auto-RP,
MSDP,
or
bootstrap
router
(BSR).
Deploying
SSM
in
a
network
that
is
already
configured
for
PIM-SM
simply
requires
the
last-hop
routers
be
upgraded
to
a
software
image
that
supports
SSM.
These
non-last-hop
routers
must
only
run
PIM-SM
in
the
SSM
range.
The
SSM
mode
of
operation
is
enabled
by
configuring
the
SSM
range
using
the
ip
pim
ssm
global
configuration
command.
For
groups
within
the
SSM
range,
(S,
G)
channel
subscriptions
are
accepted
through
IGMPv3
INCLUDE
mode
membership
reports.
PIM
operations
within
the
SSM
range
of
addresses
change
to
PIM-SSM,
a
mode
derived
from
PIM-SM.
In
this
mode,
only
PIM
(S,
G)
Join
and
Prune
messages
are
generated
by
the
router.
Incoming
messages
related
to
rendezvous
point
tree
(RPT)
operations
are
ignored
or
rejected,
and
incoming
PIM
register
messages
are
immediately
answered
with
Register-Stop
messages.
PIM-SSM
is
backward-compatible
with
PIM-SM
unless
a
router
is
a
last-hop
router.
Therefore,
routers
that
are
not
last-hop
routers
can
run
PIM-SM
for
SSM
groups
(for
example,
if
they
do
not
yet
support
SSM).
For
groups
within
the
SSM
range,
no
MSDP
Source-Active
(SA)
messages
within
the
SSM
range
will
be
accepted,
generated,
or
forwarded.
IGMPv3
is
the
third
version
of
the
IETF
standards
track
protocol
in
which
hosts
signal
membership
to
last-hop
routers
of
multicast
groups.
IGMPv3
introduces
the
ability
for
hosts
to
signal
group
membership
13-12
that
allows
filtering
capabilities
with
respect
to
sources.
A
host
can
signal
either
that
it
wants
to
receive
traffic
from
all
sources
sending
to
a
group
except
for
some
specific
sources
(a
mode
called
EXCLUDE)
or
that
it
wants
to
receive
traffic
only
from
some
specific
sources
sending
to
the
group
(a
mode
called
INCLUDE).
IGMPv3
can
operate
with
both
ISM
and
SSM.
In
ISM,
both
EXCLUDE
and
INCLUDE
mode
reports
are
accepted
by
the
last-hop
router.
In
SSM,
only
INCLUDE
mode
reports
are
accepted
by
the
last-hop
router.
In
some
environments
it
is
necessary
to
adapt
the
typical
PIM
protocol
deployment
in
such
a
fashion
as
to
allow
it
to
better
support
one-to-many
packet
exchange
models.
This
adaptation
takes
the
form
of
a
special
extension
called
Source
Specific
Multicast
(SSM).
This
extension
enables
a
receiver
to
select
content
directly
from
a
specified
source.
This
results
in
the
creation
of
a
source
based
tree,
thus
bypassing
the
need
for
a
using
an
RP.
In
most
multicast
implementations,
applications
must
"join"
an
IP
multicast
group,
because
traffic
is
distributed
group
members.
If
two
applications
with
different
sources
and
receivers
use
the
same
IP
multicast
group
address,
receivers
of
both
applications
will
receive
traffic
from
the
senders
of
both
the
applications.
Even
though
the
receivers,
if
programmed
appropriately,
can
filter
out
the
unwanted
traffic,
using
filters
like
those
discussed
previously,
this
situation
generates
large
amounts
of
unwanted
traffic.
However,
in
an
SSM
multicast
network,
the
router
closest
to
the
receiver
will
be
aware
of
a
request
coming
from
an
application
to
join
to
a
particular
multicast
source
by
using
the
include
mode
in
IGMPv3.
The
multicast
router
now
forwards
the
request
directly
to
the
source
rather
than
sending
the
request
to
an
RP.
The
source
will
send
packets
directly
to
the
receiver
using
the
shortest
path.
In
SSM,
routing
of
multicast
traffic
relies
solely
on
source-based
trees.
This
means
that
an
RP
is
not
required.
The
ability
for
SSM
to
explicitly
include
and
exclude
particular
sources
allows
for
a
limited
amount
of
security.
Traffic
from
a
source
to
a
group
that
is
not
explicitly
listed
on
the
include
list
will
not
be
forwarded
to
uninterested
receivers.
SSM
also
solves
IP
multicast
address
collision
issues
associated
with
one-to-many
type
applications.
Routers
running
in
SSM
mode
will
route
data
streams
based
on
the
full
(S,
G)
address.
Assuming
that
a
source
has
a
unique
IP
address
to
send
on
the
internet,
any
(S,
G)
from
this
source
also
would
be
unique.
We
will
apply
SSM
in
our
environment
on
R1
as
an
example:
R1#conf t
Enter configuration commands, one per line.
13-13
R1(config)#interface FastEthernet0/0
R1(config-if)#ip pim sparse-mode
R1(config-if)#interface FastEthernet0/1
R1(config-if)#ip pim sparse-mode
R1(config-if)#exit
R1(config)#ip pim ssm default
R1(config)#end
This
command
application
tells
the
router
that
multicast
groups
in
the
range
of
232.0.0.0/8
will
be
multicast
routed
using
source
specific
multicast.
Next
on
the
client
it
is
necessary
to
employ
an
IGMP
protocol
that
supports
SSM.
In
the
case
of
R8
we
will
have
its
FastEthernet0/0
interface
join
the
multicast
group
232.9.9.9
specifically
from
the
source
located
at
172.16.100.5
only:
R8#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R8(config)#ip pim ssm default
R8(config)#interface FastEthernet0/0
R8(config-if)#ip igmp join-group 232.9.9.9 source 172.16.100.5
R8(config-if)#ip igmp version 3
R8(config-if)#end
This
means
that
R8
will
accept
the
multicast
stream
for
the
group
232.9.9.9
from
the
source
172.16.100.5
and
no
other
source.
13-14
Trouble
Ticket
#1
Your
supervisor
has
brought
to
your
attention
that
R8
is
not
receiving
any
multicast
traffic
sent
from
R5
to
the
multicast
address
224.9.9.9.
Correct
this
issue.
Trouble
Ticket
#2
After
solving
Trouble
Ticket
#1,
your
supervisor
has
observed
that
multicast
traffic
being
sent
to
the
group
224.99.99.99
is
not
being
received
by
R9.
Correct
this
issue.
13-15
13-16
Mtrace
output
seem
to
indicate
that
there
is
no
RPF
fault.
This
means
the
next
most
logical
step
will
be
to
look
at
the
multicast
routing
tables
of
the
devices
in
the
network
between
the
source
and
the
destination
devices:
R1#show ip mroute 224.9.9.9
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.9.9.9), 00:07:09/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/1, Forward/Dense, 00:07:09/00:00:00
FastEthernet0/0, Forward/Dense, 00:07:09/00:00:00
(172.16.100.5, 224.9.9.9), 00:07:09/00:02:50, flags: T
Incoming interface: FastEthernet0/0, RPF nbr 172.16.100.5
Outgoing interface list:
FastEthernet0/1, Forward/Dense, 00:07:10/00:00:00
We
see
the
S,G
pair
in
the
multicast
routing
table
of
R1,
what
about
R7?
R7#show ip mroute 224.9.9.9
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.9.9.9), 00:09:06/stopped, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
13-17
We
see
the
S,G
pair
but
we
also
observe
that
the
pair
is
being
limited
to
0
kbps.
This
isolates
the
fault.
Step
3
-
Fault
Remediation:
In
this
scenario,
the
ip
multicast
rate-limit
command
needs
to
be
removed
from
R7s
FastEthernet0/0
interface:
R7#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R7(config)#interface FastEthernet0/0
R7(config-if)#no ip multicast rate-limit out group-list 1 source-list 2 0
R7(config-if)#end
to
to
to
to
to
to
to
to
to
to
request
request
request
request
request
request
request
request
request
request
0
1
2
3
4
5
6
7
8
9
from
from
from
from
from
from
from
from
from
from
172.16.200.8,
172.16.200.8,
172.16.200.8,
172.16.200.8,
172.16.200.8,
172.16.200.8,
172.16.200.8,
172.16.200.8,
172.16.200.8,
172.16.200.8,
1
1
1
1
1
1
1
1
1
1
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
Pings to the group are now successful thus telling us that we have remediated the problem.
13-18
Mtrace
output
seem
to
indicate
that
there
is
no
RPF
fault.
This
means
the
next
most
logical
step
will
be
to
look
at
the
multicast
routing
tables
of
the
devices
in
the
network
between
the
source
and
the
destination
devices:
R1#show ip mroute 224.99.99.99
13-19
We
see
the
S,G
pair
in
the
multicast
routing
table
of
R1,
what
about
R7?
R7#show ip mroute 224.99.99.99
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,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.99.99.99), 00:03:50/stopped, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/1, Forward/Dense, 00:03:50/00:00:00
FastEthernet0/0, Forward/Dense, 00:03:50/00:00:00
(172.16.100.5, 224.99.99.99), 00:03:00/00:02:50, flags: T
Incoming interface: FastEthernet0/1, RPF nbr 172.16.17.1
Outgoing interface list:
FastEthernet0/0, Forward/Dense, 00:03:01/00:00:00
13-20
We
see
the
S,G
pair
but
what
about
the
table
on
R9?
R9#show ip mroute 224.99.99.99
Group 224.99.99.99 not found
The
output
says
that
R9
does
not
have
any
record
of
the
group.
Not
long
after
executing
the
show
command
the
console
reports
the
message:
R9#
%MROUTE-4-ROUTELIMIT: Current count of 2 exceeds multicast route-limit of 1 -Process=
"<interrupt level>", ipl= 1
This
output
tells
us
that
we
have
a
route-limit
parameter
configured
on
R9
as
evidenced
by
the
output
of
show
run:
R9#show run | inc route-limit
ip multicast route-limit 1
13-21
Reply
Reply
Reply
Reply
Reply
Reply
Reply
to
to
to
to
to
to
to
request
request
request
request
request
request
request
3
4
5
6
7
8
9
from
from
from
from
from
from
from
172.16.200.9,
172.16.200.9,
172.16.200.9,
172.16.200.9,
172.16.200.9,
172.16.200.9,
172.16.200.9,
1
1
1
1
1
1
1
ms
ms
ms
ms
ms
ms
ms
Pings to the group are now successful thus telling us that we have remediated the problem.
13-22
14-1
0
-
reserved
1
-
Interface-Local
scope
2
-
Link-Local
scope
3
-
reserved
4
-
Admin-Local
scope
5
-
Site-Local
scope
6
-
(unassigned)
7
-
(unassigned)
8
-
Organization-Local
scope
9
-
(unassigned)
A
-
(unassigned)
B
-
(unassigned)
C
-
(unassigned)
D
-
(unassigned)
E
-
Global
scope
F
-
reserved
14-2
The
remaining
112
bits
of
the
address
make
up
the
multicast
Group
ID.
An
example
of
an
IPv6
multicast
address
would
be
all
of
the
NTP
servers
on
the
Internet
FF0E:0:0:0:0:0:0:101.
Keep
in
mind
that
just
like
in
IPv4
multicast,
there
are
many
reserved
addresses
of
link-local
scope.
Here
are
some
examples:
A
special,
reserved
IPv6
multicast
address
that
is
very
important
is
the
Solicited-Node
multicast
address:
FF02:0:0:0:0:1:FFXX:XXXX
A
Solicited-Node
multicast
address
is
created
automatically
by
the
router.
The
router
takes
the
low-
order
24
bits
of
the
IPv6
address
(unicast
or
anycast)
and
appends
those
bits
to
the
prefix
FF02:0:0:0:0:1:FF00::/104.
This
results
in
a
multicast
address
within
the
range
FF02:0:0:0:0:1:FF00:0000
to
FF02:0:0:0:0:1:FFFF:FFFF.
These
addresses
are
used
by
the
IPv6
Neighbor
Discovery
(ND)
protocol
in
order
to
provide
a
much
more
efficient
address
resolution
protocol
than
Address
Resolution
Protocol
(ARP)
of
IPv4.
Protocol
Independent
Multicast
Version
2
(PIMv2)
for
IPv6
In
Chapter
4:
Protocol
Independent
Multicast
-
Sparse
Mode
(PIM-SM)
you
learned
the
detailed
operation
of
PIM-SM.
It
is
important
that
you
review
that
chapter
now.
Protocol
Independent
Multicast
version
2
for
IPv6
features
a
single
mode
of
operation
sparse
mode.
Just
like
the
version
4
PIM-SM,
PIMv2
for
IPv6
utilizes
concepts
such
as
Designated
Routers,
Assert
Messages,
and
Rendezvous
Points.
Reverse
Path
Forwarding
(RPF)
checks
are
performed
against
the
underlying
IPv6
routing
database.
Again,
be
sure
to
review
Chapter
4
should
any
of
these
important
concepts
need
a
review.
Multicast
Listener
Discovery
(MLD)
Protocol
IPv6
multicast
renames
IGMP
(detailed
in
Chapter
2:
Internet
Group
Management
Protocol
(IGMP))
to
the
Multicast
Listener
Discovery
Protocol
(MLD).
Version
1
of
MLD
is
similar
to
IGMP
Version
2,
while
Version
2
of
MLD
is
similar
to
Version
3
IGMP.
As
such,
MLD
Version
2
supports
Source
Specific
Multicast
(SSM)
for
IPv6
environments.
Using
the
Multicast
Listener
Discovery
Protocol,
hosts
can
indicate
they
want
to
receive
multicast
transmissions
for
select
groups.
Routers
(queriers)
can
control
the
flow
of
multicast
in
the
network
through
the
use
of
MLD.
14-3
MLD
uses
Internet
Control
Message
Protocol
(ICMP)
to
carry
its
messages.
All
such
messages
are
link-
local
in
scope,
and
they
all
have
the
router
alert
option
set.
MLD
uses
three
types
of
messages
Query,
Report,
and
Done.
The
Done
message
is
like
the
Leave
message
in
IGMP
version
2.
It
indicates
a
host
no
longer
wants
to
receive
the
multicast
transmission.
This
triggers
a
Query
to
check
for
any
more
receivers
on
the
segment.
IPv6
PIM
Bootstrap
Router
Protocol
(BSR)
Options
for
Rendezvous
Point
(RP)
assignment
in
IPv6
multicast
are:
Static
BSR
Embedded
RP
14-4
Gig0/0
Gig0/1
64
:2
01
R1
Fa0/0
Fa0/0
2001:1515::/64
R5
Fa0/1
Fa0/1
2001:4545::/64
R4
01
:2
20
Fa0/0
64
/
6::
42
62
4::
/
20
R2
S0/0/0.1
S0/1/0.1
Fa0/1
R6
Fa0/0
Fa0/0
2001:6767::/64
R7
Fa0/1
Fa0/1
2001:7979::/64
R9
Receiver
Source
406
.
.
.
.
.
.
.
.
.604
.
.
.
.
2001:4646::/6
4
14-5
Notice
that
because
IPv6
routing
capabilities
are
enabled
for
this
device,
one
of
the
multicast
groups
joined
is
ALL
ROUTERS
for
the
local-link
(FF02::2).
Protocol
Independent
Multicast
Version
2
(PIMv2)
for
IPv6
Typing
the
following
command
on
the
Cisco
router
automatically
enables
IPv6
PIM
version
2
on
all
IPv6
enabled
interfaces:
ipv6
multicast-routing
Should
you
need
to
disable
this
functionality
on
a
particular
interface,
simplt
type
no
ipv6
pim
under
that
interface
as
shown
below:
R1(config)#ipv6 multicast-routing
R1(config)#exit
R1#
R1#show ipv6 pim interface
Interface
PIM Nbr
Hello
Count Intvl
DR
Prior
Loopback0
on
0
30
1
Address: FE80::20A:B8FF:FE1A:5030
DR
: this system
Null0
off 0
30
1
Address: FE80::1
DR
: not elected
VoIP-Null0
off 0
30
1
Address: ::
DR
: not elected
FastEthernet0/0
on
1
30
1
Address: FE80::20A:B8FF:FE1A:5030
DR
: FE80::20A:B8FF:FE2C:80E0
FastEthernet0/1
off 0
30
1
Address: ::
14-6
DR
:
Loopback10
Address:
DR
:
Tunnel0
Address:
DR
:
not elected
on
0
30
1
FE80::20A:B8FF:FE1A:5030
this system
off 0
30
1
FE80::20A:B8FF:FE1A:5030
not elected
R1#conf t
R1(config)#interface lo10
R1(config-if)#no ipv6 pim
R1(config-if)#end
R1#show ipv6 pim interface
Interface
PIM Nbr
Hello
Count Intvl
DR
Prior
Loopback0
on
0
30
1
Address: FE80::20A:B8FF:FE1A:5030
DR
: this system
Null0
off 0
30
1
Address: FE80::1
DR
: not elected
VoIP-Null0
off 0
30
1
Address: ::
DR
: not elected
FastEthernet0/0
on
1
30
1
Address: FE80::20A:B8FF:FE1A:5030
DR
: FE80::20A:B8FF:FE2C:80E0
FastEthernet0/1
off 0
30
1
Address: ::
DR
: not elected
Loopback10
off 0
30
1
Address: FE80::20A:B8FF:FE1A:5030
DR
: not elected
Tunnel0
off 0
30
1
Address: FE80::20A:B8FF:FE1A:5030
DR
: not elected
R1#
Static
assigmnet
of
the
RP
for
the
topology
is
simple.
Use
the
following
command:
ipv6
pim
rp-address
ip_address
A
significant
difference
between
PIM
for
IP
version
4
and
PIM
for
IP
version
6
involves
the
source
registration
process.
Immediately
upon
learning
the
RP,
an
IPv6
multicast
Cisco
router
constructs
a
14-7
tunnel
interface
leading
to
the
RP.
The
tunnel
is
also
immediately
enabled
for
IPv6
multicast.
This
tunnel
is
used
for
the
duration
of
the
registration
process.
After
the
completion
of
registration,
multicast
receivers
switch
to
the
most
optimal
path,
which
negates
the
use
of
the
tunnel.
Examine
the
automatic
creation
of
the
tunnel
below:
R1(config)#ipv6 pim rp-address 2001:2222::2
R1(config)#
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up
R1(config)#end
R1#
In
order
to
examine
a
list
of
currently
active
tunnels,
Cisco
provides
the
command
show
ipv6
pim
tunnel.
R1#show ipv6 pim tunnel
Tunnel0*
Type : PIM Encap
RP
: Embedded RP Tunnel
Source: 2001:1111::1
Tunnel1*
Type : PIM Encap
RP
: 2001:2222::2
Source: 2001:1111::1
R1#
Uptime
00:00:18
Expires
never
14-8
R9(config-if)#
Various
MLD-related
query
paramets
may
be
set
as
well
on
the
Cisco
router,
once
again,
following
IGMP
logic.
The
following
commands
are
used:
You
may
also
use
an
IPv6
access
control
list
in
order
to
control
groups
joined
by
a
host.
In
order
to
apply
the
ACL
to
the
MLD
configuration,
use
the
command:
ipv6
mld
access-group
acl_name
IPv6
PIM
Bootstrap
Router
Protocol
(BSR)
As
was
pointed
out
earlier
in
this
chapter,
BSR
is
functionally
very
similar
to
its
IPv4
counterpart
as
covered
in
Chapter
6:
Bidirectional
Protocol
Independent
Multicast
(BIDIR-PIM).
The
command
required
for
the
candidate
rendezvous
point
(C-RP)
configuration
is:
ipv6
pim
bsr
candidate
rp
ipv6_address
The
command
to
configure
the
bootstrap
router
itself
is:
ipv6
pim
bsr
candidate
bsr
ipv6_address
An
interesting
enhancement
to
the
IPv6
version
of
BSR
is
the
fact
that
you
may
statically
configure
the
bootstrap
router
itself
with
a
list
of
candidate
RPs
(C-RPs)
using
the
command:
ipv6
pim
bsr
announced
rp
ipv6_address
Remarkably,
this
altogether
eliminates
the
need
for
the
dynamic
candidate
RP
announcements
from
other
devices
in
the
topology.
IPv6
Embedded
RP
As
described
earlier,
following
the
initial
8
bits
of
an
IPv6
multicast
address,
there
are
4
bits
(labeled
0RPT)
which
are
flag
fields.
The
high-order
flag
is
reserved,
and
must
be
initialized
to
0.
If
the
R
bit
is
set
to
1,
then
the
P
and
T
bits
must
also
be
set
to
1.
This
indicates
there
is
an
embedded
Rendezvous
Point
(RP)
address
in
the
multicast
address.
Cisco
routers
will
now
no
longer
rely
on
BSR
or
static
configurations
for
the
RP
assignment,
and
now
senders
and
receivers
in
IPv6
multicast
will
agree
to
embed
the
RP
IPv6
address
in
the
IPv6
multicast
address
itself.
14-9