Table Of Contents
ipx sap-incremental split-horizon
ipx server-split-horizon-on-server-paths
ipx sap-incremental (EIGRP)
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 0ipx sap-incremental eigrp 200ipx sap-incremental split-horizon
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
CautionFor 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
Examples
The following example disables split horizon on serial interface 0:
interface serial 0no ipx sap-incremental split-horizonRelated Commands
ipx eigrp-sap-split-horizon
Configures Enhanced IGRP SAP split horizon.
Configures split horizon.
show ipx eigrp neighbors
Displays the neighbors discovered by Enhanced IGRP.
ipx sap-max-packetsize
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
bytes
Maximum packet size, in bytes. The default is 480 bytes, which allows for 7 servers (64 bytes each), plus 32 bytes of IPX network and SAP header information.
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 672Related Commands
ipx rip-max-packetsize
Configures the maximum packet size of RIP updates sent out the interface.
ipx sap-multiplier
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 0ipx sap-multiplier 10Related Commands
ipx sap-queue-maximum
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 500Related Commands
ipx sap-update-queue-maximum
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
Examples
The following example sets a SAP update queue maximum of 500:
ipx sap-update-queue-maximum 500Related Commands
ipx server-split-horizon-on-server-paths
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-pathsRelated Commands
ipx split-horizon eigrp
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
autonomous-system-number
Enhanced Interior Gateway Routing Protocol (EIGRP) autonomous system number. It can be a number from 1 to 65,535.
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 0no ipx split-horizon eigrp 200ipx spx-idle-time
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
delay-in-seconds
The amount of time, in seconds, to wait before spoofing SPX keepalives after data transfer has stopped.
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 0ipx spx-spoofno ipx route-cacheipx spx-idle-time 300Related Commands
ipx spx-spoof
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 0ipx spx-spoofno ipx route-cacheRelated Commands
Configures the throughput.
show ipx spx-spoof
Displays the table of SPX connections through interfaces for which SPX spoofing is enabled.
ipx throughput
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. This value is also supplied to NetWare Link-Services Protocol (NLSP) for use in its metric calculations.
Examples
The following example changes the throughput to 1,000,000 bits per second:
ipx throughput 1000000Related Commands
ipx triggered-rip-delay
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
delay
Delay, in milliseconds, between packets in a multiple-packet RIP update. The default delay is 55 ms. Novell recommends a delay of 55 ms.
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 0ipx triggered-rip-delay 55Related Commands
ipx triggered-rip-holddown
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
milliseconds
Amount of time, in milliseconds, for which the router will wait before sending flashes about RIP changes.
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 0ipx triggered-rip-holddown 100Related Commands
ipx triggered-sap-delay
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
delay
Delay, in milliseconds, between packets in a multiple-packet SAP update. The default delay is 55 ms. Novell recommends a delay of 55 ms.
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 0ipx triggered-sap-delay 55Related Commands
ipx triggered-sap-holddown
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
milliseconds
Amount of time, in milliseconds, for which the router will wait before sending flashes about RIP changes.
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 0ipx triggered-sap-holddown 100Related Commands
ipx type-20-helpered
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 0ipx network aaipx type-20-helperedipx helper-address bb.ffff.ffff.ffffRelated Commands
ipx helper-address
Forwards broadcast packets to a specified server.
Forwards IPX type 20 propagation packet broadcasts to other network segments.
ipx type-20-input-checks
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-checksRelated Commands
Restricts the forwarding of IPX type 20 propagation packet broadcasts.
Forwards IPX type 20 propagation packet broadcasts to other network segments.
ipx type-20-output-checks
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-checksRelated Commands
Restricts the acceptance of IPX type 20 propagation packet broadcasts.
Forwards IPX type 20 propagation packet broadcasts to other network segments.
ipx type-20-propagation
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 0ipx type-20-propagationThe 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 0ipx network 123ipx type-20-propagation!interface ethernet 1ipx network 456ipx type-20-propagation!interface ethernet 2ipx network 789Related Commands
ipx update interval
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:
•
•
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:
•
•
•
Examples
The following example configures the update timers for RIP updates on two interfaces in a router:
interface serial 0ipx update interval rip 40interface ethernet 0ipx update interval rip 20The 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 0ipx update interval sap 300Related Commands
ipx update sap-after-rip
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 0ipx update sap-after-ripRelated Commands
ipx watchdog
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 [
