Delivering HTTP/2 upload speed improvements
Cloudflare recently shipped improved upload speeds across our network for clients using HTTP/2. This post describes our journey from troubleshooting an issue to fixing it and delivering faster upload speeds to the global Internet.
We launched speed.cloudflare.com in May 2020 to give our users insight into how well their networks perform. The test provides download, upload and latency tests. Soon after release, we received reports from a small number of users that sometimes upload speeds were underreported. Our investigation determined that it seemed to happen with end users that had high upload bandwidth available (several hundreds Mbps class cable modem or fiber service). Our speed tests are performed via browser JavaScript, and most browsers use HTTP/2 by default. We found that HTTP/2 upload speeds were sometimes much slower than HTTP/1.1 (assuming all TLS) when the user had high available upload bandwidth.
Upload speed is more important than ever, especially for people using home broadband connections. As many people have been forced to work from home they’re using their broadband connections differently than before. Prior to the pandemic broadband traffic was very asymmetric (you downloaded way more than you uploaded… think listening to music, or streaming a movie), Continue reading
This feed has moved and will be deleted soon. Please update your subscription now.
The publisher is using a new address for their RSS feed. Please update your feed reader to use this new URL:
MUST READ: What I’ve learned about scaling OSPF in Datacenters
Justin Pietsch published a fantastic recap of his experience running OSPF in AWS infrastructure. You MUST read what he wrote, here’s the TL&DR summary:
- Contrary to popular myths, OSPF works well on very large leaf-and-spine networks.
- OSPF nuances are really hard to grasp intuitively, and the only way to know what will happen is to run tests with the same codebase you plan to use in production environment.
Dinesh Dutt made similar claims on one of our podcasts, and I wrote numerous blog posts on the same topic. Not that anyone would care or listen, it’s so much better to watch vendor slide decks full of latest unicorn dust… but in the end, it’s usually not the protocol that’s broken, but the network design.
The Making of an RFC in today’s IETF
These days the process of making an RFC involves extensive review. You might think that the result of this truly exhaustive document review process is some bright shiny truth that is stated with precision and clarity. But that is not necessarily so. Why not?Zero-Touch Provisioning for Cisco IOS
The official documentation to automatically upgrade and configure on first boot a Cisco switch running on IOS, like a Cisco Catalyst 2960-X Series switch, is scarce on details. This note explains how to configure the ISC DHCP Server for this purpose.
When booting for the first time, Cisco IOS sends a DHCP request on all ports:
Dynamic Host Configuration Protocol (Discover)
Message type: Boot Request (1)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 0
Transaction ID: 0x0000117c
Seconds elapsed: 0
Bootp flags: 0x8000, Broadcast flag (Broadcast)
Client IP address: 0.0.0.0
Your (client) IP address: 0.0.0.0
Next server IP address: 0.0.0.0
Relay agent IP address: 0.0.0.0
Client MAC address: Cisco_6c:12:c0 (b4:14:89:6c:12:c0)
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (53) DHCP Message Type (Discover)
Option: (57) Maximum DHCP Message Size
Option: (61) Client identifier
Length: 25
Type: 0
Client Identifier: cisco-b414.896c.12c0-Vl1
Option: (55) Parameter Request List
Length: 12
Parameter Request List Item: (1) Subnet Mask
Parameter Request List Item: (66) TFTP Server Name
Parameter Request List Item: (6) Domain Name Server
Parameter Request List Item: Continue readingCEX (Code EXpress) 13. Creating your own Python modules.
Hello my friend,
Recently we have learned how to use the external modules to make your Python’s code more powerful. At some point, perhaps already now, you started creating user-defined functions so good that you would like to re-use them in other projects.
Automate all the things
Network automation is one of the most important things named by CIOs in Gather’s research. As such, the companies are (and will be) looking for the experts, who are able to develop new solutions and find creative ways to improve networks’ efficiency via automation. And we are keen to help you with that?
At our network automation training, either self-paced or instructor lead, you will learn the leading technologies, protocols, and tools used to manage the networks in the busiest networks worldwide, such as Google data centres. However, once you master all the skills, you will be able to automate the network of any scale. You will see the opportunities and you will exploit them.
Secret words: NETCONF, REST API, gRPC, JSON , XML, Protocol buffers, SSH, OpenConfig, Python, Ansible, Linux, Docker; and many other wonderful tools and techniques are waiting for you in our training!
Don’t miss opportunity to start your network Continue reading
Heavy Networking 536: Arrcus Reimagines The Chassis Router With Its Virtualized Distributed Router (Sponsored)
Today's Heavy Networking dives into sponsor Arrcus's Virtualized Distributed Router, new software that transforms the monolithic chassis that can scale to thousands of ports while being operated and managed like a single device. Our guests are Murali Gandluru, Keyur Patel, and Nalin Pai from Arrcus.Heavy Networking 536: Arrcus Reimagines The Chassis Router With Its Virtualized Distributed Router (Sponsored)
Today's Heavy Networking dives into sponsor Arrcus's Virtualized Distributed Router, new software that transforms the monolithic chassis that can scale to thousands of ports while being operated and managed like a single device. Our guests are Murali Gandluru, Keyur Patel, and Nalin Pai from Arrcus.
The post Heavy Networking 536: Arrcus Reimagines The Chassis Router With Its Virtualized Distributed Router (Sponsored) appeared first on Packet Pushers.
Opening Up Remote Access with Opengear
The Opengear OM2200
If you had told me last year at this time that remote management of devices would be a huge thing in 2020 I might have agreed but laughed quietly. We were traveling down the path of simultaneously removing hardware from our organizations and deploying IoT devices that could be managed easily from the cloud. We didn’t need to access stuff like we did in the past. Even if we did, it was easy to just SSH or console into the system from a jump box inside the corporate firewall. After all, who wants to work on something when you’re not in the office?
Um, yeah. Surprise, surprise.
Turns out 2020 is the Year of Having Our Hair Lit On Fire. Which is a catchy song someone should record. But it’s also the year where we have learned how to stand up 100% Work From Home VPN setups within a week, deploy architecture to the cloud and refactor on the fly to help employees stay productive, and institute massive change freezes in the corporate data center because no one can drive in to do a reboot if someone forgets to do commit confirmed or reload in 5.
Remote Continue reading
JUNOS | Filter-Based Forwarding
Alright, so Filter-Based Forwarding is nothing new. The technology has been around for a while and is relatively well documented. However, I wanted to share a specific use case where Filter-Based Forwarding can be extremely useful. In this scenario, we’re going to use Filter-Based Forwarding to forward traffic to a dedicated VRF where it is then pushed through a DDOS appliance and back to the router via a different VRF.
This construct is very useful when you only need to pass specific ingress traffic through the DDOS appliance. For example, customer destination prefixes who are paying for a DDOS service. Or traffic from certain source prefixes that are known to be malicious. Return traffic in either scenario is not passed via the appliance and is routed directly back to the source.
Challenge Statement
Specific ingress traffic received from transit & peering providers, via the TRANSIT VRF, must be pushed to the DIRTY VRF. The traffic must then be forwarded back towards the TRANSIT VRF via an appliance for inspection. Once the traffic is received back into the TRANSIT VRF it is onward routed as normal.
Solution
The solution involves defining the prefixes that should be considered within the Filter-Based Forwarding Continue reading
Mapping Intermediary Liability in Latin America
Thanks to our Chapters in Latin America, we now have a clearer map of the intermediary liability regulatory landscape across the region.
Intermediary liability answers the question, “Should Internet intermediaries (ISPs, web hosting and cloud services, social media platforms, etc.) be liable for content posted or for actions performed by others, such as, for example, their users?”
The success of the Internet depends on intermediary liability regimes that protect Internet providers – by ensuring responsibility for user behavior is on the users themselves, not on the intermediaries upon which they rely (both at the infrastructure and content layers).
The way legal frameworks deal with intermediary liability around the world can impact the Internet way of networking in different ways.
In some countries, intermediary liability legislation is well known: the 1996 US Communications Decency Act (Section 230) and the Brazilian Internet Bill of Rights, for example. But in much of the world it is covered by other more general-purpose regulations, such as tort law, consumer protection law, and child protection law.
We asked our local community to help us map and monitor the current regimes that apply to Internet intermediaries in their countries, so that our work can Continue reading
Working Collaboratively to Improve Emerging Network Time Security Implementations
Accurate and secure time is essential for the security and trustworthiness of the Internet. Many systems that we regularly interact with rely on accurate time to function properly. Accurate time also provides an essential foundation for online security, and many security mechanisms, such as digital certificates used for Transport Layer Security (TLS), depend on accurate timekeeping. The Network Time Protocol (NTP) provides time synchronization for clocks on computer networks.
NTP’s security mechanisms were designed back in an era when most Internet traffic was trusted, and the risk of attack was unlikely. Due to the continued exponential expansion of the Internet, these mechanisms became outdated and needed to be redesigned. The Internet Engineering Task Force (IETF) has been working on a specification for Network Time Security (NTS) for several years now. This specification was approved by the Internet Engineering Steering Group (IESG) in March of this year and is currently in the RFC editing process for the final publication. Over the course of the last couple of years, there have been a series of NTS projects held as part of the IETF Hackathons. These projects have worked to identify mistakes and ambiguities in the specification and to test and improve interoperability Continue reading
How Cloudflare uses Cloudflare Spectrum: A look into an intern’s project at Cloudflare
Cloudflare extensively uses its own products internally in a process known as dogfooding. As part of my onboarding as an intern on the Spectrum (a layer 4 reverse proxy) team, I learned that many internal services dogfood Spectrum, as they are exposed to the Internet and benefit from layer 4 DDoS protection. One of my first tasks was to update the configuration for an internal service that was using Spectrum. The configuration was managed in Salt (used for configuration management at Cloudflare), which was not particularly user-friendly, and required an engineer on the Spectrum team to handle updating it manually.
This process took about a week. That should instantly raise some questions, as a typical Spectrum customer can create a new Spectrum app in under a minute through Cloudflare Dashboard. So why couldn’t I?
This question formed the basis of my intern project for the summer.
The Process
Cloudflare uses various IP ranges for its products. Some customers also authorize Cloudflare to announce their IP prefixes on their behalf (this is known as BYOIP). Collectively, we can refer to these IPs as managed addresses. To prevent Bad Stuff (defined later) from happening, we prohibit managed addresses from Continue reading
Podcast: Trusting Routing Protocols
The can we trust routing protocols series of blog posts I wrote in April 2020 (part 1, part 2, response from Jeff Tantsura) culminated in an interesting discussion with Russ White and Nick Russo now published as The Hedge Episode 43.