TechLibrary

Navigation

Supported Platforms

Enabling IGMP Static Group Membership

You can create IGMP static group membership to test multicast forwarding without a receiver host. When you enable IGMP static group membership, data is forwarded to an interface without that interface receiving membership reports from downstream hosts. The router on which you enable static IGMP group membership must be the designated router (DR) for the subnet. Otherwise, traffic does not flow downstream.

When enabling IGMP static group membership, you cannot configure multiple groups using the group-count, group-increment, source-count, and source-increment statements if the all option is specified as the IGMP interface.

Class-of-service (CoS) adjustment is not supported with IGMP static group membership.

In this example, you create static group 225.1.1.1.

On the DR, configure the static groups to be created by including the static statement and group statement and specifying which IP multicast address of the group to be created. When creating groups individually, you must specify a unique address for each group.
[edit protocols igmp]user@host# set interface fe-0/1/2 static group 225.1.1.1
After you commit the configuration, use the show configuration protocol igmp command to verify the IGMP protocol configuration.
user@host> show configuration protocol igmp
interface fe-0/1/2.0 {static {group 225.1.1.1 ;}}
After you have committed the configuration and the source is sending traffic, use the show igmp group command to verify that static group 225.1.1.1 has been created.
user@host> show igmp group
```
Interface: fe-0/1/2
     Group: 225.1.1.1
         Source: 10.0.0.2
         Last reported by: Local
         Timeout: 0 Type: Static
```

Note: When you configure static IGMP group entries on point-to-point links that connect routing devices to a rendezvous point (RP), the static IGMP group entries do not generate join messages toward the RP.

When you create IGMP static group membership to test multicast forwarding on an interface on which you want to receive multicast traffic, you can specify that a number of static groups be automatically created. This is useful when you want to test forwarding to multiple receivers without having to configure each receiver separately.

In this example, you create three groups.

On the DR, configure the number of static groups to be created by including the group-count statement and specifying the number of groups to be created.
[edit protocols igmp]user@host# set interface fe-0/1/2 static group 225.1.1.1 group-count 3
After you commit the configuration, use the show configuration protocol igmp command to verify the IGMP protocol configuration.
user@host> show configuration protocol igmp
interface fe-0/1/2.0 {static {group 225.1.1.1 {group-count 3;}}}

After you have committed the configuration and after the source is sending traffic, use the show igmp group command to verify that static groups 225.1.1.1, 225.1.1.2, and 225.1.1.3 have been created.

user@host> show igmp group

Interface: fe-0/1/2
     Group: 225.1.1.1
         Source: 10.0.0.2
         Last reported by: Local
         Timeout: 0 Type: Static
     Group: 225.1.1.2
         Source: 10.0.0.2
         Last reported by: Local
         Timeout: 0 Type: Static
     Group: 225.1.1.3
         Source: 10.0.0.2
         Last reported by: Local
         Timeout: 0 Type: Static

When you create IGMP static group membership to test multicast forwarding on an interface on which you want to receive multicast traffic, you can also configure the group address to be automatically incremented for each group created. This is useful when you want to test forwarding to multiple receivers without having to configure each receiver separately and when you do not want the group addresses to be sequential.

In this example, you create three groups and increase the group address by an increment of two for each group.

On the DR, configure the group address increment by including the group-increment statement and specifying the number by which the address should be incremented for each group. The increment is specified in dotted decimal notation similar to an IPv4 address.
[edit protocols igmp]user@host# set interface fe-0/1/2 static group 225.1.1.1 group-count 3 group-increment 0.0.0.2
After you commit the configuration, use the show configuration protocol igmp command to verify the IGMP protocol configuration.
user@host> show configuration protocol igmp
interface fe-0/1/2.0 {version 3;static {group 225.1.1.1 {group-increment 0.0.0.2;group-count 3;}}}

After you have committed the configuration and after the source is sending traffic, use the show igmp group command to verify that static groups 225.1.1.1, 225.1.1.3, and 225.1.1.5 have been created.

user@host> show igmp group

Interface: fe-0/1/2
     Group: 225.1.1.1
         Source: 10.0.0.2
         Last reported by: Local
         Timeout: 0 Type: Static
     Group: 225.1.1.3
         Source: 10.0.0.2
         Last reported by: Local
         Timeout: 0 Type: Static
     Group: 225.1.1.5
         Source: 10.0.0.2
         Last reported by: Local
         Timeout: 0 Type: Static

When you create IGMP static group membership to test multicast forwarding on an interface on which you want to receive multicast traffic, and your network is operating in source-specific multicast (SSM) mode, you can also specify that the multicast source address be accepted. This is useful when you want to test forwarding to multicast receivers from a specific multicast source.

If you specify a group address in the SSM range, you must also specify a source.

If a source address is specified in a multicast group that is statically configured, the IGMP version on the interface must be set to IGMPv3. IGMPv2 is the default value.

In this example, you create group 225.1.1.1 and accept IP address 10.0.0.2 as the only source.

On the DR, configure the source address by including the source statement and specifying the IPv4 address of the source host.
[edit protocols igmp]user@host# set interface fe-0/1/2 static group 225.1.1.1 source 10.0.0.2
After you commit the configuration, use the show configuration protocol igmp command to verify the IGMP protocol configuration.
user@host> show configuration protocol igmp
interface fe-0/1/2.0 {version 3;static {group 225.1.1.1 {source 10.0.0.2;}}}
After you have committed the configuration and the source is sending traffic, use the show igmp group command to verify that static group 225.1.1.1 has been created and that source 10.0.0.2 has been accepted.
user@host> show igmp group
```
Interface: fe-0/1/2
     Group: 225.1.1.1
         Source: 10.0.0.2
         Last reported by: Local
         Timeout: 0 Type: Static
```

