This command controls whether the system floods GARP-requests / GARP-replies to the EVPN. The GARPs impacted by this command are identified by the sender's IP being equal to the target's IP and the MAC DA being broadcast.

The no form of the command only floods to local SAPs or binds but not to EVPN destinations.

Disabling this command is only recommended in networks where CEs are routers that are directly connected to the PEs. Networks using aggregation switches between the host/routers and the PEs should flood GARP messages in the EVPN to ensure that the remote caches are updated and the BGP does not miss the advertisement of these entries.

This command enables debugging for dynamic IPsec tunnels that terminate on the specified IPsec gateway.

The tunnel to be debugged can be specified by either its source address or source subnet. If a subnet is specified, the system will enable debugging for all tunnels with source addresses in the specified subnet.

This command configures the parameters to send the mirrored packets to a remote destination gateway. Once a gateway is created, no changes to the layer-3-encap type, router or direction-bit are allowed.

This command assigns a gateway IP address for the video interface within the VPLS service. Because VPLS is a Layer 2 service and the video interface is modeled like a host within the service, the video interface needs a gateway IP to send requests to devices outside of the VPLS subnet.

The no form of the command deletes the gateway IP address from the VPLS video interface.

This command generates RSA, DSA, or ECDSA private key or public key pairs at the specified location.

This command generates a PKCS#10 formatted certificate request by using a local existing key pair file.

This command configures the port number used by this node to receive SNMP request messages and to send replies. SNMP notifications generated by the agent are sent from the port specified in the config>log>snmp-trap-group>trap-target CLI command.

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

This command configures the type of payload carried by the gLSP. Standard ethertype values are used for packet and Ethernet LSPs (see RFC 3471).

This command enables mLDP to generate a basic FEC despite the actual root node being resolved using BGP. This functionality is useful if a connected router does not support the mLDP recursive FEC type.

This command only operates with recursive opaque type 7 FECs and non-recursive type 1 FECs.

The no form of the command causes mLDP to generate a recursive FEC if the actual root node is resolved using BGP.

This optional command causes the ICMP unreachable messages to be sent when received packets match the associated static route. By default, the ICMP unreachable messages for those types of static routes are not generated.

This command can only be associated with a static route that has a black-hole next-hop

The no form of this command removes the black-hole next-hop from static route configuration.

This optional command causes the ICMP unreachable messages to be sent when received packets match the associated static route. By default, the ICMP unreachable messages for those types of static routes are not generated.

This command can only be associated with a static route that has a blackhole next-hop

The no form of this command removes the black-hole nexthop from the static route configuration.

This command configures whether traps are generated every time a node is updated, added, or removed from the OSPF opaque database (using LSA type 10 opaque update).

The no form of causes traps to not be generated for database changes.

This command enables/disables support for the get opcode.

This command enables the context to configure communication with a GGSN Mobile Gateway.

The command includes the GGSN-Address AVP value in all Diameter DCCA CCR messages. The value is either the local IPv4 address or local IPv6 address used to set up the diameter peer.

The no form of this command removes the GGSN-Address AVP from the Diameter DCCA CCR messages.

This command allows selection of GI addresses based on the host entry in LUDB.

The gi-address must be a valid address (associated with an interface) within the routing context that received the DHCP message on the access side.

The no form of this command reverts to the default.

This command configures the gateway interface address for the DHCP relay. A subscriber interface can include multiple group interfaces with multiple SAPs. The GI address is needed, when the router functions as a DHCP relay, to distinguish between the different subscriber interfaces and potentially between the group interfaces defined.

By default, the GI address used in the relayed DHCP packet is the primary IP address of a normal IES interface. Specifying the GI address allows the user to choose a secondary address. For group interfaces a GI address must be specified under the group interface DHCP context or subscriber-interface DHCP context in order for DHCP to function.

The no form of this command reverts to the default.

This command specifies the gateway IP address of the DHCPv4 packets sent by the system. IPsec DHCP Relay uses only the gi-address configuration found under the IPsec gateway and does not take into account gi-address with src-ip-addr configuration below other interfaces.

This command configures the gateway interface address for the DHCP relay. The GI address is needed, when the router functions as a DHCP relay, to distinguish between the different subscriber interfaces and potentially between the group interfaces defined.

This command enables an operator to define a common CLI script that executes when any user logs into a CLI session. This login exec script is executed when any user (authenticated by any means including local user database, TACACS+, or RADIUS) opens a CLI session. This allows a user, for example, to define a common set of CLI aliases that are made available on the router for all users. This global login exec script is executed before any user-specific login exec files that may be configured.

This CLI script executes in the context of the user who opens the CLI session. Any commands in the script that the user is not authorized to execute will fail.

The no form of this command disables the execution of a global login-script.

This command configures the MPLS-TP Global ID for the node. This is used as the ‘from’ Global ID used by MPLS-TP LSPs originating at this node. If a value is not entered, the Global ID is taken to be Zero. This is used if the global-id is not configured. If an operator expects that inter-domain LSPs will be configured, then it is recommended that the global ID should be set to the local ASN of the node, as configured under config>system. If two-byte ASNs are used, then the most significant two bytes of the global-id are padded with zeros.

In order to change the value of the global-id, config>router>mpls>mpls-tp must be in the shutdown state. This will bring down all of the MPLS-TP LSPs on the node. New values a propagated to the system when a no shutdown is performed.

This command enables the global-variables configuration context.

The no form of this command removes all global variables.

This command binds a GMPLS LSP as a member of the GMPLS tunnel group. The session name is used to identify the GMPLS LSP. This is the LSP name of the GMPLS LSP.

The no form of this command removes the member.

This command enables the context to configure GMPLS parameters. GMPLS is not enabled by default and must be explicitly enabled using no shutdown. The shutdown command administratively disables GMPLS.

The no form of this command deletes this GMPLS protocol instance; this will remove all configuration parameters for this GMPLS instance.

