3.11. IP Router Command Reference

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

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

The shutdown command administratively disables the entity. The operational state of the entity is disabled as well as the operational state of any entities contained within. When disabled, an entity does not change, reset, or remove any configuration settings or statistics. Many objects must be shut down before they may be deleted. Many entities must be explicitly enabled using the no shutdown command.

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 the command puts an entity into the administratively enabled state.

This command enables the context to configure router parameters, interfaces, route policies, and protocols.

The router name refers to the router instance (in other commands, the router instance can be either router name or service ID). The 7705 SAR has two routing domains (instances).

The base routing domain includes all in-band IP traffic; that is, any IP packet arriving at the router over any IP interface (all services, all physical ports on the adapter cards). The routing table for the base instance is populated with these IP addresses.

The management routing domain is for out-of-band management traffic; that is, the Mgmt port on the CSM is being used for management traffic. In this case, the routing table for the management routing instance is populated.

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, such as the OSPF tag, to aggregate routes.

Multiple entries with the same prefix but a different mask can be configured; 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 the command removes the aggregate.

The following adapter cards and platforms support the full IPv6 subnet range for IPv6 static routes:

For these cards and platforms, the supported route range for statically provisioned or dynamically learned routes is from /1 to /128.

For all other cards, modules, and ports (including the v-port on the 2-port 10GigE (Ethernet) module), the supported range for statically provisioned or dynamically learned routes is from /1 to /64 or is /128 (indicating a host route).

This command allows or drops ICMP redirects received on the management interface.

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 (Equal-Cost Multipath Protocol) refers to the distribution of packets over two or more outgoing links that share the same routing cost. ECMP provides a fast local reaction to route failures. ECMP is supported on static routes and dynamic (OSPF, IS-IS, and BGP) routes.

ECMP can only be used for routes with the same preference and same protocol. See the static-route command for information on preferences.

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 the command disables ECMP path sharing. If ECMP is disabled and multiple routes are available at the best preference and equal cost, the route with the lowest next-hop IP address is used.

The no form of the command disables ECMP path sharing.

This command enables the context to configure interface attributes such as administrative group and SRLG.

This command defines an administrative group (admin group) that can be associated with an IP or MPLS interface. Admin groups 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 10 Gbytes.

Admin groups must be defined before they can be assigned to an MPLS or IP interface in the config>router>mpls>interface or config>router>interface>if-attribute context. Up to 32 group names can be defined. The admin-group names must be identical across all routers in a single domain.The IGP communicates the information throughout the area.

When admin groups are associated with MPLS interfaces, the interfaces can be included or excluded in the LSP path definition by matching on the admin-group name. CSPF will compute a path that satisfies the admin-group include and exclude constraints.

When admin groups are associated with network IP interfaces, the interfaces can be included or excluded in the route next-hop selection by matching on the admin-group name in a route next-hop policy template applied to an interface or a set of prefixes.

The system will reject the creation of an admin group 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 admin group if it reuses 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.

The no form of this command deletes the admin group.

This command defines a Shared Risk Link Group (SRLG) that can be associated with an IP or MPLS interface. SRLG is used to tag IP or MPLS interfaces that share the same risk of failure with the same identifier. For example, an SRLG group identifier could represent all links that 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.

SRLGs must be defined before they can be assigned to an MPLS or IP interface in the config>router>mpls>interface or config>router>interface>if-attribute context. Up to 256 group names can be defined. SRLG names must be identical across all routers in a single domain.

When SRLGs are associated with MPLS interfaces, CSPF at an LER will exclude the SRLGs of interfaces used by the LSP primary path when calculating the route 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 calculation of the path of the FRR backup LSP. This provides a path disjoint between the primary path and the secondary path or FRR backup path of an LSP.

When SRLGs are associated with network IP interfaces, they are evaluated in the route next-hop selection if the srlg-enable option is included in a route next-hop policy template applied to an interface or a set of prefixes. For example, the SRLG constraint can be enabled to select an LFA next hop for a prefix that avoids all interfaces that share the same risk of failure as the primary next hop.

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.

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.

The no form of this command deletes the SRLG.

This command enables IP Fast Reroute (FRR).

IP FRR protects against link or node failures in an IP network by precalculating a backup route to use when the primary next hop is not available. Both routes are populated in the RTM.

IP FRR uses a Loop-Free Alternate (LFA) backup next hop to forward in-transit IP packets as soon as the primary next-hop failure is detected and the backup is invoked. This means that a node resumes forwarding IP packets to a destination prefix without waiting for the routing convergence. Convergence times should be similar to RSVP-TE FRR, in the tens of milliseconds.

The backup LFA is enabled when either of the following events occurs:

IP FRR is supported on IPv4 and IPv6 OSPF and IS-IS prefixes and on VPN-IPv4 OSPF prefixes forwarded in the base router instance. IP FRR also provides an LFA backup next hop for the destination prefix of a GRE tunnel used in an SDP or in VPRN auto-bind.

