5 Etapas para uma solução de problemas de aplicativo bem-sucedida | NETSCOUT

5 Key Steps to Successful Application Troubleshooting

Cinco etapas para uma solução de problemas de aplicativo bem-sucedida

We will discuss each of these steps in succession:
1. Determine the domain of the problem and exonerate the network.
2. Conduct an Application flow analysis.
3. Fix the problem.
4. Validate the problem.
5. Document the fix.

Determine the domain of the problem and exonerate the network.
This process involves three steps: (1) Validating network services; (2) Validating connectivity to the server; and (3) Determining the network path.

Validating Network Services. To validate network service, we need to do two things. First, we must be sure that clients have or are getting an IP address, subnet mask, default router address, and DNS server address. On a Windows® client, you can use the command line tool ipconfig to do this. If there isn't an IP address assigned to the client, it could be because there is a failure in the connection to the DHCP server. From the command line, you can issue the command ipconfig/release followed by ipconfig/renew. this will cause the client to initiate the four step process to obtain the configuration parameters from the DHCP server.

Using NETSCOUT OptiView, it's much easier to test DHCP and you get significantly more information. By placing the OptiView at the point of connection used by the client and starting it, the OptiView automatically does a Discovery process to find devices on the network. That process includes obtaining an address for the analyzer from DHCP as shown in Figure 21.

Figura 21. DHCP Response using OptiView

You can see that the test was successful and the OptiView received an IP address, subnet mask, default router and DNS server. From the Network Services test, you can see that the process to obtain an address took less than one second, a fact that isn't available from common line tools. A Network Port connection log provides the DHCP process steps to obtain the OptiView IP address.

The second thing we must test is DNS. To see whether a client can get names resolved we can again use two approaches. From the command line we can use nslookup.

The nslookup is a tool that is sometimes used to troubleshoot domain name servers. It's use is somewhat controversial because it is often used by hackers. It may not provide consistent results because name servers are often restricted from responding to nslookup queries. Yet, in competent hands that have good intentions, nslookup is helpful.

It can be used to do a general query in a domain and it can be used to specify a particular type of query. For example, if you type nslookup and hit enter you may receive a result such as is shown in Figure 22.

Figura 22. The nslookup Tool

The nslookup is a tool that tells us about servers, domains, and the addresses of the servers. Often, there are subcommands that allow querying about mail servers or exchange servers. Searching the Internet for descriptions will provide a great deal of information. An easier approach is to use the same screen that we used to test DHCP. In figure 23, we can see that the OptiView has been configured to resolve the name flukenetworks.com. The test was successful and IP address was returned in 2 ms.

Figura 23. DNS Test using OptiView

A test which we use less frequently is the reverse lookup. By submitting an IP address, the DNS server should return the corresponding server that uses that name. While the command line tool nslookup can be used, you can add a reverse name lookup to the OptiView by just entering the IP address in the screen that pops up when you select a DNS Server and click Add. This is shown in Figure 24.

Figura 24. Adding a Reverse using OptiView

Device Connectivity. The ping command is so widely used, that it has become part of our language. In networking, it has a very specific meaning. It is a small application that sends a query packet to a target device to see if the device will respond. For security reasons, the device is sometimes not allowed to respond.However, it remains the most widely used method of testing connectivity.

From most command prompts, you can execute the command ping x.x.x.x. This will cause your protocol stack to send a packet called an ICMP echo request to the address you listed as x.x.x.x. Some devices do not respond to pings and some firewalls block echo requests. But if your echo request survives the journey and reaches the target, the target device is likely to respond with another ICMP packet called an ICMP echo response. Network administrators use ping packets for many purposes. You do this by adding a switch which is similar to a subcommand. Among other things you can: see if a packet containing M bytes will get to the target (ping with — l M switch), ping continuously until interrupted (-t switch) and ping allowing up to N hops (ping — i N). You can see the first of these illustrated in Figure 25. The continuous ping is usually stopped with CNTL-C. While there are slight variations of the ping command across different operating systems, most support the usage described here.

Figura 25. Ping with Designated Payload

So, suppose we believe that we have a route that is dropping packets that are over 1000 bytes because the MTU isn't the standard value 1460. We can send a ping that specifies a payload of 900 bytes followed by a ping that specifies a payload of 1100 bytes. This will give us an indication. Keep in mind that this depends on the fact that nothing in the path is blocking ICMP packets for security reasons.

Ping connectivity tests are easy to configure and run in the OptiView. In Figure 26 you can see the screen that appears when you select a device on the Discovery screen and click on Device Detail. From here you can run ping tests and other tests that we will discuss later.

Figura 26. Using OptiView

If you want to change the payload, run the test more or less frequently, or limit the hop count, you can click on configure test.

Figura 27. Ping options

The result will be a report like the one in Figure 28 that tells us to how fast the response came back and whether any of the packets or responses were lost.

Figura 28. The Ping Report



Powered By OneLink