GMPLS must be shut down before the GMPLS instance can be deleted. If GMPLS is not shut down when the no gmpls command is executed, a warning message on the console indicates that GMPLS is still administratively up.

This command enables and configures debugging for GMPLS.

The no form of the command disables debugging for GMPLS.

This command specifies the GMPLS Loopback Address to be used by LMP. A corresponding gmpls-loopback interface must have been configured for LMP to be enabled.

This command configures a loopback address to refer to the GMPLS loopback IP interface configured within the control channel router.

The no form of the command removes the configured loopback address.

This command configures a GMPLS tunnel group. A GMPLS tunnel group is a bundle of GMPLS LSPs providing an abstraction of the data bearers that are intended to be associated to one IP interface. This object allows, for example, end-to-end load balancing across the set of data bearers corresponding to a set of gLSPs. A gLSP is bound to an overlay tunnel group by a gLSP tunnel name at both the head end and the tail end UNI-C nodes of a gLSP. A sender-address may be optionally configured for the tail end of a gLSP in case overlapping GMPLS LSP tunnel names are used by different head end nodes.

The no form of this command removes the tunnel group. All members of a GMPLS tunnel group must be removed and the tunnel group shutdown before the tunnel group can be deleted.

This command enables the context for configuring a gNMI service on gRPC.

This command permits the use of Capability RPC for a user associated with the given format.

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

This command permits the use of Get RPC.

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

This command permits the use of Set RPC.

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

This command permits the use of Subscribe RPC.

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

This command permits the use of gNOI CanGenerateCSR RPCs for the user profile.

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

This command permits the use of gNOI GetCertificate RPCs for the user profile.

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

This command permits the use of gNOI Install RPCs for the user profile.

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

This command permits or denies the use of gNOI RevokeCertificates RPCs for the user profile.

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

This command permits the use of gNOI Rotate RPCs for the user profile.

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

This command permits the use of gNOI System RebootStatus RPC for a user-given profile.

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

This command permits the use of gNOI System Reboot RPC for a user-given profile.

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

This command permits the use of gNOI System RebootStatus RPC for a user-given profile.

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

This command permits the use of gNOI System SetPackage RPC for a user-given profile.

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

This command permits the use of gNOI System SwitchControlProcessor RPC for a user-given profile.

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

This command changes the edit point of the candidate configuration. The edit point is the point after which new commands are inserted into the candidate configuration as an operator navigates the CLI and issues commands in edit-cfg mode.

This command enables the inclusion of the 3GPP QoS specification in AAA protocols as signaled in the incoming GTP setup message.

The no form of this command disables the inclusion of the attribute.

This command enables the RSVP Graceful Restart Helper feature.

The RSVP-TE Graceful Restart helper mode allows the SROS based system (the helper node) to provide another router that has requested it (the restarting node) a grace period, during which the system will continue to use RSVP sessions to neighbors requesting the grace period. This is typically used when another router is rebooting its control plane but its forwarding plane is expected to continue to forward traffic based on the previously available Path and Resv states.

The user can enable Graceful Restart helper on each RSVP interface separately. When the GR helper feature is enabled on an RSVP interface, the node starts inserting a new Restart_Cap Object in the Hello packets to its neighbor. The restarting node does the same and indicates to the helper node the desired Restart Time and Recovery Time.

The GR Restart helper consists of a couple of phases. Once it loses Hello communication with its neighbor, the helper node enters the Restart phase. During this phase, it preserves the state of all RSVP sessions to its neighbor and waits for a new Hello message.

Once the Hello message is received indicating the restarting node preserved state, the helper node enters the recovery phase in which it starts refreshing all the sessions that were preserved. The restarting node will activate all the stale sessions that are refreshed by the helper node. Any Path state which did not get a Resv message from the restarting node once the Recovery Phase time is over is considered to have expired and is deleted by the helper node causing the proper Path Tear generation downstream.

The duration of the restart phase (recovery phase) is equal to the minimum of the neighbor’s advertised Restart Time (Recovery Time) in its last Hello message and the locally configured value of the max-restart (max-recovery) parameter.

When GR helper is enabled on an RSVP interface, its procedures apply to the state of both P2P and P2MP RSVP LSP to a neighbor over this interface.

This command configures the local values for the max-recovery and the max-restart intervals used in the RSVP Graceful Restart Helper feature when applied to a GMPLS UNI.

The values are configured globally in GMPLS.

The no version of this command re-instates the default value for the delay timer.

This command configures the local values for the max-recovery and the max-restart intervals used in the RSVP Graceful Restart Helper feature.

The values are configured globally in RSVP but separate instances of the timers are applied to each RSVP interface that has the RSVP Graceful Restart Helper enabled.

The no version of this command re-instates the default value for the delay timer.

This command enables the context to configure Nokia ETH-CFM Grace and ITU-T Y.1731 ETH-ED expected defect functional parameters.

This command enables the context to configure Nokia ETH-CFM Grace and ITU-T Y.1731 ETH-ED expected defect functional parameters.

This command enters the context to configure Nokia ETH-CFM Grace and ITU-T Y.1731 ETH-ED expected defect functional parameters.

This command enters the context to configure Nokia ETH-CFM Grace and ITU-T Y.1731 ETH-ED expected defect functional parameters.

This command enters the context to configure Nokia ETH-CFM Grace and ITU-T Y.1731 ETH-ED expected defect functional parameters.

This command enables the context to configure Nokia ETH-CFM Grace and ITU-T Y.1731 ETH-ED expected defect functional parameters.

Enables the sending of grace for all the enabled EFM-OAM sessions on the node. Disabled by default at the system level and enabled by default at the port level. The combination of the system level and port level configuration will determine if the grace function is enabled on the individual ports. Both the system level and the port level must be enabled in order to support grace on a specific port. If either level is disabled, grace is not enabled on those ports. Enabling grace during an active ISSU or soft reset does not invoke the grace function for the active event.

