Why does ping by name fail when ping by ip succeeds

This is a very common problem and is faced by many people all the time. The real question here is

why does ping by name fail when ping by ip succeeds?

The answer to this question is very simple. It lies within your ISP or routing device. There is a specific service that converts host name to IPs and vice versa. For example if you were to type a specific web address in the browser and the browser searches for the relavent IP address and locates the website for you.

Now the thing is that most of the internet routers didnt not allow inter-network ping command. The situation became critical when they actually needed ping command but did fail to do so. The issue of ping command failing with name but succeeding with ip address is the blockage of ping command parameter to use the dns service to locate the relavent ip address. So on the real problem lies with your routing device or ISP server. They may have blocked your transmission.

Another important issue in this regard is the permission problem. If you are using an access permission bbased operating system most notably Vista. You have an access problem. The easiest solution in Windos vista is to do the following for succeeding with ping command using hostname

Click Start
type cmd
At the top of the menu right click on cmd.exe and click Run as Administrator
In the command prompt, type ping google.com


You will be able to ping it. Pretty simple. If you are running linux, check your administrative privalages to use services and try again.

Pathping command is also helpful in this regard.
Check this
Ping command demystified
Pathping command

Difference between lserver and server in nslookup

There are little chores you'll come to use nslookup for almost every day: finding the IP address or MX records for a given domain name, or querying a particular name server for data. We'll cover these first, before moving on to the more occasional stuff.

12.5.1. Looking Up Different Record Types

By default, nslookup looks up the address for a domain name, or the domain name for an address. You can look up any record type by changing the querytype, as we show in this example:

% nslookup


Default Server:  terminator.movie.edu
Address:  0.0.0.0

> misery                  -- Look up address
Server:  terminator.movie.edu
Address:  0.0.0.0

Name:    misery.movie.edu
Address:  192.253.253.2

> 192.253.253.2           -- Look up domain name
Server:  terminator.movie.edu
Address:  0.0.0.0

Name:    misery.movie.edu
Address:  192.253.253.2

> set q=mx                -- Look up MX records
> wormhole
Server:  terminator.movie.edu
Address:  0.0.0.0

wormhole.movie.edu      preference = 10, mail exchanger = wormhole.movie.edu
wormhole.movie.edu      internet address = 192.249.249.1
wormhole.movie.edu      internet address = 192.253.253.1

> set q=any               -- Look up records of any type
> diehard
Server:  terminator.movie.edu
Address:  0.0.0.0

diehard.movie.edu       internet address = 192.249.249.4
diehard.movie.edu       preference = 10, mail exchanger = diehard.movie.edu
diehard.movie.edu       internet address = 192.249.249.4

These are only a few of the valid DNS record types, of course. For a more complete list, see Appendix A, "DNS Message Format and Resource Records".

12.5.2. Authoritative Versus Nonauthoritative Answers

If you've used nslookup before, you might have noticed something peculiar -- the first time you look up a remote domain name, the answer is authoritative, but the second time you look up the same name it is nonauthoritative. Here's an example:

% nslookup
Default Server:  relay.hp.com
Address:  15.255.152.2

> slate.mines.colorado.edu.
Server:  relay.hp.com
Address:  15.255.152.2

Name:     slate.mines.colorado.edu
Address:  138.67.1.3

> slate.mines.colorado.edu.
Server:  relay.hp.com
Address:  15.255.152.2

Non-authoritative answer:
Name:    slate.mines.colorado.edu
Address:  138.67.1.3

While this looks odd, it really isn't. What's happening here is that the first time the local name server looks up slate.mines.colorado.edu, it contacts the name server for mines.colorado.edu, and the mines.colorado.edu server then responds with an authoritative answer. The local name server, in effect, passes the authoritative response directly back to nslookup. It also caches the response. The second time you look up slate.mines.colorado.edu, the name server answers out of its cache, which results in the answer "non-authoritative." [96]

[96]BIND 9 name servers, interestingly, show even the first responses as nonauthoritative.

