Lívio Zanol Puppim published a series of blog posts describing a full-stack network automation, including GitOps with GitLab, handling secrets with Hashicorp Vault, using Ansible and AWX to run automation scripts, continuous integration with Gitlab CI Runner, and topped it off with a REST API and React-based user interface.
You might not want to use the exact same components, but it’s probably worthwhile going through his solution and explore the source code. He’s also looking for any comments or feedback you might have on how to improve what he did.
You can register for my network troubleshooting course here.
Information about the IEEE Network Softwarification Conference can be found here.
Our upcoming episodes for this month are George Michaelson on the death of ISDN and old networks; an update on the FR Routing project; and Rick Graziani on college and network engineering. Thanks for listening to the Hedge!
Unicast Multicast Broadcast Anycast and Incast Traffic Types will be explained in this post. Traffic flow/traffic types are important information that needs to be considered in Network Design, thus understanding each one of them by every IT Engineer is critical and Important for Application requirements, Security, and Performance of the overall system.
In this blog post, Unicast, Multicast, Broadcast, and Anycast traffic types/patterns will be explained with examples and the topologies.
Unicast traffic type is a point-to-point communication type. Usually from a scalability perspective, Unicast is not the desired traffic type. But if there are only two points that communicate with each other, Unicast is an optimal choice.
Point to Multipoint or Multi-Point to Multi-Point Traffic type. If the communication is targeted to a group of recipients, then the Multicast traffic type is more suitable. Multicast source/sender, receivers, and multicast groups are the components of Multicast communication. A classical example is IPTV – IP Television.
One multicast group is assigned for each IPTV channel and only interested receivers get the stream.
If traffic is sent to everyone, regardless of considering if there is an uninterested receiver, then it is a broadcast Continue reading
Russ White’s Weekend Reads are full of gems, including a recent pointer to the AI Illusion – State-of-the-Art Chatbots Aren’t What They Seem article. It starts with “Artificial intelligence is an oxymoron. Despite all the incredible things computers can do, they are still not intelligent in any meaningful sense of the word.” and it only gets better.
While the article focuses on natural language processing (GPT-3 model), I see no reason why we should expect better performance from AI in networking (see also: AI/ML in Networking – The Good, the Bad, and the Ugly).
Today's Heavy Networking dives into home IoT at scale. We’re going to get into the weeds with two network engineers who’ve gone way beyond lighting and a few smart plugs in their home automation setup. We'll talk devices, protocols, security, and more.
The post Heavy Networking 625: Home IoT Networking At Scale appeared first on Packet Pushers.
MPLS Benefits and Advantages, Network Engineers should understand MPLS. In this post, we will look at what are the benefits of deploying MPLS in the Network, and the advantages of having MPLS-enabled infrastructure.
MPLS is Multi-Protocol Label Switching as you might know already. Multi-Protocol because we can carry many different types of traffic over MPLS.
Layer 2 and Layer 3 network traffic Ethernet, Frame Frame-Relay, ATM, TDM different types of traffic was carried over MPLS. Because it provides an abstraction layer for the protocols, it is possible to carry many different types of traffic that couldn’t be possible with other technologies easily.
If we talk about MPLS benefits, probably one of the most important ones would be MPLS Scalability. There is a popular belief that MPLS was invented because the packet processing resource requirement and lookup speed are faster with MPLS, compare to IP destination-based lookup.
Because MPLS is just a switching operation on the Mid-Label Switch Routers – LSR, and MPLS Label is 20 bits long, compared to IP which is 32 bits long with IPv4 and 128 bits long with IPv6, MPLS was considered a better performance protocol, Continue reading
I saw a great tweet yesterday from Swift on Security that talked about helpdesk work and how it’s nothing to be ashamed of:
I thought it was especially important to call this out for my readers. I’ve made no secret that my first “real” job in IT was on the national helpdesk for Gateway Computers through a contractor. I was there for about six months before I got a job doing more enterprise-type support work. And while my skills today are far above what I did when I started out having customers search for red floppy disks and removing helper apps in MSCONFIG, the basics that I learned there are things I still carry with me today.
Most people have a negative outlook on helpdesk work. They see it as entry-level and not worth admitting to. They also don’t quite understand Continue reading
IGP vs BGP is one of the topics every Network Engineer want to learn in their career. In this post, without going into each IGP protocol detail, where and why IGP or BGP is used and should be used will discuss. As usual, we will look at it from a design aspect and understand the reasons for the protocol selection.
Although I will not explain the above chart in this blog post in detail, I would like to share it for completeness. Also, please note that we compared BGP with each IGP protocol from a design point of view on the website in different blog posts already.
When igp vs BGP is compared, the first thing we should understand is that BGP is the most scalable routing protocol and it is used for the Global Internet.
Global Internet, as of 2022, carries almost a million IPv4 Unicast prefixes.
When we talk about IGP scaling, OSPF, IS-IS, or EIGRP, can carry couple of tens of thousand prefixes, and after that, we may start seeing meltdowns, even in well-designed Continue reading
OSPF LSA Types is the first topic you need to understand if you are trying to understand OSPF routing protocol. There are 11 different types of LSA in OSPF and we will look at each one of them, why do we have many different LSA in OSPF, we will discuss the topologies and the examples to make it more clear for everyone.
We should start asking the most fundamental question first about OSPF. What is LSA?. LSA stands for Link State Advertisement and it carries, prefix information, interface cost, if advanced technologies such as Traffic Engineering are enabled, can carry link color information, used bandwidth, available bandwidth, and so on.
When a router receives an LSA, it is stored in the Link State Database (LSDB) of OSPF. Once the LSDBs between the routers are synchronized, OSPF uses the SPF/Dijkstra algorithm to calculate the best path for each destination network.
OSPF LSAs are information about a route that is transported inside OSPF Link State Update (LSU) packets.
We can only have scalable, resilient, fast-converged OSPF design when we understand OSPF LSAs and Area types and their restrictions
Figure -11 Different LSA Types is OSPF v2
After discussing the basics of IPv6 security in the hands-on part of IPv6 security webinar webinar, Christopher Werny focused on the IPv6 trust model (aka “we’re all brothers and sisters on link-local").
Kali is a purpose build Linux distribution for penetration testing. They have many pre-built deployment options, but unfortunately a cloud-init compatible image is not one of them. In this post, I will show you how to convert a pre-build VMware image into a cloud-init compatible image...continue reading
Who Should Read: If you are interested in VPC Endpoints or if you want to know more about AWS VPC services please continue.
I have been trying to understand endpoint services and thought I will write up a few posts on it, here are some posts I have written on medium(if you have access), I will port them to the blog by the weekend.
https://towardsaws.com/part-2-setting-up-ipsec-vpn-to-explore-interface-end-points-3048080e5514
Again, these will be ported here as well along with an audio version.
-Rakesh
An important part of any Kubernetes cluster is the underlying containers. Containers are the workloads that your business relies on, what your customers engage with, and what shapes your networking infrastructure. Long story short, containers are arguably the soul of any containerized environment.
One of the most popular open-source container orchestration systems, Kubernetes, has a modular architecture. On its own, Kubernetes is a sophisticated orchestrator that helps you manage multiple projects in order to deliver highly available, scalable, and automated deployment solutions. But to do so, it relies on having a suite of underlying container orchestration tools.
This blog post focuses on containers and container networking. Throughout this post, you will find information on what a container is, how you can create one, what a namespace means, and what the mechanisms are that allow Kubernetes to limit resources for a container.
A container is an isolated environment used to run an application. By utilizing the power of cgroup
, namespace
, and filesystem
from the Linux kernel, containers can be allocated with a limited amount of resources and filesystems inside isolated environments.