Chapter 8. Configuring IPXInternetwork Packet eXchange (IPX) is a layer-3 network protocol developed by Novell originally for file and printer sharing in small, desktop environments. IPX is based on a client-server model in which a client cannot do anything on an internetwork until it attaches to a server. Our coverage of IPX will begin with an overview of IPX host addressing and protocol operation. The IOS commands for configuring IPX will be illustrated as we make modifications to our test internetwork.
IPX host addresses are 80 bits long, and we normally write them in hexadecimal (hex). An IPX address has a 32-bit network part and a 48-bit node part. The network part identifies a single network, and the node part identifies a single host on the network. We must assign a unique network address to every network (physical and logical) that is to carry IPX traffic. There is no common registry to obtain IPX network addresses as there is with IP. Instead, we can use any IPX address we want as long as it is unique with the entire internetwork where it is located. Network addresses are defined only on Novell servers and routers. All servers and routers on the same network must have the same network address defined. Clients figure out the network address of a network dynamically when they start. Network administrators use many ways of determining IPX network addresses to assign to networks. Some of these are as follows:
The node portion of an IPX address is defined automatically to be the MAC address of an IPX host's interface. On Cisco router interfaces that do not have MAC addresses, such as serial interfaces, the MAC address of the first LAN interface in the router is used as the node portion of the IPX address. If there are no LAN interfaces in the router, IOS just makes up the node part of the address. The network number can have from one to eight hex digits; writing leading zeros is not required. A period separates the network and node portion, and the node portion is written in three four-digit sections separated by periods. For example, AC100A00.0010.7B3A.D4BF is the IPX address of the Ethernet0 interface on our test router Dallas. AC100A00 is the network number we assigned to the network, and 0010.7B3A.D4BF is the interface's MAC address. Novell servers have logical internal networks that contain a single host, the server itself. We define the network number for the internal network, and Novell defines the node address to be 1. In hex, the node portion is 0000.0000.0001. 2.1.3.1 Since host's layer-2 address (MAC address) is part of its layer-3 address (IPX address), a host using IPX can determine the destination address to put in the frame header directly from the IPX address without using any network overhead. In Section 2.1.3.1, we defined this method of acquiring a host's MAC address as prediction.
We are going to use the OSI Reference Model to help discuss the components that make up the IPX protocol suite. Figure 8-1 shows the IPX stack as compared to the seven layers of the OSI Reference Model. <<<J121 - Figure 8-1 IPX Stack Compared to OSI Reference Model>>> Our goal is be able to configure IPX on an IOS-based router; therefore, this overview is meant to provide enough background information for us to understand what is happening on a router that is routing IPX packets. We can run IPX over just about any physical medium. On LAN interfaces, the frame header and trailer format (encapsulation) of IPX packets is defined separately from that of other protocols. LAN interfaces can support multiple frame encapsulation types for IPX. There are four Ethernet encapsulation types, two token ring encapsulation types, and two FDDI encapsulation types defined. Figure 8-2 shows the defined encapsulation types for Ethernet and Token Ring interfaces. The Novell names for the major encapsulation types are shown with their corresponding Cisco IOS names. We are concerned with the Cisco names because they are used in IOS commands.
<<<Figure 8-2 Ethernet and Token Ring IPX Encapsulation Types>>> IOS uses NOVELL-ETHER as its default Ethernet interface encapsulation and SAP as its default Token Ring interface encapsulation for IPX packets. The encapsulation of a router's WAN interface is used for all of the protocols that are being processed on that interface, including IPX. The default encapsulation for a Cisco-router serial interface is HDLC. IPX appears at layer 3. The first thing in an IPX packet is the layer-3 IPX header. The IPX header contains the IPX destination address and source address. The IPX header also contains a packet type and source and destination socket numbers, which help a host determine the type of data being carried in the packet. The top four layers are bundled together into a mixed bag of applications and transport mechanisms. SAP (Service Advertisement Protocol) runs over IPX and is the application used by servers and routers to learn about services available on a Novell network. Each service is uniquely identified with a combination of type, name, and address. A service type is a number given for a particular service provided by a server, such as a file service, a print service, or a database service. The name of the service is a descriptive text string usually defined by a network administrator, and the address is the IPX address of the host that is offering the service. Novell servers use SAP to tell the devices on their local network about their presence. SAP advertisements are transmitted periodically every 60 seconds to the IPX broadcast address of a network. File servers and routers collect the advertised services into a service table (sometimes called a SAP table) and advertise all of the services, using SAP, out all of their IPX-enabled interfaces every 60 seconds. SAP uses split horizon to avoid advertising a service to the same network from which a service was learned. Clients ignore the information in the SAP broadcasts; however, since a client cannot perform any internetwork activity until it attaches to a server, the client needs some way of locating servers. Clients use either Get Nearest Server (GNS) requests to find a server or Novell Directory Services (NDS) tree to which it can attach. File servers, NDS servers, and routers can respond to these requests. Once attached, the client can access Novell services. RIP (Routing Information Protocol) and NLSP (Novell Link Services Protocol) are IPX routing protocols. IPX RIP is very similar to IP RIP. RIP is the default routing protocol for IPX; it is enabled on an interface as soon as an IPX network number is assigned to the interface. IPX RIP is a distance vector routing protocol that uses 60-second periodic updates. RIP uses two metrics: ticks and hop count. A tick is about 1/18th of a second and is meant to be a measurement of delay across a network. The preferred path to a network is the one with the lower number of ticks; if ticks are the same, the route with the lowest hop count is preferred. If both ticks and hop count are equal, IOS will just pick one to use unless we have configured IPX load sharing. NLSP is a Novell-developed, link state routing protocol, similar to OSPF. IOS also supports using EIGRP for the exchange of IPX routes and services. Servers use NCP (NetWare Core Protocol) to provide services such as file and print operations. SPX (Sequenced Packet eXchange) is similar to TCP in IP. SPX provides connection-oriented communication for applications that require it. For example rconsole and IPX SNA gateways use SPX. IPX NetBIOS is Novell's implementation of IBM's NetBIOS. Some IPX network applications are written to run over IPX NetBIOS. IPX NetBIOS uses type-20 IPX packets. These must be handled separately in the IOS configuration of IPX. IOS strips the frame header and trailer from IPX packets received on an interface. The IPX packet is then sent to the IPX routing process, which searches the IPX routing table for an entry matching the network part of the destination IPX address. Two of the routers, Dallas and FortWorth, in our test internetwork already have IPX enabled on two of their interfaces. Figure 8-3 shows the existing internetwork with the already-configured IPX network addresses. We did this initial configuration in Chapter 3. <<<J122 - Figure 8-3 Current IPX Internetwork>>> We added Austin in Chapter 7, but we have not configured IPX communication for it yet. The FortWorth Ethernet LAN has a NetWare file server attached. The internal IPX address of the server is AC101401. The IPX routing table can be displayed by issuing the command show ipx route in user mode or privileged mode. Figure 8-4 shows the IPX routing table on Dallas.
<<<Figure 8-4 Show IPX Route Output on Dallas>>> Just like the displays of all IOS routing tables, the IPX routing table display starts with a legend describing the letters that appear in the left column of each table entry. We see that there are four routes in the table (Line 7). Line 7 also reports that 1 parallel path is supported; this means that equal-cost route load sharing is effectively disabled. For the directly-connected networks (Lines 11 and 12), the table has the IPX network address and the IPX encapsulation. Ethernet0 is using NOVELL-ETHER encapsulation, the default. There are two RIP-learned routes (Lines 13 and 14). For each route, there is the IPX address of the next hop gateway to reach a network, the elapsed time since the route was updated, and the interface out which packets are to be routed to reach the network. The numbers in brackets are the two metrics used by RIP in determining the best path to the network. The first value is the number of ticks, and the second value is the number of hops. We will be using the show ipx route command a few more times in this chapter to check the effects of our configuration changes. Since there is a server on the FortWorth side of the internetwork, there should be something in the service tables of the routers. The show ipx servers command tells IOS to display the a router's Novell service table. Figure 8-5 shows the output of the show ipx servers command on Dallas. <<<Figure 8-5 Show IPX Servers Output on Dallas>>> Figure 8-5 shows that there are five services in Dallas' service table (Line 4). The letter P in the left column of each of the five entries indicates that the entries were learned through a periodic SAP advertisement. The Type column contains the identification of the service being described by an entry. Service types are written in hex, and the ones shown here are described as follows:
The name assigned to each service is displayed in the Name column. The Net and Address columns combine to give the IPX address of the host that is providing the service. The Port column defines the upper layer socket number at which the service can be reached. The Route columns gives the metrics (ticks and hops) for reaching a service's local network. The Hops columns shows the number of router hops away the service resides, and the Itf column shows which local interface used to reach a service.
IOS does not route IPX traffic by default; therefore, we must first turn on IPX routing. We use the global configuration command ipx routing to do this. We then configure the assigned IPX network numbers on the interfaces that are to transmit and receive IPX packets. On LAN interfaces, we can set an IPX encapsulation if we do not want to use default encapsulation. The interface configuration command ipx network is used to configure the network number and, if applicable, the encapsulation for an interface. As soon as we enter a valid ipx network command on an interface, IPX RIP and SAP start processing on the interface. <<<J123 - Figure 8-6 Internetwork Diagram Showing Austin IPX Network Addresses>>> Figure 8-6 shows an updated internetwork diagram showing the network addresses to be used for Austin IPX connectivity. IPX is already enabled on Dallas and FortWorth so we will start our configuration example on Austin then move to the Dallas and FortWorth interfaces that are connected to Austin. The commands for configuring IPX on Austin, based on Figure 8-6, are shown in Figure 8-7.
<<<Figure 8-7 IPX Configuration on Austin>>> The ipx routing command (Line 3) tells IOS to start the process that will be used to route IPX packets. To start IPX processing on an interface, we need to be in interface configuration mode. Starting with Ethernet0 (Line 4), we entered the ipx network command (Line 5) for assigned the IPX network number. According the Figure 8-6, the desired encapsulation on the Ethernet LAN is SAP (or Novell Ethernet_802.2). Since this is different from the default of NOVELL-ETHER, we added the keywords encapsulation sap to the command. Now IPX packets can be routed through Ethernet0; they will be transmitted with a SAP-encapsulated frame header, and they will be received and processed if a host on the Ethernet LAN transmitted them with a SAP-encapsulated frame header. The second interface on Austin is Serial0 (Line 6), and its IPX network address is assigned on Line 7. The third interface is Serial1 (Line 8), and its IPX network address is assigned on Line 9. The encapsulation for the serial interfaces is HDLC, the default. We still do not have IPX communication from Dallas and FortWorth to Austin. We need to enable IPX on the other routers' serial interfaces that are connected to Austin. Figure 8-8 shows Dallas' Serial0 IPX configuration, and Figure 8-9 shows FortWorth's Serial1 IPX configuration. <<<Figure 8-8 IPX Configuration on Dallas Serial0>>> <<<Figure 8-9 IPX Configuration on FortWorth Serial1>>> Now that all of our IPX network addresses have been assigned to the appropriate interfaces, let us take a look at one of the router's IPX routing table. Figure 8-10 shows the IPX routing table on Dallas. <<<Figure 8-10 IPX Routing Table on Dallas After IPX Configuration>>> Dallas now has three directly-connected IPX networks (Lines 7, 8 and 9) and four RIP-learned IPX routes (Lines 10 through 13). Notice that the number of ticks for the routes is the same for each of the serial links regardless of their bandwidth. Figure 8-6 shows seven IPX networks so this must be all of them. Now we want to examine Dallas' path to the serial link between FortWorth and Austin, C0A80300 (Line 13). The preferred path goes through Austin, but from looking at our diagram, we can see that there are actually two equal-cost paths (as far as IPX RIP is concerned) from Dallas to the network. We can configure IPX load sharing with the global configuration command ipx maximum-paths. Figure 8-11 shows the configuration of load sharing for IPX on Dallas. <<<Figure 8-11 IPX Load Sharing Configuration>>> <<<Figure 8-12 IPX Routing Table After Load Sharing Configuration>>> Two parallel (equal-cost) paths to a destination are now allowed in the routing table (Line 3). The new routing table shows the two equal-cost paths (Lines 12 and 13). As far as IPX RIP knows, the two serial links have the same metric even though we know from our original implementation that one is a T1 and one is a 256 kbps line. Turning on load sharing in this case may not be such a good idea, because it increases the likelihood of IPX packets arriving at a host out of order.
We have already used the show ipx route command to view one of the IPX routing tables. Other commands that we can use for IPX configuration verification are as follows:
The show protocols command shows us the protocols that IOS is configured to route, the status of each interface, and the primary address of each protocol on each interface. Figure 8-13 shows the output of the show protocols command on Austin.
<<<Figure 8-13 Show Protocols Output on Austin>>> We see that Austin is routing IP packets (Line 3) and IPX packets (Line 4). The IPX addresses of the configured interfaces are given on Lines 10, 13, and 16. The node part of all of the IPX addresses is the same. Serial0 and Serial1 have no MAC addresses that IOS can use in the IPX address completion; therefore, IOS uses the MAC address of the first Ethernet interface, Ethernet0, in the IPX addresses of both the serial interfaces. The addition of the assigned network address to the node part makes each of the IPX addresses unique. The Ethernet0 IPX address (Line 10) contains the MAC address of the Ethernet0 interface. The IPX address of an interface can also be obtained from the output of the show ipx interface command. Issuing this command without any arguments will display information for all of the interfaces that have been assigned an IPX network address. Figure 8-14 shows the output on Austin when information for a single interface is requested. <<<Figure 8-14 Show IPX Interface Output>>> The output includes both the IPX address and the encapsulation for the interface (Line 3). The delay, in ticks, for Ethernet0 is 1 (Line 4). By default, IOS assigns one tick to LAN interfaces and six ticks to WAN interfaces. The SAP update interval on Ethernet0 is set to its default of 60 seconds (Line 6). This is shown because it can be changed on a per-interface basis. Ethernet0 is not currently propagating type-20 IPX packets. Type-20 packets are transmitted by applications that use Novell's NetBIOS over IPX. RIP updates are being sent every 60 seconds (Line 22), and routes and services learned via RIP/SAP are marked as down if they are not updated within 180 seconds. Ethernet0 has received no RIP updates (Line 28), but has transmitted 7. Since there are not other IPX routers on Austin's Ethernet LAN, we expect that Ethernet0 will never receive any updates. For a quick summary of IPX interface information, we can add the brief keyword to the end of the show ipx interface command. Figure 8-15 shows the output of the show ipx interface brief command on Austin. For each interface, IOS displays the IPX network number, the encapsulation, and the status. We do not get the full IPX addresses. <<<Figure 8-15 Show IPX Interface Brief Output>>> Statistics for IPX packets can be viewed by using the show ipx traffic command. We issued the command on Austin; Figure 8-16 shows the output. <<<Figure 8-16 Show IPX Traffic Output>>> The output of show ipx traffic divided into sections. Each section has statistics for a particular type of IPX traffic. The Rcvd section shows the number of IPX packets that have been received by IOS (Lines 3 and 4), and the Sent section shows the number of IPX packets transmitted (Lines 6 and 7). The number of IPX broadcast packets received and transmitted is given in the Bcast section (Line 5). SAP statistics are shown in the SAP section, and the number of entries in the service table is also given. There are five entries in Austin's IPX service table (Line 8). Line 13 of the RIP section shows that there are seven entries in Austin's IPX routing table. Austin is not yet running EIGRP; therefore, the counters in the EIGRP section (Lines 26 through 30) are all still zero. The show commands described above are good ways of verifying the configuration of IPX; however, they do not do much for making sure that IPX connectivity has been established. For that we need to use the IPX ping application. The IPX ping application transmits IPX echo request packets to an IPX destination address and expects to receive IPX echo replies. Three ways of doing an IPX ping are as follows:
The normal ping and the ping ipx commands can be used to check connectivity to Cisco routers. Cisco uses its own proprietary IPX ping mechanism by default, and NetWare servers will not respond to it. If you want to ping a NetWare server, use the extended ping, and select the Novell echo option. Figure 8-17 shows examples of all three options. The IPX pings are being done from Dallas, and the destination address is that of Austin's Ethernet0 interface as obtained with the show ipx interface in Figure 8-14.
<<<Figure 8-17 IPX Ping Examples>>> When the normal ping is used to performing the IPX ping (Line 1), we are counting on IOS recognizing that the address we have typed is an IPX address. IOS first thinks that the address is an IP host name and attempts to perform address resolution. When that fails, IOS correctly does the IPX ping by sending five IPX echoes to Austin's Ethernet0 interface and receiving five replies. The success rate and response time information is given on the last line (Line 8). Using the ping ipx command (Line 10) tells IOS that the address in the command is an IPX address so that IOS does not have to guess. The result is the same as that of the normal ping. We invoke an extended ping by typing the ping command without an address (Line 18), and then IOS prompts us for the protocol (Line 19). Entering ipx at the protocol prompt will cause IOS to ask for an IPX destination address (Line 20). The extended ping gives us the opportunity to change the number of echoes sent, the size of the echoes, and the reply timeout. Since we are pinging another Cisco router, we answered with no (the default) at the Novell Standard Echo prompt (Line 25). If we were sending the echoes to a NetWare server, we would answer with yes. Cisco routers will respond to both types of echoes.
IPX EIGRP has the same basic operation as IP EIGRP, which we described in Section 7.7.3.2. IPX EIGRP is Cisco-proprietary. It is supported only on Cisco routers for the sharing of IPX routes and services. IPX EIGRP can replace IPX RIP and SAP on networks that have only Cisco IPX routers and no local Novell services; these networks are usually WAN's. The implementation of IPX EIGRP can save WAN bandwidth since EIGRP performs incremental updates for routes and services. This means that updates are transmitted only when a change occurs, not at the usual 60-second interval. We will configure IPX EIGRP on the WAN's of our internetwork and leave IPX RIP and SAP on the LAN's. The configuration of IPX EIGRP is similar to the configuration of an IP routing protocol. We use the ipx router eigrp command along with an Autonomous System Number (ASN). We then enable IPX EIGRP on interfaces by using network commands, with the IPX network numbers of the interfaces that are to have IPX EIGRP enabled. We need at least one network command for each interface. Turning on IPX EIGRP on an interface does not automatically turn off IPX RIP on the interface; therefore, we should disable IPX RIP on the interface to avoid running two IPX routing protocols and using network bandwidth needlessly. IPX RIP is disabled on an interface with the ipx router rip command along a no network command for each interface. Figure 8-18 shows the configuration of IPX EIGRP on Dallas. Figure 8-19 shows the configuration of IPX EIGRP on FortWorth, and Figure 8-20 shows the configuration on Austin.
<<<Figure 8-18 IPX EIGRP Configuration on Dallas>>> <<<Figure 8-19 IPX EIGRP Configuration on Dallas>>> <<<Figure 8-20 IPX EIGRP Configuration on Dallas>>> The ASN for IPX EIGRP must the same on all of the router sharing information; we chose to use ASN 500 here. When both IPX EIGRP and IPX RIP are running on the same router, IOS automatically redistributes routes between them. Routes learned from RIP are included in EIGRP updates, and routes learned from EIGRP are included in RIP updates. The same redistribution also performed for services. Figure 8-21 shows the IPX routing table on Dallas after the configuration on all three routers. <<<Figure 8-21 IPX Routing Table After IPX EIGRP Configuration>>> The routing table on Dallas still shows seven routes (Line 3), but the routes that are learned from across the WAN's have the letter E in the left column of the displayed entry. IOS maintains a neighbor table and a topology table for IPX EIGRP. These can be displayed with the show ipx eigrp neighbors and show ipx eigrp topology commands, respectively. The structure of the IPX versions of the tables is similar to that of the IP versions we described in Section 7.7.3.4.
A LAN interface can support multiple IPX encapsulations. When an interface needs multiple encapsulations, we must assign a unique IPX network number for each one; this effectively creates a logical IPX network for each encapsulation type. There are two ways of configuring multiple encapsulations on a LAN interface: secondary addresses and subinterfaces. We are going to use both methods in configuring multiple encapsulation types on Austin's Ethernet0 interface. Austin's Ethernet0 interface currently is using SAP encapsulation. We will pretend that some hosts just got installed on the Ethernet. These hosts were pre-configured with Novell Ethernet_802.3 encapsulation, and the administrator did not want to change them. Therefore, we must compensate the adding the second encapsulation to the router. The new internetwork diagram showing the additional encapsulation and network number for Austin is shown in Figure 8-22. <<<J124 - Figure 8-22 Internetwork Diagram Showing Multiple Encapsulations on Austin Ethernet>>> Implementing a secondary IPX address on an interface requires the addition of the keyword secondary to the end of another ipx network command in interface configuration mode. Figure 8-23 shows the configuration of a secondary IPX address on Austin's Ethernet0 interface.
<<<Figure 8-23 Secondary IPX Address Configuration on Austin>>> The ipx network command (Line 4) does not affect the existing IPX network number (entered in Figure 8-7, Line 5); however, if we had typed this command without the secondary keyword, the original network number and encapsulation would have been replaced with the newly specified values. The hosts that were added to Austin's Ethernet LAN were configured to use Novell's Ethernet_802.3 encapsulation. The IOS keyword for that encapsulation type is novell-ether (see Figure 8-2). The second way of doing multiple encapsulations uses subinterfaces. A subinterface is a logical interface that is coupled with a physical interface. IOS treats a subinterface just as it does a physical interface as far as routing packets is concerned. We are going to create two subinterfaces on Austin's Ethernet0 and give each its own IPX network number and encapsulation. The subinterface method will be used instead of the secondary address method in our internetwork. Figure 8-24 shows the configuration of subinterfaces on Austin to provide multiple encapsulations on its Ethernet0 interface. <<<Figure 8-24 Configuration of Subinterfaces for Multiple Encapsulation Types on Austin>>> Each of our subinterfaces is to have its own IPX network number; therefore, the physical interface, Ethernet0, no longer needs its network number. The no ipx network command removes the IPX network number from an interface (Line 4). To create a subinterface, we just have to reference the subinterface's name with the global configuration command interface. Subinterface names always begin with name of their associated physical interface and end with a period and a decimal number, which is the subinterface number. Subinterface numbers do not have to start with zero, and they do not have to be sequential. Our first subinterface is Ethernet0.1 (Line 5). The Ethernet0.1 subinterface is assigned the Ethernet0's original IPX network number (Line 6) and IPX encapsulation (Line 7). The second subinterface is Ethernet0.2 (Line 8). The second IPX network number for the Ethernet LAN is assigned to subinterface Ethernet0.2 (Line 9). Ethernet0.2 is using NOVELL-ETHER encapsulation (Line 10). Since NOVELL-ETHER is the default encapsulation for an Ethernet interface, we do not really have to type this command. It is shown here just for consistency. <<<Figure 8-25 Show IPX Interface Brief Output After Subinterface Configuration>>> Figure 8-25 shows the output of the show ipx interface brief command on Austin after the subinterface configuration. The two subinterfaces with their addresses and encapsulations are displayed (Lines 7 and 8). Subinterfaces can be deleted from the running configuration with the global configuration command no interface; however, IOS will not remove a deleted subinterface's Interface Descriptor Block (IDB) from RAM until the router is rebooted.
IPX configuration requires that the IOS IPX routing process be started with the ipx routing command. Then we must go to each interface that is to be involved in routing IPX packets and assign it an IPX network number and, possibly, an IPX encapsulation. The network numbers and encapsulations are assigned with the ipx network command in interface configuration mode. The internetwork that we now have for IPX connectivity is shown in Figure 8-26. All of the IPX network numbers and encapsulations are shown. The boundary of the IPX EIGRP autonomous system is also displayed. <<<J125 - Figure 8-26 Final IPX Internetwork Diagram>>> Figure 8-27 shows the IPX-specific commands from Dallas' running configuration. Figure 8-28 shows FortWorth's IPX-specific commands taken from the running configuration. Figure 8-29 shows the IPX-specific commands from Austin.
<<<Figure 8-27 Dallas IPX Configuration Commands>>> <<<Figure 8-28 FortWorth IPX Configuration Commands>>> <<<Figure 8-29 Austin IPX Configuration Commands>>> The address shown at the end of the ipx routing command (Line 3, Figures 8-27, 8-28, and 8-29) is the address that IOS uses as the node part of IPX addresses of WAN interfaces. IOS chooses this address itself. On each of our routers, this is the MAC address of a router's Ethernet0 interface. We can change this address to something more easily remembered by including a static address on the ipx routing command when we enter it.
We are going to leave IPX running on our test internetwork; however if we wanted to stop the IPX routing process on a router, we can enter the following global configuration command. no ipx routing The no ipx routing command will remove, from the running configuration, the commands dealing with IPX routing. These commands include those that define IPX network numbers, encapsulations, and routing protocols. If we were to type this command on our test router, Austin, the Ethernet subinterfaces would remain, but they would have no addresses. |