Cisco IOS Novell IPX Command Reference

ipx sap

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

To specify static Service Advertising Protocol (SAP) entries, use the ipx sap command in global configuration mode. To remove static SAP entries, use the no form of this command.

ipx sap service-type name network.node socket hop-count

no ipx sap service-type name network.node socket hop-count

Syntax Description

Defaults

Disabled

Command Modes

Global configuration

Command History

Usage Guidelines

The ipx sap command allows you to add static entries into the SAP table. Each entry has a SAP service associated with it. Static SAP assignments always override any identical entries in the SAP table that are learned dynamically, regardless of hop count. The router will not announce a static SAP entry unless it has a route to that network.

Examples

In the following example, the route to JOES_SERVER is not yet learned, so the system displays an informational message. The JOES_SERVER service will not be announced in the regular SAP updates until Cisco IOS software learns the route to it either by means of a RIP update from a neighbor or an ipx sap command.

ipx sap 107 MAILSERV 160.0000.0c01.2b72 8104 1

ipx sap 4 FILESERV 165.0000.0c01.3d1b 451 1

ipx sap 143 JOES_SERVER A1.0000.0c01.1234 8170 2

no route to A1, JOES_SERVER won't be announced until route is learned

Related Commands

ipx sap follow-route-path

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

To enable a router to accept IPX Service Advertising Protocol (SAP) entries from SAP updates received on an interface only if that interface is one of the best paths to reach the destination networks of those SAPs, use the ipx sap follow-route-path command in global configuration mode. To disable this router function, use no form of this command.

ipx sap follow-route-path

no ipx sap follow-route-path

Syntax Description

This command has no arguments or keywords.

Defaults

Disabled

Command Modes

Global configuration

Command History

Usage Guidelines

In redundantly connected networks that use IPX-Enhanced IGRP routing in which multiple IPX paths exist, IPX SAP services can be learned on nonoptimal interfaces, causing SAP loops, also known as phantom SAPs, when those services become obsolete. Use the ipx sap follow-route-path command to prevent the occurrence of SAP loops.

When the ipx sap follow-route-path command is used, the router screens individual services (SAPs) in SAP updates. The router looks at the destination network number of each SAP entry's . If the receiving interface is one of the best interfaces to reach the destination network of the SAP, that SAP entry is accepted. Otherwise, the SAP entry is discarded.

Caution When the ipx sap follow-route-path command is globally enabled in conjunction with SAP input filters on interfaces that are considered the best paths to reach the destination networks, the SAPs that are being filtered will no longer be learned by the router, even if other less optimal interfaces are capable of receiving those SAP updates.

Examples

The following example enables the router to accept only the IPX SAP entries from SAP updates received on an interface deemed to be one of the best paths to the destination address of those SAPs:

ipx sap follow-route-path

Related Commands

ipx sap-helper

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

To set an address, which should be another Cisco router that is adjacent to the router being configured, to which all Service Advertising Protocol (SAP) request packets are received, use the ipx sap-helper command in interface configuration mode. To remove the address and stop forwarding SAP request packets, use the no form of this command.

ipx sap-helper network.node

no ipx sap-helper network.node

Syntax Description

Defaults

No helper address is specified.

Command Modes

Interface configuration

Command History

Usage Guidelines

Use this command to redirect SAP packet requests that are sent to a remote router that has a limited memory size, CPU speed, and often a slow WAN link joining it to the main corporate backbone. The SAP helper target is usually much a much larger router that has a much larger routing table and a complete SAP table.

Examples

The following example assigns a router with the address 1000.0000.0c00.1234 as the SAP helper:

interface ethernet 0

 ipx sap-helper 1000.0000.0c00.1234

Related Commands

ipx sap-incremental (EIGRP)

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

To send Service Advertising Protocol (SAP) updates only when a change occurs in the SAP table, use the ipx sap-incremental command in interface configuration mode. To send periodic SAP updates, use the no form of this command.

ipx sap-incremental eigrp autonomous-system-number [rsup-only]

no ipx sap-incremental eigrp autonomous-system-number [rsup-only]

Syntax Description

Defaults

Enabled on serial interfaces

Disabled on LAN media (Ethernet, Token Ring, FDDI)

Command Modes

Interface configuration

Command History

Usage Guidelines

To use the ipx sap-incremental command, you must enable Enhanced IGRP. This is the case even if you want to use only RIP routing. You must do this because the incremental SAP feature requires the Enhanced IGRP reliable transport mechanisms.

With this functionality enabled, if an IPX Enhanced IGRP peer is found on the interface, SAP updates will be sent only when a change occurs in the SAP table. Periodic SAP updates are not sent. When no IPX Enhanced IGRP peer is present on the interface, periodic SAPs are always sent, regardless of how this command is set.

If you configure the local router to send incremental SAP updates on an Ethernet, and if the local device has at least one IPX Enhanced IGRP neighbor and any servers, clients, or routers that do not have IPX Enhanced IGRP configured on the Ethernet interface, these devices will not receive complete SAP information from the local router.

If the incremental sending of SAP updates on an interface is configured and no IPX Enhanced IGRP peer is found, SAP updates will be sent periodically until a peer is found. Then, updates will be sent only when changes occur in the SAP table.

To take advantage of Enhanced IGRP's incremental SAP update mechanism while using the RIP routing protocol instead of the Enhanced IGRP routing protocol, specify the rsup-only keyword. SAP updates are then sent only when changes occur, and only changes are sent. Use this feature only when you want to use RIP routing; Cisco IOS software disables the exchange of route information via Enhanced IGRP for that interface.

Examples

The following example sends SAP updates on Ethernet interface 0 only when there is a change in the SAP table:

interface ethernet 0

 ipx sap-incremental eigrp 200

ipx sap-incremental split-horizon

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

To configure incremental SAP split horizon, use the ipx sap-incremental split-horizon command in interface configuration mode. To disable split horizon, use the no form of this command.

ipx sap-incremental split-horizon

no ipx sap-incremental split-horizon

Syntax Description

This command has no argument or keywords.

