8.6. Triple Play Multicast Command Reference

This command creates a text description stored in the configuration file for a configuration context.

The description command associates a text string with a configuration context to help identify the context in the configuration file.

The no form of this command removes any description string from the context.

This command administratively disables the entity. When disabled, an entity does not change, reset, or remove any configuration settings or statistics. Many entities must be explicitly enabled using the no shutdown command. The operational state of the entity is disabled as well as the operational state of any entities contained within. Many objects must be shut down before they may be deleted.

The no form of this command places the entity into an administratively enabled state.

This command enables the context to configure multicast management parameters. The mcast-management CLI node contains the bandwidth-policy and multicast-info-policy definitions. The bandwidth-policy is used to manage the ingress multicast paths into the switch fabric. The multicast-info-policy defines how each multicast channel is handled by the system. The policy may be used by the ingress multicast bandwidth manager, the ECMP path manager and the egress multicast CAC manager.

The mcast-management node always exists and contains the default bandwidth-policy and the default multicast-info-policy. Enter the mcast-management node when editing, deleting or creating a bandwidth policy or multicast info policy. The default bandwidth policy and multicast-info-policy cannot be edited or deleted.

A chassis-level node within multicast-management is used to control the switch fabric multicast planes replication limits. The switch fabric multicast planes are the individual multicast spatial replication contexts available in the system.

This command creates a multicast reporting destination hierarchy in CLI under which parameters defining this destination can be specified. The destination refers to an external node that collects and analyze IGMP events.

The multicast reporting destination is associated with a name that each subscriber can reference to send the IGMP related events.

It can be also referenced in the host tracking policy in case that IGMP events are related to the host tracking feature.

The no form of this command removes the destination name from the configuration.

This command specifies the IP address of the external node to which IGMP events are exported. The destination IP address can only be reachable from the global routing table (no vrf access).

The no form of this command removes the destination address from the configuration.

This command specifies the time interval before the packet starts transmitting towards the destination. When an IGMP event is encoded and ready to be transported, a buffer for the packet is allocated (if not already existent). The events are written into this buffer. Along with the initial buffer creation, a timer is started. The trigger for the transmission of the packet is either the TX buffer being filled up to 1400 B, or the timer expiry, whichever comes first.

The no form of this command reverts to the default.

This command specifies the UDP destination port of the external node to which IGMP events are exported.

The no form of this command reverts to the default.

This command creates a multicast bandwidth policy. Bandwidth policies are used to manage the ingress multicast path bandwidth. Each forwarding plane supports multicast forwarding paths into the switch fabric. By default, two paths are available; the multicast high priority path and the multicast low priority path. Multicast packets are forwarded on either path based on the expedited or non-expedited (best-effort) nature of the queue the packets are scheduled from. The ingress forwarding plane uses the classification rules to determine the forwarding class of each multicast packet and uses the forwarding class to queue mapping to decide which ingress multipoint queue forwards the packet.

When multicast path management is enabled, the ingress forwarding plane allows IP multicast snooped or routed packets to be placed on to the two multicast paths independently of the ingress classification rules. The high priority multicast path is treated as the primary path and the low priority multicast path is treated as the secondary path. The ingress bandwidth manager evaluates each multicast FIB (M-FIB) record to determine which path is best based on ingress bandwidth, number of switch fabric destinations and the fill level of each path. Explicit path association is also supported.

Dynamic Bandwidth Activity Monitoring

When ingress multicast path management is enabled on an MDA, the system monitors the in-use bandwidth associated with each Layer 2 and Layer 3 ingress multicast record. When records are first populated by static, snooping or routing protocols, they are first assumed to be inactive. An inactive record is not considered to be currently consuming ingress multicast path bandwidth.

Within the multicast-info-policy, the bandwidth activity of the new record was configured to be either managed based on an administrative bandwidth, or based on the dynamic bandwidth rate table. The bandwidth-policy associated with ingress MDA contains the configuration parameters for creating the dynamic bandwidth rate table. The purpose of the table is to allow for the system to monitor the bandwidth activity associated with a multicast record and compare the current rate against several rate thresholds. Rate thresholds are used to allow a multicast streams rate to fluctuate between a given range while keeping the managed rate at a certain level. Multiple dynamic managed rates are supported in the table to allow monitoring of different types of multicast traffic. Each rate threshold is associated with a rising and falling threshold that defines when the specified rate should be used and when the next lower rate should be used.

Once a record’s monitored current rate rises to the first dynamic rising threshold, the record is active and the system then manages the bandwidth the record represents based on the parameters associated with the record in the records multicast-info-policy and the configured path information in the MDAs associated bandwidth-policy.

Ingress Multicast Path Parameters

The bandwidth-policy also contains the configuration parameters for each of the managed ingress multicast paths. The queue default parameters can be overridden for each primary and secondary path. In addition, the number of secondary paths (and by implication the number of primary paths) can be overridden.

Default Bandwidth Policy

A bandwidth policy with the name ‘default’ always exists and is used as the default bandwidth policy when ingress multicast path management is enabled without an explicit bandwidth policy defined on an FP. The default policy cannot be deleted or edited.

The no form of this command removes the specified bandwidth policy from the system. The bandwidth policy associations must be removed from MDA configurations before it can be removed.

