Network Connectivity checking procedures and techniques

Objectives

▪Connect network segments that use different media types (for instance, thin coax and
unshielded twisted pair [UTP])

▪Segment the network to reduce traffic without dividing the network into separate IP
subnets

Discussion

Step 1: Confirm network connectivity

On the source server, perform a operating system level connectivity test on established ports from
source server/firewall to destination server/firewall. The test should verify routing, network address
translation, ports, and URLs where applicable.

Telnet
Telnet is a good command to start your network connectivity tests. Open a command prompt on your
server (e.g. cmd.exe or Powershell on Windows and a console or SSH session in Unix) and execute
the following:
Note for Windows 7 users, you may have enable the Telnet client/command. To enable telnet on Windows
7, search in the start menu for “Turn Windows features on or off”. Click into that menu item and turn on
the “Telnet client”.

<source_server> command prompt>> telnet <destination> <destination_port>

$ telnet justintung.wordpress.com 80

If there is connectivity from the source server to the destination, the telnet session should begin. On
Windows and Unix, a blank screen or area should appear with a prompt. If there is no connectivity, it
will just hang after the telnet command like the following:

Connecting To <destination_server>…

and then finally show:

Connecting To <destination_server>…Could not open connection to the host, on

port <destination_port>: Connect failed.
Telnet hang on Windows PowerShell. Same thing happens on the normal cmd.exe window.
Moments later, we know the connectivity failed.

Other Telnet Failures

It is also possible you receive a message:

telnet: Unable to connect to remote host: Network is unreachable

This telnet message could occur from:

 Routing issues – Try a ping to the destination server (ping <destination>). Hopefully the ping is
successful, if not check the netstat -rn to examine gateways used for routing. It could be that a
static/alternatve route needs to be created to the destination server using an alternative gateway.
 Network infrastructure down – It is possible a piece of the network on the path to your destination
server is down.
 Incorrect information in telnet command – Make sure the IPs or fully qualified domains you are
using in telnet are correct.
Terminology

<source_server> is the server we are coming from and where the command is being executed on
the operating system. The firewall should be opened from the source server and its source
ports to the destination server and its destination ports.

<destination> is the destination server IP or fully qualified domain name (FQDN). The IP should work
whether you are using an IPv4 or IPv6 address. However, if you are testing IPv6 connectivity, it is
likely you will use a FQDN due to the long length of IPv6 addresses.
<destination_port> is the port on the destination server you are trying to get to. The destination
server should be listening on this port. The following command (netstat -a) can be used on the
destination server to check if the port is listening and you should be looking for the port after the IP
address and whether its state is listening:
$ netstat -a

Proto Local Address Foreign Address State

TCP 10.86.32.211:80 fcore:0 LISTENING

In this example, we know the machine where we are executing the command is listening on port 80
on the IP address 10.86.32.211.

If there is no connectivity, follow steps below for troubleshooting procedures.

Step 2: Check other stuff

Check firewall rule and network implementation
Check you have the right IPs, fully qualified domain names (FQDN), and ports for the servers.
Sometimes firewall rules are not requested properly and more work needs to be done to make
connectivity happen such as:

 Host file entries

 Routing: static routes, address resolution protocol (ARP) configurations
 Network Address Translation (NAT)
 Security: VPN configuration, If applicable, ensure SSL certificate trust is in place and/or certificate
exchanges installed and in place (e.g. 1-way, 2-way SSL certificates installed, and destination network
can see successful SSL handshakes).
 Servers may have several IPs – make sure the correct ones are used and seen on the firewall(s)
Another type of test: Application Interface Test (depending on application
availability)
This type of testing occurs from the application running on the source server and is common if you
do not have access to the servers themselves and may be easier to perform. In this test, the
application on the source server generates a test message/request to be received on the destination
server interface and source confirms a valid response. This test confirms URL in place and basic
messaging interface is available.

Step 3: Network connectivity troubleshooting on

server
1. Test Connectivity on source server(s)
a. Initial test by server operator:
Telnet to destination IP via destination port. If IPs are using network address translation (NAT),
choose the appropriate IP from source server – the IP the firewall sees and translates from the
source server.

b. If telnet fails:
Check if static routing is done in source server routing table. Make sure routing goes to the correct
default gateway and ping default gateway to check if it works.

Netstat – Checking the IP configuration on the server

netstat -rn

to check IP configuration on server and:

ping <destination_server>

Runs in Windows natively and in Unix sometimes under /usr/sbin/ping

c. If server routing table is ok:

Conduct the telnet test while having network resources monitor firewalls between source and
destination points.

d. If traffic is not picked up on firewall:

Check points along the network path. If possible trace the network route. Traffic bound for the
destination address should be monitored in case source server IPs are not seen on the firewall.

Traceroute – Find network routes

Use:

/usr/sbin/traceroute

