3.15. IP Multicast Command Reference

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 can be deleted.

Unlike other commands and parameters where the default state is not indicated in the configuration file, shutdown and no shutdown are always indicated in system-generated configuration files.

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

This command enables the Internet Group Management Protocol (IGMP) context. When the context is created, the IGMP protocol is enabled.

The Internet Group Management Protocol (IGMP) is used by IPv4 systems (hosts and routers) to report their IP multicast group memberships to neighboring multicast routers. An IP multicast router can be a member of one or more multicast groups, in which case it performs both the “multicast router” part of the protocol, which collects the membership information needed by its multicast routing protocol, and the “group member” part of the protocol, which informs itself and other neighboring multicast routers of its memberships.

The no form of the command disables the IGMP instance. To start or suspend execution of IGMP without affecting the configuration, use the no shutdown command.

This command enables the context to configure an IGMP interface. The interface is a local identifier of the network interface on which reception of the specified multicast address is to be enabled or disabled.

The no form of the command deletes the IGMP interface. The shutdown command in the config>router>igmp>interface context can be used to disable an interface without removing the configuration for the interface.

This command disables or enables router alert checking for IGMP messages received on the interface.

The no form of the command enables the IGMP router alert check option.

This command specifies the import route policy to be used for determining which membership reports are accepted by the router. Route policies are configured in the config>router>policy-options context (see the “Route Policies” section in the 7705 SAR Router Configuration Guide).

If an import policy is not specified, all the IGMP reports are accepted.

The no form of the command removes the policy association from the IGMP instance.

This command specifies the maximum number of groups for which IGMP can have local receiver information based on received IGMP reports on this interface. If this configuration is changed dynamically to a value lower than the currently accepted number of groups, the groups that are already accepted are not deleted. Only new groups will not be allowed.

The no version of the command removes the configured value and the maximum number of groups is not defined.

This command specifies the maximum number of group sources for which IGMP can have local receiver information based on received IGMP reports on this interface. If this configuration is changed dynamically to a value lower than the currently accepted number of group sources, the group sources that are already accepted are not deleted. Only new group sources will not be allowed.

The no version of the command removes the configured value and the maximum number of group sources is not defined.

This command enables the context to configure group ranges that are translated to SSM (S,G) entries. If the static entry needs to be created, it has to be translated from an IGMPv1 or IGMPv2 request to a Source-Specific Multicast (SSM) join message.

This command adds or removes SSM translate group range entries. The group range is not created until the grp-range>source command is used to configure the source address.

This command specifies the source IP address for the group range. Whenever a (*,G) report is received in the range specified by the grp-range start and end parameters, it is translated to an (S,G) report with the value of this object as the source address.

This command allows multicast forwarding out an interface without having received a dynamic join report on that interface. The specific multicast traffic to be forwarded is configured using the static>group and static>group>source commands.

This command adds a static multicast (S,G) group membership to an IPv4 interface. When IGMP static groups are enabled, data is forwarded to an interface without receiving membership reports from host members. A possible use for IGMP static groups is to test multicast forwarding in the absence of an IGMP host receiver.

The group command, in combination with the source command, is used to create a specific (S,G) static group entry.

This command specifies the source IPv4 address (S) for the static IGMP group being configured. Multicast traffic to the group (G) will be forwarded out the interface on which this static group is configured if the source address in the IPv4 header of the multicast packets matches S.

The source command, in combination with the group command, is used to create a specific (S,G) static group entry.

The no form of the command removes the source from the configuration.

This command enables subnet checking for IGMP messages received on this interface. All IGMP packets with a source address that is not in the local subnet are dropped.

This command specifies the IGMP version. If routers run different versions of IGMP, they will negotiate the lowest common version of IGMP that is supported by hosts on their subnet and operate in that version. For IGMP to function correctly, all routers on a LAN must be configured to run the same version of IGMP on that LAN.

For IGMPv3, a multicast router that is also a group member performs both parts of IGMPv3, receiving and responding to its own IGMP message transmissions as well as those of its neighbors.

This command specifies the frequency at which the querying router transmits general host-query messages. Host-query messages solicit group membership information and are sent to the all-systems multicast group address, 224.0.0.1.

