FRRouting Claims IBGP Loopbacks Are Inaccessible
Last week, I explained the differences between FRRouting and more traditional networking operating systems in scenarios where OSPF and IBGP advertise the same prefix:
- Traditional networking operating systems enter only the OSPF route into the IP routing table.
- FRRouting enters OSPF and IBGP routes into the IP routing table.
- On all platforms I’ve tested, only the OSPF route gets into the forwarding table1.
One could conclude that it’s perfectly safe to advertise the same prefixes in OSPF and IBGP. The OSPF routes will be used within the autonomous system, and the IBGP routes will be propagated over EBGP to adjacent networks. Well, one would be surprised đ¤Śââď¸
Getting Started With Juniper PyEZ Library
In this blog post, we're diving into how to use the PyEZ Python library to interact with Juniper devices. I'll be working with a Juniper vMX device as our example, but PyEZ can work with any other Junos-based device. So, whether you have a vMX, an SRX, or any other Junos device, you'll find this guide helpful.
What we will cover?
- What is Juniper PyEZ?
- Why do we need PyEZ?
- Prerequisites
- Getting facts from Juniper vMX
- Getting Interface Stats and Errors
- A few things to note
- Closing thoughts
What is Juniper PyEZ?
Junos PyEZ is a microframework for Python that enables you to manage and automate Junos devices. Junos PyEZ is designed to provide the capabilities that we would typically get from the CLI.
You can use Junos PyEZ to retrieve facts or operational information from a device, execute remote procedure calls (RPC) available through the Junos XML API and even install or upgrade the Junos software. But for the sake of this example, we will retrieve the facts from the vMX and then retrieve some interface statistics.
But, Why Do I need PyEZ?
If you're wondering why we need PyEZ, here's a straightforward reason from my experience. I often Continue reading
Recap: KubeCon + CloudNativeCon EU + CalicoCon 2024
Last week we had the pleasure of attending KubeCon + CloudNativeCon EU in Paris, France. It was a fantastic event where we once again had the opportunity to engage in meaningful conversations about Kubernetes, container security, and the latest developments in the open source ecosystem. We also hosted CalicoCon 2024, a co-located event, to talk about our favorite subject: Calico! Letâs take a look at some of the highlights from the conference.
CalicoCon 2024
A large group of KubeCon attendees joined us on March 19th for a full-day event to explore the trends, strategies, and technologies making waves in the Kubernetes networking, security, and observability world. The day included a keynote on Project Calicoâs past, present, and future, plus multiple presentations and workshops delivered by Calico engineers that provided a deep dive into topics such as eBPF, Windows HNS, multi-cluster mesh, best practices for network policies, scale, performance, encryption, and compliance.
A good time was had by all in attendance, and two lucky winners of our raffles each took home a pair of AirPods! The day ended with happy hour and networking, where attendees had a chance to meet other Calico users as well as the engineers and leadership Continue reading
Packet Protector: IPv6 Security Essentials
Welcome to a crossover episode with the Packet Protector podcast! Youâre already running IPv6, even if you donât know it yet. Your remote users are using it at their homes, your printers come with it built into the kernel, your generals are using it on their mobile phones (check out our news headlines section). So... Read more »PP007: IPv6 Security Essentials
Youâre already running IPv6, even if you donât know it yet. Your remote users are using it at their homes, your printers come with it built into the kernel, your generals are using it on their mobile phones (check out our news headlines section). So letâs stop trying to disable it whack-a-mole style, and start... Read more »OSI Layers in Routing Protocols
Now and then, someone rediscovers that IS-IS does not run on top of CLNP or IP and claims that, therefore, it must be a layer-2 protocol. Even vendors’ documentation is not immune.
Interestingly, most routing protocols span the whole seven layers of the OSI stack, with some layers implemented internally and others offloaded to other standardized protocols.
OSI Layers in Routing Protocols
Now and then, someone rediscovers that IS-IS does not run on top of CLNP or IP and claims that, therefore, it must be a layer-2 protocol. Even vendors’ documentation is not immune.
Interestingly, most routing protocols span the whole seven layers of the OSI stack, with some layers implemented internally and others offloaded to other standardized protocols.
Cisco Live 2024 â an Englishman in Vegas
Once again this year, Cisco Live US 2024 will take place in Las Vegas, Nevada, from June 2 to 6, 2024. I’m already registered and I’m looking forward to it! This year will be my 11th time attending Cisco’s annual conference in person, in both Europe and the United States. Straight to the point I’ve already written a few posts in previous years about what’s interesting to see and do at Cisco Live, and whether the conference is worth attending in person (and of course, it’s worth it!). This…
The post Cisco Live 2024 – an Englishman in Vegas appeared first on AboutNetworks.net.
Tech Bytes: How SR Linux Lets You Take Control Of Your Data Center (Sponsored)
On todayâs Tech Bytes, we explore SR Linux, the network operating system developed by todayâs sponsor Nokia. Why should you care about the network OS running in your data center? Nokia designed SR Linux to support automation, orchestration, and customization. Weâll dig into SR Linuxâs support for YANG and gNMI and how that ties into... Read more »The New AI Era: Networking for AI and AI for Networking*
As we all recover from NVIDIAâs exhilarating GTC 2024 in San Jose last week, AI state-of-the-art news seems fast and furious. Nvidiaâs latest Blackwell GPU announcement and Metaâs blog validating Ethernet for their pair of clusters with 24,000 GPUs to train on their Llama 3 large language model (LLM) made the headlines. Networking has come a long way, accelerating pervasive compute, storage, and AI workloads for the next era of AI. Our large customers across every market segment, as well as the cloud and AI titans, recognize the rapid improvements in productivity and unprecedented insights and knowledge that AI enables. At the heart of many of these AI clusters is the flagship Arista 7800R AI spine.
NB471: Nvidia Unveils 800G Ethernet, InfiniBand Switches For AI Fabrics; âGhost Jobsâ Haunt Job Boards
Take a Network Break! Nvidia announces new 800G switches, one for Ethernet and one for InfiniBand, for building AI fabrics. Nvidia also announces an “AI supercomputer,” a rack-scale pre-built bundle of Nvidia GPUs and CPUs connected via InfiniBand switches. The NaaS startup Meter announces new campus switches and what it calls a “digital twin” capability,... Read more »The network digital twin GOAT
In its most rudimentary terms, a digital twin in the realm of networking is the concept of emulating or simulating a like-for-like topology of a production...
The post The network digital twin GOAT appeared first on /overlaid.
Navigating the Next Frontier of Wi-Fi 7 Performance
As we move closer to fully realizing the potential of Wi-Fi 7, it becomes evident that the RF, signaling, and throughput tests are not merely procedural checkpoints but the pillars of excellence in wireless communication.netlab: Building Leaf-and-Spine Fabrics with the Fabric Plugin
netlab release 1.7.0 added the fabric plugin that simplifies building lab topologies with leaf-and-spine fabrics. All you have to do to build a full-blown leaf-and-spine fabric is:
- Specify the default device type
- Enable the fabric plugin
- Specify the number of leaves and spines in the fabric.
For example, the following lab topology builds a fabric with Arista cEOS containers having two spines and four leaves:
netlab: Building Leaf-and-Spine Fabrics with the Fabric Plugin
netlab release 1.7.0 added the fabric plugin that simplifies building lab topologies with leaf-and-spine fabrics. All you have to do to build a full-blown leaf-and-spine fabric is:
- Specify the default device type
- Enable the fabric plugin
- Specify the number of leaves and spines in the fabric.
For example, the following lab topology builds a fabric with Arista cEOS containers having two spines and four leaves:
Azure Networking: Cloud Scale Load Balancing
Introduction
During the load balancer deployment process, we define a virtual IP (a.k.a front-end IP) for our published service. As a next step, we create a backend (BE) pool to which we attach Virtual Machines using either their associated vNIC or Direct IP (DIP). Then, we bind the VIP to BE using an Inbound rule. Besides, in this phase, we create and associate health probes with inbound rules for monitoring VM's service availability. If VMs in the backend pool also initiate outbound connections, we build an outbound policy, which states the source Network Address Translation (SNAT) rule (DIP, src port > VIP, src port).
This chapter provides an overview of the components of the Azure load balancer service: Centralized SDN Controller, Virtual Load balancer pools, and Host Agents. In this chapter, we discuss control plane and data plane operation. â
Management & Control Plane â External Connections
Figure 20-1 depicts our example diagram. The top-most box, Loadbalancer deployment, shows our LB settings. We intend to forward HTTP traffic from the Internet to VIP 1.2.3.4 to either DIP 10.0.0.4 (vm-beetle) or DIP 10.0.0.5 (vm-bailey). The health probe associated with Continue reading
MMLU in Network Flow Optimization
In a previous post, I discussed how Maximum Flow problems can be used for network optimization. We focused on a scenario where demands were already routed in the network, and our objective was to determine the maximum demand that could be handled between a given source and a destination metro. We solved this problem by calculating the residual bandwidth for the graph, creating fake demand nodes for each metro with high-capacity edges to avoid them being bottlenecks, and applying Dinicâs algorithm between the source and the destination metro. This is also called a Single Commodity Flow Problem.
We then extended the problem to consider two metros sending traffic to the same destination sink and used the Network Simplex algorithm to determine the maximum traffic the network could accommodate. This is also known as a Multi Commodity Flow Problem. Finally, we validated our findings by routing the results through a network model.
In this post, we will discuss another constraint-based problem called Minimum Maximum Link Utilization (MMLU). The primary goal of MMLU is to route traffic demands in a network to minimize the maximum link utilization. In other words, we aim to distribute the traffic evenly across the network links to Continue reading
Worth Reading: Things We Know about Network Queues
Every time someone tries to persuade you to buy (expensive) big-buffer data center switches, take an antidote: the Things we (finally) know about network queues article by Avery Pennarun.