VMware vSphere 5 details leaked

VMware vSphere 5 will support up to 1 TB of RAM and 32 virtual CPUs per VM, according to a leaked document.

A posting entitled “What’s new in vSphere 5.0” appeared last Friday in a Turkish Web forum, with details on the next major release of VMware’s server virtualization platform.

The public posting about vSphere 5, which appears to have been copied and pasted from a typical VMware “What’s New” page accessible only to authorized users, also suggests that a release candidate hit the market March 31, judging by captured metadata code.

John Troyer, VMware’s senior social media specialist, responded to tweets calling attention to the posting with a request that they be taken down, saying, “That info is still confidential!” His posting has since been removed, as has the posting with the vSphere 5 details.

New scalability, Auto-Deploy feature
Among the enhancements detailed in the document is support for still larger virtual machines (VMs) than were supported in vSphere 4.0 and 4.1 -- up to 32 virtual CPUs per VM, up to 1 TB of RAM per VM, and a new graphical user interface to support provisioning multicore CPUs.

Another reported vSphere 5 feature is VMware vSphere Auto Deploy, which combines features from host profiles, Image Builder and PXE. The feature will “[simplify] the task of managing ESXi installation and upgrade for hundreds of machines,” according to the document. With this feature, new hosts can be automatically provisioned based on user-defined rules, and “rebuilding a server to a clean slate is as simple as a reboot.”

It also appears VMware has overhauled VMware High Availability (HA). “VMware HA is more reliable in operation, more scalable in its ability to protect virtual machines, and can provide better uptime than before,” the document says. It also mentions that all hosts in the cluster can be primary nodes (active-active failover), and the cluster can use shared storage for host heartbeat detection.

Storage integration to deepen through new APIs
As previewed at the VMware Partner Exchange 2011 conference in February, vSphere 5 will also offer a feature called Storage Distributed Resource Scheduling, or Storage DRS, which would allow virtual machine disk format files to be automatically moved between RAID groups as well as separate storage arrays, depending on resource availability.

New details about storage integration in the leaked document also include a category called “policy-driven storage delivery,” which appears to be the incarnation of new application programming interfaces (APIs) extended to storage partners, previously known as VMware-Aware Storage APIs. Policy-driven storage delivery “enables virtual machine storage provisioning to become independent of specific storage available in the environment,” according to the document.

Other storage integration updates include a new version of the VMware Cluster File System, with improved scalability and performance. That could be achieved -- at least in part -- by adding finer-grained SCSI locking controls. This is an area in which VMware and storage vendors have been honing performance for at least the last three platform releases, and previous efforts have included the offloading of SCSI lock management to the array through the VMware vStorage APIs for Array Integration released with vSphere 4.1.

As is its custom, VMware is also adding support for existing features to new storage protocols following a first release that focused mainly on Fibre Channel block storage. This release contains a new UI for managing iSCSI storage through the vSphere Client and support for Storage I/O control on Network File System storage volumes.

Another detail mentioned in the document is new support for LUNs greater than 2 TB. Brandon Worrell, director of business development for VMware partner Solutions-II in Salt Lake City, Utah, said his customers have been looking for this feature.

“We have some customers with petabytes and petabytes of info, and having to carve everything up in 2-TB chunks is a pain,” he said prior to the vSphere 5 documentation leak.

Network I/O control, virtual firewall updates
As with storage management, vSphere 5 users will reportedly be able to establish networking resource pools according to pre-defined rules. The new version will also enable multi-tenancy deployment, and will bridge physical and virtual QoS by complying with a new IEEE 802.1 VLAN tagging standard.

And when it comes to the vSphere 5 version of VMware’s virtual firewall, the management interface will now be “protected by a service-oriented and stateless firewall, which [users] can configure using the vSphere Client or at the command line.” This could potentially address issues of vShield management interface availability, which have been raised by some evaluators of the 1.0 product.