This command configures the frequency at which the querying router sends group-specific query messages, including messages sent in response to leave-group messages. The shorter the interval, the faster the detection of the loss of the last member of a group.

This command specifies how long the querying router waits to receive a response to a host-query message from a host.

This command configures the robust count, which is the number of times the router will retry a query. The robust-count variable allows tuning for the expected packet loss on a subnet. If a subnet anticipates losses, the robust-count variable can be increased.

This command enables the context to configure Multicast Listener Discovery (MLD) parameters.

The no form of the command disables MLD.

This command enables the context to configure an MLD interface. The interface is a local identifier of the network interface on which reception of the specified multicast address is to be enabled or disabled.

The no form of the command deletes the MLD interface. The shutdown command in the config>router>mld>interface context can be used to disable an interface without removing the configuration for the interface.

This command enables or disables the router alert checking for MLD messages received on this interface.

The no form of the command enables the MLD router alert check option.

This command specifies the import route policy to be used for determining which membership reports are accepted by the router. Route policies are configured in the config>router>policy-options context.

If an import policy is not specified, all the MLD reports are accepted.

The no form of the command removes the policy association from the MLD instance.

This command specifies the maximum number of groups for which MLD can have local receiver information based on received MLD reports on this interface. If this configuration is changed dynamically to a value lower than the currently accepted number of groups, the groups that are already accepted are not deleted. Only new groups will not be allowed.

The no version of the command removes the configured value and the maximum number of groups is not defined.

This command specifies the frequency at which the querying router transmits general host-query messages. Host-query messages solicit group membership information and are sent to the all-systems multicast group address, 224.0.0.1.

This command configures the frequency at which the querying router sends group-specific query messages, including messages sent in response to leave-group messages. The shorter the interval, the faster the detection of the loss of the last member of a group.

This command specifies how long the querying router waits to receive a response to a host-query message from a host.

This command configures the robust count. The robust-count variable allows tuning for the expected packet loss on a subnet. If a subnet anticipates losses, the robust-count variable can be increased.

This command enables the context to configure group ranges that are translated to SSM (S,G) entries. If the static entry needs to be created, it has to be translated from an MLDv1 request to a Source-Specific Multicast (SSM) join message.

This command is used to configure group ranges that are translated to SSM (S,G) entries.

This command specifies the source IPv6 address for the group range. Whenever a (*,G) report is received in the range specified by grp-range start and end parameters, it is translated to an (S,G) report with the value of this object as the source address.

This command allows multicast forwarding out an interface without having received a dynamic join report on that interface. The specific multicast traffic to be forwarded is configured using the static>group and static>group>source commands.

This command adds a static multicast (S,G) group membership to an IPv6 interface. When MLD static groups are enabled, data is forwarded to an interface without receiving membership reports from host members. A possible use for MLD static groups is to test multicast forwarding in the absence of an MLD host receiver.

The no form of the command removes the IPv6 address from the configuration.

This command specifies the source IPv6 address (S) for the static MLD group being configured. Multicast traffic to the group (G) will be forwarded out the interface on which this static group is configured if the source address in the IPv6 header of the multicast packets matches S.

The source command, in combination with the group command, is used to create a specific (S,G) static group entry.

The no form of the command removes the source from the configuration.

This command specifies the MLD version. If routers run different versions of MLD, they will negotiate the lowest common version of MLD that is supported by hosts on their subnet and operate in that version. For MLD to function correctly, all routers on a LAN must be configured to run the same version of MLD on that LAN.

This command configures a Protocol Independent Multicast (PIM) instance.

PIM is used for multicast routing within the network. Devices in the network can receive the multicast feed requested and non-participating routers can be pruned. The 7705 SAR supports PIM Source-Specific Multicast (SSM) and PIM Sparse-Mode (SM).

The no form of the command deletes the PIM instance and removes all configuration parameters.

This command automatically creates or removes PIM interfaces. The ies, non-ies, and all options create a PIM interface with default PIM parameters when a new IP or IES interface is created manually. The none option removes any automatically created PIM interfaces that have not been modified manually in the PIM context. Existing manually created or modified PIM interfaces are not affected.

The default option for the apply-to command is none, so to activate its automatic behavior it must first be saved in the PIM configuration structure. Then, all subsequent commands either create new structures (in the case of IP or IES interface commands) or modify the default values created by the apply-to command (in the case of PIM interface commands).

