Commands in this context configure egress counter parameters for this custom record.

The no form of this command reverts to the default.

This command configures egress counter parameters for this custom record.

The no form of this command reverts all egress counters to their default value.

Commands in this context configure E-1 parameters. E-1 is a basic time division multiplexing scheme used to carry digital circuits. It is also a standard WAN digital communication format designed to operate over copper facilities at a rate of 2.048 Mb/s.

North America uses the T-Carrier system while Europe uses the E-Carrier system of transmission, using multiples of the DS system. Digital signals are carried inside the carrier systems.

The no form of this command disables E-1 capabilities.

This command defines the end-to-end recovery type for the gLSP. This is the recovery model between the source and terminating UNI-C nodes of the GMPLS LSP.

The no form of this command removes any configured end-to-end recovery, and the GMPLS LSP becomes unprotected.

Commands in this context configure E-3 parameters. E-3 lines provide a speed of 44.736 Mb/s and is also frequently used by service providers. E-3 lines carry 16 E-1 signals with a data rate of 34.368 Mb/s.

An E-3 connection typically supports data rates of about 43 Mb/s. An E-3 line actually consists of 672 individual channels, each supporting 64 kb/s. E-3 lines are used mainly by Service Providers to connect to the Internet backbone and for the backbone itself.

Depending on the MDA type, the E-3 parameters must be disabled if clear channel is enabled by default (for example, on the m12-ds3e3 MDA). Clear channel is a channel that uses out-of-band signaling, not in-band signaling, so the channel's entire bit rate is available. Channelization must be explicitly specified. Note that if E-3 nodes are provisioned on the channelized SONET/SDH MDA you must provision the parent STS-1 SONET/STM0 SDH path first.

North America uses the T-Carrier system while Europe uses the E-Carrier system of transmission, using multiples of the DS system. Digital signals are carried inside the carrier systems.

The no form of this command disables E-3 capabilities.

This command configures the length of EA bits in the MAP rule. The no ea-length statement sets the ea-length to 0.

The EAPoL destination MAC address uses a destination multicast MAC address of 01:80:C2:00:00:03. Some networks cannot tunnel this packet over the network and consume these packets, causing the MKA session to fail. This command can change the destination MAC of the EAPoL to the unicast address of the MACsec peer, and as such, the EAPoL and MKA signaling will be unicasted between two peers.

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

This command configures the default import and export policy behavior for EBGP neighbors.

The no form of this command removes the default import and export policy behavior.

This command configures the default import and export policy behavior for EBGP neighbors.

The no form of this command removes the default import and export policy behavior.

This command instructs the BGP decision process to ignore the difference between EBGP and IBGP routes in selecting the best path and eligible multipaths (if multipath and ECMP are enabled). The result is a form of EIBGP load-balancing in a multipath scenario.

By default (with the no form of this command), the BGP decision process prefers an EBGP learned route over an IBGP learned route.

The behavior can be applied selectively to only certain types of routes by specifying one or more address family names in the command. If no families are specified, the command applies to IPv4 and IPv6 routes, and VPN-IPv4 and VPN-IPv6 routes.

This command instructs the BGP decision process to ignore the difference between EBGP and IBGP routes in selecting the best path and eligible multipaths (if multipath and ECMP are enabled). The result is a form of EIBGP load-balancing in a multipath scenario.

By default (with the no form of this command), the BGP decision process prefers an EBGP learned route over an IBGP learned route.

The behavior can be applied selectively to only certain types of routes by specifying one or more address family names in the command. If no families are specified, the command applies to IPv4, IPv6, label-IPv4, label-IPv6, VPN-IPv4, and VPN-IPv6 routes.

This command allows the user to enter the context to configure ECDSA public keys.

This command creates an ECDSA public key and associates it with the username. Multiple public keys can be associated with the user. The key ID is used to identify these keys for the user.

This command echoes arguments on the command line. The primary use of this command is to allow messages to be displayed to the screen in files executed with the exec command.

This command configures the Echo Request interval for monitoring the OpenFlow control channels to the controllers for this OpenFlow switch instance.

The no form of this command restores default value.

This command configures the number of consecutive Echo Reply messages that must be lost to declare OF control channel down.

The no form of this command restores default value.

This command sets the minimum echo receive interval, in milliseconds, for a session. This is not used by a BFD session for MPLS-TP.

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

When configured in a VPLS service, this command controls the number of paths that are allowed to reach a specified MAC address when that MAC in the FDB is associated to a remote all-active multi-homed ES.

The configuration of two or more ECMP paths to a specified MAC enables the aliasing function described in RFC 7432.

When used in an Epipe service, this command controls the number of paths that are allowed to reach a specified remote Ethernet tag that is associated to an ES destination.

This command configures the maximum number of tunnels that may be used as ECMP next-hops for the VPRN. This value overrides any values that are configured using the config>service>vprn>ecmp command.

The no form of this command removes the configured overriding value, and the value configured using the config>service>vprn>ecmp command is used.

This command enables ECMP and configures the number of routes for path sharing; for example, the value 2 means two equal cost routes will be used for cost sharing.

ECMP can only be used for routes learned with the same preference and same protocol.

When more ECMP routes are available at the best preference than configured in max-ecmp-routes, then the lowest next-hop IP address algorithm is used to select the number of routes configured in max-ecmp-routes.

The no form of this command disables ECMP path sharing. If ECMP is disabled and multiple routes are available at the best preference and equal cost, then the route with the lowest next-hop IP address is used.

This command enables equal-cost multipath (ECMP) and configures the number of routes for path sharing. For example, the value of 2 means that 2 equal cost routes are used for cost sharing.

ECMP groups form when the system routes to the same destination with equal cost values. Routing table entries can be entered manually (as static routes), or they can be formed when neighbors are discovered and routing table information is exchanged by routing protocols. The system can balance traffic across the groups with equal costs.

ECMP can only be used for routes learned with the same preference and same protocol. See the discussion on preferences in the application6 command.

When more ECMP routes are available at the best preference than configured by the max-ecmp-routes parameter, then the lowest next-hop IP address algorithm is used to select the number of routes configured.

The no form of this command disables ECMP path sharing. If ECMP is disabled and multiple routes are available at the best preference and equal cost, the newly updated route is used.

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

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

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

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

This command relaxes the constraint that ECMP multipaths must have the same IGP cost to reach the BGP next-hop. When VPN routes for the same IP prefix are imported into a VPRN service, they are eligible to be used as multipaths. The resulting route is programmed as an ECMP IP route.

The BGP best path selection algorithm is the basis for choosing the set of imported VPN routes that can be combined to form an ECMP route. Normally (unless an ignore-nh-metric command is configured), the BGP decision process gives higher preference to VPN routes with a lower next-hop cost if other, more significant criteria, are tied. In these circumstances, a VPN route cannot be an eligible multipath if it does not have the same next-hop cost as the best VPN route. Configuring this command removes this restriction and allows the multipaths to have different (meaning lower) next-hop costs than the best route. This broadens the applicability of multipath and can result in better load balancing in the network.

This command applies only to the following types of routes imported by a VPRN.

The no form of this command restores the default behavior that requires next-hop costs of multipaths to be equal, unless the next-hop cost is completely removed from the BGP decision process.

This command configures the ect-algorithm associated with a FID. Names are:

The algorithm for low-path-id chooses the path with the lowest metric and uses the sum of each Bridge-ID to break-ties (in this case preferring the lowest bridge identifiers).

The algorithm for high-path-id choose the path with the lowest metric and the sum of each Bridge-ID (after each one is modified by the algorithm mask) to break-ties (in this case preferring the highest bridge identifiers).

A Forwarding Identifier (FID) is an abstraction of the IEEE 802.1 SPB Base VID and represents the VLAN (B-VPLS) in IS-IS LSPs. B-VPLS services with the same FID share B-MACs and I-SIDs. (the SAP encapsulation VLAN tag may be set to the same value as the FID or to any other valid VLAN tag). One or more FIDs can be associated with an ECT-algorithm by using the FID range. User B-VPLS services may share the same FID as the control B-VPLS or use independent FIDs where each FID has an assigned ect-algorithm. B-VPLS services with i-vpls services must have an independent FID. B-VPLS services with only PBB Epipes may share FIDs with other B-VPLS services including the control B-VPLS service.

The ect-algorithm is associated with the FID and can only be changed only when there are no VPLS, SAPs or SDP bindings associated with the FID. The FID must be independent from the FID assigned to other services.

This command configures the SAP or SDP as an edge or non-edge port. If auto-edge is enabled for the SAP, this value will be used only as the initial value.

Note: The function of the edge-port command is similar to the rapid-start command. It tells RSTP that it is on the edge of the network (for example, there are no other bridges connected to that port) and, as a consequence, it can immediately transition to a forwarding state if the port becomes available.

RSTP, however, can detect that the actual situation is different from what edge-port may indicate.

Initially, the value of the SAP or spoke-SDP parameter is set to edge-port. This value will change if:

The no form of this command returns the edge port setting to the default value.

This command configures the SAP or SDP as an edge or non-edge port. If auto-edge is enabled for the SAP, this value will be used only as the initial value.

Note: On the 7750 SR and the 7950 XRS, the function of the edge-port command is similar to the rapid-start command. It tells RSTP that it is on the edge of the network (for example, there are no other bridges connected to that port) and, as a consequence, it can immediately transition to a forwarding state if the port becomes available.

RSTP, however, can detect that the actual situation is different from what edge-port may indicate.

Initially, the value of the SAP or spoke SDP parameter is set to edge-port. This value will change if:

The no form of this command returns the edge port setting to the default value.

This command enables the edit-cfg mode where changes can be made to the candidate configuration and sets the edit-point to the end of the candidate. In edit-cfg mode the CLI prompt contains edit-cfg near the root of the prompt. Commands in the candidate CLI branch, except candidate edit, are available only when in edit-cfg mode.

This command enables Ethernet in the First Mile (EFM) OAM tests loopback tests on the specified port. The EFM OAM remote loopback OAMPDU is sent to the peering device to trigger remote loopback.

When EFM OAM is disabled or shutdown on a port, the dying gasp flag for the OAMPDU is set for the OAMPDUs sent to the peer. This speeds up the peer loss detection time.

This command configures EFM-OAM attributes.

This command specifies whether to include the source address or destination address or both in the LAG/ECMP hash on IP interfaces. Additionally, when l4-load-balancing is enabled, the command also applies to the inclusion of source/destination port in the hash inputs.

The no form of this command includes both source and destination parameters.

This command specifies whether to include the source address or destination address or both in the LAG/ECMP hash on IP interfaces. Additionally, when l4-load-balancing is enabled, the command also applies to the inclusion of source/destination port in the hash inputs.

The no form of this command includes both source and destination parameters.

This command specifies whether to include source address or destination address or both in LAG/ECMP hash on IP interfaces. Additionally, when l4-load-balancing is enabled the command applies also to inclusion of source/destination port in the hash inputs.

The no form of this command includes both source and destination parameters.

The egr-percentage-of-rate command increases or decreases the active bandwidth associated with the egress port that affects the amount of egress buffer space managed by the port. Changing a ports active bandwidth using the egr-percentage-of-rate command is an effective means of artificially lowering the buffers managed by one egress port and giving them to other egress ports on the same MDA.

The egr-percentage-of-rate command accepts a percentage value that increases or decreases the active bandwidth based on the defined percentage. A value of 50% causes the active bandwidth to be reduced by 50%. A value of 150% causes the active bandwidth to be increased by 50%. Values from 1 to 1000 percent are supported.

A value of 100 (the default value) is equivalent to executing the no egr-percentage-of-rate command and restores the egress active rate to the normal value.

The no form of this command removes any artificial increase or decrease of the egress active bandwidth used for egress buffer space allocation to the port. The no egr-percentage-of-rate command sets the egress rate percentage to 100%.

This command configures the static destination VTEP IP used when originating VXLAN packets for the service.

This command configures the sharing of the egress buffers allocated to a hybrid port among the access and network contexts. By default, it is split equally between network and access.

The no form of this command reverts to the default values for the egress access and network weights.

Commands in this context configure egress ANCP policy parameters.

Commands in this context configure egress policies for Managed SAPs (MSAPs).

Commands in this context configure egress SDP parameters.

This command configures an SDP context.

Commands in this context configure egress parameters for the SLA profile.

Commands in this context configure egress Quality of Service (QoS) policies and filter policies.

If no QoS policy is defined, the system default QoS policy is used for egress processing. If no egress filter is defined, no filtering is performed.

Commands in this context configure egress filter policies.

If no sap-egress QoS policy is defined, the system default sap-egress QoS policy is used for egress processing. If no egress filter is defined, no filtering is performed.

Commands in this context configure egress SDP parameters.

Commands in this context configure egress ATM attributes for the SAP.

This command configures Ethernet access egress port parameters.

Commands in this context configure egress QoS parameters for wlan-gw tunnels.

Commands in this context configure egress buffer pool parameters which define the percentage of the pool buffers that are used for CBS calculations and specify the slope policy that is configured in the config>qos>slope-policy context.

On the MDA level, network and access egress pools are only allocated on channelized MDAs.

This command enables access to the egress fp CLI context.

This command configures Ethernet egress port parameters.

Commands in this context configure the egress QoS profile for an MLFR bundle or a Frame Relay port with FRF.12 UNI/NNI fragmentation enabled.

Commands in this context configure egress MLPPP QoS profile parameters for the multilink bundle.

Commands in this context configure egress traffic attributes for the ILMI link.

Commands in this context configure PW port egress side parameters.

This command enters egress configuration context for the vport.

This command configures egress ATM attributes for the SAP.

Commands in this context configure egress SAP parameters.

If no sap-egress QoS policy is defined, the system default sap-egress QoS policy is used for egress processing.

This command configures the egress SDP context.

Commands in this context configure PW-port egress-side parameters

Commands in this context configure egress filter policies.

Commands in this context configure the egress for a spoke SDP.

The egress node under the vpls binding is used to define the optional sap-egress QoS policy that will be used for reclassifying the egress forwarding class or profile for routed packets associated with the IP interface on the attached VPLS or I-VPLS service context.

Commands in this context configure egress ATM attributes for the SAP.

Commands in this context configure the egress for a spoke SDP.

Commands in this context configure egress network filter policies for the interface.

Commands in this context configure egress SAP Quality of Service (QoS) policies and filter policies.

If no sap-egress QoS policy is defined, the system default sap-egress QoS policy is used for egress processing. If no egress filter is defined, no filtering is performed.

The egress node under the vpls binding is used to define the optional sap-egress QoS policy that will be used for reclassifying the egress forwarding class or profile for routed packets associated with the IP interface on the attached VPLS service context.

Commands in this context configure egress network filter policies for the interface.

Commands in this context configure egress parameters.

Commands in this context configure IOM port-level Quality of Service for this application assurance group in the egress direction (traffic entering an application assurance engine).

Commands in this context configure egress parameters for the service’s video SAP.

Commands in this context configure spoke SDP egress parameters.

This command enables access to the context to associate an egress SAP Quality of Service (QoS) policy with a mirror destination SAP.

If no QoS policy is defined, the system default SAP egress QoS policy is used for egress processing.

This command is used to enter the CLI node that creates or edits egress policy entries that specify the forwarding class queues to be instantiated when this policy is applied to the network port.

The forwarding class and profile state mapping to in- and out-of-profile DiffServ Code Points (DSCPs), dot1p, and MPLS EXP bits mapping for all labeled packets are also defined in this context.

All service packets are aggregated into DiffServ-based egress queues on the network interface. The service packets are transported either with IP GRE encapsulation or over a MPLS LSP. The exception is with the IES service. In this case, the actual customer IP header has the DSCP field mapped.

All out-of-profile service packets are marked with the corresponding out-of-profile DSCP, dot1p, or the EXP bit value at network egress. All the in-profile service ingress packets are marked with the corresponding in-profile DSCP, dot1p, or EXP bit value based on the forwarding class to which they belong. The exceed-profile traffic is marked with the same value as out-of-profile traffic and the inplus-profile traffic is marked with the same value as in-profile traffic.

Commands in this context configure QoS egress queue groups. Egress queue group templates can be applied to egress Ethernet ports to create an egress queue group.

This command enables access to the context to configure egress network filter policies for the IP interface. If an egress filter is not defined, no filtering is performed.

Commands in this context configure the egress node associate an existing scheduler policy name with the customer site. The egress node is an entity to associate commands that complement the association.

Commands in this context configure spoke SDP binding egress filter parameters.

Commands in this context configure MSAP ATM egress parameters.

Commands in this context configure subscriber profile egress setting parameters.

This command configures the egress counter map for sFlow. The map must be configured so sFlow agent understands how to interpret data collected against SAP queues and policers. Multiple queues and policers can be mapped to the same traffic-type using separate line entries.

The no form of this command deletes a SAP policy queue/policer from the map.

This command configures the forwarding class to be used by the egress QoS processing. It overrides the forwarding class determined by ingress classification but not the QoS Policy Propagation via BGP.

The forwarding class and/or forwarding subclass can be overridden.

The new egress forwarding class is applicable to both SAP egress and network egress.

Commands in this context configure the egress IP filter parameters.

The no form of this command reverts to the default.

Commands in this context configure the egress IPv6 filter parameters.

The no form of this command reverts to the default.

This command specifies that the configured PBR action is applicable to egress processing. The command should only be enabled in ACL policies used by residential subscribers. Enabling egress-pbr on filters not deployed for residential subscribers is not blocked but may lead to unexpected behavior and should be avoided.

The no form of this command removes the egress-pbr designation of the filter entry's action.

This command specifies the egress policer applied to all UEs corresponding to default vlan-range (such as, group-interface) or the specified vlan-range. The policer can be created in the config>subscr-mgmt>isa-policer context. The egress policer can be overridden per UE from RADIUS via access-accept or COA.

The no form of this command reverts to the default.

Commands in this context configure Ethernet network egress port queue override parameters.

This command configures the rate of traffic leaving the network. The configured sub-rate uses packet-based accounting. An event log is generated each time the egress rate is modified unless the port is part of a LAG.

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

This command specifies the egress-rate modification that is to be applied.

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

This command is used to apply HQoS Adjustment to a subscriber. HQoS Adjustment is needed when multicast traffic flow for the subscriber is dissociated from subscriber host queues. Multicast redirection is typical such case although it can be applied in direct IPoE subscriber per-sap replication mode.

The channel bandwidth definition policy is defined in the mcac policy under the config>router>mcac>policy context. The policy is applied under the redirected interface or under the group-interface.

In order for HQoS Adjustment to take effect, sub-mcac-policy must be in a no shutdown mode and applied under the sub-profile even if mcac is not deployed.

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

This command configures the egress rate modification.

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

This command applies HQoS Adjustment to a Vport. HQoS Adjustment refers to the dynamic adjustment of the rate limit at an QoS enforcement point within a Nokia router when the multicast traffic stream is disjointed from the unicast traffic stream. This QoS enforcement point within the router represents the physical point further down in the access part of the network where the two streams join each other and potentially can cause congestion.

An example would be a PON port which is shared amongst subscriber’s multicast traffic (single copy of each channel) and subscriber’s unicast traffic. The bandwidth control point for this PON port resides in the upstream Nokia BNG node in the form of a Vport. In the case where the multicast delivery method of the BNG utilizes redirection, the multicast traffic in the BNG will flow outside of the subscriber or the Vport context and thus will bypass any bandwidth enforcement in the Nokia router. To correct this, a Vport bandwidth adjustment is necessary in the router that will account for the multicast bandwidth consumption that is bypassing Vport in the router but is present in the PON port whose bandwidth is controlled by Vport.

