2.15. IP Router Configuration Command Reference

The shutdown command administratively disables the entity. When disabled, an entity does not change, reset, or remove any configuration settings or statistics. Many entities must be explicitly enabled using the no shutdown command.

The shutdown command administratively disables an entity. The operational state of the entity is disabled as well as the operational state of any entities contained within. Many objects must be shut down before they may be deleted.

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

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

This command creates a text description stored in the configuration file for a configuration context.

The no form of this command removes the description string from the context.

This command creates a text description stored in the configuration file for a configuration context.

The no form of this command removes the description string from the context

This command creates a text description stored in the configuration file for a configuration context.

The no form of this command removes the description string from the context.

This command enables the context to configure router parameters including interfaces, route policies and protocols. This command is also used to create CPM router instances.

For CPM router instances, this command enters or creates a user-created CPM router instance. A CPM router instance is a not a VPRN router instance. VPRN router instances are configured under configure service vprn. CPM router instances are the only type of non-VPRN router instances that can be created by a user, and they have a user-defined name. CPM router instances only use CPM/CCM ethernet ports as interfaces.

This command enables the context for the configuration of admin tags and router admin tag policy templates used for route resolution to LSPs.

This command configures an admin tag value in the nodal LSP administrative tag database.

Up to 64 admin tags can be configured.

The no form of this command removes the admin tag.

This command configures a route admin tag policy.

Up to 2,000 policies can be configured per system.

The no form of this command removes the route admin tag policy.

This configures an admin tag to be excluded when matching a route against an LSP.

Up to eight exclusion statements are supported per policy.

The no form of this command removes the admin tag from the exclude statement.

This configures an admin tag to be included when matching a route against an LSP.

Up to eight inclusion statements are supported per policy.

The no form of this command removes the admin tag from the include statement.

This command creates an aggregate route.

Use this command to automatically install an aggregate route in the routing table when there are one or more component routes. A component route is any route used for forwarding that is a more-specific match of the aggregate.

The use of aggregate routes can reduce the number of routes that need to be advertised to neighbor routers, leading to smaller routing table sizes.

Overlapping aggregate routes may be configured; in this case a route becomes a component of only the one aggregate route with the longest prefix match. For example if one aggregate is configured as 10.0.0.0/16 and another as 10.0.0.0/24, then route 10.0.128/17 would be aggregated into 10.0.0.0/16, and route 10.0.0.128/25 would be aggregated into 10.0.0.0/24. If multiple entries are made with the same prefix and the same mask the previous entry is overwritten.

A standard 4-byte BGP community may be associated with an aggregate route in order to facilitate route policy matching.

By default aggregate routes are not installed in the forwarding table, however there are configuration options that allow an aggregate route to be installed with a black-hole next hop or with an indirect IP address as next hop.

The no form of this command removes the aggregate.

This command allows ICMP redirects received on the management interface.

The no form of this command drops the ICMP redirects received on the management interface.

This command allows IPv6 ICMP redirects received on the management interface.

The no form of this command drops the IPv6 ICMP redirects received on the management interface.

This command configures the autonomous system (AS) number for the router. A router can only belong to one AS. An AS number is a globally unique number with an AS. This number is used to exchange exterior routing information with neighboring ASs and as an identifier of the AS itself.

If the AS number is changed on a router with an active BGP instance, the new AS number is not used until the BGP instance is restarted either by administratively disabling/enabling (shutdown/no shutdown) the BGP instance or rebooting the system with the new configuration.

This command enables class-based forwarding (CBF) over IGP shortcuts. When the class-forwarding command is enabled, the following types of packets are forwarded based on their forwarding class:

The SR OS CBF implementation supports spraying of packets over a maximum of four forwarding sets of ECMP LSPs. The user must define a class-forwarding policy object in MPLS to configure the mapping of FCs to the forwarding sets. Then, the user assigns the CBF policy name and set ID to each MPLS LSP that is used in IGP shortcuts.

When a BGP IPv4 or IPv6 prefix is resolved, the FC of the packet is used to look up the forwarding set ID. Then, a modulo operation is performed on the tunnel next-hops of this set ID only, to spray packets of this FC. The data path concurrently implements CBF and ECMP within the tunnels of each set ID.

CPM-originated packets on the router, including control plane and OAM packets, are forwarded over a single LSP from the set of LSPs that the packet's FC is mapped to, as per the CBF configuration.

Note: Weighted ECMP, at the transport tunnel level of BGP prefixes over IGP shortcuts and the CBF feature on a per BGP next-hop basis are mutually exclusive.

This command creates confederation autonomous systems within an AS.

This technique is used to reduce the number of IBGP sessions required within an AS. Route reflection is another technique that is commonly deployed to reduce the number of IBGP sessions.

The no form of this command deletes the specified member AS from the confederation.

When no members are specified in the no statement, the entire list is removed and confederation is disabled.

When the last member of the list is removed, confederation is disabled.

This command disables the selective FIB.

The no form of this command enables the selective FIB.

This command configures the DNS.

This command configures the DNS resolution to be resolved via VPRN. If configured, all packet URL resolution is done through a DNS server that is reachable in a VPRN. This includes packets in the global routing table.

This command configures the VPRN DNS redirection for the specified service.

The no form of this command removes the service from the VPRN DNS resolution configuration.

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

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

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

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

If entropy-label is configured, the Entropy label and Entropy Label Indicator is inserted on packets for which at least one LSP in the stack for the far-end of the LDP or RSVP tunnel used by an IGP or BGP shortcut has advertised entropy-label-capability. If the tunnel is of type RSVP, then entropy-label must also have been enabled under config>router>mpls or config>router>mpls>lsp.

This configuration will result in other traffic that is forwarded over an LDP or RSVP LSP for which this router is the LER, and for which there is no explicit service endpoint on this router, to have the EL/ELI enabled, subject to the LSP far-end advertising entropy-label-capability. An example of such traffic includes packets arriving on a stitched LDP LSP forwarded over an RSVP LSP.

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 enables the context to configure FlowSpec related parameters for the specified routing instance.

This command specifies the filter type that is required to embed FlowSpec entries. The filter type defines the match criteria that are available in the filter policy.

This command configures the maximum number of FlowSpec routes or rules that can be embedded into the auto-created embedded filter (fSpec-X). FlowSpec filter entries embedded in a filter policy in this routing instance will use filter entries from the range between “embedding offset + 1” and “embedding offset + ip-filter-max-size”.

The sum of the ip-filter-max-size value parameter and the highest offset in any IPv4 filter that embeds IPv4 FlowSpec rules from this routing instance (excluding filters that embed at offset 262143) must not exceed 262143.

