From: George Cassels (glcassels3@nc.rr.com)
Date: Tue Jun 07 2005 - 20:58:44 GMT-3
Brian,
Couldn't you also you the mtrace command? I find it useful in real
world multicast troubleshooting. It basically will inform you of any
interface that is not pim enabled and will show you the path destination
to the source of the multicast. The thing to remember though is it uses
the ip address of the source not the multicast group.
Just something else to help in the multicast arena,
George
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Brian McGahan
Sent: Tuesday, June 07, 2005 1:24 PM
To: John Matus; ccielab@groupstudy.com
Subject: RE: extended ping question
John,
The source of the packet *does* matter, as this is the address
that the RPF check is performed on. Your method of choosing the source
address and outgoing interface are correct. Alternatively you could put
an SVI in that VLAN on one of the 3550s to simulate the source. Issue
the "no ip mroute-cache" command on all the transit interfaces then look
at the output of the "debug ip mpacket" command. This will tell you
where the packet is getting discarded and why.
HTH,
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
24/7 Support: http://forum.internetworkexpert.com
Live Chat: http://www.internetworkexpert.com/chat/
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> ccie2be
> Sent: Tuesday, June 07, 2005 12:38 PM
> To: 'John Matus'; ccielab@groupstudy.com
> Subject: RE: extended ping question
>
> Hey John,
>
> It looks OK but I think I would do this a bit differently.
>
> First, I'd check the sho ip mroute on R1 and R2 to make sure they see
each
> other as pim nei.
>
> Assuming they do, then the source addr of the ping doesn't much
matter.
> but, you want to have the ping continue for a long time - say 500
times or
> more.
>
> Then check your mroute tables again and make sure the incoming and
> outgoing
> int's are what you expect them on both R1 and R2.
>
> You can also do a show ip mroute count to see if there's an rpf
failure
> issue.
>
> HTH, Tim
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> John
> Matus
> Sent: Tuesday, June 07, 2005 1:30 PM
> To: ccielab@groupstudy.com
> Subject: extended ping question
>
> ok, i've been having a problem going pings from arbitrary
> interfaces...basically for multicast. i need help with how to do this
> properly. let's say i have a multicast server on a subnet and i want
to
> see
>
> if i can get responds from a router on another subnet, how would i go
> about
> doing the extended ping?
>
> Server-----------e0/0--R1--S0/0-----------------------------s0/0--R2
> --e0/0---"igmp join-group 225.1.1.1
> 1.1.1.5 1.1.1.1 2.1.1.1 2.1.1.2
> 3.1.1.1
>
> i want to ping from the server, or i guess in practicality, from R1
int
> e0/0, to multicast address 225.1.1.1.
>
> r1#ping
> Protocol [ip]:
> Target IP address: 225.1.1.1
> Repeat count [1]:
> Datagram size [100]:
> Timeout in seconds [2]:
> Extended commands [n]: y
> Interface [All]: serial0
> Time to live [255]:
> Source address: 1.1.1.1
> Type of service [0]:
> Set DF bit in IP header? [no]:
> Validate reply data? [no]:
> Data pattern [0xABCD]:
> Loose, Strict, Record, Timestamp, Verbose[none]:
> Sweep range of sizes [n]:
> Type escape sequence to abort.
> Sending 1, 100-byte ICMP Echos to 225.1.1.1, timeout is 2 seconds:
> Packet sent with a source address of 1.1.1.1
> ...
>
>
> is this the correct way to source the ping packets from the subnet
that
> the
> server is on?
>
> _________________________________________________________________
> Express yourself instantly with MSN Messenger! Download today - it's
FREE!
> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
>
>
This archive was generated by hypermail 2.1.4 : Wed Jul 06 2005 - 14:43:41 GMT-3