to destination server and check for default gateway (assuming devices along the way do not have
ICMP blocked).

Step 4: Network protocol/packet analyzers

If you have exhausted the steps outlined above and there is still no connectivity …
you may have to use logging tools and applications traces.

The use of Wireshark, TCPdump, or similar tools for network protocol and packet analysis on the
source and/or destination servers and firewalls will aid in the troubleshooting by checking for
abnormalities or errors in packets.
Analyzing application logs
If you are working with applications that need the network connectivity, you can enable verbose
logging on the application. When testing web services, you can enable logging for protocol level
APIs. For example, if a Java application is a web service client and is connecting to the web service
endpoint, we could enable logging of the HTTP implementation in Java via JVM arguments or look at
the verbose logging of the Java SSL or Java Secure Socket Extension (JSSE) APIs.
Ping
USING PING TEST ON MICROSOFT WINDOWS

To use the ping program on Microsoft Windows, follow these steps:

1. Open a DOS command window. To do this, click Start, click Run,

type cmd, and then press Enter.
2. At the command prompt, type the following command.
Replace example.com with the domain that you want to test:
3. ping example.com
4. Interpret the output from ping:

 If the remote host is active and configured to respond to ping

requests, responses appear. For example, the following output
shows ping responses from an A2 Hosting server:
 C:\Documents and Settings\user>ping
a2s78.a2hosting.com


 Pinging a2s78.a2hosting.com
[216.119.143.98] with 32 bytes of data:


 Reply from 216.119.143.98: bytes=32

time=46ms TTL=54
 Reply from 216.119.143.98: bytes=32
time=45ms TTL=54
 Reply from 216.119.143.98: bytes=32
time=47ms TTL=54


 Ping statistics for 216.119.143.98:

  Packets: Sent = 3, Received = 3, Lost =
0 (0% loss),
 Approximate round trip times in milli-
seconds:
 Minimum = 45ms, Maximum = 47ms, Average
= 46ms
 Alternatively, if the remote host is down, or not configured to
respond to ping requests, you do not see any responses.

Firewalls can be configured to block packets from ping. If a remote

host does not respond to ping requests, it is possible that it is up
and running normally, but ignoring ping requests.
USING PING TEST ON APPLE MAC OS X AND LINUX

To use the ping program on Mac OS X and Linux, follow these steps:

1. Open a terminal window. The procedure to do this depends on your

operating system and desktop environment:
 On Mac OS X, click Applications, click Utilities, and then
click Terminal.
 On Linux, open a terminal window.
2. At the command prompt, type the following command.
Replace example.com with the domain that you want to test:

3. ping example.com
4. Press Ctrl+C to stop ping after a few tests run, and then interpret the
output:

 If the remote host is active and configured to respond to ping

requests, responses appear. For example, the following output
shows ping responses from an A2 Hosting server:
 user@localhost:~$ ping a2s78.a2hosting.com
  PING a2s78.a2hosting.com (216.119.143.98)
56(84) bytes of data.
 64 bytes from a2s78.a2hosting.com
(216.119.143.98): icmp_req=1 ttl=54 time=44.4
ms
 64 bytes from a2s78.a2hosting.com
(216.119.143.98): icmp_req=2 ttl=54 time=43.8
ms
 64 bytes from a2s78.a2hosting.com
(216.119.143.98): icmp_req=3 ttl=54 time=44.7
ms
 On the other hand, if the remote host is down, or not configured to
respond to ping requests, you do not see any responses.

Firewalls can be configured to block packets from ping. If a remote

host does not respond to ping requests, it is possible that it is up
and running normally, but ignoring ping requests.
Testing the path to a remote host with traceroute

The traceroute program provides much more detailed information

about a connection to a remote host than ping. Traceroute
(or tracert on Microsoft Windows systems) displays information about
each “hop” a packet takes from your computer to the remote host. It is
often a good way to pinpoint possible ISP connection issues or
network bottlenecks.
USING TRACERT ON MICROSOFT WINDOWS

On Windows-based systems, use the tracert program to test the path

to a server. To do this, follow these steps:

1. Open a DOS command window. To do this, click Start, click Run,

type cmd, and then press Enter.
2. At the command prompt, type the following command.
Replace example.com with the domain that you want to test:

tracert example.com
3. Interpret the output from tracert:

 Tracert displays each hop, indicated by a number in the left

column. It also displays the domain and IP address at each hop,
as well as the time spent. For example, the following output shows
the path to an A2 Hosting server:
 C:\>tracert a2s78.a2hosting.com


 Tracing route to a2s78.a2hosting.com

[216.119.143.98]
 over a maximum of 30 hops:


 1 1 ms <1 ms <1 ms Linksys

[192.168.0.1]
 [Lines omitted for brevity]
 8 45 ms 38 ms 38 ms pos-1-6-0-
