-3

We all know that ping is the most common way to establish layer 3 connectivity. Layer 1 connectivity is established by link light. Layer 2 connectivity is establish by checking if link protocol shows as up (or you see the MAC address), but how about non-ethernet layer 2 connectivity? How about layers 4, 5, 6, and 7?

So, the question is: What are common ways to unequivocally establish connectivity at layers 2, 4, 5, 6, and 7?

Some ideas that pop into my head:

1) telnet to port 80/443 for layer 7 connectivity

2) use netcat (how?)

15
  • 1
    I'm assuming by establish you mean confirm?
    – joeqwerty
    Aug 18 '15 at 20:49
  • 1
    This question is too broad. Entire bookshelves have been written on the subject. My personal favourite is amazon.com/TCP-Illustrated-Vol-Addison-Wesley-Professional/dp/…
    – ErikE
    Aug 18 '15 at 21:09
  • 1
    Your basic assumptions are flat-out wrong. ping is a crap diagnostic tool (failing ping doesn't mean a problem exists) and so is telnet to port 80 on a mail server.
    – Sven
    Aug 18 '15 at 21:16
  • 1
    @kasperd Are you saying that http, icmp, ethernet, and any other protocol mentioned thus far does not "follow" the OSI model? If so, you will need to significantly elaborate on that as well as provide examples to back up your argument. If you can actually do this, then please submit it as an answer so that I can mark it if I am convinced. As it stands now, you are incorrect in implying that HTTP, for example, does not adhere to the OSI model's layers' "meanings".
    – lobi
    Aug 20 '15 at 2:08
  • 1
    @kasperd I have absolutely no idea what you are talking about, sorry. Telnet is a layer 6 protocol (let us say layer 7 for simplicity sake). Telnet rides (is encapsulated) over TCP, which is a layer 4 protocol. TCP (usually) rides over IP, which is a layer 3 protocol. IP (usually) rides over Ethernet, which is a layer 2 protocol. It doesn't matter what "specific deployment" you have <- that is the whole purpose of the OSI model; to provide a standardized framework for different technologies to use.
    – lobi
    Aug 20 '15 at 17:04
4

If you are debugging connectivity(Layer 3) you need ping and traceroute.

If you want to check open ports you need tcptraceroute(Layer 4 TCP) or nmap (Layer 4 TCP/UDP), but it's pretty hard to debug UDP.

openssl s_client -connect will help you to debug SSL(Layer 5).

For everything else use tcpdump/tshark.

1
  • Thanks Navern, this is exactly the kind of answer I was looking for. Will wait for other answers before marking this.
    – lobi
    Aug 20 '15 at 2:12
4

Layer 2 requires layer 1 and layer 3 requires layer 2. Everything above that requires a functioning transport layer (3) and therefore tests above that are application specific and will vary between what type of service you are running.

Like you have already said, telnet which is an application so layer 7 is a handy way of testing socket connectivity between devices. It also requires all layers below it to be working and therefore I would call it a complete test of all the layers involved to have a working IP network.

1
  • Thanks Tom. I agree that successful connectivity of telnet/netcat/etc @ layer 7 proves all lower layers to be working, however I am specifically interested in connectivity tests per individual layer. I am not a developer, however I would imagine that there must be a way for a developer to troubleshoot connectivity between layer 5-6, for example. Of course it is possible that there is simply no way to test connectivity at layers 5/6, and it can only be done via establishing layer 7 connectivity.
    – lobi
    Aug 19 '15 at 22:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.