Practical TCP/IP and Ethernet Networking- P27 pps

242 Practical TCP/IP and Ethernet Networking 15.4.2 TCP/IP based factory automation Schneider Automation: http://www.transparentfactory.com Richard Hirschmann Gmbh: http://www.hirschmann.de Allen-Bradley: http://www.ab.com 15.4.3 Thin servers LANTronix, http://www.lantronix.com 15.4.4 Web compatible SCADA systems WizNet, http://www.conlab.com.au 15.4.5 Java RCS-7 Java, http://www.auspex-inc.com 16 /TYZGRROTMGTJZXU[HRKYNUUZOTM +ZNKXTKZY_YZKSY  5HPKIZO\KY When you have completed study of this chapter you should be able to: • Define the functions of various types of network driver software • Describe the parameters which need to be set for a network card to function correctly • Determine how network cards are configured under the plug and play and PCMCIA architectures • Specify the uses for a protocol analyzer  4KZ]UXQJXO\KXY  4KZ]UXQJXO\KXY The network driver is a program used to provide an interface between the network card and the higher-level protocols. It spans the data link and network layers of the OSI model as shown in Figure 16.1. The network driver needs to match the specific hardware configuration of the network card such as its addresses of I/O ports, control and status registers, etc. Ethernet cards use the same IEEE 802.3 protocol so they can communicate with one another but each needs a unique driver because of the different vendor hardware implementations.  )USVGZOHOROZ_GTJ[YGMK The network driver must also be compatible with the appropriate network operating system protocols in the network, transport and session layers that are used to send data 6XGIZOIGR:)6/6GTJ+ZNKXTKZ4KZ]UXQOTM across the network. In early systems changing from one network protocol to another, e.g. TCP/IP to SPX/IPX, generally necessitated changing the network driver. The network operating systems communication protocols and their relationship to the OSI model are shown in Figure 16.1. Figure 16.1 Network operating system drivers/protocols  4KZ]UXQIGXJJXO\KXIUTLOM[XGZOUT The configuration of the network card must be set at installation to avoid conflict with the other devices installed on your computer. The manufacturers usually provide an installation guide and/or configuration software to help you set the correct options. The main parameters that may need to be set are as follows: /87INGTTKR The IRQ channel sets a unique interrupt request (IRQ) vector for when the network card needs attention. This must not conflict with existing devices. It needs to be checked in the normal operating environment. For example, with Windows applications the network card configuration software should be run from within the Windows shell. *3'YNGXKJSKSUX_ The Network card communicates its data to computer using either direct memory access (DMA) or use of a block of shared memory. The base address of the shared memory (usually 64 kilobytes) is defined here. Network cards are designed to be flexibly reconfigurable to accommodate other applications on your computer. 8'3HGYKGJJXKYY RAM base address defines the beginning of the address space (usually 16 kilobytes) used by the network card. Other devices must not use such address space. For example, extended memory manager software should be set to exclude such memory to avoid conflicts. /5HGYKGJJXKYY I/O base address defines the beginning of the address space used to communicate with the internal registers on the network card. Avoid conflicts with existing devices. /TYZGRROTMGTJZXU[HRKYNUUZOTM+ZNKXTKZY_YZKSY 853HGYKGJJXKYYGTJYO`K This is used for systems with an auto-boot ROM to configure diskless workstations. These load their operating systems over the network. Match the base address and EPROM size to the supplied boot ROM. The network card configuration is set on the card using switches or links and/or stored in flash memory (EEPROM) on the card by the configuration software.  4KZ]UXQJXO\KXOTZKXLGIKYVKIOLOIGZOUT4*/9 This is a software specification developed by 3COM and Microsoft in 1988 for use mainly in DOS and OS/2 operating systems. This defines a standard interface for communication between the MAC layer and any compatible protocols. This means that the MAC driver in any vendor’s NDIS compatible network cards can pass data to any NDIS compatible protocol. This standardization enables products from various vendors to be interconnected and to provide simultaneous support for multiple protocols. These NDIS drivers can be unloaded from memory to conserve DOS RAM space or allow changes to other drivers.  5VKTJGZGROTQOTZKXLGIK5*/ The ODI architecture provides an alternative to the OSI layering structure that can allow a number of network cards to simultaneously support different protocol stacks such as TCP/IP, SPX/IPX, etc. The ODI architecture makes use of a link support layer (LSL) and a multiple link interface driver (MLID) as shown in Figure 16.2. The MLID corresponds to part of the data link layer and interfaces to the LSL, which covers part of both the data link and network layers. This provides a standard, hardware independent, virtual interface for the network cards. The LSL switches multiple protocol packets to the correct MLID or the correct protocol stack as required. Figure 16.2 ODI architecture 6XGIZOIGR:)6/6GTJ+ZNKXTKZ4KZ]UXQOTM  6GIQKZJXO\KXY The packet driver is the generic interface between the TCP/IP protocol stack and the software responsible for the local area network card hardware. The packet driver hides the hardware specifics from the protocol stacks and likewise hides the protocol issues from the hardware. The packet driver operates at the MAC layer, and its implementation is critically dependent on the specific card hardware. Common driver specifications have evolved to provide standard interfaces to both the protocol stack and the card hardware, thus enabling the protocol to run on top of all network cards, which have that MAC driver specification. A common example is the packet driver developed by FTP Software, Inc, in 1987. The specification defines how the MAC driver loads and operates under DOS and defines a common software interface for various protocol stacks. The network card is independent of the protocol stacks, and one card can simultaneously handle packets destined for multiple protocols. Each protocol uses a software interrupt in the range 60 h–80 h to communicate with the packet driver.  6R[MGTJVRG_GXINOZKIZ[XK Modern PC motherboards support the PC/ISA plug and play (PnP) architecture. With this architecture the PC identifies which slot the particular card is inserted into and the BIOS dynamically assigns the resources the card requires e.g. IRQ, DMA channel etc, resolving any resource conflicts. These resource details are registered in the ESCD (extended system configuration data) and stored in flash memory on the motherboard. The data structure defines the resources used by each device and card on the system. When using PnP it is important to register all legacy cards and devices (non PnP), otherwise resource conflicts are likely.  6)3)/'OTZKXLGIK  /TZXUJ[IZOUT PCMCIA are the initials of the Personal Computer Memory Card International Association, which was formed in 1989 to promote the standardization and interchangeability of PC cards. As the name indicates initial devices were memory cards implemented as ‘virtual disk drives’ for mobile computer support. PC cards now come in a wide range of memory devices such as RAM, ROM FLASH memory, AT Attachment (ATA) hard drives, and many I/O devices including modems and network interface cards. The interface enables these devices to be powered from the computer and automatically detected by the system as soon as they are installed and then automatically configured. This gives the PC cards the ability to be inserted into a PCMCIA socket after the system has already been powered up.  6)3)/'OTZKXLGIK The PCMCIA interface consists of the following, as shown in Figure 16.3: .GXJ]GXK • The 16-bit PC card, (A 32-bit PC card and socket interface also exists called CardBus) • PCMCIA socket /TYZGRROTMGTJZXU[HRKYNUUZOTM+ZNKXTKZY_YZKSY • PCMCIA host bus adapter (HBA). These are hardware specific providing the interface between the host expansion bus (EISA, PCI, Micro Channel etc) and the standard interface to the PC card sockets 9ULZ]GXK • Socket services, which provide a standard low level software interface for programmers so that the details of the HBA do not need to be known • Card services provide a high level software interface for configuration software and a method of allocating system resources to the PC cards • PC card enablers, or PC card client drivers, read the PC card’s card information structure (CIS), which is in non-volatile memory on the card, indicating the type of device, the resources it requires, and configuration options. The enabler then configures the HBA and PC card Figure 16.3 PCMCIA software and hardware relationships After configuration, subsequent accesses to the PC card take place directly, without using the PCMCIA socket or card services, as illustrated above.  6XUZUIURGTGR_`KXY Protocol analyzers enable us to capture data going across the LAN for purposes of analysis. An analyzer inserted into a ring or connected across a bus has the capability of looking at all messages being sent. These messages can be stored in our computer-based protocol analyzer for subsequent analysis. By looking through the captured packet of data we can examine the message and protocol control information at each layer of the software. Protocol analyzers can operate in ‘promiscuous mode’ where they capture all messages from all nodes, or filters can be set so that the analyzer only captures those messages to or from specific nodes or in specific protocols. This is very useful for tracking down intermittent faults, so we can leave the analyzer running in the knowledge that it will capture the fault condition, along with all other packets from our faulty node, but will ignore the thousands of other packets from other users. 6XGIZOIGR:)6/6GTJ+ZNKXTKZ4KZ]UXQOTM Protocol analyzers range in cost and complexity from simple analyzers based on a standard LAN card which will capture valid packets, to more sophisticated units which will also analyze the pulses, and capture packet fragments.  17 :XU[HRKYNUUZOTM:)6/6  5HPKIZO\KY When you have completed study of this chapter you should be able to: • Describe how to do maintenance on TCP/IP networks • Describe three typical areas requiring troubleshooting • Describe how to troubleshoot with netstat, ping, tracert, ripquery  3GOTZKTGTIKGTJZXU[HRKYNUUZOTMULXKGR:)6/6TKZ]UXQY Obviously a pro-active approach to maintenance of the TCP/IP network is preferable to that of the troubleshooting which is really a reactive approach. Network monitoring needs to be objective and the creation of a baseline is a useful start. This comprises a set of monitoring points by which the network can be monitored and indeed be measured. It is important to distinguish between normal and peak network operation. If the network monitoring is done over a peak period such as large database backups being performed, this may result in false statistics being generated. Typical network statistics that need to be monitored are: 6KXIKTZGMK[ZORO`GZOUT This indicates how much of the total available activity on the network is used compared to the total (theoretically) available bandwidth. 6GIQKZYYKIUTJ This indicates the total number of messages on the bus. This is not the same as the utilization statistic, which indicates the total amount of data. 1ORUH_ZKYYKIUTJ This provides an indication of the actual throughput on the network.   6XGIZOIGR:)6/6GTJ+ZNKXTKZ4KZ]UXQOTM  +XXUXYYKIUTJ This gives the total number of errors on the network. This would include such as items as electrical noise on the network. Be careful of some network analyzers which report collisions as errors – these are not errors but an essential part of the operation of Ethernet using the CSMA/CD philosophy. 5\KXX[TY This indicates packets greater than 1518 bytes (1544 bytes in total length) and indicates a failing LAN driver. ;TJKXX[TY For similar causes to that of overruns, this indicates packets, which are shorter than 64 bytes. 0GHHKXY This arises due to packets longer than 1518 bytes. This arises from a faulty LAN driver or faulty LAN hardware. )8)GROMTSKTZY Packets that are not multiples of 8-bit bytes or have a CRC error may arise from noisy cables or defective components. )URROYOUTY This results from a collision between two (or more) Ethernet frames, which are greater than 64 bytes in length. Note that some network analyzers (such as Snooper and the Netboy Suite) may not be able to detect some of these statistics (such as errors/second) when operating in promiscuous mode, as the physical Ethernet card may not provide this information. Some of the important server-based baseline statistics are: )6;[ZORO`GZOUT This relates to the loading on the server CPU. This gives an indication of the capability of the network interface to maintain the performance levels. *OYQ/5 This indicates the speed of reading and writing the server/hosts file system(s). There should be some indication of the efficiency of the read and write caches. 3KSUX_[YGMK This gives an indication of the performance of the server/host memory. This information should be gathered continuously and then used to set up alarms for each measuring point. Typical alarm points should be set to about 10% of the averages recorded for each statistic gathered. It should be noted that baseline statistics don’t stay static but are constantly changing and as any network change is effected, the new statistics will need to be gathered.  4KZ]UXQZXU[HRKYNUUZOTM According to Dr Tim Parker (TCP/IP Unleashed) there are four attributes you require in troubleshooting TCP/IP problems (and indeed most network problems): • Some basic knowledge of the operation of networking protocols :XU[HRKYNUUZOTM:)6/6 • A clear understanding of the network’s topology and layout • The ability to utilize the troubleshooting tools (such as a Protocol Sniffer) • Some luck The greater the strength of the first three items, the less reliance will be placed on luck. A few typical areas to examine are:  /TIXKGYOTMT[SHKXULIURROYOUTYUTZNK+ZNKXTKZTKZ]UXQ As the utilization of the network increases the number of network errors will increase (although depending on the protocol analyzer and the specific Ethernet card you are using you may not directly observe these statistics). The quickest way to rectify this problem is to reduce the traffic by segmenting the network into smaller sub-networks using bridges or switches. Typical utilization figures would be 2 to 3% on an industrial Ethernet network with a maximum average of 10%. A commercial type Ethernet network (e.g. banking) where the response time may not be as critical can tolerate utilization figures up to 25% without undue problems. However if the number of errors on an Ethernet network is increasing but the utilization is staying at roughly the same level; this may be due to faulty hardware. Be careful of some network monitoring packages – they report collisions (a normal part of the CSMA/CD Ethernet system) as errors. In addition, some versions of the TCP/IP Netstat utility also report collisions as errors.  4KZ]UXQ[ZORO`GZOUTRU]H[ZKXXUXYNOMN This can invariably be traced to a faulty networking component – either hardware or software. If the packets are undersized (less than 64 bytes) and the frame check sequence (FCS) is good, it is likely that the network device driver needs to be replaced. On the other hand if the FCS is bad and the packets are undersized, this may mean that the network device driver is faulty. On the other hand if the packets are oversized (greater than 1518 bytes) and the FCS is good, this is referred to as excessive jabbering and probably means that the interface board or transceiver needs to be replaced. If the FCS is bad and the packets are greater than 1518 bytes, this probably means that the network device driver needs to be replaced.  .OMNT[SHKXULVGIQKZYH[ZRU]JGZGZXGTYLKXY As the traffic on a network increases it is expected that the number of packets increases and the total data throughput increases up to the maximum saturation amount of course. Hence the ratio of the number of packets transmitted per second and the total volume of data passed between hosts should remain roughly constant. If the number of packets increases without any corresponding increase in data throughput this could indicate potential routing problems/badly configured network applications or network components that are failing. A data capture will have to be performed to work out what is actually happening here.  :XU[HRKYNUUZOTM]OZN:)6/6;ZOROZOKY A complete list of utility programs for the TCP/IP environment is contained in the RFC 1340 and is discussed in an earlier chapter. Typical utilities useful for troubleshooting are: . 242 Practical TCP/IP and Ethernet Networking 15.4.2 TCP/IP based factory automation Schneider Automation: http://www.transparentfactory.com. specification developed by 3COM and Microsoft in 1988 for use mainly in DOS and OS/2 operating systems. This defines a standard interface for communication between the MAC layer and any compatible protocols loads and operates under DOS and defines a common software interface for various protocol stacks. The network card is independent of the protocol stacks, and one card can simultaneously handle