The ip-filter-max-size configuration can be adjusted up or down at any time. If the number of IPv4 FlowSpec rules that are currently installed is M, and the new limit is N, where N<M, then the last set of rules from N to M (by FlowSpec order) are immediately removed, but are retained in the BGP RIB. If the limit is increased, new rules are programmed only as they are received again in new BGP updates.

This command configures the maximum number of IPv6 FlowSpec routes or rules that can be embedded into the auto-created embedded filter (fSpec-X). FlowSpec filter entries embedded in a filter policy in this routing instance will use filter entries from the range between “embedding offset + 1” and “embedding offset + ip-filter-max-size”.

The sum of the ipv6-filter-max-size value parameter and the highest offset in any IPv6 filter that embeds IPv6 FlowSpec rules from this routing instance (excluding filters that embed at offset 262143) must not exceed 262143.

The ipv6-filter-max-size configuration can be adjusted up or down at any time. If the number of IPv6 FlowSpec rules that are currently installed is M, and the new limit is N, where N<M, then the last set of rules from N to M (by FlowSpec order) are immediately removed, but are retained in the BGP RIB. If the limit is increased, new rules are programmed only as they are received again in new BGP updates.

This command enables the tunneling of ICMP reply packets over MPLS LSP at a LSR node as per RFC 3032.

The LSR part of this feature consists of crafting the reply ICMP packet of type=11- 'time exceeded', with a source address set to a local address of the LSR node, and appending the IP header and leading payload octets of the original datagram. The system skips the lookup of the source address of the sender of the label TTL expiry packet, which becomes the destination address of the ICMP reply packet. Instead, CPM injects the ICMP reply packet in the forward direction of the MPLS LSP the label TTL expiry packet was received from. The TTL of pushed labels should be set to 255.

The source address of the ICMP reply packet is determined as follows. The LSR uses the address of the outgoing interface for the MPLS LSP. With LDP LSP or BGP LSP multiple ECMP next-hops can exist and in such a case the first outgoing interface is selected. If that interface does not have an address of the same family (IPv4 or IPv6) as the ICMP packet, then the system address of the same family is selected. If one is not configured, the packet is dropped.

When the packet is received by the egress LER, it performs a regular user packet lookup in the data path in the GRT context for BGP shortcut, 6PE, and BGP label route prefixes, or in VPRN context for VPRN and 6VPE prefixes. It then forwards it to the destination, which is the sender of the original packet which TTL expired at the LSR.

If the egress LER does not have a route to the destination of the ICMP packet, it drops the packets.

The rate of the tunneled ICMP replies at the LSR can be directly or indirectly controlled by the existing IOM level and CPM levels mechanisms. Specifically, the rate of the incoming UDP traceroute packets received with a label stack can be controlled at ingress IOM using the distributed CPU protection feature. The rate of the ICMP replies by CPM can also be directly controlled by configuring a system wide rate limit for packets ICMP replies to MPLS expired packets which are successfully forwarded to CPM using the command 'configure system security vprn-network-exceptions'. While this command's name refers to VPRN service, this feature rate limits ICMP replies for packets received with any label stack, including VPRN and shortcuts.

The 7450 ESS, 7750 SR, and 7950 XRS implementation supports appending to the ICMP reply of type Time Exceeded the MPLS label stack object defined in RFC 4950. It does not include it in the ICMP reply type of Destination unreachable.

The new MPLS Label Stack object permits an LSR to include label stack information including label value, EXP, and TTL field values, from the encapsulation header of the packet that expired at the LSR node. The ICMP message continues to include the IP header and leading payload octets of the original datagram.

In order to include the MPLS Label Stack object, SR OS implementation adds support of RFC 4884 which defines extensions for a multi-part ICMPv4/v6 message of type Time Exceeded.

The no form of command disables the tunneling of ICMP reply packets over MPLS LSP at a LSR node.

This command enables IP Fast-Reroute (FRR) feature on the system.

This feature provides for the use of a Loop-Free Alternate (LFA) backup next-hop for forwarding in-transit and CPM generated IP packets when the primary next-hop is not available. IP FRR is supported on IPv4 and IPv6 OSPF/IS-IS prefixes forwarded in the base router instance to a network IP interface or to an IES SAP interface or spoke interface. It is also supported for VPRN VPN-IPv4 OSPF prefixes and VPN-IPv6 OSPF prefixes forwarded to a VPRN SAP interface or spoke interface.

IP FRR also provides a LFA backup next-hop for the destination prefix of a GRE tunnel used in an SDP or in VPRN auto-bind.

When any of the following events occurs, IGP instructs in the fast path on the XMAs to enable the LFA backup next-hop:

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. Therefore, the IP prefix will resolve to the multiple equal-cost primary next-hops that provide the required protection.

The no form of this command disables the IP FRR feature on the system

This command enters the context to configure the IPv6 interface of the router.

This command configures the neighbor reachability detection timer.

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

This command configures the time a neighbor discovery cache entry can remain stale before being removed.

The no form of this command removes the stale-time value.

This command configures the IPv6 TE Router ID. The IPv6 TE Router ID, when configured, uniquely identifies the router as being IPv6 TE capable to other routers in an IGP TE domain.

IS-IS advertises this information using the IPv6 TE Router ID TLV.

If this command is not configured, the IPv6 TE Router ID will use the global unicast address of the system interface by default. The user can specify the system interface using this command to achieve the same result. If a different interface is specified, the preferred primary global unicast address of that interface is used instead

The no form of this command reverts the IPv6 TE Router ID to the default value.

This command enables the resolution of IGP routes using LDP LSP across all network interfaces participating in the IS-IS and OSPF routing protocol in the system.

When LDP shortcut is enabled, LDP populates the routing table with next-hop entries corresponding to all prefixes for which it activated an LDP FEC. For a given prefix, two route entries are populated in the system routing table. One route corresponds to the LDP shortcut next-hop and has an owner of LDP. The other route is the regular IP next-hop. The LDP shortcut next-hop always has preference over the regular IP next-hop for forwarding user packets and specified control packets over a given outgoing interface to the route next-hop.

All user and specified control packets for which the longest prefix match in RTM yields the FEC prefix will be forwarded over the LDP LSP.

When an IPv4 packet is received on an ingress network interface, a subscriber IES interface, or a regular IES interface, the lookup of the packet by the ingress IOM, IMMM, or XMA will result in the packet being sent labeled with the label stack corresponding to the NHLFE of the LDP LSP when the preferred RTM entry corresponds to an LDP shortcut.

