Полезная информация

cc/td/doc/product/software/ios120/12cgcr
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table of Contents

Configuring Novell IPX

Configuring Novell IPX

This chapter describes how to configure Novell Internet Packet Exchange (IPX) and provides configuration examples. For a complete description of the IPX commands in this chapter, refer to the "Novell IPX Commands" chapter in the Network Protocols Command Reference, Part 2. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

IPX Addresses

An IPX network address consists of a network number and a node number expressed in the format network.node.

Network Numbers

The network number identifies a physical network. It is a 4-byte (32-bit) quantity that must be unique throughout the entire IPX internetwork. The network number is expressed as hexadecimal digits. The maximum number of digits allowed is eight.

The Cisco IOS software does not require that you enter all eight digits; you can omit leading zeros.

Node Numbers

The node number identifies a node on the network. It is a 48-bit quantity, represented by dotted triplets of four-digit hexadecimal numbers.

If you do not specify a node number for a router to be used on WAN links, the Cisco IOS software uses the hardware Media Access Control (MAC) address currently assigned to it as its node address. This is the MAC address of the first Ethernet, Token Ring, or FDDI interface card. If there are no valid IEEE interfaces, then the Cisco IOS software randomly assigns a node number using a number that is based on the system clock.

IPX Address Example

The following is an example of an IPX network address:

4a.0000.0c00.23fe

In this example, the network number is 4a (more specifically, it is 0000004a), and the node number is 0000.0c00.23fe. All digits in the address are hexadecimal.

IPX Configuration Task List

To configure IPX routing, complete the tasks in the following sections. At a minimum, you must enable IPX routing. The remaining tasks are optional.

See the "Novell IPX Configuration Examples" section at the end of this chapter for configuration examples.

Enable IPX Routing

You enable IPX routing by first enabling it on the router and then configuring it on each interface.

Optionally, you can route IPX on some interfaces and transparently bridge it on other interfaces. You can also route IPX traffic between routed interfaces and bridge groups, or route IPX traffic between bridge groups.

IPX Default Routes

In IPX, a default route is the network where all packets for which the route to the destination address is unknown are forwarded.

Original RIP implementations allowed the use of network -2 (0xFFFFFFFE) as a regular network number in a network. With the inception of NLSP, network  -2 is reserved as the default route for NLSP and RIP. Both NLSP and RIP routers should treat network  -2 as a default route. Therefore, you should implement network -2 as the default route regardless of whether you configure NLSP in your IPX network.

By default, Cisco IOS software treats network -2 as the default route. You should ensure that your IPX network does not use network -2 as a regular network. If, for some reason, you must use network  -2 as a regular network, you can disable the default behavior. To do so, see the "Adjust Default Routes" section in this chapter.

For more background information on how to handle IPX default routes, refer to Novell's NetWare Link Services Protocol (NLSP) Specification, Revision 1.1.

Enable IPX Routing Task List

Complete the tasks in the following sections to enable IPX routing. The first two tasks are required; the rest are optional.

Enable IPX Routing

The first step in enabling IPX routing is to enable it on the router. If you do not specify the node number of the router to be used on WAN links, the Cisco IOS software uses the hardware Media Access Control (MAC) address currently assigned to it as its node address. This is the MAC address of the first Ethernet, Token Ring, or FDDI interface card. If there are no valid IEEE interfaces, then the Cisco IOS software randomly assigns a node number using a number that is based on the system clock.

To enable IPX routing, use the following global configuration command:
Command Purpose

ipx routing [node]

Enable IPX routing.

For an example of how to enable IPX routing, see the "IPX Routing Examples" section at the end of this chapter.

Caution If you plan to use DECnet and IPX routing concurrently on the same interface, you should enable DECnet routing 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 because DECnet forces a change in the MAC-level node number.

Assign Network Numbers to Individual Interfaces

After you have enabled IPX routing, you assign network numbers to individual interfaces. This enables IPX routing on those interfaces.

You enable IPX routing on interfaces that support a single network or on those that support multiple networks.

When you enable IPX routing on an interface, you can also specify an encapsulation (frame type) to use for packets being transmitted on that network. Table 8 lists the encapsulation types you can use on IEEE interfaces and shows the correspondence between Cisco naming conventions and Novell naming conventions for the encapsulation types.


Table 8: Cisco and Novell IPX Encapsulation Names on IEEE Interfaces
Interface Type Cisco Name Novell Name

Ethernet

novell-ether (Cisco IOS default)
arpa
sap
snap

Ethernet_802.3
Ethernet_II
Ethernet_802.2
Ethernet_Snap

Token Ring

sap (Cisco IOS default)
snap

Token-Ring
Token-Ring_Snap

FDDI

snap (Cisco IOS default)
sap
novell-fddi

Fddi_Snap
Fddi_802.2
Fddi_Raw

Assign Network Numbers to Individual Interfaces Task List

The following sections describe how to enable IPX routing on interfaces that support a single network and on those that support multiple networks. You must perform one of the tasks to enable IPX routing on an interface:

Assign Network Numbers to Interfaces That Support a Single Network

A single interface can support a single network or multiple logical networks. For a single network, you can configure any encapsulation type. Of course, it should match the encapsulation type of the servers and clients using that network number.

To assign a network number to an interface that supports a single network, use the following interface configuration command:
Command Purpose

ipx network network [encapsulation encapsulation-type]

Enable IPX routing on an interface.

If you specify an encapsulation type, be sure to choose the one that matches the one used by the servers and clients on that network. Refer to Table 8 for a list of encapsulation types you can use on IEEE interfaces.

For an example of how to enable IPX routing, see the "IPX Routing Examples" section at the end of this chapter.

Assign Network Numbers to Interfaces That Support Multiple Networks

When assigning network numbers to an interface that supports multiple networks, you must specify a different encapsulation type for each network. Because multiple networks share the physical medium, this allows the Cisco IOS software to identify the packets that belong to each network. For example, you can configure up to four IPX networks on a single Ethernet cable, because four encapsulation types are supported for Ethernet. Again, the encapsulation type should match the servers and clients using the same network number. Refer to Table 8 for a list of encapsulation types you can use on IEEE interfaces.

There are two ways to assign network numbers to interfaces that support multiple networks. You can use subinterfaces or primary and secondary networks.

Subinterfaces

You typically use subinterfaces to assign network numbers to interfaces that support multiple networks.

A subinterface is a mechanism that allows a single physical interface to support multiple logical interfaces or networks. That is, several logical interfaces or networks can be associated with a single hardware interface. Each subinterface must use a distinct encapsulation, and the encapsulation must match that of the clients and servers using the same network number.


Note When enabling NLSP and configuring multiple encapsulations on the same physical LAN interface, you must use subinterfaces. You cannot use secondary networks.

Any interface configuration parameters that you specify on an individual subinterface are applied to that subinterface only.

To configure multiple IPX networks on a physical interface using subinterfaces, use the following commands, starting in global configuration mode:
Step Command Purpose

1 . 

interface type number.subinterface-number

Specify a subinterface.

2 . 

ipx network network [encapsulation encapsulation-type]

Enable IPX routing, specifying the first encapsulation type.

To configure more than one subinterface, repeat these two steps. Refer to Table 8 for a list of encapsulation types you can use on IEEE interfaces.

For examples of configuring multiple IPX networks on an interface, see the "IPX Routing on Multiple Networks Examples" section at the end of this chapter.

Primary and Secondary Networks

When assigning network numbers to interfaces that support multiple networks, you can also configure primary and secondary networks.


Note In future Cisco IOS software releases, primary and secondary networks will not be supported.

The first logical network you configure on an interface is considered the primary network. Any additional networks are considered secondary networks. Again, each network on an interface must use a distinct encapsulation and it should match that of the clients and servers using the same network number.

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 use primary and secondary networks to configure multiple IPX networks on an interface, use the following commands in interface configuration mode:
Step Command Purpose

1 . 

ipx network network [encapsulation encapsulation-type]

Enable IPX routing on the primary network.

2 . 

ipx network network [encapsulation encapsulation-type] [secondary]

Enable IPX routing on a secondary network.

To configure more than one secondary network, repeat as appropriate. Refer to Table 8 for a list of encapsulation types you can use on IEEE interfaces.


Note When enabling NLSP and configuring multiple encapsulations on the same physical LAN interface, you must use subinterfaces. You cannot use secondary networks.

Enable Concurrent Routing and Bridging

You can route IPX on some interfaces and transparently bridge it on other interfaces simultaneously. To do this, you must enable concurrent routing and bridging. To enable concurrent routing and bridging, use the following command in global configuration mode:
Command Purpose

bridge crb

Enable concurrent routing and bridging.

Configure Integrated Routing and Bridging

Integrated routing and bridging (IRB) enables a user to route IPX traffic between routed interfaces and bridge groups, or route IPX traffic between bridge groups. Specifically, local or unroutable traffic is bridged among the bridged interfaces in the same bridge group. Routable traffic is routed to other routed interfaces or bridge groups. Using IRB, you can do the following:

For more information about configuring integrated routing and bridging, refer to the "Configuring Transparent Bridging" chapter in the Bridging and IBM Networking Configuration Guide.

Configure IPX Enhanced IGRP

Enhanced IGRP is an enhanced version of the Interior Gateway Routing Protocol (IGRP) developed by Cisco Systems, Inc. Enhanced IGRP uses the same distance vector algorithm and distance information as IGRP. However, the convergence properties and the operating efficiency of Enhanced IGRP have improved significantly over IGRP.

The convergence technology is based on research conducted at SRI International and employs an algorithm referred to as the Diffusing Update Algorithm (DUAL). This algorithm guarantees loop-free operation at every instant throughout a route computation, and allows all routers involved in a topology change to synchronize at the same time. Routers that are not affected by topology changes are not involved in recomputations. The convergence time with DUAL rivals that of any other existing routing protocol.

Enhanced IGRP Features

Enhanced IGRP offers the following features:

Enhanced IGRP Components

Enhanced IGRP has four basic components discussed in the following sections:

Neighbor Discovery/Recovery

Neighbor discovery/recovery is the process that routers use to dynamically learn of other routers on their directly attached networks. Routers must also discover when their neighbors become unreachable or inoperative. Neighbor discovery/recovery is achieved with low overhead by periodically sending small hello packets. As long as hello packets are received, a router can determine that a neighbor is alive and functioning. Once this status is determined, the neighboring devices can exchange routing information.

Reliable Transport Protocol

The reliable transport protocol is responsible for guaranteed, ordered delivery of Enhanced IGRP packets to all neighbors. It supports intermixed transmission of multicast and unicast packets. Some Enhanced IGRP packets must be transmitted reliably, and others need not be. For efficiency, reliability is provided only when necessary. For example, on a multiaccess network that has multicast capabilities (such as Ethernet) it is not necessary to send hellos reliably to all neighbors individually. Therefore, Enhanced IGRP sends a single multicast hello with an indication in the packet informing the receivers that the packet need not be acknowledged. Other types of packets (such as updates) require acknowledgment, and this is indicated in the packet. The reliable transport has a provision to send multicast packets quickly when there are unacknowledged packets pending. Doing so helps ensure that convergence time remains low in the presence of varying speed links.

DUAL Finite-State Machine

The DUAL finite-state machine embodies the decision process for all route computations. It tracks all routes advertised by all neighbors. DUAL uses the distance information (known as a metric) to select efficient, loop-free paths. DUAL selects routes to be inserted into a routing table based on feasible successors. A successor is a neighboring router used for packet forwarding that has a least-cost path to a destination that is guaranteed not to be part of a routing loop. When there are no feasible successors but there are neighbors advertising the destination, a recomputation must occur. This is the process whereby a new successor is determined. The amount of time it takes to recompute the route affects the convergence time. Recomputation is processor-intensive. It is advantageous to avoid recomputation if it is not necessary. When a topology change occurs, DUAL will test for feasible successors. If there are feasible successors, it will use any it finds in order to avoid unnecessary recomputation.

Protocol-Dependent Modules

The protocol-dependent modules are responsible for network layer protocol-specific tasks. They are also responsible for parsing Enhanced IGRP packets and informing DUAL of the new information received. Enhanced IGRP asks DUAL to make routing decisions, but the results are stored in the IPX routing table. Also, Enhanced IGRP is responsible for redistributing routes learned by other IPX routing protocols.

Configure IPX Enhanced IGRP Task List

To enable IPX Enhanced IGRP, complete the tasks in the following sections. Only the first task is required; the remaining tasks are optional.

Enable IPX Enhanced IGRP

To create an IPX Enhanced IGRP routing process, use the following commands:
Step Command Purpose

1 . 

ipx router eigrp autonomous-system-number

Enable an Enhanced IGRP routing process in global configuration mode.

2 . 

network {network-number | all}

Enable Enhanced IGRP on a network in IPX router configuration mode.

To associate multiple networks with an Enhanced IGRP routing process, you can repeat the preceding two steps.

For an example of how to enable Enhanced IGRP, see the "IPX Enhanced IGRP Example" section at the end of this chapter.

Customize Link Characteristics

You might want to customize the Enhanced IGRP link characteristics. The following sections describe these customization tasks:

Configure the Percentage of Link Bandwidth Used by Enhanced IGRP

By default, Enhanced IGRP packets consume a maximum of 50 percent of the link bandwidth, as configured with the bandwidth interface subcommand. If a different value is desired, use the ipx bandwidth-percent command. This command may be useful if a different level of link utilization is required, or if the configured bandwidth does not match the actual link bandwidth (it may have been configured to influence route metric calculations).

To configure the percentage of bandwidth that may be used by Enhanced IGRP on an interface, use the following command in interface configuration mode:
Command Purpose

ipx bandwidth-percent eigrp as-number percent

Configure the percentage of bandwidth that may be used by Enhanced IGRP on an interface.

For an example of how to configure the percentage of Enhanced IGRP bandwidth, see the "IPX Enhanced IGRP Bandwidth Configuration Example" section at the end of this chapter.

Configure Maximum Hop Count


Note While adjusting the maximum hop count is possible, it is not recommended for Enhanced IGRP. We recommend that you use the default value for the maximum hop count of Enhanced IGRP.

By default, IPX packets whose hop count exceeds 15 are discarded. In larger internetworks, this may be insufficient. You can increase the hop count to a maximum of 254 hops for Enhanced IGRP. To modify the maximum hop count, use the following command in global configuration mode:
Command Purpose

ipx maximum-hops hop

Set the maximum hop count accepted from RIP update packets.

 

Adjust the Interval Between Hello Packets and the Hold Time

You can adjust the interval between hello packets and the hold time.

Routers periodically send hello packets to each other to dynamically learn of other devices on their directly attached networks. Routers use this information to discover who their neighbors are and to discover when their neighbors become unreachable or inoperative.

By default, hello packets are sent every 5 seconds. The exception is on low-speed, nonbroadcast, multiaccess (NBMA) media, where the default hello interval is 60 seconds. Low speed is considered to be a rate of T1 or slower, as specified with the bandwidth interface configuration command. The default hello interval remains 5 seconds for high-speed NBMA networks.


Note For the 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.

You can configure the hold time on a specified interface for a particular Enhanced IGRP routing process designated by the autonomous system number. The hold time is advertised in hello packets and indicates to neighbors the length of time they should consider the sender valid. The default hold time is 3 times the hello interval, or 15 seconds.

To change the interval between hello packets, use the following command in interface configuration mode:
Command Purpose

ipx hello-interval eigrp autonomous-system-number seconds

Set the interval between hello packets.

On very congested and large networks, 15 seconds may not be sufficient time for all routers to receive hello packets from their neighbors. In this case, you may want to increase the hold time. To do this, use the following command in interface configuration mode:
Command Purpose

ipx hold-time eigrp autonomous-system-number seconds

Set the hold time.


Note Do not adjust the hold time without consulting with Cisco technical support.

Customize the Exchange of Routing and Service Information

You might want to customize the exchange of routing and service information. The following sections describe these customization tasks:

Redistribute Routing Information

By default, the Cisco IOS software redistributes IPX RIP routes into Enhanced IGRP, and vice versa.

To disable route redistribution, use the following command in IPX router configuration mode:
Command Purpose

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

Disable redistribution of RIP routes into Enhanced IGRP and Enhanced IGRP routes into RIP.

The Cisco IOS software does not automatically redistribute NLSP routes into Enhanced IGRP routes and vice versa. You must configure this type of redistribution. To do so, use the following commands, starting in global configuration mode:
Step Command Purpose

1 . 

ipx router eigrp autonomous-system-number

From global configuration mode, enable Enhanced IGRP.

2 . 

redistribute nlsp [tag]

From IPX-router configuration mode, enable redistribution of NLSP into Enhanced IGRP.

3 . 

ipx router nlsp [tag]

Enable NLSP.

4 . 

redistribute eigrp autonomous-system-number

From IPX-router configuration mode, enable redistribution of Enhanced IGRP into NLSP.

For an example of how to enable redistribution of Enhanced IGRP and NLSP, see the "Enhanced IGRP and NLSP Route Redistribution Example" section at the end of this chapter.

Disable Split Horizon

Split horizon controls the sending of Enhanced IGRP update and query packets. If split horizon is enabled on an interface, these packets are not sent for destinations if this interface is the next hop to that destination.

By default, split horizon is enabled on all interfaces.

Split horizon blocks information about routes from being advertised by the Cisco IOS software 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 can disable split horizon.

To disable split horizon, use the following command in interface configuration mode:
Command Purpose

no ipx split-horizon eigrp autonomous-system-number

Disable split horizon.


Note Split horizon cannot be disabled for RIP or SAP, only for Enhanced IGRP.

Control the Advertising of Routes in Routing Updates

To control which devices learn about routes, you can control the advertising of routes in routing updates. To do this, use the following command in router configuration mode:
Command Purpose

distribute-list access-list-number out [interface-name |
routing
-process]

Control the advertising of routes in routing updates.

Control the Processing of Routing Updates

To control the processing of routes listed in incoming updates, use the following command in router configuration mode:
Command Purpose

distribute-list access-list-number in [interface-name]

Control which incoming route updates are processed.

Control SAP Updates

If IPX Enhanced IGRP peers are found on an interface, you can configure the Cisco IOS software to send SAP updates either periodically or when a change occurs in the SAP table. When no IPX Enhanced IGRP peer is present on the interface, periodic SAPs are always sent.

On serial lines, by default, if an Enhanced IGRP neighbor is present, the Cisco IOS software sends SAP updates only when the SAP table changes. On Ethernet, Token Ring, and FDDI interfaces, by default, the software sends SAP updates periodically. To reduce the amount of bandwidth required to send SAP updates, you might want to disable the periodic sending of SAP updates on LAN interfaces. Do this only when all nodes out this interface are Enhanced IGRP peers; otherwise, loss of SAP information on the other nodes will result.

To send SAP updates only when a change occurs in the SAP table and to send only the SAP changes, use the following command in interface configuration mode:
Command Purpose

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

Send SAP updates only when a change in the SAP table occurs, and send only the SAP changes.

