Cisco Knowledge Suite Cisco SystemsCisco Press
   

   
Home
MyCKS
Cutting Edge
Certification
Core Reference
Guided Learning
   
Networking Architecture
LAN
WAN
Switching
Internet Protocols (IP)
Network Protocols
Transport and Application Protocols
Desktop Protocols
Security and Troubleshooting
Network Resources and Management
Integrated Services
 

Configuring IPX Addresses

   

< Back Contents Next >

IPX Basics

  

 

IPX Addressing and Address Structure

  

 

Configuring IPX Addresses

  

 

IPX Routing Configuration

  

 

Configuring IPX Routing Protocols

  

 

Configuring IPX Filtering via Access Lists

  

 

Configuring Basic IPX Dialup Services

  

 

Verifying IPX Connectivity and Troubleshooting

  

 

Configuring IPX Type 20 Packet Forwarding

  

 

Summary

  

 

References

Save to MyCKS

 
Cisco Router Configuration

From: Cisco Router Configuration
Author: Bruce Pinsky; Allan Leinwand; Mark Culpepper
Publisher: Cisco Press (53)
More Information

Configuring IPX Addresses

This section discusses how to configure IPX addresses on LAN and WAN interfaces for Cisco routers. We also discuss the configuration of the four IPX LAN interface encapsulations used in an IPX environment.

LAN Interface Configuration

All Cisco routers that are routing IPX have a unique IPX network.node address on each of the attached LAN segments. This address enables the router to know which networks are connected to each interface and where packets for those networks should be sent.

Assigning IPX network addresses to both LAN and WAN interfaces is accomplished with the Cisco IOS interface subcommand ipx network. The IPX node address is set via the ipx routing global configuration command, as we mentioned earlier in this chapter. In the following example, we configure the SF-2 router with IPX addresses on each of its three LAN interfaces:

SF-2#configure
Configuring from terminal, memory, or network [terminal]?
Enter configuration commands, one per line.  End with CNTL/Z.
SF-2(config)#interface ethernet 0
SF-2(config-if)#ipx network 200
SF-2(config-if)#interface ethernet 1
SF-2(config-if)#ipx network 150
SF-2(config-if)#interface fddi 0
SF-2(config-if)#ipx network 10
SF-2(config-if)#^Z

IPX LAN Interface Encapsulations

As seen in Figure 6-1, IPX operates over a variety of data link protocols. Originally, IPX was developed over ethernet. Then, as new data link protocols were invented—such as IEEE 802.3, IEEE 802.5, and FDDI—IPX was enhanced to support encapsulations for these data link protocols. As a result, different versions of NetWare support different data link protocols and their associated encapsulation methods. IPX uses a single data link layer protocol for most newer LAN technologies but has four different encapsulation methods for ethernet LAN segments.

LAN encapsulations are known by different names to IPX and the Cisco IOS. Table 6-1 maps IPX frame type names to Cisco IOS encapsulation syntax.

Table 6-1. IPX Encapsulation Terminology and Cisco IOS Encapsulation Syntax

IPX Frame Type

Cisco IOS Encapsulation Name

Ethernet_802.2

sap

Ethernet_802.3

novell-ether

Ethernet_II

arpa

Ethernet_Snap

snap

Token-Ring

sap

Token-Ring_Snap

snap

Fddi_Snap

snap

Fddi_802.2

sap

Fddi_Raw

novell-fddi

NOTE

The default Cisco IOS encapsulation type for all ethernet interfaces on Cisco routers is novell-ether. Cisco Token Ring interfaces default to sap encapsulation, while Cisco FDDI interfaces default to snap encapsulation.

The Cisco IOS encapsulation name, is the default encapsulation used by NetWare Version 4.0. On ethernet interfaces, this frame type uses a standard IEEE 802.3 header, followed by an IEEE 802.2 logical link control (LLC) header, also known as the service access point (sap). IEEE 802.2 LLC header provides a means for the data link layer to determine the network layer protocol in a data link protocol frame. On Token Ring interfaces, the sap encapsulation, which is the default encapsulation, consists of a standard IEEE 802.5 header, followed by an IEEE 802.2 LLC header. Similarly, on FDDI interfaces this frame type consists of a standard FDDI header, followed by an IEEE 802.2 LLC header.

