This command moves the context back one level of the command hierarchy. For example, if the current level is the config router ospf context, the back command moves the cursor to the config router context level.

This command configures B-VPLS service associated with the I-VPLS.

This command configures virtual router IP addresses for the interface.

This command configures virtual router IP addresses for the interface.

This command configures virtual router IP addresses for the interface.

This command configures virtual router IP addresses for the interface.

This command assigns an AA ISA or ESA-VM configured in the specified location to this application assurance group. The backup module provides the application assurance group with warm redundancy when the primary module in the group is configured. Primary and backup modules have equal operational status and when both module are coming up, the ones that becomes operational first becomes the active module. A module can serve as a backup for multiple AA ISA cards but only one can fail to it at one time.

On an activity switch from the primary module, configurations are already on the backup MDA but flow state information must be re-learned. Any statistics not yet spooled will be lost. Auto-switching from the backup to primary, once the primary becomes available again, is not supported.

Operator is notified through SNMP events when:

The no form of this command removes the specified module from the application assurance group.

This command assigns a tunnel ISA configured in the specified slot to this IPsec group. The backup module provides the IPsec group with warm redundancy when the primary module in the group is configured. An IPsec group must always have a primary configured.

Primary and backup modules have equal operational status and when both modules are coming up, the one that becomes operational first becomes the active module. An IPsec module can serve as a backup for multiple IPsec groups but the backup can become active for only one ISA IPsec group at a time.

All configuration information is pushed down to the backup MDA from the CPM once the CPM gets notice that the primary module has gone down. This allows multiple IPsec groups to use the same backup module. Any statistics not yet spooled will be lost. Auto-switching from the backup to primary, once the primary becomes available again, is supported.

The operator is notified through SNMP events when:

The no form of this command removes the specified module from the IPsec group.

This command associates router IP addresses with the parental IP interface IP addresses.

The backup command has two distinct functions when used in an owner or a non-owner context of the virtual router instance.

Non-owner virtual router instances actually create a routable IP interface address that is operationally dependent on the virtual router instance mode (master or backup). The backup command in owner virtual router instances does not create a routable IP interface address; it simply defines the existing parental IP interface IP addresses that are advertised by the virtual router instance.

For owner virtual router instances, the backup command defines the IP addresses that are advertised within VRRP advertisement messages. This communicates the IP addresses that the master is representing to backup virtual routers receiving the messages. Advertising a correct list is important. The specified ip-address must be equal to one of the existing parental IP interface IP addresses (primary or secondary) or the backup command fails.

For non-owner virtual router instances, the backup command actually creates an IP interface IP address used for routing IP packets and communicating with the system when the access commands are defined (ntp-reply, ping-reply, telnet-reply, and ssh-reply). The specified ip-address must be an IP address that is within one of the parental IP interface local subnets created with the address or secondary commands. If a local subnet does not exist that includes the specified ip-address or if ip-address is the same IP address as the parental IP interface IP address, the backup command fails.

The new interface IP address created with the backup command assumes the mask and parameters of the corresponding parent IP interface IP address. The ip-address is only active when the virtual router instance is operating in the master state. When not operating as master, the virtual router instance acts as if it is operationally down. It does not respond to ARP requests to ip-address, nor does it route packets received with its vrid derived source MAC address. A non-master virtual router instance always silently discards packets destined to ip-address. A single virtual router instance may only have a single virtual router IP address from a given parental local subnet. Multiple virtual router instances can define a virtual router IP address from the same local subnet as long as each is a different IP address.

In IPv4, up to sixteen backup ip-address commands can be executed within the same virtual router instance. Executing backup multiple times with the same ip-address results in no operation performed and no error generated. At least one successful backup ip-address command must be executed before the virtual router instance can enter the operational state.

When operating as (non-owner) master, the default functionality associated with ip-address is ARP response to ARP requests to ip-address, routing of packets destined to the virtual router instance source MAC address and silently discarding packets destined to ip-address. Enabling the non-owner-access parameters selectively allows ping, Telnet and SSH connectivity to ip-address when the virtual router instance is operating as master.

The no form of the command removes the specified virtual router IP address from the virtual router instance. For non-owner virtual router instances, this causes all routing and local access associated with the ip-address to cease. For owner virtual router instances, the no backup command only removes ip-address from the list of advertised IP addresses. If the last ip-address is removed from the virtual router instance, the virtual router instance will enter the operationally down state

This command associates router IPv6 addresses with the parental IP interface IP addresses.

The backup command has two distinct functions when used in an owner or a non-owner context of the virtual router instance.

Non-owner virtual router instances actually create a routable IP interface address that is operationally dependent on the virtual router instance mode (master or backup). The backup command in owner virtual router instances does not create a routable IP interface address; it simply defines the existing parental IP interface IP addresses that are advertised by the virtual router instance.

For owner virtual router instances, the backup command defines the IP addresses that are advertised within VRRP advertisement messages. This communicates the IP addresses that the master is representing to backup virtual routers receiving the messages. Advertising a correct list is important. The specified ipv6-addr must be equal to one of the existing parental IP interface IP addresses (link-local or global) or the backup command will fail.

For non-owner virtual router instances, the backup command actually creates an IP interface IP address used for routing IP packets and communicating with the system when the access commands are defined (ntp-reply, ping-reply, telnet-reply, and ssh-reply). The specified ipv6-addr must be an IP address that is within one of the parental IP interface local subnets created with the link-local-address or address commands. If a local subnet does not exist that includes the specified ipv6-addr or if ipv6-addr is the same IP address as the parental IP interface IP address, the backup command will fail.

The new interface IP address created with the backup command assumes the mask and parameters of the corresponding parent IP interface IP address. The ipv6-addr is only active when the virtual router instance is operating in the master state. For IPv6 VRRP, the parental interface's IP address that is in the same subnet as the backup address must be manually-configured, non EUI-64 and configured to be in the preferred state.

When not operating as master, the virtual router instance acts as if it is operationally down. It will not respond to Neighbor Solicitation (NS) requests to ipv6-addr, nor will it route packets received with its vrid derived source MAC address. A non-master virtual router instance always silently discards packets destined to ipv6-addr.

IPv6 allows the configuration of a link-local IPv6 address and multiple global IPv6 addresses on an interface. For each of these configured subnets, a virtual router IP address can be configured. Each IPv6 enabled device on a particular IPv6 subnet dynamically learns the connected IPv6 routers and correlated subnets in addition to the IPv6 default gateway using IPv6 neighbor discovery protocol (RFC4861). This protocol behavior is revised from IPv4 where the default gateway is manually configured or derived from supporting protocols (for example, DHCP). During the IPv6 neighbor discovery process, VRRP enabled routers will use backup IPv6 addresses and correlated derived virtual MAC addresses. Multiple virtual router instances can define a virtual router IP address from the same local subnet as long as each is a different IP address.

Executing backup multiple times with the same ipv6-addr results in no operation performed and no error generated. At least one successful backup ipv6-addr command must be executed before the virtual router instance can enter the operational state.

When operating as (non-owner) master, the default functionality associated with ipv6-addr results in the IPv6 Neighbor Advertisement response to IPv6 Neighbor Solicitation requests to ip-addr, routing of packets destined to the virtual router instance source MAC address, and silently discarding packets destined to ipv6-addr. An IPv6 virtual router instance can enter the operational state only if one of the configured backup addresses is a link-local address and the router advertisement of the interface is configured to use the virtual MAC address. Enabling the non-owner-access parameters selectively allows ping, Telnet, and traceroute connectivity to ipv6-addr when the virtual router instance is operating as master.

The no form of the command removes the specified virtual router IP address from the virtual router instance. For non-owner virtual router instances, this causes all routing and local access associated with the ipv6-addr to cease. For owner virtual router instances, the no backup command only removes ipv6-addr from the list of advertised IP addresses. If the last ipv6-addr or the link-local address is removed from the virtual router instance, the virtual router instance will enter the operationally down state

This command enables the use of the Diff-Serv backup Class-Type (CT), instead of the Diff-Serv main CT, to signal the LSP primary path when it fails and goes into retry. The Diff-Serv main CT is configured at the LSP level or at the primary path level using the following commands:

config>router>mpls>lsp>class-type ct-number

config>router>mpls>lsp>primary>class-type ct-number

When an LSP primary path retries due a failure, for example, it fails after being in the UP state, or undergoes any type of Make-Before-Break (MBB), MPLS will retry a new path for the LSP using the main CT. If the first attempt failed, the head-end node performs subsequent retries using the backup CT. This procedure must be followed regardless if the currently used CT by this path is the main or backup CT. This applies to both CSPF and non-CSPF LSPs.

The triggers for using the backup CT after the first retry attempt are:

When an unmapped LSP primary path goes into retry, it uses the main CT until the number of retries reaches the value of the new main-ct-retry-limit parameter. If the path did not come up, it must start using the backup CT at that point in time. By default, this parameter is set to infinite value. The new main-ct-retry-limit parameter has no effect on an LSP primary path which retries due to a failure event.

An unmapped LSP primary path is a path which has never received a Resv in response to the first Path message sent. This can occur when performing a ‘shut/no-shut’ on the LSP or LSP primary path or when the node reboots. An unmapped LSP primary path goes into retry if the retry timer expired or the head-end node received a PathErr message before the retry timer expired.

When the re-signal timer expires, CSPF will try to find a path with the main CT. The head-end node must re-signal the LSP even if the new path found by CSPF is identical to the existing one since the idea is to restore the main CT for the primary path. A path with main CT is not found, the LSP remains on its current primary path using the backup CT.

When the user performs a manual re-signal of the primary path, CSPF will try to find a path with the main CT. The head-end node must re-signal the LSP as in current implementation.

The no form of this command disables the use of the Diff-Serv backup CT.

Commands in this context configure the backup next hop of an NHG entry in a forwarding policy.

The no form of this command removes the backup next hop context from an NHG entry in a forwarding policy.

Commands in this context configure static route entry fast failover.

This command enables LFA Protection using segment routing backup node SID.

The objective of this feature is to reduce the label stack pushed in a LFA tunnel next hop of inter-area and inter-domain prefixes. This is applicable in MPLS deployments across multiple IGP areas or domains such in seamless MPLS design.

The user enables the feature by configuring a backup node SID at an ABR/ASBR that is acting as a backup to the primary exit ABR/ASBR of inter-area or inter-as routes learned as BGP labeled routes. The user can enter either a label or an index for the backup node SID.

When a node in a IGP domain resolves a BGP label route for an inter-area or inter-domain prefix via the primary ABR exit router, it will use the backup node SID of this router, which is advertised by the backup ABR/ABR, as the LFA backup instead of the SID to the remote LFA PQ node to save on the pushed label stack.

This feature only allows the configuration of a single backup node SID per IGP instance and per ABR/ASBR. In other words, only a pair of ABR/ASBR nodes can back up each other in an IGP domain. Each time the user invokes the above command within the same IGP instance, it will override any previous configuration of the backup node SID. The same ABR/ASBR can, however, participate in multiple IGP instances and provide backup support within each instance.

This command enables the computation and use of a backup path for IPv4 and/or IPv6 BGP-learned prefixes belonging to the base router or a particular VPRN. Multiple paths must be received for a prefix to take advantage of this feature. When a prefix has a backup path and its primary paths fail, the affected traffic is rapidly diverted to the backup path without waiting for control plane reconvergence to occur. When many prefixes share the same primary paths, and in some cases also the same backup path, the time to failover traffic to the backup path is independent of the number of prefixes.

By default, IPv4 and IPv6 prefixes do not have a backup path installed in the IOM.

This command enables the computation and use of a backup path for IPv4 and/or IPv6 BGP-learned prefixes belonging to the base router. Multiple paths must be received for a prefix to take advantage of this feature. When a prefix has a backup path and its primary paths fail, the affected traffic is rapidly diverted to the backup path without waiting for control plane reconvergence to occur. When many prefixes share the same primary paths, and in some cases also the same backup path, the time to failover traffic to the backup path is independent of the number of prefixes.

By default, IPv4 and IPv6 prefixes do not have a backup path installed in the IOM.

This command configures the alternate destination IPv4 or IPv6 address to use for an IP tunnel. This destination address is used only if the primary destination configured with the remote-ip command is unreachable in the delivery service. The source address, remote-ip address and backup-remote-ip address of a tunnel must all belong to the same address family (IPv4 or IPv6). When the backup-remote-ip address contains an IPv6 address it must be a global unicast address.

The no form of this command deletes the backup-destination address from the tunnel configuration.

This command associates a 4-byte backup route tag with the static route when the backup-next-hop command is activated. The tag value is an identifier that can be used in route policies to control distribution of the static route into other protocols when the backup-next-hop is activated for the associated static route.

The tag specified at this level of the static route causes the tag values that are configured under the next-hop, black-hole, and indirect contexts of the static route to be ignored.

The no form of this command removes the tag association.

This command configures the administrator bandwidth assigned and available to ports and LAGs for use by SAP bandwidth Connection Admission Control (CAC). The administrator bandwidth on a port or LAG can be overbooked or underbooked using the booking-factor command.

Port or LAG: Increasing the port or LAG admin bandwidth will increase the available admin bandwidth on that port or LAG. Reducing the port or LAG admin bandwidth will reduce the available admin bandwidth on that port or LAG, however, if the reduction of available admin bandwidth would cause it to be insufficient to cover the sum of the current SAP admin bandwidth on the port or LAG then the command will fail.

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

This command configures the administrator bandwidth assigned and available to SAPs for use by SAP bandwidth Connection Admission Control (CAC).

Attempts to increase the SAP administrator bandwidth fail if there is insufficient available administrator bandwidth on its port or LAG, otherwise the available port or LAG administrator bandwidth is reduced by the incremental SAP administrator bandwidth. Reducing the SAP administrator bandwidth increases the available administrator bandwidth on its port or LAG.

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

This command specifies the bandwidth to be used for VLL bandwidth accounting by the VLL CAC feature.

The service manager keeps track of the available bandwidth for each SDP. The maximum value is the sum of the bandwidths of all constituent LSPs in the SDP. The SDP available bandwidth is adjusted by the user configured booking factor.

If an LSP consists of a primary and many secondary standby LSPs, then the bandwidth used in the maximum SDP available bandwidth is that of the active path. Any change to and LSP active path bandwidth will update the maximum SDP available bandwidth. Note however that a change to any constituent LSP bandwidth due to re-signaling of the primary LSP path or the activation of a secondary path which causes overbooking of the maximum SDP available bandwidth causes a warning and a trap to be issued but no further action is taken. The activation of a bypass or detour LSP in the path of the primary LSP does not change the maximum SDP available bandwidth.

When the user binds a VLL service to this SDP, an amount of bandwidth equal to bandwidth is subtracted from the SDP available bandwidth adjusted by the booking factor. When the user deletes this VLL service binding from this SDP, an amount of bandwidth equal to bandwidth is added back into the SDP available bandwidth.

If the total SDP available bandwidth when adding this VLL service is about to overbook, a warning is issued and the binding is rejected. This means that the spoke SDP bandwidth does not update the maximum SDP available bandwidth. In this case, the spoke SDP is put in operational down state and a status message of “pseudowire not forwarding” is sent to the remote SR-series PE node. A trap is also generated. The service manager will not put the spoke SDP into an operationally up state until the user executes a shutdown command and then a no-shutdown command of the spoke SDP and the bandwidth check succeeds. Therefore, the service manager will not automatically audit spoke SDPs subsequently to their creation to check if bandwidth is available.

If the VLL service contains an endpoint with multiple redundant spoke SDPs, each spoke SDP will have its bandwidth checked against the available bandwidth of the corresponding SDP.

If the VLL service performs a pseudowire switching (VC switching) function, each spoke SDP is separately checked for bandwidth against the corresponding SDP.

This feature does not alter the way service packets are sprayed over multiple RSVP LSPs, which are part of the same SDP. That is, by default load balancing of service packets occurs over the SDP LSPs based on service-id, or based on a hash of the packet header if ingress SAP shared queuing is enabled. In both cases, the VLL bandwidth is not checked against the available bandwidth of the selected LSPs but on the total SDP available bandwidth. Therefore, if there is a single LSP per SDP, these two matches.

If class-forwarding is enabled on the SDP, VLL service packets are forwarded to the SDP LSP which the packet forwarding class maps to, or if this is down to the default LSP. However, the VLL bandwidth is not checked against the selected LSP available bandwidth but on the total SDP available bandwidth. If there is a single LSP per SDP, these two matches.

If a non-zero bandwidth is specified for a VLL service and attempts to bind the service to an LDP or a GRE SDP, a warning is issued that CAC failed but the VLL is established. A trap is also generated.

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

This command specifies the admin bandwidth assigned to SAPs, ports and LAGs which is used by SAP bandwidth CAC.

SAP: Attempts to increase the SAP admin bandwidth will fail if there is insufficient available admin bandwidth on its port or LAG, otherwise the port or LAG available admin bandwidth will be reduced by the incremental SAP admin bandwidth. Reducing the SAP admin bandwidth will increase the available admin bandwidth on its port or LAG. This is not supported for PW-SAPs, Ethernet tunnels or subscriber group interface SAPs.

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

This command specifies the admin bandwidth assigned to SAPs, ports and LAGs which is used by SAP bandwidth CAC.

SAP: Attempts to increase the SAP admin bandwidth will fail if there is insufficient available admin bandwidth on its port or LAG, otherwise the port or LAG available admin bandwidth will be reduced by the incremental SAP admin bandwidth. Reducing the SAP admin bandwidth will increase the available admin bandwidth on its port or LAG. This is not supported for PW-SAPs, Ethernet tunnels or subscriber group interface SAPs.

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

This command specifies the admin bandwidth assigned to SAPs, ports and LAGs which is used by SAP bandwidth CAC.

SAP: Attempts to increase the SAP admin bandwidth will fail if there is insufficient available admin bandwidth on its port or LAG, otherwise the port or LAG available admin bandwidth will be reduced by the incremental SAP admin bandwidth. Reducing the SAP admin bandwidth will increase the available admin bandwidth on its port or LAG. This is not supported for PW-SAPs, Ethernet tunnels or subscriber group interface SAPs.

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

This command specifies the bandwidth to be signaled for the path of the GMPLS LSP. Bandwidth is specified in terms of the RFC 3471 signal type name.

If an empty path is configured or the first hop TE Link is not configured, the system will automatically select a TE Link to use for a GMPLS LSP path based on the lowest available TE Link ID with a matching bandwidth (if a bandwidth is configured for the GMPLS LSP). During a data-bearer link allocation request, an RSVP-requested GMPLS LSP BW can be either a non-zero value as per RFC 3471 signal-type, or it can be zero). There are the following cases:

The no form of the command updates the bandwidth to zero.

This command specifies the amount of bandwidth to be reserved for the P2MP instance.

The config>router>mpls>lsp>primary-p2mp-instance>bandwidth command is not supported on the 7450 ESS.

This command specifies the amount of bandwidth to be reserved for the LSP path.

The no form of this command resets bandwidth parameters (no bandwidth is reserved).

Commands in this context configure watermark parameters based on the bandwidth.

This command configures the MCAC policy bundle maximum bandwidth.

This command defines the bandwidth for a maximum Layer 2 rate for the MAC loopback. This is equivalent to a faceplate port rate with the difference that the bandwidth of a faceplate port is a Layer 1 rate, which on Ethernet- based ports includes 20B per frame (preamble and inter-packet gap).

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

This command modifies or controls the bandwidth distribution phase of the parent virtual scheduler.

This command edits the parameters that control the child given bandwidth for all policers and queues associated with the policy.

This command assigns an existing bandwidth policer as an action on flows matching this AQP entry. The match criteria for the AQP entry must specify a uni-directional traffic direction before a policer action can be configured. If a policer is used in one direction in an AQP match entry the same policer name cannot be used by another AQP entry which uses a different traffic direction match criteria.

When multiple policers apply to a single flow, the final action on a packet is the worst case of all policer outcomes (for example, if one of the policers marks packet out of profile, the final marking will reflect that).

The no form of this command removes bandwidth policer from actions on flows matching this AQP entry.

This command creates a multicast bandwidth policy. Bandwidth policies are used to manage the ingress multicast path bandwidth. Each forwarding plane supports multicast forwarding paths into the switch fabric. By default, two paths are available; the multicast high priority path and the multicast low priority path. Multicast packets are forwarded on either path based on the expedited or non-expedited (best-effort) nature of the queue the packets are scheduled from. The ingress forwarding plane uses the classification rules to determine the forwarding class of each multicast packet and uses the forwarding class to queue mapping to decide which ingress multipoint queue forwards the packet.

When multicast path management is enabled, the ingress forwarding plane allows IP multicast snooped or routed packets to be placed on to the two multicast paths independently of the ingress classification rules. The high priority multicast path is treated as the primary path and the low priority multicast path is treated as the secondary path. The ingress bandwidth manager evaluates each multicast FIB (M-FIB) record to determine which path is best based on ingress bandwidth, number of switch fabric destinations and the fill level of each path. Explicit path association is also supported.

Dynamic Bandwidth Activity Monitoring

When ingress multicast path management is enabled on an MDA, the system monitors the in-use bandwidth associated with each Layer 2 and Layer 3 ingress multicast record. When records are first populated by static, snooping or routing protocols, they are first assumed to be inactive. An inactive record is not considered to be currently consuming ingress multicast path bandwidth.

Within the multicast-info-policy, the bandwidth activity of the new record was configured to be either managed based on an administrative bandwidth, or based on the dynamic bandwidth rate table. The bandwidth-policy associated with ingress MDA contains the configuration parameters for creating the dynamic bandwidth rate table. The purpose of the table is to allow for the system to monitor the bandwidth activity associated with a multicast record and compare the current rate against several rate thresholds. Rate thresholds are used to allow a multicast streams rate to fluctuate between a given range while keeping the managed rate at a certain level. Multiple dynamic managed rates are supported in the table to allow monitoring of different types of multicast traffic. Each rate threshold is associated with a rising and falling threshold that defines when the specified rate should be used and when the next lower rate should be used.

Once a record’s monitored current rate rises to the first dynamic rising threshold, the record is active and the system then manages the bandwidth the record represents based on the parameters associated with the record in the records multicast-info-policy and the configured path information in the MDAs associated bandwidth-policy.

Ingress Multicast Path Parameters

The bandwidth-policy also contains the configuration parameters for each of the managed ingress multicast paths. The queue default parameters can be overridden for each primary and secondary path. In addition, the number of secondary paths (and by implication the number of primary paths) can be overridden.

Default Bandwidth Policy

A bandwidth policy with the name ‘default’ always exists and is used as the default bandwidth policy when ingress multicast path management is enabled without an explicit bandwidth policy defined on an FP. The default policy cannot be deleted or edited.

The no form of this command removes the specified bandwidth policy from the system. The bandwidth policy associations must be removed from MDA configurations before it can be removed.

This command explicitly associates a bandwidth policy to a forwarding plane. The bandwidth policy defines the dynamic rate table and the multicast paths bandwidth and queuing parameters.

If a bandwidth policy is not explicitly associated with a forwarding plane, the default bandwidth policy is used when ingress multicast path management is enabled.

The no form of this command removes an explicit bandwidth policy from a forwarding plane or MDA and restores the default bandwidth policy.

Commands in this context configure the permission to use NETCONF operations at the base operation level for the specified profile.The NETCONF operations are authorized by default in the built-in system-generated administrative profile.

This command enables or disables support of the Base-R13 YANG modules in the SR OS NETCONF server. If the Base-R13 modules are disabled, then the NETCONF requests, which reference the Base-R13 modules, return an error, and when a NETCONF client establishes a new session, the Base-R13 modules are not advertised in the SR OS hello. When management-interface configuration-mode is set to model-driven, attempts to modify the configuration using the Base-13 configuration modules or namespace via NETCONF results in errors, even if base-r13-modules is enabled.

The no form of this command disables support of the Base-R13 YANG modules in the SR OS NETCONF server.

Commands in this context configure the function value for End SID, End.X SID, and service SID of an IPv4 or an IPv6 prefix in the global routing instance.

This command sets the prefix for the user name that shall be used as access requests. The actual name used is a concatenation of this string, the “-” (dash) character and a monotonically increasing integer.

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

This command enables matching on UEs that are part of the specified BD.

The no form of this command disables matching on the BD.

This command specifies the prefix of the HLE BD MAC address.

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

This command, in the case of ESM over GTP access includes the Alc-Bearer-Fteid VSA in accounting. This VSA contains the fully qualified TEID of the current GTP-U tunnel, including the bearer ID, endpoint IP addresses and TEIDs for both local and remote endpoints.

The no version of this command disables inclusion of the Alc-Bearer-Fteid VSA.

This command begins a policy editing session.

The editing session continues until one of the following conditions takes place:

The editing session is not interrupted by:

This command switches to edit mode for a BFD template. Changes are not activated until the commit command is issued for the BFD template changes.

This command switches to edit mode for route next-hop templates. Changes are not activated until the commit command is issued for the route next-hop templates changes.

This command is required in order to enter the mode to create or edit the system synchronous interface timing configuration.

This command is required in order to enter the mode to create or edit route policies.

This command specifies the calendar date and time after which the key specified by the keychain authentication key is used to sign and/or authenticate the protocol stream.

If no date and time is set, the begin-time is represented by a date and time string with all NULLs and the key is not valid by default.

This command enables the port down on BER-SF alarm. When enabled, the link will be placed out of service once ber-sf is detected.

The no form of this command reverts to normal operation where the link remains in-service when ber-sf is encountered.

This command initiates or restarts a Bit Error Rate Test (BERT) on the associated DS-1/E-1 or DS-3/E-3 circuit.

The associated DS-1, E-1, DS-3, or E-3 must be in a shutdown (admin down) state to initiate this test.

The no form of this command terminates the BERT test if it has not yet completed.

Notes:

This command enables path selection configuration.

Commands in this context configure path selection parameters.

This command specifies the BFD parameters for the associated IP interface. If no parameters are defined the default value are used.

The multiplier specifies the number of consecutive BFD messages that must be missed from the peer before the BFD session state is changed to down and the upper level protocols (OSPF, IS-IS, BGP or PIM) is notified of the fault.

The no form of this command removes BFD from the interface.

Note: On the 7750 SR, the transmit-interval, receive receive-interval, and echo-receive echo-interval values can only be modified to a value less than 100 when: The type cpm-np option is explicitly configured. The service is shut down (shutdown) The interval is specified 10 to 100000. The service is re-enabled (no shutdown)

To remove the type cpm-np option, re-issue the bfd command without specifying the type parameter.

This command specifies the BFD attributes for the associated retail subscriber interface or group interface. If no parameters are defined the default value are used.

The no form of this command removes BFD from the interface.

To remove the type cpm-np option, re-issue the bfd command without specifying the type parameter.

This command creates the bfd context and enables BFD over the associated LAG links.

Commands in this context configure LSP BFD commands on RSVP LSPs or seamless BFD commands on SR-TE LSPs.

This command specifies the context for the configuration of BFD parameters global to a specific router.

The no form of this command removes the context.

This command specifies the bidirectional forwarding detection (BFD) parameters for the associated IP interface. If no parameters are defined the default values are used.

The multiplier specifies the number of consecutive BFD messages that must be missed from the peer before the BFD session state is changed to down and the upper level protocols (OSPF, IS-IS, BGP or PIM) is notified of the fault.

The no form of this command removes BFD from the router interface regardless of the IGP/RSVP.

Important notes: On the 7750 SR and 7950 XRS SR OS, the transmit-interval and receive receive-interval values can only be modified to a value less than 100 ms when:

To remove the type cpm-np option, re-issue the bfd command without specifying the type parameter.

This command creates a context for the configuration of VCCV BFD.

This command specifies whether this IPsec tunnel is the BFD designated tunnel.

This commands assigns a bi-directional forwarding (BFD) session providing heart-beat mechanism for the given VRRP/SRRP instance. There can be only one BFD session assigned to any given VRRP/SRRP instance, but there can be multiple SRRP/VRRP sessions using the same BFD session. If the interface configured with BFD is using a LAG or a spoke-SDP, the BFD transmit and receive intervals need to be set to a minimum of 300 ms.

BFD control the state of the associated interface. By enabling BFD on a given protocol interface, the state of the protocol interface is tied to the state of the BFD session between the local node and the remote node. The parameters used for the BFD are set via the BFD command under the IP interface. The specified interface may not be configured with BFD; when it is, the virtual router will then initiate the BFD session.

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

This command enables the use of bi-directional forwarding (BFD) to control the state of the associated protocol interface. By enabling BFD on a given protocol interface, the state of the protocol interface is tied to the state of the BFD session between the local node and the remote node. The parameters used for the BFD are set via the BFD command under the IP interface.

The no form of this command disables BFD.

This command enables VCCV BFD on the PW associated with the VLL, BGP VPWS, or VPLS service. The parameters for the BFD session are derived from the named BFD template, which must have been first configured using the bfd-template command.

The no form of this command disables VCCV BFD on the spoke-SDP.

This command enables VCCV BFD on the PW associated with the VLL, BGP VPWS, or VPLS service. The parameters for the BFD session are derived from the named BFD template, which must have been first configured using the bfd-template command.

The no form of this command disables VCCV BFD.

This command enables VCCV BFD on the PWs associated with the VPLS service's spoke or mesh SDPs. The parameters for the BFD session are derived from the named BFD template, which must have been first configured using the bfd-template command.

The no form of this command disables VCCV BFD on the mesh-SDP or spoke-SDP.

This command enables VCCV BFD on the PWs associated with the BGP AD VPLS service. The parameters for the BFD session are derived from the named BFD template, which must have been first configured using the bfd-template command.

The no form of this command disables VCCV BFD.

This command enables VCCV BFD on the PW associated with the spoke-SDP terminated on the IES interface. The parameters for the BFD session are derived from the named BFD template, which must have been first configured using the bfd-template command.

The no form of this command disables VCCV BFD on the spoke-SDP.

This commands assigns a bi-directional forwarding (BFD) session providing heart-beat mechanism for the given VRRP/SRRP instance. There can be only one BFD session assigned to any given VRRP/SRRP instance, but there can be multiple SRRP/VRRP sessions using the same BFD session.

BFD control the state of the associated interface. By enabling BFD on a given protocol interface, the state of the protocol interface is tied to the state of the BFD session between the local node and the remote node. The parameters used for the BFD are set via the BFD command under the IP interface. The specified interface may not be configured with BFD; however, when it is, the virtual router will then initiate the BFD session.

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

This command associates the static route state to a BFD session between the local system and the configured nexthop.

The remote end of the BFD session must also be configured to originate or accept the BFD session controlling the static route state.

The no form of this command removes the association of the static route state to that of the BFD session.

This command enables VCCV BFD on the PW associated with the spoke-SDP terminated on the VPRN interface service. The parameters for the BFD session are derived from the named BFD template, which must have been first configured using the bfd-template command.

The no form of this command disables VCCV BFD on the spoke-SDP.

This commands assigns a bi-directional forwarding (BFD) session providing heart-beat mechanism for the given VRRP/SRRP instance. There can be only one BFD session assigned to any given VRRP/SRRP instance, but there can be multiple SRRP/VRRP sessions using the same BFD session. If the interface used is configured with centralized BFD, the BFD transmit and receive intervals need to be set to at least 300 ms.

BFD control the state of the associated interface. By enabling BFD on a given protocol interface, the state of the protocol interface is tied to the state of the BFD session between the local node and the remote node. The parameters used for the BFD are set via the BFD command under the IP interface. The specified interface may not be configured with BFD; when it is, the virtual router will then initiate the BFD session.

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

This command enables the use of bi-directional forwarding (BFD) to control IPv4 or adjacencies. By enabling BFD on an IPv4 or IPv6 protocol interface, the state of the protocol interface is tied to the state of the BFD session between the local node and the remote node. The parameters used for the BFD are set by the BFD command under the IP interface. This command must be given separately to enable or disable BFD for IPv4 and IPv6.

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

This command enables the use of bi-directional forwarding (BFD) to control the state of the associated protocol interface. By enabling BFD on a given protocol interface, the state of the protocol interface is tied to the state of the BFD session between the local node and the remote node. The parameters used for the BFD are set using the bfd command in the associated IP interface context.

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

This command enables the use of bi-directional forwarding (BFD) to control the state of the associated protocol interface. By enabling BFD on a given protocol interface, the state of the protocol interface is tied to the state of the BFD session between the local node and the remote node. The parameters used for the BFD are set via the BFD command under the IP interface.

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

This command enables the use of bi-directional forwarding (BFD) to control the state of the associated protocol interface. The parameters used for the BFD are set with the BFD command under the IP interface.

The no form of this command disables bfd-enable on the VPRN service.

This command enables bi-directional forwarding (BFD) to control the state of the associated protocol adjacency. By enabling BFD on a given protocol interface, the state of the RIP neighbor is tied to the state of the BFD session between the local node and the remote node. The parameters used for the BFD are set using the bfd command under the IP interface configuration context.

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

This command enables BFD on LDP LSPs with FECs that match the prefix list specified using the lsp-bfd command. A named BFD template must be configured and applied prior to enabling BFD.

The no form of this command disables BFD.

This command enables tracking of the Hello adjacency to an LDP peer using BFD.

The ipv6 option for this command is not supported on the 7450 ESS.

When this command is enabled on an LDP interface, LDP registers with BFD and starts tracking the LSR-id of all peers it formed Hello adjacencies with over that LDP interface. The LDP hello mechanism is used to determine the remote address to be used for the BFD session. The parameters used for the BFD session, that is, transmit-interval, receive-interval, and multiplier are those configured under the IP interface in existing implementation: config>router>if>bfd.

The operation of BFD over an LDP interface tracks the next-hop of the IPv4 and IPv6 prefixes in addition to tracking the LDP peer address of the Hello adjacency over that link. This is required since LDP can resolve both IPv4 and IPv6 prefix FECs over a single IPv4 or IPv6 LDP session and as such the next-hop of a prefix will not necessarily match the LDP peer source address of the Hello adjacency.

The failure of either or both of the BFD session tracking the FEC next-hop and the one tracking the Hello adjacency will cause the LFA backup NHLFE for the FEC to be activated or the FEC to be re-resolved if there is no FRR backup.

When multiple links exist to the same LDP peer, a Hello adjacency is established over each link and a separate BFD session is enabled on each LDP interface. If a BFD session times out on a specific link, LDP will immediately associate the LDP session with one of the remaining Hello adjacencies and trigger the LDP FRR procedures. As soon as the last Hello adjacency goes down due to BFD timing out, the LDP session goes down and the LDP FRR procedures will be triggered.

The no form of this command disables BFD on the LDP interface.

This command enables the bidirectional forwarding detection (BFD) session for the selected TLDP session. By enabling BFD for a selected targeted session, the state of that session is tied to the state of the underneath BFD session between the two nodes.

The parameters used for the BFD are set via the BFD command under the IP interface.

The no form of this command removes the TLDP session operational state binding to the central BFD session one.

This command enables LSP BFD on the RSVP LSP or S-BFD for the SR-TE LSP. LSP BFD must also be configured under config>router to enable LSP BFD. The parameters for the BFD session are derived from the named BFD Template, which must have been configured prior to the bfd-enable command and associated with the service using the bfd-template command.

The no form of this command disables LSP BFD on the RSVP LSP or S-BFD on the SR-TE LSP.

The command associates the operational state of an MPLS-TP path with a BFD session whose control packets flow on the path. The BFD packets are encapsulated in a generic associated channel (G-ACh) on the path. The timer parameters of the BFD session are taken from the OAM template of the MEP.

A value of cc means that the BFD session is only used for continuity check of the MPLS-TP path. In this case, the CC timer parameters of the OAM template apply. A value of cv means that the BFD session is used for both continuity checking and connectivity verification, and the CV timers of the OAM template apply.

This form of the bfd-enable command is only applicable when it is configured under a MEP used on an MPLS-TP working or protection path.

This command enables the use of bi-directional forwarding (BFD) to control the state of the associated RSVP interface. This causes RSVP to register the interface with the BFD session on that interface.

The user configures the BFD session parameters, such as, transmit-interval, receive-interval, and multiplier, under the IP interface in the config>router> if>bfd context.

Note: It is possible that the BFD session on the interface was started because of a prior registration with another protocol, for example, OSPF or IS-IS.

The registration of an RSVP interface with BFD is performed at the time of neighbor gets its first session. This means when this node sends or receives a new Path message over the interface. If however the session did not come up, due to not receiving a Resv for a new path message sent after the maximum number of re-tries, the LSP is shutdown and the node de-registers with BFD. In general, the registration of RSVP with BFD is removed as soon as the last RSVP session is cleared.

The registration of an RSVP interface with BFD is performed independent of whether RSVP hello is enabled on the interface or not. However, hello timeout will clear all sessions towards the neighbor and RSVP de-registers with BFD at clearing of the last session.

An RSVP session is associated with a neighbor based on the interface address the path message is sent to. If multiple interfaces exist to the same node, each interface is treated as a separate RSVP neighbor. The user will have to enable BFD on each interface and RSVP will register with the BFD session running with each of those neighbors independently

Similarly the disabling of BFD on the interface results in removing registration of the interface with BFD.

When a BFD session transitions to DOWN state, the following actions are triggered. For RSVP signaled LSPs, this triggers activation of FRR bypass/detour backup (PLR role), global revertive (head-end role), and switchover to secondary if any (head-end role) for affected LSPs with FRR enabled. It triggers switchover to secondary if any and scheduling of re-tries for signaling the primary path of the non-FRR affected LSPs (head-end role).

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

This command assigns a BFD session to provide a heart-beat mechanism for a given IPsec tunnel. There can be only one BFD session assigned to any given IPsec tunnel, but there can be multiple IPsec tunnels using same BFD session. BFD controls the state of the associated tunnel. If the BFD session goes down, the system will also bring down the associated non-designated IPsec tunnel.

This command enables tracking a central BFD session, if the BFD session goes down, then system consider the peer is down and change the mc-ipsec status of configured tunnel-group accordingly.

The BFD session uses specified the loopback interface (in the specified service) address as the source address and uses specified dst-ip as the destination address. Other BFD parameters are configured with the bfd command on the specified interface.

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

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

This command enables BFD tracking at the P2MP SR tree level, which causes all next-hops of the replication segments that use a BFD-enabled Layer 3 interface to register with the BFD module.

The no form of this command disables BFD tracking of the P2MP SR tree.

This command associates the static route state to a BFD session between the local system and the configured nexthop.

The remote end of the BFD session must also be configured to originate or accept the BFD session controlling the static route state.

The no form of this command removes the association of the static route state to that of the BFD session.

This commands assigns a bidirectional forwarding detect (BFD) session to a specific VRRP/SRRP instance. This BFD sessions provided a heartbeat mechanism that can be used to speed up the transition of the standby VRRP router to an active state. If the associated BFD session fails, the VRRP routers will immediately send a VRRP Advertisement message. In addition, the standby VRRP router(s) will transition to a Master state to speed convergence. The normal VRRP election process will then take place based on the Advertisement messages sent by all VRRP routers.

There can be only one BFD session assigned to any given VRRP/SRRP instance, but there can be multiple SRRP/VRRP sessions using the same BFD session.

The parameters used for the BFD sessions are set by the BFD command under the IP interface.

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

This command associates a BFD sessions with the named oper-group so that if the BFD session fails then the oper-group is changed to operationally down and all monitoring interfaces should also be brought operationally down.

This command enables the use of bidirectional forwarding detection (BFD) to control IPv4 or IPv6 adjacencies. By enabling BFD on an IPv4 or IPv6 protocol interface, the state of the protocol interface is tied to the state of the BFD session between the local node and the remote node. The parameters used for the BFD are set by the BFD command under the IP interface. This command must be given separately to enable or disable BFD for both IPv4 and IPv6.

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

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

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

This command enables bidirectional forwarding detection (BFD) to control the state of the associated protocol adjacency. By enabling BFD on a given protocol interface, the state of the RIP neighbor is tied to the state of the BFD session between the local node and the remote node. The parameters used for the BFD are set using the bfd command under the IP interface configuration context.

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

This command enables seamless BFD on every programmed segment list of an SR policy candidate path to which the maintenance policy is applied. BFD session parameters are taken from the BFD template that is configured for the maintenance policy.

The no form of this command disables seamless BFD on every segment list of an SR policy.

This command configures BFD tracking for BIER, which means that all next-hops that use a BFD-enabled interface register with the BFD module.

The no form of this command disables BFD tracking under BIER.

This command enables bi-directional forwarding (BFD) to control the state of an ESM dynamic BGP peer that is setup with this BGP peering policy. The parameters used for the BFD session are configured in the bfd context of the group-interface or retail subscriber-interface.

The no form of this command disables BFD for new ESM dynamic BGP peers that are setup with this BGP peering policy.

This command enables standardized implementation for interworking with other vendors by restricting micro-BFD sessions to links in LACP state distributing.

The no form of this command disables restricting micro-BFD sessions, which is an enhanced proprietary solution.

This command enables or disables LSP BFD at the tail end of LSPs on the system. It is also used to limit the maximum number of LSP BFD sessions that may be established at the tail-end of LSPs on a node to max-limit. It has no impact on the number of LSP BFD sessions that may be configured at the head end.

The no version of this command disables the creation of LSP BFD sessions by the node at the tail end of LSPs.

This command configures a named BFD template to be used by VCCV BFD on PWs belonging to the VLL service. The template specifies parameters, such as the minimum transmit and receive control packet timer intervals, used by the BFD session. Template parameters are configured under the config>router>bfd context.

The no form of this command removes the binding of the BFD template to the spoke-SDP.

This command configures a named BFD template to be used by VCCV BFD on PWs belonging to the BGP VPWS service. The template specifies parameters, such as the minimum transmit and receive control packet timer intervals, to be used by the BFD session. Template parameters are configured under the config>router>bfd context.

The no form of this command removes the binding of the BFD template to the BGP VPWS.

This command configures a named BFD template to be used by VCCV BFD on the PW belonging to the VPLS spoke-SDP or mesh-SDP. The template specifies parameters, such as the minimum transmit and receive control packet timer intervals, to be used by the BFD session. Template parameters are configured under the config>router>bfd context.

The no form of this command removes the binding of the BFD template to the spoke-SDP.

This command configures a named BFD template to be used by VCCV BFD on PWs belonging to the BGP VPWS, or BGP AD VPLS service. The template specifies parameters, such as the minimum transmit and receive control packet timer intervals, to be used by the BFD session. Template parameters are configured under the config>router>bfd context.

This command configures a named BFD template to be used by VCCV BFD on the PW belonging to the spoke-SDP that is terminated on the IES interface. The template specifies parameters, such as the minimum transmit and receive control packet timer intervals, to be used by the BFD session. Template parameters are configured under the config>router>bfd context.

The no form of this command removes the binding of the BFD template to the spoke-SDP.

This command configures a named BFD template to be used by VCCV BFD on the PW belonging to spoke-SDP that is terminated on the VPRN interface. The template specifies parameters, such as the minimum transmit and receive control packet timer intervals, to be used by the BFD session. Template parameters are configured under the config>router>bfd context.

The no form of this command removes the binding of the BFD template to the spoke-SDP.

This command applies the specified BFD template to the BFD sessions for LDP LSPs with FECs that match the prefix list. The specified BFD template must exist prior to its application to LSP BFD.

The no form of this command removes the application of the BFD template.

This command configures a named BFD template to be referenced by an OAM template.

This command references a named BFD template to be used by LSP BFD. The template specifies parameters, such as the minimum transmit and receive control packet timer intervals, to be used by the BFD session. Templates are configured under the config>router>bfd context.

The no form of this command removes the association of the named BFD template to the LSP.

This command configures a BFD template. A BFD template defines the set of configurable parameters used by a BFD session. These include the transmit and receive timer intervals used for BFD CC packets, the transmit timer interval used when the session is providing a CV function, the multiplier value, the echo-receive interval, and whether the BFD session terminates in the CPM network processor.

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

This command references a named BFD template that is used by seamless BFD. The template specifies parameters, such as the minimum transmit and receive control packet timer intervals, that are used by the BFD session. Templates are configured under the config>router>bfd context.

A BFD template must exist on the system before being referenced from a maintenance policy.

The no form of this command removes the configured template.

This command enables AIS packets on a working or protection path of an MPLS-TP LSP to suppress BFD Down traps if a BFD session goes down on that path. It also causes BFD Up traps to be suppressed, and enables the 2.5 s hold-down timer.

Suppression only occurs as a result of a received AIS packet. Traps generated as a result of a local failure at an LER are not suppressed.

The no form of this command disables BFD Down/Up trap suppression when AIS packets are received.

This command specifies the BIER-ID for this sub-domain. BIER-IDs should be assigned sequentially as the SI and BIER bit position are driven by the IDs. The equation used to drive BIER SI and bit positions from the ID is as follows:

SI = (BFR-id -1) /BitStringLength

bit position = ((BFR-id -1) modulo BitStringLength) +1

If the BIER-ID is sequential then the all bit positions in a bit string length will be utilized before moving on to the next SetID (SI).

BFR ID configuration is only necessary for BFIR and BFER, and not for transit BFRs

The no form of this command removes the BIER-ID.

Commands in this context configure EVPN BGP-specific information.

The no form of this command reverts to the default.

Commands in this context configure the BGP related parameters BGP used for multi-homing and BGP VPWS.

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

This command selects the BGP tunnel type.

This command instructs BGP EVPN to search for a BGP LSP to the address of the BGP next hop. If the user does not enable the BGP tunnel type, inter-area or inter-as prefixes are not resolved.

The no form of this command removes the BGP tunnel type configuration.

Commands in this context configure the BGP related parameters for BGP VPLS.

A maximum of two BGP instances can be configured in a VPLS service. The bgp-instance parameter value can be configured as 1 or 2. If it is not specified, the parameter value is configured as 1 by default.

The route-distinguisher configured in BGP instance 1 and 2 must be different. However, the route-target value may be configured the same or different for the two instances.

Only BGP-EVPN MPLS is allowed to be assigned to instance 2. Instance 1 must be used for the VXLAN and L2VPN address families.

BGP-EVPN VXLAN and BGP-EVPN MPLS can only be configured as no shutdown in the same service if they are associated with different instances (When the two BGP instances are created, the bgp-instance command must be configured in the bgp-evpn mpls context).

The evi value in bgp-evpn can be used to auto-derive the route distinguisher in instance 1 only. However, the evi value can be used to auto-derive the route-target in both instances.

The no version of the command removes the BGP instance.

This command creates the BGP protocol instance and BGP configuration context. BGP is administratively enabled upon creation.

The no form of this command deletes the BGP protocol instance and removes all configuration parameters for the BGP instance. BGP must be shutdown before deleting the BGP instance. An error occurs if BGP is not shutdown first.

This command enables the BGP protocol with the VPRN service.

The no form of this command disables the BGP protocol from the given VPRN service.

This command enables debugging for PIM/BGP-specific interoperation.

The no form of this command disables debugging for PIM/BGP-specific interoperation.

This command selects BGP tunneling for next-hop resolution and specifies the IPv4 tunnels created by receiving BGP label-unicast IPv4 routes for /32.

The no form of this command disables the selection of BGP tunneling for next-hop resolution.

This command configures BGP auto-discovery.

This command defines the type-1 route-distinguisher IPv4 address and community value range within which the system will select a route-distinguisher for the bgp-enabled services using auto-rd.

Interactions:

This command is used along with the route-distinguisher auto-rd command supported in VPLS, VPRN and Epipe services. The system forces the user to create a bgp-auto-range before the auto-rd option can be used in the services.

The system will keep allocating values for services configured with route-distinguisher auto-rd as long as there are available community values within the configured range. After the command is added, the following changes are allowed:

Commands in this context configure the BGP EVPN parameters in the base instance.

Commands in this context configure the BGP EVPN parameters.

Commands in this context configure the BGP-EVPN global timers

This command enables eligible BGP routes matched by the policy entry or policy default-action that are tagged for faster route table updates.

This action applies only when the policy is applied as a BGP import policy to a base router BGP peer or VPRN BGP peer and applies only to the following route types:

This command is useful when the BGP RIB contains a large number of routes and quick routing table updates are needed for a small subset of these routes. The effectiveness of this command decreases as the subset becomes a larger proportion of the total RIB.

The no form of this command disables the routes that are tagged for faster route table updates.

Commands in this context configure the BGP IPVPN parameters.

This command configures the BGP labels hold timer on the ingress router.

This command causes qualifying matched BGP routes to be marked as leakable, meaning they are candidates to be leaked into other routing instances (copied with their complete set of path attributes). A BGP route is a qualifying route if it is an IPv4 route (unlabeled), IPv6 route (unlabeled) or a label-IPv4 route.

Note: A leakable BGP route is not actually leaked into another routing instance unless it is accepted by a leak-import policy of that other routing instance.

The bgp-leak command has an effect only when the policy is applied as a BGP import policy in the base router or a VPRN context.

This command changes the BGP MED attribute value in BGP routes matched by the route policy entry (or the policy default action).

If the matched route already has a MED attribute, this command overwrites the existing value. If the matched route does not have a MED attribute, then one is added and the value is set based on the parameters of this command.

This command has no effect on non-BGP routes. The default, no bgp-med, does not modify MED values.

This command configures BGP multi-homing parameters.

This command configures the name of the BGP peering policy.

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

This command configures auto-generation of IPv4 or IPv6 address prefixes (as required by the context that the command is executed within) based on the base router BGP instance configuration.

The no form of this command removes the bgp-peers configuration for auto-generation of address prefixes for the specified index value.

This command enables all BGP peers within a VPRN instance to share a single CPM queue. This command takes effect on new BGP connections established; already established BGP peers continue to use their own CPM queue. Any changes to PIR/CIR of the shared queue takes effect only after BGP connections are re-established.

This command enables the use of RSVP LSP for IPv4 BGP routes.

This command allows or blocks RSVP-TE LSP to be used as a transport LSP for BGP tunnel routes.

This command allows the use of BGP route tunnels available in the tunnel table to reach SDP far-end nodes. Use of BGP route tunnels are only available with MPLS-SDP. Only one of the transport methods is allowed per SDP - LDP, RSVP-LSP BGP, SR-ISIS, or SR-OSPF. This restriction is relaxed for some combinations of the transport methods when the mixed-lsp-mode option is enabled within the SDP.

The no form of the command disables resolving BGP route tunnel LSP for SDP far-end.

This command sets the TTM metric of all BGP tunnels to a fixed value or a value derived from the AIGP metric of the BGP-LU route, if the BGP-LU route has an AIGP path attribute; otherwise, it is set to the number specified by value. The effect of this command can be overridden by BGP import policies.

By default, BGP tunnels are installed with a fixed cost of 1000 in the tunnel table. This can overstate or understate their true cost when compared to other tunnels with IGP-derived costs.

The no form of this command reverts to the default.

This command provides the ability to set the TTM metric of all BGP tunnels, matched by the policy entry or the policy default action, to a fixed value or a value derived from the AIGP metric of the BGP-LU route, if the BGP-LU route has an AIGP path attribute, otherwise it reverts to the value parameter.

The no form of this command reverts to the default.

This command configures the tunnel table preference for BGP-LU tunnel type away from its default value.

The tunnel table preference applies to the next-hop resolution of BGP routes of the following families: EVPN, IPv4, IPv6, VPN-IPv4, VPN-IPv6, label-IPv4, and label-IPv6 in the tunnel table.

This feature does not apply to a VPRN, VPLS, or VLL service with explicit binding to an SDP which enabled the mixed-lsp-mode option. The tunnel preference, in such an SDP, is fixed and is controlled by the service manager. The configuration of the tunnel table preference parameter does not modify the behavior of such an SDP and the services that bind to it.

It is recommended to not set two or more tunnel types to the same preference value. In such a situation, the tunnel table prefers the tunnel type which was first introduced in SR OS implementation historically.

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

