Repost: Campus-Wide Wireless Roaming with EVPN

As a response to my LISP vs EVPN: Mobility in Campus Networks blog post, Route Abel provided interesting real-life details of a large-scale campus wireless testing using EVPN and VXLAN tunnels to a central aggregation point (slightly edited):


I was arguing for VxLAN EVPN with some of my peers, but I had no direct hands-on knowledge of how it would actually perform and very limited ability to lab it on hardware. My client was considering deploying Campus VxLAN, and they have one of the largest campuses in North America.

Optimal and Heuristic Approaches to Disjoint Path Routing

To doubt everything or to believe everything are two equally convenient solutions; both dispense with the necessity of reflection. - Henri Poincaré

Disjoint Path routing problems involve finding multiple paths between a source and a destination pair without any shared components. There are different types of disjoint paths, each with specific requirements. For example, link disjoint paths ensure that the paths do not have any common links, while node disjoint paths guarantee that the paths do not share any common nodes. SRLG disjoint paths are another variation, where the paths do not share any common risk groups.

These problems are commonly addressed to ensure network reliability, load balancing, and congestion reduction. The first problem we will examine is the MIN-SUM problem, which aims to determine a set of disjoint routes with the lowest overall cost. To solve this issue, we will look at integer linear programming (ILP). Afterwards, we will explore the MIN-SUM problem in the context of networks with shared risk link groups (SRLGs) and present corresponding solutions.

Basic Disjoint Problem

Let’s say our problem is to find a simple link disjoint paths between a given source and destination. One of the common ways we hear to do in Continue reading

What is platform engineering and when should you invest in it?

As application platforms grow larger, the idea of DevOps teams where developers support the software development lifecycle, but also manage infrastructure and the platform, is beginning to reach the limits of what these teams can support. Rather than taking their best application developers and making them work on infrastructure problems, more organizations are coming to the conclusion that a centralized platform team specialized in that area is a better use of their developers’ skill sets. But what exactly is the platform engineering team and how is it different from the DevOps team? Should your organization invest in platform engineering? Let’s take a closer look.

Platform engineering: What is it and how did it come about?

Platform engineering is essentially building (selecting/standardizing on), operating, and managing the infrastructure that supports 1st- and 3rd-party applications. In the days before cloud-native application development, what we saw was that there was a central team that provided compute infrastructure for enterprise developers to build and host their applications. At a certain point in time, those developers moved to a microservices-based architecture. They didn’t just need virtual machines or servers where they could run their applications; they were building those applications in a containerized form factor, Continue reading

HN730: Retail, Healthcare, Manufacturing and More Transform Their Branches with Next-Gen SD-WAN and SASE (Sponsored)

If you haven’t made the leap from traditional wide area networking to SD-WAN, or perhaps you’re thinking about adding security services to your SD-WAN infrastructure, this episode is for you. Rajesh Kari from Palo Alto Networks joins the show to share customer stories from the front lines of multi-branch businesses’ networks. Industry verticals including retail,... Read more »

Cross compiling Rust — Fixed

Set up build environment

rustup toolchain install nightly
rustup component add rust-src --toolchain nightly
apt install {binutils,gcc}-mips-linux-gnu

Create test project

cargo new foo
cd foo

Configure linker

mkdir .cargo
cat > .cargo/config.toml
[target.mips-unknown-linux-gnu]
linker = "mips-linux-gnu-gcc"
^D

Build

cargo +nightly build --release -Zbuild-std --target mips-unknown-linux-gnu

Change the “interpreter” to what the Ubiquiti system expects

cd target/mips-unknown-linux-gnu/release
patchelf --remove-needed ld.so.1 foo
patchelf --set-interpreter /lib/ld-musl-mips-sf.so.1 foo

Does it work?

$ ./foo
Hello, world!

Yay!

  • https://doc.rust-lang.org/rustc/targets/custom.html
  • https://doc.rust-lang.org/cargo/reference/config.html

Meta Llama 3 available on Cloudflare Workers AI

We are thrilled to give developers around the world the ability to build AI applications with Meta Llama 3 using Workers AI. We are proud to be a launch partner with Meta for their newest 8B Llama 3 model, and excited to continue our partnership to bring the best of open-source models to our inference platform.

Workers AI

Workers AI’s initial launch in beta included support for Llama 2, as it was one of the most requested open source models from the developer community. Since that initial launch, we’ve seen developers build all kinds of innovative applications including knowledge sharing chatbots, creative content generation, and automation for various workflows.  

At Cloudflare, we know developers want simplicity and flexibility, with the ability to build with multiple AI models while optimizing for accuracy, performance, and cost, among other factors. Our goal is to make it as easy as possible for developers to use their models of choice without having to worry about the complexities of hosting or deploying models.

As soon as we learned about the development of Llama 3 from our partners at Meta, we knew developers would want to start building with it as quickly as possible. Continue reading

Cloudflare named in 2024 Gartner® Magic Quadrant™ for Security Service Edge

Gartner has once again named Cloudflare to the Gartner® Magic Quadrant™ for Security Service Edge (SSE) report1. We are excited to share that Cloudflare is one of only ten vendors recognized in this report. For the second year in a row, we are recognized for our ability to execute and the completeness of our vision. You can read more about our position in the report here.

Last year, we became the only new vendor named in the 2023 Gartner® Magic Quadrant™ for SSE. We did so in the shortest amount of time as measured by the date since our first product launched. We also made a commitment to our customers at that time that we would only build faster. We are happy to report back on the impact that has had on customers and the Gartner recognition of their feedback.

Cloudflare can bring capabilities to market quicker, and with greater cost efficiency, than competitors thanks to the investments we have made in our global network over the last 14 years. We believe we were able to become the only new vendor in 2023 by combining existing advantages like our robust, multi-use global proxy, our lightning-fast DNS resolver, our Continue reading

Cross compiling Rust to Ubiquiti access point

This is not the right way to do it, as will become abundantly clear. But it works.

Set up build environment

rustup toolchain install nightly
rustup component add rust-src --toolchain nightly
apt install {binutils,gcc}-mips-linux-gnu

Create test project

cargo new foo
cd foo

Build most of it

This will build for a while, then fail.

cargo +nightly build --release -Zbuild-std --target mips-unknown-linux-gnu

For some reason it’s trying to use cc to link. I tried putting this in Cargo.toml, but it does nothing:

[target.mips-unknown-linux-gnu]
linker = "mips-linux-gnu-gcc"

But I found a workaround.

Temporarily change /usr/bin/cc to point to the mips gcc

It does not work if you do this before the previous step.

PREV="$(readlink -v /usr/bin/cc)"
sudo rm /usr/bin/cc
sudo ln -s /usr/bin/mips-linux-gnu-gcc /usr/bin/cc

Same command again

cargo +nightly build --release -Zbuild-std --target mips-unknown-linux-gnu

It should succeed. Yay.

Restore /usr/bin/cc

sudo rm /usr/bin/cc
sudo ln -s "${PREV?}" /usr/bin/cc

Change the “interpreter” to what the Ubiquiti system expects

cd target/mips-unknown-linux-gnu/release
patchelf --remove-needed ld.so.1 foo
patchelf --set-interpreter /lib/ld-musl-mips-sf.so.1 foo

Building it again

Probably easiest to rm -fr target, and go back to the step “Build most of it”.

Does it work?

$ ./foo
Hello, world!

Yay!

  • https://doc.rust-lang.org/rustc/targets/custom.html