Home > General Administration > Tools and Troubleshooting > Determining link state using common network utilities - Mac OS

Determining link state using common network utilities - Mac OS

Table of contents
No headers

Operating systems that support IP networking share a common set of utilities that can be used to determine a local hosts wired or wireless link state and IP connectivity. If a host has IP connectivity it can be concluded that that the wired or wireless link is in good working order. In Mac OS these utilities are:


ifconfig: Used to find the IP address of network interfaces.

netstat: Can be used with -r to find the default gateway of a specific network interface.

ping: Used to test end-to-end IP connectivity between hosts.

arp: Manage the local ARP cache.

Determining link state and IP connectivity example:

 

1. Open the Terminal.

2. Issue the ifconfig command to find the IP address (inet) of a specific network interface. In this example the IP address for the wireless network interface (en1) is 192.168.128.253.

myhost:/usr/bin someuser$ ifconfig
en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 192.168.128.253 netmask 0xffffff00 broadcast 192.168.128.255
        ether 00:17:f2:e8:ac:0a
        media: autoselect status: active
        supported media: autoselect

3. Enter netstat -r to find the default gateway used by interface en1. The default gateway for en1 is 192.168.128.1.


myhost:/usr/bin someone$ netstat -r
Routing tables

Internet:
Destination             Gateway             Flags    Refs     Use  Netif Expire
default                    192.168.128.1    UGSc    90        2       en1

4. LAN communication is done on layer 2 of the OSI model. Hosts on the same LAN send data to each other using MAC addresses which is a layer 2 address. Every host builds a dynamic list of MAC address to IP address mappings in an ARP table. This table is populated by using the ARP protocol to discover which MAC addresses are associated with which IP addresses (layer 3) on the LAN. ARP is a detailed protocol and much has been left out here for the sake of brevity. Below is a brief description of ARP.

Each time a host needs to send data to another host on the LAN it checks its ARP table. If a mapping exists the data is sent to the MAC address associated to the IP address of the destination host. If no mapping exists, the local host sends an ARP request broadcast to discover the MAC address associated with the known IP address. The host that owns the IP address receives the request and responds with a unicast ARP reply claiming ownership of the IP address and its associated MAC address. When the local host receives the ARP reply, it can update its ARP table and send a frame directly to the destination host using its MAC address. ARP Cache entries turn stale periodically so hosts frequently send ARP requests to maintain an updated cache as old entries are aged out.

From the Terminal console clear your ARP table to repopulate the list.

mycomputer:/usr/bin someuser$ arp -d -a

4. Test IP connectivity by pinging the IP address of the default gateway or another host on the LAN. In Mac OS the ping is continuous.

mycomputer:/usr/bin someuser$ ping 192.168.128.1

If the local link is up and the destination host is online and reachable you will receive an ICMP echo reply for each ICMP echo request sent.

PING 192.168.128.1 (192.168.128.1): 56 data bytes
64 bytes from 192.168.128.1: icmp_seq=0 ttl=64 time=3.255 ms
64 bytes from 192.168.128.1: icmp_seq=1 ttl=64 time=0.897 ms
64 bytes from 192.168.128.1: icmp_seq=2 ttl=64 time=0.897 ms
64 bytes from 192.168.128.1: icmp_seq=3 ttl=64 time=0.905 ms

If ICMP timeouts are received between ICMP replies, there is most likely a cabling issue between the local host and destination host or the destination host is too busy to respond. In this case, try pinging a different host on the LAN. If the timeouts are not present when pinging the new host then your local link is good and you need to troubleshoot the other host.


PING 192.168.128.1 (192.168.128.1): 56 data bytes
64 bytes from 192.168.128.1: icmp_seq=0 ttl=64 time=3.255 ms
64 bytes from 192.168.128.1: icmp_seq=1 ttl=64 time=0.897 ms
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3

64 bytes from 192.168.128.1: icmp_seq=4 ttl=64 time=0.897 ms
64 bytes from 192.168.128.1: icmp_seq=5 ttl=64 time=0.905 ms
Request timeout for icmp_seq 6


If the link is up but the destination host firewall blocks ICMP you will receive ICMP timeouts. In this case the remote host did responded to your ARP requests which means your local link state and IP connectivity are good. Try disabling the firewall on the destination host and run the ping test again or try pinging a different host on the LAN. 


PING 192.168.128.1 (192.168.128.1): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 5

If the remote host is not replying to ARP requests or is offline you will receive a "Host is down" message. In this case try pinging another host on the LAN. If pinging different hosts on the LAN also results in "Host is down" it is a good chance your IP address is incorrectly configured or your uplink segment is good but the uplink segment connecting to the rest of the LAN is down. This issue could be caused by an administratively down upstream port, VLAN mismatch, or bad cabling upstream.


PING 192.168.128.1 (192.168.128.1): 56 data bytes
ping: sendto: No route to host
ping: sendto: Host is down
ping: sendto: Host is down
ping: sendto: Host is down
ping: sendto: Host is down

If your local link is down you will receive a "No route to host" message. In this case make sure your adapter is enabled, re-seat your Ethernet cable or restart your wireless connection.

PING 192.168.128.1 (192.168.128.1): 56 data bytes
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host


You must to post a comment.
Last modified
08:13, 3 Feb 2015

Tags

This page has no custom tags.

Classifications

This page has no classifications.

Article ID

ID: 1676

Contact Support

Most questions can be answered by reviewing our documentation, but if you need more help, Cisco Meraki Support is ready to work with you.

Open a Case