2.5. IP Router Command Reference

The shutdown command administratively disables an 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 administratively enables an entity.

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, and interfaces.

This command creates an aggregate route.

Use this command to group a number of routes with common prefixes into a single entry in the routing table. This reduces the number of routes that need to be advertised by this router and reduces the number of routes in the routing tables of downstream routers.

Both the original components and the aggregated route (source protocol aggregate) are offered to the Routing Table Manager (RTM). Subsequent policies can be configured to assign protocol-specific characteristics (BGP, IS-IS or OSPF), such as the route type or OSPF tag to aggregate routes.

Multiple entries with the same prefix but a different mask can be configured; for example, routes are aggregated to the longest mask. If one aggregate is configured as 10.0./16 and another as 10.0.0./24, then route 10.0.128/17 would be aggregated into 10.0/16, and route 10.0.0.128/25 would be aggregated into 10.0.0/24. If multiple entries are made with the same prefix and the same mask, the previous entry is overwritten.

The no form of this command removes the aggregate.

This command configures the autonomous system (AS) number for the router. A router can only belong to one AS. An ASN 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.

If the ASN is changed on a router with an active BGP instance, the new ASN 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 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. See the description on preferences in the static-route command. 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.

Note: For the 7210 SAS-M, 7210 SAS-T (network mode), 7210 SAS-Sx/S 1/10GE (standalone and standalone-VC), 7210 SAS-Sx 10/100GE, and 7210 SAS-Mxp: Before enabling ECMP, user must allocate appropriate amount of resources using the command configure>system>resource-profile>router>ecmp>max-ecmp-routes. The value specified with this command must be less than or equal to the value specified with the command configure>system>resource-profile>router>ecmp> max-ecmp-routes. Refer to the 7210 SAS-M, T, R6, R12, Mxp, Sx, S Basic System Configuration Guide for more information. For 7210 SAS-R6 and 7210 SAS-R12: Before enabling ECMP, user must allocate appropriate amount of resources using the configure>system>global-resource-profile>router>ecmp>max-ecmp-routes command The value specified with this command must be less than or equal to the value specified with the configure>system>global-resource-profile>router>ecmp>max-ecmp-routes command. Refer to the 7210 SAS-M, T, R6, R12, Mxp, Sx, S Basic System Configuration Guide for more information.

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 IGP chooses the next-hop based on lowest router-ID while static-route chooses the next-hop based on lowest next-hop ip address.

For more information, refer to the 7210 SAS-M, T, R6, R12, Mxp, Sx, S Basic System Configuration Guide.

This command enables the context to configure global parameters related to MPLS labels.

This command configures the range of MPLS static label values shared among static LSP, MPLS-TP LSP, and static service VC label. Once this range is configured, it is reserved and cannot be used by other protocols such as RSVP, LDP, BGP, or segment routing to assign a label dynamically.

This command configures the range of the segment routing global block (SRGB). It is a label block which is used for assigning labels to segment routing prefix SIDs originated by this router. This range is carved from the system dynamic label range and is not instantiated by default.

This is a reserved label and once configured it cannot be used by other protocols such as RSVP, LDP, and BGP to assign a label dynamically.

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.

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 static route entries for both the network and access routes.

When configuring a static route, either next-hop or black-hole must be configured to indicate the type of static route. Different types of static routes can be applied to the same IP prefix. If a static route that is forwarding traffic goes down, the default route will be used instead. The preference parameter is used to specify the order in which the routes are applied. If a blackhole static route has the same reference as another route with the same prefix, the blackhole route takes a lower precedence.

If a CPE connectivity check target address is already being used as the target address in a different static route, then cpe-check parameters must match. If they do not, the new configuration command will be rejected.

If a static-route command is issued with no cpe-check target but the destination prefix/netmask and next hop address matches a static route that did have an associated cpe-check, the cpe-check test will be removed from the associated static route.

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 as necessary to uniquely identify the static route must be entered.

This command enables route policy reevaluation.

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 7210 SAS Mrouter, 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 specific 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. 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 discards the changes that are made to the BFD template configuration.

