From: Andrew Bruce Caslow (abcaslow@netmasterclass.net)
Date: Fri Nov 17 2006 - 02:38:04 ART
Hi Michael,
When attempting to learn the basics of multicasting and the concept of RPF
lookups in particular, consider using the following debugging technique.
NOTE: DO NOT USE THIS TECHNIQUE ON PRODUCTION ROUTERS!!! Use this technique
only in a testing environment:
On the interfaces that are receiving multicast traffic, enter the following
interface configuration command:
R3(config-if)#no ip mroute-cache
On this same router, enter the following debug utility: "debug ip mpacket".
Once you enter in these two commands, you can observe healthy output that
reflects the proper operational state:
*Mar 1 02:39:35.895: IP(0): s=144.44.124.129 (Serial0/0) d=234.4.4.4
(Serial0/1) id=619, prot=1, len=100(100), mforward
You can also observe the following unhealthy output that reflects a
malfunctioning operational state:
*Mar 1 02:34:51.855: IP(0): s=144.44.124.129 (Serial0/0) d=234.4.4.4
id=477, prot=1, len=104(100), not RPF interface
Notice the last line "not RPF interface". This represents an RPF lookup
failure.
This output can be generated by initiating a multicast ping with a high
repeat value. I used:
R1#ping 234.4.4.4 rep 10000
This problem can be solved with an "ip mroute" global configuration
statement:
R3(config)#ip mroute 144.44.124.129 255.255.255.255 144.44.43.4
By adding and removing this "mroute" command, I can predictably generate a
shifting between the following two debug outputs when the configuration
above is implemented:
*Mar 1 02:39:35.895: IP(0): s=144.44.124.129 (Serial0/0) d=234.4.4.4
(Serial0/1) id=619, prot=1, len=100(100), mforward
*Mar 1 02:34:51.855: IP(0): s=144.44.124.129 (Serial0/0) d=234.4.4.4
id=477, prot=1, len=104(100), not RPF interface
These are some useful learning tips to be aware of when attempting to learn
how Multicast operates.
HTH,
-Bruce Caslow CCIE #3139
NetMasterClass LLC
A Cisco Learning Partner
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Jian Gu
> Sent: Thursday, November 16, 2006 9:41 PM
> To: Michael Zuo
> Cc: ccielab@groupstudy.com
> Subject: Re: mroute needed for dense mode?
>
> 1) router will do RPF check for each multicast packet, irrelavent whether
> it
> is PIM sparse or dense.
> 2) you have "ip igmp join-group" configured, which will make the router
> behave like a host, once a multicast packet is received it will be
> consumed
> by CPU.
>
> On 11/16/06, Michael Zuo <mzuo@ixiacom.com> wrote:
> >
> > Hi Group,
> >
> >
> >
> > I have a couple of possible stupid questions: if I have:
> >
> >
> >
> > R1--------------------------------------------------------R2
> >
> >
> >
> > e0/1 e0/0 150.1.12.x/24 e0/0 e0/1
> >
> >
> >
> >
> >
> >
> >
> > R1:
> >
> >
> >
> > interface Tunnel0
> >
> > ip address 10.0.0.1 255.0.0.0
> >
> > ip pim dense-mode
> >
> > tunnel source Ethernet0/0
> >
> > tunnel destination 150.1.12.2
> >
> > !
> >
> > interface Ethernet0/0
> >
> > ip address 150.1.12.1 255.255.255.0
> >
> > !
> >
> > interface Ethernet0/1
> >
> > ip address 150.1.14.1 255.255.255.0
> >
> > ip pim dense-mode
> >
> > ip igmp join-group 239.1.1.1
> >
> >
> >
> >
> >
> > R2:
> >
> >
> >
> > interface Tunnel0
> >
> > ip address 10.0.0.2 255.0.0.0
> >
> > ip pim dense-mode
> >
> > tunnel source Ethernet0/0
> >
> > tunnel destination 150.1.12.1
> >
> > !
> >
> > interface Ethernet0/0
> >
> > ip address 150.1.12.2 255.255.255.0
> >
> > !
> >
> > interface Ethernet0/1
> >
> > ip address 150.1.23.2 255.255.255.0
> >
> > ip pim dense-mode
> >
> >
> >
> >
> >
> > Rack1R2(config-if)#do ping 239.1.1.1 source e0/1
> >
> >
> >
> > Type escape sequence to abort.
> >
> > Sending 1, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:
> >
> > Packet sent with a source address of 150.1.23.2
> >
> >
> >
> > Reply to request 0 from 10.0.0.1, 108 ms
> >
> >
> >
> > My questions are:
> >
> > 1. for R1's e0/1 to talk to R2's e0/1 via multicast dense mode, do I
> > need "ip mroute 0.0.0.0 0.0.0.0 tunnel 0" configured on both routers?
> > (ie, does dense mode do RPF checks. In my mind, it should not because
> > the router should just forward dense mode packets to all the interfaces
> > that it did not come in on)
> >
> > 2. how come 10.0.0.1 is responding but not e0/1 on R1?
> >
> >
> >
> >
> >
> > Thanks for your help...
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Fri Dec 01 2006 - 08:05:47 ART