Layer 2 multicast

1.6.a i IGMPv2, IGMPv3

Internet Group Management Protocol

IGMP introduction (not on blueprint)

General information on “IGMP introduction (not on blueprint)":

• Used to inform a multicast router that a host wants to receive multicast traffic for a specific group
• Used to inform a multicast router that a host doesn’t want to receive multicast traffic for a specific group anymore

“IGMP introduction” CLI configuration commands:"

## Joining a specific IPv4 multicast group
Router(config)# interface <if>
Router(config-if)# ip igmp join-group <multicast-address>

Router(config)# interface <if>
Router(config-if)# ip igmp join-group <multicast-address> source <multicast-source>

## Setting the IGMP version on a per-interface basis
Router(config)# interface <if>
Router(config-if)# ip igmp version <version>

IGMPv2

General information on “IGMPv2”:

• Different message types:
  • Membership reports: Will be sent from a host when he wants to join/receive a specific multicast group (unsolicited report) and in response to IGMP membership queries from a local multicast router (solicited report).
  • Membership queries: Issued by local multicast routers at regular intervals to check if there’s a host on the segment interested in a specific multicast group. Also sent out when a host on a segment sends a IGMP leave message to check if there are still other receivers on the segment.
  • Leave messages: Issued by hosts to inform that they don’t want to receive a specific multicast group anymore. After receiving the IGMP leave message, the multicast router sends a group-specific IGMP query to the segment to see if any host still wants to receive traffic for that multicast group.
• IGMPv2 message destinations:
  • Membership reports: The multicast group address the host wants to join
  • General membership queries: The all-nodes multicast group 224.0.0.1
  • Group-specific membership queries: The specific multicast group the router wants to check
  • Leave messages: The all-routers multicast group 224.0.0.2

IGMPv3

General information on “IGMPv3”:

• Backwards compatible with v1/v2
• Introduces support for SSM (= source-specific multicast) so that hosts can signalize from which source address they want to receive the multicast traffic
• Membership reports can now contain multiple multicast groups the host is interested in
• IGMPv3 message destinations:
  • Membership reports: The IGMPv3-routers multicast group 224.0.0.22
  • General membership queries: The all-nodes multicast group 224.0.0.1
  • Group-specific membership queries: The specific multicast group the router wants to check
  • Leave messages: The all-routers multicast group 224.0.0.2

1.6.a ii IGMP Snooping, PIM Snooping

// Graphic missing - coming soon //

IGMP Snooping

General information on “IGMP Snooping”:

• By default, a switch floods multicast traffic to all ports within a broadcast domain
• This results in unnecessary traffic because even hosts who don’t request traffic will receive it
• With IGMP snooping, the L2 device learns which end hosts need to receive multicast traffic within a specific VLAN
• This is done by listening to IGMP membership report/leave messages
• This way the switch finds out which hosts wants to join/leave which multicast groups
• IGMP snooping is done by maintaining a map of which links need which IP multicast traffic
• Example: If a host wants to receive multicast traffic from 239.1.1.1 he sends an IGMP membership report message. With IGMP snooping enabled, the switch now knows that he needs to forward the specific multicast traffic on the link to the host. If a host doesn’t want to receive multicast traffic anymore, he sends an IGMP leave message. The switch now knows the host doesn’t need the multicast traffic anymore and will prune it off the link to the host.

“IGMP Snooping” configuration considerations:

• The feature is enabled by default and can be disabled globally on a per VLAN basis

“IGMP Snooping” CLI show commands:

## Showing the IGMP snooping configuration
Switch# show ip igmp snooping

## Showing which interfaces requested which multicast group
Switch# show ip igmp groups

## Showing the IGMP interface table
Switch# show ip igmp interface

PIM Snooping

General information on “PIM Snooping”:

• This feature is not supported on all platforms
• By default, a switch floods multicast traffic to all ports where a router is connected
• This results in unnecessary traffic because even routers who don’t need to forward multicast traffic will receive it
• With PIM snooping, the L2 device learns which routers need to receive multicast traffic within a specific VLAN
• This is done by listening to PIM hello/join/prune messages
• Auto-RP multicast groups (224.0.1.39 and 224.0.1.40) are always flooded
• Important: PIM snooping requires IGMP (IPv4)/MLD (IPv6) snooping to be enabled!

“PIM Snooping” configuration considerations:

• The feature is disabled by default and can be enabled globally or on a per VLAN basis

“PIM Snooping” CLI configuration commands:

## Enabling PIM snooping globally
Switch(config)# ip pim snooping

## Enabling PIM snooping for a specific VLAN interface
Switch(config)# interface vlan <vlan-id>
Switch(config-if)# ip pim snooping

“PIM Snooping” CLI show commands:

## Showing the PIM snooping configuration
Switch# show ip pim snooping

1.6.a iii IGMP Querier

General information on “IGMP Querier”:

• Without a dedicated multicast router within a network, IGMP snooping doesn’t work
• This is because the L2 device doesn’t know who to signalize that end hosts want to or don’t want receive multicast traffic anymore
• This results in that the L2 device will treating multicast traffic like broadcast traffic and flood it out all ports within a broadcast domain, no matter if IGMP snooping is enabled or not
• Solution: When the IGMP Querier option enabled, a L2 device can act as pseudo multicast router (mrouter). The L2 device will then send out periodic IGMP queries (60 seconds by default) in the network.

“IGMP Querier” CLI configuration commands:

## Configuring a switch as an IGMP querier
Switch(config)# ip igmp snooping querier

“IGMP Querier” CLI show commands:

### Showing the IGMP snooping querier configuration and operation information
Switch# show ip igmp snooping querier

1.6.a iv IGMP Filter

General information on “IGMP Filter”:

• By default, every multicast group can be used for multicast traffic
• With IGMP Filter it’s possible to allow/deny specific multicast groups based on ACLs
• The implementation can be done at L2 and L3 devices
• Requires configured and enabled IGMP snooping to work
• Can be applied at an SVI, per port or per VLAN on a trunk port
• Example: A host is attached to port eth0/0 and wants to join the multicast group 239.1.1.1. An IGMP filter is applied on eth0/0 denying the multicast group 239.1.1.1. When the host tries to join the multicast group it will fail and not can’t receive/send traffic from/to it. This only applies to hosts attached to a port where the IGMP filter is activated.

“IGMP Filter” CLI configuration commands:

## Configuring a L2 IGMP filter
Switch(config)# ip igmp profile <id>
Switch(config-if)# [permit | deny | range] <multicast-group>

Switch(config)# interface <if>
Switch(config-if)# ip igmp filter <igmp-profile-id>

## Configuring a L3 IGMP filter
Switch(config)# interface <if>
Switch(config-if)# ip igmp access-group [ACL-NAME]

1.6.a v MLD

Multicast Listener Discovery

General information on “MLD”:

• MLD is for IPv6 what IGMP is for IPv4
• MLD is a part of the ICMPv6 stack
• Provides the same functions as IGMP like snooping, querier, filtering, … and configuration is almost the same
• Two different versions:
  • MLDv1: Functions similar to IGMPv2
  • MLDv2: Functions similar to IGMPv3, backwards compatible to MLDv1
• Different message types:
  • Multicast Listener Report: Will be sent from a host when he wants to join/receive a specific multicast group (unsolicited report) and in response to Multicast Listener Queries from a local multicast router (solicited report).
  • Multicast Listener Query: Issued by local multicast routers at regular intervals to check if there’s a host on the segment interested in a specific multicast group. Also sent out when a host on a segment sends a Multicast Listener Done to check if there are still other receivers on the segment.
  • Multicast Listener Done: Issued by hosts to inform that they don’t want to receive a specific multicast group anymore. After receiving the Multicast Listener Done message, the multicast router sends a group-specific Multicast Listener Query to the segment to see if any host still wants to receive traffic for that multicast group.
• MLDv1 message destinations:
  • Multicast Listener Report: The multicast group address the host wants to join
  • Multicast Listener Query: The all-nodes multicast group FF02::1
  • Group-specific Multicast Listener Query: The specific multicast group the router wants to check
  • Multicast Listener Done: The all-routers multicast group FF02::2
• MLDv2 message destinations:
  • Multicast Listener Report: The MLDv2 multicast group FF02::16
  • Multicast Listener Query: The all-nodes multicast group FF02::1
  • Group-specific Multicast Listener Query: The specific multicast group the router wants to check
  • Multicast Listener Done: The all-routers multicast group FF02::2

“MLD” CLI configuration commands:

## Joining a specific IPv6 multicast group
Router(config-if)# ipv6 mld join-group <multicast-address>

## Joining a specific IPv6 multicast group and filter/limit the allowed multicast sources
Router(config-if)# ipv6 mld join-group <multicast-address> source-list [IPv6 ACL]