This command defines at which bandwidth rate a multicast channel configured to use an administrative rate starts and stop using that rate as the in-use ingress bandwidth when managing ingress multicast paths. This parameter only applies to channels that are configured to use the admin-bw rate with the bw-activity use-admin-bw command (both are configured in the multicast-info-policy associated with the channel context).

To be effective, the admin-bw-threshold value must be less than the channels configured admin-bw. If the administrative bandwidth configured on the channel is less than the administrative bandwidth threshold defined in the bandwidth policy, the admin-bw value is ignored for ingress multicast path management and the system continually uses the dynamic ingress bandwidth associated with the channel. Since the value is defined in the bandwidth-policy and the channel admin-bw value is defined in the multicast-info-policy, it is not possible to pre-determine that a given administrative bandwidth value is less than an administrative bandwidth threshold. Since a typical administrative bandwidth threshold is set significantly lower than any administrative bandwidth values, this corner case is not expected to be prevalent. However, if the case does arise in a production environment, no ill behavior is expected as the threshold is simply a tuning parameter used to detect when the bandwidth associated with a channel has risen above any OAM or background type traffic.

While a channel that is configured to use-admin-bw (in the bw-activity command) current bandwidth is less than the admin-bw-threshold, the system treats the channel as a dynamic type channel. Once the threshold is crossed, the system immediately allocates the full admin-bw value to the channel and manages the ingress multicast path accordingly. If the bandwidth monitored on the channel rises above the admin-bw value, the system reverts to dynamic bandwidth management operation. If the bandwidth drops below the admin-bw value, but is above the admin-bw-threshold, the system uses the admin-bw value. If the bandwidth drops below the admin-bw-threshold, the system goes back to dynamic bandwidth management operation.

This command has no effect on multicast ECMP or egress CAC management operations.

The no form of this command reverts to the default, which is 10 kb/s.

This command enables the context to configure T2 path queuing parameters for primary and secondary paths.

This command enables the context to configure primary path parameters.

This command enables the context to configure secondary path queue parameters. This command overrides the default path limit for the secondary path, which is one of the three ingress multicast paths into the switch fabric.

This command is used to explicitly provision the number of secondary paths (and imply the number of primary paths) supported by the TChip based forwarding plane the bandwidth policy is managing. The default (and minimum) number of secondary paths is 1 and the maximum configurable is 15. The number of primary paths is total number of available paths minus the number of secondary paths.

Secondary paths are used by:

Secondary paths are used by:

The number of secondary paths should be increased from the default value of 1 when a single secondary path is enough for explicit secondary path managed traffic or the amount of best-effort multipoint non-managed queue traffic.

The no form of this command restores the default number of secondary paths.

This command enables the context to configure queue parameters. This command defines the individual parameters for the queues through which multicast packets are forwarded into the switch fabric on each path.

The individual path queues may be viewed as shared queues. All multicast packets forwarded through the switch fabric associated with one of the paths traverses bypass the normal queuing behavior. Instead of being forwarded through the normal service or network multicast queue, a single queue associated with the multicast path is used. To retain billing and diagnostic information, the forwarding and discard statistics for the service or network queue the packet would have traversed without ingress multicast management is used to account for each packet’s behavior.

Note: Any ingress scheduling policy functions attempting to manage the service or network multicast queues is only able to read the statistics of the multicast queues and not able to manage the queues dynamic rate since the packets are flowing through different, non-managed queues. Since this is the case, multicast queues parented to a scheduling policy should be parented to the root scheduler at the highest priority without any rate limitation. Any ingress rate limiting for multicast traffic is performed by the multicast path bandwidth manger based on each records priority and a possible “black-hole” rate threshold.

All queues created for ingress multicast path management are automatically created by the system out of the system reserved queue space. Each queue is created as an expedited queue.

When forwarding through the queues, each packets forwarding class is ignored. However, the forwarding class is retained for proper egress processing. The packets expressed or implied profile is also ignored within the ingress path queues. A packets congestion priority is derived from the records cong-priority-threshold evaluation result as indicated by the policy or multicast-info-policy. The cong-priority-threshold sets the high or low congestion priority of a record based on the records preference value. Within each multicast information policy bundle the cong-priority-threshold preference-level is set with a value from 0 to 7 and defines the threshold at which all records with a preference equal to or higher than the defined preference is treated as congestion priority high. Multicast records with a preference lower than the defined class threshold is treated as congestion priority low. Low-priority packets use the low drop-tail threshold of the queue, while high-priority packets use the standard MBS value. In the event of path congestion, low-priority packets are discarded first, leaving room for the higher priority packets.

For the primary and secondary paths, a single queue exists for each path and every packet forwarded through the path by the bandwidth manager uses that queue.

This command overrides the default Committed Buffer Size (CBS) for each individual path’s queue. The queues CBS threshold is used when requesting buffers from the systems ingress buffer pool to indicate whether the requested buffer should be removed from the reserved portion of the buffer pool or the shared portion. When the queue’s fill depth is below or equal to the CBS threshold, the requested buffer comes from the reserved portion. Once the queues depth exceeds the CBS threshold, buffers come from the shared portion.

The cbs percent-of-resv-cbs parameter is defined as a percentage of the reserved portion of the pool. The system allows the sum of all CBS values to equal more than 100% allowing for oversubscription of the reserved portion of the pool. If the reserved portion is oversubscribed and the queues are currently using more reserved space than provisioned in the pool, the pool automatically starts using the shared portion of the pool for within-CBS buffer allocation. The shared early detection slopes can assume more buffers that exist within the shared portion that may cause the early detection function to fail.