If the preferred RTM entry corresponds to an IP next-hop, the IPv4 packet is forwarded unlabeled.

When ECMP is enabled and multiple equal-cost next-hops exit for the IGP route, the ingress IOM, IMMM, or XMA will spray the packets for this route based on hashing routine currently supported for IPv4 packets. When the preferred RTM entry corresponds to an LDP shortcut route, spraying will be performed across the multiple next-hops for the LDP FEC. The FEC next-hops can either be direct link LDP neighbors or T-LDP neighbors reachable over RSVP LSPs in the case of LDP-over-RSVP but not both.

When the preferred RTM entry corresponds to a regular IP route, spraying will be performed across regular IP next-hops for the prefix.

The no form of this command disables the resolution of IGP routes using LDP shortcuts.

This command associates up to four policies to control the leaking of GRT routes into the associated VPRN.

If a route is being evaluated and the action is accepted, then that route is subject leaking into an associated VPRN instance assuming the route is fully resolved and active.

This process creates the pool of routes that can be leaked. Within each VPRN a corresponding import-grt policy must be configured to import select routes into that specific VPRN instance.

The no form of this command removes all route leaking policy associations and effectively disables the leaking of GRT routes into associated VPRNs.

This command sets a maximum limit on the number of GRT routes that can be leaked into VPRNs.

The no form of this command resets the leak-export-limit to its default value of 5.

This command specifies the maximum number of multicast routes that can be held within a VPN routing/forwarding (VRF) context. When this limit is reached, a log and SNMP trap are sent. If the log-only parameter is not specified and the maximum-routes value is set below the existing number of routes in a VRF, then no new joins will be processed.

The no form of this command disables the limit of multicast routes within a VRF context. Issue the no form of this command only when the VPRN instance is shutdown.

This command associates the MSS adjust group consisting of multiple ISAs with the routing context in which the application requiring TCP MSS adjust resides.

This command traces a multicast path from a source to a receiver.

This command specifies the destination and listening port for the Mtrace2 command. When set, this command generates Mtrace2 packets with the set UDP-port, and also listens on the same port for any incoming Mtrace2 packets.

This command configures multicast information policy.

This command opens context for defining network-domains. This command is applicable only in the base routing context.

This command creates network-domains that can be associated with individual interfaces and SDPs.

This command enables the context to display origin validation information.

This command configures a session with an RPKI local cache server by using the RPKI-Router protocol. It is over these sessions that the router learns dynamic VRP entries expressing valid origin AS and prefix associations. SR OS supports the RPKI-Router protocol over TCP/IPv4 or TCP/IPv6 transport. The router can set up an RPKI-Router session using the base routing table (in-band) or the management router (out-of-band). Configure the command in the config>router management instance to configure a session using the management port.

This command configures the time in seconds to wait between one TCP connection attempt that fails and the next attempt. The default (with no connect-retry) is 120 seconds.

This command configures the local address to use for setting up the TCP connection used by an RPKI-Router session. The default local-address is the outgoing interface IPv4 or IPv6 address. The local-address cannot be changed without first shutting down the session.

This command configures the destination port number to use when contacting the cache server. The default port number is 323. The port cannot be changed without first shutting down the session.

This command is used to configure the refresh-time and hold-time intervals that are used for liveness detection of the RPKI-Router session. The refresh-time defaults to 300 seconds and is reset whenever a Reset Query PDU or Serial Query PDU is sent to the cache server. When the timer expires, a new Serial Query PDU is sent with the last known serial number.

The hold-time specifies the length of time in seconds that the session is to be considered UP without any indication that the cache server is alive and reachable. The timer defaults to 600 seconds and must be at least 2x the refresh-time (otherwise the CLI command is not accepted). Reception of any PDU from the cache server resets the hold timer. When the hold-time expires, the session is considered to be DOWN and the stale timer is started.

This command configures the maximum length of time that prefix origin validation records learned from the cache server remain usable after the RPKI-Router session goes down. The default stale-time is 3600 seconds (1 hour). When the timer expires all remaining stale entries associated with the session are deleted.

This command configures a static VRP entry indicating that a specific origin AS is either valid or invalid for a specific IP prefix range. Static VRP entries are stored along with dynamic VRP entries (learned from local cache servers using the RPKI-Router protocol) in the origin validation database of the router. This database is used for determining the origin-validation state of IPv4 and/or IPv6 BGP routes received over sessions with the enable-origin-validation command configured.

Static entries can only be configured under the config>router>origin-validation context of the base router.

This command configures the router ID for the router instance.

The router ID is used by both OSPF and BGP routing protocols in this instance of the routing table manager. IS-IS uses the router ID value as its system ID.

When configuring a new router ID, protocols are not automatically restarted with the new router ID. The next time a protocol is initialized, the new router ID is used. This can result in an interim period of time when different protocols use different router IDs.

It is possible to configure SR OS to operate with an IPv6 only BOF and no IPv4 system interface address. When configured in this manner, the operator must explicitly define IPv4 router IDs for protocols such as OSPF and BGP as there is no mechanism to derive the router ID from an IPv6 system interface address.

To force the new router ID to be used, issue the shutdown and no shutdown commands for each protocol that uses the router ID, or restart the entire router.

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

This command creates an IP address range reserved for IES or VPLS services.

The purpose of reserving IP addresses using service-prefix is to provide a mechanism to reserve one or more address ranges for services.

When services are defined, the address must be in the range specified as a service prefix. If a service prefix is defined, then IP addresses assigned for services must be within one of the ranges defined in the service-prefix command. If the service-prefix command is not configured, then no limitations exist.

Addresses in the range of a service prefix can be allocated to a network port unless the exclusive parameter is used. Then, the address range is exclusively reserved for services.

When a range that is a superset of a previously defined service prefix is defined, the subset is replaced with the superset definition; for example, if a service prefix exists for 10.10.10.0/24, and a service prefix is configured as 10.10.0.0/16, then 10.10.10.0/24 is replaced by the new 10.10.0.0/16 configuration.

When a range that is a subset of a previously defined service prefix is defined, the subset replaces the existing superset, providing addresses used by services are not affected; for example, if a service prefix exists for 10.10.0.0/16, and a service prefix is configured as 10.10.10.0/24, then the 10.10.0.0/16 entry is removed as long as no services are configured that use 10.10.x.x addresses other than 10.10.10.x.

The no form of this command removes all address reservations. A service prefix cannot be removed while one or more service uses an address or addresses in the range.

This command configures DSCP/dot1p re-marking for self-generated traffic.