“VShield … needs to be fully developed and easy to implement, [with] best practices defined,” said the CIO of a state government agency on the East Coast. “Right now it seems that third party-vendors like Altor Networks have more mature solutions … but I think in a year or two, we will wonder how we survived without it.”

VSphere’s command line interface also appears to be getting an update, in the form of a unified CLI framework. This will bring together esxcli and PowerCLI, allowing “consistency of authentication, roles, and auditing, using the same methods as other management frameworks.” It is unclear whether this update will address market concerns relating to the transition from PowerCLI version 4.0 to version 4.1.x.

VCenter Server gets a facelift
Finally, the vSphere management server for deployments itself will be getting an update, including a new browser-based vSphere Client; a new preconfigured vCenter Server appliance; the ability to deploy new management extensions created by VMware partners; and enhanced logging support.

Matthew Liebowitz, a solutions architect for Manhattan-based VAR Kraft and Kennedy Inc., said he hopes there will be improvements to the native availability of vCenter Server itself as VMware builds more features into vCenter.

“It used to be that if vCenter went down, you couldn’t do vMotion, but that was pretty much the worst of it,” Liebowitz said. “Now look at all the pieces that are integrated: distributed vSwitches, the vShield products, VMware View, Site Recovery Manager, CapacityIQ, AppSpeed, vCloud. … VMware sells their vCenter Heartbeat product that is pretty expensive and can protect vCenter, and I think folks will be almost forced into buying it. There is too much relying on vCenter these days to simply rely on VMware HA … to protect it.”

Another detail revealed in the leaked documentation is that Apple OS X is now supported as a guest OS. Phil DeMeyer , an information technologist at an early-childhood education program in the Midwest, said he’d like to see a Mac version of the vSphere Client as well.

“The thing I’m kind of intrigued with is their new iPad app for vCenter,” DeMeyer said. “I thought that that was interesting. In lieu of a Mac client … that would be nice.”

VMware vSphere 5 licensing concerns
Worrell said he still has customers that remember that bought Virtual Infrastructure 3 just before VMware released vSphere 4.

“[They] thought they were buying the most recent, updated version, only to find out a few months later that something new came out,” he said.

That remains a lingering sore subject for some users, as does the addition of the Enterprise Plus licensing tier.

“Two-plus years later, there are still customers that are unhappy about this,” Worrell said.

There haven’t been any indications of licensing changes with vSphere 5, and Worrell and others said they hope it stays that way.

“Licensing is still way too painful,” said the government CIO on the East Coast. “That and cost are the only reasons I would look at Hyper-V.”

Comparing Hyper-V R2, vSphere and XenServer 5.5 pros and cons

When comparing Hyper-V R2, vSphere and XenServer 5.5 pros and cons, customers are often confused about which option is best. Solutions providers will find that their customers' ignorance serves as a valuable opportunity to seal new business deals. The virtualization market is very competitive, and knowing about the big players in this segment will give you a key advantage over other solutions providers. In this tip, you'll learn about the various features included in Microsoft's Hyper-V R2, VMware Inc.'s vSphere and Citrix Systems Inc.'s XenServer 5.5, and how each product can impact a customer's virtual environment.

VMware vSphere pros

• Broadest vendor support: When it comes to virtualizing applications, customers need to choose an option that will be supported by the largest number of software programs and systems. VMware's market-leading position gives customers the most options when it comes to building virtualized environments that will have the most support.
• Most features: The vSphere series of products, in particularvCenter Server, allow solutions providers to design highly-available infrastructures with advanced management features. ESX, ESXi, vCenter Server and other VMware products apply not only to enterprises, but to smaller organizations as well that need high-performance and enterprise-class features for virtualization compnents.
• High entry costs: Along with a wide array of features, vSphere also comes with a high price tag for initial purchases. Simply comparing per-processor costs of core virtualization components, vSphere is more expensive at face value than its competitors' products. All virtualization providers contentiously argue the price and return on investment (ROI) factors of virtualization. Be sure to check out the VMware Cost-Per-Application calculator, Microsoft virtualization cost comparison calculator and the Citrix ROI demonstration tool.
• Hardware incompatibility: While the vSphere Compatibility Matrix continues to expand, other virtualization offerings have broader hardware support. Microsoft virtualization has the broadest supported device inventory.