For example, assume that the apply-to setting is none and that two manually created PIM interfaces already exist. If the apply-to setting is changed to ies, then the two manually created PIM interfaces remain unchanged but any newly created or modified IES interfaces will automatically create a corresponding PIM interface with default PIM values. Subsequently, if the apply-to command is changed back to none, then all PIM interfaces that were not manually created or modified are removed.

If a manually created or modified PIM interface is deleted, the interface will be recreated when (re)processing the apply-to command. If PIM is not required on a specific interface, then a config>router>pim>if>shutdown command should be executed.

This command specifies the import route policy to be used by PIM. Route policies are configured in the config>router>policy-options context. Up to five import policy names can be specified.

If an import policy is not specified, IGP routes are accepted by default.

The no form of the command removes the policy association from the instance.

This command creates a logical IP routing interface.

The no form of the command removes the IP interface and all the associated configurations.

This command configures the period for refreshes of PIM Assert messages on an interface.

The no form of the command removes the assert period from the configuration.

This command enables the use of IPv4 or IPv6 Bidirectional Forwarding Detection (BFD) to control the state of the associated protocol interface. By enabling BFD on a given protocol interface, the state of the protocol interface is tied to the state of the BFD session between the local node and the remote node. The parameters used for BFD are set via the BFD command under the IP interface.

The no form of this command removes BFD from the associated IGP protocol adjacency.

This command enables the checking of the router alert option in the bootstrap messages received on this interface.

This command configures the time interval between PIM Hello messages transmitted on this interface.

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

This command configures the multiplier used to determine the hold time for a PIM neighbor on this interface.

The hello-multiplier in conjunction with the hello-interval determines the hold time for a PIM neighbor.

The multiplier value is expressed in deci-units, so that (for example) 10 deci-units represents a multiplier of 1 and 35 deci-units represents a multiplier of 3.5. For example, if the hello-interval is 1 s and the hello-multiplier is 35 deci-units, then the calculated hold time (in seconds) is:

      hold time    =  (hello-interval * hello-multiplier) / 10                         =  (1 s * 35 deci-units) / 10                         =  3.5 s   

This command enables or disables instant PruneEcho for a PIM interface.

This command administratively disables or enables PIM operation for IPv4.

This command administratively disables or enables PIM operation for IPv6.

This command specifies the maximum number of groups for which PIM can have local receiver information based on received PIM reports on this interface. If this configuration is changed dynamically to a value lower than the currently accepted number of groups, the groups that are already accepted are not deleted. Only new groups will not be allowed. This command is applicable for IPv4 and IPv6.

The no version of the command removes the configured value and the maximum number of groups is not defined.

This command configures how traffic from directly attached multicast sources should be treated on broadcast interfaces. It can also be used to treat all traffic received on an interface as traffic coming from a directly attached multicast source. This is particularly useful if a multicast source is connected to a point-to-point or unnumbered interface.

This command sets the priority value that is used to elect the designated router (DR). The DR election priority is a 32-bit unsigned number and the router with numerically largest dr-priority value is always the preferred DR.

The no form of the command restores the default values.

This command enables sticky-dr operation on this interface. When enabled, the priority in PIM Hello messages sent on this interface when elected as the designated router (DR) will be modified to the value configured in dr-priority. This is done to avoid the delays in forwarding caused by DR recovery, when switching back to the old DR on a LAN when it comes back up.

By enabling sticky-dr on this interface, it will continue to act as the DR for the LAN even after the old DR comes back up.

The no form of the command disables sticky-dr operation on this interface.

This command enables three-way hello. By default, three-way hello is disabled on all interfaces and the standard two-way hello is supported.

This command sets the T-bit in the LAN Prune Delay option of the Hello Message. This indicates the router’s capability to enable join message suppression. This capability allows for upstream routers to explicitly track Join memberships.

This command specifies whether the router should ignore the designated router state and attract traffic even when it is not the designated router.

An operator can configure an interface (router or IES) to IGMP for PIM. The interface IGMP state will be synchronized to the backup node if it is associated with the redundant peer port. The interface can be configured to use PIM, which will cause multicast streams to be sent to the elected DR only. The DR will also be the router sending traffic to the DSLAM. Since it may be required to attract traffic to both routers, a non-dr-attract-traffic flag can be used in the PIM context to have the router ignore the DR state and attract traffic if it is not the DR. While using this flag, the router may not send the stream down to the DSLAM while it is not the DR.