This command enables the context to configure the BFD template.

This command creates or edits a BFD template. A BFD template defines the set of configurable parameters used by a BFD session. These include the transmit and receive timers 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.

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.

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.

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

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

This command saves the changes made to the BFD template configuration. This command must be executed for the commands to take effect and made persistent across system reboot.

This command creates a logical system or a loopback IP routing or unnumbered MPLS-TP interface. When 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. 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.

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 7210 SAS-M), 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.

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.

Note: MPLS-TP unnumbered interfaces are only supported on 7210 SAS-T (network operating mode), 7210 SAS-R6, and 7210 SAS-R12. IP unnumbered interfaces are supported on all 7210 SAS platforms as described in this document, except for those operating in access-uplink mode. Refer to the 7210 SAS-M, T, R6, R12, Mxp, Sx, S Basic System Configuration Guide for information about allocating addresses toward IP subnets using the config>system>resource-profile>max-ip-subnets CLI command. Before using IPv6, resources for IPv6 routes must be allocated. Refer to the 7210 SAS-M, T, R6, R12, Mxp, Sx, S Basic System Configuration Guide for information about the config>system>resource-profile>max-ipv6-routes CLI command.

This command enables the context to configure an accounting policy. An accounting policy must be defined before it can be associated with a SAP. If the policy-id does not exist, an error message is generated. A maximum of one accounting policy can be associated with a SAP at one time.

This command assigns an IP address, IP subnet, and broadcast address format to an IP system IP interface. Only one IP address can be associated with an IP interface.

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.

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. The no form of this command can only be performed when the IP interface is administratively shut down. Shutting down the IP interface will operationally stop any protocol interfaces or MPLS LSPs that explicitly reference that IP address. When a new IP address is defined, the IP interface can be administratively enabled (no shutdown), which reinitializes the protocol interfaces and MPLS LSPs associated with that IP interface.

If a new address is entered while another address is still active, the new address will be rejected.

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) is notified of the fault.

Note: These hardware sessions cannot be used for an IP interfaces configured over a LAG or for BFD over IP interfaces with system IP address or loopback address. LAG based IP interfaces always use the CPM-based centralized CPU sessions on 7210 SAS-R6, 7210 SAS-R12 and CPU based sessions on 7210 SAS-Sx/S 1/10GE (standalone and standalone-VC), 7210 SAS-Sx 10/100GE, 7210 SAS-T, and 7210 SAS-Mxp with a minimum timer support of 100ms. User cannot configure centralized CPU sessions on 7210 SAS-R6, 7210 SAS-R12 and CPU based sessions on 7210 SAS-T for port-based IP interfaces. For more information about the protocols and platforms that support BFD, see Bidirectional Forwarding Detection.

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

This command creates a delay to make the interface operational by the specified number of seconds

The value is used whenever the system attempts to bring the interface operationally up.

This command configures the IGP-LDP synchronization timer. This timer enables synchronization of IGP and LDP, and synchronization of static routes and LDP. When a link is restored after a failure, IGP sets the link cost to infinity and advertises it; if it is a static route, the route activation is delayed until this timer expires. The supported IGPs are OSPF and IS-IS. The actual value advertised in OSPF is 0xFFFF (65535). The actual value advertised in IS-IS regular metric is 0x3F (63) and in IS-IS wide-metric is 0xFFFFFE (16777214). This command is not supported on RIP interfaces.

If an interface belongs to both IS-IS and OSPF, a physical failure will cause both IGPs to advertise infinite metric and to follow the IGP-LDP synchronization procedures. If only one IGP bounces on this interface or on the system, then only the affected IGP advertises the infinite metric and follows the IGP-LDP synchronization procedures.

The LDP hello adjacency is brought up with the neighbor. The LDP synchronization timer is started by IGP from the time the LDP session to the neighbor is up over the interface. This synchronization timer allows time for the label-FEC bindings to be exchanged.