Microsoft Hyper-V R2 pros

• Familiar interface: Some customers prefer using products from just one vendor, and Hyper-V virtualization is a more natural transition from Windows server environments. The virtualization management engine with System Center adds features for customers in a simple tiered approach, from the application to the OS, and lastly, to the virtualization engine. For organizations that have a large investment in other System Center technologies, such as Operations Manager, System Center Virtual Machine Manager for Hyper-V may be a natural addition.
• Broad hardware compatibility: Being part of Windows Server 2008 R2, Hyper-V R2 benefits by having the same driver support. While VMware is expanding its product line and has also added the new pluggable storage architecture, Windows device support can't be beat.
• Integration with existing virtualization infrastructure: Customers want to capitalize on existing investments. Most environments have some level of Microsoft Windows Server investment, and expanding that investment to include Hyper-V may be attractive.

Microsoft Hyper-V R2 cons

• Less vendor support: For software publishers that do have virtualization support, Hyper-V R2 is not frequently listed as one of the products they support. While virtualization support is determined by a number of factors, Hyper-V isn't the most supported hypervisor for third-party applications.
• Features gap: Hyper-V virtualization goes deeper with some features, such as alert management and monitoring within the guest virtual machine's OS with System Center Operations Manager and integration with Group Policy. VSphere has more virtualization-specific features that are more important to infrastructure architects. Hyper-V does not yet offer a fault tolerance virtual machine (VM) that runs concurrently on two hosts, and it has fewer virtualization-specific disaster recovery options than vSphere.

Citrix XenServer 5.5 pros

