ping uses localhost instead of public IP
lets say my server has IP address 11.22.33.44 and hostname server1.mydomain.com.
when I ping server1.mydomain.com, it looks as if ping is actually using the public IP address:
# ping server1.mydomain.com
PING server1.mydomain.com (11.22.33.44) 56(84) bytes of data.
64 bytes from server1.mydomain.com (11.22.33.44): icmp_seq=1 ttl=64 time=0.014 ms
64 bytes from server1.mydomain.com (11.22.33.44): icmp_seq=2 ttl=64 time=0.012 ms
64 bytes from server1.mydomain.com (11.22.33.44): icmp_seq=3 ttl=64 time=0.011 ms
but with tcpdump, I can see no ICMP traffic on eth0, and instead see the pings comming through lo:
# tcpdump -i lo
listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
08:43:49.076918 IP server1.mydomain.com > server1.mydomain.com: ICMP echo request, id 8525, seq 1, length 64
08:43:49.076931 IP server1.mydomain.com > server1.mydomain.com: ICMP echo reply, id 8525, seq 1, length 64
08:43:50.075913 IP server1.mydomain.com > server1.mydomain.com: ICMP echo request, id 8525, seq 2, length 64
08:43:50.075924 IP server1.mydomain.com > server1.mydomain.com: ICMP echo reply, id 8525, seq 2, length 64
08:43:51.074911 IP server1.mydomain.com > server1.mydomain.com: ICMP echo request, id 8525, seq 3, length 64
08:43:51.074919 IP server1.mydomain.com > server1.mydomain.com: ICMP echo reply, id 8525, seq 3, length 64
This behaviour is not limited to ping. I get the same with wget.
Why is this happening ?
Is this something caused by configuration on my server ?
I am using Debian Stretch.
networking routing wget ping tcpdump
asked 2 hours ago
Martin Vegter
29334120234
add a comment |
lets say my server has IP address 11.22.33.44 and hostname server1.mydomain.com.
when I ping server1.mydomain.com, it looks as if ping is actually using the public IP address:
# ping server1.mydomain.com
PING server1.mydomain.com (11.22.33.44) 56(84) bytes of data.
64 bytes from server1.mydomain.com (11.22.33.44): icmp_seq=1 ttl=64 time=0.014 ms
64 bytes from server1.mydomain.com (11.22.33.44): icmp_seq=2 ttl=64 time=0.012 ms
64 bytes from server1.mydomain.com (11.22.33.44): icmp_seq=3 ttl=64 time=0.011 ms
but with tcpdump, I can see no ICMP traffic on eth0, and instead see the pings comming through lo:
# tcpdump -i lo
listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
08:43:49.076918 IP server1.mydomain.com > server1.mydomain.com: ICMP echo request, id 8525, seq 1, length 64
08:43:49.076931 IP server1.mydomain.com > server1.mydomain.com: ICMP echo reply, id 8525, seq 1, length 64
08:43:50.075913 IP server1.mydomain.com > server1.mydomain.com: ICMP echo request, id 8525, seq 2, length 64
08:43:50.075924 IP server1.mydomain.com > server1.mydomain.com: ICMP echo reply, id 8525, seq 2, length 64
08:43:51.074911 IP server1.mydomain.com > server1.mydomain.com: ICMP echo request, id 8525, seq 3, length 64
08:43:51.074919 IP server1.mydomain.com > server1.mydomain.com: ICMP echo reply, id 8525, seq 3, length 64
This behaviour is not limited to ping. I get the same with wget.
Why is this happening ?
Is this something caused by configuration on my server ?
I am using Debian Stretch.
networking routing wget ping tcpdump
asked 2 hours ago
Martin Vegter
29334120234
This is correct behaviour. There's no need for the machine to send packets destined for itself via the Ethernet NIC, so it doesn't.
– roaima
30 mins ago
@roaima - I disagree. It is not up to the network stack to decide what is "needed". I have clearly specified I want to ping the IP address associated witheth0. If I had wanted to ping localhost, I would have used127.0.0.1instead.
– Martin Vegter
10 mins ago
add a comment |
lets say my server has IP address 11.22.33.44 and hostname server1.mydomain.com.
when I ping server1.mydomain.com, it looks as if ping is actually using the public IP address:
# ping server1.mydomain.com
PING server1.mydomain.com (11.22.33.44) 56(84) bytes of data.
64 bytes from server1.mydomain.com (11.22.33.44): icmp_seq=1 ttl=64 time=0.014 ms
64 bytes from server1.mydomain.com (11.22.33.44): icmp_seq=2 ttl=64 time=0.012 ms
64 bytes from server1.mydomain.com (11.22.33.44): icmp_seq=3 ttl=64 time=0.011 ms
but with tcpdump, I can see no ICMP traffic on eth0, and instead see the pings comming through lo:
# tcpdump -i lo
listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
08:43:49.076918 IP server1.mydomain.com > server1.mydomain.com: ICMP echo request, id 8525, seq 1, length 64
08:43:49.076931 IP server1.mydomain.com > server1.mydomain.com: ICMP echo reply, id 8525, seq 1, length 64
08:43:50.075913 IP server1.mydomain.com > server1.mydomain.com: ICMP echo request, id 8525, seq 2, length 64
08:43:50.075924 IP server1.mydomain.com > server1.mydomain.com: ICMP echo reply, id 8525, seq 2, length 64
08:43:51.074911 IP server1.mydomain.com > server1.mydomain.com: ICMP echo request, id 8525, seq 3, length 64
08:43:51.074919 IP server1.mydomain.com > server1.mydomain.com: ICMP echo reply, id 8525, seq 3, length 64
This behaviour is not limited to ping. I get the same with wget.
Why is this happening ?
Is this something caused by configuration on my server ?
I am using Debian Stretch.
networking routing wget ping tcpdump
asked 2 hours ago
Martin Vegter
29334120234
lets say my server has IP address 11.22.33.44 and hostname server1.mydomain.com.
when I ping server1.mydomain.com, it looks as if ping is actually using the public IP address:
# ping server1.mydomain.com
PING server1.mydomain.com (11.22.33.44) 56(84) bytes of data.
64 bytes from server1.mydomain.com (11.22.33.44): icmp_seq=1 ttl=64 time=0.014 ms
64 bytes from server1.mydomain.com (11.22.33.44): icmp_seq=2 ttl=64 time=0.012 ms
64 bytes from server1.mydomain.com (11.22.33.44): icmp_seq=3 ttl=64 time=0.011 ms
but with tcpdump, I can see no ICMP traffic on eth0, and instead see the pings comming through lo:
# tcpdump -i lo
listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
08:43:49.076918 IP server1.mydomain.com > server1.mydomain.com: ICMP echo request, id 8525, seq 1, length 64
08:43:49.076931 IP server1.mydomain.com > server1.mydomain.com: ICMP echo reply, id 8525, seq 1, length 64
08:43:50.075913 IP server1.mydomain.com > server1.mydomain.com: ICMP echo request, id 8525, seq 2, length 64
08:43:50.075924 IP server1.mydomain.com > server1.mydomain.com: ICMP echo reply, id 8525, seq 2, length 64
08:43:51.074911 IP server1.mydomain.com > server1.mydomain.com: ICMP echo request, id 8525, seq 3, length 64
08:43:51.074919 IP server1.mydomain.com > server1.mydomain.com: ICMP echo reply, id 8525, seq 3, length 64
This behaviour is not limited to ping. I get the same with wget.
Why is this happening ?
Is this something caused by configuration on my server ?
I am using Debian Stretch.
networking routing wget ping tcpdump
networking routing wget ping tcpdump
asked 2 hours ago
Martin Vegter
29334120234
asked 2 hours ago
Martin Vegter
29334120234
asked 2 hours ago
Martin Vegter
29334120234
asked 2 hours ago
Martin Vegter
29334120234
asked 2 hours ago
Martin Vegter
29334120234
29334120234
This is correct behaviour. There's no need for the machine to send packets destined for itself via the Ethernet NIC, so it doesn't.
– roaima
30 mins ago
@roaima - I disagree. It is not up to the network stack to decide what is "needed". I have clearly specified I want to ping the IP address associated witheth0. If I had wanted to ping localhost, I would have used127.0.0.1instead.
– Martin Vegter
10 mins ago
add a comment |
This is correct behaviour. There's no need for the machine to send packets destined for itself via the Ethernet NIC, so it doesn't.
– roaima
30 mins ago
@roaima - I disagree. It is not up to the network stack to decide what is "needed". I have clearly specified I want to ping the IP address associated witheth0. If I had wanted to ping localhost, I would have used127.0.0.1instead.
– Martin Vegter
10 mins ago
This is correct behaviour. There's no need for the machine to send packets destined for itself via the Ethernet NIC, so it doesn't.
– roaima
30 mins ago
This is correct behaviour. There's no need for the machine to send packets destined for itself via the Ethernet NIC, so it doesn't.
– roaima
30 mins ago
@roaima - I disagree. It is not up to the network stack to decide what is "needed". I have clearly specified I want to ping the IP address associated with
eth0. If I had wanted to ping localhost, I would have used 127.0.0.1 instead.– Martin Vegter
10 mins ago
@roaima - I disagree. It is not up to the network stack to decide what is "needed". I have clearly specified I want to ping the IP address associated with
eth0. If I had wanted to ping localhost, I would have used 127.0.0.1 instead.– Martin Vegter
10 mins ago
add a comment |
1 Answer
1
active
oldest
votes
The kernel knows "it is already there" and therefore "optimizes" the sending of the ICMP-packets. Thats why you see them on the loopback-interface. Someone else may be able the fill in more details.
Nevertheless: I had a similar problem some ages ago and I was able the solve them by creating a new network-namespace with unshare like unshare -n /bin/bash. Then you have a shell with an entire new network-stack (I lack the correct term for that) and without a loopback-interface. You have to define a new IP, routes etc pp. in that, but from that shell you are able to send ICMP-packets to yourself out of the ethernet-interface.
answered 1 hour ago
std_unordered_map
413
New contributor
std_unordered_map is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f491859%2fping-uses-localhost-instead-of-public-ip%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
The kernel knows "it is already there" and therefore "optimizes" the sending of the ICMP-packets. Thats why you see them on the loopback-interface. Someone else may be able the fill in more details.
Nevertheless: I had a similar problem some ages ago and I was able the solve them by creating a new network-namespace with unshare like unshare -n /bin/bash. Then you have a shell with an entire new network-stack (I lack the correct term for that) and without a loopback-interface. You have to define a new IP, routes etc pp. in that, but from that shell you are able to send ICMP-packets to yourself out of the ethernet-interface.
answered 1 hour ago
std_unordered_map
413
New contributor
std_unordered_map is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
The kernel knows "it is already there" and therefore "optimizes" the sending of the ICMP-packets. Thats why you see them on the loopback-interface. Someone else may be able the fill in more details.
Nevertheless: I had a similar problem some ages ago and I was able the solve them by creating a new network-namespace with unshare like unshare -n /bin/bash. Then you have a shell with an entire new network-stack (I lack the correct term for that) and without a loopback-interface. You have to define a new IP, routes etc pp. in that, but from that shell you are able to send ICMP-packets to yourself out of the ethernet-interface.
answered 1 hour ago
std_unordered_map
413
New contributor
std_unordered_map is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
The kernel knows "it is already there" and therefore "optimizes" the sending of the ICMP-packets. Thats why you see them on the loopback-interface. Someone else may be able the fill in more details.
Nevertheless: I had a similar problem some ages ago and I was able the solve them by creating a new network-namespace with unshare like unshare -n /bin/bash. Then you have a shell with an entire new network-stack (I lack the correct term for that) and without a loopback-interface. You have to define a new IP, routes etc pp. in that, but from that shell you are able to send ICMP-packets to yourself out of the ethernet-interface.
answered 1 hour ago
std_unordered_map
413
New contributor
std_unordered_map is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
The kernel knows "it is already there" and therefore "optimizes" the sending of the ICMP-packets. Thats why you see them on the loopback-interface. Someone else may be able the fill in more details.
Nevertheless: I had a similar problem some ages ago and I was able the solve them by creating a new network-namespace with unshare like unshare -n /bin/bash. Then you have a shell with an entire new network-stack (I lack the correct term for that) and without a loopback-interface. You have to define a new IP, routes etc pp. in that, but from that shell you are able to send ICMP-packets to yourself out of the ethernet-interface.
answered 1 hour ago
std_unordered_map
413
New contributor
std_unordered_map is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
answered 1 hour ago
std_unordered_map
413
New contributor
std_unordered_map is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
answered 1 hour ago
std_unordered_map
413
answered 1 hour ago
std_unordered_map
413
413
New contributor
std_unordered_map is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
std_unordered_map is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
std_unordered_map is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f491859%2fping-uses-localhost-instead-of-public-ip%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
This is correct behaviour. There's no need for the machine to send packets destined for itself via the Ethernet NIC, so it doesn't.
– roaima
30 mins ago
@roaima - I disagree. It is not up to the network stack to decide what is "needed". I have clearly specified I want to ping the IP address associated with
eth0. If I had wanted to ping localhost, I would have used127.0.0.1instead.– Martin Vegter
10 mins ago