When the LDP synchronization timer expires, the link cost is restored and is re-advertised. IGP will announce a new best next-hop and LDP will use it if the label binding for the neighbor FEC is available.

The preceding behavior is similar for static routes. If the static route is enabled for ldp-sync (see static-route), the route is not enabled immediately after the interface to the next hop comes up. Routes are suppressed until the LDP adjacency with the neighbor comes up and the synchronization timer expires. The timer does not start until the LDP adjacency with the neighbor node is fully established.

If the user changes the cost of an interface, the new value is advertised at the next flooding of link attributes by IGP. However, if the LDP synchronization timer is still running, the new cost value will only be advertised after the timer expires. Also, if the currently advertised cost is different, the new cost value will be advertised after the user executes any of the following commands:

If the user changes the value of the LDP synchronization timer parameter, the new value will take effect at the next synchronization event. That is, if the timer is still running, it will continue using the previous value.

If parallel links exist to the same neighbor, then the bindings and services should remain UP as long as there is one interface that is up. However, the user-configured LDP synchronization timer still applies on the failed then restored interface. In this case, it will only consider this interface for forwarding after IGP re-advertised its actual cost value.

The LDP Sync Timer State is not always synchronized across to the standby CPM, so after an activity switch the timer state might not be same as it was on the previously active CPM.

The no form of this command disables IGP-LDP synchronization and deletes the configuration.

Note: IGP-LDP synchronization is supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode. Static route-LDP synchronization is supported on all 7210 SAS platforms as described in this document, except platforms operating in access-uplink mode. For more information, see IGP-LDP and Static Route-LDP Synchronization.

This command enables local proxy ARP on the interface.

This command configures the interface as a loopback interface.

This command assigns a specific MAC address to an IP interface. Only one MAC address can be assigned to an IP interface. When multiple mac commands are entered, the last command overwrites the previous command.

The no form of this command reverts the MAC address of the IP interface to the default value.

This command enables SNTP broadcasts received on the IP interface. This parameter is only valid when the SNTP broadcast-client global parameter is configured.

The no form of this command disables SNTP broadcast received on the IP interface.

This command creates an association with a logical IP interface and a physical port.

An interface can also be associated with the system (loopback address).

The command returns an error if the interface is already associated with another port or the system. In this case, the association must be deleted before the command is reattempted. The port-id can be in one of the following forms:

If the card in the slot has MDAs, port-id is in the slot_number/MDA_number/port_number format; for example, 1/1/3 specifies port 3 of the MDA installed in MDA slot 1 on the card installed in chassis slot 1.

The encapsulation type is an property of a Ethernet network port. The port in this context can be tagged with either IEEE 802.1Q (referred to as dot1q) encapsulation or null encapsulation. Dot1q encapsulation supports multiple logical IP interfaces on a specific network port and Null encapsulation supports a single IP interface on the network port.

The no form of this command deletes the association with the port. The no form of this command can only be performed when the interface is administratively down.

This command enables and configures proxy ARP on the interface and specifies an existing policy statement to analyze match and action criteria that controls the flow of routing information to and from a specific protocol, set of protocols, or a particular neighbor. The policy name is configured in the config>router>policy-options context.

Use proxy ARP so the 7210 SAS responds to ARP requests on behalf of another device. Static ARP is used when a 7210 SAS needs to know about a device on an interface that cannot or does not respond to ARP requests. Therefore, the 7210 SAS configuration can state that if it has a packet that has a certain IP address to send it to the corresponding ARP address.

This command associates a network QoS policy of the type “ip-interface” with an IP interface. Only one network QoS policy can be associated with an IP interface at one time. Attempts to associate a second QoS policy return an error.

The network QoS policy of the type ip-interface allows the user to configure an ingress and an egress component. The ingress component allows user to map the EXP bits in the MPLS packets received on the IP interface to one of the eight forwarding classes, and to rate-limit the traffic per FC using ingress policers and meters. The egress component allows the user to optionally enable the marking of EXP bits in MPLS packets by configuring the MPLS EXP values for each of the forwarding classes.