0-pe01.350ecermak.il.ibone.comcast.net
[68.86.87.130]
 9 67 ms 150 ms 76 ms cr-1.sfld-
mi.123.net [66.208.233.62]
 10 44 ms 63 ms 46
ms gateway1.a2hosting.com [216.234.104.254]
 11 72 ms 57 ms 63
ms a2s78.a2hosting.com [216.119.143.98]
 

 Trace complete.
You can examine the times between each hop to look for places
where the connection “hangs”. In some cases, tracert may also
time out, which is indicated by an asterisk (*).
USING TRACEROUTE ON APPLE MAC OS X AND LINUX

To use the traceroute program on Mac OS X and Linux, follow these

steps:

1. Open a terminal window. The procedure to do this depends on your

operating system and desktop environment:
 On Mac OS X, click Applications, click Utilities, and then
click Terminal.
 On Linux, open a terminal window.
2. At the command prompt, type the following command.
Replace example.com with the domain that you want to test:

3. traceroute example.com
4. Interpret the output from traceroute:

 Traceroute displays each hop, indicated by a number in the left

column. It also displays the domain and IP address at each hop,
as well as the time spent. For example, the following output shows
the path to an A2 Hosting server:
 user@localhost:~$ traceroute
a2s78.a2hosting.com
 1 Linksys (192.168.0.1) 0.315 ms 0.452
ms 0.472 ms
 [Lines omitted for brevity]
  8 pos-1-6-0-0-
pe01.350ecermak.il.ibone.comcast.net
(68.86.87.130) 39.010 ms 38.054 ms 38.092
ms
 9 cr-1.sfld-mi.123.net
(66.208.233.62) 45.056 ms 44.335 ms 44.974
ms
 10 gateway1.a2hosting.com
(216.234.104.254) 45.274 ms 46.650
ms 46.089 ms
11 a2s78.a2hosting.com
(216.119.143.98) 44.654 ms 46.028 ms 43.852
ms
You can examine the times between each hop to look for places
where the connection “hangs”. In some cases, traceroute may also
time out, which is indicated by an asterisk (*).
Testing network connectivity with MTR

MTR (“My Traceroute”) is a network diagnostic tool that combines the

functionality of the ping and traceroute programs described above. It is
a good way to monitor in real-time the path network packets take to
their destination.
USING MTR ON LINUX

MTR may already be installed by your Linux distribution. If it is not

installed, you can install it using your distribution's package manager
(for example, apt-get or yum). After MTR is installed, follow these
steps to run a network test:

1. In Linux, open a terminal window.

2. To begin a network test, type the following command.
Replace example.com with the name of the domain you want to test:
 mtr --curses example.com
The previous command starts MTR in text mode. If your Linux
installation has a desktop environment installed, you can type the
following command to start MTR with a GUI instead:

mtr --gtk example.com

3. MTR continually tests connectivity to the host, displaying the packet
route and total number of pings:
 To change the display mode, type d.
 To restart the test, type r.
 For additional help, type h.
4. To stop testing, type q.
Netstat

To list out all vailable switches of netstat command run the following command:

netstat -h

Output:

usage: netstat [-vWeenNcCF] [] -r netstat {-V|--version|-h|--help}

netstat [-vWnNcaeol] [ ...]
netstat { [-vWeenNac] -i | [-cWnNe] -M | -s }-r, --route
display routing table
-i, --interfaces display interface table
-g, --groups display multicast group memberships
-s, --statistics display networking statistics (like SNMP)
-M, --masquerade display masqueraded connections-v, --verbose
be verbose
-W, --wide don't truncate IP addresses
-n, --numeric don't resolve names
--numeric-hosts don't resolve host names
--numeric-ports don't resolve port names
--numeric-users don't resolve user names
-N, --symbolic resolve hardware names
-e, --extend display other/more information
-p, --programs display PID/Program name for
sockets
-c, --continuous continuous listing-l, --listening
display listening server sockets
-a, --all, --listening display all sockets (default:
connected)
-o, --timers display timers
-F, --fib display Forwarding Information
Base (default)
-C, --cache display routing cache instead of
FIB={-t|--tcp} {-u|--udp} {-w|--raw} {-x|--unix} --ax25 --ipx --netrom
=Use '-6|-4' or '-A ' or '--'; default: inet
 List of possible address families (which support routing):
inet (DARPA Internet) inet6 (IPv6) ax25 (AMPR AX.25)
netrom (AMPR NET/ROM) ipx (Novell IPX) ddp (Appletalk DDP)
x25 (CCITT X.25)

List All TCP and UDP Connections

To list out only tcp connections, run:

netstat -at

Output:

Active Internet connections (servers and established)

Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 localhost:mysql *:* LISTEN
tcp 0 0 *:ssh *:* LISTEN
tcp 0 0 Node1.mshome.net:ssh Vyom-PC.mshome.ne:36405 ESTABLISHED
tcp6 0 0 localhost:9200 [::]:* LISTEN