Defaults

Enabled

Command Modes

Interface configuration

Command History

Usage Guidelines

Caution For IPX incremental SAP split horizon to work properly, IPX Enhanced IGRP should
be turned on. Otherwise, a warning message like the following will be displayed:

%IPX EIGRP not running.

When split horizon is enabled, Enhanced IGRP incremental SAP update packets are not sent back to the same interface from where the SAP is received. This reduces the number of Enhanced IGRP packets on the network.

Split horizon blocks information about SAPs from being advertised by a router to the same interface from where that SAP is received. Typically, this behavior optimizes communication among multiple routers, particularly when links are broken. However, with nonbroadcast networks, such as Frame Relay and SMDS, situations can arise for which this behavior is less than ideal. For these situations, you may wish to disable split horizon.

Note IPX incremental SAP split horizon is off for WAN interfaces and subinterfaces, and on for LAN interfaces. The global default stays off. The interface setting takes precedence if the interface setting is modified or when both the global and interface settings are unmodified. The global setting is used only when global setting is modified and the interface setting is unmodified.

Examples

The following example disables split horizon on serial interface 0:

interface serial 0

  no ipx sap-incremental split-horizon

Related Commands

ipx sap-max-packetsize

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

To configure the maximum packet size of Service Advertising Protocol (SAP) updates sent out the interface, use the ipx sap-max-packetsize command in interface configuration mode. To restore the default packet size, use the no form of this command.

ipx sap-max-packetsize bytes

no ipx sap-max-packetsize bytes

Syntax Description

Defaults

480 bytes

Command Modes

Interface configuration

Command History

Usage Guidelines

The maximum size is for the IPX packet, including the IPX network and SAP header information. For example, to allow 10 servers per SAP packet, you would configure (32 + (10 * 64)), or 672 bytes for the maximum packet size.

You are responsible for guaranteeing that the maximum packet size does not exceed the allowed maximum size of packets for the interface.

Examples

The following example sets the maximum SAP update packet size to 672 bytes:

ipx sap-max-packetsize 672

Related Commands

ipx sap-multiplier

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

To configure the interval at which a Service Advertising Protocol (SAP) entry for a network or server ages out, use the ipx sap-multiplier command in interface configuration mode. To restore the default interval, use the no form of this command.

ipx sap-multiplier multiplier

no ipx sap-multiplier multiplier

Syntax Description

Defaults

Three times the SAP update interval.

Command Modes

Interface configuration

Command History

Usage Guidelines

All routers on the same physical cable should use the same multiplier value.

Examples

In the following example, in a configuration where SAP updates are sent once every 1 minute, the interval at which SAP entries age out is set to 10 minutes:

interface ethernet 0

 ipx sap-multiplier 10

Related Commands

ipx sap-queue-maximum

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

To set an IPX Service Advertising Protocol (SAP) queue maximum to control how many SAP packets can be waiting to be processed at any given time, use the ipx sap-queue-maximum command in global configuration mode. To clear a set SAP queue maximum, use the no form of this command.

ipx sap-queue-maximum queue-maximum

no ipx sap-queue-maximum queue-maximum

Syntax Description

Defaults

No queue limit

Command Modes

Global configuration

Command History

Usage Guidelines

When you use the ipx sap-queue-maximum command to control how many SAP packets can be waiting to be processed at any given time, remember that if the queue limit is reached, the incoming SAP request packets are dropped. Be sure to set a large enough queue limit to handle normal incoming SAP requests on all interfaces, or else the SAP information may time out.

Examples

The following example sets a SAP queue maximum of 500 milliseconds:

ipx sap-queue-maximum 500

Related Commands

ipx sap-update-queue-maximum

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

To set an IPX Service Advertising Protocol (SAP) queue maximum to control how many incoming SAP update packets can be waiting to be processed at any given time, use the ipx sap-update-queue-maximum command in global configuration mode. To clear a set SAP queue maximum, use the no form of this command.

ipx sap-update-queue-maximum queue-maximum

no ipx sap-update-queue-maximum queue-maximum

Syntax Description

Defaults

No queue limit

Command Modes

Global configuration

Command History

Usage Guidelines

When you use the ipx sap-update-queue-maximum command to control how many incoming SAP update packets can be waiting to be processed at any given time, remember that if the queue limit is reached, the incoming SAP update packets are dropped.

Note When using the ipx sap-update-queue-maximum command, be sure to set this queue high enough to handle a full update on all interfaces, or else the SAP information may time out.

Examples

The following example sets a SAP update queue maximum of 500:

ipx sap-update-queue-maximum 500

Related Commands

ipx server-split-horizon-on-server-paths

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

To control whether Service Information split horizon checking should be based on Router Information Protocol (RIP) paths or Service Advertising Protocol (SAP) paths, use the ipx server-split-horizon-on-server-paths command in global configuration mode. To return to the normal mode of following route paths, use the no form of this command.

ipx server-split-horizon-on-server-paths

no ipx server-split-horizon-on-server-paths

Syntax Description

This command has no arguments or keywords.

Defaults

Disabled

Command Modes

Global configuration

Command History

Usage Guidelines

By default, split horizon prevents information about periodic SAPs from being advertised by a router to the same interface in which the best route to that SAP is learned. However, in an instance where the SAP may be learned from interfaces other than, or in addition to, the interface on which the best route to that SAP is learned, using the ipx server-split-horizon-on-server-paths command may reduce the number of unnecessary periodic SAP updates. The reduction in the number of SAP updates occurs because each SAP will not be advertised on the interface or interfaces it was learned from. The reduction in the number of SAP updates will also prevent a potential SAP loop in the network.

Examples

The following example shows the application of split horizon blocks:

ipx server-split-horizon-on-server-paths

Related Commands

ipx split-horizon eigrp

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

To configure split horizon, use the ipx split-horizon eigrp command in interface configuration mode. To disable split horizon, use the no form of this command.

ipx split-horizon eigrp autonomous-system-number

no ipx split-horizon eigrp autonomous-system-number

Syntax Description

Defaults

Enabled

