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.

The shutdown command is used to disable ingress multicast path management for a forwarding plane or MDA. The default state is shutdown. When the no shutdown command is executed, ingress multicast path management is enabled and the system will evaluate all multicast channels on the MDA or forwarding plane based on the default or explicit bandwidth policy applied and multicast information policies associated with the channels.

The no form of the command is used to enable ingress multicast path management on the MDA or forwarding plane.

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 will create a Multicast Reporting Destination hierarchy in CLI under which parameters defining this destination can be specified. The destination refers to an external node that will collect and analyze IGMP events.

The Multicast Reporting Destination is associated with a name that each subscriber can reference in order to send the IGMP related events.

It can be also referenced in the Host Tracking Policy in case that IGMP events are related to Host Tracking feature.

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

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 will be allocated (if not already existent). The events will be 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 1400B, or the timer expiry, whichever comes first.

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

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 will forward the packet. When multicast path management has been enabled on an ingress forwarding plane, the multicast bandwidth manager adds a third path for ingress multicast forwarding (ancillary path) and changes the way multicast packets are mapped to the three paths. This new forwarding plane behavior only applies to Layer 2 snooped or Layer 3 routed IP multicast forwarding. VPLS broadcast and unknown or non-snooped flooding is not affected.

When multicast path management is enabled, the ingress forwarding plane allows IP multicast snooped or routed packets to be placed on to the three 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 ancillary path is the point-to-point bandwidth unused by switch fabric point-to-point traffic. 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 a number of 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 considered to be active and the system will then manage 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. Each path may be configured with a path-limit rate used to override a specific paths default rate. Also, forwarding on each path is managed though an ingress path queue. The queue default parameters may be overridden for each path.

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 MDA. The default policy cannot be deleted or edited.

The no form of the 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 will start 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 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 admin-bw-threshold 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 will be 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 for of the command restores the default threshold value of 10 Kbps.

This command enables the context to configure primary path parameters.

This command overrides the default path limit for the ancillary path, which is one of the three ingress multicast paths into the switch fabric.

The t2-paths CLI node contains the primary and secondary path CLI nodes for IOM-3s. The commands within this context are ignored when the policy is applied to an IOM-1 or IOM-2.

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 T2 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 insufficient for the amount of explicit secondary path managed traffic or the amount of best-effort multipoint non-managed queue traffic.

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

This command is used to individually override the default path limit for each of the three ingress multicast paths into the switch fabric on an IOM-1 or IOM-2. When the bandwidth policy is applied to an IOM-3, the path-limit commands are ignored. The configured path limit may be less than, equal to or greater than the terminating switch fabric multicast plane limit.

The system will not violate the configured path limit or the multicast plane limits. The system uses all bandwidth limits and record preferences when determining which records should be allowed on which path, which records should be moved and which records should be placed in the black-hole state.

Changing a paths bandwidth limit causes the system to immediately reevaluate each record on the path. For dynamic path records, this could cause records to be moved to other paths and records on other paths to be placed in the black-hole state.

Changing a path-limit value within the bandwidth policy affects all MDAs where the policy is applied. The policy derived path limit may be overridden on each MDA using the primary-override, secondary-override or ancillary-override nodes in the MDA context.

The no form of the command returns the default path bandwidth limit for the ingress multicast path. The command has no effect for MDAs with a path override in effect for the given path.

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. In order 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 packets behavior.

Note: Any ingress scheduling policy functions attempting to manage the service or network multicast queues will only be able to read the statistics of the multicast queues and will not be 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 will be preformed 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 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 will be treated as congestion priority high. Multicast records with a preference lower than the defined class threshold will be treated as congestion priority low. Low priority packets use the low priority MBS 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. For the ancillary path, a single queue exists for each switch fabric destination. Ancillary path packets are replicated to each switch fabric destination. The replication process places a copy of the packet in the correct ancillary path queue that forwards to that destination.

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. On the shared early detection slopes could assume more buffers exist within the shared portion than actually do which 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. For the ancillary-path, multiple queues are required. The cbs percent-of-resv-cbs is divided between all ancillary path queues. For example, if primary is given 10 percent, the primary path queues CBS is set to 10% of the reserved portion of the buffer pool. If ancillary is given 50 percent and 10 ancillary path queues exist, each ancillary queue gets 5%. The number of path queues required depends on the available chassis slots and the provisioned IOM types. 7450 ESS-6 chassis have 4 slots, 7450 ESS-7 and 7750 SR-7 have 5 and the 7450 ESS-12 and 7750 SR-12 have 10. An IOM-1 or IOM-2 on a slot has two switch fabric destinations.

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

This command overrides the default percentage value used to determine the low priority MBS value for the queue. By default, 10 percent of the queue depth is reserved for high congestion priority traffic. When specified, the high-prior-only percentage value is applied to the queues MBS threshold. The resulting value is subtracted from the MBS to derive the low priority MBS threshold maintained by the queue. The low priority MBS threshold defines the point at which all low congestion priority packets destined for the queue will be 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 is used to override 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 will be discarded based on queue depth. The defined threshold also provides context for the queues high-prior-only 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. For the ancillary-path, multiple queues are required. The mbs percentage is divided between all ancillary path queues. For example, if primary is given 10 percent, the primary path queues MBS is set to 10% of the buffer pool. If ancillary is given 50 percent and 10 ancillary path queues exist, each ancillary queue gets 5%. The number of path queues required depends on the available chassis slots and the provisioned IOM types. ESS-6 chassis have 4 slots, ESS/SR-7 have 5 and ESS/SR-12 have 10. An IOM-1 or IOM-2 on a slot has two switch fabric destinations while an IOM-3 has one.

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

