[c-nsp] Multicast Issue

Thu Apr 27 07:37:11 EDT 2006

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/