Command Modes

Interface configuration

Command History

Usage Guidelines

When split horizon is enabled, Enhanced IGRP update and query packets are not sent for destinations that have next hops on this interface. This reduces the number of Enhanced IGRP packets on the network.

Split horizon blocks information about routes from being advertised by Cisco IOS software to any interface from which that information originated. Typically, this behavior optimizes communication among multiple routers, particularly when links are broken. However, with nonbroadcast networks, such as Frame Relay and Switched Multimegabit Data Service (SMDS), situations can arise for which this behavior is less than ideal. For these situations, you may wish to disable split horizon.

Examples

The following example disables split horizon on serial interface 0:

interface serial 0

 no ipx split-horizon eigrp 200 

ipx spx-idle-time

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

To set the amount of time to wait before starting the spoofing of Sequenced Packet Exchange (SPX) keepalive packets following inactive data transfer, use the ipx spx-idle-time command in interface configuration mode. To disable the current delay time set by this command, use the no form of this command.

ipx spx-idle-time delay-in-seconds

no ipx spx-idle-time

Syntax Description

Defaults

60 seconds

Command Modes

Interface configuration

Command History

Usage Guidelines

This command sets the elapsed time in seconds after which spoofing of keepalive packets occurs, following the end of data transfer; that is, after the acknowledgment and sequence numbers of the data being transferred have stopped increasing. By default, SPX keepalive packets are sent from servers to clients every 15 to 20 seconds.

If you turn on SPX spoofing and you do not set an idle time, the default of 60 seconds is assumed. This means that the dialer idle time begins when SPX spoofing begins. For example, if the dialer idle time is 3 minutes, the elapse time before SPX spoofing begins is 4 minutes: 3 minutes of dialer idle time plus 1 minute of SPX spoofing idle time.

For this command to take effect, you must first use the ipx spx-spoof interface configuration command to enable SPX spoofing for the interface.

Examples

The following example enables spoofing on serial interface 0 and sets the idle timer to 300 seconds:

interface serial 0

 ipx spx-spoof 

 no ipx route-cache

 ipx spx-idle-time 300

Related Commands

ipx spx-spoof

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

To configure Cisco IOS software to respond to a client or server's Sequenced Packet Exchange (SPX) keepalive packets on behalf of a remote system so that a dial-on-demand (DDR) link will go idle when data has stopped being transferred, use the ipx spx-spoof command in interface configuration mode. To disable spoofing, use the no form of this command.

ipx spx-spoof [session-clear session-clear-minutes | table-clear table-clear-hours]

no ipx spx-spoof [session-clear | table-clear]

Syntax Description

Defaults

Disabled

Command Modes

Interface configuration

Command History

Usage Guidelines

You can use the ipx spx-spoof command on any serial dialer or point-to-point interface. Fast switching and autonomous switching must be disabled on the interface; otherwise, SPX spoofing will not be permitted.

SPX keepalive packets are sent from servers to clients every 15 to 20 seconds after a client session has been idle for a certain period of time following the end of data transfer and after which only unsolicited acknowledgments are sent. The idle time may vary, depending on parameters set by the client and server.

Because of acknowledgment packets, a session would never go idle on a DDR link. On pay-per-packet or byte networks, these keepalive packets can incur for the customer large phone connection charges for idle time. You can prevent these calls from being made by configuring the software to respond to the server's keepalive packets on a remote client's behalf. This is sometimes referred to as "spoofing the server."

You can use the ipx spx-idle-time command to set the elapsed time in seconds after which spoofing of keepalive packets occurs, following the end of data transfer. If you turn on SPX spoofing and you do not set an idle time, the default of 60 seconds is assumed. This means that the dialer idle time begins when SPX spoofing begins. For example, if the dialer idle time is 3 minutes, the elapse time before the line goes "idle-spoofing" is 4 minutes: 3 minutes of dialer idle time plus 1 minute of SPX spoofing idle time.

Examples

The following example enables spoofing on serial interface 0:

interface serial 0

 ipx spx-spoof 

 no ipx route-cache

Related Commands

ipx throughput

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

To configure the throughput, use the ipx throughput command in interface configuration mode. To revert to the current bandwidth setting for the interface, use the no form of this command.

ipx throughput bits-per-second

no ipx throughput bits-per-second

Syntax Description

Defaults

Current bandwidth setting for the interface

Command Modes

Interface configuration

Command History

Usage Guidelines

The value you specify with the ipx throughput command overrides the value measured by IPXWAN when it starts.

Examples

The following example changes the throughput to 1,000,000 bits per second:

ipx throughput 1000000

Related Commands

ipx triggered-rip-delay

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

To set the interpacket delay for triggered Routing Information Protocol (RIP) updates sent on a single interface, use the ipx triggered-rip-delay command in interface configuration mode. To return to the default delay, use the no form of this command.

ipx triggered-rip-delay delay

no ipx triggered-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. A triggered routing update is one that the system sends in response to a "trigger" event, such as a request packet, interface up/down, route up/down, or server up/down.

The ipx triggered-rip-delay command sets the interpacket delay for triggered routing updates sent on a single interface. The delay value set by this command overrides the delay value set by the ipx output-rip-delay or ipx default-output-rip-delay command for triggered routing updates sent on the interface.

If the delay value set by the ipx output-rip-delay or ipx default-output-rip-delay command is high, then we strongly recommend a low delay value for triggered routing updates so that updates triggered by special events are sent in a more timely manner than periodic routing updates.

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.

When you do not set the interpacket delay for triggered routing updates, the system uses the delay specified by the ipx output-rip-delay or ipx default-output-rip-delay command for both periodic and triggered routing updates.

When you use the no form of the ipx triggered-rip-delay command, the system uses the global default delay set by the ipx default-triggered-rip-delay command for triggered RIP updates, if it is set. If it is not set, the system uses the delay set by the ipx output-rip-delay or ipx default-output-rip-delay command for triggered RIP updates, if set. Otherwise, the system uses the initial default delay as described in the "Defaults" section.

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

Examples