Notice that we terminated the domain name with a trailing dot each time we looked it up. The response would have been the same if we'd left the trailing dot off. There are times when it's critical that you use the trailing dot while debugging, and times when it's not. Rather than stopping to decide if this name needs a trailing dot, we always add one if we know the name is fully qualified, except, of course, if we've turned off the search list.

12.5.3. Switching Name Servers

Sometimes you want to query another name server directly -- you may think it is misbehaving, for example. You can switch servers with nslookup by using the server or lserver command. The difference between server and lserver is that lserver queries your "local" name server -- the one you started out with -- to get the address of the server you want to switch to; server uses the default name server instead of the local server. This difference is important because the server you just switched to may not be responding, as we'll show in this example:

% nslookup
Default Server:  relay.hp.com
Address:  15.255.152.2

When we start up, our first name server, relay.hp.com, becomes our lserver. This will matter later on in this session.

> server galt.cs.purdue.edu.
Default Server:  galt.cs.purdue.edu
Address:  128.10.2.39

> cs.purdue.edu.
Server:  galt.cs.purdue.edu
Address:  128.10.2.39

*** galt.cs.purdue.edu can't find cs.purdue.edu.: No response from server

At this point, we try to switch back to our original name server. But there is no name server running on galt.cs.purdue.edu to look up relay.hp.com's address:

> server relay.hp.com.

*** Can't find address for server relay.hp.com.: No response from server

Instead of being stuck, though, we use the lserver command to have our local name server look up relay.hp.com's address:

> lserver relay.hp.com.
Default Server:  relay.hp.com
Address:  15.255.152.2

> ^D

Since the name server on galt.cs.purdue.edu did not respond -- that host isn't even running a name server -- it wasn't possible to look up the address of relay.hp.com to switch back to using relay 's name server. Here's where lserver comes to the rescue: the local name server, relay, was still responding, so we used it. Instead of using lserver, we also could have recovered by using relay's IP address directly -- server 15.255.152.2.

You can even change servers on a per-query basis. To specify that you'd like nslookup to query a particular name server for information about a given domain name, you can specify the server as the second argument on the line, after the domain name to look up, like so:

% nslookup
Default Server:  relay.hp.com
Address:  15.255.152.2

> saturn.sun.com. ns.sun.com.
Name Server:  ns.sun.com
Address:  192.9.9.3

Name:    saturn.sun.com
Addresses: 192.9.25.2

> ^D

And, of course, you can change servers from the command line. You can specify the server to query as the argument after the domain name to look up, like this:

% nslookup -type=mx fisherking.movie.edu. terminator.movie.edu.

This instructs nslookup to query terminator.movie.edu for MX records for fisherking.movie.edu.

Finally, to specify an alternate default name server and enter interactive mode, you can use a hyphen in place of the domain name to look up:

% nslookup - terminator.movie.edu.

See Also: NsLookup ommand explained in detailOriginal Article Source Here

There are little chores you'll come to use nslookup for almost every day: finding the IP address or MX records for a given domain name, or querying a particular name server for data. We'll cover these first, before moving on to the more occasional stuff.

12.5.1. Looking Up Different Record Types

By default, nslookup looks up the address for a domain name, or the domain name for an address. You can look up any record type by changing the querytype, as we show in this example:

% nslookup
Default Server:  terminator.movie.edu
Address:  0.0.0.0

> misery                  -- Look up address
Server:  terminator.movie.edu
Address:  0.0.0.0

Name:    misery.movie.edu
Address:  192.253.253.2

> 192.253.253.2           -- Look up domain name
Server:  terminator.movie.edu
Address:  0.0.0.0

Name:    misery.movie.edu
Address:  192.253.253.2

> set q=mx                -- Look up MX records
> wormhole
Server:  terminator.movie.edu
Address:  0.0.0.0

wormhole.movie.edu      preference = 10, mail exchanger = wormhole.movie.edu
wormhole.movie.edu      internet address = 192.249.249.1
wormhole.movie.edu      internet address = 192.253.253.1