tcp6 0 0 localhost:9200 [::]:* LISTEN

tcp6 0 0 [::]:http [::]:* LISTEN

tcp6 0 0 localhost:9300 [::]:* LISTEN

tcp6 0 0 localhost:9300 [::]:* LISTEN

tcp6 0 0 [::]:ssh [::]:* LISTEN

tcp6 0 0 [::]:https [::]:* LISTEN

tcp6 0 0 [::]:36351 [::]:* LISTEN

tcp6 0 0 [::]:2181 [::]:* LISTEN

Similarly use following command to list all udp connections:

netstat -au

Output:

Active Internet connections (servers and established)

Proto Recv-Q Send-Q Local Address Foreign Address State
udp 0 0 *:16305 *:*
 udp 0 0 *:bootpc *:*
udp6 0 0 [::]:60495 [::]:*

List All Connections

To list out all the current tcp and udp port connections, run the following command:

netstat -a

Output:

Active Internet connections (servers and established)

Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 localhost:mysql *:* LISTEN
tcp 0 0 *:ssh *:* LISTEN
tcp 0 0 Node1.mshome.net:ssh Vyom-PC.mshome.ne:36405 ESTABLISHED
tcp6 0 0 localhost:9200 [::]:* LISTEN

tcp6 0 0 localhost:9200 [::]:* LISTEN

tcp6 0 0 [::]:http [::]:* LISTEN

tcp6 0 0 localhost:9300 [::]:* LISTEN

tcp6 0 0 localhost:9300 [::]:* LISTEN

tcp6 0 0 [::]:ssh [::]:* LISTEN

tcp6 0 0 [::]:https [::]:* LISTEN

tcp6 0 0 [::]:36351 [::]:* LISTEN

tcp6 0 0 [::]:2181 [::]:* LISTEN

udp 0 0 *:16305 *:*
udp 0 0 *:bootpc *:*
udp6 0 0 [::]:60495 [::]:*
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags Type State I-Node Path
unix 2 [ ACC ] STREAM LISTENING 7945
/var/run/dbus/system_bus_socket
unix 2 [ ACC ] SEQPACKET LISTENING 7480 /run/udev/control

unix 2 [ ACC ] STREAM LISTENING 9796

/var/run/mysqld/mysqld.sock
unix 2 [ ACC ] STREAM LISTENING 7146 @/com/ubuntu/upstart
 unix 7 [ ] DGRAM 8099 /dev/log

unix 2 [ ACC ] STREAM LISTENING 9126 /var/run/acpid.socket

unix 2 [ ACC ] STREAM LISTENING 9531 flaskproject.sock

The above command shows you all connections from different protocols like tcp, udp
and unix sockets.

List All Listening Ports

To list out all listening port, run the following command:

netstat -l

Output:

Active Internet connections (only servers)

Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 localhost:mysql *:* LISTEN
tcp 0 0 *:ssh *:* LISTEN
tcp6 0 0 localhost:9200 [::]:* LISTEN

tcp6 0 0 localhost:9200 [::]:* LISTEN

tcp6 0 0 [::]:http [::]:* LISTEN

tcp6 0 0 localhost:9300 [::]:* LISTEN

tcp6 0 0 localhost:9300 [::]:* LISTEN

tcp6 0 0 [::]:ssh [::]:* LISTEN

tcp6 0 0 [::]:https [::]:* LISTEN

tcp6 0 0 [::]:36351 [::]:* LISTEN

tcp6 0 0 [::]:2181 [::]:* LISTEN

udp 0 0 *:16305 *:*
udp 0 0 *:bootpc *:*
udp6 0 0 [::]:60495 [::]:*

List All TCP Listening Ports

To list only tcp listening ports run the following command:
netstat -lt

Output:

Active Internet connections (only servers)

Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 localhost:mysql *:* LISTEN
tcp 0 0 *:ssh *:* LISTEN
tcp6 0 0 localhost:9200 [::]:* LISTEN

tcp6 0 0 localhost:9200 [::]:* LISTEN

tcp6 0 0 [::]:http [::]:* LISTEN

tcp6 0 0 localhost:9300 [::]:* LISTEN

tcp6 0 0 localhost:9300 [::]:* LISTEN

tcp6 0 0 [::]:ssh [::]:* LISTEN

tcp6 0 0 [::]:https [::]:* LISTEN

tcp6 0 0 [::]:36351 [::]:* LISTEN

tcp6 0 0 [::]:2181 [::]:* LISTEN

List All UDP Listening Port

To list only udp listening port run the following command:

netstat -lu

Output:

Active Internet connections (only servers)

Proto Recv-Q Send-Q Local Address Foreign Address State
udp 0 0 *:16305 *:*
udp 0 0 *:bootpc *:*
udp6 0 0 [::]:60495 [::]:*

List All Unix Listening Port

You can list all listening Unix port by running the following command:
netstat -lx

Output:

Active UNIX domain sockets (only servers)

Proto RefCnt Flags Type State I-Node Path
unix 2 [ ACC ] STREAM LISTENING 7945
/var/run/dbus/system_bus_socket
unix 2 [ ACC ] SEQPACKET LISTENING 7480 /run/udev/control

unix 2 [ ACC ] STREAM LISTENING 9796

/var/run/mysqld/mysqld.sock
unix 2 [ ACC ] STREAM LISTENING 7146 @/com/ubuntu/upstart

unix 2 [ ACC ] STREAM LISTENING 9126 /var/run/acpid.socket

unix 2 [ ACC ] STREAM LISTENING 9531 flaskproject.sock

Display Network Information

You can print out the information about the network interfaces by running the following
command:

netstat -i

Output:

Kernel Interface table

Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0 1500 0 1051 0 0 0 649 0 0 0
BMRU
lo 65536 0 65 0 0 0 65 0 0 0
LRU

The above command displays information in a very raw format. To get more information
run the following command:

netstat -ie

Output:

Kernel Interface table

 eth0 Link encap:Ethernet HWaddr 08:00:27:6c:2d:a6
inet addr:192.168.137.91 Bcast:192.168.137.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fe6c:2da6/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:573 errors:0 dropped:0 overruns:0 frame:0
TX packets:403 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:56080 (56.0 KB) TX bytes:62412 (62.4 KB)

lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128

Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:65 errors:0 dropped:0

overruns:0 frame:0 TX packets:65 errors:0 dropped:0 overruns:0 carrier:0 collisions:0

txqueuelen:0 RX bytes:6364 (6.3 KB) TX bytes:6364 (6.3 KB)

##Displaying RAW Network Statistics You can use the following command to display
the raw network statistics:

netstat --statistics --raw

Output:

Ip:
72893 total packets received
0 forwarded
0 incoming packets discarded
72888 incoming packets delivered
83458 requests sent out
8 outgoing packets dropped
16 dropped because of missing route
Icmp:
493 ICMP messages received
0 input ICMP message failed.
ICMP input histogram:
destination unreachable: 493
927 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
 destination unreachable: 927
IcmpMsg:
InType3: 493
OutType3: 927
UdpLite:
IpExt:
InNoRoutes: 4
InMcastPkts: 161
OutMcastPkts: 177
InBcastPkts: 366
OutBcastPkts: 355
InOctets: 36976311
OutOctets: 10651904
InMcastOctets: 21555
OutMcastOctets: 22195
InBcastOctets: 60984
OutBcastOctets: 57358
InNoECTPkts: 72893

Display IPv4 and IPv6 Information

To display both IPv4 and IPv6 information, run the following command:

netstat -g

Output:

IPv6/IPv4 Group Memberships

Interface RefCnt Group
--------------- ------ ---------------------
lo 1 all-systems.mcast.net
eth0 1 all-systems.mcast.net
lo 1 ip6-allnodes
lo 1 ff01::1
eth0 1 ff02::1:ff6c:2da6
eth0 1 ip6-allnodes
eth0 1 ff01::1
Print Netstat Information
Continuously
To print netstat command output continuously, run the following command:

netstat -c

Output:

Active Internet connections (w/o servers)

Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 Node1.mshome.net:ssh Vyom-PC.mshome.ne:36405 ESTABLISHED
Active UNIX domain sockets (w/o servers)
Proto RefCnt Flags Type State I-Node Path
unix 7 [ ] DGRAM 8099 /dev/log

unix 3 [ ] STREAM CONNECTED 7464 @/com/ubuntu/upstart

unix 3 [ ] DGRAM 7520

unix 3 [ ] DGRAM 7519

unix 2 [ ] STREAM CONNECTED 10686

unix 3 [ ] STREAM CONNECTED 8526 @/com/ubuntu/upstart

unix 2 [ ] DGRAM 9115

unix 3 [ ] STREAM CONNECTED 8003 @/com/ubuntu/upstart

unix 2 [ ] DGRAM 8259

unix 3 [ ] STREAM CONNECTED 7923

unix 2 [ ] DGRAM 11466

unix 3 [ ] STREAM CONNECTED 8004

unix 3 [ ] STREAM CONNECTED 8279

/var/run/dbus/system_bus_socket
unix 2 [ ] STREAM CONNECTED 10008

unix 3 [ ] STREAM CONNECTED 7459

unix 2 [ ] DGRAM 11060

unix 2 [ ] STREAM CONNECTED 10966

unix 3 [ ] STREAM CONNECTED 8413

unix 2 [ ] DGRAM 11176

 unix 3 [ ] STREAM CONNECTED 7962

unix 3 [ ] STREAM CONNECTED 7963

unix 3 [ ] STREAM CONNECTED 8005