• Strongest free virtualization offering: Citrix XenServer 5.5 offers the best free virtualization suite, which includes live migration, physical server to virtual machine (P2V) conversions and virtual-to-virtual (V2V) conversions, shared storage driver integration, centralized management, Active Directory integrated security, VM template functionality and infrastructure update management. Citrix Essentials has additional features for customers and is a modestly priced automation and management package.
• Enterprise ready: Citrix XenServer (along with VMware's vSphere) meets the Burton Group's criteria for enterprise production virtualization workloads. The Xen hypervisor also has an active open source community for organizations that wish to produce their own virtualization solutions.

Citrix XenServer 5.5 cons

• Most limited application and vendor support: While VMware has broad virtualization support in the application world, customers may face vendor support issues when moving critical systems to a Xen-based virtualization environment.
• Limited partner support: The Citrix offering has the most limited software partner product support of the three platforms. VMware-based virtualization has the largest level of partner support for products in areas such as backup and recovery, capacity planning, lifecycle management and infrastructure.

Are pros and cons enough?

When comparing Hyper-V R2, vSphere and XenServer 5.5 pros and cons, you'll find that there is no one-size-fits-all virtualization product or service. Each product can present customers with many advantages and disadvantages depending on their current environment and needs. From the customers' perspective, virtualization must be an investment that fits with their overall IT goals and architecture. The aggregation of infrastructure components that virtualization brings to the table requires customers to choose wisely about which investments to make.

TCP-IP Command Line Utilities:

This section covers:

• Viewing configuration by using ipconfig /all
• Viewing configuration by using the Status feature
• Refreshing configuration by using ipconfig /renew
• Managing DNS and DHCP class IDs by using ipconfig
• Testing connections by using ping
• Troubleshooting hardware addresses by using arp
• Troubleshooting NetBIOS names by using nbstat
• Displaying connection statistics by using netstat
• Tracing network connections by using tracert
• Testing routers by using pathping

Viewing configuration by using ipconfig /all

When you troubleshoot a TCP/IP networking problem, begin by checking the TCP/IP configuration on the computer that is experiencing the problem. You can use the ipconfig command to get host computer configuration information, including the IP address, subnet mask, and default gateway.

Note

• For clients running Windows 95, Windows 98, and Windows Millennium Edition, use the winipcfg command instead of ipconfig.

When you use the ipconfig command with the /all option, a detailed configuration report is produced for all interfaces, including any configured serial ports. With ipconfig /all, you can redirect command output to a file and paste the output into other documents. You can also use this output to confirm the TCP/IP configuration of each computer on the network or to further investigate TCP/IP network problems.

For example, if a computer is configured with an IP address that is a duplicate of an existing IP address, the subnet mask appears as 0.0.0.0.

The following example shows the output of the ipconfig /all command on a computer that running Windows XP Professional and is configured to use the DHCP server for automatic TCP/IP configuration, and WINS and DNS servers for name resolution.

 IP Configuration

        Node Type . . . . . . . . . : Hybrid

        IP Routing Enabled. . . . . : No

        WINS proxy Enabled. . . . . : No

Ethernet adapter Local Area Connection:

        Host Name . . . . . . . . . : client1.microsoft.com

        DNS Servers . . . . . . . . : 10.1.0.200

        Description . . . . . . . . : 3Com 3C90x Ethernet Adapter

        Physical Address. . . . . . : 00-60-08-3E-46-07

        DHCP Enabled. . . . . . . . : Yes

        Autoconfiguration Enabled . : Yes

        IP Address. . . . . . . . . : 192.168.0.112

        Subnet Mask . . . . . . . . : 255.255.0.0

        Default Gateway . . . . . . : 192.168.0.1

        DHCP Server . . . . . . . . : 10.1.0.50

        Primary WINS Server . . . . : 10.1.0.101

        Secondary WINS Server . . . : 10.1.0.102

        Lease Obtained. . . . . . . : Wednesday, September 02, 1998 10:32:13 AM

        Lease Expires . . . . . . . : Friday, September 18, 1998 10:32:13 AM

If no problems appear in the TCP/IP configuration, the next step is testing the ability to connect to other host computers on the TCP/IP network.

Viewing configuration by using the Status feature

An alternate method of viewing configuration is available through the Status feature of a network connection. For more information, see View the status of a local area connection.

Refreshing configuration by using ipconfig /renew

When you troubleshoot a TCP/IP networking problem, begin by checking the TCP/IP configuration on the computer that is experiencing the problem. If the computer is DHCP-enabled and is using a DHCP server to obtain configuration, you can initiate a refresh of the lease by using the ipconfig /renew command.

When you use ipconfig /renew, all network adapters on the computer that uses DHCP (except those that are manually configured) try to contact a DHCP server and renew their existing configuration or obtain a new configuration.

You can also use the ipconfig command with the /release option to immediately release the current DHCP configuration for a host.

Note

• For Windows 95, Windows 98, and Windows Millennium Edition DHCP-enabled clients, use the release and renew options of the winipcfg command instead of ipconfig /release and ipconfig /renew to perform manual release or renewal of the IP configuration lease for a client.

Repair feature

As an alternative to ipconfig you can use Repair to renew LAN or high-speed Internet connection IP settings. Repair performs a series of commands that repair a connection. The commands that are invoked by Repair are listed below with their command-line equivalents:

Repair	Command-line equivalent
Checks whether DHCP is enabled and, if enabled, issues a broadcast renew to refresh the IP address	No command line equivalent available
Flushes the ARP cache	arp -d *
Flush the NetBIOS cache	nbtstat -R
Flushes the DNS cache	ipconfig /flushdns
Re-registers with WINS	nbtstat -RR
Re-registers with DNS	ipconfig /registerdns

Important

• Repair uses a broadcast renew and will cause a computer to accept any lease from any DHCP server that is on the network. In contrast, a unicast renew (ipconfig /renew) will only renew the existing lease from the last DHCP server from which the client got a lease.

For more information, see Repair a LAN or high-speed Internet connection.

Managing DNS and DHCP class IDs by using ipconfig

You can also use the ipconfig command to:

• Display or reset the DNS cache.
  
  For more information, see Flush and reset a client resolver cache using the ipconfig command.
• Refresh registered DNS names.
  
  For more information, see Renew DNS client registration using the ipconfig command.
• Display the DHCP class IDs for an adapter.
  
  For more information, see Show DHCP class ID information at a client computer.
• Set the DHCP class IDs for an adapter.
  
  For more information, see Set DHCP class ID information at a client computer.

Testing connections by using ping

The ping command helps to verify IP-level connectivity. When troubleshooting, you can use ping to send an ICMP echo request to a target host name or IP address. Use ping whenever you need to verify that a host computer can connect to the TCP/IP network and network resources. You can also use ping to isolate network hardware problems and incompatible configurations.

It is usually best to verify that a route exists between the local computer and a network host by first using the ping command and the IP address of the network host to which you want to connect. Try pinging the IP address of the target host to see if it responds, as follows:

ping IP_address

You should perform the following steps when using ping:

Ping the loopback address to verify that TCP/IP is configured correctly on the local computer.

ping 127.0.0.1

Ping the IP address of the local computer to verify that it was added to the network correctly.

pingIP_address_of_local_host

Ping the IP address of the default gateway to verify that the default gateway is functioning and that you can communicate with a local host on the local network.

pingIP_address_of_default_gateway

Ping the IP address of a remote host to verify that you can communicate through a router.

pingIP_address_of_remote_host

The ping command uses Windows Sockets-style name resolution to resolve a computer name to an IP address, so if pinging by address succeeds, but pinging by name fails, then the problem lies in address or name resolution, not network connectivity. For more information, see Troubleshooting hardware addresses by using arp.

If you cannot use ping successfully at any point, confirm that:

• The computer was restarted after TCP/IP was configured.
• The IP address of the local computer is valid and appears correctly on the General tab of the Internet protocol (TCP/IP) properties dialog box.
• IP routing is enabled and the link between routers is operational.

You can use different options with the ping command to specify the size of packets to use, how many packets to send, whether to record the route used, what Time-to-Live (TTL) value to use, and whether to set the "don't fragment" flag. You can type ping -? to see these options.

The following example illustrates how to send two pings, each 1,450 bytes in size, to IP address 131.107.8.1:

C:\>ping -n 2 -l 1450 131.107.8.1

Pinging 131.107.8.1 with 1450 bytes of data:

Reply from 131.107.8.1: bytes=1450 time<10ms ttl="32

Reply from 131.107.8.1: bytes=1450 time<10ms ttl="32

Ping statistics for 131.107.8.1:

    Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),

