Basic using OSPF and ACL LAB with solution

 #CCNA #LAB #ACl #OSPF 

Basic using OSPF and ACL.

The goal is practicing with the basic commands of OSPF and standard ACLs. You must do the next configurations:

1. - Configure the IP addresses as:

               - Host A: 10.1.1.1/24. Gateway: 10.1.1.3

               - Host B: 10.1.1.2/24. Gateway: 10.1.1.3

               - R1´s G0/0: 10.1.1.3/24

               - Host C: 10.3.3.3/25. Gateway: 10.3.3.1

               - R1´s G0/1: 10.3.3.1/25

               - S1: 10.2.2.1/24. Gateway: 10.2.2.3

               - S2: 10.2.2.2/24. Gateway: 10.2.2.3

               - R2´s G0/0: 10.2.2.3/24

               - R1´s S0/3/0: 10.4.4.1/30

               - R2´s S0/3/0: 10.4.4.2/30

 

               Check that you can ping between hosts in the same subnet:

 

               - From Host A to Host B.

               - From Host C to R1´s G0/1 interface.

               - From S1 to S2.

               - From R1´s S0/3/0 interface to R2´s S0/3/0 interface.

 

Note that you can´t ping between hosts in different subnets because the routers don´t have any entry in their routing table.

 

2. – Enable OSPF in all interfaces both R1 and R2 (area 0) with only one subcommand in the OSPF configuration.

Check that the neighboring relationships have been created between R1 and R2.

Check that, after configuring OSPF, you can ping between hosts in different subnets.

               - From Host A to Host C.

               - From Host C to S1.

               - From Host A to S1.

 

2. – Configure ACL on the right routers, interfaces and directions based on these requirements:

               - Permit packets from S1 going to subnet of hosts A and B.

               - Deny packets from S2 going to subnet of host A and B.

               - Permit packets from S2 going to subnet of host C.

               - Deny packets from S1 going to subnet of host C.

 

After configuring ACL, check that:

 

               - You can ping from S1 to host A and B, but not to host C.

               - You can ping from S2 to host C, but not to hosts A and B.

Solution

The solution is marked as bold an italic.

The goal is practicing with the basic commands of OSPF and standard ACLs. You must do the next configurations:

1. - Configure the IP addresses as:

               - Host A: 10.1.1.1/24. Gateway: 10.1.1.3

                              IP: 10.1.1.1

                              Mask: 255.255.255.0

                              Gateway: 10.1.1.3

               - Host B: 10.1.1.2/24. Gateway: 10.1.1.3

                              IP: 10.1.1.2

                              Mask: 255.255.255.0

                              Gateway: 10.1.1.3            

               - R1´s G0/0: 10.1.1.3/24

                              Router>enable

                              Router#configure terminal

                              Router (config)#interface g0/0

                              Router (config-if)#ip address 10.1.1.3 255.255.255.0

                              Router (config-if)#no shutdown

                              Router (config-if)#end

               - Host C: 10.3.3.3/25. Gateway: 10.3.3.1

                              IP: 10.3.3.3

                              Mask: 255.255.255.128

                              Gateway: 10.3.3.1            

               - R1´s G0/1: 10.3.3.1/25

                              Router#configure terminal

                              Router (config)#interface g0/1

                              Router (config-if)#ip address 10.3.3.1 255.255.255.128

                              Router (config-if)#no shutdown

                              Router (config-if)#end

               - S1: 10.2.2.1/24. Gateway: 10.2.2.3

                              IP: 10.2.2.1

                              Mask: 255.255.255.0

                              Gateway: 10.2.2.3            

               - S2: 10.2.2.2/24. Gateway: 10.2.2.3

                              IP: 10.2.2.2

                              Mask: 255.255.255.0

                              Gateway: 10.2.2.3            

               - R2´s G0/0: 10.2.2.3/24

                              Router>enable

                              Router#configure terminal

                              Router (config)#interface g0/0

                              Router (config-if)#ip address 10.2.2.3 255.255.255.0

                              Router (config-if)#no shutdown

                              Router (config-if)#end

 

               - R1´s S0/3/0: 10.4.4.1/30

                              Router#configure terminal

                              Router (config)#interface s0/3/0

                              Router (config-if)#ip address 10.4.4.1 255.255.255.252

                              Router (config-if)#no shutdown

                              Router (config-if)#end

 

               - R2´s S0/3/0: 10.4.4.2/30

                              Router#configure terminal

                              Router (config)#interface s0/3/0

                              Router (config-if)#ip address 10.4.4.2 255.255.255.252

                              Router (config-if)#no shutdown

                              Router (config-if)#end

 

               Check that you can ping between hosts in the same subnet:

 

               - From Host A to Host B.

               - From Host C to R1´s G0/1 interface.

               - From S1 to S2.

               - From R1´s S0/3/0 interface to R2´s S0/3/0 interface.

 