The falling-percent-reset command is used to configure 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 of time. 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 will immediately use the current dynamic ingress bandwidth as the highest bandwidth for the channel.

By default 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 the command restores the default value of 50%.

This command configures the ingress multicast path management buffer pool. The pool is used by the primary, secondary and ancillary 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 percents and the percents are allowed to 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 channels 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 the 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 due to the fact that each context has its own multicast address space. The same multicast channels may be and most likely will 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 L2 or L3 multicast FIB records that will be 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 will return 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 the command removes an explicit multicast information policy from the VPLS or routing context and restores the default multicast information policy.

The bundle command is used to create or edit 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 is able to 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 may be deleted at anytime (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 the 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 the command removes the specified multicast channel from the containing bundle.

This command specifies an administrative bandwidth for multicast channels.

The specified bandwidth rate may be used by the multicast ingress path manger, multicast CAC manager or multicast ECMP manager.

The admin-bw 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 will fail. Setting the bw-activity command to dynamic (the default setting), breaks the association between the commands.

The no form of the 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 will fail.

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 the command restores the default bandwidth activity monitoring setting (dynamic or null depending on the context).

This command defines the channels multicast CAC channel type, either mandatory or optional. The cac-type command is supported for future interaction with the egress multicast CAC manager policy. The multicast CAC manager always reserves egress bandwidth for mandatory channels within a bundle, while optional channels are only given bandwidth when a join is received.

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 the 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 an 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 will be allowed on the path and which records should 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 the 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 will be able to 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 will be able to 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 the 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 the 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 priority MBS (LP-MBS) or the MBS tail-drop threshold. In the event that congestion happens on the queue, the queue depth increases. As the queue depth increases beyond the low priority MBS, 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 will be treated as having low congestion priority and channels with preference level of 4 to 7 will be 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 will be 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 will be treated as low class and channels with a preference equal to or greater than the threshold will be 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 the command restores the default congestion priority preference threshold value.

This command defines the preference level threshold where multicast ECMP path management is allowed to dynamically optimize channels based on topology or bandwidth events. If the channels preference is equal to or less than the ecmp-opt-threshold, ECMP is allowed to move the channel between ECMP paths when bandwidth distribution events happen. Channels with a preference level higher than the threshold will not be 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) will be 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 the 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 will be evaluated for the sum 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 will load balance over ECMP links and if multicast is not balanced then it is possible that a given link does not have sufficient bandwidth to pass its allotted unicast traffic portion.

In order 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 the purpose of ECMP load balancing, the net effect will be 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 a 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 is used to define the preference level threshold where multicast ECMP path management is allowed to dynamically optimize channels based on topology or bandwidth events. If the channels preference is equal to or less than the ecmp-opt-threshold, ECMP is allowed to move the channel between ECMP paths when bandwidth distribution events happen. Channels with a preference level higher than the threshold will not be moved during these events.

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

The no form of the 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 will be 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 then the configured ecmp-opt-threshold.

The no form of the command reverts to default.

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

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 the command disables the IMPM monitoring.

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 the 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 the command reverts to the default values.

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

The no form of the 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.

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 will be considered incomplete and will be inactive.

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

This command enables IGMP (or MLD) on the multicast redirect interface.

This command disables router alert checking for IGMP/MLD messages received on this interface. The no form of the 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.

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.

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.

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 fp CLI node contains the multicast path management configuration commands for IOM-3 ingress multicast management. Ingress multicast management manages multicast switch fabric paths which are forwarding plane specific. On IOM-1 and IOM-2, each MDA has a dedicated forwarding plane and so have dedicated multicast paths to the switch fabric allowing the multicast management to be defined per MDA. IOM-3 has a single forwarding plane shared by two MDAs making the previous model of managing multicast at the MDA level problematic. The fp node has been added to simplify ingress multicast management on IOM-3.

In subsequent releases, the fp node will be moved to IOM-1 and IOM-2 and the multicast path management commands will be consistent for all IOM types. Other forwarding plane resource configuration commands (i.e. buffer pool management) are expected to also move to the fp node.

While IOM-3 only has a single forwarding plane, other IOMs that will use the node in the future will have multiple (i.e. IOM-1 and IOM-2). To accommodate multiple forwarding planes, each forwarding plane is assigned a number. The default forwarding plane is 1. When entering the fp node, if the forwarding plane number is omitted, the system will assume forwarding plane number 1. All show and save configuration output must include the forwarding plane number.

The ingress CLI node within the fp node contains the multicast path management configuration commands for IOM-3 ingress multicast management. For this release, on the bandwidth-policy command is supported within the ingress node.

The multicast-path-management CLI node contains the forwarding plane or MDA settings for ingress multicast path management. Enter the node to configure the bandwidth-policy, the individual path bandwidth overrides 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 the command removes an explicit bandwidth policy from a forwarding plane or MDA and restores the default bandwidth policy.

This command enables the context to configure MDA ingress multicast path-limit overrides.

The path override CLI nodes are not supported on IOM-3.

This command enables the context to configure MDA ingress multicast path-limit overrides.

The path override CLI nodes are not supported on IOM-3.

This command enables the context to configure MDA ingress multicast path-limit overrides.

The path-limit command is used to override the path limits contained in the bandwidth policy associated with the MDA. The path limits are used to give the upper limit that multicast channels may use on each path.

The path-limit commands are not supported on IOM-3.

The no form of the command removes a path limit override from an ingress multicast path and restore the path limit defined in the bandwidth policy associated with the MDA.