Approximate roundtrip times in milliseconds:

    Minimum = 0ms, Maximum =  10ms, Average =  2ms

By default, ping waits 4,000 milliseconds (4 seconds) for each response to be returned before displaying the "Request Timed Out" message. If the remote system being pinged is across a high-delay link, such as a satellite link, responses may take longer to be returned. You can use the -w (wait) option to specify a longer time-out.

Troubleshooting hardware addresses by using arp

The Address Resolution protocol (ARP) allows a host to find the media access control address of a host on the same physical network, given the IP address of the host. To make ARP efficient, each computer caches IP-to-media access control address mappings to eliminate repetitive ARP broadcast requests.

You can use the arp command to view and modify the ARP table entries on the local computer. The arp command is useful for viewing the ARP cache and resolving address resolution problems.

For more information, see View the Address Resolution Protocol (ARP) cache and Add a static ARP cache entry.

Troubleshooting NetBIOS names by using nbtstat

NetBIOS over TCP/IP (NetBT) resolves NetBIOS names to IP addresses. TCP/IP provides many options for NetBIOS name resolution, including local cache lookup, WINS server query, broadcast, DNS server query, and Lmhosts and Hosts file lookup.

Nbtstat is a useful tool for troubleshooting NetBIOS name resolution problems. You can use the nbtstat command to remove or correct preloaded entries:

• nbtstat -n displays the names that were registered locally on the system by programs such as the server and redirector.
• nbtstat -c shows the NetBIOS name cache, which contains name-to-address mappings for other computers.
• nbtstat -R purges the name cache and reloads it from the Lmhosts file.
• nbtstat -RR releases NetBIOS names registered with a WINS server and then renews their registration.
• nbtstat -a name performs a NetBIOS adapter status command against the computer specified by name. The adapter status command returns the local NetBIOS name table for that computer plus the media access control address of the adapter.
• nbtstat -S lists the current NetBIOS sessions and their status, including statistics, as shown in the following example:
  
  
  

NetBIOS connection table

Local name State     In/out Remote Host    Input   Output

------------------------------------------------------------------

CORP1 <00> Connected Out    CORPSUP1<20>   6MB     5MB

CORP1 <00> Connected Out    CORPPRINT<20>  108KB   116KB

CORP1 <00> Connected Out    CORPSRC1<20>   299KB   19KB

CORP1 <00> Connected Out    CORPEMAIL1<20> 324KB   19KB

CORP1 <03> Listening

Displaying connection statistics by using netstat

You can use the netstat command to display protocol statistics and current TCP/IP connections. The netstat -a command displays all connections, and netstat -r displays the route table plus active connections. The netstat -o command displays process IDs so you can view the owner of the port for each connection. The netstat -e command displays Ethernet statistics, and netstat -s displays per-protocol statistics. If you use netstat -n, addresses and port numbers are not converted to names. The following shows sample output for netstat:

C:\>netstat -e

Interface Statistics

                       Received      Sent

Bytes                  3995837940    47224622

Unicast packets        120099        131015

Non-unicast packets    7579544       3823

Discards               0             0

Errors                 0             0

Unknown protocols      363054211

C:\>netstat -n -o

Active Connections

  proto  Local Address          Foreign Address        State           PID

  TCP    172.31.71.152:1136     157.54.2.84:389        CLOSE_WAIT      180

  TCP    172.31.71.152:2730     172.31.71.99:139       ESTABLISHED     4

  TCP    172.31.71.152:3110     157.54.2.84:389        CLOSE_WAIT      364

  TCP    172.31.71.152:3796     172.30.236.233:1479    ESTABLISHED     1128

  TCP    172.31.71.152:3800     172.30.236.233:1740    ESTABLISHED     1128

  TCP    172.31.71.152:3815     172.30.236.233:1479    ESTABLISHED     908

  TCP    172.31.71.152:3819     172.30.236.233:1740    ESTABLISHED     908

  TCP    172.31.71.152:4034     172.31.16.197:139      TIME_WAIT       0

  TCP    172.31.71.152:4037     157.54.4.183:445       TIME_WAIT       0

  TCP    172.31.71.152:4043     157.60.218.11:119      TIME_WAIT       0

  TCP    172.31.71.152:4044     157.60.218.11:119      TIME_WAIT       0

  TCP    172.31.71.152:4045     157.60.218.11:119      TIME_WAIT       0

  TCP    172.31.71.152:4046     157.60.218.11:119      TIME_WAIT       0

  TCP    172.31.71.152:4047     157.60.218.11:119      TIME_WAIT       0

  TCP    172.31.71.152:4048     157.60.218.11:119      TIME_WAIT       0

  TCP    172.31.71.152:4049     157.60.218.11:119      TIME_WAIT       0

  TCP    172.31.71.152:4050     157.60.218.11:119      TIME_WAIT       0

C:\>netstat -a

Active Connections

 proto Local Address      Foreign Address       State

 TCP  CORP1:1572       172.16.48.10:nbsession   ESTABLISHED

 TCP  CORP1:1589       172.16.48.10:nbsession   ESTABLISHED

 TCP  CORP1:1606       172.16.105.245:nbsession ESTABLISHED

 TCP  CORP1:1632       172.16.48.213:nbsession  ESTABLISHED

 TCP  CORP1:1659       172.16.48.169:nbsession  ESTABLISHED

 TCP  CORP1:1714       172.16.48.203:nbsession  ESTABLISHED

 TCP  CORP1:1719       172.16.48.36:nbsession   ESTABLISHED

 TCP  CORP1:1241       172.16.48.101:nbsession  ESTABLISHED

 UDP  CORP1:1025       *:*

 UDP  CORP1:snmp       *:*

 UDP  CORP1:nbname     *:*

 UDP  CORP1:nbdatagram *:*

 UDP  CORP1:nbname     *:*

 UDP  CORP1:nbdatagram *:*