The following example sets an interpacket delay of 55 ms for triggered routing updates sent on interface FDDI 0:

interface FDDI 0

 ipx triggered-rip-delay 55

Related Commands

ipx triggered-rip-holddown

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

To set the amount of time for which an IPX Routing Information Protocol (RIP) process will wait before sending flashes about RIP changes, use the ipx triggered-rip-holddown command in interface configuration mode. To remove the RIP hold-down, use the no form of this command.

ipx triggered-rip-holddown milliseconds

no ipx triggered-rip-holddown milliseconds

Syntax Description

Defaults

55 milliseconds

Command Modes

Interface configuration

Command History

Usage Guidelines

To set a default hold-down used for all interfaces, use the ipx default-triggered-rip-holddown command in global configuration mode.

Examples

The following example shows a hold-down time of 100 milliseconds:

interface ether 0

 ipx triggered-rip-holddown 100

Related Commands

ipx triggered-sap-delay

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

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

ipx triggered-sap-delay delay

no ipx triggered-sap-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 SAP update. A triggered SAP update is one that the system sends in response to a "trigger" event, such as a request packet, interface up/down, route up/down, or server up/down.

The ipx triggered-sap-delay command sets the interpacket delay for triggered updates sent on a single interface. The delay value set by this command overrides the delay value set by the ipx output-sap-delay or ipx default-output-sap-delay command for triggered updates sent on the interface.

If the delay value set by the ipx output-sap-delay or ipx default-output-sap-delay command is high, then we strongly recommend a low delay value for triggered updates so that updates triggered by special events are sent in a more timely manner than periodic updates.

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 this command forces the router to pace its output to the slower-processing needs of these IPX servers.

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

When you do not set the interpacket delay for triggered updates, the system uses the delay specified by the ipx output-sap-delay or ipx default-output-sap-delay command for both periodic and triggered SAP updates.

When you use the no form of the ipx triggered-sap-delay command, the system uses the global default delay set by the ipx default-triggered-sap-delay command for triggered SAP updates, if it is set. If it is not set, the system uses the delay set by the ipx output-sap-delay or ipx default-output-sap-delay command for triggered SAP updates, if set. Otherwise, the system uses the initial default delay as described in the "Defaults" section.

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

Examples

The following example sets an interpacket delay of 55 ms for triggered SAP updates sent on interface FDDI 0:

interface FDDI 0

 ipx triggered-sap-delay 55

Related Commands

ipx triggered-sap-holddown

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

To set the amount of time for which a Service Advertising Protocol (SAP) process will wait before sending flashes about SAP changes, use the ipx triggered-sap-holddown command in interface configuration mode. To remove the SAP hold-down, use the no form of this command.

ipx triggered-sap-holddown milliseconds

no ipx triggered-sap-holddown milliseconds

Syntax Description

Defaults

55 milliseconds

Command Modes

Interface configuration

Command History

Usage Guidelines

To set a default hold-down used for all interfaces, use the ipx default-triggered-sap-holddown command in global configuration mode.

Examples

The following example shows a hold-down time of 100 milliseconds:

interface ethernet 0

 ipx triggered-sap-holddown 100

Related Commands

ipx type-20-helpered

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

To forward IPX type 20 propagation packet broadcasts to specific network segments, use the ipx type-20-helpered command in global configuration mode. To disable this function, use the no form of this command.

ipx type-20-helpered

no ipx type-20-helpered

Syntax Description

This command has no arguments or keywords.

Defaults

Disabled

Command Modes

Global configuration

Command History

Usage Guidelines

The ipx type-20-helpered command disables the input and output of type 20 propagation packets as done by the ipx type-20-propagation interface configuration command.

The ipx type-20-propagation command broadcasts type 20 packets to all nodes on the network and imposes a hop-count limit of eight routers for broadcasting these packets. These functions are in compliance with the Novell IPX router specification. In contrast, the ipx type-20-helpered command broadcasts type 20 packets to only those nodes indicated by the ipx helper-address interface configuration command and extends the hop-count limit to 16 routers.

Use of the ipx type-20-helpered command does not comply with the Novell IPX router specification; however, you may need to use this command if you have a mixed internetwork that contains routers running Software Release 9.1 and routers running later versions of Cisco IOS software.

Examples

The following example forwards IPX type 20 propagation packet broadcasts to specific network segments:

interface ethernet 0

 ipx network aa

 ipx type-20-helpered

 ipx helper-address bb.ffff.ffff.ffff

Related Commands

ipx type-20-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 type-20-input-checks command is not supported in Cisco IOS software.

To restrict the acceptance of IPX type 20 propagation packet broadcasts, use the ipx type-20-input-checks command in global configuration mode. To remove these restrictions, use the no form of this command.

ipx type-20-input-checks

no ipx type-20-input-checks

Syntax Description

This command has no arguments or keywords.

Defaults

Disabled

Command Modes

Global configuration

Command History

Usage Guidelines

By default, Cisco IOS software is configured to block type 20 propagation packets. When type 20 packet handling is enabled on multiple interfaces, you can use the ipx type-20-input-checks command to impose additional restrictions on the acceptance of type 20 packets. Specifically, the software will accept type 20 propagation packets only on the single network that is the primary route back to the source network. Similar packets received via other networks will be dropped. This behavior can be advantageous in redundant topologies, because it reduces unnecessary duplication of type 20 packets.

Examples

The following example imposes additional restrictions on incoming type 20 broadcasts:

ipx type-20-input-checks

Related Commands

ipx type-20-output-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 type-20-output-checks command is not supported in Cisco IOS software.

To restrict the forwarding of IPX type 20 propagation packet broadcasts, use the ipx type-20-output-checks command in global configuration mode. To remove these restrictions, use the no form of this command.

ipx type-20-output-checks

no ipx type-20-output-checks

Syntax Description

This command has no arguments or keywords.

Defaults

Disabled

Command Modes

Global configuration

Command History

Usage Guidelines