The no form of this command removes the QoS policy association from the IP interface, and the QoS policy reverts to the default.

This command enables remote proxy ARP on the interface.

This command assigns up to 64 secondary IP addresses to the interface, including the primary IP address. Each address can be configured in an IP address, IP subnet, or broadcast address format.

This command configures a static Address Resolution Protocol (ARP) entry associating an IP address with a MAC address for the core router instance. This static ARP appears in the core routing ARP table. A static ARP can only be configured if it exists on the network attached to the IP interface.

If an entry for a particular IP address already exists and a new MAC address is configured for the IP address, the existing MAC address is replaced by the new MAC address. The number of static-arp entries that can be configured on a single node is limited to 1000. Static ARP is used when a 7210 SAS-M needs to know about a device on an interface that cannot or does not respond to ARP requests. Therefore, the 7210 SAS-M configuration can state that if it has a packet that has a certain IP address to send it to the corresponding ARP address. Use proxy ARP so the 7210 SAS responds to ARP requests on behalf of another device.

Note: When used within the context for an MPLS-TP unnumbered interface, the unnumbered parameter is only supported on 7210 SAS-R6, 7210 SAS-R12, and 7210 SAS-T (network operating mode). When used within the context for an MPLS IP unnumbered interface, the unnumbered parameter is supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode.

The no form of this command removes a static ARP entry.

This command configures a static Address Resolution Protocol (ARP) entry associating an unnumbered interface with a MAC address for the core router instance. This static ARP appears in the core routing ARP table. A static ARP can only be configured if it exists on the network attached to an unnumbered interface.

If an entry for a particular unnumbered interface already exists and a new MAC address is configured for the interface, the existing MAC address is replaced by the new MAC address.

The number of static-arp entries that can be configured on a single node is limited to 1000.

Static ARP is used when the node needs to know about a device on an interface that cannot or does not respond to ARP requests. Therefore, the node configuration can state that if it has a packet that has a certain IP address to send it to the corresponding ARP address. Use proxy ARP so the node responds to ARP requests on behalf of another device.

The no form of this command removes a static ARP entry.

This command is used on a network IP interface to alter the default trusted state to a non-trusted state. When unset or reverted to the trusted default, the ToS field will not be remarked by egress network IP interfaces unless the egress network IP interface has the remark-trusted state set, in which case the egress network interface treats all IES and network IP interface as untrusted.

When the ingress network IP interface is set to untrusted, all egress network IP interfaces will remark IP packets received on the network interface according to the egress marking definitions on each network interface. The egress network remarking rules also apply to the ToS field of IP packets routed using IGP shortcuts (tunneled to a remote next-hop). However, the tunnel QoS markings are always derived from the egress network QoS definitions.

Egress marking and remarking is based on the internal forwarding class and profile state of the packet when it reaches the egress interface. The forwarding class is derived from ingress classification functions. The profile of a packet is either derived from ingress classification or ingress policing.

The default marking state for network IP interfaces is trusted. This is equivalent to declaring no tos-marking-state on the network IP interface. When undefined or set to tos-marking-state trusted, the trusted state of the interface will not be displayed when using show config or show info unless the detail parameter is specified. The save config command will not store the default tos-marking-state trusted state for network IP interfaces unless the detail parameter is also specified.

The no form of this command is used to restore the trusted state to a network IP interface. This is equivalent to executing the tos-marking-state trusted command.

This command sets an IP interface as an unnumbered interface and specifies the IP address to be used for the interface.

To conserve IP addresses, unnumbered interfaces can be configured. The address used when generating packets on this interface is the ip-addr parameter configured.

An error message will be generated if an unnumbered interface is configured, and an IP address already exists on this interface.

The no form of this command removes the IP address from the interface, effectively removing the unnumbered property. The interface must be shutdown before no unnumbered is issued to delete the IP address from the interface, or an error message will be generated.

This command enables the context to configure route next-hop policies.

This command discards the changes that have been made to route next-hop templates during the current session.

This command enables the context to edit route next-hop templates. Use the commit command to save edits made during the current session. Use the abort command to discard edits made during the current session.

