In the previous blog posts, we explored the simplest possible IBGP-based EVPN design and tried to figure out whether BGP route reflectors do more harm than good. Ignoring that tiny detail for the moment, let’s see how we could add route reflectors to our leaf-and-spine fabric.
As before, this is the fabric we’re working with:
Have you ever made a phone call, only to have the call cut as soon as it is answered, with no obvious reason or explanation? This analogy is the starting point for understanding connection tampering on the Internet and its impact.
We have found that 20 percent of all Internet connections are abruptly closed before any useful data can be exchanged. Essentially, every fifth call is cut before being used. As with a phone call, it can be challenging for one or both parties to know what happened. Was it a faulty connection? Did the person on the other end of the line hang up? Did a third party intervene to stop the call?
On the Internet, Cloudflare is in a unique position to help figure out when a third party may have played a role. Our global network allows us to identify patterns that suggest that an external party may have intentionally tampered with a connection to prevent content from being accessed. Although they are often hard to decipher, the ways connections are abruptly closed give clues to what might have happened. Sources of tampering generally do not try to hide their actions, which leaves hints of Continue reading
Cloudflare handles over 60 million HTTP requests per second globally, with approximately 70% received over TCP connections (the remaining are QUIC/UDP). Ideally, every new TCP connection to Cloudflare would carry at least one request that results in a successful data exchange, but that is far from the truth. In reality, we find that, globally, approximately 20% of new TCP connections to Cloudflare’s servers time out or are closed with a TCP “abort” message either before any request can be completed or immediately after an initial request.
This post explores those connections that, for various reasons, appear to our servers to have been halted unexpectedly before any useful data exchange occurs. Our work reveals that while connections are normally ended by clients, they can also be closed due to third-party interference. Today we’re excited to launch a new dashboard and API endpoint on Cloudflare Radar that shows a near real-time view of TCP connections to Cloudflare’s network that terminate within the first 10 ingress packets due to resets or timeouts, which we’ll refer to as anomalous TCP connections in this post. Analyzing this anomalous behavior provides insights into scanning, connection tampering, DoS attacks, connectivity issues, and other behaviors.
Maximum Segment Size (MSS) and MSS clamping are concepts that can be confusing. How do they relate to the MTU (Maximum Transmission Unit)? Before we setup a lab to demonstrate these concepts, let’s give some background. Note that this entire post assumes a maximum frame size of 1518 bytes, the original Ethernet definition, and does not cover jumbo frames.
Almost all interfaces today are Ethernet. The original 802.3 standard from 1985 defined the minimum size- and maximum size frame as the following:
With a maximum frame size of 1518 octets (bytes), that leaves 1500 bytes of payload as the Ethernet frame adds 18 bytes, 14 bytes of header and 4 bytes of trailer. The Ethernet frame is shown below:
An IPv4 IP header adds at least 20 bytes to the frame. The IPv4 header is shown below:
Note that more than 20 bytes can be used if the header has IP options. With no options in the IP header, there’s 1480 bytes remaining for the L4 protocol such as UDP or TCP.
TCP also adds a minimum of 20 bytes, meaning that the maximum payload Continue reading
The Texas Advanced Computing Center at the University of Austin is the flagship datacenter for supercomputing for the US National Science Foundation, and so what TACC does – and doesn’t do – is a kind of bellwether for academic supercomputing. …
TACC Fires Up “Vista” Bridge To Future “Horizon” Supercomputer was written by Timothy Prickett Morgan at The Next Platform.
Ages ago, I described how “traditional” network operating systems used the BGP Routing Information Base (BGP RIB), the system routing table (RIB), and the forwarding table (FIB). Here’s the TL&DR:
Rated horsepower for a compute engine is an interesting intellectual exercise, but it is where the rubber hits the road that really matters. …
The First AI Benchmarks Pitting AMD Against Nvidia was written by Timothy Prickett Morgan at The Next Platform.
Béla Várkonyi wrote a succinct comment explaining why so many customers prefer layer-2 VPNs over layer-3 VPNs:
The reason of L2VPN is becoming more popular by service providers and customers is about provisioning complexity.
The Internet can feel like magic. When you load a webpage in your browser, many simultaneous requests for data fly back and forth to remote servers. Then, often in less than one second, a website appears. Many people know that DNS is used to look up a hostname, and resolve it to an IP address, but fewer understand how data flows from your home network to the network that controls the IP address of the web server.
The Internet is an interconnected network of networks, operated by thousands of independent entities. To allow these networks to communicate with each other, in 1989, on the back of two napkins, three network engineers devised the Border Gateway Protocol (BGP). It allows these independent networks to signal directions for IP prefixes they own, or that are reachable through their network. At that time, Internet security wasn’t a big deal — SSL, initially developed to secure websites, wasn’t developed until 1995, six years later. So BGP wasn’t originally built with security in mind, but over time, security and availability concerns have emerged.
Today, the White House Office of the National Cyber Director issued the Roadmap to Enhancing Internet Routing Security, and Continue reading
I just realized how much I didn't know about Python Object-Oriented Programming. I thought I knew the basics, but a few days ago, while going through a Python course, I found out I was wrong. Before I forget what I’ve learned, I wanted to write this blog post and share it with you.
In this blog post, we’ll cover the difference between functions and methods, and what exactly ‘self’ means in Python. So, let’s get to it.
class MyClass:
def say_hello():
print('Hello')In this snippet, we’ve defined a Class called MyClass with a function named say_hello. But here’s a question for you - what do you call say_hello? Is it a function or a method?
It’s a common misconception to think that simply defining a function inside a Class automatically makes it a method. However, the distinction lies in how the function is accessed.
This lab delves into configuring a Cisco 1812 router, a legacy device with 100 Mbps […]
The post Cisco 1812 as Home Router first appeared on Brezular's Blog.
Segment Routing allows the network operator to deploy Traffic Engineering even with the most basic routers that support the bare minimum of features.
Traffic engineering is a set of techniques to influence the path a particular …
Nick Buraglio and Brian E. Carpenter published a free, open-source IPv6 textbook.
The book seems to be in an early (ever-evolving) stage, but it’s well worth exploring if you’re new to the IPv6 world, and you might consider contributing if you’re a seasoned old-timer.
It would also be nice to have a few online labs to go with it ;)
Hi all, welcome back to the Packetswitch blog. In today's post, we'll explore how to use NAPALM for managing device configurations. We'll focus on Arista EOS as our example. We'll cover the methods available in NAPALM and how to push, commit and revert configurations on Arista devices.
We'll start by explaining what NAPALM is and why you might want to use it. Then we'll move on to a few examples and take a look at what happens behind the scenes. This approach will give you a clear understanding of NAPALM's role in network configuration management and how it works with Arista EOS devices.
NAPALM stands for Network Automation and Programmability Abstraction Layer with Multivendor support. It's a Python library that helps network engineers manage and automate different network devices using a common set of functions. NAPALM solves the problem of dealing with multiple vendor-specific interfaces by providing a unified way to interact with network devices from various manufacturers. This means you can use the same code to manage devices from Cisco, Juniper, Arista, and others, saving time and reducing the complexity of network automation tasks.