Cisco IOS Novell IPX Command Reference

ipx input-network-filter (RIP)

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, and 15.2(2)T, the ipx input-network-filter (RIP) command is not supported in Cisco IOS software.

To control which networks are added to the Cisco IOS software routing table, use the ipx input-network-filter command in interface configuration mode. To remove the filter from the interface, use the no form of this command.

ipx input-network-filter {access-list-number | name}

no ipx input-network-filter {access-list-number | name}

Syntax Description

Defaults

No filters are predefined.

Command Modes

Interface configuration

Command History

Usage Guidelines

The ipx input-network-filter command controls which networks are added to the routing table based on the networks learned in incoming IPX routing updates (RIP updates) on the interface.

You can issue only one ipx input-network-filter command on each interface.

Examples

In the following example, access list 876 controls which networks are added to the routing table when IPX routing updates are received on Ethernet interface 1. Routing updates for network 1b will be accepted. Routing updates for all other networks are implicitly denied and are not added to the routing table.

access-list 876 permit 1b

interface ethernet 1

 ipx input-network-filter 876

The following example is a variation of the preceding that explicitly denies network 1a and explicitly allows updates for all other networks:

access-list 876 deny 1a 
access-list 876 permit -1

Related Commands

ipx input-sap-filter

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, and 15.2(2)T, the ipx input-sap-filter command is not supported in Cisco IOS software.

To control which services are added to the Cisco IOS software SAP table, use the ipx input-sap-filter command in interface configuration mode. To remove the filter, use the no form of this command.

ipx input-sap-filter {access-list-number | name}

no ipx input-sap-filter {access-list-number | name}

Syntax Description

Defaults

No filters are predefined.

Command Modes

Interface configuration

Command History

Usage Guidelines

The ipx input-sap-filter command filters all incoming service advertisements received by the router. This is done prior to accepting information about a service.

You can issue only one ipx input-sap-filter command on each interface.

When configuring SAP filters for NetWare 3.11 and later servers, use the server's internal network and node number (the node number is always 0000.0000.0001) as its address in the access-list (SAP filtering) command. Do not use the network.node address of the particular interface board.

Examples

The following example denies service advertisements about the server at address 3c.0800.89a1.1527, but accepts information about all other services on all other networks:

access-list 1000 deny 3c.0800.89a1.1527

access-list 1000 permit -1

!

interface ethernet 0

 ipx input-sap-filter 1000

Related Commands

ipx internal-network

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, 15.2(2)T, and 15.1(1)SY, the ipx internal-network command is not supported in Cisco IOS software.

To set an internal network number for use by NetWare Link Services Protocol (NLSP) and IPXWAN, use the ipx internal-network command in global configuration mode. To remove an internal network number, use the no form of this command.

ipx internal-network network-number

no ipx internal-network [network-number]

Syntax Description

Defaults

No internal network number is set.

Command Modes

Global configuration

Command History

Usage Guidelines

An internal network number is a network number assigned to the router. This network number must be unique within the internetwork.

You must configure an internal network number on each device on an NLSP-capable network for NLSP to operate.

When you set an internal network number, the Cisco IOS software advertises the specified network out all interfaces. It accepts packets destined to that network at the address internal-network.0000.0000.0001.

Examples

The following example assigns internal network number e001 to the local router:

ipx routing

ipx internal-network e001

Related Commands

ipx ipxwan

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, 15.2(2)T, and 15.1(1)SY, the ipx ipxwan command is not supported in Cisco IOS software.

To enable the IPX wide-area network (IPXWAN) protocol on a serial interface, use the ipx ipxwan command in interface configuration mode. To disable the IPXWAN protocol, use the no form of this command.

ipx ipxwan [local-node {network-number | unnumbered} local-server-name retry-interval retry-limit]

no ipx ipxwan

Syntax Description

Defaults

IPXWAN is disabled.

If you enable IPXWAN, the default is unnumbered.

Command Modes

Interface configuration

Command History

Usage Guidelines

If you omit all optional arguments and keywords, the ipx ipxwan command defaults to ipx ipxwan 0 unnumbered router-name (which is equivalent to ipx ipxwan 0 local-server-name), where router-name is the name of the router as configured with the hostname global configuration command. For this configuration, the show ipx interface command displays ipx ipxwan 0 0 local-server-name.

If you enter a value of 0 for the network-number argument, the output of the show running-config EXEC command does not show the 0 but rather reports this value as "unnumbered."

The name of each device on each side of the link must be different.

IPXWAN is a start-up end-to-end options negotiations protocol. When a link comes up, the first IPX packets sent across are IPXWAN packets negotiating the options for the link. When the IPXWAN options have been successfully determined, normal IPX traffic starts. The three options negotiated are the link IPX network number, internal network number, and link delay (ticks) characteristics. The side of the link with the higher local-node number (internal network number) gives the IPX network number and delay to use for the link to the other side. Once IPXWAN finishes, no IPXWAN packets are sent unless link characteristics change or the connection fails. For example, if the IPX delay is changed from the default setting, an IPXWAN restart will be forced.

To enable the IPXWAN protocol on a serial interface, you must not have configured an IPX network number (using the ipx network interface configuration command) on that interface.

To control the delay on a link, use the ipx delay interface configuration command. If you issue this command when the serial link is already up, the state of the link will be reset and renegotiated.

Examples

The following example enables IPXWAN on serial interface 0:

interface serial 0

 encapsulation ppp

 ipx ipxwan 

The following example enables IPXWAN on serial interface 1 on device CHICAGO-AS. When the link comes up, CHICAGO-AS will be the master because it has a larger internal network number. It will give the IPX number 100 to NYC-AS to use as the network number for the link. The link delay, in ticks, will be determined by the exchange of packets between the two access servers.

On the local access server (CHICAGO-AS):

interface serial 1

 no ipx network

 encapsulation ppp

 ipx ipxwan 6666 100 CHICAGO-AS

On the remote router (NYC-AS):

interface serial 0

 no ipx network

 encapsulation ppp

 ipx ipxwan 1000 101 NYC-AS

Related Commands

ipx ipxwan error

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, and 15.2(2)T, the ipx ipxwan error command is not supported in Cisco IOS software.

To define how to handle IPX wide-area network (IPXWAN) when IPX fails to negotiate properly at link startup, use the ipx ipxwan error command in interface configuration mode. To restore the default, use the no form of this command.

ipx ipxwan error [reset | resume | shutdown]

no ipx ipxwan error [reset | resume | shutdown]

Syntax Description

Defaults

The link is reset.

Command Modes

Interface configuration

Command History

Usage Guidelines

Use the ipx ipxwan error command to define what action to take if the IPXWAN startup negotiation fails.