When both grace-tx-enable and config>system>ethernet>efm-oam dying-gasp-tx-on-reset, config>port>ethernet>efm-oam dying-gasp-tx-on-reset are active on the same port, grace-tx-enable takes precedence when a soft reset is invoked if the Peer Vendor OUI being received is 00:16:4d (ALU) or the configured config>port>ethernet>efm-oam grace-vendor-oui value. The grace-tx-enable command should not be configured if the Nokia Vendor Specific Grace TLV is not supported on the remote peer, including Nokia 7750 SR equipment prior to release 11.0 R4.

The no form of this command disables the sending of the Nokia Vendor Specific Grace TLV.

This command enables ETH-CFM grace transmission at the system level when a soft reset message is received and processed by the ETH-CFM module. Individual MEP configuration determines which of the two supported grace functions, ETH-VSM or ETH-ED, is used to announce grace.

This command controls the overall capability to transmit grace and does not control which grace announcement to use. This command also has no impact on the reception and processing of grace-style PDUs.

The no form of this command disables ETH-CFM grace transmission at the system level.

This optional command configures an additional peer vendor OUI which indicates support for the Vendor Specific EFM-OAM Grace functionality, allowing grace to be preferred over dying gasp when both are configured. This is in addition to the Nokia Vendor OUI 00:16:4d.

When both grace-tx-enable (config>system>ethernet>efm-oam grace-tx-enable, config>port>ethernet>efm-oam grace-tx-enable) and dying-gasp-tx-on-reset (config>system>ethernet>efm-oam dying-gasp-tx-on-reset, config>port>ethernet>efm-oam dying-gasp-tx-on-reset) are active on the same port, grace-tx-enable takes precedence when a soft reset is invoked if the Peer Vendor OUI being received is 00:16:4d (ALU) or the configured grace-vendor-oui value. The grace-tx-enable command should not be configured if the Nokia Vendor Specific Grace TLV is not supported on the remote peer, including Nokia 7750 SR equipment prior to release 11.0 R4.

The no form of this command removes the additional Vendor OUI but does not remove the Nokia 00:16:4d value.

This command enables BGP graceful restart helper procedures (the “receiving router” role defined in the standard) for address families included in the GR capabilities of both peers. In a VPRN, SR OS can support GR helper functionality for IPv4, IPv6, label-ipv4, flow-ipv4 (IPv4 FlowSpec) and flow-ipv6 (IPv6 FlowSpec) routes.

When a neighbor covered by the GR helper mode restarts its control plane, forwarding can continue uninterrupted while the session is re-established and routes are re-learned.

The no form of this command disables graceful restart.

This command enables IS-IS graceful restart (GR) to minimize service interruption. When the control plane of a GR-capable router fails or restarts, the neighboring routers (GR helpers) temporarily preserve IS-IS forwarding information. Traffic continues to be forwarded to the restarting router using the last known forwarding tables. If the control plane of the restarting router becomes operationally and administratively up within the grace period, the restarting router resumes normal IS-IS operation. If the grace period expires, then the restarting router is presumed inactive and the IS-IS topology is recalculated to route traffic around the failure.

The no form of this command disables graceful restart and removes the graceful restart configuration from the IS-IS instance.

This command enables OSPF graceful restart (GR) to minimize service interruption.

When the control plane of a GR-capable router fails or restarts, the neighboring routers (GR helpers) temporarily preserve OSPF forwarding information. Traffic continues to be forwarded to the restarting router using the last known forwarding tables. If the control plane of the restarting router becomes operationally and administratively up within the grace period, the restarting router resumes normal OSPF operation. If the grace period expires, the restarting router is presumed inactive and the OSPF topology is recalculated to route traffic around the failure.

The no form of this command disables GR and removes the GR configuration from the OSPF instance.

This command enables graceful restart helper.

The no form of this command disables graceful restart.

Graceful restart helper configuration changes, enable/disable, or change of a parameter will cause the LDP session to bounce.

This command enables BGP graceful restart helper procedures (the “receiving router” role defined in the standard) for address families included in the GR capabilities of both peers. SR OS can support GR helper functionality for IPv4, IPv6, VPN-IPv4, VPN-IPv6, Label-IPv4, Label-IPv6, L2-VPN, Route-Target (RTC), Flow-IPv4 (IPv4 FlowSpec) and Flow-IPv6 (IPv6 FlowSpec) routes.

If a neighbor covered by the GR helper mode restarts its control plane, forwarding can continue uninterrupted while the session is re-established and routes are re-learned.

The no form of this command disables graceful restart.

This command enables debugging for BGP graceful restart.

The no form of this command disables the debugging.

This command enables IS-IS graceful restart (GR) to minimize service interruption. When the control plane of a GR-capable router fails or restarts, the neighboring routers (GR helpers) temporarily preserve IS-IS forwarding information. Traffic continues to be forwarded to the restarting router using the last known forwarding tables. If the control plane of the restarting router becomes operationally and administratively up within the grace period, the restarting router resumes normal IS-IS operation. If the grace period expires, then the restarting router is presumed inactive and the IS-IS topology is recalculated to route traffic around the failure.

The no form of this command disables graceful restart and removes the graceful restart configuration from the IS-IS instance.

This command enables debugging for IS-IS graceful-restart.

The no form of the command disables debugging.

This command enables OSPF graceful restart (GR) to minimize service disruption. When the control plane of a GR-capable router fails or restarts, the neighboring routers (GR helpers) temporarily preserve OSPF forwarding information. Traffic continues to be forwarded to the restarting router using the last known forwarding tables. If the control plane of the restarting router comes back up within the grace period, the restarting router resumes normal OSPF operation. If the grace period expires, then the restarting router is presumed inactive and the OSPF topology is recalculated to route traffic around the failure.

The no form of this command disables graceful restart and removes the graceful restart configuration from the OSPF instance.

This command enables debugging for OSPF and OSPF3 graceful restart.

This command initiates a graceful shutdown of the specified RSVP interface or all RSVP interfaces on the node if applied at the RSVP level. These are referred to as maintenance interface and maintenance node, respectively.