For the primary-path and secondary-path queues, the percentage is applied to a single queue for each path.

The no form of this command restores the path queues default CBS value.

This command enters the context to configure queue drop-tail parameters.

This command enters the context to configure the queue low drop-tail parameters. The low drop-tail defines the queue depth beyond which out-of-profile packets are not accepted into the queue and are discarded.

This command overrides the default percentage value used to determine the low drop-tail value for the queue. By default, 10 percent of the queue depth is reserved for high congestion priority traffic. When specified, the percent-reduction-from-mbs percentage value is applied to the queues’ MBS threshold. The resulting value is subtracted from the MBS to derive the low drop-tail threshold maintained by the queue. The low drop-tail threshold defines the point at which all low-congestion priority packets destined for the queue are discarded based on queue depth. Low- and high-congestion priority is derived from the multicast records preference value compared to the record’s bundle priority threshold.

The no form of this command restores the default value.

This command configures the override for the default Maximum Buffer Size (MBS) for each individual path’s queue. The queues MBS threshold defines the point at which all packets destined for the queue are discarded based on queue depth. The defined threshold also provides context for the queues drop-tail parameter.

The mbs percent-of-pool parameter is defined as a percentage of the total pool size. The system allows the sum of all MBS values to equal more than 100% allowing for oversubscription of the pool.

For the primary-path and secondary-path queues, the mbs percent is applied to a single queue for each path.

The no form of this command is used to restore the path queues default MBS value.

This command is configures the percentage of bandwidth decrease that must occur to reset the dynamic bandwidth monitoring function for a multicast channel. When a channel is configured to use the ingress dynamic bandwidth as the in-use bandwidth for ingress multicast path management, the system maintains a sliding window in time that defines how long the last highest bandwidth value associated with the channel should be used. The sliding window duration is derived from the channels bw-activity dynamic falling-delay parameter within the multicast information policy. Each time the system detects a current bandwidth for a channel that is equal to or greater than the current highest bandwidth for the channel, the sliding window is reset and the highest value is used when managing the ingress multicast paths. If the system does not detect a higher or equal bandwidth value for the channel within the window period, the system resets the sliding window and uses the next highest rate seen during the duration of the window period. In this way, the system delays relinquishing bandwidth for a dynamic bandwidth channel for a configurable period. If a momentary fluctuation (decrease) in ingress bandwidth occurs, the system ignores the bandwidth change.

While this is useful for momentary fluctuations in bandwidth, it may be desirable to react faster when the current bandwidth monitored for a channel drops significantly relative to the currently in-use bandwidth. When the bandwidth decrease is equal to or greater than the falling-percent-reset value, the system immediately stops using the highest bandwidth and starts using the current bandwidth while resetting the sliding window.

If falling-percent-reset is set to 50%, when the current ingress dynamic bandwidth is 50% of the current in-use highest bandwidth, the system immediately uses the current dynamic ingress bandwidth as the highest bandwidth for the channel.

By default, the falling-percent-reset is 50% when a new bandwidth policy is created. The default bandwidth policy also has a hard configured value of 50%. Setting falling-percent-reset to 100 is equivalent to specifying no falling-percent-reset.

The no form of this command restores the default value of 50%.

This command configures the ingress multicast path management buffer pool. The pool is used by the primary and secondary path queues through which all ingress managed multicast traffic must flow. The parameters may be used to configure the size of the pool relative to the total ingress buffer space, the amount of reserved CBS buffers within the pool and the slope policy used to manage early congestion detection functions in the shared portion of the pool.

Care should be taken when managing the buffer pool space as changes to the systems buffer pool behavior can have negative effects on multicast and unicast forwarding.

Sizing the Pool

The percent-of-total command defines how much of the total ingress buffer pool space for the MDA is dedicated for multicast channels managed by the bandwidth policy. Since multicast typically has a higher scheduling priority through the switch fabric, the buffer pool does not need to be large. By default, the system reserves 10% of the buffers on the ingress side of the MDA once multicast path management is enabled.

Reserved CBS Portion of the Pool

The multicast pool is divided into two portions; reserved and shared. The reserved portion is used by the multicast path queues until they cross there individual CBS thresholds. Since the CBS thresholds are configured as percentages and the percentages can oversubscribe the reserved portion of the pool, it is possible for some of the queues CBS buffer allocation to be met by the shared portion of the pool. By default, 50% of the pool is defined as reserved. This may be changed using the resv-cbs percentage parameter.

Shared Portion WRED Slopes

The shared portion of the buffer pool is used by queues that have crossed over their CBS thresholds. Since the total MBS values for the multicast path queues may oversubscribe the pool size, a buffer congestion control mechanism is supported within the pool in the form of two WRED slopes. The slope-policy parameter defines how the slopes are configured and whether they are activated. Each packet entering a path queue is defined as high or low priority within the queue based on the channel’s preference value relative to the cong-priority-threshold command. When getting a shared buffer of a high priority packet, the high WRED slope is used. Low priority packets use the low WRED slope.

The no form of this command returns the managed multicast path pool to its default settings.

This command configures a multicast information policy. Multicast information policies are used to manage parameters associated with Layer 2 and Layer 3 multicast records. Multiple features use the configured information within the policy. The multicast ingress path manager uses the policy to decide the inactive and active state behavior for each multicast record using the ingress paths to the switch fabric. The system’s multicast ECMP join decisions are influenced by the channel information contained within the policy.