When you enable incremental SAP using the ipx sap-incremental eigrp rsup-only command, Cisco IOS software disables the exchange of route information via Enhanced IGRP for that interface.

To send periodic SAP updates, use the following command in interface configuration mode:
Command Purpose

no ipx sap-incremental eigrp autonomous-system-number

Send SAP updates periodically.

For an example of how to configure SAP updates, see the "Enhanced IGRP SAP Update Examples" section at the end of this chapter.

To disable split horizon for incremental SAP, use the following command in interface configuration mode:
Command Purpose

no ipx sap-incremental split-horizon

Disable split horizon for SAP.


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

Control the Advertising of Services in SAP Updates

To control which devices learn about services, you can control the advertising of these services in SAP updates. To do this, use the following command in router configuration mode:
Command Purpose

distribute-sap-list access-list-number out [interface-name | routing-process]

Control the advertising of services in SAP updates.

For a configuration example of controlling the advertisement of SAP updates, see the "Advertisement and Processing of SAP Update Examples" section at the end of this chapter.

Control the Processing of SAP Updates

To control the processing of routes listed in incoming updates, use the following command in router configuration mode:
Command Purpose

distribute-sap-list access-list-number in [interface-name]

Control which incoming SAP updates are processed.

For a configuration example of controlling the processing of SAP updates, see the "Advertisement and Processing of SAP Update Examples" section at the end of this chapter.

Query the Backup Server

The backup server table is a table kept for each Enhanced IGRP peer. It lists the IPX servers that have been advertised by that peer. If a server is removed from the main server table at any time and for any reason, the Cisco IOS software examines the backup server table to see if this just-removed server is known by any of the Enhanced IGRP peers. If it is, the information from that peer is advertised back into the main server table just as if that peer had readvertised the server information to this router. Using this method to allow the router to keep the backup server table consistent with what is advertised by each peer means that only changes to the table must be advertised between Enhanced IGRP routers; full periodic updates do not need to be sent.

By default, the Cisco IOS software queries its own copy of each Enhanced IGRP neighbor's backup server table every 60  seconds. To change this interval, use the following command in global configuration mode:
Command Purpose

ipx backup-server-query-interval interval

Specify the minimum period of time between successive queries of a neighbor's backup server table.

Configure NLSP

The NetWare Link Services Protocol (NLSP) is a link-state routing protocol based on the Open System Interconnection (OSI) Intermediate System to Intermediate System (IS-IS) protocol.

NLSP is designed to be used in a hierarchical routing environment, in which networked systems are grouped into routing areas. Routing areas can then be grouped into routing domains, and domains can be grouped into an internetwork.

Understand Level 1, 2, and 3 Routers

Level 1 routers connect networked systems within a given routing area. Areas are connected to each other by Level 2 routers, and domains are connected by Level 3 routers. A Level  2 router also acts as a Level 1 router within its own area; likewise, a Level 3 router also acts as a Level  2 router within its own domain.

The router at each level of the topology stores complete information for its level. For instance, Level  1 routers store complete link-state information about their entire area. This information includes a record of all the routers in the area, the links connecting them, the operational status of the devices and their links, and other related parameters. For each point-to-point link, the database records the end-point devices and the state of the link. For each LAN, the database records which routers are connected to the LAN. Similarly, Level 2 routers would store information about all the areas in the routing domain, and Level 3 routers would store information about all the domains in the internetwork.

Although NLSP is designed for hierarchical routing environments containing Level 1, 2, and 3 routers, only Level 1 routing with area route aggregation and route redistribution has been defined in a specification.

Understand NLSP Databases

NLSP is a link-state protocol. This means that every router in a routing area maintains an identical copy of the link-state database, which contains all information about the topology of the area. All routers synchronize their views of the databases among themselves to keep their copies of the link-state databases consistent. NLSP has the following three major databases:

Cisco Support of NLSP

Cisco's implementation of NLSP supports the Novell NLSP specification, version 1.1. Our implementation of NLSP also includes read-only NLSP MIB variables.

Configure NLSP Task List

To configure NLSP, you must have configured IPX routing on your router, as described previously in this chapter. Then, you must perform the tasks described in the following sections:

You can optionally perform the tasks described in the following sections:

For an example of enabling NLSP, see the "IPX Routing Protocols Examples" section at the end of this chapter.

Define an Internal Network

An internal network number is an IPX network number assigned to the router. For NLSP to operate, you must configure an internal network number for each device.

To enable IPX routing and to define an internal network number, use the following commands in global configuration mode:
Step Command Purpose

1 . 

ipx routing

Enable IPX routing.

2 . 

ipx internal-network network-number

Define an internal network number.

Enable NLSP Routing

To enable NLSP, use the following commands, starting in global configuration mode:
Step Command Purpose

1 . 

ipx router nlsp [tag]

Enable NLSP.

2 . 

area-address address mask

Define a set of network numbers to be part of the current NLSP area.

Configure NLSP on an Interface

You configure NLSP differently on LAN and WAN interfaces, as described in the following sections:

Configure NLSP on a LAN Interface

To configure NLSP on a LAN interface, use the following commands in interface configuration mode:
Step Command Purpose

1 . 

ipx network network [encapsulation encapsulation-type]

Enable IPX routing on an interface.

2 . 

ipx nlsp [tag] enable

Enable NLSP on the interface.

To configure multiple encapsulations on the same physical LAN interfaces, you must configure subinterfaces. Each subinterface must have a different encapsulation type. To do this, use the following commands, starting in global configuration mode:
Step Command Purpose

1 . 

interface type number.subinterface-number

Specify a subinterface.

2 . 

ipx network network [encapsulation encapsulation-type]

Enable IPX routing, specifying the first encapsulation type.

3 . 

ipx nlsp [tag] enable

Enable NLSP on the subinterface.

Repeat these three steps for each subinterface.


Note When enabling NLSP and configuring multiple encapsulations on the same physical LAN interface, you must use subinterfaces. You cannot use secondary networks.

Configure NLSP on a WAN Interface

To configure NLSP on a WAN interface, use the following commands, starting in global configuration mode:
Step Command Purpose

1 . 

interface serial number

Specify a serial interface.

2 . 

ipx ipxwan [local-node unnumbered local-server-name retry-interval retry-limit]

Enable IPXWAN.

3 . 

ipx nlsp [tag] enable

Enable NLSP on the interface.

Customize Link Characteristics

You might want to customize the NLSP link characteristics. The following sections describe these customization tasks:

Enable NLSP Multicast Addressing

Cisco IOS supports the use of NLSP multicast addressing for Ethernet, Token Ring, and FDDI router interfaces. This capability is only possible when the underlying Cisco hardware device or driver supports multicast addressing.

With this feature, the router defaults to using multicasts on Ethernet, Token Ring, and FDDI interfaces, instead of broadcasts, to address all NLSP routers on the network. If an adjacent neighbor does not support NLSP multicasting, the router will revert to using broadcasts on the affected interface.

This feature is only available on routers running Cisco IOS Release 11.3 or later software. When routers running prior versions of Cisco IOS software are present on the same network with routers running Cisco IOS Release 11.3 software, broadcasts will be used on any segment shared by the two routers.

Benefits of NLSP Multicast Addressing

The NLSP multicast addressing offers the following benefits:

Enable NLSP Multicast Addressing Task List

The following sections describe configuration tasks associated with the NLSP multicast addressing:

Enable NLSP Multicast Addressing

By default, NLSP multicast addressing is enabled. You do not need to configure anything to turn on NLSP multicasting.

Disable NLSP Multicast Addressing

Typically, you do not want to substitute broadcast addressing where NLSP multicast addressing is available. NLSP multicast addressing uses network bandwidth more efficiently than broadcast addressing. However, there are circumstances where you might want to disable NLSP multicast addressing.

For example, you might want to disable NLSP multicast addressing in favor of broadcast addressing when one or more devices on a segment do not support NLSP multicast addressing. You might also want to disable it for testing purposes.

If you want to disable NLSP multicast addressing, you can do so for the entire router or for a particular interface.

To disable multicast addressing for the entire router, use the following commands in IPX-router configuration mode:
Step Command Purpose

1 . 

ipx router nlsp

Enter NLSP router configuration mode.

2 . 

no multicast

Disable NLSP multicast addressing on the router.

To disable multicast addressing on a particular router interface, use the following command in interface configuration mode:
Command Purpose

no ipx nlsp [tag] multicast

Disable multicast addressing on the interface.

For examples of how to disable NLSP multicast addressing, see the "NLSP Multicast Addressing Examples" section at the end of this chapter.

Configure the Metric Value

NLSP assigns a default link cost (metric) based on the link throughput. If desired, you can set the link cost manually.

Typically, you do not need to set the link cost manually; however, there are some cases where you might want to. For example, in highly redundant networks, you might want to favor one route over another for certain kinds of traffic. As another example, you might want to ensure load sharing. Changing the metric value can help achieve these design goals.

To set the NLSP link cost for an interface, use the following command in interface configuration mode:
Command Purpose

ipx nlsp [tag] metric metric-number

Set the metric value for an interface.

 

Configure the Link Delay and Throughput

The delay and throughput of each link are used by NLSP as part of its route calculations. By default, these parameters are set to appropriate values or, in the case of IPXWAN, are dynamically measured.

Typically, you do not need to change the link delay and throughput; however, there are some cases where you might want to change these parameters. For example, in highly redundant networks, you might want to favor one route over another for certain kinds of traffic. To do this, you would change the metric on the less-desirable path to be slightly worse, by assigning it a higher metric value using the ipx-link-delay command. This forces the traffic to route over the favorable path. As another example, you might want to ensure load sharing. To load share, you would ensure that the metrics on the equal paths are the same.

The link delay and throughput 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.

To change the link delay, use the following command in interface configuration mode:
Command Purpose

ipx link-delay microseconds

Specify the link delay.

To change the throughput, use the following command in interface configuration mode:
Command Purpose

ipx throughput bits-per-second

Specify the throughput.

Configure the Maximum Hop Count

By default, IPX packets whose hop count exceeds 15 are discarded. In larger internetworks, this may be insufficient. You can increase the hop count to a maximum of 127 hops for NLSP.

For example, if you have a network with end nodes separated by more than 15 hops, you can set the maximum hop count to a value between 16 and 127.

To modify the maximum hop count, use the following command in global configuration mode:
Command Purpose

ipx maximum-hops hop

Set the maximum hop count accepted from RIP update packets.

 

Specify a Designated Router


Note In the context of this discussion, the term designated router can refer to an access server or a router.

NLSP elects a designated router on each LAN interface. The designated router represents all routers that are connected to the same LAN segment. It creates a virtual router called a pseudonode, which generates routing information on behalf of the LAN and transmits it to the remainder of the routing area. The routing information generated includes adjacencies and RIP routes. The use of a designated router significantly reduces the number of entries in the LSP database.

By default, electing a designated router is done automatically. However, you can manually affect the identity of the designated router by changing the priority of the system; the system with the highest priority is elected to be the designated router.

By default, the priority of the system is 44. To change it, use the following command in interface configuration mode:
Command Purpose

ipx nlsp [tag] priority priority-number

Configure the designated router election priority.

Configure Transmission and Retransmission Intervals

You can configure the hello transmission interval and holding time multiplier, the complete sequence number PDU (CSNP) transmission interval, the LSP transmission interval, and the LSP retransmission interval.

The hello transmission interval and holding time multiplier used together determine how long a neighboring system should wait after a link or system failure (the "holding time") before declaring this system to be unreachable. The holding time is equal to the hello transmission interval multiplied by the holding time multiplier.

To configure the hello transmission interval on an interface, use the following command in interface configuration mode:
Command Purpose

ipx nlsp [tag] hello-interval seconds

Configure the hello transmission interval.

To specify the holding time multiplier used on an interface, use the following command in interface configuration mode:
Command Purpose

ipx nlsp [tag] hello-multiplier multiplier

Configure the hello multiplier.

Although not typically necessary, you can configure the CSNP transmission interval. To do so, use the following command in interface configuration mode:
Command Purpose

ipx nlsp [tag] csnp-interval seconds

Configure the CSNP transmission interval.

You can specify how fast LSPs can be flooded out an interface by configuring the LSP transmission interval. To configure the LSP transmission interval, use the following command in interface configuration mode:
Command Purpose

ipx nlsp [tag] lsp-interval interval

Configure the LSP transmission interval.

You can set the maximum amount of time that can pass before an LSP will be retransmitted on a WAN link when no acknowledgment is received. To configure this LSP retransmission interval, use the following command in interface configuration mode:
Command Purpose

ipx nlsp [tag] retransmit-interval seconds

Configure the LSP retransmission interval.

Modify Link-State Packet Parameters

To modify link-state packet (LSP) parameters, use one or more of the following commands in router configuration mode:
Command Purpose

lsp-gen-interval seconds

Set the minimum LSP generation interval.

max-lsp-lifetime [hours] value

Set the maximum time the LSP persists.

lsp-refresh-interval seconds

Set the LSP refresh time.

lsp-mtu bytes

Set the maximum size of a link-state packet.

spf-interval seconds

Set the minimum time between SPF calculations.

Limit Partial Route Calculations

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

To modify the partial route calculation, use the following command in router configuration mode:
Command Purpose

prc-interval seconds

Set the holddown period between partial route calculations.

Configure Route Aggregation

Prior to Cisco IOS Release 11.1, you could segregate IPX internetworks into distinct NLSP areas only by interconnecting them with IPX RIP. With Release 11.1 or later software, you can easily perform the following tasks:

In this document, these independent capabilities are known collectively as the route aggregation feature. Cisco has designed the route aggregation feature to be compatible with Novell's NetWare Link Services Protocol (NLSP) Specification, Revision 1.1.


Note In the sections that follow, "NLSP version 1.1 routers" refers to routers that support the route aggregation feature, while "NLSP version 1.0 routers" refers to routers that do not. Additionally, all NLSP instances configured on a router running Release 11.1 are NLSP 1.1 instances. They are all capable of generating and using aggregated routes. However, in the text and examples that follow, an "NLSP 1.0 instance" refers to an instance of NLSP that is in an area that includes NLSP version 1.0 routers.

Benefits of Route Summarization

NLSP route summarization provides the following benefits to well-designed IPX networks:

As a result, you can build larger IPX networks using route aggregation.

Understand Area Addresses, Route Summaries, and Aggregated Routes

This section discusses area addresses, route summaries, and aggregated routes. It also describes how area addresses relate to route summaries.

Area Addresses

An area address uniquely identifies an NLSP area. The area addresses configured on each router determine the areas to which a router belongs.

An area address consists of a pair of 32-bit hexadecimal numbers that include an area number and a corresponding mask. The mask indicates how much of the area number identifies the area, and how much identifies individual networks in the area. For example, the area address pair 12345600  FFFFFF00 describes an area composed of 256 networks in the range 12345600 to 123456FF.

You can configure up to three area addresses per NLSP process on the router. Adjacencies are formed only between routers that share at least one common area address.

Route Summaries

A route summary defines a set of explicit routes that the router uses to generate an aggregated route. A route summary tells the router how to summarize the set of explicit routes into a single summarized route.

A route summary is similar in form to an area address. That is, the route summary described by 12345600  FFFFFF00 summarizes the 256 networks in the range 12345600 to 123456FF.

Aggregated Routes

An aggregated route is the single, compact data structure that describes many IPX network numbers simultaneously. The aggregated route represents all the explicit routes defined by the route summary. In an LSP, the router expresses an aggregated route as a 1-byte number that gives the length, in bits, of the portion of the 32-bit network number common to all summarized addresses. The aggregated route for 12345600  FFFFFF00 is 18 12345600.

Relationship between Area Addresses and Route Summaries

When you enable route summarization in Release 11.1 while running multiple instances of NLSP, the router performs default route summarization based on the area address configured in each NLSP area. That is, explicit routes that match the area address in a given area are not redistributed individually into neighboring NLSP areas. Instead, the router redistributes a single aggregated route that is equivalent to the area address into neighboring areas.

Understand NLSP Areas

This section describes single versus multiple NLSP areas and discusses the router's behavior when you mix NLSP versions within a single NLSP area.

Single Versus Multiple NLSP Areas

NLSP version 1.0 routers support only a single, Level 1 area. Two routers form an adjacency only if they share at least one configured area address in common. The union of routers with adjacencies in common form an area.

Each router within the NLSP area has its own adjacencies, link-state, and forwarding databases. Further, each router's link-state database is identical. Within the router, these databases operate collectively as a single process or instance to discover, select, and maintain route information about the area. NLSP version 1.0 routers and NLSP version 1.1 routers that exist within a single area use a single NLSP instance.

With NLSP version 1.1 and Cisco IOS Release 11.1, multiple instances of NLSP may exist on a given router. Each instance discovers, selects, and maintains route information for a separate NLSP area. Each instance has its own copy of the NLSP adjacency and link state database for its area. However, all instances (along with other routing protocols such as RIP and Enhanced IGRP) share a single copy of the forwarding table.

Mixing NLSP Versions in a Single Area

You can have NLSP version 1.1 routers and NLSP version 1.0 routers in the same area. However, NLSP version 1.0 routers do not recognize aggregated routes. For this reason, the default behavior of Cisco IOS Release 11.1 software is to not generate aggregated routes. To prevent routing loops in a mixed environment, packets routed via an aggregated route by an NLSP version 1.1 router are dropped if the next hop is an NLSP version 1.0 router.


Note In general, you should ensure that all routers in an area are running NLSP version 1.1-capable software before you enable route summarization on any of the routers in an area.

Understand Route Redistribution

Because you can configure multiple NLSP areas, you must understand how the router passes route information from one area to another. Passing route information from one area to another, or from one protocol to another, is known as route redistribution. Additionally, you must understand the router's default route redistribution behavior before configuring route summarization.

This section describes the default route redistribution behavior between multiple NLSP areas, between NLSP and Enhanced IGRP, and between NLSP and RIP.

Default Redistribution between Multiple NLSP Areas

Regardless of the NLSP version, Cisco IOS Release 11.1 redistributes routes between multiple NLSP areas by default. That is, redistribution between multiple NLSP version 1.1 areas, between multiple NLSP version 1.0 areas, and between NLSP version 1.1 and NLSP version 1.0 areas is enabled by default. All routes are redistributed as individual, explicit routes.

Default Redistribution between NLSP and Enhanced IGRP

Route redistribution between instances of NLSP (version 1.1 or version 1.0) and Enhanced IGRP is disabled by default. You must explicitly configure this type of redistribution. Refer to the "Redistribute Routing Information" section in this chapter for information about configuring redistribution between NLSP and Enhanced IGRP.

Default Redistribution between NLSP and RIP

Route redistribution between instances of NLSP (version 1.1 or version 1.0) and RIP is enabled by default. All routes are redistributed as individual, explicit routes.

Understand Route Summarization

