|
|
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 Advertisement Protocol (SAP) to advertise special network services.
Our implementation of Novell's IPX protocol has been certified as providing full IPX router functionality. Our router connects Ethernet, Token Ring, and FDDI networks, either directly or through high-speed serial lines (56 kbps to T1 speeds), X.25, or Frame Relay. The Cisco X.25 and T1 support currently is not compatible with Novell. This means that our routers must be used on both ends of T1 and X.25 circuits.
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 Router Products Configuration Guide.
Note For all commands that previously had the keyword novell, this keyword has been changed to ipx. However, you can still use the keyword novell in all commands.
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.
No access lists are predefined.
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:
To delete the access list for a specific network, use the following command:
The following example denies access to traffic from all IPX networks (-1) to destination network 2:
The following example denies access to all traffic from IPX address 1.0000.0c00.1111:
The following example denies access from all nodes on network 1 that have a source address beginning with 0000.0c:
The following example denies access from source address 1111.1111.1111 on network 1 to destination address 2222.2222.2222 on network 2:
A dagger () indicates that the command is documented in another chapter.
access-list (extended)
ipx access-group
ipx input-network-filter
ipx output-network-filter
ipx router-filter
priority-list protocol
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.
Number of the access list. This is a decimal number from 900 to 999. |
|
Number of an IPX protocol type, in decimal. This also is sometimes referred to as the packet type. Table 20-1 in the "Usage Guidelines" section lists some IPX protocol numbers. |
|
(Optional) Number of the network from which the packet is being sent. This is an eight-digit hexadecimal number that uniquely identifies a network cable segment. It can be a number in the range 1 to FFFFFFFE. A network number of 0 matches the local network. A network number of -1 matches all networks. You do not need to specify leading zeros in the network number; for example, for the network number 000000AA, you can just enter AA. |
|
(Optional) Node on source-network from which the packet is being sent. This is a 48-bit value represented by a dotted triplet of four-digit hexadecimal numbers (xxxx.xxxx.xxxx). |
|
(Optional) Mask to be applied to source-network. This is an eight-digit hexadecimal mask. Place ones in the bit positions you want to mask. The mask must immediately be followed by a period, which must in turn immediately be followed by source-node-mask. |
|
(Optional) Mask to be applied to source-node. This is a 48-bit value represented as a dotted triplet of four-digit hexadecimal numbers (xxxx.xxxx.xxxx). Place ones in the bit positions you want to mask. |
|
Socket number from which the packet is being sent, in hexadecimal. Table 20-2 in the "Usage Guidelines" section lists some IPX socket numbers. |
|
(Optional) Number of the network to which the packet is being sent. This is an eight-digit hexadecimal number that uniquely identifies a network cable segment. It can be a number in the range 1 to FFFFFFFE. A network number of 0 matches the local network. A network number of -1 matches all networks. You do not need to specify leading zeros in the network number. For example, for the network number 000000AA, you can enter just AA. |
|
(Optional) Node on destination-network to which the packet is being sent. This is a 48-bit value represented by a dotted triplet of four-digit hexadecimal numbers (xxxx.xxxx.xxxx). |
|
(Optional) Mask to be applied to destination-network. This is an eight-digit hexadecimal mask. Place ones in the bit positions you want to mask. The mask must immediately be followed by a period, which must in turn immediately be followed by destination-node-mask. |
|
(Optional) Mask to be applied to destination-node. This is a 48-bit value represented as a dotted triplet of four-digit hexadecimal numbers (xxxx.xxxx.xxxx). Place ones in the bit positions you want to mask. |
|
(Optional) Socket number to which the packet is being sent, in hexadecimal. Table 20-2 in the "Usage Guidelines" section lists some IPX socket numbers. |
No access lists are predefined.
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 For some versions of NetWare, the protocol type field is not a reliable indicator of the type of packet encapsulated by the IPX header. In these cases, use the source and destination socket fields to make this determination. For additional information, contact Novell.
Table 20-1 lists some IPX protocol numbers. Table 20-2 lists some IPX socket numbers. For additional information about IPX protocol numbers and socket numbers, contact Novell.
Table 20-1 Some IPX Protocol Numbers
| IPX Protocol Number (Decimal) | Protocol (Packet Type) |
|---|---|
Could be any protocol; refer to the socket number to determine the packet type |
|
Table 20-2 Some IPX Socket Numbers
| IPX Socket Number (Hexadecimal) | Socket |
|---|---|
Dynamic sockets; used by workstations for interaction with file servers and other network servers |
|
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:
To delete the access list for a specific protocol, use the following command:
The following example denies access to all RIP packets (protocol number 1) from socket 453 (RIP process socket) on source network 1 that are destined for socket 453 on network 2. It permits all other traffic.
The following example permits type 2 packets from any socket on network 10 to access any sockets on any nodes on networks 1000 through 100F. It denies all other traffic (with an implicit deny all):
Note This type is chosen only as an example. The actual type to use depends on the specific application.
A dagger () indicates that the command is documented in another chapter.
access-list (standard)
ipx access-group
ipx input-network-filter
ipx output-network-filter
ipx router-filter
priority-list protocol
To define an access list for filtering Service Advertisement 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.
Number of the SAP access list. This is a decimal number from 1000 to 1099. |
|
Network number. This is an eight-digit hexadecimal number that uniquely identifies a network cable segment. It can be a number in the range 1 to FFFFFFFE. A network number of 0 matches the local network. A network number of -1 matches all networks. You do not need to specify leading zeros in the network number. For example, for the network number 000000AA, you can enter just AA. |
|
(Optional) Node on network. This is a 48-bit value represented by a dotted triplet of four-digit hexadecimal numbers (xxxx.xxxx.xxxx). |
|
(Optional) Mask to be applied to network and node. Place ones in the bit positions to be masked. |
|
(Optional) Service type on which to filter. This is a hexadecimal number. A value of 0 means all services. Table 20-3 in the "Usage Guidelines" section lists examples of service types. |
|
(Optional) Name of the server providing the specified service type. This can be any contiguous string of printable ASCII characters. Use double quotation marks (" ") to enclose strings containing embedded spaces. You can use an asterisk (*) at the end of the name as a wildcard to match one or more trailing characters. |
No access lists are predefined.
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.
Table 20-3 lists some sample IPX SAP types. For more information about SAP types, contact Novell.
Table 20-3 Sample IPX SAP Services
| Service Type (Hexadecimal) | Description |
|---|---|
NetWare management (Novell's Network Management Station [NMS]) |
|
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:
To delete the access list for a specific network, use the following command:
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:
A dagger () indicates that the command is documented in another chapter.
ipx input-sap-filter
ipx output-gns-filter
ipx output-sap-filter
ipx router-sap-filter
priority-list protocol
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.
No area address is defined by default.
You must configure at least one area address before NLSP will operate.
The area-address command defines a prefix that includes all networks that are 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.
The following example defines an area address that includes networks AAAABBC0 through AAAABBDF:
The following example defines an area address that includes all networks:
ipx router nlsp
To delete all entries in the accounting database when IPX accounting is enabled, use the clear ipx accounting EXEC command.
Specifying the clear ipx accounting command with no keywords deletes all entries in the active database.
You can also delete all entries in the checkpointed database by issuing the clear ipx accounting command twice in succession.
The following example clears all entries in the active database:
ipx accounting
ipx accounting-list
ipx accounting-threshold
ipx accounting-transits
show ipx accounting
To delete entries from the IPX fast-switching cache, use the clear ipx cache EXEC command.
This command has no arguments or keywords.
The clear ipx cache command clears entries used for fast switching, autonomous switching, and SSE fast switching.
The following example deletes all entries from the IPX fast-switching cache:
To delete all NLSP adjacencies from the router's adjacency database, use the clear ipx nlsp neighbors EXEC command.
This command has no arguments or keywords.
Deleting all entries from the adjacency database forces all routers in the area to perform the shortest path first (SPF) calculation.
The following example deletes all NLSP adjacencies from the router's adjacency database:
To delete routes from the IPX routing table, use the clear ipx route EXEC command.
The following example clears the entry for network 3 from the IPX routing table:
To have the Cisco 7000 series route processor recompute the entries in the IPX SSE fast-switching cache, use the clear ipx sse EXEC command.
This command has no arguments or keywords.
Recomputing the entries in the RP's SSE fast-switching cache also updates the SSP's fast-switching cache.
The following example recomputes the entries in the IPX SSE fast-switching cache:
To reinitialize the route processor on the Cisco 7000 series, use the clear sse EXEC command.
This command has no arguments or keywords.
The silicon switching engine (SSE) is on the Silicon Switch Processor (SSP) board in the Cisco 7000 series.
The following example causes the route processor to be reinitialized:
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.
The following example causes only two networks—network 2 and network 3—to be accepted by an Enhanced IGRP routing process:
access-list (standard)
distribute-list out
redistribute
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.
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.
The following example causes only one network—network 3—to be advertised by an Enhanced IGRP routing process:
access-list (standard)
distribute-list in
redistribute
To apply a generic output filter to an interface, use ipx access-group interface configuration command. To remove the access list, use the no form of this command.
Generic filters control which packets are sent out an interface 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 generic filter to an interface.
In the following example, access list 801 is applied to Ethernet interface 1:
A dagger () indicates that the command is documented in another chapter.
access-list (standard)
access-list (extended)
priority-list protocol
To enable IPX accounting, use the ipx accounting interface configuration command. To disable IPX accounting, use the no form of this command.
This command has no arguments or keywords.
IPX accounting allows you to collect information about IPX packets and the number of bytes that are switched through the router. You collect information based on the source and destination IPX address. Accounting tracks only IPX traffic that is passing out of the router; it does not track traffic generated by or terminating at the router.
IPX accounting statistics will be accurate even if IPX fast switching is enabled or if IPX access lists are being used. However, IPX accounting does not keep statistics if autonomous switching is enabled.
The router software maintains two accounting databases, an active database and a checkpointed database.
The following example enables IPX accounting on Ethernet interface 0:
clear ipx accounting
ipx accounting-list
ipx accounting-threshold
ipx accounting-transits
show ipx accounting
To filter the 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.
The source and destination addresses of each IPX packet are logically ANDed with the mask and compared with the network number. If there is a match, accounting information about the IPX packet is entered into the 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.
The following example adds all networks with IPX network numbers beginning with 1 to the list of networks for which accounting information is kept:
clear ipx accounting
ipx accounting
ipx accounting-threshold
ipx accounting-transits
show ipx accounting
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.
The accounting threshold defines the maximum number of entries (source and destination address pairs) that the router 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, used the show ipx accounting EXEC command.
The following example sets the IPX accounting database threshold to 500 entries:
clear ipx accounting
ipx accounting
ipx accounting-list
ipx accounting-transits
show ipx accounting
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.
Transit entries are those that do not match any of the filters specified by ipx accounting-list global configuration commands. If you have not defined any filters, no transit entries are possible.
To maintain accurate accounting totals, the router software maintains two accounting databases: an active database and a checkpointed database.
The following example specifies a maximum of 100 transit records to be stored in the IPX accounting database:
clear ipx accounting
ipx accounting
ipx accounting-list
ipx accounting-threshold
show ipx accounting
To advertise only the default route via the specified network, use the ipx advertise-default-route-only interface configuration command. To advertise all known routes out the interface, use the no form of this command.
Disabled; that is, all known routes are advertised out the interface.
If you specify the ipx advertise-default-route-only command, only the default route, if known, will be 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 1000 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 1000 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.
Note Services are not considered to be reachable via the default route. They are not added to the service table unless an explicit route to the server's network is known. Therefore, do not specify the ipx advertise-default-route-only command if you want services advertised via this interface.
Note Not all routers recognize and support the default route. Use this command with caution if you are not sure if all routers in your network support the default route.
The following example enables the advertising of the default route only:
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.
A lower interval may use more CPU resources, but may cause lost server information to be retrieved from other servers' tables sooner.
The following example changes the server query time to 5 seconds:
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.
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.
The following example allows Enhanced IGRP to use up to 75 percent (42 kbps) of a 56 kbps serial link in autonomous system 209.
bandwidth
ipx router
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.
This command has no arguments or keywords.
The default behavior is to process-switch directed broadcast packets.
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.
The following example enables the router to fast switch IPX directed broadcast packets:
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.
With Cisco IOS Release 10.0 and Release 10.2, the default delay is 0 ms (that is, no additional delay between routing update packets). With Cisco IOS Release 10.3, the default delay is 5 ms.
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.
The following example sets a default interpacket delay of 55 ms for RIP updates sent on all interfaces:
ipx default-triggered-rip-delay
ipx output-rip-delay
ipx triggered-rip-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.
With Cisco IOS Release 10.0 and Release 10.2, the default delay is 0 ms (that is, no additional delay between update packets). With Cisco IOS Release 10.3, the default delay is 5 ms.
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.
The following example sets a default interpacket delay of 55 ms for SAP updates sent on all interfaces:
ipx default-triggered-sap-delay
ipx output-sap-delay
ipx triggered-sap-delay
To forward towards the default network, if known, all packets for which a route to the destination network is unknown, use the ipx default-route global configuration command. To discard all packets for which a route to the destination network is unknown, use the no form of this command.
This command has no arguments or keywords.
Enabled; that is, all packets for which a route to the destination is unknown are forwarded towards the default network, which is -2 (0xFFFFFFFE).
The following example disables the forwarding of packets towards the default network:
ipx advertise-default-route-only
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.
With Cisco IOS Release 10.0 and Release 10.2, the default delay is 0 ms (that is, no additional delay between routing update packets). With Cisco IOS Release 10.3, the default delay is 5 ms.
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 broadcast-fastswitching command for triggered routing updates.
If the delay value set by the ipx output-rip-delay or ipx broadcast-fastswitching command is high, then we strongly recommend a low delay value for triggered routing updates so that updates triggered by special events are sent in a more timely manner than periodic routing updates.
Novell recommends a delay of 55 ms for compatibility with older and slower IPX machines. These machines may lose RIP updates because they process packets more slowly than the router sends them. The delay imposed by this command forces the router to pace its output to the slower-processing needs of these IPX machines.
The default delay on a NetWare 3.11 server is about 100 ms.
When you do not set the interpacket delay for triggered routing updates, the system uses the delay specified by the ipx output-rip-delay or ipx broadcast-fastswitching 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 broadcast-fastswitching 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.
The following example sets an interpacket delay of 55 ms for triggered routing updates sent on all interfaces:
ipx broadcast-fastswitching
ipx output-rip-delay
ipx triggered-rip-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.
With Cisco IOS Release 10.0 and Release 10.2, the default delay is 0 ms (that is, no additional delay between update packets). With Cisco IOS Release 10.3, the default delay is 5 ms.
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 about 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.
The following example sets an interpacket delay of 55 ms for triggered SAP updates sent on all interfaces:
ipx default-output-sap-delay
ipx output-sap-delay
ipx triggered-sap-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.
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.
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. Therefore, the ipx delay command has no effect.
Leaving the delay at its default value is sufficient for most interfaces.
The following example changes the delay for serial interface 0 to 10 ticks:
A dagger () indicates that the command is documented in another chapter.
delay
ipx maximum-paths
ipx output-network-filter
ipx output-rip-delay
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.
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.
The following example administratively shuts down network AA on Ethernet interface 0:
To disable the sending of replies to IPX GNS queries, use the ipx gns-reply-disable interface configuration command. To return to the default, use the no form of this command.
This command has no arguments or keywords.
Replies are sent to IPX GNS queries.
The following example disables the sending of replies to GNS queries on Ethernet interface 0:
To change the delay when responding to Get Nearest Server (GNS) requests, use the ipx gns-response-delay global configuration command. To return to the default delay, use the no form of this command.
A delay in responding to Get Nearest Server requests might be imposed so that in certain topologies any local Novell IPX servers respond to the GNS requests before our router 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. 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 milliseconds 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.
The following example sets the delay in responding to GNS requests to 500 milliseconds (0.5 second):
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.
The command has no arguments or keywords.
The most recently learned, eligible server is used.
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 router maintains a list of the nearest servers eligible to provide specific services. It uses this list when responding to Get Nearest Server (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.
The following example responds to GNS requests using a round-robin selection method from a list of eligible nearest servers:
ipx output-gns-filter
ipx output-sap-delay
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.
If the current value for the hold time is less than two times the interval between hello packets, the hold time will be reset.
The following example changes the hello interval to 10 seconds:
To forward broadcast packets (except type 20 propagation packets) to a specified server, use the ipx helper-address interface configuration command. To disable this function, use the no form of this command.
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 (except type 20 propagation packets). 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.
Note that type 20 propagation packet handling is controlled by a separate mechanism. See the discussion of the ipx type-20-propagation command for more information.
You can specify multiple ipx helper-address commands on a given interface.
Our routers support 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:
On systems configured for IPX routing, this helper address is displayed as follows (via the
show ipx interface command):
Although our routers take 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.
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:
ipx helper-list
ipx type-20-propagation
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.
No access list is preassigned.
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.
You should filter IPX broadcasts on dial-on-demand routing (DDR) and other similar interfaces, because IPX sends broadcast messages very regularly.
The following example assigns access list 900 to Ethernet interface 0 to control broadcast traffic:
access-list (standard)
access-list (extended)
ipx helper-address
ipx type-20-propagation
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.
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.
The following example changes the hold-down time for autonomous system 4 to 45 seconds:
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.
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 following example changes the hold time to 45 seconds:
To control which networks are added to the router'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.
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.
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.
The following example is a variation of the preceding that explicitly denies network 1a and explicitly allows updates for all other networks:
access-list (standard)
access-list (extended)
ipx output-network-filter
ipx router-filter
To control which services are added to the router's SAP table, use the ipx input-sap-filter interface configuration command. To remove the filter, use the no form of this command.
The ipx input-sap-filter command filters all incoming service advertisements received by the router. This is done prior to a router's 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.
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 (SAP filtering)
ipx output-sap-filter
ipx router-sap-filter
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.
No internal network number is set.
An internal network number is a number assigned to the router.
You must configure an internal network number on each router on an NLSP-capable network in order for NLSP to operate.
When you set an internal network number, the router advertises the specified network out all interfaces. It accepts packets destined to that network at the address internal-network.0000.0000.0001.
The following example assigns internal network number e001 to the local router:
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.
(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 router with the higher number is determined to be the link master. A value of 0 causes the router to use the configured internal 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 just enter AA. |
|
(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. |
|
(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). |
|
(Optional) Retry interval, in seconds. This interval defines how often the router 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 through 600. The default is 20 seconds. |
|
(Optional) Maximum number of times the router 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. |
If you enable IPXWAN, the default is unnumbered.
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 write terminal EXEC command does not show the 0 but rather reports this value as "unnumbered."
The name of each router 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, Ethernet 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.
The following example enables IPXWAN on serial interface 0:
A dagger () indicates that the command is documented in another chapter.
encapsulation ppp
hostname
ipx delay
ipx internal-network
ipx ipxwan error
ipx ipxwan static
ipx network
show ipx interface
To define how to handle IPXWAN when a serial link fails, use the ipx ipxwan error interface configuration command. To restore the default, use the no form of this command.
Use the ipx ipxwan error command to define what action to take if the IPXWAN start-up negotiation fails.
In the following example, the serial link will be shut down if the IPXWAN start-up negotiation fails after three attempts spaced 20 seconds apart:
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.
This command has no arguments or keywords.
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 for static routing, the link will not initialize.
The following example enables static routing with IPXWAN:
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.
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.
The following example sets the link delay to 20 microseconds:
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.
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 router never advertises any network with a hop count greater than 15. However, using protocols other than RIP, the router might learn routes that are farther away than 15 hops. The ipx maximum-hops command defines the maximum number of hops that the router will accept as reachable, as well as the maximum number of hops that an IPX packet can traverse before it is dropped by the router. Also, the router will respond to a specific RIP request for a network that is reachable at a distance of greater than 15 hops.
The following command configures the router to accept routes that are up to 64 hops away:
To set the maximum number of equal-cost paths the router uses when forwarding packets, use the ipx maximum-paths global configuration command. To restore the default value, use the no form of this command.
The ipx maximum-paths command is designed to increase throughput by allowing the router to choose among several equal-cost, parallel paths. (Note that when paths have differing costs, the router chooses lower-cost routes in preference to higher-cost routes.) IPX does 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 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.
In the following example, the router uses up to three parallel paths:
To control incoming IPX NetBIOS messages, use the ipx netbios input-access-filter interface configuration command. To remove the filter, use the no form of this command.
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 packets. They have no effect on LLC2 NetBIOS packets.
The following example filters packets arriving on Token Ring interface 1 using the NetBIOS access list "engineering":
ipx netbios output-access-filterr
netbios access-list
show ipx interface
To control outgoing NetBIOS messages, use the ipx netbios output-access-filter interface configuration command. To remove the filter, use the no form of this command.
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 packets. They have no effect on LLC2 NetBIOS packets.
The following example filters packets leaving Token Ring interface 1 using the NetBIOS access list "engineering":
ipx netbios input-access-filter
netbios access-list
show ipx interface
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.
Encapsulation types:
For Ethernet: novell-ether
For Token Ring: sap
For FDDI: snap
The ipx network command allows you to configure 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. You can also use this command to configure a single logical network on a physical network. NLSP does not support secondary networks. You must use subinterfaces in order to use multiple encapsulations with NLSP.
Note When enabling NLSP and configuring multiple encapsulations on the same physical LAN interface, you must use subinterfaces. You cannot use secondary networks.
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:
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.
To delete a secondary network on an interface, use one of the following commands. The argument number is the number of a secondary network.
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.
The following example uses primary and secondary networks to create the same four logical networks as shown earlier 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.
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.
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.
The following example configures Ethernet interface 0 to transmit CSNPs every 10 seconds:
ipx nlsp hello-interval
ipx nlsp retransmit-interval
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.
This command has no arguments or keywords.
NLSP is disabled on all interfaces.
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.
The following example enables NLSP routing on Ethernet interface 0:
The following example enables NLSP routing on serial interface 0:
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.
10 seconds for the designated router
20 seconds for nondesignated routers
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 is detected. A router is declared to be down if a hello has not been received from it for three times the hello interval (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.
The following example configures serial interface 0 to transmit hello packets every 30 seconds:
ipx nlsp csnp-interval
ipx nlsp retransmit-interval
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.
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.
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.
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.
The default varies based on the throughput of the link connected to the interface.
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.
The following example configures a metric of 10 on serial interface 0:
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.
Use the ipx nlsp priority command to control which router is elected designated router. The router 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 elected designated router, configure its priority to be at least 65.
The following example sets the designated router election priority to 65:
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.
Reducing the retransmission interval can improve the rate of convergence of the network in the face of lossy WAN links at the cost of potentially increasing link utilization.
The following example configures the LSP retransmission interval to 2 seconds:
ipx nlsp csnp-interval
ipx nlsp hello-interval
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.
RIP periodic traffic is sent only if another router in sending periodic RIP traffic.
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.
In the following example, the interface never generates or sends RIP periodic traffic:
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.
SAP periodic traffic is sent only if another router in sending periodic SAP traffic.
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.
In the following example, the interface never generates or sends SAP periodic traffic:
To control which servers are included in the Get Nearest Server (GNS) responses sent by the router, use the ipx output-gns-filter interface configuration command. To remove the filter from the interface, use the no form of this command.
You can issue only one ipx output-gns-filter command on each interface.
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 (SAP filtering)
ipx gns-round-robin
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.
The ipx output-network-filter command controls which networks the router advertises in its IPX routing updates (RIP updates).
You can issue only one ipx output-network-filter command on each interface.
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 (standard)
access-list (extended)
ipx input-network-filter
ipx router-filter
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.
With Cisco IOS Release 10.0 and Release 10.2, the default delay is 0 ms (that is, no additional delay between routing update packets). With Cisco IOS Release 10.3, the default delay is 5 ms.
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 broadcast-fastswitching 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.
The following example establishes a 55-ms interpacket delay on serial interface 0:
ipx update-time
ipx broadcast-fastswitching
ipx default-triggered-rip-delay
ipx triggered-rip-delay
To set the interpacket delay for 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.
With Cisco IOS Release 10.0 and Release 10.2, the default delay is 0 ms (that is, no additional delay between update packets). With Cisco IOS Release 10.3, the default delay is 5 ms.
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.
The following example establishes a 55-ms delay between packets in multiple-packet SAP updates on Ethernet interface 0:
ipx default-output-sap-delay
ipx default-triggered-sap-delay
ipx sap-interval
ipx triggered-sap-delay
To control which services are included in Service Advertisement Protocol (SAP) updates sent by the router, use the ipx output-network-filter interface configuration command. To remove the filter, use the no form of this command.
The router 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.
The following example denies service advertisements about server 0000.0000.0001 on network aa from being send 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 (SAP filtering)
ipx gns-round-robin
ipx input-sap-filter
ipx router-sap-filter
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.
This command has no arguments or keywords.
Enabled on Ethernet interfaces
Disabled on Token Ring, FDDI, and serial interfaces.
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.
To select the ping type that the router transmits, use the ipx ping-default global configuration command. To return to the default ping type, use the no form of this command.
Standard Novell pings conform to the definition in the Novell NLSP specification.
The following example enables standard Novell pings:
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.
The maximum size is for the IPX packet excluding the media header.
Do not allow the maximum packet size to exceed the allowed maximum size of packets for the interface.
The following example sets the maximum RIP update packet to 832 bytes:
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.
Three times the RIP update interval.
All routers on the same physical cable should use the same multiplier value.
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:
To add a static route 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.
No static routes are predefined.
The ipx route command forwards packets destined for the specified network (network) via the specified router (network.node), regardless of whether that router is sending dynamic routing information.
Be careful when assigning static routes. When links associated with static routes are lost, traffic may stop being forwarded, even though alternative paths might be available.
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 router 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 router 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.
Note that by default, floating static routes are not redistributed into other dynamic protocols.
In the following example, the router at address 3abc.0000.0c00.1ac9 handles all traffic destined for network 5e:
ipx default-route
show ipx route
To enable IPX fast switching and autonomous switching, use the ipx route-cache interface configuration command. To disable fast switching, use the no form of this command.
Fast switching is enabled.
Autonomous switching is disabled.
SSE switching is disabled.
Specifying the ipx route-cache command with no keywords enables fast switching.
Fast switching allows higher throughput by switching packets using a cache created by previous transit packets. 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.
Autonomous switching provides faster packet switching by allowing the ciscoBus processor to switch packets independently without having to interrupt the system processor. It is available only in Cisco 7000 systems, and in AGS+ systems with high-speed network controller ciscoBus2-only interfaces, such as the CCTL2 ciscoBus controller running microcode version 11.0 or later.
Autonomous switching is supported to and from all encapsulation types that you can use on IEEE interfaces; it is also supported to and from serial HDLC encapsulation. Table 20-4 lists the encapsulation types you can use on IEEE interfaces and shows the correspondence between the encapsulation type and the IPX frame type.
Table 20-4 Novell IPX Encapsulation Types on IEEE Interfaces
| Interface Type | Encapsulation Type | IPX Frame Type |
|---|---|---|
SSE fast switching uses the silicon switching engine (SSE) on the Cisco 7000 Series SSP card to perform packet switching.
The following example enables fast switching and autonomous switching on an interface:
The following example enables fast switching and SSE fast switching on an interface:
In the following example, both fast switching and autonomous switching are turned off on an interface:
Assuming that Ethernet 0 has ipx route-cache and ipx route-cache cbus is enabled, the following example turns off only autonomous switching on an interface, but leaves fast switching enabled:
clear ipx cache
ipx source-network-update
ipx watchdog-spoof
show ipx cache
To specify the routing protocol to use, use the ipx router global configuration command.
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.
The following example enables Enhanced IGRP on the router:
To control 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.
You can issue only one ipx router-filter command on each interface.
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 (standard)
access-list (extended)
ipx input-network-filter
ipx output-network-filter
To filter Service Advertisement Point (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.
You can issue only one ipx router-sap-filter command on each interface.
In the following example, the router will receive service advertisements only from router aa.0207.0104.0874:
access-list (SAP filtering)
ipx input-sap-filter
ipx output-sap-filter
ipx sap
show ipx interface
To enable IPX routing, use the ipx routing global configuration command. To disable IPX routing, use the no form of this command.
The ipx routing command enables the IPX Routing Information Protocol (RIP) and Service Advertisement Point (SAP) services on the router.
If you omit the argument node and if the MAC address later changes, the IPX node address automatically changes to the new address. However, connectivity may be lost between the time that the MAC address changes and the time that the IPX clients and servers learn the router's new address.
If you plan to use DECnet and IPX routing concurrently on the same interface, you should enable DECnet router first, then enable IPX routing without specifying the optional MAC node number. If you enable IPX before enabling DECnet routing, routing for IPX will be disrupted.
The following example enables IPX routing:
To specify static Service Advertisement Protocol (SAP) entries, use the ipx sap global configuration command. To remove static SAP entries, use the no form of this command.
SAP service-type number. Table 20-3 earlier in this chapter lists some IPX SAP services. |
|
Network number and node address of the server. The argument network is an eight-digit hexadecimal number that uniquely identifies a network cable segment. It can be a number in the range 1 to FFFFFFFD. You do not need to specify leading zeros in the network number. For example, for the network number 000000AA you can enter just AA. The argument node is the node number of the target Novell server. This is a 48-bit value represented by a dotted triplet of four-digit hexadecimal numbers (xxxx.xxxx.xxxx). |
|
Socket number for this service. Table 20-2 earlier in this chapter lists some IPX socket numbers. |
|
The ipx sap command allows you to add static entries into the SAP table. Each entry has a SAP service associated with it. Static SAP assignments always override any identical entries in the SAP table that are learned dynamically, regardless of hop count. The router will not announce a static SAP entry unless it has a route to that network.
In the following example, the route to JOES_SERVER is not yet learned, so the system displays an informational message. The JOES_SERVER service will not be announced in the regular SAP updates until the router learns the route to it either by means of a RIP update from a neighbor or an ipx sap command.
ipx input-sap-filter
ipx output-sap-filter
ipx router-sap-filter
show ipx servers
To send SAP updates only when a change occurs in the SAP table, use the ipx sap-incremental interface configuration command. To send periodic SAP updates, use the no form of this command.
Enabled on serial interfaces
Disabled on LAN media (Ethernet, Token Ring, FDDI)
In order to use the ipx sap-incremental command, you must enable Enhanced IGRP on the router. This is the case even if you want to use only RIP routing. You must do this because the incremental SAP feature requires the Enhanced IGRP reliable transport mechanisms.
With this functionality enabled, if an IPX Enhanced IGRP peer is found on the interface, SAP updates will be sent only when a change occurs in the SAP table. Periodic SAP updates are not sent. When no IPX Enhanced IGRP peer is present on the interface, periodic SAPs are always sent regardless of how this command is set.
If you configure the local router to send incremental SAP updates on an Ethernet, and if the local router has at least one IPX Enhanced IGRP neighbor and any servers, clients, or routers that do not have IPX Enhanced IGRP configured on the Ethernet interface, these devices will not receive complete SAP information from the local router.
If the incremental sending of SAP updates on an interface is configured and no IPX Enhanced IGRP peer is found, SAP updates will be sent periodically until a peer is found. Then, updates will be sent only when changes occur in the SAP table.
To take advantage of Enhanced IGRP's incremental SAP update mechanism while using the RIP routing protocol instead of the Enhanced IGRP routing protocol, specify the rsup-only keyword. SAP updates are then sent only when changes occur, and only changes are sent. Use this feature only when you want to use RIP routing.
The following example sends SAP updates on Ethernet interface 0 only when there is a change in the SAP table:
To configure less frequent Service Advertisement Point (SAP) updates over slow links, use the ipx sap-interval interface configuration command. To return to the default value, use the no form of this command.
Setting the interval at which SAP updates are sent is most useful on limited-bandwidth, point-to-point links or on X.25 interfaces.
You should ensure that all IPX servers and routers on a given network have the same SAP interval. Otherwise, they may decide that a server is down when it is really up.
It is not possible to change the interval at which SAP updates are sent on most PC-based servers. This means that you should never change the interval for an Ethernet or Token Ring network that has servers on it.
Setting the interval to zero means that periodic SAP updates are never sent. It is recommended that you never do this. If you set the interval to zero, routers that are inaccessible for any reason when a server powers up or shuts down will miss that event, and will either fail to learn about new servers or fail to detect that the server shut down.
In the following example, SAP updates are sent (and expected) on serial interface 0 every 5 minutes:
To configure the maximum packet size of SAP updates sent out the interface, use the ipx sap-max-packetsize interface configuration command. To restore the default packet size, use the no form of this command.
The maximum size is for the IPX packet excluding the media header. For example, to allow ten servers per SAP packet, you would configure (32 + (10 x 64)), or 672 bytes for the maximum packet size.
You are responsible for guaranteeing that the maximum packet size does not exceed the allowed maximum size of packets for the interface.
The following examples sets the maximum SAP update packet size to 672 bytes:
To configure the interval at which a network's or server's SAP entry ages out, use the ipx sap-multiplier interface configuration command. To restore the default interval, use the no form of this command.
Three times the SAP update interval.
All routers on the same physical cable should use the same multiplier value.
In the following example, in a configuration where SAP updates are sent once every 1 minute, the interval at which SAP entries age out is set to 10 minutes:
To configure the maximum length of the queue of pending input SAP GNS requests and SAP query packets, use the ipx sap-queue-maximum global configuration command. To return to the default value, use the no form of this command.
The router maintains a list of SAP requests to process, including all pending Get Nearest Server (GNS) queries from clients attempting to reach servers. When the network is restarted, the router can be inundated with hundreds of requests for servers. Most of these can be repeated requests from the same clients. The ipx sap-queue-maximum command allows you to configure the maximum length allowed for the pending SAP requests queue. Packets received when the queue is full are dropped.
The following example sets the length of the queue of pending SAP requests to 20:
To repair corrupted network numbers, use the ipx source-network-update interface configuration command. To disable this feature, use the no form of this command.
This command has no arguments or keywords.
In some early implementations of IPX client software, it was possible for the client's network number to become corrupted. The ipx source-network-update command repairs this number by setting the source network field of any packet on the local network that has a hop count of zero.
You must disable fast switching with the no ipx route-cache command before using the ipx source-network-update command.
This command interferes with the proper working of OS/2 Requestors. Therefore, do not use this command in a network that has OS/2 Requestors.
Do not use the ipx source-network-update command on interfaces on which NetWare servers are using internal network numbers.
 | Caution The ipx source-network-update command interferes with the proper working of OS/2 Requestors. Do not use this command in a network that has OS/2 Requestors. |
 | Caution Do not use the ipx source-network-update command on interfaces on which NetWare (NetWare 3.1x or 4.0 or later) Servers are using internal network numbers. |
In the following example, corrupted network numbers on serial interface 0 are repaired:
To configure split horizon, use the ipx split-horizon eigrp interface configuration command. To disable split horizon, use the no form of this command.
When split horizon is enabled, Enhanced IGRP update and query packets are not sent for destinations that have next hops on this interface. This reduces the number of Enhanced IGRP packets on the network.
Split horizon blocks information about routes from being advertised by a router out any interface from which that information originated. This behavior usually optimizes communication among multiple routers, particularly when links are broken. However, with nonbroadcast networks, such as Frame Relay and SMDS, situations can arise for which this behavior is less than ideal. For these situations, you may wish to disable split horizon.
The following example disables split horizon on serial interface 0:
To configure the throughput, use the ipx throughput interface configuration command. To restore the default throughput, use the no form of this command.
No default throughput is defined.
The value you specify with the ipx throughput command overrides the value measured by IPXWAN when it starts. This value is also supplied to NLSP for use in its metric calculations.
The following example changes the throughput to 1000000 bits per second:
To set the interpacket delay for triggered RIP updates sent on a single interface, use the ipx triggered-rip-delay interface configuration command. To return to the default delay, use the no form of this command.
With Cisco IOS Release 10.0 and Release 10.2, the default delay is 0 ms (that is, no additional delay between routing update packets). With Cisco IOS Release 10.3, the default delay is 5 ms.
The interpacket delay is the delay between the individual packets sent in a multiple-packet routing update. A triggered routing update is one that the system sends in response to a "trigger" event, such as a request packet, interface up/down, route up/down, or server up/down.
The ipx triggered-rip-delay command sets the interpacket delay for triggered routing updates sent on a single interface. The delay value set by this command overrides the delay value set by the ipx output-rip-delay or ipx broadcast-fastswitching command for triggered routing updates sent on the interface.
If the delay value set by the ipx output-rip-delay or ipx broadcast-fastswitching command is high, then we strongly recommend a low delay value for triggered routing updates so that updates triggered by special events are sent in a more timely manner than periodic routing updates.
Novell recommends a delay of 55 ms for compatibility with older and slower IPX machines. These machines may lose RIP updates because they process packets more slowly than the router sends them. The delay imposed by this command forces the router to pace its output to the slower-processing needs of these IPX machines.
The default delay on a NetWare 3.11 server is about 100 ms.
When you do not set the interpacket delay for triggered routing updates, the system uses the delay specified by the ipx output-rip-delay or ipx broadcast-fastswitching command for both periodic and triggered routing updates.
When you use the no form of the ipx triggered-rip-delay command, the system uses the global default delay set by the ipx default-triggered-rip-delay command for triggered RIP updates, if it is set. If it is not set, the system uses the delay set by the ipx output-rip-delay or ipx broadcast-fastswitching 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.
The following example sets an interpacket delay of 55 ms for triggered routing updates sent on interface FDDI 0:
ipx broadcast-fastswitching
ipx default-triggered-rip-delay
ipx output-rip-delay
To set the interpacket delay for triggered SAP updates sent on a single interface, use the ipx triggered-sap-delay interface configuration command. To return to the default delay, use the no form of this command.
With Cisco IOS Release 10.0 and Release 10.2, the default delay is 0 ms (that is, no additional delay between update packets). With Cisco IOS Release 10.3, the default delay is 5 ms.
The interpacket delay is the delay between the individual packets sent in a multiple-packet SAP update. A triggered SAP update is one that the system sends in response to a "trigger" event, such as a request packet, interface up/down, route up/down, or server up/down.
The ipx triggered-sap-delay command sets the interpacket delay for triggered updates sent on a single interface. The delay value set by this command overrides the delay value set by the ipx output-sap-delay or ipx default-output-sap-delay command for triggered updates sent on the interface.
If the delay value set by the ipx output-sap-delay or ipx default-output-sap-delay command is high, then we strongly recommend a low delay value for triggered updates so that updates triggered by special events are sent in a more timely manner than periodic updates.
Novell recommends a delay of 55 ms for compatibility with older and slower IPX servers. These servers may lose SAP updates because they process packets more slowly than the router sends them. The delay imposed by this command forces the router to pace its output to the slower-processing needs of these IPX servers.
The default delay on a NetWare 3.11 server is about 100 ms.
When you do not set the interpacket delay for triggered updates, the system uses the delay specified by the ipx output-sap-delay or ipx default-output-sap-delay command for both periodic and triggered SAP updates.
When you use the no form of the ipx triggered-sap-delay command, the system uses the global default delay set by the ipx default-triggered-sap-delay command for triggered SAP updates, if it is set. If it is not set, the system uses the delay set by the ipx output-sap-delay or ipx default-output-sap-delay command for triggered SAP updates, if set. Otherwise, the system uses the initial default delay as described in the "Default" section.
This command is also useful on limited bandwidth point-to-point links or X.25 and Frame Relay multipoint interfaces.
The following example sets an interpacket delay of 55 ms for triggered SAP updates sent on interface FDDI 0:
ipx default-output-sap-delay
ipx default-triggered-sap-delay
ipx output-sap-delay
To forward IPX type 20 propagation packet broadcasts to specific network segments, use the ipx type-20-helpered interface configuration command. To disable this function, use the no form of this command.
This command has no arguments or keywords.
The ipx type-20-helpered command disables the input and output of type 20 propagation packets as done by the ipx type-20-propagation interface configuration command.
The ipx type-20-propagation command broadcasts type 20 packets to all nodes on the network and imposes a hop-count limit of eight routers for broadcasting these packets. These functions are in compliance with the Novell IPX router specification. In contrast, the ipx type-20-helpered command broadcasts type 20 packets to only those nodes indicated by the ipx helper-address interface configuration command and extends the hop-count limit to 16 routers.
Use of the ipx type-20-helpered command does not comply with the Novell IPX router specification.
The following example forwards IPX type 20 propagation packet broadcasts to specific network segments:
ipx helper-address
ipx type-20-propagation
To restrict the acceptance of IPX type 20 propagation packet broadcasts, use the ipx type-20-input-checks global configuration command. To remove these restrictions, use the no form of this command.
This command has no arguments or keywords.
By default, the router is configured to block type 20 propagation packets. When type 20 packet handling is enabled on multiple interfaces, you can use the ipx type-20-input-checks command to impose additional restrictions on the acceptance of type 20 packets. Specifically, the router will accept type 20 propagation packets only on the single network that is the primary route back to the source network. Similar packets received via other networks will be dropped. This behavior can be advantageous in redundant topologies, because it reduces unnecessary duplication of type 20 packets.
The following example imposes additional restrictions on incoming type 20 broadcasts:
ipx type-20-output-checks
ipx type-20-propagation
To restrict the forwarding of IPX type 20 propagation packet broadcasts, use the ipx type-20-output-checks global configuration command. To remove these restrictions, use the no form of this command.
This command has no arguments or keywords.
By default, the router is configured to block type 20 propagation packets. When type 20 packet handling is enabled on multiple interfaces, you can use the ipx type-20-output-checks command to impose additional restrictions on outgoing type 20 packets. Specifically, the router will forward these packets only to networks that are not routes back to the source network. (The router uses the current routing table to determine routes.) This behavior can be advantageous in redundant topologies, because it reduces unnecessary duplication of type 20 packets.
The following example imposes restrictions on outgoing type 20 broadcasts:
ipx type-20-input-checks
ipx type-20-propagation
To forward IPX type 20 propagation packet broadcasts to other network segments, use the ipx type-20-propagation interface configuration command. To disable both the reception and forwarding of type 20 broadcasts on an interface, use the no form of this command.
This command has no arguments or keywords.
Routers normally block all broadcast requests. To allow input and output of type 20 propagation packets on an interface, use the ipx type-20-propagation command. Note that type 20 packets are subject to loop detection and control as specified in the IPX router specification.
Additional input and output checks may be imposed by the ipx type-20-input-checks and ipx type-20-output-checks commands.
IPX type 20 propagation packet broadcasts are subject to any filtering defined by the ipx helper-list command.
The following example enables both the reception and forwarding of type 20 broadcasts on Ethernet interface 0:
The following example enables the reception and forwarding of type 20 broadcasts between networks 123 and 456, but does not enable reception and forwarding of these broadcasts to and from network 789.
ipx helper-list
ipx type-20-input-checks
ipx type-20-output-checks
To adjust the IPX routing update timers, use the ipx update-time interface configuration command. To restore the default value, use the no form of this command.
The ipx update-time command sets the routing update timer on a per-interface basis.
Routers exchange information about routes by sending broadcast messages when they are brought up and shut down, and periodically while they are running. The ipx update-time command lets you modify the periodic update interval. By default, this interval is 60 seconds (this default is defined by Novell).
You can set RIP timers only in a configuration in which all routers are our routers or in which the IPX routers allow configurable timers. The timers should be the same for all routers connected to the same cable segment.
The update value you choose affects the internal IPX timers as follows:
The concept of granularity is best explained by an example. (This example is illustrated in the "Example" section following.) If you have two interfaces in the router and you set the update timer on one to 20 seconds and the second to 30 seconds, the router wakes up every 20 seconds to try to send routing updates. So at time 0:00:20, the router sends an update out the first interface only, and at time 0:00:40 it sends updates out the first and second interfaces. The router does not wake up at 0:00:30 to see if it needs to send an update out the second interface. This means that routing updates are sent out the second interface at N:NN:40 and N:NN:00. That is, the interval alternates between 40 seconds and 20 seconds; it is never 30 seconds. The interval on the first interface is always 20 seconds.
The following example sets the update timers on two interfaces in the router. The update timer granularity would be 20 seconds because this is the lowest value specified.
To have the router respond to a server's watchdog packets on behalf of a remote client, use the ipx watchdog-spoof interface configuration command. To disable spoofing, use the no form of this command.
This command has no arguments or keywords.
You can use the ipx watchdog-spoof command only on a serial interface on which dial-on-demand routing (DDR) has been enabled. Also, fast switching and autonomous switching must be disabled on the interface.
IPX watchdog packets are keepalive packets that are sent from servers to clients after a client session has been idle for approximately 5 minutes. On a DDR link, this would mean that a call would be made every 5 minutes, regardless of whether there were data packets to send. You can prevent these calls from being made by configuring the router to respond to the server's watchdog packets on a remote client's behalf. This is sometimes referred to as "spoofing the server."
The following example enables spoofing on serial interface 0:
To generate a log message when an NLSP adjacency changes state (up or down), use the log-adjacency-changes router configuration command. Use the no form of this command to disable this function.
This command has no arguments or keywords.
Adjacency changes are not logged.
This command allows the monitoring of NLSP adjacency state changes. This may be very useful when monitoring large networks. Messages are logged using the system error message facility. Messages are of the form:
%CLNS-5-ADJCHANGE: NLSP: Adjacency to 0000.0000.0034 (Serial0) Up, new adjacency
%CLNS-5-ADJCHANGE: NLSP: Adjacency to 0000.0000.0034 (Serial0) Down, hold time expired
The following example instructs the router to log adjacency changes for the NLSP process area1:
A dagger () indicates that the command is documented outside this chapter.
To enable the logging of changes in Enhanced IGRP neighbor adjacencies, use the log-neighbor-changes command.
No adjacency changes are logged.
Enable the logging of neighbor adjacency changes in order to monitor the stability of the routing system and to help detect problems. Log messages are of the form:
%DUAL-5-NBRCHANGE: IPX EIGRP as-number: Neighbor address (interface) is state: reason
The following configuration will log neighbor changes for Enhanced IGRP process 209.
To set the minimum interval at which link-state packets (LSPs) are generated, use the lsp-gen-interval router configuration command. To restore the default interval, use the no form of this command.
The lsp-gen-interval command controls the rate at which LSPs are generated on a per-LSP basis. For instance, if a link is changing state at a high rate, the default value of the LSP generation interval limits the signaling of this change to once every 5 seconds. Because the generation of an LSP may cause all routers in the area to perform the SPF calculation, controlling this interval may have area-wide impact. Raising this interval can reduce the load on the network imposed by a rapidly changing link.
The following example sets the minimum interval at which LSPs are generated to 10 seconds:
To set the maximum size of a link-state packet (LSP) generated by the router, use the lsp-mtu router configuration command. To restore the default MTU size, use the no form of this command.
You can increase the LSP MTU if there is a very large amount of information generated by a single router, because each router is limited to approximately 250 LSPs. In practice, this should never be necessary.
The LSP MTU must never be larger than the smallest MTU of any link in the area. This is because LSPs are flooded throughout the area.
The lsp-mtu command limits the size of LSPs generated by this router only; the router can receive LSPs of any size up to the maximum.
The following example sets the maximum LSP size to 1500 bytes:
ipx router nlsp
To set the link-state packet (LSP) refresh interval, use the lsp-refresh-interval router configuration command. To restore the default refresh interval, use the no form of this command.
The refresh interval determines the rate at which a router periodically transmits the route topology information that it originates. This is done in order to keep the information from becoming too old. By default, the refresh interval is 2 hours.
LSPs must be periodically refreshed before their lifetime expires. The refresh interval must be less than the LSP lifetime specified with the max-lsp-lifetime router configuration command. Reducing the refresh interval reduces the amount of time that undetected link state database corruption can persist (this is an extremely unlikely event, however, because there are other safeguards against corruption) at the cost of increased link utilization. Increasing the interval reduces the link utilization caused by the flooding of refreshed packets (although this utilization is very small).
The following example changes the LSP refresh interval to 10800 seconds (3 hours):
ipx router nlsp
max-lsp-lifetime
To set the maximum time that link-state packets (LSPs) persist without being refreshed, use the max-lsp-lifetime router configuration command. To restore the default time, use the no form of this command.
7500 seconds (2 hours, 5 minutes)
You might need to adjust the maximum LSP lifetime if you change the LSP refresh interval with the lsp-refresh-intervalrouter configuration command. The maximum LSP lifetime must be greater than the LSP refresh interval.
The following example sets the maximum time that the LSP persists to 11000 seconds (just over 3 hours):
ipx router nlsp
lsp-refresh-interval
To define an IPX NetBIOS access list filter, use the netbios access-list interface configuration command. To remove a filter, use the no form of the command.
Keep the following points in mind when configuring IPX NetBIOS access control:
These filters apply only to IPX NetBIOS packets. They have no effect on LLC2 NetBIOS packets.
To delete an IPX NetBIOS access list, specify the minimum number of keywords and arguments needed to delete the proper list. For example, to delete the entire list, use the following command:
To delete a single entry from the list, use the following command:
The following example defines the IPX NetBIOS access list engineering:
The following example removes a single entry from the engineering access list:
The following example removes the entire engineering NetBIOS access list:
ipx netbios input-access-filter
ipx netbios output-access-filterr
show ipx interface
To enable Enhanced IGRP on the router, use the network IPX-router configuration command. To disable Enhanced IGRP on the router, use the no form of this command.
Use the network command to enable the routing protocol specified in the ipx router command on each network.
The following commands disable RIP on network 10 and enable Enhanced IGRP on networks 10 and 20:
To check host reachability and network connectivity, use the ping privileged EXEC command.
The privileged ping (IPX echo) command provides a complete ping facility for users who have system privileges.
The ping command works only on our routers running Software Release 8.2 or later.
Novell IPX devices that support the echo function defined in version 1.0 of the NLSP specification will respond to this command if you answer y to the prompt Novell Standard Echo that is displayed when you use the ping command. If you answer n to this prompt, Novell IPX devices will not respond.
To abort a ping session, type the escape sequence. By default, this is Ctrl-^ X. You enter this by simultaneously pressing the Ctrl, Shift, and 6 keys, letting go, and then pressing the X key.
Table 20-5 describes the test characters displayed in ping responses.
Table 20-5 Ping Test Characters
The following sample display shows input to and output from the ping command:
To check host reachability and network connectivity, use the ping user EXEC command.
The user-level ping (packet internet groper function) command provides a basic ping facility for users who do not have system privileges. This command is equivalent to the nonverbose form of the privileged ping command. It sends five 100-byte ping packets.
The ping command works only on our routers running Software Release 8.2 or later. Novell IPX devices will not respond to this command.
You cannot ping a router from itself.
If the system cannot map an address for a host name, it will return an "%Unrecognized host or address" error message.
To abort a ping session, type the escape sequence. By default, this is Ctrl-^ X. You enter this by simultaneously pressing the Ctrl, Shift, and 6 keys, letting go, and then pressing the X key.
Table 20-6 describes the test characters displayed in ping responses.
Table 20-6 Ping Test Characters
The following sample display shows input to and output from the user ping command:
ipx ping-default
ping (privileged)
To redistribute from one routing domain into another, and vice versa, use the redistribute IPX-router configuration command. To disable this feature, use the no form of this command.
Redistribution is enabled between all routing domains except between separate Enhanced IGRP processes.
Redistribution of floating static routes is disabled.
Redistribution provides for routing information generated by one protocol to be advertised in another.
The only connected routes affected by this redistribute command are the routes not specified by the network command.
If you have enabled floating static routes by specifying the floating keyword in the ipx route global configuration command and you redistribute floating static routes into a dynamic IPX routing protocol, any nonhierarchical topology causes the floating static destination to be redistributed immediately via a dynamic protocol back to the originating router, causing a routing loop. This occurs because dynamic protocol information overrides floating static routes. For this reason, automatic redistribution of floating static routes is off by default. If you redistribute floating static routes, you should specify filters to eliminate routing loops.
In the following example, RIP routing information is not redistributed:
In the following example, Enhanced IGRP routes from autonomous system 100 are redistributed into Enhanced IGRP autonomous sytem 300:
To display the active accounting or checkpointed database, use the show ipx accounting EXEC command.
The following is sample output from the show ipx accounting command:
Table 20-7 describes the fields shown in the display.
Table 20-7 Show IPX Accounting Field Descriptions
clear ipx accounting
ipx accounting
ipx accounting-list
ipx accounting-threshold
ipx accounting-transits
To display the contents of the IPX fast-switching cache, use the show ipx cache EXEC command.
This command has no arguments or keywords.
The following is sample output from the show ipx cache command:
Table 20-8 describes the fields shown in the display.
Table 20-8 Show IPX Cache Field Descriptions
clear ipx cache
ipx route-cache
To display information about interfaces configured for Enhanced IGRP, use the show ipx eigrp interfaces EXEC command.
Use the show ipx eigrp interfaces command to determine on which interfaces Enhanced IGRP is active and to find out information about Enhanced IGRP relating to those interfaces.
If an interface is specified, only that interface is displayed. Otherwise, all interfaces on which Enhanced IGRP is running are displayed.
If an autonomous system is specified, only the routing process for the specified autonomous system is displayed. Otherwise, all Enhanced IGRP processes are displayed.
The following is sample output from the show ipx eigrp interfaces command:
Table 20-9 describes the fields shown in the display.
Table 20-9 Show IPX Enhanced IGRP Interfaces Field Descriptions
To display the neighbors discovered by Enhanced IGRP, use the show ipx eigrp neighbors EXEC command.
The following is sample output from the show ipx eigrp neighbors command:
Table 20-10 explains the fields in the display.
Table 20-10 Show IPX EIGRP Neighbors Field Descriptions
| Field | Description |
|---|---|
Autonomous system number specified in the ipx router configuration command. |
|
Handle. An arbitrary and unique number inside this router that identifies the neighbor. |
|
Interface on which the router is receiving hello packets from the peer. |
|
Length of time, in seconds, that the router will wait to hear from the peer before declaring it down. If the peer is using the default hold time, this number will be less than 15. If the peer configures a nondefault hold time, it will be reflected here. |
|
Elapsed time, in hours, minutes, and seconds, since the local router first heard from this neighbor. |
|
Number of IPX Enhanced IGRP packets (Update, Query, and Reply) that the router is waiting to send. |
|
Sequence number of the last Update, Query, or Reply packet that was received from this neighbor. |
|
Smooth round-trip time. This is the number of milliseconds it takes for an IPX Enhanced IGRP packet to be sent to this neighbor and for the local router to receive an acknowledgment of that packet. |
|
Retransmission timeout, in milliseconds. This is the amount of time the router waits before retransmitting a packet from the retransmission queue to a neighbor. |
To display the Enhanced IGRP topology table, use the show ipx eigrp topology EXEC command.
The following is sample output from the show ipx eigrp topology command:
Table 20-11 explains the fields in the output.
Table 20-11 Show IPX EIGRP Topology Field Descriptions
The following is sample output from the show ipx eigrp topology command when you specify an IPX network number:
Table 20-12 explains the fields in the output.
Table 20-12 Show IPX EIGRP Topology Field Descriptions for a Specified Network
| Field | Description |
|---|---|
State of this entry. It can be either Passive or Active. Passive means that no Enhanced IGRP computations are being performed for this destination, and Active means that they are being performed. |
|
Exact Enhanced IGRP state that this destination is in. It can be the number 0, 1, 2, or 3. This information appears only when the destination is Active. |
|
Number of successors. This number corresponds to the number of next hops in the IPX routing table. |
|
Indicates how this destination was learned. It can be one of the following: |
|
Peer from whom the information was learned. For connected and redistributed routers, this is 0.0000.0000.0000. For information learned via Enhanced IGRP, this is the peer's address. Currently, for information learned via Enhanced IGRP, the peer's IPX address always matches the address in the "Next hop is" field. |
|
Enhanced IGRP composite metric. The first number is this router's metric to the destination, and the second is the peer's metric to the destination. |
|
Numeric representation of the "flags" field described in Table 20-11. It is 0 when nothing is being sent, 1 when an Update is being sent, 3 when a Query is being sent, and 4 when a Reply is being sent. Currently, 2 is not used. |
|
Type of router. It can be either internal or external. Internal routes are those that originated in an Enhanced IGRP autonomous system, and external are routes that did not. Routes learned via RIP are always external. |
|
Indicates that this path is being ignored because of filtering. |
|
This section describes the components of the Enhanced IGRP metric. |
|
Minimum bandwidth of the network used to reach the next hop. |
|
This section describes the original protocol from which this route was redistributed. It appears only for external routes. |
|
Network address of the router that first distributed this route into Enhanced IGRP. |
|
External protocol from which this route was learned. The metric will match the external hop count displayed by the show ipx route command for this destination. The delay is the external delay. |
|
To display the status of the IPX interfaces configured in the router and the parameters configured on each interface, use the show ipx interface EXEC command.
The following is sample output from the show ipx interface command:
The following is sample output from the show ipx interface command when NLSP is enabled on the router:
Table 20-13 describes the fields shown in the display.
Table 20-13 Show IPX Interface Field Descriptions
| Field | Description |
|---|---|
Type of interface and whether it is currently active and inserted into the network (up) or inactive and not inserted (down). |
|
Network and node address of the local router interface, followed by the type of encapsulation configured on the interface and the interface's status. Refer to theipx network command for a list of possible values. |
|
Indicates whether IPX routing is enabled or disabled on the interface. "line-up" indicates that IPX routing has been enabled with the ipx routing command. "line-down" indicates that it is not enabled. The word in square brackets provides more detail about the status of IPX routing when it is in the process of being enabled or disabled. |
|
Address of a secondary network configured on this interface, if any, followed by the type of encapsulation configured on the interface and the interface's status. Refer to the ipx network command for a list of possible values. This line is displayed only if you have configured a secondary address with the ipx network command. |
|
Value of the ticks field (configured with the iipx delay command). |
|
Throughput of the interface (configured with the ipx throughput interface configuration command). |
|
Link delay of the interface (configured with the ipx link-delay interface configuration command). |
|
Indicates whether IPXWAN processing has been enabled on this interface with the ipx ipxwancommand. |
|
Indicates the frequency of outgoing SAP updates (configured with the iipx sap-interval command). |
|
Indicates whether forwarding of IPX type 20 propagation packets (used by NetBIOS) is enabled or disabled on this interface, as configured with the ipx type-20-propagation command. |
|
Indicates whether an access list has been enabled with the |
|
Number of the broadcast helper list applied to the interface with the ipx helper-listcommand. |
|
Number of the input SAP filter applied to the interface with the |
|
Number of the output SAP filter applied to the interface with the |
|
Number of the router SAP filter applied to the interface with the |
|
Number of the Get Nearest Server (GNS) response filter applied to the interface with the ipx output-gns-filtercommand. |
|
Number of the input filter applied to the interface with the |
|
Number of the output filter applied to the interface with the |
|
Number of the router entry filter applied to the interface with the |
|
Name of the IPX NetBIOS input host filter applied to the interface with the ipx netbios input-access-filter host command. |
|
Name of the IPX NetBIOS input bytes filter applied to the interface with the ipx netbios input-access-filter bytes command. |
|
Name of the IPX NetBIOS output host filter applied to the interface with the ipx netbios output-access-filter host command. |
|
Name of the IPX NetBIOS output bytes filter applied to the interface with the ipx netbios output-access-filter bytes command. |
|
How often the router sends RIP updates, as configured with the |
|
Indicates whether watchdog spoofing is enabled of disabled for this interface, as configured with the ipx watchdog-spoof command. This information is displayed only on serial interfaces. |
|
Indicates whether IPX accounting has been enabled with the ipx accounting command. |
|
Indicates whether IPX fast switching is enabled (default) or disabled for this interface, as configured with ipx route-cache command. (If IPX autonomous switching is enabled, it is configured with the iipx route-cache cbus command.) |
|
Indicates whether IPX SSE switching is enabled for this interface, as configured with the ipx route-cache sse command. |
|
Indicates that NLSP is running and the number of the primary IPX network on which it is running. |
|
State of RIP compatibility (configured by the ipx nlsp ripinterface configuration command). |
|
State of SAP compatibility (configured by the ipx nlsp sapinterface configuration command). |
|
Interval between transmission of hello packets for nondesignated routers (configured by the ipx nlsp hello-interval interface configuration command). |
|
Interval between transmission of hello packets for designated routers (configured by the iipx nlsp hello-interval interface configuration command). |
|
CSNP interval (as configured by the ipx nlsp csnp-interval interface configuration command). |
|
LSP retransmisison interval (as configured by the |
|
System ID and pseudonode number of the designated router. In this example, 0000.0C02.8CF9 is the system ID, and 02 is the pseudonode number. |
access-list (standard)
access-list (extended))
access-list (SAP filtering))
ipx accounting
ipx delay
ipx encapsulation
ipx helper-list
ipx input-network-filter
ipx input-sap-filter
ipx ipxwan
ipx link-delay
ipx netbios input-access-filter
ipx netbios output-access-filter
ipx network
ipx nlsp csnp-interval
ipx nlsp hello-interval
ipx nlsp retransmit-interval
ipx nlsp rip
ipx nlsp sap
ipx output-gns-filter
ipx output-network-filter
ipx output-rip-delay
ipx output-sap-delay
ipx route-cache
ipx router-filter
ipx router-sap-filter
ipx routing
ipx sap-interval
ipx throughput
ipx update-time
ipx watchdog-spoof
netbios access-list
To display the entries in the link-state packet (LSP) database, use the show ipx nlsp database EXEC command.
If you omit all options, a summary display is shown.
The following is sample output from the show ipx nlsp database command:
Table 20-14 explains the fields in the display.
Table 20-14 Show IPX NLSP Database Fields
To display the router's NLSP neighbors and their states, use the show ipx nlsp neighbors EXEC command.
If you omit the keyword detail, a summary display is shown.
The following is sample output from the show ipx nlsp neighbors command:
Table 20-15 explains the fields in the display.
Table 20-15 Show IPX NLSP Neighbors Fields
To display the contents of the IPX routing table, use the show ipx route user EXEC command.
The following is sample output from the show ipx route command:
Table 20-16 describes the fields shown in the display.
Table 20-16 Show IPX Route Field Descriptions
| Field | Description |
|---|---|
Statically defined route via theipx route command. |
|
Maximum number of parallel paths for which the router has been configured with the ipx maximum-paths command. |
|
Indicates whether a default route is known and, if so, what it is. |
|
Age of the entry, in seconds. For RIP and SAP, this is normally a value from 0 to 59. For NLSP, this is normally a value from 0 to 7200. |
|
Cost of the route (NLSP only). For interior NLSP routes (marked "N"), this is the cost to the destination network. For exterior NLSP routes (marked "NX") this is the equivalent NLSP cost to the edge of the NLSP area. You can override default cost with the ipx nlsp hello-multiplier command. |
|
Ticks/hops to the destination network. For RIP routes, this is the cumulative ticks and hops to the destination network. For NLSP routes, this is the equivalent ticks/hops computed from the NLSP cost to the destination network. For NLSP exterior routes, this is the equivalent ticks/hops computed by adding the RIP ticks/hops advertised at the edge of the NLSP area to the equivalent ticks/hops computed from the NLSP cost to the edge of the area. |
|
Ticks/hops external to the NLSP cloud. These numbers are the tick and hop values advertised by RIP at the point where it entered the NLSP cloud. |
The following is sample output from the show ipx route detailed command:
Table 20-17 explains the additional fields shown in the display.
Table 20-17 Show IPX Route Detailed Fields
clear ipx route
ipx maximum-paths
ipx nlsp hello-multiplier
ipx route
To list the IPX servers discovered through SAP advertisements, use the show ipx servers EXEC command.
IPX servers are displayed numerically by SAP service type.
The following is sample output from the show ipx servers command when NLSP is enabled:
Table 20-18 describes the fields shown in the display.
Table 20-18 Show IPX Server Field Descriptions
| Field | Description |
|---|---|
Statically defined route via the ipx route command. |
|
Indicates that the entry is in holddown mode and is not reachable. |
|
Indicates that multiple paths to the server exist. Use the show ipx servers detailed EXEC command to display more detailed information about the paths. |
|
To display information about the number and type of IPX packets transmitted and received by the router, use the show ipx traffic user EXEC command.
This command has no arguments or keywords.
The following is sample output from the show ipx traffic command:
The following is sample output from the show ipx traffic command when NLSP is enabled:
Table 20-19 describes the fields that might possibly be shown in the display.
Table 20-19 Show IPX Traffic Field Descriptions
To display a summary of Silicon Switch Processor (SSP) statistics, use the show sse summary EXEC command.
This command has no arguments or keywords.
The following is sample output from the show sse summary command:
To control how often the router performs the shortest path first (SPF) calculation, use the spf-interval router configuration command. To restore the default interval, use the no form of this command.
SPF calculations are performed only when the router topology changes. They are not performed when external routes change.
The spf-interval command controls how often the router can perform the shortest path first (SPF) calculation. The SPF calculation is processor-intensive. Therefore, it may be useful to limit how often this is done, especially when the area is large and the topology changes often. Increasing the SPF interval reduces the processor load of the router, but potentially slows down the rate of convergence.
The following example sets the SPF calculation interval to 30 seconds:
ipx router nlsp
lsp-gen-interval
Posted: Wed Jul 2 23:42:43 PDT 2003
All contents are Copyright © 1992--2003 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.