Archive

Category Archives for "Networking"

BGP EVPN in SONiC – Part II: BGP EVPN – Inter-Subnet Forwarding

Introduction

 

Though inter-subnet communication in a BGP EVPN-based network between hosts happens through the anycast default gateway of the subnet, it can use two different forwarding models: Asymmetric and Symmetric Integrated Routing and Bridging (IRB). The basic difference between these two IRB models is how the packet is forwarded between the ingress and egress VTEPs.

When an ingress VTEP receives a frame whose destination is in a different subnet from the source, the initial forwarding operations are common to both IRB models. The VTEP performs a MAC lookup in the local VLAN's MAC address table and resolves the anycast gateway (AGW) MAC address. The packet is then routed toward the tenant IP-VRF, where an IP lookup determines the route toward the destination IP address. The routing information identifies the remote VTEP as the overlay next hop. The remote VTEP's underlay IP address is then resolved for use as the outer VXLAN destination IP address. This resolution can involve recursive lookup through the underlay routing table.

The forwarding paths diverge after the ingress VTEP performs the IP lookup. In asymmetric IRB, the ingress VTEP performs an additional MAC lookup in the bridge table associated with the destination subnet. The resulting Continue reading

BGP EVPN in SONiC – Part I: L2VNI for Inter-Switch VLAN Extension

 

Introduction

 

The previous chapter explained how to build an IPv6-only multi-ASN Clos fabric where IPv4 prefixes can be advertised with IPv6 link-local next hops.

In this chapter, we extend VLAN 10 between Leaf-101 and Leaf-102 using BGP EVPN as the control plane and VXLAN as the data plane.

Figure 7-1 shows the main building blocks required to provide this functionality. The IP underlay, where leaf and spine switches use IPv6 link-local addresses for eBGP peering, has already been configured in the previous chapter. Loopback0 is used only as the BGP Router ID and is not advertised to any peer.

The IP address of Loopback1, in turn, is used as the VXLAN Tunnel Endpoint (VTEP) address. Each switch therefore advertises its Loopback1 IP address using BGP IPv4 Unicast so that the VTEP addresses are reachable across the fabric. This address identifies the local VTEP in the EVPN control plane and is used as the BGP next hop for EVPN routes. A VXLAN packet sent to a remote VTEP uses the remote VTEP address as the destination address in the outer IP header.

Each extended VLAN is mapped to an L2VNI (Layer-2 VXLAN Network Identifier). In Figure 7-1, VLAN 10 Continue reading

SONiC Deep Dive: BGP Update Message Processing

 

BGP Route Advertisement

The next step after configuring BGP peering using BGP Unnumbered with IPv6 link-local addresses is to advertise the host networks. The lower part of Figure 6-10 shows the sonic-cli configuration commands used to advertise the local VLAN subnet on each leaf. On Leaf-101, we advertise 10.0.10.0/24, which is the subnet for VLAN 10. On Leaf-102, we advertise 10.0.20.0/24, which is the subnet for VLAN 20.

By examining the BGP Loc-RIB on Leaf-102, for example, we can see that the next hop for 10.0.10.0/24, originated on Leaf-101, is the IPv6 link-local address of Spine-11's Ethernet0 interface.

Figure 6-10: IPv4 Routes Installed in the BGP Loc-RIB Table.

Figure 6-11 verifies that the host subnets learned through BGP have been installed in the IP routing table on all switches. For example, the destination prefix 10.0.10.0/24 is installed on Leaf-102 with the next hop fe80::e22:34ff:feb6:a and the outgoing interface Ethernet0.

This also illustrates the separation between the BGP control plane and the data plane. BGP uses IPv6 link-local addresses to establish the BGP session and exchange BGP messages carrying IPv4 NLRI, with an IPv6 link-local address specified as Continue reading

SONiC Deep Dive: BGP Peer Configuration – BGP Unnumbered

 

After enabling IPv6 on the Ethernet0 interface, we can configure BGP peering. Instead of statically defining a peer IP address and AS number, the BGP neighbor is defined at the interface level. This tells BGP to expect a neighbor and initialize the BGP peering over Ethernet0. Because our intent is to transport IPv4 traffic over the IPv6 network, we activate both the IPv4 and IPv6 address families. We also configure the peer as an external BGP (eBGP) neighbor by using a command remote-as external. This tells BGP that the peer must use an AS number different from the local AS number.

