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 defines the autonomous system (AS) number for the router. The no form of the command removes the defined AS number from the router.

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 preference command (under the static-route-entry context) 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, when configured, inserts the entropy label (EL) and Entropy Label Indicators (ELI) into packets where at least one LSP in the stack for the far end of the LDP or the RSVP-TE or SR-TE tunnel used by an IGP or BGP shortcut has advertised entropy label capability. If the tunnel is of type RSVP-TE or SR-TE, then entropy-label must also be enabled under config>router>mpls or config>router>mpls>lsp.

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

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 creates a context for the configuration of global parameters related to MPLS labels.

This command configures the range of the Segment Routing Global Block (SRGB). The SRGB is a label block that is used for assigning labels to segment routing prefix SIDs originated by this router. This range is derived from the system dynamic label range and, by default, is not instantiated.

The SR label is a reserved label, and when configured it cannot be used by other protocols such as RSVP-TE, LDP, or BGP to assign a label dynamically.

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

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 command, 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.

When editing an existing static route—that is, configuring a static-route entry having an existing prefix, subnet mask, and next-hop IP address—the options that were applied before the edit persist unless explicitly changed.

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. Before deleting the static-route entry, the underlying next-hop, black-hole, or indirect entries need to be shutdown and deleted as well. Otherwise, attempting to delete the static-route entry results in the warning “Cannot delete static-route prefix without deleting configured next-hops”.

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 specifies that the route is a blackhole route. If the destination address on a packet matches this static route, it will be silently discarded.

This command specifies the cost metric for the static route, expressed as a decimal integer. This value is used when importing the static route into other protocols such as OSPF or IS-IS. When the metric is configured as 0, the metric configured in the other protocol applies.

This value is also used to determine which static route to install in the forwarding table.

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

This command specifies the preference of this static route over routes from different sources such as OSPF, IS-IS, and BGP. The preference is expressed as a decimal integer. A route with a lower preference value is preferred over a route with a higher preference value.

When modifying the preference value of an existing static route, the metric will not be changed unless specified. The preference command is also used to prioritize static routes applied to the same prefix. If a blackhole static route has the same preference as another route with the same prefix, the blackhole route takes a lower precedence.

If multiple routes are learned with an identical preference using the same protocol, the lowest-cost route is used. If multiple routes are learned with an identical preference using the same protocol and the costs (metrics) are equal, the decision of which route to use is determined by the ecmp command.

Different protocols should not be configured with the same preference. If this occurs, the tiebreaker is according to the route preference defaults listed in Table 19.

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

This command adds a 32-bit integer tag to the static route.

The tag value is used in route policies to control distribution of the route into other protocols.

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

The configured ip-address is not directly connected to a network configured on this node. The destination can be reachable via multiple paths. The indirect address can be resolved either via a dynamic routing protocol or by another static route.

The ip-address configured for the indirect parameter must be on the network side of this node and be at least one hop away from the node.

This command enables the context to configure the indirect static route to use a tunnel programmed in the tunnel table manager (TTM) for resolving the next hop of the route.

This command determines whether the static route can be resolved via an IGP next hop in the routing table manager (RTM) if no tunnel next hops are found in the TTM.

If enabled, the static route will not be resolved to an available IGP route in the RTM.

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

This command configures the mode for resolving the static route to a tunnel next hop.

This command configures the subset of tunnel types that can be used in the resolution of the static route next hop.

If one or more tunnel filter criteria are specified, the tunnel type will be selected following the TTM preference order.

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

The ldp value instructs the system to search for an LDP LSP with a FEC prefix corresponding to the address of the indirect next hop. Both an LDP IPv4 FEC and LDP IPv6 FEC can be used as the tunnel next hop. However, only an indirect next hop of the same family (IPv4 or IPv6) as the prefix of the route can use an LDP FEC as the tunnel next hop; for example, an IPv4 prefix can only be resolved to an IPv4 FEC.

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

The rsvp-te value instructs the system to search for the best metric RSVP-TE LSP to the address of the indirect next hop. The LSP metric is provided by MPLS in the tunnel table. If there are multiple RSVP-TE LSPs with the same lowest metric, the system selects the LSP with the lowest tunnel-id.

A point-to-point auto LSP that is instantiated via an LSP template can be selected in the TTM when resolution is set to any.

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

For RSVP-TE, it is recommended that auto LSP names not be specified because the auto-generated name can change if the node reboots, which will blackhole the traffic of the static route.

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

When the sr-isis value is enabled, an SR tunnel to the indirect next hop is selected in the TTM from the lowest-numbered IS-IS instance.

Both SR-ISIS IPv4 and SR-ISIS IPv6 tunnels can be used as tunnel next hops. However, only an indirect next hop of the same family (IPv4 or IPv6) as the prefix of the route can use an SR-ISIS tunnel as the tunnel next hop; for example, an IPv4 prefix can only be resolved using an SR-ISIS IPv4 tunnel.

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

When the sr-ospf value is enabled, an SR tunnel to the indirect next hop is selected in the TTM from OSPF instance 0.

Segment routing is not supported for OSPFv3. Therefore, SR-OSPF tunnels and tunnel next hops are IPv4 only.

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

The sr-te value instructs the system to search for the best metric SR-TE LSP to the address of the indirect next hop. The LSP metric is provided by MPLS in the tunnel table. If there are multiple SR-TE LSPs with the same lowest metric, the system selects the LSP with the lowest tunnel-id.

This command specifies the directly connected next-hop IP interface name or IP address used to reach the destination. If the next hop is over an unnumbered interface, the interface name of the unnumbered interface can be used.

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).

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

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

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

This command prevents the static route from being enabled immediately after the interface to the next hop comes back up after a failure. The static route will be enabled after the LDP adjacency comes up and the LDP synchronization timer expires (see ldp-sync-timer).

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 enables the context to configure global BFD session commands on the router.

This command creates or edits a BFD template for a router. A BFD template defines the set of parameters used by a BFD session. These parameters include the transmit and receive timers used for BFD continuity check (CC) packets, the transmit timer interval used when the session is providing a connection verification (CV) function, the multiplier value, and whether the BFD session terminates in the network processor.

The no form of the command removes the template.

This command specifies the integer used during a BFD session to determine when the far end is down. If a BFD control packet is not received for a period of multiplier x receive-interval, the session is declared down.

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

This command specifies the interval between received BFD packets that is required to maintain the BFD session.

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

This command specifies the interval between transmitted BFD packets that is required to maintain the BFD session.

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

This command sets the CSM network processor as the local termination point for the BFD session. This setting is enabled by default.

This command enables the context to configure global seamless BFD (S-BFD) initiator parameters on this router.

This command creates the context for the local mapping between a far-end S-BFD reflector and its discriminator value. The mapping is used by the router when it is acting as an S-BFD initiator.

For IPv6, only a global unicast address can be used as a peer address.

The no form of this command removes the peer address from the mapping table.

This command specifies the S-BFD reflector discriminator for the remote peer in the mapping table that is used for S-BFD sessions initiated by the router.

The no form of this command removes the discriminator.

This command enables the context to configure the parameters for a seamless BFD (S-BFD) reflector on the router.

This command configures the S-BFD reflector name.

The no form of this command removes the reflector.

This command configures a description for the S-BFD reflector.

The no form of this command removes the description.

This command configures the discriminator for the S-BFD reflector. The S-BFD discriminator must be unique for each router and separate from the BFD discriminators negotiated by standard BFD sessions. The discriminator value is configured from a defined range.

The no form of this command removes the discriminator.

This command sets the local state field in reflected S-BFD control packets.

The no form of this command means that the field is not explicitly set by the reflector.

This command specifies the administrative state of the seamless BFD reflector.

The no form of this command administratively enables the reflector. A discriminator must be configured before the no shutdown command is issued.

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 configure Cflowd parameters for the specified IP interface.

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

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

This command can be used to configure the sampling parameters for unicast and multicast traffic separately.

If Cflowd sampling is enabled with no direction parameter specified, ingress-only sampling is enabled by default.

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

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 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 the ldp-sync command under the static-route-entry context), 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 enables the context to configure load balancing hashing options on the interface. The options enabled at the interface level overwrite parallel system-level configurations.

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 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 SPI hashing for ESP/AH encrypted IPv4 or IPv6 traffic at the interface level.

The no form of this command disables SPI hashing.

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 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 assigns a specific MAC address to the network interface.

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

This command enables multicast address translation on the 7705 SAR that is the translator router for unicast-to-multicast or multicast-to-multicast translation.

When enabled for unicast-to-multicast translation, the 7705 SAR will try to find the source and destination address of the packet in the unicast-to-multicast translation table. If the source and destination address is not found, the packet is processed as a regular IP packet. To disable unicast-to-multicast translation, all entries must be removed from the translation table and then the command must be set to no multicast-translation.

When enabled for multicast-to-multicast translation, the static group configuration is used for multicast PDUs that arrive on the node and are to be translated via the translation table. If the command is enabled and an arriving PDU does not match an entry in the translation table, the multicast PDU is dropped. If the (S,G) arrives from another interface via a dynamic protocol while this command is enabled, the interface that the dynamic (S,G) arrived from will be added as an outgoing interface but it will not forward traffic. Only the outgoing loopback interface on the translation router will forward the translated PDU.

For multicast-to-multicast translation, if this command is not enabled, the node will function as a leaf for the static group configuration.

To disable multicast-to-multicast translation, the interface must be shut down before the no version of this command is issued.

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.