To initiate a graceful shutdown the maintenance node generates a PathErr message with a specific error sub-code of Local Maintenance on TE Link required for each LSP that is exiting the maintenance interface.

The node performs a single make-before-break attempt for all adaptive CSPF LSPs it originates and LSP paths using the maintenance interfaces. If an alternative path for an affected LSP is not found, then the LSP is maintained on its current path. The maintenance node also tears down and re-signals any detour LSP path using listed maintenance interfaces as soon as they are not active.

The maintenance node floods an IGP TE LSA/LSP containing Link TLV for the links under graceful shutdown with TE metric set to 0xffffffff and Unreserved Bandwidth parameter set to zero (0).

A head-end LER node, upon receipt of the PathErr message performs a single make-before-break attempt on the affected adaptive CSPF LSP. If an alternative path is not found, then the LSP is maintained on its current path.

A node does not take any action on the paths of the following originating LSPs after receiving the PathErr message:

a. An adaptive CSPF LSP for which the PathErr indicates a node address in the address list and the node corresponds to the destination of the LSP. In this case, there are no alternative paths which can be found.

b. An adaptive CSPF LSP whose path has explicit hops defined using the listed maintenance interface(s)/node(s).

c. A CSPF LSP with the adaptive option disabled and which current path is over the listed maintenance interfaces in the PathErr message. These are not subject to make-before-break.

d. A non CSPF LSP which current path is over the listed maintenance interfaces in the PathErr message.

The head-end LER node upon receipt of the updates IPG TE LSA/LSP for the maintenance interfaces updates the TE database. This information will be used at the next scheduled CSPF computation for any LSP which path may traverse any of the maintenance interfaces.

The no form of this command disables the graceful shutdown operation at the RSVP interface level or at the RSVP level. The configured TE parameters of the maintenance links are restored and the maintenance node floods the links.

This command enables debugging for PIM grafts.

The no form of this command disables PIM graft debugging.

This command is used to create a step-like behavior where the operational PIR will round up to the nearest increment of the specified granularity before being applied to the child. The only exception is when the distributed bandwidth is less than 1% above a lower step value, in which case the lower step value is used.

This step-like behavior may be useful when the bandwidth used by an active child is well known. While the above-offered-cap command automatically adds a specified amount to the operational PIR of a child, the granularity command only increments the operational PIR to the next step value. While not expected to be used in conjunction, the above-offered-cap and granularity commands may be used simultaneously, in which case the above-offered-cap increase will be applied first, followed by the granularity rounding to the next step value.

If the granularity command is used with a percent-based value, the rounding up function of the configured PIR value on the policer or queue is based on the child’s administrative PIR. In this case, care should be taken that the child is either configured with an explicit PIR rate (other than max) or the child’s administrative PIR is defined using the percent-rate command with the local parameter enabled if an explicit value is not desired. When a maximum PIR is in use on the child, the system attempts to interpret the maximum child forwarding rate. This rate could be very large if the child is associated with multiple ingress or egress ports.

If the child’s administrative PIR is modified while a percent-based granularity is in effect, the system automatically uses the new relative rounding value the next time the child’s operational PIR is determined.

When this command is not specified or removed, the system makes no attempt to round up the child’s determined operational PIR.

The no form of this command is used to remove the operational PIR rounding behavior from all child policers and queues associated with the policy.

This command is used to adjust the sensitivity of the virtual scheduler to changes in the child offered rate. As the child offered rate is determined, it is compared to the previous offered rate. If the delta does not exceed the sensitivity threshold determined for the current offered rate, the change in offered rate is ignored for that iteration.

While it is assumed that changing the offered rate change sensitivity will be a rare occurrence, it may be prudent to react to smaller changes in the offered rate of a particular child policer or queue. Another possible reason for changing the sensitivity is that it may be desired to lower the impact of changes in offered rate on the virtual scheduler for a particular child by raising the granularity.

A side effect of higher sensitivity (lower granularity) is that the virtual scheduler may need to adjust the distributed bandwidth between all children more often, resulting in the possibility of lowering resources available to other virtual scheduler instances on the slot.

A side effect of lower sensitivity (higher granularity) is that the parent virtual scheduler may distribute insufficient bandwidth to the child resulting in dropped packets.

If the granularity command is used with a percent-based value, the sensitivity is a function of the configured PIR value on the policer or queue. In this case, care should be taken that the child is either configured with an explicit PIR rate (other than max) or the child’s administrative PIR is defined using the percent-rate command with the local parameter enabled if an explicit value is not desired. When a maximum PIR is in use on the child, the system attempts to interpret the maximum child forwarding rate. This rate could be very large if the child is associated with multiple ingress or egress ports.

Except for the overall cap on the offered input into the virtual scheduler, the child’s administrative PIR has no effect on the calculated sensitivity if an explicit rate is specified.

If the child’s administrative PIR is modified while a percent-based granularity is in effect, the system automatically uses the new relative sensitivity value the next time the child’s offered rate is determined.

The no form of this command is used to restore the default offered rate sensitivity behavior to all child policers and queues associated with the policy.

This command enables the generation of unsolicited Router-advertisement on creation of v4 host.

The no form of this command disables gratuitous-rtr-adv.

This command enables matching on GRE tunnels.

The no form of this command disables matching on GRE tunnels, unless no other tunnel type specifier is configured.

This command enables setting the tunnel type for the auto bind tunnel.

The gre encapsulation of the MPLS service packet uses the base 4-byte header as per RFC 2890. The optional fields Checksum (plus Reserved field), Key, and Sequence Number are not inserted.

This command creates a GRE header for inclusion in test OAM build packet instance.

This command provides the context for configuring parameters related to termination of a GRE tunnel carrying Ethernet payload onto a PW port by using Forwarding Path Extensions (FPE).

This command configures the type of the IP tunnel. If the gre-header command is configured then the tunnel is a GRE tunnel with a header inserted between the outer and inner IP headers.

If the no form of this command is configured then the tunnel is a simple IP-IP tunnel.

