Last Updated: June 1, 2011

Simple Diagnostics

Included in simple diagnostics are ping, tracert, pathping and nslookup commands that test basic connectivity to cloud servers and some well-known Web sites. Ping output captures the replies from a particular data center and other well-known Web sites.

Tracert performs trace routes to several popular Web sites, recording the path the message takes through each router the packet traverses on the way to its destination. If a packet is lost during routing, the Tracert output indicates where the packet is being dropped. Pathping traces the route and the reliability of communication links between the customer and a particular Microsoft data center. Pathping is similar to tracert, but also tracks the time between each hop, and the percentage of packets lost during transmission.

MOSDAL  also individually performs domain name resolution on several Microsoft online cloud servers and other popular Internet Web sites by using each on-premise DNS server. Web portals such as home.microsoftonline.com are queried and any DNS lookup failures will result in Microsoft Online Services connectivity issues.

The purpose of the simple diagnostics is to insure that the user’s system has basic connectivity to all front end servers in the Microsoft Online Services' environment. If any of the diagnostics in this section fail, it is likely that intermediate and advanced diagnostics will also fail.

PING Log Files

Among other collected data, the Network_Diagnostics folder in MOSDAL contains information on connectivity AND latency, either of which may be causing network connectivity issues.

A ping command takes a basic or rudimentary pulse of the ability to connect to the data center, similar to a doctor using a stethoscope to listen to a patient’s heartbeat. As any doctor knows, this does not provide any insight into the actual health of a patient; from a technical support perspective, a ping command does not describe the health of the server or the network. MOSDAL uses the ping command only to confirm basic network connectivity to the Internet and BPOS-S data centers.

For example, when a user is experiencing service connectivity issues, their ability to connect to echoVA3.microsoftonline.com (VA3 is the BPOS-S United States production data center) is the first item they should check to determine whether they are able to reach our servers. If they can successfully ping VA3, they can get to our data centers and the connectivity issue lies elsewhere.

The ping command can be used to check any Web address.

NOTE: MOSDAL is not necessary to test this connection; a ping command can be used as a substitute to test the connection. Regardless, testing whether a customer can ping echoVA3 validates whether our service is down or potentially identifies whether the customer may have another issue preventing the service client from connecting to the service. If the service is down, follow the Escalate to Development Hosting procedure.

Here are two examples of a ping file in MOSDAL, displaying a successful (Graphic 8) and unsuccessful (Graphic 9) ping of the echoWA4 data center (non-production).

MOSDAL_successful_ping.png

Graphic 8 – Successful ping command in MOSDAL.

MOSDAL_unsuccessful_ping.png

Graphic 9 – Unsuccessful ping command in MOSDAL.

MOSDAL always sends a small packet of data (32 bytes) to collect ping command data and the log file (identified by the word ping at the front of the log file) always contains the following information:

As shown in Graphic 8, the echoVA3.microsoftonline.com.txt log data can be analyzed using the following guidelines. The ping results should display log data similar to the following examples:

If the ping fails (Graphic 9), support engineers see one of the following four error messages when reviewing the log files:

If a customer cannot reach one of the Microsoft® Online Services (BPOS-S or Office 365) data centers and the information is confirmed by the ping log file, first check to see if there are any network outages reported. If not, the next step is using the pathping log files to provide additional insight in to potential issues that may be affecting network connectivity.

PATHPING Log Files

Check latency and intermittent router or communication link problems by using the following log file: pathping echoVA3.microsoftonline.com.txt (BPOS-S North American production data center). If the customer is an International customer, use echoIE2.microsoftonline.com (EMEA production) or echoSG1.microsoftonline.com (APAC production).

NOTE: Although these examples use the Microsoft Online Services’ (BPOS-S) North American data center, APAC, and EMEA data centers, the Office 365 data center or any common URL for a data center or website can be used for the pathping command.

Pathping is similar to ping in that it confirms not only the pulse of the patient, but also uses an algorithm to display vital information, such as the patient’s blood pressure and cholesterol levels. Much as a doctor uses this information to gain additional insight and detail into the patient’s health, the customer uses the information to look beyond just simply connecting to a data center or Web site.

The pathping command identifies not only the Microsoft® Online Services' (BPOS-S or Office 365) data center or server, but also the routers between the source and destination used to connect to the data center or server and whether or not the routers are dropping any of the data packets. Data packets may take different routes to their ultimate destination. Dropped data packets at the router leads to network latency. Pathping output is similar ping, but also includes information on packets lost while traveling to destination. This can be used to confirm whether or not customer is able to connect to our servers and what percentage of data being sent is actually lost in transit.