Multicast Bundles:

A multicast information policy consists of one or multiple named bundles. Multicast streams are mapped to a bundle based on matching the destination address of the multicast stream to configured channel ranges defined within the bundles. Each policy has a bundle named ‘default’ that is used when a destination address does not fall within any of the configured channel ranges.

Each bundle has a set of default parameters used as the starting point for multicast channels matching the bundle. The default parameters may be overridden by optional exception parameters defined under each channel range. Further optional parameter overrides are possible under explicit source address contexts within each channel range.

Default Multicast Information Policy

A multicast information policy always exists with the name ‘default’ and cannot be edited or deleted. The following parameters are contained in the default multicast information policy:

The default multicast information policy is applied to all VPLS and VPRN services and all routing contexts until an explicitly defined multicast information policy has been mapped.

Explicit Multicast Information Policy Associations

Each VPLS service and each routing context (including VPRN routing contexts) supports an explicit association with an pre-existing multicast information policy. The policy may need to be unique per service or routing context since that each context has its own multicast address space. The same multicast channels may be and most likely be used for completely different multicast streams and applications in each forwarding context.

Interaction with Ingress Multicast Path Management

When ingress multicast path management is enabled on an MDA, the system automatically creates a bandwidth manager context that manages the multicast path bandwidth into the switch fabric used by the ingress ports on the MDA. As routing or snooping protocols generate Layer 2 or Layer 3 multicast FIB records that are populated on the MDA’s forwarding plane, they are processed though the multicast information policy that is associated with the service or routing context associated with the record. The policy returns the following information for the record to be used by the ingress bandwidth manager:

Interaction with Multicast ECMP Optimization

The multicast information policy is used by the multicast ECMP optimization function to derive each channels administrative bandwidth. The ECMP function tallies all bandwidth information for channels joined and attempts to equalize the load between the various paths to the sender. The multicast information policy returns the following information to the ECMP path manager:

This command overrides the default multicast information policy on a VPLS or routing context. When the policy association is changed, all multicast channels in the service or routing context must be reevaluated.

If a multicast information policy is not explicitly associated with the VPLS service or routing context, the default multicast information policy is used when ingress multicast path management is enabled.

While a multicast information policy is associated with a service or routing context, the policy cannot be deleted from the system.

The no form of this command removes an explicit multicast information policy from the VPLS or routing context and restores the default multicast information policy.

This command creates or edits channel bundles within a multicast information policy. Bundles are used for two main purposes. First, bundles are used by the multicast CAC function to group multicast channels into a common bandwidth context. The CAC function limits the ability for downstream nodes to join multicast channels based on the egress interfaces ability to handle the multicast traffic. Bundling allows multicast channels with common preference or application to be managed into a certain percentage of the available bandwidth.

The second function of bundles is to provide a simple provisioning mechanism. Each bundle within a multicast information policy has a set of default channel parameters. If each channel provisioned in to the bundle can use the default parameters for the bundle, the provisioning and configuration storage requirements are minimized.

Up to 31 explicit bundles may be defined within a multicast information policy (32 including the default bundle).

Once a bundle is created, the default channel parameters should be configured and the individual channel ranges should be defined. Within each channel range, override parameters may be defined that override the default channel parameters. Further overrides are supported within the channel range based on explicit source overrides.

A bundle can be deleted at any time (except for the default bundle). When a bundle is deleted, all configuration information within the bundle is removed including multicast channel ranges. Any multicast records using the bundle should be reevaluated. Multicast CAC and ECMP managers should also be updated.

Default Bundle

Each multicast information policy contains a bundle named default. The default bundle cannot be deleted. Any multicast channel that fails to match a channel range within an explicit bundle is automatically associated with the default bundle.

The no form of this command removes a bundle from the multicast information policy. The default bundle cannot be removed from the policy.

This command defines explicit channels or channel ranges that are associated with the containing bundle. A channel or channel range is defined by their destination IP addresses. A channel may be defined using either IPv4 or IPv6 addresses. If a channel range is being defined, both the start and ending addresses must be the same type.

A specific channel may only be defined within a single channel or channel range within the multicast information policy. A defined channel range cannot overlap with an existing channel range.

If a channel range is to be shortened, extended, split or moved to another bundle, it must first be removed from its existing bundle.

Each specified channel range creates a containing context for any override parameters for the channel range. By default, no override parameters exist.

The no form of this command removes the specified multicast channel from the containing bundle.

This command specifies an administrative bandwidth for multicast channels. The specified bandwidth rate can be used by the multicast ingress path manger, multicast CAC manager or multicast ECMP manager.

The kbps value is closely tied to the bw-activity command. When the bw-activity command is set to use-admin-bw, the multicast ingress path manager uses the configured administrative bandwidth value as the managed ingress bandwidth. The admin-bw value must be defined for the bw-activity use-admin-bw command to succeed. Once the bw-activity command is set to use the admin-bw value, the value cannot be set to 0 and the no admin-bw command fails. Setting the bw-activity command to dynamic (the default setting), breaks the association between the commands.

The no form of this command restores the default value for admin-bw. If the command is executed in the channel context, the channels administrative bandwidth value is set to null. If the command is executed in the source-override context, the source override administrative bandwidth value is set to null.

