Table Of Contents
access-list (NLSP route aggregation summarization)
deny (NLSP route aggregation summarization)
ipx advertise-default-route-only
ipx backup-server-query-interval
ipx default-triggered-rip-delay
ipx default-triggered-sap-delay
ipx netbios input-access-filter
ipx netbios output-access-filter
ipx pad-process-switched-packets
ipx route-cache inactivity-timeout
ipx route-cache update-timeout
permit (NLSP route aggregation summarization)
Novell IPX commands
Novell Internet Packet Exchange (IPX) is derived from the Xerox Network Systems (XNS) Internet Datagram Protocol (IDP). One major difference between IPX and XNS is that they do not always use the same Ethernet encapsulation format. A second difference is that IPX uses Novell's proprietary Service Advertising Protocol (SAP) to advertise special network services.
Our implementation of Novell's IPX protocol has been certified as providing full IPX router functionality.
Use the commands in this chapter to configure and monitor Novell IPX networks. For IPX configuration information and examples, refer to the "Configuring Novell IPX" chapter in the Network Protocols Configuration Guide, Part 2.
Note
For all commands that previously used the keyword novell, this keyword has been changed to ipx. You can still use the keyword novell in all commands.
access-list (extended)
To define an extended Novell IPX access list, use the extended version of the access-list global configuration command. To remove an extended access list, use the no form of this command.
access-list access-list-number {deny | 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]no access-list access-list-number {deny | 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]Syntax Description
Default
No access lists are predefined.
Command Mode
Global configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.0. The log keyword first appeared in Cisco IOS Release 11.2.
Extended IPX access lists filter on protocol type. All other parameters are optional.
If a network mask is used, all other fields are required.
Use the ipx access-group command to assign an access list to an interface. You can apply only one extended or one standard access list to an interface. The access list filters all outgoing packets on the interface.
Note
lists some IPX protocol names and numbers. lists some IPX socket names and numbers. For additional information about IPX protocol numbers and socket numbers, contact Novell.
Table 45 Some IPX Protocol Names and Numbers
To delete an extended access list, specify the minimum number of keywords and arguments needed to delete the proper access list. For example, to delete the entire access list, use the following command:
no access-list access-list-number
To delete the access list for a specific protocol, use the following command:
no access-list access-list-number {deny | permit} protocol
Examples
The following example denies access to all RIP packets from the RIP process socket on source network 1 that are destined for the RIP process socket on network 2. It permits all other traffic. This example uses protocol and socket names rather than hexadecimal numbers.
access-list 900 deny -1 1 rip 2 rip access-list 900 permit -1The following example permits type 2 packets from any socket from host 10.0000.0C01.5234 to access any sockets on any node on networks 1000 through 100F. It denies all other traffic (with an implicit deny all):
Note
access-list 910 permit 2 10.0000.0C01.5234 0000.0000.0000 0 1000.0000.0000.0000 F.FFFF.FFFF.FFFF 0Related Commands
You can use the master indexes or search online to find documentation of related commands.
access-list (standard)
deny (extended)
ipx access-group
ipx access-list
ipx input-network-filter
ipx output-network-filter
ipx router-filter
permit (extended)
priority-list protocolaccess-list (NLSP route aggregation summarization)
To define an access list that denies or permits area addresses that summarize routes, use the NLSP route aggregation version of the access-list global configuration command. To remove an NLSP route aggregation access list, use the no form of this command.
access-list access-list-number {deny | permit} network network-mask [ticks ticks]
[area-count area-count]no access-list access-list-number {deny | permit} network network-mask [ticks ticks]
[area-count area-count]Syntax Description
Default
No access lists are predefined.
Command Mode
Global configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 11.1.
Use the NLSP route aggregation access list in the following situations:
•
Use the access list to instruct the router to redistribute an aggregated route instead of the explicit route. The access list also contains a "permit all" statement that instructs the router to redistribute explicit routes that are not subsumed by a route summary.
•
•
•
Note
Example
The following example uses NLSP route aggregation access lists to redistribute routes learned from RIP to NLSP area1. Routes learned via RIP are redistributed into NLSP area1. Any routes learned via RIP that are subsumed by aaaa0000 ffff0000 are not redistributed. An address summary is generated instead.
ipx routingipx internal-network 2000interface ethernet 1ipx network 1001ipx nlsp area1 enableinterface ethernet 2ipx network 2001access-list 1200 deny aaaa0000 ffff0000access-list 1200 permit -1ipx router nlsp areaarea-address 1000 fffff000route-aggregationredistribute rip access-list 1200Related Commands
You can use the master indexes or search online to find documentation of related commands.
area-address
deny (NLSP route aggregation summarization)
ipx access-list
ipx nlsp enable
ipx router
permit (NLSP route aggregation summarization)
redistributeaccess-list (SAP filtering)
To define an access list for filtering Service Advertising Protocol (SAP) requests, use the SAP filtering form of the access-list global configuration command. To remove the access list, use the no form of this command.
access-list access-list-number {deny | permit} network[.node] [network-mask.node-mask]
[service-type [server-name]]
no access-list access-list-number {deny | permit} network[.node] [network-mask.node-mask]
[service-type [server-name]]Syntax Description
Default
No access lists are predefined.
Command Mode
Global configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.0.
When configuring SAP filters for NetWare 3.11 and later servers, use the server's internal network and node number (the node number is always 0000.0000.0001) as its address in the access-list command. Do not use the network.node address of the particular interface board.
lists some sample IPX SAP types. For more information about SAP types, contact Novell. Note that in the filter (specified by the service-type argument), we define a value of 0 to filter all SAP services. If, however, you receive a SAP packet with a SAP type of 0, this indicates an unknown service.
Table 47 Sample IPX SAP Services
To delete a SAP access list, specify the minimum number of keywords and arguments needed to delete the proper access list. For example, to delete the entire access list, use the following command:
no access-list access-list-number
To delete the access list for a specific network, use the following command:
no access-list access-list-number {deny | permit} network
Example
The following access list blocks all access to a file server (service Type 4) on the directly attached network by resources on other Novell networks, but allows access to all other available services on the interface:
access-list 1001 deny -1 4access-list 1001 permit -1Related Commands
You can use the master indexes or search online to find documentation of related commands.
deny (SAP filtering)
ipx access-list
ipx input-sap-filter
ipx output-gns-filter
ipx output-sap-filter
ipx router-sap-filter
permit (SAP filtering)
priority-list protocolaccess-list (standard)
To define a standard IPX access list, use the standard version of the access-list global configuration command. To remove a standard access list, use the no form of this command.
access-list access-list-number {deny | permit} source-network[.source-node
[source-node-mask]] [destination-network[.destination-node [destination-node-mask]]]
no access-list access-list-number {deny | permit} source-network[.source-node
[source-node-mask]] [destination-network[.destination-node [destination-node-mask]]]Syntax Description
Default
No access lists are predefined.
Command Mode
Global configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.0.
Standard IPX access lists filter on the source network. All other parameters are optional.
Use the ipx access-group command to assign an access list to an interface. You can apply only one extended or one standard access list to an interface. The access list filters all outgoing packets on the interface.
To delete a standard access list, specify the minimum number of keywords and arguments needed to delete the proper access list. For example, to delete the entire access list, use the following command:
no access-list access-list-number
To delete the access list for a specific network, use the following command:
no access-list access-list-number {deny | permit} source-network
Examples
The following example denies access to traffic from all IPX networks (-1) to destination network 2:
access-list 800 deny -1 2The following example denies access to all traffic from IPX address 1.0000.0c00.1111:
access-list 800 deny 1.0000.0c00.1111The following example denies access from all nodes on network 1 that have a source address beginning with 0000.0c:
access-list 800 deny 1.0000.0c00.0000 0000.00ff.ffffThe following example denies access from source address 1111.1111.1111 on network 1 to destination address 2222.2222.2222 on network 2:
access-list 800 deny 1.1111.1111.1111 0000.0000.0000 2.2222.2222.2222 0000.0000.0000or
access-list 800 deny 1.1111.1111.1111 2.2222.2222.2222Related Commands
You can use the master indexes or search online to find documentation of related commands.
access-list (extended)
deny (standard)
ipx access-group
ipx access-list
ipx input-network-filter
ipx output-network-filter
ipx router-filter
permit (standard)
priority-list protocolarea-address
To define a set of network numbers to be part of the current NLSP area, use the area-address router configuration command. To remove a set of network numbers from the current NLSP area, use the no form of this command.
area-address address mask
no area-address address maskSyntax Description
address
Network number prefix. This is a 32-bit hexadecimal number.
mask
Mask that defines the length of the network number prefix. This is a 32-bit hexadecimal number.
Default
No area address is defined by default.
Command Mode
Router configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.3.
You must configure at least one area address before NLSP will operate.
The area-address command defines a prefix that includes all networks in the area. This prefix allows a single route to an area address to substitute for a longer list of networks.
All networks on which NLSP is enabled must fall under the area address prefix. This configuration is for future compatibility. When Level 2 NLSP becomes available, the only route advertised for the area will be the area address prefix (the prefix represents all networks within the area).
All routers in an NLSP area must be configured with a common area address, or they will form separate areas. You can configure up to three area addresses on the router.
The area address must have zero bits in all bit positions where the mask has zero bits. The mask must consist of only left-justified contiguous one bits.
Examples
The following example defines an area address that includes networks AAAABBC0 through AAAABBDF:
area-address AAAABBC0 FFFFFFE0The following example defines an area address that includes all networks:
area-address 0 0Related Commands
You can use the master indexes or search online to find documentation of related commands.
ipx router nlsp
clear ipx accounting
To delete all entries in the accounting database when IPX accounting is enabled, use the clear ipx accounting EXEC command.
clear ipx accounting [checkpoint]
Syntax Description
Command Mode
EXEC
Usage Guidelines
This command first appeared in Cisco IOS Release 10.0.
Specifying the clear ipx accounting command with no keywords copies the active database to the checkpoint database and clears all entries in the active database. When cleared, active database entries and static entries, such as those set by the ipx accounting-list command, are reset to zero. Dynamically found entries are deleted.
Any traffic that traverses the router after you issue the clear ipx accounting command is saved in the active database. Accounting information in the checkpoint database at that time reflects traffic prior to the most recent clear ipx accounting command.
You can also delete all entries in the active and checkpoint database by issuing the clear ipx accounting command twice in succession.
Example
The following example first displays the contents of the active database before the contents are cleared. Then, the clear ipx accounting command clears all entries in the active database. As a result, the show ipx accounting command shows that there is no accounting information in the active database. Lastly, the show ipx accounting checkpoint command shows that the contents of the active database were copied to the checkpoint database when the clear ipx accounting command was issued.
Router# show ipx accountingSource Destination Packets Bytes0000C003.0000.0c05.6030 0000C003.0260.8c9b.4e33 72 28800000C001.0260.8c8d.da75 0000C003.0260.8c9b.4e33 14 6240000C003.0260.8c9b.4e33 0000C001.0260.8c8d.da75 62 31100000C001.0260.8c8d.e7c6 0000C003.0260.8c9b.4e33 20 14700000C003.0260.8c9b.4e33 0000C001.0260.8c8d.e7c6 20 1470Accounting data age is 6Router# clear ipx accountingRouter# show ipx accountingSource Destination Packets BytesAccounting data age is 0Router# show ipx accounting checkpointSource Destination Packets Bytes0000C003.0000.0c05.6030 0000C003.0260.8c9b.4e33 72 28800000C001.0260.8c8d.da75 0000C003.0260.8c9b.4e33 14 6240000C003.0260.8c9b.4e33 0000C001.0260.8c8d.da75 62 31100000C001.0260.8c8d.e7c6 0000C003.0260.8c9b.4e33 20 14700000C003.0260.8c9b.4e33 0000C001.0260.8c8d.e7c6 20 1470Accounting data age is 6Related Commands
You can use the master indexes or search online to find documentation of related commands.
ipx accounting
ipx accounting-list
ipx accounting-threshold
ipx accounting-transits
show ipx accountingclear ipx cache
To delete entries from the IPX fast-switching cache, use the clear ipx cache EXEC command.
clear ipx cache
Syntax Description
This command has no arguments or keywords.
Command Mode
EXEC
Usage Guidelines
This command first appeared in Cisco IOS Release 10.0.
The clear ipx cache command clears entries used for fast switching and autonomous switching.
Example
The following example deletes all entries from the IPX fast-switching cache:
clear ipx cacheRelated Commands
You can use the master indexes or search online to find documentation of related commands.
clear ipx nhrp
To clear all dynamic entries from the Next Hop Resolution Protocol (NHRP) cache, use the clear ipx nhrp EXEC command.
clear ipx nhrp
Syntax Description
This command has no arguments or keywords.
Command Mode
EXEC
Usage Guidelines
This command first appeared in Cisco IOS Release 11.1.
This command does not clear any static (configured) IPX-to-NBMA address mappings from the NHRP cache.
Example
The following example clears all dynamic entries from the NHRP cache for the interface:
clear ipx nhrpRelated Commands
You can use the master indexes or search online to find documentation of related commands.
clear ipx nlsp neighbors
To delete all NetWare Link Services Protocol (NLSP) adjacencies from the Cisco IOS software's adjacency database, use the clear ipx nlsp neighbors EXEC command.
clear ipx nlsp [tag] neighbors
Syntax Description
Command Mode
EXEC
Usage Guidelines
This command first appeared in Cisco IOS Release 10.3.
Deleting all entries from the adjacency database forces all routers in the area to perform the shortest path first (SPF) calculation.
When you specify an NLSP tag, the router clears all NLSP adjacencies discovered by that NLSP process. An NLSP process is a router's databases working together to manage route information about an area. NLSP version 1.0 routers are always in the same area. Each router has its own adjacencies, link-state, and forwarding databases. These databases operate collectively as a single process to discover, select, and maintain route information about the area. NLSP version 1.1 routers that exist within a single area also use a single process.
NLSP version 1.1 routers that interconnect multiple areas use multiple processes to discover, select, and maintain route information about the areas they interconnect. These routers manage an adjacencies, link-state, and area address database for each area to which they attach. Collectively, these databases are still referred to as a process. The forwarding database is shared among processes within a router. The sharing of entries in the forwarding database is automatic when all processes interconnect NLSP version 1.1 areas.
Configure multiple NLSP processes when a router interconnects multiple NLSP areas.
Note
Examples
The following example deletes all NLSP adjacencies from the adjacency database:
clear ipx nlsp neighborsThe following example deletes the NLSP adjacencies for process area2:
clear ipx nlsp area2 neighborsRelated Commands
You can use the master indexes or search online to find documentation of related commands.
clear ipx route
To delete routes from the IPX routing table, use the clear ipx route EXEC command.
clear ipx route {network [network-mask] | default | *}
Syntax Description
Command Mode
EXEC
Usage Guidelines
This command first appeared in Cisco IOS Release 10.0. The network-mask argument and default keyword first appeared in Cisco IOS Release 11.1.
After you use the clear ipx route command, RIP/SAP general requests are issued on all IPX interfaces.
For routers configured for NLSP route aggregation, use this command to clear an aggregated route from the routing table.
Examples
The following example clears the entry for network 3 from the IPX routing table:
clear ipx route 3The following example clears a route summary entry from the IPX routing table:
clear ipx route ccc00000 fff00000Related Commands
You can use the master indexes or search online to find documentation of related commands.
deny (extended)
To set conditions for a named IPX extended access list, use the deny access-list configuration command. To remove a deny condition from an access list, use the no form of this command.
deny 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]no deny 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]Syntax Description
Default
No access lists are defined.
Command Mode
Access-list configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 11.3.
Use this command following the ipx access-list command to specify conditions under which a packet cannot pass the named access list.
For additional information on IPX protocol names and numbers, and IPX socket names and numbers, see the access-list (extended) command.
Example
The following example creates an extended access list named sal that denies all SPX packets:
ipx access-list extended saldeny spx any all any all logpermit anyRelated Commands
You can use the master indexes or search online to find documentation of related commands.
access-list (extended)
ipx access-group
ipx access-list
permit (extended)
show ipx access-listdeny (NLSP route aggregation summarization)
To filter explicit routes and generate an aggregated route for a named NLSP route aggregation access list, use the deny access-list configuration command. To remove a deny condition from an access list, use the no form of this command.
deny network network-mask [ticks ticks] [area-count area-count]
no deny network network-mask [ticks ticks] [area-count area-count]Syntax Description
Default
No access lists are defined.
Command Mode
Access-list configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 11.3.
Use this command following the ipx access-list command to prevent the redistribution of explicit networks that are denied by the access list entry and, instead, generate an appropriate aggregated (summary) route.
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.
Example
The following example from a configuration file defines the access list named finance for NLSP route aggregation. This access list prevents redistribution of explicit routes in the range 12345600 to 123456FF and, instead, summarizes these routes into a single aggregated route. The access list allows explicit route redistribution of all other routes.
ipx access-list summary financedeny 12345600 ffffff00permit -1Related Commands
You can use the master indexes or search online to find documentation of related commands.
access-list (NLSP route aggregation summarization)
ipx access-group
ipx access-list
permit (NLSP route aggregation summarization)
show ipx access-listdeny (SAP filtering)
To set conditions for a named IPX SAP filtering access list, use the deny access-list configuration command. To remove a deny condition from an access list, use the no form of this command.
deny network[.node] [network-mask.node-mask] [service-type [server-name]]
no deny network[.node] [network-mask.node-mask] [service-type [server-name]]Syntax Description
Default
No access lists are defined.
Command Mode
Access-list configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 11.3.
Use this command following the ipx access-list command to specify conditions under which a packet cannot pass the named access list.
For additional information on IPX SAP service types, see the access-list (SAP filtering) command.
Example
The following example creates a SAP access list named MyServer that denies MyServer to be sent in SAP advertisements:
ipx access-list sap MyServerdeny 1234 4 MyServerRelated Commands
You can use the master indexes or search online to find documentation of related commands.
access-list (SAP filtering)
ipx access-group
ipx access-list
permit (SAP filtering)
show ipx access-listdeny (standard)
To set conditions for a named IPX access list, use the deny access-list configuration command. To remove a deny condition from an access list, use the no form of this command.
deny source-network[.source-node [source-node-mask]]
[destination-network[.destination-node [destination-node-mask]]]
no deny source-network[.source-node [source-node-mask]]
[destination-network[.destination-node [destination-node-mask]]]Syntax Description
Default
No access lists are defined.
Command Mode
Access-list configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 11.3.
Use this command following the ipx access-list command to specify conditions under which a packet cannot pass the named access list.
For additional information on creating IPX access lists, see the access-list (standard) command.
Example
The following example creates a standard access list named fred. It denies communication with only IPX network number 5678.
ipx access-list standard freddeny 5678 anypermit anyRelated Commands
You can use the master indexes or search online to find documentation of related commands.
access-list (standard)
ipx access-group
ipx access-list
permit (standard)
show ipx access-listdistribute-list in
To filter networks received in updates, use the distribute-list in router configuration command. To change or cancel the filter, use the no form of this command.
distribute-list {access-list-number | name} in [interface-name]
no distribute-list {access-list-number | name} in [interface-name]Syntax Description
Default
Disabled
Command Mode
Router configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.0.
Example
The following example causes only two networks—network 2 and network 3—to be accepted by an Enhanced IGRP routing process:
access-list 800 permit 2access-list 800 permit 3access-list 800 deny -1!ipx router eigrp 100network 3distribute-list 800 inRelated Commands
You can use the master indexes or search online to find documentation of related commands.
access-list (NLSP route aggregation summarization)
access-list (standard)
deny (NLSP route aggregation summarization)
deny (standard)
distribute-list out
ipx access-list
permit (NLSP route aggregation summarization)
permit (standard)
redistributedistribute-list out
To suppress networks from being advertised in updates, use the distribute-list out router configuration command. To cancel this function, use the no form of this command.
distribute-list {access-list-number | name} out [interface-name | routing-process]
no distribute-list {access-list-number | name} out [interface-name | routing-process]Syntax Description
Default
Disabled
Command Mode
Router configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.0.
When redistributing networks, a routing process name can be specified as an optional trailing argument to the distribute-list out command. This causes the access list to be applied to only those routes derived from the specified routing process. After the process-specific access list is applied, any access list specified by a distribute-list out command without a process name argument is applied. Addresses not specified in the distribute-list out command are not advertised in outgoing routing updates.
Example
The following example causes only one network—network 3—to be advertised by an Enhanced IGRP routing process:
access-list 800 permit 3access-list 800 deny -1!ipx router eigrp 100network 3distribute-list 800 outRelated Commands
You can use the master indexes or search online to find documentation of related commands.
access-list (NLSP route aggregation summarization)
access-list (standard)
deny (NLSP route aggregation summarization)
deny (standard)
distribute-list in
ipx access-list
ipx router
permit (NLSP route aggregation summarization)
permit (standard)
redistributedistribute-sap-list in
To filter services received in updates, use the distribute-sap-list in router configuration command. To change or cancel the filter, use the no form of this command.
distribute-sap-list {access-list-number | name} in [interface-name]
no distribute-sap-list {access-list-number | name} in [interface-name]Syntax Description
Default
Disabled
Command Mode
Router configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 11.1.
Example
In the following example, the router redistributes Enhanced IGRP into NLSP area1. Only services for network 2 and 3 are accepted by the NLSP routing process.
access-list 1000 permit 2access-list 1000 permit 3access-list 1000 deny -1!ipx router nlsp area1redistribute eigrpdistribute-sap-list 1000 inRelated Commands
You can use the master indexes or search online to find documentation of related commands.
access-list (SAP filtering)
deny (SAP filtering)
distribute-list out
ipx access-list
permit (SAP filtering)
redistributedistribute-sap-list out
To suppress services from being advertised in SAP updates, use the distribute-sap-list out router configuration command. To cancel this function, use the no form of this command.
distribute-sap-list {access-list-number | name} out [interface-name | routing-process]
no distribute-sap-list {access-list-number | name} out [interface-name | routing-process]Syntax Description
Default
Disabled
Command Mode
Router configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 11.1.
When redistributing networks, a routing process name can be specified as an optional trailing argument to the distribute-sap-list out command. This causes the access list to be applied to only those routes derived from the specified routing process. After the process-specific access list is applied, any access list specified by a distribute-sap-list out command without a process name argument is applied. Addresses not specified in the distribute-sap-list out command are not advertised in outgoing routing updates.
Example
The following example causes only services from network 3 to be advertised by an Enhanced IGRP routing process:
access-list 1010 permit 3access-list 1010 deny -1!ipx router eigrp 100network 3distribute-sap-list 1010 outRelated Commands
You can use the master indexes or search online to find documentation of related commands.
access-list (SAP filtering)
deny (SAP filtering)
distribute-sap-list in
ipx access-list
ipx router
permit (SAP filtering)
redistributeipx access-group
To apply generic input and output filters to an interface, use the ipx access-group interface configuration command. To remove filters, use the no form of this command.
ipx access-group {access-list-number | name} [in | out]
no ipx access-group {access-list-number | name} [in | out]Syntax Description
Default
No filters are predefined.
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.0.
Generic filters control which data packets an interface receives or sends out based on the packet's source and destination addresses, IPX protocol type, and source and destination socket numbers. You use the standard access-list and extended access-list commands to specify the filtering conditions.
You can apply only one input filter and one output filter per interface or subinterface.
When you do not specify an input (in) or output (out) filter in the command line, the default is an output filter.
You cannot configure an output filter on an interface where autonomous switching is already configured. Similarly, you cannot configure autonomous switching on an interface where an output filter is already present. You cannot configure an input filter on an interface if autonomous switching is already configured on any interface. Likewise, you cannot configure input filters if autonomous switching is already enabled on any interface.
Examples
In the following example, access list 801 is applied to Ethernet interface 1. Because the command line does not specify an input filter or output filter with the keywords in or out, the software assumes that it is an output filter.
interface ethernet 1ipx access-group 801In the following example, access list 901 is applied to Ethernet interface 0. The access list is an input filter access list as specified by the keyword in.
interface ethernet 0ipx access-group 901 inTo remove the input access list filter in the previous example, you must specify the in keyword when you use the no form of the command. The following example correctly removes the access list:
interface ethernet 0no ipx access-group 901 inRelated Commands
You can use the master indexes or search online to find documentation of related commands.
access-list (extended)
access-list (standard)
deny (extended)
deny (standard)
ipx access-list
permit (extended)
permit (standard)
priority-list protocolipx access-list
To define an IPX access list by name, use the ipx access-list global configuration command. To remove a named IPX access list, use the no form of this command.
ipx access-list {standard | extended | sap | summary} name
no ipx access-list {standard | extended | sap | summary} name
CautionNamed access lists will not be recognized by any software release prior to Cisco IOS Release 11.3.
Syntax Description
Default
There is no default named IPX access list.
Command Mode
Global configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 11.3.
Use this command to configure a named IPX access list as opposed to a numbered IPX access list. This command will take you into access-list configuration mode, where you must define the denied or permitted access conditions with the deny and permit commands.
Specifying standard, extended, sap, or summary with the ipx access-list command determines the prompt you get when you enter access-list configuration mode.
Named access lists are not compatible with Cisco IOS releases prior to Release 11.3.
Examples
The following example creates a standard access list named fred. It permits communication with only IPX network number 5678.
ipx access-list standard fredpermit 5678 anydeny anyThe following example creates an extended access list named sal that denies all SPX packets:
ipx access-list extended saldeny spx any all any all logpermit anyThe following example creates a SAP access list named MyServer that allows only MyServer to be sent in SAP advertisements:
ipx access-list sap MyServerpermit 1234 4 MyServerThe following example creates a summary access list named finance that allows the redistribution of all explicit routes every 64 ticks:
ipx access-list summary financepermit -1 ticks 64Related Commands
You can use the master indexes or search online to find documentation of related commands.
access-list (extended)
access-list (NLSP route aggregation summarization)
access-list (SAP filtering)
access-list (standard)
deny (extended)
deny (NLSP route aggregation summarization)
deny (SAP filtering)
deny (standard)
permit (extended)
permit (NLSP route aggregation summarization)
permit (SAP filtering)
permit (standard)
show ipx access-listipx accounting
To enable IPX accounting, use the ipx accounting interface configuration command. To disable IPX accounting, use the no form of this command.
ipx accounting
no ipx accountingSyntax Description
This command has no arguments or keywords.
Default
Disabled
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.0.
IPX accounting allows you to collect information about IPX packets and the number of bytes that are switched through the Cisco IOS software. You collect information based on the source and destination IPX address. IPX accounting tracks only IPX traffic that is routed out an interface on which IPX accounting is configured; it does not track traffic generated by or terminated at the router itself.
The Cisco IOS software maintains two accounting databases: an active database and a checkpoint database. The active database contains accounting data tracked until the database is cleared. When the active database is cleared, its contents are copied to the checkpoint database. Using these two databases together allows you to monitor both current traffic and traffic that has previously traversed the router.
IPX accounting statistics will be accurate even if IPX access lists are being used or if IPX fast switching is enabled. Enabling IPX accounting significantly decreases performance of a fast switched interface.
IPX accounting does not keep statistics if autonomous switching is enabled. In fact, IPX accounting is disabled if autonomous or SSE switching is enabled.
Example
The following example enables IPX accounting on Ethernet interface 0:
interface ethernet 0ipx accountingRelated Commands
You can use the master indexes or search online to find documentation of related commands.
clear ipx accounting
ipx accounting-list
ipx accounting-threshold
ipx accounting-transits
show ipx accountingipx accounting-list
To filter networks for which IPX accounting information is kept, use the ipx accounting-list global configuration command. To remove the filter, use the no form of this command.
ipx accounting-list number mask
no ipx accounting-list number maskSyntax Description
Default
No filters are predefined.
Command Mode
Global configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.0.
The source and destination addresses of each IPX packet traversing the router are compared with the network numbers in the filter. If there is a match, accounting information about the IPX packet is entered into the active accounting database. If there is no match, the IPX packet is considered to be a transit packet and may be counted, depending on the setting of the ipx accounting-transits global configuration command.
Example
The following example adds all networks with IPX network numbers beginning with 1 to the list of networks for which accounting information is kept:
ipx accounting-list 1 0000.0000.0000Related Commands
You can use the master indexes or search online to find documentation of related commands.
clear ipx accounting
ipx accounting
ipx accounting-threshold
ipx accounting-transits
show ipx accountingipx accounting-threshold
To set the maximum number of accounting database entries, use the ipx accounting-threshold global configuration command. To restore the default, use the no form of this command.
ipx accounting-threshold threshold
no ipx accounting-threshold thresholdSyntax Description
threshold
Maximum number of entries (source and destination address pairs) that the Cisco IOS software can accumulate.
Default
512 entries
Command Mode
Global configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.0.
The accounting threshold defines the maximum number of entries (source and destination address pairs) that the software accumulates. The threshold is designed to prevent IPX accounting from consuming all available free memory. This level of memory consumption could occur in a router that is switching traffic for many hosts. To determine whether overflows have occurred, use the show ipx accounting EXEC command.
Example
The following example sets the IPX accounting database threshold to 500 entries:
ipx accounting-threshold 500Related Commands
You can use the master indexes or search online to find documentation of related commands.
clear ipx accounting
ipx accounting
ipx accounting-list
ipx accounting-transits
show ipx accountingipx accounting-transits
To set the maximum number of transit entries that will be stored in the IPX accounting database, use the ipx accounting-transits global configuration command. To disable this function, use the no form of this command.
ipx accounting-transits count
no ipx accounting-transitsSyntax Description
Default
0 entries
Command Mode
Global configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.0.
Transit entries are those that do not match any of the networks specified by ipx accounting-list global configuration commands. If you have not defined networks with ipx accounting-list commands, IPX accounting tracks all traffic through the interface (all transit entries) up to the accounting threshold limit.
Example
The following example specifies a maximum of 100 transit records to be stored in the IPX accounting database:
ipx accounting-transits 100Related Commands
You can use the master indexes or search online to find documentation of related commands.
clear ipx accounting
ipx accounting-list
ipx accounting-threshold
show ipx accountingipx advertise-default-route-only
To advertise only the default RIP route via the specified network, use the ipx advertise-default-route-only interface configuration command. To advertise all known RIP routes out the interface, use the no form of this command.
ipx advertise-default-route-only network
no ipx advertise-default-route-only networkSyntax Description
Default
Disabled (that is, all known routes are advertised out the interface)
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.3.
If you specify the ipx advertise-default-route-only command, only a known default RIP route is advertised out the interface; no other networks will be advertised. If you have a large number of routes in the routing table, for example, on the order of 1,000 routes, none of them will be advertised out the interface. However, if the default route is known, it will be advertised. Nodes on the interface can still reach any of the 1,000 networks via the default route.
Specifying the ipx advertise-default-route-only command results in a significant reduction in CPU processing overhead when there are many routes and many interfaces. It also reduces the load on downstream routers.
This command applies only to RIP. NLSP and Enhanced IGRP are not affected when you enable this command. They continue to advertise all routes that they know about.
Note
Example
The following example enables the advertising of the default route only:
interface ethernet 1ipx network 1234ipx advertise-default-route-only 1234Related Commands
You can use the master indexes or search online to find documentation of related commands.
ipx backup-server-query-interval
To change the time between successive queries of each Enhanced IGRP neighbor's backup server table, use the ipx backup-server-query-interval global configuration command. To restore the default time, use the no form of this command.
ipx backup-server-query-interval interval
no ipx backup-server-query-intervalSyntax Description
interval
Minimum time, in seconds, between successive queries of each Enhanced IGRP neighbor's backup server table. The default is 15 seconds.
Default
15 seconds
Command Mode
Global configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.0.
A lower interval may use more CPU resources, but may cause lost server information to be retrieved from other servers' tables sooner.
Example
The following example changes the server query time to 5 seconds:
ipx backup-server-query-interval 5ipx bandwidth-percent eigrp
To configure the percentage of bandwidth that may be used by Enhanced IGRP on an interface, use the ipx bandwidth-percent eigrp interface configuration command. To restore the default value, use the no form of this command.
ipx bandwidth-percent eigrp as-number percent
no ipx bandwidth-percent eigrp as-numberSyntax Description
Default
50 percent
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 11.2.
Enhanced IGRP will use up to 50 percent of the bandwidth of a link, as defined by the bandwidth interface configuration command. This command may be used if some other fraction of the bandwidth is desired. Note that values greater than 100 percent may be configured; this may be useful if the bandwidth is set artificially low for other reasons.
Example
The following example allows Enhanced IGRP to use up to 75 percent (42 kbps) of a 56 kbps serial link in autonomous system 209:
interface serial 0bandwidth 56ipx bandwidth-percent eigrp 209 75Related Commands
You can use the master indexes or search online to find documentation of related commands.
bandwidth
ipx routeripx broadcast-fastswitching
To enable the router to fast switch IPX directed broadcast packets, use the ipx broadcast-fastswitching global configuration command. To disable fast switching of IPX directed broadcast packets, use the no form of the command.
ipx broadcast-fastswitching
no ipx broadcast-fastswitchingSyntax Description
This command has no arguments or keywords.
Default
Disabled
The default behavior is to process-switch directed broadcast packets.
Command Mode
Global configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 11.1.
A directed broadcast is one with a network layer destination address of the form net.ffff.ffff.ffff. The ipx broadcast-fastswitching command permits the router to fast switch IPX directed broadcast packets. This may be useful in certain broadcast-based applications that rely on helpering.
Note that the router never uses autonomous switching for eligible directed broadcast packets, even if autonomous switching is enabled on the output interface. Also note that routing and service updates are always exempt from this treatment.
Example
The following example enables the router to fast switch IPX directed broadcast packets:
ipx broadcast-fastswitchingRelated Commands
You can use the master indexes or search online to find documentation of related commands.
ipx default-output-rip-delay
To set the default interpacket delay for RIP updates sent on all interfaces, use the ipx default-output-rip-delay global configuration command. To return to the initial default delay value, use the no form of this command.
ipx default-output-rip-delay delay
no ipx default-output-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.
Default
55 ms
Command Mode
Global configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 11.1.
The interpacket delay is the delay between the individual packets sent in a multiple-packet routing update. The ipx default-output-rip-delay command sets a default interpacket delay for all interfaces.
The system uses the delay specified by the ipx default-output-rip-delay command for periodic and triggered routing updates when no delay is set for periodic and triggered routing updates on an interface. When you set a delay for triggered routing updates, the system uses the delay specified by the ipx default-output-rip-delay command for only the periodic routing updates sent on all interfaces.
To set a delay for triggered routing updates, see the ipx triggered-rip-delay or ipx default-triggered-rip-delay commands.
Novell recommends a delay of 55 ms for compatibility with older and slower IPX machines. These machines may lose RIP updates because they process packets more slowly than the router sends them. The delay imposed by this command forces the router to pace its output to the slower-processing needs of these IPX machines.
The default delay on a NetWare 3.11 server is about 100 ms.
This command is also useful on limited bandwidth point-to-point links or X.25 and Frame Relay multipoint interfaces.
Example
The following example sets a default interpacket delay of 55 ms for RIP updates sent on all interfaces:
ipx default-output-rip-delay 55Related Commands
You can use the master indexes or search online to find documentation of related commands.
ipx default-triggered-rip-delay
ipx output-rip-delay
ipx triggered-rip-delayipx default-output-sap-delay
To set a default interpacket delay for SAP updates sent on all interfaces, use the ipx default-output-sap-delay global configuration command. To return to the initial default delay value, use the no form of this command.
ipx default-output-sap-delay delay
no ipx default-output-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.
Default
55 ms
Command Mode
Global configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 11.1.
The interpacket delay is the delay between the individual packets sent in a multiple-packet SAP update. The ipx default-output-sap-delay command sets a default interpacket delay for all interfaces.
The system uses the delay specified by the ipx default-output-sap-delay command for periodic and triggered SAP updates when no delay is set for periodic and triggered updates on an interface. When you set a delay for triggered updates, the system uses the delay specified by the ipx default-output-sap-delay command only for the periodic SAP updates sent on all interfaces.
To set a delay for triggered updates, see the ipx triggered-sap-delay or ipx default-triggered-sap-delay commands.
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 servers.
The default delay on a NetWare 3.11 server is about 100 ms.
This command is also useful on limited bandwidth point-to-point links or X.25 interfaces.
Example
The following example sets a default interpacket delay of 55 ms for SAP updates sent on all interfaces:
ipx default-output-sap-delay 55Related Commands
You can use the master indexes or search online to find documentation of related commands.
ipx default-triggered-sap-delay
ipx output-sap-delay
ipx triggered-sap-delayipx default-route
To forward to the default network all packets for which a route to the destination network is unknown, use the ipx default-route global configuration command. To disable the use of the default network, use the no form of this command.
ipx default-route
no ipx default-routeSyntax Description
This command has no arguments or keywords.
Default
Enabled; that is, all packets for which a route to the destination is unknown are forwarded to the default network, which is -2 (0xFFFFFFFE).
Command Mode
Global configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.3.
When you use the no ipx default-route command, Cisco IOS software no longer uses -2 as the default network. Instead, the software interprets -2 as a regular network and packets for which a route to the destination network is unknown are dropped.
Example
The following example disables the forwarding of packets towards the default network:
no ipx default-routeRelated Commands
You can use the master indexes or search online to find documentation of related commands.
ipx advertise-default-route-only
ipx default-triggered-rip-delay
To set the default interpacket delay for triggered RIP updates sent on all interfaces, use the ipx default-triggered-rip-delay global configuration command. To return to the system default delay, use the no form of this command.
ipx default-triggered-rip-delay delay
no ipx default-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.
Default
55 ms
Command Mode
Global configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 11.1.
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 default-triggered-rip-delay command sets the default interpacket delay for triggered routing updates sent on all interfaces. On a single interface, you can override this global default delay for triggered routing updates using the ipx triggered-rip-delay interface command.
The global default delay for triggered routing updates overrides the delay value set by the ipx output-rip-delay or ipx default-output-rip-delay command for triggered routing updates.
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 approximately 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 default-triggered-rip-delay command, 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 "Default" section.
This command is also useful on limited bandwidth point-to-point links, or X.25 and Frame Relay multipoint interfaces.
Example
The following example sets an interpacket delay of 55 ms for triggered routing updates sent on all interfaces:
ipx default-triggered-rip-delay 55Related Commands
You can use the master indexes or search online to find documentation of related commands.
ipx default-output-rip-delay
ipx output-rip-delay
ipx triggered-rip-delayipx default-triggered-sap-delay
To set the default interpacket delay for triggered SAP updates sent on all interfaces, use the ipx default-triggered-sap-delay global configuration command. To return to the system default delay, use the no form of this command.
ipx default-triggered-sap-delay delay
no ipx default-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.
Default
55 ms
Command Mode
Global configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 11.1.
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 default-triggered-sap-delay command sets the default interpacket delay for triggered SAP updates sent on all interfaces. On a single interface, you can override this global default delay for triggered updates using the ipx triggered-sap-delay interface command.
The global default delay for triggered updates overrides the delay value set by the ipx output-sap-delay or ipx default-output-sap-delay command for triggered updates.
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 approximately 100 ms.
When you do not set the interpacket delay for triggered SAP 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 default-triggered-sap-delay command, 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 "Default" section.
This command is also useful on limited bandwidth point-to-point links, or X.25 and Frame Relay multipoint interfaces.
Example
The following example sets an interpacket delay of 55 ms for triggered SAP updates sent on all interfaces:
ipx default-triggered-sap-delay 55Related Commands
You can use the master indexes or search online to find documentation of related commands.
ipx default-output-sap-delay
ipx output-sap-delay
ipx triggered-sap-delayipx delay
To set the tick count, use the ipx delay interface configuration command. To reset the default increment in the delay field, use the no form of this command.
ipx delay ticks
no ipx delaySyntax Description
ticks
Number of IBM clock ticks of delay to use. One clock tick is 1/18 of a second (approximately 55 ms).
Default
The default delay is determined from the delay configured on the interface with the delay command. It is (interface delay + 333) / 334. Therefore, unless you change the delay by a value greater than 334, you will not notice a difference.
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.0.
The ipx delay command sets the count used in the IPX RIP delay field, which is also known as the ticks field.
IPXWAN links determine their delay dynamically. If you do not specify the ipx delay command on an interface and you have not changed the interface delays with the interface delay interface configuration command, all LAN interfaces have a delay of 1 and all WAN interfaces have a delay of 6. The preferred method of adjusting delays is to use the ipx delay command, not the interface delay command. The show ipx interface EXEC command display only the delay value configured with the ipx delay command.
With IPXWAN, if you change the interface delay with the interface delay command, the ipx delay command uses that delay when calculating a delay to use. Also, when changing delays with IPXWAN, the changes affect only the link's calculated delay on the side considered to be the master.
Leaving the delay at its default value is sufficient for most interfaces.
Example
The following example changes the delay for serial interface 0 to 10 ticks:
interface serial 0 ipx delay 10Related Commands
You can use the master indexes or search online to find documentation of related commands.
delay
ipx maximum-paths
ipx output-network-filter
ipx output-rip-delayipx down
To administratively shut down an IPX network, use the ipx down interface configuration command. To restart the network, use the no form of this command.
ipx down network
no ipx downSyntax Description
Default
Disabled
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.0.
The ipx down command administratively shuts down the specified network. The network still exists in the configuration, but is not active. When shutting down, the network sends out update packets informing its neighbors that it is shutting down. This allows the neighboring systems to update their routing, SAP, and other tables without having to wait for routes and services learned via this network to time out.
To shut down an interface in a manner that is considerate of one's neighbor, use ipx down before using the shutdown command.
Example
The following example administratively shuts down network AA on Ethernet interface 0:
interface ethernet 0 ipx down AAipx gns-reply-disable
To disable the sending of replies to IPX Get Nearest Server (GNS) queries, use the ipx gns-reply-disable interface configuration command. To return to the default, use the no form of this command.
ipx gns-reply-disable
no ipx gns-reply-disableSyntax Description
This command has no arguments or keywords.
Default
Replies are sent to IPX GNS queries.
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.0.
Example
The following example disables the sending of replies to GNS queries on Ethernet interface 0:
interface ethernet 0ipx gns-reply-disableRelated Commands
You can use the master indexes or search online to find documentation of related commands.
ipx gns-response-delay
To change the delay when responding to Get Nearest Server (GNS) requests, use the ipx gns-response-delay global or interface configuration command. To return to the default delay, use the no form of this command.
ipx gns-response-delay [milliseconds]
no ipx gns-response-delaySyntax Description
Default
0 (no delay)
Command Mode
Global configuration (globally changes the delay for the router)
Interface configuration (overrides the globally configured delay for an interface)Usage Guidelines
This command first appeared in Cisco IOS Release 10.0.
This command can be used in two modes: global configuration or interface configuration. In both modes, the command syntax is the same. A delay in responding to GNS requests might be imposed so that, in certain topologies, any local Novell IPX servers respond to the GNS requests before our software does. It is desirable to have these end-host server systems get their reply to the client before the router does because the client typically takes the first response, not the best response. In this case the best response is the one from the local server.
NetWare 2.x has a problem with dual-connected servers in parallel with a router. If you are using this version of NetWare, you should set a GNS delay. A value of 500 ms is recommended.
In situations in which servers are always located across routers from their clients, there is no need for a delay to be imposed.
Example
The following example sets the delay in responding to GNS requests to 500 ms (0.5 second):
ipx gns-response-delay 500Related Commands
You can use the master indexes or search online to find documentation of related commands.
ipx gns-round-robin
To rotate using a round-robin selection method through a set of eligible servers when responding to Get Nearest Server (GNS) requests, use the ipx gns-round-robin global configuration command. To use the most recently learned server, use the no form of this command.
ipx gns-round-robin
no ipx gns-round-robinSyntax Description
The command has no arguments or keywords.
Default
The most recently learned, eligible server is used.
Command Mode
Global configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.0.
In the normal server selection process, requests for service are responded to with the most recently learned, closest server. If you enable the round-robin method, the Cisco IOS software maintains a list of the nearest servers eligible to provide specific services. It uses this list when responding to GNS requests. Responses to requests are distributed in a round-robin fashion across all active IPX interfaces on the router.
Eligible servers are those that satisfy the "nearest" requirement for a given request and that are not filtered either by a SAP filter or by a GNS filter.
Example
The following example responds to GNS requests using a round-robin selection method from a list of eligible nearest servers:
ipx gns-round-robinRelated Commands
You can use the master indexes or search online to find documentation of related commands.
ipx output-gns-filter
ipx output-sap-delayipx hello-interval eigrp
To configure the interval between Enhanced IGRP hello packets, use the ipx hello-interval eigrp interface configuration command. To restore the default interval, use the no form of this command.
ipx hello-interval eigrp autonomous-system-number seconds
no ipx hello-interval eigrp autonomous-system-number secondsSyntax Description
Default
For low-speed NBMA networks: 60 seconds
For all other networks: 5 secondsCommand Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.0.
The default of 60 seconds applies only to low-speed, nonbroadcast, multiaccess (NBMA) media. Low speed is considered to be a rate of T1 or slower, as specified with the bandwidth interface configuration command. Note that for purposes of Enhanced IGRP, Frame Relay and SMDS networks may or may not be considered to be NBMA. These networks are considered NBMA if the interface has not been configured to use physical multicasting; otherwise they are considered not to be NBMA.
Example
The following example changes the hello interval to 10 seconds:
interface ethernet 0ipx network 10ipx hello-interval eigrp 4 10Related Commands
You can use the master indexes or search online to find documentation of related commands.
ipx helper-address
To forward broadcast packets to a specified server, use the ipx helper-address interface configuration command. To disable this function, use the no form of this command.
ipx helper-address network.node
no ipx helper-address network.nodeSyntax Description
Default
Disabled
Command Mode
Interface configuration
Usage Guidelines
This command first appeared prior to Cisco IOS Release 10.0.
Routers normally block all broadcast requests and do not forward them to other network segments. This is done to prevent the degradation of performance over the entire network. The ipx helper-address command allows broadcasts to be forwarded to other networks. This is useful when a network segment does not have an end-host capable of servicing a particular type of broadcast request. This command lets you forward the broadcasts to a server, network, or networks that can process them. Incoming unrecognized broadcast packets that match the access list created with the ipx helper-list command, if it is present, are forwarded.
You can specify multiple ipx helper-address commands on a given interface.
The Cisco IOS software supports all-networks flooded broadcasts (sometimes referred to as all-nets flooding). These are broadcast messages that are forwarded to all networks. To configure the all-nets flooding, define the IPX helper address for an interface as follows:
ipx helper-address -1.FFFF.FFFF.FFFFOn systems configured for IPX routing, this helper address is displayed as follows (via the show ipx interface command):
FFFFFFFF.FFFF.FFFF.FFFFAlthough our software takes care to keep broadcast traffic to a minimum, some duplication is unavoidable. When loops exist, all-nets flooding can propagate bursts of excess traffic that will eventually age out when the hop count reaches its limit (16 hops). Use all-nets flooding carefully and only when necessary. Note that you can apply additional restrictions by defining a helper list.
To forward type 20 packets to only those nodes specified by the ipx helper-address command, use the ipx helper-address command in conjunction with the ipx type-20-helpered global configuration command.
To forward type 20 packets to all nodes on the network, use the ipx type-20-propagation command. See the ipx type-20-propagation command for more information.
Example
In the following example, all-nets broadcasts on Ethernet interface 0 (except type 20 propagation packets) are forwarded to IPX server 00b4.23cd.110a on network bb:
interface ethernet 0 ipx helper-address bb.00b4.23cd.110aRelated Commands
You can use the master indexes or search online to find documentation of related commands.
ipx helper-list
ipx type-20-propagationipx helper-list
To assign an access list to an interface to control broadcast traffic (including type 20 propagation packets), use the ipx helper-list interface configuration command. To remove the access list from an interface, use the no form of this command.
ipx helper-list {access-list-number | name}
no ipx helper-list {access-list-number | name}Syntax Description
Default
No access list is preassigned.
Command Mode
Interface configuration
Usage Guidelines
This command first appeared prior to Cisco IOS Release 10.0.
The ipx helper-list command specifies an access list to use in forwarding broadcast packets. One use of this command is to prevent client nodes from discovering services they should not use.
Because the destination address of a broadcast packet is by definition the broadcast address, this command is useful only for filtering based on the source address of the broadcast packet.
The helper list, if present, is applied to both all-nets broadcast packets and type 20 propagation packets.
The helper list on the input interface is applied to packets before they are output via either the helper address or type 20 propagation packet mechanism.
Example
The following example assigns access list 900 to Ethernet interface 0 to control broadcast traffic:
interface ethernet 0ipx helper-list 900Related Commands
You can use the master indexes or search online to find documentation of related commands.
access-list (extended)
access-list (standard)
deny (extended)
deny (standard)
ipx access-list
ipx helper-address
ipx type-20-propagation
permit (extended)
permit (standard)ipx hold-down eigrp
To specify the length of time a lost Enhanced IGRP route is placed in the hold-down state, use the ipx hold-down eigrp interface configuration command. To restore the default time, use the no form of this command.
ipx hold-down eigrp autonomous-system-number seconds
no ipx hold-down eigrp autonomous-system-number secondsSyntax Description
autonomous-system-number
Enhanced IGRP autonomous system number. It can be a number from 1 to 65535.
seconds
Hold-down time, in seconds. The default hold time is 5 seconds.
Default
5 seconds
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.0.
When an Enhanced IGRP route is lost, it is placed into a hold-down state for a period of time. The purpose of the hold-down state is to ensure the validity of any new routes for the same destination.
The amount of time a lost Enhanced IGRP route is placed in the hold-down state is configurable. Set the amount of time to a value longer than the default of 5 seconds if your network requires a longer time for the unreachable route information to propagate.
Example
The following example changes the hold-down time for autonomous system 4 to 45 seconds:
interface ethernet 0ipx network 10ipx hold-down eigrp 4 45ipx hold-time eigrp
To specify the length of time a neighbor should consider Enhanced IGRP hello packets valid, use the ipx hold-time eigrp interface configuration command. To restore the default time, use the no form of this command.
ipx hold-time eigrp autonomous-system-number seconds
no ipx hold-time eigrp autonomous-system-number secondsSyntax Description
Default
For low-speed NBMA networks: 180 seconds
For all other networks: 15 secondsCommand Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.0.
If the current value for the hold time is less than two times the interval between hello packets, the hold time will be reset to three times the hello interval.
If a router does not receive a hello packet within the specified hold time, routes through the router are considered available.
Increasing the hold time delays route convergence across the network.
The default of 180 seconds applies only to low-speed, nonbroadcast, multiaccess (NBMA) media. Low speed is considered to be a rate of T1 or slower, as specified with the bandwidth interface configuration command.
Example
The following example changes the hold time to 45 seconds:
interface ethernet 0ipx network 10ipx hold-time eigrp 4 45Related Commands
You can use the master indexes or search online to find documentation of related commands.
ipx input-network-filter
To control which networks are added to the Cisco IOS software's routing table, use the ipx input-network-filter interface configuration command. To remove the filter from the interface, use the no form of this command.
ipx input-network-filter {access-list-number | name}
no ipx input-network-filter {access-list-number | name}Syntax Description
Default
No filters are predefined.
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.0.
The ipx input-network-filter command controls which networks are added to the routing table based on the networks learned in incoming IPX routing updates (RIP updates) on the interface.
You can issue only one ipx input-network-filter command on each interface.
Examples
In the following example, access list 876 controls which networks are added to the routing table when IPX routing updates are received on Ethernet interface 1. Routing updates for network 1b will be accepted. Routing updates for all other networks are implicitly denied and are not added to the routing table.
access-list 876 permit 1binterface ethernet 1ipx input-network-filter 876The following example is a variation of the preceding that explicitly denies network 1a and explicitly allows updates for all other networks:
access-list 876 deny 1a access-list 876 permit -1Related Commands
You can use the master indexes or search online to find documentation of related commands.
access-list (extended)
access-list (standard)
deny (extended)
deny (standard)
ipx access-list
ipx output-network-filter
ipx router-filter
permit (extended)
permit (standard)ipx input-sap-filter
To control which services are added to the Cisco IOS software's SAP table, use the ipx input-sap-filter interface configuration command. To remove the filter, use the no form of this command.
ipx input-sap-filter {access-list-number | name}
no ipx input-sap-filter {access-list-number | name}Syntax Description
Default
No filters are predefined.
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.0.
The ipx input-sap-filter command filters all incoming service advertisements received by the router. This is done prior to accepting information about a service.
You can issue only one ipx input-sap-filter command on each interface.
When configuring SAP filters for NetWare 3.11 and later servers, use the server's internal network and node number (the node number is always 0000.0000.0001) as its address in the access-list (SAP filtering) command. Do not use the network.node address of the particular interface board.
Example
The following example denies service advertisements about the server at address 3c.0800.89a1.1527, but accepts information about all other services on all other networks:
access-list 1000 deny 3c.0800.89a1.1527access-list 1000 permit -1!interface ethernet 0ipx input-sap-filter 1000Related Commands
You can use the master indexes or search online to find documentation of related commands.
access-list (SAP filtering)
deny (SAP filtering)
ipx access-list
ipx output-sap-filter
ipx router-sap-filter
permit (SAP filtering)ipx internal-network
To set an internal network number for use by NLSP and IPXWAN, use the ipx internal-network global configuration command. To remove an internal network number, use the no form of this command.
ipx internal-network network-number
no ipx internal-network [network-number]Syntax Description
Default
No internal network number is set.
Command Mode
Global configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.3.
An internal network number is a network number assigned to the router. This network number must be unique within the internetwork.
You must configure an internal network number on each device on an NLSP-capable network for NLSP to operate.
When you set an internal network number, the Cisco IOS software advertises the specified network out all interfaces. It accepts packets destined to that network at the address internal-network.0000.0000.0001.
Example
The following example assigns internal network number e001 to the local router:
ipx routingipx internal-network e001Related Commands
You can use the master indexes or search online to find documentation of related commands.
ipx ipxwan
To enable the IPXWAN protocol on a serial interface, use the ipx ipxwan interface configuration command. To disable the IPXWAN protocol, use the no form of this command.
ipx ipxwan [local-node {network-number | unnumbered} local-server-name retry-interval
retry-limit]
no ipx ipxwanSyntax Description
local-node
(Optional) Primary network number of the router. This is an IPX network number that is unique across the entire internetwork. On NetWare 3.x servers, the primary network number is called the internal network number. The device with the higher number is determined to be the link master. A value of 0 causes the Cisco IOS software to use the configured internal network number.
network-number
(Optional) IPX network number to be used for the link if this router is the one determined to be the link master. The number is an eight-digit hexadecimal number that uniquely identifies a network cable segment. It can be a number in the range 0 to FFFFFFFD. A value 0 is equivalent to specifying the keyword unnumbered.
You do not need to specify leading zeros in the network number. For example, for the network number 000000AA, you can enter AA.
unnumbered
(Optional) Specifies that no IPX network number is defined for the link. This is equivalent to specifying a value of 0 for the network-number argument.
local-server-name
(Optional) Name of the local router. It can be up to 47 characters long, and can contain uppercase letters, digits, underscores (_), hyphens (-), and at signs (@). On NetWare 3.x servers, this is the router name. For our routers, this is the name of the router as configured via the hostname command; that is, the name that precedes the standard prompt, which is an angle bracket (>) for EXEC mode or a pound sign (#) for privileged EXEC mode.
retry-interval
(Optional) Retry interval, in seconds. This interval defines how often the software will retry the IPXWAN start-up negotiation if a start-up failure occurs. Retries will occur until the retry limit defined by the retry-limit argument is reached. It can be a value from 1 to 600. The default is 20 seconds.
retry-limit
(Optional) Maximum number of times the software retries the IPXWAN start-up negotiation before taking the action defined by the ipx ipxwan error command. It can be a value from
1 through 100. The default is 3.
Default
IPXWAN is disabled.
If you enable IPXWAN, the default is unnumbered.
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.0. The unnumbered keyword and retry-interval argument first appeared in Cisco IOS Release 10.3.
If you omit all optional arguments and keywords, the ipx ipxwan command defaults to ipx ipxwan 0 unnumbered router-name (which is equivalent to ipx ipxwan 0 local-server-name), where router-name is the name of the router as configured with the hostname global configuration command. For this configuration, the show ipx interface command displays ipx ipxwan 0 0 local-server-name.
If you enter a value of 0 for the network-number argument, the output of the show running-config EXEC command does not show the 0 but rather reports this value as "unnumbered."
The name of each device on each side of the link must be different.
IPXWAN is a start-up end-to-end options negotiations protocol. When a link comes up, the first IPX packets sent across are IPXWAN packets negotiating the options for the link. When the IPXWAN options have been successfully determined, normal IPX traffic starts. The three options negotiated are the link IPX network number, internal network number, and link delay (ticks) characteristics. The side of the link with the higher local-node number (internal network number) gives the IPX network number and delay to use for the link to the other side. Once IPXWAN finishes, no IPXWAN packets are sent unless link characteristics change or the connection fails. For example, if the IPX delay is changed from the default setting, an IPXWAN restart will be forced.
To enable the IPXWAN protocol on a serial interface, you must not have configured an IPX network number (using the ipx network interface configuration command) on that interface.
To control the delay on a link, use the ipx delay interface configuration command. If you issue this command when the serial link is already up, the state of the link will be reset and renegotiated.
Examples
The following example enables IPXWAN on serial interface 0:
interface serial 0encapsulation pppipx ipxwanThe following example enables IPXWAN on serial interface 1 on device CHICAGO-AS. When the link comes up, CHICAGO-AS will be the master because it has a larger internal network number. It will give the IPX number 100 to NYC-AS to use as the network number for the link. The link delay, in ticks, will be determined by the exchange of packets between the two access servers.
On the local access server (CHICAGO-AS):
interface serial 1no ipx networkencapsulation pppipx ipxwan 6666 100 CHICAGO-ASOn the remote router (NYC-AS):
interface serial 0no ipx networkencapsulation pppipx ipxwan 1000 101 NYC-ASRelated Commands
You can use the master indexes or search online to find documentation of related commands.
encapsulation ppp
hostname
ipx delay
ipx internal-network
ipx ipxwan error
ipx ipxwan static
ipx network
show ipx interfaceipx ipxwan error
To define how to handle IPXWAN when IPX fails to negotiate properly at link startup, use the ipx ipxwan error interface configuration command. To restore the default, use the no form of this command.
ipx ipxwan error [reset | resume | shutdown]
no ipx ipxwan error [reset | resume | shutdown]Syntax Description
Default
The link is reset.
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.3.
Use the ipx ipxwan error command to define what action to take if the IPXWAN startup negotiation fails.
Example
In the following example, the serial link will be shut down if the IPXWAN startup negotiation fails after three attempts spaced 20 seconds apart:
interface serial 0encapsulation pppipx ipxwanipx ipxwan error shutdownRelated Commands
You can use the master indexes or search online to find documentation of related commands.
ipx ipxwan static
To negotiate static routes on a link configured for IPXWAN, use the ipx ipxwan static interface configuration command. To disable static route negotiation, use the no form of this command.
ipx ipxwan static
no ipx ipxwan staticSyntax Description
This command has no arguments or keywords.
Default
Static routing is disabled.
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.3.
When you specify the ipx ipxwan static command, the interface negotiates static routing on the link. If the router at the other side of the link is not configured to negotiate for static routing, the link will not initialize.
Example
The following example enables static routing with IPXWAN:
interface serial 0encapsulation pppipx ipxwanipx ipxwan staticRelated Commands
You can use the master indexes or search online to find documentation of related commands.
ipx link-delay
To specify the link delay, use the ipx link-delay interface configuration command. To return to the default link delay, use the no form of this command.
ipx link-delay microseconds
no ipx link-delay microsecondsSyntax Description
Default
No link delay (delay of 0)
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.3.
The link delay you specify replaces the default value or overrides the value measured by IPXWAN when it starts. The value is also supplied to NLSP for use in metric calculations.
Example
The following example sets the link delay to 20 microseconds:
ipx link-delay 20Related Commands
You can use the master indexes or search online to find documentation of related commands.
ipx linkup-request
To enable the sending of a general RIP and/or SAP query when an interface comes up, use the
ipx linkup-request interface configuration command. To disable the sending of a general RIP and/or SAP query when an interface comes up, use the no form of this command.ipx linkup-request {rip | sap}
no ipx linkup-request {rip | sap}Syntax Description
rip
Enables the sending of a general RIP query when an interface comes up.
sap
Enables the sending of a general SAP query when an interface comes up.
Default
General RIP and SAP queries are sent.
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 11.3.
Under normal operation, when using serial or other point-to-point links, the router sends RIP and SAP information twice when an interface comes up. The RIP and SAP information is sent as soon as the link is up and is sent again when the router receives a general RIP query from the other end of the connection. By disabling the ipx linkup-request command, the router sends the RIP and SAP information once, instead of twice.
Example
The following example configures the router to disable the general query for both RIP and SAP on serial interface 0:
interface serial 0no ipx linkup-request ripno ipx linkup-request sapRelated Commands
You can use the master indexes or search online to find documentation of related commands.
ipx update interval
ipx update sap-after-ripipx maximum-hops
To set the maximum hop count allowed for IPX packets, use the ipx maximum-hop global configuration command. To return to the default number of hops, use the no form of this command.
ipx maximum-hops hops
no ipx maximum-hops hopsSyntax Description
Default
16 hops
Command Mode
Global configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.3.
Packets whose hop count is equal to or greater than that specified by the ipx maximum-hops command are dropped.
In periodic RIP updates, the Cisco IOS software never advertises any network with a hop count greater than 15. However, using protocols other than RIP, the software might learn routes that are farther away than 15 hops. The ipx maximum-hops command defines the maximum number of hops that the software will accept as reachable, as well as the maximum number of hops that an IPX packet can traverse before it is dropped by the software. Also, the software will respond to a specific RIP request for a network that is reachable at a distance of greater than 15 hops.
Example
The following command configures the software to accept routes that are up to 64 hops away:
ipx maximum-hops 64ipx maximum-paths
To set the maximum number of equal-cost paths the Cisco IOS software uses when forwarding packets, use the ipx maximum-paths global configuration command. To restore the default value, use the no form of this command.
ipx maximum-paths paths
no ipx maximum-pathsSyntax Description
paths
Maximum number of equal-cost paths which the Cisco IOS software will use. It can be a number from 1 to 512. The default value is 1.
Default
1 path
Command Mode
Global configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.0.
The ipx maximum-paths command increases throughput by allowing the software to choose among several equal-cost, parallel paths. (Note that when paths have differing costs, the software chooses lower-cost routes in preference to higher-cost routes.)
When per-host load sharing is disabled, IPX performs load sharing on a packet-by-packet basis in round-robin fashion, regardless of whether you are using fast switching or process switching. That is, the first packet is sent along the first path, the second packet along the second path, and so on. When the final path is reached, the next packet is sent to the first path, the next to the second path, and so on.
Limiting the number of equal-cost paths can save memory on routers with limited memory or with very large configurations. Additionally, in networks with a large number of multiple paths and systems with limited ability to cache out-of-sequence packets, performance might suffer when traffic is split between many paths.
When you enable per-host load sharing, IPX performs load sharing by transmitting traffic across multiple, equal-cost paths while guaranteeing that packets for a given end host always take the same path. Per-host load sharing decreases the possibility that successive packets to a given end host will arrive out of order.
With per-host load balancing, the number of equal-cost paths set by the ipx maximum-paths command must be greater than one; otherwise, per-host load sharing has no effect.
Example
In the following example, the software uses up to three parallel paths:
ipx maximum-paths 3Related Commands
You can use the master indexes or search online to find documentation of related commands.
ipx delay
ipx per-host-load-share
show ipx routeipx netbios input-access-filter
To control incoming IPX NetBIOS FindName messages, use the ipx netbios input-access-filter interface configuration command. To remove the filter, use the no form of this command.
ipx netbios input-access-filter {host | bytes} name
no ipx netbios input-access-filter {host | bytes} nameSyntax Description
Default
No filters are predefined.
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.0.
You can issue only one ipx netbios input-access-filter host and one ipx netbios input-access-filter bytes command on each interface.
These filters apply only to IPX NetBIOS FindName packets. They have no effect on LLC2 NetBIOS packets.
Example
The following example filters packets arriving on Token Ring interface 1 using the NetBIOS access list named engineering:
netbios access-list host engineering permit eng*netbios access-list host engineering deny manu*interface tokenring 1ipx netbios input-access-filter engineeringRelated Commands
You can use the master indexes or search online to find documentation of related commands.
ipx netbios output-access-filter
netbios access-list
show ipx interfaceipx netbios output-access-filter
To control outgoing NetBIOS FindName messages, use the ipx netbios output-access-filter interface configuration command. To remove the filter, use the no form of this command.
ipx netbios output-access-filter {host | bytes} name
no ipx netbios output-access-filter {host | bytes} nameSyntax Description
Default
No filters are predefined.
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.0.
You can issue only one ipx netbios output-access-filter host and one ipx netbios output-access-filter bytes command on each interface.
These filters apply only to IPX NetBIOS FindName packets. They have no effect on LLC2 NetBIOS packets.
Example
The following example filters packets leaving Token Ring interface 1 using the NetBIOS access list named engineering:
netbios access-list bytes engineering permit 20 AA**04interface token 1ipx netbios output-access-filter bytes engineeringRelated Commands
You can use the master indexes or search online to find documentation of related commands.
ipx netbios input-access-filter
netbios access-list
show ipx interfaceipx network
To enable IPX routing on a particular interface and to optionally select the type of encapsulation (framing), use the ipx network interface configuration command. To disable IPX routing, use the no form of this command.
ipx network network [encapsulation encapsulation-type [secondary]]
no ipx network network [encapsulation encapsulation-type]Syntax Description
Default
IPX routing is disabled.
Encapsulation types:
For Ethernet: novell-ether
For Token Ring: sap
For FDDI: snapIf you use NetWare Version 4.0 and Ethernet, you must change the default encapsulation type from novell-ether to sap.
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.0.
The ipx network command allows you to configure a single logical network on a physical network or more than one logical network on the same physical network (network cable segment). Each network on a given interface must have a different encapsulation type.
The first network you configure on an interface is considered to be the primary network. Any additional networks are considered to be secondary networks; these must include the secondary keyword.
Note
NLSP does not support secondary networks. You must use subinterfaces in order to use multiple encapsulations with NLSP.
Note
You can configure an IPX network on any supported interface as long as all the networks on the same physical interface use a distinct encapsulation type. For example, you can configure up to four IPX networks on a single Ethernet cable because Ethernet supports four encapsulation types.
The interface processes only packets with the correct encapsulation and the correct network number. IPX networks using other encapsulations can be present on the physical network. The only effect on the router is that it uses some processing time to examine packets to determine whether they have the correct encapsulation.
All logical networks on an interface share the same set of configuration parameters. For example, if you change the IPX RIP update time on an interface, you change it for all networks on that interface.
When you define multiple logical networks on the same physical network, IPX treats each encapsulation as if it were a separate physical network. This means, for example, that IPX sends RIP updates and SAP updates for each logical network.
The ipx network command is useful when migrating from one type of encapsulation to another. If you are using it for this purpose, you should define the new encapsulation on the primary network.
To delete all networks on an interface, use the following command:
no ipx network
Deleting the primary network with the following command also deletes all networks on that interface. The argument number is the number of the primary network.
no ipx network number
To delete a secondary network on an interface, use one of the following commands. The argument number is the number of a secondary network.
no ipx network number
no ipx network number encapsulation encapsulation-typeNovell's FDDI_RAW encapsulation is common in bridged or switched environments that connect Ethernet-based Novell end hosts via a FDDI backbone. Packets with FDDI_RAW encapsulation are classified as Novell packets, and are not automatically bridged when you enable both bridging and IPX routing. Additionally, you cannot configure FDDI_RAW encapsulation on an interface configured for IPX autonomous or SSE switching. Similarly, you cannot enable IPX autonomous or SSE switching on an interface configured with FDDI_RAW encapsulation.
With FDDI_RAW encapsulation, platforms that do not use CBUS architecture support fast switching. Platforms using CBUS architecture support only process switching of novell-fddi packets received on an FDDI interface.
Examples
The following example uses subinterfaces to create four logical networks on Ethernet interface 0. Each subinterface has a different encapsulation. Any interface configuration parameters that you specify on an individual subinterface are applied to that subinterface only.
ipx routinginterface ethernet 0interface ethernet 0.1ipx network 1 encapsulation novell-etherinterface ethernet 0.2ipx network 2 encapsulation snapinterface ethernet 0.3ipx network 3 encapsulation arpainterface ethernet 0.4ipx network 4 encapsulation sapThe following example uses primary and secondary networks to create the same four logical networks as shown previously in this section. Any interface configuration parameters that you specify on this interface are applied to all the logical networks. For example, if you set the routing update timer to 120 seconds, this value is used on all four networks.
ipx routingipx network 1 encapsulation novell-etheripx network 2 encapsulation snap secondaryipx network 3 encapsulation arpa secondaryipx network 4 encapsulation sap secondaryThe following example enables IPX routing on FDDI interfaces 0.2 and 0.3. On FDDI interface 0.2, the encapsulation type is SNAP. On FDDI interface 0.3, the encapsulation type is Novell's FDDI_RAW.
ipx routinginterface fddi 0.2ipx network f02 encapsulation snapinterface fddi 0.3ipx network f03 encapsulation novell-fddiRelated Commands
You can use the master indexes or search online to find documentation of related commands.
ipx nhrp authentication
To configure the authentication string for an interface using Next Hop Resolution Protocol (NHRP), use the ipx nhrp authentication interface configuration command. To remove the authentication string, use the no form of this command.
ipx nhrp authentication string
no ipx nhrp authentication [string]Syntax Description
string
Authentication string configured for the source and destination stations that controls whether NHRP stations allow intercommunication. The string can be up to eight characters long.
Default
No authentication string is configured; the Cisco IOS software adds no authentication option to NHRP packets it generates.
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 11.1.
All routers configured with NHRP on a fabric (for an interface) must share the same authentication string.
Example
In the following example, the authentication string specialxx must be configured in all devices using NHRP on the interface before NHRP communication occurs:
ipx nhrp authentication specialxxipx nhrp holdtime
To change the number of seconds that NHRP nonbroadcast, multiaccess (NBMA) addresses are advertised as valid in authoritative NHRP responses, use the ipx nhrp holdtime interface configuration command. To restore the default value, use the no form of this command.
ipx nhrp holdtime seconds-positive [seconds-negative]
no ipx nhrp holdtime [seconds-positive [seconds-negative]]Syntax Description
Default
7200 seconds (2 hours) for both arguments
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 11.1.
The ipx nhrp holdtime command affects authoritative responses only. The advertised holding time is the length of time the Cisco IOS software tells other routers to keep information that it is provided in authoritative NHRP responses. The cached IPX-to-NBMA address mapping entries are discarded after the holding time expires.
The NHRP cache can contain static and dynamic entries. The static entries never expire. Dynamic entries expire regardless of whether they are authoritative or nonauthoritative.
If you want to change the valid time period for negative NHRP responses, you must also include a value for positive NHRP responses, as the arguments are position-dependent.
Examples
In the following example, NHRP NBMA addresses are advertised as valid in positive authoritative NHRP responses for one hour:
ipx nhrp holdtime 3600In the following example, NHRP NBMA addresses are advertised as valid in negative authoritative NHRP responses for one hour and in positive authoritative NHRP responses for two hours:
ipx nhrp holdtime 7200 3600ipx nhrp interest
To control which IPX packets can trigger sending a Next Hop Resolution Protocol (NHRP) Request, use the ipx nhrp interest interface configuration command. To restore the default value, use the no form of this command.
ipx nhrp interest access-list-number
no ipx nhrp interest [access-list-number]Syntax Description
Default
All non-NHRP packets can trigger NHRP requests.
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 11.1.
Use this command with the access-list command to control which IPX packets trigger NHRP Requests.
Example
In the following example, any NetBIOS traffic can cause NHRP requests to be sent, but no other IPX packets will cause NHRP requests:
ipx nhrp interest 901access-list 901 permit 20Related Commands
You can use the master indexes or search online to find documentation of related commands.
access-list (extended)
access-list (standard)ipx nhrp map
To statically configure the IPX-to-NBMA address mapping of IPX destinations connected to a nonbroadcast, multiaccess (NBMA) network, use the ipx nhrp map interface configuration command. To remove the static entry from NHRP cache, use the no form of this command.
ipx nhrp map ipx-address nbma-address
no ipx nhrp map ipx-address nbma-addressSyntax Description
Default
No static IPX-to-NBMA cache entries exist.
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 11.1.
You will probably have to configure at least one static mapping in order to reach the Next Hop Server. Repeat this command to statically configure multiple IPX-to-NBMA address mappings.
Example
In the following example, this station in an SMDS network is statically configured to be served by two Next Hop Servers 1.0000.0c14.59ef and 1.0000.0c14.59d0. The NBMA address for 1.0000.0c14.59ef is statically configured to be c141.0001.0001 and the NBMA address for 1.0000.0c14.59d0 is c141.0001.0002.
interface serial 0ipx nhrp nhs 1.0000.0c14.59efipx nhrp nhs 1.0000.0c14.59d0ipx nhrp map 1.0000.0c14.59ef c141.0001.0001ipx nhrp map 1.0000.0c14.59d0 c141.0001.0002Related Commands
You can use the master indexes or search online to find documentation of related commands.
ipx nhrp max-send
To change the maximum frequency at which NHRP packets can be sent, use the ipx nhrp max-send interface configuration command. To restore this frequency to the default value, use the no form of this command.
ipx nhrp max-send pkt-count every interval
no ipx nhrp max-sendSyntax Description
pkt-count
Number of packets which can be transmitted in the range 1 to 65535.
interval
Time (in seconds) in the range 10 to 65535.
Default
pkt-count = 5 packets
interval = 10 secondsCommand Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 11.1.
The software maintains a per interface quota of NHRP packets that can be transmitted. NHRP traffic, whether locally generated, or forwarded, cannot be sent at a rate that exceeds this quota. The quota is replenished at the rate specified by interval.
Example
In the following example, only one NHRP packet can be sent out serial interface 0 each minute:
interface serial 0 ipx nhrp max-send 1 every 60Related Commands
You can use the master indexes or search online to find documentation of related commands.
ipx nhrp network-id
To enable the Next Hop Resolution Protocol (NHRP) on an interface, use the ipx nhrp network-id interface configuration command. To disable NHRP on the interface, use the no form of this command.
ipx nhrp network-id number
no ipx nhrp network-id [number]Syntax Description
number
Globally unique, 32-bit network identifier for a nonbroadcast, multiaccess (NBMA) network. The range is 1 to 4294967295.
Default
NHRP is disabled on the interface.
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 11.1.
In general, all NHRP stations within a fabric must be configured with the same network identifier.
Example
The following example enables NHRP on the interface:
ipx nhrp network-id 1ipx nhrp nhs
To specify the address of one or more NHRP Next Hop Servers, use the ipx nhrp nhs interface configuration command. To remove the address, use the no form of this command.
ipx nhrp nhs nhs-address [net-address]
no ipx nhrp nhs nhs-address [net-address]Syntax Description
nhs-address
Address of the Next Hop Server being specified.
net-address
(Optional) IPX address of a network served by the Next Hop Server.
Default
No Next Hop Servers are explicitly configured, so normal network layer routing decisions forward NHRP traffic.
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 11.1.
Use this command to specify the address of a Next Hop Server and the networks it serves. Normally, NHRP consults the network layer forwarding table to determine how to forward NHRP packets. When Next Hop Servers are configured, the next hop addresses specified with the ipx nhrp nhs command override the forwarding path specified by the network layer forwarding table that would usually be used for NHRP traffic.
For any Next Hop Server that is configured, you can specify multiple networks that it serves by repeating this command with the same nhs-address address, but different net-address IPX network numbers.
Example
In the following example, the Next Hop Server with address 1.0000.0c00.1234 serves IPX network 2:
ipx nhrp nhs 1.0000.0c00.1234 2ipx nhrp record
To re-enable the use of forward record and reverse record options in NHRP Request and Reply packets, use the ipx nhrp record interface configuration command. To suppress the use of such options, use the no form of this command.
ipx nhrp record
no ipx nhrp recordSyntax Description
This command has no arguments or keywords.
Default
Forward record and reverse record options are enabled by default.
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 11.1.
Forward record and reverse record options provide loop detection and are used in NHRP Request and Reply packets. Using the no form of this command disables this method of loop detection. For another method of loop detection, see the ipx nhrp responder command.
Example
The following example suppresses forward record and reverse record options:
no ipx nhrp recordRelated Commands
You can use the master indexes or search online to find documentation of related commands.
ipx nhrp responder
To designate which interface's primary IPX address that the Next Hop Server uses in NHRP Reply packets when the NHRP requestor uses the Responder Address option, use the ipx nhrp responder interface configuration command. To remove the designation, use the no form of this command.
ipx nhrp responder type number
no ipx nhrp responder [type] [number]Syntax Description
Default
The Next Hop Server uses the IPX address of the interface where the NHRP Request was received.
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 11.1.
If an NHRP requestor wants to know which Next Hop Server generates an NHRP Reply packet, it can request that information through the Responder Address option. The Next Hop Server that generates the NHRP Reply packet then complies by inserting its own IPX address in the Responder Address option of the NHRP Reply. The Next Hop Server uses the primary IPX address of the specified interface.
If an NHRP Reply packet being forwarded by a Next Hop Server contains that Next Hop Server's own IPX address, the Next Hop Server generates an Error Indication of type "NHRP Loop Detected" and discards the Reply.
Example
In the following example, any NHRP requests for the Responder Address will cause this router acting as a Next Hop Server to supply the primary IPX address of interface serial 0 in the NHRP Reply packet:
ipx nhrp responder serial 0ipx nhrp use
To configure the software so that NHRP is deferred until the system has attempted to send data traffic to a particular destination multiple times, use the ipx nhrp use interface configuration command. To restore the default value, use the no form of this command.
ipx nhrp use usage-count
no ipx nhrp use usage-countSyntax Description
Default
usage-count = 1. The first time a data packet is sent to a destination for which the system determines NHRP can be used, an NHRP request is sent.
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 11.1.
When the software attempts to transmit a data packet to a destination for which it has determined that NHRP address resolution can be used, an NHRP request for that destination is normally transmitted right away. Configuring the usage-count causes the system to wait until that many data packets have been sent to a particular destination before it attempts NHRP. The usage-count for a particular destination is measured over 1-minute intervals (the NHRP cache expiration interval).
The usage-count applies per destination. So if usage-count is configured to be 3, and 4 data packets are sent toward 10.0.0.1 and 1 packet toward 10.0.0.2, then an NHRP request is generated for 10.0.0.1 only.
If the system continues to need to forward data packets to a particular destination, but no NHRP response has been received, retransmission of NHRP requests are performed. This retransmission occurs only if data traffic continues to be sent to a destination.
The ipx nhrp interest command controls which packets cause NHRP address resolution to take place; the ipx nhrp use command controls how readily the system attempts such address resolution.
Example
In the following example, if in the first minute four packets are sent to one IPX address and five packets are sent to a second IPX address, then a single NHRP request is generated for the second IPX address. If in the second minute the same traffic is generated and no NHRP responses have been received, then the system retransmits its request for the second IPX address.
ipx nhrp use 5Related Commands
You can use the master indexes or search online to find documentation of related commands.
ipx nhrp interest
ipx nhrp max-sendipx nlsp csnp-interval
To configure the NLSP complete sequence number PDU (CSNP) interval, use the ipx nlsp csnp-interval interface configuration command. To restore the default value, use the no form of this command.
ipx nlsp [tag] csnp-interval seconds
no ipx nlsp [tag] csnp-interval secondsSyntax Description
Default
30 seconds
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.3.
The ipx nlsp csnp-interval command applies only to the designated router for the specified interface only. This is because only designated routers send CSNP packets, which are used to synchronize the database.
CSNP does not apply to serial point-to-point interfaces. However, it does apply to WAN connections if the WAN is viewed as a multiaccess meshed network.
Example
The following example configures Ethernet interface 0 to transmit CSNPs every 10 seconds:
interface ethernet 0ipx network 101ipx nlsp enableipx nlsp csnp-interval 10Related Commands
You can use the master indexes or search online to find documentation of related commands.
ipx nlsp hello-interval
ipx nlsp retransmit-intervalipx nlsp enable
To enable NLSP routing on the primary network configured on this interface or subinterface, use the ipx nlsp enable interface configuration command. To disable NLSP routing on the primary network configured on this interface or subinterface, use the no form of this command.
ipx nlsp [tag] enable
no ipx nlsp [tag] enableSyntax Description
Default
NLSP is disabled on all interfaces.
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.3.
When you enable NLSP routing, the current settings for RIP and SAP compatibility modes as specified with the ipx nlsp rip and ipx nlsp sap interface configuration commands take effect automatically.
When you specify an NLSP tag, the router enables NLSP on the specified process. An NLSP process is a router's databases working together to manage route information about an area. NLSP version 1.0 routers are always in the same area. Each router has its own adjacencies, link-state, and forwarding databases. These databases operate collectively as a single process to discover, select, and maintain route information about the area. NLSP version 1.1 routers that exist within a single area also use a single process.
NLSP version 1.1 routers that interconnect multiple areas use multiple processes to discover, select, and maintain route information about the areas they interconnect. These routers manage an adjacencies, link-state, and area address database for each area to which they attach. Collectively, these databases are still referred to as a process. The forwarding database is shared among processes within a router. The sharing of entries in the forwarding database is automatic when all processes interconnect NLSP version 1.1 areas.
Configure multiple NLSP processes when a router interconnects multiple NLSP areas.
Note
Examples
The following example enables NLSP routing on Ethernet interface 0:
interface ethernet 0ipx nlsp enableThe following example enables NLSP routing on serial interface 0:
interface serial 0ipx ipxwan 2442 unnumbered local1ipx nlsp enableThe following example enables NLSP routing for process area3 on Ethernet interface 0:
interface ethernet 0ipx nlsp area3 enableRelated Commands
You can use the master indexes or search online to find documentation of related commands.
ipx nlsp hello-interval
To configure the interval between the transmission of hello packets, use the ipx nlsp hello-interval interface configuration command. To restore the default value, use the no form of this command.
ipx nlsp [tag] hello-interval seconds
no ipx nlsp [tag] hello-interval secondsSyntax Description
Default
10 seconds for the designated router
20 seconds for nondesignated routersCommand Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.3.
The designated router sends hello packets at an interval equal to one-half the configured value.
Use this command to improve the speed at which a failed router or link is detected. A router is declared to be down if a hello has not been received from it for the time determined by the holding time (the hello interval multiplied by the holding time multiplier; by default, 60 seconds for nondesignated routers and 30 seconds for designated routers). You can reduce this time by lowering the hello-interval setting, at the cost of increased traffic overhead.
You may also use this command to reduce link overhead on very slow links by raising the hello interval. This will reduce the traffic on the link at the cost of increasing the time required to detect a failed router or link.
Example
The following example configures serial interface 0 to transmit hello packets every 30 seconds:
interface serial 0ipx ipxwan 2442 unnumbered local1ipx nlsp enableipx nlsp hello-interval 30Related Commands
You can use the master indexes or search online to find documentation of related commands.
ipx nlsp csnp-interval
ipx nlsp hello-multiplier
ipx nlsp retransmit-intervalipx nlsp hello-multiplier
To specify the hello multiplier used on an interface, use the ipx nlsp hello-multiplier interface configuration command. To restore the default value, use the no form of this command.
ipx nlsp [tag] hello-multiplier multiplier
no nlsp [tag] hello-multiplierSyntax Description
Default
The default multiplier is 3.
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 11.1.
You use the hello modifier in conjunction with the hello interval to determine the holding time value sent in a hello packet. The holding time is equal to the hello interval multiplied by the hello multiplier.
The holding time tells the neighboring router how long to wait for another hello packet from the sending router. If the neighboring router does not receive another hello packet in the specified time, then the neighboring router declares that the sending router is down.
You can use this method of determining the holding time when hello packets are lost with some frequency and NLSP adjacencies are failing unnecessarily. You raise the hello multiplier and lower the hello interval correspondingly to make the hello protocol more reliable without increasing the time required to detect a link failure.
Example
In the following example, serial interface 0 will advertise hello packets every 15 seconds. The multiplier is 5. These values determine that the hello packet holding time is 75 seconds.
interface serial 0ipx nlsp hello-interval 15ipx nlsp hello-multiplier 5Related Commands
You can use the master indexes or search online to find documentation of related commands.
ipx nlsp lsp-interval
To configure the time delay between successive NLSP link-state packet (LSP) transmissions, use the ipx nlsp lsp-interval interface configuration command. To restore the default time delay, use the no form of the command.
ipx nlsp [tag] lsp-interval interval
no ipx nlsp [tag] lsp-intervalSyntax Description
Default
55 milliseconds
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 11.1.
This command allows you to control how fast LSPs can be flooded out an interface.
In topologies with a large number of NLSP neighbors and interfaces, a router may have difficulty with the CPU load imposed by LSP transmission and reception. This command allows you to reduce the LSP transmission rate (and by implication the reception rate of other systems).
Example
The following example causes the system to transmit LSPs every 100 milliseconds (10 packets per second) on Ethernet interface 0:
interface Ethernet 0ipx nlsp lsp-interval 100Related Commands
You can use the master indexes or search online to find documentation of related commands.
ipx nlsp metric
To configure the NLSP cost for an interface, use the ipx nlsp metric interface configuration command. To restore the default cost, use the no form of this command.
ipx nlsp [tag] metric metric-number
no ipx nlsp [tag] metric metric-numberSyntax Description
tag
(Optional) Names the NLSP process. The tag can be any combination of printable characters.
metric-number
Metric value for the interface. It can be a number from 0 to 63.
Default
The default varies based on the throughput of the link connected to the interface.
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.3.
Use the ipx nlsp metric command to cause NLSP to prefer some links over others. A link with a lower metric is more preferable than one with a higher metric.
Typically, it is not necessary to configure the metric; however, it may be desirable in some cases when there are wide differences in link bandwidths. For example, using the default metrics, a single 64-kbps ISDN link will be preferable to two 1544-kbps T1 links.
Example
The following example configures a metric of 10 on serial interface 0:
interface serial 0ipx network 107ipx nlsp enableipx nlsp metric 10Related Commands
You can use the master indexes or search online to find documentation of related commands.
ipx nlsp multicast
To configure an interface to use multicast addressing, use the ipx nlsp multicast interface configuration command. To configure the interface to use broadcast addressing, use the no form of this command.
ipx nlsp [tag] multicast
no ipx nlsp [tag] multicastSyntax Description
Default
Multicast addressing is enabled.
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 11.3.
This command allows the router interface to use NLSP multicast addressing. If an adjacent neighbor does not support NLSP multicast addressing, the router will revert to using broadcasts on the affected interface.
The router will also revert to using broadcasts if multicast addressing is not supported by the hardware or driver.
Example
The following example disables multicast addressing on Ethernet interface 0:
interface ethernet0no ipx nlsp multicastipx nlsp priority
To configure the election priority of the specified interface for designated router election, use the ipx nlsp priority interface configuration command. To restore the default priority, use the no form of this command.
ipx nlsp [tag] priority priority-number
no ipx nlsp [tag] priority priority-numberSyntax Description
Default
44
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.3.
Use the ipx nlsp priority command to control which router is elected designated router. The device with the highest priority number is selected as the designated router.
The designated router increases its own priority by 20 in order to keep its state as of the designated router more stable. To have a particular router be selected as the designated router, configure its priority to be at least 65.
Example
The following example sets the designated router election priority to 65:
interface ethernet 0ipx network 101ipx nlsp enableipx nlsp priority 65ipx nlsp retransmit-interval
To configure the link-state packet (LSP) retransmission interval on WAN links, use the ipx nlsp retransmit-interval interface configuration command. To restore the default interval, use the no form of this command.
ipx nlsp [tag] retransmit-interval seconds
no ipx nlsp [tag] retransmit-interval secondsSyntax Description
Default
5 seconds
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.3.
This command sets the maximum amount of time that can pass before an LSP will be sent again (retransmitted) on a WAN link, if no acknowledgment is received.
Reducing the retransmission interval can improve the convergence rate of the network in the face of lost WAN links. The cost of reducing the retransmission interval is the potential increase in link utilization.
Example
The following example configures the LSP retransmission interval to 2 seconds:
ipx nlsp retransmit-interval 2Related Commands
You can use the master indexes or search online to find documentation of related commands.
ipx nlsp csnp-interval
ipx nlsp hello-intervalipx nlsp rip
To configure RIP compatibility when NLSP is enabled, use the ipx nlsp rip interface configuration command. To restore the default, use the no form of this command.
ipx nlsp [tag] rip [on | off | auto]
no ipx nlsp [tag] rip [on | off | auto]Syntax Description
Default
RIP periodic traffic is sent only if another router in sending periodic RIP traffic.
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.3.
The ipx nlsp rip command is meaningful only on networks on which NLSP is enabled. (RIP and SAP are always on by default on other interfaces.) Because the default mode is auto, no action is normally required to fully support RIP compatibility on an NLSP network.
Example
In the following example, the interface never generates or sends RIP periodic traffic:
interface ethernet 0ipx nlsp rip offRelated Commands
You can use the master indexes or search online to find documentation of related commands.
ipx nlsp sap
To configure SAP compatibility when NLSP in enabled, use the ipx nlsp sap interface configuration command. To restore the default, use the no form of this command.
ipx nlsp [tag] sap [on | off | auto]
no ipx nlsp [tag] sap [on | off | auto]Syntax Description
Default
SAP periodic traffic is sent only if another router in sending periodic SAP traffic.
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.3.
The ipx nlsp sap command is meaningful only on networks on which NLSP is enabled. Because the default mode is auto, no action is normally required to fully support SAP compatibility on an NLSP network.
Example
In the following example, the interface never generates or sends SAP periodic traffic:
interface ethernet 0ipx nlsp sap offRelated Commands
You can use the master indexes or search online to find documentation of related commands.
ipx output-gns-filter
To control which servers are included in the Get Nearest Server (GNS) responses sent by the Cisco IOS software, use the ipx output-gns-filter interface configuration command. To remove the filter from the interface, use the no form of this command.
ipx output-gns-filter {access-list-number | name}
no ipx output-gns-filter {access-list-number | name}Syntax Description
Default
No filters are predefined.
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.0.
You can issue only one ipx output-gns-filter command on each interface.
Example
The following example excludes the server at address 3c.0800.89a1.1527 from GNS responses sent on Ethernet interface 0, but allows all other servers:
access-list 1000 deny 3c.0800.89a1.1527access-list 1000 permit -1ipx routinginterface ethernet 0ipx network 2Bipx output-gns-filter 1000Related Commands
You can use the master indexes or search online to find documentation of related commands.
access-list (SAP filtering)
deny (SAP filtering)
ipx access-list
ipx gns-round-robin
permit (SAP filtering)ipx output-network-filter
To control the list of networks included in routing updates sent out an interface, use the ipx output-network-filter interface configuration command. To remove the filter from the interface, use the no form of this command.
ipx output-network-filter {access-list-number | name}
no ipx output-network-filter {access-list-number | name}Syntax Description
Default
No filters are predefined.
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.0.
The ipx output-network-filter command controls which networks the Cisco IOS software advertises in its IPX routing updates (RIP updates).
You can issue only one ipx output-network-filter command on each interface.
Example
In the following example, access list 896 controls which networks are specified in routing updates sent out the serial 1 interface. This configuration causes network 2b to be the only network advertised in Novell routing updates sent on the specified serial interface.
access-list 896 permit 2binterface serial 1ipx output-network-filter 896Related Commands
You can use the master indexes or search online to find documentation of related commands.
access-list (extended)
access-list (standard)
deny (extended)
deny (standard)
ipx access-list
ipx input-network-filter
ipx router-filter
permit (extended)
permit (standard)ipx output-rip-delay
To set the interpacket delay for RIP updates sent on a single interface, use the ipx output-rip-delay interface configuration command. To return to the default value, use the no form of this command.
ipx output-rip-delay delay
no ipx output-rip-delay [delay]Syntax Description
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.
Default
55 ms
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.0.
The interpacket delay is the delay between the individual packets sent in a multiple-packet routing update. The ipx output-rip-delay command sets the interpacket delay for a single interface.
The system uses the interpacket delay specified by the ipx output-rip-delay command for periodic and triggered routing updates when no delay is set for triggered routing updates. When you set a delay for triggered routing updates, the system uses the delay specified by the ipx output-rip-delay command for only the periodic routing updates sent on the interface.
To set a delay for triggered routing updates, see the ipx triggered-rip-delay or ipx default-triggered-rip-delay commands.
You can also set a default RIP interpacket delay for all interfaces. See the ipx default-output-rip-delay command for more information.
Novell recommends a delay of 55 ms for compatibility with older and slower IPX machines. These machines may lose RIP updates because they process packets more slowly than the router sends them. The delay imposed by this command forces the router to pace its output to the slower-processing needs of these IPX machines.
The default delay on a NetWare 3.11 server is about 100 ms.
This command is also useful on limited bandwidth point-to-point links or X.25 and Frame Relay multipoint interfaces.
Example
The following example establishes a 55-ms interpacket delay on serial interface 0:
interface serial 0ipx network 106Aipx output-rip-delay 55Related Commands
You can use the master indexes or search online to find documentation of related commands.
ipx default-output-rip-delay
ipx default-triggered-rip-delay
ipx triggered-rip-delay
ipx update sap-after-ripipx output-sap-delay
To set the interpacket delay for Service Advertising Protocol (SAP) updates sent on a single interface, use the ipx output-sap-delay interface configuration command. To return to the default delay value, use the no form of this command.
ipx output-sap-delay delay
no ipx output-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.
Default
55 ms
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.0.
The interpacket delay is the delay between the individual packets sent in a multiple-packet SAP update. The ipx output-sap-delay command sets the interpacket delay for a single interface.
The system uses the interpacket delay specified by the ipx output-sap-delay command for periodic and triggered SAP updates when no delay is set for triggered updates. When you set a delay for triggered updates, the system uses the delay specified by the ipx output-sap-delay command only for the periodic updates sent on the interface.
To set a delay for triggered updates, see the ipx triggered-sap-delay or ipx default-triggered-sap-delay commands.
You can also set a default SAP interpacket delay for all interfaces. See the ipx default-output-sap-delay command for more information.
Novell recommends a delay of 55 ms for compatibility with older and slower IPX servers. These servers may lose SAP updates because they process packets more slowly than the router sends them. The delay imposed by the ipx output-sap-delay command forces the router to pace its output to the slower-processing needs of these servers.
The default delay on a NetWare 3.11 server is about 100 ms.
This command is also useful on limited bandwidth point-to-point links or X.25 and Frame Relay multipoint interfaces.
Example
The following example establishes a 55-ms delay between packets in multiple-packet SAP updates on Ethernet interface 0:
interface ethernet 0ipx network 106Aipx output-sap-delay 55Related Commands
You can use the master indexes or search online to find documentation of related commands.
ipx default-output-sap-delay
ipx default-triggered-sap-delay
ipx linkup-request
ipx triggered-sap-delayipx output-sap-filter
To control which services are included in SAP updates sent by the Cisco IOS software, use the ipx output-network-filter interface configuration command. To remove the filter, use the no form of this command.
ipx output-sap-filter {access-list-number | name}
no ipx output-sap-filter {access-list-number | name}Syntax Description
Default
No filters are predefined.
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.0.
The Cisco IOS software applies output SAP filters prior to sending SAP packets.
You can issue only one ipx output-sap-filter command on each interface.
When configuring SAP filters for NetWare 3.11 and later servers, use the server's internal network and node number (the node number is always 0000.0000.0001) as its address in the SAP access-list command. Do not use the network.node address of the particular interface board.
Example
The following example denies service advertisements about server 0000.0000.0001 on network aa from being sent on network 4d (via Ethernet interface 1). All other services are advertised via this network. All services, included those from server aa.0000.0000.0001, are advertised via networks 3c and 2b.
access-list 1000 deny aa.0000.0000.0001access-list 1000 permit -1interface ethernet 0ipx network 3cinterface ethernet 1ipx network 4dipx output-sap-filter 1000interface serial 0ipx network 2bRelated Commands
You can use the master indexes or search online to find documentation of related commands.
access-list (SAP filtering)
deny (SAP filtering)
ipx access-list
ipx gns-round-robin
ipx input-sap-filter
ipx router-sap-filter
permit (SAP filtering)ipx pad-process-switched-packets
To control whether odd-length packets are padded so as to be sent as even-length packets on an interface, use the ipx pad-process-switched-packets interface configuration command. To disable padding, use the no form of this command.
ipx pad-process-switched-packets
no ipx pad-process-switched-packetsSyntax Description
This command has no arguments or keywords.
Default
Enabled on Ethernet interfaces
Disabled on Token Ring, FDDI, and serial interfacesCommand Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.0.
Use this command only under the guidance of a customer engineer or other service representative.
The ipx pad-process-switched-packets command affects process-switched packets only, so you must disable fast switching before the ipx pad-process-switched-packets command has any effect.
Some IPX end hosts reject Ethernet packets that are not padded. Certain topologies can result in such packets being forwarded onto a remote Ethernet network. Under specific conditions, padding on intermediate media can be used as a temporary workaround for this problem.
Example
The following example configures the Cisco IOS software to pad odd-length packets so that they are sent as even-length packets on FDDI interface 1.
interface fddi 1ipx network 2Ano ipx route-cacheipx pad-process-switched-packetsRelated Commands
You can use the master indexes or search online to find documentation of related commands.
ipx per-host-load-share
To enable per-host load sharing, use the ipx per-host-load-share global configuration command. To disable per-host load sharing, use the no form of the command.
ipx per-host-load-share
no ipx per-host-load-shareSyntax Description
This command has no arguments or keywords.
Default
Disabled
Command Mode
Global configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 11.1.
Use this command to enable per-host load sharing. Per-host load sharing transmits traffic across multiple, equal-cost paths while guaranteeing that packets for a given end host always take the same path.
When you do not enable per-host load sharing, the software uses a round-robin algorithm to accomplish load sharing. Round-robin load sharing transmits successive packets over alternate, equal-cost paths, regardless of the destination host. With round-robin load sharing, successive packets destined for the same end host might take different paths. Thus, round-robin load sharing increases the possibility that successive packets to a given end host might arrive out of order or be dropped, but ensures true load balancing of a given workload across multiple links.
In contrast, per-host load sharing decreases the possibility that successive packets to a given end host will arrive out of order; but, there is a potential decrease in true load balancing across multiple links. True load sharing occurs only when different end hosts utilize different paths; equal link utilization cannot be guaranteed.
With per-host load balancing, the number of equal-cost paths set by the ipx maximum-paths command must be greater than one; otherwise, per-host load sharing has no effect.
Example
The following command globally enables per-host load sharing:
ipx per-host-load shareRelated Commands
You can use the master indexes or search online to find documentation of related commands.
ipx ping-default
To select the ping type that the Cisco IOS software transmits, use the ipx ping-default global configuration command. To return to the default ping type, use the no form of this command.
ipx ping-default {cisco | novell}
no ipx ping-default {cisco | novell}Syntax Description
Default
Cisco pings
Command Mode
Global configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.3.
Standard Novell pings conform to the definition in the Novell NLSP specification.
Example
The following example enables standard Novell pings:
ipx ping-default novellRelated Commands
You can use the master indexes or search online to find documentation of related commands.
ipx rip-max-packetsize
To configure the maximum packet size of RIP updates sent out the interface, use the ipx rip-max-packetsize interface configuration command. To restore the default packet size, use the no form of this command.
ipx rip-max-packetsize bytes
no ipx rip-max-packetsize bytesSyntax Description
bytes
Maximum packet size in bytes. The default is 432 bytes, which allows for 50 routes at 8 bytes each, plus 32 bytes of IPX network and RIP header information.
Default
432 bytes
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.3.
The maximum size is for the IPX packet including the IPX network and RIP header information.
Do not allow the maximum packet size to exceed the allowed maximum size of packets for the interface.
Example
The following example sets the maximum RIP update packet to 832 bytes:
ipx rip-max-packetsize 832Related Commands
You can use the master indexes or search online to find documentation of related commands.
ipx rip-multiplier
To configure the interval at which a network's RIP entry ages out, use the ipx rip-multiplier interface configuration command. To restore the default interval, use the no form of this command.
ipx rip-multiplier multiplier
no ipx rip-multiplier multiplierSyntax Description
Default
Three times the RIP update interval
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.3.
All routers on the same physical cable should use the same multiplier value.
Example
In the following example, in a configuration where RIP updates are sent once every 2 minutes, the interval at which RIP entries age out is set to 10 minutes:
interface ethernet 0ipx rip-multiplier 5Related Commands
You can use the master indexes or search online to find documentation of related commands.
ipx route
To add a static route or static NLSP route summary to the routing table, use the ipx route global configuration command. To remove a route from the routing table, use the no form of this command.
ipx route {network [network-mask] | default} {network.node | interface} [ticks] [hops]
[floating-static]
no ipx routeSyntax Description
Default
No static routes are predefined.
Command Mode
Global configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.0. The following arguments and keywords first appeared in Cisco IOS 10.3: network-mask, default, interface, floating-static.
The ipx route command forwards packets destined for the specified network (network) via the specified router (network.node) or an interface (interface) on that network regardless of whether that router is sending dynamic routing information.
Floating static routes are static routes that can be overridden by dynamically learned routes. Floating static routes allow you to switch to another path whenever routing information for a destination is lost. One application of floating static routes is to provide back-up routes in topologies where dial-on-demand routing is used.
If you configure a floating static route, the Cisco IOS software checks to see if an entry for the route already exists in its routing table. If a dynamic route already exists, the floating static route is placed in reserve as part of a floating static route table. When the software detects that the dynamic route is no longer available, it replaces the dynamic route with the floating static route for that destination. If the route is later relearned dynamically, the dynamic route replaces the floating static route and the floating static route is again placed in reserve.
If you specify an interface instead of a network node address, the interface must be an IPXWAN unnumbered interface. For IPXWAN interfaces, the network number need not be preassigned; instead, the nodes may negotiate the network number dynamically.
Note that by default, floating static routes are not redistributed into other dynamic protocols.
Examples
In the following example, a router at address 3abc.0000.0c00.1ac9 handles all traffic destined for network 5e:
ipx routing ipx route 5e 3abc.0000.0c00.1ac9The following example defines a static NLSP route summary:
ipx routing ipx route aaaa0000 ffff0000Related Commands
You can use the master indexes or search online to find documentation of related commands.
ipx default-route
show ipx routeipx route-cache
To enable IPX fast switching, use the ipx route-cache interface configuration command. To disable fast switching, use the no form of this command.
ipx route-cache
no ipx route-cacheSyntax Description
This command has no arguments or keywords.
Default
Fast switching is enabled.
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.0.
Fast switching allows higher throughput by switching packets using a cache created by previous transit packets. Fast switching is enabled by default on all interfaces that support fast switching, including Token Ring, Frame Relay, PPP, SMDS, and ATM.
On ciscoBus-2 interface cards, fast switching is done between all encapsulation types. On other interface cards, fast switching is done in all cases except the following: transfer of packets with sap encapsulation from an Ethernet, a Token Ring, or an FDDI network to a standard serial line.
You might want to disable fast switching in two situations. One is if you want to save memory on the interface cards: fast-switching caches require more memory than those used for standard switching. The second situation is to avoid congestion on interface cards when a high-bandwidth interface is writing large amounts of information to a low-bandwidth interface.
Examples
The following example enables fast switching:
interface ethernet 0ipx route-cacheIn the following example, fast switching is turned off on an interface:
interface ethernet 0no ipx route-cacheRelated Commands
You can use the master indexes or search online to find documentation of related commands.
clear ipx cache
ipx source-network-update
ipx watchdog-spoof
show ipx cache
show ipx interfaceipx route-cache inactivity-timeout
To adjust the period and rate of route cache invalidation because of inactivity, use the ipx route-cache inactivity-timeout global configuration command. To return to the default values, use the no form of this command.
ipx route-cache inactivity-timeout period [rate]
no ipx route-cache inactivity-timeoutSyntax Description
Defaults
The default period is 2 minutes. The default rate is 0 (cache entries do not age).
Command Mode
Global configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.3.
IPX fast-switch cache entries that are not in use may be invalidated after a configurable period of time. If no new activity occurs, these entries will be purged from the route cache after one additional minute.
Cache entries that have been uploaded to the switch processor when autonomous switching is configured are always exempt from this treatment.
This command has no effect if silicon switching is configured.
Example
The following example sets the inactivity period to 5 minutes, and sets a maximum of 10 entries that can be invalidated per minute:
ipx route-cache inactivity-timeout 5 10Related Commands
You can use the master indexes or search online to find documentation of related commands.
clear ipx cache
ipx route-cache
ipx route-cache update-timeout
show ipx cacheipx route-cache max-size
To set a maximum limit on the number of entries in the IPX route cache, use the ipx route-cache max-size global configuration command. To return to the default setting, use the no form of this command.
ipx route-cache max-size size
no ipx route-cache max-sizeSyntax Description
Default
The default setting is no limit on the number of entries.
Command Mode
Global configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.3.
On large networks, storing too many entries in the route cache can use a significant amount of router memory, causing router processing to slow. This situation is most common on large networks that run network management applications for NetWare. If the network management station is responsible for managing all clients and servers in a very large (greater than 50,000 nodes) Novell network, the routers on the local segment can become inundated with route cache entries. The ipx route-cache max-size command allows you to set a maximum number of entries for the route cache.
If the route cache already has more entries than the specified limit, the extra entries are not deleted. However, all route cache entries are subject to being removed via the parameter set for route cache aging via the ipx route-cache inactivity-timeout command.
Example
The following example sets the maximum route cache size to 10,000 entries.
ipx route-cache max-size 10000Related Commands
You can use the master indexes or search online to find documentation of related commands.
ipx route-cache
ipx route-cache inactivity-timeout
ipx route-cache update-timeout
show ipx cacheipx route-cache update-timeout
To adjust the period and rate of route cache invalidation because of aging, use the ipx route-cache update-timeout global configuration command. To return to the default values, use the no form of this command.
ipx route-cache update-timeout period [rate]
no ipx route-cache update-timeoutSyntax Description
Default
The default setting is disabled.
Command Mode
Global configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 11.2.
IPX fast-switch cache entries that exceed a minimum age may be invalidated after a configurable period of time. Invalidation occurs unless the cache entry was marked as active during the last minute. Following invalidation, if no new activity occurs, these entries will be purged from the route cache after one additional minute.
This capability is primarily useful when autonomous switching or silicon switching is enabled. In both cases, activity is not recorded for entries in the route cache, because data is being switched by the Switch Processor (SP) or Silicon Switch Processor (SSP). In this case, it may be desirable to periodically invalidate a limited number of older cache entries each minute.
If the end hosts have become inactive, the cache entries will be purged after one additional minute. If the end hosts are still active, the route cache and autonomous or SSP cache entries will be revalidated instead of being purged.
Example
The following example sets the update timeout period to 5 minutes and sets a maximum of 10 entries that can be invalidated per minute:
ipx route-cache update-timeout 5 10Related Commands
You can use the master indexes or search online to find documentation of related commands.
clear ipx cache
ipx route-cache
ipx route-cache inactivity-timeout
show ipx cacheipx router
To specify the routing protocol to use, use the ipx router global configuration command. To disable a particular routing protocol on the router, use the no form of this command.
ipx router {eigrp autonomous-system-number | nlsp [tag] | rip}
no ipx router {eigrp autonomous-system-number | nlsp [tag] | rip}Syntax Description
Default
RIP is enabled.
Command Mode
Global configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.0. The nlsp keyword and tag argument first appeared in Cisco IOS Release 11.0.
You must explicitly disable RIP by issuing the no ipx router rip command if you do not want to use this routing protocol.
You can configure multiple Enhanced IGRP processes on a router. To do so, assign each a different autonomous system number.
Note
When you specify an NLSP tag, you configure the NLSP routing protocol for a particular NLSP process. An NLSP process is a router's databases working together to manage route information about an area. NLSP version 1.0 routers are always in the same area. Each router has its own adjacencies, link-state, and forwarding databases. These databases operate collectively as a single process to discover, select, and maintain route information about the area. NLSP version 1.1 routers that exist within a single area also use a single process.
NLSP version 1.1 routers that interconnect multiple areas use multiple processes to discover, select, and maintain route information about the areas they interconnect. These routers manage an adjacencies, link-state, and area address database for each area to which they attach. Collectively, these databases are still referred to as a process. The forwarding database is shared among processes within a router. The sharing of entries in the forwarding database is automatic when all processes interconnect NLSP version 1.1 areas.
Configure multiple NLSP processes when a router interconnects multiple NLSP areas.
Examples
The following example enables Enhanced IGRP:
ipx router eigrp 4The following example enables NLSP on process area1. This process handles routing for NLSP area 1.
ipx router nlsp area1Related Commands
You can use the master indexes or search online to find documentation of related commands.
ipx router-filter
To filter the routers from which packets are accepted, use the ipx router-filter interface configuration command. To remove the filter from the interface, use the no form of this command.
ipx router-filter {access-list-number | name}
no ipx router-filterSyntax Description
Default
No filters are predefined.
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.0.
You can issue only one ipx router-filter command on each interface.
Example
In the following example, access list 866 controls the routers from which packets are accepted. For Ethernet interface 0, only packets from the router at 3c.0000.00c0.047d are accepted. All other packets are implicitly denied.
access-list 866 permit 3c.0000.00c0.047dinterface ethernet 0ipx router-filter 866Related Commands
You can use the master indexes or search online to find documentation of related commands.
access-list (extended)
access-list (standard)
deny (extended)
deny (standard)
ipx access-list
ipx input-network-filter
ipx output-network-filter
permit (extended)
permit (standard)ipx router-sap-filter
To filter Service Advertising Protocol (SAP) messages received from a particular router, use the ipx router-sap-filter interface configuration command. To remove the filter, use the no form of this command.
ipx router-sap-filter {access-list-number | name}
no ipx router-sap-filter {access-list-number | name}Syntax Description
Default
No filters are predefined.
Command Mode
Interface configuration
Usage Guidelines
This command first appeared in Cisco IOS Release 10.0.
You can issue only one ipx router-sap-filter command on each interface.
Example
In the following example, the Cisco IOS software will receive service advertisements only from router aa.0207.0104.0874:
access-list 1000 permit aa.0207.0104.0874access-list 1000 deny -1interface ethernet 0ipx router-sap-filter 1000Related Commands
You can use the master indexes or search online to find documentation of related commands.
access-list (SAP filtering)
deny (SAP filtering)
ipx access-list
ipx input-sap-filter
ipx output-sap-filter
ipx sap
permit (SAP filtering)
show ipx interfaceipx routing
To enable IPX routing, use the ipx routing global configuration command. To disable IPX routing, use the no form of this command.
ipx routing [node]
no ipx routingSyntax Description
