From: Radioactive Frog (pbhatkoti@gmail.com)
Date: Sat Mar 21 2009 - 07:09:50 ART
Can someone test this on the real router?
Jeff - did you test them on a real router and not on dynamips?
Sometime dynamips sucks :(
-frog
On Sat, Mar 21, 2009 at 3:56 PM, Ravi Singh <way2ccie@googlemail.com> wrote:
> Hi Jeff,
>
> Although I don't see it in the logs, but just to confirm that this
> means its not working with 12.4(21) and working with 12.4(15). Bryan
> Bartik (in one of the emails above) had also tried this with 12.4(7)
> and it worked for him. I have tried this with 12.4(23) & 22T, so it
> looks like to me that newer IOS's are having this problem ( if at all
> it can be called a problem ). I will try this with either 12.4(7) or
> 12.4(15) and see what I get.
>
> Thank you Jeff for testing this for me. I Appreciate that !!
>
> Ravi
>
> On Sat, Mar 21, 2009 at 3:50 AM, Jeff Andiorio <jandiorio@gmail.com>
> wrote:
> > 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
>
> _______________________________________________________________________
> 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