/var/run/dbus/system_bus_socket
unix 2 [ ] STREAM CONNECTED 9799

unix 3 [ ] STREAM CONNECTED 8278

List process name, pid and user id

If you want to know the process name and pid which has opened that port or
connection., run the following command:

netstat -nlpt

Output:

Active Internet connections (only servers)

Proto Recv-Q Send-Q Local Address Foreign Address State
PID/Program name
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN
1158/mysqld
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
859/sshd
tcp6 0 0 ::1:9200 :::* LISTEN
1610/java
tcp6 0 0 127.0.0.1:9200 :::* LISTEN
1610/java
tcp6 0 0 :::80 :::* LISTEN
1966/apache2
tcp6 0 0 ::1:9300 :::* LISTEN
1610/java
tcp6 0 0 127.0.0.1:9300 :::* LISTEN
1610/java
tcp6 0 0 :::22 :::* LISTEN
859/sshd
tcp6 0 0 :::443 :::* LISTEN
1966/apache2
tcp6 0 0 :::36351 :::* LISTEN
857/java
 tcp6 0 0 :::2181 :::* LISTEN
857/java

You can also list process name with uid by running the following command:

netstat -ltpe

Output:

Active Internet connections (only servers)

Proto Recv-Q Send-Q Local Address Foreign Address State
User Inode PID/Program name
tcp 0 0 localhost:mysql *:* LISTEN
mysql 9795 1158/mysqld
tcp 0 0 *:ssh *:* LISTEN
root 9183 859/sshd
tcp6 0 0 localhost:9200 [::]:* LISTEN
elasticsearch 11013 1610/java
tcp6 0 0 localhost:9200 [::]:* LISTEN
elasticsearch 11012 1610/java
tcp6 0 0 [::]:http [::]:* LISTEN
root 10775 1966/apache2
tcp6 0 0 localhost:9300 [::]:* LISTEN
elasticsearch 10968 1610/java
tcp6 0 0 localhost:9300 [::]:* LISTEN
elasticsearch 10965 1610/java
tcp6 0 0 [::]:ssh [::]:* LISTEN
root 9190 859/sshd
tcp6 0 0 [::]:https [::]:* LISTEN
root 10779 1966/apache2
tcp6 0 0 [::]:36351 [::]:* LISTEN
zookeeper 9801 857/java
tcp6 0 0 [::]:2181 [::]:* LISTEN
zookeeper 10017 857/java

The above command is very useful to get the username/uid owning that particular
process. It is also contains the username and inode of the process. This is a very useful
command for network administrators.
Disable Reverse DNS Lookup for
Faster Output
When you run the netstat command, it tries to find out the hostname of each ip address
in the connection by doing a reverse dns lookup, this will slows down the output. If you
need to know only ip address then ignore the hostname lookup by running the following
command:

netstat -ant

Output:

Active Internet connections (servers and established)

Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 192.168.137.91:22 192.168.137.130:36405 ESTABLISHED
tcp6 0 0 ::1:9200 :::* LISTEN
tcp6 0 0 127.0.0.1:9200 :::* LISTEN
tcp6 0 0 :::80 :::* LISTEN
tcp6 0 0 ::1:9300 :::* LISTEN
tcp6 0 0 127.0.0.1:9300 :::* LISTEN
tcp6 0 0 :::22 :::* LISTEN
tcp6 0 0 :::443 :::* LISTEN
tcp6 0 0 :::36351 :::* LISTEN
tcp6 0 0 :::2181 :::* LISTEN

Verify DDOS Attacks

To display all active internet connections to the server, run the following command:

netstat -na

Output:

Active Internet connections (servers and established)

Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:3000 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
tcp 0 0 127.0.1.1:53 0.0.0.0:* LISTEN
tcp 0 0 10.0.3.1:53 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 181 192.168.43.4:51550 74.125.200.105:443 ESTABLISHED
tcp 0 0 192.168.137.130:48314 162.243.43.181:80 ESTABLISHED
tcp 0 0 192.168.137.130:48307 162.243.43.181:80 ESTABLISHED
tcp 0 0 192.168.137.130:48311 162.243.43.181:80 TIME_WAIT
tcp 0 3130 192.168.43.4:33282 74.125.200.94:443 FIN_WAIT1
tcp 0 354 192.168.137.130:46685 52.84.105.226:80 ESTABLISHED
tcp 0 0 192.168.137.130:33093 75.126.153.202:80 ESTABLISHED
tcp 0 0 192.168.137.130:33101 75.126.153.202:80 ESTABLISHED
tcp 0 1 192.168.137.130:52242 74.125.130.95:80 FIN_WAIT1
tcp 0 0 192.168.137.130:48308 162.243.43.181:80 ESTABLISHED
tcp 0 0 192.168.137.130:50452 192.0.73.2:80 TIME_WAIT
tcp 0 0 192.168.137.130:33076 75.126.153.202:80 TIME_WAIT
tcp 0 0 192.168.137.130:52236 74.125.130.95:80 ESTABLISHED
tcp 0 178 192.168.43.4:51551 74.125.200.105:443 FIN_WAIT1
tcp 0 1 192.168.43.4:52630 162.243.43.181:80 LAST_ACK
tcp 0 1 192.168.43.4:52623 162.243.43.181:80 LAST_ACK
tcp 0 0 192.168.137.130:48315 162.243.43.181:80 ESTABLISHED
tcp 0 0 192.168.137.130:33079 75.126.153.202:80 TIME_WAIT
tcp 0 1 192.168.137.130:52241 74.125.130.95:80 FIN_WAIT1
tcp 0 0 192.168.137.130:33077 75.126.153.202:80 TIME_WAIT
tcp 0 1 192.168.137.130:33098 75.126.153.202:80 FIN_WAIT1
tcp 0 0 192.168.137.130:48320 162.243.43.181:80 ESTABLISHED
tcp 0 0 192.168.137.130:48318 162.243.43.181:80 ESTABLISHED
tcp 0 0 192.168.137.130:52237 74.125.130.95:80 ESTABLISHED
tcp 0 1 192.168.137.130:33096 75.126.153.202:80 FIN_WAIT1
tcp 0 0 192.168.137.130:49134 216.58.199.163:80 TIME_WAIT
tcp 0 480 192.168.43.4:52622 162.243.43.181:80 FIN_WAIT1
 tcp 0 1 192.168.137.130:52238 74.125.130.95:80 FIN_WAIT1
tcp 0 0 192.168.137.130:50459 192.0.73.2:80 TIME_WAIT
tcp 0 0 192.168.137.130:49135 216.58.199.163:80 TIME_WAIT
tcp 0 1 192.168.137.130:49130 216.58.199.163:80 LAST_ACK
tcp 0 1 192.168.43.4:52595 162.243.43.181:80 FIN_WAIT1
tcp 0 0 192.168.137.130:48309 162.243.43.181:80 TIME_WAIT
tcp 0 1 192.168.43.4:52626 162.243.43.181:80 LAST_ACK
tcp 0 0 192.168.137.130:46686 52.84.105.226:80 ESTABLISHED
tcp 0 1 192.168.137.130:33100 75.126.153.202:80 FIN_WAIT1
tcp 0 0 192.168.137.130:50458 192.0.73.2:80 ESTABLISHED
tcp 0 0 192.168.137.130:33078 75.126.153.202:80 ESTABLISHED

To display only active connections to the server on port 80, run the following command:

sudo netstat -an | grep :80 | sort

Output:

tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN

tcp 0 1 192.168.137.130:39239 52.222.135.39:80 LAST_ACK
tcp 0 1 192.168.137.130:48354 162.243.43.181:80 LAST_ACK
tcp 0 587 192.168.137.130:33127 75.126.153.202:80 LAST_ACK
tcp6 0 0 :::80 :::* LISTEN

If you want to find out how many active SYNC_REC are occurring on the server, run the
following command:

sudo netstat -n -p | grep SYN_REC | sort -u

You can also detect a single flood by allowing you to recognize many connections
coming from one IP by running the following command:

sudo netstat -n -p|grep SYN_REC | wc -l

To list out all the unique IP addresses of the attacker that is sending SYN_REC
connections, run the following command:

sudo netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n
To calculate and count the number of connections each IP address makes to the server,
run the following command:

sudo netstat -anp |grep 'tcp|udp' | awk '{print $5}' | cut -d: -f1 | sort |
uniq -c | sort -n

TO list out the number of connections the IPs are connected to the server using TCP or
UDP protocol, run the following command:

sudo netstat -ntu | grep ESTAB | awk '{print $5}' | cut -d: -f1 | sort | uniq
-c | sort -nr

You can also list out only ESTABLISHED connections instead of all connections, and
displays the connections count for each IP by running the following command:

sudo netstat -plan|grep :80|awk {'print $5'}|cut -d: -f 1|sort|uniq -c|sort -

nk 1
IP Config

The first step is to power cycle everything and checks your other devices. It
might be as simple as rebooting your device so it can reconnect with the
network. Restarting your device can fix many issues. If you played video
games when you were younger (or maybe you’re like myself and still do),
I’m sure you tried turning your gaming system off and on when it wasn’t
working, and somehow magically it worked after that. This should be your
first plan of action when troubleshooting.

Once you’ve restarted your device, try connecting another device as well. If
you are having trouble connecting other devices, it could be an equipment
issue or your Internet service provider. If you find that it’s just one device
that’s having problems, you can start narrowing down the problem from here.

Next, check your firewall settings to see if it’s blocking the Internet
connection. Running an anti-virus scan can also confirm your computer does
not have any malware affecting the connection. Lastly, try using a different
Internet browser to see if something wrong with your default browser.

