Network Troubleshooting for Beginners - 3 commands , 1 framework, 3 methods

friends there is a reason why I call Ping Trace root and tell net your bread and butter commands for Network troubleshooting the reason is even while using these three commands these basic commands you can do a lot of troubleshooting on your own and come to a place where you could involve experts okay so what a ping does ping simply checks whether a Remote device is available or not for example if a website is not reachable one thing which you could do is you can try pinging you can try pinging its IP address and see if

you are getting the response and if you're not getting the response you can come to a basic conclusion that there could be something broken in the networks because the response is not coming and it could be due to any reason we have not yet concluded it but at least you can say that you know the server is not reachable now it could be that server can be uh down and there could be a number of issues which we'll understand in the next section which is the framework okay but for now let's have these practical handy

tools with us so first try the Ping if you see that okay the Ping response is not coming your immediate Next Step should be Trace root because now what Trace root is trying to do would be that from your source to your destination it would check every hop which the network takes and maybe it could be through different uh you know router devices and it would you know it would see there would be a time to live pack ET and it would check whether it is getting response from every place or not and for example

if it breaks uh it will show step by step by step and suppose from here it is broken then we can say that somewhere here the problem is present so Trace root is a very good example tnet is a different kind of command which you can use which could actually check whether a particular service is available on a particular port for example for this same situation you're able to log to your web server but after that when you're trying to make an entry uh you are not able to do anything because it says that database

is down in those cases you can use tet to see whether a particular application is listening on a particular port for example if this database was Oracle we can check whether our Oracle server is listening on Port 1521 I think this is the default Port I don't know so you can you know you can do a tnet the IP address of Oracle server and then Port 1521 and you should see a success and then that will show that your network Port is accessible if not it could be a firewall issue it could be that this

particular Port is not at all accessible or maybe this particular Port specific Port is down on the server there could be a number of issues but tnet gives you that kind of visibility so these three even before understanding any Theory I wanted to give you practical three tools with these three tools you can do any kind of troubleshooting but the problem is if you do not have the framework in mind you will get lost so now understand the fix it framework which will not help you fix every issue on network but it will also give

you an approach which would help you fix issues on other in other areas as well so now let's understand the Fixit framework so this is our five step fix it framework and the number one step for troubleshooting any issue and especially Network issue starts with finding the problem and when we say finding the problem we have to collect whatever data we can whatever information we can uh for that particular isue for example if a user comes in and says that I'm not able to log in then we have to exactly find why he or she

is not able to log in okay we have to clearly Define what is the problem is that user not able to log in from laptop is the user not able to log in through mobile is the user not able to log in from one particular Network location or a Wi-Fi what the problem is so finding the problem uh you everything starts with that and then once you have found the problem once you have defined the basic problem then comes the next step which is inspect the symptoms what are the symptoms what the user is facing

what kind of information you have gathered and what kind of symptoms you can see for example user says uh in the first phase that I'm not able to log in but when you are inspecting the system he or she says that I'm not able to log in during the busy hours now that is a different problem right because when he the moment user says it is a busy whenever I am facing this issue generally it is a busy Thursday or busy Tuesday the problem narrative has changed so inspecting the symptom again the another could be

is it is it only you who's facing this login issue or other leagues of yours are also facing the issue so that shows that how broader the impact is whether the whole network itself is not able to access that particular uh website or portal so all those kind of symptoms you have to inspect to further Define the problem and narrow it down the target of any troubleshooting is to narrow it down bid by bid by bid to a level where we could not further go down okay so we have to funnel it down as much

as possible so finding the problem then inspecting the symptoms the third is exclude possibilities so once we have all this data a very good thing which we can do is to exclude what could be the reasons okay excluding those possibilities excluding those causes let's take an example we took an example that a user is not able to login now when user says that I'm not able to log in during busy hours that means that connectivity part per se could be fine why because it's only during the busy hours when the particular user is facing the

issue which shows that it could be a load issue on the particular server because when too many users when too many users are bomb warding that particular server okay the server might be facing performance lag we could kind of exclude it we can never say that for sure it is not the issue but what we can do we can exclude so one thing we could which we could exclude for example is that it it could not be a port issue because if if it would have been the port issue would have not been accessible anytime

during the day but on the other side it could well very happen that when the load is coming this particular port is going down okay so what we are trying to do we are trying to exclude the possibility the possibility of a router not working okay of a particular router not working is again going down and down because this is only happening when the load is too high and generally the routers are capable enough to handle those kind of uh loads it's generally your web server which is not scaling uh enough on time because this

particular router is not only used for your server it is used for so many servers so again you need to understand that it could be a performance issue on the server side or maybe there could be a performance issue on the client Network side but not at the router level it and again all these are assumptions we are making we are trying to exclude the possibilities but with an open mind that we could be wrong once you have these three steps okay we come to the fourth step where we Implement a fixed hypothesis what is

an hypothesis hypothesis is a kind of a test we try to run to understand whether our hypothesis is right or wrong for example this particular user is facing the issue during peak hours uh that particular user is not able to access the server so now one particular hypothesis could be that we ask five different users to test the same website the same web server at the same time at the same peak hours you know if all five or four or five of them face the same issue then we can say that it could be a

load but what if only one particular user is facing it then what we can do we can ask this particular user to instead of trying to log into this server try to log into to another server in the same network maybe it could be a quality server and see that if he or she is facing the same issue it could be that the problem lies with his workstation or a very specific setting on his laptop so this is how you implement a fixed hypothesis and if your first hypothesis is wrong for example this whole hypothesis

which we are building that it could be a performance issue it could be a load on the server suddenly fails because this user faces the issue or multiple user faces the issue even in the lean time even during the night when there's no load the same issue of inaccessibility is coming again the whole shift happens and we have to come up with a new hypothesis so it is kind of an iterative process which you have to do until you narrow it down to the minute details and then you know once you have done everything you

have to do tracking what is tracking tracking means that once you have implemented the fix for example after doing this Implement hypothesis your initial hypothesis was right and your server was facing uh outages because of the heavy load and what you did you horizontally scaled it to three different nodes so now instead of one node there are two three nodes sitting with a load balancer which is doing Auto scaling okay I'm just taking random examples whatever is coming to my mind but now with these load balancers uh the load is equally distributed so if you

have created this hypothesis the last thing which you have to do is to track it tracking means you have to document whatever you have done and you have to monitor that whether your hypothesis and your fix is working on in all the different conditions or not and documenting will help you because if you face the similar issue in the future you will not have to scratch your head and bend your back again okay so yes this is the Fixit framework I use this AC acronym because it is easy to uh recall so we'll just rephrase

it find the problem inspect the symptoms exclude the possibilities Implement a fixed hypothesis and iterate till the time you find a particular 100% short shot fix and then you track it so this is your fix it framework which could be applied in fixing on troubleshooting different kind of issues now with this now comes the next section where we understand what three kind of approaches you can take on your OSI layer which will help you further troubleshoot your issues in a better way so now let's discuss three strategies which we could uh deploy while troubleshooting network

issues uh especially uh taking OSI layer as our reference if you don't know the OSI layer we have our in-depth video on OSI layer which you could watch but just for Simplicity sake in order to remember this we have our famous acronym which we you know invented on it Gund Chan channel uh and which was all people should try new Domino's Pizza so we go from layer 7even to layer 1 so this is the acronym which we always use to remember all the seven layers but the most important part is how to use this for

your troubleshooting so basically the three approaches which we are talking about is so let's start with the number one so number one approach is top down approach so for example in your top down approach you will first see what if your application itself is misconfigured or if your application itself is not working correctly okay it could be due to a bug into in your application it could be due to some issue with your sttp stps protocols it could be some certificate issue all those kind of things which we check and it could vary I'm just

giving you a strategy it will apply from case to case basis so top down approach always starts from the top from your application layer presentation layer session layer transport layer so where the TCP protocol or UDP protocol comes in and then your IP packets come at the network layer and generally this approach is very good if issue is very persistent with a particular application or if the user if a particular user or set of users are facing it then it's always advisable to go top down because in all U you know in all possibilities the

problem will either be present in these three layers maybe okay or maybe at the transport layer but for example your whole you know office is not able to access anything now there you will deploy a bottom up approach for example in your house also when you suddenly lose uh your internet connectivity the first thing which you do because your whole house is down virtually you go and see if your router is plugged in and your cable is router cable is plugged in properly or not your router is up and running or not so all those

things what you're doing you're starting from the physical layer you're checking your cas cables and modems whether these are connected properly or not and then you move up so this is called as bottom up and then there is a third approach which is called as a hybrid so what is a hybrid so you take I think from here okay so you take your layer three because Layer Three is very important guys Layer Three is where your IP packets come into picture Layer Three is where your routers come into picture so you can take this as

a center point and you can deploy hybrid approach which is called as hybrid so in hybrid from layer three you will see upwards and downwards look based on your troubleshooting for example if you are trying to Ping the server and if the server itself is not available that very well suggest that it could be a issue with the server okay that particular server but from that same layer if you're able to you know if you're able to Ping another server in the same subnet that means that your routers are doing pretty much fine so there

is something you know from layer three up to layer 7 there is something happening there so this is how you can deploy a hybrid approach but for example if you if you see that the whole subnet you're not able to reach the whole network you're not able to reach so then you can go down you can check at your data link or at your physical layer okay so this is called as hybrid approach generally top down is used by people who are you know who are on the application end because they mostly know what's happening

in top three four layers but they don't have much understanding the moment routers and switches come into picture which is your layer three and Layer Two and generally the network specialist will not touch the problem till the time it it reaches layer three or layer Layer Two this is where the network specialist comes in so generally bottom up is something where Network specialist starts because we don't have any clue how it is being done right behind the scenes and then hybrid is an approach which is uh used by the intermed mediate users who have Fair

understanding of how this whole OSI model works so guys I hope with these uh you know these three strategies you will be better equipped to troubleshoot your issues so just to uh refresh we understood the three bread and butter commands ping trace route and tnet then we moved on and we understood the fix it framework the five step framework to troubleshoot uh a network issue or any issue for that matter and then now we know how we can use these three top down bottom up and hybrid strategies on OSI layer to troubleshoot any kind of

network issue so friends now I hope this video uh is somewhat helpful if yes then please give us a like leave in the comment below what kind of approaches you follow when troubleshooting any kind of issues and also suggest what other topics you want to learn on this channel so until next time keep learning keep sharing all your knowledge and yes keep hustling bye for now