15 = Precedence Cut Off in Effect (precedence of datagram is below the level set by the network administrators).
Figure 5 shows packets with sub type 3, or Port Unreachable.
These Internet Control Message Protocol (ICMP) packets are generated because the IP address 10.3.32.37 port 10139 tried to access port 161 on the same machine. No application was listening on port 161, so this generated an ICMP error. Since this port happened to be for UDP, it also generated a UDP No Ports error.
8. Thou shalt address the reason for your IP address errors: Consider problems that may appear in
IP traffic. You may find in monitoring your TCP network some counters that may be called IP Address Errors. One especially suspicious circumstance is when the IP address errors and IP discards in counters are the same. Packets are coming in with an “unknown” address and are being discarded.
What kinds of packets might these be? Figure 6 shows many packets coming into the mainframe with an address of 255.255.255.255. This is a broadcast address; by setting the address to all ones (255.255.255.255), all hosts on the network receive the broadcast. These packets may not contain data that the mainframe can understand or is interested in, so the packets are discarded. Why send packets just to have them discarded?
9. Thou shalt not convert thy applications directly from multi-dropped Synchronous Data Link Control (SDLC): When many short segments are sent, there’s overhead associated with the traffic;
each packet contains at least 40 bytes in IP and TCP headers. If you send a short segment, then a high proportion of the packet is overhead. Figure 7 shows an application that was ideal for a multi-dropped SDLC link. It was converted directly to a TCP application keeping the same message lengths. On a TCP virtual circuit, this kind of application is quite resource-intensive and may have poor response time.
10. Thou shalt not use two packets when one will do: We’ve seen applications send two packets for
each transmission with the second packet having only a protocol flag set on! The protocol flag could have been combined with the flags in the first packet. This is a small mistake, but when you make it a million times a day, it becomes a big mistake.
Tuning TCP/IP is like death by a thousand paper cuts. There can be thousands of small mistakes. When we do tuning, we work little by little, fixing each one the best we can. The results have been quite satisfying. As problems are fixed, we can see a reduction in the overhead CPU usage for the TCP stack on the mainframe. Throughput and response time for the applications should also improve. It’s a task well worth undertaking.