An estimate of the multicast bandwidth consumption on the PON port can be made at the Vport level based on the IGMP messages sourced from the subscribers behind the PON port. This process is called HQoS Adjustment.

A multicast channel bandwidth is subtracted from or added to the Vport rate limit according to the received IGMP Join/Leave messages and the channel bandwidth definition policy associated with the Vport (indirectly through a group-interface). Since the multicast traffic on the PON port is shared amongst subscribers behind this PON port, only the first IGMP Join or the last IGMP Leave per multicast channel is tracked for the purpose of the Vport bandwidth modification.

The Vport rate that will be affected by this functionality depends on the configuration:

The channel bandwidth definition policy is defined in the mcac policy in the config>router>mcac>policy context. The policy is applied under the group-interface or in case of redirection under the redirected-interface.

The rates in effect can be displayed with the following two commands:

The configuration of a scheduler policy under a Vport, which is only applicable to Ethernet interfaces, is mutually exclusive with the configuration of the egress-rate-modify parameter.

Context: HQoS Adjustment for Vport is disabled.

This command applies egress scheduler overrides. When a port scheduler is associated with an egress port, it is possible to override the following parameters:

See the 7450 ESS, 7750 SR, 7950 XRS, and VSR Quality of Service Guide for command syntax and usage for the port-scheduler-policy command.

The no form of this command removes all override parameters from the egress port or channel scheduler context. Once removed, the port scheduler reverts all rate parameters back to the parameters defined on the port-scheduler-policy associated with the port.

This command references a port scheduler policy that is defined under the config>qos>port-scheduler-policy> hierarchy. Port schedulers are instantiated on carrier IOMs towards all ISAs that are part of the lns-group.

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

This command enables the provisioning of an existing port-scheduler-policy to a port or channel.

The egress-scheduler-override node allows for the definition of the scheduler overrides for a specific port or channel.

When a port scheduler is active on a port or channel, all queues and intermediate service schedulers on the port are subject to receiving bandwidth from the scheduler. Any policers, queues, or schedulers with port-parent associations are mapped to the appropriate port priority levels based on the port-parent command parameters. Any policers, queues, or schedulers that do not have a port-parent or valid intermediate scheduler parent defined are treated as orphaned and are handled based on the port scheduler policies default or explicit orphan behavior.

The port scheduler maximum rate and priority level rate parameters may be overridden to allow unique values separate from the port-scheduler-policy-name attached to the port or channel. Use the egress-scheduler-override command to specify the port or channel specific scheduling parameters.

The no form of this command removes a port scheduler policy from an egress port or channel. Once the scheduler policy is removed, all orphaned policers, queues, and schedulers revert to a free running state governed only by the local queue or scheduler parameters. This includes any queues or schedulers with a port-parent association.

Commands in this context enter the LDP FEC prefix for the purpose of enabling egress data path statistics at the ingress LER for this FEC.

This command configures statistics in the egress data path of an originating LSP at a head-end node. The user must execute the no shutdown for this command to effectively enable statistics.

Note: SR-TE LSP egress statistics are not supported on VSR.

The same set of counters is updated for packets forwarded over any path of the RSVP-TE LSP and over the lifetime of the LSP. In steady state, the counters are updated for packets forwarded over the active path of the LSP. The active path can be the primary path, one of the secondary paths, the FRR detour path, or the FRR bypass path when the head-end node is also the PLR.

For SR-TE LSPs, egress statistics are collected independently for each path (primary, backup standby or not), and are preserved on switchover (except for non-standby).

LSP egress statistics are collected if the head-end node is also the Penultimate-Popping Hop (PHP) node for a single-hop LSP using an implicit null egress label.

RSVP-TE LSP statistics are not collected on a dynamic or a static bypass tunnel itself.

Statistics collection on two labels of the stack is possible. Please refer to config>system>ip>mpls>label-stack-statistics-count.

The no form of this command disables the statistics in the egress data path and removes the accounting policy association from the LSP.

This command configures egress statistics in an MPLS forwarding policy.

The no form of this command removes any egress statistics in a forwarding policy.

Commands in this context configure the egress statistics for IGP SIDs.

This command administratively enables the collection of egress traffic statistics for all segment routing policies.

The no form of this command disables egress traffic statistics collection for all segment routing policies.

This command enables the allocation of statistical indexes to BGP-LU route entries that are programmed on an egress data path.

The no form of this command disables the allocation of statistical indexes to BGP-LU entries.

Commands in this context configure egress-xpl settings used by the fail-on-error feature.

This command enables eiBGP load sharing so routes with both MP-BGP and IPv4 next-hops can be used simultaneously.

In order for this command to be effective, the ecmp and multipath commands for the associated VPRN instance must also be configured to allow for multiple routes to the same destination.

The no form of this command used at the global level reverts to default values.

This command configures Ethernet Local Management Interface (E-LMI) parameters for the Ethernet port. E-LMI is only supported on Ethernet access ports with Dot1q encapsulation type.

This command embeds a previously defined IPv4, IPv6, or MAC embedded filter policy or Hybrid OpenFlow switch instance into this exclusive, template, or system filter policy at the specified offset value. Rules derived from the BGP FlowSpec can also be embedded into template filter policies only.

Note: For MAC filters, embedding is supported for VSD filters or filter entries only.

The embed-filter open-flow ofs-name form of this command enables OpenFlow (OF) in GRT either by embedding the specified OpenFlow switch (OFS) instance with switch-defined-cookie disabled, or by embedding rules with sros-cookie:type “grt-cookie”, value 0, from the specified OFS instance with switch-defined-cookie enabled. The embedding filter can only be deployed in GRT context or be unassigned.

The embed-filter open-flow ofs-name system form of this command enables OF in system filters by embedding rules with sros-cookie:type “system-cookie”, value 0, from the specified OFS instance with switch-defined-cookie enabled. The embedding filter can only be of scope system.

The embed-filter open-flow ofs-name service {service-id | service-name} form of this command enables OF in VPRN/VPLS filters by embedding rules with sros-cookie:type “service-cookie”, value service-id, from the specified OFS instance with switch-defined-cookie enabled—per service rules. The embedding filter can only be deployed in the specified VPRN/VPLS service. A single VPLS service can only support OF rules per SAP or per service.

The embed-filter open-flow ofs-name sap sap-id form of this command enables OF in VPLS SAP filters by embedding rules with sros-cookie:type “service-cookie”, value service-id and flow match conditions specifying the sap-id from the specified OFS instance with switch-defined-cookie enabled—per SAP OF rules. The embedding filter must be of type exclusive and can only be deployed on the specified SAP in the context of the specified VPLS service. A single VPLS service can only support OF rules per SAP or per service.

The no embed-filter open-flow ofs-name form of this command removes the OF embedding for the GRT context.

The embed-filter flowspec form of this command enables the embedding of rules derived from BGP FlowSpec routes into the filter policy that is being configured. The optional group parameter specifies that only FlowSpec routes tagged with an interface-set extended community containing this group ID should be selected for embedding. The optional router parameter specifies the routing instance source of the BGP FlowSpec routes; if the parameter is not specified, the routing instance is derived automatically from the context in which the filter policy is applied.

The no embed-filter flowspec form of this command removes the FlowSpec filter embedding from this filter policy.

The embed-filter vsd vsd-filter-id command refers to the VSD filter ID encoded _tmnx_vsd_filter-id. The filter is created dynamically and managed exclusively using the Python script, so rules can be inserted and removed in the correct VSD filters. The command is supported with IP, IPv6, and MAC filters. For more information about VSD filter provisioning, automation, and the Python script, refer to the 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 2 Services and EVPN Guide: VLL, VPLS, PBB, and EVPN.

The no embed-filter vsd vsd-filter-id form of this command removes the VSD filter embedding from this filter policy.

The no embed-filter filter-id form of this command removes the embedding from this filter policy.

See the description of embedded filter policies in this guide for further operational details.

This command enables context to configure IPv6 embedded RP parameters.

Commands in this context configure embedded RP parameters.

Embedded RP is required to support IPv6 inter-domain multicast because there is no MSDP equivalent in IPv6.

The detailed protocol specification is defined in RFC 3956, Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address. This RFC describes a multicast address allocation policy in which the address of the RP is encoded in the IPv6 multicast group address, and specifies a PIM-SM group-to-RP mapping to use the encoding, leveraging, and extending unicast-prefix-based addressing. This mechanism not only provides a simple solution for IPv6 inter-domain ASM but can be used as a simple solution for IPv6 intra-domain ASM with scoped multicast addresses as well. It can also be used as an automatic RP discovery mechanism in those deployment scenarios that would have previously used the Bootstrap Router protocol (BSR).

The no form of this command disables embedded RP.

This command configures the IP address which is used as the DHCP server address in the context of the SAP. Typically, the configured address should be in the context of the subnet represented by the service.

The no form of this command reverts to the default setting. The local proxy server will not become operational without the emulated-server address being specified.

The no form of this command reverts to the default.

See the description for the admin-password command. If the admin-password is configured in the config>system>security>password context, then any user can enter a special administrative mode by entering the enable-admin command.

enable-admin is in the default profile. By default, all users are given access to this command.

Once the enable-admin command is entered, the user is prompted for a password. If the password matches, the user is given unrestricted access to all the commands.

The minimum length of the password is determined by the minimum-length command. The complexity requirements for the password are determined by the complexity command.

The following shows a password configuration example:

There are two ways to verify that a user is in the enable-admin mode:

Enable the user to become a system administrator.

Note: This command applies to users on RADIUS, TACACS, and LDAP.

This command enables Data MDT with PIM-ASM mode on the receiver PE node. PIM-ASM or PIM-SSM operation mode is derived based on the locally configured SSM range on the node.

If asm-mode is disabled using this command, then PIM-SSM mode is enabled for all groups, independent of the configured SSM range on the node.

This command enables unidirectional multi-point BFD session on a receiver (leaf) PE node for upstream fast failure detection over RSVP-TE P2MP LSP.

This command enables unidirectional multi-point BFD session on a sender (Root) PE node for upstream fast failure detection over RSVP-TE P2MP LSP.

This command allows BGP-VPN routes imported into the VPRN to be used as backup paths for IPv4 and/or IPv6 BGP-learned prefixes.

This command enables access to a satellite console interface for additional debugging purposes.

When configured through the 7750 SR, 7450 ESS, and 7950 XRS host CLI, the 7210 SAS console port is enabled to perform the debug function. Console commands are limited to specific show commands and no configuration or operational changes can be made using the 7210 console.

The no form of this command disables satellite console interface access.

This command enables DSCP/precedence remarking based on the profile state of a packet being forwarded by a SAP or subscriber egress policer. The DSCP/precedence can be remarked to a value independent of, or separately based on, the packet's profile, if the packet has an exceed, in-profile, or out-of-profile state.

Note: See also the description for the dynsvc-password command.

If the dynsvc-password is configured in the config>system>security>password context, then any user can enter a special dynamic services configuration mode by entering the enable-dynamic-services-config command.

The enable-dynamic-services-config command is not in the default profile. To give access to this command, the user must belong to the administrative profile or a new profile should be created.

Once the enable-dynamic-services-config command is entered, the user is prompted for a password. If the password matches, the user is given access to the dynamic services configuration. Access to static configuration is in this case prohibited.

To verify that a user is in the enable-dynamic-services-config mode, use the show users command. Users in the enable-dynamic-services-config mode lists the letter “D” next to the user’s CLI session.

The no form of this command disables the dynamic services configuration mode for this user.

This command enables the forwarding of packets with an exceed-profile state and traffic exceeding the PIR for a SAP egress or a network egress queue group (configured in the egress queue group template) policer. This traffic is forwarded as exceed-profile instead of being dropped. This parameter is not supported when policers-hqos-manageable is configured in the SAP egress QoS policy.

This command enables the forwarding of traffic exceeding the PIR for a SAP egress or a network egress queue group (configured in the egress queue group template) policer. This traffic is forwarded as exceed-profile instead of being dropped.

This command enables the ETH-LMM test within the OAM-PM session to collect per-FC counters. This command must be used in combination with the collect-lmm-fc-stats command for the entity over which the source MEP is defined. The config>oam-pm>session>ethernet>priority value must match the numerical value that represents the FC name (7 = NC, 6 = H1, 5 = EF, 4 = H2, 3 = L1, 2 = AF, 1 = L2, 0 = BE).

The OAM-PM infrastructure does not validate that the proper counting mode has been configured on the entity that is linked to the source MEP, and does not validate that the FC and priority have been configured. The show>eth-cfm>collect-lmm-fc-stats command may be used to display the entities and the FCs on those entities that have established individual FC counters.

Sessions that launch from the same source MEP must use the same counting model; either collect-lmm-fc-stats for individual counters for the defined FCs, or collect-lmm-stats for a single all-encompassing counter.

Individual OAM-PM sessions must be configured if multiple Ethernet LMM tests are required for different FCs. Cross-session validation occurs to ensure that a source MEP does not include multiple tests that are using the same priority.

The no form of this command removes all previously defined FCs and stops counting for those FCs.

