You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What is the problem your feature is trying to solve?
IGMP Snooping is a feature on many managed network switches to allow L3 multicast traffic to be propagated as L2 unicast (instead of L2 broadcast). Any end devices that use L3 multicast as part of their functionality should send/respond with IGMP Membership Reports to indicate membership to certain multicast groups.
By way of an example, one of the current tests in Testrun (dns.mdns) listens for mDNS traffic. If a device did indeed implement mDNS, it also ought to send IGMP Membership Reports to indicate to the network switch its need to receive multicast traffic to 224.0.0251.
Describe the solution you think would solve the problem
Implement IGMP Membership Report or Join detection/querying for informational purposes only, with membership reports included in a separate section in the report (much like the detail for NTP and DNS probes, etc.).
Testing could either be done by passive listening for an IGMP join message on DUT start up, or by sending query using something similar to the below nmap command.
Additional context
Not all devices implement IGMP, and so in some cases the network administrators have no choice to but to disable IGMP Snooping on their network switches, leading to a more inefficient network.
There are a number of (smart building) protocols that utilise IP multicast, KNXnet/IP Routing being one of the most popular.
What is the problem your feature is trying to solve?
IGMP Snooping is a feature on many managed network switches to allow L3 multicast traffic to be propagated as L2 unicast (instead of L2 broadcast). Any end devices that use L3 multicast as part of their functionality should send/respond with IGMP Membership Reports to indicate membership to certain multicast groups.
By way of an example, one of the current tests in Testrun (dns.mdns) listens for mDNS traffic. If a device did indeed implement mDNS, it also ought to send IGMP Membership Reports to indicate to the network switch its need to receive multicast traffic to 224.0.0251.
Describe the solution you think would solve the problem
Implement IGMP Membership Report or Join detection/querying for informational purposes only, with membership reports included in a separate section in the report (much like the detail for NTP and DNS probes, etc.).
Testing could either be done by passive listening for an IGMP join message on DUT start up, or by sending query using something similar to the below nmap command.
nmap --script broadcast-igmp-discovery --script-args 'broadcast-igmp-discovery.version=all'
Additional context
Not all devices implement IGMP, and so in some cases the network administrators have no choice to but to disable IGMP Snooping on their network switches, leading to a more inefficient network.
There are a number of (smart building) protocols that utilise IP multicast, KNXnet/IP Routing being one of the most popular.
More info on multicast and IGMP Snooping here.
The text was updated successfully, but these errors were encountered: