CENTOS6 Failure analysis of the next network Ping packet not responding

1) Description of the phenomenon

Today, colleagues visit, he used the VMware Workstation test, using NAT mode, at home can ping www.baidu.com, but in the company how to Ping, but access to the intranet and gateway are normal. And both the SELinux and iptables of the test machine are closed.

2) Processing process

A, testing to other intranet host

[Email protected] ~]# ping-c 5 10.10.10.1PING 10.10.10.1 (10.10.10.1) (+) bytes of data.64 bytes from 10.10.10.1:ICM P_seq=1 ttl=64 time=0.440 ms64 bytes from 10.10.10.1:icmp_seq=2 ttl=64 time=0.968 ms64 bytes from 10.10.10.1:icmp_seq=3 ttl=64 time=3.39 ms64 bytes from 10.10.10.1:icmp_seq=4 ttl=64 time=4.77 ms64 bytes from 10.10.10.1:icmp_seq=5 ttl=64 Tim e=1.55 ms---10.10.10.1 PING statistics---5 packets transmitted, 5 received, 0% packet loss, time 4005msrtt min/avg/max/m dev = 0.440/2.226/4.777/1.618 ms Description: to other hosts in the intranet, normal

b, test to the gateway

[Email protected] ~]# ping-c 5 10.10.10.2PING 10.10.10.2 (10.10.10.2) (+) bytes of data.64 bytes from 10.10.10.2:ICM P_seq=1 ttl=128 time=1.15 ms64 bytes from 10.10.10.2:icmp_seq=2 ttl=128 time=2.21 ms64 bytes from 10.10.10.2:icmp_seq=3 ttl=128 time=0.252 ms64 bytes from 10.10.10.2:icmp_seq=4 ttl=128 time=0.209 ms64 bytes from 10.10.10.2:icmp_seq=5 ttl=12 Description: Normal to Gateway

C, test to baidu.com connectivity

[Email protected] ~]# ping-c 5 Www.baidu.comPING www.a.shifen.com (61.135.169.121) (+) bytes of data.---Www.a.shifen . com Ping Statistics---5 packets transmitted, 0 received, 100% packet loss, time 13999MS Description: Discovery packet is completely lost, but DNS can resolve to IP address, the network is not Is there doubt about the restrictions?

D, detection of DNS resolution

[email protected] ~]# nslookup www.baidu.comServer:10.10.10.2Address:10.10.10.2#53Non-authoritative answer: Www.baidu.comcanonical name = Www.a.shifen.com.Name:www.a.shifen.comAddress:61.135.169.125Name: www.a.shifen.comAddress:61.135.169.121 Description: DNS resolution is normal

E, test whether the network is really connected (wget and Nmap)

[[email protected] ~]# mkdir -p /packet[[email protected] ~]# cd  /packet/[[email protected] packet]# wget www.baidu.com--2016-10-19 06:01:48--   http://www.baidu.com/parsing host  www.baidu.com... 61.135.169.125, 61.135.169.121 connecting   www.baidu.com|61.135.169.125|:80...  is connected. Issued  HTTP  request, waiting to respond ...  200 ok length:2381  (2.3K)  [text/html] saving to:  "index.html" 100%[==================================================================================>] 2,381        --.-k/s   in 0s       2016-10-19 06:01:48  (128 mb/s)  -  saved   "index.html"  [2381/2381]) [[email  The protected] packet]# echo $?0 test indicates that wget is normal and can be downloaded normally [[Email protected] packet]# nmap  www.baidu.comStarting Nmap 5.51  ( http://nmap.org )  at 2016-10-19 06:02 cstnmap scan report for www.baidu.com  ( 61.135.169.125) host is up  (0.036s latency). other addresses for www.baidu.com  (not scanned):  61.135.169.121not shown:  998 filtered portsPORT    STATE SERVICE80/tcp  open   http443/tcp open  httpsNmap done: 1 IP address  (1 host  up)  scanned in 56.33 seconds Description: The ability to use NMAP to detect port opening conditions

F, using tcpdump for packet capture analysis

[[email protected] ~]# ping -c 5 10.10.10.2ping 10.10.10.2  (10.10.10.2 )  56 (+)  bytes of data.64 bytes from 10.10.10.2: icmp_seq=1 ttl= 128 time=0.287 ms64 bytes from 10.10.10.2: icmp_seq=2 ttl=128 time= 0.626 ms64 bytes from 10.10.10.2: icmp_seq=3 ttl=128 time=0.370 ms64  bytes from 10.10.10.2: icmp_seq=4 ttl=128 time=0.412 ms64 bytes  From 10.10.10.2: icmp_seq=5 ttl=128 time=0.248 ms--- 10.10.10.2 ping  statistics ---5 packets transmitted, 5 received, 0% packet loss,  Time 4003msrtt min/avg/max/mdev = 0.248/0.388/0.626/0.133 ms[[email protected]  ~]# tcpdump -i eth0 icmptcpdump: verbose output suppressed, use  -v or -vv for full protocol decodelistening on eth0, link-type en10mb   (Ethernet), capture size 65535 bytes05:48:57.350869 ip mysql-master  > localhost: ICMP echo request, id 10786, seq 1, length  6405:48:57.351123 ip localhost > mysql-master: icmp echo reply, id  10786, seq 1, length 6405:48:58.352296 IP mysql-master >  localhost: icmp echo request, id 10786, seq 2, length  6405:48:58.352889 ip localhost > mysql-master: icmp echo reply, id  10786, seq 2, length 6405:48:59.352281 IP mysql-master >  localhost: icmp echo request, id 10786, seq 3, length  6405:48:59.352590 ip localhost > mysql-master: icmp echo reply, id 10786, seq 3, length  6405:49:00.353060 ip mysql-master > localhost: icmp echo request,  id 10786, seq 4, length 6405:49:00.353433 ip localhost >  mysql-master: icmp echo reply, id 10786, seq 4, length  6405:49:01.353288 ip mysql-master > localhost: icmp echo request,  id 10786, seq 5, length 6405:49:01.353503 ip localhost >  Mysql-master: icmp echo reply, id 10786, seq 5, length 64

Description: There is a normal request package and reply, stating that the machine to 10.10.10.2 normal (Request package), and 10.10.10.2 to the native has a response (reply package)

[[email protected] ~]# ping -c 5 www.baidu.comping www.a.shifen.com  ( 61.135.169.125)  56 (+)  bytes of data.--- www.a.shifen.com ping statistics  ---5 packets transmitted, 0 received, 100% packet loss, time  14003ms[[email protected] ~]# tcpdump -i eth0 icmptcpdump: verbose  output suppressed, use -v or -vv for full protocol  decodelistening on eth0, link-type en10mb  (Ethernet), capture size  65535 bytes05:53:27.820920 ip mysql-master > 61.135.169.125: icmp echo  request, id 14370, seq 1, length 6405:53:28.822483 IP  Mysql-master > 61.135.169.125: icmp echo request, id 14370, seq  2, length 6405:53:29.823843 ip mysql-master > 61.135.169.125: icmp echo request, id 14370,  SEQ 3, LENGTH 6405:53:30.823290 IP MYSQL-MASTER > 61.135.169.125:  icmp echo request, id 14370, seq 4, length 6405:53:31.823680  ip mysql-master > 61.135.169.125: icmp echo request, id 14370 ,  seq 5, length 64 Description: Found a request package, indicating that this machine to Baidu's package, Baidu is received, may be Baidu did not respond (unlikely) or blocked by the company's firewall

Use a phone hotspot to share with a test machine

[[email protected] ~]# ping -c 5 www.baidu.comping www.a.shifen.com  ( 183.232.231.173)  56 ( bytes of data.64 bytes from 183.232.231.173: ) icmp_seq=1 ttl=128 time=74.4 ms64 bytes from 183.232.231.173: icmp_seq=2  ttl=128 time=74.7 ms64 bytes from 183.232.231.173: icmp_seq=3 ttl=128  time=64.4 ms64 bytes from 183.232.231.173: icmp_seq=4 ttl=128 time= 57.0 ms64 bytes from 183.232.231.173: icmp_seq=5 ttl=128 time=60.5  MS--- www.a.shifen.com ping statistics ---5 packets transmitted, 5  received, 0% packet loss, time 4065msrtt min/avg/max/mdev = 57.081/ 66.263/74.772/7.216 ms[[email protected] ~]# tcpdump -i eth0 icmptcpdump:  verbose output&nbSp;suppressed, use -v or -vv for full protocol decodelistening on  eth0, link-type EN10MB  (Ethernet),  CAPTURE SIZE 65535 BYTES05 : 58:31.031646 ip mysql-master > 183.232.231.173: icmp echo request,  id 40226, seq 1, length 6405:58:31.106104 IP 183.232.231.173  > mysql-master: ICMP echo reply, id 40226, seq 1, length  6405:58:32.032448 ip mysql-master > 183.232.231.173: icmp echo request,  id 40226, seq 2, length 6405:58:32.107194 IP 183.232.231.173  > mysql-master: ICMP echo reply, id 40226, seq 2, length  6405:58:33.034464 ip mysql-master > 183.232.231.173: icmp echo request,  id 40226, seq 3, length 6405:58:33.098846 ip 183.232.231.173 > mysql-master: icmp  echo reply, id 40226, seq 3, length 6405:58:34.035272 IP  Mysql-master > 183.232.231.173: icmp echo request, id 40226, seq  4, length 6405:58:34.092322 IP 183.232.231.173 > mysql-master:  Icmp echo reply, id 40226, seq 4, length 6405:58:35.036289 ip  mysql-master > 183.232.231.173: ICMP echo request, id 40226,  seq 5, length 6405:58:35.096837 ip 183.232.231.173 > mysql-master:  ICMP ECHO REPLY, ID 40226, SEQ 5, LENGTH 64 Description: To Baidu is a request and reply package, All the bags in and out are normal.

Comprehensive analysis: Should be the company's internal network when the back of the network package made some restrictions, and then checked with the network engineer, indeed on the firewall to do some restrictions.

This article is from the "Frozen vs watermelon" blog, so be sure to keep this source http://molewan.blog.51cto.com/287340/1865812

CENTOS6 Failure analysis of the next network Ping packet not responding