This command configures the type of the IP tunnel. If the gre-header command is configured then the tunnel is a GRE tunnel with a GRE header inserted between the outer and inner IP headers. If the no form of this command is configured then the tunnel is a simple IP-IP tunnel.

This command configures the type of the IP tunnel. If the gre-header command is configured then the tunnel is a GRE tunnel with a GRE header inserted between the outer and inner IP headers. If the no form of this command is configured then the tunnel is a simple IP-IP tunnel.

This command enables the population of the GRE key field in the GRE header sent with the encapsulated IP packet.

The no form of this command disables the population of the optional GRE key field when the matching IP packet is sent encapsulated in a GRE tunnel.

This command enables the termination of MPLS-over-GRE and IP-over-GRE packets on destination IP addresses from a user-defined subnet. The user defines a subnet for the termination of GRE packets by applying the gre-termination command to a numbered network IP interface, including a loopback interface.

For more information, refer to “IP-over-GRE and MPLS-over-GRE Termination on a User-Configured Subnet” in the 7450 ESS, 7750 SR, 7950 XRS, and VSR Router Configuration Guide.

The no form of this command disables the termination of MPLS-over-GRE and IP-over-GRE packets on the subnet of the interface. Packets are dropped.

This command enables the context to configure a GRE tunnel template parameters to be used to tunnel associated traffic.

The no form of this command removes the GRE tunnel template from the configuration.

This command configures the L2TP tunnel group. The tunnel-group-name is configured in the config>router>l2tp context. Refer to the 7450 ESS, 7750 SR, 7950 XRS, and VSR Router Configuration Guide.

This command configures an L2TP tunnel group.

The no form of this command reverts removes the tunnel group name from the configuration.

This command enables debugging for an L2TP tunnel group.

This command enables and configures debugging for an L2TP group.

This command specifies a GSMP name. A GSMP group name is unique only within the scope of the service in which it is defined.

The no form of this command reverts to the default.

This command adds or removes a static multicast group.

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

This command configures a static multicast group.

The no form of this command reverts to the default.

This command creates a context for configuring a RIP group of neighbors. RIP groups are a way of logically associating RIP neighbor interfaces to facilitate a common configuration for RIP interfaces.

The no form of this command deletes the RIP neighbor interface group. Deleting the group also removes the RIP configuration of all the neighbor interfaces currently assigned to this group.

This command changes the maximum rate allowed for a weighted scheduling group on the local HSMDA scheduler. Scheduling classes within the group are managed with an aggregate rate limit when either an explicit group rate is defined on the HSMDA scheduling policy or a local override is defined based on the group override command.

The no form of this command removes the local overrides for the weighted scheduling group. Once removed, the defined behavior within the HSMDA scheduling policy for the weighted scheduling group is used.

This command overrides a group rate configured in the HS scheduler policy applied to the port egress.

The no form of this command removes the rate override from the port egress configuration.

This command configures payload of the SONET/SDH group.

This command is supported by TDM satellite, however the tu3 parameter is not.

For example:

config>port>sonet-sdh#

group tug3-1.1 payload tu3 group tug3-1.2 payload vt2 group tug3-1.3 payload vt2 group tug3-2.1 payload vt15 group tug3-2.2 payload vt15 group tug3-2.3 payload tu3 group tug3-3.1 payload tu3 group tug3-3.2 payload tu3 group tug3-3.3 payload tu3

This command enables the context to configure a BGP peer group.

The no form of this command deletes the specified peer group and all configurations associated with the peer group. The group must be shutdown before it can be deleted.

This command enters the context to add a static multicast group as a (*, G) or as one or more (S,G) records. When a static MLD or 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 creates a context to configure a BGP peer group.

The no form of this command deletes the specified peer group and all configurations associated with the peer group. The group must be shut down before it can be deleted.

This command adds a static multicast group either as a (*,G) or one or more (S,G) records. Use IGMP static group memberships to test multicast forwarding without a receiver host. When IGMP static groups are enabled, data is forwarded to an interface without receiving membership reports from host members.

When static IGMP group entries on point-to-point links that connect routers to a rendezvous point (RP) are configured, the static IGMP group entries do not generate join messages toward the RP.

This command enters the context to add a static multicast group either as a (*,G) or one or more (S,G) records. Use MLD static group memberships to test multicast forwarding without a receiver host. When MLD static groups are enabled, data is forwarded to an interface without receiving membership reports from host members.

When static MLD group entries on point-to-point links that connect routers to a rendezvous point (RP) are configured, the static MLD group entries do not generate join messages toward the RP.

The no form of this command removes the IPv6 address 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 these 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. In this case, the $ prompt to indicate that a new entity (group) is being created should be used.

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

This command creates group prefixes that map to the multicast stream. At least one source must be specified for the policy to be active.

This command configures and enables the context to configure an application assurance group and partition parameters.

This commands performs a group-specific upgrade.

This command configures application-assurance within a group/partition debugging.

This command enables the context to add a static multicast group either as a (*,G) or one or more (S,G) records. Use IGMP static group memberships to test multicast forwarding without a receiver host. When IGMP static groups are enabled, data is forwarded to an interface without receiving membership reports from host members.

When static IGMP group entries on point-to-point links that connect routers to a rendezvous point (RP) are configured, the static IGMP group entries do not generate join messages toward the RP.

This command enables the context to add a static multicast group either as a (*,G) or one or more (S,G) records.

The user can assign static multicast group joins to a tunnel interface associated with an RSVP P2MP LSP.

A given (*,G) or (S,G) can only be associated with a single tunnel interface.

A multicast packet which is received on an interface and which succeeds the RPF check for the source address will be replicated and forwarded to all OIFs which correspond to the branches of the P2MP LSP. The packet is sent on each OIF with the label stack indicated in the NHLFE of this OIF. The packets will also be replicated and forwarded natively on all OIFs which have received IGMP or PIM joins for this (S,G).

The multicast packet can be received over a PIM or IGMP interface which can be an IES interface, a spoke SDP terminated IES interface, or a network interface.

