[c-nsp] Multicast Issue
John Neiberger
John.Neiberger at efirstbank.com
Thu Apr 27 10:13:59 EDT 2006
It looks like the TTL is set to 2, which should be fine since there is
only one routed hop in the chain. I'm glad you mentioned it, though.
That's not typically something I would have thought to look at.
Thanks,
John
--
>>> Rodney Dunn <rodunn at cisco.com> 4/27/06 5:37:11 AM >>>
We had one very similar to this yesterday and the device
sending the mcast stream had the TTL set to 1.
Make sure that isn't the case.
Rodney
On Wed, Apr 26, 2006 at 05:09:13PM -0700, Tim Stevenson wrote:
> At 04:14 PM 4/26/2006, John Neiberger pronounced:
> >I think you're right that the problem is at L2. The 6513 is
connected
> >via trunk port to a 2950. I have IGMP snooping disabled on the 2950
and
> >another static MAC address entry pointing to the interface where
the
> >server is connected. It sure seems like it should work, darn it!
:)
> >
> >Regarding snooping on Vlan4, I didn't disable it globally but I did
> >disable for that MAC address using the disable-snooping keyword in
the
> >mac-address-table command.
>
> This would be on a per vlan basis though. Eg, if you did it in vlan 1
> & not in vlan 4, it would not apply to vlan 4.
>
> In any case, the tools to use now would be sh int cou on gig 4/16 to
> see if mcast out is incrementing on the 6k (hopefully it's a fairly
> high rate source, if not, then you won't be able to tell), and if
> mcast in is incrementing on the 2950.
>
> You can also always try a span session to a sniffer of gig 4/16 in
> the tx direction to see if the packets are going out.
>
> Tim
>
>
> >Thanks!
> >John
> >--
> >
> > >>> Tim Stevenson <tstevens at cisco.com> 4/26/06 5:05:11 PM >>>
> >I assume you never disabled snooping in vlan 4? Multicast router
> >ports (in this case the internal router, the RP/MSFC) are always
> >member ports for all snooping groups.
> >
> >This all looks ok.
> >
> >Can you do a sh mls ip multicast and see if the packet stats
increase
> >for this S,G - if they do (& I think they will/should), then the
> >packets are getting to vlan 1 & then you need to focus your
> >troubleshooting on L2 between vlan 1 & the server.
> >
> >Tim
> >
> >At 03:58 PM 4/26/2006, John Neiberger pronounced:
> > >This is on a native mode SUP2.
> > >
> > >I just had my co-worker startup the client and I see this:
> > >
> > >(10.a.b.c, 224.0.1.55), 00:07:16/00:00:10, flags: T
> > > Incoming interface: Vlan4, RPF nbr 0.0.0.0, RPF-MFD
> > > Outgoing interface list:
> > > Vlan1, Forward/Dense, 00:07:16/00:00:00, H
> > >
> > >where 10.a.b.c is the IP address of the client.
> > >
> > >Here is the output of some debugging:
> > >
> > >y19w: IP: s=10.a.b.c (Vlan4) d=224.0.1.55 (Vlan1) len 92,
mforward
> > >1y19w: MRT: Create (10.a.b.c,224.0.1.55), RPF Vlan4/0.0.0.0
> > >1y19w: MRT: WAVL Insert interface: Vlan1 in (10.a.b.c,224.0.1.55)
> > >Successful
> > >1y19w: MRT: Add Vlan1/224.0.1.55 to the olist of (10.a.b.c,
> > >224.0.1.55), Forward state
> > >1y19w: IP: MAC sa=0003.470b.6bce (Vlan4), IP last-hop=10.a.b.c
> > >1y19w: IP: IP tos=0x0, len=78, id=0x34BF, ttl=1, prot=17
> > >1y19w: IP: s=10.a.b.c (Vlan4) d=224.0.1.55 (Vlan1) len 92,
mforward
> > >
> > >Interestingly, the output of show mac-address-table multicast
shows
> >two
> > >entries for 0100.5e00.0137:
> > >
> > >4 0100.5e00.0137 static Yes -- Router
> > >1 0100.5e00.0137 static Yes -- Gi4/16
> > >
> > >The Vlan1 entry is my static entry. Why would the 6513 an entry
in
> > >Vlan4? The source of the packet is in Vlan4 but I don't
understand
> >why
> > >that would create an entry in the mac address table. Isn't the
table
> > >only for destination MAC addresses? If so, why would an entry show
up
> > >for the source?
> > >
> > >Thanks!
> > >John
> > >--
> > >
> > >
> > > >>> Tim Stevenson <tstevens at cisco.com> 4/26/06 4:44:38 PM >>>
> > >Do you see a source,group entry? You seem to be running dense
mode,
> > >and DM fwding is always on the s,g never the *,g (the *,g is
created
> > >but not used for fwding).
> > >
> > >So you need to see a PC,224.0.1.55 mroute entry with vlan1 as an
OIF.
> > >
> > >BTW, what supervisor engine are you using, sup2 or sup720?
> > >
> > >Also, you are sure the packets are not getting L3 switched (ie,
that
> > >they're not dropping somewhere in vlan 1)?
> > >
> > >Tim
> > >
> > >At 02:37 PM 4/26/2006, John Neiberger pronounced:
> > > >I've got an interesting issue that I think I'm tantalizingly
close
> >to
> > > >solving but I haven't had to deal with multicast stuff in
years.
> > > >
> > > >We have a PC on one subnet that is sourcing a multicast packet.
I
> > >need
> > > >to get that packet to a device on another LAN that is not
capable
> >of
> > > >sending IGMP joins. Here's the topology:
> > > >
> > > >PC *- 6513(IOS) *- 2950 *- Server
> > > >
> > > >In this case, the PC is sending out a single multicast packet
> >trying
> > >to
> > > >reach the server. The packet does not reach the server because
it
> > >can't
> > > >join the group. The multicast group is 224.0.1.55. The "server"
is
> >in
> > > >Vlan1, so on the 6513 I have the following configured:
> > > >
> > > >int Vlan1
> > > > ...
> > > > ip igmp static-group 224.0.1.55
> > > >!
> > > >! That makes Vlan1 show up in the mroute table, but I still need
to
> > > >forward that packet out some particular interface, right? So...
> > > >!
> > > >mac-address-table static 0100.5e00.0137 vlan 1 interface
> > > >GigabitEthernet4/16
> > > >!
> > > >! That statically forwards traffic destined for that multicast
> > >address
> > > >out the interface leading to the Catalyst 2950
> > > >
> > > >On the 2950 I have the following:
> > > >
> > > >mac-address-table static 0100.5e00.0137 vlan 1 interface
> > > >GigabitEthernet0/2
> > > >
> > > >That should forward the multicast traffic to the server hanging
of
> > >off
> > > >g0/2. However, this isn't working. I've tinkered with a couple
of
> > > >different configs but nothing seems to work. Debugging shows
that
> >the
> > > >multicast packet is making it to the 6513.
> > > >
> > > >1y19w: IP: s=10.a.b.c (Vlan4) d=224.0.1.55 (Vlan1) len 92,
mforward
> > > >
> > > >The output of "show ip mroute 224.0.1.55" shows the following:
> > > >
> > > >(*, 224.0.1.55), 00:00:01/00:02:58, RP 0.0.0.0, flags: DC
> > > > Incoming interface: Null, RPF nbr 0.0.0.0
> > > > Outgoing interface list:
> > > > Vlan1, Forward/Dense, 00:00:01/00:00:00
> > > >
> > > >It looks to me like the 6513 should know where to forward the
> >packets
> > > >but it isn't working.
> > > >
> > > >Any ideas?
> > > >
> > > >Thanks!
> > > >John
> > > >--
> > > >_______________________________________________
> > > >cisco-nsp mailing list cisco-nsp at puck.nether.net
> > > >https://puck.nether.net/mailman/listinfo/cisco-nsp
> > > >archive at http://puck.nether.net/pipermail/cisco-nsp/
> > >
> > >
> > >
> > >Tim Stevenson, tstevens at cisco.com
> > >Routing & Switching CCIE #5561
> > >Technical Marketing Engineer, Catalyst 6500
> > >Cisco Systems, http://www.cisco.com
> > >IP Phone: 408-526-6759
> > >********************************************************
> > >The contents of this message may be *Cisco Confidential*
> > >and are intended for the specified recipients only.
> >
> >
> >
> >Tim Stevenson, tstevens at cisco.com
> >Routing & Switching CCIE #5561
> >Technical Marketing Engineer, Catalyst 6500
> >Cisco Systems, http://www.cisco.com
> >IP Phone: 408-526-6759
> >********************************************************
> >The contents of this message may be *Cisco Confidential*
> >and are intended for the specified recipients only.
>
>
>
> Tim Stevenson, tstevens at cisco.com
> Routing & Switching CCIE #5561
> Technical Marketing Engineer, Catalyst 6500
> Cisco Systems, http://www.cisco.com
> IP Phone: 408-526-6759
> ********************************************************
> The contents of this message may be *Cisco Confidential*
> and are intended for the specified recipients only.
> _______________________________________________
> cisco-nsp mailing list cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
More information about the cisco-nsp
mailing list