BGP ORIGIN attribute manipulation and its impact on the Internet

Border Gateway Protocol (BGP) is the de facto routing protocol of the Internet. It offers built-in mechanisms to allow entities, represented by Autonomous Systems (ASes), to express how they want to send and receive traffic on the Internet. One such mechanism is path attributes, which carry essential routing information and metadata for their associated route. The path selection algorithm processes some of these path attributes in a deterministic sequence to calculate the best path for this specific prefix.

Using our unique position on the Internet, we took an investigative look at one of the well-known mandatory attributes in BGP, the ORIGIN attribute. ORIGIN must be present in every BGP prefix announcement and should not be modified by any router after being set by the originating one. What we found through our own experiments was a dramatic ~70% of observed paths in numerous vantage points have a different ORIGIN value compared to what was set by the originating Autonomous System. This ORIGIN attribute manipulation has a significant impact on the way traffic is forwarded on the Internet, as we’ll explore in this post.

BGP ORIGIN and its operational history

The ORIGIN attribute indicates how a route was injected Continue reading

Hedge 313: Out of Band Management Networks

Most designers and operators default to carrying all traffic–including network management traffic–across the same paths as application data, or in band. Is this the right choice, or should operators seriously consider creating an out-of-band network just for network management? If you decide to build an out-of-band network, what are some of the considerations and lessons learned? Daryll Swer joins Tom and Russ to discuss.
 

 
download

IPB204: Tayga and IPv6 Translation

Andrew Palardy joins the hosts to discuss how Tayga, the open-source NAT64 daemon for Linux, is being updated to ensure it is up to date with all the current RFCs. Andrew explains how recent RFC compliance and UDP checksum fixes help resolve connectivity issues and how the new eBPF CLAT support arriving in NetworkManager promises... Read more »

Introducing Cache Response Rules

Today we’re excited to announce Cache Response Rules. These are a new rule type that runs after an origin server replies but before Cloudflare caches the content. 

If you've ever been irked watching something that should easily sail out of cache get dragged back to the origin by a stray Set-Cookie or wrong Cache-Control, headers that are sometimes hard or impossible to strip or change on the origin itself, then Cache Response Rules is that fix, applied at exactly the right moment.  

When and how caching decisions are made

A CDN cache and an origin server work as a pair. Their goal is to answer from the cache whenever possible and only go back to the origin when the edge can’t respond. Every point of cache hit ratio comes from getting that division of labor right. Check the cache when we shouldn't, and we waste a lookup that was always going to miss. Check it too rarely, the origin serves traffic the edge should have absorbed and the performance win evaporates.

Importantly, the origin guides the cache. When it returns a cacheable asset, its response headers tell Cloudflare how long it’s OK to serve it, when and Continue reading

What Happens to a VM’s IP When It Moves During Migration?

Why VM IP identity needs handling on Kubernetes

A KubeVirt VM runs inside a pod. That is the trick that lets Kubernetes schedule a VM like any other workload. It also means the VM and the pod have different lifecycles. The VM is long-lived and has a stable identity. The pod is disposable. When the VM reboots, gets evicted, or live-migrates, the pod underneath is destroyed and a new one is created.

That matters because a VM’s IP is load-bearing. Firewall rules, load balancer entries, and DNS records all point at it. On Kubernetes, standard pod IPAM ties the address to the pod, so a new pod would mean a new IP, and a changed IP is what breaks those dependencies. KubeVirt on its own does not carry the IP across a migration. Its issue tracker has a user reporting exactly this, with a maintainer confirming sticky IPs were never built into the project. The network identity needs something to carry it. That something is Calico.

The diagram below shows the difference this makes. Default pod networking on the left, Calico on the right.

How Calico keeps the IP

Calico’s approach is elegant and specific. Instead of building the IPAM Continue reading

TCG080: Skills Over MCP and More

What if your MCP server shipped with its own manual? Angie Jones, VP of Developer Experience at the Agentic AI Foundation, joins William and Eyvonne to break down the Skills Over MCP working group effort, which delivers Agent Skills through MCP’s existing resources primitive (think voice over IP, not skills versus MCP). Angie shares her... Read more »

NAN127: Scaling Network Automation Communities

Eric Chou welcomes Florian Lohden, a NetDevOps engineer and co-founder of the NetAuto Group, to discuss his community-building efforts and his latest adventures in network automation. Together they explore how adopting software development practices can help with network automation, and the importance of sharing knowledge within networking communities. Florian also talks about how he balances... Read more »

HS138: When “One Cloud To Rule Them All” Is NOT the Answer: Repatriation for AI and more

Some enterprises are finding reasons to pull back from a cloud-first IT strategy and run workloads in on-premises data centers. John and Johna dig into why companies are making the change, including cost and AI security. They also discuss and the strategic implications for IT, and what organizations stand to gain—and lose—from repatriation.  Episode Links:... Read more »
1 2 3 3,889