From: Jeff Andiorio (jandiorio@gmail.com)
Date: Sat Mar 21 2009 - 00:50:01 ART
Ravi,
I labbed this up with both 12.4(21) and 12.4(15)T6 and the multicast
ping was handled differently in the two different versions.
In both scenarios I used the configurations that you had provided with
the exception of adding ip multicast-routing.
In 12.4(21) I turned on debug ip packet det and the ping from R1 to
224.1.1.1 showed the following :
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:
*Mar 1 00:04:20.051: IP: s=1.1.1.1 (local), d=224.1.1.1
(FastEthernet0/0), len 100, sending broad/multicast
*Mar 1 00:04:20.051: ICMP type=8, code=0
*Mar 1 00:04:20.051: IP: s=1.1.1.1 (local), d=224.1.1.1 (Loopback0),
len 100, sending broad/multicast
*Mar 1 00:04:20.051: ICMP type=8, code=0
*Mar 1 00:04:20.051: IP: s=1.1.1.1 (Loopback0), d=224.1.1.1, len 100,
unroutable
*Mar 1 00:04:20.051: ICMP type=8, code=0
*Mar 1 00:04:20.279: IP: s=10.1.13.3 (FastEthernet0/0), d=224.0.0.5,
len 80, rcvd 0, proto=89.
R1#
I then used the 12.4(15) version and had the following results from
the debug ip packet det:
IP packet debugging is on
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:
*Mar 1 00:06:26.639: IP: s=10.1.13.1 (local), d=224.1.1.1
(FastEthernet0/0), len 100, sending broad/multicast
*Mar 1 00:06:26.639: IP: s=1.1.1.1 (local), d=224.1.1.1 (Loopback0),
len 100, sending broad/multicast
*Mar 1 00:06:26.647: IP: s=1.1.1.1 (Loopback0), d=224.1.1.1, len 100,
unroutable
*Mar 1 00:06:26.723: IP: tableid=0, s=10.1.35.5 (FastEthernet0/0),
d=10.1.13.1 (FastEthernet0/0), routed via RIB
*Mar 1 00:06:26.723: IP: s=10.1.35.5 (FastEthernet0/0), d=10.1.13.1
(FastEthernet0/0), len 100, rcvd 3
What I find interesting is that in the 12.4(21) IOS the router does
attempt to send the packet out fa0/0, but selects a source address of
the loopback. The 12.4(15) debug shows that it attempts to send it
out fa0/0 interface and sets the source IP as that of the
interface(what I would expect).
Interesting issue, but I would say it is a problem with the version
IOS not your configuration.
Jeff
In 12.4(21) the debug ip packet detail showed that the packet was sourced from
On Fri, Mar 20, 2009 at 12:32 PM, Ravi Singh <way2ccie@googlemail.com> wrote:
> Hi Bryan,
>
> I do not have any other connections between the routers and I am using
> 12.4(23), but I have tested this on 12.3 as well and its the same
> problem.
> I am pasting my dynamips connections below and would appreciate if
> anyone in the group could try this and let me know if it is the same
> problem with him/her as well. The router configurations have already
> been given in one of my mails before.
>
> autostart = False
> [localhost:7200]
>
> workingdir = C:\Program Files\Dynamips\sample_labs\working\test
>
> [[3640]]
> image = C:\Program Files\Dynamips\images\c3640-ik9o3s-mz.124-23.bin
> ram = 96
> disk0 = 0
> disk1 = 0
> idlepc = 0x605f00fc
> ghostios = True
> sparsemem = True
>
> [[Router R1]]
> model = 3640
> console = 2001
> autostart = False
> F0/0 = R3 F0/0
>
>
> [[Router R3]]
> model = 3640
> console = 2003
> autostart = False
> slot1 = NM-1FE-TX
> F1/0 = R5 F1/0
>
> [[Router R5]]
> model = 3640
> console = 2005
> autostart = False
> slot1 = NM-1FE-TX
> F0/0 = SW1 F0/0
>
> [[Router SW1]]
> model = 3640
> console = 2007
> autostart = False
>
> Thanks in anticipation
>
> Ravi
>
>
> On Fri, Mar 20, 2009 at 3:28 PM, Bryan Bartik <bbartik@ipexpert.com> wrote:
>> Hi Ravi,
>>
>> That is interesting. Even when I try and specify loopback 0 (without PIM
>> enabled) as the source, packets are still sent with source address of the
>> Ethernet port. I do not have any problems pinging.
>>
>> Do you have any other connections between this routers that would cause RPF
>> check to fail?
>> What software are you running?
>>
>>
>> Bryan Bartik
>> CCIE #23707, CCNP
>> Sr. Support Engineer - IPexpert, Inc.
>> URL: http://www.IPexpert.com
>>
>> On Fri, Mar 20, 2009 at 4:15 AM, Ravi Singh <way2ccie@googlemail.com> wrote:
>>>
>>> Hi Mink,
>>>
>>> Could you elaborate on that please. I have not specified in my
>>> configuration that loo0 should be the source of multicast traffic for
>>> R1.I don't want it to be the source . Its just the mere presence of
>>> the loop0 interface thats making R1 take it as source. If I remove
>>> loo0 from R1 , the source interface becomes F0/0 and I don't specify
>>> this in the config.
>>> Hope you got what I am trying to say.
>>> Thanks
>>> Ravi
>>>
>>> On Fri, Mar 20, 2009 at 9:03 AM, Mink <maritpra@hotmail.com> wrote:
>>> > Hello Ravi,
>>> >
>>> > By the way you test, multicast source seem to connected to R1 loop0. I
>>> > dont
>>> > think R1 can forward the multicast packet if the source connected to
>>> > non-multicast enabled interface, in this case loopback 0. "show ip
>>> > mroute" on
>>> > R1 should be able to help you identify the problem, you will not see
>>> > anything
>>> > related to your multicast group that R5 joined if you haven't enable
>>> > multicast
>>> > on the interface that you pretend to be the souce of multicast traffic.
>>> >
>>> > Hope this will help.
>>> >
>>> >
>>> > 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
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>
>
> 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