Non-Subscribers receiving traffic from Multicast Group

[FLind9999]

Hello all,

    We came across a really bizarre issue. We have been doing wireshark captures to determine why were are getting outages. We have devices that are basically getting hit with mutlicast traffic they did not subscribe to and when this happens they send the ICMP unreachable requests to our server cause our server to have a service failure. Digging into the capture it was noticed that some of the groups being sent included HSRP. The software on the devices limits what groups it can even subscribe to so the HSRP group should not have any been an option. Over all it is an odd issue as we have been trying find out how this is even happening with IGMPv3 running.

[balaji.bandi]

Can you post some logs what MCAST address is that ?

[FLind9999]

172.16.48.2 is our aggregate switch and 172.16.48.175 is our device we are trying to determine why this happened. We looked at the IGMP traffic and there is no join request from that device for the MC HSRP group from the .175. 

[johnd2310]

Hi,

I think the HSRP packets 224.0.0.102 are sent out all interfaces. Generally addresses in the 224.0.0.0/24 will be sent out all interfaces. There is no joins required. In your case, the question is why is the device 172.16.48.175 responding. Does this device support/understand HSRP and is not configured or is something else going on on this device. You should look at why this device is responding to HSRP

Thanks

John

[paul driver]

Hello

---

@FLind9999 wrote: 172.16.48.2 is our aggregate switch 

---

And is this switch actively running HRSPv2 with your host on the same subnet?

[Elliot Dierksen]

I can think of a couple things that might cause this. First, are you directly plugged in to the Cisco switch or any managed switch? Un-managed switches treat multicast like broadcasts.

Second, are you getting topology changes in spanning tree? Something like this.

EBD-3750E#sh spanning-tree vlan 1 detail

 VLAN0001 is executing the rstp compatible Spanning Tree protocol
  Bridge Identifier has priority 4096, sysid 1, address 0024.c45a.6900
  Configured hello time 2, max age 20, forward delay 15, transmit hold-count 6
  We are the root of the spanning tree
  Topology change flag not set, detected flag not set
  Number of topology changes 131 last change occurred 2w2d ago
          from GigabitEthernet1/0/30
  Times:  hold 1, topology change 35, notification 2
          hello 2, max age 20, forward delay 15
  Timers: hello 0, topology change 0, notification 0, aging 300

Pay particular attention to the last change occurred part. Whether a change is active is also important like this: Topology change flag not set, detected flag not set. If a topology change is active, switches will flood traffic until spanning tree has re-converged.

Last, is there an L3 device that is running PIM in dense mode?

In general I would say that it is incorrect behavior for the client to send an ICMP unreachable in response to a multicast packet.

[David Ruess]

Hello,

As others have noted HSRP sends the multicast to all ports and even hosts/PCs can see them. However, when I labbed this up my VPC did NOT respond to the multicast address, but it did receive it on the port.

Also as others have noted its not so much of a join request thing like actual multicast. So it may be that the PC can understand or process that multicast (or at least tries to) and fails. See attached picture of my capture showing standard operation. .6 is my PC and it is not in the capture responding to any of that traffic.

There could be an underlying program that responds to all multicast addresses on that PC.

Hope that helps.

-David