LiSA

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== IGMP Snooping / Forwarding Behaviour ======

===== Port states =====

  * mrouter (router port)
  * subscriber (port belongs to established multicast group)
  * none

===== Forwarding cases (igmp snooping enabled on vlan) =====

  * multicast traffic received on "none" port
    * if no mrouter present, flood to all ports
    * otherwise flood to mrouter ports
  * igmp received on "none" port
    * if no mrouter present, ignore frame (no group is created)
    * otherwise
      * creates multicast group
      * forwards to mrouter ports only
      * port becomes "subscriber"
  * multicast traffic received on "mrouter" port
    * send to established group members only
  * igmp received on "mrouter" port
    * creates multicast group
    * forwards to mrouter ports only

===== Other notes =====

  * if igmp snooping is disabled, multicast traffic is flooded to all ports in vlan, regardless of frame nature (i.e. it is igmp or not); static multicast fdb entries are ignored;
  * mrouters can be statically configured while igmp snooping is disabled on vlan, but they are ignored until igmp snooping is enabled; when igmp snooping is enabled, the rules listed above apply;
  * mrouters are not activated until: interface is up AND interface has access to mrouter vlan (either access mode vlan or trunk allowed vlan)

When changing access vlan, with mrouter already configured (in new vlan):
<code>
5w0d: IGMPSN: mgt: Vlan 15, port Fa0/5 port_id 7 in non-fwd mode
5w0d: IGMPSN: mgt: received pmvlan_linkchange down event on vlan 15 
5w0d: IGMPSN: Adding router port Fa0/5 to all GCEs in Vlan 18
5w0d: L2MM: added rport Fa0/5 on Vlan 18
5w0d: %SYS-5-CONFIG_I: Configured from console by vty0 (10.0.0.2)
</code>

====== Implementation Approach ======

Analyzing the forwarding cases, it turns out that when incoming packets are forwarded to more than one port at the same time, they are forwarded to either all ports in a specific igmp group or all mrouter ports (but not a mix of the two). In other words, depending on the igmp snooping logic, either an igmp group or a list of mrouter ports is sufficient to determine which ports to forward to.

===== Forwarding to ports in an igmp group =====

  * igmp group membership is stored as special fdb entry
  * is_static field in struct net_switch_fdb_entry is change to a bitwise field:
    * b0 tells if entry is dynamic or static
    * b1 tells if entry is regular fdb entry or igmp membership entry
    * for igmp membership entries, a b0 value corresponding to "static" means user-configured group membership
  * all igmp membership entries have a virtual MAC address formed as 01-00 plus the group address (4 bytes)
  * when flooding to all ports in a group, the following actions are taken:
    * first the virtual mac corresponding to the packet destination is build;
    * the fdb bucket corresponding to the virtual mac is determined;
    * the fdb bucket is walked to determine the ports to forward to:
      * virtual mac must be equal (between fdb entry and packet)
      * vlan must be equal (between fdb entry and packet)
  * igmp group listing is done only on the slow path (upon user request) by walking the entire fdb and building the igmp group list:
    * the kernel module is asked for a list of all igmp membership fdb entries (with the ability to filter by a specific group and/or vlan);
    * userspace code walks the fdb entry list and builds a (temporary) list of groups and, for each group, a list of member ports

The following changes need to be made to existing code:
  * fdb queries from userspace need to filter out igmp membership entries;
  * standard (non-multicast) packet fdb lookup needs to ignore igmp membership entries;

===== Forwarding to mrouter ports =====

Whether a port is mrouter or not is a function of the port and vlan. In other words, mrouter can be stored as a flag (bit) depending on the port and vlan. Since vlan number is limited and relatively small (4096), mrouter information can be stored as a per-port vlan-indexed bitmap. The data structure would be similar to vlan membership for trunk ports.

Flooding to all mrouter ports in a specific vlan becomes very simple:
  * use the VDB to iterate through all ports in the required vlan;
  * for each port check if it's mrouter in the required vlan;

Algorithm can be easily cloned from sw_flood().

====== CLI Commands ======

**exec#**
<file>
sh ip igmp snooping [vlan x]
sh ip igmp snooping groups [vlan x] [dynamic|user] [count] etc
sh ip igmp snooping mrouter [vlan x]
</file>

**config#**
<file>
[no] ip igmp snooping vlan x mrouter interface y
[no] ip igmp snooping vlan x static a.b.c.d interface y
</file>

====== Useful links ======
  * [[http://tools.ietf.org/html/rfc4541|RFC 4541 - Considerations for IGMP and MLD Snooping Switches]]
  * [[http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_25_see/configuration/guide/swigmp.html|Configuring IGMP Snooping and MVR (Catalyst 3560)]]
  * [[http://technet.microsoft.com/en-us/library/cc957928.aspx|Mapping IP Multicast to MAC-Layer Multicast]]
  * [[http://www.columbia.edu/~alan/igmp/|Some experiments with IGMP snooping behavior of a couple of switches]]
  * [[http://www.advenage.com/topics/change-IGMP-version-on-debian-linux.php|Changing IGMP version on Debian Linux Systems]]