From: Pavel Bykov (slidersv@gmail.com)
Date: Thu Mar 19 2009 - 09:06:18 ART
You need to enable PIM-SM on all interfaces that are participating in MCAST,
that is including RP interface, which I assume you did. Just to check: so
you have "ip pim rp-add 5.5.5.5 over"on all routers and you have "ip pim
sparse-m" on lo0 of R5.
If you join a group on an interface of R1, which directs all packets for
that group to the CPU, the standard testing is originating packets from
other routers (R3/R5 in your case). Otherwise, you are originating packets
on the CPU that are destined to the CPU, some sort of a loop.
Third, normally router originates multicast packets from every multicast
enabled interface, that is at least before (and including) 12.4.15T, not
sure about behaviour in newer 12.4.20T+.
On Thu, Mar 19, 2009 at 7:22 AM, Ravi Singh <way2ccie@googlemail.com> wrote:
> Hi Group,
>
> I don't know what am I missing here but this thing is really making me
> crazy. I am configuring PIM sparse mode on 3 routers connected
> linearly i.e
>
>
> R1(F0/0) <-------> (F0/0) R3 (F1/0) <-------> (F1/0) R5
> (F0/0)---->joined 224.1.1.1
> | | | |
> (10.1.13.1) (10.1.13.3) (10.1.35.3) (10.1.35.5)
>
> All the routers have loopback0 addresses configured on them as
> 1.1.1.1/8 , 3.3.3.3/8 and 5.5.5.5/8 . R5 is the RP . RP address is
> configured as 5.5.5.5 in all the three routers statically.OSPF runs in
> all the three routers on all the interfaces with them being in area 0.
> I have done all the required config i.e enabled sparse-mode on the
> interfaces , defined the static rp-address but when I ping the
> multicast 224.1.1.1 from R1 , it times out. A debug shows me that the
> ping is being sourced from loopback 0 of R1 (1.1.1.1) and R1 says it
> as unroutable. I don't get anything if I debug ip pim or debug ip
> mpacket detail. The only output I get is when I debug ip packet detail
> which is this
>
> R1#ping 224.1.1.1
>
> Type escape sequence to abort.
> Sending 1, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
>
> IP: s=1.1.1.1 (local), d=224.1.1.1 (FastEthernet0/0), len 100, sending
> broad/multicast
> ICMP type=8, code=0
> IP: s=1.1.1.1 (local), d=224.1.1.1 (Loopback0), len 100, sending
> broad/multicast
> ICMP type=8, code=0
> IP: s=1.1.1.1 (Loopback0), d=224.1.1.1, len 100, unroutable
> ICMP type=8, code=0.
>
>
> Also, here is the debug ip mpacket detail output on R3, if it helps. I
> don't know why it fails an RPF check when the routing looks ok to me.
>
> R3#
> PIM(0): Check RP 5.5.5.5 into the (*, 224.1.1.1) entry
> IP(0): MAC sa=cc00.0928.0000 (FastEthernet0/0), IP last-hop=10.1.13.1
> IP(0): IP tos=0x0, len=100, id=32, ttl=254, prot=1
> IP(0): s=1.1.1.1 (FastEthernet0/0) d=224.1.1.1 id=32, ttl=254, prot=1,
> len=114(100), not RPF interface
> R3#
>
> Now, If I change the source interface or IP address in the ping
> command to F0/0 , everything works. If I enable sparse-mode on
> Loopback 0, everything works again.Why is R1 sourcing the packet from
> Loopback 0 ? Is this expected behaviour ? Has anyone else encountered
> this before, or is it just sheer stupidity that I am enjoying here ? I
> am using dynamips by the way and and it's the same problem, in three
> different machines where I run Dynamips.
>
> Can anyone help me get out of this please .
>
> TIA
> Ravi
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>
-- Pavel Bykov ---------------- Don't forget to help stopping the braindumps, use of which reduces value of your certifications. Sign the petition at http://www.stopbraindumps.com/Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Mon Apr 06 2009 - 06:44:06 ART