Novell NetWare – 2000Trainers.com

Extended IPX Access Lists

In the same way that extended IP access lists give you a more granular level of control over IP traffic, extended IPX access lists allow you a finer level of control over IPX traffic. Extended IPX access lists not only allow you to filter traffic based on source and destination IPX addresses, but also IPX protocols and socket numbers. A variety of different IPX protocols and sockets exist, many of which were looked at in Chapter 4. The following example shows an extended IPX access list that denies all standard IPX ping traffic from moving from network 101A to network 101B. Recall that extended IPX access lists use the numerical range 900-999.

RouterA(config)#access-list 900 deny ? <0-255> Protocol type number (DECIMAL) any Any IPX protocol type ncp NetWare Core Protocol netbios IPX NetBIOS rip IPX Routing Information Protocol sap Service Advertising Protocol spx Sequenced Packet Exchange

After the deny statement, an extended IPX access list expects an IPX protocol type to be entered. For the purpose of illustration, I have chosen the entry for any, which would be similar to choosing ip in an extended IP access list.

RouterA(config)#access-list 900 deny any ? <0-FFFFFFFF> Source net N.H.H.H Source net.host address any Any IPX net log Log matches against this entry RouterA(config)#access-list 900 deny any 101A ? <0-FFFFFFFF> Source Socket HEXIDECIMAL all All sockets cping Cisco ipx ping diagnostic Diagnostic packet eigrp IPX Enhanced Interior Gateway Routing Protocol log Log matches against this entry ncp NetWare Core Protocol netbios IPX NetBIOS nlsp NetWare Link State Protocol nping Standard IPX ping rip IPX Routing Information Protocol sap Service Advertising Protocol trace Trace Route packet

After the source address has been entered, the access list expects a source socket to be specified. An IPX socket is similar to a TCP or UDP port. In this case, I want to deny standard IPX pings from network 101A to network 101B, so I chose nping (which is socket number 9086, incidentally), as shown below.

RouterA(config)#access-list 900 deny any 101A nping ? <0-FFFFFFFF> Destination net N.H.H.H Destination net.host address any Any IPX net log Log matches against this entry

The destination network is specified next, followed by the destination socket number.

RouterA(config)#access-list 900 deny any 101A nping 101B ? <0-FFFFFFFF> Destination Socket HEXIDECIMAL all All sockets cping Cisco ipx ping diagnostic IPX Diagnostic packet eigrp IPX Enhanced Interior Gateway Routing Protocol log Log matches against this entry ncp NetWare Core Protocol netbios IPX NetBIOS nlsp NetWare Link State Protocol nping Standard IPX ping rip IPX Routing Information Protocol sap Service Advertising Protocol trace IPX Trace Route packet RouterA(config)#access-list 900 deny any 101A nping 101B nping

After the command has been entered, this access list consists of one deny statement. Recall that we’ll still need some type of permit statement to allow all other traffic to pass. The statement below will allow all other traffic to pass through the access list.

RouterA(config)#access-list 900 permit any any all any all

If you take a look at the previous example, the meaning of the statement above should become clearer. The first two any statements represent protocols and source networks. The first all statement represents all sockets. The final any all statement is equivalent to saying “any destination network, all sockets”. Don’t forget to apply the access list to an interface – in this case, we’ll apply it close to the source network (that’s how extended access lists are usually applied), as an inbound access list on interface E0.

RouterA(config-if)#ipx access-group 900 in

To view all of the ipx access lists defined on the router, use the show ipx access-list command.

RouterA#show ipx access-list IPX standard access list 850 deny 101A 101B permit FFFFFFFF FFFFFFFF IPX extended access list 900 deny any 101A 9086 101B 9086 permit any any all any all

For the most part, you probably shouldn’t concentrate on memorizing the syntax of extended IPX access lists. However, you should be familiar with the ways in which they are capable of filtering traffic (source address, destination address, protocol, and socket numbers) and the numeric range (900-999) that they are identified by.

Routing IPX

For the purpose of both the CCNA and CCDA, you’ll also need to be familiar with routing IPX traffic across an internetwork. Recall from Chapter 7 that IPX functionality is enabled on a router through the use of the ipx routing command. After issuing this command, you can assign IPX addresses to interfaces by providing a network number, and optionally (on Ethernet, Token Ring, or FDDI interfaces) specifying an encapsulation type.

Setting up IPX routing is exceptionally simple. What I didn’t tell you in the last chapter is that after issuing the ipx routing command, your router is already running an IPX routing protocol – IPX RIP. Though much like the RIP protocol looked at previously, IPX RIP and IP RIP are not compatible – they are different routing protocols, even if they exhibit similar characteristics. For example, both define infinity as 16 hops, meaning that the maximum diameter of an IPX network running IPX RIP is 15 hops. IPX RIP update packets are broadcast every 60 seconds by default.

One major difference between the IP and IPX versions of RIP is the metric used. IPX RIP uses something referred to as a “tick” as its metric. A tick is the expected delay in reaching a network, and is defined as 1/18th of a second. In cases where the tick count between two networks is equal, hop count is used as the tiebreaker.

Figure: IPX network configuration.

For the purpose of illustrating IPX routing, we’re going to configure our routers as per the figure above. In this scenario we have two routers and three networks. The steps below outline the configuration of Router A.

RouterA#config t Enter configuration commands, one per line. End with CNTL/Z. RouterA(config)#ipx routing RouterA(config)#int s0 RouterA(config-if)#ipx network 99 RouterA(config-if)#int e0 RouterA(config-if)#ipx network 102A

The configuration of Router B is similar:

RouterB#config t Enter configuration commands, one per line. End with CNTL/Z. RouterB(config)#ipx routing RouterB(config)#int s0 RouterB(config-if)#ipx network 99 RouterB(config-if)#int e0 RouterB(config-if)#ipx network 101A

With only the few steps shown, we have enabled IPX on the routers, given the appropriate interfaces IPX addresses, and even enabled IPX RIP routing – recall that it is enabled automatically as part of the ipx routing command. The next step is taking a look at our IPX routing tables. This is done using the show ipx route command, which is shown on

Router A below. RouterA#sh ipx route Codes: C - Connected primary network, c - Connected secondary network S - Static, F - Floating static, L - Local (internal), W - IPXWAN R - RIP, E - EIGRP, N - NLSP, X - External, A - Aggregate s - seconds, u - uses, U - Per-user static 3 Total IPX routes. Up to 1 parallel paths and 16 hops allowed. No default route known. C 99 (HDLC), Se0 C 102A (NOVELL-ETHER), Et0 R 101A [07/01] via 99.0060.5cc4.f41b, 13s, Se0

Notice that an IPX routing table has a slightly different format, but still displays similar information to an IP routing table. It shows that networks 99 and 102A are directly connected, and also shows a route to network 101A via IPX address 99.0060.5cc4.f41b, which is the S0 interface on Router B. To check and see whether Router A can route all the way to network 101A properly, we can use an IPX ping, specifying the IPX address of interface E0 on Router B.

Router#ping ipx 101a.0060.5cc4.f88b Type escape sequence to abort. Sending 5, 100-byte IPXcisco Echoes to 101a.0060.5cc4.f88b, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms

Since our IPX ping worked, Router A and Router B are both configured with complete information about the IPX internetwork.

Pages: 12

NetWare Upper Layer Protocols

The IPX/SPX protocol suite isn’t nearly as orderly as others when it comes to mapping upper layer protocols to the OSI model. Many of the protocols found above the network layer span multiple OSI layers between Transport and Application. The mapping of the suite to the OSI model at the beginning of this section helps to illustrate this. While the actual mappings may not be so clear-cut, the purpose of these protocols is what is most important. We’ll take a look at a number of these here including SAP, NCP, NetWare Shell, and NetBIOS.

Service Advertising Protocol (SAP)

In older version of NetWare (those prior to version 4.0), servers made other systems aware of the services that they offered through the use of Service Advertising Protocol (SAP) broadcasts. For example, a NetWare server might be functioning as a both a file and print server. In this case, the server would broadcast SAP advertisements onto the network, making clients aware that these services are offered at its network address. SAP advertisements are also used by clients to find their nearest server at startup, in the form of a Get Nearest Server (GNS) request. SAP identifiers are hexadecimal numbers that represent the services. Common examples of SAP identifiers are listed below.

File Server 0x4 Gateway 0x6 Print Server 0x7

Servers send out SAP broadcasts every 60 seconds by default. Since these advertisements are broadcasts, they are limited in scope to the local broadcast domain. For this reason, clients in other broadcast domains will not hear these advertisements. To account for this, Cisco routers can be configured with access lists that can selectively propagate or ignore SAP advertisements from different systems. Similarly, when a local NetWare router is not available, a Cisco router can be configured to respond to GNS requests. Access lists and their configuration will be looked at in detail in Chapter 9.

Newer versions of NetWare that use eDirectory or NetWare Directory Services (NDS) rely on SAP broadcasts to a lesser degree, since the location of servers can be found via a query to an NDS/eDirectory server.

NetWare Core Protocol (NCP)

The NetWare Core Protocol (NCP) is a set of procedures followed in IPX-based communication. When a client using the NetWare Shell attempts to access file, print, or directory resources on a NetWare server, NCP processes the request.

NetWare Shell

In a Windows environment, the line between client and server roles is blurred. NetWare clients, on the other hand, are those running another operating system such as Windows 2000. The NetWare Shell is additional redirector software installed on a client to allow it to make requests to NCP on a NetWare server. For example, when a client wishes to access a network drive, the request is passed to the NetWare shell, which creates an NCP request. It then passes the NCP data to IPX to be forwarded over the network. In this way, a client application is unaware that the request is actually for a remote resource.

NetBIOS

NetWare also provides an emulated environment in which NetBIOS applications can be run. NetBIOS is a broadcast-based Session layer protocol developed by Microsoft and IBM that uses names instead of numerical addresses to represent clients. NetBIOS traffic can be encapsulated in IPX packets to allow NetBIOS-based communication across an internetwork.

Transport Layer – Sequenced Packet Exchange (SPX)

Sequenced Packet Exchange (SPX) is the reliable transport protocol used by IPX when connection-oriented communication is required. Much like TCP, SPX uses sequence numbers and acknowledgments to be sure that data is reliably passed between hosts. Beginning with NetWare 4.0, a new (and backwards-compatible) version of SPX called SPX II was released, providing a sliding window flow-control mechanism. You should be aware that not all IPX network communication requires the use of SPX. IPX is also capable of interacting with some of the other upper-layer protocols directly.

Network Layer – Internetwork Packet Exchange (IPX)

IPX is the routable Network layer protocol of the Novell IPX/SPX protocol suite. Similar to IP, IPX is also connectionless, meaning that it leaves reliability to upper-layer protocols such as SPX. IPX addresses are used to uniquely identify hosts on an IPX network. While an IP address is comprised of 32 bits and is usually represented in dotted-decimal notation, an IPX address is an 80-bit address, represented in hexadecimal.

An IPX address is also made up of two parts – a network address and a host address. The network address is represented by the first 32-bits, while the unique host address is comprised of the final 48 bits. The example below outlines an IPX address.

0000000A.0101AE560163AC

An administrator defines the network portion of an IPX address. Leading 0’s can be left off the network portion. Because of this, the network above can be more simply referred to as network A. Like IP networks, every IPX network requires a unique network address.

Tip: Remember that the network portion of an IPX address is represented in hexadecimal. Since each hex digit represents 4 bits, it can be comprised of 8 hex digits maximum. Don’t forget that only the characters 0-9 and A-F are valid in hexadecimal.

The host address portion of an IPX address is actually incredibly simple – it’s the MAC address of a given host. Since all MAC addresses are different, the combination of a network number and a MAC address uniquely identifies a host on a given IPX network. Note that this also eliminates the need for a protocol such as TCP/IP’s ARP, since a host’s MAC address is already contained within the full IPX address.

The figure below outlines the fields with an IPX header. Note that this particular diagram, field sizes are displayed in bytes rather than bits.

Figure: IPX Header.

The IPX header fields are described below:

Checksum. A computed value that verifies the integrity of the IPX header, similar to a CRC. This was not used in versions of NetWare prior to 4.0, where it was set to all 1’s.
Packet Length. This field specifies the complete length of the IPX packet, including data.
Transport Control. Similar to a TTL (Time-To-Live), when a router processes a packet, it must increment this TTL by 1. At 16, a packet is removed from the network.
Packet Type. This field specifies the upper-layer protocol that data is to be passed to. Common hexadecimal values include 4 (SAP), 5 (SPX), 17 (NCP), 20 (NetBIOS)
Destination Network. The 32-bit destination network address.
Destination Node. The 48-bit destination node address.
Destination Socket. This field specifies the software process address on the destination system, similar to a TCP port number.
Source Network. The 32-bit source network address
Source Node. The 48-bit source node address.
Source Socket. Specifies the software process address on the sending system.
Data. The encapsulated data passed down from upper-layer protocols and applications.

Routing protocols such as RIP and NLSP also exist at the Network layer of the NetWare protocol suite. These will be covered in detail in Chapter 8.

Physical and Data Link Layers – Frame Encapsulation

NetWare protocols can run over a variety of different network technologies, similar to TCP/IP. For the purpose of keeping things simple, in this section we’ll concentrate on Ethernet. However, IPX can also be run over Token Ring, FDDI, ATM and a variety of WAN technologies. If you recall, Novell originally defined the 802.3 frame type to be used over Ethernet networks. These frames lacked a Type field, since all 802.3 frames were assumed to be destined for IPX at the Network layer. The 802.3 frame type is commonly referred to as Novell Ethernet 802.3 or Ethernet Raw. Different versions of NetWare use different Ethernet frame types as their default for encapsulating IPX packets. In NetWare 3.11 and earlier versions, the default frame type was 802.3. Beginning with Netware 3.12, the default frame type was changed to 802.2.

This presents a technical challenge, since different frame types are not interoperable. As such, a system configured to use only 802.3 frames cannot communicate with a system in the same broadcast domain that uses only 802.2 frames.

To help overcome these limitations, a Cisco router can be configured to use more than one Ethernet encapsulation type for IPX on a single interface. This allows a router to communicate with systems using different frame types. We’ll look at the actual configuration of IPX on a router in Chapter 8. For now, it is sufficient to know the different frame types support by Cisco, and the terms used to describe them.

novell-ether. Refers to 802.3 frames that lack an LLC header.
sap. Refers to the IEEE standard Ethernet frame with an 802.2 LLC header.
arpa. Refers to the Ethernet II frame type.
snap. Refers to the Ethernet SNAP frame type.

NetWare Protocol Suite

Similar to TCP/IP, the Netware or IPX/SPX protocol suite is actually made up of a number of protocols that serve different purposes in the network communication process. While the IPX/SPX suite has become less popular based on the widespread adoption of TCP/IP, it is still in use in many (especially larger) network environments.

The IPX/SPX suite comes from the world of NetWare, Novell’s popular network operating system (NOS). Up until NetWare 4.x versions, Novell servers primarily relied on IPX/SPX as their native networking protocol suite. However, versions as early as 3.1x are capable of IP-based communication via a loadable module called NetWare/IP that encapsulates IPX/SPX traffic in UDP datagrams. Beginning with version 5.0, NetWare began using TCP/IP as its primary network protocol, although support for IPX/SPX continues into current versions. In order to reduce the complexity of networks, most companies now deploying NetWare are choosing to use TCP/IP only. However, the use of older IPX-based servers continues to make IPX/SPX a requirement on many networks. For the purpose of both the CCNA and CCDA exams, you are expected to be familiar with IPX/SPX, although you will definitely find a much larger emphasis placed on TCP/IP.