Examples

In the following example, the serial link will be shut down if the IPXWAN startup negotiation fails after three attempts spaced 20 seconds apart:

interface serial 0

 encapsulation ppp

 ipx ipxwan 

 ipx ipxwan error shutdown

Related Commands

ipx ipxwan static

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, and 15.2(2)T, the ipx ipxwan static command is not supported in Cisco IOS software.

To negotiate static routes on a link configured for IPX wide-area network (IPXWAN), use the ipx ipxwan static command in interface configuration mode. To disable static route negotiation, use the no form of this command.

ipx ipxwan static

no ipx ipxwan static

Syntax Description

This command has no arguments or keywords.

Defaults

Static routing is disabled.

Command Modes

Interface configuration

Command History

Usage Guidelines

When you specify the ipx ipxwan static command, the interface negotiates static routing on the link. If the router at the other side of the link is not configured to negotiate for static routing, the link will not initialize.

Examples

The following example enables static routing with IPXWAN:

interface serial 0

 encapsulation ppp

 ipx ipxwan 

 ipx ipxwan static

Related Commands

ipx link-delay

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, and 15.2(2)T, the ipx link-delay command is not supported in Cisco IOS software.

To specify the link delay, use the ipx link-delay command in interface configuration mode. To return to the default link delay, use the no form of this command.

ipx link-delay microseconds

no ipx link-delay microseconds

Syntax Description

Defaults

No link delay (delay of 0).

Command Modes

Interface configuration

Command History

Usage Guidelines

The link delay you specify replaces the default value or overrides the value measured by IPXWAN when it starts.

Examples

The following example sets the link delay to 20 microseconds:

ipx link-delay 20

Related Commands

ipx linkup-request (RIP)

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, and 15.2(2)T, the ipx linkup-request (RIP) command is not supported in Cisco IOS software.

To enable the sending of a general RIP and/or SAP query when an interface comes up, use the ipx linkup-request command in interface configuration mode. To disable the sending of a general RIP and/or SAP query when an interface comes up, use the no form of this command.

ipx linkup-request {rip | sap}

no ipx linkup-request {rip | sap}

Syntax Description

Defaults

General RIP and SAP queries are sent.

Command Modes

Interface configuration

Command History

Usage Guidelines

Under normal operation, when using serial or other point-to-point links, the router sends RIP and SAP information twice when an interface comes up. The RIP and SAP information is sent as soon as the link is up and is sent again when the router receives a general RIP query from the other end of the connection. By disabling the ipx linkup-request command, the router sends the RIP and SAP information once, instead of twice.

Examples

The following example configures the router to disable the general query for both RIP and SAP on serial interface 0:

interface serial 0

 no ipx linkup-request rip

 no ipx linkup-request sap

Related Commands

ipx maximum-hops (RIP)

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, and 15.2(2)T, the ipx maximum-hops (RIP) command is not supported in Cisco IOS software.

To set the maximum hop count allowed for IPX packets, use the ipx maximum-hops command in global configuration mode. To return to the default number of hops, use the no form of this command.

ipx maximum-hops hops

no ipx maximum-hops hops

Syntax Description

Defaults

16 hops

Command Modes

Global configuration

Command History

Usage Guidelines

Packets whose hop count is equal to or greater than that specified by the ipx maximum-hops command are dropped.

In periodic RIP updates, the Cisco IOS software never advertises any network with a hop count greater than 15. However, using protocols other than RIP, the software might learn routes that are farther away than 15 hops. The ipx maximum-hops command defines the maximum number of hops that the software will accept as reachable, as well as the maximum number of hops that an IPX packet can traverse before it is dropped by the software. Also, the software will respond to a specific RIP request for a network that is reachable at a distance of greater than 15 hops.

Examples

The following command configures the software to accept routes that are up to 64 hops away:

ipx maximum-hops 64

ipx maximum-paths

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, and 15.2(2)T, the ipx maximum-paths command is not supported in Cisco IOS software.

To set the maximum number of equal-cost paths that the Cisco IOS software uses when forwarding packets, use the ipx maximum-paths command in global configuration mode. To restore the default value, use the no form of this command.

ipx maximum-paths paths

no ipx maximum-paths

Syntax Description

Defaults

1 path

Command Modes

Global configuration

Command History

Usage Guidelines

The ipx maximum-paths command increases throughput by allowing the software to choose among several equal-cost, parallel paths. (Note that when paths have differing costs, the software chooses lower-cost routes in preference to higher-cost routes.)

When per-host load sharing is disabled, IPX performs load sharing on a packet-by-packet basis in round-robin fashion, regardless of whether you are using fast switching or process switching. That is, the first packet is sent along the first path, the second packet along the second path, and so on. When the final path is reached, the next packet is sent to the first path, the next to the second path, and so on.

Limiting the number of equal-cost paths can save memory on routers with limited memory or with very large configurations. Additionally, in networks with a large number of multiple paths and systems with limited ability to cache out-of-sequence packets, performance might suffer when traffic is split between many paths.

When you enable per-host load sharing, IPX performs load sharing by transmitting traffic across multiple, equal-cost paths while guaranteeing that packets for a given end host always take the same path. Per-host load sharing decreases the possibility that successive packets to a given end host will arrive out of order.

With per-host load balancing, the number of equal-cost paths set by the ipx maximum-paths command must be greater than one; otherwise, per-host load sharing has no effect.

Examples

In the following example, the software uses up to three parallel paths:

ipx maximum-paths 3

Related Commands

ipx nasi-server enable

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, 15.2(2)T, and 15.1(1)SY, the ipx nasi-server enable command is not supported in Cisco IOS software.

To enable NetWare Asynchronous Services Interface (NASI) clients to connect to asynchronous devices attached to your router, use the ipx nasi-server enable command in global configuration mode. To prevent NASI clients from connecting to asynchronous devices through a router, use the no form of this command.

ipx nasi-server enable

no ipx nasi-server enable

Syntax Description

This command has no arguments or keywords.

Command Default

NASI is not enabled.

Command Modes

Global configuration

Command History

Usage Guidelines

When you enter this command, NASI clients can connect to any port on the router, other than the console port, to access network resources. When the user on the NASI client uses the Windows or DOS application to connect to the router, a list of available tty and vty lines appear, beginning with tty1. The user can select the desired outgoing tty or vty port.

To to enable a username and password prompt for authentication, authorization, and accounting purposes, you can configure TACACS+ security on the router, after the user on the NASI client selects a tty or vty port.

Examples

The following example shows a minimum configuration to enable NASI clients dial-in access with TACACS+ authentication:

ipx routing

ipx internal-network ncs001

interface ethernet 0

  ipx network 1 

ipx nasi-server enable

! enable TACACS+ authentication for NASI clients using the list name swami

aaa authentication nasi swami tacacs+

line 1 8

  modem inout

Related Commands

ipx netbios input-access-filter

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, and 15.2(2)T, the ipx netbios input-access-filter command is not supported in Cisco IOS software.

To control incoming IPX NetBIOS FindName messages, use the ipx netbios input-access-filter command in interface configuration mode. To remove the filter, use the no form of this command.

ipx netbios input-access-filter {host | bytes} name

no ipx netbios input-access-filter {host | bytes} name

Syntax Description

Defaults

No filters are predefined.

Command Modes

Interface configuration

Command History

Usage Guidelines

You can issue only one ipx netbios input-access-filter host and one ipx netbios input-access-filter bytes command on each interface.

These filters apply only to IPX NetBIOS FindName packets. They have no effect on LLC2 NetBIOS packets.

Examples

The following example filters packets arriving on Token Ring interface 1 using the NetBIOS access list named engineering:

netbios access-list host engineering permit eng*

netbios access-list host engineering deny manu*

interface tokenring 1

 ipx netbios input-access-filter engineering

Related Commands

ipx netbios output-access-filter

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, and 15.2(2)T, the ipx netbios output-access-filter command is not supported in Cisco IOS software.

To control outgoing NetBIOS FindName messages, use the ipx netbios output-access-filter command in interface configuration mode. To remove the filter, use the no form of this command.

ipx netbios output-access-filter {host | bytes} name

no ipx netbios output-access-filter {host | bytes} name

Syntax Description

Defaults

No filters are predefined.

Command Modes

Interface configuration

Command History

Usage Guidelines

You can issue only one ipx netbios output-access-filter host and one ipx netbios output-access-filter bytes command on each interface.

These filters apply only to IPX NetBIOS FindName packets. They have no effect on LLC2 NetBIOS packets.

Examples

The following example filters packets leaving Token Ring interface 1 using the NetBIOS access list named engineering:

netbios access-list bytes engineering permit 20 AA**04

interface token 1

 ipx netbios output-access-filter bytes engineering

Related Commands

ipx netbios-socket-input-checks

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, 15.2(2)T, and 15.1(1)SY, the ipx netbios-socket-input-checks command is not supported in Cisco IOS software.

To enable additional checks that are performed on Network Basic Input/Output System (NetBIOS) packets that do not conform fully to Novell Type20 NetBIOS packets, use the ipx netbios-socket-input-checks command in global configuration mode. To disable the additional checking, use the no form of this command.

ipx netbios-socket-input-checks

no ipx netbios-socket-input-checks

Syntax Description

This command has no arguments or keywords.

Defaults

Disabled

Command Modes

Global configuration

Command History

Usage Guidelines

When you use the ipx netbios-socket-input-checks command to enable additional checks on NetBIOS packets that do not fully conform to Novell Type20 NetBIOS packets, the same checks that are performed on Type20 packets to avoid broadcast loops are performed for any packet that does not have the netBIOS socket, even if it is not a Novell Type20 packet.

Note In order to forward non-Type20 broadcasts, you must configure a helper address on two or more interfaces. For more information, see the ipx helper-address command earlier in this chapter.

Examples

The following example enables the additional checks on NetBIOS packets:

ipx netbios-socket-input-checks

Related Commands

ipx network

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, 15.2(2)T, and 15.1(1)SY, the ipx network command is not supported in Cisco IOS software.

To enable IPX routing on a particular interface and to optionally select the type of encapsulation (framing), use the ipx network command in interface configuration mode. To disable IPX routing, use the no form of this command.

ipx network network [encapsulation encapsulation-type [secondary]]

no ipx network network [encapsulation encapsulation-type]

Syntax Description

Defaults

IPX routing is disabled.

Encapsulation types:
   For Ethernet: novell-ether
   For Token Ring: sap
   For FDDI: snap
   For serial: hdlc

If you use NetWare Version 4.0 and Ethernet, you must change the default encapsulation type from novell-ether to sap.

Command Modes

Interface configuration

Command History

Usage Guidelines

The ipx network command allows you to configure a single logical network on a physical network or more than one logical network on the same physical network (network cable segment). Each network on a given interface must have a different encapsulation type.

Note You cannot configure more than 200 IPX interfaces on a router using the ipx network command.

The first network you configure on an interface is considered to be the primary network. Any additional networks are considered to be secondary networks; these must include the secondary keyword.

Note In future Cisco IOS software releases, primary and secondary networks may not be supported.

You can configure an IPX network on any supported interface as long as all the networks on the same physical interface use a distinct encapsulation type. For example, you can configure up to four IPX networks on a single Ethernet cable because Ethernet supports four encapsulation types.

The interface processes only packets with the correct encapsulation and the correct network number. IPX networks that use encapsulations can be present on the physical network. The only effect on the router is that it uses some processing time to examine packets to determine whether they have the correct encapsulation.

All logical networks on an interface share the same set of configuration parameters. For example, if you change the IPX RIP update time on an interface, you change it for all networks on that interface.

When you define multiple logical networks on the same physical network, IPX treats each encapsulation as if it were a separate physical network. This means, for example, that IPX sends RIP updates and SAP updates for each logical network.

Caution The maximum size of the IPX packets that can be sent via the secondary networks depends on the encapsulation of the primary network and the maximum transfer unit (MTU) of the interface where these networks are configured. Otherwise, packet loss may occur. Subinterfaces, when used instead of secondary networks, do not impose primary network-based packet size restrictions. Some of the maximum IPX packet sizes supported for the supported encapsulation types are shown in the examples.

The ipx network command is useful when migrating from one type of encapsulation to another. If you are using it for this purpose, you should define the new encapsulation on the primary network.

Note If you have already enabled IPX routing on the specified interface, you can use the ipx encapsulation command to change the encapsulation type.

To delete all networks on an interface, use the following command:

no ipx network

Deleting the primary network with the following command also deletes all networks on that interface. The argument number is the number of the primary network.

no ipx network number

To delete a secondary network on an interface, use one of the following commands. The argument number is the number of a secondary network.

no ipx network number

no ipx network number encapsulation encapsulation-type

Novell's FDDI_RAW encapsulation is common in bridged or switched environments that connect Ethernet-based Novell end hosts via a FDDI backbone. Packets with FDDI_RAW encapsulation are classified as Novell packets and are not automatically bridged when you enable both bridging and IPX routing. Additionally, you cannot configure FDDI_RAW encapsulation on an interface configured for IPX autonomous or silicon switching engine (SSE) switching. Similarly, you cannot enable IPX autonomous or SSE switching on an interface configured with FDDI_RAW encapsulation.

With FDDI_RAW encapsulation, platforms that do not use CBUS architecture support fast switching. Platforms using CBUS architecture support only process switching of novell-fddi packets received on an FDDI interface.

Table 12 describes the types of encapsulation available for specific interfaces.

Examples

The following example uses subinterfaces to create four logical networks on Ethernet interface 0. Each subinterface has a different encapsulation. Any interface configuration parameters that you specify on an individual subinterface are applied to that subinterface only.

ipx routing

interface ethernet 0

 ipx network 1 encapsulation novell-ether

interface ethernet 0.1

 ipx network 2 encapsulation snap

interface ethernet 0.2

 ipx network 3 encapsulation arpa 

interface ethernet 0

 ipx network 4 encapsulation sap 

The following example uses primary and secondary networks to create the same four logical networks as shown previously in this section. Any interface configuration parameters that you specify on this interface are applied to all the logical networks. For example, if you set the routing update timer to 120 seconds, this value is used on all four networks.

ipx routing

ipx network 1 encapsulation novell-ether

ipx network 2 encapsulation snap secondary

ipx network 3 encapsulation arpa secondary

ipx network 4 encapsulation sap secondary

The following example provides information about maximum supported packet sizes described in the "Caution." If the primary network is configured with SAP encapsulation, IPX packets greater than 1497 are dropped because one of the following situations exists:

•The size of a datagram is rounded off from an odd number of bytes to an even number of bytes, which may increase the IPX packet length by 1; in this example, from 1497 bytes to 1498 bytes.

•A secondary network on the same interface is configured with Novell-Ethernet encapsulation, although this encapsulation supports an MTU of 1500 bytes.

The following data compares some maximum sizes of IPX datagrams:

Novell-Ethernet is 1518 - 12 -2 (length) -4 (CRC) = 1500

SAP is 1518 - 12 -2 (length) -3 (SAP header) -4 (CRC) = 1497

SNAP is 1518 - 12 -2 (length) -8 (SNAP header) -4 (CRC) = 1492

ARPA is 1518 -12 -2 (length) -2 (type) -4 (CRC) =1500

Twelve bytes represents the source address and destination address in the Ethernet frame.

The following example enables IPX routing on FDDI interfaces 0.2 and 0.3. On FDDI interface 0.2, the encapsulation type is SNAP. On FDDI interface 0.3, the encapsulation type is Novell's FDDI_RAW.

ipx routing

interface fddi 0.2 enc sde 2

 ipx network f02 encapsulation snap

interface fddi 0.3 enc sde 3

 ipx network f03 encapsulation novell-fddi

Related Commands

ipx nhrp authentication

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, and 15.2(2)T, the ipx nhrp authentication command is not supported in Cisco IOS software.

To configure the authentication string for an interface using Next Hop Resolution Protocol (NHRP), use the ipx nhrp authentication command in interface configuration mode. To remove the authentication string, use the no form of this command.

ipx nhrp authentication string

no ipx nhrp authentication [string]

Syntax Description

Defaults

No authentication string is configured; the Cisco IOS software adds no authentication option to NHRP packets it generates.

Command Modes

Interface configuration

Command History

Usage Guidelines

All routers configured with NHRP on a fabric (for an interface) must share the same authentication string.

Examples

In the following example, the authentication string specialxx must be configured in all devices using NHRP on the interface before NHRP communication occurs:

ipx nhrp authentication specialxx

ipx nhrp holdtime

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, and 15.2(2)T, the ipx nhrp holdtime command is not supported in Cisco IOS software.

To change the number of seconds for which Next Hop Resolution Protocol (NHRP) nonbroadcast multiaccess (NBMA) addresses are advertised as valid in authoritative NHRP responses, use the ipx nhrp holdtime command in interface configuration mode. To restore the default value, use the no form of this command.

ipx nhrp holdtime seconds-positive [seconds-negative]

no ipx nhrp holdtime [seconds-positive [seconds-negative]]

Syntax Description

Defaults

7200 seconds (2 hours) for both arguments.

Command Modes

Interface configuration

Command History

Usage Guidelines

The ipx nhrp holdtime command affects authoritative responses only. The advertised holding time is the length of time for which the Cisco IOS software tells other routers to keep information that it is provided in authoritative NHRP responses. The cached IPX-to-NBMA address mapping entries are discarded after the holding time expires.

The NHRP cache can contain static and dynamic entries. The static entries never expire. Dynamic entries expire regardless of whether they are authoritative or nonauthoritative.

If you want to change the valid time period for negative NHRP responses, you must also include a value for positive NHRP responses, as the arguments are position-dependent.

Examples

The following example advertises NHRP NBMA addresses as valid in positive authoritative NHRP responses for one hour:

ipx nhrp holdtime 3600

The following example advertises NHRP NBMA addresses as valid in negative authoritative NHRP responses for one hour and in positive authoritative NHRP responses for two hours:

ipx nhrp holdtime 7200 3600

ipx nhrp interest

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, and 15.2(2)T, the ipx nhrp interest command is not supported in Cisco IOS software.

To control which IPX packets can trigger sending a Next Hop Resolution Protocol (NHRP) request, use the ipx nhrp interest command in interface configuration mode. To restore the default value, use the no form of this command.

ipx nhrp interest access-list-number

no ipx nhrp interest [access-list-number]

Syntax Description

Defaults

All non-NHRP packets can trigger NHRP requests.

Command Modes

Interface configuration

Command History

Usage Guidelines

Use this command with the access-list command to control which IPX packets trigger NHRP requests.

Examples

In the following example, any NetBIOS traffic can cause NHRP requests to be sent, but no other IPX packets will cause NHRP requests:

ipx nhrp interest 901

access-list 901 permit 20

Related Commands

ipx nhrp map

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, and 15.2(2)T, the ipx nhrp map command is not supported in Cisco IOS software.

To statically configure the IPX-to-NBMA address mapping of IPX destinations connected to a nonbroadcast multiaccess (NBMA) network, use the ipx nhrp map command in interface configuration mode. To remove the static entry from NHRP cache, use the no form of this command.

ipx nhrp map ipx-address nbma-address

no ipx nhrp map ipx-address nbma-address

Syntax Description

Defaults

No static IPX-to-NBMA cache entries exist.

Command Modes

Interface configuration

Command History

Usage Guidelines

You will probably have to configure at least one static mapping in order to reach the Next Hop Server. Repeat this command to statically configure multiple IPX-to-NBMA address mappings.

Examples

The following example statically configures this station in an SMDS network to be served by two Next Hop Servers 1.0000.0c14.59ef and 1.0000.0c14.59d0. The NBMA address for 1.0000.0c14.59ef is statically configured to be c141.0001.0001 and the NBMA address for 1.0000.0c14.59d0 is c141.0001.0002.

interface serial 0

 ipx nhrp nhs 1.0000.0c14.59ef

 ipx nhrp nhs 1.0000.0c14.59d0

 ipx nhrp map 1.0000.0c14.59ef c141.0001.0001

 ipx nhrp map 1.0000.0c14.59d0 c141.0001.0002

Related Commands

ipx nhrp max-send

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, and 15.2(2)T, the ipx nhrp max-send command is not supported in Cisco IOS software.

To change the maximum frequency at which Next Hop Resolution Protocol (NHRP) packets can be sent, use the ipx nhrp max-send command in interface configuration mode. To restore this frequency to the default value, use the no form of this command.

ipx nhrp max-send pkt-count every interval

no ipx nhrp max-send

Syntax Description

Defaults

pkt-count = 5 packets
interval = 10 seconds

Command Modes

Interface configuration

Command History

Usage Guidelines

The software maintains a per interface quota of NHRP packets that can be transmitted. NHRP traffic, whether locally generated, or forwarded, cannot be sent at a rate that exceeds this quota. The quota is replenished at the rate specified by the interval argument.

Examples

In the following example, only one NHRP packet can be sent out serial interface 0 each minute:

interface serial 0 
 ipx nhrp max-send 1 every 60

Related Commands

ipx nhrp network-id

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, and 15.2(2)T, the ipx nhrp network-id command is not supported in Cisco IOS software.

To enable the Next Hop Resolution Protocol (NHRP) on an interface, use the ipx nhrp network-id command in interface configuration mode. To disable NHRP on the interface, use the no form of this command.

ipx nhrp network-id number

no ipx nhrp network-id

Syntax Description

Defaults

NHRP is disabled on the interface.

Command Modes

Interface configuration

Command History

Usage Guidelines

In general, all NHRP stations within a fabric must be configured with the same network identifier.

Examples

The following example enables NHRP on the interface:

ipx nhrp network-id 1

ipx nhrp nhs

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, and 15.2(2)T, the ipx nhrp nhs command is not supported in Cisco IOS software.

To specify the address of one or more Next Hop Resolution Protocol (NHRP) Next Hop Servers, use the ipx nhrp nhs command in interface configuration mode. To remove the address, use the no form of this command.

ipx nhrp nhs nhs-address [net-address]

no ipx nhrp nhs nhs-address [net-address]

Syntax Description

Defaults

No Next Hop Servers are explicitly configured, so normal network layer routing decisions forward NHRP traffic.

Command Modes

Interface configuration

Command History

Usage Guidelines

Use this command to specify the address of a Next Hop Server and the networks it serves. Normally, NHRP consults the network layer forwarding table to determine how to forward NHRP packets. When Next Hop Servers are configured, the next hop addresses specified with the ipx nhrp nhs command override the forwarding path specified by the network layer forwarding table that would usually be used for NHRP traffic.

For any Next Hop Server that is configured, you can specify multiple networks that it serves by repeating this command with the same nhs-address address, but different net-address IPX network numbers.

Examples

In the following example, the Next Hop Server with address 1.0000.0c00.1234 serves IPX network 2:

ipx nhrp nhs 1.0000.0c00.1234 2

ipx nhrp record

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, and 15.2(2)T, the ipx nhrp record command is not supported in Cisco IOS software.

To re-enable the use of forward record and reverse record options in Next Hop Resolution Protocol (NHRP) Request and Reply packets, use the ipx nhrp record command in interface configuration mode. To suppress the use of such options, use the no form of this command.

ipx nhrp record

no ipx nhrp record

Syntax Description

This command has no arguments or keywords.

Defaults

Forward record and reverse record options are enabled by default.

Command Modes

Interface configuration

Command History

Usage Guidelines

Forward record and reverse record options provide loop detection and are used in NHRP Request and Reply packets. Using the no form of this command disables this method of loop detection. For another method of loop detection, see the ipx nhrp responder command.

Examples

The following example suppresses forward record and reverse record options:

no ipx nhrp record

Related Commands

ipx nhrp responder

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, and 15.2(2)T, the ipx nhrp responder command is not supported in Cisco IOS software.

To designate which interface's primary IPX address that the Next Hop Server uses in Next Hop Resolution Protocol (NHRP) Reply packets when the NHRP requestor uses the Responder Address option, use the ipx nhrp responder command in interface configuration mode. To remove the designation, use the no form of this command.

ipx nhrp responder type number

no ipx nhrp responder [type] [number]

Syntax Description

Defaults

The Next Hop Server uses the IPX address of the interface where the NHRP Request was received.

Command Modes

Interface configuration

Command History

Usage Guidelines

If an NHRP requestor wants to know which Next Hop Server generates an NHRP Reply packet, it can request that information through the Responder Address option. The Next Hop Server that generates the NHRP Reply packet then complies by inserting its own IPX address in the Responder Address option of the NHRP Reply. The Next Hop Server uses the primary IPX address of the specified interface.

If an NHRP Reply packet being forwarded by a Next Hop Server contains that Next Hop Server's own IPX address, the Next Hop Server generates an Error Indication of type "NHRP Loop Detected" and discards the Reply.

Examples

In the following example, any NHRP requests for the Responder Address will cause this router acting as a Next Hop Server to supply the primary IPX address of interface serial 0 in the NHRP Reply packet:

ipx nhrp responder serial 0

ipx nhrp use

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, and 15.2(2)T, the ipx nhrp use command is not supported in Cisco IOS software.

To configure the software so that Next Hop Resolution Protocol (NHRP) is deferred until the system has attempted to send data traffic to a particular destination multiple times, use the ipx nhrp use command in interface configuration mode. To restore the default value, use the no form of this command.

ipx nhrp use usage-count

no ipx nhrp use usage-count

Syntax Description

Defaults

The default is usage-count = 1. The first time a data packet is sent to a destination for which the system determines NHRP can be used, an NHRP request is sent.

Command Modes

Interface configuration

Command History

Usage Guidelines

When the software attempts to transmit a data packet to a destination for which it has determined that NHRP address resolution can be used, an NHRP request for that destination is normally transmitted right away. Configuring the usage-count causes the system to wait until that many data packets have been sent to a particular destination before it attempts NHRP. The usage-count for a particular destination is measured over 1-minute intervals (the NHRP cache expiration interval).

The usage-count applies per destination. So if usage-count is configured to be 3, and 4 data packets are sent toward 10.0.0.1 and 1 packet toward 10.0.0.2, then an NHRP request is generated for 10.0.0.1 only.

If the system continues to need to forward data packets to a particular destination, but no NHRP response has been received, retransmission of NHRP requests are performed. This retransmission occurs only if data traffic continues to be sent to a destination.

The ipx nhrp interest command controls which packets cause NHRP address resolution to take place; the ipx nhrp use command controls how readily the system attempts such address resolution.

Examples

In the following example, if in the first minute four packets are sent to one IPX address and five packets are sent to a second IPX address, then a single NHRP request is generated for the second IPX address. If in the second minute the same traffic is generated and no NHRP responses have been received, then the system retransmits its request for the second IPX address.

ipx nhrp use 5

Related Commands

ipx nlsp csnp-interval

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, and 15.2(2)T, the ipx nlsp csnp-interval command is not supported in Cisco IOS software.

To configure the NetWare Link-Services Protocol (NLSP) complete sequence number PDU (CSNP) interval, use the ipx nlsp csnp-interval command in interface configuration mode. To restore the default value, use the no form of this command.

ipx nlsp [tag] csnp-interval seconds

no ipx nlsp [tag] csnp-interval seconds

Syntax Description

Defaults

30 seconds

Command Modes

Interface configuration

Command History

Usage Guidelines

The ipx nlsp csnp-interval command applies only to the designated router for the specified interface only. This is because only designated routers send CSNP packets, which are used to synchronize the database.

CSNP does not apply to serial point-to-point interfaces. However, it does apply to WAN connections if the WAN is viewed as a multiaccess meshed network.

Examples

The following example configures Ethernet interface 0 to transmit CSNPs every 10 seconds:

interface ethernet 0

 ipx network 101

 ipx nlsp enable

 ipx nlsp csnp-interval 10

Related Commands

ipx nlsp enable

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, and 15.2(2)T, the ipx nlsp enable command is not supported in Cisco IOS software.

To enable NetWare Link-Services Protocol (NLSP) routing on the primary network configured on this interface or subinterface, use the ipx nlsp enable command in interface configuration mode. To disable NLSP routing on the primary network configured on this interface or subinterface, use the no form of this command.

ipx nlsp [tag] enable

no ipx nlsp [tag] enable

Syntax Description

Defaults

NLSP is disabled on all interfaces.

Command Modes

Interface configuration

Command History

Usage Guidelines

When you enable NLSP routing, the current settings for RIP and SAP compatibility modes as specified with the ipx nlsp rip and ipx nlsp sap interface configuration commands take effect automatically.

When you specify an NLSP tag, the router enables NLSP on the specified process. An NLSP process is a router's databases working together to manage route information about an area. NLSP version 1.0 routers are always in the same area. Each router has its own adjacencies, link-state, and forwarding databases. These databases operate collectively as a single process to discover, select, and maintain route information about the area. NLSP version 1.1 routers that exist within a single area also use a single process.

NLSP version 1.1 routers that interconnect multiple areas use multiple processes to discover, select, and maintain route information about the areas they interconnect. These routers manage an adjacencies, link-state, and area address database for each area to which they attach. Collectively, these databases are still referred to as a process. The forwarding database is shared among processes within a router. The sharing of entries in the forwarding database is automatic when all processes interconnect NLSP version 1.1 areas.

Configure multiple NLSP processes when a router interconnects multiple NLSP areas.

Note NLSP version 1.1 routers refer to routers that support the route aggregation feature, while NLSP version 1.0 routers refer to routers that do not.

Examples

The following example enables NLSP routing on Ethernet interface 0:

interface ethernet 0

 ipx nlsp enable

The following example enables NLSP routing on serial interface 0:

interface serial 0

 ipx ipxwan 2442 unnumbered local1

 ipx nlsp enable

The following example enables NLSP routing for process area3 on Ethernet interface 0:

interface ethernet 0

 ipx nlsp area3 enable

Related Commands

ipx nlsp hello-interval

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, and 15.2(2)T, the ipx nlsp hello-interval command is not supported in Cisco IOS software.

To configure the interval between the transmission of hello packets, use the ipx nlsp hello-interval command in interface configuration mode. To restore the default value, use the no form of this command.

ipx nlsp [tag] hello-interval seconds

no ipx nlsp [tag] hello-interval seconds

Syntax Description

Defaults

10 seconds for the designated router.
20 seconds for nondesignated routers.

Command Modes

Interface configuration

Command History

Usage Guidelines

The designated router sends hello packets at an interval equal to one-half the configured value.

Use this command to improve the speed at which a failed router or link is detected. A router is declared to be down if a hello has not been received from it for the time determined by the holding time (the hello interval multiplied by the holding time multiplier; by default, 60 seconds for nondesignated routers and 30 seconds for designated routers). You can reduce this time by lowering the hello-interval setting, at the cost of increased traffic overhead.

You may also use this command to reduce link overhead on very slow links by raising the hello interval. This will reduce the traffic on the link at the cost of increasing the time required to detect a failed router or link.

Examples

The following example configures serial interface 0 to transmit hello packets every 30 seconds:

interface serial 0

 ipx ipxwan 2442 unnumbered local1

 ipx nlsp enable

 ipx nlsp hello-interval 30

Related Commands

ipx nlsp hello-multiplier

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, and 15.2(2)T, the ipx nlsp hello-multiplier command is not supported in Cisco IOS software.

To specify the hello multiplier used on an interface, use the ipx nlsp hello-multiplier command in interface configuration mode. To restore the default value, use the no form of this command.

ipx nlsp [tag] hello-multiplier multiplier

no ipx nlsp [tag] hello-multiplier

Syntax Description

Defaults

The default multiplier is 3.

Command Modes

Interface configuration

Command History

Usage Guidelines

You use the hello modifier in conjunction with the hello interval to determine the holding time value sent in a hello packet. The holding time is equal to the hello interval multiplied by the hello multiplier.

The holding time tells the neighboring router how long to wait for another hello packet from the sending router. If the neighboring router does not receive another hello packet in the specified time, then the neighboring router declares that the sending router is down.

You can use this method of determining the holding time when hello packets are lost with some frequency and NLSP adjacencies are failing unnecessarily. You raise the hello multiplier and lower the hello interval correspondingly to make the hello protocol more reliable without increasing the time required to detect a link failure.

Examples

In the following example, serial interface 0 will advertise hello packets every 15 seconds. The multiplier is 5. These values determine that the hello packet holding time is 75 seconds.

interface serial 0

 ipx nlsp hello-interval 15

 ipx nlsp hello-multiplier 5

Related Commands

ipx nlsp lsp-interval

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, and 15.2(2)T, the ipx nlsp lsp-interval command is not supported in Cisco IOS software.

To configure the time delay between successive NetWare Link-Services Protocol (NLSP) link-state packet (LSP) transmissions, use the ipx nlsp lsp-interval command in interface configuration mode. To restore the default time delay, use the no form of this command.

ipx nlsp [tag] lsp-interval interval

no ipx nlsp [tag] lsp-interval

Syntax Description

Defaults

55 milliseconds

Command Modes

Interface configuration

Command History

Usage Guidelines

This command allows you to control how fast LSPs can be flooded out an interface.

In topologies with a large number of NLSP neighbors and interfaces, a router may have difficulty with the CPU load imposed by LSP transmission and reception. This command allows you to reduce the LSP transmission rate (and by implication the reception rate of other systems).

Examples

The following example causes the system to transmit LSPs every 100 ms (10 packets per second) on Ethernet interface 0:

interface Ethernet 0

 ipx nlsp lsp-interval 100

Related Commands

ipx nlsp metric

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, and 15.2(2)T, the ipx nlsp metric command is not supported in Cisco IOS software.

To configure the NetWare Link-Services Protocol (NLSP) cost for an interface, use the ipx nlsp metric command in interface configuration mode. To restore the default cost, use the no form of this command.

ipx nlsp [tag] metric metric-number

no ipx nlsp [tag] metric metric-number

Syntax Description

Defaults

The default varies on the basis of the throughput of the link connected to the interface.

Command Modes

Interface configuration

Command History

Usage Guidelines

Use the ipx nlsp metric command to cause NLSP to prefer some links over others. A link with a lower metric is more preferable than one with a higher metric.

Typically, it is not necessary to configure the metric; however, it may be desirable in some cases when there are wide differences in link bandwidths. For example, using the default metrics, a single 64-kbps ISDN link will be preferable to two 1544-kbps T1 links.

Examples

The following example configures a metric of 10 on serial interface 0:

interface serial 0

 ipx network 107

 ipx nlsp enable

 ipx nlsp metric 10

Related Commands

ipx nlsp multicast

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, and 15.2(2)T, the ipx nlsp multicast command is not supported in Cisco IOS software.

To configure an interface to use multicast addressing, use the ipx nlsp multicast command in interface configuration mode. To configure the interface to use broadcast addressing, use the no form of this command.

ipx nlsp [tag] multicast

no ipx nlsp [tag] multicast

Syntax Description

Defaults

Multicast addressing is enabled.

Command Modes

Interface configuration

Command History

Usage Guidelines

This command allows the router interface to use NLSP multicast addressing. If an adjacent neighbor does not support NLSP multicast addressing, the router will revert to using broadcasts on the affected interface.

The router will also revert to using broadcasts if multicast addressing is not supported by the hardware or driver.

Examples

The following example disables multicast addressing on Ethernet interface 0:

interface ethernet 0

 no ipx nlsp multicast

ipx nlsp priority

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, and 15.2(2)T, the ipx nlsp priority command is not supported in Cisco IOS software.

To configure the election priority of the specified interface for designated router election, use the ipx nlsp priority command in interface configuration mode. To restore the default priority, use the no form of this command.

ipx nlsp [tag] priority priority-number

no ipx nlsp [tag] priority priority-number

Syntax Description

Defaults

44

Command Modes

Interface configuration

Command History

Usage Guidelines

Use the ipx nlsp priority command to control which router is elected designated router. The device with the highest priority number is selected as the designated router.

The designated router increases its own priority by 20 in order to keep its state as of the designated router more stable. To have a particular router be selected as the designated router, configure its priority to be at least 65.

Examples

The following example sets the designated router election priority to 65:

interface ethernet 0

 ipx network 101

 ipx nlsp enable

 ipx nlsp priority 65

ipx nlsp retransmit-interval

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, and 15.2(2)T, the ipx nlsp retransmit-interval command is not supported in Cisco IOS software.

To configure the link-state packet (LSP) retransmission interval on WAN links, use the ipx nlsp retransmit-interval command in interface configuration mode. To restore the default interval, use the no form of this command.

ipx nlsp [tag] retransmit-interval seconds

no ipx nlsp [tag] retransmit-interval seconds

Syntax Description

Defaults

5 seconds

Command Modes

Interface configuration

Command History

Usage Guidelines

This command sets the maximum amount of time that can pass before an LSP will be sent again (retransmitted) on a WAN link, if no acknowledgment is received.

Reducing the retransmission interval can improve the convergence rate of the network in the face of lost WAN links. The cost of reducing the retransmission interval is the potential increase in link utilization.

Examples

The following example configures the LSP retransmission interval to 2 seconds:

ipx nlsp retransmit-interval 2

Related Commands

ipx nlsp rip

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, and 15.2(2)T, the ipx nlsp rip command is not supported in Cisco IOS software.

To configure RIP compatibility when NetWare Link-Services Protocol (NLSP) is enabled, use the ipx nlsp rip command in interface configuration mode. To restore the default, use the no form of this command.

ipx nlsp [tag] rip [on | off | auto]

no ipx nlsp [tag] rip [on | off | auto]

Syntax Description

Defaults

RIP periodic traffic is sent only if another router in sending periodic RIP traffic.

Command Modes

Interface configuration

Command History

Usage Guidelines

The ipx nlsp rip command is meaningful only on networks on which NLSP is enabled. (RIP and SAP are always on by default on other interfaces.) Because the default mode is auto, no action is normally required to fully support RIP compatibility on an NLSP network.

Examples

In the following example, the interface never generates or sends RIP periodic traffic:

interface ethernet 0

 ipx nlsp rip off

Related Commands

ipx nlsp sap

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, and 15.2(2)T, the ipx nlsp sap command is not supported in Cisco IOS software.

To configure SAP compatibility when NetWare Link-Services Protocol (NLSP) in enabled, use the ipx nlsp sap command in interface configuration mode. To restore the default, use the no form of this command.

ipx nlsp [tag] sap [on | off | auto]

no ipx nlsp [tag] sap [on | off | auto]

Syntax Description

Defaults

SAP periodic traffic is sent only if another router in sending periodic SAP traffic.

Command Modes

Interface configuration

Command History

Usage Guidelines

The ipx nlsp sap command is meaningful only on networks on which NLSP is enabled. Because the default mode is auto, no action is normally required to fully support SAP compatibility on an NLSP network.

Examples

In the following example, the interface never generates or sends SAP periodic traffic:

interface ethernet 0

 ipx nlsp sap off

Related Commands

ipx output-ggs-filter

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, and 15.2(2)T, the ipx output-ggs-filter command is not supported in Cisco IOS software.

To control which servers are included in the Get General Service (GGS) responses sent by Cisco IOS software, use the ipx output-ggs-filter command in interface configuration mode. To remove the filter from the interface, use the no form of this command.

ipx output-ggs-filter {access-list-number | name}

no ipx output-ggs-filter {access-list-number | name}

Syntax Description

Defaults

No filters are predefined.

Command Modes

Interface configuration

Command History

Usage Guidelines

You can issue only one ipx output-ggs-filter command on each interface.

Note Because GGS SAP response filters are applied ahead of output SAP filters, a SAP entry permitted to pass through the GGS SAP response filter can still be filtered by the output SAP filter.

Examples

The following example excludes the server at address 3c.0800.89a1.1527 from GGS responses sent on Ethernet interface 0, but allows all other servers:

access-list 1000 deny 3c.0800.89a1.1527

access-list 1000 permit -1

ipx routing

interface ethernet 0

 ipx network 2B 

 ipx output-ggs-filter 1000

Related Commands

ipx output-gns-filter

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, and 15.2(2)T, the ipx output-gns-filter command is not supported in Cisco IOS software.

To control which servers are included in the Get Nearest Server (GNS) responses sent by Cisco IOS software, use the ipx output-gns-filter command in interface configuration mode. To remove the filter from the interface, use the no form of this command.

ipx output-gns-filter {access-list-number | name}

no ipx output-gns-filter {access-list-number | name}

Syntax Description

Defaults

No filters are predefined.

Command Modes

Interface configuration

Command History

Usage Guidelines

You can issue only one ipx output-gns-filter command on each interface.

Examples

The following example excludes the server at address 3c.0800.89a1.1527 from GNS responses sent on Ethernet interface 0, but allows all other servers:

access-list 1000 deny 3c.0800.89a1.1527

access-list 1000 permit -1

ipx routing

interface ethernet 0

 ipx network 2B

 ipx output-gns-filter 1000

Related Commands

ipx output-network-filter (RIP)

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, and 15.2(2)T, the ipx output-network-filter (RIP) command is not supported in Cisco IOS software.

To control the list of networks included in routing updates sent out an interface, use the ipx output-network-filter command in interface configuration mode. To remove the filter from the interface, use the no form of this command.

ipx output-network-filter {access-list-number | name}

no ipx output-network-filter {access-list-number | name}

Syntax Description

Defaults

No filters are predefined.

Command Modes

Interface configuration

Command History

Usage Guidelines

The ipx output-network-filter command controls which networks the Cisco IOS software advertises in its IPX routing updates (RIP updates).

You can issue only one ipx output-network-filter command on each interface.

Examples

In the following example, access list 896 controls which networks are specified in routing updates sent out the serial 1 interface. This configuration causes network 2b to be the only network advertised in Novell routing updates sent on the specified serial interface.

access-list 896 permit 2b

interface serial 1

 ipx output-network-filter 896

Related Commands

ipx output-rip-delay

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, and 15.2(2)T, the ipx output-rip-delay command is not supported in Cisco IOS software.

To set the interpacket delay for RIP updates sent on a single interface, use the ipx output-rip-delay command in interface configuration mode. To return to the default value, use the no form of this command.

ipx output-rip-delay delay

no ipx output-rip-delay [delay]

Syntax Description

Defaults

55 ms

Command Modes

Interface configuration

Command History

Usage Guidelines

The interpacket delay is the delay between the individual packets sent in a multiple-packet routing update. The ipx output-rip-delay command sets the interpacket delay for a single interface.

The system uses the interpacket delay specified by the ipx output-rip-delay command for periodic and triggered routing updates when no delay is set for triggered routing updates. When you set a delay for triggered routing updates, the system uses the delay specified by the ipx output-rip-delay command for only the periodic routing updates sent on the interface.

To set a delay for triggered routing updates, see the ipx triggered-rip-delay or ipx default-triggered-rip-delay commands.

You can also set a default RIP interpacket delay for all interfaces. See the ipx default-output-rip-delay command for more information.

Novell recommends a delay of 55 ms for compatibility with older and slower IPX machines. These machines may lose RIP updates because they process packets more slowly than the router sends them. The delay imposed by this command forces the router to pace its output to the slower-processing needs of these IPX machines.

The default delay on a NetWare 3.11 server is about 100 ms.

This command is also useful on limited bandwidth point-to-point links or X.25 and Frame Relay multipoint interfaces.

Examples

The following example establishes a 55-ms interpacket delay on serial interface 0:

interface serial 0

 ipx network 106A

 ipx output-rip-delay 55

Related Commands

ipx output-sap-delay

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, and 15.2(2)T, the ipx output-sap-delay command is not supported in Cisco IOS software.

To set the interpacket delay for Service Advertising Protocol (SAP) updates sent on a single interface, use the ipx output-sap-delay command in interface configuration mode. To return to the default delay value, use the no form of this command.

ipx output-sap-delay delay

no ipx output-sap-delay

Syntax Description

Defaults

55 ms

Command Modes

Interface configuration

Command History

Usage Guidelines

The interpacket delay is the delay between the individual packets sent in a multiple-packet SAP update. The ipx output-sap-delay command sets the interpacket delay for a single interface.

The system uses the interpacket delay specified by the ipx output-sap-delay command for periodic and triggered SAP updates when no delay is set for triggered updates. When you set a delay for triggered updates, the system uses the delay specified by the ipx output-sap-delay command only for the periodic updates sent on the interface.

To set a delay for triggered updates, see the ipx triggered-sap-delay or ipx default-triggered-sap-delay commands.

You can also set a default SAP interpacket delay for all interfaces. See the ipx default-output-sap-delay command for more information.

Novell recommends a delay of 55 ms for compatibility with older and slower IPX servers. These servers may lose SAP updates because they process packets more slowly than the router sends them. The delay imposed by the ipx output-sap-delay command forces the router to pace its output to the slower-processing needs of these servers.

The default delay on a NetWare 3.11 server is about 100 ms.

This command is also useful on limited bandwidth point-to-point links or X.25 and Frame Relay multipoint interfaces.

Examples

The following example establishes a 55-ms delay between packets in multiple-packet SAP updates on Ethernet interface 0:

interface ethernet 0

 ipx network 106A

 ipx output-sap-delay 55

Related Commands

ipx output-sap-filter

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, and 15.2(2)T, the ipx output-sap-filter command is not supported in Cisco IOS software.

To control which services are included in Service Advertising Protocol (SAP) updates sent by Cisco IOS software, use the ipx output-sap-filter command in interface configuration mode. To remove the filter, use the no form of this command.

ipx output-sap-filter {access-list-number | name}

no ipx output-sap-filter {access-list-number | name}

Syntax Description

Defaults

No filters are predefined.

Command Modes

Interface configuration

Command History