Understanding the OSI model

 In this lesson, we explain what the OSI model is in an easy and understandable language. It is one of the most important concepts in networking, so we break it down into pieces to help you understand exactly what its purpose is.

What is data encapsulation?

To understand the OSI model, you must first understand what data encapsulation is. Let's explore the following example. Imagine you want to send a letter to a friend who lives in another city to invite him to your wedding. What if you send the letter without an envelope, with any information, such as the sender's and recipient's names, addresses, and postcodes? What if you simply write the letter and drop it in the mailbox at the post office? 





Most readers of this CCNA course are so young that they've never sent a physical letter in their lives. They live in the digital age and have grown up with emails and instant text messages. However, surprisingly, everyone understands the concept of the post service and sending mail.

Let's examine the following two examples: a letter without an envelope (on the left) and one placed inside an envelope with all required information written on top (on the right). If you put those two into your mailbox, which one will reach its intended recipient and which one won't?



#cisco #networking #OSI #model

It is pretty obvious, right? If you send a letter with no envelope and no additional information, such as sender and recipient details, the postal service won't know where to deliver it. The letter won't reach anyone. Your friend won't show up at your wedding.

To ensure that the information (the letter) is delivered to the correct recipient, we must include additional information alongside the letter, so that the postal service knows how to handle it (we encapsulate the data).



The envelope that encapsulates the letter contains the following information, which helps the postal service deliver the letter correctly:

  • Stamp and postcard
  • Sender's name
  • Sender's address
  • Sender's postcode
  • Recipient's name
  • Recipient's address
  • Recipient's postcode

Optionally, the envelope may include:

  • Return address (if different from the sender’s address)
  • Date and time stamp
  • Subject or reference line inside the letter (in formal letters)

The main idea is that sending letters equals sending information by utilizing the postal service as the medium. Sending emails is the same—it’s still a process of sending information, but through a computer network. The key point is that in both cases, you can’t send just the information alone; you need to include extra details that tell the transporting medium how to deliver the information.



Data Encapsulation in Networking

Computer networks function similarly to the postal service. The difference is that they move digital information instead of paper letters. However, you can’t just send raw data onto the network and expect it to reach the destination, just like you can’t drop a plain letter into a mailbox and expect it to be delivered. The data must be encapsulated with additional information first, as shown in the diagram below.







Imagine a device (like your laptop) wants to send data onto the network. Let's say you're sending a Facebook message to a friend. As you type the message and hit enter, the data goes from the web browser (where you have Facebook opened), to the Operating System (OS), to the NIC, and out to the network. Many processes add their own additional information called headers. These headers contain important details, like:

  • Who the data is for.
  • Where did it come from?
  • How it should be delivered.
  • What type of data is it?

In the end, the simple Facebook message "Hey! What's up?" looks like a network packet encapsulated with multiple headers, as shown in the diagram below.



At the destination, the data undergoes the reverse process of removing headers before the it is presented to the correct application.

Why do we need the OSI model?

The process of data encapsulation is not simple. It involves many different protocols, headers, and steps. Each part of a network—like applications, network devices, and physical mediums—needs to know what to do with the data and how to handle it correctly.

In the early days of networking, different companies built their own systems, using their own encapsulation methods. These systems often couldn’t work together because they didn’t follow the same rules. For example, one vendor might add certain headers in a unique order that another vendor's device couldn't understand. This made it hard to send data between different networks or even between devices from the same company.

Additionally, to achieve the ultra-high speeds of today's networks, network devices must precisely locate the information they need, without examining headers that are irrelevant, as shown in the diagram below.

.

To fix this, engineers realized that the industry needed a standard framework. They needed a common way to describe how data should be prepared, sent, and received. That’s where the OSI model comes in.

The OSI model gives a step-by-step structure for how data encapsulation should work:

  • Each layer has a specific job, like adding source and destination addresses or checking for errors.
  • Each layer uses specific protocols that follow agreed-upon rules.
  • Each layer adds its own header (and sometimes trailer) to the message, so the receiving system knows how to process it.

In short, the OSI model helps manage the complexity of data encapsulation by providing a clear, standard method that everyone in networking can use. This ensures interoperability, consistency, and easier troubleshooting.

The OSI model helps us understand and explain how data is wrapped up layer by layer (encapsulation), and how it's unwrapped at the other end (de-encapsulation).