This command configures DSCP or dot1p remarking for self-generated traffic. When an application is configured using this command, then the specified DSCP name/value is used for all packets generated by this application.

Using the value configured in this command:

Only one DSCP name or value can be configured per application, if multiple entries are configured then the subsequent entry overrides the previous configured entry.

The no form of this command resets the command back to the default value.

This command creates a mapping between the DiffServ Code Point (DSCP) of the self-generated traffic and the forwarding class.

Self-generated traffic that matches the specified DSCP will be assigned to the corresponding forwarding class. Multiple commands can be entered to define the association of some or all sixty-four DiffServ code points to the forwarding class. For undefined code points, packets are assigned to the forwarding class specified under the default-action command.

All DSCP names that defines a DSCP value must be explicitly defined.

The no form of this command removes the DiffServ code point to forwarding class association. The default-action then applies to that code point value.

This command configures OSPF, OSPFv3 and IS-IS to set overload when the router has fewer than the full set of SFMs functioning, which reduces forwarding capacity. Setting overload enables a router to still participate in exchanging routing information, but routes all traffic away from it.

The conditions to set overload are as follows:

The no form of this command configures the router to not set overload if an SFM fails.

This command creates a static route entry for both the network and access routes. A prefix and netmask must be specified.

Once the static route context for the specified prefix and netmask has been created, additional parameters associated with the static routes may be specified through the inclusion of additional static route parameter commands

The no form of this command deletes the static route entry. If a static route needs to be removed when multiple static routes exist to the same destination, then as many parameters to uniquely identify the static route must be entered

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 associates one BGP community (standard, extended or large) with a next-hop of the static route. This community can be matched in route policies and automatically added to BGP routes that are created from the static route.

Any community specified in one of these contexts is overridden by any communities specified at the prefix level of the static route entry.

The no form of this command removes the association.

This optional command controls the behavior of the associated static route so that if a matching BGP route to the same exact prefix is present in BGP, the static route's nexthop is set to the BGP’s nexthop value. If there is no matching active BGP route, the static route's nexthop is set to be a black-hole nexthop.

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

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

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

This command specifies the cost metric for the static route, expressed as a decimal integer. This value is used when importing the static route into other protocols such as OSPF. When the metric is configured as 0 then the metric configured in OSPF, default-import-metric, applies. When modifying the metric of an existing static route, the preference will not change unless specified. This value is also used to determine which static route to install in the forwarding table.

If there are multiple static routes with the same preference but different metrics then the lower cost (metric) route will be installed.

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

This command specifies the route preference to be assigned to the associated static route. The lower the preference value the more preferred the route is considered.

Table 6 shows the default route preference based on the route source.

The no form of this command returns the returns the associated static route preference to its default value.

This command associates a new constraint to the associated static route such that the static route is only active if none or all of the routes in the prefix list are present and active in the route-table.

This command associates a 4-byte route-tag with the static route. The tag value can be used in route policies to control distribution of the static route into other protocols.

The tag specified at this level of the static route causes tag values 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 enables the hold down time feature globally for static routes in the system.

The no form of this command disables the hold down time feature globally for static routes in the system.

This command associates a list of up to 12 BGP communities (any mix of standard, extended, and large communities) with the static route. These communities can be matched in route policies and are automatically added to BGP routes that are created from the static route.

The communities specified at this level of the static route causes communities 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 association.

This command specifies that the route is indirect and specifies the next hop IP address used to reach the destination.

The configured ip-address is not directly connected to a network configured on this node. The destination can be reached via multiple paths. The indirect address can only be resolved from dynamic routing protocol. Another static route cannot be used to resolve the indirect address.

The ip-address configured here can be either on the network side or the access side and is typically at least one hop away from this node.

This command enables CPE-check and specifies the IP address of the target CPE device.

This option initiates a background ICMP ping test to the configured target IP address. The IP address can either be an IPv4 address for IPv4 static routes or an IPv6 address for IPv6 static routes. The target-ip-address cannot be in the same subnet as the static route subnet itself to avoid possible circular references. This option is mutually exclusive with BFD support on a given static route.

The no form of this command disables the cpe-check option.

This optional parameter specifies the number of consecutive ping-replies that must be missed to declare the CPE down and to deactivate the associated static route.

This optional parameter specifies the interval between ICMP pings to the target IP address.

This optional parameter enables the ability to log transitions between active and in-active based on the CPE connectivity check. Events will be sent to the system log, syslog and SNMP traps.

This command specifies the amount of padding to add to the ICMP packet in bytes. The parameter is only applicable when the cpe-check option is used with the associated static route.

This command configures the policy accounting destination-class index to be used when incrementing accounting statistic for traffic matching the associated static route.

The no form of this command removes the associated destination-class from the associated static route nexthop.

This command specifies the enqueuing forwarding class that should be associated with traffic matching the associate static route. If this parameter is not specified, the packet will use the forwarding-class association based on default classification or other QoS Policy associations.

This optional command associates an enqueuing priority with the static route. The options are either high or low, with low being the default. This parameter has the ability to affect the likelihood that a packet will be enqueued at SAP ingress in the face of ingress congestion.

Once a packet is enqueued into an ingress buffer, the significance of this parameter is lost.

This command configures the policy accounting source-class index to be used when incrementing accounting statistic for traffic matching the associated static route.

If source route policy accounting is enabled and a source-class index is configured, traffic with a source IP address matches the associated static route, the source accounting statistics for the specified class will be incremented.

The no form of this command removes the associated destination-class from the associated static route nexthop.

This command enables the context to configure the static route's nexthop to be resolved to an indirect tunnel next-hop.

This optional command determines if the associated static route can be resolved via an IGP next-hop in the RTM if no tunnel next-hops are found in TTM.

When configured, the associated static route will not be resolved to an available IGP route in the RTM.

The no form of this command returns the behavior to the default, which does allow for the static route to be resolved via an IGP route in the RTM if no tunnel next-hop can be found in the TTM.

This command instructs the tunnel towards the indirect static-route next-hop to use the specified flexible algorithm.

It is assumed that the router using this command is participating in the flexible algorithm. This command instructs the router to lookup the indirect next-hop using flexible algorithm tunnels. If flexible algorithm aware tunnel to the indirect next-hop does not exist, then the static-route is not activated.

The expected outcome of this command is that when the router receives an IP payload packet, that it is steered towards the indirect next-hop using a flexible algorithm aware segment-routing tunnel if such tunnel exists. If such tunnel does not exist, then the route is not active, and the received IP packet will be dropped, if no other Longest Prefix Match (LPM) route exists.