This command enables the context to configure IPv6 neighbor discovery parameters on the router.

This command specifies the time that an IPv6 neighbor remains in a reachable state.

This command specifies the time that an IPv6 neighbor cache entry remains in a stale state. When the specified time elapses, the system removes the neighbor cache entry.

This command enables the context to configure reassembly profiles.

This command creates a reassembly profile and enables the context to configure the reassembly profile parameters. The reassembly profile contains all of the timing information used to ensure that all expected fragments of a packet are received within an expected time frame, on a per-forwarding class basis. When the reassembly profile timers expire, all fragments of the current incomplete frame are dropped and a “Fragment Reassembly Time Exceeded” ICMP error message is sent to the source node.

The no form of the command deletes the specified profile.

This command configures the CBS for all reassembly queue groups of each forwarding class that does not have a configured CBS override. The reassembly queue groups are the groups of queues that are used to reassemble fragmented packets.

This command configures the early packet discard (EPD) threshold. This value is a percentage of the MBS and CBS. When the reassembly queue group reaches the configured percentage of the MBS and CBS, all fragments of packets without existing reassembly contexts are discarded. Fragments of packets whose reassembly contexts are already created will still be accepted until the MBS and CBS is reached.

This command creates a forwarding class for which exclusive CBS, MBS, and wait times can be configured.

Note: When no forwarding class is specified, the CBS, MBS, and wait times configured for the reassembly profile are used.

This command configures the CBS for the specified forwarding class. This value overrides the CBS value configured for the reassembly profile.

The no form of the command removes the CBS override for the specified forwarding class; the CBS configured for the reassembly profile is used.

This command configures the MBS for the specified forwarding class in either bytes or kilobytes. The default configuration is in kilobytes. This value overrides the MBS value configured for the reassembly profile.

Note: For the 7705 SAR, 1 kbyte of buffer management space is 1000 bytes.

The MBS value is used by a reassembly queue group to prevent exhaustion of the main buffer pool while enqueuing packet fragments. If the queue group exceeds the number of buffers allowed by MBS, all buffers previously used to reassemble packets are freed up except for one. The remaining buffer remains active until all remaining fragments of the frame are received and discarded, or the wait time expires, after which the buffer is freed up.

The sum of the MBS for all queues on an adapter card or fixed platform can exceed the total amount of buffering available. Therefore, for a packet fragment arriving at a queue group that has not exceeded its MBS size, it is not guaranteed that a buffer will be available. If a buffer is not available, the packet fragment will be discarded.

Setting proper CBS parameters and controlling CBS oversubscription is one major safeguard against queue starvation (that is, when a queue does not receive an adequate share of buffers).

The no form of the command removes the MBS override for the specified forwarding class; the MBS configured for the reassembly profile is used.

This command configures the wait time for the specified forwarding class. The wait time specifies the amount of time that the IP reassembly function will wait to reassemble a packet before discarding the collected fragments. This value overrides the wait time configured for the reassembly profile.

The no form of the command removes the wait time override for the specified forwarding class; the wait time configured for the reassembly profile is used.

This command configures the MBS, in either bytes or kilobytes, for all queue groups of each forwarding class that does not have a configured MBS override. The default configuration is in kilobytes.

Note: For the 7705 SAR, 1 kbyte of buffer management space is 1000 bytes.

The MBS value is used by a reassembly queue group to prevent exhaustion of the main buffer pool while enqueuing packet fragments. If the queue group exceeds the number of buffers allowed by MBS, all buffers previously used to reassemble packets are freed up except for one. The remaining buffer remains active until all remaining fragments of the frame are received and discarded, or the wait time expires, after which the buffer is freed up.

The sum of the MBS for all queues on an adapter card or fixed platform can exceed the total amount of buffering available. Therefore, for a packet fragment arriving at a queue group that has not exceeded its MBS size, it is not guaranteed that a buffer will be available. If a buffer is not available, the packet fragment will be discarded.

Setting proper CBS parameters and controlling CBS oversubscription is one major safeguard against queue starvation (that is, when a queue does not receive an adequate share of buffers).

This command configures the wait time for the reassembly profile. The wait time specifies the amount of time that the IP reassembly function will wait to reassemble a packet before discarding the collected fragments.

Note: The system checks the reassembly queues every 64 ms in a constant loop, which may cause a maximum of 63 ms variation between the user-configured value and the actual detection time. For example, using the default configuration of 2000 ms, the system may check the reassembly queue timer at 1999 ms, in which case the timeout would not occur during that cycle and would instead take place during the next cycle at 2063 ms.

This command enables the context to create Loop-Free Alternate (LFA) Shortest Path First (SPF) policies. LFA SPF policies allow specific criteria, such as admin group and SRLG constraints, to be applied when selecting an LFA backup next hop for a subset of prefixes that resolve to a primary next hop.

This command discards any changes made to the route next-hop policy template.

This command enters the mode to create or edit the route next-hop policy template.