What is the OSI model?

The OSI model, or Open Systems Interconnection model, is a framework that breaks down the encapsulation process into seven layers. Each layer has a specific role and handles a part of the encapsulation, such as data formatting, logical addressing, routing, physical addressing, or error checking.

The following example shows how data moves through the OSI layers and gets wrapped at each step before being sent over the network to the next device. Notice that each layer adds its own specific header with relevant information for the network function.




The primary goal of the OSI model is to establish a standard and vendor-agnostic data encapsulation framework. It helps different devices and systems work together by following the same set of rules and standards. 

The following diagram illustrates each layer, with a brief description and the protocols that operate at that layer. Notice that in general, different network devices operate at different layers of the OSI model. This means that a network device cares only for the headers up to a particular layer and doesn't care about the rest of the headers in the message. For example, a switch only cares about the data link (layer 2) header, which consists of the source and destination MAC addresses. A router cares only about the layer 2 and layer 3 headers, and so on.







Note also that we refer to the data at each layer of the OSI model with a different term. For example, at layer 4, we refer to a TCP message as a segment. At layer 3, we refer to it as a packet. At layer 2, we refer to it as a frame.

The OSI model vs. TCP/IP model

The OSI model, with its seven layers, is a well-structured and useful way to understand how data encapsulation works. However, network engineers quickly notice that layers 5, 6, and 7 are not directly related to most networking tasks. These layers focus more on how software applications handle data, which is usually outside the scope of networking.

As a result, network professionals, through practice and real-world experience, began using a simpler model that focuses on the aspects that matter most to networking—Layers 1 through 4. This led to the development of the TCP/IP model, which has fewer layers and is more aligned with how networks actually operate.

The following diagram shows a comparison of the OSI model (with 7 layers), the first version of TCP/IP (which had 4 layers), and the modern version of the TCP/IP model (with 5 layers).


The modern 5-layer TCP/IP model uses the same names as the OSI model for the lower layers, and their jobs are very similar. So, when reading about networks or talking to others in the field, you can think of the lower four layers as being the same in both models- OSI and TCP/IP.

For this course, make sure you understand how the 5-layer TCP/IP model maps to the 7-layer OSI model (as shown in both ends of the diagram above). Also, remember that when people refer to “Layer 7,” they typically mean the top layer in both models, which handles applications.

For example, you will often hear one of the following phrases that you must understand:

  •  "Do you need a layer 2 or a layer 3 port?"
  •  "Is this a layer 2 or layer 3 switch?"
  •  "The problem is at layer 2."

Although networks today use TCP/IP, many people still refer to OSI layer numbers. For example, people call an application protocol a “Layer 7 protocol,” even though TCP/IP combines some of those OSI layers (application, presentation, and session) into just one.



Key Takeaways on the OSI Model

  • The OSI model is a theoretical framework that breaks down the data encapsulation process into seven layers
  • Each layer describes the information included in the message as a header.
  • The OSI model remains widely used to teach networking and explain how protocols function. 
  • However, while Cisco includes the OSI model in the CCNA/CCNP exams, knowing more than the basics isn’t very useful in real-world networking today. 
  • It’s essential to know the first four layers as they are the ones that concern network engineers the most.

Understanding Cisco SD-WAN Architecture: A Deep Dive into Control and Management Plane Functions

 Cisco SD-WAN revolutionizes network management by decoupling the control and management planes from WAN edge routers, centralizing them in software-based controllers. This architectural shift improves security, availability, and scalability, making Cisco SD-WAN a preferred choice for managing large and distributed networks.

In this blog post, we’ll explore the roles of vEdge routers and the SD-WAN controllers, namely vSmart, vManage, and vBond, each of which interacts with WAN edge devices in unique ways to ensure secure, streamlined, and reliable control connections.

Control Connections and Security Protocols

Each vEdge router establishes secure control connections to SD-WAN controllers using DTLS or TLS protocols. DTLS, which operates over UDP, is the default protocol due to its efficiency and speed, while TLS, running over TCP, provides slightly enhanced reliability. These protocols create secured tunnels that shield the control plane protocols (such as OMP, NETCONF, and SNMP) from security vulnerabilities by running them over encrypted channels.

Controller Roles Explained

  • vSmart acts as the central brain of the network, handling routing information and distributing policy-driven paths via the Overlay Management Protocol (OMP).
  • vManage is the configuration hub, interacting with vEdges through protocols like NETCONF, SNMP, and ICMP for configuration management and monitoring.
  • vBond serves as the orchestrator, assisting newly connected routers in finding their respective SD-WAN controllers and ensuring they securely join the network.

Deployment Options and Control Connections

For a new vEdge router, there are several options for connecting to the Cisco SD-WAN overlay, including Zero-Touch Provisioning (ZTP), Plug-and-Play (PnP), and manual CLI configuration. Once connected, each router establishes a DTLS/TLS tunnel to vSmart and vManage for ongoing management and control, ensuring a resilient network fabric.

Control Plane Overview and Data Plane Connections

Each WAN edge device in the SD-WAN fabric initiates IPsec tunnels across remote locations. Cisco SD-WAN’s overlay design uses these encrypted data plane tunnels for secure data transmission across the network. This approach allows organizations to achieve high performance and reliability across geographically distributed networks.

Whether you're working on a new Cisco SD-WAN deployment or seeking a better understanding of secure control plane connections, Cisco SD-WAN architecture provides the flexibility and security required in today’s dynamic network environments.

Stay tuned for more networking insights!





TROUBLESHOOTING BGP/MPLS ON CISCO AND JUNIPER DEVICES

 

TROUBLESHOOTING BGP/MPLS ON CISCO AND JUNIPER DEVICES


Mastering the Basics: Troubleshooting BGP/MPLS on Cisco and Juniper Devices

Introduction:
In the intricate world of networking, BGP (Border Gateway Protocol) and MPLS (Multi-Protocol Label Switching) are fundamental technologies that enable efficient, scalable, and robust communication across vast and diverse infrastructures. Understanding how to troubleshoot these protocols in Cisco and Juniper devices is essential for maintaining a smooth operational network. Today, we’ll dive into some practical tips to help you navigate common issues with these technologies.

Understanding BGP/MPLS Basics:

  • BGP: As the backbone of the internet, BGP makes routing decisions based on paths, network policies, or rule sets, which allows it to be very flexible and robust. However, it can also be complex and challenging to troubleshoot.
  • MPLS: MPLS enhances the flow of traffic on a network by making data forwarding decisions based on short path labels rather than long network addresses, simplifying and speeding up the process.

Common Issues and Troubleshooting Steps:
Cisco:

  1. Neighbor Issues: Use show ip bgp summary to check if BGP sessions are established correctly. Look for states that might indicate problems, such as “idle” or “active”.
  2. Route Advertisement Problems: The command show ip bgp neighbors <neighbor IP> advertised-routes is crucial for troubleshooting issues related to route advertisements.
  3. MPLS Label Problems: Use show mpls ldp bindings and show mpls forwarding-table to troubleshoot label distribution and forwarding issues, ensuring labels are correctly assigned and used.

Juniper:

  1. Session Troubleshooting: show bgp summary can help you diagnose session problems by indicating whether BGP sessions are up and how long they’ve been established.
  2. Route Reception Issues: To inspect received routes, use show route receive-protocol bgp <neighbor IP>.
  3. MPLS Path Troubleshooting: show mpls lsp extensive provides detailed information on the status and health of Label Switched Paths.

Advanced Troubleshooting Techniques:

  • Use extensive logging and event management tools to capture data about network performance and anomalies, which is invaluable for diagnosing intermittent issues.
  • Employ tools like traceroute with MPLS options (traceroute mpls on Cisco and traceroute routing-instance <instance name> on Juniper) to diagnose path selection and connectivity issues across your MPLS network.
  • Engage with external resources such as BGP looking glasses and route servers to understand how your network is perceived from the outside and to troubleshoot external routing issues.

Best Practices:

  • Continuous Monitoring: Implementing SNMP or NetFlow can help you keep an ongoing check on network performance and quickly pinpoint areas needing attention.
  • Regular Updates and Patches: Keep your network devices updated to mitigate security risks and improve functionality.
  • Knowledge Sharing: Encourage regular training sessions within your team to ensure all members are up-to-date with the latest troubleshooting techniques and tools.

Conclusion:
Troubleshooting BGP and MPLS effectively requires not only a deep understanding of the protocols but also a systematic approach to diagnosing and resolving issues. With these tips and techniques, you can enhance your network’s reliability and performance, ensuring that communication flows smoothly and efficiently.

Call to Action:
Have you encountered a tricky network issue or have additional tips to share? Comment below.

#cisco #juniper #bgp #mpls #troubleshooting

Types of Links on Switches

Types of Links  that can be created on a Network Switch


Video Tutorial link given at end

ACCESS LINKS

Access Links are the most common type of links on any VLAN switch. All network hosts connect to the switch's Access Links in order to gain access to the local network. These links are your ordinary ports found on every switch, but configured in a special way, so you are able to plug a computer into them and access your network.

knowledge streams blog spot dot com free knowledge blog. download free source codes for python and java and other free stuff.

We must note that the 'Access Link' term describes a configured port - this means that the ports above can be configured as the second type of VLAN links - Trunk Links. What we are showing here is what's usually configured as an Access Link port in 95% of all switches. Depending on your needs, you might require to configure the first port (top left corner) as a Trunk Link, in which case, it is obviously not called a Access Link port anymore, but a Trunk Link!
When configuring ports on a switch to act as Access Links, we usually configure only one VLAN per port, that is, the VLAN our device will be allowed to access. If you recall the diagram below which was also present during the introduction of the VLAN concept, you'll see that each PC is assigned to a specific port:

TRUNK LINKS

What we've seen so far is a switch port configured to carry only one VLAN, that is, an Access Link port. There is, however, one more type of port configuration which we mentioned in the introductory section on this page - the Trunk Link.

knowledge streams blog spot dot com free knowledge blog. download free source codes for python and java and other free stuff.

A Trunk Link, or 'Trunk' is a port configured to carry packets for any VLAN. These type of ports are usually found in connections between switches. These links require the ability to carry packets from all available VLANs because VLANs span over multiple switches.
The diagram below shows multiple switches connected throughout a network and the Trunk Links are marked in purple colour to help you identify them:



As you can see in our diagram, our switches connect to the network backbone via the Trunk Links. This allows all VLANs created in our network to propagate throughout the whole network. Now in the unlikely event of Trunk Link failure on one of our switches, the devices connected to that switch's ports would be isolated from the rest of the network, allowing only ports on that switch, belonging to the same VLAN, to communicate with each other.
So now that we have an idea of what Trunk Links are and their purpose, let's take a look at an actual switch to identify a possible Trunk Link:

knowledge streams blog spot dot com free knowledge blog. download free source codes for python and java and other free stuff.




As we noted with the explanation of Access Link ports, the term 'Trunk Link' describes a configured port. In this case, the Gigabit ports are usually configured as Trunk Links, connecting the switch to the network backbone at the speed of 1 Gigabit, while the Access Link ports connect at 100Mbits.
In addition, we should note that for a port or link to operate as a Trunk Link, it is imperative that it runs at speeds of 100Mbit or greater. A port running at speeds of 10Mbit's cannot operate as a Trunk Link and this is logical because a Trunk Link is always used to connect to the network backbone, which must operate at speeds greater than most Access Links!

knowledge streams blog spot dot com free knowledge blog. download free source codes for python and java and other free stuff.

Video Tutorial for Configuration of Trunk Link and VLANS



#CCNA #CIsco #Networking #Tutorial #Video #Picture #Diagram #trunk #link #Router #switch #connection #3550 #Speed #Security #training #HCNA #HCIA #CCNP #HCNP

Featured Post

Day 41 — BGP Confederations: Sub-AS Design, External View and Migration

1. Opening Confederations are another way to scale BGP inside a large administrative domain. They divide the domain into member autonomous systems while presenting a single confederation identifier to external peers. They are powerful, but their operational model is more complex than simply 'using private ASNs inside.' The engineering goal is not to memorize another BGP command. It is to understand what information each speaker is allowed to propagate, what path information can be hidden, and what failure domain is created by the chosen control-plane architecture . 2. Concept and standards behavior RFC 5065 defines AS_CONFED_SEQUENCE and AS_CONFED_SET and how member-AS relationships are represented. Confederation external sessions have eBGP-like properties inside the confederation, while the confederation is presented externally as one AS. Modern guidance must also account for the fact that RFC 9774 prohibits new origination of AS_SET/AS_CONFED_SET in ordinary aggregation c...