C:\>netstat -s

IP Statistics

 Packets Received             = 5378528

 Received Header Errors       = 738854

 Received Address Errors      = 23150

 Datagrams Forwarded          = 0

 Unknown protocols Received   = 0

 Received Packets Discarded   = 0

 Received Packets Delivered   = 4616524

 Output Requests              = 132702

 Routing Discards             = 157

 Discarded Output Packets     = 0

 Output Packet No Route       = 0

 Reassembly Required          = 0

 Reassembly Successful             = 0

 Reassembly Failures               = 0

 Datagrams Successfully Fragmented = 0

 Datagrams Failing Fragmentation   = 0

 Fragments Created                 = 0

ICMP Statistics

                          Received  Sent

 Messages                 693       4

 Errors                   0         0

 Destination Unreachable  685       0

 Time Exceeded            0         0

 Parameter problems       0         0

 Source Quenches          0         0

 Redirects                0         0

 Echoes                   4         0

 Echo Replies             0         4

 Timestamps               0         0

 Timestamp Replies        0         0

 Address Masks            0         0

 Address Mask Replies     0         0

TCP Statistics

 Active Opens                 = 597

 Passive Opens                = 135

 Failed Connection Attempts   = 107

 Reset Connections            = 91

 Current Connections          = 8

 Segments Received            = 106770

 Segments Sent                = 118431

 Segments Retransmitted       = 461

UDP Statistics

 Datagrams Received   = 4157136

 No Ports             = 351928

 Receive Errors       = 2

 Datagrams Sent       = 13809

Tracing network connections by using tracert

Tracert (Trace Route) is a route-tracing utility that is used to determine the path that an IP datagram takes to reach a destination. The tracert command uses the IP Time-to-Live (TTL) field and ICMP error messages to determine the route from one host to another through a network.

How tracert works

The Tracert diagnostic utility determines the route taken to a destination by sending Internet Control Message protocol (ICMP) echo packets with varying IP Time-to-Live (TTL) values to the destination. Each router along the path is required to decrement the TTL on a packet by at least 1 before forwarding it. When the TTL on a packet reaches 0, the router should send an "ICMP Time Exceeded" message back to the source computer.

Tracert determines the route by sending the first echo packet with a TTL of 1 and incrementing the TTL by 1 on each subsequent transmission until the target responds or the maximum TTL is reached. The route is determined by examining the "ICMP Time Exceeded" messages sent back by intermediate routers. Some routers silently drop packets with expired TTLs and are invisible to the Tracert utility.

The tracert command prints out an ordered list of the near-side interface of the routers in the path that returned the "ICMP Time Exceeded" message. If the -d option is used, the Tracert utility does not perform a DNS lookup on each IP address.

In the following example, the packet must travel through two routers (10.0.0.1 and 192.168.0.1) to get to host 172.16.0.99. The default gateway of the host is 10.0.0.1 and the IP address of the router on the 192.168.0.0 network is 192.168.0.1.

C:\>tracert 172.16.0.99 -d

Tracing route to 172.16.0.99 over a maximum of 30 hops

1     2 ms     3 ms     2 ms  10.0.0.1

2    75 ms    83 ms    88 ms  192.168.0.1

3    73 ms    79 ms    93 ms  172.16.0.99

Trace complete.

Troubleshooting with tracert

You can use the tracert command to determine where a packet stopped on the network. In the following example, the default gateway has determined that there is not a valid path for the host on 192.168.10.99. There is probably a router configuration problem or the 192.168.10.0 network does not exist (a bad IP address).

C:\>tracert 192.168.10.99