NOTE

Do not confuse the IEEE 802.2 LLC SAP (service access point) encapsulation method with the NetWare SAP (Service Advertising Protocol). We discuss NetWare SAP later in this chapter.

The Cisco IOS Novell-ether encapsulation, which is the same as Novell's Ethernet_802.3 encapsulation, only operates on ethernet interfaces. The Novell-ether frame type consists of a standard IEEE 802.3 header, followed by the IPX header with the checksum field set to the hexadecimal value of FFFF. Novell-ether is the default encapsulation used by NetWare Version 3.11 and by the IOS on Cisco routers.

For ethernet interfaces that need to handle TCP/IP and IPX traffic, you should use the Novell Ethernet_II encapsulation (called arpa in the Cisco IOS). This encapsulation simply uses an ethernet header, which is followed by an IPX header.

The Cisco IOS encapsulation snap on ethernet uses a standard IEEE 802.3 header, followed by an IEEE 802.2 SNAP LLC header. SNAP (Subnetwork Access Protocol) is a standard method of encapsulating network layer datagrams in IEEE protocols. On Token Ring and FDDI interfaces, the SNAP frame type consists of a standard IEEE 802.5 or FDDI header, followed by an IEEE 802.2 SNAP LLC header.

On FDDI interfaces, the Cisco IOS Novell-fddi encapsulation matches Novell's Fddi_Raw encapsulation. This frame type consists of a standard FDDI header, followed by the IPX header with the checksum field set to the hexadecimal value of FFFF.

To summarize this discussion, four encapsulations are possible on ethernet interfaces (SAP, ARPA, novell-ether, and SNAP), three are possible on FDDI (SAP, SNAP, and novell-fddi), and two are possible on Token Ring (SAP and SNAP). Figure 6.2 shows the four ethernet encapsulation schemes.

Figure 6-2. Encapsulation formats for IPX data link layer protocols.

Although multiple IPX data link encapsulations exist, the NetWare release (such as NetWare 3.11 or NetWare 4.0) running on your network often determines which encapsulation method is needed. All devices must be running the same IPX encapsulation for NetWare clients, NetWare servers, and Cisco routers to communicate properly on a given IPX LAN segment.

Configuring Encapsulations

To configure the encapsulation method on a LAN interface, use the ipx network command with the encapsulation option. In the following example, we configure the snap encapsulation on Ethernet 0 of the ZIP network's SF-2 router:

SF-2#configure
Configuring from terminal, memory, or network [terminal]?
Enter configuration commands, one per line.  End with CNTL/Z.
SF-2(config)#interface ethernet 0
SF-2(config-if)#ipx network 200 encapsulation snap
SF-2(config-if)#^Z

In some situations, you may need to run several NetWare data link layer encapsulations on the same LAN interface at the same time. For example, you may need to transition some IPX clients from NetWare 3.11 to NetWare 4.0, each of which uses a different data link layer encapsulation method. Normally, different client and server encapsulation methods would prevent the clients from communicating with servers using a different version of NetWare. However, by using two different encapsulations on one IPX LAN segment, the Cisco router permits communication between clients and servers running different versions of NetWare.

When running multiple encapsulation methods, you must assign unique network numbers for each data link encapsulation method on a router interface. One of the networks becomes the primary IPX network and the other becomes the secondary IPX network. Both are assigned to the same physical interface. Use the secondary option with the ipx network command to assign secondary networks on a LAN interface that is running different encapsulation methods. We assign the arpa encapsulation to Ethernet 0 of the ZIP network's SF-2 router in the following example:

SF-2#configure
Configuring from terminal, memory, or network [terminal]?
Enter configuration commands, one per line.  End with CNTL/Z.
SF-2(config)#interface ethernet 0
SF-2(config-if)#ipx network 201 encapsulation arpa secondary
SF-2(config-if)#^Z