Because the network uses IPv6 as the transport for IPv4 traffic, IPv4 Network Layer Reachability Information (NLRI) exchanged through BGP use IPv6 next-hop addresses. BGP therefore needs the Extended Next Hop Encoding capability to support IPv4 routes with IPv6 next hops. In this configuration, the capability is explicitly enabled with the capability extended-nexthop command.

In FRRouting, the v6only option controls which IP version is used for interface-based BGP Unnumbered peering. Without v6only, FRR uses the interface's IPv6 link-local address for peering only when no suitable IPv4 address is configured on the interface. With v6only, FRR skips Continue reading

Introducing Adaptive Intelligence: Undermining the economics of every bot attack

Modern bot threats are increasingly driven by determined, sophisticated attackers. Often it is not even one person, but a group trading techniques with each other or a commercial service sold to anyone willing to pay. For many of them, getting past bot detection is a full-time job they genuinely enjoy. Block them and they get to work, finding a workaround. AI has simplified this further, making it even easier to set up complex configurations for attackers, lowering the overhead of an attack. 

This shift puts defenders at an economic disadvantage. Responding and adapting to new attacks takes care, evidence, and effort to ensure efforts to block attackers don’t impact real users on the way. Attackers have no such concerns and are primarily constrained by their time and their pool of proxies, and ensuring their infrastructure providers don’t shut down their accounts.

Their advantage is the cost of adaptation. Attackers can adapt as often and continuously as they need, while most defenses are deployed in discrete, managed releases. Cloudflare analyzes more than a trillion requests a day for signs of automated abuse, so we see how fast attackers change tactics. That gap in responsiveness is widening.

The inconvenient truth: bot Continue reading

Why Is My Switch Still Red? The Future of Network Switches

Rethinking Network Switches The rate of technological change today can seem overwhelming but if you are old enough, you start to realize its pretty much more of the same. My biggest fear with tech change is that I don't want it to happen TO me. I may not be in a position to be in READ MORE

The post Why Is My Switch Still Red? The Future of Network Switches appeared first on The Gratuitous Arp.

BotBase for Operators: A clearer path to joining Cloudflare’s directory of bots and agents

Last month, on our second Content Independence Day, we announced a couple of features designed to give website owners more visibility and control over automated traffic: BotBase added a searchable directory of known bots to the Cloudflare dashboard, while Business Insights helped owners understand how crawlers interact with their content. We know that the ecosystem of bots is vast, making it all the more important for site owners to be able to manage bot traffic sustainably.

But this ecosystem goes both ways. While website owners need to decide which automated traffic they allow, bot operators need a clear way to identify themselves, explain what their bots do, and keep that information current. BotBase works best when both sides can participate.

When we launched BotBase, we said we would build tools to bring bot operators into this ecosystem. Until now, their experience largely ended at submission. After pressing submit, an operator had no easy way to check the submission's status, understand why it was rejected, or update an existing entry. Today, we start to change that with the launch of BotBase for Operators, tackling what bot operators need first: transparency.

A new home for bot submissions

Imagine you’re a bot operator Continue reading

The Safest Place to Run an AI Agent Is On a Cluster That Doesn’t Trust It

Every organization running AI agents has already made a hosting decision. Most made it by accident.

The sales team switched on the agent built into their CRM. Engineering is piloting a coding agent in a vendor’s cloud. Someone on the data team deployed a LangGraph service to a VM with a database key in an environment variable, and someone else is running an agent framework on a laptop with production credentials in a dotfile. Each of these is a hosting decision. Each one quietly settled who holds the agent’s credentials, what network paths it can reach, what gets recorded when it acts, and who can stop it. Nobody ran an architecture review, because no single deployment looked big enough to deserve one.

The scale says otherwise. By May 2025, 82% of organizations surveyed by SailPoint were already using AI agents. Only 44% had policies for securing them, 80% said their agents had already taken unintended actions, and 23% had watched an agent get tricked into revealing credentials. A year later the bill arrived: IBM’s 2026 Cost of a Data Breach report found that one in four malicious breaches is now AI-enabled, up 56% in a single year, and that those Continue reading

How we saved 100 terabytes of memory by optimizing 1.1.1.1’s DNS cache

