DEV Community: mahir dasare

Networking Series Day-02

mahir dasare — Sat, 23 Aug 2025 03:11:18 +0000

Think of Border Gateway Protocol (BGP) as the internet's global positioning system (GPS) that maps the routes between major networks. These major networks, like those belonging to large ISPs, universities, or corporations, are called Autonomous Systems (AS). Each AS is identified by a unique Autonomous System Number (ASN).

How BGP Works: A Deeper Look
Instead of calculating the shortest distance, BGP operates as a path-vector protocol. This means it doesn't just look at how "far" a destination is; it looks at the entire path (the sequence of ASNs) a data packet will take to get there.

Peer Connection: Two BGP routers (known as "peers") in different ASes form a TCP connection on port 179. They exchange OPEN messages to set up the session, including their ASNs and capabilities.

Route Advertisement: Once the connection is established, BGP peers send route advertisements in UPDATE messages. These advertisements don't just say, "I can reach this network." Instead, they include a rich set of path attributes that describe the path to that network. The most important attribute is the AS Path, which is a list of all the ASNs the route has passed through.

Loop Prevention: BGP’s path-vector nature is a powerful tool for preventing routing loops. When a router receives a route advertisement, it checks the AS Path. If it sees its own ASN already in the list, it knows the route has been advertised back to it and will ignore that path to avoid a loop.

Route Selection: A BGP router might receive multiple advertisements for the same destination network from different peers. To choose the "best" path, it uses a complex, step-by-step algorithm that evaluates the path attributes in a specific, prioritized order.

Weight: (Cisco proprietary) The highest value is preferred.

Local Preference: The highest value is preferred. This attribute is exchanged within an AS to control the preferred exit path to the internet.

AS Path Length: The path with the fewest ASNs is generally preferred. This is a primary factor in traffic engineering and a core part of BGP's design.

Origin Type: BGP prefers routes that were originated within an AS over those learned from other protocols.

MED (Multi-Exit Discriminator): The lowest value is preferred. An AS can use this attribute to influence how traffic from another AS enters its network when there are multiple connection points.

and many more tie-breaking rules, including a preference for eBGP over iBGP, lowest IGP metric to the BGP next-hop, and lowest router ID.

This entire process, from neighbor discovery to path selection, makes BGP incredibly robust and flexible, allowing network administrators to implement detailed routing policies and manage the flow of traffic across the internet.

Networking Series Day--01

mahir dasare — Sat, 23 Aug 2025 03:00:26 +0000

🌐 Networking Series – Day 1: Routing Essentials
Routing is the heart of networking—it decides how data travels from source to destination. Let’s explore:
🔹 Static Routing
Manually configured routes.
✅ Simple and secure, ⚠️ not scalable.
🔹 Dynamic Routing
Protocols automatically discover/update routes.
✅ Scalable, ✅ Fault-tolerant, ⚠️ Resource intensive.
Important Protocols:
RIP (Routing Information Protocol): Hop-count metric, max 15 hops. Simple but not scalable.
OSPF (Open Shortest Path First): Link-state protocol, uses Dijkstra’s Algorithm, supports areas for scalability.
EIGRP (Enhanced IGRP): Cisco proprietary, fast convergence, balances simplicity and efficiency.
🔹 Default Route
A “catch-all” route (0.0.0.0/0) when no specific route exists.

💡 Takeaway: Routing protocols are the brain of network communication—choosing the right one depends on network size and needs.

hashtag#Networking hashtag#Routing hashtag#RIP hashtag#OSPF hashtag#EIGRP hashtag#DevOps

CI/CD Pipeline

mahir dasare — Thu, 24 Jul 2025 04:08:59 +0000

The /proc Filesystem

mahir dasare — Thu, 19 Jun 2025 11:27:52 +0000

The /proc Filesystem
Certain filesystems, like the one mounted at /proc, are called pseudo-filesystems because they have no actual permanent presence anywhere on the disk.

The /proc filesystem contains virtual files (files that exist only in memory) that permit viewing constantly changing kernel data. /proc contains files and directories that mimic kernel structures and configuration information. It does not contain real files, but runtime system information, e.g. system memory, devices mounted, hardware configuration, etc. Some important entries in /proc are:

/proc/cpuinfo
/proc/interrupts
/proc/meminfo
/proc/mounts
/proc/partitions
/proc/version

/proc has subdirectories as well, including:

/proc/
/proc/sys

The first example shows there is a directory for every process running on the system, which contains vital information about it. The second example shows a virtual directory that contains a lot of information about the entire system, in particular its hardware and configuration. The /proc filesystem is very useful because the information it reports is gathered only as needed and never needs storage on the disk.

The API Lifecycle

mahir dasare — Tue, 17 Jun 2025 19:57:20 +0000

This lifecycle was created by the OpenAPI Initiative to explain how OpenAPI can be used throughout the development and deployment of APIs:

Providing and using an OpenAPI Specification (OAS) document is not, however, a point-in-time activity. It is fundamental to the API lifecycle, providing affordances for all activities from the inception of the design right through to deployment and support. If an API lifecycle is a transport network then OAS should be considered an arterial road, providing the means to efficiently transfer large amounts of pertinent information quickly and efficiently.

When one considers the API lifecycle it starts to become clear how useful an OpenAPI document is. Consider the simple API lifecycle below. It is based on the idea of API-first design, where the interface is designed without writing a stitch of implementation code. OAS can be used at each stage in this lifecycle.
An API lifecycle within an organization clearly has more nuances than the steps described above, and will undoubtedly be tailored towards the software development lifecycle in use. An agile methodology may, for example, iterate over the steps shown above many times. However, for the purposes of exemplar this simplified view has merit as it shows the utility of OAS at each stage.

Using OAS to help elicit requirements
The first step in our conceptional lifecycle is Requirements, where ideas about an API start to take shape. “Taking shape” covers a multitude of different activities – some technical, some not. Requirements gathering in most organizations stretches back into the business, working with the product team to define what the API should provide for its consumers and that support a holistic view of the product features.

Technologists working on bringing those requirements need some means to convey them. OAS provides the means to support this in an agnostic and portable way. It also provides the means to do this quickly and be able to socialize their ideas with other stakeholders with minimal set-up.

Having a sketch of your API design in OAS when gathering requirements gives you a headstart when starting design.

OAS in development
Once an API design has been created the time has come to write some code and create an implementation of that API in software. Acting on the output design process means working with the OpenAPI document to help bring your application to life.

Our conception lifecycle assumes an API-first design approach, where the OpenAPI document is created upfront and code is then written to create the implementation. There is, of course, the “code-first” approach where the implementation is created and then (typically) annotated so an OpenAPI document can then be generated.

The pros and cons of both approaches are beyond the scope of this post, but if you take the API first approach then having the design detailed in an OpenAPI document is critical to your implementation. The OAS has a rich tooling ecosystem and using the OpenAPI document to generate server-side code is a common approach to automating the creation of controller classes. This speeds up the delivery of the implementation and helps ensure the interface design and the implementation are closely-matched.

Implementing your API in code is, however, only one of the subsequent steps in the lifecycle. Other activities rely on OAS to be completed successfully.

Why Code-first Works

mahir dasare — Fri, 13 Jun 2025 20:28:34 +0000

Design-first has many benefits for rapid prototyping and shaping ideas. However, code-first is probably the more mature of the two design methodologies discussed in this chapter. The reason for this is quite simple: Implementation code predated API description languages, which in turn were born from the need to produce a schematic representation of an API for consumption outside the code base. The API economy and software engineering in general have had this need for a long time. We cannot simply throw open our code repositories and invite any external collaborators in to view our implementation code. We need the means to describe the shape of our API outside our safe and secure codebase. That fact is true regardless of whether we are going with code-first or design-first, but it's all the more pertinent in the code-first world. The reason that API description languages came into being is so that developers could automatically generate API-related documentation based on the shape of their implementation code and provide the description to external consumers.

The methodology is generally as follows:

Write implementation code that reflects a given interaction with the API.
Implement routing to provide request and response operations.
Apply meaningful annotations that can transpose the "shape" of the code to an API description document.
Generate the API description document at build time, source control it, and distribute the document to interested parties.
This approach has grown organically, matured over time, and is not unique to OpenAPI. There is also a huge number of packages that support code-first. We have two examples in the following sections that use springdoc-openapi and APIFlask, written in Java and Python respectively, to demonstrate how code-first works with popular programming languages and frameworks. In both examples, we will use the stripped-down Petstore API we created in the design-first section as the implementation requirement, and show how this OpenAPI description would be generated from code.

How Security Requirements are Implemented in OpenAPI

mahir dasare — Fri, 13 Jun 2025 20:21:47 +0000

OpenAPI currently provides support for five different security schemes through the Security Scheme Object, including the following:

API Key (apiKey): API keys are a popular means for providing a coarse-grained security credential to API consumers. The popularity of API keys has waned somewhat, largely due to the fact they are not protocol-bound and therefore not standardized, and because they provide limited proofs-of-possession. However, they continue to be provided in OpenAPI.

HTTP (http): HTTP provides a pointer to any valid security scheme in the IANA Authentication Scheme registry. While there are several entries in this registry, probably the most popular are Basic Authentication - essentially a username and password - and Bearer Tokens in the context of OAuth 2.0.

Mutual TLS (mutualTLS): Mutual TLS is a security mechanism that is popular in financial service APIs as it enforces the verification of x509 certificates at both the client and the server. OpenAPI provides limited built-in metadata for this Security Scheme, and API providers must provide additional details to describe specifics like accepted certificate authorities and supported ciphers.

OAuth 2.0 (oauth2): OAuth 2.0 is a fundamental building block of the API Economy as it facilitates allowing users (real human beings) to delegate their access to a third party at a given service provider. It is therefore well represented in OpenAPI, with the means to describe the most important OAuth flows.

OpenID Connect (openIdConnect): Support for OpenID Connect is supported in providing a link to the OpenID Connect Discovery metadata. While this in itself does not provide much in the way of rich metadata, it provides a pointer to a very rich document that can be programmatically parsed, allowing API consumers to access and act on this information in their applications in an automated manner.

Soft Links

mahir dasare — Thu, 12 Jun 2025 19:23:12 +0000

Soft (or Symbolic) links are created with the -s option, as in:

$ ln -s file1 file3
$ ls -li file1 file3

Notice file3 no longer appears to be a regular file, and it clearly points to file1 and has a different inode number.

ymbolic links take no extra space on the filesystem (unless their names are very long). They are extremely convenient, as they can easily be modified to point to different places. An easy way to create a shortcut from your home directory to long pathnames is to create a symbolic link.

Unlike hard links, soft links can point to objects even on different filesystems, partitions, and/or disks and other media, which may or may not be currently available or even exist. In the case where the link does not point to a currently available or existing object, you obtain a dangling link.

Hard Links

mahir dasare — Thu, 12 Jun 2025 19:06:32 +0000

The ln utility is used to create hard links and (with the -s option) soft links, also known as symbolic links or symlinks. These two kinds of links are very useful in UNIX-based operating systems.

Suppose that file1 already exists. A hard link, called file2, is created with the command:

$ ln file1 file2

Note that two files now appear to exist. However, a closer inspection of the file listing shows that this is not quite true.

$ ls -li file1 file2

The -i option to ls prints out in the first column the inode number, which is a unique quantity for each file object. This field is the same for both of these files; what is really going on here is that it is only one file, but it has more than one name associated with it, as is indicated by the 2 that appears in the ls output. Thus, there was already another object linked to file1 before the command was executed.

Hard links are very useful and they save space, but you have to be careful with their use, sometimes in subtle ways. For one thing, if you remove either file1 or file2 in the example, the inode object (and the remaining file name) will remain, which might be undesirable, as it may lead to subtle errors later if you recreate a file of that name.

If you edit one of the files, exactly what happens depends on your editor; most editors, including vi and gedit, will retain the link by default, but it is possible that modifying one of the names may break the link and result in the creation of two objects