WAN Interface Configuration

WAN addressing in IPX, which is similar to LAN addressing, is configured using the ipx network interface configuration subcommand. In this section, we explore assigning IPX network numbers to point-to-point and multipoint WAN interfaces. Recall from Chapter 3, “The Basics of Device Interfaces,” that specific encapsulation methods (such as X.25 or Frame Relay) usually have to be explicitly configured to operate on a WAN interface. Such is the case for the WAN encapsulation methods used by IPX.

Point-to-Point WAN Interface Addressing

As seen in the discussion in Chapter 4 about IP, a point-to-point WAN interface connects exactly two devices. For two routers to route IPX over a point-to-point WAN interface, they must both be configured with the same IPX network number on the connected interfaces. As on a LAN interface, each device must have a unique IPX node number on a WAN interface.

You can configure the IPX network number on point-to-point WAN interfaces using the ipx network interface configuration subcommand. Following is an example of assigning an IPX network number to the point-to-point WAN interfaces (two Frame Relay subinterfaces and one HDLC interface) on the Seoul-1 router:

Seoul-1#configure
Configuring from terminal, memory, or network [terminal]?
Enter configuration commands, one per line.  End with CNTL/Z
Seoul-1(config)#interface serial 0.16 point-to-point
Seoul-1(config-if)#ipx network 2901
Seoul-1(config-if)#interface serial 0.17 point-to-point
Seoul-1(config-if)#ipx network 2902
Seoul-1(config-if)#interface serial 1
Seoul-1(config-if)#ipx network 1901
Seoul-1(config-if)#^Z

Multipoint WAN Interface Addressing

Multipoint WAN interface addressing issues were covered in Chapter 4 with reference to IP. Like IP, IPX can be used with many different multipoint WAN interfaces, including Frame Relay, X.25, ISDN, and ATM. You can configure each of these multipoint WAN interfaces to route IPX using the ipx network interface configuration subcommand. The mapping from the specific data link layer address to the IPX network number is configured differently for each WAN protocol.

When you are using Frame Relay multipoint interfaces, the router needs to map DLCI numbers on a multipoint Frame Relay interface to an IPX network.node number. Frame Relay Inverse ARP can dynamically map the DLCI number to an IPX network and node number. Alternatively, you can use the interface configuration subcommand frame-relay mapipx to statically map the Frame Relay DLCI address to an IPX network.node number that is reachable through the multipoint WAN interface.

Addressing multipoint X.25 WAN interfaces is similar to addressing Frame Relay interfaces in that both use static map interface configuration subcommands. X.25 interfaces must have their IPX addresses mapped to the X.121 addresses used to set up the virtual circuits between systems. Each virtual circuit is identified by the X.121 address used to set up the connection. Use the interface configuration subcommand x25 map ipx to establish the static mapping between the IPX address and X.121 address on a multipoint WAN interface.

Addressing multipoint ISDN interfaces also requires static map commands. In ISDN, however, the mapping commands are only required when a device wants to establish a call to another device. The IOS interface configuration subcommand dialer map ipx is used to map IPX addresses to system names and phone numbers that are used to set up calls over ISDN.

The mapping between ATM data link VPI/VCI addresses and the IPX network number on the multipoint ATM interface depends on the type of ATM protocols and the type of virtual circuits used. For IPX, you can use LLC/SNAP encapsulation over ATM with both PVCs and SVCs. With PVCs, a permanent virtual circuit is established through the ATM network, and packets are identified as being destined for an IPX address at the other end of the specific virtual circuit. With SVCs, IPX packets are identified as being destined for a specific, statically defined ATM link layer address. When the router requests a connection to the ATM address for a specific IPX address, the ATM switch establishes the virtual circuit on demand.