Tracing route to 192.168.10.99 over a maximum of 30 hops

1  10.0.0.1  reports: Destination net unreachable.

Trace complete.

The Tracert utility is useful for troubleshooting large networks where several paths can be taken to arrive at the same point.

Tracert command-line options

The tracert command supports several options, as shown in the following table.

tracert [-d] [-h maximum_hops] [-j host-list] [-w timeout] target_name

Option	Description
-d	Specifies that IP addresses are not resolved to host names.
-h maximum_hops	Specifies the number of hops to allow in tracing a route to the host named in target_name.
-j host-list	Specifies the list of router interfaces in the path taken by the Tracert utility packets.
-w timeout	Waits the number of milliseconds specified by timeout for each reply.
target_name	Name or IP address of the target host.

For more information, see Trace a path by using the tracert command.

Testing routers by using pathping

The pathping command is a route tracing tool that combines features of the ping and tracert commands with additional information that neither of those tools provides. The pathping command sends packets to each router on the way to a final destination over a period of time, and then computes results based on the packets returned from each hop. Since the command shows the degree of packet loss at any given router or link, it is easy to determine which routers or links might be causing network problems. A number of options are available, as shown in the following table.

Option	Name	Function
-n	Hostnames	Does not resolve addresses to host names.
-h	Maximum hops	Maximum number of hops to search for target.
-g	Host-list	Loose source route along host list.
-p	Period	Number of milliseconds to wait between pings.
-q	Num_queries	Number of queries per hop.
-w	Time-out	Waits this many milliseconds for each reply.
-i	address	Use the specified source address.
-4	IPv4	Force pathping to use IPv4.
-6	IPv6	Force pathping to use IPv6.

The default number of hops is 30, and the default wait time before a time-out is 3 seconds. The default period is 250 milliseconds, and the default number of queries to each router along the path is 100.

The following is a typical pathping report. The compiled statistics that follow the hop list indicate packet loss at each individual router.

D:\>pathping -n server1

Tracing route to server1 [10.54.1.196]

over a maximum of 30 hops:

  0  172.16.87.35

  1  172.16.87.218

  2  192.168.52.1

  3  192.168.80.1

  4  10.54.247.14

  5  10.54.1.196

Computing statistics for 125 seconds...

            Source to Here   This Node/Link

Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address

  0                                           172.16.87.35

                                0/ 100 =  0%   

  1   41ms     0/ 100 =  0%     0/ 100 =  0%  172.16.87.218

                               13/ 100 = 13%   

  2   22ms    16/ 100 = 16%     3/ 100 =  3%  192.168.52.1

                                0/ 100 =  0%   

  3   24ms    13/ 100 = 13%     0/ 100 =  0%  192.168.80.1

                                0/ 100 =  0%   

  4   21ms    14/ 100 = 14%     1/ 100 =  1%  10.54.247.14

                                0/ 100 =  0%   

  5   24ms    13/ 100 = 13%     0/ 100 =  0%  10.54.1.196

Trace complete.

When pathping is run, you first see the results for the route as it is tested for problems. This is the same path that is shown by the tracert command. The pathping command then displays a busy message for the next 125 seconds (this time varies by the hop count). During this time, pathping gathers information from all the routers previously listed and from the links between them. At the end of this period, it displays the test results.

The two rightmost columns--This Node/Link Lost/Sent=Pct and Address--contain the most useful information. The link between 172.16.87.218 (hop 1), and 192.168.52.1 (hop 2) is dropping 13 percent of the packets. All other links are working normally. The routers at hops 2 and 4 also drop packets addressed to them (as shown in the This Node/Link column), but this loss does not affect their forwarding path.

The loss rates displayed for the links (marked as a in the rightmost column) indicate losses of packets being forwarded along the path. This loss indicates link congestion. The loss rates displayed for routers (indicated by their IP addresses in the rightmost column) indicate that those routers' CPUs might be overloaded. These congested routers might also be a factor in end-to-end problems, especially if packets are forwarded by software routers.