This command saves the changes that have been made to route next-hop templates during the current session.

This command creates a template to configure the attributes of a Loop-Free Alternate (LFA) Shortest Path First (SPF) policy. An LFA SPF policy allows the user to apply specific criteria, such as admin group and SRLG constraints, to the selection of a LFA backup next-hop for a subset of prefixes which resolve to a specific primary next-hop.

The user first creates a route next-hop policy template under the global router context and then applies it to a specific OSPF or ISIS interface in the global routing instance.

A policy template can be used in both IS-IS and OSPF to apply the specific criteria to prefixes protected by LFA. Each instance of IS-IS or OSPF can apply the same policy template to one or more interfaces.

The commands within the route next-hop policy template use the begin-commit-abort model.

The following are the steps needed to create and modify the template.

When the commit command is executed, IS-IS or OSPF will reevaluate the templates. If there are any net changes, ISIS or OSPF will schedule a new LFA SPF to recompute the LFA next-hop for the prefixes associated with these templates.

The no form of this command deletes the specified template.

This command is used to configure the description of the next-hop template.

This command prunes all links belonging to the specified admin group before making the LFA backup next-hop selection for a prefix.

If the same group name is part of both include-group and exclude-group configurations, the exclude-group configuration takes precedence. It other words, the exclude-group statement can be viewed as having an implicit preference value of 0.

The admin group criteria are applied before running the LFA next-hop selection algorithm.

The no form of this command deletes the admin group exclusion constraint from the route next-hop policy template.

This command instructs the LFA SPF selection algorithm to pick up a subset of LFA next-hops among the links which belong to one or more of the specified admin groups. A link which does not belong to at least one of the admin groups is excluded. However, a link can still be selected if it belongs to one of the groups in an include-group configuration but also belongs to other groups which are not part of any include-group configuration in the route next-hop policy.

The pref option is used to provide a relative preference for the admin group to select. A lower preference value means that LFA SPF will first attempt to select an LFA backup next-hop which is a member of the corresponding admin group. If none is found, then the admin group with the next higher preference value is evaluated. If no preference is configured for a specific admin group name, then it is supposed to be the least preferred, or numerically the highest preference value.

When evaluating multiple include-group configurations within the same preference, any link which belongs to one or more of the included admin groups can be selected as an LFA next-hop. There is no relative preference based on how many of those included admin groups the link is a member of.

If the same group name is part of both include-group and exclude-group configurations, the exclude-group configuration takes precedence. It other words, the exclude-group statement can be viewed as having an implicit preference value of 0.

The admin group criteria are applied before running the LFA next-hop selection algorithm.

The no form of this command deletes the admin group constraint from the route next-hop policy template.

This command configures the next-hop type for the route next-hop policy template.

The user can select IP backup next-hop.

When the route next-hop policy template is applied to an IP interface, all prefixes using this interface as a primary next-hop will follow the next-hop type preference specified in the template.

The no form of this command deletes the next-hop type constraint from the route next-hop policy template.

This command configures the protection type for the route next-hop policy template.

The user can select if link protection or node protection is preferred in the selection of a LFA next-hop for all IP prefixes and LDP FEC prefixes to which a route next-hop policy template is applied. The default in SR OS implementation is node protection. The implementation will fall back to the other type if no LFA next-hop of the preferred type is found.

When the route next-hop policy template is applied to an IP interface, all prefixes using this interface as a primary next-hop will follow the protection type preference specified in the template.

The no form of this command deletes the protection type constraint from the route next-hop policy template.

This command configures the SRLG constraint for the route next-hop policy template.

When this command is applied to a prefix, the LFA SPF will attempt to select an LFA next-hop from the computed ones, which uses an outgoing interface that does not participate in any of the SLRGs of the outgoing interface used by the primary next-hop.

The SRLG criterion is applied before running the LFA next-hop selection algorithm.

The no form of this command deletes the SRLG constraint from the route next-hop policy template.

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

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

This command associates an IP filter policy with an IP interface.