> set q=any               -- Look up records of any type
> diehard
Server:  terminator.movie.edu
Address:  0.0.0.0

diehard.movie.edu       internet address = 192.249.249.4
diehard.movie.edu       preference = 10, mail exchanger = diehard.movie.edu
diehard.movie.edu       internet address = 192.249.249.4

These are only a few of the valid DNS record types, of course. For a more complete list, see Appendix A, "DNS Message Format and Resource Records".

12.5.2. Authoritative Versus Nonauthoritative Answers

If you've used nslookup before, you might have noticed something peculiar -- the first time you look up a remote domain name, the answer is authoritative, but the second time you look up the same name it is nonauthoritative. Here's an example:

% nslookup
Default Server:  relay.hp.com
Address:  15.255.152.2

> slate.mines.colorado.edu.
Server:  relay.hp.com
Address:  15.255.152.2

Name:     slate.mines.colorado.edu
Address:  138.67.1.3

> slate.mines.colorado.edu.
Server:  relay.hp.com
Address:  15.255.152.2



Non-authoritative answer:
Name:    slate.mines.colorado.edu
Address:  138.67.1.3

While this looks odd, it really isn't. What's happening here is that the first time the local name server looks up slate.mines.colorado.edu, it contacts the name server for mines.colorado.edu, and the mines.colorado.edu server then responds with an authoritative answer. The local name server, in effect, passes the authoritative response directly back to nslookup. It also caches the response. The second time you look up slate.mines.colorado.edu, the name server answers out of its cache, which results in the answer "non-authoritative." [96]

[96]BIND 9 name servers, interestingly, show even the first responses as nonauthoritative.

Notice that we terminated the domain name with a trailing dot each time we looked it up. The response would have been the same if we'd left the trailing dot off. There are times when it's critical that you use the trailing dot while debugging, and times when it's not. Rather than stopping to decide if this name needs a trailing dot, we always add one if we know the name is fully qualified, except, of course, if we've turned off the search list.

12.5.3. Switching Name Servers

Sometimes you want to query another name server directly -- you may think it is misbehaving, for example. You can switch servers with nslookup by using the server or lserver command. The difference between server and lserver is that lserver queries your "local" name server -- the one you started out with -- to get the address of the server you want to switch to; server uses the default name server instead of the local server. This difference is important because the server you just switched to may not be responding, as we'll show in this example:

% nslookup
Default Server:  relay.hp.com
Address:  15.255.152.2

When we start up, our first name server, relay.hp.com, becomes our lserver. This will matter later on in this session.

> server galt.cs.purdue.edu.
Default Server:  galt.cs.purdue.edu
Address:  128.10.2.39

> cs.purdue.edu.
Server:  galt.cs.purdue.edu
Address:  128.10.2.39

*** galt.cs.purdue.edu can't find cs.purdue.edu.: No response from server

At this point, we try to switch back to our original name server. But there is no name server running on galt.cs.purdue.edu to look up relay.hp.com's address:

> server relay.hp.com.

*** Can't find address for server relay.hp.com.: No response from server

Instead of being stuck, though, we use the lserver command to have our local name server look up relay.hp.com's address:

> lserver relay.hp.com.
Default Server:  relay.hp.com
Address:  15.255.152.2

> ^D

Since the name server on galt.cs.purdue.edu did not respond -- that host isn't even running a name server -- it wasn't possible to look up the address of relay.hp.com to switch back to using relay 's name server. Here's where lserver comes to the rescue: the local name server, relay, was still responding, so we used it. Instead of using lserver, we also could have recovered by using relay's IP address directly -- server 15.255.152.2.

You can even change servers on a per-query basis. To specify that you'd like nslookup to query a particular name server for information about a given domain name, you can specify the server as the second argument on the line, after the domain name to look up, like so:

% nslookup
Default Server:  relay.hp.com
Address:  15.255.152.2

> saturn.sun.com. ns.sun.com.
Name Server:  ns.sun.com
Address:  192.9.9.3

Name:    saturn.sun.com
Addresses: 192.9.25.2

> ^D