Route summarization is disabled by default to avoid the generation of aggregated routes in an area running mixed versions of NLSP. You can explicitly enable route summarization on a router running Cisco  IOS Release 11.1. This section describes default route summarization, customized route summarization, and the relationship between filtering and route summarization.

Default Route Summarization

When you explicitly enable route summarization, the default route summarization depends on the following circumstances:

In the case of the first two circumstances, the area address for each NLSP instance is used as the basis for generating aggregated routes. That is, all explicit routes that match a local area address generate a common aggregated route. The router redistributes only the aggregated route into other NLSP areas; explicit routes (and more specific aggregated routes) represented by a particular aggregated route are filtered.


Note The router continues to redistribute into other areas the explicit routes that do not match the area address.
Customized Route Summarization

You can also customize the router's route summarization behavior using the redistribute IPX-router subcommand with an access list. The access list specifies in detail which routes to summarize and which routes to redistribute explicitly. In this case, the router ignores area addresses and uses only the access list as a template to control summarization and redistribution. You can use numbered or named access lists to control summarization and redistribution.

In addition, you must use customized route summarization in environments that use either of the following combinations:

Route summarization between Enhanced IGRP and NLSP is controlled by the access list. Route summarization is possible only in the Enhanced IGRP-to-NLSP direction. Routes redistributed from NLSP to Enhanced IGRP are always explicit routes.

Route summarization between RIP and NLSP is also controlled by the access list. Route summarization is possible only in the RIP-to-NLSP direction. Routes redistributed from NLSP to RIP are always explicit routes. Use the default route instead to minimize routing update overhead, yet maximize reachability in a RIP-only area.


Note Before introducing the default route into a RIP-only area, be sure that all routers and servers in the area are upgraded to understand and use the default route.

In a well-designed network, within each NLSP area, most external networks are reachable by a few aggregated routes, while all other external networks are reachable either by individual explicit routes or by the default route.

Relationship between Filtering and Route Summarization

Redistribution of routes and services into and out of an NLSP area may be modified using filters. Filters are available for both input and output directions. Refer to the distribute-list in, distribute-list out, distribute-sap-list in, and distribute-sap-list out commands in the "Novell IPX Commands Chapter."

Filtering is independent of route summarization, but may affect it indirectly, since filters are always applied before the aggregation algorithm is applied. It is possible to filter all explicit routes that could generate aggregated routes, making the router unable to generate aggregated routes even though route aggregation is turned on.

Understand Service and Path Selection

The router always accepts service information as long as the service's network is reachable by an explicit route, an aggregated route, or the default route. When choosing a server for a Get Nearest Server (GNS) response, the tick value of the route to each eligible server is used as the metric. No distinction is made between explicit and summary routes in this determination. If the tick values are equal, then the hop count is used as a tiebreaker. However, because there is no hop value associated with an aggregated route, services reachable via an explicit route are always preferred over those reachable via only an aggregated route.

An NLSP version 1.1 router always uses the most explicit match to route packets. That is, the router always uses an explicit route if possible. If not, then a matching aggregated route is used. If multiple aggregated routes match, then the most explicit (longest match) is used. If no aggregated route is present, then the default route is used as a last resort.

Configure Route Aggregation Task List

To configure the route aggregation feature, perform one or more of the task in the following sections:

Configure Route Aggregation for Multiple NLSP Version 1.1 Areas

Redistribution between multiple NLSP 1.1 areas is enabled by default. Because multiple NLSP processes are present on the router, a tag or label identifies each. For each instance, configure an appropriate area address and, optionally, enable route summarization. Finally, enable NLSP on appropriate interfaces. Be sure to use the correct tag (process) identifier to associate that interface with the appropriate NLSP area.


Note Note that the tag used to identify an NLSP instance is meaningful only locally within the router. NLSP adjacencies and areas are determined by the area address and interfaces configured for each instance of NLSP running on each router. There is no need (other than administrative convenience) to ensure that individual tags match between routers.

The following sections describe how to configure route aggregation for multiple NLSP Version 1.1 areas:

Configure Route Aggregation with Default Route Summarization

To configure the route aggregation feature with the default route summarization behavior, use the following commands for each NLSP process, starting in global configuration mode:
Step Command Purpose

1 . 

ipx router nlsp [tag]

Enable NLSP routing and identify the process with a unique tag.

2 . 

area-address address mask

From router configuration mode, define up to three area addresses for the process.

3 . 

route-aggregation

(Optional) From router configuration mode, enable route summarization.

4 . 

ipx nlsp [tag] enable

From interface configuration mode, enable NLSP on each network in the area described by the tag argument.

For an example of how to configure this type of route aggregation, see "NLSP Route Aggregation for NLSP Version 1.1 and Version 1.0 Areas Example" section at the end of this chapter.

Configure Route Aggregation with Customized Route Summarization Using Numbered Access Lists

To configure the route aggregation feature with customized route summarization behavior (using numbered access lists), use the following commands for each NLSP process, starting in global configuration mode:
Step Command Purpose

1 . 

ipx router nlsp [tag]

Enable NLSP routing and identify the process with a unique tag.

2 . 

area-address address mask

From router configuration mode, define up to three area addresses for the process.

3 . 

route-aggregation

Enable route summarization from router configuration mode.

4 . 

redistribute nlsp [tag] access-list access-list-number

From router configuration mode, use the redistribute command with an access list in the range of 1200 to 1299. In this case, the tag argument identifies a unique NLSP process.

5 . 

ipx nlsp [tag] enable

From interface configuration mode, enable NLSP on each network in the area described by the tag argument.

6 . 

access-list access-list-number deny network network-mask [ticks ticks] [area-count area-count]

From global configuration mode, define the access list to redistribute an aggregated route instead of the explicit route. For each address range you want to summarize, use the deny keyword.

7 . 

access-list access-list-number permit -1

(Optional) Terminate the access list with a "permit all" statement to redistribute all other routes as explicit routes.

Configure Route Aggregation with Customized Route Summarization Using Named Access Lists

To configure the route aggregation feature with customized route summarization behavior (using named access lists), use the following commands for each NLSP process, starting in global configuration mode:
Step Command Purpose

1 . 

ipx router nlsp [tag]

Enable NLSP routing and identify the process with a unique tag.

2 . 

area-address address mask

From router configuration mode, define up to three area addresses for the process.

3 . 

route-aggregation

Enable route summarization from router configuration mode.

4 . 

redistribute nlsp [tag] access-list name

From router configuration mode, use the redistribute command with a named access list. In this case, the tag argument identifies a unique NLSP process.

5 . 

ipx nlsp [tag] enable

From interface configuration mode, enable NLSP on each network in the area described by the tag argument.

6 . 

ipx access-list summary name

From global configuration mode, specify a named IPX access list for NLSP route aggregation.

7 . 

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

In access-list configuration mode, specify the redistribution of aggregated routes instead of explicit routes. For each address range you want to summarize, use a deny command.

8 . 

permit -1

(Optional) Terminate the access list with a "permit all" statement to redistribute all other routes as explicit routes.

Configure Route Aggregation for NLSP Version 1.1 and NLSP Version 1.0 Areas

By default, redistribution is enabled between multiple instances of NLSP. Route summarization, when enabled, is possible in one direction only---from NLSP version 1.0 to NLSP version 1.1.

The following sections describe how to configure route aggregation for NLSP Version 1.1 and NLSP Version 1.0 areas:

Configure Route Aggregation with Default Route Summarization

To configure the route aggregation feature with default route summarization behavior, use the following commands for each NLSP process, starting in global configuration mode:
Step Command Purpose

1 . 

ipx router nlsp [tag]

Enable NLSP routing and identify the process with a unique tag.

2 . 

area-address address mask

From router configuration mode, define up to three area addresses for the process.

3 . 

route-aggregation

For NLSP version 1.1 areas, enable route summarization from router configuration mode. Skip this step for NLSP version 1.0 areas.

4 . 

ipx nlsp [tag] enable

From interface configuration mode, enable NLSP on each network in the area described by the tag argument.

Configure Route Aggregation with Customized Route Summarization Using Numbered Access Lists

To configure the route aggregation feature with customized route summarization behavior (using numbered access lists), use the commands in the following two tables.

For the NLSP version 1.1 process, use the following commands, starting in global configuration mode:
Step Command Purpose

1 . 

ipx router nlsp [tag]

Enable NLSP routing and identify the process with a unique tag.

2 . 

area-address address mask

From router configuration mode, define up to three area addresses for the process.

3 . 

route-aggregation

For NLSP version 1.1 areas, enable route summarization from router configuration mode.

4 . 

redistribute nlsp [tag] access-list access-list-number

(Optional) From router configuration mode, redistribute NLSP version 1.0 into the NLSP version 1.1 area. Include an access list number between 1200 and 1299.

5 . 

ipx nlsp [tag] enable

From interface configuration mode, enable NLSP on each network in the area described by the tag argument.

6 . 

access-list access-list-number deny network network-mask [ticks ticks] [area-count area-count]

(Optional) From global configuration mode, define the access list to redistribute an aggregated route instead of explicit routes learned from the NLSP version 1.0 area. For each address range you want to summarize, use the deny keyword.

7 . 

access-list access-list-number permit -1

(Optional) Terminate the access list with a "permit all" statement to redistribute all other routes as explicit routes.

For the NLSP version 1.0 process, use the following commands, starting in global configuration mode
Step Command Purpose

1 . 

ipx router nlsp [tag]

Enable NLSP routing and identify the process with a unique tag.

2 . 

area-address address mask

From router configuration mode, define up to three area addresses for the process.

3 . 

ipx nlsp [tag] enable

From interface configuration mode, enable NLSP on each network in the area described by the tag argument.

:

For an example of how to configure the route aggregation feature with this type of customized route summarization, refer to the "NLSP Route Aggregation for NLSP Version 1.1 and Version 1.0 Areas Example" section at the end of this chapter.

Configure Route Aggregation with Customized Route Summarization Using Named Access Lists

To configure the route aggregation feature with customized route summarization behavior (using named access lists), use the commands in the following two tables.

For the NLSP version 1.1 process, use the following commands, starting in global configuration mode:
Step Command Purpose

1 . 

ipx router nlsp [tag]

Enable NLSP routing and identify the process with a unique tag.

2 . 

area-address address mask

From router configuration mode, define up to three area addresses for the process.

3 . 

route-aggregation

For NLSP version 1.1 areas, enable route summarization from router configuration mode.

4 . 

redistribute nlsp [tag] access-list name

(Optional) From router configuration mode, redistribute NLSP version 1.0 into the NLSP version 1.1 area.

5 . 

ipx nlsp [tag] enable

From interface configuration mode, enable NLSP on each network in the area described by the tag argument.

6 . 

ipx access-list summary name

(Optional) From global configuration mode, specify a named IPX access list for NLSP route aggregation.

7 . 

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

(Optional) From access-list configuration mode, define the access list to redistribute an aggregated route instead of explicit routes learned from the NLSP version 1.0 area. For each address range you want to summarize, use a deny statement.

8 . 

permit -1

(Optional) Terminate the access list with a "permit all" statement to redistribute all other routes as explicit routes.

For the NLSP version 1.0 process, use the following commands, starting in global configuration mode
Step Command Purpose

1 . 

ipx router nlsp [tag]

Enable NLSP routing and identify the process with a unique tag.

2 . 

area-address address mask

From router configuration mode, define up to three area addresses for the process.

3 . 

ipx nlsp [tag] enable

From interface configuration mode, enable NLSP on each network in the area described by the tag argument.

:

Configure Route Aggregation for Enhanced IGRP and NLSP Version 1.1 Environments

Redistribution is not enabled by default. Additionally, summarization is possible in the Enhanced IGRP to NLSP direction only.

The following sections describe how to configure route aggregation for Enhanced IGRP and NLSP Version 1.1 environments:

Configure Route Aggregation Using Numbered Access Lists

For each NLSP version 1.1 process, use the following commands, starting in global configuration mode:
Step Command Purpose

1 . 

ipx router nlsp [tag]

Enable NLSP routing and identify the process with a unique tag.

2 . 

area-address address mask

From router configuration mode, define up to three area addresses for the process.

3 . 

route-aggregation

(Optional) From router configuration mode, enable route summarization.

4 . 