If the flex-algo parameter is specified, the resolution filter can only use matching flexible algorithm-aware segment routing tunnels created by flexible algorithm-aware routing protocols (for example, SR IS-IS).

The no form of this command disables flexible algorithm-aware indirect next-hop resolution.

This command determines how the associated static route can be resolved to a tunnel next-hop.

This command creates the context to specify the tunnel next-hop resolution options.

If one or more tunnel filter criteria are specified, the static route nexthop will be resolved to an available tunnel from one of those LSP types. The tunnel type will be selected following the TTM preference.

This command enables the use of LDP sourced tunnel entries in the TTM to resolve the associated static route next-hop.

This command enables the use of the MPLS forwarding policy to resolve the indirect next hops of statically-configured routes.

This command enables tunnels programmed using the RibApi gRPC service for use in resolving the indirect next hops of statically-configured IPv4 and IPv6 routes.

This command enables the use of RSVP-TE sourced tunnel entries in the TTM to resolve the associated static route next-hop.

The rsvp-te value instructs the code to search for the set of lowest metric RSVP-TE LSPs to the address of the indirect next-hop. The LSP metric is provided by MPLS in the tunnel table. The static route treats a set of RSVP-TE LSPs with the same lowest metric as an ECMP set. The user has the option of configuring a list of RSVP-TE LSP names to be used exclusively instead of searching in the tunnel table. In that case, all LSPs must have the same LSP metric in order for the static route to use them as an ECMP set. Otherwise, only the LSPs with the lowest common metric value will be selected.

A P2P auto-lsp that is instantiated via an LSP template can be selected in TTM when resolution is set to any. However, it is not recommended to configure an auto-lsp name explicitly under the rsvp-te node as the auto-generated name can change if the node reboots, which will blackhole the traffic of the static route.

This command restricts the search for a resolving LSP to a specific set of named LSPs. Only those LSPs named in the associated name list will be searched for a match to resolve the associated static route.

This command enables the use of SR-ISIS sourced tunnel entries in the TTM to resolve the associated static route next hop.

This command enables the use of SR-OSPF sourced tunnel entries in the TTM to resolve the associated static route next hop.

The sr-te value instructs the code to search for the set of lowest metric SR-TE LSPs to the address of the indirect next-hop. The LSP metric is provided by MPLS in the tunnel table. The static route treats a set of SR-TE LSPs with the same lowest metric as an ECMP set. The user has the option of configuring a list of SR-TE LSP names to be used exclusively instead of searching in the tunnel table. In that case, all LSPs must have the same LSP metric in order for the static route to use them as an ECMP set. Otherwise, only the LSPs with the lowest common metric value are selected.

This command specifies the directly connected next hop IP address or interface used to reach the destination. If the next hop is over a point-to-point unnumbered interface, the ip-int-name of the unnumbered point-to-point interface (on this node) can be configured.

If the next hop is over an unnumbered interface in the 7450 ESS router, the ip-int-name of the unnumbered interface (on this node) can be configured.

The configured ip-address can be either on the network side or the access side on this node. The address must be associated with a network directly connected to a network configured on this node.

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 extends the LDP synchronization feature to a static route. When an interface comes back up, it is possible that a preferred static route using the interface as next-hop for a given prefix is enabled before the LDP adjacency to the peer LSR comes up on this interface. In this case, traffic on an SDP that uses the static route for the far-end address would be black-holed until the LDP session comes up and the FECs exchanged.

This option when enabled delays the activation of the static route until the LDP session comes up over the interface and the ldp-sync-timer configured on that interface has expired

This command configures a weighted ECMP load-balancing weight for a static route next-hop.

If all of the ECMP next-hops of a static route have a configured load-balancing-weight then packets matching the route are sprayed according to the relative weights. In other words, the next-hop interface with the largest load-balancing weight should receive the most forwarded traffic if weighted ECMP is applicable.

The no form of this command disables weighted ECMP for the interface and effectively disables weighted ECMP for the entire static route.

This optional command tracks the state of the next-hop in the IPv4 ARP cache or IPv6 Neighbor Cache. When the next-hop is not reachable and is removed from the ARP or Neighbor Cache, the next-hop will no longer be considered valid and the associated static-route state removed from the active route-table.

When the next-hop is reachable again and present in the ARP/Neighbor Cache, the static route will be considered valid and is subject to being placed into the active route-table.

This command triggers route policy re-evaluation.

By default, when a change is made to a policy in the config router policy options context and then committed, the change is effective immediately. There may be circumstances when the changes should or must be delayed; for example, if a policy change is implemented that would affect every BGP peer on a router, the consequences could be dramatic. It would be more effective to control changes on a peer-by-peer basis.

If the triggered-policy command is enabled, and a given peer is established, and you want the peer to remain up, in order for a change to a route policy to take effect, a clear command with the soft or soft inbound option must be used; for example, clear router bgp neighbor x.x.x.x soft. This keeps the peer up, and the change made to a route policy is applied only to that peer or group of peers.

This command enables the context to configure TTL propagation for transit and locally generated packets in the Global Routing Table (GRT) and VPRN routing contexts

This command configures the TTL propagation for locally generated packets which are forwarded over a BGP label route in the Global Routing Table (GRT) context.

For IPv4 and IPv6 packets forwarded using a RFC 3107 label route in the global routing instance, including 6PE, the all value of the command enables TTL propagation from the IP header into all labels in the transport label stack. The none value reverts to the default mode which disables TTL propagation from the IP header to the labels in the transport label stack. This command does not have a no version.

The TTL of the IP packet is always propagated into the RFC 3107 label itself, and this command only controls the propagation into the transport labels, for example, labels of the RSVP or LDP LSP to which the BGP label route resolves and which are pushed on top of the BGP label.

If the BGP peer advertised the implicit-null label value for the BGP label route, the TTL propagation will not follow the configuration described, but will follow the configuration to which the BGP label route resolves:

RSVP LSP shortcut:

LDP LSP shortcut:

This feature does not impact packets forwarded over BGP shortcuts. The ingress LER operates in uniform mode by default and can be changed into pipe mode using the configuration of TTL propagation for RSVP or LDP LSP shortcut listed.

This command configures the TTL propagation for transit packets which are forwarded over a BGP label route in the Global Routing Table (GRT) context.

For IPv4 and IPv6 packets forwarded using a RFC 3107 label route in the global routing instance, including 6PE, the all value of the command enables TTL propagation from the IP header into all labels in the transport label stack. The none value reverts to the default mode which disables TTL propagation from the IP header to the labels in the transport label stack. This command does not have a no version.

