From: Ravi Singh (way2ccie@googlemail.com)
Date: Thu Mar 19 2009 - 11:37:38 ART
Here's the output of the sh ip mroute on all the routers
R1#sh 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), 01:18:46/00:02:22, RP 5.5.5.5, flags: SJPL
Incoming interface: FastEthernet0/0, RPF nbr 10.1.13.3
Outgoing interface list: Null
R3#sh 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), 01:19:08/00:02:58, RP 5.5.5.5, flags: SJCL
Incoming interface: FastEthernet1/0, RPF nbr 10.1.35.5
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 01:19:08/00:02:58
R3#
R5#sh 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.1.1.1), 01:17:33/00:02:29, RP 5.5.5.5, flags: SJCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 01:17:33/00:02:29
(*, 224.0.1.40), 01:17:33/00:02:33, RP 5.5.5.5, flags: SJCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet1/0, Forward/Sparse, 01:16:38/00:02:36
FastEthernet0/0, Forward/Sparse, 01:17:33/00:02:33
R5#
AFTER THE PING FROM R1 to 224.1.1.1
R1 stays the same as above
R3#sh 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.1.1.1), 00:00:13/00:02:46, RP 5.5.5.5, flags: SP
Incoming interface: FastEthernet1/0, RPF nbr 10.1.35.5
Outgoing interface list: Null
(*, 224.0.1.40), 01:20:38/00:02:32, RP 5.5.5.5, flags: SJCL
Incoming interface: FastEthernet1/0, RPF nbr 10.1.35.5
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 01:20:38/00:02:32
R3#
R5#sh 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.1.1.1), 01:22:13/00:02:52, RP 5.5.5.5, flags: SJCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 01:22:13/00:02:52
(*, 224.0.1.40), 01:22:13/00:02:49, RP 5.5.5.5, flags: SJCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet1/0, Forward/Sparse, 01:21:18/00:02:51
FastEthernet0/0, Forward/Sparse, 01:22:13/00:02:49
R5#
Mukom, I am sure you have understood the problem but just to reiterate
it in different words . If I don't enable ip pim sparse on Loopback 0
of R1 , it should simply not forward out multicast traffic on that
interface. I don't want it to. All I want is F0/0 should forward
traffic out and receive it and I am not concerned with Loopback0.
Another interesting thing to note is if I remove the interface
loopback0 , everything works fine and traffic goes out using R1 f0/0.
So basically,
1) if Loo0 is there, it does not work. If it is not there it works.
2) If I ping using the source address or interface of F0/0 it works,
otherwise it doesn't.
3) If I enable ip pim sparse on Loo0, it works. Otherwise it doesn't
Ravi
On Thu, Mar 19, 2009 at 2:17 PM, Mukom TAMON <mukom.tamon@gmail.com> wrote:
> I would look at it from the perspective of the "not RPF interface" message.
> Could we see the results of show ip mroute? I THINK that without the ip pim
> sparse-m on the loopback interface, that interface isn't going to take part
> in multicasting.
> M.A. TAMON
> B.Eng, CCNP, CCNA
> _________________________
> "A man owns nothing, not land or money, only his character, the loyalty &
> courage in his heart" - Commander Chakotay - StarTrek Voyager
> My BLOGs:
> [ICT Business Integration] - http://ibiztech.wordpress.com
> [Leadership Lessons from Movies] - http://thbs.wordpress.com
> [In Search of Excellence & Perfection] - http://perfexcellence.wordpress.com
> [Technical How-Tos & Stuff-at-a-Glance] - http://techowto.wordpress.com
>
>
>
> On Thu, Mar 19, 2009 at 2:09 PM, Ravi Singh <way2ccie@googlemail.com> wrote:
>>
>> Thanks a lot for the response Pavel.
>> Well actually , I have the group joined at the F0/0 interface of R5
>> and not R1. The word wrap ruined the diagram. Sorry about that. Here's
>> it again ( hope the word wrap doesn't spoil it again)
>>
>> 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)
>>
>> I have ip sparse-m on all the routers including the loop0 of R5. I
>> don't have it though on loo0 of R1 and R3. Putting it on R1's loop)
>> makes the setup work as mentioned in my previous email but why do you
>> have to put a sparse mode on it, is my concern. I am using 12.4(23)
>> but I have also tested it on 12.3 and its the same so I think it has
>> got to do something with my configuration. Below are the relevant
>> configs on the three routers if they could help
>>
>> hostname R1
>> interface Loopback0
>> ip address 1.1.1.1 255.0.0.0
>> !
>> interface FastEthernet0/0
>> ip address 10.1.13.1 255.255.255.0
>> ip pim sparse-mode
>> duplex auto
>> speed auto
>> !
>> router ospf 10
>> log-adjacency-changes
>> network 0.0.0.0 255.255.255.255 area 0
>> !
>> ip pim rp-address 5.5.5.5 override
>>
>>
>>
>> hostname R3
>> interface Loopback0
>> ip address 3.3.3.3 255.0.0.0
>> !
>> interface FastEthernet0/0
>> ip address 10.1.13.3 255.255.255.0
>> ip pim sparse-mode
>> duplex auto
>> speed auto
>> !
>> interface FastEthernet1/0
>> ip address 10.1.35.3 255.255.255.0
>> ip pim sparse-mode
>> duplex auto
>> speed auto
>> !
>> router ospf 10
>> log-adjacency-changes
>> network 0.0.0.0 255.255.255.255 area 0
>> !
>> ip pim rp-address 5.5.5.5 override
>>
>>
>> hostname R5
>> !
>> interface Loopback0
>> ip address 5.5.5.5 255.0.0.0
>> ip pim sparse-mode
>> !
>> interface FastEthernet0/0
>> ip address 10.1.55.5 255.255.255.0
>> ip pim sparse-mode
>> ip igmp join-group 224.1.1.1
>> duplex auto
>> speed auto
>> !
>> interface FastEthernet1/0
>> ip address 10.1.35.5 255.255.255.0
>> ip pim sparse-mode
>> duplex auto
>> speed auto
>> !
>> router ospf 10
>> log-adjacency-changes
>> network 0.0.0.0 255.255.255.255 area 0
>> !
>> !
>> ip pim rp-address 5.5.5.5 override
>> !
>>
>> I have "debug ip mpacket detail" "debug ip pim" and "debug ip packe
>> deta" and this is the ping output with the source interface and
>> without it on R1
>>
>> R1#ping 224.1.1.1 source f0/0
>>
>> Type escape sequence to abort.
>> Sending 1, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
>> Packet sent with a source address of 10.1.13.1
>>
>> IP: s=10.1.13.1 (local), d=224.1.1.1 (FastEthernet0/0), len 100,
>> sending broad/multicast
>> ICMP type=8, code=0
>> IP: s=10.1.13.1 (local), d=224.1.1.1 (Loopback0), len 100, sending
>> broad/multicast
>> ICMP type=8, code=0
>> IP: s=10.1.13.1 (Loopback0), d=224.1.1.1, len 100, unroutable
>> ICMP type=8, code=0
>> IP: tableid=0, s=10.1.35.5 (FastEthernet0/0), d=10.1.13.1
>> (FastEthernet0/0), routed via RIB
>> IP: s=10.1.35.5 (FastEthernet0/0), d=10.1.13.1 (FastEthernet0/0), len
>> 100, rcvd 3
>> ICMP type=0, code=0
>> Reply to request 0 from 10.1.35.5, 128 ms
>> R1#
>> R1#
>>
>> without the source interface
>>
>> 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
>>
>> And this is the output on R3 when R1 intiates a ping without any
>> source interface or IP .
>>
>> R3#
>> *Mar 1 20:52:11.934: PIM(0): Check RP 5.5.5.5 into the (*, 224.1.1.1)
>> entry
>> *Mar 1 20:52:11.942: IP(0): MAC sa=cc00.0e70.0000 (FastEthernet0/0),
>> IP last-hop=10.1.13.1
>> *Mar 1 20:52:11.942: IP(0): IP tos=0x0, len=100, id=15, ttl=254, prot=1
>> *Mar 1 20:52:11.946: IP(0): s=1.1.1.1 (FastEthernet0/0) d=224.1.1.1
>> id=15, ttl=254, prot=1, len=114(100), not RPF interface
>> R3#
>>
>> Any ideas ??
>>
>> Thanks,
>> Ravi
>>
>> On Thu, Mar 19, 2009 at 12:06 PM, Pavel Bykov <slidersv@gmail.com> wrote:
>> > 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
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
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