igmp snooping?

igmp snooping?

[Lennert Buytenhek]

Hi,

Is someone working on igmp snooping (and/or active discovery) for
bridging yet?  I currently have a need for this, so if noone is
working on it yet, I'll probably give it a go myself.

AFAICS, for the kernel part:
- Add capability to add/modify/delete multicast (ethernet) addresses
  in the forwarding database.  Each multicast fdb entry contains a port
  bitmask of ports that are interested in this address.
- Lookup multicast addresses in the forwarding path, instead of flooding
  every packet.
- Policy decision on whether to drop or flood traffic for multicast
  addresses that have no corresponding fdb entry.
- Add capability for userland to 'steal' IGMP packets.  (I.e. to be able
  to prevent them from being forwarded.)

And some userspace daemon that implements the necessary bits.

Ideas?


cheers,
Lennert

Re: igmp snooping?

[jamal]

On Thu, 2005-19-05 at 00:14 +0200, Lennert Buytenhek wrote:
> Hi,
> 
> Is someone working on igmp snooping (and/or active discovery) for
> bridging yet?  I currently have a need for this, so if noone is
> working on it yet, I'll probably give it a go myself.
> 

Not that i know of - someone else may.

> AFAICS, for the kernel part:
> - Add capability to add/modify/delete multicast (ethernet) addresses
>   in the forwarding database.  Each multicast fdb entry contains a port
>   bitmask of ports that are interested in this address.

You would probably also need to do a SIOCADDMULTI for those ports -
unless bridging puts all those ports in promisc mode. If it doesnt go
promisc, you _may_ also need to worry about boundary conditions when the
tiny physical devices hardware multicast entries start overflowing.

> - Lookup multicast addresses in the forwarding path, instead of flooding
>   every packet.
> - Policy decision on whether to drop or flood traffic for multicast
>   addresses that have no corresponding fdb entry.

Make this configurable. i.e flood on miss, drop on miss, pass to user
space(daemon if one exists) on a miss. 

> - Add capability for userland to 'steal' IGMP packets.  (I.e. to be able
>   to prevent them from being forwarded.)
> 

That would be the the last policy above. 
I think you will also need to have something that just listens to the
different IGMP variants (maybe a packet socket with a pcap filter).
The nice thing about pcap (in mmaped format) is it will tell you about
the ifindex of port it arrived on.

> And some userspace daemon that implements the necessary bits.
> 
> Ideas?
> 

Above. Also take note of:
http://www.ietf.org/internet-drafts/draft-ietf-magma-snoop-12.txt

Many years of experience there on snooping IGMP.
I think your most exciting challenge would be snooping IGMPv3 ;->

cheers,
jamal

Re: igmp snooping?

[David Stevens]

If you put the interface in multicast promiscuous mode (set flag 
IFF_ALLMULTI),
you can receive all hardware groups without joining.

For IGMP and MLD packets, one way to do that pat in an application is to 
create
a raw socket and specify the protocol there. So, to receive all reports
for any version of IGMP sent to any group, you can create a socket like 
this:

        s = socket(PF_INET, SOCK_RAW, IPPROTO_IGMP);


For MLDv1 and MLDv2 (IPv6), they are part of ICMPv6, but you can use
ICMPV6_FILTER with the MLD report types to receive only those.

You can get the receiving interface as ancillary data on a recvmsg()
call with the IPV6_PKTINFO socket option on Linux systems
(IPV6_RECVPKTINFO when RFC 3542 compliant) for IPv6 and
similarly with IP_PKTINFO with IPv4, I believe. You also can get this
information by restricting the socket to receiving on a particular
interface, if you don't want one socket to handle multiple interfaces.
Then, you know which interface by which socket you received on.

So, you should be able to do most, possibly all, of what you want at
application level without modification to the kernel, if you're looking
to do this in an application and not a kernel module.

                                        +-DLS

Re: igmp snooping?

[jamal]

