When you think you have made a procedure idiot proof your company employs a better idiot.
True. But here's the answer that I was looking for.
TCP has error correction, right? If you go to a HTTP site and a couple of packets get lost, they will be sent again and all the data put back together in the proper order. Right?
But what happens if you're having a phone conversation on a VOIP system? What if a few packets get lost during the conversation? Would you want the packets to be resent? Of course not because the conversation is happening in real time. It's better that a word or 2 is lost than resending them and the words being out of place. So, that's the big reason that we need UPD, in my opinion.
UDP isn't worried about error, it's worried about speed.
Last edited by BillyCarpenter; 05-12-2021 at 06:15 PM.
When I'm taking a course in whatever, I always know that I have one chance to learn it the right way because I'll probably never go back and cover the fundamentals again. I remember when I was taking industrial electronics back in 1990 that I tried to pay attention to every little detail. I'm attempting to do that with the CCNA course.
It can be maddening at times. It can be very frustrating to trace a packet from end-to-end. Sometimes I just want to say FUCK IT.
However, there's no better feeling in the world than when I have one of those break-thru moments. When everything starts to click, it's a beautiful thing. It doesn't last long because I'm steadily progressing to something that's more complicated and harder to learn.
If I could give any advice it would be to NOT move on to something else until you fully understand what you're currently working on. I mean REALLY UNDERSTAND it. Nothing about this CCNA course is easy. Not a damn thing.
Peace.
By the way, I want to address the OSI Model.
When I first started the CCNA course, I didn't know if it was something that was used in the real world or if it was even important. Now I know enough about it to give a definitive statement.
The question is: Is the OSI Model important?
Answer: If may be the single most important thing you'll ever learn about networking. They don't include the OSI model in these courses because it's a waste of time. They don't constantly refer back to the OSI model over and over and over again because it's unimportant.
If you plan on troubleshooting a network, you better know the OSI Model. There's a million different things that can go wrong with a network and you need to narrow it down to a specific layer. If not, you'll be chasing your tail all over the place. I've been beat over the head so much with the OSI Model in this course that it's become 2nd nature. My mind automatically thinks in terms of the OSI model when there's a problem.
Last post of the night. This is random and only my personal opinion.
Here's what's surprised me the most thus far.
1. Layer 4 of the OSI Model.
2. ARP
At layer 4 there's more going on than in the other layers, but I never hear it talked about like that.
ARP gets barely any attention from what I can tell. But I find it's role fascinating. The way it interacts with a switch expands the broadcast domain and the way ARP is used in conjunction with the default gateway to reach another network is very interesting.
Subject: The Life of a Packet
This has been a slow build up to tracing a packet from one end of the network to the other. This time we have the following devices on the network:
4 PC's
2 Switches
1 Router
Since we have a router that means that we have 2 networks. In this lab we want to send a packet from PC1 on one network to PC 4 on a different network.
We must know a few things in order to understand the life of a packet.
* Every device on the network has an ARP table. Yes, the switch, router and PC's all have an arp table.
** Switches also have a Mac Address Table
*** Routers also contain a routing table.
We need to learn how all these tables work together to get the packet to it's destination. Moreover, we need to understand how all the tables are populated for the first time.
Let me put it like this: When all the tables (arp, mac, routing) are empty it takes 28 steps for PC1 to send a packet to PC4. But we've only covered half of the process for the life of a packet. PC4 must now respond back to PC1. Since all the tables were populated the first time around, it only require 8 more steps for PC4 to respond back to PC1. As you can see, it takes a lot less steps.
This CCNA is a monster of a test. I think I'm gonna camp out for a while on learning the life of a packet. I'm gonna fire up Wire Shark to really get it down. I think I have it down now but will leave no stone unturned.
EDIT: ARP is the Rockstar of the show. We must give ARP it's just due.
I was laid off for about a year and a half, and had all kinds of time on my paws.
Now I’m back to workin’ for the man, and my spare time is scarce again.
Gotta say…It feels really good to be back at work. And as Joni Mitchell so elegantly put it, “Don’t it always seem to go, that you don’t know what you got ‘til it’s gone”. Couldn’t be more true!
Last edited by KenB; 05-15-2021 at 06:07 PM.
“I think you should treat good friends like a fine wine. That’s why I keep mine locked up in the basement.” - Tim Hawkins
Bookmarks