This command defines how the multicast ingress path manager determines the amount of bandwidth required by a multicast channel. The default setting is dynamic which causes the bandwidth manager to use the bandwidth policies dynamic rate table entries to determine the current rate. The alternative setting is use-admin-bw which causes the bandwidth manager to use the configured admin-bw associated with the channel. The use-admin-bw setting also requires an active and inactive threshold to be defined which allows the bandwidth manager to determine when the channel is actively using ingress path bandwidth and when the channel is idle.

The use-admin-bw setting requires that the channel be configured with an admin-bw value that is not equal to 0 in the same context as the bw-activity command using the setting. Once a context has use-admin-bw configured, the context’s admin-bw value cannot be set to 0 and the no admin-bw command fails.

This command also supports an optional black-hole-rate kbps command that defines at which current rate a channel should be placed in the black-hole state. This is intended to provide a protection mechanism against multicast channels that exceed a reasonable rate and cause outages in other channels.

The no form of this command restores the default bandwidth activity monitoring setting (dynamic or null depending on the context).

This command defines an explicit ingress switch fabric multicast path assigned to a multicast channel. When defined, the channel is setup with the explicit path as its inactive path. When an explicit path is not defined, all multicast channels are initialized on the secondary path and when they start to consume bandwidth, they are moved to the appropriate path based on the channel attributes and path limitations. Explicit path channels are not allowed to move from their defined path.

The explicit-sf-path command in the bundle context defines the initial path for all channels associated with the bundle unless the channel has an overriding explicit-sw-path defined in the channel context. The channel context may also be overridden by the explicit-sf-path command in the source-override context. The channel and source-override explicit-sf-path settings default to null (undefined) and have no effect unless explicitly set.

The no form of this command restores default path association behavior (dynamic or null depending on the context).

This command configures the keepalive timer override. The PIM (S,G) Keepalive Timer (KAT) is used to maintain the (S,G) state when (S,G) join is not received. Expiry of the KAT causes the (S,G) entry to be removed.

The KAT override configuration is performed with a multicast information policy, which must be applied to the related PIM routing instance. When a KAT override is configured under a channel (a group or a group range), it applies to all (S,G) entries that fall under it, except when the source-override is configured and a KAT override is also configured under the source-override. In this scenario, the specific KAT override must be used for the (S,G) entries that fall under the source-override, while other (S,G) entries under the bundle use the KAT override configured under the channel.

This command sets the relative preference level for multicast channels. The preference of a channel specifies its relative importance over other multicast channels. Eight levels of preference are supported; 0 through 7. Preference value 7 indicates the highest preference level.

When the multicast ingress path manager is congested on one or more of the switch fabric multicast paths, it uses the preference values associated with each multicast record to determine which records are allowed on the path and which records be placed in a black-hole state.

The preference value is also compared to the bundles cong-priority-threshold setting to determine the congestion priority of the channel. The result also dictates the channels multicast CAC class level (high or low). When the channels preference value is less than the congestion priority threshold, it is considered to have a congestion priority and CAC class value equal to low. When the channels preference value is equal to or greater than the threshold, it is considered to have a congestion priority and a CAC class value equal to high.

The preference value is also compared to the bundles ecmp-opt-threshold setting to determine whether the channel is eligible for ECMP path dynamic optimization. If the preference value is equal to or less than the threshold, the channel may be optimized. If the preference value is greater than the threshold, the channel will not be dynamically optimized.

The preference command may be executed in three contexts; bundle, channel and source-override. The bundle default preference value is 0. The channel and source-override preference settings are considered overrides to the bundle setting and have a default value of null (undefined).

The no form of this command restores the default preference value (0 or null depending on the context).

This command allows the user to define a bundle in the multicast-info-policy and specify channels in the bundle that must be received from the primary tunnel interface associated with an RSVP P2MP LSP. The multicast info policy is applied to the base router instance.

The egress LER can accept multicast packets via two different methods. The regular RPF check on unlabeled IP multicast packets, which is based on routing table lookup. The static assignment which specifies the receiving of a multicast group <*,G> or a specific <S,G> from a primary tunnel-interface associated with an RSVP P2MP LSP.

One or more primary tunnel interfaces in the base router instance can be configured. That is, the user can specify to receive different multicast groups, <*,G> or specific <S,G>, from different P2MP LSPs. This assumes that there are static joins configured for the same multicast groups at the ingress LER to forward over a tunnel interface associated with the same P2MP LSP.

At any given time, packets of the same multicast group can be accepted from either the primary tunnel interface associated with a P2MP LSP or from a PIM interface. These are mutually exclusive options. As soon as a multicast group is configured against a primary tunnel interface in the multicast info policy, it is blocked from other PIM interfaces.

A multicast packet received on a tunnel interface associated with a P2MP LSP can be forwarded over a PIM or IGMP interface which can be an IES interface, a spoke SDP terminated IES interface, or a network interface.

The no form of this command removes the static RPF check.

This command defines a multicast channel parameter override context for a specific multicast sender within the channel range. The specified senders IP address must be of the same type (IPv4 or IPv6) as the containing channel range.

The no form of this command removes the specified sender override context from the channel range.

This command defines the preference level threshold where records change from low congestion priority to high congestion priority. Congestion priority is used by the ingress multicast path queues to map packets entering the queue to either the low drop-tail or the MBS drop-tail threshold. If congestion occurs on the queue, the queue depth increases. As the queue depth increases beyond the low drop-tail, packets with low priority congestion priority are discarded. This leaves room in the queue for packets with high congestion priority until the queue reaches the MBS threshold.