LLC/SNAP encapsulation with PVCs makes use of the IOS interface configuration subcommand map-group and the IOS global configuration command map-list to map IPX addresses to specific PVCs. LLC/SNAP encapsulation with SVCs makes use of the IOS interface configuration subcommand map-group and the IOS global configuration command map-list to map IPX addresses to the NSAP (network service access point) addresses used to identify the remote devices on the ATM network.

Verifying IPX Address Configuration

Verifying the IPX addresses and other IPX attributes assigned to your interfaces can be accomplished via the EXEC command show ipx interface. This command provides a complete look at all the parameters associated with the IPX configuration of all interfaces. If a specific interface is supplied as a parameter to the command, only the information about that interface is displayed. Following is the output of the show ipx interface ethernet 0 command executed on ZIP network's SF-2 router:

SF-2#show ipx interface ethernet 0
Ethernet0 is up, line protocol is up
  IPX address is 200.0000.0c0c.11bb, NOVELL-ETHER [up]
  Delay of this IPX network, in ticks is 1 throughput 0 link delay 0
  IPXWAN processing not enabled on this interface.
  IPX SAP update interval is 60 seconds
  IPX type 20 propagation packet forwarding is disabled
  Incoming access list is not set
  Outgoing access list is not set
  IPX helper access list is not set
  SAP GNS processing enabled, delay 0 ms, output filter list is 1010
  SAP Input filter list is not set
  SAP Output filter list is not set
  SAP Router filter list is not set
  Input filter list is not set
  Output filter list is not set
  Router filter list is not set
  Netbios Input host access list is not set
  Netbios Input bytes access list is not set
  Netbios Output host access list is not set
  Netbios Output bytes access list is not set
  Updates each 60 seconds, aging multiples RIP: 3 SAP: 3
  SAP interpacket delay is 55 ms, maximum size is 480 bytes
  RIP interpacket delay is 55 ms, maximum size is 432 bytes
  IPX accounting is disabled
  IPX fast switching is configured (enabled)
  RIP packets received 6, RIP packets sent 1861
  SAP packets received 330, SAP packets sent 4

In the first line of the output, you can see the administrative and operational status of the interface. The second line shows the IPX network.node address and IPX encapsulation. The output also shows the status of many different IPX filters and access lists, some of which we discuss later in this chapter.

The IOS EXEC show ipx interface command has an option that enables you to see a brief summary of IPX address information and the interface statuses for all available interfaces on the device. This summarized version is obtained using the show ipx interface brief command. Following is the output of the show ipx interface brief command executed on the ZIP SF-2 router:

SF-2#show ipx interface brief
Interface    IPX Network   Encapsulation   Status       IPX State
Ethernet0    200           NOVELL-ETHER    up           [up]
Ethernet1    150           NOVELL-ETHER    up           [up]
Fddi0       10            SNAP            up           [up]
Loopback1     unassigned       not config'd    up           n/a

From the preceding output, you can see the IPX network number assigned to each interface, the Novell encapsulation, and the operational status of each interface.

In addition to verifying the IPX configuration on the interface itself, you can view both the static and dynamic mappings of IPX addresses to data link addresses on the various WAN multipoint media. To do so, use the IOS EXEC commands show frame-relay map, show atm map, show x25 map, and show dialer maps.

   

< Back Contents Next >

Save to MyCKS

 

Breaking News

One of the primary architects of OpenCable, Michael Adams, explains the key concepts of this initiative in his book OpenCable Architecture.

Expert Advice

Ralph Droms, Ph.D., author of The DHCP Handbook and chair of the IETF Dynamic Host Configuration Working Group, guides you to his top picks for reliable DHCP-related information.

Just Published

Residential Broadband, Second Edition
by George Abe

Introduces the topics surrounding high-speed networks to the home. It is written for anyone seeking a broad-based familiarity with the issues of residential broadband (RBB) including product developers, engineers, network designers, business people, professionals in legal and regulatory positions, and industry analysts.

             
     

From the Brains at InformIT

|

Contact Us

|

Copyright, Terms & Conditions

|

Privacy Policy

 

© Copyright 2000 InformIT. All rights reserved.