|
|
Table Of Contents
ipx default-triggered-rip-delay
ipx default-triggered-rip-holddown
ipx default-triggered-sap-delay
ipx default-triggered-sap-holddown
ipx input-network-filter (RIP)
ipx netbios input-access-filter
ipx netbios output-access-filter
ipx netbios-socket-input-checks
ipx default-output-rip-delay
To set the default interpacket delay for RIP updates sent on all interfaces, use the ipx default-output-rip-delay command in global configuration mode. To return to the initial default delay value, use the no form of this command.
ipx default-output-rip-delay delay
no ipx default-output-rip-delay
Syntax Description
delay
Delay, in milliseconds (ms), between packets in a multiple-packet RIP update. The default delay is 55 ms. Novell recommends a delay of 55 ms.
Defaults
55 ms
Command Modes
Global configuration
Command History
Usage Guidelines
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.
Examples
The following example sets a default interpacket delay of 55 ms for RIP updates sent on all interfaces:
ipx default-output-rip-delay 55Related Commands
ipx default-output-sap-delay
To set a default interpacket delay for SAP updates sent on all interfaces, use the ipx default-output-sap-delay command in global configuration mode. To return to the initial default delay value, use the no form of this command.
ipx default-output-sap-delay delay
no ipx default-output-sap-delay
Syntax Description
delay
Delay, in milliseconds (ms), between packets in a multiple-packet SAP update. The default delay is 55 ms. Novell recommends a delay of 55 ms.
Defaults
55 ms
Command Modes
Global configuration
Command History
Usage Guidelines
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.
Examples
The following example sets a default interpacket delay of 55 ms for SAP updates sent on all interfaces:
ipx default-output-sap-delay 55Related Commands
ipx default-route
To forward to the default network all packets for which a route to the destination network is unknown, use the ipx default-route command in global configuration mode. To disable the use of the default network, use the no form of this command.
ipx default-route
no ipx default-route
Syntax Description
This command has no arguments or keywords.
Defaults
Enabled. All packets for which a route to the destination is unknown are forwarded to the default network, which is -2 (0xFFFFFFFE).
Command Modes
Global configuration
Command History
Usage Guidelines
When you use the no ipx default-route command, Cisco IOS software no longer uses -2 as the default network. Instead, the software interprets -2 as a regular network and packets for which a route to the destination network is unknown are dropped.
Examples
The following example disables the forwarding of packets towards the default network:
no ipx default-routeRelated Commands
ipx advertise-default-route-only
Advertises only the default RIP route through the specified network.
ipx default-triggered-rip-delay
To set the default interpacket delay for triggered RIP updates sent on all interfaces, use the ipx default-triggered-rip-delay command in global configuration mode. To return to the system default delay, use the no form of this command.
ipx default-triggered-rip-delay delay
no ipx default-triggered-rip-delay [delay]
Syntax Description
delay
Delay, in milliseconds (ms), between packets in a multiple-packet RIP update. The default delay is 55 ms. Novell recommends a delay of 55 ms.
Defaults
55 ms
Command Modes
Global configuration
Command History
Usage Guidelines
The interpacket delay is the delay between the individual packets sent in a multiple-packet routing update. A triggered routing update is one that the system sends in response to a "trigger" event, such as a request packet, interface up/down, route up/down, or server up/down.
The ipx 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 approximately 100 ms.
When you do not set the interpacket delay for triggered routing updates, the system uses the delay specified by the ipx output-rip-delay or ipx 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 "Defaults" section.
This command is also useful on limited bandwidth point-to-point links, or X.25 and Frame Relay multipoint interfaces.
Examples
The following example sets an interpacket delay of 55 ms for triggered routing updates sent on all interfaces:
ipx default-triggered-rip-delay 55Related Commands
ipx default-triggered-rip-holddown
To set the global default for the ipx triggered-rip-holddown interface configuration command, use the ipx default-triggered-rip-holddown command in global configuration mode. To re-establish the default value of 55 milliseconds, use the no form of this command.
ipx default-triggered-rip-holddown milliseconds
no ipx default-triggered-rip-holddown milliseconds
Syntax Description
milliseconds
Specifies how many milliseconds (ms) a router will wait before sending the triggered route change information.
Defaults
55 milliseconds
Command Modes
Global configuration
Command History
Usage Guidelines
Setting the global default for the ipx triggered-rip-holddown interface configuration command saves you from needing to configure the command on every interface.
Examples
The following example shows the hold-down time changed to 100 milliseconds:
ipx default-triggered-rip-holddown 100Related Commands
ipx default-triggered-sap-delay
To set the default interpacket delay for triggered SAP updates sent on all interfaces, use the ipx default-triggered-sap-delay command in global configuration mode. To return to the system default delay, use the no form of this command.
ipx default-triggered-sap-delay delay
no ipx default-triggered-sap-delay [delay]
Syntax Description
delay
Delay, in milliseconds (ms), between packets in a multiple-packet SAP update. The default delay is 55 ms. Novell recommends a delay of 55 ms.
Defaults
55 ms
Command Modes
Global configuration
Command History
Usage Guidelines
The interpacket delay is the delay between the individual packets sent in a multiple-packet SAP update. A triggered SAP update is one that the system sends in response to a "trigger" event, such as a request packet, interface up/down, route up/down, or server up/down.
The ipx default-triggered-sap-delay command sets the default interpacket delay for triggered SAP updates sent on all interfaces. On a single interface, you can override this global default delay for triggered updates using the ipx triggered-sap-delay interface command.
The global default delay for triggered updates overrides the delay value set by the ipx output-sap-delay or ipx default-output-sap-delay command for triggered updates.
If the delay value set by the ipx output-sap-delay or ipx default-output-sap-delay command is high, then we strongly recommend a low delay value for triggered updates so that updates triggered by special events are sent in a more timely manner than periodic updates.
Novell recommends a delay of 55 ms for compatibility with older and slower IPX servers. These servers may lose SAP updates because they process packets more slowly than the router sends them. The delay imposed by this command forces the router to pace its output to the slower-processing needs of these IPX servers.
The default delay on a NetWare 3.11 server is approximately 100 ms.
When you do not set the interpacket delay for triggered SAP updates, the system uses the delay specified by the ipx output-sap-delay or ipx default-output-sap-delay command for both periodic and triggered SAP updates.
When you use the no form of the ipx default-triggered-sap-delay command, the system uses the delay set by the ipx output-sap-delay or ipx default-output-sap-delay command for triggered SAP updates, if set. Otherwise, the system uses the initial default delay as described in the "Defaults" section.
This command is also useful on limited bandwidth point-to-point links, or X.25 and Frame Relay multipoint interfaces.
Examples
The following example sets an interpacket delay of 55 ms for triggered SAP updates sent on all interfaces:
ipx default-triggered-sap-delay 55Related Commands
ipx default-triggered-sap-holddown
To set the global default for the ipx triggered-sap-holddown interface configuration command, use the ipx default-triggered-sap-holddown command in global configuration mode. To re-establish the default value of 55 milliseconds, use the no form of this command.
ipx default-triggered-sap-holddown milliseconds
no ipx default-triggered-sap-holddown milliseconds
Syntax Description
milliseconds
Specifies how many milliseconds (ms) a router will wait before sending the triggered route change information.
Defaults
55 milliseconds
Command Modes
Global configuration
Command History
Usage Guidelines
Setting the global default for the ipx triggered-sap-holddown interface configuration command saves you from needing to configure a triggered-sap-holddown command on every interface.
Examples
The following example shows the hold-down time changed to 100 ms:
ipx default-triggered-sap-holddown 100Related Commands
ipx delay
To set the tick count, use the ipx delay command in interface configuration mode. To reset the default increment in the delay field, use the no form of this command.
ipx delay ticks
no ipx delay
Syntax Description
ticks
Number of IBM clock ticks of delay to use. One clock tick is 1/18 of a second (approximately 55 ms).
Defaults
The IPX default delay is determined from the interface delay configured on the interface with the delay command. It is (interface delay + 333) / 334. Therefore, unless you change the delay by a value greater than 334, you will not notice a difference.
Command Modes
Interface configuration
Command History
Usage Guidelines
The ipx delay command sets the count used in the IPX RIP delay field, which is also known as the ticks field.
IPXWAN links determine their delay dynamically. If you do not specify the ipx delay command on an interface and you have not changed the interface delays with the interface delay interface configuration command, all LAN interfaces have a delay of 1 and all WAN interfaces have a delay of 6. The preferred method of adjusting delays is to use the ipx delay command, not the interface delay command. The show ipx interface EXEC command display only the delay value configured with the ipx delay command.
With IPXWAN, if you change the interface delay with the interface delay command, the ipx delay command uses that delay when calculating a delay to use. Also, when changing delays with IPXWAN, the changes affect only the link's calculated delay on the side considered to be the master.
Leaving the delay at its default value is sufficient for most interfaces.
Examples
The following example changes the delay for serial interface 0 to 10 ticks:
interface serial 0 ipx delay 10Related Commands
ipx down
To administratively shut down an IPX network, use the ipx down command in interface configuration mode. To restart the network, use the no form of this command.
ipx down network
no ipx down
Syntax Description
Defaults
Disabled
Command Modes
Interface configuration
Command History
Usage Guidelines
The ipx down command administratively shuts down the specified network. The network still exists in the configuration, but is not active. When shutting down, the network sends out update packets informing its neighbors that it is shutting down. This allows the neighboring systems to update their routing, SAP, and other tables without having to wait for routes and services learned via this network to time out.
To shut down an interface in a manner that is considerate of one's neighbor, use ipx down before using the shutdown command.
Examples
The following example administratively shuts down network AA on Ethernet interface 0:
interface ethernet 0 ipx down AAipx eigrp-sap-split-horizon
To configure Enhanced Interior Gateway Routing Protocol (EIGRP) SAP split horizon, use the ipx eigrp-sap-split-horizon command in global configuration mode. To revert to the default, use the no form of this command.
ipx eigrp-sap-split-horizon
no ipx eigrp-sap-split-horizon
Syntax Description
This command has no argument or keywords.
Defaults
Enabled on LANs and disabled on WANs.
Command Modes
Global configuration
Command History
Usage Guidelines
When split horizon is enabled, Enhanced IGRP SAP update and packets are not sent back to the same interface where the SAP is received from. This reduces the number of Enhanced IGRP packets on the network.
Split horizon blocks information about SAPs from being advertised by a router about any interface from which that information originated. Typically, this behavior optimizes communication among multiple routers, particularly when links are broken. However, with nonbroadcast networks, such as Frame Relay and SMDS, situations can arise for which this behavior is less than ideal. For these situations, you may wish to disable split horizon.
Note
When the ipx sap-incremental split-horizon interface configuration command is configured, it takes precedence over the ipx eigrp-sap-split-horizon command.
Examples
The following example disables split horizon on the router:
no ipx eigrp-sap-split-horizonRelated Commands
ipx encapsulation
To set the Ethernet frame type of the interface to that of the local file server, use the ipx encapsulation command in interface configuration mode. To reset the frame type to the default, use the no form of this command.
ipx encapsulation encapsulation-type
no ipx encapsulation encapsulation-type
Syntax Description
encapsulation-type
(Required) Type of encapsulation (framing). For a list of possible encapsulation types, see Table 6.
Table 6 describes the types of encapsulation available for specific interfaces.
Defaults
novell-ether
Command Modes
Interface configuration
Command History
Usage Guidelines
You can configure an IPX network on any supported interface as long as all the networks on the same physical interface use a distinct encapsulation type. For example, you can configure up to four IPX networks on a single Ethernet cable because Ethernet supports four encapsulation types.
The interface processes only packets with the correct encapsulation and the correct network number. IPX networks that use 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.
Note
To determine the frame type of the server, use the config command at the prompt of the local server.
Examples
The following example sets the frame type to Novell Ethernet II:
interface ethernet 0 ipx encapsulation arpaRelated Commands
Enables IPX routing on a particular interface and optionally selects the type of encapsulation (framing).
ipx routing
Enables IPX routing.
ipx gns-reply-disable
To disable the sending of replies to IPX Get Nearest Server (GNS) queries, use the ipx gns-reply-disable command in interface configuration mode. To return to the default, use the no form of this command.
ipx gns-reply-disable
no ipx gns-reply-disable
Syntax Description
This command has no arguments or keywords.
Defaults
Replies are sent to IPX GNS queries.
Command Modes
Interface configuration
Command History
Examples
The following example disables the sending of replies to GNS queries on Ethernet interface 0:
interface ethernet 0ipx gns-reply-disableRelated Commands
ipx gns-response-delay
To change the delay when responding to Get Nearest Server (GNS) requests, use the ipx gns-response-delay command in global or interface configuration mode. To return to the default delay, use the no form of this command.
ipx gns-response-delay [milliseconds]
no ipx gns-response-delay
Syntax Description
Defaults
0 (no delay)
Command Modes
Global configuration (globally changes the delay for the router)
Interface configuration (overrides the globally configured delay for an interface)Command History
Usage Guidelines
This command can be used in two modes: global configuration or interface configuration. In both modes, the command syntax is the same. A delay in responding to GNS requests might be imposed so that, in certain topologies, any local Novell IPX servers respond to the GNS requests before our software does. It is desirable to have these end-host server systems get their reply to the client before the router does because the client typically takes the first response, not the best response. In this case the best response is the one from the local server.
NetWare 2.x has a problem with dual-connected servers in parallel with a router. If you are using this version of NetWare, you should set a GNS delay. A value of 500 ms is recommended.
In situations in which servers are always located across routers from their clients, there is no need for a delay to be imposed.
Examples
The following example sets the delay in responding to GNS requests to 500 ms (0.5 seconds):
ipx gns-response-delay 500Related Commands
Disables the sending of replies to IPX GNS queries.
ipx rip-response-delay
Changes the delay when responding to RIP requests.
ipx gns-round-robin
To rotate using a round-robin selection method through a set of eligible servers when responding to Get Nearest Server (GNS) requests, use the ipx gns-round-robin command in global configuration mode. To use the most recently learned server, use the no form of this command.
ipx gns-round-robin
no ipx gns-round-robin
Syntax Description
This command has no arguments or keywords.
Defaults
The most recently learned eligible server is used.
Command Modes
Global configuration
Command History
Usage Guidelines
In the normal server selection process, requests for service are responded to with the most recently learned, closest server. If you enable the round-robin method, the Cisco IOS software maintains a list of the nearest servers eligible to provide specific services. It uses this list when responding to GNS requests. Responses to requests are distributed in a round-robin fashion across all active IPX interfaces on the router.
Eligible servers are those that satisfy the "nearest" requirement for a given request and that are not filtered either by a SAP filter or by a GNS filter.
Examples
The following example responds to GNS requests using a round-robin selection method from a list of eligible nearest servers:
ipx gns-round-robinRelated Commands
ipx hello-interval eigrp
To configure the interval between Enhanced Interior Gateway Routing Protocol (EIGRP) hello packets, use the ipx hello-interval eigrp command in interface configuration mode. To restore the default interval, use the no form of this command.
ipx hello-interval eigrp autonomous-system-number seconds
no ipx hello-interval eigrp autonomous-system-number seconds
Syntax Description
Defaults
For low-speed NBMA networks: 60 seconds
For all other networks: 5 secondsCommand Modes
Interface configuration
Command History
Usage Guidelines
The default of 60 seconds applies only to low-speed, nonbroadcast, multiaccess (NBMA) media. Low speed is considered to be a rate of T1 or slower, as specified with the bandwidth interface configuration command. Note that for purposes of Enhanced IGRP, Frame Relay and SMDS networks may or may not be considered to be NBMA. These networks are considered NBMA if the interface has not been configured to use physical multicasting; otherwise they are considered not to be NBMA.
Examples
The following example changes the hello interval to 10 seconds:
interface ethernet 0ipx network 10ipx hello-interval eigrp 4 10Related Commands
Specifies the length of time a lost Enhanced IGRP route is placed in the hold-down state.
ipx helper-address
To forward broadcast packets to a specified server, use the ipx helper-address command in interface configuration mode. To disable this function, use the no form of this command.
ipx helper-address network.node
no ipx helper-address network.node
Syntax Description
Defaults
Disabled
Command Modes
Interface configuration
Command History
Usage Guidelines
Routers normally block all broadcast requests and do not forward them to other network segments. This is done to prevent the degradation of performance over the entire network. The ipx helper-address command allows broadcasts to be forwarded to other networks. This is useful when a network segment does not have an end-host capable of servicing a particular type of broadcast request. This command lets you forward the broadcasts to a server, network, or networks that can process them. Incoming unrecognized broadcast packets that match the access list created with the ipx helper-list command, if it is present, are forwarded.
You can specify multiple ipx helper-address commands on a given interface.
The Cisco IOS software supports all-networks flooded broadcasts (sometimes referred to as all-nets flooding). These are broadcast messages that are forwarded to all networks. To configure the all-nets flooding, define the IPX helper address for an interface as follows:
ipx helper-address -1.FFFF.FFFF.FFFFOn systems configured for IPX routing, this helper address is displayed as follows (via the show ipx interface command):
FFFFFFFF.FFFF.FFFF.FFFFAlthough our software takes care to keep broadcast traffic to a minimum, some duplication is unavoidable. When loops exist, all-nets flooding can propagate bursts of excess traffic that will eventually age out when the hop count reaches its limit (16 hops). Use all-nets flooding carefully and only when necessary. Note that you can apply additional restrictions by defining a helper list.
To forward type 20 packets to only those nodes specified by the ipx helper-address command, use the ipx helper-address command in conjunction with the ipx type-20-helpered global configuration command.
To forward type 20 packets to all nodes on the network, use the ipx type-20-propagation command. See the ipx type-20-propagation command for more information.
Examples
The following example forwards all-nets broadcasts on Ethernet interface 0 (except type 20 propagation packets) are forwarded to IPX server 00b4.23cd.110a on network bb:
interface ethernet 0 ipx helper-address bb.00b4.23cd.110aRelated Commands
ipx helper-list
To assign an access list to an interface to control broadcast traffic (including type 20 propagation packets), use the ipx helper-list command in interface configuration mode. To remove the access list from an interface, use the no form of this command.
ipx helper-list {access-list-number | name}
no ipx helper-list {access-list-number | name}
Syntax Description
Defaults
No access list is preassigned.
Command Modes
Interface configuration
Command History
Usage Guidelines
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.
Examples
The following example assigns access list 900 to Ethernet interface 0 to control broadcast traffic:
interface ethernet 0ipx helper-list 900Related Commands
ipx hold-down eigrp
To specify the length of time a lost Enhanced Interior Gateway Routing Protocol (EIGRP) route is placed in the hold-down state, use the ipx hold-down eigrp command in interface configuration mode. To restore the default time, use the no form of this command.
ipx hold-down eigrp autonomous-system-number seconds
no ipx hold-down eigrp autonomous-system-number seconds
Syntax Description
autonomous-system-number
Enhanced IGRP autonomous system number. It can be a number from 1 to 65,535.
seconds
Hold-down time, in seconds. The default hold time is 5 seconds.
Defaults
5 seconds
Command Modes
Interface configuration
Command History
Usage Guidelines
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.
Examples
The following example changes the hold-down time for autonomous system from 4 to 45 seconds:
interface ethernet 0ipx network 10ipx hold-down eigrp 4 45ipx hold-time eigrp
To specify the length of time for which a neighbor should consider Enhanced IGRP hello packets valid, use the ipx hold-time eigrp command in interface configuration mode. To restore the default time, use the no form of this command.
ipx hold-time eigrp autonomous-system-number seconds
no ipx hold-time eigrp autonomous-system-number seconds
Syntax Description
Defaults
For low-speed nonbroadcast, multiaccess (NBMA) networks: 180 seconds
For all other networks: 15 secondsCommand Modes
Interface configuration
Command History
Usage Guidelines
If the current value for the hold time is less than two times the interval between hello packets, the hold time will be reset to three times the hello interval.
If a router does not receive a hello packet within the specified hold time, routes through the router are considered available.
Increasing the hold time delays route convergence across the network.
The default of 180 seconds applies only to low-speed NBMA media. Low speed is considered to be a rate of T1 or slower, as specified with the bandwidth interface configuration command.
Examples
The following example changes the hold time to 45 seconds:
interface ethernet 0ipx network 10ipx hold-time eigrp 4 45Related Commands
ipx input-network-filter (RIP)
To control which networks are added to the Cisco IOS software routing table, use the ipx input-network-filter command in interface configuration mode. To remove the filter from the interface, use the no form of this command.
ipx input-network-filter {access-list-number | name}
no ipx input-network-filter {access-list-number | name}
Syntax Description
Defaults
No filters are predefined.
Command Modes
Interface configuration
Command History
Usage Guidelines
The ipx input-network-filter command controls which networks are added to the routing table based on the networks learned in incoming IPX routing updates (RIP updates) on the interface.
You can issue only one ipx input-network-filter command on each interface.
Examples
In the following example, access list 876 controls which networks are added to the routing table when IPX routing updates are received on Ethernet interface 1. Routing updates for network 1b will be accepted. Routing updates for all other networks are implicitly denied and are not added to the routing table.
access-list 876 permit 1binterface ethernet 1ipx input-network-filter 876The following example is a variation of the preceding that explicitly denies network 1a and explicitly allows updates for all other networks:
access-list 876 deny 1a access-list 876 permit -1Related Commands
ipx input-sap-filter
To control which services are added to the Cisco IOS software SAP table, use the ipx input-sap-filter command in interface configuration mode. To remove the filter, use the no form of this command.
ipx input-sap-filter {access-list-number | name}
no ipx input-sap-filter {access-list-number | name}
Syntax Description
Defaults
No filters are predefined.
Command Modes
Interface configuration
Command History
Usage Guidelines
The ipx input-sap-filter command filters all incoming service advertisements received by the router. This is done prior to accepting information about a service.
You can issue only one ipx input-sap-filter command on each interface.
When configuring SAP filters for NetWare 3.11 and later servers, use the server's internal network and node number (the node number is always 0000.0000.0001) as its address in the access-list (SAP filtering) command. Do not use the network.node address of the particular interface board.
Examples
The following example denies service advertisements about the server at address 3c.0800.89a1.1527, but accepts information about all other services on all other networks:
access-list 1000 deny 3c.0800.89a1.1527access-list 1000 permit -1!interface ethernet 0ipx input-sap-filter 1000Related Commands
ipx ipxwan error
To define how to handle IPX wide-area network (IPXWAN) when IPX fails to negotiate properly at link startup, use the ipx ipxwan error command in interface configuration mode. To restore the default, use the no form of this command.
ipx ipxwan error [reset | resume | shutdown]
no ipx ipxwan error [reset | resume | shutdown]
Syntax Description
Defaults
The link is reset.
Command Modes
Interface configuration
Command History
Usage Guidelines
Use the ipx ipxwan error command to define what action to take if the IPXWAN startup negotiation fails.
Examples
In the following example, the serial link will be shut down if the IPXWAN startup negotiation fails after three attempts spaced 20 seconds apart:
interface serial 0encapsulation pppipx ipxwanipx ipxwan error shutdownRelated Commands
ipx ipxwan
Enables the IPXWAN protocol on a serial interface.
Negotiates static routes on a link configured for IPXWAN.
ipx ipxwan static
To negotiate static routes on a link configured for IPX wide-area network (IPXWAN), use the ipx ipxwan static command in interface configuration mode. To disable static route negotiation, use the no form of this command.
ipx ipxwan static
no ipx ipxwan static
Syntax Description
This command has no arguments or keywords.
Defaults
Static routing is disabled.
Command Modes
Interface configuration
Command History
Usage Guidelines
When you specify the ipx ipxwan static command, the interface negotiates static routing on the link. If the router at the other side of the link is not configured to negotiate for static routing, the link will not initialize.
Examples
The following example enables static routing with IPXWAN:
interface serial 0encapsulation pppipx ipxwanipx ipxwan staticRelated Commands
ipx ipxwan
Enables the IPXWAN protocol on a serial interface.
Defines how to handle IPXWAN when IPX fails to negotiate properly at link startup.
ipx link-delay
To specify the link delay, use the ipx link-delay command in interface configuration mode. To return to the default link delay, use the no form of this command.
ipx link-delay microseconds
no ipx link-delay microseconds
Syntax Description
Defaults
No link delay (delay of 0).
Command Modes
Interface configuration
Command History
Usage Guidelines
The link delay you specify replaces the default value or overrides the value measured by IPXWAN when it starts.
Examples
The following example sets the link delay to 20 microseconds:
ipx link-delay 20Related Commands
ipx linkup-request (RIP)
To enable the sending of a general RIP and/or SAP query when an interface comes up, use the ipx linkup-request command in interface configuration mode. To disable the sending of a general RIP and/or SAP query when an interface comes up, use the no form of this command.
ipx linkup-request {rip | sap}
no ipx linkup-request {rip | sap}
Syntax Description
rip
Enables the sending of a general RIP query when an interface comes up.
sap
Enables the sending of a general SAP query when an interface comes up.
Defaults
General RIP and SAP queries are sent.
Command Modes
Interface configuration
Command History
Usage Guidelines
Under normal operation, when using serial or other point-to-point links, the router sends RIP and SAP information twice when an interface comes up. The RIP and SAP information is sent as soon as the link is up and is sent again when the router receives a general RIP query from the other end of the connection. By disabling the ipx linkup-request command, the router sends the RIP and SAP information once, instead of twice.
Examples
The following example configures the router to disable the general query for both RIP and SAP on serial interface 0:
interface serial 0no ipx linkup-request ripno ipx linkup-request sapRelated Commands
ipx update interval
Adjusts the RIP or SAP update interval.
ipx update sap-after-rip
Configures the router to send a SAP update immediately following a RIP broadcast.
ipx maximum-hops (RIP)
To set the maximum hop count allowed for IPX packets, use the ipx maximum-hops command in global configuration mode. To return to the default number of hops, use the no form of this command.
ipx maximum-hops hops
no ipx maximum-hops hops
Syntax Description
Defaults
16 hops
Command Modes
Global configuration
Command History
Usage Guidelines
Packets whose hop count is equal to or greater than that specified by the ipx maximum-hops command are dropped.
In periodic RIP updates, the Cisco IOS software never advertises any network with a hop count greater than 15. However, using protocols other than RIP, the software might learn routes that are farther away than 15 hops. The ipx maximum-hops command defines the maximum number of hops that the software will accept as reachable, as well as the maximum number of hops that an IPX packet can traverse before it is dropped by the software. Also, the software will respond to a specific RIP request for a network that is reachable at a distance of greater than 15 hops.
Examples
The following command configures the software to accept routes that are up to 64 hops away:
ipx maximum-hops 64ipx maximum-paths
To set the maximum number of equal-cost paths that the Cisco IOS software uses when forwarding packets, use the ipx maximum-paths command in global configuration mode. To restore the default value, use the no form of this command.
ipx maximum-paths paths
no ipx maximum-paths
Syntax Description
paths
Maximum number of equal-cost paths which the Cisco IOS software will use. It can be a number from 1 to 512. The default value is 1.
Defaults
1 path
Command Modes
Global configuration
Command History
Usage Guidelines
The ipx maximum-paths command increases throughput by allowing the software to choose among several equal-cost, parallel paths. (Note that when paths have differing costs, the software chooses lower-cost routes in preference to higher-cost routes.)
When per-host load sharing is disabled, IPX performs load sharing on a packet-by-packet basis in round-robin fashion, regardless of whether you are using fast switching or process switching. That is, the first packet is sent along the first path, the second packet along the second path, and so on. When the final path is reached, the next packet is sent to the first path, the next to the second path, and so on.
Limiting the number of equal-cost paths can save memory on routers with limited memory or with very large configurations. Additionally, in networks with a large number of multiple paths and systems with limited ability to cache out-of-sequence packets, performance might suffer when traffic is split between many paths.
When you enable per-host load sharing, IPX performs load sharing by transmitting traffic across multiple, equal-cost paths while guaranteeing that packets for a given end host always take the same path. Per-host load sharing decreases the possibility that successive packets to a given end host will arrive out of order.
With per-host load balancing, the number of equal-cost paths set by the ipx maximum-paths command must be greater than one; otherwise, per-host load sharing has no effect.
Examples
In the following example, the software uses up to three parallel paths:
ipx maximum-paths 3Related Commands
Sets the tick count.
ipx per-host-load-share
Enables per-host load sharing.
show ipx route
Displays the contents of the IPX routing table.
ipx netbios input-access-filter
To control incoming IPX NetBIOS FindName messages, use the ipx netbios input-access-filter command in interface configuration mode. To remove the filter, use the no form of this command.
ipx netbios input-access-filter {host | bytes} name
no ipx netbios input-access-filter {host | bytes} name
Syntax Description
Defaults
No filters are predefined.
Command Modes
Interface configuration
Command History
Usage Guidelines
You can issue only one ipx netbios input-access-filter host and one ipx netbios input-access-filter bytes command on each interface.
These filters apply only to IPX NetBIOS FindName packets. They have no effect on LLC2 NetBIOS packets.
Examples
The following example filters packets arriving on Token Ring interface 1 using the NetBIOS access list named engineering:
netbios access-list host engineering permit eng*netbios access-list host engineering deny manu*interface tokenring 1ipx netbios input-access-filter engineeringRelated Commands
ipx netbios output-access-filter
To control outgoing NetBIOS FindName messages, use the ipx netbios output-access-filter command in interface configuration mode. To remove the filter, use the no form of this command.
ipx netbios output-access-filter {host | bytes} name
no ipx netbios output-access-filter {host | bytes} name
Syntax Description
Defaults
No filters are predefined.
Command Modes
Interface configuration
Command History
Usage Guidelines
You can issue only one ipx netbios output-access-filter host and one ipx netbios output-access-filter bytes command on each interface.
These filters apply only to IPX NetBIOS FindName packets. They have no effect on LLC2 NetBIOS packets.
Examples
The following example filters packets leaving Token Ring interface 1 using the NetBIOS access list named engineering:
netbios access-list bytes engineering permit 20 AA**04interface token 1ipx netbios output-access-filter bytes engineeringRelated Commands
ipx netbios-socket-input-checks
To enable additional checks that are performed on Network Basic Input/Output System (NetBIOS) packets that do not conform fully to Novell Type20 NetBIOS packets, use the ipx netbios-socket-input-checks command in global configuration mode. To disable the additional checking, use the no form of this command.
ipx netbios-socket-input-checks
no ipx netbios-socket-input-checks
Syntax Description
This command has no arguments or keywords.
Defaults
Disabled
Command Modes
Global configuration
Command History
Usage Guidelines
When you use the ipx netbios-socket-input-checks command to enable additional checks on NetBIOS packets that do not fully conform to Novell Type20 NetBIOS packets, the same checks that are performed on Type20 packets to avoid broadcast loops are performed for any packet that does not have the netBIOS socket, even if it is not a Novell Type20 packet.
Note
Examples
The following example enables the additional checks on NetBIOS packets:
ipx netbios-socket-input-checksRelated Commands
ipx network
To enable IPX routing on a particular interface and to optionally select the type of encapsulation (framing), use the ipx network command in interface configuration mode. To disable IPX routing, use the no form of this command.
ipx network network [encapsulation encapsulation-type [secondary]]
no ipx network network [encapsulation encapsulation-type]
Syntax Description
network
Network number. This is an 8-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 AA.
encapsulation encapsulation-type
(Optional) Type of encapsulation (framing). For a list of possible encapsulation types, see Table 7.
secondary
(Optional) Indicates an additional (secondary) network configured after the first (primary) network.
Table 7 describes the types of encapsulation available for specific interfaces.
Defaults
IPX routing is disabled.
Encapsulation types:
For Ethernet: novell-ether
For Token Ring: sap
For FDDI: snap
For serial: hdlcIf you use NetWare Version 4.0 and Ethernet, you must change the default encapsulation type from novell-ether to sap.
Command Modes
Interface configuration
Command History
10.0
This command was introduced.
12.0(1)T
This command was modified to support the FDDI interface.
Usage Guidelines
The ipx network command allows you to configure a single logical network on a physical network or more than one logical network on the same physical network (network cable segment). Each network on a given interface must have a different encapsulation type.
Note
The first network you configure on an interface is considered to be the primary network. Any additional networks are considered to be secondary networks; these must include the secondary keyword.
Note
You can configure an IPX network on any supported interface as long as all the networks on the same physical interface use a distinct encapsulation type. For example, you can configure up to four IPX networks on a single Ethernet cable because Ethernet supports four encapsulation types.
The interface processes only packets with the correct encapsulation and the correct network number. IPX networks that use encapsulations can be present on the physical network. The only effect on the router is that it uses some processing time to examine packets to determine whether they have the correct encapsulation.
All logical networks on an interface share the same set of configuration parameters. For example, if you change the IPX RIP update time on an interface, you change it for all networks on that interface.
When you define multiple logical networks on the same physical network, IPX treats each encapsulation as if it were a separate physical network. This means, for example, that IPX sends RIP updates and SAP updates for each logical network.
The ipx network command is useful when migrating from one type of encapsulation to another. If you are using it for this purpose, you should define the new encapsulation on the primary network.
Note
To delete all networks on an interface, use the following command:
no ipx network
Deleting the primary network with the following command also deletes all networks on that interface. The argument number is the number of the primary network.
no ipx network number
To delete a secondary network on an interface, use one of the following commands. The argument number is the number of a secondary network.
no ipx network number
no ipx network number encapsulation encapsulation-type
Novell's FDDI_RAW encapsulation is common in bridged or switched environments that connect Ethernet-based Novell end hosts via a FDDI backbone. Packets with FDDI_RAW encapsulation are classified as Novell packets and are not automatically bridged when you enable both bridging and IPX routing. Additionally, you cannot configure FDDI_RAW encapsulation on an interface configured for IPX autonomous or silicon switching engine (SSE) switching. Similarly, you cannot enable IPX autonomous or SSE switching on an interface configured with FDDI_RAW encapsulation.
With FDDI_RAW encapsulation, platforms that do not use CBUS architecture support fast switching. Platforms using CBUS architecture support only process switching of novell-fddi packets received on an FDDI interface.
Examples
The following example uses subinterfaces to create four logical networks on Ethernet interface 0. Each subinterface has a different encapsulation. Any interface configuration parameters that you specify on an individual subinterface are applied to that subinterface only.
ipx routinginterface ethernet 0ipx network 1 encapsulation novell-etherinterface ethernet 0.1ipx network 2 encapsulation snapinterface ethernet 0.2ipx network 3 encapsulation arpainterface ethernet 0ipx network 4 encapsulation sapThe following example uses primary and secondary networks to create the same four logical networks as shown previously in this section. Any interface configuration parameters that you specify on this interface are applied to all the logical networks. For example, if you set the routing update timer to 120 seconds, this value is used on all four networks.
ipx routingipx network 1 encapsulation novell-etheripx network 2 encapsulation snap secondaryipx network 3 encapsulation arpa secondaryipx network 4 encapsulation sap secondaryThe following example enables IPX routing on FDDI interfaces 0.2 and 0.3. On FDDI interface 0.2, the encapsulation type is SNAP. On FDDI interface 0.3, the encapsulation type is Novell's FDDI_RAW.
ipx routinginterface fddi 0.2 enc sde 2ipx network f02 encapsulation snapinterface fddi 0.3 enc sde 3ipx network f03 encapsulation novell-fddiRelated Commands
Sets the Ethernet frame type of the interface to that of the local file server.
ipx routing
Enables IPX routing.
Posted: Tue Jul 24 02:28:12 PDT 2007
All contents are Copyright © 1992--2007 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.