Big Pineapple, the platform behind 1.1.1.1, Gateway DNS, DNS Firewall, AS112, and several other Cloudflare DNS services, stores over 250 billion DNS cache entries at any given time. At that scale, wasting a single byte per entry costs more than 250 gigabytes of memory across our fleet.

Five successive changes to how cache entries are stored in memory cut the per-entry footprint by over 50%. Across our fleet, these changes freed up roughly 100 terabytes of memory, equivalent to the amount of RAM in 130 of our Gen 13 servers. The cache also got faster. Insert throughput rose 43% and lookup latency dropped 19%, as fewer allocations and better memory locality meant we did not trade speed for space.

What we cache

On cold start, Big Pineapple starts out with an empty cache. As DNS queries arrive, the cache fills until it hits its maximum entry count, at which point we evict older or less popular items to make room.

The exact cache size varies by data center. When EDNS Client Subnet (ECS) is in use, authoritative servers return different answers depending on the client's network, so we cache multiple versions of Continue reading

Dear Junos, Tunnels Are Not Virtual Links

In late June, we added GRE tunnels to netlab, including a Junos implementation. It looked great (as in “everything worked”) until I changed the integration tests to have GRE tunnels between a tested device and a pair of FRR containers. All other implementations worked as before, but Junos failed to establish an OSPFv3 adjacency over the GRE tunnel with FRR.

Stefano Sasso quickly identified the culprit: Junos OSPFv3 process thinks it should send the DBD packets over GRE tunnels with MTU set to zero (the behavior reserved for virtual links)1.

Read more …

Testing DDoS mitigation software

The recently released open source sflowgen tool is a synthetic sFlow generator intended for testing, demonstrations, dashboards, and attack-detection validation. This article uses sflowgen to test the DDoS Protect application.

The screen capture shows how sflowgen DDoS attack telemetry appears in the DDoS Protect dashboard. Charts in the dashboard show different types of DDoS attack. You can see normal low level background activity below the red horizontal threshold line. DDoS traffic can be seen ramping up on the udp_flood and ip_flood charts and leveling off once the attack reaches maximum intensity. Notice that as soon as the attack traffic crosses the threshold, the Controls chart indicates that a Pending control has been created to mitigate the attack.

The Controls table shows the udp_flood attack against host 10.10.0.42 using port 443 as the attack vector. In this case the control action is set to drop, i.e. use a Remotely Triggered Black Hole (RTBH) as the mitigation action. The pending status indicates that it is waiting for user confirmation before being applied.

The Settings tab has been configured to add a local address group containing the 10.10.0.0/24 and 2001:db8:10::/64 CIDRs used in the default Continue reading

The Cloudflare Blog – Brought to you by EmDash

You likely noticed the recent redesign of the Cloudflare Blog. We added dark mode, modernized the look and feel, and made a lot of other small improvements along the way.

What you might not have noticed – well, except for those who are more terminally online – is that the redesign was part of a much bigger migration project. On Wednesday, August 12, we moved the blog to EmDash, a content management system (CMS) built especially to work on Astro and with Cloudflare.

We’ll take you into the migration story – what we learned and how EmDash got better – as well as into the benefits we’re already seeing from a new platform.

We are Customer Zero

At Cloudflare, Cloudflare itself is Customer Zero. This means that we use our products. And – in use – we make them better for ourselves and our customers.

This is a very real cultural value at Cloudflare. The burden of proof is on you if you want to use an external vendor. Why can’t that team support you, what gaps are there, why can’t those gaps be filled, and are those “gaps” true requirements?

This preference is even enshrined in our internal Continue reading

NB588: Active Threats Target Siemens PLCs; IBM Chills Qubits With Modular Cryogenics

Take a Network Break! It’s a Red Alert double feature for Oracle’s Internet Directory LDAP server and Cisco’s Secure Workload Software. In tech news, US law enforcement and intelligence agencies release a joint advisory warning of active threats against Siemens PLCs, Marvell wins a deal to make chips for Google that could bring billions in... Read more »

An interactive introduction to the spanning tree protocol

Warning

This post contains interactive examples. To visualize and interact with them, you need to leave your RSS reader.

