This command configures the facility code for messages sent to the syslog target host.

Multiple syslog IDs can be created with the same target host but each syslog ID can only have one facility code. If multiple facility codes are entered, the last facility-code entered overwrites the previous facility-code.

If multiple facilities need to be generated for a single syslog target host, then multiple log-id entries must be created, each with its own filter criteria to select the events to be sent to the syslog target host with a given facility code.

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

This command configures the syslog facility. The syslog facility is an information field associated with a syslog message. It is defined by the syslog protocol and provides an indication of which part of the system originated the message.

This command configures a syslog facility. For more information, refer to the 7450 ESS, 7750 SR, 7950 XRS, and VSR System Management Guide. The config>log>syslog>level hierarchy also applies to this context.

This command configures the facility code for messages sent to the syslog target host.

Multiple syslog IDs can be created with the same target host but each syslog ID can only have one facility code. If multiple facility codes are entered, the last facility-code entered overwrites the previous facility-code.

If multiple facilities need to be generated for a single syslog target host, then multiple log-id entries must be created, each with its own filter criteria to select the events to be sent to the syslog target host with a given facility code.

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

Allows the facility MEP to move from alarming only to network actionable function. This means a facility MEP will not merely report the defect conditions but will be able to action based on the transition of the MEP state. Without this command the facility MEP will only monitor and report and conditions of the MEP do not affect related services.

This command allows the facility MEP to move from alarming only to network actionable function. This means that a MEP facility reports both the defect conditions and the actions that are based on the transition of the MEP state.

The no form of this command causes the facility MEP to only monitor and report conditions on the MEPs that do not affect related services.

This command allows the operator to include the sender-id TLV information that was specified under the config>eth>system>sender-id context for facility base MEPs. When this option is present under the maintenance association, the specific MPs in the association included the sender-id TLV information in ETH-CFM PDUs. MEPs include the sender-id TLV for CCM (not sub second CCM enabled MEPs), LBM/LBR, and LTM/LTR. MIPs include this value in the LBR and LTR PDUs.

Note: LBR functions reflect all TLVs received in the LBM unchanged including the SenderID TLV. This command produces an error when a bridge-identifier is configured under the association. Facility MEPs do not support the bridge-identifier. Transmission of the Management Domain and Management Address fields are not supported in this TLV.

This command specifies the action to take when no match is found in the cache.

The no form of this command reverts to the default.

This command configures the fail action when a packet matches with a VAS filter entry in a specific direction, but no mapping exists for the specified SF-IP or ESI in the specified EVPN service.

The no form of this command removes the fail action from the configuration.

This command controls the behavior of the card when any one of a specific set of card level errors is encountered in the system. When the fail-on-error command is enabled, and any one (or more) of the specific errors is detected, then the Operational State of the card is set to Failed. This Failed state will persist until the clear card command is issued (reset) or the card is removed and re-inserted (re-seat). If the condition persists after re-seating the card, then Nokia support should be contacted for further investigation.

Enabling fail-on-error is only recommended when the network is designed to be able to route traffic around a failed card (redundant cards, nodes or other paths exist).

The list of specific errors includes:

On platforms without independent IOM/IMM and CPM cards, the node is rebooted if fail-on-error is enabled and one of the card level errors is encountered.

The tmnxEqCardPChipError is only considered as a trigger for card fail-on-error for ingress FCS errors (not egress FCS errors), and only for Ethernet MDAs or IMMs.

Note that upon the detection of the event/error in the system, the reporting of the event (logs) and the fail-on-error behavior of the card are independent. Log event control configuration will determine whether the events are reported in logs (or SNMP traps, and so on) and the fail-on-error configuration will determine the behavior of the card. This implies that the card can be configured to fail-on-error even if the events are suppressed (some may be suppressed in the system by default). In order to facilitate post-failure analysis, Nokia recommends that you enable the reporting of the specific events/errors (configure log event-control) when fail-on-error is enabled.

This command enables the fail-on-error feature. If an MDA is experiencing too many Egress XPL Errors, this feature causes the MDA to fail. This can force an APS switchover or traffic re-route. The purpose of this feature is to avoid situations where traffic is forced to use a physical link that suffers from errors but is still technically operational.

The feature uses values configured in the config>card>mda>egress-xpl context. When this feature is enabled on a MDA, if window consecutive minutes pass in which the MDA experiences more than threshold Egress XPL Errors per minute, then the MDA will be put in the failed state.

The no form of this command disables the feature on the MDA.

This command configures the mode of operation during an operational failure of this application assurance group when no application assurance engines are available to service traffic. When enabled, all traffic that was to be inspected will be dropped. When disabled, all traffic that was to be inspected will be forwarded without any inspection as if the group was not configured at all.

This command configures the maximum number of supported simultaneously failures in the active-active intra-chassis NAT redundancy model. Traffic from the failed ISAs is distributed over the remaining ISA in the system. Memory resources are reserved in every ISA to accommodate new mappings from the failed ISA. However, bandwidth is not reserved and each ISA operates at max speed in all conditions (with failure or without the failure).

NAT translations are not preserved across switchovers and consequently they will have to be re-initiated by the clients.

For this command to take effect, the intra-chassis redundancy mode must be set to active-active (config>isa>nat-group>redundancy active-active).

This command defines the number of objects should be down for the site to be declared down. Both administrative and operational status must be evaluated and if at least one is down, the related object is declared down.

Commands in this context configure failover parameters.

Commands in this context configure LAC multi-chassis redundancy.

This command configures the action to take when LSP BFD fails on an LDP LSP.

The system generates an SNMP trap if BFD goes down on an LSP, regardless of whether a failure action is configured or not.

The no form of this command removes the failure action.

This command configures the ability to bind the operational state of a spoke-SDP to the state of its VCCV BFD session.

If failure-action down is configured, the spoke-SDP is taken operationally down if the associated VCCV BFD session goes down. This configuration also allows BFD packets to be forwarded on an otherwise operationally down spoke-SDP in order to test the spoke-SDP connectivity.

The no form of this command removes the failure action.

This command configures what action occurs when LSP BFD fails on an RSVP, SR-TE, or LDP LSP.

A failure action of down means an LSP is marked as unusable in TTM. If it appears as a shortcut in RTM, the route is removed. This failure action can only be configured on RSVP LSPs.

A failure action of failover causes the active path of an RSVP LSP to switch to the secondary or next-preference available secondary path. This option is only available for RSVP LSPs. It is not applicable to one-hop-p2p and mesh-p2p auto LSPs.

A failure action of failover-or-down means that a switchover from the active path is triggered on failure of the BFD session on the active path (primary or standby). If there is no available path to switch to, then the LSP is taken operationally down. For RSVP-TE LSPs, this failure action causes the two best-preference standby paths to be programmed in the data path, in addition to the primary.

The system generates an SNMP trap if BFD goes down on an LSP, regardless of whether a failure action is configured or not.

The no form of this command removes the failure action.

This command configures the action to take when LSP BFD fails on an RSVP LSP.

The system generates an SNMP trap if BFD goes down on an LSP, regardless of whether or not a failure action is configured.

The no form of this command removes the failure action.

This command defines the failure mode for egress traffic of SAPs/network interfaces that use this link-map-profile when neither primary nor secondary links of this profile are available.

Commands in this context configure attributes related to the automatic switch fabric recovery process.

The automatic switch fabric recovery process is triggered when there are two resets of an IOM/XCM due to ICC failures within a small time frame. The recovery process involves the sequential resetting of SFM in case the issues are due to one of the SFM in the ICC communication path. As the final step in the recovery process, a CPM switchover is triggered to reset the active CPM.

This command configures the count, when reached, that causes the transition of the IPv4 interface from operationally up to operationally down because of a ping template failure.

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

This command configures the action when no RADIUS server is available; servers are either out of service or are in a probing state.

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

This command specifies the fallback path computation method used if all configured PCEs are down or the signaling overload and the redelegation timer has expired. This method is used regardless of whether the LSP is PCE-controlled and PCE-computed, or just PCE-computed.

The no form of this command removes the fallback path computation method used.

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

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

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

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

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

This command specifies the address family for the micro-BFD session over the associated LAG links.

This command specifies the convergence family used for route convergence.

This command configures family-specific LLGR parameters for BGP peers.

This command configures the set of BGP address families (AFI plus SAFI) to be supported by the applicable VPRN BGP sessions.

The no form of this command restores the default, which corresponds to unlabeled IPv4 unicast routes (AFI 1, SAFI 1) only.

This command specifies if the lsp-template is for use in IPv4 or IPv6 SR-TE LSP.

This command is optional in a IPv4 SR-TE auto-LSP but must be set to ipv6 value in a IPv6 SR-TE auto-LSP. By default, this command is set to ipv4 value for backward compatibility.

When establishing both IPv4 and IPv6 SR-TE mesh auto-LSPs with the same parameters and constraints, a separate LSP template of type mesh-p2p-srte must be configured for each address family with the family CLI leaf set to the IPv4 or IPv6 value. SR-TE one-hop auto-LSPs can only be established for either IPv4 or IPv6 family, but not both. The family leaf in the LSP template of type one-hop-p2p-srte should be set to the desired IP family value.

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

This command defines the address family for the flow types that should not be sent to the associated cflowd collector.

Multiple family types can be defined in this context to filter out multiple address families to a given collector.

The no form of this command removes the address family definition, allowing all address family types to be exported to the associated collector.

This command configures the IP family used for route convergence.

This command configures the set of BGP address families (AFI plus SAFI) to be supported by the base router BGP sessions.

The no form of this command restores the default, which corresponds to unlabeled IPv4 unicast routes (AFI 1, SAFI 1) only.

This command configures family-specific LLGR parameters for BGP peers.

This command configures the address family context for configuring next-hop resolution of BGP label routes.

This command creates the context to configure next-hop resolution of unlabeled IPv4 or unlabeled IPv6 routes by certain tunnel types in the tunnel table.

This command configures the address families that are reported to a BMP monitoring station.

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

Commands in this context configure the resolution of IGP IPv4 and IGP IPv6 prefix families, as well as SR-ISIS IPv4 and SR-ISIS IPv6 tunnel families using IGP shortcuts.

This command specifies the address family of an adjacency set in IS-IS.

The no form of this command reverts to the default.

Commands in this context configure the resolution of the IGP IPv4 prefix family or SR-OSPF IPv4 tunnel using IGP shortcuts.

Commands in this context configure the resolution of the IGP IPv6 prefix family using IGP shortcuts.

This command specifies address families as matching conditions.

This command adds a configuration context for family-specific behaviors that relate to processing prefix SID attributes containing SRv6 TLVs.

The no form of this command deletes the family configuration context.

This command specifies an address family to use when configuring whether to strip SRv6 TLVs from BGP routes advertised to peers.

The no form of this command deletes the context.

This command configures the IP address (GMPLS Loopback Address) of the far-end UNI-C router.

The no form of this command removes the far-end address

This command is used on a destination router in a remote mirroring solution. See the description for the remote-source command for additional information.

When using L2TPv3, MPLS-TP or LDP IPv6 LSP SDPs in the remote mirroring solution, the destination node should be configured with remote-src>spoke-sdp entries. For all other types of SDPs, remote-source>far-end entries are used.

Up to 50 far-end entries can be specified.

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

This command configures the system IP address of the far-end destination router for the Service Distribution Point (SDP) that is the termination point for a service.

The far-end IP address must be explicitly configured. The destination IP address must be that of an SR OS and for a GRE SDP it must match the system IP address of the far end router.

If the SDP uses GRE for the destination encapsulation, the IP address is checked against other GRE SDPs to verify uniqueness. If the IP address is not unique within the configured GRE SDPs, an error is generated and the IP address is not associated with the SDP. The local device may not know whether the IP address is actually a system IP interface address on the far-end device.

If the SDP uses MPLS encapsulation, the far-end address is used to check LSP names when added to the SDP. If the “to IP address” defined within the LSP configuration does not exactly match the SDP far-end address, the LSP will not be added to the SDP and an error will be generated. Alternatively, an SDP that uses MPLS can have an MPLS-TP node with an MPLS-TP node-id and (optionally) a global ID. In this case, the SDP must use an MPLS-TP LSP and the SDP signaling parameter must be set to off.

An SDP cannot be administratively enabled until a far-end ip-address or MPLS-TP node-id is defined. The SDP is operational when it is administratively enabled (no shutdown) and the far-end ip-address is contained in the IGP routing table as a host route. OSPF ABRs should not summarize host routes between areas. This can cause SDPs to become operationally down. Static host routes (direct and indirect) can be defined in the local device to alleviate this issue.

On a tunnel configured as SDP with delivery type of eth-gre-bridged, this command designates L2oGRE tunnel end points. This is the only configuration option allowed for this type of SDP.

The no form of this command removes the currently configured destination IP address for the SDP. The ip-address parameter is not specified and will generate an error if used in the no far-end command. The SDP must be administratively disabled using the config service sdp shutdown command before the no far-end command can be executed. Removing the far-end IP address will cause all lsp-name associations with the SDP to be removed.

This command enables fast leave.

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

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

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

This command enables IGMP fast-leave processing.

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

This command enables fast leave.

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

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

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

The no form of this command reverts to the default.

This command enables fast leave. When fast leave processing is enabled, the router immediately removes a SAP or SDP from the IP multicast group when it detects an MLD leave on that SAP or SDP. Fast leave processing allows the switch to remove a SAP or SDP that sends a leave from the forwarding table without first sending out group-specific queries to the SAP or SDP, and thus speeds up the process of changing channels (zapping).

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

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

The no form of this command reverts to the default.

This command enables fast leave.

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

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

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

This command enables LDP Fast-Reroute (FRR) procedures. When enabled, LDP uses both the primary next-hop and LFA next-hop, when available, for resolving the next-hop of an LDP FEC against the corresponding prefix in the routing table. This will result in LDP programming a primary NHLFE and a backup NHLFE into the forwarding engine for each next-hop of a FEC prefix for the purpose of forwarding packets over the LDP FEC.

When any of the following events occurs, LDP instructs in the fast path the forwarding engines to enable the backup NHLFE for each FEC next-hop impacted by this event:

The tunnel-down-dump-time option or the label-withdrawal-delay option, when enabled, does not cause the corresponding timer to be activated for a FEC as long as a backup NHLFE is still available.

Because LDP can detect the loss of a neighbor/next-hop independently, it is possible that it switches to the LFA next-hop while IGP is still using the primary next-hop. Also, when the interface for the previous primary next-hop is restored, IGP may re-converge before LDP completed the FEC exchange with it neighbor over that interface. This may cause LDP to de-program the LFA next-hop from the FEC and blackhole traffic. In order to avoid this situation, it is recommended to enable IGP-LDP synchronization on the LDP interface.

When the SPF computation determines there is more than one primary next-hop for a prefix, it will not program any LFA next-hop in RTM. Thus, the LDP FEC will resolve to the multiple primary next-hops that provide the required protection.

The backup-sr-tunnel option enables the use of SR tunnel, as a remote LFA or TI-LFA backup tunnel next-hop by an LDP FEC.

As a pre-requisite, the user must enable the stitching of LDP and SR in the LDP-to-SR direction. That is because the LSR must perform the stitching of the LDP ILM to SR tunnel when the primary LDP next-hop of the FEC fails. Thus LDP must listen to SR tunnels programmed by the IGP in TTM but the mapping server feature is not required.

Assuming the following:

IGP SPF will run both the base LFA and the TI-LFA algorithms and if it does not find a backup next-hop for a prefix of an LDP FEC, it will also run the remote LFA algorithm. If IGP finds a TI-LFA or a remote LFA tunnel next-hop, LDP programs the primary next-hop of the FEC using a LDP NHLFE and programs the LFA backup next-hop using a LDP NHLFE pointing to the SR tunnel endpoint. Note that the LDP packet is not “tunneled” over the SR tunnel. The LDP label is actually stitched to the segment routing label stack. LDP points both the LDP ILM and the LTN to the backup LDP NHLFE which itself uses the SR tunnel endpoint.

The behavior of the feature is thus similar to the LDP-to-SR stitching feature, except the behavior is augmented to allow the stitching of an LDP ILM/LTN to a SR tunnel also when the primary LDP next-hop of the FEC fails.

If the LDP FEC primary next-hop failed and LDP has pre-programmed a remote LFA or TI-LFA next-hop with a LDP backup NHLFE pointing to SR tunnel, the LDP ILM/LTN switches to it. Note that if for some reason the failure impacted only the LDP tunnel primary next-hop but not the SR tunnel primary next-hop, the LDP backup NHLFE will effectively point to the primary next-hop of the SR tunnel and traffic of the LDP ILM/LTN will follow this path instead of the TI-LFA or remote LFA next-hop of the SR tunnel until the latter is activated.

This feature is limited to IPv4 /32 prefixes in both LDP and SR.

The no form of this command disables the use of SR tunnels as backups for LDP FECs and disables LDP FRR.

This command creates a pre-computed detour LSP from each node in the path of the LSP. In case of failure of a link or LSP between two nodes, traffic is immediately rerouted on the pre-computed detour LSP, thus avoiding packet-loss.

When fast-reroute is enabled, each node along the path of the LSP tries to establish a detour LSP as follows:

Fast reroute is available only for the primary path. No configuration is required on the transit hops of the LSP. The ingress router will signal all intermediate routers using RSVP to set up their detours. TE must be enabled for fast-reroute to work.

If an LSP is configured with fast-reroute frr-method specified but does not enable CSPF, then global revertive will not be available for the LSP to recover.

The no form of the fast-reroute command removes the detour LSP from each node on the primary path. This command will also remove configuration information about the hop-limit and the bandwidth for the detour routes.

The no form of fast-reroute hop-limit command reverts to the default value.

Note: A one-to-one detour backup LSP cannot be used at the PLR for ABR node protection. As a result, a PLR node does not signal a one-to-one detour LSP for ABR protection. In addition, the ABR node rejects a Path message that it has received from a third-party implementation configured with a detour object and a loose ERO next-hop. The Path message is rejected regardless of whether the cspf-on-loose-hop command is enabled on the node. When the router transits ABR for the detour path, the router rejects the signaling of an inter-area detour backup LSP.

This command enables BIER Fast Reroute (FRR).

The no form of this command disables BIER FRR.

This command is used to enable fast detection of initial bandwidth on a child policer or queue associated with the policy. Multiple offered rate counter reads may be performed per the sampling interval. The system accumulates these counter values and evaluates the delta at the conclusion of the sampling interval. When fast-start is enabled, the system identifies all children associated with the policy that enter the inactive state (current offered rate is zero). Any inactive ‘fast start’ child that has a positive offered counter during a sampling period bypasses the normal sampling interval and does an immediate offered rate evaluation.

This option is intended for use with children that would benefit from faster than normal startup detection, typically those of a real-time nature.

When this parameter is not enabled, the system uses the normal sampling interval behavior of both newly active and currently active children.

The no form of this command is used to restore the sampling-interval-based offered rate evaluation for newly active children.

This command is used to enable fast detection of lack of offered rate on a child policer or queue associated with the policy. Multiple offered rate counter reads may be performed per sampling interval. The system accumulates these counter values and evaluates the delta at the conclusion of the sampling interval. When fast-stop is enabled, the system bypasses the sampling interval for any currently active ‘fast stop’ child that has a zero offered counter measurement and does an immediate offered rate evaluation using the zero value.

This option is intended for use with children where other children would benefit from faster than normal inactive detection, typically those of a real-time nature.

When this parameter is not enabled, the system uses the normal sampling interval behavior of both newly inactive and currently active children.

The no form of this command is used to restore the sampling-interval-based offered rate evaluation for newly inactive children.

This command creates a template that configures resiliency parameters per FSG.

The no form of this command deletes the template.

This command configures associated B-MAC addresses for fault propagation on a B-VPLS SAP or SDP binding. The statement can appear up to four times in the configuration to support four remote B-MAC addresses in the same remote B-VPLS. The configured VPLS must be a B-VPLS.

The no form of this command removes the specified MAC name or MAC address from the list of Fault Propagation B-MAC addresses associated with the SAP (or SDP).

This command configures the fault propagation for the MEP.

This command configures the fault propagation for the MEP.

This command configures the fault propagation for the MEP.

This command configures the fault propagation for the MEP.

This command creates individual counters for the specified FCs without regard for profile. All countable packets that match a configured FC, regardless of profile, will be included in this counter.

A differential is performed when this command is re-entered. Omitted FCs will stop counting, newly added FCs will start counting, and unchanged FCs will continue to count.

Up to eight FCs may be specified. An FC that is specified as part of this command for this specific context cannot be specified as a profile-aware FC using the fc-in-profile command under the same context.

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

This command creates individual counters for the specified FCs without regard for profile. All countable packets that match a configured FC, regardless of profile, will be included in this counter.

A differential is performed when this command is re-entered. Omitted FCs will stop counting, newly added FCs will start counting, and unchanged FCs will continue to count.

Up to eight FCs may be specified. An FC that is specified as part of this command for this specific context cannot be specified as a profile-aware FC using the fc-in-profile command under the same context.

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

This command creates individual counters for the specified FCs without regard for profile. All countable packets that match a configured FC, regardless of profile, will be included in this counter.

A differential is performed when this command is re-entered. Omitted FCs will stop counting, newly added FCs will start counting, and unchanged FCs will continue to count.

An FC that is specified as part of this command for this specific context cannot be specified as a profile-aware FC using the fc-in-profile command under the same context.

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

This command creates individual counters for the specified FCs without regard for profile. All countable packets that match a configured FC, regardless of profile, will be included in this counter.

A differential is performed when this command is re-entered. Omitted FCs will stop counting, newly added FCs will start counting, and unchanged FCs will continue to count.

Up to eight FCs may be specified. An FC that is specified as part of this command for this specific context cannot be specified as a profile-aware FC using the fc-in-profile command under the same context.

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

This command configures the mapping of FCs to up to six forwarding sets for the class-based forwarding (CBF) of an LDP FEC or a BGP prefix over IGP shortcuts.

All FCs are mapped to set 1 as soon as the policy is created. The user can then make changes to the mapping of FCs as required. An FC that is not added to the class forwarding policy is thus always mapped to set 1. An FC can only be mapped to one forwarding set. One or more FCs can map to the same set. The user can indicate the initial default set by including the default-set option.

The default forwarding set forwards packets of an FC when all LSPs of the forwarding set that the FC maps to become operationally down. The router uses the user-configured default set as the initial default set if no default is configured; otherwise, it elects the lowest numbered set as the default forwarding set in a class forwarding policy. When the last LSP in a default forwarding set goes into an operationally down state, the router designates the next lowest numbered set as the new default forwarding set.

This command configures the sampling weight.

This command maps one or more system forwarding classes to a Diff-Serv Class Type (CT). The default mapping is shown in Table 53.

The no form of this command reverts to the default mapping for the forwarding class name.

This command configures remark FC action on flows matching this AQP entry. When enabled, all packets for all flows matching this AQP entry will be remarked to the configured forwarding class.

The no form of this command stops FC remarking action on packets belonging to flows matching this AQP entry.

This command configures the forwarding classes that have their sessions prioritized.

This command specifies a forwarding class for all mirrored packets transmitted to the destination SAP or SDP overriding the default (be) forwarding class. All packets are sent with the same class of service to minimize out-of-sequence issues. The mirrored packet does not inherit the forwarding class of the original packet.

When the destination is on a SAP, a single egress queue is created that pulls buffers from the buffer pool associated with the fc-name.

When the destination is on an SDP, the fc-name defines the DiffServ-based egress queue that is used to reach the destination. The fc-name also defines the encoded forwarding class of the encapsulation.

The FC configuration also affects how mirrored packets are treated at the ingress queuing point on the line cards. One ingress queue is used per mirror destination (service) and that is an expedited queue if the configured FC is expedited (one of nc, h1, ef or h2). The ingress mirror queues have no CIR, but a line-rate PIR.

The no form of this command reverts the mirror-dest service ID forwarding class to the default forwarding class.

This command indicates the forwarding class and profile of the MPLS echo request packet.

When an MPLS echo request packet is generated in CPM and is forwarded to the outgoing interface, the packet is queued in the egress network queue corresponding to the specified FC and profile parameter values. The marking of the packet's EXP is dictated by the LSP-EXP mappings on the outgoing interface.

When the MPLS echo request packet is received on the responding node, The FC and profile parameter values are dictated by the LSP-EXP mappings of the incoming interface.

When an MPLS echo reply packet is generated in CPM and is forwarded to the outgoing interface, the packet is queued in the egress network queue corresponding to the FC and profile parameter values determined by the classification of the echo request packet, which is being replied to, at the incoming interface. The marking of the packet's EXP is dictated by the LSP-EXP mappings on the outgoing interface. The ToS byte is not modified. Table 54 summarizes this behavior.

This command specifies the FC and profile parameters that are used to indicate the forwarding class and profile of the MPLS echo request packet.

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

This command sets the forwarding class designation for TWAMP Light packets that are sent through the node and exposed to the various QoS functions on the network element.

The no form of this command restores the default value.

This command sets the forwarding class designation for DM packets sent through the node and exposed to the various QoS functions on the network element.

The no form of this command reverts the default value.

This command specifies the forwarding class and profile state of an egress policed packet that is to be mapped to another forwarding class and profile, where the profile state is that of the resulting profile after the packet has been processed by the egress policer.

The new forwarding class and profile state is configured using the maps-to command.

The traffic remarking is based on the marking configured for the forwarding class and profile of the traffic after being policed but before it is remapped.

The no form of this command deletes the forwarding class and profile remapping statement, including the maps-to command.

The fc command creates a class or subclass instance of the forwarding class fc-name. When the fc-name is created, classification actions can be applied and the subclass can be used in match classification criteria. Attempting to use an undefined subclass in a classification command will result in an execution error and the command will fail.

The no form of this command removes all the explicit queue mappings for fc-name forwarding types. The queue mappings revert to the default queues for fc-name. To successfully remove a subclass, all associations with the subclass in the classification commands within the policy must first be removed or diverted to another forwarding class or subclass.

The fc fc-name node within the SAP egress QoS policy is used to contain the explicitly defined queue mapping and dot1p marking commands for fc-name. When the mapping for fc-name points to the default queue and the dot1p marking is not defined, the node for fc-name is not displayed in the show configuration or save configuration output unless the detail option is specified.

The no form of this command removes the explicit queue mapping and dot1p marking commands for fc-name. The queue mapping reverts to the default queue for fc-name and the dot1p marking (if appropriate) uses the default of 0.

This command configures the mapping of the system forwarding class to the MLPPP classes for this profile. There is a many-to-one relationship between the system forwarding class and an MLPPP class.

This command is used to enter the CLI node to configure QoS parameters for the specified forwarding class. The fc command overrides the default parameters for that forwarding class from the values defined in the network default policy.

The no form of this command removes the forwarding class name configuration. The forwarding class reverts to the parameters defined in the default network policy.

This command is used to enter the CLI node to configure QoS parameters for the specified forwarding class. The FC name represents a CLI parent node that contains parameters describing the egress marking criteria of packets flowing through it. This command overrides the default parameters for that forwarding class from the values defined in the network default policy. It can also be used to redirect packets to a policer or queue in a network egress queue group instance.

The no form of this command removes the forwarding class name configuration. The forwarding class reverts to the parameters defined in the default network policy.

The fc command is used to enter the forwarding class mapping context for the given fc-name. Each forwarding class maps by default to queues 1 (unicast) and 9 (multipoint).

The fc command is used to enter the forwarding class mapping context for the given fc-name. Each forwarding class has a default mapping depending on the egress queue group template. The system-created policer-output-queue template contains queues 1 and 2 by default with queue 1 being best-effort and queue 2 expedited. Forwarding classes be, l1, af and l2 all map to queue 1 by default. Forwarding classes h1, ef, h2 and nc all map to queue 2 by default. More queues may be created within the policer-output-queues template and the default forwarding classes may be changed to any defined queue within the template.

When all other user-defined egress queue group templates are created, only queue 1 (best-effort) exists and all forwarding classes are mapped to that queue. Other queues may be created and the forwarding classes may be changed to any defined queue within the template.

Besides the default mappings within the templates, the egress queue group template forwarding class queue mappings operate the same as the forwarding class mappings in a sap-egress QoS policy.

The template forwarding class mappings are the default mechanism for mapping egress policed traffic to a queue within an egress port queue group associated with the template. If a queue-id is explicitly specified in the QoS policy forwarding class policer mapping, and that queue exists within the queue group, the template forwarding class mapping is ignored.

On the 7450 ESS and 7750 SR, egress policed subscriber traffic works in a slightly different way. The subscriber and subscriber host support destination and organization strings are used to identify the egress port queue group. In this instance, the forwarding class mappings are always used and any queue overrides in the QoS policy are ignored. If neither string exists for the subscriber host, the egress queue group queue-id can be derived from either the QoS policy policer mapping or the template forwarding class queue mappings.

The no form of this command is used to return the specified forwarding class to its default template queue mapping.

This command specifies the forwarding class name. The forwarding class name represents an egress queue. The fc fc-name represents a CLI parent node that contains sub-commands or parameters describing the egress characteristics of the queue and the marking criteria of packets flowing through it. The fc command overrides the default parameters for that forwarding class defined in the network default policy policy-id 1.

This command assigns a forwarding class to packets matching the filter entry.

The no version of this command removes the forwarding class marking action.

This command creates individual counters for the specified FCs without regard for profile. All countable packets that match a configured FC, regardless of profile, will be included in this counter.

A differential is performed when this command is re-entered. Omitted FCs will stop counting, newly added FCs will start counting, and unchanged FCs will continue to count.

Up to eight FCs may be specified. An FC that is specified as part of this command for this specific context cannot be specified as a profile-aware FC using the fc-in-profile command under the same context.

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

This command makes an explicit association between a forwarding class and an LSP. The LSP name must exist and must have been associated with this SDP using the command config>service>sdp>lsp. Multiple forwarding classes can be associated with the same LSP. However, a forwarding class can only be associated with a single LSP in a given SDP. All subclasses will be assigned to the same LSP as the parent forwarding class.

This command associates a forwarding-class and optionally priority with the routes matched by a route policy entry. The command takes effect when the action of the route policy entry is accept, next-entry, or next-policy. It has no effect except in route policies applied as VRF import policies, BGP import policies, or RIP import policies.

The no form of this command removes the QoS association of the routes matched by the route policy entry.

This command configures the FC name for the TWAMP Light packet.

This command creates individual counters for the specified FCs with regard for profile. All countable packets that match a configured FC and are deemed to be in-profile will be included in this counter.

A differential is performed when this command is re-entered. Omitted FCs will stop counting, newly added FCs will start counting, and unchanged FCs will continue to count.

Up to eight FCs may be specified. An FC that is specified as part of this command for this specific context cannot be specified as a profile-unaware FC using the fc command under the same context.

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

This command creates individual counters for the specified FCs with regard for profile. All countable packets that match a configured FC and are deemed to be in-profile will be included in this counter.

A differential is performed when this command is re-entered. Omitted FCs will stop counting, newly added FCs will start counting, and unchanged FCs will continue to count.

Up to eight FCs may be specified. An FC that is specified as part of this command for this specific context cannot be specified as a profile-unaware FC using the fc command under the same context.

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

This command creates individual counters for the specified FCs with regard for profile. All countable packets that match a configured FC and are deemed to be in profile will be included in this counter.

A differential is performed when this command is re-entered. Omitted FCs will stop counting, newly added FCs will start counting, and unchanged FCs will continue to count.

An FC that is specified as part of this command for this specific context cannot be specified as a profile-unaware FC using the fc command under the same context.

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

This command creates individual counters for the specified FCs with regard for profile. All countable packets that match a configured FC and are deemed to be in profile will be included in this counter.

A differential is performed when this command is re-entered. Omitted FCs will stop counting, newly added FCs will start counting, and unchanged FCs will continue to count.

Up to eight FCs may be specified. An FC that is specified as part of this command for this specific context cannot be specified as a profile-unaware FC using the fc command under the same context.

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

This command creates individual counters for the specified FCs with regard for profile. All countable packets that match a configured FC and are deemed to be in-profile will be included in this counter.

A differential is performed when this command is re-entered. Omitted FCs will stop counting, newly added FCs will start counting, and unchanged FCs will continue to count.

Up to eight FCs may be specified. An FC that is specified as part of this command for this specific context cannot be specified as a profile-unaware FC using the fc command under the same context.

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

This command sets the watermark to trigger the SNMP trap if the FCC bandwidth or session exceeds the configured percentage. The bandwidth is the available egress bandwidth of the ISA. The SNMP trap is cleared when the consumption is lowered by 10%. For example, if the system resource of the available bandwidth is 10 Gb/s and the watermark is configured to be 90%, the SNMP trap is raised as the bandwidth exceeds 9 Gb/s (90% of 10 Gb/s). The SNMP trap is cleared when the bandwidth drops below 8.1 Gb/s (10% of 9 Gb/s = 0.9 Gb/s, and 9 Gb/s - 0.9 Gb/s = 8.1 Gb/s). The default value of the watermark is set at 90% of the system resources for both bandwidth and session.

This command sets the burst rate at which the Fast Channel Change (FCC) server will send unicast data to the FCC client above the received rate to allow the client to catchup to the multicast stream.

This parameter is only applicable if the FCC server mode is burst.

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

This command configures the channel type for the bundle/channel. The channel type is used in the video policy to set various Fast Channel Change (FCC) parameters including the type of FCC and various FCC rates.

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

This command configures the minimum time duration, in milliseconds, of the Fast Channel Change (FCC) burst. The value of this object determines the starting point of the FCC burst. If the current Group of Pictures (GOP) has less than the minimum duration worth of data, FCC burst begins from the previous GOP.

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

This command enables the FCC server capability for the ISA video group. FCC server cannot be enabled if ad insertion or the local RET server is enabled.

FCC server parameters can be configured in a multicast information policy or a service, but the parameters will have no effect if the FCC server is disabled or if the video group is administratively disabled (shutdown).

The no form of the command disables the FCC server.

This command enables the Fast Channel Change (FCC) server and sets the mode to send the FCC unicast stream.

The mode indicates how the FCC server will send information to the client. When burst is specified, the FCC server will send the channel at a nominally faster rate than the channel was received based on the applicable fcc-burst setting. When dent is specified, the FCC server will selectively discard frames from the original stream based on the applicable dent-threshold setting. If no mode is specified, burst is the default mode.

The no form of the command disables the FCC server at that context and subordinate contexts.

This command enables Fast Channel Change (FCC) for a multicast bundle or channel. Additional parameters such as fcc-channel-type should also be configured to match the characteristics of the bundle/channel.

The no form of the command disables removes the FCC configuration for the bundle/channel context and implies the setting is inherited from a higher context or the default policy.

This command enables debugging the FCC server.

By default, the video ISA will wait for 5 minutes before closing the RTCP session from the subscriber. The RTCP session can be adjusted from 5 second to 5 minutes. The timeout is applicable to both RET and FCC RTCP sessions.

The no form of the command reverts to the default.

This command specifies the sending of average frame delay for a specified direction.

The no form of this command deletes the specified average direction.

Note: All directions can be specified if all directions are important for reporting. However, only enable those directions that are required.

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

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

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

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

This command specifies the maximum number of MAC entries in the forwarding database (FDB) for the VPLS instance on this node.

The fdb-table-size specifies the maximum number of forwarding database entries for both learned and static MAC addresses for the VPLS instance.

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

This command configures the maximum system FDB table size, which is dependent on the chassis type. CPMs with at least 16 GB of memory are required when exceeding 500k MAC addresses in a system. The table size cannot be reduced below its default value, which is also chassis-dependent.

The maximum system FDB table size also limits the maximum FDB table size of any card within the system.

The no version of this command sets the table size to its default.

The command default depends on the chassis type and available memory.

This command enables the associated DS-3 interface to respond to remote loop signals.

The DS-3 far-end alarm and control (FEAC) signal is used to send alarm or status information from the far-end terminal back to the local terminal. DS-3 loopbacks at the far-end terminal from the local terminal are initiated.

The no form of this command prevents the associated DS-3 interface from responding to remote loop signals.

This command enables specific satellite functionality that may have specific satellite requirements, such as software version.

The no form of this command disables the specific satellite functionality.

Commands in this context configure the Gx features.

This command enables the Forwarding Error Correction (FEC) encoder/decoder and specifies the FEC encoder/decoder mode to use when enabled.

The following rules must be followed:

Note that FEC cannot be disabled on OTU3 encapsulated OC768 or 40-Gigabit Ethernet by the no fec command. Therefore, the default depends on the port type. The default for OTU3 encapsulated OC768 or 40-Gigabit Ethernet is fec enhanced.

The no form of this command disables FEC encoder and decoder.

This command configures a limit on the number of FECs which an LSR will accept from a given peer and add into the LDP label database. The limit applies to the aggregate count of all FEC types including service FEC. Once the limit is reached, any FEC received will be released back to the peer. This behavior is different from the per-peer import policy which will still accept the FEC into the label database but will not resolve it.

When the FEC limit for a peer is reached, the LSR performs the following actions:

If a legitimate FEC is released back to a peer, while the FEC limit was exceeded, the user must have a means to replay that FEC back to the router LSR once the condition clears. This is done automatically if the peer is an SR OS-based router and supports the LDP overload status TLV (SR OS 11.0R5 and higher). Third-party peer implementations must support the LDP overload status TLV or provide a manual command to replay the FEC.

The threshold option allows to set a threshold value when a trap and an syslog message are generated as a warning to the user in addition to when the limit is reached. The default value for the threshold when not configured is 90%.

The log-only option causes a trap and syslog message to be generated when reaching the threshold and limit. However, LDP labels are not released back to the peer.

If the user decreases the limit value such that it is lower than the current number of FECs accepted from the peer, the LDP LSR raises the trap for exceeding the limit. In addition, it will set overload for peers which signaled support for LDP overload protection capability TLV. However, no existing resolved FECs from the peer which does not support the overload protection capability TLV should be de-programmed or released.

A different trap is released when crossing the threshold in the upward direction, when reaching the FEC limit, and when crossing the threshold in the downward direction. However the same trap will not be generated more often than 2 minutes apart if the number of FECs oscillates around the threshold or the FEC limit.

This command defines a way to originate a FEC (with a swap action) for which the LSR is not egress, or to originate a FEC (with a pop action) for which the LSR is egress.

This command configures statistics in the egress data path at the ingress LER or LSR for an LDP FEC. The user must execute the no shutdown command for this command to effectively enable statistics. The egress data path counters will be updated for both originating and transit packets. Originating packets may be service packets or IP user and control packets forwarded over the LDP LSP when used as an IGP shortcut. Transit packets of the FEC which are label switched on this node.

When ECMP is enabled and multiple paths exist for a FEC, the same set of counters are updated for each packet forwarded over any of the NHLFEs associated with this FEC and for as long as this FEC is active.

The statistics can be enabled on prefix FECs imported from both LDP neighbors and T-LDP neighbors (LDP over RSVP). LDP sets up egress statistics collection for the LDP tunnels whose FECs match the exact prefix specified in this command. Service FECs, that is, FEC 128 and FEC 129, are not valid. LDP FEC egress statistics are collected at the Penultimate-Popping Hop (PHP) node for a LDP FEC using an implicit null egress label.

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

This command enables or disables the advertisement of a FEC type on a given LDP session or Hello adjacency to a peer.

The config>router>ldp>if-params>if>ipv6>fec-type-capability command is not supported on the 7450 ESS.

This command specifies whether LDP will provide translation between non-compliant FEC 129 formats of Cisco. Peer LDP sessions must be manually configured towards the non-compliant Cisco PEs.

When enabled, Cisco non-compliant format will be used to send and interpret received label release messages that is the FEC129 SAII and TAII fields will be reversed.

When the disabled, Cisco non-compliant format will not be used or supported. Peer address has to be the peer LSR-ID address.

The no form of this command returns the default.

This command specifies the FIB priority for VPRN BGP routes.

This command specifies the FIB priority for VPRN BGP routes.

This command enables the collection of extra state information related to the forwarding table state of certain IP routes, TTM tunnels, and MPLS LFIB entries. This extra state can be retrieved by gNMI telemetry subscriptions targeted to the following YANG paths:

If this command is not configured, no information is displayed by the following show commands:

The no form of this command disables the collection of this extra state.

This command specifies which fields to include in the exported cflowd template.

Certain fields, such as source and destination IP addresses, are always included in the exported template, so they are not optional.

The no form of this command removes the specified field from the template.

This command specifies the fields to insert into the HTTP header. The command must be repeated for each field to be inserted. The same field cannot be inserted twice into the header under different header names.

Note: AA can insert two copies of the following fields in the same HTTP header (with a different header name): imei-hyphenated, imei-hyphenated-2, imsi, imsi-2, static-string, static-string-2, user-location-raw, and user-location-raw2.

The no form of this command removes the specified field so that it is not inserted into the HTTP header.

Commands in this context configure an override value for a field within a header within a packet to be launched by the OAM find-egress tool.

This command configures how fields included in the exported cflowd template are selected.

The no form of this command reverts to the legacy field selection type.

This command specifies the file for the URL list.

The no form of this command removes the url-list object.

Specifies the context to enter and perform file system operations. When entering the file context, the prompt changes to reflect the present working directory. Navigating the file system with the cd .. command results in a changed prompt.

The exit all command leaves the file system/file operation context and returns to the operational root CLI context. The state of the present working directory is maintained for the CLI session. Entering the file command returns the cursor to the working directory where the exit command was issued.

This command creates the context to configure a file policy that is used as the destination for an event log or billing (accounting) file.

This command defines the file location and characteristics that are to be used as the destination for a log event message stream or accounting/billing information. The file defined in this context is subsequently specified in the to command under log-id or accounting-policy to direct specific logging or billing source streams to the file destination.

A file policy can only be assigned to either one log-id or one accounting-policy. It cannot be reused for multiple instances. A file policy and associated file definition must exist for each log and billing file that must be stored in the file system.

A file is created when the file policy defined in this command is selected as the destination type for a specific log or accounting record. Log files are collected in a “log” directory. Accounting files are collected in an “act” directory.

The file names for a log are created by the system as summarized in Table 55.

Where:

When initialized, each file contains:

If the process of writing to a log file fails (for example, the compact flash card is full) and if a backup location is not specified or fails, the log file will not become operational even if the compact flash card is replaced. Enter either a clear log command or a shutdown/no shutdown command to reinitialize the file.

If the primary location fails (for example, the compact flash card fills up during the write process), a trap is sent and logging continues to the specified backup location. This can result in truncated files in different locations.

The no form of this command removes the file policy from the configuration. A file policy can only be removed from the configuration if the policy is not the designated output for a log destination. The actual log or accounting file remain on the file system when a file policy is deleted.

This command specifies the file transfer protocol to use between the 7750 SR or 7950 XRS host and 7210 SAS Ethernet satellite.

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

This command creates a new file transmission profile or enters the configuration context of an existing file-transmission-profile.

The file-transmission-profile context defines transport parameters for protocol such as HTTP, include routing instance, source address, timeout value, and so on.

The no form of the command removes the profile name from the configuration.

This command specifies the file-transmission-profile for the url-entry. When the system downloads a CRL from the configured URL in the url-entry it will use the transportation parameter configured in the file-transmission-profile. auto-crl-update supports Base/Management/VPRN routing instance. vpls-management is not supported. In case of VPRN, the HTTP server port can only be 80 or 8080.

The no form of this command removes the specified profile name.

This command specifies a file URL for the FTP or TFTP server, including the filename for packet capture transfer. After the file URL is entered, the system attempts to establish a connection and creates a file using the filename specified. The command prompt displays an error and rejects the file URL if the session establishment fails, if write privilege to remote server fails, or if the session experiences a sudden termination. If the FTP or TFTP server is unreachable, the command prompt is halted for further input until the retires are timed out after 24 seconds (after four attempts of about six seconds each). This command overwrites any file on the FTP or TFTP server with the same filename.

The no form of this command removes the file-url instance and stops the packet capture and file transfer session.

This command assigns a DHCP filter to the group-interface. This feature is used where the SR 7750 is the second DHCP relay or where DHCP messages are snooped for subscriber management. The filter can be used to bypass host creation, drop DHCP message, or perform no action.

The no form of this command reverts to the default.

This command assigns a DHCP6 filter to the group interface. This feature is used where the SR 7750 is the second DHCP6 relay or where DHCP6 messages are snooped for subscriber management. The filter can be used to bypass host creation, drop DHCP6 message, or perform no action.

The no form of this command reverts to the default.

This command associates an IP filter policy with an ingress or egress Service Access Point (SAP) or IP interface. An IP filter policy can be associated with spoke SDPs. Filter policies control the forwarding and dropping of packets based on IP or MAC matching criteria.

The filter command is used to associate a filter policy with a specified ip-filter-id with an ingress or egress SAP. The ip-filter-id must already be defined before the filter command is executed. If the filter policy does not exist, the operation fails and an error message returned.

In general, filters applied to SAPs (ingress or egress) apply to all packets on the SAP. One exception is non-IP packets are not applied to IP match criteria, so the default action in the filter policy applies to these packets.

The no form of this command removes any configured filter ID association with the SAP or IP interface. The filter ID itself is not removed from the system unless the scope of the created filter is set to local. To avoid deletion of the filter ID and only break the association with the service object, use scope command within the filter definition to change the scope to local or global. The default scope of a filter is local.

This command associates a filter policy with an ingress or egress Service Access Point (SAP). Filter policies control the forwarding and dropping of packets based on the matching criteria. MAC filters are only allowed on Epipe and Virtual Private LAN Service (VPLS) SAPs.

The filter command is used to associate a filter policy with a specified ip-filter-id or ipv6-filter-id (7750 SR) with an ingress or egress SAP. The filter policy must already be defined before the filter command is executed. If the filter policy does not exist, the operation fails and an error message returned.

In general, filters applied to SAPs (ingress or egress) apply to all packets on the SAP. One exception is non-IP packets are not applied to the match criteria, so the default action in the filter policy applies to these packets.

The no form of this command removes any configured filter ID association with the SAP. The filter ID itself is not removed from the system unless the scope of the created filter is set to local. To avoid deletion of the filter ID and only break the association with the service object, use scope command within the filter definition to change the scope to local or global. The default scope of a filter is local.

This command associates an IP filter policy or MAC filter policy with an ingress or egress Service Access Point (SAP) or IP interface.

Filter policies control the forwarding and dropping of packets based on IP or MAC matching criteria. There are two types of filter policies: IP and MAC. Only one type may be applied to a SAP at a time.

The filter command is used to associate a filter policy with a specified filter ID with an ingress or egress SAP. The filter ID must already be defined before the filter command is executed. If the filter policy does not exist, the operation will fail and an error message returned.

In general, filters applied to SAPs (ingress or egress) apply to all packets on the SAP. One exception is non-IP packets are not applied to IP match criteria, so the default action in the filter policy applies to these packets.

This command is only supported in 'classic' configuration-mode (configure system management-interface configuration-mode classic).

The no form of this command removes any configured filter ID association with the SAP or IP interface. The filter ID itself is not removed from the system unless the scope of the created filter is set to local. To avoid deletion of the filter ID and only break the association with the service object, use scope command within the filter definition to change the scope to local or global. The default scope of a filter is local.

This command applies to VPRN services only to filter for ingress home traffic.

This command applies to VPRN services only to filter for cross-connect traffic.

This command applies to VPRN services only to filter for ingress data center traffic.

This command associates a filter policy with an ingress or egress Service Access Point (SAP) or IP interface.

Filter policies control the forwarding and dropping of packets based on IP matching criteria. Only one filter can be applied to a SAP at a time.

The filter command is used to associate a filter policy with a specified ip-filter-id with an ingress or egress SAP. The ip-filter-id must already be defined before the filter command is executed. If the filter policy does not exist, the operation will fail and an error message returned.

IP filters apply only to RFC 2427-routed IP packets. Frames that do not contain IP packets will not be subject to the filter and will always be passed, even if the filter's default action is to drop.

The no form of this command removes any configured filter ID association with the SAP or IP interface. The filter ID itself is not removed from the system unless the scope of the created filter is set to local. To avoid deletion of the filter ID and only break the association with the service object, use scope command within the filter definition to change the scope to local or global. The default scope of a filter is local.

This command associates an IP filter policy with an ingress or egress Service Access Point (SAP) or IP interface.

Filter policies control the forwarding and dropping of packets based on IP matching criteria. Only one filter can be applied to a SAP at a time.

The filter command is used to associate a filter policy with a specified filter-id with an ingress or egress SAP. The filter-id must already be defined before the filter command is executed. If the filter policy does not exist, the operation will fail and an error message returned.

IP filters apply only to RFC 2427-routed IP packets. Frames that do not contain IP packets will not be subject to the filter and will always be passed, even if the filter's default action is to drop.

The no form of this command removes any configured filter ID association with the SAP or IP interface. The filter ID itself is not removed from the system unless the scope of the created filter is set to local. To avoid deletion of the filter ID and only break the association with the service object, use scope command within the filter definition to change the scope to local or global. The default scope of a filter is local.

IPv6 filters are only supported by the 7450 ESS and 7750 SR but are not supported on a Layer 2 SAP that is configured with QoS MAC criteria. Also, MAC filters are not supported on a Layer 2 SAP that is configured with QoS IPv6 criteria.

Commands in this context configure filter parameters.

This command associates an IP filter policy with an ingress or egress IP interface. Filter policies control the forwarding and dropping of packets based on IP matching criteria.

The filter-id must already be defined before the filter command is executed. If the filter policy does not exist, the operation fails and an error message returned.

IP filters apply only to RFC 2427-routed IP packets. Frames that do not contain IP packets will not be subject to the filter and will always be passed, even if the filter's default action is to drop.

The no form of this command removes any configured filter ID association with the IP interface. The filter ID itself is not removed from the system unless the scope of the created filter is set to local.

This command associates an IP filter policy filter policy with an ingress or egress spoke SDP.

Filter policies control the forwarding and dropping of packets based on matching criteria.

MAC filters are only allowed on Epipe and Virtual Private LAN Service (VPLS) SAPs.

The filter command is used to associate a filter policy with a specified ip-filter-id with an ingress or egress spoke SDP. The ip-filter-id must already be defined in the config>filter context before the filter command is executed. If the filter policy does not exist, the operation fails and an error message returned.

In general, filters applied to SAPs or spoke SDPs (ingress or egress) apply to all packets on the SAP or spoke SDPs. One exception is non-IP packets are not applied to IP match criteria, so the default action in the filter policy applies to these packets.

The no form of this command removes any configured filter ID association with the SAP or IP interface. The filter ID itself is not removed from the system unless the scope of the created filter is set to local. To avoid deletion of the filter ID and only break the association with the service object, use scope command within the filter definition to change the scope to local or global. The default scope of a filter is local.

This command associates an IP filter policy with an ingress or egress IP interface. Filter policies control the forwarding and dropping of packets based on IP matching criteria.

The filter-id must already be defined before the filter command is executed. If the filter policy does not exist, the operation fails and an error message returned.

IP filters apply only to RFC 2427-routed IP packets. Frames that do not contain IP packets will not be subject to the filter and will always be passed, even if the filter's default action is to drop.

The no form of this command removes any configured filter ID association with the IP interface. The filter ID itself is not removed from the system unless the scope of the created filter is set to local.

This command associates an IP filter policy with an ingress or egress Service Access Point (SAP) or IP interface. Filter policies control the forwarding and dropping of packets based on IP matching criteria.

The filter command is used to associate a filter policy with a specified filter ID with an ingress or egress SAP. The filter ID must already be defined before the filter command is executed. If the filter policy does not exist, the operation fails and an error message returned.

In general, filters applied to SAPs (ingress or egress) apply to all packets on the SAP. One exception is non-IP packets are not applied to IP match criteria, so the default action in the filter policy applies to these packets.

The no form of this command removes any configured filter ID association with the SAP or IP interface. The filter ID itself is not removed from the system unless the scope of the created filter is set to local. To avoid deletion of the filter ID and only break the association with the service object, use scope command within the filter definition to change the scope to local or global. The default scope of a filter is local.

This command creates a context for an event filter. An event filter specifies whether to forward or drop an event or trap based on the match criteria.

Filters are configured in the filter filter-id context and then applied to a log in the log-id log-id context. Only events for the configured log source streams destined to the log ID where the filter is applied are filtered.

Changes made to an existing filter using any of the sub-commands are immediately applied to the destinations where the filter is applied.

By default, no event filters are defined. Event filters must be explicitly configured.

The no form of this command removes the filter association from log IDs, which causes those logs to forward all events.

This command configures a network ingress filter for IPv4 or IPv6 traffic arriving over explicitly defined spokes or auto-bind network interfaces for the VPRN service.

The no form of this command removes an IPv4, IPv6, or both filters.

This command applies an IP filter to the SAP.