This command enables the context to add a static multicast group either as a (*,G) or one or more (S,G) records. Use MLD static group memberships to test multicast forwarding without a receiver host. When MLD static groups are enabled, data is forwarded to an interface without receiving membership reports from host members.

When static MLD group entries on point-to-point links that connect routers to a rendezvous point (RP) are configured, the static MLD group entries do not generate join messages toward the RP.

The no form of this command removes the IPv6 address 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 these 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. In this case, the $ prompt to indicate that a new entity (group) is being created should be used.

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

The no form of this command removes the group-name from the MSDP configuration.

This command defines the maximum rate allowed for the scheduling classes mapped to the specified group-id. A group is a scheduling entity used to combine up to three consecutive scheduling classes into a single strict priority level. Each scheduling class within the group has an associated weight. When the scheduler is operating at the strict level associated with the group, the ratio of bandwidth allocated to each scheduling class within the group during congestion at that strict level is relative to the ratio of the weight of each member. The bandwidth is allocated in a work-conserving fashion and is sensitive to packet size up to the maximum rate defined for the group.

The no form of this command reverts the specified weighted scheduling class group rate limit to the default setting.

This command defines the maximum rate allowed for the scheduling classes mapped to the specified group-id. A group is a scheduling component used to combine up to six consecutive scheduling classes into a single strict priority level. Each scheduling class within the group has an associated weight. When the scheduler is servicing the strict level associated with the group, the ratio of bandwidth allocated to each scheduling class within the group during congestion is relative to the ratio of the weight of each active member.

The no form of the command reverts to the default.

This command defines a weighted scheduler group within a port scheduler policy.

The port scheduler policy defines a set of eight priority levels. The weighted scheduler group allows for the application of a scheduling weight to groups of child queues competing at the same priority level of the port scheduler policy applied to a Vport defined in the context of the egress of an Ethernet port or applied to the egress of an Ethernet port.

Up to eight groups can be defined within each port scheduler policy. One or more levels can map to the same group. A group has a rate and, optionally, a cir-rate, and inherits the highest scheduling priority of its member levels. A group receives bandwidth from the port or from the Vport and distributes it within the member levels of the group according to the weight of each level within the group.

Each priority level will compete for bandwidth within the group based on its weight under a congestion situation. If there is no congestion, a priority level can achieve up to its rate (cir-rate) worth of bandwidth.

CLI will enforce that mapping of levels to a group are contiguous. A user would not be able to add a priority level to a group unless the resulting set of priority levels is contiguous.

The no form of this command removes the group from the port scheduler policy.

This command monitors statistics for a PIM source group.

This command enables the context to perform a group-specific upgrade.

This command associates (or links) a user to a group name. The group name must be configured with the config>system>security>user >snmp>group command. The config>system>security>user access command links the group with one or more views, security model (s), security level (s), and read, write, and notify permissions.

This command creates a context for configuring a RIP group of neighbor interfaces.

RIP groups are a way of logically associating RIP neighbor interfaces to facilitate a common configuration for RIP interfaces.

The no form of the command deletes the RIP neighbor interface group. Deleting the group will also remove the RIP configuration of all the neighbor interfaces currently assigned to this group.

This command configures the number of seconds to wait before notifying clients monitoring this group when its operational status transitions from up to down.

The no form of the command sets the values back to the default.

This command configures the number of seconds to wait before notifying clients monitoring this group when its operational status transitions from down to up. A value of zero indicates that transitions are reported immediately to monitoring clients. The up time option is a must to achieve fast convergence: when the group comes up, the monitoring MH site which tracks the group status may wait without impacting the overall convergence; there is usually a pair MH site that is already handling the traffic.

The no form of the command reverts to the default.

This command specifies the multicast group-address prefix list containing multicast group-addresses that are embedded in the join or prune packet as a filter criterion. The prefix list must be configured prior to entering this command. Prefix lists are configured in the config>router>policy-options>prefix-list context.

The no form of this command removes the criterion from the configuration.

This command configures group encryption for the WLAN-GW group interface.

This command enables NGE on the router interface. When NGE is enabled on the interface, all received Layer 3 packets that have the protocol ID configured as ESP are considered to be NGE packets and must be encrypted using a valid set of keys from any preconfigured key group on the system.

The no form of this command disables NGE on the interface. NGE cannot be disabled unless all key groups and IP exception filters are removed.

This command enables the context to configure group encryption parameters.

This command configures the group encryption label used to identify when an MPLS payload is encrypted. This label must be unique network-wide and must be configured consistently on all nodes participating in a network group encryption domain. The label cannot be changed or deleted when there are any key groups configured on the node.

The no form of the command reverts to the default setting.

This command groups automatically-inserted entries.

This command configures the group interface.

The no form of this command removes the group interface parameters from the configuration.

This command creates a group interface. This interface is designed for triple play services where multiple SAPs are part of the same subnet. A group interface may contain one or more SAPs.

The no form of this command removes the group interface from the subscriber interface.

This command configures the default group interface where the hosts of the GTP connection is enabled. The group interface must be of type gtp.

The no form of this command removes the default group interface. In this case, a group interface must be specified using authentication.

This command configures IGMP group interfaces.

The no form of this command reverts to the default.

This command enables debugging for IGMP group-interface.

The no form of the command disables debugging.

This command enables IGMP on a group-interface in a VRF context. Activating IGMP under the group-interface is a prerequisite for subscriber replication. The group-interface is also needed so that MCAC can be applied and various IGMP parameters defined.

This command can be used in a regular, wholesaler or retailer type of VRF. The retailer VRF does not have the concept of group-interfaces under the subscriber-interface hierarchy. In the case that this command is applied to a retailer VRF instance, the optional fwd-service command must be configured. The fwd-service command is referencing the wholesaler VRF in which the traffic is ultimately replicated. Redirection in the retailer VRF is supported.