By default, Cisco IOS software is configured to block type 20 propagation packets. When type 20 packet handling is enabled on multiple interfaces, you can use the ipx type-20-output-checks command to impose additional restrictions on outgoing type 20 packets. Specifically, the software will forward these packets only to networks that are not routes back to the source network. (The software uses the current routing table to determine routes.) This behavior can be advantageous in redundant topologies, because it reduces unnecessary duplication of type 20 packets.

Examples

The following example imposes restrictions on outgoing type 20 broadcasts:

ipx type-20-output-checks

Related Commands

ipx type-20-propagation

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

To forward IPX type 20 propagation packet broadcasts to other network segments, use the ipx type-20-propagation command in interface configuration mode. To disable both the reception and forwarding of type 20 broadcasts on an interface, use the no form of this command.

ipx type-20-propagation

no ipx type-20-propagation

Syntax Description

This command has no arguments or keywords.

Defaults

Disabled

Command Modes

Interface configuration

Command History

Usage Guidelines

Routers normally block all broadcast requests. To allow input and output of type 20 propagation packets on an interface, use the ipx type-20-propagation command. Note that type 20 packets are subject to loop detection and control as specified in the IPX router specification.

Additional input and output checks may be imposed by the ipx type-20-input-checks and
ipx type-20-output-checks commands.

IPX type 20 propagation packet broadcasts are subject to any filtering defined by the ipx helper-list command.

Examples

The following example enables both the reception and forwarding of type 20 broadcasts on Ethernet interface 0:

interface ethernet 0

 ipx type-20-propagation

The following example enables the reception and forwarding of type 20 broadcasts between networks 123 and 456, but does not enable reception and forwarding of these broadcasts to and from network 789:

interface ethernet 0

 ipx network 123

 ipx type-20-propagation

!

interface ethernet 1

 ipx network 456

 ipx type-20-propagation

!

interface ethernet 2

 ipx network 789

Related Commands

ipx update interval

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

To adjust the Routing Information Protocol (RIP) or Service Advertising Protocol (SAP) update interval, use the ipx update interval command in interface configuration mode. To restore the default values, use the no form of this command.

ipx update interval {rip | sap} {value | changes-only}

no ipx update interval {rip | sap}

Syntax Description

Defaults

The default interval is 60 seconds for both IPX routing updates and SAP updates.

Command Modes

Interface configuration

Command History

Usage Guidelines

This command replaces two commands found in previous releases of Cisco IOS software: ipx sap-interval and ipx update-time.

Routers exchange information about routes by sending broadcast messages when they are started up and shut down, and periodically while they are running. The ipx update interval command enables you to modify the periodic update interval. By default, this interval is 60 seconds (this default is defined by Novell).

You should set RIP timers only in a configuration in which all routers are Cisco routers or in which all other IPX routers allow configurable timers. The timers should be the same for all devices connected to the same cable segment.

The update value you choose affects the internal IPX timers as follows:

•IPX routes are marked invalid if no routing updates are heard within three times the value of the update interval and are advertised with a metric of infinity.

•IPX routes are removed from the routing table if no routing updates are heard within four times the value of the update interval.

Setting the interval at which SAP updates are sent is most useful on limited-bandwidth links, such as slower-speed serial interfaces.

You should ensure that all IPX servers and routers on a given network have the same SAP interval. Otherwise, they may decide that a server is down when it is really up.

It is not possible to change the interval at which SAP updates are sent on most PC-based servers. This means that you should never change the interval for an Ethernet or Token Ring network that has servers on it.

You can set the router to send an update only when changes have occurred. Using the changes-only keyword specifies the sending of a SAP update only when the link comes up, when the link is downed administratively, or when the databases change. The changes-only keyword causes the router to do the following:

•Send a single, full broadcast update when the link comes up.

•Send appropriate triggered updates when the link is shut down.

•Send appropriate triggered updates when specific service information changes.

Examples

The following example configures the update timers for RIP updates on two interfaces in a router:

interface serial 0

 ipx update interval rip 40

interface ethernet 0

 ipx update interval rip 20

The following example configures SAP updates to be sent (and expected) on serial interface 0 every 300 seconds (5 minutes) to reduce periodic update overhead on a slow-speed link:

interface serial 0

 ipx update interval sap 300

Related Commands

ipx update sap-after-rip

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

To configure the router to send a Service Advertising Protocol (SAP) update immediately following a Routing Information Protocol (RIP) broadcast, use the ipx update sap-after-rip command in interface configuration mode. To restore the default value, use the no form of this command.

ipx update sap-after-rip

no ipx update sap-after-rip

Syntax Description

This command has no arguments or keywords.

Defaults

RIP and SAP updates are sent every 60 seconds.

Command Modes

Interface configuration

Command History

Usage Guidelines

The ipx update sap-after-rip command causes the router to issue a SAP update immediately following a RIP broadcast. This ensures that the SAP update follows the RIP broadcast, and that the SAP update is sent using the RIP update interval. It also ensures that the receiving router has learned the route to the service interface via RIP prior to getting the SAP broadcast.

Examples

The following example configures the router to issue a SAP broadcast immediately following a RIP broadcast on serial interface 0.

interface serial 0

 ipx update sap-after-rip

Related Commands

ipx watchdog

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

To enable watchdog, use the ipx watchdog command in interface configuration mode. To specify filtering, spoofing, or how long spoofing is to be enabled or disabled, use arguments and keywords. To disable filtering or spoofing, use the no form of this command.

ipx watchdog {filter | spoof [enable-time-hours disable-time-minutes]}

no ipx watchdog {filter | spoof}

Syntax Description

Defaults

There is no watchdog processing.

Command Modes

Interface configuration

Command History

Usage Guidelines

Use the ipx watchdog command when you want to enable watchdog processing. Use this command only on a serial interface with dial-on-demand (DDR) routing enabled.

Using the filter keyword when the DDR link is not connected will cause IPX server watchdog packets to be discarded, preventing them from bringing the DDR link up again.

Using the spoof keyword will allow IPX server watchdog packets to be answered when the DDR link is not connected. You can control how long spoofing is to be enabled or disabled by using the enable-time-hours and disable-time-minutes arguments.