The TTL of the IP packet is always propagated into the RFC 3107 label itself, and this command only controls the propagation into the transport labels, for example, labels of the RSVP or LDP LSP to which the BGP label route resolves and which are pushed on top of the BGP label.

If the BGP peer advertised the implicit-null label value for the BGP label route, the TTL propagation will not follow the configuration described, but will follow the configuration to which the BGP label route resolves.

RSVP LSP shortcut:

LDP LSP shortcut:

This feature does not impact packets forwarded over BGP shortcuts. The ingress LER operates in uniform mode by default and can be changed into pipe mode using the configuration of TTL propagation for the listed RSVP or LDP LSP shortcut.

This command configures the TTL propagation for transit packets at a router acting as an LSR for a BGP label route.

When an LSR swaps the BGP label for a ipv4 prefix packet, therefore acting as a ABR, ASBR, or data-path Route-Reflector (RR) in the base routing instance, or swaps the BGP label for a vpn-ipv4 or vpn-ipv6 prefix packet, therefore acting as an inter-AS Option B VPRN ASBR or VPRN data path Route-Reflector (RR), the all value of this command enables TTL propagation of the decremented TTL of the swapped BGP label into all outgoing LDP or RSVP transport labels.

When an LSR swaps a label or stitches a label, it always writes the decremented TTL value into the outgoing swapped or stitched label. What this feature controls is whether this decremented TTL value is also propagated to the transport label stack pushed on top of the swapped or stitched label.

The none value reverts to the default mode which disables TTL propagation. This changes the existing default behavior which propagates the TTL to the transport label stack. When a customer upgrades, the new default becomes in effect. This command does not have a no version.

This feature also controls the TTL propagation at an LDP-BGP stitching LSR in the LDP to BGP stitching direction. It also controls the TTL propagation in Carrier Supporting Carrier (CsC) VPRN at both the CsC CE and CsC PE.

SR OS does not support ASBR or data path RR functionality for labeled IPv6 routes in the global routing instance (6PE). As such the CLI command of this feature has no impact on prefix packets forwarded in this context.

This command configures the TTL propagation for locally generated packets which are forwarded over a MPLS LSPs in all VPRN service contexts.

For vpn-ipv4 and vpn-ipv6 packets forwarded in the context of all VPRN services in the system, including 6VPE packets, the all value of the command enables TTL propagation from the IP header into all labels in the stack:

The user can enable the TTL propagation behavior separately for locally generated packets by CPM (vprn-local) and for user and control packets in transit at the node (vprn-transit).

The vc-only value reverts to the default behavior by which the IP TTL is propagated into the VC label but not to the transport labels in the stack. The user can explicitly set the default behavior by configuring the vc-only value. This command does not have a no version.

The value none allows the user to disable the propagation of the IP TTL to all labels in the stack, including the VC label. This is needed for a transparent operation of UDP traceroute in VPRN inter-AS option B such that the ingress and egress ASBR nodes are not traced.

The user can override the global configuration within each VPRN instance using the following commands:

The default behavior for a given VPRN instance is to inherit the global configuration for the same command. The user can explicitly set the default behavior by configuring the inherit value.

When a packet is received in a VPRN context but is looked up in the Global Routing Table (GRT), for example, leaking to GRT is enabled, the behavior of the TTL propagation is governed by the RSVP or LDP shortcut configuration when the matching routing is a LSP shortcut route. It is governed by the BGP label route configuration when the matching route is a RFC 3107 label route or a 6PE route.

When a packet is received on one VPRN instance and is redirected using Policy Based Routing (PBR) to be forwarded in another VPRN instance, the TTL propagation is governed by the configuration of the outgoing VPRN instance.

This command configures the TTL propagation for in transit packets which are forwarded over a MPLS LSPs in all VPRN service contexts. For vpn-ipv4 and vpn-ipv6 packets forwarded in the context of all VPRN services in the system, including 6VPE packets, the all value of the command enables TTL propagation from the IP header into all labels in the stack:

The user can enable the TTL propagation behavior separately for locally generated packets by CPM (vprn-local) and for user and control packets in transit at the node (vprn-transit).

The vc-only value reverts to the default behavior by which the IP TTL is propagated into the VC label but not to the transport labels in the stack. The user can explicitly set the default behavior by configuring the vc-only value. This command does not have a no version.

The value none allows the user to disable the propagation of the IP TTL to all labels in the stack, including the VC label. This is needed for a transparent operation of UDP trace-route in VPRN inter-AS option B such that the ingress and egress ASBR nodes are not traced.

The user can override the global configuration within each VPRN service instance using the following commands:

The default behavior for a given VPRN instance is to inherit the global configuration for the same command. The user can explicitly set the default behavior by configuring the inherit value.

When a packet is received in a VPRN context but is looked up in the Global Routing Table (GRT), for example, leaking to GRT is enabled, the behavior of the TTL propagation is governed by the RSVP or LDP shortcut configuration when the matching routing is a LSP shortcut route. It is governed by the BGP label route configuration when the matching route is a RFC 3107 label route or a 6PE route.

When a packet is received on one VPRN instance and is redirected using Policy Based Routing (PBR) to be forwarded in another VPRN instance, the TTL propagation is governed by the configuration of the outgoing VPRN instance

This command enables the weighted load-balancing, or weighted ECMP, over MPLS LSP.

When this command is enabled, packets of IGP, BGP, and static route prefixes resolved to a set of ECMP tunnel next-hops are sprayed proportionally to the weights configured for each MPLS LSP in the ECMP set.

Weighted load-balancing over MPLS LSP is supported in the following forwarding contexts:

IGP computes the normalized weight for each prefix tunnel next-hop. IGP updates the route in RTM with the set of tunnel next-hops and normalized weights. RTM downloads the information to IOM for inclusion in the FIB.

If one or more LSPs in the ECMP set of a prefix do not have a weight configured, the regular ECMP spraying for the prefix will be performed.

The weight assigned to an LSP impacts only the forwarding decision, not the routing decision. In other words, it does not change the selection of the set of ECMP tunnel next-hops of a prefix when more next-hops exist than the value of the router ecmp option. Once the set of tunnel next-hops is selected, the LSP weight is used to modulate the amount of packets forwarded over each next-hop. It also does not change the hash routine, but only the spraying of the flows over the tunnel next-hops is modified to reflect the normalized weight of each tunnel next-hop.

The no form of this command resumes regular ECMP spraying of packets of IGP, BGP, and static route prefixes over MPLS LSP.