On Wed, 2005-18-05 at 18:44 -0700, David Stevens wrote:
> If you put the interface in multicast promiscuous mode (set flag 
> IFF_ALLMULTI),
> you can receive all hardware groups without joining.
> 
> For IGMP and MLD packets, one way to do that pat in an application is to 
> create
> a raw socket and specify the protocol there. So, to receive all reports
> for any version of IGMP sent to any group, you can create a socket like 
> this:
> 
>         s = socket(PF_INET, SOCK_RAW, IPPROTO_IGMP);
> 
> 
> For MLDv1 and MLDv2 (IPv6), they are part of ICMPv6, but you can use
> ICMPV6_FILTER with the MLD report types to receive only those.
> 
> You can get the receiving interface as ancillary data on a recvmsg()
> call with the IPV6_PKTINFO socket option on Linux systems
> (IPV6_RECVPKTINFO when RFC 3542 compliant) for IPv6 and
> similarly with IP_PKTINFO with IPv4, I believe. You also can get this
> information by restricting the socket to receiving on a particular
> interface, if you don't want one socket to handle multiple interfaces.
> Then, you know which interface by which socket you received on.
> 

Better approach than i proposed.

> So, you should be able to do most, possibly all, of what you want at
> application level without modification to the kernel, if you're looking
> to do this in an application and not a kernel module.

I think it belongs in user space. I would say its probably time that STP
also got moved out. The fact it's in the kernel has hurt addition of
interesting new features.

cheers,
jamal

Re: igmp snooping?

[Jonathan Day]

The information there is excellent, but I would add
one note of caution. IGMPv3 is extensible, and one of
the early extensions out there is for privacy and
security. (No big surprise, there.)

Unless you can guarantee that an IGMPv3 packet will
not contain any extensions not directly supported by
the underlying system, how much of the information you
can snoop on once the packet has been parsed by the
kernel is going to be implementation-dependent.

Now, in 99.99% of all cases, you're not going to have
any significant IGMPv3 traffic, as barely anyone uses
it yet and IGMP specifies that the highest common
version will be used in a group. Thus, if the group
contains IPMPv2 or even IGMPv1 members, none of what
I've written is the least bit important.

If all the systems are using the same OS, then it also
doesn't matter, as anything supported in one will be
supported in the others.

Any case that is left over is the case where you may
need to intercept the traffic prior to it being parsed
by the usual IGMP handler in the kernel. Even so,
you're still using a userspace application, you'd just
want to use one of the pseudo network devices to run a
copy of the traffic to your program.

So the direst case you could possibly imagine is
certainly very doable, and most cases are considerably
easier.

--- David Stevens <dlstevens@us.ibm.com> wrote:
> If you put the interface in multicast promiscuous
> mode (set flag 
> IFF_ALLMULTI),
> you can receive all hardware groups without joining.
> 
> For IGMP and MLD packets, one way to do that pat in
> an application is to 
> create
> a raw socket and specify the protocol there. So, to
> receive all reports
> for any version of IGMP sent to any group, you can
> create a socket like 
> this:
> 
>         s = socket(PF_INET, SOCK_RAW, IPPROTO_IGMP);
> 
> 
> For MLDv1 and MLDv2 (IPv6), they are part of ICMPv6,
> but you can use
> ICMPV6_FILTER with the MLD report types to receive
> only those.
> 
> You can get the receiving interface as ancillary
> data on a recvmsg()
> call with the IPV6_PKTINFO socket option on Linux
> systems
> (IPV6_RECVPKTINFO when RFC 3542 compliant) for IPv6
> and
> similarly with IP_PKTINFO with IPv4, I believe. You
> also can get this
> information by restricting the socket to receiving
> on a particular
> interface, if you don't want one socket to handle
> multiple interfaces.
> Then, you know which interface by which socket you
> received on.
> 
> So, you should be able to do most, possibly all, of
> what you want at
> application level without modification to the
> kernel, if you're looking
> to do this in an application and not a kernel
> module.
> 
>                                         +-DLS
> 
> 
> 


		
Discover Yahoo! 
Have fun online with music videos, cool games, IM and more. Check it out! 
http://discover.yahoo.com/online.html

Re: igmp snooping?

[jamal]

On Wed, 2005-18-05 at 22:09 -0700, Jonathan Day wrote:
> mentation-dependent.
> 
> Now, in 99.99% of all cases, you're not going to have
> any significant IGMPv3 traffic, as barely anyone uses
> it yet and IGMP specifies that the highest common
> version will be used in a group. 

A significant amount of video type apps that i have seen lately
try to use IGMPv3 and then fallback to IGMPv2. I think that this may be
aggravated due to our friends at MS discovering IGMPv3.

cheers,
jamal