-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?)

lobi
  • 1,083
  • 2
  • 15
  • 30
  • 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 http://www.amazon.com/TCP-Illustrated-Vol-Addison-Wesley-Professional/dp/0201633469/ref=pd_sim_sbs_14_1?ie=UTF8&refRID=1VQ58B2W1P6YTVXBS6HB – 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
  • Adding to Svens comment, successful ping does not mean layer 2 is functioning either. Seen a faulty NIC driver screw only certain application traffic up, ping and other basic connectivity tests indicated the problem was higher up in the stack. Iterating the bejesus out of the OSI model is the only unequivocal way, together with knowing the network stack and applications one got stuck with. – ErikE Aug 18 '15 at 22:03
  • @ ErikE: This is not broad; the question asks for a specific answer for each layer. As a matter of fact, you clearly have forgot (or never understood) the fundamentals. If a ping between two hosts is successful, then 100% guaranteed layer 2 is also established since the packet is encapsulated within a frame. "Ping and other basic connectivity tests indicated the problem was higher up in the stack" <- This is 100% incorrect, as ICMP resides at layer 3 and has no exposure to higher layers. I highly recommend you refresh your understanding of basic layer2/3 communication. – lobi Aug 19 '15 at 22:34
  • @Sven: Anyone who says ping is crap must have not had real world experience in networking. Of course if ping fails, then it doesn't tell you anything (ICMP can simply be blocked). However, if a ping work, then you can **UNEQUIVOCALLY ** confirm that those two IPs have a route to each other, which means that layer 3 connectivity has been established. There may be a problem with that particular route, but the route exists. – lobi Aug 19 '15 at 22:38
  • Just to clarify my statement under @Sven since SE won't let me edit. "you can unequivocally confirm that those two IPs have a route to each other //and they can communicate via layer 3//, which means that layer 3 connectivity has been established". – lobi Aug 19 '15 at 22:46
  • This question is based on an incorrect premise. You are assuming that OSI layer numbers have a meaning while you are using a protocol stack that doesn't follow the OSI model. If you want to ask a meaningful question about the IP protocol stack, then use the names of the protocols you want to ask about. – kasperd Aug 20 '15 at 00:34
  • 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 02:08
  • @lobi A protocol layer in the IP stack cannot be assigned a number because the number of layers beneath it depends on the specific deployment. Sometimes you'll find that IP itself is present more than once in the stack. Even if you consider the simplest or most common layering, the numbers still don't match up with OSI. You already gave an example yourself by mentioning telnet as layer 7 even though in a typical stack the only layers beneath telnet are: TCP, IP, Ethernet. – kasperd Aug 20 '15 at 12:52
  • 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
  • 1
    @lobi In your question you said telnet was layer 7, now you say it is layer 6. And you say TCP is layer 4. What happened to layer 5? In case it wasn't clear already: **IP is not OSI**. And yes, it does matter what your deployment looks like. Some deployments have a protocol layer between Ethernet and IP. The whole purpose of IP is that you can use IP just the same regardless of what you use beneath it including stacks of varying depth. – kasperd Aug 20 '15 at 23:29
  • As in the previous comment, I stated "let us consider telnet as layer 7 for simplicity purposes". Of course IP is not "OSI" (that makes no sense). IP is a layer 3 protocol. Your latest comment did not expand at all on your previous comments, and it also reinforced what I stated in my previous comment. Honestly I don't think you have a firm grasp on network (layer 1-4) fundamentals. For layer 5, Navern gave a response that is good enough for me. Will mark that as answer and keep open. Also, I appreciate the discussion from everyone here regardless of each person's knowledge of the subject. – lobi Aug 21 '15 at 18:22
  • @lobi: You assume too much about your networking insight as well as about others. Tone it down and realize no theoretical model is immune to faulty code, or indeed to code that excepts the model. Consider instead this little riddle: The OSI model places the NIC driver solidly in the upper half of L2. Period. When the driver has done its job the frame data is passed to L3 and doesn't touch the driver again according to OSI. Yet modern NICs can do TCP offloading (L4) with help from the NIC driver and still leave L3 processing to the OS. How, and what issues may arise? – ErikE Aug 29 '15 at 07:59
  • 1
    I don't know why this question got so many downvotes, I think its a fair question and its in the spirit of trying to gather concepts and techniques to debug the Linux network stack. – LeanMan Dec 16 '20 at 12:16

2 Answers2

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.

tomstephens89
  • 1,011
  • 1
  • 12
  • 24
  • 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
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.

Navern
  • 1,619
  • 1
  • 10
  • 14
  • 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 02:12