The second step is to check your physical connections. If you are still having
network problems after rebooting your system, the next step is just as easy
and simple. Make sure your physical connections are still plugged in and
aren’t damaged. If you are using an Ethernet cable to connect your router,
there might be a physical wireless switch, make sure that is switched to on.

At this point, make sure all the lights are flashing the way they should (many
routers and modems have a green flashing light indicating it’s connected
properly. If the lights aren’t blinking the correct color (or no color at all),
your device may be dead. If the light is red, it may be a problem with the ISP.

The third step is to run the Windows network troubleshooter program. There
are built-in troubleshooter programs that are included in Windows. These
programs can automatically search for and fix issues within your system. Try
running the program, and if it finds and fixes the problem, it will let you
know. If it does, try connecting to the network again. Some of the best
network troubleshooting programs are free and easy to use.

The fourth step is to check for a valid IP address. If you’ve gone through all
of these steps and you are still having trouble connecting to the network, you
will need to specifically locate the exact spot where the connection is failing.

In this step, make sure your device isn’t set to any abnormal IP settings.
Under Settings, to go Network & Internet Status. At the bottom of the menu,
click on Change adapter options and click on the name of your network.
When the status box appears, click on the Properties button. After you have
done this, click on Internet Protocol Version 4. Make sure the Obtain an IP
address automatically and Obtain DNS server addresses automatically are
both checked. Follow these same steps for Internet Protocol Version 6 as
well.

After these steps, review the validity of your IP Address. Type “cmd” into the
start menu to open the Command prompt window and enter “ipconfig.” Next,
look for Ethernet adapter or Wireless LAN adapter. If it says you are not
receiving a valid IP address from your router, and it says 169.x.x.x, there are
two commands that will release your computer’s current IP address and
request a new one—ipconfig / release and ipconfig / renew.

If this doesn’t work after a couple of attempts, try connecting your computer
directly to the modem by an Ethernet cable. If this works and you are online,
the problem is your router.

The fifth step will be trying to Ping and Trace its Route. If your IP doesn’t
begin with 169 (when you run ipconfig), you know you have a valid IP
address from your router. This means the failure is happening between the
router and the Internet. Pinging and tracing the route will be the next step.

To ping a computer by IP address, open a shell prompt by entering Command

Prompt or MS-DOS Prompt on the Start menu. Next type “ping” followed by
space and then the IP address. Press the enter/return key.
Microsoft windows ping will send a series of four messages to the address.
You will receive a confirmation line for each response. Bytes, Time it takes
to respond, and TTL (Time-to-Live). If this fails, check to see where the
problem is occurring. If the failure is happening early in the route, the
problem is most likely happening within your local network.

The sixth and final step is to contact your Internet Service Provider. If
you’ve reached this step, this means your equipment is working fine, and you
have a valid IP address from the router. You have also confirmed that the
issue is happening outside of the network for multiple devices. While you are
contacting your ISP, you can also check an outage map on your smartphone
by going to downtector.com. This may give you information if there are
known problems in your area.

Once you have contacted your ISP, waiting until they fix the problem may be
your only choice left. You have completed all the steps and can confirm the
problem isn’t something you can fix so all you can do is wait.

Conclusion
Problems connecting to your network can be one of the most frustrating
things, especially if you are working on the computer often. Understanding
the common connectivity issues can be beneficial when it comes to
troubleshooting. There are some good tools you can use to narrow down your
network problems. And if you are still having trouble getting yourself online,
follow the steps above to get your computer back up and running.
Evaluation

True or False

1. When you run the netstat command, it tries to find out the hostname of
each ip address in the connection by doing a reverse dns lookup.

2. Belnet is a good command to start your network connectivity tests

3. To list out all listening port run the following command: use this netstat -3

4. If you have exhausted the steps outlined above and there is still no
connectivity … you may have to use logging tools and applications traces.

5. Microsoft windows networks will send a series of four messages to the

address.

6. The sixth and final step is to contact your nearby provider

7. The fourth step is to check for a valid IP address

8. Running an anti-virus scan can also confirm your computer does not
have any malware affecting the connection

9. If you are working with applications that need the network connectivity

10. The fifth step will be trying to Ping and Trace its Route
Answer Key

1. True

2. False

3. False

4. True

5. False

6. False

7. True

8. True

9. True

10. True

Reference

https://www.colocationamerica.com/blog/network-troubleshooting-steps

https://hostpresto.com/community/tutorials/netstat-command-line-tips-and-tricks/

https://www.a2hosting.com/kb/getting-started-guide/internet-and-networking/troubleshooting-network-
connectivity-with-ping-and-traceroute

https://justintung.com/2010/12/03/network-connectivity-troubleshooting-step-by-step-with-commands/

https://www.sciencedirect.com/topics/computer-science/network-connectivity