duplicate multicast messages

[Microbyte]

This is simple connections.
PC1
// \\
6509a = 6509b
\\ //
PC5
PC - computer/workstation dual homed using HSRP where 6509a has the priority.
6509 - catalyst 6509 with sup2
- fast ethernet link
= 2 gigbit link using port-channel

There are many other connected PCs but for sake of this argument they are omitted.
One more thing to note is that there are several VLANs.

The problem is when PC1 sends out a multicast where PC5 is member of, PC5 receives duplicate multicast messages.
PC1 and PC5 have two sets of NIC card.
PC1 sends multicast out from VLAN13, and although PC5 is also part of VLAN13, PC5 sends its membership message from VLAN10.

From using network analyzer, there were indeed two messages going into PC5. By observing Source MAC address, one packet was coming from the port where PC1 resides. But the other one was not clear.
So for unclear source mac-address, issued "show ip arp <source mac-address>" and the switch lists all these different different VLAN addresses (total of 7 - including vlan10 and vlan13) from 6509b (lower priority switch).

I would appreciate if someone can help me with this strange problem.
Thanks!

Microbyte

 

[ADB100]

What is your multicast configuration on the 6509's? Interface PIM modes?, RP's, IGMP?

If the 6509's aren't configured to forward (and restrain) the multicast it will be handled like broadcasts.

Post some more information to help us assist you.

Andy

 

[Microbyte]

PIM-DM is enabled by each inter vlan

6509a has...
interface vlan13
ip address 192.168.13.2 255.255.255.0
no ip redirects
ip pim dense-mode
standby 13 ip 192.168.13.1
standby 13 timers msec 100 msec 300
standby 13 priority 200
standby 13 preempt

6509b has...
interface vlan13
ip address 192.168.13.3 255.255.255.0
no ip redirects
ip pim dense-mode
standby 13 ip 192.168.13.1
standby 13 timers msec 100 msec 300

vlan10 and other vlans are configured in same fashion but under different subnet.

Microbyte

 

[ADB100]

With PIM Dense Mode you will see this as it works in a Flood & Prune fashion. I.e. all multicast interfaces will be periodically flooded with the multicast traffic (as far as the TTL will let it) and then it will prune off the interfaces that don't want to receive it.

HTH

Andy