This command discards the changes made to a BFD template during an active session.

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 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 sets the minimum echo receive interval, in milliseconds, for a session. This is not used by a BFD session for MPLS-TP.

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

This command specifies the detect multiplier for a BFD session. If a BFD control packet is not received for a period of multiplier x receive-interval (the parameter value of the receive-interval command), the session is declared down.

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

This command specifies the receive timer used for BFD packets. If the template is used for a BFD session on an MPLS-TP LSP, then this timer is used for CC packets.

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

This command specifies the transmit timer used for BFD packets. If the template is used for a BFD session on an MPLS-TP LSP, then this timer is used for CC packets.

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

This command selects the CPM network processor as the local termination point for the BFD session. This is enabled by default.

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

This command saves the changes made to a BFD template during an active session and makes the changes active.

This command specifies the context for the configuration of seamless BFD initiator parameters that are global to this router.

The no form of this command removes the context.

This command specifies the context for the local mapping, used by an S-BFD initiator, between a discriminator for a far-end S-BFD reflector and its discriminator value.

The no form of this command removes the mapping for the peer.

This command specifies the seamless BFD reflector discriminator for the remote peer node in the mapping table used by seamless BFD sessions initiated on the router.

The no form of this command removes the discriminator.

This command creates the context to configure or apply IP interface attributes such as administrative group (admin-group) or Shared Risk Loss Group (SRLG).

This command defines an administrative group (admin-group) that can be associated with an IP or MPLS interface.

Admin groups, also known as affinity, are used to tag IP and MPLS interfaces that share a specific characteristic with the same identifier. For example, an admin group identifier can represent all links that connect to core routers, or all links that have a bandwidth higher than 10G, or all links that are dedicated to a specific service.

The user first configures locally on each router the name and identifier of each admin group. A maximum of 32 admin groups can be configured per system.

The user then configures the admin group membership of an interface. The user can apply admin groups to a IES, VPRN, network IP, or MPLS interface.

When applied to MPLS interfaces, the interfaces can be included or excluded in the LSP path definition by inferring the admin-group name. CSPF will compute a path that satisfies the admin-group include and exclude constraints.

When applied to IES, VPRN, or network IP interfaces, the interfaces can be included or excluded in the route next-hop selection by inferring the admin-group name in a route next-hop policy template applied to an interface or a set of prefixes.

The following provisioning rules are applied to admin group configuration. The system will reject the creation of an admin-group if it re-uses the same name but with a different group value than an existing group. The system will also reject the creation of an admin-group if it re-uses the same group value but with a different name than an existing group.

Only the admin groups bound to an MPLS interface are advertised area-wide in TE link TLVs and sub-TLVs when the traffic-engineering option is enabled in IS-IS or OSPF. IES and VPRN interfaces do not have their attributes advertised in TE TLVs.

This command defines a Shared Risk Link Group (SRLG) which can be associated with an IP or MPLS interface.

SRLG is used to tag IP or MPLS interfaces which share a specific fate with the same identifier. For example, an SRLG group identifier could represent all links which use separate fibers but are carried in the same fiber conduit. If the conduit is accidentally cut, all the fiber links are cut which means all interfaces using these fiber links will fail.

The user first configures locally on each router the name and identifier of each SRLG group. A maximum of 1024 SRLGs can be configured per system.

The user then configures the SRLG membership of an interface. The user can apply SRLGs to an IES, VPRN, network IP, or MPLS interface. A maximum of 64 SRLGs can be applied to a given interface.

When SRLGs are applied to MPLS interfaces, CSPF at an LER will exclude the SRLGs of interfaces used by the LSP primary path when computing the path of the secondary path. CSPF at an LER or LSR will also exclude the SRLGs of the outgoing interface of the primary LSP path in the computation of the path of the FRR backup LSP. This provides path disjointness between the primary path and the secondary path or FRR backup path of an LSP.

When SRLGs applied to IES, VPRN, or network IP interfaces, they are evaluated in the route next-hop selection by adding the srlg-enable option in a route next-hop policy template applied to an interface or a set of prefixes. For instance, the user can enable the SRLG constraint to select a LFA next-hop for a prefix which avoids all interfaces that share fate with the primary next-hop.

The following provisioning rules are applied to SRLG configuration. The system will reject the creation of a SRLG if it re-uses the same name but with a different group value than an existing group. The system will also reject the creation of an SRLG if it re-uses the same group value but with a different name than an existing group.

Only the SRLGs bound to an MPLS interface are advertised area-wide in TE link TLVs and sub-TLVs when the traffic-engineering option is enabled in IS-IS or OSPF. IES and VPRN interfaces do not have their attributes advertised in TE TLVs.

A user may specify a penalty weight (penalty-weight) associated with an SRLG. This controls the likelihood of paths with links sharing SRLG values with a primary path being used by a bypass or detour LSP. The higher the penalty weight, the less desirable it is to use the link with a given SRLG.

This command creates a logical IP routing or unnumbered MPLS-TP interface. Once created, attributes like IP address, port, or system can be associated with the IP interface.

Interface names are case-sensitive and must be unique within the group of IP interfaces defined for config router interface and config service ies interface. Interface names must not be in the dotted decimal notation of an IP address.; for example, the name “1.1.1.1” is not allowed, but “int-1.1.1.1” is allowed. Show commands for router interfaces use either the interface names or the IP addresses. Ambiguity can exist if an IP address is used as an IP address and an interface name. Duplicate interface names can exist in different router instances, although this is not recommended because it is confusing.

When a new name is entered, a new logical router interface is created. When an existing interface name is entered, the user enters the router interface context for editing and configuration.

Although not a keyword, the ip-int-name “system” is associated with the network entity (such as a specific router), not a specific interface. The system interface is also referred to as the loopback address.

An unnumbered MPLS-TP interface is a special type of interface that is only intended for MPLS-TP LSPs. IP routing protocols are blocked on interfaces of this type. If an interface is configured as unnumbered-mpls-tp, then it can only be associated with an Ethernet port or VLAN, using the port command, then either a unicast, multicast, or broadcast remote MAC address may be configured. Only static ARP is supported.

A GMPLS loopback interface is a special type of loopback interface that is used as the IP interface for a GMPLS IP Control Channel (IPCC). RSVP and LMP packets associated with GMPLS are associated with this loopback interface. All other IP protocols are blocked on this interface. One gmpls-loopback interface is required for each GMPLS peer node.

The control-tunnel parameter creates a loopback interface representing a GRE tunnel. One IP tunnel can be created in this interface.