Related Commands

ipx watchdog-spoof

The ipx watchdog-spoof command is replaced by the ipx watchdog command. See the description of the ipx watchdog command in this chapter for more information.

log-adjacency-changes (IPX)

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, and 15.2(2)T, the log-adjaceny-changes (IPX) command is not supported in Cisco IOS software.

To generate a log message when an NetWare Link-Services Protocol (NLSP) adjacency changes state (up or down), use the log-adjacency-changes command in IPX-router configuration mode. To disable this function, use the no form of this command.

log-adjacency-changes

no log-adjacency-changes

Syntax Description

This command has no arguments or keywords.

Defaults

Adjacency changes are not logged.

Command Modes

IPX-router configuration

Command History

Usage Guidelines

This command allows the monitoring of NLSP adjacency state changes. Adjacency state monitoring can be very useful when monitoring large networks. Messages are logged using the system error message facility. Messages are of the form:

%CLNS-5-ADJCHANGE: NLSP: Adjacency to 0000.0000.0034 (Serial0) Up, new adjacency

%CLNS-5-ADJCHANGE: NLSP: Adjacency to 0000.0000.0034 (Serial0) Down, hold time expired

Messages regarding the use of NLSP multicast and broadcast addressing are also logged. For example, if broadcast addressing is in use on Ethernet interface 1.2, and the last neighbor requiring broadcasts goes down, the following messages will be logged:

%CLNS-5-ADJCHANGE: NLSP: Adjacency to 0000.0C34.D838 (Ethernet1.2) Down, hold time expired

%CLNS-5-MULTICAST: NLSP: Multicast address in use on Ethernet1.2

If multicast addressing is in use and a new neighbor that supports only broadcast addressing comes up, the following messages will be logged:

%CLNS-5-ADJCHANGE: NLSP: Adjacency to 0000.0C34.D838 (Ethernet1.2) Up, new adjacency

%CLNS-5-MULTICAST: NLSP Broadcast address is in use on Ethernet1.2

Examples

The following example instructs the router to log adjacency changes for the NLSP process area1:

ipx router nlsp area1

 log-adjacency-changes

Related Commands

log-neighbor-changes (EIGRP)

Note Effective with Cisco IOS Release 15.1(3)S, XE 3.4, and 15.2(2)T, the log-neighbor-changes (EIGRP) command is not supported in Cisco IOS software.

To enable the logging of changes in Enhanced Interior Gateway Routing Protocol (EIGRP) neighbor adjacencies, use the log-neighbor-changes command in IPX-router configuration mode. To disable this function, use the no form of this command.

log-neighbor-changes

no log-neighbor-changes

Syntax Description

This command has no arguments or keywords.

Defaults

No adjacency changes are logged.

Command Modes

IPX-router configuration

Command History

Usage Guidelines

Enable the logging of neighbor adjacency changes in order to monitor the stability of the routing system and to help detect problems. Log messages are of the following form:

%DUAL-5-NBRCHANGE: IPX EIGRP as-number: Neighbor address (interface) is state: reason

where the arguments have the following meanings:

Examples

The following configuration will log neighbor changes for EIGRP process 209:

ipx router eigrp 209

 log-neighbor-changes

log-neighbor-warnings

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

Note Effective with Cisco IOS Release 15.0(1)M, 12.2(33)SRE and Cisco IOS XE Release 2.5, the log-neighbor-warnings command was replaced by the eigrp log-neighbor-warnings command for IPv4 and IPv6 configurations. The log-neighbor-warnings command is still available for IPX configurations.

To enable the logging of Enhanced Interior Gateway Routing Protocol (EIGRP) neighbor warning messages, use the log-neighbor-warnings command in router configuration mode. To disable the logging of EIGRP neighbor warning messages, use the no form of this command.

log-neighbor-warnings [seconds]

no log-neighbor-warnings

Syntax Description

Command Default

Neighbor warning messages are logged.

Command Modes

Router configuration (config-router)

Command History

Usage Guidelines

When neighbor warning messages occur, they are logged by default. With the log-neighbor-warnings command, you can disable and enable the logging of neighbor warning messages and configure the interval between repeated neighbor warning messages.

Examples

The following example shows that neighbor warning messages will be logged for EIGRP process 1 and warning messages will be repeated in 5-minute (300 seconds) intervals:

Router(config)# ipv6 router eigrp 1

Router(config-router)# log-neighbor-warnings 300

Related Commands

lsp-gen-interval (IPX)

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

To set the minimum interval at which link-state packets (LSPs) are generated, use the lsp-gen-interval command in router configuration mode. To restore the default interval, use the no form of this command.

lsp-gen-interval seconds

no lsp-gen-interval seconds

Syntax Description

Defaults

5 seconds

Command Modes

Router configuration

Command History

Usage Guidelines

The lsp-gen-interval command controls the rate at which LSPs are generated on a per-LSP basis. For instance, if a link is changing state at a high rate, the default value of the LSP generation interval limits the signaling of this change to once every 5 seconds. Because the generation of an LSP may cause all routers in the area to perform the SPF calculation, controlling this interval may have area-wide impact. Raising this interval can reduce the load on the network imposed by a rapidly changing link.

Examples

The following example sets the minimum interval at which LSPs are generated to 10 seconds:

lsp-gen-interval 10

Related Commands

lsp-mtu (IPX)

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

To set the maximum size of a link-state packet (LSP) generated by Cisco IOS software, use the lsp-mtu command in router configuration mode. To restore the default Maximum Transmission Unit (MTU) size, use the no form of this command.

lsp-mtu bytes

no lsp-mtu bytes

Syntax Description

Defaults

512 bytes

Command Modes

Router configuration

Command History

Usage Guidelines

You can increase the LSP MTU if there is a very large amount of information generated by a single router, because each device is limited to approximately 250 LSPs. In practice, this should never be necessary.

The LSP MTU must never be larger than the smallest MTU of any link in the area. This is because LSPs are flooded throughout the area.

The lsp-mtu command limits the size of LSPs generated by this router only; Cisco IOS software can receive LSPs of any size up to the maximum.

Examples

The following example sets the maximum LSP size to 1500 bytes:

lsp-mtu 1500

Related Commands

lsp-refresh-interval (IPX)

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

To set the link-state packet (LSP) refresh interval, use the lsp-refresh-interval command in router configuration mode. To restore the default refresh interval, use the no form of this command.

lsp-refresh-interval seconds

no lsp-refresh-interval seconds

Syntax Description

Defaults

7200 seconds (2 hours)

Command Modes

Router configuration

Command History

Usage Guidelines

The refresh interval determines the rate at which Cisco IOS software periodically transmits the route topology information that it originates. This is done in order to keep the information from becoming too old. By default, the refresh interval is 2 hours.

LSPs must be periodically refreshed before their lifetimes expire. The refresh interval must be less than the LSP lifetime specified with the max-lsp-lifetime (IPX) router configuration command. Reducing the refresh interval reduces the amount of time that undetected link state database corruption can persist at the cost of increased link utilization. (This is an extremely unlikely event, however, because there are other safeguards against corruption.) Increasing the interval reduces the link utilization caused by the flooding of refreshed packets (although this utilization is very small).

Examples

The following example changes the LSP refresh interval to 10,800 seconds (3 hours):

lsp-refresh-interval 10800 

Related Commands

max-lsp-lifetime (IPX)

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

To set the maximum time for which link-state packets (LSPs) persist without being refreshed, use the max-lsp-lifetime command in router configuration mode. To restore the default time, use the no form of this command.

max-lsp-lifetime [hours] value

no max-lsp-lifetime

Syntax Description

Defaults

7500 seconds (2 hours, 5 minutes)

Command Modes

Router configuration

Command History

Usage Guidelines

The hours keyword enables the router to interpret the maximum lifetime field in hours, allowing the router to keep LSPs for a much longer time. Keeping LSPs longer reduces overhead on slower-speed serial links and keeps ISDN links from becoming active unnecessarily.

You might need to adjust the maximum LSP lifetime if you change the LSP refresh interval with the lsp-refresh-interval (IPX) router configuration command. The maximum LSP lifetime must be greater than the LSP refresh interval.

Examples

The following example sets the maximum time that the LSP persists to 11,000 seconds (more than 3 hours):

max-lsp-lifetime 11000

The following example sets the maximum time that the LSP persists to 15 hours:

max-lsp-lifetime hours 15

Related Commands

multicast

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

To configure the router to use multicast addressing, use the multicast command in router configuration mode. To configure the router to use broadcast addressing, use the no form of this command.

multicast

no multicast

Syntax Description

This command has no arguments or keywords.

Defaults

Multicast addressing is enabled.

Command Modes

Router configuration

Command History

Usage Guidelines

