TCP/IP architecture model

1. Network interface(Data link) layer
2. Network layer
3. Transport layer
4. Application layer


Network interface layer
The lowest layer of the TCP/IP model. Its task is to provide access to the transmission physical medium and it differs according to the implementation of the medium.

Network layer
The network layer provides network addressing, routing and datagram transmission. Used protocols that will be of interest further regarding DHCP are IP and ARP.

IP protocol
It is the basic protocol of the network layer and in general the internet as a whole. It sends datagrams, which are independent units that contain information about the destination, source and the sequence number of the datagram. The sequence number is used for message reconstruction, since the delivery order of the datagrams might not be the same as their order in the message and delivery reliability isn't guaranteed at all.
IP protocol versions:
" IP v4 - 32 bit addresses. Provides approximately 4 billion unique addresses which aren't sufficient at present times.
" IP v6 - 128 bit addresses. The transition to v6 will bring (is bringing) higher security, QoS, packet segmentation and many more IP addresses. (the transition from IP v4 to IP v6 must be supported by the system provider)


ARP protocol
The ARP abbreviation stands for Address Resolution Protocol. This protocol is used to find the physical address (MAC) based on a known IP address. If required ARP sends information concerning the wanted address to all the stations in the network - Broadcast. The stations consequently answer with a message containing their MAC. If the wanted device/station is outside the node/segment, the appropriate router will answer instead of it.

Transport layer
The transport layer is implemented only in terminal devices and it adjusts the behavior of the network according to the requirements of the device/application.



Application layer
The application layer is composed of programs that use net services to fulfill the needs of users. Examples of specific protocols are for instance FTP, DNS and DHCP.
Application protocols use TCP, UDP or both services at the same time. So called ports are used to differentiate between application protocols, they represent a type of label of the application. It is possible to change the ports in the settings of the service, but each service has a default port that isn't changed for most services and is used as an unwritten standard.

" FTP = 21
" DNS = 53
" DHCP = 67 + 68

Cisco CCNA Exam Tutorial: Mapping The OSI Model To The TCPIP Model

The OSI model is the model that most networking personnel are familiar with, but to earn your CCNA, you need to know the OSI model, the TCP/IP model, and how the two map to each other.

The four layers of the TCP/IP architecture can be compared to certain levels of the OSI model. It’s important to know what each level of the TCP/IP protocol architecture does, and how these layers map to the OSI model.

The Application Layer of the TCP/IP model performs much the same tasks as the Application, Presentation, and Session layers of the OSI model.

The Transport layer in the TCP/IP architecture is similar to the Transport layer in the OSI model. This layer can use TCP or UDP as well.

The Internetwork layer in the TCP/IP architecture uses IP addresses to determine how packets should be routed. Remember that the OSI model uses IP addresses, or “Layer 3 Addresses”, at the Network layer. The two layers do much the same thing. This layer is also referred to in the TCP/IP model as the Internet layer.

The Network Interface layer in the TCP/IP architecture serves to define the protocols and the hardware needed to actually deliver the data across the network. The Network Interface model does the work of both the Data Link and Physical Layers in the OSI model.

Keeping all this straight can be very confusing when you first start your CCNA studies. Concentrate on the OSI model in your studies, but make sure you know how the TCP/IP model maps to that model and you'll be ready for CCNA exam success!

Cisco CCNA Certification: Error Detection vs. Error Recovery

Passing the CCNA, Intro, and ICND exam is all about knowing and noticing the details. (Which makes perfect sense, since becoming a master networking administrator or engineer is also about noticing the details!) One such detail knows the difference between error detection and error recovery. While the terms are sometimes used interchangeably, they are not the same thing.

Error detection is just that - error detection only. Two common error detection methods are found at the Data Link layer of the OSI model, the FCS (Frame Check Sequence) and CRC (Cyclical Redundancy Check). A mathematical equation is run against the data in the frame, and the result is sent along with the data. The receiver runs the equation again, but this time. If the result is the same, the frame is considered valid; if the result is different, the frame is considered corrupt and is discarded.

Note that the FCS and CRC do nothing in regards to retransmission. They are strictly error detection schemes.

For an example of error recovery, we look to the Transport layer, where TCP runs. TCP performs reliable delivery, and the reason we call it "reliable" is that TCP uses sequence numbers to detect missing segments. If the sender determines from the sequence numbers that the remote host did not receive transmitted segments, the sender will retransmit the missing segments.

The key to keeping the terms straight in your head is to remember that while both error detection and error recovery both detect problems, only error recovery does anything about it. It's also worth reading an exam question twice when you see either term!

CCNP Certification / BSCI Exam Tutorial: The BGP Neighbor Process

Like TCP, BGP is connection-oriented. An underlying connection between two BGP speakers is established before any routing information is exchanged. This connection takes place on TCP port 179. As with EIGRP and OSPF, keepalive messages are sent out by the BGP speakers in order to keep this relationship alive.

Once the connection is established, the BGP speakers exchange routes and synchronize their tables. After this initial exchange, a BGP speaker will only send further updates upon a change in the network topology.

The IGP protocols that use Autonomous Systems, IGRP and EIGRP, require prospective neighbors to be in the same AS. This is not true with BGP. Routers can be in different Autonomous Systems and still exchange routes. The BGP neighbors do not have to be directly connected, and often are not, but do need to be able to reach the IP addresses they use in their neighbor statements.

A BGP peer that is in the same AS is referred to as an Internal BGP (iBGP) Peer, where a BGP peer in another AS is an External BGP (eBGP) Peer.

A sample iBGP configuration:

Router bgp 100

Neighbor 10.1.1.2 remote-as 100


A sample eBGP configuration:

Router bgp 100

Neighbor 10.1.1.2 remote-as 200

Cisco recommends that eBGP peers be directly connected, where iBGP peers generally will not be.

Before we get too much farther into BGP theory, let’s get a configuration started. You’ll use the router bgp command to configure a router as a BGP speaker. Right after that, the neighbor command will be used to identify this BGP speaker’s potential neighbors. (The terms "peer" and "neighbor" are interchangeable in BGP, but it's the neighbor statement that is used to statically define neighbors. BGP is not capable of discovering neighbors dynamically.)

R1(config-router)#neighbor 172.12.123.3 remote-as 200

While almost all of the neighbor options are just that -- optional -- you do have to specify the BGP AS of the remote router. BGP has no mechanism to dynamically discover neighbors. Remember, BGP speakers do not have to be in the same AS to become peers. To verify that the remote BGP speaker has become a peer, run show ip bgp neighbor.


R1#show ip bgp neighbor

BGP neighbor is 172.12.123.3, remote AS 200, external link

BGP version 4, remote router ID 0.0.0.0

BGP state = Active

Last read 00:01:39, hold time is 180, keepalive interval is 60 seconds

Received 0 messages, 0 notifications, 0 in queue

Sent 0 messages, 0 notifications, 0 in queue

Route refresh request: received 0, sent 0

Default minimum time between advertisement runs is 30 seconds

The output here can be a little misleading the first time you read it. The first highlighted line shows 172.12.123.3 is a BGP neighbor, is located in AS 200, and is an external link, indicating that the neighbor is in another AS entirely. The second highlighted line shows the BGP state as Active. This sounds great, but it actually means that a BGP peer connection does not yet exist with the prospective neighbor.

So even though the show ip bgp neighbor output indicated that this is an Active neighbor relationship, that’s not as good as it sounds. Of course, the reason the peer relationship hasn’t been established is that we haven’t configured R3 yet!


R3(config)#router bgp 200
R3(config-router)#neighbor 172.12.123.1 remote-as 100

Verify the peer establishment with show ip bgp neighbor:

R3#show ip bgp neighbor

BGP neighbor is 172.12.123.1, remote AS 100, external link

BGP version 4, remote router ID 172.12.123.1

BGP state = Established, up for 00:01:18

Last read 00:00:17, hold time is 180, keepalive interval is 60 seconds

Local host: 172.12.123.3, Local port: 179 (BGP uses TCP Port 179)

Foreign host: 172.12.123.1, Foreign port: 11007
The peer relationship between R1 and R3 has been established.

Now that you know how the neighbor relationship itself is built, you need to start learning the many options of the neighbor command. You’ll have to master these to become a CCNP and CCIE!