MOSDAL’s pathping log files identify the communication links between the routers and how well the routers are doing in cleanly routing test data packets. The pathping log files work best for network latency issues and identifying the routers (by name or IP address) in the middle before the packets reach their destination. The log files can also identify potential issues involving ISP routers, allowing the customer to contact them for resolving the issue.

The second section of the pathping log files displays any latency issues. As shown in Graphic 11, a vertical line identifies the connection between any two routers. If the router is down or disabled for ICMP replies, an asterisk is displayed in the first section of the pathping log files. The TRACERT command, which looks at public Web sites, can also be used to gather this output, but does not display any potential problem (data packet losses) on the communication links.

If there are communications issues, users will see a number larger than zero percent (0%). An extreme example would be to see the number 100, indicating that all, or 100 percent of the packets, are being lost in transit. Refer to Graphic 10 to see an example of Pathping output.

Once the first part is done, then the second piece is done to check speed and packet loss against the individual routers. Any speed calculated above 80ms confirms latency issues; a normal range for speed is considered to be between one and 25 milliseconds. Pathping and echo as examples for the latency scenario.

Interpreting a Successful PATHPING Command

MOSDAL pathping logs contain more info than simply pinging a destination, including the routers in the middle being hit by the packets as they travel to the data center. The first number is the user’s computer; in Graphic 10, this is 192.168.2.2. The last number is the name or IP address of the final destination; in Graphic 10, the final destination is Hop 19 (216.32.180.239).

Pathping1_NO_latency.png

Graphic 10 – Successful pathping command in MOSDAL – top portion of log file.

NOTE: Users can also use the TRACERT command for this output, but what if there is a problem (packet losses) on the communication link? (See Graphic 12)

The second section of the pathping log file shows latency issues. This section of the log files show whether each of the connections or routers between the originating computer and the final destination are responsible for dropping data packets. Vertical lines indicate a connection between two routers and if the router is down or disabled, an asterisk appears in the Hop column. Horizontal lines next to the Hop number indicate data loss.

Graphic 8 and Graphic 9 display the different components of the network connectivity log files, with no data loss. In Graphic 11, each of the data routing points is also identified by name or IP address; in this example, there are 19 data routing points.

NOTE: The first hop, labeled 0, is always the user’s computer. The final hop (in this example, 19) is always the final destination for the data packet.

Pathping2_NO_latency.png

Graphic 11 – Successful pathping command in MOSDAL – bottom portion of log file.

Note in Graphic 11 that each data routing point is receiving one hundred percent of the data sent, displayed as 0% in the log. Each of the data routing points is also identified by name or IP address.

Interpreting an Unsuccessful PATHPING Command

Pathping_latency_scenario.png
Graphic 12 – Unsuccessful pathping command in MOSDAL.

As shown in Graphic 12, not all of the data packets are being transmitted successfully, visually indicated by the dashes (-) in the RTT column for hops 8 through 15 (the graphic does not show all of the hops). When there are communications issues, users will see a percentage other than 0% (in this example, 100% is displayed for these hops). This could be related to any of the routers, slowing down the test data packet delivery. Depending upon how the pathping log files are read, the user should perform one of the following actions:

Within the Network Diagnostics, there are also log files called NetworkNSLookup (these are servers and the log file is shown in Graphic 13), which have their own config (.cfg) file. Whatever servers are mentioned in the config file are identified with the specific command, verifying whether the cloud servers are behaving properly. These servers can be modified.

Nslookup is a name lookup, basically saying: "Here is a name, what is the IP address?" Once the IP address is confirmed, the computers can begin talking. The first line is the internal DNS server; the second line is the IP address of the internal DNS server; the third line is the DNS server you asked for; the fourth line is the IP address.

nslookup_VA3.png

Graphic 13 – nslookup log file.

Check to see if the user's internal DSN servers can resolve the names properly, which can help address the following questions:

  1. What if their internal DNS server is down?
  2. What if the internal DNS server is corrupted?
  3. What if the DNS server is caching some old server addresses?

The internal DNS server may say one thing, but MOSDAL might say something different. In this scenario, the user can use www.dnsstuff.com to double-check (or resolve) whether the server address is correct.