This command enables graceful shutdown of telnet sessions.

The no form of this command disables graceful shutdown of telnet sessions.

This command enables the functions required for looking up routes in the Global Route Table (GRT) when the lookup in the local VRF fails. If this command is enabled without the use of a static-route option (as subcommand to this parent), a lookup in the local VRF is preferred over the GRT. When the local VRF returns no route table lookup matches, the result from the GRT is preferred.

The no form of this command disables the lookup in the GRT when the lookup in the local VRF fails.

This command enables vendor specific extensions to ICMP.

This command enables the collection of ingress interface IP stats. This command is only applicable to IP statistics, and not to uRPF statistics.

If enabled, then the following statistics are collected:

Note: Octet statistics for IPv4 and IPv6 bytes at IP interfaces include the Layer 2 frame overhead.

This command specifies whether VPNs can exchange routes across autonomous system boundaries, providing model B connectivity.

The no form of this command disallows ASBRs to advertise VPRN routes to their peers in other autonomous systems.

This command enables MAC accounting functionality on this interface.

The no form of this command disables MAC accounting functionality on this interface.

This command enables MAC accounting functionality on this interface.

The no form of this command disables MAC accounting functionality on this interface.

This command enables MAC Accounting functionality for the interface.

This command enables SPT switchover for default MDT. On enable, PIM instance resets all MDTs and re-initiate setup.

The no form of this command disables SPT switchover for default MDT. On disable, PIM instance resets all MDTs and re-initiate setup.

When this command is present, the graceful restart capability sent by this router indicates support for NOTIFICATION messages. If the peer also supports this capability then the session can be restarted gracefully (while preserving forwarding) if either peer sends a NOTIFICATION message due to some type of event or error.

When this command is present, the graceful restart capability sent by this router indicates support for NOTIFICATION messages. If the peer also supports this capability, then the session can be restarted gracefully (while preserving forwarding) if either peer needs to send a NOTIFICATION message due to some type of event or error.

When this command is added to the configuration of a group or neighbor, it causes every inbound IPv4, IPv6, and label-IPv4 route from that peer to be marked with one of the following origin validation states:

By default (when no family parameter is present in the command) or when all the family options are specified, all unicast IPv4 (AFI1/SAFI1), label-IPv4 (AFI1/SAFI4), and unicast IPv6 (AFI2/SAFI1) routes are evaluated to determine their origin validation states. When only a subset of the family options are present, then only the corresponding address family routes are evaluated.

This command applies to all types of VPRN BGP peers, generally, it should only be applied to EBGP peers and groups that contain only EBGP peers.

The no form of this command disables the inspection of received routes from the peer to determine origin validation state.

When the enable-origin-validation command is added to the configuration of a group or neighbor, it causes every inbound IPv4 and/or IPv6 route from that peer to be marked with one of the 3 following origin validation states:

By default (when neither the ipv4 or ipv6 option is present in the command) or when both the ipv4 and ipv6 options are specified, all unicast IPv4 (AFI1/SAFI1), label-IPv4 (AFI1/SAFI4), unicast IPv6 (AFI2/SAFI1), and label-IPv6 (AFI2/SAFI4) routes are evaluated to determine their origin validation states. When only the ipv4 or ipv6 option is present, only the corresponding address family routes (unlabeled and labeled) are evaluated.

The enable-origin-validation command applies to all types of BGP peers, but as a general rule, it should only be applied to EBGP peers and groups that contain only EBGP peers.

This command enables BGP peer tracking.

This command enables BGP peer tracking. BGP peer tracking allows a BGP peer to be dropped immediately if the route used to resolve the BGP peer address is removed from the IP routing table and there is no alternative available. The BGP peer will not wait for the holdtimer to expire; therefore, the BGP re-convergence process is accelerated.

The no form of this command disables peer tracking.

This command includes the mirrored packet system’s port ID. The system port ID can be used to identify which port the packet was received or sent on. Inclusion of the port ID is only supported for mirror-dest type ppp.

The no form of this command disables the inclusion of the port ID of the system in the packet.

When this command is configured all received VPN-IP routes, regardless of route target, are imported into the dummy VRF, where the BGP next-hops are resolved. The label-route-transport-tunnel under config>router>bgp>next-hop-resolution determines what types of tunnels are eligible to resolve the next-hops. If a received VPN-IP route from IBGP peer X is resolved and selected as best so that it can be re-advertised to an IBGP peer Y, and the BGP next-hop is modified towards peer Y (by using the next-hop-self command in Y’s group or neighbor context or by using a next-hop action in an export policy applied to Y) then BGP allocates a new VPRN service label value for the route, signals that new label value to Y and programs the IOM to do the corresponding label swap operation. The supported combinations of X and Y are outlined below:

The no form of this command causes the re-advertisement of a VPN-IP route between one IBGP peer and another IBGP peer does not cause a new VPRN service label value to be signaled and programmed even if the BGP next-hop is changed through group/neighbor configuration or policy.

Nokia recommends leaving this command disabled for scaling and convergence reasons.

By default, the video ISA has both client and server capability for RET (retransmission). The client capability can be disabled to enable higher performance

The no form of the command enables higher performance.

This command enables the shell and kernel commands.

Note: This command should only be used with authorized direction from the Nokia Technical Assistance Center (TAC).

This command enables system to auto creates ESM hosts upon successful WPP authentication. The default host must be configured under SAP on the subscriber SAP to redirect unauthenticated client traffic to the web portal.

The no form of this command reverts to the default.

This command allows editing of VSD services just like normal services. As this is an action that should only be executed by authorized personnel, the activation of this command is protected by the use of a password, defined under configure system security password vsd-password.

Commands in this context configure encapsulation options for the mirrored traffic. Note that the use of encap is mutually exclusive with SAP or spoke SDP options in the same mirror destination. Only one type of encapsulation can be specified for a single mirror destination. Slicing and encap are mutually exclusive in the same mirror-dest context.

This command creates a new QoS sub-context in B-VPLS SAP egress context. The user can define encapsulation groups, referred to as encap-group, based on the ISID value in the packet’s encapsulation and assign a QoS policy and a scheduler policy or aggregate rate limit to the group.

This command defines an encapsulation group which consists of a group of ISID values. All packets forwarded on the egress of a B-VPLS SAP which payload header matches one of the ISID value in the encap-group will use the same QoS policy instance and scheduler policy or aggregate rate limit instance.

The user adds or removes members to the encap-group one at a time or as a range of contiguous values using the member command. However, when the qos-per-member option is enabled, members must be added or removed one at a time. These members are also referred to as ISID contexts.