Commands in this context configure the BGP-VPLS parameters and addressing.

This command upon the configuration of the ve-id under the SAP and if BGP-VPLS is configured and is operationally up, causes the PE to advertise a bgp-mh route for the ve-id (the route does not contain label information). The bgp-mh route contains the F and D flags properly set based on the SAP operational state. Upon switchover, the former active PE (DF in case of EVPN-MH) sends an update with a transition of the F bit from 1 to 0. This is an indication for the remote PEs to flush their MACs associated to the advertising PE.

This command is required when MC-LAG or EVPN-MH is used for multi-homing redundancy and mac-flush is required at remote BGP-VPLS PEs when there is a failure in the active PE.

The no form of this command withdraws the L2 VPN route.

Commands in this context configure BGP-VPWS parameters and addressing.

This command configures keys for both send and receive stream directions.

This command creates a BIER inclusive or selective provider tunnel.

The no form of this command deletes the tunnel.

Commands in this context configure BIER.

This command enables BIER capabilities.

The no form of this command disables BIER capabilities.

This command enables BIER capabilities.

The no form of this command disables BIER capabilities.

This command performs connectivity tests on the BIER data plane.

This command enables debugging for bier inband.

The no form of this command disables debugging for bier inband.

This commands enables PIM signaling through a BIER domain. PIM signaling only functions in the context of SD0. PIM signaling can signal PIM IPv4 and IPv6 over a BIER IPV4 core.

The no form of this command disables PIM signaling through a BIER domain.

This command performs trace tests on the BIER data plane.

Commands in this context configure the thresholds for the specified bin.

This command allows the operator to configure the parameters for a specific bin group. Bin-group 1 is a default bin-group and cannot be modified. If no bin group is assigned to an oam-pm session, this is assigned by default. The default values for bin-group 1 are (fd-bin-count 3 bin 1 lower-bound 5000us, bin 2 lower-bound 10000us fdr-bin-count 2 bin 1lower-bound 5000us and ifdv-bin-count 2 bin 1lower-bound 5000us)

The no form of this command disables the OAM Performance Monitoring bin group.

This command links the individual test to the group of bins that map the probe responses.

The no form of this command installs the default bin-group 1 as the bin-group for the session.

This command is the start of the hierarchy where the specific delay metric bin structure isis defined.

This command configures the LDAP binding used to log into LDAP server. A string of domain components (DC) and common names (CN) can be programmed to identify the user in addition to the password field. The password is hashed. For example, “cn=admin,dc=nokia,dc=com” indicates the user admin in domain nokia.com. Table 33 lists the LDAP attributes.

The no version of this command removes the bind-authentication.

Commands in this context configure SDP bindings.

This command configures a binding label for the MPLS forwarding policy.

The policy associates an incoming label, referred to as a binding label, to an NHG in which the primary and backup direct or indirect next hops are defined. This type of MPLS forwarding policy is referred to as a label-binding policy.

The no form of the command removes the binding label from the MPLS forwarding policy.

This command configures the logical operator to use with the destinations test results to obtain the master test result (the redirect-policy binding test result). A change in this configuration results in the re-evaluation of the master test result.

The no version of this command sets the value to its default

This command associates a binding SID with a statically defined segment routing policy. This is a mandatory parameter and configuration command to enable the segment routing policy; if the binding SID label value is not configured, the execution of the no shutdown command on the static segment routing policy fails.The BSID label should be an available label in the reserved-label-block range.

The no form of this command removes the BSID association.

This command displays debugging information about addresses and label bindings learned from LDP peers for LDP bindings.

The no form of the command disables the debugging output.

This command inserts bit errors into a running BERT test. The number of errors inserted corresponds to 10^(-rate). A rate of 0 will cause 1 error in every bit transmitted. A rate of 7 will cause an error rate of 10^(-7), or 1 error in every one billion bits transmitted.

The no command disables the insertion of bit errors into the bit error rate test stream.

Note that this command is not saved in the router configuration between boots.

This command specifies the lowest priority defect that is allowed to generate a fault alarm.

This command is used to specify the threshold value of bit errors.

This command specifies the lowest priority defect that is allowed to generate a fault alarm.

This command specifies the lowest priority defect that is allowed to generate a fault alarm.

This command specifies the lowest priority defect that is allowed to generate a fault alarm.

This command specifies the lowest priority defect that generates a fault alarm.

This command specifies the lowest priority defect that is allowed to generate a fault alarm.

This command configures the high watermark for bit rate alarms.

This command configures the utilization of the flow records on the ISA-AA Group when the full alarm will be cleared by the agent.

Commands in this context configure parameters for the Building Integrated Timing Supply (BITS). The settings specified under this context apply to both the BITS input and BITS output ports.

The bits command subtree is only available on the 7450 ESS-7, 7450 ESS-12, 7750 SR-7, 7750 SR-12, 7750 SR-12e, 7950 XRS-20, 7950 XRS-40, 7750 SR-a4, 7750 SR-a8, 7750 SR-1e, 7750 SR-2e, and 7750 SR-3e.

This command configures the interface type of the BITS timing reference.

The no form of the command reverts to the default configuration

This command specifies that the route is a black hole route. If the destination address on a packet matches this static route, it will be silently discarded.

This command specifies that the route is a black hole route. If the destination address on a packet matches this static route, it will be silently discarded.

The black-hole-dup-mac command is disabled by default. If enabled, a duplicated MAC detected in the network is programmed as a black-hole MAC in the FDB and displayed in the show service id fdb detail command as follows:

Because the MAC is now programmed in the FDB as a black-hole, all received frames with MAC DA matching the duplicate MAC are discarded. The duplicate black-hole MACs are installed as Protected, therefore, all received frames with MAC SA matching the duplicate MAC are discarded by default.

A BGP-EVPN (MPLS or VXLAN) shutdown is required to add or remove the black-hole-dup-mac command.

The no form of the command removes the feature, and duplicate MACs are no longer programmed as black-hole MACs.

This command installs a low priority blackhole route for the entire aggregate. Existing routes that make up the aggregate have a higher priority and only the components of the range for which no route exists are blackholed.

It is possible that when performing area aggregation, addresses may be included in the range for which no actual route exists. This can cause routing loops. To avoid this problem, configure the blackhole-aggregate command.

The no form of this command removes this configuration.

This command installs a low priority blackhole route for the entire aggregate. Existing routes that make up the aggregate will have a higher priority and only the components of the range for which no route exists are blackholed.

When performing area aggregation, addresses may be included in the range for which no actual route exists, which can cause routing loops. To avoid this problem, configure the blackhole-aggregate option.

The no form of this command removes this option.

This command configures the length of the block field of a SRv6 locator.

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

This command configures the maximum number of port blocks per subscriber.

The no form of the command reverts to the default.

This command enables blocking (brings the entity to an operationally down state) after all configured SDPs or endpoints are in operationally down state. This event is signaled to corresponding T-LDP peer by withdrawing service label (status-bit-signaling non-capable peer) or by setting “PW not forwarding” status bit in T-LDP message (status-bit-signaling capable peer).

The no form of this command reverts to the default.

When enabled, this command blocks the transmit direction of a PW when any of the following PW status codes is received from the far end PE:

The transmit direction is unblocked when the following PW status code is received:

This command is mutually exclusive with no pw-status-signaling, and standby-signaling-slave. It is not applicable to spoke SDPs forming part of an MC-LAG or spoke SDPs in an endpoint.

When enabled, this command blocks the transmit direction of a pseudowire when any of the following pseudowire status codes is received from the far end PE:

The transmit direction is unblocked when the following pseudowire status code is received: