Protocols and Packets
Applying what you have learned to real-world troubleshooting is important for the successful support person. Starting with Table 4-3, I compare some of the protocols, applications, and utilities at each layer of Novell's IPX/SPX stack to the TCP/IP suite to assist you with supporting day-to-day internetworks.
| Layer | ISO's OSI Model | DoD TCP/IP Suite | Novell IPX/SPX Stack |
|---|---|---|---|
| 7 | Application | Application | Applications
NetBIOS NCP[*] SAP[*] RIP NLSP[*] |
| 6 | Presentation | ||
| 5 | Session | ||
| 4 | Transport | Transport Host-to-Host | SPX |
| 3 | Network | Internet | IPX |
| 2 | Data Link | Data Link | Various LAN/WAN technologies such as Ethernet, Token Ring, FDDI, Frame Relay, HDLC, PPP |
| 1 | Physical | Physical |
[*] NCP = NetWare Core Protocol
[*] SAP = Service Advertisement Protocol
[*] NLSP = NetWare Link State (Services) Protocol
Networks today are predominantly IP, but IPX still exists. NetWare 5 and 6 run native IP, but earlier Novell networks used Novell's own flavor of IP. Internetwork Packet Exchange (IPX), like IP, is a connectionless datagram delivery routed protocol that encompasses the upper five layers of the OSI model. IPX relies on its counterpart Sequenced Packet Exchange (SPX) for reliability like IP relies on TCP or an upper-layer application. At Layer 2, IPX supports media such as Ethernet, Token Ring, FDDI, Frame Relay, HDLC, and PPP. However, the main IPX troubleshooting target at Layer 2 is encapsulation.
NOTE
With NetWare, the client configuration is intentionally very simple. If the client gets the frame type (encapsulation) correct, it will likely work.
Frame Types
Encapsulation, frame format, frame type—they all mean the same thing, which is packaging the upper-layer data, voice, or video into a Layer 2 frame. Compare the IPX and IP framing examples in Figure 4-5.
Frame types are not just another table to memorize to take a Cisco test. They are real troubleshooting targets regardless of the upper-layer protocols. For instance, machines running only Ethernet_II cannot see machines running only Ethernet_802.3 and vice versa. On the Cisco side, subinterfaces and secondary addresses support multiple frame types, and on the Novell server side you can bind multiple frame types to the NIC or use multiple NICs. Be aware, however, that running multiple frame types affects network speed and performance. Routers assist with multiple frame types by stripping the Layer 2 package and repackaging it according to the destination network address.
Although frame formats are covered more thoroughly in Chapter 5, “Shooting Trouble with Ethernet,” they are covered briefly here because you must at least be familiar with them to support the Novell environment. Review them in Table 4-4.
| 802.3 RAW (Novell) Frame Format | |||
|---|---|---|---|
| 802.3 | IPX | ||
| |||
| 802.3 (IEEE) Frame Format with an 802.2 (LLC) SAP Header | |||
| 802.3 | 802.2 LLC | IPX | |
| |||
| 802.3 (IEEE) Frame Format with a 802.2 (LLC) SAP/SNAP Header | |||
| 802.3 | 802.2 LLC | SNAP | IPX |
| |||
| Ethernet II (DIX) Frame Format | |||
| Ethernet II | IPX | ||
| |||
NOTE
Unfortunately many acronyms are re-used in the industry. 802.2 LLC SAPs are service access points or pointers to the Layer 3 protocol. They have nothing to do with the Novell Service Advertisement Protocol (SAP).
The default frame type on Novell servers varies from NetWare version to NetWare version. In the next chapter, you will use your protocol analyzer to analyze the frame types in more detail, but for now use the following NetWare version list as a guide:
Ethernet_II is the default for NetWare 5.x and 6.x for Ethernet links.
HDLC is the default for serial links.
Ethernet_802.3 is the default for NetWare 3.11 and prior for Ethernet links.
Ethernet_802.2 is the default to NetWare 3.12 through 4.x for Ethernet links.
SNAP is the default for Token Ring and FDDI.
NOTE
In a TCP/IP Ethernet environment, Cisco defaults to ARPA, whereas in a Novell IPX network, Cisco defaults to Novell-Ether. In either case, serial links default to HDLC encapsulation. However, Cisco has never changed their default IPX frame type. If NetWare is using IP, there is no IPX, so there is no issue with IPX frame types. Hence, there is some validity to drop the X in IPX and things work just fine.
Table 4-5 illustrates the Cisco names and Novell names for the various frame types. This is not only critical CCNA/CCNP material but information you need to configure IPX on Cisco routers in the real world.
| Cisco Encapsulation | Novell Frame Type | Description | Novell Version Default |
|---|---|---|---|
| ARPA (Default for IP Ethernet) | Ethernet_II | EtherType pointer to Layer 3 | NetWare 6.x NetWare 5.x |
| SAP | Ethernet_802.2 | Length field 802.2 LLC SAP pointer to Layer 3 | NetWare 3.12 through NetWare 4.x |
| Novell-Ether (Default for IPX Ethernet) | Ethernet_802.3 | Length field | NetWare 3.11 and below |
| SNAP | Ethernet_SNAP | Length field
802.2 LLC SAP SNAP header | SNAP default for Token Ring and FDDI |
| HDLC | HDLC | Serial links | All versions for serial links |
Now is a good time to bring a Novell server online or to investigate my scenario so that you can witness a practical example of framing issues. My Novell server is a 4.11 box that is also serving as a GroupWise mail server. However, my Novell server, named gwise is beeping pretty loud and quite often right now. Example 4-24 displays the server output that is occurring about every 60 seconds.
Example 4-24. Bringing the Novell NetWare 4.11 Box Online
#4-01-02 6:26:36pm: IPXRTR-6.50-2 RIP router configuration error detected. Node 00000C8D6705 claims network address 8DA0A850 should be 00000516. |
What is wrong? You can press Ctrl+Esc to see the current screens on the Novell server and type help at the NetWare console (GWISE: server prompt) for hints and help with Novell commands.
From the server console, I issued the load monitor command to look at the Available Options menu and found the LAN/WAN information to be quite useful. Example 4-25 displays the information I gleaned from the Novell monitor.
Example 4-25. load monitor Displays the Bindings
#NE2000_1_E82 [NE2000 port=300 int=A frame=ETHERNET_802.2] NE2000_1_E83 [NE2000 port=300 int=A frame=ETHERNET_802.3] NE2000_1_EII [NE2000 port=300 int=A frame=ETHERNET_II] |
Pressing Enter on each of the bindings in the preceding example yields the following information:
802.2 binding:
Node address 008029E85C6B
IPX network address 8A4A85A5
802.3 binding:
Node address 008029E85C6B
IPX network address 8DA0A850
Ethernet II binding:
Node address 008029E85C6B
Address Resolution Protocol (ARP) and IP protocols
The NetWare display networks command shows the following networks: 346648E2, 8A4A85A5, and 8DA0A850. 346648E2 is the IPX internal network number for the server, which always has a node address of 000000000001. The others are IPX external numbers that are bound to the NIC. 8A4A85A5 is for frame type 802.2, and 8DA0A850 is for frame type 802.3. Look back at the original problem and note that the server is saying that 8DA0A850, the 802.3 network, should be 516. Refer back to Figure 4-1 to confirm the whereabouts of IPX network 516 to determine the issue.
NOTE
The exact error message is often helpful when trying to find the problem. This one happens to be: “RIP router configuration error detected. Node 00000C8D6705 claims network address 8DA0A850 should be 00000516.”
Next I typed load edit to bring up the Novell autoexec.ncf file, but my parameters were transferred to a netinfo.cfg file by the inetcfg NLM. So I typed load inetcfg to configure the correct network for frame type 802.3. Remember the default frame type for NetWare 4.x is Novell 802.2 or Cisco SAP, which is the issue here. From the inetcfg menu, I picked Internetworking Configuration and then the Bindings submenu to change the 8DA0A850 network to 516. For the commands to take effect, I had to type the reinitialize system command.
You can do the same thing in multiple ways. For example, instead of using the menus as I did, you could do everything from the Novell server console prompt, where you would have to issue the unbind command first and then bind. In addition, instead of downing and exiting the console, you certainly could issue the down command and then restart server, or down, then exit, and then server. Example 4-26 illustrates loading drivers and binding IPX to the NIC at the console.
Example 4-26. Loading Drivers and Binding IPX to the NIC at the Console
LOAD NE2000 NAME=NE2000_1_E83 FRAME=ETHERNET_802.3 INT=A PORT=300 BIND IPX NE2000_1_E83 NET=516 ... |
NOTE
Whether from the command line or inetcfg, these commands prove quite helpful in a Cisco/Novell support environment; after all, incorrect frame types are a common issue between Novell and Cisco devices. Multiple frame types are supported in Novell and Cisco, although not a best practice. On Cisco devices, the preferred method is to configure subinterfaces, but secondary addresses still work too.
That did it. You fixed the beep and can see the following networks, including the tick/hop count with display networks at the server console:
516 0/1
532 1/2
548 2/3
564 2/3
580 2/3
596 2/8
1011 1/2
1022 2/8
346648E2 0/1 (internal IPX number)
8A4A85A5 0/1
NOTE
Ticks/hops and the network numbers are explained in the section “Internet Layer Protocols, Applications, and Utilities” later in this chapter.
NOTE
The Cisco equivalent command to Novell's display networks is show ipx route. Remember that as with other protocols, all routes can be cleared to force convergence with clear ipx route *, but clearing an individual route is preferable and therefore not as much of a career-limiting move (CLM) in the practical environment.
The Novell config console command is great for getting a quick display of the hardware settings, node address, frame type, board name, and bindings for documentation or for setting up filters. Use it to check your work on the server (see Figure 4-6).
NOTE
I am recommending you update your drawing at this point. However, I am assuming that you have realized the importance of documentation and have been doing so all along. I will continue without too many reminders in this area.
NOTE
It is a good practice to always specify encapsulation when you configure Novell interfaces on Cisco routers. Whether the default or not, this will make you conscious of the correct encapsulation type. Besides, this is a good item to document.
Next you should configure at least one IPX host to prepare for the rest of the chapter. Using the Network Properties sheet, configure hostb for IPX as the default protocol using the Microsoft Client for NetWare as the primary logon with auto frame-type detection. Follow these steps for the Windows 98 hostb client. Other Microsoft client configurations are very similar. If you prefer to use the Novell clients, go to Novell's website for specific instructions.
Step 1. | Go to Start > Settings > Control Panel and choose Network or just right-click Network Neighborhood to get to Properties. |
Step 2. | Add the Microsoft Client for NetWare and select it as the Primary Network Logon. |
Step 3. | Add the Microsoft protocol IPX/SPX (or NWLink). Enable NetBIOS support in the Properties sheet and review the other tabs. On the Advanced tab, locate where you adjust the frame type so that you are familiar with it. Also put a check in the box for IPX to be the default protocol. It is not necessary to run TCP/IP on the client at all for this chapter. |
Step 4. | Make sure the Novell server is up and running before you reboot the client. Reboot the client and log in with the Administrator account and password for your Novell server. |
Step 5. | Right-click Network Neighborhood and edit the Microsoft Client for NetWare. Choose the preferred server name for your lab from the drop-down list. For example, mine is gwise. |
NOTE
Many workstations send out Get Nearest Server (GNS) requests in a specific order, such as 802.3, 802.2, Ethernet_II, and SNAP. To stop a workstation from attaching itself to a server with the wrong frame type, manually set the correct frame type under the IPX properties. Depending on the client, you can check this information using ipxroute config at the command prompt.
Internet Layer Protocols, Applications, and Utilities
The Novell IPX suite of protocols includes not only IPX and SPX but also many upper-layer applications and utilities for file, print, messaging, database, and other common practical services. You confirmed this when you enabled IPX routing, because it automatically enabled IPX RIP as the routing protocol by default.
IPX uses RIP and SAP broadcasts to build a table of routes and a table of services. Just as with an IP packet, routing decisions must be made for an IPX packet based on the destination network.
Your first task in this subsection is to turn on debug ipx packet and ping the Novell server internal IPX number from r1 using the address from the Novell console config command (as in Example 4-27). Next ping a few router interfaces. Why can you ping the router interfaces but not the Novell server? Capture this activity to a Sniffer file and save it as chapter 4 ping fails from r1 to novell server sniffer capture.
Example 4-27. Ping IPX Fails from R1 to Novell Server
r1#debug ipx packet IPX packet debugging is on r1#ping Protocol [ip]: ipx Target IPX address: 346648e2.0000.0000.0001 Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: Verbose [n]: Type escape sequence to abort. Sending 5, 100-byte IPXcisco Echoes to 346648E2.0000.0000.0001, timeout is 2 seconds: 01:28:39: IPX: local:516.0000.0c8d.6705->346648E2.0000.0000.0001 ln=100 tc=00 pt=01 ds=0002 ss=0002, gw=Et0:516.0080.29e8.5c6b. 01:28:41: IPX: local:516.0000.0c8d.6705->346648E2.0000.0000.0001 ln=100 tc=00 pt=01 ds=0002 ss=0002, gw=Et0:516.0080.29e8.5c6b. 01:28:43: IPX: local:516.0000.0c8d.6705->346648E2.0000.0000.0001 ln=100 tc=00 pt=01 ds=0002 ss=0002, gw=Et0:516.0080.29e8.5c6b. 01:28:45: IPX: local:516.0000.0c8d.6705->346648E2.0000.0000.0001 ln=100 tc=00 pt=01 ds=0002 ss=0002, gw=Et0:516.0080.29e8.5c6b. 01:28:47: IPX: local:516.0000.0c8d.6705->346648E2.0000.0000.0001 ln=100 tc=00 pt=01 ds=0002 ss=0002, gw=Et0:516.0080.29e8.5c6b 01:28:47: IPX: Se1:580.00b0.6481.e300->580.ffff.ffff.ffff ln= 72 tc=00 pt=01 ds=0453 ss=0453, rcvd 01:28:47: IPX: Se1:580.00b0.6481.e300->580.ffff.ffff.ffff ln= 72 tc=00 pt=01 ds=0453 ss=0453, local. Success rate is 0 percent (0/5) ... r1#show ipx interface ethernet 1 Ethernet1 is up, line protocol is up IPX address is 532.0000.0c8d.6706, NOVELL-ETHER [up] Delay of this IPX network, in ticks is 1 throughput 0 link delay 0 ... r1#ping ipx 532.0000.0c8d.6706 01:29:20: IPX: Et0:516.0080.29e8.5c6b->516.ffff.ffff.ffff ln= 40 tc=00 pt=01 ds=0453 ss=0453, rcvd 01:29:20: IPX: Et0:516.0080.29e8.5c6b->516.ffff.ffff.ffff ln= 40 tc=00 pt=01 ds=0453 ss=0453, local0c38.a05d Type escape sequence to abort. Sending 5, 100-byte IPXcisco Echoes to 532.0000.0c38.a05d, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 16/16/16 ms r1# 01:29:26: IPX: local:532.0000.0c8d.6706->532.0000.0c38.a05d ln=100 tc=00 pt=01 ds=0002 ss=0002, gw=Et1:532.0000.0c38.a05d 01:29:26: IPX: Et1:532.0000.0c38.a05d->532.0000.0c8d.6706 ln=100 tc=00 pt=02 ds=0002 ss=0002, rcvd 01:29:26: IPX: Et1:532.0000.0c38.a05d->532.0000.0c8d.6706 ln=100 tc=00 pt=02 ds=0002 ss=0002, local 01:29:26: IPX: local:532.0000.0c8d.6706->532.0000.0c38.a05d ln=100 tc=00 pt=01 ds=0002 ss=0002, gw=Et1:532.0000.0c38.a05d 01:29:26: IPX: Et1:532.0000.0c38.a05d->532.0000.0c8d.6706 ln=100 tc=00 pt=02 ds=0002 ss=0002, rcvd ... r2#show ipx interface serial 0 Serial0 is up, line protocol is up IPX address is 564.0000.0c38.a05d [up] r2#ping ipx 564.0000.0c38.a05d type escape sequence to abort. Sending 5, 100-byte IPXcisco Echoes to 564.0000.0c38.a05d, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 60/60/64 ms r1#undebug all All possible debugging has been turned off |
NOTE
In the previous examples you looked at the interfaces to gather the IPX address to ping. Don't forget that show cdp neighbors detail gives that information for remote devices too. Just like with IP it is helpful to test local and remote communications. Use the CDP method to locate the r2e0 address to ping test it.
A simple ping is the most basic testing tool with IPX, too, for checking whether packets make it to the destination. In IPX, however, the address is a little more difficult to type because you need the network number followed by the node address (MAC address). The default ping is a Cisco ping, which uses IPX protocol number 2 (as you can verify in the shaded output of the preceding example). The IPX official ping uses socket number 0x9086. Cisco ping works fine for your Cisco devices, but your IPX devices do not understand its proprietary nature. It is good practice to change the IPX ping type using the ipx ping-default novell global configuration command on your routers. Fix the IPX ping problem and verify as in Example 4-28. Change the ping type to Novell on r1 through r5 and save your configurations. Capture the results with a protocol analyzer to a file named chapter 4 ping fix from r1 to novell server sniffer capture.
Example 4-28. Ping IPX Fix from r1 to Novell Server
r1(config)#ipx ping-default ? cisco use cisco echoes for IPX ping diagnostic use Diagnostic Request/Response for IPX ping novell use Novell Standard echoes for IPX ping r1(config)#ipx ping-default novell r1(config)#end r1#copy running-config startup-config ... r1#ping ipx 346648e2.0.0.1 Type escape sequence to abort. Sending 5, 100-byte IPX Novell Echoes to 346648E2.0000.0000.0001, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms r1#debug ipx packet IPX packet debugging is on 01:42:05: IPX: Et1:532.0000.0c38.a05d->532.ffff.ffff.ffff ln= 64 tc=00 pt=01 ds=0453 ss=0453, rcvd 01:42:05: IPX: Et1:532.0000.0c38.a05d->532.ffff.ffff.ffff ln= 64 tc=00 ... r1#ping ipx 346648e2.0.0.1 Type escape sequence to abort. Sending 5, 100-byte IPX Novell Echoes to 346648E2.0000.0000.0001, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 16/16/20 ms r1# 01:42:16: IPX: local:516.0000.0c8d.6705->346648E2.0000.0000.0001 ln=100 tc=00 pt=04 ds=9086 ss=9086, gw=Et0:516.0080.29e8.5c6b 01:42:16: IPX: Et0:346648E2.0000.0000.0001->516.0000.0c8d.6705 ln=100 tc=01 pt=04 ds=9086 ss=9086, rcvd 01:42:16: IPX: Et0:346648E2.0000.0000.0001->516.0000.0c8d.6705 ln=100 tc=01 pt=04 ds=9086 ss=9086, local 01:42:16: IPX: local:516.0000.0c8d.6705->346648E2.0000.0000.0001 ln=100 tc=00 pt=04 ds=9086 ss=9086, gw=Et0:516.0080.29e8.5c6b ... r1#undebug all All possible debugging has been turned off |
The Cisco debug ipx packet command is quite helpful in this instance. Notice that when you change the ping type to Novell, socket 0x9086 is used, whereas previously it was protocol number 2. The 452s and 453s shown are for SAP and RIP sockets. Later you may notice 455 for NetBIOS. Also compare the Example 4-28 Novell IPX echos to the Example 4-27 Cisco IPX echos. You can also load ipxping at the Novell server console and test things from that direction if you desire.
NOTE
The debug ipx packet command was helpful in finding the source of this problem, but debug packet anything is not the best choice in a production environment. Actually, not all Novell hosts respond to a ping, and in the real world you might have to resort to pinging a router interface and using other upper-layer testing methods for the host. Problems such as these are mind teasers at times and often frustrating. If all else fails with your structured layered methodology, remember to ask someone for help or get a good night's sleep on it.
Compare the output of the debug and Sniffer captures for the ping portion only. Figure 4-7 and Figure 4-8 help you locate the protocol and socket information in Sniffer.
Table 4-6 lists the fields of the IPX header (packet or datagram). Use the Sniffer capture of the IPX ping file from the preceding example to view the fields as in Figure 4-9.
| Field | Bits | Description |
|---|---|---|
| Checksum | 16 bits | Not used when set to all 1s (FFFF). |
| Packet Length | 16 bits | Number of bytes up to the MTU[*] size. No fragmentation. |
| Transport Control | 8 bits | Shows routers the packet has transited. The limit is 16. |
| Packet Type | 8 bits | Link to next layer (like IP protocol number). Examples include 0-unknown, 1-RIP, 5-SPX, and 17-NCP. |
| Destination Network | 32 bits | External (wire) network number. |
| Destination Node | 48 bits | MAC address. |
| Destination Socket | 16 bits | See source socket. |
| Source Network | 32 bits | External (wire) network. |
| Source Node | 48 bits | MAC address. |
| Source Socket | 16 bits | Pointer to upper layers (like a TCP/UDP port number). Examples include 0451-NCP, 0452-SAP, 0453-RIP, 0455-NetBIOS, and 0456-Diagnostics. 4000–6000 are ephemeral sockets for server and network communications. |
| Upper Layer Data | Varies | Information for upper-layer processes. |
[*] MTU = Maximum Transmission Unit
NOTE
The first 2 bytes of the IPX header are a 2-byte checksum. It is calculated in 1's complement binary, not 2's complement, so FFFF = minus 0 has the reserved meaning of “no checksum performed.”
The checksum is not used when set to all FFFFs. The length of the selected packet is 88 bytes; remember IPX does not fragment packets like IP. The transport control shows that 0 routers have been transited. Note that IPX time-to-live (TTL) counts up to a maximum of 16. In the IP header, TTL is initialized to a maximum of 255 and decremented to 0. The packet type is 1, which is how IPX links to the next layer. Sniffer is friendly enough to display packet type 1 as RIP rather than make you look up the data. Other sample protocol numbers you can expect to see here include the following:
The destination network.node is 516.FFFFFFFFFFFF, which is the directed broadcast for network 516. The source network.node is 516.00000c8d6705 for r1, which is the same as the source MAC from the Data Link Layer. The source and destination socket numbers are 453, which is the socket for RIP to link to the RIP header. Now review the IPX RIP packet in the Sniffer output in Figure 4-10. Compare it to Table 4-7.
| Field | Description |
|---|---|
| Operation | 1 RIP request 2 RIP response |
| Network number | Specified external IPX number |
| Number of hops | Routers passed through |
| Number of ticks | Time to reach network (about 1/18 of a second)
1 tick for LAN 6 ticks for WAN |
| SAP packet | See Table 4-8 |
Figure 4-10 illustrates Frame 22 of the previous ping file. The RIP header displays operation 2, which is a RIP response about various IPX external network numbers (wire IDs), including 548. The hop count is 2, which means passing through two routers, and the tick count is 3, which is how long it took, which in this case was about 3/18 of a second. Review Table 4-8 and Figure 4-11 to get more familiar with the IPX RIP SAP packet.
| Field | Description |
|---|---|
| Operation | 1 General service request
2 General service reply 3 Nearest service request 4 Nearest service reply |
| Service type | 4 File server
7 Print server 47 Advertising print server 112 HP print server 26B Time synchronization 278 NDS server |
| Server name | 48 bytes |
| Network address | 32-bit network, 48-bit node |
| Node address | 48-bit MAC address |
| Socket address | 16-bit socket number |
| Hops to server | Routers passed through |
[*] Refer to IANA's Novell SAP Table for a list of SAPs from various sources (www.iana.org/assignments/novell-sap-numbers).
The first occurrence of any SAP activity in Figure 4-11 and my previous ping Sniffer capture is Frame 24. The operation is a general service response for the following services:
0004 File Server
026B Time Synchronization
0278 NetWare Directory Server
0107 RSPX
The network.node information for each of these services is 346648e2.0000.0000.0001, which is the internal IPX number for my gwise server. The socket information is as follows:
0451 NCP
0005 Time Synchronization
4006 Ephemeral
8104 RConsole
NOTE
IPX sockets 4000 to 6000 are temporary sockets used for interaction with NetWare servers and other network communications.
You might find it interesting to go to your protocol analyzer with this capture open to check the SAP interval. Select the first SAP frame, use the Display menu to mark it, go down to the next SAP frame and view the relative or delta, which is roughly 1 minute. Obviously this can cause problems, especially over dial-on-demand routing (DDR) links. However, the Cisco IOS can spoof this traffic. NetWare 5 and above replace SAP with Service Location Protocol (SLP) so that service and directory agents interact to locate network services. See Novell's website for more information.
SAPs remind me of commercials on television. They just keep reminding you of things to eat or buy. This extra traffic is definitely not advantageous on the WAN. SAP tables can get rather large, and at a minimum you should limit SAP traffic on the WAN using SAP filters. Alternatively, you can adjust the SAP interval on the WAN interfaces or just don't configure IPX on the interface at all. Otherwise, you will severely impact the bandwidth available to users. Printers are a good example. They are typically local to your facility, so why advertise them to the rest of the world? SAP filters are from 1000 to 1099.
Consider this example. Assume that print servers are configured on the chapter scenario network 516. hosta and hostb need all IPX services on network 516. However, the other routers and hostc need only to be made aware of IPX file servers. Think about how to configure this and check your thoughts against Example 4-29.
Example 4-29. SAP Filter to Allow Only IPX File Servers
r1(config)#access-list 1005 permit ? -1 Any IPX net <0-FFFFFFFF> Source net N.H.H.H Source net.host address r1(config)#access-list 1005 permit -1 ? <0-FFFF> Service type-code (0 matches all services) N.H.H.H Source net.host mask <cr> r1(config)#access-list 1005 permit -1 4 r1(config)#interface ethernet 1 r1(config-if)#ipx output-sap-filter 1005 r1(config)#interface serial 0 r1(config-if)#ipx output-sap-filter 1005 r1(config)#interface serial 1 r1(config-if)#ipx output-sap-filter 1005 r1(config-if)#end r1#copy running-config startup-config |
The problem with Example 4-29 is that it blocks services other than print services. Remove the preceding filter if you actually configured this on your router. Apply a SAP filter to permit everything except print services, as in Example 4-30. Whether you need all the no statements is IOS version-dependent.
Example 4-30. SAP Filter to Deny All IPX Print Servers
r1(config)#no access-list 1005 r1(config)#interface ethernet 1 r1(config-if)#no ipx output-sap-filter 1005 r1(config)#interface s0 r1(config-if)#no ipx output-sap-filter 1005 r1(config)#interface s1 r1(config-if)#no ipx output-sap-filter 1005 r1(config-if)#exit r1(config)#access-list 1005 deny -1 7 r1(config)#access-list 1005 deny -1 47 r1(config)#access-list 1005 permit -1 r1(config)#interface e1 r1(config-if)#ipx output-sap-filter 1005 r1(config)#interface s0 r1(config-if)#ipx output-sap-filter 1005 r1(config)#interface s1 r1(config-if)#ipx output-sap-filter 1005 r1(config-if)#end r1#copy running-config startup-config |
NOTE
Input and output SAP filters are very effective. In general you should block Novell SAPs as close to the source as possible. Any network is permitted or denied by using -1, whereas any service is permitted or denied using 0. A combination of IPX standard access lists and SAP filters can accomplish quite a bit on the IPX scene. SAP filters are popular and useful, but be aware of how Novell print services works (because the printer SAP entry must be known to the file server).
Static SAPs can be created to simulate services that would show up with the show ipx servers command. The syntax is as follows:
router(config)#ipx sap service-type name network.node socket hop-count
The network must be in the router's IPX routing table. Take a look at a SAP table for many common SAP numbers and their descriptions. One way to do this in a lab environment is to enter ipx network commands on loopback interfaces. Then point the static SAPs to them. Remember that both IPX RIP and SAP obey split horizon.
Setting up your routers, the Novell server, and the clients; working with various commands; and performing the packet analysis in your lab should have made you a little more comfortable with how IPX works. I'll certainly test that out in the upcoming Trouble Tickets. IPX is the main protocol at the Internet Layer for the IPX/SPX stack. Helpers such as ARP and Reverse Address Resolution Protocol (RARP) are not used with IPX because the MAC address is the node address.
Before you venture into the Trouble Tickets, I'll spend a bit more time discussing addressing and routing protocols as I cover the Transport and Application Layers.
Transport (Host-to-Host) Layer Protocols, Applications, and Utilities
As you recall from the OSI model in Chapter 1, “Shooting Trouble,” the Transport Layer is all about host-to-host delivery. IPX is a Layer 3 unreliable connectionless datagram delivery protocol; its Layer 4 counterpart, reliable connection-oriented SPX, is for things such as remote console and printing. SPX II is compatible with SPX and in addition provides features such as sliding windows, end-to-end large data packets, and an orderly release of a connection. Check out www.novell.com for more details. Figure 4-12 displays Sniffer's view of the SPX header format when I issued the RConsole command from my client. Feel free to capture your own RConsole session, open the Sniffer file (chapter 4 remote console and spx sniffer capture) or just view the output from Figure 4-12.
As you have seen in the previous layered subsections, after you have eliminated Physical Layer issues, protocol connections are troubleshooting targets that must be considered. After the protocol connections have been confirmed as operational, it is time to move up to the Application Layers. I could not begin to cover the vast variety of upper-layer applications in use today, but I will introduce some more of the major Application Layer protocols of the IPX/SPX suite.
Prepare for the next section by performing the following:
Use Sniffer to capture the Novell server starting up; use a config command on the Novell box and a ping to the Novell server from r1. Save the file as chapter 4 startup 8023 server config and ping sniffer capture.
Use Sniffer to capture a client startup on an 802.3 network. Browse Network Neighborhood and look at the sys volume on the Novell server. Next select Start > Run \gwisevol1, choose Software and then Client. Optionally, select Whoami by right-clicking Network Neighborhood. Save the file as chapter 4 client startup on 8023 browse net neigh and sys sniffer capture.
Upper-Layer Protocols, Applications, and Utilities
At the upper layers of the IPX/SPX protocol stack, the Novell NetWare Core Protocol (NCP) is used by file servers and clients alike for server routines and file and print management. Novell clients make a GNS request, and Novell servers or Cisco routers can respond. This is possible because Cisco routers maintain a RIP and SAP table. However, the Cisco device is polite in that it lets a Novell server of the requested type respond if one exists in the direction from where the request was heard. When the client finds a server, it broadcasts a RIP request to locate a route to the server. Finally, the Novell client can send NCP requests to log on and use the file system.
Analyze the Sniffer client startup file that you captured earlier as I do in Figure 4-13 and Figure 4-14.
The IPX header in frame 26 shows the RIP request where the source address is 0.hostbmac and the destination is broadcast. The client does not actually learn its IPX network address until after the RIP response, as you can see in frame 33. Follow the overall sequence of messages in the Sniffer summary pane for GNS, the IPX RIP request, the NCP connection and negotiation, including the volume mounting. The IPX header in frame 32 displays the source and destination address as 0, which means this wire and the all FFFFFFFFFFFFs indicate a broadcast on this wire.
The NCP connection and negotiation occurs in lines 83 to 114. Frame 87 mentions the negotiation of get big packet max size where it is negotiating the path MTU size. IPX uses path MTU discovery rather than fragmentation. I think of this portion of NCP as like Microsoft's Server Message Block (SMB) protocol. Frames 89 to 92 sends two full MTU-size echos to port 0x4002 for testing. ACK packets take up space and burst mode is there for windowing, which can improve throughput for file transfers. NetWare increases and decreases the gap between packets for windowing. Login starts in f 4rame 105, where Sniffer shows the bindery object information for Administrator. NCP continues the mounting of the sys volume and volume 1 as well as the Administrator login.
NOTE
The bindery is a flat database on each server, whereas Novell Directory Services (NDS) is a hierarchical database of all objects in directory trees and organizational units. Although you can use just bindery services today, most Novell shops take advantage of the NDS capabilities for single-login purposes to use and manage network resources.
Another example of upper-layer services is Network Basic Input/Output System (NetBIOS). You enable NetBIOS support on the client. It is a Session Layer interface for IBM and Microsoft. Practical applications of NetBIOS include browsing Network Neighborhood and using many of the command-line net commands. Type net /? at the client command prompt to see the available network commands.
For example, I can type net view \GWISE to see the sys volume and volume 1 on my server or type net use to map a drive. The net use g: \gwisesys command maps the G: drive to my NetWare sys volume, so I can get to it as easily as I can to my C: drive. Type net config to see client and server information. These commands and others are very helpful troubleshooting commands for Windows-based clients, whether they are running the Microsoft Client for Novell Networks or for Microsoft Networks.
As with any protocol suite, you can spend a lifetime learning the specifics of the upper layers. For IPX in particular, you might want to spend more time researching NDS, ZenWorks, the NLMs, and other add-on modules for Novell and third-party services responsible for management, file, print, message, and database services.