Only the primary IPv4 interface address and only one IP tunnel per interface are allowed. Multiple tunnels can be configured using up to four controlTunnel loopback interfaces. A static route can take the new controlTunnel interface as a next hop.

The no form of this command removes the IP interface and all the associated configurations. The interface must be administratively shut down before issuing the no interface command.

This command assigns an IP address, IP subnet, and broadcast address format to an IP interface. Only one IP address can be associated with an IP interface. Use the secondary command to assign additional addresses.

An IP address must be assigned to each IP interface. An IP address and a mask combine to create a local IP prefix. The defined IP prefix must be unique within the context of the routing instance. It cannot overlap with other existing IP prefixes defined as local subnets on other IP interfaces in the same routing context within the router.

From Release 19.10, The overlap restriction is not applicable for host-addresses configured on loopback interfaces. For example, a loopback interface addresses configured with mask of 32 or netmask of 255.255.255.255 can overlap with other prefixes on other IP interfaces in the same routing context within the router.

The local subnet that the address command defines must not be part of the services address space within the routing context by use of the config router service-prefix command. Once a portion of the address space is allocated as a service prefix, that portion is not available to IP interfaces for network core connectivity.

The IP address for the interface can be entered in either CIDR (Classless Inter-Domain Routing) or traditional dotted decimal notation. Show commands display CIDR notation and are stored in configuration files.

By default, no IP address or subnet association exists on an IP interface until it is explicitly created.

The no form of this command removes the IP address assignment from the IP interface. Interface specific configurations for MPLS are also removed. This will operationally stop any MPLS LSPs that explicitly reference that IP address. When a new IP address is configured, interface specific configurations for MPLS need to be added. IEEE 1588 port based timestamping configured with ptp-hw-assist is also disabled.

This command enables the forwarding of directed broadcasts out of the IP interface.

A directed broadcast is a packet received on a local router interface destined for the subnet broadcast address of another IP interface. The allow-directed-broadcasts command on an IP interface enables or disables the transmission of packets destined to the subnet broadcast address of the egress IP interface.

When enabled, a frame destined to the local subnet on this IP interface is sent as a subnet broadcast out this interface.

Note: Allowing directed broadcasts is a well-known mechanism used for denial-of-service attacks.

By default, directed broadcasts are not allowed and are discarded at this egress IP interface.

The no form of this command disables directed broadcasts forwarding out of the IP interface.

This command allows the ARP application to learn new entries based on any received ARP message (GARP/ARP-Request/ARP-Reply, such as any frame with ethertype 0x0806).

The no form of this command disables the above behavior and ARP entries are only learned when needed, that is, when the router receives an ARP-reply after an ARP-request triggered by some received traffic.

This command configures the maximum amount of dynamic IPv4 ARP entries that can be learned on an IP interface.

When the number of dynamic ARP entries reaches the configured percentage of this limit, an SNMP trap is sent. When the limit is exceeded, no new entries are learned until an entry expires and traffic to these destinations will be dropped. Entries that have already been learned will be refreshed.

The no form of this command removes the arp-limit.

This command enables the router to always send out a refresh message 30 seconds prior to the timeout of the entry (a single refresh message with no retries).

The no form of this command sets the default behavior, in which an entry is marked as stale 30 seconds prior to age-out, and the router only sends an ARP request to refresh the entry if the IOM receives traffic that uses it. If so, the IOM asks the ARP application to send a refresh message. With arp-proactive-refresh enabled, the ARP module sends a refresh message regardless of the IOM receiving traffic.

This command allows the arp retry timer to be configured to a specific value.

The timer value is entered as a multiple of 100 ms. So a timer value of 1, means the ARP timer will be set to 100 ms.

The no form of this command removes the command from the active configuration and returns the ARP retry timer to its default value of 5 seconds.

This command configures the minimum time, in seconds, an ARP entry learned on the IP interface is stored in the ARP table. ARP entries are automatically refreshed when an ARP request or gratuitous ARP is seen from an IP host. Otherwise, the ARP entry is aged from the ARP table. If the arp-timeout value is set to 0 seconds, ARP aging is disabled.

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

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 the configuration context to configure cflowd parameters for the associated IP interfaces.

cflowd is used for network planning and traffic engineering, capacity planning, security, application and user profiling, performance monitoring, usage-based billing, and SLA measurement.

At a minimum, the sampling command must be configured within this context in order to enable cflowd sampling, otherwise traffic sampling will not occur.

This command enables and configures the cflowd sampling behavior to collect traffic flow samples through a router for analysis.

This command can be used to configure the sampling parameters for unicast and multicast traffic separately. If sampling is not configured for either unicast or multicast traffic, then that type of traffic will not be sampled.

If cflowd is enabled without either egress-only or both specified or with the ingress-only keyword specified, then only ingress sampling will be enabled on the associated IP interface.

The no form of this command disables the associated type of traffic sampling on the associated interface.

This command assigns an existing CPU protection policy for the interface. The CPU protection policies are configured in the config>sys>security>cpu-protection>policy cpu-protection-policy-id context.

This command assigns a Distributed CPU Protection (DCP) policy to the SAP. Only a valid created DCP policy can be assigned to a SAP or a network interface (note that this rule does not apply to templates such as an msap-policy).

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

If enabled, then the following statistics are collected:

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

This command enables MAC Accounting functionality for the interface.

This command enables the context to configure ETH-CFM parameters.

This command provisions an 802.1ag maintenance endpoint (MEP).

The no form of this command deletes the MEP.

This command configures the MEP alarm notification parameters.

This command configures the Fault Notification Generation (FNG) alarm time.

This command configures the FNG reset time.

This command enables the generation of CCM messages.

The no form of this command disables the generation of CCM messages.

This command specifies the priority of the CCM and LTM messages transmitted by the MEP. Since CCM does not apply to the router facility MEP only the LTM priority is of value under that context.

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

This command inserts additional padding in the CCM packets.

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

This command allows the receiving MEP to ignore the specified TLVs in CCM PDU. Ignored TLVs are reported as absent and do not have any impact on the MEP state machine.

The no form of this command causes that the receiving MEP processes all recognized TLVs in the CCM PDU.

This command enables the collection of per-forwarding class LMM statistics.

The collect-lmm-fc-stats and collect-lmm-stats commands are mutually exclusive when there is entity resource contention.

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 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 enables the collection of statistics on the facility MEPs. This command is an object under the facility MEP. This is at a different level of the hierarchy than collection of LMM statistics for service SAPs and MPLS SDP bindings. The show mep command can be used to determine that the facility MEP collects statistics.

The no form of this command disables and deletes the counters for this SAP, binding or facility.