When enabled, the designated router state is ignored. When disabled, the designated router value is honored.

This command provides access to the bootstrap import and export policy commands.

The 7705 SAR cannot become a Rendezvous Point (RP); however, it may be present in a network that has one or more RPs. The 7705 SAR handles Register messages by allowing the configuration of policies that will drop incoming Register messages silently, or send register-stop messages if the policy action is set to “accept” or if no policy action is assigned.

This command configures a PIM anycast protocol instance for the RP being configured. Anycast enables fast convergence when a PIM RP router fails by allowing receivers and sources to rendezvous at the closest RP.

The no form of the command removes the anycast instance from the configuration.

This command configures a peer in the anycast-RP set. The ip-address identifies the address used by the other node as the RP candidate address for the same multicast group address range as configured on this node.

Caution: This is a manual procedure. Caution should be taken to produce a consistent configuration of an RP set for a multicast group address range. The priority should be identical on each node and be a higher value than any other configured RP candidate that is not a member of this RP set.

Although there is no set maximum number of addresses that can be configured in an RP set, a maximum of 15 IP addresses is recommended.

The no form of the command removes an entry from the list.

This command enables auto-RP protocol in discovery mode. In discovery mode, RP-mapping and RP-candidate messages are received and forwarded to downstream nodes. RP-mapping messages are received locally to learn about the availability of RP nodes present in the network.

Either bsr-candidate for IPv4 or auto-rp-discovery can be configured; the two mechanisms cannot be enabled together.

The no form of the command disables auto-RP discovery.

This command applies export policies to the PIM configuration. The policies control the flow of bootstrap messages from the RP. Up to five policy names can be specified.

Bootstrap export policies are created using the config>router>policy-options>policy-statement command. For more information on configuring bootstrap policies, refer to the “Configuring Bootstrap Message Import and Export Policies” section of the 7705 SAR Router Configuration Guide.

This command applies import policies to the PIM configuration. The policies control the flow of bootstrap messages to the RP. Up to five policy names can be specified.

Bootstrap import policies are created using the config>router>policy-options>policy-statement command. For more information on configuring bootstrap policies, refer to the “Configuring Bootstrap Message Import and Export Policies” section of the 7705 SAR Router Configuration Guide.

This command enables the context to configure candidate bootstrap router (BSR) parameters.

Either bsr-candidate for IPv4 or auto-rp-discovery can be configured; the two mechanisms cannot be enabled together.

This command is used to configure the candidate BSR IP address. This address is for bootstrap router election.

This command is used to configure the length of the mask that is combined with the group address before the hash function is called. All groups with the same hash result will map to the same RP. For example, if the hash-mask-length value is 24, only the first 24 bits of the group addresses matter. This mechanism is used to map one group or multiple groups to an RP.

This command configures the bootstrap priority of the router. The RP is sometimes called the bootstrap router. The priority determines if the router is eligible to be a bootstrap router. In the case of a tie, the router with the highest IP address is elected to be the bootstrap router.

This command enables the context to configure the candidate rendezvous point (RP) parameters.

Routers use a set of available rendezvous points distributed in bootstrap messages to get the proper group-to-RP mapping. A set of routers within a domain are also configured as candidate RPs; typically, these will be the same routers that are configured as candidate BSRs.

Every multicast group has a shared tree through which receivers learn about new multicast sources and new receivers learn about all multicast sources. The RP is the root of this shared tree.

This command configures the local RP address. This address is sent in the RP candidate advertisements to the bootstrap router.

This command configures a range of addresses for the RP candidate group.

This command configures the length of time, in seconds, that neighbors should consider the sending router to be operationally up. A local RP cannot be configured on a logical router.

This command configures the candidate RP priority for becoming a rendezvous point (RP). This value is used to elect the RP for a group range.

This command enables the context to configure static rendezvous point (RP) addresses for a multicast group range.

Entries can be created or destroyed. If no IP addresses are configured in the config>router>pim>rp>static>address context, then the multicast group-to-RP mapping is derived from the RP-set messages received from the bootstrap router.