The default congestion priority threshold is 4. This means that multicast channels with a preference level of 0 to 3 are treated as having low congestion priority and channels with preference level of 4 to 7 are treated as having a high congestion priority. The cong-priority-threshold command can be used to change the default threshold. Any multicast channel with a preference equal to or higher than the configured threshold is treated with high congestion priority.

The cong-priority-threshold value is also used by the multicast CAC manager to derive the class of a channel matched by the multicast information policy. Channels with a preference less than the configured threshold are treated as low class and channels with a preference equal to or greater than the threshold is treated as high class.

Changing the cong-priority-threshold value causes all channels congestion priority to be reevaluated. Both the ingress multicast path managers and multicast CAC managers must be updated.

The no form of this command restores the default congestion priority preference threshold value.

This command defines the preference level threshold where multicast ECMP path management can dynamically optimize channels based on topology or bandwidth events. If the channels preference is equal to or less than the ecmp-opt-threshold, ECMP can move the channel between ECMP paths when bandwidth distribution events happen. Channels with a preference level higher than the threshold are moved during these events.

The default ECMP optimization limit threshold is 7. This means that multicast channels with a preference level of 0 to 7 (all channels) are allowed to move between ECMP paths. The ecmp-opt-threshold command can be used to change the default threshold.

Changing the threshold causes all channels ECMP optimization eligibility to be reevaluated.

The no form of this command restores the default ECMP optimization preference threshold value.

This command enables multicast balancing of traffic over ECMP links considering multicast bandwidth. When enabled, every multicast stream that needs to be forwarded over an ECMP link is evaluated for the total multicast utilization currently using the ECMP interface in question.

Note: A given interface can be shared between multiple (partially overlapping) ECMP sets. This is taken into consideration and a complete balance is attempted.

ECMP load balancing helps to avoid loss of unicast traffic over ECMP links as it loads balance over ECMP links and if multicast is not balanced then it is possible that a given link does not have enough bandwidth to pass its allotted unicast traffic portion.

To achieve a proper balance, multicast groups and their bandwidth should be configured in the config mcast-management context.

If the bandwidth is not configured, then the default value applies, and for ECMP load balancing, the net effect is that the balance achieved reflects a balance of the number of multicast groups traversing over the ECMP link. The bandwidth used in this policy is the configured value, not the actual bandwidth.

If mc-ecmp-balance is enabled, a redistribution may be triggered whenever an interface is added to an ECMP link.

If mc-ecmp-balance is enabled, a period re-balance may be configured that re-optimizes the distribution as some multicast streams may have been removed from the ECMP link.

If mc-ecmp-balance is enabled, then a threshold (ecmp-opt-threshold) can be configured to avoid moving multicast streams where interruption should be avoided.

The ecmp-opt-threshold defines the preference level threshold where multicast ECMP path management can dynamically optimize channels based on topology or bandwidth events. If the channels preference is equal to or less than the ecmp-opt-threshold, ECMP can move the channel between ECMP paths when bandwidth distribution events happen. Channels with a preference level higher than the threshold are not moved during these events.

Changing the ecmp-opt-threshold causes all channels ECMP optimization eligibility to be reevaluated.

The no form of this command removes the re-balancing capability from the configuration.

This command defines a hold period that applies after an interface has been added to the ECMP link. It is also used periodically to rebalance if channels have been removed from the ECMP link.

If the ECMP interface has not changed in the hold period and if no multicast streams have been removed, then no action is taken when the timer triggers.

This parameter should be used to avoid excessive changes to the multicast distribution.

A rebalance will not occur to multicast streams that have a priority greater than the configured ecmp-opt-threshold.

The no form of this command reverts to default.

This command triggers an immediate rebalance, regardless if the hold timer has triggered or if any changes have occurred.

This command enables the context to configure multicast CAC policy parameters and constraints for this interface.

This command enables the context to configure MLD snooping parameters.

This command configures the multicast CAC policy name.

The no form of this command reverts to the default value.

This command configures the bandwidth for the interface's multicast CAC policy traffic. When disabled (no unconstrained-bw) there is no checking of bandwidth constraints on the interface level. When enabled and a policy is defined, enforcement is performed. The allocated bandwidth for optional channels should not exceed the unconstrained-bw minus the mandatory-bw and the mandatory channels must stay below the specified value for the mandatory-bw. After this interface check, the bundle checks are performed.

The no form of this command reverts to the default value.

This command creates or edits a VPLS instance. If the service-id does not exist, a context for the service is created. If the service-id exists, the context for editing the service is entered.

A VPLS service connects multiple customer sites together, acting as a zero-hop, Layer 2 switched domain. A VPLS is always a logical full mesh.

When a service is created, the create keyword must be specified if the create command is enabled in the environment context.

When a service is created, the customer keyword and customer-id must be specified and associated the service with a customer. The customer-id must already exist, having been created using the customer command in the service context. Once a service has been created with a customer association, it is not possible to edit the customer association. The service must be deleted and recreated with a new customer association.

To create a management VPLS, the m-vpls keyword must be specified.

Once a service is created, the use of the customer customer-id is optional for navigating into the service configuration context. Attempting to edit a service with the incorrect customer-id specified results in an error.

More than one VPLS service may be created for a single customer ID.

By default, no VPLS instances exist until they are explicitly created.