This command allows the router to use NetWare Link-Services Protocol (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 on any interface where multicast addressing is not supported by the hardware or driver.

Examples

The following example disables multicast addressing on the router:

ipx router nlsp

 no multicast

nasi authentication

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

To enable authentication, authorization, and accounting (AAA) authentication for NetWare Asynchronous Services Interface (NASI) clients connecting to a router, use the nasi authentication command in line configuration mode. To return to the default, as specified by the aaa authentication nasi command, use the no form of the command.

nasi authentication {default | list-name}

no nasi authentication {default | list-name}

Syntax Description

Defaults

Uses the default set with the aaa authentication nasi command.

Command Modes

Line configuration

Command History

Usage Guidelines

This command is a per-line command used with AAA authentication that specifies the name of a list of authentication methods to try at login. If no list is specified, the default list is used, even if it is not specified in the command line. (You create defaults and lists with the aaa authentication nasi command.) Entering the no form of this command has the same effect as entering the command with the default argument.

Caution If you use a list-name value that was not configured with the aaa authentication nasi command, you will disable login on this line.

Before issuing this command, create a list of authentication processes by using the aaa authentication nasi global configuration command.

Examples

The following example specifies that the default AAA authentication be used on line 4:

line 4

 nasi authentication default

The following example specifies that the AAA authentication list called list1 be used on line 7:

line 7

 nasi authentication list1

Related Commands

netbios access-list (IPX)

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

To define an IPX NetBIOS FindName access list filter, use the netbios access-list command in global configuration mode. To remove a filter, use the no form of this command.

netbios access-list host name {deny | permit} string

no netbios access-list host name {deny | permit} string

netbios access-list bytes name {deny | permit} offset byte-pattern

no netbios access-list bytes name {deny | permit} offset byte-pattern

Syntax Description

Defaults

No filters are predefined.

Command Modes

Global configuration

Command History

Usage Guidelines

Keep the following points in mind when configuring IPX NetBIOS access control:

•Host (node) names are case-sensitive.

•Host and byte access lists can have the same names. They are independent of each other.

•When filtering by node name for IPX NetBIOS, the names in the access lists are compared with the destination name field for IPX NetBIOS "find name" requests.

•When filtering by byte offset, note that these access filters can have a significant impact on the packets' transmission rate across the bridge because each packet must be examined. You should use these access lists only when absolutely necessary.

•If a node name is not found in an access list, the default action is to deny access.

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

To delete an IPX NetBIOS access list, specify the minimum number of keywords and arguments needed to delete the proper list. For example, to delete the entire list, use the following command:

no netbios access-list {host | bytes} name

To delete a single entry from the list, use the following command:

no netbios access-list host name {permit | deny} string

Examples

The following example defines the IPX NetBIOS access list engineering:

netbios access-list host engineering permit eng-ws1 eng-ws2 eng-ws3

The following example removes a single entry from the engineering access list:

netbios access-list host engineering deny eng-ws3

The following example removes the entire engineering NetBIOS access list:

no netbios access-list host engineering 

Related Commands

network (IPX Enhanced IGRP)

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

To enable Enhanced Interior Gateway Routing Protocol (EIGRP), use the network (IPX Enhanced IGRP) command in router configuration mode. To disable Enhanced IGRP, use the no form of this command.

network {network-number | all}

no network {network-number | all}

Syntax Description

Defaults

Disabled

Command Modes

Router configuration

Command History

Usage Guidelines

Use the network (IPX Enhanced IGRP) command to enable the routing protocol specified in the ipx router command on each network.

Examples

The following commands disable RIP on network 10 and enable Enhanced IGRP on networks 10 and 20:

ipx router rip

 no network 10

ipx router eigrp 12

 network 10

 network 20

Related Commands

permit (IPX extended)

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

To set conditions for a named IPX extended access list, use the permit command in access-list configuration mode. To remove a permit condition from an access list, use the no form of this command.

permit protocol [source-network][[[.source-node] source-node-mask] | [.source-node source-network-mask.source-node-mask]] [source-socket] [destination-network][[[.destination-node] destination-node-mask] | [.destination-node destination-network-mask.destination-node-mask]] [destination-socket] [log] [time-range time-range-name]

no permit protocol [source-network][[[.source-node] source-node-mask] | [.source-node source-network-mask.source-node-mask]] [source-socket] [destination-network][[[.destination-node] destination-node-mask] | [.destination-node destination-network-mask.destination-nodemask]] [destination-socket] [log] [time-range time-range-name]

Syntax Description

Defaults

There is no specific condition under which a packet passes the named access list.

Command Modes

Access-list configuration

Command History

Usage Guidelines

Use this command following the ipx access-list command to specify conditions under which a packet passes the named access list.

For additional information on IPX protocol names and numbers, and IPX socket names and numbers, see the access-list (IPX extended) command.

Examples

The following example creates an extended access list named sal that denies all SPX packets and permits all others:

ipx access-list extended sal

 deny spx any all any all log

 permit any

The following example provides a time range to permit access:

time-range no-spx

 periodic weekdays 8:00 to 18:00

!

ipx access-list extended test

 permit spx any all any all time-range no spx

Related Commands

permit (IPX standard)

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

To set conditions for a named IPX access list, use the permit command in access-list configuration mode. To remove a permit condition from an access list, use the no form of this command.

permit source-network[.source-node [source-node-mask]] [destination-network[.destination-node[destination-node-mask]]]

no permit source-network[.source-node [source-node-mask]] [destination-network[.destination-node[destination-node-mask]]]

Syntax Description

Defaults

No access lists are defined.

Command Modes

Access-list configuration

Command History

Usage Guidelines

Use this command following the ipx access-list command to specify conditions under which a packet passes the named access list.

For additional information on creating IPX access lists, see the access-list (IPX standard) command.

Examples

The following example creates a standard access list named fred. It permits communication with only IPX network number 5678.

ipx access-list standard fred

 permit 5678 any

 deny any

Related Commands

permit (NLSP)

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

To allow explicit route redistribution in a named NetWare Link-Services Protocol (NLSP) route aggregation access list, use the permit command in access-list configuration mode. To remove a permit condition, use the no form of this command.

permit network network-mask [ticks ticks] [area-count area-count]

no permit network network-mask [ticks ticks] [area-count area-count]

Syntax Description

Defaults

No access lists are defined.

Command Modes

Access-list configuration

Command History

Usage Guidelines

Use this command following the ipx access-list command to specify conditions under which networks that are permitted by the access list entry can be redistributed as explicit networks, without summarization.

For additional information on creating access lists that deny or permit area addresses that summarize routes, see the access-list (NLSP route aggregation summarization) command.

Examples

The following example allows networks 12345600 and 12345601 to be redistributed explicitly. Other routes in the range 12345600 to 123456FF are summarized into a single aggregated route. All other routes will be redistributed as explicit routes.

ipx access-list summary finance

 permit 12345600

 permit 12345601

 deny 12345600 ffffff00

 permit -1

Related Commands

permit (SAP filtering)

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

To set conditions for a named IPX Service Advertising Protocol (SAP) filtering access list, use the permit command in access-list configuration mode. To remove a permit condition from an access list, use the no form of this command.

permit network[.node] [network-mask.node-mask] [service-type [server-name]]

no permit network[.node] [network-mask.node-mask] [service-type [server-name]]

Syntax Description

Defaults

No access lists are defined.

Command Modes

Access-list configuration

Command History

Usage Guidelines

Use this command following the ipx access-list command to specify conditions under which a packet passes the named access list.

For additional information on IPX SAP service types, see the access-list (SAP filtering) command.

Examples

The following example creates a SAP access list named MyServer that allows only MyServer to be sent in SAP advertisements:

ipx access-list sap MyServer

 permit 1234 4 MyServer

Related Commands

prc-interval (IPX)

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

To control the hold-down period between partial route calculations, use the prc-interval command in router configuration mode. To restore the default interval, use the no form of this command.

prc-interval seconds

no prc-interval seconds

Syntax Description

Defaults

5 seconds

Command Modes

Router configuration

Command History

Usage Guidelines

The prc-interval command controls how often Cisco IOS software can performs a partial route (PRC) calculation. The PRC calculation is processor-intensive. Therefore, it may be useful to limit how often this is done, especially on slower router models. Increasing the PRC interval reduces the processor load of the router, but potentially slows down the rate of convergence.

This command is analogous to the spf-interval command, which controls the hold-down period between shortest path first calculations.

Examples

The following example sets the PRC calculation interval to 20 seconds:

prc-interval 20

Related Commands

redistribute (IPX)

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

To redistribute from one routing domain into another, and vice versa, use one of the following redistribute commands in router configuration mode. To disable this feature, use the no form of these commands.

For Enhanced Interior Gateway Routing Protocol (EIGRP) or Routing Information Protocol (RIP) environments, use the following command to redistribute from one routing domain into another, and vice versa:

redistribute {connected | eigrp autonomous-system-number | floating-static | rip | static}

no redistribute {connected | eigrp autonomous-system-number | floating-static | rip | static}

Syntax Description

Defaults

Redistribution is enabled between all routing domains except between separate Enhanced IGRP processes.

Redistribution of floating static routes is disabled.

Command Modes

Router configuration

Command History