Security IAM Role

mahir dasare — Thu, 12 Jun 2025 11:08:15 +0000

For AWS Lambda to run, we need to define an IAM role. This specifies which AWS subsystems can call the lambda, and what AWS operations this lambda invokes.

Our role specifies that the lambda subsystem lambda.amazonaws.com can call our lambda, and that our lambda can write any logs. While this is slightly unsafe, it enables us to apply this role to all of our lambdas.

Monolithic vs Microservices

mahir dasare — Mon, 09 Jun 2025 18:12:48 +0000

Monolithic vs Microservices
Monolithic Architecture:

Single codebase
Tightly coupled components
Difficult to scale individual features
Suitable for small-scale applications
Microservices Architecture:
Application broken into smaller, independent services
Services communicate via APIs
Easier to scale and deploy independently
Ideal for complex and scalable applications

_Kubernetes Architecture
_To understand the architecture and components of your Kubernetes cluster:

kubectl cluster-info

Display cluster information (API server, DNS, etc.)

Setup on Local/AWS EC2
Create a local Kubernetes cluster using Kind (Kubernetes IN Docker):
kind create cluster --name tws-cluster --config=config.yml

Creates a Kind cluster with the given name and configuration

Set the context to the newly created cluster:

kubectl config use-context kind-tws-cluster

Switch to the context of the Kind cluster

Kubectl and Pods
kubectl get nodes

List all nodes in the cluster

kubectl run nginx --image=nginx -n nginx

Create an nginx pod in the 'nginx' namespace

kubectl describe pod nginx -n nginx

Show detailed information about the nginx pod

_Namespaces, Labels, Selectors, and Annotations
_
kubectl create namespace monitoring

Create a namespace named 'monitoring'

kubectl get namespaces

List all namespaces in the cluster

kubectl label namespace monitoring team=devops

Add a label 'team=devops' to the 'monitoring' namespace

kubectl describe namespace monitoring

Display detailed information about the 'monitoring' namespace

Workloads
Deployments
kubectl apply -f deployment.yml

Deploy a workload defined in deployment.yml

kubectl scale deployment nginx-deployment --replicas=3 -n nginx

Scale the nginx deployment to 3 replicas

StatefulSets_
_kubectl apply -f statefulset.yml

Deploy a StatefulSet using the configuration file

kubectl describe statefulset mysql -n database

Display detailed information about the 'mysql' StatefulSet

*DaemonSets
*
kubectl apply -f daemonset.yml

Deploy a DaemonSet to run pods on every node

kubectl describe daemonset fluentd -n logging

Show details about the 'fluentd' DaemonSet

ReplicaSets

kubectl apply -f replicaset.yml

Deploy a ReplicaSet using the specified YAML file

kubectl describe replicaset nginx-replicaset -n nginx

Show detailed information about the 'nginx-replicaset'

Jobs and CronJobs

kubectl apply -f job.yml

Deploy a one-time Job using job.yml

kubectl apply -f cronjob.yml

Deploy a CronJob to schedule recurring tasks

END

Wired and Wireless Connections

mahir dasare — Fri, 06 Jun 2025 16:51:08 +0000

Wired connections usually do not require complicated or manual configuration. The hardware interface and signal presence are automatically detected, and then Network Manager sets the actual network settings via Dynamic Host Configuration Protocol (DHCP).

For static configurations that do not use DHCP, manual setup can also be done easily through Network Manager. You can also change the Ethernet Media Wired and Wireless Connections
Wired connections usually do not require complicated or manual configuration. The hardware interface and signal presence are automatically detected, and then Network Manager sets the actual network settings via Dynamic Host Configuration Protocol (DHCP).

For static configurations that do not use DHCP, manual setup can also be done easily through Network Manager. You can also change the Ethernet Media Access Control (MAC) address if your hardware supports it. The MAC address is a unique hexadecimal number of your network card.

Wireless networks are usually not connected by default. You can view the list of available wireless networks and see which one (if any) you are currently connected to by using Network Manager. You can then add, edit, or remove known wireless networks, and also specify which ones you want connected by default when present.