This command saves any changes made to the route next-hop policy template.

This command creates a template to configure the attributes of an LFA SPF policy. When the template is created, it can then be applied to a specific OSPF or IS-IS interface. 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.

Use the begin command to create or edit the template attributes. Use the abort command to discard any changes made before saving. Use the commit command to save the changes.

When the commit command is issued, OSPF or IS-IS will re-evaluate the template, and if there are any changes, the protocol will schedule a new LFA SPF to recalculate the LFA next hop for the prefixes associated with the template.

This command configures the admin group constraint in the route next-hop policy template. Each group is entered individually. The 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 the include-group and exclude-group statements, the exclude statement takes precedence.

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

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

This command configures the admin group constraint in the route next-hop policy template. Each group is entered individually. The command instructs the LFA SPF selection algorithm to pick up a subset of LFA next hops among the links that belong to one or more of the specified admin groups. A link that 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 statement but also belongs to other groups that are not part of any include-group statement in the route next-hop policy.

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

When evaluating multiple include-group statements with the same preference, any link that 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 the include-group and exclude-group statements, the exclude statement takes precedence.

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

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

This command configures the next-hop type constraint in the route next-hop policy template. Either a tunnel backup next hop or an IP backup next hop can be selected as the preferred next hop. The default is an IP next hop.

If no LFA next hop of the preferred type is found, the other type will be selected.

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 the command deletes the next-hop type constraint from the route next-hop policy template.

This command configures the protection type constraint in the route next-hop policy template. Either link protection or node protection can be selected as the preferred protection type in the selection of an LFA next hop for all IP prefixes and LDP FEC prefixes to which the template is applied. The default is node protection.

If no LFA next hop of the preferred type is found, the other type will be selected.

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 the command deletes the next-hop type constraint from the route next-hop policy template.

This command configures the SRLG constraint in 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 that uses an outgoing interface that does not participate in any of the SRLGs 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 the command deletes the SRLG constraint from the route next-hop policy template.

This command configures the router ID for the router instance.

The router ID is used by OSPF and BGP in the routing table manager. IS-IS uses the router ID as its system ID. Refer to the 7705 SAR Routing Protocols Guide for information on OSPF, IS-IS, and BGP.

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 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 the command reverts to the default value.

This command reserves one or more IP address ranges for IES or VPRN services. The range can be made up of IPv4 or IPv6 addresses.

When the service is configured, the IP address must be within one of the ranges defined in the service-prefix command. If the service-prefix command is not configured, then no limitation exists.

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

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

Similarly, when the configured range is a subset of a previously defined service prefix, the new subset definition replaces the existing definition providing the addresses used by services are not affected. For example, if a service prefix exists for 10.10.0.0/16, and a new service prefix is configured as 10.10.10.0/24, then the 10.10.0.0/16 entry is removed provided that there are no configured services that are using the 10.10.x.x addresses other than 10.10.10.x.

The no form of the command removes all IP address reservations. A service prefix cannot be unreserved if one or more services is using an address or addresses in the defined range.

This command creates IPv4 and IPv6 static route entries for network routes. When configuring a static route, the next-hop, indirect, or black-hole parameter, indicating the type of static route, must be configured. Multiple types of static routes (next-hop, indirect, black-hole) 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 preference as another route with the same prefix, the blackhole route takes a lower precedence.

If the next hop or interface pointing to the next hop changes state (from active to inactive or vice versa), an event is generated and a trap is raised. The generation of this event is disabled by default. To enable generation of this event globally (across all routing instances), the appropriate command must be configured under config>log>event-control (refer to the 7705 SAR System Management Guide).

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

If the router name is management (see router), the static routes configured populate the routing table for the management routing instance. Up to 32 IPv4 and 32 IPv6 static routes can be configured for management traffic. This is in addition to the management routes configured using the bof>static-route command (refer to the 7705 SAR Basic System Configuration Guide, “BOF Command Reference”). The static routes are not added to the routing table until after the configuration file is executed in the application load.

The following adapter cards and platforms support the full IPv6 subnet range for IPv6 static routes:

For these cards and platforms, the supported route range for statically provisioned or dynamically learned routes is from /1 to /128.

For all other cards, modules, and ports (including the v-port on the 2-port 10GigE (Ethernet) module), the supported range for statically provisioned or dynamically learned routes is from /1 to /64 or is /128 (indicating a host route).

This command enables the context to configure local DHCP server parameters.

This command enables the context to configure local DHCPv6 server parameters.

This command creates a local DHCP or DHCPv6 server instance. A local DHCP or DHCPv6 server can serve multiple interfaces but is limited to the routing context in which it was created.

The no form of the command removes the local DHCP or DHCPv6 server instance.

This command enables the sending of FORCERENEW messages. If the DHCP server sends a unicast FORCERENEW message to the client, upon receipt of the message, the client will change its state to the RENEW state and will then try to renew its lease according to normal DHCP procedures.

The no form of the command disables the use of FORCERENEW messages.