This command enables IGMP on a group-interface in the Global Routing Table (GRT). The group-interface in GRT is defined under the IES service. Activating IGMP under the group-interface is a prerequisite for subscriber replication. The group-interface is also needed so that MCAC can be applied and various IGMP parameters defined.

This command creates and enables the context to configure MLD group interface parameters.

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

This command creates a template for specifying parameters for automatically generated group interfaces, for example, the creation of CUPS sessions. When no specific name is specified, a template named “default” is used, if it has been manually provisioned.

This command defines SDP administrative groups, referred to as SDP admin groups.

SDP admin groups provide a way for services using a pseudowire template to automatically include or exclude specific provisioned SDPs. SDPs sharing a specific characteristic or attribute can be made members of the same admin group. When users configure a pseudowire template, they can include and/or exclude one or more admin groups. When the service is bound to the pseudowire template, the SDP selection rules will enforce the admin group constraints specified in the sdp-include and sdp-exclude commands.

A maximum of 32 admin groups can be created. The group value ranges from zero (0) to 31. It is uniquely associated with the group name at creation time. If the user attempts to configure another group name for a group value that is already assigned to an existing group name, the SDP admin group creation is failed. The same happens if the user attempts to configure an SDP admin group with a new name but associates it to a group value already assigned to an existing group name.

The no option of this command deletes the SDP admin group but is only allowed if the group-name is not referenced in a PW template or SDP.

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.

This command identifies filter policy of multicast groups to be applied to this VPLS entity. The sources of the multicast traffic must be a member of the VPLS.

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

This command configures multicast group IPv4 prefixes for the MVPN with per-group mapping extranet functionality. Multiple lines are allowed. Duplicate prefixes are ignored.

When the starg option is specified, extranet functionality is enabled for PIM ASM as for the specified group. When the option is not specified (not recommended with PIM ASM), the PIM ASM join will be mapped and data plane will be established, but the control plane will not be updated on SPT switchover, unless the switchover is driven by a CPE router on a receiver side.

The no form of this command deletes specified prefix from the list, or removes mapping of all prefixes if group-prefix any was specified.

This command configures multicast group IPv4 prefixes for the multicast GRT/VRF with per group mapping extranet functionality. Multiple lines are allowed. Duplicate prefixes are ignored. Operator can either configure specific groups for extranet or specify all groups by using key-word any. The two options are mutually exclusive in configuration.

When the starg option is specified, extranet functionality is enabled for PIM ASM as for the specified group. When the option is not specified (not recommended with PIM ASM), the PIM ASM join will be mapped and data plane will be established, but the control plane will not be updated on SPT switchover, unless the switchover is driven by a CPE router on a receiver side.

The no form of this command deletes specified prefix from the list, or removes mapping of all prefixes if group-prefix any was specified.

The group-prefix for a static-rp defines a range of multicast-ip-addresses for which this static RP is applicable.

The no form of this command removes the criterion.

The group-prefix for a static-rp defines a range of multicast-ip-addresses for which a certain RP is applicable.

The no form of this command removes the criterion.

This command specifies the range of multicast group addresses which should be used by the router as the Rendezvous Point (RP). The config>router>pim>rp>static>address a.b.c.d implicitly defaults to deny all for all multicast groups (224.0.0.0/4). A group-prefix must be specified for that static address. This command does not apply to the whole group range.

The no form of this command removes the group-prefix from the configuration.

This command configures the group address or range of group addresses for which this router can be the rendezvous point (RP).

The no form of this command removes the group address or range of group addresses for which this router can be the RP from the configuration.

This command configures the group address or range of group addresses for which this router can be the rendezvous point (RP).

Use the no form of this command to remove the group address or range of group addresses for which this router can be the RP from the configuration.

This command defines which multicast groups can embed RP address information besides FF70::/12. Embedded RP information is only used when the multicast group is in FF70::/12 or the configured group range.

The no form of this command removes the parameter from the

This command configures the address ranges of the multicast groups for which this router can be an RP.

The no form of this commands removes the parameter from the configuration.

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.

The no form of this command removes the parameter from the configuration.

This command configures the session limit. The value controls how many L2TP session will be allowed within a given context (system, group, tunnel).

The no form of this command removes the session limit value from the configuration.

This command configures the query source IP address for all group interfaces.

The no form of this command removes the IP address.

This command configures the query source IP address for all group interfaces.

The no form of the command removes the IP address.

This command configures the query source IPv6 address for all group interfaces.

The no form of this command removes the IP address.

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

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

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

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

The no form of this command removes the start and end ranges from the configuration.

This command enables the debug context for gRPC.

The no form of this command removes any debug activation within the gRPC context.

This command enters the context to configure hash-control for the gRPC interface.

This command enables the context to configure a specific gRPC security profile.

This command enables the context to configure gRPC parameters.

This command creates a static route in a VPRN service context that points to the global routing context (base router). This is primarily used to allow traffic that ingress through a VPRN service to be routed out of the global routing context.

This next-hop type cannot be used in conjunction with any other next-hop types.

This command enters the context to configure GRT/VRF extranet for this MVPN instance.

This command provides the context under which all Global Route Table (GRT) leaking commands are configured. If all the supporting commands in the context are removed, this command will also be removed.

This command enters the context to configure General Switch Management Protocol (GSMP) connections maintained in this service.

This command enters the context to configure GTM parameters.

This command enables the context to configure GTM parameters.

This command enables the context to configure GTM parameters.

This command enables the context to configure GTP parameters for the routing context.

This command enables the context to configure box-wide GTP parameters and profiles.

This command enables the context to configure debugging for GTP.

This command enables the context to configure distributed GTP parameters.

This command enters the context to configure GTP parameters.

This command includes the extracted IPV4 GTP packets for ip-src-monitoring. IPv4 GTP packets will be subject to the per-source-rate of CPU protection policies.

This command enables matching on UEs in a GTP-authorized state.

The no form of this command disables matching on UEs in a GTP-authorized state, unless all state matching is disabled.

This command assigns an existing GTP filter as an action on flows matching this AQP entry.