And, of course, you can change servers from the command line. You can specify the server to query as the argument after the domain name to look up, like this:

% nslookup -type=mx fisherking.movie.edu. terminator.movie.edu.

This instructs nslookup to query terminator.movie.edu for MX records for fisherking.movie.edu.

Finally, to specify an alternate default name server and enter interactive mode, you can use a hyphen in place of the domain name to look up:

% nslookup - terminator.movie.edu.

How to run Pathping

Pathping is a TCP/IP based utility (command-line tool) that provides useful information about network latency and network loss at intermediate hops between a source address and a destination address. It does this by sending echo requests via ICMP and analyzing the results. ICMP stands for Internet Control Message Protocol. ICMP is an extension to the Internet Protocol (IP - part of the TCP/IP protocol suite) defined by RFC 792. ICMP supports packets containing error, control and informational messages. Pathping will send multiple echo request messages to each router between what you are attempting to ping – the source address. If your destination is across a WAN link then it’s certain that you will be using some form of router, most likely two, which would mean that you could test pathping across a two hop network – two router hops. A typical network diagram is seen in the following illustration.

Typical WAN

This is a typical WAN setup which shows you two sites that are connected via a T1 and an Integrated Services Digital Network (ISDN) link. What’s important to see here is that there are multiple paths throughout the network. There is a T1 and an ISDN link. Both technologies connect to each site. The T1 is the main link operating at 1.544 Mbps and the ISDN link is the back up in case the primary fails. Since ISDN is a technology that allows you to pay as you use it, it is a perfect technology to lay dormant until needed. It has less transmission speed (perhaps 64 Kbps), but at the same time, it’s only for emergency so it may be good enough for critical services. The bandwidth drop will add more time for packets to traverse the network and add latency or delay to the traffic. Latency is a measurement of how long it takes for a data packet to get from one point to another. Pathping is a good testing for this element. Latency can be measured by sending a packet as a test that will be returned back to the sender and from that time period - the round-trip time – that is what is considered the latency.

You can use a tool like pathping to see not only if your packets are making it across the network, but are taking the correct preferred path (the T1), or flowing over the alternate link (which would indicate a misconfiguration or a downed link) which is ISDN and, if you have bottlenecks on your network, to see if you have any latency issues. Lack of bandwidth and latency or delay may cause time out issues for your data transmissions. Using the pathping tool you can send multiple echo request messages to each router between you (the source) and your intended destination and after a specific amount of time has elapsed, computes the results from the data that it receives back from each router the packets traversed. Pathping will then display the results.

Syntax

To use pathping, you simply need to open a command prompt on the source system you will run the test from. If you want to use the next illustration as an example, adding an IP address will help you to perform the test. You can see that we have a test PC located at site B and the IP address is 10.1.2.4. This system wants to pathping to site A, a server with an IP address of 10.1.1.5.

Running pathping is easy. Open a command prompt (start -> run -> cmd -> pathping) and type pathping.

As listed here, you can see that the pathping command has many options to include

-n	Prevents pathping from attempting to resolve the IP addresses of intermediate routers to their names. You may want to consider doing this if you think you have a name resolution issue, or if DNS for example is not configured on your system … the time spent trying to contact a name server can be avoided using this switch.
-h	Specifies the maximum number of hops in the path to search for the target (destination). The default is 30 hops.
-p	Specifies the number of milliseconds to wait between consecutive pings. The default is 250 milliseconds (1/4 second).
-q	Specifies the number of Echo Request messages sent to each router in the path. The default is 100 queries.
-w	Specifies the number of milliseconds to wait for each reply. The default is 3000 milliseconds (3 seconds).
/?	Displays help at the command prompt

There are more options, but these are the most commonly used. You can use the help feature to learn more about the options as they are listed in the Windows command prompt.

To use pathping, launch the pathping command from the source to the destination and let pathping do its computation.