Filter policies control packet forwarding and dropping based on IP match criteria.

The ip-filter-id and ipv6-filter-id must have been preconfigured before this filter command is executed. If the filter ID does not exist, an error occurs.

Only one filter ID can be specified.

Note: For more information about service and IP interface support for different ACL match criteria per platform, see the tables in the Applying Filter Policies section.

The no form of this command removes the filter policy association with the IP interface.

This command enables the context to configure Internet Control Message Protocol (ICMP) parameters on a network IP interface. ICMP is a message control and error reporting protocol that also provides information relevant to IP packet processing.

This command enables responses to ICMP mask requests on the router interface.

If a local node sends an ICMP mask request to the router interface, the mask-reply command configures the router interface to reply to the request.

The no form of this command disables replies to ICMP mask requests on the router interface.

This command enables and configures the rate for ICMP redirect messages issued on the router interface.

When routes are not optimal on this router, and another router on the same subnetwork has a better route, the router can issue an ICMP redirect to alert the sending node that a better route is available.

The redirects command enables the generation of ICMP redirects on the router interface. The rate at which ICMP redirects are issued can be controlled with the optional number and time parameters by indicating the maximum number of redirect messages that can be issued on the interface for a specific time interval.

The no form of this command disables the generation of ICMP redirects on the router interface.

This command configures the rate that Internet Control Message Protocol (ICMP) Time To Live (TTL) expired messages are issued by the IP interface.

The no form of this command disables the generation of TTL expired messages.

This command enables and configures the rate for ICMP host and network destination unreachable messages issued on the router interface.

The unreachables command enables the generation of ICMP destination unreachables on the router interface. The rate at which ICMP unreachables is issued can be controlled with the optional number and seconds parameters by indicating the maximum number of destination unreachable messages that can be issued on the interface for a specific time interval.

The no form of this command disables the generation of ICMP destination unreachables on the router interface.

This command enables 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) which can be associated with an IP or MPLS interface.

Admin groups, also known as affinity, are used to tag IP and MPLS interfaces which share a specific characteristic with the same identifier. For example, an admin group identifier could represent all links which connect to core routers, all links which have bandwidth higher than 10G, or all links which 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 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 which satisfies the admin group include and exclude constraints.

When applied to 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 reuses the same name or group value as an existing group.

Note: Only admin groups bound to an MPLS interface are advertised in TE link TLVs and sub-TLVs when the traffic-engineering option is enabled in IS-IS or OSPF.

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

SRLG is used to tag IP or MPLS interfaces that 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 that 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 a network IP or MPLS interface. A maximum of 64 SRLGs can be applied to a specific interface.

When SRLGs are applied to MPLS interfaces, CSPF at LER will exclude the SRLGs of interfaces used by the LSP primary path when computing the path of the secondary path. CSPF at a 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 are applied to 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 reuses 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 reuses the same group value but with a different name than an existing group.

Note: Only the SRLGs bound to an MPLS interface are advertised in TE link TLVs and sub-TLVs when the traffic-engineering option is enabled in IS-IS or OSPF.

This command configures the admin group membership of an interface. The user can apply admin groups to a network IP or MPLS interface.

Each single operation of the admin-group command allows a maximum of 5 groups to be specified at a time. However, a maximum of 32 groups can be added to a specific interface through multiple operations. When an admin group is bound to one or more interfaces, its value cannot be changed until all bindings are removed.

The configured admin group membership will be applied in all levels/areas the interface is participating in. The same interface cannot have different memberships in different levels/areas.

Note: Only admin groups bound to an MPLS interface are advertised in TE link TLVs and sub-TLVs when the traffic-engineering option is enabled in IS-IS or OSPF.

The no form of this command deletes one or more of the admin-group memberships of an interface. The user can also delete all memberships of an interface by not specifying a group name.

This command configures the SRLG membership of an interface. The user can apply SRLGs to a network IP or MPLS interface.