The no form of this command deletes the VPLS service instance with the specified service-id. The service cannot be deleted until all SAPs and SDPs defined within the service ID have been shut down and deleted, and the service has been shut down.

This command enables the IGMP snooping context.

This command enables the context to configure Multicast VPLS Registration (MVR) parameters.

Identifies filter policy of multicast groups to be applied to this MVR VPLS. The sources of the multicast traffic must be a member of the MVR VPLS.

The no form of this command removes the MVR policy association from the VPLS.

If the send-queries command is enabled, this command specifies the interval between two consecutive general queries sent by the system on this SAP or SDP.

The configured query interval must be greater than the configured query response interval.

If send-queries is not enabled on this SAP or SDP, the configured query interval value is ignored.

The no form of this command reverts to the default value.

If the send-queries command is enabled, this parameter specifies the maximum response time advertised in IGMPv2 or IGMPv3 queries.

The configured query response interval must be smaller than the configured query interval.

If send-queries is not enabled on this SAP or SDP, the configured query response interval value is ignored.

The no form of this command reverts to the default value.

This parameters specifies the source IP address used when generating IGMP reports. According the IGMPv3 standard, a zero source address is allowed in sending IGMP reports. However, for interoperability with some multicast routers, the source IP address of IGMP group reports can be configured using this command.

The no form of this command reverts to the default value.

This command configures the IP source address used in IGMP or MLD queries.

The no form of this command removes the IP address from this configuration.

If the send-queries command is enabled, this parameter allows tuning for the expected packet loss on a SAP or SDP and is comparable to a retry count. If this SAP or SDP is expected to experience high packet loss, this parameter may be increased. IGMP snooping on this SAP or SDP is robust to packet losses.

If send-queries is not enabled, this parameter is ignored.

The no form of this command reverts to the default value.

This command specifies the value to send logs and traps when the threshold is reached.

The no form of this command reverts to the default.

This command specifies the value to send logs and traps when the threshold is reached.

The no form of this command reverts to the default.

This command specifies the maximum number of MAC entries in the forwarding database (FDB) for both learned and static MAC addresses for the VPLS instance.

The no form of this command returns the maximum FDB table size to its default.

This command specifies the multicast FIB high watermark. When the percentage filling level of the multicast FIB exceeds the configured value, a trap is generated and a log entry is added.

The no form of this command reverts to the default.

This command specifies the multicast FIB low watermark. When the percentage filling level of the multicast FIB drops below the configured value, the corresponding trap is cleared and a log entry is added.

The no form of this command reverts to the default.

This command specifies the maximum number of (s,g) entries in the multicast forwarding database (MFIB) for this VPLS instance.

When a table size limit is set on the MFIB of a service which is lower than the current number of dynamic entries present in the MFIB then the number of entries remains above the limit.

The no form of this command removes the configured maximum MFIB table size.

This command enables fast leave.

When IGMP fast leave processing is enabled, the 7450 ESS or 7750 SR immediately removes a SAP or SDP from the IP multicast group when it detects an IGMP leave message on that SAP or SDP. Fast leave processing allows the switch to remove a SAP or SDP that sends a leave message from the forwarding table without first sending out group-specific queries to the SAP or SDP, which speeds up the process of changing channels.

Fast leave should only be enabled when there is a single receiver present on the SAP or SDP.

When fast leave is enabled, the configured last-member-query-interval value is ignored.

This command specifies the import routing policy to be used for IGMP packets to be used on this SAP or SDP. Only a single policy can be imported on a SAP at any time.

The no form of this command removes the policy association from the SAP or SDP.

This command configures the maximum response time used in group-specific queries sent in response to 'leave' messages, and is also the amount of time between two consecutive group-specific queries. This value may be tuned to modify the leave latency of the network. A reduced value results in reduced time to detect the loss of the last member of a group.

The configured last-member-query-interval is ignored when fast leave is enabled on the SAP or SDP.

The no form of this command reverts to the default value.

This command defines the maximum number of multicast groups that can be joined on this SAP or SDP. If the 7450 ESS or 7750 SR receives an IGMP join message that would exceed the configured number of groups, the request is ignored.

The no form of this command reverts to the default value.

This command specifies whether a multicast router is attached behind this SAP or SDP.

Configuring a SAP as an mrouter-port has two effects. First, all multicast traffic received on another SAP or SDP is copied to this SAP or SDP. Second, IGMP reports generated by the system because of joining or leaving a multicast group, are sent to this SAP or SDP.

If two multicast routers exist in the network, one of them becomes the active querier. While the other multicast router (non-querier) stops sending IGMP queries, it should still receive reports to keep its multicast trees up to date. To support this, mrouter-port should be enabled on all SAPs or SDPs connecting to a multicast router.

Note: The IGMP version to be used for the reports (v1, v2 or v3) can only be determined after an initial query has been received. Until this query is received, no reports are sent on the SAP or spoke SDP, even if mrouter-port is enabled.

If the send-queries command is enabled on this SAP or spoke SDP, the mrouter-port parameter cannot be set.

The no form of this command reverts to the default.

This command configures the VPLS from which multicast traffic is copied upon receipt of an IGMP join request.

IGMP snooping must be enabled on the MVR VPLS.

In some situations, the multicast traffic should not be copied from the MVR VPLS to the SAP on which the IGMP message was received (standard MVR behavior) but to another SAP.

This command configures the SAP to which the multicast data needs to be copied.

The no form of this command reverts to the default value.