redistribute {eigrp autonomous-system-number} [access-list access-list-number

(Optional) From router configuration mode, redistribute Enhanced IGRP into the NLSP version 1.1 area. Include an access list number between 1200 and 1299.

5 . 

ipx nlsp [tag] enable

From interface configuration mode, enable NLSP on each network in the area described by the tag argument.

6 . 

access-list access-list-number deny network network-mask [ticks ticks] [area-count area-count]

(Optional) From global configuration mode, define the access list to redistribute an aggregated route instead of explicit routes learned from Enhanced IGRP. For each address range you want to summarize, use the deny keyword.

7 . 

access-list access-list-number permit -1

(Optional) Terminate the access list with a "permit all" statement to redistribute all other Enhanced IGRP routes as explicit routes.

For each Enhanced IGRP autonomous system, use the following commands starting in global configuration mode:
Step Command Purpose

1 . 

ipx router eigrp autonomous-system-number

Enable Enhanced IGRP.

2 . 

network {network-number | all}

From router configuration mode, specify the networks to be enabled for Enhanced IGRP.

3 . 

redistribute nlsp [tag]

From router configuration mode, redistribute NLSP version 1.1 into Enhanced IGRP.

For an example of how to configure this type of route aggregation, refer to the "NLSP Route Aggregation for NLSP Version 1.1, Enhanced IGRP, and RIP Example" section at the end of this chapter.

Configure Route Aggregation Using Named Access Lists

For each NLSP version 1.1 process, use the following commands, starting in global configuration mode:
Step Command Purpose

1 . 

ipx router nlsp [tag]

Enable NLSP routing and identify the process with a unique tag.

2 . 

area-address address mask

From router configuration mode, define up to three area addresses for the process.

3 . 

route-aggregation

(Optional) From router configuration mode, enable route summarization.

4 . 

redistribute {eigrp autonomous-system-number} access-list name

(Optional) From router configuration mode, redistribute Enhanced IGRP into the NLSP version 1.1 area.

5 . 

ipx nlsp [tag] enable

From interface configuration mode, enable NLSP on each network in the area described by the tag argument.

6 . 

ipx access-list summary name

(Optional) From global configuration mode, specify a named IPX access list for NLSP route aggregation

7 . 

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

(Optional) From access-list configuration mode, define the access list to redistribute an aggregated route instead of explicit routes learned from Enhanced IGRP. For each address range you want to summarize, use a deny statement.

8 . 

permit -1

(Optional) Terminate the access list with a "permit all" statement to redistribute all other Enhanced IGRP routes as explicit routes.

For each Enhanced IGRP autonomous system, use the following commands, starting in global configuration mode:
Step Command Purpose

1 . 

ipx router eigrp autonomous-system-number

Enable Enhanced IGRP.

2 . 

network {network-number | all}

From router configuration mode, specify the networks to be enabled for Enhanced IGRP.

3 . 

redistribute nlsp [tag]

From router configuration mode, redistribute NLSP version 1.1 into Enhanced IGRP.

Configure Route Aggregation for RIP and NLSP Version 1.1 Environments

Because redistribution between RIP and NLSP is enabled by default, you only need to enable the route summarization, if desired, to configure all the capabilities of the route aggregation feature.

The following sections describe how to configure route aggregation for RIP and NLSP Version 1.1 environments:

Configure Route Aggregation Using Numbered Access Lists

For each NLSP version 1.1 process, use the following commands, starting in global configuration mode:
Step Command Purpose

1 . 

ipx router nlsp [tag]

Enable NLSP routing and identify the process with a unique tag.

2 . 

area-address address mask

From router configuration mode, define up to three area addresses for the process.

3 . 

route-aggregation

(Optional) From router configuration mode, enable route summarization.

4 . 

redistribute rip [access-list access-list-number]

(Optional) From router configuration mode, redistribute RIP routes into the NLSP version 1.1 area. Include an access list number between 1200 and 1299.

5 . 

ipx nlsp [tag] enable

From interface configuration mode, enable NLSP on each network in the area described by the tag argument.

6 . 

access-list access-list-number deny network network-mask [ticks ticks] [area-count area-count]

(Optional) From global configuration mode, define the access list to redistribute an aggregated route instead of explicit RIP routes. For each address range you want to summarize, use the deny keyword.

7 . 

access-list access-list-number permit -1

(Optional) Terminate the access list with a "permit all" statement to redistribute all other RIP routes as explicit routes.

For an example of how to configure this type of route aggregation, refer to the "NLSP Route Aggregation for NLSP Version 1.1, Enhanced IGRP, and RIP Example" section at the end of this chapter.

Configure Route Aggregation Using Named Access Lists

For each NLSP version 1.1 process, use the following commands, starting in global configuration mode:
Step Command Purpose

1 . 

ipx router nlsp [tag]

Enable NLSP routing and identify the process with a unique tag.

2 . 

area-address address mask

From router configuration mode, define up to three area addresses for the process.

3 . 

route-aggregation

(Optional) From router configuration mode, enable route summarization.

4 . 

redistribute rip access-list name

(Optional) From router configuration mode, redistribute RIP routes into the NLSP version 1.1 area.

5 . 

ipx nlsp [tag] enable

From interface configuration mode, enable NLSP on each network in the area described by the tag argument.

6 . 

ipx access-list summary name

(Optional) From global configuration mode, specify a named IPX access list for NLSP route aggregation.

7 . 

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

(Optional) From access-list configuration mode, define the access list to redistribute an aggregated route instead of explicit RIP routes. For each address range you want to summarize, use a deny statement.

8 . 

permit -1

(Optional) Terminate the access list with a "permit all" statement to redistribute all other RIP routes as explicit routes.

Customize the Exchange of Routing Information

You might want to customize the exchange of routing information. The following sections describe customization tasks:

Configure RIP and SAP Compatibility

Routing Information Protocol (RIP) and (Service Advertisement Protocol) SAP are enabled by default on all interfaces configured for IPX, and these interfaces always respond to RIP and SAP requests. When you also enable NLSP on an interface, the interface, by default, generates and sends RIP and SAP periodic traffic only if another RIP router or SAP service is sending RIP or SAP traffic.

To modify the generation of periodic RIP updates on a network enabled for NLSP, use one of the following commands in interface configuration mode:
Command Purpose

ipx nlsp [tag] rip off

Never generate RIP periodic traffic.

ipx nlsp [tag] rip on

Always generate RIP periodic traffic.

ipx nlsp [tag] rip auto

Send RIP periodic traffic only if another RIP router is sending periodic RIP traffic. (This is the default on interfaces configured for NLSP.)

To modify the generation of periodic SAP updates on a network enabled for NLSP, use one of the following commands in interface configuration mode:
Command Purpose

ipx nlsp [tag] sap off

Never generate SAP periodic traffic.

ipx nlsp [tag] sap on

Always generate SAP periodic traffic.

ipx nlsp [tag] sap auto

Send SAP periodic traffic only if another SAP service is sending periodic SAP traffic. (This is the default on interfaces configured for NLSP.)

Redistribute Routing Information

Automatic redistribution of one routing protocol into another provides a simple and effective means for building IPX networks in a heterogeneous routing protocol environment. Redistribution is usually effective as soon as you enable an IPX routing protocol. One exception is NLSP and Enhanced IGRP. You must configure the redistribution of Enhanced IGRP into NLSP, and vice versa.

Once you enable Enhanced IGRP and NLSP redistribution, the router makes path decisions based on a predefined, nonconfigurable administrative distance, and prevents redistribution feedback loops without filtering via a stored, external hop count.

To enable redistribution of Enhanced IGRP into NLSP, and vice versa, use the following commands, starting in global configuration mode:
Step Command Purpose

1 . 

ipx router nlsp [tag]

Enable NLSP.

2 . 

redistribute eigrp autonomous-system-number

From IPX-router configuration mode, enable redistribution of Enhanced IGRP into NLSP.

3 . 

ipx router eigrp autonomous-system-number

From global configuration mode, enable Enhanced IGRP.

4 . 

redistribute nlsp [tag]

From IPX-router configuration mode, enable redistribution of NLSP into Enhanced IGRP.

For an example of how to enable redistribution of Enhanced IGRP and NLSP, see the "Enhanced IGRP and NLSP Route Redistribution Example" section at the end of this chapter.

Configure Next Hop Resolution Protocol

Routers, access servers, and hosts can use Next Hop Resolution Protocol (NHRP) to discover the addresses of other routers and hosts connected to a nonbroadcast, multiaccess (NBMA) network. NHRP provides an ARP-like solution that alleviates some NBMA network problems. With NHRP, systems attached to an NBMA network can dynamically learn the NBMA address of the other systems that are part of that network. These systems can then directly communicate without requiring traffic to use an intermediate hop.

For more information on NHRP and Cisco's implementation, refer to the "Configuring IP Addressing" chapter in the Network Protocols Configuration Guide, Part 1.

NHRP Configuration Task List

To configure NHRP, perform the tasks described in the following sections. The first task is required, the remainder are optional.

For NHRP configuration examples, see the "NHRP Examples" section at the end of this chapter.

Enable NHRP on an Interface

To enable NHRP for an interface on a router, use the following command in interface configuration mode. In general, all NHRP stations within a logical NBMA network must be configured with the same network identifier.
Command Purpose

ipx nhrp network-id number

Enable NHRP on an interface.

For an example of enabling NHRP, see the "NHRP Examples" section at the end of this chapter.

Configure a Station's Static IPX-to-NBMA Address Mapping

To participate in NHRP, a station connected to an NBMA network must be configured with the IPX and NBMA addresses of its Next Hop Servers. The format of the NBMA address depends on the medium you are using. For example, ATM uses a network-layer service access point (NSAP) address, Ethernet uses a MAC address, and SMDS uses an E.164 address.

These Next Hop Servers are most likely the stations's default or peer routers, so their IPX addresses are obtained from the station's network layer forwarding table.

If the station is attached to several link layer networks (including logical NBMA networks), the station should also be configured to receive routing information from its Next Hop Servers and peer routers so that it can determine which IPX networks are reachable through which link layer networks.

To configure static IPX-to-NBMA address mapping on a station (host or router), use the following command in interface configuration mode:
Command Purpose

ipx nhrp map ipx-address nbma-address

Configure static IPX-to-NBMA address mapping.

Statically Configure a Next Hop Server

A Next Hop Server normally uses the network layer forwarding table to determine where to forward NHRP packets and to find the egress point from an NBMA network. A Next Hop Server may alternately be statically configured with a set of IPX address prefixes that correspond to the IPX addresses of the stations it serves, and their logical NBMA network identifiers.

To statically configure a Next Hop Server, use the following command in interface configuration mode:
Command Purpose

ipx nhrp nhs nhs-address [net-number]

Statically configure a Next Hop Server.

To configure multiple networks that the Next Hop Server serves, repeat the ipx nhrp nhs command with the same Next Hop Server address, but different IPX network addresses. To configure additional Next Hop Servers, repeat the ipx nhrp nhs command.

Configure NHRP Authentication

Configuring an authentication string ensures that only routers configured with the same string can intercommunicate using NHRP. Therefore, if the authentication scheme is to be used, the same string must be configured in all devices configured for NHRP on a fabric. To specify the authentication string for NHRP on an interface, use the following command in interface configuration mode:
Command Purpose

ipx nhrp authentication string

Specify an authentication string.

Control NHRP Initiation

Complete one of the tasks in the following sections to control when NHRP is initiated:

Trigger NHRP by IPX Packet

You can specify an IPX access list that is used to decide which IPX packets trigger the sending of NHRP requests. By default, all non-NHRP packets can trigger NHRP requests. To limit which IPX packets trigger NHRP requests, you must define an access list and then apply it to the interface.

To define an access list, use one of the following commands in global configuration mode:
Command Purpose

access-list access-list-number {deny | permit} source-network[.source-node[source-node-mask]]
[destination-network[.destination-node [destination-node-mask]]]

Define a standard IPX access list.

access-list access-list-number {deny | permit} protocol [source-network] [[[.source-node] source-node-mask] | [.source-node source-network-mask.source-node-mask]] [source-socket] [destination.network] [[[.destination-node] destination-node-mask] | [.destination-node destination-network-mask .destination-nodemask]] [destination-socket]

Define an extended IPX access list.

Then apply the IPX access list to the interface by using the following command in interface configuration mode:
Command Purpose

ipx nhrp interest access-list-number

Specify an IPX access list that controls NHRP requests.

Trigger NHRP on a Per-Destination Basis

By default, when the software attempts to transmit a data packet to a destination for which it has determined that NHRP can be used, it transmits an NHRP request for that destination. You can configure the system to wait until a specified number of data packets have been sent to a particular destination before NHRP is attempted. To do so, use the following command in interface configuration mode:
Command Purpose

ipx nhrp use usage-count

Specify how many data packets are sent to a destination before NHRP is attempted.

Control NHRP Packet Rate

By default, the maximum rate at which the software sends NHRP packets is 5 packets per 10  seconds. The software maintains a per-interface quota of NHRP packets (whether generated locally or forwarded) that can be transmitted. To change this maximum rate, use the following command in interface configuration mode:
Command Purpose

ipx nhrp max-send pkt-count every interval

Change the NHRP packet rate per interface.

Suppress Forward and Reverse Record Options

To dynamically detect link-layer filtering in NBMA networks (for example, SMDS address screens), and to provide loop detection and diagnostic capabilities, NHRP incorporates a route record in requests and replies. The route record options contain the network (and link layer) addresses of all intermediate Next Hop Servers between source and destination (in the forward direction) and between destination and source (in the reverse direction).

By default, forward record options and reverse record options are included in NHRP request and reply packets. To suppress the use of these options, use the following command in interface configuration mode:
Command Purpose

no ipx nhrp record

Suppress forward and reverse record options.

Specify the NHRP Responder Address

If an NHRP requester wants to know which Next Hop Server generates an NHRP reply packet, it can request that information by including the responder address option in its NHRP request packet. The Next Hop Server that generates the NHRP reply packet then complies by inserting its own IPX address in the NHRP reply. The Next Hop Server uses the primary IPX address of the specified interface.

To specify which interface the Next Hop Server uses for the NHRP responder IPX address, use the following command in interface configuration mode:
Command Purpose

ipx nhrp responder type number

Specify which interface the Next Hop Server uses to determine the NHRP responder address.

If an NHRP reply packet being forwarded by a Next Hop Server contains that Next Hop Server's own IPX address, the Next Hop Server generates an "NHRP Loop Detected" error indication and discards the reply.

Change the Time Period NBMA Addresses Are Advertised as Valid

You can change the length of time that NBMA addresses are advertised as valid in positive and negative NHRP responses. In this context, advertised means how long the Cisco IOS software tells other routers to keep the addresses it is providing in NHRP responses. The default length of time for each response is 7,200 seconds (2  hours). To change the length of time, use the following command in interface configuration mode:
Command Purpose

ipx nhrp holdtime seconds-positive [seconds-negative]

Specify the number of seconds that NBMA addresses are advertised as valid in positive or negative NHRP responses.

Configure IPX and SPX over WANs

You can configure IPX over dial-on-demand routing (DDR), Frame Relay, Point-to-Point Protocol (PPP), Switched Multimegabit Data Service (SMDS), and X.25 networks. To do this, you configure address mappings as described in the appropriate chapter.

When you configure IPX over PPP, address maps are not necessary for this protocol. Also, you can enable IPX header compression over point-to-point links to increase available useful bandwidth of the link and reduce response time for interactive uses of the link.

You can use fast-switching IPX serial interfaces configured for Frame Relay and SMDS, and you can use fast-switching SNAP-encapsulated packets over interfaces configured for ATM.

Additionally, you can configure the IPXWAN protocol.

For an example of how to configure IPX over a WAN interface, see the "IPX over a WAN Interface Example" section at the end of this chapter.

Configure IPX over DDR

IPX sends periodic watchdog (keepalive) packets. These 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 means 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 Cisco IOS software to respond to the server's watchdog packets on a remote client's behalf. This is sometimes referred to as spoofing the server.

When configuring IPX over DDR, you might want to disable the generation of these packets so that a call is not made very 5 minutes. This is not an issue for the other WAN protocols, because they establish dedicated connections rather than establishing connections only as needed.

To keep the serial interface idle when only watchdog packets are being sent, refer to the tasks described in the "Deciding and Preparing to Configure DDR" chapter of the Dial Solutions Configuration Guide. For an example of configuring IPX over DDR, see the "IPX over DDR Example" section at the end of this chapter.

Configure SPX Spoofing over DDR

Sequenced Packet Exchange (SPX) sends periodic keepalive packets between clients and servers. Similar to IPX watchdog packets, these are keepalive packets that are sent between servers and clients after the data has stopped being transferred. On pay-per-packet or byte networks, these packets can incur large customer telephone connection charges for idle time. You can prevent these calls from being made by configuring the Cisco IOS software to respond to the keepalive packets on behalf of a remote system.

When configuring SPX over DDR, you might want to disable the generation of these packets so that a call has the opportunity to go idle. This may not be an issue for the other WAN protocols because they establish dedicated connections rather than establishing connections only as needed.

To keep the serial interface idle when only keepalive packets are being sent, refer to the tasks described in the "Deciding and Preparing to Configure DDR" chapter of the Dial Solutions Configuration Guide.

For an example of how to configure SPX spoofing over DDR, see the "IPX over DDR Example" section at the end of this chapter.

Configure IPX Header Compression

You can configure IPX header compression over point-to-point links. With IPX header compression, a point-to-point link can compress IPX headers only, or the combined IPX and NetWare Core Protocol headers. Currently, point-to-point links must first negotiate IPX header compression via IPXCP or IXPWAN. The Cisco IOS software supports IPX header compression as defined by RFC  1553.

For details on configuring IPX header compression, refer to the "Configuring Media-Independent PPP and Multilink PPP" chapter in the Dial Solutions Configuration Guide.

Configure the IPXWAN Protocol

The Cisco IOS software supports the IPXWAN protocol, as defined in RFC 1634. IPXWAN allows a router that is running IPX routing to connect via a serial link to another router, possibly from another manufacturer, that is also routing IPX and using IPXWAN.

IPXWAN is a connection start-up protocol. Once a link has been established, IPXWAN incurs little or no overhead.

You can use the IPXWAN protocol over PPP. You can also use it over HDLC; however, the devices at both ends of the serial link must be Cisco routers.

To configure IPXWAN, use the following commands in interface configuration mode on a serial interface:
Step Command Purpose

1 . 

no ipx network

Ensure that you have not configured an IPX network number on the interface.

2 . 

encapsulation ppp

Enable PPP.

3 . 

ipx ipxwan [local-node {network-number | unnumbered} local-server-name retry-interval retry-limit]

Enable IPXWAN.

4 . 

ipx ipxwan error [reset | resume | shutdown]

Optionally, define how to handle IPXWAN when a serial link fails.

5 . 

ipx ipxwan static

Optionally, enable static routing with IPXWAN. Note that the remote site must also use static routing.

Control Access to IPX Networks

To control access to IPX networks, first create access lists and then apply them to individual interfaces using filters.

Types of Access Lists

You can create the following IPX access lists to filter various kinds of traffic:

Types of Filters

There are more than 14 different IPX filters that you can define for IPX interfaces. They fall into the following six groups:

Table 9 summarizes the filters, the access lists they use, and the commands used to define the filters in the first five groups. Use the show  ipx interfaces command to display the filters defined on an interface. Route aggregation is discussed in detail in the "Configure Route Aggregation" section. Refer to that section for additional information.


Table 9: IPX Filters
Filter Type Access List Used by Filter Command to Define Filter
Generic filters

Filter inbound or outbound packets based on the contents of the IPX network header.

Standard or Extended

ipx access-group {access-list-number | name} [in | out]

Routing table filters

Control which networks are added to the routing table.

Standard or Extended

ipx input-network-filter {access-list-number | name}

Control which networks are advertised in routing updates.

Standard or Extended

ipx output-network-filter {access-list-number | name}

Control which networks are advertised in the Enhanced IGRP routing updates sent out by the Cisco  IOS software.

Standard or Extended

distribute-list {access-list-number | name} out [interface-name | routing-process]

Control the routers from which updates are accepted.

Standard or Extended

ipx router-filter {access-list-number | name}

SAP filters

Filter incoming service advertisements.

SAP

ipx input-sap-filter {access-list-number | name}

Filter outgoing service advertisements.

SAP

ipx output-sap-filter {access-list-number | name}

Control the routers from which SAP updates are accepted.

SAP

ipx router-sap-filter {access-list-number | name}

Filter list of servers in GNS response messages.

SAP

ipx output-gns-filter {access-list-number | name}

IPX NetBIOS filters

Filter incoming packets by node name.

IPX NetBIOS

ipx netbios input-access-filter host name

Filter incoming packets by byte pattern.

IPX NetBIOS

ipx netbios input-access-filter bytes name

Filter outgoing packets by node name.

IPX NetBIOS

ipx netbios output-access-filter host name

Filter outgoing packets by byte pattern.

IPX NetBIOS

ipx netbios output-access-filter bytes name

Broadcast filters

Control which broadcast packets are forwarded.

Standard or Extended

ipx helper-list {access-list-number | name}

Implementation Considerations

Keep the following information in mind when configuring IPX network access control:

For named access lists, all new entries to an existing list are placed at the end of the list. You cannot add entries to the middle of a list. However, you can remove specific entries using the no deny and no permit commands, rather than deleting the entire access list.

Control Access to IPX Networks Task List

You perform the required tasks in the following section to control access to IPX networks:

Create Access Lists

You can create access lists using numbers or names. You can choose which method you prefer. If you use numbers to identify your access lists, you are limited to 100 access lists per filter type. If you names to identify your access lists, you can have an unlimited number of access lists per filter type.

The following sections describe how to perform these tasks:

Create Access Lists Using Numbers

To create access lists using numbers, you can use one or more of the following commands in global configuration mode:
Command Purpose

access-list access-list-number {deny | permit} source-network[.source-node[source-node-mask]]
[destination-network[.destination-node [destination-node-mask]]]

Create a standard IPX access list using a number. (Generic, routing, and broadcast filters use this type of access list.)

access-list access-list-number {deny | permit} protocol [source-network[.source-node [source-network-mask.source-node-mask]] source-socket [destination-network [.destination-node [destination-network-mask.destination-node-mask] destination-socket] [log]

Create an extended IPX access list using a number. (Generic, routing, and broadcast filters use this type of access list.)

access-list access-list-number {deny | permit} network[.node] [network-mask node-mask] [service-type [server-name]]

Create a SAP filtering access list using a number. (SAP and GNS response filters use this type of access list).

Once you have created an access list using numbers, apply it to the appropriate interfaces using filters as described in the "Create Filters" section of this chapter. This activates the access list.

Create Access Lists Using Names

IPX named access lists allow you to identify IPX access lists with an alphanumeric string (a name) rather than a number. You can configure an unlimited number of the following types of IPX named access lists:

If you identify your access list with a name rather than a number, the mode and command syntax are slightly different.

Benefits of IPX Named Access Lists

Using IPX named access lists allow you to maintain security by using a separate and easily identifiable access list for each user or interface. IPX named access lists also remove the limit of 100  lists per filter type.

Implementation Considerations for Configuring IPX Named Access Lists

Consider the following information before configuring IPX named access lists:

IPX Named Access List Configuration Task List

To configure IPX named access lists for standard, extended, SAP, NLSP route aggregation (summarization), or NetBIOS access lists, complete one or more of the tasks in the following sections:

Create a Named Standard Access List

To create a named standard access list, use the following commands, starting in global configuration mode:
Step Command Purpose

1 . 

ipx access-list standard name

Define a standard IPX access list using a name. (Generic, routing, and broadcast filters use this type of access list.)

2 . 

{deny | permit} source-network[.source-node
[source-node-mask]] [destination-network [.destination-node [destination-node-mask]]]

In access-list configuration mode, specify one or more conditions allowed or denied. This determines whether the packet is passed or dropped.

3 . 

exit

Exit access-list configuration mode.

For an example of creating a named standard access list, see the "Standard Named Access List Example" section at the end of this chapter.

Create a Named Extended Access List

To create a named extended access list, use the following commands, starting in global configuration mode:
Step Command Purpose

1 . 

ipx access-list extended name

Define an extended IPX access list using a name. (Generic, routing, and broadcast filters use this type of access list.)

2 . 

{deny | permit} protocol [source-network] [[[.source-node] source-node-mask] | [.source-node source-network-mask.source-node-mask]] [source-socket] [destination.network] [[[.destination-node] destination-node-mask] | [.destination-node destination-network-mask.destination-node-mask]] [destination-socket] [log]

In access-list configuration mode, specify the conditions allowed or denied. Use the log keyword to get access list logging messages, including violations.

3 . 

exit

Exit access-list configuration mode.

Create a Named SAP Filtering Access List

To create a named access list for filtering SAP requests, use the following commands, starting in global configuration mode:
Step Command Purpose

1 . 

ipx access-list sap name

Define a SAP filtering access list using a name. (SAP and GNS response filters use this type of access list.)

2 . 

{deny | permit} network[.node] [network-mask.node-mask] [service-type [server-name]]

In access-list configuration mode, specify the conditions allowed or denied.

3 . 

exit

Exit access-list configuration mode.

Create a Named NLSP Route Aggregation Access List

NLSP route aggregation access lists perform one of the following functions:

To create a named access list for NLSP route aggregation, use the following commands, starting in global configuration mode:
Step Command Purpose

1 . 

ipx access-list summary name

Define an IPX access list for NLSP route aggregation using a name.

2 . 

{deny | permit} network network-mask [ticks ticks]
[area-count area-count]

In access-list configuration mode, specify the conditions allowed or denied. For each address range you want to redistribute as a single aggregated route, use the deny keyword. For each address that you want to redistribute explicitly, use the permit keyword.

3 . 

exit

Exit access-list configuration mode.

For information on how to use named access list when configuring route aggregation, refer to the tasks listed in the "Configure Route Aggregation Task List" section of this chapter.

Create a NetBIOS Access List

To create a NetBIOS access list, use one or more of the following commands in global configuration mode:
Command Purpose

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

Create an access list for filtering IPX NetBIOS packets by node name. (NetBIOS filters use this type of access list.)

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

Create an access list for filtering IPX NetBIOS packets by arbitrary byte pattern. (NetBIOS filters use this type of access list.)

Modifying IPX Named Access Lists

After you initially create an access list, you place any subsequent additions (possibly entered from the terminal) at the end of the list. In other words, you cannot selectively add access list command lines to the middle of a specific access list. However, you can use no permit and no deny commands to remove entries from a named access list.


Note 
When creating access lists, remember that, by default, the end of the access list contains an implicit deny statement for everything if it did not find a match before reaching the end.
For an example of creating a generic filter, see the "IPX Network Access Examples" section at the end of this chapter.
Applying Named Access Lists to Interfaces

After creating an access list, you must apply it to the appropriate interface using filters as described in the "Create Filters" section of this chapter. This activates the access list.

Create Filters

Filters allow you to control which traffic is forwarded or blocked at a router's interfaces. Filters apply specific numbered or named access lists to interfaces.

The following sections describe how to perform the tasks for creating filters:

Create Generic Filters

Generic filters determine which data packets to receive from or send to an interface, based on the packet's source and destination addresses, IPX protocol type, and source and destination socket numbers.

To create generic filters, first create a standard or an extended access list as described in the "Create Access Lists" section of this chapter and then apply a filter to an interface.

To apply a generic filter to an interface, use the following command in interface configuration mode:
Command Purpose

ipx access-group {access-list-number | name} [in | out]

Apply a generic filter to an interface.

You can apply only one input filter and one output filter per interface or subinterface. You cannot configure an output filter on an interface where autonomous switching is already configured. Similarly, you cannot configure autonomous switching on an interface where an output filter is already present. You cannot configure an input filter on an interface if autonomous switching is already configured on any interface. Likewise, you cannot configure input filters if autonomous switching is already enabled on any interface.

For an example of creating a generic filter, see the "IPX Network Access Examples" section at the end of this chapter.

Create Filters for Updating the Routing Table

Routing table update filters control the entries that the Cisco IOS software accepts for its routing table, and the networks that it advertises in its routing updates.

To create filters to control updating of the routing table, first create a standard or an extended access list as described in the "Create Access Lists" section of this chapter and then apply one or more routing filters to an interface.

To apply routing table update filters to an interface, use one or more of the following commands in interface configuration mode:
Command Purpose

ipx input-network-filter {access-list-number | name}

Control which networks are added to the routing table when IPX routing updates are received.

ipx output-network-filter {access-list-number | name}

Control which networks are advertised in RIP routing updates sent out by the Cisco  IOS  software.

distribute-list {access-list-number | name} out [interface-name | routing-process]

Control which networks are advertised in the Enhanced IGRP routing updates sent out by the Cisco  IOS software.

ipx router-filter {access-list-number | name}

Control the routers from which routing updates are accepted.


Note The ipx output-network-filter command applies to the IPX RIP only. To control the advertising of routes when filtering routing updates in Enhanced IGRP, use the distribute-list out command. See the "
Control the Advertising of Routes in Routing Updates" section in this chapter for more information.

Create SAP Filters

A common source of traffic on Novell networks is SAP messages, which are generated by NetWare servers and the Cisco IOS software when they broadcast their available services.

To control how SAP messages from network segments or specific servers are routed among IPX networks, first create a SAP filtering access list as described in the "Create Access Lists" section of this chapter and then apply one or more filters to an interface.

To apply SAP filters to an interface, use one or more of the following commands in interface configuration mode:
Command Purpose

ipx input-sap-filter {access-list-number | name}

Filter incoming service advertisements.

ipx output-sap-filter {access-list-number | name}

Filter outgoing service advertisements.

ipx router-sap-filter {access-list-number | name}

Filter service advertisements received from a particular router.

You can apply one of each SAP filter to each interface.

For examples of creating and applying SAP filters, see the "SAP Input Filter Example" and "SAP Output Filter Example" sections at the end of this chapter.

Create GNS Response Filters

To create filters for controlling which servers are included in the GNS responses sent by the Cisco  IOS software, first create a SAP filtering access list as described in the "Create Access Lists" section of this chapter and then apply a GNS filter to an interface.

To apply a GNS filter to an interface, use the following command in interface configuration mode:
Command Purpose

ipx output-gns-filter {access-list-number | name}

Filter the list of servers in GNS response messages.

Create IPX NetBIOS Filters

Novell's IPX NetBIOS allows messages to be exchanged between nodes using alphanumeric names and node addresses. Therefore, the Cisco IOS software lets you filter incoming and outgoing NetBIOS FindName packets by the node name or by an arbitrary byte pattern (such as the node address) in the packet.


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

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

IPX NetBIOS Filters Configuration Task List

To create filters for controlling IPX NetBIOS access, first create a NetBIOS access list as described in the "Create Access Lists" section of this chapter and then apply the access list to an interface.

To apply a NetBIOS access list to an interface, use one or more of the following commands in interface configuration mode:
Command Purpose

ipx netbios input-access-filter host name

Filter incoming packets by node name.

ipx netbios input-access-filter bytes name

Filter incoming packets by byte pattern.

ipx netbios output-access-filter host name

Filter outgoing packets by node name.

ipx netbios output-access-filter bytes name

Filter outgoing packets by byte pattern.

You can apply one of each of these four filters to each interface.

For an example of how to create filters for controlling IPX NetBIOS, see the "IPX NetBIOS Filter Examples" section at the end of this chapter.

Create Broadcast Message Filters

Routers normally block all broadcast requests and do not forward them to other network segments. This is done to prevent the degradation of performance inherent in broadcast traffic over the entire network. You can define which broadcast messages get forwarded to other networks by applying a broadcast message filter to an interface.

To create filters for controlling broadcast messages, first create a standard or an extended access list as described in the "Create Access Lists" section of this chapter and then apply a broadcast message filter to an interface.

To apply a broadcast message filter to an interface, use the following commands in interface configuration mode:
Step Command Purpose

1 . 

ipx helper-address network.node

Specify a helper address for forwarding broadcast messages.

2 . 

ipx helper-list {access-list-number | name}

Apply a broadcast message filter to an interface.


Note A broadcast message filter has no effect unless you have issued an ipx helper-address or an ipx type-20-propagation command on the interface to enable and control the forwarding of broadcast messages. These commands are discussed later in this chapter.

For examples of creating and applying broadcast message filters, see the "Helper Facilities to Control Broadcast Examples" section at the end of this chapter.

Tune IPX Network Performance

You can tune IPX network performance by completing the tasks in one or more of the following sections:

Control Novell IPX Compliance

Cisco's implementation of Novell's IPX protocol is certified to provide full IPX router functionality, as defined by Novell's IPX Router Specification, Version 1.10, published November  17, 1992.

You can control compliance to Novell specifications by performing the tasks in the following sections:

Control the Forwarding of Type 20 Packets

NetBIOS over IPX uses type 20 propagation broadcast packets flooded to all networks to get information about the named nodes on the network. NetBIOS uses a broadcast mechanism to get this information, because it does not implement a network layer.

Routers normally block all broadcast requests. By enabling type 20 packet propagation, IPX interfaces on the router may accept and forward type 20 packets.

How Type 20 Packet Propagation Works

When an interface configured for type 20 propagation receives a type 20 packet, Cisco IOS software processes the packet according to Novell specifications. Cisco IOS software propagates the packet to the next interface. The type 20 packet can be propagated for up to eight hop counts.

Loop Detection and Other Checks

Before forwarding (flooding) the packets, the router performs loop detection as described by the IPX router specification.

You can configure the Cisco IOS software to apply extra checks to type 20 propagation packets above and beyond the loop detection described in the IPX specification. These checks are the same ones that are applied to helpered all-nets broadcast packets. They can limit unnecessary duplication of type 20 broadcast packets. The extra helper checks are as follows:

While this extra checking increases the robustness of type 20 propagation packet handling by decreasing the amount of unnecessary packet replication, it has the following two side effects:

Relationship between Type 20 Propagation and Helper Addresses

You use helper addresses to forward non-type 20 broadcast packets to other network segments. For information on forwarding other broadcast packets, see the "Use Helper Addresses to Forward Broadcast Packets" section in this chapter.

You can use helper addresses and type 20 propagation together in your network. Use helper addresses to forward non-type 20 broadcast packets and use type 20 propagation to forward type 20 broadcast packets.

Type 20 Packets Configuration Task List

You can enable the forwarding of type 20 packets on individual interfaces. Additionally, you can restrict the acceptance and forwarding of type 20 packets. You can also choose to not comply with Novell specifications and forward type 20 packets using helper addresses rather than using type 20 propagation. The following sections describe these tasks:

Enable the Forwarding of Type 20 Packets

By default, type 20 propagation packets are dropped by the Cisco IOS software. You can configure the software to receive type 20 propagation broadcast packets and forward (flood) them to other network segments, subject to loop detection.

To enable the receipt and forwarding of type 20 packets, use the following command in interface configuration mode:
Command Purpose

ipx type-20-propagation

Forward IPX type 20 propagation packet broadcasts to other network segments.

When you enable type 20 propagation, Cisco IOS propagates the broadcast to the next interface up to eight hops.

Restrict the Acceptance of Incoming Type 20 Packets

For incoming type 20 propagation packets, the Cisco IOS software is configured by default to accept packets on all interfaces enabled to receive type 20 propagation packets. You can configure the software to accept packets only from the single network that is the primary route back to the source network. This means that similar packets from the same source that are received via other networks will be dropped.

Checking of incoming type 20 propagation broadcast packets is done only if the interface is configured to receive and forward type 20 packets.

To impose restrictions on the receipt of incoming type 20 propagation packets in addition to the checks defined in the IPX specification, use the following command in global configuration mode:
Command Purpose

ipx type-20-input-checks

Restrict the acceptance of IPX type 20 propagation packets.

Restrict the Forwarding of Outgoing Type 20 Packets

For outgoing type 20 propagation packets, the Cisco IOS software is configured by default to send packets on all interfaces enabled to send type 20 propagation packets, subject to loop detection. You can configure the software to send these packets only to networks that are not routes back to the source network. (The software uses the current routing table to determine routes.)

Checking of outgoing type 20 propagation broadcast packets is done only if the interface is configured to receive and forward type 20 packets.

To impose restrictions on the transmission of type 20 propagation packets, and to forward these packets to all networks using only the checks defined in the IPX specification, use the following command in global configuration mode:
Command Purpose

ipx type-20-output-checks

Restrict the forwarding of IPX type 20 propagation packets.

Forward Type 20 Packets Using Helper Addresses

You can also forward type 20 packets to specific network segments using helper addresses rather than using the type 20 packet propagation.

You may want to forward type 20 packets using helper addresses when some routers in your network are running versions of Cisco IOS that do not support type 20 propagation. When some routers in your network support type 20 propagation and others do not, you can avoid flooding packets everywhere in the network by using helper addresses to direct packets to certain segments only.

Cisco IOS Release 9.1 and earlier versions do not support type 20 propagation.


Note Forwarding type 20 packets using helper addresses does not comply with the Novell IPX router specification.

To forward type 20 packets addresses using helper addresses, use the following commands, starting in global configuration mode:
Step Command Purpose

1 . 

ipx type-20-helpered

Forward IPX type 20 packets to specific networks segments. This step turns off type 20 propagation.

2 . 

ipx helper-address network.node

From interface configuration mode, specify a helper address for forwarding broadcast messages, including IPX type 20 packets.

The Cisco IOS software forwards type 20 packets to only those nodes specified by the ipx helper-address command.


Note Using the ipx type-20-helpered command disables the receipt and forwarding of type 20 propagation packets as directed by the ipx type-20-propagation command.

Control Interpacket Delay

To control interpacket delay, you can use a combination of global configuration and interface configuration commands.

You can use one or more of the following commands in global configuration mode:
Command Purpose

ipx default-output-rip-delay delay

Set the interpacket delay of multiple-packet routing updates sent on all interfaces.

ipx default-triggered-rip-delay delay

Set the interpacket delay of multiple-packet triggered routing updates sent on all interfaces.

ipx default-output-sap-delay delay

Set the interpacket delay of multiple-packet SAP updates sent on all interfaces.

ipx default-triggered-sap-delay delay

Set the interpacket delay of multiple-packet triggered SAP updates sent on all interfaces.

You can also use one or more of the following commands in interface configuration mode:
Command Purpose

ipx output-rip-delay delay

Set the interpacket delay of multiple-packet routing updates sent on a single interface.

ipx triggered-rip-delay delay

Set the interpacket delay of multiple-packet triggered routing updates sent on a single interface.

ipx output-sap-delay delay

Set the interpacket delay of multiple-packet SAP updates sent on a single interface.

ipx triggered-sap-delay delay

Set the interpacket delay of multiple-packet triggered SAP updates sent on a single interface.


Note We recommend that you use an ipx output-rip-delay and ipx output-sap-delay on slower speed WAN interfaces.The default delay for Cisco IOS Release 11.1 and later versions is 55  milliseconds.

Shut Down an IPX Network

To shut down an IPX network using a Novell-compliant method, use the following command in interface configuration mode:
Command Purpose

ipx down network

Administratively shut down an IPX network on an interface. This removes the network from the interface.

Convergence is faster when you shut down an IPX network using the ipx down command than when using the shutdown command.

Achieve Full Novell Compliance

To achieve full compliance, use the following interface configuration commands on each interface configured for IPX:
Step Command Purpose

1 . 

ipx output-rip-delay 55

Set the interpacket delay of multiple-packet routing updates to 55  milliseconds.

2 . 

ipx output-sap-delay 55

Set the interpacket delay of multiple-packet SAP updates to
55 milliseconds.

3 . 

ipx type-20-propagation

Optionally enable type 20 packet propagation if you want to forward type 20 broadcast traffic across the router.

You can also globally set interpacket delays for multiple-packet RIP and SAP updates to achieve full compliance, eliminating the need to set delays on each interface. To do so, use the following commands from global configuration mode:
Step Command Purpose

1 . 

ipx default-output-rip-delay 55

Set the interpacket delay of multiple-packet routing updates sent on all interfaces to 55 milliseconds.

2 . 

ipx default-output-sap-delay 55

Set the interpacket delay of multiple-packet SAP updates sent on all interfaces to 55 milliseconds.


Note The default delay for Cisco IOS Release 11.1 and later versions is 55  milliseconds.

Adjust RIP and SAP Information

You can adjust RIP and SAP information by completing one or more of the optional tasks in the following sections:

Configure Static Routes

IPX uses RIP, Enhanced IGRP, or NLSP to determine the best path when several paths to a destination exist. The routing protocol then dynamically updates the routing table. However, you might want to add static routes to the routing table to explicitly specify paths to certain destinations. Static routes always override any dynamically learned paths.

Be careful when assigning static routes. When links associated with static routes are lost, traffic may stop being forwarded or traffic may be forwarded to a nonexistent destination, even though an alternative path might be available.

To add a static route to the routing table, use the following command in global configuration mode:
Command Purpose

ipx route {network | default} {network.node | interface} [floating-static]

Add a static route to the routing table.

You can configure static routes that can be overridden by dynamically learned routes. These routes are referred to a floating static routes. You can use a floating static route to create a path of last resort that is used only when no dynamic routing information is available.


Note By default, floating static routes are not redistributed into other dynamic protocols.

To add a floating static route to the routing table, use the following command in global configuration mode:
Command Purpose

ipx route {network | default} {network.node | interface} [floating-static]

Add a floating static route to the routing table.

Adjust the RIP Delay Field

By default, all LAN interfaces have a RIP delay of 1 and all WAN interfaces have a RIP delay of 6. Leaving the delay at its default value is sufficient for most interfaces. However, you can adjust the RIP delay field by setting the tick count. To set the tick count, use the following command in interface configuration mode:
Command Purpose

ipx delay number

Set the tick count, which is used in the IPX RIP delay field.

-

Control Responses to RIP Requests

To control responses to RIP requests, use the following command:
Command Purpose

ipx rip-response-delay ms

Set the delay when responding to RIP requests.

Adjust RIP Update Timers

You can set the interval between IPX RIP updates on a per-interface basis. You can also specify the delay between the packets of a multiple-packet RIP update on a per-interface or global basis. Additionally, you can specify the delay between packets of a multiple-packet triggered RIP update on a per-interface or global basis.

You can set RIP update timers only in a configuration in which all routers are Cisco routers, or in which the IPX routers allow configurable timers. The timers should be the same for all devices connected to the same cable segment. The update value you choose affects internal IPX timers as follows:

You might want to set a delay between the packets in a multiple-packet update if there are some slower PCs on the network or on slower-speed interfaces.

To adjust RIP update timers on a per-interface basis, use any or all of the following commands in interface configuration mode:
Command Purpose

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

Adjust the RIP update timer.

ipx output-rip-delay delay

Adjust the delay between multiple-packet routing updates sent on a single interface.

ipx triggered-rip-delay delay

Adjust the delay between multiple-packet triggered routing updates sent on a single interface.

To adjust RIP update timers on a global basis, use any or all of the following commands in global configuration mode:
Command Purpose

ipx default-output-rip-delay delay

Adjust the delay between multiple-packet routing updates sent on all interfaces.

ipx default-triggered-rip-delay delay

Adjust the delay between multiple-packet triggered routing updates sent on all interfaces.

By default, the RIP entry for a network or server ages out at an interval equal to three times the RIP timer. To configure the multiplier that controls the interval, use the following command in interface configuration mode:
Command Purpose

ipx rip-multiplier multiplier

Configure the interval at which a network RIP entry ages out.

Configure RIP Update Packet Size

By default, the maximum size of RIP updates sent out an interface is 432 bytes. This size allows for 50 routes at 8 bytes each, plus a 32-byte IPX RIP header. To modify the maximum packet size, use the following command in interface configuration mode:
Command Purpose

ipx rip-max-packetsize bytes

Configure the maximum packet size of RIP updates sent out an interface.

Configure Static SAP Table Entries

Servers use SAP to advertise their services via broadcast packets. The Cisco IOS software stores this information in the SAP table, also known as the Server Information Table. This table is updated dynamically. You might want to explicitly add an entry to the Server Information Table so that clients always use the services of a particular server. Static SAP assignments always override any identical entries in the SAP table that are learned dynamically, regardless of hop count. If a dynamic route that is associated with a static SAP entry is lost or deleted, the software will not announce the static SAP entry until it relearns the route.

To add a static entry to the SAP table, use the following command in global configuration mode:
Command Purpose

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

Specify a static SAP table entry.

Configure the Queue Length for SAP Requests

The Cisco IOS software maintains a list of SAP requests to process, including all pending GNS queries from clients attempting to reach servers. When the network is restarted following a power failure or other unexpected event, the router can be inundated with hundreds of requests for servers. Typically, many of these are repeated requests from the same clients. You can configure the maximum length allowed for the pending SAP requests queue. SAP requests received when the queue is full are dropped, and the client must resend them.

To set the queue length for SAP requests, use the following command in global configuration mode:
Command Purpose

ipx sap-queue-maximum number

Configure the maximum SAP queue length.

Adjust SAP Update Timers

You can adjust the interval at which SAP updates are sent. You can also set the delay between packets of a multiple-packet SAP update on a per-interface or global basis. Additionally, you can specify the delay between packets of a multiple-packet triggered SAP update on a per-interface or global basis.

Changing the interval at which SAP updates are sent is most useful on limited-bandwidth, point-to-point links, such as slower-speed interfaces. You should ensure that all IPX servers and routers on a given network have the same SAP interval. Otherwise, they might decide that a server is down when it is really up.

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

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

To modify the SAP update timers on a per-interface basis, use any or all of the following commands in interface configuration mode:
Command Purpose

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

Adjust the interval at which SAP updates are sent.

ipx output-sap-delay delay

Adjust the interpacket delay of multiple-packet SAP updates sent on a single interface.

ipx triggered-sap-delay delay

Adjust the interpacket delay of multiple-packet triggered SAP updates sent on a single interface.

To adjust SAP update timers on a global basis (eliminating the need to configure delays on a per-interface basis), use any or all of the following commands in global configuration mode:
Command Purpose

ipx default-output-sap-delay delay

Adjust the interpacket delay of multiple-packet SAP updates sent on all interfaces.

ipx default-triggered-sap-delay delay

Adjust the interpacket delay of multiple-packet triggered SAP updates sent on all interfaces.

By default, the SAP entry of a network or server ages out at an interval equal to three times the SAP update interval. To configure the multiplier that controls the interval, use the following command in interface configuration mode:
Command Purpose

ipx sap-multiplier multiplier

Configure the interval at which a network's or server's SAP entry ages out.

Configure SAP Update Packet Size

By default, the maximum size of SAP updates sent out an interface is 480 bytes. This size allows for 7 servers (64 bytes each), plus a 32-byte IPX SAP header. To modify the maximum packet size, use the following command in interface configuration mode:
Command Purpose

ipx sap-max-packetsize bytes

Configure the maximum packet size of SAP updates sent out an interface.

Enable SAP-after-RIP

The IPX SAP-after-RIP feature links Service Advertisement Protocol (SAP) updates to Routing Information Protocol (RIP) updates so that SAP broadcast and unicast updates automatically occur immediately after the completion of the corresponding RIP update. This feature ensures that a remote router does not reject service information because it lacks a valid route to the service. As a result of this feature, periodic SAP updates are sent at the same interval as RIP updates.

The default behavior of the router is to send RIP and SAP periodic updates with each using its own update interval, depending on the configuration. In addition, RIP and SAP periodic updates are jittered slightly, such that they tend to diverge from each other over time. This feature synchronizes SAP and RIP updates.

Benefits of SAP-after-RIP

Sending all SAP and RIP information in a single update reduces bandwidth demands and eliminates erroneous rejections of SAP broadcasts.

Linking SAP and RIP updates populates the remote router's service table more quickly, because services will not be rejected due to the lack of a route to the service. This can be especially useful on WAN circuits where the update intervals have been greatly increased to reduce the overall level of periodic update traffic on the link.

Send a SAP Update after RIP Broadcast

To configure the router to send a SAP update following a RIP broadcast, use the following command in interface configuration mode:
Command Purpose

ipx update sap-after-rip

Configure the router to send a SAP broadcast immediately following a RIP broadcast.

Disable Sending of General RIP or SAP Queries

You can disable the sending of general RIP and/or SAP queries on a link when it first comes up to reduce traffic and save bandwidth.

RIP and SAP general queries are normally sent by remote routers when a circuit first comes up. On WAN circuits, two full updates of each kind are often sent across the link. The first update is a full broadcast update, triggered locally by the link-up event. The second update is a specific (unicast) reply triggered by the general query received from the remote router. By disabling the sending of general queries when the link first comes up, it is possible to reduce traffic to a single update, and save bandwidth.

To disable the sending of a general RIP and/or SAP query when an interface comes up, use the following command in interface configuration mode:
Command Purpose

no ipx linkup-request {rip | sap}

Disable the sending of a general RIP and/or SAP Query when an interface comes up.

To re-enable the sending of a general RIP and/or SAP query, use the positive form of the command.

Control Responses to GNS Requests

You can set the method in which the router responds to SAP GNS requests, you can set the delay time in responding to these requests, or you can disable the sending of responses to these requests altogether.

By default, the router responds to GNS requests if appropriate. For example, if a local server with a better metric exists, then the router does not respond to the GNS request on that segment.

The default method of responding to GNS requests is to respond with the server whose availability was learned most recently.

To control responses to GNS requests, use one or both of the following commands in global configuration mode:
Command Purpose

ipx gns-round-robin

Respond to GNS requests using a round-robin selection method.

ipx gns-response-delay [milliseconds]

Set the delay when responding to GNS requests.


Note The ipx gns-response-delay command is also supported as an interface configuration command. To override the global delay value for a specific interface, use the ipx  gns-response-delay command in interface configuration mode.

You can also disable GNS queries on a per-interface basis. To do so, use the following command in interface configuration mode:
Command Purpose

ipx gns-reply-disable

Disable the sending of replies to GNS queries.

Configure Load Sharing

You can configure IPX to perform round-robin or per-host load sharing, as described in the following sections:

Enable Round-Robin Load Sharing

You can set the maximum number of equal-cost, parallel paths to a destination. (Note that when paths have differing costs, the Cisco IOS software chooses lower-cost routes in preference to higher-cost routes.) The software then distributes output on a packet-by-packet basis in round-robin fashion. 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. This round-robin scheme is used regardless of whether fast switching is enabled.

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.

To set the maximum number of paths, use the following command in global configuration mode:
Command Purpose

ipx maximum-paths paths

Set the maximum number of equal-cost paths to a destination.

Enable Per-Host Load Sharing

Round-robin load sharing is the default behavior when you configure ipx maximum-paths to a value greater than 1. Round-robin load sharing works by sending data packets over successive equal cost paths without regard to individual end hosts or user sessions. Path utilization is good, but, because packets destined for a given end host may take different paths, they might arrive out of order.

You can address the possibility of packets arriving out of order by enabling per-host load sharing. With per-host load sharing, the router still uses multiple, equal-cost paths to achieve load sharing; however, packets for a given end host are guaranteed to take the same path, even if multiple, equal-cost paths are available. Traffic for different end hosts tend to take different paths, but true load balancing is not guaranteed. The exact degree of load balancing achieved depends on the exact nature of the workload.

To enable per-host load sharing, use the following commands in global configuration mode:
Step Command Purpose

1 . 

ipx maximum-paths paths

Set the maximum number of equal cost paths to a destination to a value greater than 1.

2 . 

ipx per-host-load-share

Enable per-host load sharing.

Specify the Use of Broadcast Messages

You can specify the use of broadcast messages as described in the following sections:

Use Helper Addresses to Forward Broadcast Packets

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. However, you can enable the router to forward broadcast packets to helper addresses on other network segments.

How Helper Addresses Work

Helper addresses specify the network and node on another segment that can receive unrecognized broadcast packets. Unrecognized broadcast packets are non-RIP and non-SAP packets that are not addressed to the local network.

When the interface configured with helper addresses receives a unrecognized broadcast packet, Cisco  IOS software changes the broadcast packet to a unicast and sends the packet to the specified network and node on the other network segment. Unrecognized broadcast packets are not flooded everywhere in your network.

With helper addresses, there is no limit on the number of hops that the broadcast packet can make.

Fast Switching Support

Cisco IOS supports fast switching of helpered broadcast packets.

When to Use Helper Addresses

You use helper addresses when you want to forward broadcast packets (except type 20 packets) to other network segments.

Forwarding broadcast packets to helper addresses is sometimes useful when a network segment does not have an end-host capable of servicing a particular type of broadcast request. You can specify the address of a server, network, or networks that can process the broadcast packet.

Relationship between Helper Addresses and Type 20 Propagation

You use type 20 packet propagation to forward type 20 packets to other network segments. For information on forwarding type  20 packets, see the "Control the Forwarding of Type 20 Packets" section in this chapter.

You can use helper addresses and type 20 propagation together in your network. Use helper addresses to forward non-type 20 broadcast packets and use type 20 propagation to forward type 20 broadcast packets.

Implementation Considerations

Using helper addresses is not Novell-compliant however, it does allow routers to forward broadcast packets to network segments that can process them without flooding the network. It also allows routers running versions of Cisco IOS that do not support type 20 propagation to forward type 20 packets.

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. Use all-nets flooding carefully and only when necessary, because the receiving networks may be overwhelmed to the point that no other traffic can traverse them.

Use the ipx helper-list command, described earlier in this chapter, to define access lists that control which broadcast packets get forwarded.

Use Helper Addresses

To specify a helper address for forwarding broadcast packets, use the following command in interface configuration mode:
Command Purpose

ipx helper-address network.node

Specify a helper address for forwarding broadcast messages.

You can specify multiple helper addresses on an interface.

For an example of using helper addresses to forward broadcast messages, see the "Helper Facilities to Control Broadcast Examples" section at the end of this chapter.

Enable Fast Switching of IPX Directed Broadcast Packets

By default, Cisco IOS software switches packets that have been helpered to the broadcast address. To enable fast switching of these IPX-directed broadcast packets, use the following command in global configuration mode:
Command Purpose

ipx broadcast-fastswitching

Enable fast switching of IPX directed broadcast packets.

Disable IPX Fast Switching

By default, fast switching is enabled on all interfaces that support fast switching. However, you might want to turn off fast switching.

Fast switching allows higher throughput by switching a packet using a cache created by previous packets. Fast switching is enabled by default on all interfaces that support fast switching.

Packet transfer performance is generally better when fast switching is enabled. However, you might want to disable fast switching in order to save memory space on interface cards and to help avoid congestion when high-bandwidth interfaces are writing large amounts of information to low-bandwidth interfaces.

Caution Turning off fast switching increases system overhead.

To disable IPX fast switching, use the following command in interface configuration mode:
Command Purpose

no ipx route-cache

Disable IPX fast switching.

Adjust the Route Cache

Adjusting the route cache allows you to control the size of the route cache, reduce memory consumption, and improve router performance. You accomplish these tasks by controlling the route cache size and invalidation. The following sections describe these optional tasks:

Control Route Cache Size

You can limit the number of entries stored in the IPX route cache to free up router memory and aid router processing.

Storing too many entries in the route cache can use a significant amount of router memory, causing router processing to slow. This situation is most common on large networks that run network management applications for NetWare.

For example, if a network management station is responsible for managing all clients and servers in a very large (greater than 50,000 nodes) Novell network, the routers on the local segment can become inundated with route cache entries. You can set a maximum number of route cache entries on these routers to free up router memory and aid router processing.

To set a maximum limit on the number of entries in the IPX route cache, use the following command in global configuration mode:
Command Purpose

ipx route-cache max-size size

Set a maximum limit on the number of entries in the IPX route cache.

If the route cache has more entries than the specified limit, the extra entries are not deleted. However, they may be removed if route cache invalidation is in use. See the "Control Route Cache Invalidation" section in this chapter for more information on invalidating route cache entries.

Control Route Cache Invalidation

You can configure the router to invalidate fast switch cache entries that are inactive. If these entries remain invalidated for one minute, the router purges the entries from the route cache.

Purging invalidated entries reduces the size of the route cache, reduces memory consumption, and improves router performance. Also, purging entries helps ensure accurate route cache information.

You specify the period of time that valid fast switch cache entries must be inactive before the router invalidates them. You can also specify the number of cache entries that the router can invalidate per minute.

To configure the router to invalidate fast switch cache entries that are inactive, use the following command in global configuration mode:
Command Purpose

ipx route-cache inactivity-timeout period [rate]

Invalidate fast switch cache entries that are inactive.

When you use the ipx route-cache inactivity-timeout command with the ipx route-cache max-size command, you can ensure a small route cache with fresh entries.

Adjust Default Routes

You can adjust the use of default routes in your IPX network. You can turn off the use of network number -2 as the default route. You can also specify that the router advertise only default RIP routes out an interface. The following sections describe these optional tasks:

Disable Network Number -2 as the Default Route

The default route is used when a route to any destination network is unknown. All packets for which a route to the destination address is unknown are forwarded to the default route. By default, IPX treats network number -2 (0xFFFFFFFE) as the default route.

For an introduction to default routes, see the "IPX Default Routes" section in this chapter. For more background information on how to handle IPX default routes, refer to Novell's NetWare Link Services Protocol (NLSP) Specification, Revision 1.1.

By default, Cisco IOS software treats network -2 as the default route. You can disable this default behavior and use network -2 as a regular network number in your network.

To disable the use of network number -2 as the default route, use the following command in global configuration mode:
Command Purpose

no ipx default-route

Disable default route handling.

Advertise Only Default RIP Routes

Unless configured otherwise, all known RIP routes are advertised out each interface. However, you can choose to advertise only the default RIP route if it is known. This greatly reduces the CPU overhead when routing tables are large.

To advertise only the default route via an interface, use the following command in interface configuration mode:
Command Purpose

ipx advertise-default-route-only network

Advertise only the default RIP route.

Pad Odd-Length Packets

Some IPX end hosts accept only even-length Ethernet packets. If the length of a packet is odd, the packet must be padded with an extra byte so that end host can receive it. By default, Cisco IOS pads odd-length Ethernet packets.

However, there are cases in certain topologies where non-padded Ethernet packets are being forwarded onto a remote Ethernet network. Under specific conditions, you can enable padding on intermediate media as a temporary workaround for this problem. Note that you should perform this task only under the guidance of a customer engineer or other service representative.

To enable the padding of odd-length packets, use the following commands in interface configuration mode:
Step Command Purpose

1 . 

no ipx route-cache

Disable fast switching.

2 . 

ipx pad-process-switched-packets

Enable the padding of odd-length packets.

Shut Down an IPX Network

You can administratively shut down an IPX network in two ways. In the first way, 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 IPX network such that the network still exists in the configuration, use the following command in interface configuration mode:
Command Purpose

ipx down network

Shut down an IPX network, but have the network still exist in the configuration.

In the second way, you shut down an IPX network and remove it from the configuration. To do this, use one of the following commands in interface configuration mode:
Command Purpose

no ipx network

Shut down an IPX network and remove it from the configuration.

no ipx network network
(where network is 1, the primary interface)

When multiple networks are configured on an interface, shut down all networks and remove them from the interface.

no ipx network network
(where
network is the number of the secondary interface [not 1])

When multiple networks are configured on an interface, shut down one of the secondary networks and remove it from the interface.

When multiple networks are configured on an interface and you want shut down one of the secondary networks and remove it from the interface, use the second command in the previous table specifying the network number of one of the secondary networks.


Note In future Cisco IOS software releases, primary and secondary networks will not be supported.

For an example of shutting down an IPX network, see the "IPX Routing Examples" section at the end of this chapter.

Configure IPX Accounting

IPX accounting enables you to collect information about IPX packets and the number of bytes that are switched through the Cisco IOS software. You collect information based on the source and destination IPX address. IPX accounting tracks only IPX traffic that is routed out an interface on which IPX accounting is configured; it does not track traffic generated by or terminated at the router itself.

The Cisco IOS software maintains two accounting databases: an active database and a checkpoint database. The active database contains accounting data tracked until the database is cleared. When the active database is cleared, its contents are copied to the checkpoint database. Using these two databases together enables you to monitor both current traffic and traffic that has previously traversed the router.

Switching Support

Process and fast switching support IPX accounting statistics. Autonomous and SSE switching do not support IPX accounting statistics.

Access List Support

IPX access lists support IPX accounting statistics.

IPX Accounting Task List

You can configure IPX accounting by completing the tasks in the following sections. The first task is required. The remaining tasks are optional.

Enable IPX Accounting

To enable IPX accounting, use the following command in interface configuration mode:
Command Purpose

ipx accounting

Enable IPX accounting.

Customize IPX Accounting

To customize IPX accounting, use one or more of the following commands in global configuration mode:
Command Purpose

ipx accounting-threshold threshold

Set the maximum number of accounting entries.

ipx accounting-transits count

Set the maximum number of transit entries.

ipx accounting-list number mask

Filter networks for which IPX accounting information is kept. Use one command for each network.

Transit entries are entries in the database that do not match any of the networks specified by the ipx accounting-list commands.

If you enable IPX accounting on an interface but do not specify an accounting list, IPX accounting tracks all traffic through the interface (all transit entries) up to the accounting threshold limit.

For an example of how to configure IPX accounting, see the "IPX Accounting Example" section at the end of this chapter.

Monitor and Maintain the IPX Network

You can monitor and maintain your IPX network by performing the optional tasks described in the following sections:

Perform General Monitoring and Maintaining Tasks

You can perform one or more of these general monitoring and maintaining tasks as described in the following sections:

Monitor and Maintain Caches, Tables, Interfaces, and Statistics

To monitor and maintain caches, tables, interfaces, or statistics in a Novell IPX network, use one or more of the following commands at the EXEC prompt:
Command Purpose

clear ipx cache

Delete all entries in the IPX fast-switching cache.

clear ipx route [network | *]

Delete entries in the IPX routing table.

show ipx cache

List the entries in the IPX fast-switching cache.

show ipx interface [type number]

Display the status of the IPX interfaces configured in the router and the parameters configured on each interface.

show ipx route [network] [default] [detailed]

List the entries in the IPX routing table.

show ipx servers [unsorted | sorted [name | net | type]] [regexp name]

List the servers discovered through SAP advertisements.

show ipx traffic

Display information about the number and type of IPX packets transmitted and received.

show sse summary

Display a summary of SSP statistics.

Specify the Type and Use of Ping Packets

The Cisco IOS software can transmit Cisco pings and standard Novell pings as defined in the NLSP specification or diagnostic request packets. By default, the software generates Cisco pings. To choose the ping type, use the following command in global configuration mode:
Command Purpose

ipx ping-default {cisco | novell | diagnostic}

Select the ping type.

The IPX diagnostic ping feature addresses diagnostic related issues by accepting and processing unicast or broadcast diagnostic packets. It makes enhancements to the current IPX ping command to ping other stations using the diagnostic packets and display the configuration information in the response packet.


Note When a ping is sent from one station to another, the response is expected to come back immediately; when ipx ping-default is set to diagnostics, the response could consist of more than one packet and each node is expected to respond within 0.5 seconds of receipt of the request. Due to the absence of an end-of-message flag, there is a delay and the requester must wait for all responses to arrive. Therefore, in verbose mode there may be a brief delay of 0.5 seconds before the response data is displayed.

The ipx ping command using the diagnostic keyword can be used to conduct a reachability test and should not be used to measure accurate roundtrip delay.

To initiate a ping, use one of the following commands in EXEC mode:
Command Purpose

ping ipx network.node

Diagnose basic IPX network connectivity (user-level command).

ping [ipx] [network.node]

Diagnose basic IPX network connectivity (privileged command).

Repair Corrupted Network Numbers

To repair corrupted network numbers on an interface, use the following commands in interface configuration mode:
Step Command Purpose

1 . 

no ipx route-cache

Disable fast switching.

2 . 

ipx source-network-update

Repair corrupted network numbers.

Caution The ipx source-network-update interface configuration 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 interface configuration command on interfaces on which NetWare servers are using internal network numbers (that is, all NetWare 3.1x, 4.x, and NetWare IntraNetWare servers).

Troubleshoot Network Connectivity

To trace the IPX destination and measure roundtrip delays, use the following commands in EXEC mode:
Command Purpose

trace [protocol] [destination]

Trace packet routes through the network (privileged).

trace [protocol] [destination]

Trace packet routes through the network (user).


Note In user EXEC mode, you are not allowed to change the trace route timeout interval, probe count, minimum and maximum time to live, and verbose mode. To do so, use the trace EXEC privileged command.

Monitor and Maintain IPX Enhanced IGRP

To monitor and maintain Enhanced IGRP on an IPX network, use one or more of the following commands at the EXEC prompt:
Command Purpose

show ipx eigrp neighbors [servers] [autonomous-system-number | interface] [regexp name]

List the neighbors discovered by IPX Enhanced IGRP.

show ipx eigrp interfaces [interface] [as-number]

Display information about interfaces configured for Enhanced IGRP.

show ipx eigrp topology [network-number]

Display the contents of the IPX Enhanced IGRP topology table.

show ipx route [network-number]

Display the contents of the IPX routing table, including Enhanced IGRP entries.

show ipx traffic

Display information about IPX traffic, including Enhanced IGRP traffic.

Log Enhanced IGRP Neighbor Adjacency Changes

You can enable the logging of neighbor adjacency changes to monitor the stability of the routing system and to help you detect problems. By default, adjacency changes are not logged.

To enable logging of Enhanced IGRP neighbor adjacency changes, use the following command in global configuration mode:
Command Purpose

log-neighbor-changes

Enable logging of Enhanced IGRP neighbor adjacency changes.

Monitor and Maintain NLSP

To monitor and maintain NLSP on an IPX network, use one or more of the following commands at the EXEC prompt:
Command Purpose

clear ipx nlsp [tag] neighbors

Delete all NLSP adjacencies from the adjacency database.

show ipx nlsp [tag] database [lspid] [detail]

Display the entries in the link-state packet (LSP) database.

show ipx nlsp [tag] neighbors [interface] [detail]

Display the device's NLSP neighbors and their states.

show ipx nlsp [tag] spf-log

Display a history of the SPF calculations for NLSP.

Log Adjacency State Changes

You can allow NLSP to generate a log message when an NLSP adjacency changes state (up or down). This may be very useful when monitoring large networks. Messages are logged using the system error message facility. Messages are of the following 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

To generate log messages when an NLSP adjacency changes state, use the following command in router configuration mode:
Command Purpose

log-adjacency-changes

Log NLSP adjacency state changes.

Monitor and Maintain NHRP

To monitor the NHRP cache or traffic, use either of the following commands in EXEC mode:
Command Purpose

show ipx nhrp [dynamic | static] [type number]

Display the IPX NHRP cache, optionally limited to dynamic or static cache entries for a specific interface.

show ipx nhrp traffic

Display NHRP traffic statistics.

The NHRP cache can contain static entries caused by statically configured addresses and dynamic entries caused by the Cisco IOS software learning addresses from NHRP packets. To clear static entries, use the no ipx nhrp map command. To clear the NHRP cache of dynamic entries, use the following command in EXEC mode:
Command Purpose

clear ipx nhrp

Clear the IPX NHRP cache of dynamic entries.

Monitor and Maintain IPX Accounting

To monitor and maintain IPX accounting in your IPX network, use the following commands in EXEC mode:
Command Purpose

clear ipx accounting [checkpoint]

Delete all entries in the IPX accounting or accounting checkpoint database.

show ipx accounting [checkpoint]

List the entries in the IPX accounting or accounting checkpoint database.

Novell IPX Configuration Examples

This section provides configuration examples for the following IPX configuration situations:

IPX Routing Examples

This section shows examples for enabling IPX routing on interfaces with a single network and with multiple networks. It also shows how to enable and disable various combinations of routing protocols.

The following sections contain these examples:

IPX Routing on a Single Network Example

The following configuration commands enable IPX routing, defaulting the IPX host address to that of the first IEEE-conformance interface (in this example, Ethernet 0). Routing is then enabled on Ethernet 0 and Ethernet 1 for IPX networks 2abc and 1def, respectively.

ipx routing
interface ethernet 0
 ipx network 2abc
interface ethernet 1
 ipx network 1def

IPX Routing on Multiple Networks Examples

There are two ways to enable IPX on an interface that supports multiple networks. You can use subinterfaces or primary and secondary networks. This section gives an example of each.

Subinterfaces Example

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 routing
interface ethernet 0.1
  ipx network 1 encapsulation novell-ether
interface ethernet 0.2
  ipx network 2 encapsulation snap
interface ethernet 0.3
  ipx network 3 encapsulation arpa
interface ethernet 0.4
  ipx network 4 encapsulation sap

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 administratively shut down each of the four subinterfaces separately by using the shutdown interface configuration command for each subinterface. For example, the following commands administratively shut down a subinterface:

interface ethernet 0.3
 shutdown 

To bring down network 1, use the following commands:

interface ethernet 0.1
 ipx down 1

To bring network 1 back up, use the following commands:

interface ethernet 0.1
 no ipx down 1

To remove all the networks on the interface, use the following interface configuration commands:

interface ethernet 0.1
 no ipx network 
interface ethernet 0.2
 no ipx network
interface ethernet 0.3
 no ipx network
interface ethernet 0.4
 no ipx network
Primary and Secondary Networks Example

Note The following examples discuss primary and secondary networks. In future Cisco IOS software releases, primary and secondary networks will not be supported. Use subinterfaces.

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.

ipx routing
interface ethernet 0
  ipx network 1 encapsulation novell-ether
 ipx network 2 encapsulation snap secondary
 ipx network 3 encapsulation arpa secondary
 ipx network 4 encapsulation sap secondary

Using this method to configure logical networks, if you administratively shut down Ethernet interface 0 using the shutdown interface configuration command, all four logical networks are shut down. You cannot bring down each logical network independently using the shutdown command; however, you can do this using the ipx down command.

To shut down network 1, use the following command:

interface ethernet 0
 ipx down 1

To bring the network back up, use the following command:

interface ethernet 0
 no ipx down 1

To shut down all four networks on the interface and remove all the networks on the interface, use one of the following interface configuration commands:

 no ipx network 
 no ipx network 1

To remove one of the secondary networks on the interface (in this case, network 2), use the following interface configuration command:

 no ipx network 2

The following example enables IPX routing on a 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 routing
interface fddi 0.2
  ipx network f02 encapsulation snap
interface fddi 0.3
  ipx network f03 encapsulation novell-fddi

IPX Routing Protocols Examples

Three routing protocols can run over interfaces configured for IPX: RIP, Enhanced IGRP, and NLSP. This section provides examples of how to enable and disable various combinations of routing protocols.

When you enable IPX routing with the ipx routing global configuration command, the RIP routing protocol is automatically enabled. The following example enables RIP on networks 1 and 2:

ipx routing
!
interface ethernet 0
  ipx network 1
!
interface ethernet 1
 ipx network 2

The following example enables RIP on networks 1 and 2 and Enhanced IGRP on network 1:

ipx routing
!
interface ethernet 0
 ipx network 1
!
interface ethernet 1
 ipx network 2
!
ipx router eigrp 100
 network 1

The following example enables RIP on network 2 and Enhanced IGRP on network 1:

ipx routing
!
interface ethernet 0
 ipx network 1
!
interface ethernet 1
 ipx network 2
!
ipx router eigrp 100
 ipx network 1
!
ipx router rip
 no ipx network 1

The following example configures NLSP on two of a router's Ethernet interfaces. Note that RIP is automatically enabled on both of these interfaces. This example assumes that the encapsulation type is Ethernet 802.2.

ipx routing
 ipx internal-network 3
!
ipx router nlsp area1
area-address 0 0
!
interface ethernet 0
  ipx network e0 encapsulation sap
ipx nlsp area1 enable
!
interface ethernet 1
  ipx network e1 encapsulation sap
ipx nlsp area1 enable

Enhanced IGRP Examples

The following sections show several examples for configuring IPX Enhanced IGRP routing.

IPX Enhanced IGRP Example

The following example configures two interfaces for Enhanced IGRP routing in autonomous system  1:

ipx routing
!
interface ethernet 0
 ipx network 10
!
interface serial 0
 ipx network 20
!
ipx router eigrp 1
 network 10
 network 20

IPX SAP-Incremental IGRP Example

The following example shows a sample configuration for enabling the IPX SAP Enhanced IGRP:

ipx routing
!
  interface ethernet 0
  ipx network 1
  ipx sap-incremental eigrp 1
  ipx sap-incremental split-horizon
!
  ipx router eigrp 100
  network 1

Enhanced IGRP SAP Update Examples

If an Ethernet interface has neighbors that are all configured for Enhanced IGRP, you might want to reduce the bandwidth used by SAP packets by sending SAP updates incrementally. To do this, you would configure the interface as follows:

ipx routing
!
interface ethernet 0
 ipx network 10
 ipx sap-incremental eigrp 1
!
interface serial 0
 ipx network 20
!
ipx router eigrp 1
 network 10
 network 20

If you want to send only incremental SAP updates on a serial line that is configured for Enhanced IGRP, but periodic RIP updates, use the following commands:

ipx routing
!
interface ethernet 0
 ipx network 10
!
interface serial 0
 ipx network 20
  ipx sap-incremental eigrp 1 rsup-only
!
ipx router eigrp 1
 network 10
 network 20

Advertisement and Processing of SAP Update Examples

The following example causes only services from network 3 to be advertised by an Enhanced IGRP routing process:

access-list 1010 permit 3
access-list 1010 deny -1
!
ipx router eigrp 100
  network 3
  distribute-sap-list 1010 out

In the following example, the router redistributes Enhanced IGRP into NLSP area1. Only services for networks 2 and 3 are accepted by the NLSP routing process.

access-list 1000 permit 2
access-list 1000 permit 3
access-list 1000 deny -1
!
ipx router nlsp area1
  redistribute eigrp
  distribute-sap-list 1000 in

IPX Enhanced IGRP Bandwidth Configuration Example

The following example shows how to configure the bandwidth used by IPX Enhanced IGRP. In this example, Enhanced IGRP process 109 is configured to use a maximum of 25 percent (or 32 kbps) of a 128 kbps circuit:

interface serial 0
  bandwidth 128
  ipx bandwidth-percent eigrp 109 25

In the following example, the bandwidth of a 56 kbps circuit has been configured to be 20  kbps for routing policy reasons. The Enhanced IGRP process 109 is configured to use a maximum of 200  percent (or 40 kbps) of the circuit.

interface serial 1
  bandwidth 20
  ipx bandwidth-percent eigrp 109 200

NLSP Examples

The following sections show several examples for configuring NSLP.

NLSP Multicast Addressing Examples

By default, NLSP multicast addressing is enabled. You do not need to configure anything to turn on NLSP multicasting.

Typically, you do not want to substitute broadcast addressing where NLSP multicast addressing is available. NLSP multicast addressing uses network bandwidth more efficiently than broadcast addressing. However, there are circumstances where you might want to disable NLSP multicast addressing.

For example, you might want to disable NLSP multicast addressing in favor of broadcast addressing when one or more devices on a segment do not support NLSP multicast addressing. You might also want to disable it for testing purposes.

If you want to disable NLSP multicast addressing, you can do so for the entire router or for a particular interface.

The following sections provide sample configurations for disabling multicast addressing:

Disable NLSP Multicasting on the Router Example

The following example disables multicast addressing on the router:

ipx router nlsp
no multicast
Disable NLSP Multicasting on an Interface Example

The following example disables multicast addressing on Ethernet interface 1.2:

interface ethernet1.2
  no ipx nlsp multicast

Enhanced IGRP and NLSP Route Redistribution Example

The following example configures a router to redistribute NLSP into Enhanced IGRP autonomous system 100 and Enhanced IGRP autonomous system 100 into NLSP:

!
ipx router eigrp 100
  redistribute nlsp
!
ipx router nlsp
  redistribute eigrp 100
!

NLSP Route Aggregation for Multiple NLSP Version 1.1 Areas Example

The following example shows the route aggregation configuration for a router connecting multiple NLSP version 1.1 areas. In this example, the two areas are area1 and area2. Because both areas are NLSP version 1.1 areas, redistribution of aggregated routes or explicit routes between the two areas is automatic.

ipx routing
ipx internal-network 2000
!
interface ethernet 1
  ipx network 1001
  ipx nlsp area1 enable
!
interface ethernet 2
  ipx network 2001
  ipx nlsp area2 enable
!
ipx router nlsp area1
  area-address 1000 fffff000
  route-aggregation
!
ipx router nlsp area2
  area-address 2000 fffff000
  route-aggregation

NLSP Route Aggregation for NLSP Version 1.1 and Version 1.0 Areas Example

The following example configures the route aggregation feature with customized route summarization. In this example, area1 is an NLSP version 1.0 area and area2 is an NLSP version  1.1 area. Any explicit routes learned in area1 that fall in the range of aaaa0000 ffff0000 are redistributed into area2 as an aggregated route. Explicit routes from area1 that do not fall in that range are redistributed into area2 as an explicit route.

Because area1 is an NLSP version 1.0 area, it cannot accept aggregated routes learned in area2. Thus, when redistribution into area1 occurs, the router sends explicit routes instead of aggregated routes.

ipx routing
ipx internal-network 2000 ! interface ethernet 1
 ipx network 1001
 ipx nlsp area1 enable ! interface ethernet 2
 ipx network 2001
 ipx nlsp area2 enable ! access-list 1200 deny aaaa0000 ffff0000
access-list 1200 permit -1 ! ipx router nlsp area1
 area-address 1000 fffff000 ! ipx router nlsp area2
 area-address 2000 fffff000  route-aggregation
 redistribute nlsp area1 access-list 1200

NLSP Route Aggregation for NLSP Version 1.1, Enhanced IGRP, and RIP Example

In the following example, the router connects two NLSP version 1.1 areas, one Enhanced IGRP area, and one RIP area.

Any routes learned via NLSP a1 that are represented by aaaa0000 ffff0000 are not redistributed into NLSP a2 as explicit routes. Instead, the router generates an aggregated route. Any routes learned via NLSP a2 that are represented by bbbb0000 ffff0000 are not redistributed as explicit routes into NLSP a1. Again, the router generates an aggregated route. Any routes learned via RIP that are represented by cccc0000 ffff0000 are not redistributed as explicit routes into NLSP a1 or NLSP a2. Instead, the router sends an aggregated route. Likewise, any routes learned via Enhanced IGRP 129 that are represented by dddd0000 ffff0000 are not redistributed into NLSP a1 or NLSP a2. Again, the router sends an aggregated route.

ipx routing
ipx internal-network 2000
!
interface ethernet 0
  ipx network aaaa0000
  ipx nlsp a1 enable
!
interface ethernet 1
  ipx network bbbb0000
  ipx nlsp a2 enable
!
interface ethernet 2
  ipx network cccc0000
!
interface ethernet 3
  ipx network dddd0000
!
access-list 1200 deny aaaa0000 ffff0000
access-list 1200 permit -1
!
access-list 1201 deny bbbb0000 ffff0000
access-list 1201 permit -1
!
access-list 1202 deny cccc0000 ffff0000
access-list 1202 permit -1
!
access-list 1203 deny dddd0000 ffff0000
access-list 1203 permit -1
!
ipx router nlsp a1
  area-address 10000 fffff000
  route-aggregation
  redistribute nlsp a2 access-list 1201
  redistribute rip access-list 1202
  redistribute eigrp 129 access-list 1203
!
ipx router nlsp a2
  area-address 2000 fffff000
  route-aggregation
  redistribute nlsp a1 access-list 1200
  redistribute rip access-list 1202
  redistribute eigrp 129 access-list 1203
!
ipx router eigrp 129
  network dddd0000
  redistribute nlsp a1
  redistribute nlsp a2

NHRP Examples

The following sections show examples for configuring NHRP.

NHRP Example

A logical NBMA network is considered the group of interfaces and hosts participating in NHRP and having the same network identifier. Figure 16 illustrates two logical NBMA networks (shown as circles) configured over a single physical NBMA network. Router A communicates with Routers  B and C because they share the same network identifier (2). Router C also communicates with Routers  D and E because they share network identifier 7. After address resolution is complete, Router  A sends IPX packets to Router C in one hop, and Router C sends them to Router E in one hop, as shown by the dotted lines.


Figure 16: Two Logical NBMA Networks over One Physical NBMA Network


The physical configuration of the five routers in Figure 16 might actually be that shown in Figure 17. The source host is connected to Router A, and the destination host is connected to Router  E. The same switch serves all five routers, making one physical NBMA network.


Figure 17: Physical Configuration of a Sample NBMA Network


Refer again to Figure 16. Initially, before NHRP resolves any NBMA addresses, IPX packets from the source host to the destination host travel through all five routers connected to the switch before reaching the destination. When Router A first forwards the IPX packet toward the destination host, Router A also generates an NHRP request for the destination host's IPX address. The request is forwarded to Router  C, where a reply is generated. Router C replies because it is the egress router between the two logical NBMA networks.

Similarly, Router C generates an NHRP request of its own, to which Router E replies. In this example, subsequent IPX traffic between the source and the destination still requires two hops to traverse the NBMA network because the IPX traffic must be forwarded between the two logical NBMA networks. Only one hop would be required if the NBMA network was not logically divided.

NHRP over ATM Example

The following example shows a configuration of three routers using NHRP over ATM. Router A is configured with a static route, which it uses to reach the IPX network where Router B resides. Router A initially reaches Router B through Router C. Router A and Router B directly communicate without Router C once NHRP resolves Router A's and Router C's respective NSAP addresses.

The significant portions of the configurations for Routers A, B, and C follow:

Router A
interface ATM0/0
  map-group a
 atm nsap-address 11.1111.11.111111.1111.1111.1111.1111.1111.1111.11
 atm rate-queue 1 10
 atm pvc 1 0 5 qsaal
  ipx network 1
  ipx nhrp network-id 1
map-list a
ipx 1.0000.0c15.3588 atm-nsap 33.3333.33.333333.3333.3333.3333.3333.3333.3333.33
ipx route 2 1.0000.0c15.3588
Router B
interface ATM0/0
  map-group a
 atm nsap-address 22.2222.22.222222.2222.2222.2222.2222.2222.2222.22
 atm rate-queue 1 10
 atm pvc 2 0 5 qsaal
  ipx network 2
  ipx nhrp network-id 1
map-list a
ipx 2.0000.0c15.3628 atm-nsap 33.3333.33.333333.3333.3333.3333.3333.3333.3333.33
ipx route 1 2.0000.0c15.3628
Router C
interface ATM0/0
atm rate-queue 1 10
 atm pvc 2 0 5 qsaal
interface ATM0/0.1 multipoint
  map-group a
 atm nsap-address 33.3333.33.333333.3333.3333.3333.3333.3333.3333.33
  ipx network 1
  ipx nhrp network-id 1
interface ATM0/0.2 multipoint
  map-group b
 atm nsap-address 33.3333.33.333333.3333.3333.3333.3333.3333.3333.33
  ipx network 2
  ipx nhrp network-id 2
map-list a
ipx 1.0000.0c15.4f80 atm-nsap 11.1111.11.111111.1111.1111.1111.1111.1111.1111.11
map-list b
ipx 2.0000.0c15.5021 atm-nsap 22.2222.22.222222.2222.2222.2222.2222.2222.2222.22

IPX over WAN Examples

The following sections show examples for configuring IPX over WAN and dial interfaces.

IPX over a WAN Interface Example

When you configure the Cisco IOS software to transport IPX packets over a serial interface that is running a WAN protocol such as X.25 or PPP, you specify how the packet will be encapsulated for transport. This encapsulation is not the same as the encapsulation used on an IPX LAN interface. Figure 18 illustrates IPX over a WAN interface.


Figure 18: IPX over a WAN Interface


The following examples configure a serial interface for X.25 encapsulation and for several IPX subinterfaces used in a nonmeshed topology:

Configuration for Main Router
hostname Main
!
no ip routing
novell routing 0000.0c17.d726
!
interface ethernet 0
 no ip address
 Novell network 100
 media-type 10BaseT
!
interface serial 0
 no ip address
 shutdown
!
interface serial 1
 no ip address
 encapsulation x25
 x25 address 33333
 x25 htc 28
!
interface serial 1.1 point-to-point
 no ip address
 novell network 2
 x25 map novell 2.0000.0c03.a4ad 11111 BROADCAST
!
interface serial 1.2 point-to-point
 no ip address
 novell network 3
 x25 map novell 3.0000.0c07.5e26 55555 BROADCAST
Configuration for Router 1
hostname Remote1
!
no ip routing
novell routing 0000.0c03.a4ad
!
interface ethernet 0
 no ip address
 novell network 1
!
interface serial 0
 no ip address
 encapsulation x25
 novell network 2
 x25 address 11111
 x25 htc 28
 x25 map novell 2.0000.0c17.d726 33333 BROADCAST
Configuration for Router 2
hostname Remote2
!
no ip routing
novell routing 0000.0c07.5e26
!
interface ethernet 0
 no ip address
 novell network 4
 media-type 10BaseT
!
interface serial 0
 no ip address
 shutdown
!
interface serial 1
 no ip address
 encapsulation x25
 novell network 3
 x25 address 55555
 x25 htc 28
 x25 map novell 3.0000.0c17.d726 33333 BROADCAST

IPX over DDR Example

In the configuration shown in Figure 19, an IPX client is separated from its server by a DDR telephone line.


Figure 19: IPX over DDR Configuration


Routing and service information is sent every minute. The output RIP and SAP filters defined in this example filter these updates, preventing them from being sent between Routers A and B. If you were to forward these packets, the two routers would each have to telephone the other once a minute. On a serial link that charges based on the number of packets transmitted, this is generally not desirable. This might not be an issue on a dedicated serial line.

Once the server and client have established contact, the server will send keepalive (watchdog) packets regularly. When SPX is used, both the server and the client send keepalive packets. The purpose of these packets is to ensure that the connection between the server and the client is still functional; these packets contain no other information. Servers send watchdog packets approximately every 5  minutes.

If you were to allow Router A to forward the server's keepalive packets to Router B, Router A would have to telephone Router B every 5  minutes just to send these packets. Again, on a serial link that charges based on the number of packets transmitted, this is generally not desirable. Instead of having Router A telephone Router B only to send keepalive packets, you can enable watchdog spoofing on Router A. This way, when the server connected to this router sends keepalive packets, Router A will respond on behalf of the remote client (the client connected to Router B). When SPX is used, you must enable spoofing of SPX keepalive packets on both Router A and Router B to inhibit the sending of them because both the server and the client send keepalive packets.

Configuration for Router A
novell routing 0000.0c04.4878
!
interface Ethernet0
 novell network 15200
!
interface Serial0
!ppp encap for DDR(recommended) encapsulation ppp novell network DD1DD2
!kill all rip updates novell output-network-filter 801
!kill all sap updates novell output-sap-filter 1001
! fast-switching off for watchdog spoofing no novell route-cache
!don't listen to rip novell router-filter 866
!novell watchdog spoofing novell watchdog-spoof !SPX watchdog spoofing
ipx spx-spoof
!turn on DDR dialer in-band dialer idle-timeout 200 dialer map IP 198.92.96.132 name R13 7917 dialer map NOVELL DD1DD2.0000.0c03.e3c3 7917 dialer-group 1 ppp authentication chap
!chap authentication required pulse-time 1 ! access-list 801 deny FFFFFFFF access-list 866 deny FFFFFFFF
!serialization packets access-list 900 deny 0 FFFFFFFF 0 FFFFFFFF 457
!RIP packets access-list 900 deny 1 FFFFFFFF 453 FFFFFFFF 453
!SAP packets access-list 900 deny 4 FFFFFFFF 452 FFFFFFFF 452
!permit everything else access-list 900 permit -1 FFFFFFFF 0 FFFFFFFF 0 ! access-list 1001 deny FFFFFFFF !
!static novell route for remote network novell route DD1 DD1DD2.0000.0c03.e3c3 ! !
!IPX will trigger the line up (9.21 and later) dialer-list 1 list 900
Configuration for Router B
novell routing 0000.0c03.e3c3
!
interface Ethernet1/0
 novell network DD1
!
interface Serial2/0
 encapsulation ppp
 novell network DD1DD2
 novell output-network-filter 801
 novell output-sap-filter 1001
 no novell route-cache
 novell router-filter 866
 ipx spx-spoof
 dialer in-band
 dialer idle-timeout 200
 dialer map IP 198.92.96.129 name R5 7919
 dialer map NOVELL DD1DD2.0000.0c04.4878 7919
 dialer-group 1
 ppp authentication chap
 pulse-time 1
!
access-list 801 deny -1
access-list 866 deny -1
access-list 900 deny  0 FFFFFFFF 0 FFFFFFFF 457
access-list 900 deny  1 FFFFFFFF 453 FFFFFFFF 453
access-list 900 deny  4 FFFFFFFF 452 FFFFFFFF 452
access-list 900 permit -1 FFFFFFFF 0 FFFFFFFF 0
access-list 1001 deny  FFFFFFFF
!
!static novell route for server's internal network novell route 1234 DD1DD2.0000.0c04.4878
novell route 15200 DD1DD2.0000.0c04.4878
!static route !The following line is the static novell sap required to get to the remote server. !It informs the router of the next hop. novell sap 4 CE1-LAB 1234.0000.0000.0001 451 4 <==== ! dialer-list 1 list 900

IPX Network Access Examples

The following sections contain examples for controlling access to your IPX network. The sections show the configurations for various access lists and filters.

IPX Network Access Example

Using access lists to manage traffic routing is a powerful tool in overall network control. However, it requires a certain amount of planning and the appropriate application of several related commands. Figure 20 illustrates a network featuring two routers on two network segments.


Figure 20: Novell IPX Servers Requiring Access Control


Suppose you want to prevent clients and servers on Network aa from using the services on Network bb, but you want to allow the clients and servers on Network bb to use the services on Network aa. To do this, you would need an access list on Ethernet interface 1 on Router 2 that blocks all packets coming from Network aa and destined for Network bb. You would not need any access list on Ethernet interface 0 on Router 1.

You would configure Ethernet interface 1 on Router 2 with the following commands:

ipx routing
access-list 800 deny aa bb01
access-list 800 permit -1 -1
interface ethernet 1
 ipx network bb
 ipx access-group 800

You can accomplish the same result as the previous example more efficiently. For example, you can place the same output filter on Router 1, interface serial 0. Or, you could also place an input filter on interface Ethernet  0 of Router 1, as follows:

ipx routing
access-list 800 deny aa bb01
access-list 800 permit -1 -1
interface ethernet 0
 ipx network aa
 ipx access-group 800 in

Note When using access control list logging on an interface with fast switching turned on, packets that match the access list (and thus need to be logged) are slow switched, not fast switched.
Logging Access Control List Violations

You can keep a log of all access control list violations by using the keyword log at the end of the access-list command, as follows:

access-list 907 deny -1 -1 0 100 0 log

The previous example denies and logs all packets that arrive at the router from any source in any protocol from any socket to any destination on network 100.

The following is an example of a log entry for the access-list command:

%IPX-6-ACL: 907 deny SPX B5A8 50.0000.0000.0001 B5A8 100.0000.0000.0001 10 pkts

In this example, 10 SPX packets were denied because they matched access list number 907. The packets were coming from socket B5A8 on networks 50.0000.0000.0001 and were destined for socket B5A8 on network 100.0000.0000.0001.

Standard Named Access List Example

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

ipx access-list standard fred
  deny 5678 any
  permit any

SAP Input Filter Example

SAP input filters allow a router to determine whether to accept information about a service.
Router C1, illustrated in Figure 21, will not accept and, consequently not advertise, any information about Novell server F. However, Router C1 will accept information about all other servers on the network 3c. Router C2 receives information about servers D and B.


Figure 21: SAP Input Filter

The following example configures Router C1. The first line denies server F, and the second line accepts all other servers.

access-list 1000 deny 3c01.0000.0000.0001
access-list 1000 permit -1
interface ethernet 0
 ipx network 3c
 ipx input-sap-filter 1000
interface ethernet 1
 ipx network 4d
interface serial 0
 ipx network 2b

Note NetWare Versions 3.11 and later use an internal network and node number as their address for access list commands (the first configuration command in this example).

SAP Output Filter Example

SAP output filters are applied prior to the Cisco IOS software sending information out a specific interface. In the example that follows, Router C1 (illustrated in Figure 22) is prevented from advertising information about Novell server A out interface Ethernet 1, but can advertise server A on network 3c.


Figure 22: SAP Output Filter


The following example refers to Router C1. The first line denies server A. All other servers are permitted.

access-list 1000 deny aa01.0000.0000.0001
access-list 1000 permit -1
interface ethernet 0
 novell net 3c
interface ethernet 1
 ipx network 4d
 ipx output-sap-filter 1000
interface serial 0
 ipx network 2b

IPX NetBIOS Filter Examples

The following is an example of using a NetBIOS host name to filter IPX NetBIOS frames. The example denies all outgoing IPX NetBIOS frames with a NetBIOS host name of Boston on Ethernet interface 0:

netbios access-list host token deny Boston
netbios access-list host token permit *
!
ipx routing 0000.0c17.d45d
!
interface ethernet 0
 ipx network 155 encapsulation ARPA
 ipx output-rip-delay 60
  ipx triggered-rip-delay 30
 ipx output-sap-delay 60
  ipx triggered-sap-delay 30
 ipx type-20-propagation
 ipx netbios output-access-filter host token
 no mop enabled
!
interface ethernet 1
 no ip address
  ipx network 105
!
interface fddi 0
 no ip address
 no keepalive
ipx network 305 encapsulation SAP
!
interface serial 0
 no ip address
 shutdown
!
interface serial 1
 no ip address
 no keepalive
 ipx network 600
 ipx output-rip-delay 100
  ipx triggered-rip-delay 60
 ipx output-sap-delay 100
  ipx triggered-sap-delay 60
 ipx type-20-propagation

The following is an example of using a byte pattern to filter IPX NetBIOS frames. This example permits IPX NetBIOS frames from IPX network numbers that end in 05. This means that all IPX NetBIOS frames from Ethernet interface 1 (network 105) and FDDI interface 0 (network 305) will be forwarded by serial interface 0. However, this interface will filter out and not forward all frames from Ethernet interface 0 (network 155).

netbios access-list bytes finigan permit 2 **05
!
ipx routing 0000.0c17.d45d
!
ipx default-output-rip-delay 1000
ipx default-triggered-rip-delay 100
ipx default-output-sap-delay 1000
ipx default-triggered-sap-delay 100
!
interface ethernet 0
 ipx network 155 encapsulation ARPA
 ipx output-rip-delay 55
  ipx triggered-rip-delay 55
 ipx output-sap-delay 55
  ipx triggered-sap-delay 55
 ipx type-20-propagation
 media-type 10BaseT
!
interface ethernet 1
 no ip address
 ipx network 105
  ipx output-rip-delay 55
  ipx triggered-rip-delay 55
 ipx output-sap-delay 55
  ipx triggered-sap-delay 55
  media-type 10BaseT
!
interface fddi 0
 no ip address
 no keepalive
 ipx network 305 encapsulation SAP
  ipx output-sap-delay 55
  ipx triggered-sap-delay 55
!
interface serial 0
 no ip address
 shutdown
!
interface serial 1
 no ip address
 no keepalive
 ipx network 600
  ipx type-20-propagation
 ipx netbios input-access-filter bytes finigan

Helper Facilities to Control Broadcast Examples

The following sections illustrate how to control broadcast messages on IPX networks.

Note that in the following examples, packet type 2 is used. This type has been chosen arbitrarily; the actual type to use depends on the specific application.

Forwarding to an Address Example

All broadcast packets are normally blocked by the Cisco IOS software. However, type 20 propagation packets may be forwarded, subject to certain loop-prevention checks. Other broadcasts may be directed to a set of networks or a specific host (node) on a segment. The following examples illustrate these options.

Figure 23 shows a router (C1) connected to several Ethernet interfaces. In this environment, all IPX clients are attached to segment aa, while all servers are attached to segments bb and dd. In controlling broadcasts, the following conditions are to be applied:


Figure 23: IPX Clients Requiring Server Access through a Router


The following example configures the router shown in Figure 23. The first line permits broadcast traffic of type 2 from network aa. The interface and network commands configure each specific interface. The ipx helper-address commands permit broadcast forwarding from network aa to bb and from network aa to dd. The helper list allows type 2 broadcasts to be forwarded. (Note that type  2 broadcasts are chosen as an example only. The actual type to use depends on the application.) The ipx type-20-propagation command is also required to allow type 20 broadcasts, usually IPX. NetBIOS, to be forwarded to all networks where type-20 propagation is enabled. The IPX helper-list filter is applied to both the type 2 packets forwarded by the helper-address mechanism and the type 20 packets forwarded by type-20 propagation.

access-list 900 permit 2 aa
interface ethernet 0
 ipx network aa
 ipx type-20-propagation
 ipx helper-address bb.ffff.ffff.ffff
 ipx helper-address dd.ffff.ffff.ffff
 ipx helper-list 900
interface ethernet 1
 ipx network bb
interface ethernet 3
 ipx network dd
 ipx type-20-propagation

This configuration means that any network that is downstream from network aa (for example, some arbitrary network aa1) will not be able to broadcast (type 2) to network bb through Router C1 unless the routers partitioning networks aa and aa1 are configured to forward these broadcasts with a series of configuration entries analogous to the example provided for Figure 23. These entries must be applied to the input interface and be set to forward broadcasts between directly connected networks. In this way, such traffic can be passed along in a directed manner from network to network. A similar situation exists for type 20 packets.

The following example rewrites the ipx helper-address interface configuration command line to direct broadcasts to server  A:

ipx helper-address bb.00b4.23cd.110a
! Permits node-specific broadcast forwarding to
! Server A at address 00b4.23cd.110a on network bb 

Forwarding to All Networks Example

In some networks, it might be necessary to allow client nodes to broadcast to servers on multiple networks. If you configure your router to forward broadcasts to all attached networks, you are flooding the interfaces. In the environment illustrated in Figure 24, client nodes on network 2b1 must obtain services from IPX servers on networks 3c2, 4a1, and 5bb through Router C1. To support this requirement, use the flooding address (-1.ffff.ffff.ffff) in your ipx  helper-address interface configuration command specifications.


Figure 24: Type 2 Broadcast Flooding


In the following example, the first line permits traffic of type 2 from network 2b1. Then the first interface is configured with a network number. The all-nets helper address is defined and the helper list limits forwarding to type 2 traffic.Type 2 broadcasts from network 2b1 are forwarded to all directly connected networks. All other broadcasts, including type 20, are blocked. To permit broadcasts, delete the ipx  helper-list entry. To allow type 20 broadcast, enable the ipx  type-20-propagation interface configuration command on all interfaces.

access-list 901 permit 2 2b1
interface ethernet 0
 ipx network 2b1
 ipx helper-address -1.ffff.ffff.ffff
 ipx helper-list 901
interface ethernet 1
 ipx network 3c2
interface ethernet 2
 ipx network 4a1
interface ethernet 3
 ipx network 5bb

All-Nets Flooded Broadcast Example

The following example configures all-nets flooding on an interface. As a result of this configuration, Ethernet interface 0 will forward all broadcast messages (except type 20) to all the networks it knows how to reach. This flooding of broadcast messages might overwhelm these networks with so much broadcast traffic that no other traffic may be able to pass on them.

interface ethernet 0
 ipx network 23
 ipx helper-address -1.FFFF.FFFF.FFFF

IPX Accounting Example

The following example configures two Ethernet network segments that are connected via a serial link (see Figure 25). On Router A, IPX accounting is enabled on both the input and output interfaces (that is, on Ethernet interface 0 and serial interface 0). This means that statistics are gathered for traffic traveling in both directions (that is, out to the Ethernet network and out the serial link).

On Router B, IPX accounting is enabled only on the serial interface and not on the Ethernet interface. This means that statistics are gathered only for traffic that passes out the router on the serial link. Also the accounting threshold is set to 1000, which means that IPX accounting will track all IPX traffic passing through the router up to 1000 source and destination pairs.


Figure 25: IPX Accounting Example


Configuration for Router A
ipx routing
interface ethernet 0
 no ip address
 ipx network C003
 ipx accounting
interface serial 0
 no ip address
 ipx network 200
 ipx accounting
Configuration for Router B
ipx routing
interface ethernet 1
 no ip address
 no keepalive
 ipx network C001
 no mop enabled
interface serial 1
 no ip address
 ipx network 200
 ipx accounting
  ipx accounting-threshold 1000


hometocprevnextglossaryfeedbacksearchhelp
Copyright 1989-1998 © Cisco Systems Inc.