This command indicates the rendezvous point (RP) address that is used by the router for the range of multicast groups configured by the range command.

The command defines a range of multicast IP addresses for which an RP is applicable.

The no form of the command removes the address range.

This command changes the precedence of static RP over dynamically learned RP.

When enabled, the static group-to-RP mappings take precedence over the dynamically learned mappings.

This command configures the sequence of route tables used to find a Reverse Path Forwarding (RPF) interface for a particular multicast route.

By default, only the unicast route table is looked up to calculate the RPF interface towards the source/rendezvous point. However the operator can specify the following:

This command configures the sequence of route tables used to find a Reverse Path Forwarding (RPF) interface for a particular multicast route.

By default, only the unicast route table is looked up to calculate the RPF interface towards the source/rendezvous point. However the operator can specify the following:

This command configures the shortest path tree (SPT) switchover thresholds for group prefixes.

PIM-SM routers with directly connected routers receive multicast traffic initially on a shared tree rooted at the RP. When the traffic arrives on the shared tree and the source of the traffic is known, a switchover to the SPT rooted at the source is attempted.

For a group that falls in the range of a prefix configured in the table, the corresponding threshold value determines when the router should switch over from the shared tree to the source-specific tree. The switchover is attempted only if the traffic rate on the shared tree for the group exceeds the configured threshold.

If there is no matching prefix in the table, the default behavior is to switch over when the first packet is seen. If there are multiple prefixes matching a group, the most specific entry is used.

This command enables and disables the IPv4 and IPv6 SSM default ranges.

This command enables the context to configure an SSM group range.

This command configures the address ranges of the multicast groups for this router. When there are parameters present, the command configures the SSM group ranges for IPv6 addresses and netmasks.

This command enables a Multicast Source Discovery Protocol (MSDP) instance. When an MSDP instance is created, the protocol is enabled. To start or suspend execution of the MSDP protocol without affecting the configuration, use the [no] shutdown command.

For MSDP to function, at least one peer must be configured.

When MSDP is configured and started an appropriate event message is generated.

Before the no form of the command is executed, all sessions must be terminated and an appropriate event message will be generated.

When all peering sessions are terminated, an event message per peer is not required.

The no form of the command deletes the MSDP instance, removing all associated configuration parameters.

This option controls the maximum number of active source messages that will be accepted by Multicast Source Discovery Protocol (MSDP), effectively controlling the number of active sources that can be stored on the system.

The no form of this command reverts the number of source message limit to default operation.

This command limits the number of Multicast Source Discovery Protocol (MSDP) messages that are read from the TCP session because it is possible that an MSDP RP router may receive a large number of MSDP message packets in a particular source-active message.

After the number of MSDP packets (including source-active messages) defined by the threshold number have been processed, the rate of all other MSDP packets is rate limited. Messages from the TCP session are no longer accepted until the interval (seconds) has elapsed.

The no form of this command reverts this active-source limit to default operation.

This command configures a Message Digest 5 (MD5) authentication key to be used with a specific Multicast Source Discovery Protocol (MSDP) peering session. The authentication key must be configured per peer, therefore no global or group configuration is possible.

This command configures a rendezvous point (RP) using Multicast Source Discovery Protocol (MSDP) to encapsulate multicast data received in MSDP register messages inside forwarded MSDP source-active messages.

This command configures the use of the default peer mechanism, where a peer can be selected as the default Multicast Source Discovery Protocol (MSDP) peer. As a result, all source-active messages from the peer will be accepted without the usual peer reverse path forwarding (RPF) check.

The MSDP peer-RPF check is different from the normal multicast RPF checks. The peer-RPF check is used to stop source-active messages from looping. A router validates source-active messages originated from other routers in a deterministic fashion.

A set of rules is applied to validate received source-active messages, and the first rule that applies determines the peer-RPF neighbor. All source-active messages from other routers are rejected. The following rules are applied to source-active messages originating at router_S and received at router_R from router_N.

This command specifies the policies to export source-active state from the source-active list into Multicast Source Discovery Protocol (MSDP).

If multiple policy names are specified, the policies are evaluated in the order they are specified. The first policy that matches is applied. If multiple export commands are issued, the last command entered will override the previous command. A maximum of five policy names can be specified.

The no form of the command removes all policies from the configuration.

