Configuring Multicast Routing Over IP Demux Interfaces

In a subscriber management network, fields in packets sent from IP demux interfaces are intended to correspond to a specific client that resides on the other side of an aggregation device (for example, a Multiservice Access Node [MSAN]). However, packets sent from a Broadband Services Router (BSR) to an MSAN do not identify the demux interface. Once it obtains a packet, it is up to the MSAN device to determine which client receives the packet.

Depending on the intelligence of the MSAN device, determining which client receives the packet can occur in an inefficient manner. For example, when it receives IGMP control traffic, an MSAN might forward the control traffic to all clients instead of the one intended client. In addition, once a data stream destination is established, though an MSAN can use IGMP snooping to determine which hosts reside in a particular group and limit data streams to only that group, the MSAN still must send multiple copies of the data stream to each group member, even if that data stream is intended for only one client in the group.

Various multicast features, when combined, enable you to avoid the inefficiencies mentioned above. These features include the following:

• The ability to configure the IP demux interface family statement to use inet for either the numbered or unnumbered primary interface. See Configuring Dynamic Subscriber Interfaces Using IP Demux Interfaces in Dynamic Profiles for details.

• The ability to configure IGMP on the primary interface to send general queries for all clients. The demux configuration prevents the primary IGMP interface from receiving any client IGMP control packets. Instead, all IGMP control packets go to the demux interfaces. However, to guarantee that no joins occur on the primary interface:

  • For static IGMP interfaces—Include the passive send-general-query statement in the IGMP configuration at the [edit protocols igmp interface interface-name] hierarchy level.
  • For dynamic IGMP demux interfaces—Include the passive send-general-query statement at the [edit dynamic-profiles profile-name protocols igmp interface interface-name] hierarchy level.

• The ability to map all multicast groups to the primary interface as follows:

  • For static IGMP interfaces—Include the oif-map statement at the [edit protocols igmp interface interface-name] hierarchy level.
  • For dynamic IGMP demux interfaces—Include the oif-map statement at the [edit dynamic-profiles profile-name protocols igmp interface interface-name] hierarchy level.
  Using the oif-map statement, you can map the same IGMP group to the same output interface and send only one copy of the multicast stream from the interface.

• The ability to configure IGMP on each demux interface. To prevent duplicate general queries:

  • For static IGMP interfaces—Include the passive allow-receive send-group-query statement at the [edit protocols igmp interface interface-name] hierarchy level.
  • For dynamic demux interfaces—Include the passive allow-receive send-group-query statement at the [edit dynamic-profiles profile-name protocols igmp interface interface-name] hierarchy level.

  Note: To send only one copy of each group, regardless of how many customers join, use the oif-map statement as previously mentioned.

Related Topics

• Configuring Dynamic Subscriber Interfaces Using IP Demux Interfaces in Dynamic Profiles
• Example: Configuring Multicast with Subscriber VLANs
• Junos Subscriber Access Configuration Guide