Welcome to Omgili,
Omgili ( Oh My God I Love It ;) is a search engine for discussions. With Omgili you can find answers and solutions, debates, discussions, personal experiences, opinions and more... To learn more about Omgili click here.
This is a complete preview of the discussion as it was indexed by Omgili crawlers. Use this preview if the original discussion is unavailable.
Click here to view the original discussion.
 |
|
 |
|
The Osi Reference Model - Critical Security.NET
Posted 21 December 2007 - 01:29 PM
Ok children, I'm going to explain the OSI Reference Model to you and hopefully, if you read this properly, you'll understand networking and internetworking a bit better!
Your History Lesson:
Ok so you know that the internet isn't some ancient and archaic invention that Romans used to calculate taxes...
(if you think this, seek help)
So, for the majority of users, you know the internet was a U.S military project and then educational and finally spread to what we have today.
We can simplify this by saying that the internet is the largest network on this planet and this network is the amalgamation of several smaller networks, hence the word: internetwork.
So, when networks got a bit more used in corporations, they started to notice a few problems.
The most major of these was compatibility between computers from different manufacturers (e.g IBM would only network with IBM and DECnet would only network with DECnet).
In fact, it's a bit like how so many Microsoft programs won't work on Linux unless you use an emulator.
So, basically the International Organization for Standardization (ISO) created the Open Systems Interconnection (OSI) Reference Model.
It was designed to help manufacturers create inter-operable network hardware/software in the form of protocols that everybody could use to design their stuff.
The OSI model is now the main architectural model for networks and shows how just about everything works on every level of the network, from the software used on your desktop, to the RJ45 run along the wall.
To simplify this, the OSI model is split into layers.
Ok, so before I go on explaining this, I'm going to post a little diagram so you can see what I'm talking about ;)
Ok, so you see 7 layers, each one for the different bit of the network.
This is very similar to how a school or a business might work;
You have senior management, accounting, I.T, HR, Marketing, Sales, Engineering.
Each of these sections has their own specific role but (in theory) work together so that the corporation works as a whole.
So the OSI model:
Divides the network communication process into smaller components letting you troubleshoot more easily
Allows compatibility between various companies thanks to standardization
Allows most network hardware and software to communicate
Prevents changes in one layer from affecting the others so your network doesn't kill itself as easily
So, to further simplify the OSI model, we can say that it consists of 4 lower layers and 3 higher layers.
The diagram explains roughly what each layer does so I won't bother telling you again but I'll try and explain each layer with a bit more detail:
The Application Layer:
Ok well the Application Layer is basically the closest layer to human interaction on the OSI Model.
This layer starts working as soon as it gets told that access to a network is going to be needed.
A typical use of network is what you're doing right now, you're reading this with your web browser (well most of you are).
The Application Layer kicks in as soon as a HTTP request is made because the browser calls the Application Layer and tells it what needs to be done so the user can get this web page.
Basically, the Application Layer acts as a middleman between the program (which doesn't play a part in the OSI Model) and the layer below it, allowing the browser to send orders down the entire protocol stack.
The Presentation Layer:
This is quite a nice layer, very simple to understand.
The layer is basically a translator and takes data from one format to the other (e.g plaintext -->
Encrypted text).
It ensures that the data sent from the Application Layer of one system can be read by the Application Layer of another (see the interoperability coming into play here?).
So basically, anything that gets compressed, decompressed, encrypted, decrypted and various other operations pass through the presentation layer.
The Session Layer:
Again another simple layer (see, this stuff isn't so hard really).
The Session Layer is in charge of sessions between Presentation layer entities.
It offers dialog control between devices and coordinates communications between different systems.
Basically, the Session Layer keeps data separated from other data (you would want your porn crossing with an email you're writing to your mum right?)
The Transport Layer:
The Transport Layer is pretty interesting, it segments (chops up) and reassembles data into a data stream (imagine tributaries of a river)
It provides end-to-end (like two people talking directly to each other) transport and can establish a logical connection (direct link) between the sending host and destination host on an internetwork.
TCP/IP, UDP and ICMP (amongst others) all work on this layer.
You should also remember that the layer is responsible for establishing sessions, tearing down Virtual Circuits, organizing upper-layer (the top 3) applications and hides details of network-dependent information from the highest layers by providing transparent data transfer.
The Transport Layer uses a lot of TCP/IP and you should be familiar with 3 Way Handshakes, packet format (SYN,ACK,REQ,URG,RECV,ID,DST,SRC,etc), windowing (how often acks are sent) and various other bits and pieces.
The Network Layer:
The Network Layer is another interesting layer and is very important!
It's responsible for device addressing, network device location tracking and determines the best way to route the traffic (even if the devices aren't locally attached).
Routers exist on the Network Layer and provide the routing services in an internetwork.
So, if a packet was sent to a router, the destination ip would be checked.
If the packet wasn't sent to the right router then it would look up the correct destination address in a routing table .
Once the router chooses an exit interface (where the packet will leave from) then it will send to that interface or failing that, drop the packet.
It's pretty similar to the Post Office really, if I knew the person's name but not the address then I'd write their name and general area on the envelope.
The envelope would be looked at in the Post Office's sorting office and the clerk (router) would put the envelope in the right slot or he'd think "what the fuck has this guy written?" and drop it in the bin.
But the network layer only likes two kinds of packets:
Data Packets: This is your bog standard data, be it text, hex, whatever.
It's like the letter in the envelope.
Router Update Packets: These remind the router about the various networks connected to them.
Protocols that send these packets are called Routing Protocols and are a bit like the address on the envelope.
Routing Tables:
I mention Routing Tables a moment ago, I better explain how they work.
Basically each protocol has it's own network address.
The router has to keep a record of the individual routing protocols because the routing protocol keeps track of a network with a different addressing scheme [IP (standard stuff), IPv6 (the secret to eternal happiness) and IPX (chatty Novell IP alternative)].
It's like those tourist signs in a million languages.
So yeah, that's what a routing table is.
Inside the routing table you get 3 columns:
Net (what I just explained above)
Int (Interface)
Metric
The Interface is pretty simple, it tells the router which exit a packet will take when it's going to network x.
Metric is pretty simple as well, it's the distance to the remote network and is measured in a variety of ways.
Most often it's a hop count, bandwidth, line delay or a tick count (1/18th of a second).
Ok so that's all understood?
Good :)
The Data Link Layer:
This is where we get a bit closer to hardware, the Data Link Layer physically transmits data and handles error notification (but not correction), topology and flow control.
Basically, this layer makes sure that messages get sent to the right play on a LAN using hardware address (e.g MAC addressing) and turns messages from the network layer into bits that hardware can transmit.
The data is turned into pieces by the Data Link Layer, each called a data frame and shoves in a header telling the data where to go and where it came from (like an envelope with a return address).
This is a process called encapsulation as the data is put into a little capsule surrounded by bits the Data Link Layer added in and that will be stripped away when the data reaches it's destination .
On this layer all the addressing goes on with MAC and LLC.
Switching occurs and binary/hex conversion is performed.
That's a shit load to write up for this topic but just google and you'll learn plenty!
The Physical Layer:
Ahhh, our last layer.
Did you have fun?
Well just wait, we're not quite done yet!
The physical layer is a rather simple creature, he doesn't have any of the fancy techniques of his friends in high places, he just sends bits and receives bits.
Bits are simple and are always in the form of 0 or 1.
These bits come in a couple of different forms, some come as audio tones, others change in voltage (State Transitions) but nothing too complicated goes on.
Basically this layer is responsible for the electrical, mechanical, procedural and functional requirements for a working network.
Conclusion:
Ok well I hope you enjoyed reading and maybe even learnt something!
For the sake of time and readability I've simplified this tutorial but by googling you can get detailed information on anything ;)
Ok well have fun!
Regards,
sas01
|
|
 |
|
 |
|
|
|
|
Posted 23 December 2007 - 09:43 PM
sas: I wrote a nice OSI article too, but it disappeared from the last CS restore.
I will upload it here.
Also, I used to have a nice layer by layer explaining what happens in each one from our daily compute activities, so this way it is better to visualize than using technical terminologies.
Quote: The OSI Reference Model
OSI Model was released on 1984 by ISO in order to provide standards reference of compatibility and interoperability to all the producers of network technologies.
The OSI Model defines network functions that happens at each layer.
There are 7 layers.
Through this guide lines you can better understand how data travel throughout a network.
Also you will have an understanding of how such txt files can travel in a wire to be shown in another remote host.
Layer7 - Application layer
Layer6 - Presentation layer
Layer5 - Session layer
Layer4 - Transport layer
Layer3 - Network layer
Layer2 - Data Link layer
Layer1 - Physical layer
Those layers provide you a better and quicker way to understand, develop and troubleshoot network problems if any occurred during data packet flow.
Layer7 - The Application Layer:
It is the closest layer to the user providing network services to applications.
The 7th layer does not have to be responsible for any other layer, since it is the last layer.
Applications that are outside of OSI model such as spreadsheet and word processing programs using Telnet, HTTP, and other protocols, are supported by the application layer giving availability of communication, synchronization and establishing agreement on procedures for error recovery and control of data integrity.
Layer6 - The Presentation Layer:
The 6th layer provides the readable part between two hosts sending data through the application layer.
It makes sure that users can read the data being transmitted.
That is where the data is encrypted and decrypted, its most important function.
Layer 6 graphic standards are PICT, TIFF, and JPEG, and for movies are MIDI and MPEG.
Layer5 - The Session Layer:
The 6th layer establishes, manages and terminates sessions between two hosts.
It provides services to the 6th layer(presentation layer), it also synchronizes dialogs between the host's presentation layer and manage their data exchange.
Protocols for layer 5 are NFS, X-Windows System and ASP.
Note: Basically Session layer is why you should log out every time you finish your connection to a certain host, such as hotmail, yahoo, forums or any other you need to login to have access.
Layer4 - The Transport Layer:
The transport layer does the breaking apart the packets and responsible for reassembling them into a data stream on the receiver host.
The 4th is where layers start not to concern much about application issues and more about data-transport issues.
Reability of transport between two hosts is the most concern of this layer.
Protocols used on this layer are TCP, UDP, and SPX.
Layer3 - The Network Layer:
A complex layer that provides connectivity and path selection between two hosts even been located geographically separated networks.
The 3rd layer is concerned with logical addressing.
Protocols are IP, IPX, and Apple Talk.
Layer2 - The Physical Layer:
Layer 2 concerns about electrical, mechanical, procedural, and functional specifications for activating, maintaining, and deactivating the physical layer between end systems.
Such as voltage levels, timing of voltages changes, physical data rates, maximum transmission distances, physical connectors, and other similar attributes.
Layer1 - Data Link Layer:
Data to be able to travel the source to its destination, each layer of the OSI at the source must communicate with its peer layer at the destination.
It's called peer-to-peer communication.
During this process, the protocols at each layer exchange information, called PDUs(Protocol Data Unit) between peer layers.
This layer is responsible for transforming data into 0s and 1s(bits) to travel through the wire to its destination.
OBS: As data moves through the layers of the OSI model, additional headers are added.
The grouping of data at the layer 4 is called a segment.
Destination logical addresses are added on the Network Layer when data is passing to the upper layer.
The data is encapsulated and a header is attached to create a Packet.
Hubs operate at Layer1, Switches at Layer2, and Routers at Layer3.
I hope you all enjoy my first tutorial.
Be minded that of course I did not create all this info.
I got references from Cisco books.
|
|
|
|
|
|
|
|
|
Posted 23 December 2007 - 09:58 PM
Yeah it's cool but it's like the beginning of the OSI model.
It's too simplistic for my tastes...
You could use that as a "Basic OSI model tutorial" though?
/me shrugs
cs.net should get less network nooby.
I'm not great but I learn more...
|
|
|
|
|
|
|
|
|
Posted 27 December 2007 - 04:01 AM
Tutorial or article, it will sure be helpful to a lot of people as an easily understandable entry to the topic.
I got a few suggestions:
Maybe you should mention the TCP/IP reference model and talk a little about how it's different from the OSI model, or why there's more than just one model.
The TCP/IP model was created even before the OSI model [1] .
Personally, if I have to explain networking concepts to others, I'd like to use the TCP/IP model rather than the OSI model, basically because the higher layers don't really have sharp boundaries.
It's easier to explain, and things tend to blur a little in the higher layers.
(Yes, I know that the article is about the OSI model, but still...
;) )
And think about leaving out that part about routing and the routing table.
Explaining routing imo doesn't really fit into a discussion of the OSI model.
Mention it, but don't explain.
This is a too complicated topic to be explained with a few sentences, anyway.
sas01, on Dec 21 2007, 02:29 PM, said:
"Basically each protocol has it's own network address."
[...]
"Protocols that send these packets are called Routing Protocols and are a bit like the address on the envelope."
I stumbled over these sentences, and they make me feel a little uneasy.
Trying to explain complicated issues in an understandable way is always good, but I believe you simplify too much in that whole routing paragraph.
I really believe it would be better if you'd just leave it out.
Protocols do not send anything.
Protocols describe how messages should be formated, sent, processed and so on, but they are not active participants.
Applications and hardware comply with protocols (more or less) or implement them.
Protocols provide a standard.
Routing protocols are not at all like the address on the envelope.
In TCP/IP-networks, the IP-address/port number combo is the address.
To use your simile, the router is the clerk, and he decides which way to send your letter according to the rules defined in whatever routing protocol is used.
And btw, if you skim through or even really read RFC 2328 (OSPF), you will never again say that "Metric is pretty simple".
;)
Adding a real-life example might help people in understanding the model and the concepts behind it.
I appreciate the time and effort you put into that article.
I'm sure it will help people who are new to the topic and who are in need of an easy summary to get them started.
This post has been edited by Memnoch : 27 December 2007 - 04:04 AM
|
|
|
|
|
|
|
|
|
Posted 07 January 2008 - 07:29 PM
Just a few things, I havent read everything word to word yet:
PrOtOn - You have layers 2 and 1 mixed up.
Although Im sure that was just an oversight :)
sas01 - You could mention what devices and addresses work at what layers: [Which I just saw PrOtOn mention in his]
Router = 3 | switch = 2 | hub, repeater = 1 etc etc.
MAC = 2 | IP = 3
It looks good though and it's definitely something people should read.
|
|
|
|
|
|
|
|
|
Posted 07 January 2008 - 10:44 PM
They are both good artilces, I'll read more closely and comment when I get chance.
The OSI model (and the other models) are weird in that they feel totally abstract when you first begin to learn them, but as you apply it, it becomes a really useful framework from which to design large scale internetworks and troubleshoot them (I love the moment when I can say, "This issue resides above layer 3, therefore is not my (a network) issue." (and therefore not my issue at work).
Then again, those Devs amongst us will think the exact opposite - "The code's good and I can see it hitting Layer 4, so whatever it is, it's the network team's problem." It really does help you break things down and understand where the problem is.
Adding physical devices to the layer decriptions always helps, it shows which deviced reside at which layer and from that you can instantly glean a lot of information on that device.
A layer 3 switch uses logical IP addressing, whereas a layer 2 one uses physical MAC addressing, so a layer 3 switch issue differs dramatically from a layer 2 switch issue.
If I am informed there is a problem with the switch, the first question that springs to my mind is, "Layer 2 or layer 3 switch?".
|
|
|
|
|
|
|
|
|
Posted 09 January 2008 - 10:15 PM
sas01, on Dec 21 2007, 12:29 PM, said:
Ahhh, our last layer.
Did you have fun?
Well just wait, we're not quite done yet!
The physical layer is a rather simple creature, he doesn't have any of the fancy techniques of his friends in high places, he just sends bits and receives bits.
Bits are simple and are always in the form of 0 or 1.
These bits come in a couple of different forms, some come as audio tones, others change in voltage (State Transitions) but nothing too complicated goes on.
LOL
The PHY is :
- a rather simple creature
- with no fancy techniques
- and nothing too complicated goes on
I nearly wet myself reading that : )
And to think I had so much trouble initially getting to grips with analysing QAM64 constellations and identifying skew anomalies due to stray moisture in cabling, the functioning of DMT itself, the NEXT/FEXT/ELFEXT PFELFEXT and how to measure and interpret issues from ACR and DSKEW to TDRIMT and exactly how the PHY layers critical margins for each type of media can deal with everything the media can throw at it.
When I studied the PHY it was where everything suddenly gets very very messy and damned hard to understand without an awful lot of nifty math - a far cry from the nice neat upper layer PDUs with their nice digital simplicity.
I think it is mainly coders and patchjockeys that have this feeling that once it gets below L2 everything suddenly becomes pretty much automatic - to everyone else it is all math'n'magic ;
)
Your guide to the OSI is certainly welcome.
I'd love to see you follow this up with some elementary packet formats in a future article just to show how the encapsulation looks in practice, that would be nice.
Oh, and please don't get me missunderstood - I am not criticising your treatment of the PHY which is probably best left to the real network nerds anyway.
: D
==DToX
|
|
|
|
|
|
|
|
|
Posted 09 January 2008 - 10:31 PM
DTox, this is for CCNA, play nice ;)
Whilst you are spot on, at this level all the magic is at layers 4-2.
That said sas, look at PrOtOn's description:
Layer1 - The Physical Layer:
Layer 1 concerns about electrical, mechanical, procedural, and functional specifications for activating, maintaining, and deactivating the physical layer between end systems.
DTox IS right, each of these layers goes much deeper as you will see when you start your CCNP later this year ;)
|
|
|
|
|
|
|
|
|
Posted 09 January 2008 - 10:50 PM
I think this miscperception exists because layer 2 and above are pretty much related to computer science, while layer 1 is electronic engineering all the way.
We never had more than maybe two or three CS students in our communication systems and modulation classes.
And, just like DTox indicated, there isn't much need for the average CS student to know that e.g.
Ethernet uses PAM-5, or what exactly QAM-64 is and how it works.
|
|
|
|
|
|
|
|
|
Posted 09 January 2008 - 10:58 PM
baph0m3t, on Jan 9 2008, 09:31 PM, said:
DTox, this is for CCNA, play nice ;)
Actually, I was being nice.
I let a lot go because I realise that this is a plain-english primer with a lot of poetic licence going on.
Some of the statements are a little off even within the limited understanding expected in the CCNA (which actually spends more time with media than the CCNP)...
But I let it slide because it is close enough for folks here.
I do understand the need to sidestep the complexity of L1 but this was the first time I heard someone actualy state that not much really goes on down there.
If anyone took offence then I do apologise : )
I only mentioned it because it made me laugh...
In a good way, not a cruel way.
Anyway, like I said, I encourage SAS to continue in the same vein, perhaps with his take on how the packet gets encapsulated as it travels through these layers, and what the more important fields in each header are responsible for.
I think that normally, until people see this laid out in terms of fields, the OSI model and the whole idea of layer PDUs are often a little too abstract and tend not to make much real sense to the uninitiated.
Basically, you've nailed the 'what'...
But I'd like to see you flesh out the 'why' and 'how'.
That would be cool.
But good work, keep it coming : )
==DToX
This post has been edited by DToX : 09 January 2008 - 11:10 PM
|
|
|
|
|
|
|
|
|
Posted 29 February 2008 - 03:30 PM
Hye, can i ask something about this OSI?
I have confusion over transport layer protocol..
:blink:
I google and found this site, just to make me more understand.
http://www.videsignl...l?term=OSImodel
Quote: transport layer performs a sequence check on the data and ensures that if a 12MB file is sent, the full 12MB is received.
How about UDP? Does this statement focus on TCP?
Actually, i need a scenario, such as sending a data, a sharing file, to make me understand much better..
Can someone give the example?
|
|
|
|
|
|
|
|
|
Posted 29 February 2008 - 03:38 PM
The layer 4 description on the site you linked to is only valid for TCP (I didn't bother to read the rest).
UDP does nothing of this, it's just fire-and-forget, to speak in military terms.
The UDP-Sender doesn't know or care if a packet is received or lost, and the receiver doesn't care if a packet is received in the right order or received at all.
There's no sequence checking, no error detection (apart from a UDP checksum check which is not mandatory), and UDP couldn't care less if from the 12 MB you send only 1 MB is received.
That functionality, if needed, must be provided by upper layers.
[reason for edit]
wrote something stupid :blush:
This post has been edited by memnoch : 29 February 2008 - 03:39 PM
|
|
|
|
|
|
|
|
|
Posted 29 February 2008 - 05:03 PM
Yeah, a good way to understand the difference between TCP and UDP is through understanding where they are used.
TCP would be the protocol of choice if you wanted to transfer a file to your mate across the internet, say the lastest Linux distro.
TCP is pretty slow, it does a lot of checking and that checking takes extra time, but it guarantees that you will get ALL of the file in the correct order - or nothing at all.
The reason for this is simple: why would you want to spend an hour transfering a 700MB file only to find that 3 out of 10,000 core files got corrupted or dropped during the transfer and so the whole file is corrupt and unusable?
So TCP is reliable, if anything gets dropped it requests that it is resent.
It's slow, but it's reliable.
*
Now UDP is, as you say, fire and forget: it's FAST, it just streams the data as fast as it can, doesn't wait for acknowledgements and doesn't bother checking very much.
As such packets can (and often do) get corrupted as they pass through the internet, but UDP doesn't care, it just keeps firing.
Why is this useful?
Well think of live video streaming, say a breaking news report.
Live video steaming will use UDP as the choice protocol because it really doesn't matter if a few packets get dropped, the overall effect is sufficient.
You're watching the news and the packet containing the information that tells your monitor to display a red pixel in the bottom left corner of the screen doesn't arrive and you get a little tiny corruption on your screen, the main show goes on - you're still listening to what the guy is saying because most of the traffic is getting through fine (just because UDP is called "unreliable" that doesn't mean it's not good at what it does, it uses a best-effort delivery system and is actually very reliable).
If that same video was being streamed with TCP, when your machine failed to send an ACK (acknowledgement) for that pixel everything would simply stop!
The screen would freeze while your computer requested a resend of that packet and, once it arrived correctly, you would see a tiny red blip at the bottom of your screen, then the video would immediately start to lag badly as the live stream would have continued in the real world and your computer now has to try to catch up....
Think about it, it suddenly gets REALLY messy.
So TCP for the stuff that needs to be 100% perfect and you have the time to wait in order for the appropriate checking to take place and UDP for jut about anything that happens in real time: VoIP, live TV, live radio, etc...
*Network Minutes Demystified
Here's an almost interesting footnote for you.
Familiar with network minutes?
You know, that unit of measurement under which a second can last anything from .
1 of a second to infinity?
You start to transfer a file and your computer immediately tells you that it will take 12 hours for that file to transfer...
Oh hang on 6 hours only kidding, 3 hours....
Had you going, 90 mins....
- that's mainly down to TCP windowing which is basically the server throwing larger and larger chunks of data at the client until the client simply cannot handle the speed and drops a couple of packets, then the server backs off and reduces the size of the chunk ("window"), then tries again.
Once it has worked out the maximum window size that the client can accept in one chunk, then the transfer speed is established and the transfer stablises.
So basically it is saying, "If I send one bit of data at a time this file will take 12 hours to transfer, so let's see if this client can receive more packets in one chunk - have 2....
Did you get that?
Yep? OK, then it will take 6 hours.
Let's see if you can catch 4 at a time...
Yep? Good, then it will take 3 hours.
Can you take 8? Yes?
Then it's going to take 90 mins."
|
|
|
|
|
|
|
|
|
Posted 29 February 2008 - 05:31 PM
well, that's totally clear view for me about these two tcp and udp..
:rolleyes:
but,the scenario that i just asking before this is about OSI, not udp or tcp..
Sorry for make a silly mistake..
But, honestly, thanks to that silly mistake, i gain more knowledge and scenario about tcp and udp..
|
|
|
|
|
|
|
|
|
Posted 29 February 2008 - 05:51 PM
Oh sorry m8, I see what you are asking.
On that page the guy defines layer 4 as
Quote: Transport Layer 4
This layer is responsible for overall end to end validity and integrity of the transmission.
The lower layers may drop packets, but the transport layer performs a sequence check on the data and ensures that if a 12MB file is sent, the full 12MB is received.
"OSI transport services" include layers 1 through 4, collectively responsible for delivering a complete message or file from sending to receiving station without error.
which is not strictly accurate.
It looks like the writer specifically has TCP in mind which is a layer 4 protocol, but he has forgotten UDP where a 12MB file may be sent and only 11.9MB received.
Layer 4 is, to most engineers, the most important layer since it is here that the network really comes into play.
Layers 7,6,5 are only interested in the data, data formatting, data presentation, etc but at layer 4 something magical happens - the network gets activey involved.
Layer 4 SEGMENTS / desegments the data, encapsulates these segments inside a header (stating source and destination ports - ports come into play at L4 - important point) and decides what network transfer protocol it will use (normally TCP or UDP).
|
|
|
|
|
|
|
|
|
Posted 01 March 2008 - 05:30 PM
I read an article about arp yesterday to improve my knowledge about ISO, i try to read as many as i can until i fully understand.
^_^
correct me if i'm wrong, if the packet is sending into local LAN only, does it will involve with network layer?
And if i sending a packet to the internet, the network layer will use?
True?
|
|
|
|
|
|
|
|
|
Posted 01 March 2008 - 07:11 PM
gamekiller, on Mar 1 2008, 05:30 PM, said:
I read an article about arp yesterday to improve my knowledge about ISO, i try to read as many as i can until i fully understand.
^_^
correct me if i'm wrong, if the packet is sending into local LAN only, does it will involve with network layer?
And if i sending a packet to the internet, the network layer will use?
True?
If a packet has a destination within the local LAN it will still use every layer of the OSI model (usually, there are cases where it doesn't).
If the destination is in the "Internet" then again, all the layers will be used.
Baph:
Quote: Well think of live video streaming, say a breaking news report.
Live video steaming will use UDP as the choice protocol because it really doesn't matter if a few packets get dropped, the overall effect is sufficient.
You're watching the news and the packet containing the information that tells your monitor to display a red pixel in the bottom left corner of the screen doesn't arrive and you get a little tiny corruption on your screen, the main show goes on - you're still listening to what the guy is saying because most of the traffic is getting through fine (just because UDP is called "unreliable" that doesn't mean it's not good at what it does, it uses a best-effort delivery system and is actually very reliable).
If that same video was being streamed with TCP, when your machine failed to send an ACK (acknowledgement) for that pixel everything would simply stop!
The screen would freeze while your computer requested a resend of that packet and, once it arrived correctly, you would see a tiny red blip at the bottom of your screen, then the video would immediately start to lag badly as the live stream would have continued in the real world and your computer now has to try to catch up....
Think about it, it suddenly gets REALLY messy.
CBT Nuggets :D
|
|
|
|
|
|
|
|
|
Posted 01 March 2008 - 07:55 PM
Yep, I've watched a fair few of those vids - the new revised CCNA is actually very good and I had heard that our Jeremy had devised a new system of subnetting, have you done that one yet?
Although he claims he is not shortcutting, he actually is and it's a very effective system for quick network / host calcs.
Good to see you're keeping up with it :D
Quote: If a packet has a destination within the local LAN it will still use every layer of the OSI model (usually, there are cases where it doesn't).
What he means here is that a LAN is basically a switched network that runs on switches, not routers: the addition of a router immediately qualifies the LAN as a WAN.
As such, all addressing is dealt with at the physical layer (layer 2) - MAC, not IP.
So it doesn't get a layer 3 (IP) header a router just drops anything that is bound for a local machine.
|
|
|
|
|
|
|
|
|
Posted 08 March 2008 - 11:51 PM
To help remember the order of the layers and such.
A pplication P resentation S ession T ransport N etwork D atalink P hysical:
A ll P orn S tars T ake N aked D irty P ictures.
and:
Data Data Data S egments P ackets F rames B its
S ome P eople F *** B etter
LOL
I always remember them now.
|
|
|
|
|
|
|
|
|
Posted 17 March 2008 - 08:59 PM
P lease D o N ot T hrow S alami P izza A way is the sentence that helped me remember the names :)
|
|
|
|
|
|
|
|