IP addressing and subnetting Guide - CCNA CCNP - Networking

 

IP Address Classes

Figure 1 IP Classes

 

Private Address Space

Class A 10.0.0.0 to 10.255.255.255

Class B 172.16.0.0 to 172.31.255.255

Class C 192.168.0.0 to 192.168.255.255

 

Default Subnet Masks

Class A 255.0.0.0

Class B 255.255.0.0

Class C 255.255.255.0

 

 

Figure 2 Decimal to Binary conversion

 

 

Figure 3 Binary to Decimal conversion

 

 

Figure 4Network and host identification

 

 

Figure 5 Network Addresses

 

 

Figure 6 Host address identification

 

 

How to determine the number of subnets and the number of hosts per subnet

 

Two formulas can provide this basic information:

Number of subnets = 2^S (Second subnet formula: Number of subnets = 2^S - 2)

Number of hosts per subnet = 2^h - 2

Both formulas calculate the number of hosts or subnets based on the number of binary bits used. For example if you borrow three bits from the host portion of the address use the number of subnets formula to determine the total number of subnets gained by borrowing the three bits. This would be 2³ or 2 x 2 x 2 = 8 subnets

To determine the number of hosts per subnet you would take the number of binary bits used in the host portion and apply this to the number of hosts per subnet formula If five bits are in the host portion of the address this would be 2⁵ or 2 x 2 x 2 x 2 x 2 = 32 hosts.

When dealing with the number of hosts per subnet you have to subtract two addresses from the range. The first address in every range is the subnet number. The last address in every range is the broadcast address. These two addresses cannot be assigned to any device in the network which is why you have to subtract two addresses to find the number of usable addresses in each range.

For example, if two bits are borrowed for the network portion of the address you can easily determine the number of subnets and hosts per subnets using the two formulas.

 

 

What about that second subnet formula:

Number of subnets = 2^S - 2

In some instances the first and last subnet range of addresses are reserved. This is similar to the first and last host addresses in each range of addreses.

The first range of addresses is the zero subnet. The subnet number for the zero subnet is also the subnet number for the classful subnet address.

The last range of addresses is the broadcast subnet. The broadcast address for the last subnet in the broadcast subnet is the same as the classful broadcast address.

 

 

Figure 7 Class A addressing Guide

 

Figure 8 Class B addressing guide

 

 

Figure 9 Class C addressing guide

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.