Note that you can´t ping between hosts in different subnets because the routers don´t have any entry in their routing table.

 

2. – Enable OSPF in all interfaces both R1 and R2 (area 0) with only one subcommand in the OSPF configuration.

                              R1:

                                             Router#configure terminal

                                             Router (config)#router ospf 1

                                             Router (config-router)#network 10.0.0.0 0.255.255.255 area 0

                                             Router (config-router)#end

 

                              R2:

                                             Router#configure terminal

                                             Router (config)#router ospf 1

                                             Router (config-router)#network 10.0.0.0 0.255.255.255 area 0

                                             Router (config-router)#end

Why We Need iBGP Alongside IGPs (OSPF/IS-IS) | CCNA Networking Guide by KnowledgeStreams

 

Introduction: The Classic Routing Dilemma

If you are studying for your CCNA or diving deep into networking, you have likely run into a very common question: Why do we need iBGP for internal communication when we already have robust Interior Gateway Protocols (IGPs) like OSPF or IS-IS? It is a valid question. IGPs like OSPF or IS-IS are link-state protocols that provide routers with a complete, detailed map of the internal network topology. They offer incredibly fast convergence times and advanced traffic engineering options. BGP, on the other hand, operates with a much more limited view of the overall network architecture, focusing instead on heavily filtering and modifying routing information.

So, why complicate things by bringing internal BGP (iBGP) into the mix? The answer comes down to one massive factor: Scalability.

Let's break down exactly why your network needs iBGP.

Understanding the 4 Categories of Network Traffic

To understand the role of iBGP, we first need to look at how traffic flows through an Autonomous System (AS). Traffic generally falls into four distinct categories:

• Internal: Traffic where both the origin and the destination are located within the network.

• Ingress: Traffic arriving from outside the network, destined for hosts within the network.

• Egress: Traffic originating inside the network, destined for hosts outside the network.

• Transit: Traffic where both the origin and the destination are located outside the network (essentially, traffic just passing through your AS).

Your IGP perfectly handles the internal routes. It is designed to rapidly and efficiently route Internal and Ingress traffic to their final local destinations. But what happens when internal hosts need to reach the outside world (Egress), or external traffic needs to cross your network (Transit)?

The Problem: Handling Egress and Transit Traffic

To route traffic to the outside world, your internal routers need to know how to reach external destinations. You have three main choices for getting external routing information into your internal network:

1. Redistribute External Routes into Your IGP (The Dangerous Choice)

At first glance, you might think, "I'll just take the BGP routes and redistribute them into OSPF!" Do not do this. The global Internet routing table contains hundreds of thousands of routes (currently approaching a million). IGPs like OSPF and IS-IS are simply not mathematically or architecturally designed to handle that volume of data. If you attempt to dump the entire Internet routing table into your IGP, your routers' CPUs and memory will max out, and your network will inevitably crash.

2. Use Default Routes (The Simple but Limited Choice)

If your Autonomous System only has one border router connecting to the outside world (a single-homed network), you actually don't need iBGP. You can simply inject a default route (0.0.0.0/0) into your IGP. If a router doesn't know where an IP address is, it follows the default route to the border router, which then hands the traffic off to the ISP.

However, if your network connects to multiple service providers (multi-homing), relying on default routes means you lose the ability to choose the most optimal, efficient exit path for specific external destinations.

3. Use iBGP (The Scalable, Professional Choice)

This is where iBGP steps in to save the day. By running iBGP on your internal routers, you create a scalable way to share external routing information across your AS.

Instead of forcing your IGP to learn every route on the internet, iBGP carries those heavy external routes in the background. The IGP does what it does best (getting packets to the correct internal next-hop router), and iBGP does what it does best (handling massive routing tables and selecting the best exit point out of the network).

I-BGP USING FULL MESH NEIGHBORSHIP & BGP SPLIT HORIZON RULE - LAB

Conclusion

Ultimately, iBGP is an absolute requirement for multi-homed networks unless you are somehow willing to attempt the disastrous process of redistributing the entire internet into your IGP. By separating your internal topology management (IGP) from your massive external routing table management (iBGP), you achieve the stability, optimal path selection, and scalability required for modern networking.

---

Blog Hashtags: #KnowledgeStreams #CCNA #Networking #BGP #OSPF #CiscoCert #NetworkEngineering #ITInfrastructure #RoutingAndSwitching #TechBlog

CCNA 200-901: The Network Engineer’s Guide to YAML Data Types | Knowledgestreams

 If you are gearing up for the CCNA Automation (200-901) exam, you already know that the days of managing networks purely through the CLI are fading fast. Modern network programmability relies heavily on structured data, and at the heart of tools like Ansible and Python-driven automation is YAML.

Master YAML

YAML (YAML Ain't Markup Language) is incredibly human-readable, but if you don't understand its core data types, a single misplaced space can break your entire automation script.

Welcome to another deep dive by Knowledgestreams. Today, we are stripping away the complexity and breaking down the basic YAML data types you absolutely need to know to crush your 200-901 exam and build rock-solid network automation.

---

The Big Three: Basic YAML Data Types

YAML was designed to be cross-compatible with most modern programming languages (like Python, JavaScript, Ruby, and PHP). It accomplishes this by relying on three foundational data structures:

1. Scalars (Strings, numbers, and booleans)

2. Sequences (Lists or arrays)

3. Mappings (Hashes, dictionaries, or key-value pairs)

Let’s look at exactly how they work in a networking context.

---

1. Scalars: The Building Blocks

Think of scalars as the actual "data" on your page. They are the individual strings, IP addresses, or integers you are trying to configure. YAML gives you five different styles for writing scalars, depending on how complex your text is.

• Plain: No quotes or indicators. Used for simple text or numbers.

• Single-quoted ('): Wraps the value. It prevents YAML from treating special characters as syntax. (Note: No escaping occurs here, except that duplicate quotes '' are read as a single quote).

• Double-quoted ("): Used when you need to use escape sequences like \u**** for Unicode characters or \x** for ASCII.

• Literal block (|): Perfect for multi-line configurations (like banners or certificates). It preserves all your exact line breaks.

• Folded block (>): Similar to the literal style, but it automatically folds consecutive non-empty lines into a single line separated by spaces. It only preserves forced blank lines.

YAML Basic

Cisco Official link

XML based prompt Engineering

XML DOM explained

XML Basics

YAML Scalar Examples:

YAML Scalar Example

2. Sequences: Making Lists

In network automation, you rarely deal with just one of anything. You have multiple VLANs, multiple routing peers, and multiple interfaces. In YAML, we handle these using Sequences.

Sequences are simply lists. Each item in the list is placed on its own line and starts with an opening dash (-) followed by a space.

Basic Sequence Example

Sequence Example

Nested Sequences

You can create lists within lists (sub-items) by indenting the child items. In YAML, indentation is strictly enforced using spaces (never tabs!).

Nested Sequences Example

You can go as many levels deep as your automation logic requires, simply by maintaining proper space indentation.

---

3. Mappings: Key-Value Pairs

Mappings are exactly what they sound like: they map a specific key to a specific value. If you are familiar with Python dictionaries (a massive part of the CCNA 200-901 curriculum), mappings are the exact YAML equivalent.

They are created using a colon and a space (: ).

Basic Mapping Example

Mapping Example

Combining Mappings and Sequences (Real-World Usage)

In the real world of DevNet and CCNA automation, you will almost always combine mappings and sequences. For example, if you are writing a playbook to configure a list of interfaces, you map a key (like interfaces) to a sequence (your list of ports).

Combining Mappings and Sequences

Wrapping Up

Mastering these three basic structures—Scalars, Sequences, and Mappings—is your first major step toward passing the CCNA Automation (200-901) exam. Once you know how to format your data, pushing configurations to Cisco devices via Python or Ansible becomes incredibly straightforward.

Ready to take your network programmability skills to the next level? Stay tuned to Knowledgestreams for more hands-on DevNet tutorials, labs, and exam prep guides!

YAML Basic

Cisco Official link

XML based prompt Engineering

XML DOM explained

XML Basics

YAML vs JSON in Network Automation: A Complete Guide for CCNA DevNet Professionals

If you are studying for your CCNA DevNet certification or stepping into the world of network automation, you already know that JSON (JavaScript Object Notation) is everywhere. APIs use it, Python scripts parse it, and controllers like Cisco DNA Center rely on it.

But as you dive deeper into tools like Ansible or write complex configuration files, you will encounter another major player: YAML.

In this guide, we will break down what YAML is, how its structure works, and exactly how it compares to JSON so you can master both for your NetDevOps career.

---

What is YAML?

YAML stands for “YAML Ain’t Markup Language” (a recursive acronym).

From the very beginning, YAML was designed with one primary goal: to be highly human-readable. It was specifically created to work well for configuration files and log files. When data is easy for a human eye to scan and understand, configuring network devices and writing automation playbooks becomes a much simpler task.

The Main Design Goals of YAML

According to its creators, YAML was built to:

• Be easily readable by humans.

• Be portable between different programming languages.

• Match the native data structures of modern programming languages (like Python dictionaries and lists).

• Have a consistent model to support generic tools.

• Be expressive and extensible.

• Be easy to implement and use.

---

The Big Showdown: YAML vs JSON

Both JSON and YAML share a common goal: they format data so it can be read by both humans and machines. However, they have completely different priorities.

JSON’s Priority: Universality and Speed

JSON’s foremost design goal is universality. It is trivial for a computer to generate and parse JSON, but it does this at the cost of some human readability. JSON uses a lot of syntax (curly braces {}, square brackets [], and quotes "") to ensure that any programming environment can process it flawlessly and quickly.

YAML’s Priority: Human Readability

YAML’s foremost design goal is you—the human. YAML strips away the heavy punctuation of JSON, allowing for extremely clean, readable files. Because of its human-friendliness, YAML has become the undisputed king of configuration files in Network Automation and SDN (Software-Defined Networking) products (most notably, Ansible). The trade-off? YAML is slightly more complex for a machine to parse and generate compared to JSON.

Quick Comparison Table

Feature	JSON	YAML
Primary Goal	Machine parsing speed & universality	Human readability
Syntax	Uses brackets {}, [] and quotes ""	Uses indentation and whitespaces
Comments	Not supported natively	Fully supported (using #)
Best Used For	API Payloads (REST APIs)	Configuration files (Ansible, Kubernetes)

XML based prompt Engineering

XML DOM explained

XML Basics

Understanding YAML Structure and Syntax

If you take away one rule about YAML, let it be this: Indentation matters.

Unlike JSON, which relies on brackets to group data, YAML uses spaces.

• Whitespaces are syntax: Unless stated otherwise, the end of a line indicates the end of a field.

• Indentation defines structure: Indentation is defined as zero or more space characters at the start of a line.

• NO TABS ALLOWED: You must use spaces (usually 2 spaces per level). Tabs should never be used because different text editors and parsers treat tabs differently, which will break your script.

• Parent/Child Nodes: Each child node must be indented further than its parent node. All sibling nodes (items at the same level) must use the exact same indentation level.

YAML’s indentation nesting is a very simple but incredibly powerful way to build sophisticated data objects.

---

Real-World Examples: JSON vs YAML for Network Engineers

Let's look at how the exact same network data is represented in both JSON and YAML to see how YAML's indentation works in practice.

Example 1: A Simple Router Configuration

Here is a standard data object representing a router.

The JSON Way:

JSON

{
  "router1": {
    "address": "10.1.1.1",
    "operational": true,
    "uptime": 46701,
    "interfaces": [
      "GigabitEthernet0/1",
      "GigabitEthernet0/2",
      "GigabitEthernet0/3"
    ]
  }
}

The YAML Way:

YAML

--
router1:
  address: 10.1.1.1
  operational: true
  uptime: 46701
  interfaces:
    - GigabitEthernet0/1
    - GigabitEthernet0/2
    - GigabitEthernet0/3

• Explanation: Notice how YAML drops all the quotes around the keys and values. The --- at the top simply denotes the start of a YAML document. The JSON array (list of interfaces) is replaced in YAML by a simple bulleted list using dashes -.

Example 2: Configuring Multiple VLANs (List of Dictionaries)

In DevNet, you often deal with lists of complex objects.

The JSON Way:

JSON

{
  "vlans": [
    {
      "vlan_id": 10,
      "name": "Management",
      "active": true
    },
    {
      "vlan_id": 20,
      "name": "Engineering",
      "active": true
    }
  ]
}

The YAML Way:

YAML

---
vlans:
  - vlan_id: 10
    name: Management
    active: true
  - vlan_id: 20
    name: Engineering
    active: true

• Explanation: In YAML, the dash - indicates a new item in a list. Because vlan_id, name, and active are indented evenly under the dash, the YAML parser knows they all belong to that specific list item. It is significantly faster to read and write than the JSON equivalent!

---

Both JSON and YAML are indispensable skills for a CCNA DevNet professional. You will use JSON to talk to APIs, and you will use YAML to write your infrastructure-as-code configurations.

The Ultimate Beginner’s Guide to JSON: What It Is, How It Works, and Why We Use It: CCNA Automation (200-901)

 Have you ever wondered how different apps, websites, and servers talk to each other so flawlessly? Whether you are refreshing your social media feed, managing network devices, or running a DevOps script, there is an invisible language flying across the internet making it all happen.

That language is JSON.

If you look under the hood of network automation tools like Cisco DNA Center, Cisco Meraki, or everyday web APIs, you will see JSON everywhere. It has become the universal translator between scripts, network devices, and controllers.

In this guide, we are going to break down exactly what JSON is, why it replaced older formats, how it works, and how to read it yourself.

XML based prompt Engineering

XML DOM explained

XML Basics

Why Do We Need JSON? (The Problem of Scale)

Before JSON, the first widely adopted plaintext data format was XML (eXtensible Markup Language). XML is incredibly powerful, flexible, and relatively easy for humans to read. For a long time, it was the gold standard for sending data over the web.

But as the internet exploded in popularity, developers ran into a major roadblock. The web had to scale to millions of users making millions of requests every single minute. At that massive scale, XML’s biggest strength—its detail—became its greatest weakness.

When were different data formats introduced.

KEY POINT: Some problems only appear at a massive scale.

XML is quite "wordy." Every piece of data needs an opening tag and a closing tag.

• <name>John</name>

You might be thinking: Okay, it’s just a few extra characters. What’s the big deal?

At a small scale, it doesn't matter. But when servers are sending responses to millions of clients every second, those extra characters add up to extra kilobytes. Extra kilobytes mean more bandwidth and more processing power required. In the tech world, that ultimately translates to money.

Web and API developers realized they needed a data format that was highly efficient, easy for programs to generate, but still readable by humans. That is why JSON was born.

---

What is JSON?

JSON stands for JavaScript Object Notation.

Despite the name, you do not need to know JavaScript to use it. JSON is not tied exclusively to JavaScript anymore; it is a simple, universal text format used for representing structured data. Humans can easily read it, and computers can process it at lightning speed.

JSON became the industry favorite because it maps perfectly to the common data structures found in almost every programming language:

• Objects / Dictionaries: Collections of key-value pairs.

• Arrays / Lists: Ordered lists of items.

• Strings: Text.

• Numbers: Integers and decimals.

• Booleans: True or False.

• Null: Empty values.

The Big Advantages of JSON

• Compact: It uses minimal punctuation, saving bandwidth.

• Readable: Both humans and machines can understand it easily.

• Language Independent: It is just plain text, meaning a Python script can easily read JSON sent from a Java server.

• Universal Support: Virtually every programming language has built-in tools to read and write JSON.

---

How Does JSON Work?

At a high level, JSON is all about serialization.

Imagine you have a complex idea in your brain (in-memory data structures). To share it with a friend over text message, you have to type it out into words (a standard text format). Your friend receives the text and translates those words back into an idea in their brain.

JSON works exactly the same way between computers:

1. Serialization: The sender takes data from its memory and turns it into JSON text.

2. Transmission: The JSON text is sent over the network.

3. Deserialization: The receiver takes the JSON text and turns it back into usable data in its own memory.

As long as both sides agree on the "shape" of the data, the communication is flawless.

---

The Big Showdown: JSON vs. XML

Today, both JSON and XML are still used, but JSON dominates modern web and API development. Here is a simple breakdown of how they compare:

Feature	JSON	XML
Formatting	Highly compact and lightweight.	Very wordy; heavily relies on tags.
Readability	Clean and easy to read, even in large files.	Becomes cluttered and hard to manage in large files.
Arrays (Lists)	Fully supports arrays.	Does not natively support arrays.
Data Types	Supports Text, Numbers, Booleans, Null.	Supports many types, including images and graphs.
Human Parsing	Very human-readable.	Less human-readable due to tag repetition.

XML based prompt Engineering

XML DOM explained

XML Basics

Let's Look at an Example

To really understand why JSON is preferred for data transfer, let's look at the exact same network data formatted in both languages.

The XML Way:

XML  Example

The JSON Way:

JSON Example

Notice how JSON eliminates all the repetitive closing tags like </name> and </interface>? By using simple brackets [] and braces {}, JSON passes the exact same information using significantly less text.

More JSON Examples Explained

If you are new to reading JSON, all the brackets can look a bit confusing. Let's break down a few more examples so you can read JSON like a pro.

Example 1: A Simple Object (Dictionary)

An object in JSON is wrapped in curly braces {}. It holds data in "key-value" pairs. Think of it like a dictionary word and its definition.

JSON Example

• Explanation: This JSON represents a single network router. The keys (left side) are wrapped in quotes. The values (right side) can be text (wrapped in quotes) or numbers (no quotes needed).

Example 2: An Array (List)

An array in JSON is wrapped in square brackets []. It is used to hold a list of items.

JSON Array

• Explanation: Here, the key is "allowed_vlans", and the value is a list of five different numbers. Arrays are perfect when you have multiple items of the same type.

Example 3: A Complex Object (Mixing Everything Together)

JSON allows you to nest objects and arrays inside one another to create rich, detailed data profiles.

JSON Complex Example

Explanation: This starts with a main object employee. Inside that, we have nested a name (String), a role (String), an active status (Boolean true), and a list of her certifications (Array). This clean, logical hierarchy is exactly why programmers love JSON!

XML based prompt Engineering

XML DOM explained

XML Basics

What is JSON Used For in the Real World?

JSON is the absolute backbone of modern data exchange. Its most common daily uses include:

• Web Browsers (AJAX): When you scroll down a webpage and new content loads without the page refreshing (like on X/Twitter or Instagram), that is your browser secretly asking a web server for more data. The server sends that data back formatted as JSON.

• Network Automation: Modern networking platforms have APIs (Application Programming Interfaces). If you want to use a Python script to tell Cisco DNA Center to update 100 routers, your script will package those instructions into a JSON payload and send it over HTTP.

• Configuration Files: Many modern software tools and text editors (like VS Code) use JSON files to save your user settings and preferences.

JSON is incredibly powerful, universally accepted, and entirely scalable. Once you learn how to read its simple brackets and braces, a whole new world of automation and web development opens up to you!