This command specifies whether the Rapid Commit Option (RCO) sent by the DHCPv6 client is processed.

If enabled and the client has included an RCO in the solicit, then the server ignores the option and processes the remainder of the message as if no RCO were present.

The no form of the command disables the ignore-rapid-commit command.

This command configures the time to retain a lease. The lease-hold-time is for unsolicited release conditions such as lease timeout and for normal solicited release from a DHCPv6 client.

This command configures a DHCP or DHCPv6 address pool on the router.

The no form of the command deletes a configured IP address pool.

This command configures the maximum amount of time that a client can lease the IP address.

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

This command configures the minimum amount of time that a client can lease the IP address.

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

This command configures the minimum number of free addresses in the pool or subnet. If the actual number of free addresses in the pool or subnet falls below the configured minimum, a notification is generated.

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

This command configures the time interval during which a DHCP offer advertisement is valid. If the client does not respond with a DHCP REQUEST within this interval, the lease is returned to the available lease pool.

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

This command enables the context to configure pool options. If the same options are defined several times in different contexts, the options defined at the subnet level take precedence over those defined at the pool level; options defined at the pool level take precedence over those defined from a DHCP or DHCPv6 client request.

This command configures specific DHCP or DHCPv6 options. If the same options are defined several times in different contexts, the options defined at the subnet level take precedence over those defined at the pool level; options defined at the pool level take precedence over those defined from a DHCP or DHCPv6 client request.

The no form of the command removes the option from the configuration.

This command configures the IP address of the DNS servers.

This command configures the default domain for a DHCP or DHCPv6 client that the router uses to complete unqualified host names (without a dotted-decimal domain name).

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

This command configures the time from the assignment of the IP address until the client transitions to a rebinding state.

The no form of the command removes the time from the configuration.

This command configures the time from the assignment of the IP address until the client transitions to a renew state.

The no form of the command removes the time from the configuration.

This command configures the time that the DHCP server grants permission to the DHCP client to use a particular IP address.

The no form of the command removes the lease time parameters from the configuration.

This command configures up to four Network Basic Input/Output System (NetBIOS) name server IP addresses.

The no form of this command removes the configuration.

This command configures the NetBIOS node type. The available types are:

The no form of this command removes the configuration.

This command enables a prefix to be routed to hosts associated with the DHCPv6 server pool. Each prefix is represented in the associated FIB with a reference to the pool.

This command configures the preferred lifetime that this prefix will continue to be preferred. The address generated from a prefix that is no longer preferred should not be used as a source address in new communications. However, packets received on such an interface are processed as expected.

This command configures the time from the assignment of the IP address until the client transitions to a rebinding state.

The no form of the command removes the timer from the configuration.

This command configures the time from the assignment of the IP address until the client transitions to a renew state.

The no form of the command removes the timer from the configuration.

This command specifies the length of time that the prefix is valid for the purpose of onlink determination. The address generated from an invalidated prefix should not appear as the destination or source address of a packet.

This command creates a subnet of IP addresses to be served from the pool. The subnet cannot include any addresses that were assigned to subscribers; those addresses must be excluded. When the subnet is created, no IP addresses are made available until a range is defined.

The no form of this command removes the configuration.

This command configures a range of IP addresses to be served from the pool. All IP addresses between the start and end IP addresses will be included (other than specific excluded addresses).

The no form of this command removes the configuration.

This command configures a range of IP addresses to be excluded from this subnet’s pool of IP addresses.

The no form of the command removes the configuration.

This command configures the maximum number of addresses that the client can decline from the server due to the address being in use.

The no form of the command removes the configuration.

This command configures the IP address of the default router for a DHCP client. Up to four IP addresses can be specified.

The no form of the command removes the addresses from the configuration.

This command specifies the subnet mask option to the client. The mask can either be defined (for supernetting) or taken from the pool address.

The no form of the command removes the address from the configuration.

This command enables the use of gateway IP address (GIADDR) matching. If the gi-address flag is enabled, a pool can be used even if a subnet is not found.

A pool can include multiple subnets. Since the GIADDR is shared by multiple subnets in a subscriber interface, the pool may provide IP addresses from any of the subnets included when the GIADDR is matched to any of its subnets. This allows a pool to be created that represents a subnet.

The no form of the command disables GIADDR matching.

This command allows an operator to customize the server-id attribute of a DHCPv6 message from the DHCPv6 proxy server (such as DHCPv6 advertise and reply). By default, the server-id uses DUID-ll (DHCP unique identifier-leased line) derived from the system link layer address. Operators have the option to use a unique identifier by using DUID-en (vendor identifier based on enterprise number). There is a maximum length associated with the customizable hex-string and ascii-string.

This command enables the local DHCPv6 server to use the link address supplied by the Relay agent to find a matching subnet prefix.

The no form of the command reverts to the default.

This command enables the use of the pool indicated by the DHCP or DHCPv6 client. When enabled, the IP address pool to be used by this server is the pool indicated by the vendor-specific suboption 13 of DHCP option 82. When disabled or if there is no suboption 13 in the DHCP message, the pool selection is specified by the value of the GIADDR.

The no form of the command disables the use of the pool indicated by the DHCP or DHCPv6 client.

This command specifies which method is used by the local DHCPv6 server to uniquely identify a user.

The no form of the command reverts to the default.

This command creates a logical IP routing 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 and must begin with a letter; 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 both 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 interface name “system” is associated with the network entity (such as a specific 7705 SAR), not a specific interface. The system interface is also referred to as the loopback address.

The no form of the 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 and IP subnet to an IP interface or enables the interface to accept a dynamic IP address using DHCP. 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 the command removes the IP address assignment from the IP interface. Interface- specific configurations for MPLS/RSVP-TE are also removed. This will operationally stop any MPLS LSPs that explicitly reference that IP address.

When a new IP address is defined, interface-specific configurations for MPLS/RSVP-TE must be added again.

If dynamic IP address assignment is enabled (using the dhcp keyword), the DHCP client ID (Option 61) and vendor class ID (Option 60) can be configured as specified in RFC 2132.

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 for the subnet broadcast address of the egress IP interface.

When enabled, a frame destined for 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 the command disables directed broadcasts forwarding out of the IP interface.

This command specifies the length of time, in 100s of milliseconds, that the system waits before reissuing a failed ARP request.

The no form of the command resets the interval to the default value.

Note: The ARP retry default value of 5000 ms is intended to protect CPU cycles on the 7705 SAR, especially when it has a large number of interfaces. Configuring the ARP retry timer to a value shorter than the default should be done only on mission-critical links, such as uplinks or aggregate spoke SDPs transporting mobile traffic; otherwise, the retry interval should be left at the default value.

This command configures the minimum interval, in seconds, that 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 s, ARP aging is disabled.

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

Note: The 7705 SAR will attempt to refresh an ARP entry 30 s prior to its expiry. This refresh attempt occurs only if the ARP timeout is set to 45 s or more.

This command configures the time interval in which BFD control messages are transmitted and received on the interface. The multiplier parameter specifies the number of consecutive BFD messages that must be missed by the peer node before the BFD session closes and the upper layer protocols (OSPF, IS-IS, BGP, PIM) are notified of the fault.

See Bidirectional Forwarding Detection (BFD) for more information on BFD.

This command enables the context to assign interface attributes such as administrative group and SRLG.

This command associates admin groups with this interface. The admin group must already be defined in the config>router>if-attribute>admin-group context.

Up to five groups can be specified with one command. When an admin group is bound to one or more interfaces, its value cannot be changed until all bindings are removed.

When admin groups are associated with network IP interfaces, the interfaces can be included or excluded in the route next-hop selection by matching on the admin-group name in a route next-hop policy template applied to an interface or a set of prefixes.

The configured admin-group membership is applied in all levels or areas that the interface is participating in. The same interface cannot have different memberships in different levels or areas.

The no form of this command deletes the association of this interface with one or more of the admin groups.

This command associates SRLGs with this interface. The SRLG must already be defined in the config>router>if-attribute>srlg-group context.

Up to five SRLGs can be specified with one command. When an SRLG is bound to one or more interfaces, its value cannot be changed until all bindings are removed.

When SRLGs are associated with network IP interfaces, they are evaluated in the route next-hop selection if the srlg-enable option is included in a route next-hop policy template applied to an interface or a set of prefixes. For example, the SRLG constraint can be enabled to select an LFA next hop for a prefix that avoids all interfaces that share the same outcome as the primary next hop.

The configured SRLG membership is applied in all levels or areas that the interface is participating in. The same interface cannot have different memberships in different levels or areas.

The no form of this command deletes the association of this interface with one or more of the SRLGs.

This command configures Layer 4 load balancing at the interface level. Configuration must be done on the ingress network interface (that is, the interface on the node that the packet is received on). When enabled, Layer 4 source and destination port fields of incoming TCP/UDP packets are included in the hashing calculation to randomly determine the distribution of packets.

You can add additional fields to generate more randomness and more equal distribution of packets with the teid-load-balancing command.

The default configuration on the interface is to match the Layer 4 load-balancing configuration in the config>system context. Using this command to modify Layer 4 load-balancing configuration on an interface overrides the system-wide load-balancing settings for that interface.

This command configures the IGP-LDP synchronization timer to enable synchronization of IGP and LDP and synchronization of static routes and LDP. This command is not supported on RIP interfaces.

When a link is restored after a failure, IGP sets the link cost to infinity and advertises it. The supported IGPs are OSPF and IS-IS. The value advertised in OSPF is 0xFFFF (65535). The value advertised in IS-IS regular metric is 0x3F (63) and in IS-IS wide-metric is 0xFFFFFE (16777214).  

After IGP advertises the link cost, 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 readvertised. IGP will announce a new best next-hop and LDP will use it if the label binding for the neighbor’s FEC is available.

The above 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. For static routes, the ldp-sync-timer function requires LDP to use the interface address, not the system address, as its transport address.

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:

Refer to the 7705 SAR OAM and Diagnostics Guide for the tools commands and to the 7705 SAR Routing Protocols Guide for the OSPF and IS-IS commands.

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

If parallel links exist to the same neighbor,  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, the 7705 SAR will only consider this interface for forwarding after IGP re-advertises its actual cost value.

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

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

Note: If the ldp-sync-timer value is configured on the interface but LDP is not running on the interface, the configuration will cause the IGP route cost to increase to the maximum value.

This command associates the interface with a local DHCP server configured on the system.

The no form of the command removes the association of the interface with the local DHCP server.

This command enables local proxy ARP on the interface.

Local proxy ARP allows the 7705 SAR to respond to ARP requests received on an interface for an IP address that is part of a subnet assigned to the interface. The router responds to all requests for IP addresses within the subnet with its own MAC address and forwards all traffic between the hosts in the subnet.

Local proxy ARP is used on subnets where hosts are prevented from communicating directly.

This command configures the interface as a loopback interface.

This command configures LSR load balancing at the interface level. Configuration must be done on the ingress network interface (that is, the interface on the LDP LSR node that the packet is received on).

Hashing can be enabled on the IP header at an LSR to send labeled packets over multiple equal-cost paths in an LDP LSP and/or over multiple links of a LAG group in all types of LSPs.

The bottom-of-stack option determines the significance of the bottom-of-stack label (VC label) based on which label stack profile option is specified.

When LSR load balancing is enabled, the default configuration for the hashing algorithm is label-only (lbl-only) hashing, and the default configuration for the bottom-of-stack hashing treatment is profile-1.

The use-ingress-port option, when enabled, specifies that the ingress port will be used by the hashing algorithm at the LSR. This option should be enabled for ingress LAG ports because packets with the same label stack can arrive on all ports of a LAG interface. In this case, using the ingress port in the hashing algorithm will result in better egress load balancing, especially for pseudowires.

The option should be disabled for LDP ECMP so that the ingress port is not used by the hashing algorithm. For ingress LDP ECMP, if the ingress port is used by the hashing algorithm, the hash distribution could be biased, especially for pseudowires.

LSR load-balancing configuration on an interface overrides the system-wide LSR load-balancing settings for the interface.

This command enables or disables the receiving of SNTP broadcasts on the IP interface.

This parameter is only valid when the SNTP broadcast-client global parameter is configured.

The no form of the 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 name consists of the port-id (for T1/E1 interfaces and Ethernet interfaces) and an optional encapsulation value (for Ethernet interfaces). The port name can also be the bundle-id used for the multilink bundle (PPP or IMA). Refer to the 7705 SAR Interface Configuration Guide for information on configuring ports.

The no form of the 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 proxy ARP on the interface and specifies an existing policy statement that controls the flow of routing information by analyzing match and action criteria. The policy statement is configured in the config>router>policy-options context (see Route Policy Options in the Route Policy Command Reference section). When proxy ARP is enabled, the 7705 SAR responds to ARP requests on behalf of another device.

This command associates a network Quality of Service (QoS) policy 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.

Packets are marked using QoS policies on edge devices. Invoking a QoS policy on a network port allows for the packets that match the policy criteria to be remarked.

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

This command assigns a reassembly profile to the interface. The same interface must receive all fragments from a fragmented flow.

Reassembly profiles cannot be assigned to an interface that uses an unsupported adapter card, or to a LAG that contains a port from an unsupported adapter card. All Ethernet adapter cards and Ethernet ports on the 7705 SAR fixed platforms support reassembly profiles except for the following adapter cards:

The no form of the command removes the association between the interface and the reassembly profile.

This command enables remote proxy ARP on the interface, allowing a router on one network to respond to ARP requests intended for another node that is physically located on another network. The router effectively pretends to be the destination node by sending an ARP response to the originating node that associates the router’s MAC address with the destination node’s IP address (acts as a proxy for the destination node). The router then takes responsibility for routing traffic to the real destination.

This command configures a static 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.

A router interface can only have one static ARP entry configured for it.

Static ARP is used when a 7705 SAR needs to know about a device on an interface that cannot or does not respond to ARP requests. Therefore, the 7705 SAR configuration can state that, if it has a packet that has a certain IP address, to send it to the corresponding ARP address.

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

This command configures the maximum segment size (MSS) in a TCP SYN or SYN-ACK packet during the establishment of a TCP connection. A tcp-mss value can be specified on an ingress interface, egress interface, or both. When configured on two interfaces, the smaller of the two values is used. If the TCP SYN packet has no TCP MSS field, the 7705 SAR assigns it the MSS value configured on the interface and recalculates the IP checksum. If the TCP SYN or SYN-ACK packet has an MSS field and the value is greater than the value configured on the interface, the 7705 SAR overwrites the packet MSS value with the lower value. If the MSS value is less than the value configured on the interface, the packet MSS value does not change.

This command is supported on interfaces with IPv4 and IPv6 traffic, and a different MSS value can be configured for the IPv4 and IPv6 interfaces.

This command configures TEID load balancing at the interface level. Configuration must be done on the ingress network interface (that is, the interface on the node that the packet is received on). The TEID attribute is included in the header of GTP (general packet radio system tunneling protocol) packets. When TEID load balancing is enabled, the TEID field of incoming TCP/UDP packets is included in the hashing calculation to randomly determine the distribution of packets.

You can add additional fields to generate more randomness and more equal distribution of packets with the l4-load-balancing command.

This command configures an IP interface as an unnumbered interface and specifies an IP address or interface name to be used for the interface. Unnumbered interfaces are point-to-point interfaces that are not explicitly configured with a dedicated IP address and subnet; instead, they borrow an IP address from another interface on the system (the system IP address, another loopback interface, or any other numbered interface).

If the dhcp keyword is specified, the interface can accept a dynamic system IP address using DHCP. If dynamic IP address assignment is enabled, the DHCP client ID (Option 61) and vendor class ID (Option 60) can be configured as specified in RFC 2132.

Only one unnumbered interface with the dhcp option can be associated with the “system” interface. Attempts to configure a second unnumbered interface with a binding to “system” is blocked in the CLI when the “system” interface already has an “unnumbered dhcp” binding.

Only one IP address can be associated with an IP interface; the interface cannot be configured as unnumbered if an IP address already exists.

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

The no form of the 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 defined, interface-specific configurations for MPLS must be added again.

This command enables the context to configure IPv6 parameters on a router interface.

IP version 6 (IPv6) addresses are supported on:

This command automatically generates an FE80:: link-local address.

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

This command assigns an IPv6 address to the interface.

The following adapter cards and platforms support the full IPv6 subnet range for interface IP addresses:

For these cards and platforms, the supported interface IP address prefixes are from /4 to /127, and /128 on system or loopback interfaces.

For all other cards, modules, and ports (including the v-port on the 2-port 10GigE (Ethernet) module), the supported interface IP address prefixes are from /4 to /64, and /128 on system or loopback interfaces.

This command associates the interface with a local DHCPv6 server configured on the system.

The no form of the command removes the association of the interface with the local DHCPv6 server.

This command configures the IPv6 link local address.

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 a static address must be used. This command can only be used on Ethernet interfaces. The ipv6-address must be on the subnet that was configured from the IPv6 address command or a link-local address.

This command specifies the time that an IPv6 neighbor remains in a reachable state.

This command specifies the time that an IPv6 neighbor cache entry remains in a stale state on a router. When the specified time elapses, the system removes the neighbor cache entry.

This command enables the context to configure DHCP Relay Agent parameters.

This command configures the gateway interface address for the DHCP Relay Agent. By default, the GIADDR used in the relayed DHCP packet is the primary address of an interface.

This command enables DHCP Option 82 (Relay Agent Information Option) parameters processing and enters the context for configuring Option 82 suboptions.

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

This command configures the processing required when the 7705 SAR receives a DHCP request that already has a Relay Agent Information Option (Option 82) field in the packet.

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

When enabled, the router sends the interface index (If Index) in the circuit-id suboption of the DHCP packet. The If Index of a router interface can be displayed using the show>router> interface>detail command. This option specifies data that must be unique to the router that is relaying the circuit.

If disabled, the circuit-id suboption of the DHCP packet will be left empty.

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

This command copies the DHCP Option 82 into Option 43 (vendor-specific) on the DHCP offer destined for the DHCP client. This command is used in conjunction with the Auto-Discovery Protocol to allow the Auto-Discovery client node to learn about its network uplink.

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

When enabled, the router sends the MAC address of the remote end (typically, the DHCP client) in the remote-id suboption of the DHCP packet. This command identifies the host at the other end of the circuit. If disabled, the remote-id suboption of the DHCP packet will be left empty.

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

This command specifies a list of servers where requests will be forwarded. The list of servers can be entered as either IP addresses or fully qualified domain names. There must be at least one server specified for DHCP Relay to work. If there are multiple servers specified, then the request is forwarded to all of the servers in the list. There can be a maximum of eight DHCP servers configured.

This command enables access to the context to configure egress network filter policies for the IP interface.

If an egress filter policy is not defined, no filtering is performed.

This command enables access to the context to configure ingress network filter policies for the IP interface.

If an ingress filter policy is not defined, no filtering is performed.

This command sets the aggregate rate limits (PIR and CIR) for the VLAN bound to the network interface once a queue-policy has been assigned. The agg-rate sets the PIR value. The cir-rate sets the CIR value. On Gen-3 hardware, the cir-rate for this command can be configured and is applied but has no effect on the network port. For a network interface on a hybrid port, this command takes effect. For information on adapter card generations, refer to the “Evolution of Ethernet Adapter Cards, Modules, and Platforms” section in the 7705 SAR Interface Configuration Guide.

The queue-policy command is used to enable and disable network egress per-VLAN shapers on a per-network-interface basis. If a queue policy has not been assigned, or if the no queue-policy command is issued, then the VLAN interface defaults to the unshaped mode and the aggregate rate limits are set to their default values. The agg-rate-limit command is only valid when the VLAN shaper is enabled.

Configuring the cir-rate is optional. If a cir-rate is not entered, then the cir-rate is set to its default value (0 kb/s). If a cir-rate has been set and the agg-rate is changed without re-entering the cir-rate, then the cir-rate automatically resets to 0 kb/s. For example, to change the agg-rate from 2000 to 1500 while maintaining a cir-rate of 500, use the command agg-rate-limit 1500 cir 500.

The no form of the command sets the agg-rate to the maximum and the cir-rate to 0 kb/s.

This command associates an IP filter policy with an IPv4 or IPv6 interface. IPv4 filters are supported on all ingress and egress network interfaces. IPv6 filters are supported on all Ethernet ingress and egress network interfaces (with null or dot1q encapsulation) and on ingress and egress interfaces on the 4-port OC3/STM1 Clear Channel Adapter card (with POS encapsulation).

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

The ip-filter-id or 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 assigned to an interface unless the interface is dual-stack (supports both IPv4 and IPv6). A dual-stack interface can have one IPv4 and one IPv6 filter ID assigned to it.

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

This command specifies the network queue policy that defines queue parameters such as CBS, MBS, CIR, and PIR rates, as well as forwarding class-to-queue mappings for the shaped VLAN queues. The network queue policy is defined in the config>qos>network-queue context. Refer to the 7705 SAR Quality of Service Guide, “Network Queue QoS Policies”, for more information.

The queue-policy command is used to enable and disable network egress per-VLAN shapers on a per-network-interface basis. If the VLAN shaper is enabled, then a set of network egress queues is created specifically for the interface, and traffic for that interface is handled by a per-VLAN shaper in the egress direction. If a queue policy has not been assigned, or if the no queue-policy command is issued, then the VLAN interface defaults to the unshaped mode and the agg-rate-limit is set to its default values. If the VLAN shaper is disabled for the interface, then the queues created for the interface are deleted, and traffic goes to the unshaped VLAN aggregate queues that are shared by all other interfaces (or VLANs).

The no form of this command reverts to the default.

This command enables network group encryption (NGE) on the router interface. When NGE is enabled on the interface, all received Layer 3 packets that have the protocol ID configured as ESP are considered to be NGE packets and must be encrypted using a valid set of keys from any preconfigured key group on the system.

The no form of the command disables NGE on the interface. NGE cannot be disabled unless all key groups and IP exception filters are removed.

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

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

This command associates an IP exception filter policy with an NGE-enabled router interface to allow packets matching the exception criteria to transit the NGE domain as clear text.

When an exception filter is added for inbound traffic, packets matching the criteria in the IP exception filter policy are allowed to be received in clear text even if an inbound key group is configured. If no inbound key group is configured, then associated inbound IP exception filter policies will be ignored.

When an exception filter is added for outbound traffic, packets matching the criteria in the IP exception filter policy are not encrypted when sent out of the router interface even if an outbound key group is configured. If no outbound key group is configured, then associated outbound IP exception filter policies will be ignored.

The no form of the command removes the IP exception filter policy from the specified direction.

This command enables access to 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 or disables 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 the command disables replies to ICMP mask requests on the router interface.

This command enables the generation of ICMP Time To Live (TTL) expired messages and configures the rate that the messages are issued by the IP interface.

By default, generation of ICMP TTL expired messages is enabled at a maximum rate of 100 per 10-s time interval.

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

This command enables the generation of ICMP host and network destination unreachable messages 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 given time interval.

By default, generation of ICMP destination unreachables messages is enabled at a maximum rate of 100 per 10-s time interval.

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

This command enables the context to configure ICMPv6 parameters on an interface.

This command enables the generation of ICMPv6 packet-too-big messages and configures the rate that the messages are issued by the IP interface.

The no form of the command disables the sending of ICMPv6 packet-too-big messages.

This command enables the generation of ICMPv6 param-problem messages and configures the rate that the messages are issued by the IP interface.

The no form of the command disables the sending of ICMPv6 param-problem messages.

This command enables the generation of ICMPv6 time-exceeded messages and configures the rate that the messages are issued by the IP interface.

The no form of the command disables the sending of ICMPv6 time-exceeded messages.

This command enables the generation of ICMPv6 host and network destination unreachable messages 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 given time interval.

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

This command enables the context to configure router advertisement properties. By default, it is disabled for all IPv6-enabled interfaces.

The no form of the command disables router advertisement on all IPv6 interfaces.

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

The no form of the command disables router advertisement on the specified router interface.

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. Refer to RFC 3315, Dynamic Host Configuration Protocol (DHCP) for IPv6.

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

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