|
|
Novell Internet Packet Exchange (IPX) is derived from the Xerox Network Systems (XNS) Internet Datagram Protocol (IDP). IPX and XNS have the following differences:
This chapter describes how to configure Novell IPX and provides configuration examples. For a complete description of the commands mentioned in this chapter, refer to the "Novell IPX Commands" chapter in the Access and Communication Servers Command Reference publication. For historical background and a technical overview of Novell IPX, see the Internetworking Technology Overview publication.
Cisco's implementation of Novell's IPX protocol has been certified as providing full IPX router functionality. When configured as a router, a Cisco communication server connects Ethernet and Token Ring networks, either directly or through high-speed serial lines (56 kbps to T1 speeds), X.25, or Frame Relay. At this time, the Cisco X.25 and T1 support is not compatible with Novell. This means that our communication servers must be used on both ends of T1 and X.25 circuits.
Cisco supports the IPX MIB. The IPX Accounting group represents one of the local variables we support. This group provides access to the active database that is created and maintained if IPX accounting is enabled on a communication server.
Cisco routers also support IPX Enhanced IGRP, which provides the following features:
An IPX network address consists of a network number and a node number expressed in the format network.node.
The network number identifies a physical network. It is a four-byte (32-bit) quantity that must be unique throughout the entire IPX internetwork. The network number is expressed as eight hexadecimal digits. Our communication server software does not require that you enter all eight digits: you can omit leading zeros.
The node number identifies a node on the network. It is a 48-bit quantity, represented by dotted triplets of four-digit hexadecimal numbers.
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.
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 "Configuration Examples" section at the end of this chapter for configuration examples.
To enable IPX routing, you must perform the tasks described in the following sections:
The first step in enabling IPX routing is to enable it on the communication server. If you do not specify the node number of the communication server, the communication server 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 or Token Ring interface card.
To enable IPX routing, perform the following global configuration task:
| Task | Command |
|---|---|
Enable IPX routing on the communication server. |
For an example of how to enable IPX routing, see the section "Enabling IPX Routing Example" at the end of this chapter.
After you have enabled IPX routing on the communication server, you assign network numbers to individual interfaces. This has the effect of enabling IPX routing on those interfaces. When you enable IPX routing on an interface, you also can specify an encapsulation (frame type) to use for packets being transmitted on that 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.
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 communication server to determine which packets belong to which 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.
The following sections describe how to enable IPX routing on interfaces that support a single network and those that support multiple networks.
To assign a network number to an interface that supports a single network, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
If you specify an encapsulation type, make sure you choose the one that matches the encapsulation used by the servers and clients on that network.
For an example of how to enable IPX routing, see the section "Enabling IPX Routing Example" in this publication.
To assign network numbers to interfaces that support multiple networks, you normally use subinterfaces. 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 the encapsulation tyhpe used by the clients and servers using the same network number. To run NLSP on multiple networks on the same physical LAN interface, you must configure subinterfaces.
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, perform the following tasks starting in global configuration mode:
| Task | Command |
|---|---|
interface type interface-number.subinterface-number | |
Step 2. Enable IPX routing, specifying the first encapsulation type. |
To configure more than one subinterface, repeat these two steps.
For examples of configuring multiple IPX networks on an interface, see the section "Enabling and Disabling IPX Routing on Multiple Networks Example" later in this chapter.
Table 20-1 lists the encapsulation types you can use on IEEE interfaces and shows the correspondence between the encapsulation type and the IPX frame type.
| Interface Type | Encapsulation Type | IPX Frame Type |
|---|---|---|
Ethernet | novell-ether (default) | Ethernet_802.3 |
Token Ring | sap (default) | Token-Ring |
FDDI | snap (default) | Fddi_Snap |
When assigning network numbers to interfaces that support multiple networks, you can also configure primary and secondary networks. 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, perform the following tasks in interface configuration mode:
| Task | Command |
|---|---|
ipx network network encapsulation encapsulation-type | |
ipx network network encapsulation encapsulation-type secondary |
To configure more than one secondary network, repeat Step 2 as appropriate.
The NetWare Link Services Protocol (NLSP) is a link-state routing protocol based on the Open Systems 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.
Level 1 routers are used to 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 current NLSP specification defines only level 1 procedures, which allow operation within a routing area and routing to the nearest level 2 router only.
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 communication servers in the area, the links connecting them, the operational status of the communication servers and links, and other related parameters. For each point-to-point link, the database records the end-point communication servers and the state of the link. For each LAN, the database records which communication servers 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.
Our implementation of NLSP is based on revision 1.0 of the Novell NLSP specification, which specifies routing with a routing area (that is, Level 1 routing). Our implementation of NLSP also includes NLSP MIB variables.
NLSP is a link-state protocol. This means that every communication server in a routing area maintains an identical copy of the link-state database, which contains all information about the topology of the area. All communication servers synchronize their views of the databases among themselves to keep their copies of the link-state databases consistent. NLSP has three major databases:
To configure NLSP, you must have configured IPX routing on your communication server, as described 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 section "Enabling and Disabling IPX Routing Protocols Examples" in this chapter.
An internal network number is a number assigned to the communication server. In order for NLSP to operate, you must configure an internal network number for each communication server.
To enable IPX routing and define an internal network numbers, perform the following task in global configuration mode:
| Task | Command |
|---|---|
Enable IPX routing. | ipx routing |
To enable NLSP on the communication server, perform the following tasks starting in global configuration mode:
| Task | Command |
|---|---|
Step 1. Enable NLSP on the communication server. | |
You configure NLSP differently on LAN and WAN interfaces, as described in the following sections.
To configure NLSP on a LAN interface, perform the following tasks in interface configuration mode:
| Task | Command |
|---|---|
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, perform the following tasks starting in global configuration mode:
| Task | Command |
|---|---|
Step 1. Specify a subinterface. | interface type interface-number.subinterface-number |
Step 2. Enable IPX routing, specifying the first encapsulation type. | ipx network network encapsulation encapsulation-type |
Step 3. Enable NLSP on the subinterface. | ipx nlsp enable |
Repeat these three steps for each subinterface.
To configure NLSP on a WAN interface, perform the following tasks starting in global configuration mode:
| Task | Command |
|---|---|
interface serial number | |
Step 2. Enable IPXWAN. | ipx ipxwan [local-node unnumbered local-server-name retry-interval retry-limit] |
RIP and 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 udpates on a network enabled for NLSP, perform one of the following tasks in interface configuration mode:
| Task | Command |
|---|---|
Never generate RIP periodic traffic. | |
Always generate RIP periodic traffic. | ipx nlsp rip on |
Send RIP periodic traffic only if another RIP router is sending periodic RIP traffic. (This is the default on interfaces configured for NLSP.) | ipx nlsp rip auto |
To modify the generation of periodic SAP updates on a network enabled for NLSP, perform one of the following tasks in interface configuration mode:
| Task | Command |
|---|---|
Never generate SAP periodic traffic. | |
Always generate SAP periodic traffic. | ipx nlsp sap on |
Send SAP periodic traffic only if another SAP service is sending periodic SAP traffic. (This is the default on interfaces configured for NLSP.) | ipx nlsp sap auto |
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. To modify the maximum hop count, perform the following task in global configuration mode:
| Task | Command |
|---|---|
The delay and throughput of each link is used by NLSP as part of its route calculations. By default, these parameters are set to reasonable values or, in the case of IPXWAN, are dynamically measured.
The link delay and throughput you specify 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, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
To change the throughput, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
NLSP assigns a default link cost (metric) based on the link throughput. If desired, you can set the link cost manually. To set the NLSP link cost for an interface, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
NLSP elects a designated router on each LAN interface. This router creates a virtual router called a pseudonode, which generates routing information on behalf of the LAN and transmits it to the rest 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 adjacency 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, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
The default route is used when a route to any destination network is unknown. By default, IPX treats network number -2 (0xFFFFFFFE) as the default route. To disable the use of this default route, perform the following task in global configuration mode:
| Task | Command |
|---|---|
Unless configured otherwise, all known routes are advertised out each interface. However, you can choose to advertise only the default route if it is known. This greatly reduces the CPU overhead when routing tables are large. Note that services are not considered to be reachable via the default route alone. A specific route to the destination network must be known before a service advertisement will be accepted. Therefore, advertise only the default route with caution if services are to be advertised via the interface.
To advertise only the default route via an interface, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
You can configure the hello and CSNP transmission intervals, and the LSP retransmission interval.
To configure the hello transmission interval, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
To configure the CSNP transmission interval, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
To configure the LSP retransmission interval, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
To modify LSP parameters, perform one or more of the following tasks in router configuration mode:
| Task | Command |
|---|---|
To control access to IPX networks, you create access lists and then apply them with filters to individual interfaces.
There are four types of IPX access lists that you can use to filter various kinds of traffic:
There are 13 different IPX filters that you can define for IPX interfaces. They fall into five groups:
Table 20-2 summarizes the types of filters and the commands you use to define them. Use the show ipx interfaces command to display the filters defined on an interface.
| Filter Type | Command Used to Define Filter |
|---|---|
| Generic filters |
|
Filter outbound packets based on protocol, address and address mask, and socket. | ipx access-group access-list-number |
| Routing table filters |
|
Control which networks are added to the routing table. | ipx input-network-filter access-list-number |
Control which networks are advertised in routing updates. | ipx output-network-filter access-list-number |
Control the communication servers from which updates are accepted. | ipx router-filter access-list-number |
| SAP filters |
|
Filter incoming service advertisements. | ipx input-sap-filter access-list-number |
Filter outgoing service advertisements. | ipx output-sap-filter access-list-number |
Control the communication servers from which SAP updates are accepted. | ipx router-sap-filter access-list-number |
Filter list of servers in GNS response messages. | ipx output-gns-filter access-list-number |
| IPX NetBIOS filters |
|
Filter incoming packets by node name. | ipx netbios input-access-filter host name |
Filter incoming packets by byte pattern. | ipx netbios input-access-filter bytes name |
Filter outgoing packets by node name. | ipx netbios output-access-filter host name |
Filter outgoing packets by byte pattern. | ipx netbios output-access-filter bytes name |
| Broadcast filters |
|
Control which broadcast packets are forwarded. | ipx helper-list access-list-number |
Keep the following in mind when configuring IPX network access control:
To control access to IPX networks, perform the tasks in the following sections:
To create access lists, you can perform one or more of the following tasks in global configuration mode:
| Task | Command |
|---|---|
Create a standard IPX access list (for generic, routing, and broadcast filters). | access-list access-list-number {deny | permit} source-network[.source-node[source-node-mask]] |
Create an extended IPX access list (for generic, routing, and broadcast filters). | access-list access-list-number {deny | permit} protocol [source-network[.source-node [source-network-mask.source-node-mask]] source-socket [destination-network [.destination-node |
access-list access-list-number {deny | permit} network[.node] [network-mask node-mask] [service-type [server-name]] | |
Create an access list for filtering IPX NetBIOS packets by node name. | |
Create an access list for filtering IPX NetBIOS packets by arbitrary byte pattern. | netbios access-list bytes name {deny | permit} offset byte-pattern |
Once you have created an access list, apply it to a filter on the appropriate interfaces as described in the sections that follow. This activates the access list.
Generic filters determine which packets to send out an interface based on the packet's source and destination addresses, IPX protocol type, and source and destination socket numbers.
To create generic filters, perform the following tasks:
Step 1 Create a standard or an extended access list.
Step 2 Apply a filter to an interface.
To create an access list, perform one of the following tasks in global configuration mode:
To apply a generic filter to an interface, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
For an example of creating a generic filter, see the section "IPX Network Access Example."
Routing table update filters control the entries that the communication server 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, perform the following tasks:
Step 1 Create a standard or an extended access list.
Step 2 Apply one or more routing filters to an interface.
To create an access list, perform one of the following tasks in global configuration mode:
To apply routing table update filters to an interface, perform one or more of the following tasks in interface configuration mode:
| Task | Command |
|---|---|
Control which networks are added to the routing table when IPX routing updates are received. | |
Control which networks are advertised in routing updates sent out by the communication server. | |
Control the communication servers from which routing updates are accepted. |
You can apply one filter to each interface.
A common source of traffic on Novell networks is SAP messages, which are generated by NetWare servers and our communication servers when they broadcast their available services. To control how SAP messages from network segments or specific servers are routed among IPX networks, perform the following steps:
Step 1 Create a SAP access list.
Step 2 Apply one or more filters to an interface.
To create a SAP access list, perform the following task in global configuration mode:
| Task | Command |
|---|---|
access-list access-list-number {deny | permit} network[.node] [network.node-mask] [service-type [server-name]] |
To apply SAP filters to an interface, perform one or more of the following tasks in interface configuration mode:
| Task | Command |
|---|---|
Filter incoming service advertisements. | |
Filter outgoing service advertisements. | |
Filter service advertisements received from a particular communication server. |
You can apply one of each SAP filter type to each interface.
For examples of creating and applying SAP filters, see the sections "SAP Input Filter Example" and "SAP Output Filter Example."
To create filters for controlling which servers are included in the GNS responses sent by the communication server, perform the following tasks:
Step 1 Create a SAP access list.
Step 2 Apply a GNS filter to an interface.
To create a SAP access list, perform the following task in global configuration mode:
| Task | Command |
|---|---|
Create a SAP access list. | access-list access-list-number {deny | permit} network[.node] [network.node-mask] [service-type [server-name]] |
To apply a GNS filter to an interface, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
Novell's IPX NetBIOS allows messages to be exchanged between nodes using alphanumeric names as well as node addresses. Therefore, the communication server lets you filter incoming and outgoing NetBIOS packets by the node name or by an arbitrary byte pattern (such as the node address) in the packet.
Keep the following in mind when configuring IPX NetBIOS access control:
To create filters for controlling IPX NetBIOS access, perform the following tasks:
Step 1 Create a NetBIOS access list.
Step 2 Apply the access list to an interface.
To create one or more NetBIOS access lists, perform one or both of the following tasks in global configuration mode:
To apply a NetBIOS access list to an interface, perform one or more of the following tasks in interface configuration mode:
| Task | Command |
|---|---|
Filter incoming packets by node name. | |
Filter incoming packets by byte pattern. | |
Filter outgoing packets by node name. | |
Filter outgoing packets by byte pattern. |
You can apply one of each of these four filters to each interface.
Communication servers 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, perform the following tasks:
Step 1 Create an access list.
Step 2 Apply a broadcast message filter to an interface.
To create an access list, perform one of the following tasks in global configuration mode:
To apply a broadcast message filter to an interface, perform the following tasks in interface configuration mode:
| Task | Command |
|---|---|
Step 1. Specify a helper address for forwarding broadcast messages. | |
Step 2. Apply a broadcast message filter to an interface. |
For examples of creating and applying broadcast message filters, see the section "Helper Facilities to Control Broadcasts Examples" later in this chapter.
To tune IPX network performance, perform the tasks in one of more of the following sections:
To control specific aspects of IPX compliance, you can use a combination of global configuration and interface configuration commands. You can perform one or more of the following tasks in global configuration mode:
| Task | Command |
|---|---|
Set the interpacket delay of multiple-packet routing updates sent on all interfaces. | |
Set the interpacket delay of multiple-packet triggered routing updates sent on all interfaces. | |
Set the interpacket delay of multiple-packet Service Advertisement Protocol (SAP) updates sent on all interfaces. | |
Set the interpacket delay of multiple-packet triggered SAP updates sent on all interfaces. |
You can perform one or more of the following tasks in interface configuration mode:
To achieve full compliance, issue the following interface configuration commands on each interface configured for IPX:
| Task | Command |
|---|---|
Step 1. Set the interpacket delay of multiple-packet routing updates to 55 ms. | |
Step 3. 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, issue the following commands from global configuration mode:
| Task | Command |
|---|---|
Step 1. Set the interpacket delay of multiple-packet routing updates sent on all interfaces to 55 ms. | |
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 communication server's routing table, perform the following task in global configuration mode:
| Task | Command |
|---|---|
You can configure static routes that can be overridden by dynamically learned routes. These 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 that by default, floating-static routes are not redistributed into other dynamic protocols.
To add a floating-static route to the communication server's routing table, perform the following task in global configuration mode:
| Task | Command |
|---|---|
You can set the interval between IPX RIP updates on a per-interface basis. You also can specify that a delay be inserted between the packets of a multiple-packet update.
You can set RIP update times only in a configuration in which all servers are our servers or in which the IPX servers allow configurable timers. The timers for all servers connected to the same network segment should be the same. The RIP 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.
To adjust RIP update times on the communication server, perform one or both of the following tasks in interface configuration mode:
| Task | Command |
|---|---|
Adjust the delay between multiple-packet routing updates. |
By default, a network's or server's RIP entry ages out at an interval equal to three times the RIP update interval. To configure the multiplier that controls the interval, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
Configure the interval at which a network RIP entry ages out. |
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, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
Configure the maximum packet size of RIP updates sent out an interface. |
Servers use SAP to advertise their services via broadcast packets. Communication servers store this information in the SAP table, also known as the Server Information Table (SIT). This table is updated dynamically. You might want to explicitly add an entry to the SIT 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 communication server will not announce the static SAP entry until it relearns the route.
To add a static entry to the communication server's SAP table, perform the following task in global configuration mode:
| Task | Command |
|---|---|
Specify a static SAP table entry. |
The communication server maintains a list of SAP requests to process, including all pending GNS queries from clients attempting to reach servers. When the network is restarted, the communication server 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, perform the following task in global configuration mode:
| Task | Command |
|---|---|
You can adjust the interval at which SAP updates are sent, and you can set the delay between packets sent in multipacket SAP updates.
Changing the interval at which SAP updates are sent is most useful on limited-bandwidth, point-to-point links or on X.25 interfaces. You should ensure that all Novell servers and communication servers on a given network have the same SAP interval. Otherwise, they might decide that a server is down when it is really up.
Adjusting the delay between packets sent in a multipacket SAP update is useful when the IPX network has slow IPX servers or communication servers. Setting a delay between packets in a multipacket SAP update forces our communication server interface to slow its output of SAP packets.
To modify the SAP timers used by the communication server, perform one or both of the following tasks in interface configuration mode:
| Task | Command |
|---|---|
Adjust the delay between packets sent in multiple-packet SAP updates. |
By default, a network's or server's SAP entry ages out at an interval equal to three times the SAP update interval. To configure the multiplier that controls the interval, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
Configure the interval at which a network's or server's SAP enty ages out. |
By default, the maximum size of SAP updates sent out an interface is 480 bytes. This size allows for seven servers (64 bytes each) plus a 32-byte IPX SAP header.To modify the maximum packet size, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
Configure the maximum packet size of SAP updates sent out an interface. |
You can set the maximum number of equal-cost, parallel paths to a destination. (Note that when paths have differing costs, the communication server chooses lower-cost routes in preference to higher-cost routes.) The communication server 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 whether or not fast switching is enabled.
The cost of a path is determined by ticks, with hop count used as a tie breaker.
Limiting the number of equal-cost paths can save memory on communication servers 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 on the communication server, perform the following task in global configuration mode:
| Task | Command |
|---|---|
Set the maximum number of equal-cost paths to a destination. |
You can set the method in which the communication server responds to SAP GNS requests, and you can set the delay time in responding to these requests. By default, the communication server responds to GNS requests. However, you can disable this.
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, perform one or more of the following tasks in global configuration mode:
| Task | Command |
|---|---|
Respond to GNS requests using a round-robin selection method. | |
Communication servers 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. You can enable the forwarding of broadcast messages (except type 20 broadcasts) to other networks and forward all other unrecognized broadcast messages. These are non-RIP and non-SAP packets that are not addressed to the local network. Forwarding broadcast messages 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 messages.
Our communication servers support 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.
To specify a helper address for forwarding broadcast messages, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
Specify a helper address for forwarding broadcast messages. |
You can specify multiple helper addresses on a given interface.
For an example of using helper addresses to forward broadcast messages, refer to the section "Helper Facilities to Control Broadcasts Examples" later in this chapter.
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.
Communication servers normally block all broadcast requests. By enabling type 20 packet propagation, IPX interfaces on the communication server may accept and forward type 20 propagation packets. Before forwarding (flooding) the packets, the communication server performs loop detection as described by the IPX Router Specification.
You can configure the communication server 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 two side effects:
You can enable the forwarding of type 20 packets on individual interfaces, and you can restrict the acceptance and forwarding of type 20 packets. The tasks to do this are described in the following sections.
By default, type 20 propagation packets are dropped by the communication server. You can configure the communication server 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, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
Forward IPX type 20 propagation packet broadcasts to other network segments. |
For incoming type 20 propagation packets, the communication server is configured by default to accept packets on all interfaces enabled to receive type 20 propagation packets. You can configure the communication server 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, perform the following global configuration task:
| Task | Command |
|---|---|
Restrict the acceptance of IPX type 20 propagation packets. |
For outgoing type 20 propagation packets, the communication server 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 communication server to send these packets only to networks that are not routes back to the source network. (The communication server 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, perform the following global configuration task:
| Task | Command |
|---|---|
Restrict the forwarding of IPX type 20 propagation packets. |
To repair corrupted network numbers on an interface, perform the following tasks in interface configuration mode:
| Task | Command |
|---|---|
Step 1. Disable fast switching. | no ipx route-cache |
Step 2. 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. Also, 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 3.1x and 4.0 servers). |
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 communication servers involved in a topology change to synchronize at the same time. Communication servers 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.
IPX Enhanced IGRP provides the following features:
To configure IPX Enhanced IGRP, complete the tasks in the following sections. At a minimum, you must enable IPX Enhanced IGRP. The remaining tasks are optional.
See the "Configuration Examples" section at the end of this chapter for configuration examples.
To create an IPX Enhanced IGRP routing process, perform the following tasks:
| Task | Command |
|---|---|
Step 1. Enable an IPX Enhanced IGRP routing process in global configuration mode. | |
For an example of how to enable IPX Enhanced IGRP, see the section "Enabling and Disabling IPX Routing Protocols Examples."
To associate multiple networks with an IPX Enhanced IGRP routing process, you can repeat step 2.
To configure the following miscellaneous IPX Enhanced IGRP parameters, perform one or more of the following tasks:
By default, the router redistributes IPX RIP routes into IPX Enhanced IGRP, and vice versa. When routes are redistributed, a RIP route to a destination with a hop count of 1 is always preferred over an Enhanced IGRP route with a hop count of 1. This ensures that the router always believes a Novell IPX server over a Cisco router for internal IPX networks. The only exception to this rule is if both the RIP and Enhanced IGRP updates were received from the same router. In this case, and in the case of all other RIP metrics (2 through 15), the Enhanced IGRP route always is preferred over the RIP route when the hop counts are the same.
Internal Enhanced IGRP routes are always preferred over external Enhanced IGRP routes. This means that if there are two Enhanced IGRP paths to a destination, the path that originated within the Enhanced IGRP autonomous system will always be preferred over the Enhanced IGRP path that originated from outside of the autonomous system, regardless of the metric. Redistributed RIP routes are always advertised in Enhanced IGRP as external.
To disable route redistribution, perform the following task in IPX router configuration mode:
| Task | Command |
|---|---|
Disable redistribution of RIP routes into Enhanced IGRP and Enhanced IGRP routes into RIP. | no redistribute {rip | eigrp autonomous-system-number | connected | static} |
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 routers 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.
You can configure the hold time, in seconds, on a specified interface for the IPX 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 three times the hello interval, or 15 seconds.
To change the interval between hello packets, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
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, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
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 a router out any interface from which that information originated. This behavior usually optimizes communication among multiple routers, particularly when links are broken. However, with nonbroadcast networks, such as Frame Relay and SMDS, situations can arise for which this behavior is less than ideal. For these situations, you may wish to disable split horizon.
To disable split horizon, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
Disable split horizon. |
If IPX Enhanced IGRP peers are found on an interface, you can configure the communication server 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 communication server sends SAP updates only when the SAP table changes. On Ethernet, Token Ring, and FDDI interfaces, by default, the communication server 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, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
Send SAP updates only when a change in the SAP table occurs, and send SAP changes only. |
To send periodic SAP updates, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
no ipx sap-incremental eigrp autonomous-system-number |
For an example of how to configure SAP updates, see the section "Enhanced IGRP SAP Update Examples" in this publication.
To control which routers learn about routes, you can control the advertising of routes in routing updates. To do this, perform the following task in router configuration mode:
| Task | Command |
|---|---|
Control the advertising of routes in routing updates. | distribute-list access-list-number out [interface-name | |
To control the processing of routes listed in incoming updates, perform the following task in router configuration mode:
| Task | Command |
|---|---|
Control which incoming route updates are processes. |
By default, the router queries its own copy of each Enhanced IGRP neighbor's backup server table every 15 seconds. To change this interval, perform the following global configuration task:
| Task | Command |
|---|---|
Specify the minimum period of time between successive queries of a neighbor's backup server table. |
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, perform the following task in global configuration mode:
| Task | Command |
|---|---|
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 appletalk eigrp-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, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
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 section "IPX Enhanced IGRP Bandwidth Configuration Example."
To monitor Enhanced IGRP on an IPX network, perform one or more of the following tasks at the EXEC prompt:
IPX accounting allows you to collect information about IPX packets and the number of bytes that are switched through the communication server. You collect information based on the source and destination IPX address. Accounting tracks only IPX traffic that is routed through the communication server; it does not track traffic generated by or terminating at the communication server.
IPX accounting statistics are accurate even if IPX fast switching is enabled or if IPX access lists are being used. However, IPX accounting does not keep statistics if autonomous switching is enabled.
The communication server software maintains two accounting databases: an active database and a checkpointed database.
To enable IPX accounting, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
Enable IPX accounting. |
To control IPX accounting on the communication server, perform one or more of the following tasks in global configuration mode:
| Task | Command |
|---|---|
Set the maximum number of accounting entries. | |
Set the maximum number of transit entries. | |
Filter the ne |