The no form of this command removes this GTP filter from actions on flows matching this AQP entry.

This command configures TCA generation for a GTP filter.

This command allows AA to treat traffic on UDP port number 2152 as GTP-u. Without further specifying any other parameters within this GTP context, AA performs basic GTP-u header sanity checks and discards packets that are malformed. This GTP context allows the operator to configure various GTP filters (maximum of 128 GTP filters).

This command configures whether to include or exclude GTP filter admit-deny statistics in accounting records.

This command configures a TCA for the counter capturing drops due to the GTP filter GTP-in-GTP packet check. A gtp-in-gtp drop TCA can be created for traffic generated from the subscriber side of AA (from-sub) or for traffic generated from the network toward the AA subscriber (to-sub). The create keyword is mandatory when creating a gtp-in-gtp TCA.

This command configures GTP-in-GTP packet filtering.

This command specifies the filter entry action to gtp-local-breakout.

This command, when enabled causes an interim update to be sent whenever a mobility event for ESM over GTP is detected. Mobility events include X2 mobility, service re-activation after idling, notification changes and any detected change of ULI or RAT-Type.

The no version of this command disables generating mobility related events.

This command enables the context to configure GTP parameters. The configuration of parameters under this context is only allowed when the group interface is created with the GTP parameter specified.

This command configures a GTP peer cleanup timeout to terminate a handover wait state.

This command verifies whether a GTPv2 peer is reachable and correctly responds to GTPv2-C Echo Request messages. This command can be executed if no peering exists for the specified peer.

This command configures a TCA for the counter capturing drops due to basic GTP header sanity checks, such as validating that the GTP-U version is 1 and that the protocol bit is set to 1 for UDP traffic destined to port 2152. A GTP sanity drop TCA can be created for traffic generated from the subscriber side of AA (from-sub) or for traffic generated from the network toward the AA subscriber (to-sub). The create keyword is mandatory when creating a default action TCA.

This command provides a mechanism to configure a policer to function at the GTP tunnel level. GTP tunnels are defined by a TEID and destination IP address as oppose to normal flows that are defined by IP 5 tuple values. By setting this value, the policer then can be used to limit GTP traffic (SeGW GTP firewall application).

The no form of this command resets policer behavior to act at the normal 5 tuple flow level and not at the GTP tunnel level.

This command enables the context to configure GTP advanced firewall functions (such as validating GTP tunnels, sequence numbers, source IP addresses).

This command configures the allocation of memory resources required for stateful GTP firewall deployment on 3GPP S5/S8/Gn/Gp interfaces.

This command causes the associated header to be defined as a GTP user header template and enables the context to define the GTP parameters.

This command defines the user-name used for authentication of a GTP session.

The no form of this command reverts to the default.

This command configures the inspection of GTP-C packets. This is relevant only when AA GTP FW is deployed on S8/S5/Gp/Gn interfaces. The gtpc-inspection command must be enabled before configuring related features, such as APN filtering, GTP tunnel validation, message-type-v2 filtering, sequence number validation, SRC IP validation.

The no form of this command disables GTP-C packet inspection.

This command configures a Python script for the specified GTPv1-C message type in the specified direction.

The no form of this command reverts to the default.

This command configures a Python script for the specified GTPv2-C message type in the specified direction.

The no form of this command reverts to the default.

This command configures the guard time for an Eth-Ring. The guard timer is standard and is configurable from “x” ms to 2 seconds.

The no form of this command restores the default guard-time.

This command specifies the address range to be used for the gateway IP address field in EVPN type-5 routes that are advertised for configured NAT pools, to the peer for service-chaining. The system allocates one address for each ISA in the NAT group out of the specified range.

The no form of this command removes the values from the configuration..

This command specifies gateway endpoint address for the wlan-gw tunnel.

The no form of this command removes the gateway ipv4 or IPv6 endpoint address for the wlan-gw tunnel.

This command overrides the default SRRP gateway MAC address used by the SRRP instance. Unless specified, the system uses the same base MAC address for all SRRP instances with the last octet overridden by the lower 8 bits of the SRRP instance ID. The same SRRP gateway MAC address should be in-use by both the local and remote routers participating in the same SRRP context.

One reason to change the default SRRP gateway MAC address is if two SRRP instances sharing the same broadcast domain are using the same SRRP gateway MAC. The system will use the SRRP instance ID to separate the SRRP messages (by ignoring the messages that does not match the local instance ID), but a unique SRRP gateway MAC is essential to separate the routed packets for each gateway IP address.

The no form of this command removes the explicit SRRP gateway MAC address from the SRRP instance. The SRRP gateway MAC address can only be changed or removed when the SRRP instance is shutdown.

This command overrides the default SRRP gateway MAC address used by the SRRP instance. Unless specified, the system uses the same base MAC address for all SRRP instances with the last octet overridden by the lower 8 bits of the SRRP instance ID. The same SRRP gateway MAC address should be in-use by both the local and remote routers participating in the same SRRP context.

One reason to change the default SRRP gateway MAC address is if two SRRP instances sharing the same broadcast domain are using the same SRRP gateway MAC. The system will use the SRRP instance ID to separate the SRRP messages (by ignoring the messages that does not match the local instance ID), but a unique SRRP gateway MAC is essential to separate the routed packets for each gateway IP address.

The no form of this command removes the explicit SRRP gateway MAC address from the SRRP instance. The SRRP gateway MAC address can only be changed or removed when the SRRP instance is shutdown.

This command enables the context to configure Gx parameters.

This command controls the instantiation of an internal category required for Diameter Gx session level Usage Monitoring (per IP-CAN session).

When configured, Gx session level Usage Monitoring can be enabled for sessions associated with this category map.

The internal category for Gx session level Usage Monitoring is counted against the maximum of sixteen categories that can be configured.

When not configured (default), then no internal category is instantiated and Gx session level Usage Monitoring cannot be enabled for sessions associated with this category map.

This command enables the context to configure Diameter Credit Control Application or Gy-specific options.