An interface can belong to a maximum of 64 SRLG groups. However, each single operation of the srlg-group command allows a maximum of 5 groups to be specified at a time. When an SRLG group is bound to one or more interfaces, its value cannot be changed until all bindings are removed.

The configured SRLG membership will be applied in all levels/areas the interface is participating in. The same interface cannot have different memberships in different levels/areas.

Note: Only the SRLGs bound to an MPLS interface are advertised in TE link TLVs and sub-TLVs when the traffic-engineering option is enabled in IS-IS or OSPF.

The no form of this command deletes one or more of the SRLG memberships of an interface. The user can also delete all memberships of an interface by not specifying a group name.

This command configures IPv6 for a router interface.

The no form of this command disables IPv6 on the interface.

This command assigns an IPv6 address to the interface.

This command enables the context to configure ICMPv6 parameters for the interface.

This command configures the rate for ICMPv6 packet-too-big messages.

This command configures the rate for ICMPv6 param-problem messages.

This command configures the rate for ICMPv6 redirect messages. When configured, ICMPv6 redirects are generated when routes are not optimal on the router and another router on the same subnetwork has a better route to alert that node that a better route is available.

The no form of this command disables ICMPv6 redirects.

This command configures rate for ICMPv6 time-exceeded messages.

This command configures the rate for ICMPv6 unreachable messages. When enabled, ICMPv6 host and network unreachable messages are generated by this interface.

The no form of this command disables the generation of ICMPv6 host and network unreachable messages by this interface.

This command configures the link local address.

This command enables local proxy neighbor discovery on the interface.

The no form of this command disables local proxy neighbor discovery.

This command configure a proxy neighbor discovery policy for the interface.

This command configures an IPv6-to-MAC address mapping on the interface. Use this command if a directly attached IPv6 node does not support ICMPv6 neighbor discovery, or for some reason, a static address must be used. This command can only be used on Ethernet media.

The ipv6-address must be on the subnet that was configured from the IPv6 address command or a link-local address.

This command enables the context to configure router advertisement properties.

The no form of this command disables all IPv6 interfaces. However, the no interface ip-int-name command disables a specific interface.

This command configures router advertisement properties on a specific interface. The interface must already exist in the config>router>interface context.

This command configures the current-hop-limit in the router advertisement messages. It informs the nodes on the subnet about the hop-limit when originating IPv6 packets.

This command sets the managed address configuration flag. This flag indicates that DHCPv6 is available for address configuration in addition to any address autoconfigured using stateless address autoconfiguration.

This command configures the maximum interval between sending router advertisement messages.

This command configures the minimum interval between sending ICMPv6 neighbor discovery router advertisement messages.

This command configures the MTU for the nodes to use to send packets on the link.

This command sets the "Other configuration" flag. This flag indicates that DHCPv6lite is available for autoconfiguration of other (non-address) information such as DNS-related information or information about other servers in the network. See RFC 3736, Stateless Dynamic Host Configuration Protocol (DHCP) for IPv6.

This command configures an IPv6 prefix in the router advertisement messages. To support multiple IPv6 prefixes, use multiple prefix statements. No prefix is advertised until explicitly configured using prefix statements.

This command specifies whether the prefix can be used for stateless address autoconfiguration.

This command specifies whether the prefix can be used for on-link determination.

This command configures the remaining length of time, in seconds, that this prefix will continue to be preferred, such as, time until deprecation. The address generated from a deprecated prefix should not be used as a source address in new communications, but packets received on such an interface are processed as expected.

This command specifies the length of time, in seconds, that the prefix is valid for the purpose of on-link determination. A value of all one bits (0xffffffff) represents infinity.

The address generated from an invalidated prefix should not appear as the destination or source address of a packet.

This command configures how long this router should be considered reachable by other nodes on the link after receiving a reachability confirmation.

This command configures the retransmission frequency of neighbor solicitation messages.

This command sets the router lifetime.

This command enables sending router advertisement messages using the VRRP virtual MAC address, provided that the virtual router is currently the master. If the virtual router is not the master, no router advertisement messages are sent.

The no form of this command disables sending router advertisement messages.