Imagine you rent office space for a three-day event. You quickly set up a few Ethernet switches and tape some cables on the floor to get everyone online. Unfortunately, Stan, your clumsiest coworker, kicks out a cable every time he gets up for coffee. You could add extra cables, but then you’d get a broadcast storm: Ethernet packets that loop and multiply until nothing else gets through.

That’s where the spanning tree protocol (STP) comes in. STP blocks just enough of your spare cables to leave a loop-free tree. When Stan strikes again, it rebuilds the tree in a second, leaving some time for Blobby, your one-person support crew, to reconnect the cable. See for yourself: the diagram below runs a real STP implementation in your browser!

:demo

A1 @0,0 prio=4096
A2 @0,1
A3 @0,2
A4 @0,3

B1 @1,0 prio=8192
B2 @1,1
B3 @1,2
B4 @1,3

C1 @2,0 prio=8192
C2 @2,1
C3 @2,2
C4 @2,3

A1 -- A2 hazard=0
A2 -- A3 hazard=0
A3 -- A4 hazard=0
B1 -- B2
B2 -- B3
B3 -- B4
C1 -- C2  Continue reading

A non-interactive introduction to the spanning tree protocol

Imagine you rent office space for a three-day event. You quickly set up a few Ethernet switches and tape some cables on the floor to get everyone online. Unfortunately, Stan, your clumsiest coworker, kicks out a cable every time he gets up for coffee. Spare cables would fix that, but a loop turns into a broadcast storm: Ethernet packets multiply until nothing else gets through. That’s where the spanning tree protocol comes in: it blocks just enough of the spare cables to leave a loop-free tree, and rebuilds it in a second each time Stan strikes again.

This content is also available as a text version, with interactive demos that run a real implementation directly in your browser!

This video is an experiment.1 Honestly, except for Radia Perlman reading her poem,2 you should read the original article instead. It presents the same content, but you can play with the interactive examples, which are the main contribution. On the other hand, if you happen to like the video, be sure to tell me in the comments!

  1. I thought automated tools would produce this video in a couple of hours. In the end, it was another rabbit hole Continue reading

AI Red Team Agents Automate Attacks on your AI Agents. Runtime Policies Automate their Defense.

The AI red teaming market grew up fast this year. OpenAI bought Promptfoo, Cisco and Microsoft shipped automated attack suites, and a seed-stage startup publicly compromised 50 of 55 live customer service bots. These platforms find real problems at a scale no human team can match. But when you read the findings closely, a pattern emerges: agents talked into refunds, transfers, and data leaks they had standing authority to perform. Patching the prompt fixes one phrasing until the next model update. Constraining the authority fixes the class. The first job belongs to a red team platform. The second belongs to your runtime, and no scanner will do it for you.

In April 2026, General Analysis raised a $10M seed round on the strength of an uncomfortable demonstration: its adversarial agent attacked 55 live customer service bots and compromised 50 of them. Not lab models, but live systems with real customers and real tool access. This post is about the market behind that demonstration: who now automates the attacker’s role, what the attacks keep finding, and why the fix that lasts is runtime policy rather than a better prompt.

What an AI red team agent actually does

A traditional red team Continue reading

SONiC Deep Dive: BGP Unnumbered for IPv4

 

Chapter 6: BGP Unnumbered for IPv4

 

Introduction

 

This chapter explains how an IPv6-only transport network can provide connectivity between IPv4 networks by using IPv6 link-local addresses as next-hop addresses for IPv4 routes.

The first part of the chapter starts by showing how to configure interfaces to enable IPv6 and automatically generate IPv6 link-local addresses. These addresses can then be advertised to IPv6 peers using Router Advertisement (RA) messages defined by the IPv6 Neighbor Discovery Protocol (NDP). This provides the IPv6 link-local addressing required to establish BGP Unnumbered peering. Because the focus of the book is SONiC NOS, this section also shows how locally configured, interface-specific IPv6 information, as well as information received from neighboring devices, is represented in the SONiC Redis databases.

The second part of the chapter introduces how to configure external BGP peering using IPv6 link-local addresses without explicitly specifying the neighbor's IPv6 address or ASN. This simplifies automation by reducing the number of switch-specific configuration parameters. As in the first part, we examine the relevant Redis database tables after configuration and verification.

Figure 6-1 depicts the example topology used in this chapter. The physical topology is based on two-tiers Clos topology, with a single Continue reading

1 2 3 … 3,530