D:\>pathping -n server-1 Tracing route to server-1 [10.1.1.5] over a maximum of 30 hops: 0 10.1.2.1 1 10.1.1.1 2 10.1.1.5 Computing statistics for 50 seconds... Source to Here This Node/Link Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address 0 10.1.2.1 0/ 100 = 0% | 1 35ms 0/ 100 = 0% 0/ 100 = 0% 10.1.1.1 13/ 100 = 13% | 2 28ms 16/ 100 = 16% 3/ 100 = 3% 10.1.1.5 0/ 100 = 0% | Trace complete. (some output omitted)

Although in this example, I skimmed it down to the basics and omitted some of the text so we can look right at what we need to know – the statistics and how to read them. In this example, we see that there is a little latency on the second hop, which is 10.1.1.1, traversing the link to the next hop which is 10.1.1.5. In this section we see a small amount of latency which is normal for this size and speed link. If the milliseconds rate were at a very high number, such as 500 ms, then you might consider having a bandwidth issue. As you can see, pathping doesn’t only ‘verify’ connectivity to a destination host, but also, it shows you how your traffic is getting there, and how fast its going, how much resistance its encountering over the wide area network – which is a very common choke point.

Here is another example, but here, I am on a production network machine using pathping to test within a production LAN out to the Internet to a Web server.

When you run pathping, you will also have to be a little patient. Pathping will first display your results as if you were using tracert or traceroute, which is a similar utility to be covered in a separate article. Tracert will show you the ‘path’ through the network as well as verify connectivity but will not show you how the packet is traversing in relation to speed, bandwidth usage and latency. Next (and this is where patience sets in), depending on the hop count (how many router hops that need to be analyzed), check pathping’s results for the Lost/Sent = Pct and Address columns show that the links may either be over utilized (if you have a high drop rate) and so on. The loss rates displayed for the links, identified as a vertical bar (|) in the Address column, indicate link congestion that is causing the loss of packets that are being forwarded on the path. The loss rates displayed for routers (identified by their IP addresses) indicate that these routers may have a problem with overloading or saturation.

Note:
If you see the ‘*’ sign, don’t fret immediately – there may be a firewall blocking ICMP, so you may not get the response although the site is up and responsive. ACL (access control lists) and firewall rule-sets commonly throw off network testers because of this fact. Make sure you know the layout of your network if you are going to troubleshoot it and take this into consideration as it is commonly seen.

Summary

In this article we covered the basics of using pathping. Make sure you visit the links section to learn more about ICMP and how to use pathping. Stay tuned for more articles about how to troubleshoot your production networks!

Original Source Here

How to tell, what to do if computer is infected

Computer-virus infections don't cause your machine to crash anymore.

Nowadays, the criminals behind the infections usually want your computer operating in top form so you don't know something's wrong. That way, they can log your keystrokes and steal any passwords or credit-card numbers you enter at Web sites, or they can link your infected computer with others to send out spam.

Here are some signs your computer is infected, tapped to serve as part of "botnet" armies run by criminals:

• You experience new, prolonged slowdowns. This can be a sign that a malicious program is running in the background.

• You continually get pop-up ads that you can't make go away. This is a sure sign you have "adware," and possibly more, on your machine.

• You're being directed to sites you didn't intend to visit, or your search results are coming back funky. This is another sign that hackers have gotten to your machine.

So what do you do?

• Having anti-virus software here is hugely helpful. For one, it can identify known malicious programs and disable them. If the virus that has infected your machine isn't detected, many anti-virus vendors offer a service in which they can remotely take over your computer and delete the malware for a fee.

• Some anti-virus vendors also offer free, online virus-scanning services.

• You may have to reinstall your operating system if your computer is still experiencing problems. It's a good idea even if you believe you've cleaned up the mess because malware can still be hidden on your machine. You will need to back up your files before you do this.



How do I know what information has been taken?

• It's very hard to tell what's been taken. Not every infection steals your data. Some just serve unwanted ads. Others poison your search result or steer you to Web sites you don't want to see. Others log your every keystroke. The anti-virus vendors have extensive databases about what the known infections do and don't do. Comparing the results from your virus scans to those entries will give you a good idea about what criminals may have snatched up.

Original Source: YahooTech Here