The user can configure one or more encap-groups in the egress context of the same B-SAP, therefore defining different ISID values and applying each a different SAP egress QoS policy, and optionally a different scheduler policy/agg-rate. ISID values are unique within the context of a B-SAP. The same ISID value cannot be re-used in another encap-group under the same B-SAP but can be re-used in an encap-group under a different B-SAP. Finally, if the user adds to an encap-group an ISID value which is already a member of this encap-group, the command causes no effect. The same if the user attempts to remove an ISID value which is not a member of this encap-group.

Once a group is created, the user will assign a SAP egress QoS policy, and optionally a scheduler policy or aggregate rate limit, using the following commands:

config>service>vpls>sap>egress>encap-defined-qos>encap-group>qos sap-egress-policy-id

config>service>vpls>sap>egress>encap-defined-qos>encap-group>scheduler-policy scheduler-policy-name

config>service>vpls>sap>egress>encap-defined-qos>encap-group>agg-rate kilobits-per-second

A SAP egress QoS policy must first be assigned to the created encap group before the user can add members to this group. Conversely, the user cannot perform the no qos command until all members are deleted from the encap-group.

An explicit or the default SAP egress QoS policy will continue to be applied to the entire B-SAP but this will serve to create the set of egress queues which will be used to store and forward a packet which does not match any of the defined ISID values in any of the encap-groups for this SAP.

Only the queue definition and fc-to-queue mapping from the encap-group SAP egress QoS policy is applied to the ISID members. All other parameters configurable in a SAP egress QoS policy must be inherited from egress QoS policy applied to the B-SAP.

Furthermore, any other CLI option configured in the egress context of the B-SAP will continue to apply to packets matching a member of any encap-group defined in this B-SAP.

The keyword qos-per-member allows the user to specify that a separate queue set instance and scheduler/agg-rate instance will be created for each ISID value in the encap-group. By default, shared instances will be created for the entire encap-group.

When the B-SAP is configured on a LAG port, the ISID queue instances defined by all the encap-groups applied to the egress context of the SAP will be replicated on each member link of the LAG. The set of scheduler/agg-rate instances will be replicated per link or per IOM or XMA depending if the adapt-qos option is set to link/port-fair mode or distribute mode. This is the same behavior as that applied to the entire B-SAP in the current implementation.

The no form of this command deletes the encap-group.

This command defines the sub-set of traffic on this port affected by this MACsec sub-port.

In order to establish an end-to-end communication between the remote MACsec peers encrypting VLAN-tagged traffic, the MKA packets have to be able to travel over the network following the same path as the encrypted traffic. MKA packets are generated with specific tags depending on the traffic match criteria configured, as shown in Table 49.

The no form of this command removes all traffic sub-set definitions from the MACsec sub-port.

This command enables the adjustment of the queue and subscriber aggregate rate based on the last mile Ethernet or ATM encapsulation.

The data path computes the adjusted frame size real-time for each serviced packet from a queue by adding the actual packet size to the fixed offset provided by CPM for this queue and variable AAL5 padding.

When this command is enabled, the fixed packet offset is derived from the encapsulation type value signaled in the Access-loop-encapsulation sub-TLV in the Vendor-Specific PPPoE Tags or DHCP Relay Options as per RFC 4679. If the user specifies an encapsulation type with the command, this value is used as the default value for all hosts of this subscriber until a host session signaled a valid value. The signaled value is applied to this host only and the remaining hosts of this subscriber continue to use the user entered default type value if configured, or no offset is applied. However, hosts of the same subscriber using the same SLA profile and which are on the same SAP will share the same instance of FC queues. In this case, the last valid encapsulation value signaled by a host of that same instance of the SAP egress QoS policy will override any previous signaled or configured value.

If the user manually applied a constant byte offset to each packet serviced by the queue by configuring the packet-byte-offset, it will have no effect on the net offset computed for the packet. This net offset is stored in the subscriber host table.

The procedures for handling signaling changes or configuration changes affecting the subscriber profile are as follows:

The avg-frame-size parameter in the subscriber profile is ignored.

If the user specifies an encapsulation type with the command, this value is used as the default value for all hosts of this subscriber until a host session signaled a valid value. The signaled value is applied to this host and other hosts of the same subscriber sharing the same SLA profile and which are on the same SAP. The remaining hosts of this subscriber continue to use the user entered default type value if configured, or no offset is applied.

If the user enables/disables the encap-offset option, or changes the parameter value of the encap-offset option, CPM immediately triggers a re-evaluation of subscribers hosts using the corresponding subscriber profile and an update the IOM with the new fixed offset value.

If a subscriber has a static host or an ARP host, the subscriber host continues to use the user-configured default encapsulation type value or the last valid encapsulation value signaled in the PPPoE tags or DHCP relay options by other hosts of the same subscriber which use the same SLA profile instance. If none was signaled or configured, then no rate adjustment is applied.

When the encap-offset option is configured in the subscriber profile, the subscriber host queue rates, that is, CLI and operational PIR and CIR as well as queue bucket updates, the queue statistics, that is, forwarded, dropped, and HQoS offered counters use the last-mile frame-over-the-wire format. The scheduler policy CLI and operational rates also use LM-FoW format. The port scheduler max-rate and the priority level rates and weights, if a Weighted Scheduler Group is used, are always entered in CLI and interpreted as local port frame-over-the-wire rates. The same is true for an agg-rate-limit applied to a Vport. Finally the subscriber agg-rate-limit is entered in CLI as last-mile frame-over-the-wire rate. The system maintains a running average frame expansion ratio for each queue to convert queue rates between these two formats.

The no form of this command reverts to the default.

This command is applicable within the LAC/LNS context. It provides the last mile link encapsulation information that is needed for proper (shaping) rate calculations and interleaving delay in the last mile.

The encapsulation value will be taken from the following sources in the order of priority:

In case that the encapsulation information is not provided by any of the existing means (LUDB, RADIUS, AVP signaling, PPPoE Tags), then by default pppoea-null encapsulation will be in effect.

The following values are supported encapsulation values on LNS in the 7750 SR.

encap-type:

The values are not supported encapsulation values on LNS in the 7750 SR.

This command specifies a range of encapsulation tags as the host identifications. The encapsulation tag is dot1q or qinq on Ethernet port.

For dot1q, the start/end-tag is single number, range from 0-4094; for QinQ, the start/end-tag format is x.y, x or y could be “*”, which means ignore inner or outer tag.

Note: This command is only used when encap-tag-range is configured as one of the match-list parameters.

The no form of this command removes the encapsulation tag range from the configuration.

This command specifies a range of encapsulation tags as the host identifications.

Note: This command is only used when encap-tag-separate-range is configured as one of the match-list parameters.