NetWare and the OSI Model

The NetWare protocol suite also follows a layered design that can be roughly mapped to the OSI model. The figure below outlines some of the more common protocols that make up the suite. We’ll look at these in more detail in this section.

Figure: NetWare Protocol Suite and the OSI Model.

Gateway Services for NetWare and Client Services for NetWare

Often referred to by its acronym CSNW, Client Services for NetWare is a client redirector, which allows a Windows 2000-based system to connect and authenticate to a NetWare-based server and access the file system. CSNW should be installed when clients need to regularly access NetWare file or print servers. Often, CSNW is not installed in favor of the native Novell client for NetWare, which ships with the Netware product. Installing CSNW is accomplished by choosing to install a Client in the properties of a connection object.

It is worth noting that the installation of CSNW on a Windows 2000 Server is actually done as part of the installation of Gateway Services for NetWare, or GSNW. GSNW will also automatically install NWLink if it hasn’t already been installed on the system. On a Windows 2000 Professional system, an option exists for installing CSNW alone.

Once installed, configuration of the client and gateway elements is actually handled via the GSNW applet in Control Panel. The configuration includes the selection of either a preferred server (in a bindery-based NetWare environment) or of a default tree and context (in an NDS-based environment).

Gateway Services for NetWare is meant to be used in environments in which clients require less frequent access to NetWare-based servers. GSNW makes a Windows 2000 Server act as a gateway (or access point) to resources located on a NetWare server. Using GSNW allows you to eliminate the need for each client system to have CSNW or NWLink installed. Instead, clients access a shared folder on the Windows 2000 system running GSNW, which in turn allows them access to files and folders on the associated NetWare server. In order to configure Windows 2000 as a gateway, a gateway account must be configured using GSNW in Control Panel.

The account used must exist on the NetWare server, and must be a member of a group created on the NetWare server called NTGATEWAY. You must also ensure that the NTGATEWAY group has appropriate trustee rights to access resources on the NetWare server. Once the account has been set up, one or more shares must be created that access the netware server.

In this example, when users access the share called ‘netware’ on the Windows 2000 server, they will actually be accessing the folder ‘resources’ on NetWare server NW1.

NetWare Connectivity in Windows

Windows 2000 still supports some of the NetWare connectivity elements that you may be familiar with from Windows NT 4. The three main elements that you’ll need to be aware of are the configuration of NWLink, Client Services for NetWare (CSNW), and finally Gateway Services for NetWare (GSNW).

NWLink

NWLink is Microsoft’s version of Novell’s IPX/SPX transport protocol, the native transport protocol in releases of NetWare prior to version 5. Since IPX/SPX is still run in many enterprise networks, it is important to know how Windows 2000 communicates with systems running the IPX/SPX protocol. NWLink is configured in Windows 2000 by choosing to install the protocol in the properties of a connection object, such as a Local Area Connection.

Once the protocol is added, it can be configured by accessing its properties. Note that adding NWLink to a system only makes that computer capable of communicating with another IPX/SPX or NWLink-based system. It does not mean that this computer can access the file system of another IPX based system. That level of access requires that an appropriate client redirector be installed, which will be discussed in a moment.

Once NWLink has been installed, it might be appropriate to check your network binding order, in order to ensure that it is optimized correctly for your network. For example, if TCP/IP is listed first in your binding order and NWLink second, a client will always try to communicate using TCP/IP first, followed by NWLink. If IPX/SPX is the primary protocol used on your network, this may not be appropriate, and may cause unnecessary network traffic. The binding order for a connection is set via the Advanced Settings option under the Advanced menu item in Network and Dial-up Connections. The binding order is controlled according to the adapter and then the client or service, and can be changed via the up or down arrows to the right.

Pages: 12