This command enables access to the context to create or modify a Multicast Source Discovery Protocol (MSDP) group. To configure multiple MSDP groups, include multiple group statements.

By default, the group’s options are inherited from the global MSDP options. To override the global options, group-specific options within the group statement can be configured.

If the group name provided is already configured then this command only provides the context to configure the options pertaining to this group.

If the group name provided is not already configured, then the group name must be created and the context to configure the parameters pertaining to the group should be provided.

For a group to be of use, at least one peer must be configured.

This command specifies the policies to import source-active state from Multicast Source Discovery Protocol (MSDP) into source-active list.

If multiple policy names are specified, the policies are evaluated in the order they are specified. The first policy that matches is applied. If multiple import commands are issued, the last command entered will override the previous command. A maximum of five policy names can be specified.

If you configure an import policy at the global level, each individual peer inherits the global policy.

If you configure an import policy at the group level, each individual peer in a group inherits the group’s policy.

If you configure an import policy at the peer level, then policy only applies to the peer where it is configured.

The no form of the command removes all policies from the configuration.

This command configures the local end of a Multicast Source Discovery Protocol (MSDP) session. For MSDP to function, at least one peer must be configured. When configuring a peer, you must include this local-address command to configure the local end of the MSDP session. This address must be present on the node and is used to validate incoming connections to the peer and to establish connections to the remote peer.

If the user enters this command, then the address provided is validated and will be used as the local address for MSDP peers from that point. If a subsequent local-address command is entered, it will replace the existing configuration and existing sessions will be terminated.

Similarly, when the no form of this command is entered, the existing local-address will be removed from the configuration and the existing sessions will be terminated.

Whenever a session is terminated, all information pertaining to and learned from that peer will be removed.

Whenever a new peering session is created or a peering session is lost, an event message should be generated.

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

This command configures groups of peers in a full mesh topology to limit excessive flooding of source-active messages to neighboring peers.

In a meshed configuration, all members of the group must have a peer connection with every other mesh group member. If this rule is not adhered to, then unpredictable results may occur.

This command configures peer parameters. Multicast Source Discovery Protocol (MSDP) must have at least one peer configured. A peer is defined by configuring a local-address that can be used by this node to set up a peering session and the address of a remote MSDP router, It is the address of this remote peer that is configured in this command and it identifies the remote MSDP router address.

After peer relationships are established, the MSDP peers exchange messages to advertise active multicast sources. It may be required to have multiple peering sessions in which case multiple peer statements should be included in the configurations.

By default, the options applied to a peer are inherited from the global or group-level. To override these inherited options, include peer-specific options within the peer statement.

If the peer address provided is already a configured peer, then this command only provides the context to configure the parameters pertaining to this peer.

If the peer address provided is not already a configured peer, then the peer instance must be created and the context to configure the parameters pertaining to this peer should be provided. In this case, the $ prompt is used, indicating that a new entity (peer) is being created.

The peer address provided will be validated and, if valid, will be used as the remote address for an MSDP peering session.

When the no form of this command is entered, the existing peering address is removed from the configuration and the existing session is terminated. Whenever a session is terminated, all source-active information pertaining to and learned from that peer is removed. Whenever a new peering session is created or a peering session is lost, an event message is generated.

At least one peer must be configured for MSDP to function.

This command configures the sequence of route tables used to find a Reverse Path Forwarding (RPF) interface for a particular multicast route.

By default, only the unicast route table is looked up to calculate RPF interface towards the source/rendezvous point. However, the operator can specify one of the following options:

This command configures the value for the SA entries in the cache. If these entries are not refreshed within the timeout value, they are removed from the cache. Normally, the entries are refreshed at least once a minute. But under high load with many of MSDP peers, the refresh cycle could be incomplete. A higher timeout value (more than 90) could be useful to prevent instabilities in the MSDP cache.

This command limits the number of active source messages the router accepts from sources in the specified address range.

If the prefix and mask provided is already configured then this command only provides the context to configure the parameters pertaining to this active source message filter.

If the prefix and mask provided is not already a configured, then the source node instance must be created and the context to configure the parameters pertaining to this node should be provided. In this case, the $ prompt indicates that a new entity (source) is being created.

The no form of this command removes the source-active rate limiter for this source address range.