Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Examples: Configuring Administrative Scoping

 

Understanding Multicast Administrative Scoping

You use multicast scoping to limit multicast traffic by configuring it to an administratively defined topological region. Multicast scoping controls the propagation of multicast messages—both multicast group join messages that are sent upstream toward a source and data forwarding downstream. Scoping can relieve stress on scarce resources, such as bandwidth, and improve privacy or scaling properties.

IP multicast implementations can achieve some level of scoping by using the time-to-live (TTL) field in the IP header. However, TTL scoping has proven difficult to implement reliably, and the resulting schemes often are complex and difficult to understand.

Administratively scoped IP multicast provides clearer and simpler semantics for multicast scoping. Packets addressed to administratively scoped multicast addresses do not cross configured administrative boundaries. Administratively scoped multicast addresses are locally assigned, and hence are not required to be unique across administrative boundaries.

The administratively scoped IP version 4 (IPv4) multicast address space is the range from 239.0.0.0 through 239.255.255.255.

The structure of the IPv4 administratively scoped multicast space is based loosely on the IP version 6 (IPv6) addressing architecture described in RFC 1884, IP Version 6 Addressing Architecture.

There are two well-known scopes:

  • IPv4 local scope—This scope comprises addresses in the range 239.255.0.0/16. The local scope is the minimal enclosing scope and is not further divisible. Although the exact extent of a local scope is site-dependent, locally scoped regions must not span any other scope boundary and must be contained completely within or be equal to any larger scope. If scope regions overlap in an area, the area of overlap must be within the local scope.

  • IPv4 organization local scope—This scope comprises 239.192.0.0/14. It is the space from which an organization allocates subranges when defining scopes for private use.

The ranges 239.0.0.0/10, 239.64.0.0/10, and 239.128.0.0/10 are unassigned and available for expansion of this space.

Two other scope classes already exist in IPv4 multicast space: the statically assigned link-local scope, which is 224.0.0.0/24, and the static global scope allocations, which contain various addresses.

All scoping is inherently bidirectional in the sense that join messages and data forwarding are controlled in both directions on the scoped interface.

You can configure multicast scoping either by creating a named scope associated with a set of routing device interfaces and an address range, or by referencing a scope policy that specifies the interfaces and configures the address range as a series of filters. You cannot combine the two methods (the commit operation fails for a configuration that includes both). The methods differ somewhat in their requirements and result in different output from the show multicast scope command. For details and configuration instructions, see and .

Routing loops must be avoided in IP multicast networks. Because multicast routers must replicate packets for each downstream branch, not only do looping packets not arrive at a destination, but each pass around the loop multiplies the number of looping packets, eventually overwhelming the network.

Scoping limits the routers and interfaces that can be used to forward a multicast packet. Scoping can use the TTL field in the IP packet header, but TTL scoping depends on the administrator having a thorough knowledge of the network topology. This topology can change as links fail and are restored, making TTL scoping a poor solution for multicast.

Multicast scoping is administrative in the sense that a range of multicast addresses is reserved for scoping purposes, as described in RFC 2365. Routers at the boundary must be able to filter multicast packets and make sure that the packets do not stray beyond the established limit.

Administrative scoping is much better than TTL scoping, but in many cases the dropping of administratively scoped packets is still determined by the network administrator. For example, the multicast address range 239/8 is defined in RFC 2365 as administratively scoped, and packets using this range are not to be forwarded beyond a network “boundary,” usually a routing domain. But only the network administrator knows where the border routers are and can implement the scoping correctly.

Multicast groups used by unicast routing protocols, such as 224.0.0.5 for all OSPF routers, are administratively scoped for that LAN only. This scoping allows the same multicast address to be used without conflict on every LAN running OSPF.

Example: Creating a Named Scope for Multicast Scoping

This example shows how to configure multicast scoping with four scopes: local, organization, engineering, and marketing.

Requirements

Before you begin:

Overview

The local scope is configured on a GRE tunnel interface. The organization scope is configured on a GRE tunnel interface and a SONET/SDH interface. The engineering scope is configured on an IP-IP tunnel interface and two SONET/SDH interfaces. The marketing scope is configured on a GRE tunnel interface and two SONET/SDH interfaces. The Junos OS can scope any user-configurable IPv6 or IPv4 group.

To configure multicast scoping by defining a named scope, you must specify a name for the scope, the set of routing device interfaces on which you are configuring scoping, and the scope's address range.

Note

The prefix specified with the prefix statement must be unique for each scope statement. If multiple scopes contain the same prefix, only the last scope applies to the interfaces. If you need to scope the same prefix on multiple interfaces, list all of them in the interface statement for a single scope statement.

When you configure multicast scoping with a named scope, all scope boundaries must include the local scope. If this scope is not configured, it is added automatically at all scoped interfaces. The local scope limits the use of the multicast group 239.255.0.0/16 to an attached LAN.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Step-by-Step Procedure

  1. The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

    Configure the local scope.

  2. Configure the organization scope.

  3. Configure the engineering scope.

  4. Configure the marketing scope.

  5. If you are done configuring the device, commit the configuration.

Results

Confirm your configuration by entering the show routing-options command.

Verification

To verify that group scoping is in effect, issue the show multicast scope command:

user@host> show multicast scope

When you configure scoping with a named scope, the show multicast scope operational mode command displays the names of the defined scopes, prefixes, and interfaces.

Example: Using a Scope Policy for Multicast Scoping

This example shows how to configure a multicast scope policy named allow-auto-rp-on-backbone, allowing packets for auto-RP groups 224.0.1.39/32 and 224.0.1.40/32 on backbone-facing interfaces, and rejecting all other addresses in the 224.0.1.0/24 and 239.0.0.0/8 address ranges.

Requirements

Before you begin:

Overview

Each referenced policy must be correctly configured at the [edit policy-options] hierarchy level, specifying the set of routing device interfaces on which to configure scoping, and defining the scope's address range as a series of route filters. Only the interface, route-filter, and prefix-list match conditions are supported for multicast scope policies. All other configured match conditions are ignored. The only actions supported are accept, reject, and the policy flow actions next-term and next-policy. The reject action means that joins and multicast forwarding are suppressed in both directions on the configured interfaces. The accept action allows joins and multicast forwarding in both directions on the interface. By default, scope policies apply to all interfaces. The default action is accept.

Note

Multicast scoping configured with a scope policy differs in some ways from scoping configured with a named scope (which uses the scope statement):

  • You cannot apply a scope policy to a specific routing instance, because all scope policies apply to all routing instances. In contrast, a named scope does apply individually to a specific routing instance.

  • In contrast to scoping with a named scope, scoping with a scope policy does not automatically add the local scope at scope boundaries. You must explicitly configure the local scope boundaries. The local scope limits the use of the multicast group 239.255.0.0/16 to an attached LAN.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

  1. Define which packets are allowed.

  2. Define which packets are not allowed.

  3. Apply the policy.

  4. If you are done configuring the device, commit the configuration.

Results

Confirm your configuration by entering the show policy-options and show routing-options commands.

Verification

To verify that the scope policy is in effect, issue the show multicast scope configuration mode command:

When you configure multicast scoping with a scope policy, the show multicast scope operational mode command displays only the name of the scope policy.

Example: Configuring Externally Facing PIM Border Routers

In this example, you add the scope statement at the [edit routing-options multicast] hierarchy level to prevent auto-RP traffic from “leaking” into or out of your PIM domain. Two scopes defined below, auto-rp-39 and auto-rp-40, are for specific addresses. The scoped-range statement defines a group range, thus preventing group traffic from leaking.