This command specifies whether to send IGMP general query messages on the SAP or SDP.

If mrouter-port is enabled on this SAP or spoke SDP, the send-queries command parameter cannot be set.

The no form of this command disables the IGMP general query messages.

This command enables the context to configure static group addresses. Static group addresses can be configured on a SAP or SDP. When present, either as a (*, g) or a (s,g) entry, multicast packets matching the configuration are forwarded even if no join message was registered for the specific group.

This command adds a static multicast group either as a (*, g) or as one or more (s,g) records. When a static IGMP group is added, multicast data for that (*,g) or (s,g) is forwarded to the specific SAP or SDP without receiving any membership report from a host.

This command adds a static (s,g) entry to allow multicast traffic for the corresponding multicast group from that specific source. For the same multicast group, more than one source can be specified.

Static (s,g) entries cannot be entered when a starg is already created.

The no form of this command removes the source IP address from this configuration.

This command adds a static (*,g) entry to allow multicast traffic for the corresponding multicast group from any source. This command can only be enabled if no existing source addresses for this group are specified.

The no form of this command reverts to the default.

This command enables the context to configure multicast plane bandwidth parameters. The chassis-level CLI node contains the multicast plane replication limit for each switch fabric multicast plane.

The chassis-level node always exists and contains the configuration command to define the total replication rates for primary and secondary associated ingress paths for each switch fabric multicast plane.

This command enables ingress Multicast Path Management (IMPM) from monitoring PIM and IGMP.

The no form of this command disables the IMPM monitoring.

This command enables the context to configure multicast plane bandwidth parameters. This CLI node contains the configuration of the overall multicast (primary plus secondary) and specific secondary rate limits for each switch fabric multicast plane.

This command configures the primary and secondary multicast plane capacities used when the full complement of possible switch fabrics in the system is not up (at least one possible switch fabric is not provisioned or is down). The rates are defined as a percentage of the total multicast plane capacity which is configured using the total-capacity command.

The no form of this command reverts to the default values.

This command configures the primary and secondary multicast plane capacities used when the full complement of possible switch fabrics in the system are up. The rates are defined as a percentage of the total multicast plane capacity which is configured using the total-capacity command.

The no form of this command reverts to the default values.

This command configures the total multicast plane capacity supported individually by all switch fabric multicast planes.

The multicast plane capacity is determined based on the provisioned line cards and switch fabrics in the chassis.

The no form of this command reverts to the default.

This command specifies whether initially inactive multicast records use the IOM default secondary multicast path or not. When enabled, the system redistributes newly populated inactive records among all available IOM multicast paths and multicast switch fabric planes. When disabled, the system continues to set all initially inactive multicast records to use the IOM default secondary multicast path.

The no form of this command reverts to the default.

This command creates the context to configure actions to take for routes matching a route policy statement entry.

This command is required and must be entered for the entry to be active.

Any route policy entry without the action command is considered incomplete and is inactive.

The no form of this command deletes the action context from the entry.

This command configures the interface where to redirect IGMP multicast traffic to.

This command enables the context to configure IGMP (or MLD) interface parameters on the multicast redirect interface.

This command disables router alert checking for IGMP/MLD messages received on this interface.

The no form of this command enables router alert checking.

This command configures the query interval when the group interface is configured with no sub-hosts-only. If nothing is configured, by default, the query-interval takes the value defined in the config>router>igmp (or mld) context or in the config>service>vprn>igmp (or mld) context.

The no form of this command reverts to the default value.

This command configures the frequency at which the querier router sends a group-specific query messages, including the messages sent in response to leave-group messages and is only applicable when the group interface is configured with the no sub-hosts-only command. The shorter the interval, the faster the loss of the last listener of a group can be detected. If nothing is configured, by default, the query-last-listener-interval takes the value defined in the config>router>mld context or in the config>service>vprn>mld context.

The no form of this command reverts to the default value.

This command configures the frequency at which the querier router sends group-specific query messages, including the messages sent in response to leave-group messages and is only applicable when the group interface is configured with no sub-hosts-only. The shorter the interval, the faster the loss of the last member of a group can be detected. If nothing is configured, by default, the query-last-member-interval takes the value defined in the config>router>igmp context or in the config>service>vprn>igmp context.

The no form of this command reverts to the default value.

This command configures the query response interval on when the group interface is configured with the no sub-hosts-only command. If nothing is configured, by default, the query-response-interval takes the value defined in the config>router>igmp (or mld) context or in the config>service>vprn>igmp (or mld) context.

The no form of this command reverts to the default value.

This command enables access to the configuration of the forwarding planes on a card.

Commands can only be configured under card>fp if the hardware that the FP resides on (either a card or an XMA) is provisioned. Conversely, all commands under card>fp of the corresponding FPs are automatically removed when that hardware is unprovisioned.

This command enables access to the ingress fp CLI context.

This CLI node contains the forwarding plane settings for ingress multicast path management. Enter the node to configure the bandwidth-policy and the administrative state of ingress multicast path management.

This command is used to explicitly associate a bandwidth policy to a forwarding plane or MDA. The bandwidth policy defines the dynamic rate table and the multicast paths bandwidth and queuing parameters.

If a bandwidth policy is not explicitly associated with a forwarding plane or MDA, the default bandwidth policy is used when ingress multicast path management is enabled.

The no form of this command removes an explicit bandwidth policy from a forwarding plane or MDA and restores the default bandwidth policy.