When you create IGMP static group membership to test multicast forwarding on an interface on which you want to receive multicast traffic, you can specify that a number of multicast sources be automatically accepted. This is useful when you want to test forwarding to multicast receivers from more than one specified multicast source.

In this example, you create group 255.1.1.1 and accept addresses 10.0.0.2, 10.0.0.3, and 10.0.0.4 as the sources.

On the DR, configure the number of multicast source addresses to be accepted by including the source-count statement and specifying the number of sources to be accepted.
[edit protocols igmp]user@host# set interface fe-0/1/2 static group 225.1.1.1 source 10.0.0.2 source-count 3
After you commit the configuration, use the show configuration protocol igmp command to verify the IGMP protocol configuration.
user@host> show configuration protocol igmp
interface fe-0/1/2.0 {version 3;static {group 225.1.1.1 {source 10.0.0.2 {source-count 3;}}}}

After you have committed the configuration and the source is sending traffic, use the show igmp group command to verify that static group 225.1.1.1 has been created and that sources 10.0.0.2, 10.0.0.3, and 10.0.0.4 have been accepted.

user@host> show igmp group

Interface: fe-0/1/2
     Group: 225.1.1.1
         Source: 10.0.0.2
         Last reported by: Local
         Timeout: 0 Type: Static
     Group: 225.1.1.1
         Source: 10.0.0.3
         Last reported by: Local
         Timeout: 0 Type: Static
     Group: 225.1.1.1
         Source: 10.0.0.4
         Last reported by: Local
         Timeout: 0 Type: Static

When you configure static groups on an interface on which you want to receive multicast traffic, and specify that a number of multicast sources be automatically accepted, you can also specify the number by which the address should be incremented for each source accepted. This is useful when you want to test forwarding to multiple receivers without having to configure each receiver separately and you do not want the source addresses to be sequential.

In this example, you create group 225.1.1.1 and accept addresses 10.0.0.2, 10.0.0.4, and 10.0.0.6 as the sources.

Configure the multicast source address increment by including the source-increment statement and specifying the number by which the address should be incremented for each source. The increment is specified in dotted decimal notation similar to an IPv4 address.
[edit protocols igmp]user@host# set interface fe-0/1/2 static group 225.1.1.1 source 10.0.0.2 source-count 3 source-increment 0.0.0.2
After you commit the configuration, use the show configuration protocol igmp command to verify the IGMP protocol configuration.
user@host> show configuration protocol igmp
interface fe-0/1/2.0 {version 3;static {group 225.1.1.1 {source 10.0.0.2 {source-count 3;source-increment 0.0.0.2;}}}}

After you have committed the configuration and after the source is sending traffic, use the show igmp group command to verify that static group 225.1.1.1 has been created and that sources 10.0.0.2, 10.0.0.4, and 10.0.0.6 have been accepted.

user@host> show igmp group

Interface: fe-0/1/2
     Group: 225.1.1.1
         Source: 10.0.0.2
         Last reported by: Local
         Timeout: 0 Type: Static
     Group: 225.1.1.1
         Source: 10.0.0.4
         Last reported by: Local
         Timeout: 0 Type: Static
     Group: 225.1.1.1
         Source: 10.0.0.6
         Last reported by: Local
         Timeout: 0 Type: Static

When you configure static groups on an interface on which you want to receive multicast traffic and your network is operating in source-specific multicast (SSM) mode, you can specify that certain multicast source addresses be excluded.

By default the multicast source address configured in a static group operates in include mode. In include mode the multicast traffic for the group is accepted from the source address configured. You can also configure the static group to operate in exclude mode. In exclude mode the multicast traffic for the group is accepted from any address other than the source address configured.

If a source address is specified in a multicast group that is statically configured, the IGMP version on the interface must be set to IGMPv3. IGMPv2 is the default value.

In this example, you exclude address 10.0.0.2 as a source for group 225.1.1.1.

On the DR, configure a multicast static group to operate in exclude mode by including the exclude statement and specifying which IPv4 source address to exclude.
[edit protocols igmp]user@host# set interface fe-0/1/2 static group 225.1.1.1 exclude source 10.0.0.2
After you commit the configuration, use the show configuration protocol igmp command to verify the IGMP protocol configuration.
user@host> show configuration protocol igmp
interface fe-0/1/2.0 {version 3;static {group 225.1.1.1 {exclude;source 10.0.0.2;}}}
After you have committed the configuration and the source is sending traffic, use the show igmp group detail command to verify that static group 225.1.1.1 has been created and that the static group is operating in exclude mode.
user@host> show igmp group detail
```
Interface: fe-0/1/2
     Group: 225.1.1.1
         Group mode: Exclude
         Source: 10.0.0.2
         Last reported by: Local
         Timeout: 0 Type: Static
     
```

TechLibrary

Supported Platforms

Related Documentation

Enabling IGMP Static Group Membership

Related Documentation

Published: 2014-07-23

Supported Platforms

Related Documentation

Published: 2014-07-23