The no form of this command removes the range of encapsulation tags from the configuration.

If different from default, this command overrides the value specified by l2-ap-encap-type on wlan-gw level. See the description of l2-ap-encap-type for more detail. This value can only be changed while the l2-ap is shut down.

The no form of this command sets the default value.

This command configures the encapsulation method used to distinguish customer traffic on an Ethernet access port, or different VLANs on a network port.

The no form of this command restores the default.

This command configures the encapsulation method used to distinguish customer traffic on an access SONET/SDH channel sub-port.

When the encap-type is set to ATM the CRC default cannot be changed.

When the encap-type is ATM, ATM sub-layer verification (GR-1248-CORE, Generic Requirements for Operations of ATM Network Elements (NEs)) is automatically enabled. The result of the verification includes:

The encap-type is only required when configuring a SONET/SDH path for access mode.

The no form of this command restores the default.

This command configures the encapsulation method used to on the specified port, path, or channel. This parameter can be set on both access and network ports.

When the encap-type is set to ATM the CRC, timeslots, scrambling (if applicable), and idle-cycle-flags are set to ATM defaults respectively. When the encap-type is changed from ATM, those parameters are set to their non-ATM defaults.

When the encap-type is ATM, ATM sub-layer verification (GR-1248-CORE, Generic Requirements for Operations of ATM Network Elements (NEs)) is automatically enabled. When ATM PLCP cell mapping is used, the results of this verification include:

When ATM direct cell mapping is used, the result of the verification includes:

The no form of this command restores the default.

This command configures the encapsulation method used to distinguish customer traffic on a LAG. The encapsulation type is configurable on a LAG port. The LAG port and the port member encapsulation types must match when adding a port member.

If the encapsulation type of the LAG port is changed, the encapsulation type on all the port members will also change. The encapsulation type can be changed on the LAG port only if there is no interface associated with it. If the MTU is set to a non-default value, it will be reset to the default value when the encap type is changed.

The no form of this command restores the default.

This command configures the encapsulation method used to distinguish customer traffic on a LAG. The encapsulation type is configurable on a LAG port. The LAG port and the port member encapsulation types must match when adding a port member.

If the encapsulation type of the LAG port is changed, the encapsulation type on all the port members will also change. The encapsulation type can be changed on the LAG port only if there is no interface associated with it. If the MTU is set to a non-default value, it will be reset to the default value when the encap type is changed.

The no form of this command reverts to the default.

This command configures the encapsulation type on a PW port. Customer Ethernet frames can be single-tagged or double-tagged, and this command determines the number of tags that the SR OS will check (and strip) on PW-SAP ingress and insert on PW-SAP egress.

The no form of this command removes the configuration.

This command specifies the maximum size of encapsulated tunnel packet for the ipsec-tunnel, ip-tunnel, or the dynamic tunnels terminated on the ipsec-gw. If the encapsulated IPv4 or IPv6 tunnel packet exceeds the encapsulated-ip-mtu, then the system fragments the packet against the encapsulated-ip-mtu.

The no form of this command reverts to the default.

This command configures the tunnel encapsulated IP MTU.

The no form of this command reverts to the default.

This command specifies the data encapsulation for an ATM PVCC delimited Epipe SAP. The definition references RFC 2684, Multiprotocol Encapsulation over ATM AAL5, and to the ATM Forum LAN Emulation specification.

Ingress traffic that does not match the configured encapsulation will be dropped.

This command specifies the data encapsulation for an ATM PVCC delimited Ipipe SAP. The definition references RFC 2684, Multiprotocol Encapsulation over ATM AAL5, and to the ATM Forum LAN Emulation specification. Ingress traffic that does not match the configured encapsulation will be dropped.

This command configures RFC 2684, Multiprotocol Encapsulation over ATM Adaptation Layer 5, encapsulation for an ATM PVCC delimited SAP. This command specifies the data encapsulation for an ATM PVCC delimited SAP. The definition also references the ATM Forum LAN Emulation specification. The encapsulation is driven by the services for which the SAP is configured.

Ingress traffic that does not match the configured encapsulation will be dropped.

This command specifies whether or not Wavetracker keys should be encoded on the transmitted optical signal.

This command configures an HTTP header enrichment template field static string.

The no form of this command removes the template field static string.

This command configures the encoding type that is used for telemetry notifications in accordance with the definitions in the gNMI OpenConfig standard.

This command configures the encoding type of the payload carried by the GMPLS LSP; line is the only supported type.

This command binds an encryption key-group to a WLAN-GW soft-GRE group interface. When configured in the inbound direction, received packets must be encrypted using one of the valid security-associations configured for the key-group. When configured in the outbound direction, L2oMPLSoGRE packets egressing the node use the “active-outbound-sa” associated with the key-group configured.

The no form of this command removes the encryption keygroup from the inbound or outbound group interface.

This command is used to bind a key group to a router interface for inbound or outbound packet processing. When configured in the outbound direction, packets egressing the router use the active-outbound-sa associated with the configured key group. When configured in the inbound direction, received packets must be encrypted using one of the valid security associations configured for the key group.

The no form of this command removes the key group from the router interface in the specified direction.

This command is used to create a key group. Once the key group is created, use the command to enter the key group context or delete a key group.

The no form of the command removes the key group. Before using the no form, the key group association must be deleted from all services that are using this key group.

This command is used to bind a key group to an SDP, VPRN service, or PW template for inbound or outbound packet processing. When configured in the outbound direction, packets egressing the node use the active-outbound-sa associated with the key group configured. When configured in the inbound direction, received packets must be encrypted using one of the valid security associations configured for the key group. Services using the SDP will be encrypted.

The encryption (enabled or disabled) configured on an SDP used to terminate a Layer 3 spoke SDP of a VPRN always overrides any VPRN-level configuration for encryption.

Encryption is enabled after the outbound direction is configured.

For PW template changes, the following tools command must be executed after the configuration changes are made: tools>perform>service>eval-pw-template>allow-service-impact. This command applies the changes to services that use the PW template.

The no form of the command removes the key group from the SDP or service in the specified direction (inbound or outbound).

This command specifies the offset of the encryption in MACsec packet.

The encryption-offset is distributed by MKA (Key-server) to all parties.

It is signaled via MACsec capabilities. There are four basic settings for this. Table 51 breaks down the settings.

The no form of this command rejects all arriving traffic whether MACsec is secured or not.

This command configures start of summer time settings.

Commands in this context configure the value and attributes of SRv6 End SID function of a locator. The End SID function encodes the basic behavior of a prefix or a node SID.

The End SID function for each SRH mode must be statically allocated. The value is not automatically allocated by default.

The no form of this command removes the specified End function.