EVPN Flooding Bug, Network-Aware Scheduling Proven, Microsoft Breaks from OpenAI

1. Arista EOS EVPN Centralized Routing Has a Silent Flooding Problem — Here's the Fix

TL;DR: Ivan Pepelnjak and Arista engineer Naveen Kumar Devaraj document a non-obvious default in Arista EOS: spine switches in EVPN centralized routing designs do not advertise MAC+IP routes for their own locally connected hosts, causing leaf switches to flood routed traffic instead of using unicast forwarding. The fix is a single configuration command, but you have to know to look for it.

Key Points:

• In a centralized routing topology, only leaf switches generate MAC+IP EVPN routes. The spine (acting as the centralized router) generates IMET routes but does NOT advertise MAC+IP routes for its own hosts by default.
• Leaf switches receiving traffic destined for spine-attached hosts fall back to flooding, because they have no unicast MAC destination to forward to.
• Each router in a multi-router MAC-VRF must perform its own ARP resolution — there is no shared ARP learning across EVPN in this topology without explicit configuration.
• Fix: add redistribute router-mac system (or redistribute router-mac system ip for MAC+IP routes) to the spine's MAC-VRF instances. This triggers the spine to advertise its gateway MAC addresses via EVPN and eliminates the flooding.
• This is the third post in Pepelnjak's ongoing EVPN centralized routing series — the ARP/EVPN issues documented in earlier installments (EVPN Asymmetric IRB, ARP Issues in Centralized Routing) are cumulative. The series is building a complete map of where centralized routing departs from textbook behavior.

Deep Dive:

The Arista EOS behavior is technically correct per the EVPN RFC — the centralized router is not obligated to redistribute its own MAC addresses unless configured to do so. But "technically correct" is cold comfort when your fabric is flooding traffic silently. The failure mode is subtle: everything appears to work during initial testing because BUM flooding delivers packets, but flooding at scale kills performance and breaks any assumption your automation makes about unicast forwarding paths.

The practical implication for network engineers: if you're running EVPN centralized routing on Arista EOS and you haven't explicitly configured redistribute router-mac system, your spine is flooding for locally attached hosts. Check this before you run into it in production. The command is a one-liner, but the diagnosis can be hours of packet capture if you don't know where to look.

The deeper pattern here is more important: EVPN centralized routing is a design that looks simple on paper (just put the router at the spine) but has at least three layers of implementation-specific behavior you have to understand before it works reliably. Pepelnjak's series is doing the industry a service by documenting what vendors don't put in the marketing slides — this is what real production readiness looks like.

So What? If you're running or planning EVPN centralized routing on Arista EOS, add redistribute router-mac system to your spine MAC-VRF instances today and verify unicast forwarding paths aren't silently falling through to flood. Treat this ipSpace.net series as required reading before any EVPN centralized routing deployment.

Sourceshttps://blog.ipspace.net/2026/06/arista-eos-evpn-central-routing/, https://blog.ipspace.net/2026/05/arp-issues-evpn-central-routing/

2. NetKV Proves That Ignoring Network Topology in AI Scheduling Is Mathematically Unjustifiable

TL;DR: A new arXiv paper introduces NetKV, a network-aware scheduler for disaggregated LLM inference that reduces Time to First Token by up to 21.2% over round-robin and 17.6% over cache-aware-only scheduling — with no changes to hardware, transport, or inference engines. The authors prove formally that cache-only scheduling becomes "arbitrarily suboptimal as context length grows."

Key Points:

• Current disaggregated inference schedulers route based on compute load and prefix-cache locality alone. They ignore topological distance and dynamic congestion between prefill and decode instances — and the paper proves this is not just suboptimal but provably unbounded in badness as context grows.
• The fix is a "network cost oracle" — a thin interface between the network operator and the scheduler that reports tier rankings for decode instances based on distance and current congestion.
• NetKV, the greedy O(|D|) algorithm consuming this oracle, reduces mean TTFT by 21.2% over round-robin, 17.6% over tuned cache-aware scheduling, and lifts SLO attainment by up to 20.1 percentage points.
• The tier rankings hold up under stale telemetry — the algorithm degrades gracefully if the oracle's information is outdated, because the cost ranking is provably stable under small perturbations.
• No transport changes, no inference engine changes, no hardware changes required. This is a scheduler-layer intervention only.

Deep Dive:

This paper lands two days after Monday's "Move the Query, Not the Cache" paper (arXiv 2606.01502) and Marvell's Computex keynote declaring connectivity the AI scaling bottleneck. The sequence is telling: Monday established that the traffic pattern assumption (move the cache to the compute) is wrong at scale. Tuesday, Marvell showed training runs are stalling on cross-rack bandwidth. Wednesday, NetKV proves the scheduler layer isn't even accounting for the network it runs on.

The mathematical contribution is important. NetKV doesn't just show that network-aware scheduling helps empirically — it proves that any scheduler ignoring network topology is unboundedly bad as context length increases. That's a formal result, not a benchmark claim. It makes the case that network-aware scheduling must be part of the specification for disaggregated inference systems, not an optimization someone adds later.

For network engineers, the practical implication is in the network cost oracle interface. This is a standardizable API — the scheduler tells the network layer which decode instances are candidates, the network layer reports topology-aware cost rankings. If this interface gets standardized (similar to what MRC does for transport), it creates a well-defined contract between inference schedulers and datacenter networking. That's the right design boundary.

So What? When evaluating disaggregated inference infrastructure, add "does the scheduler use network topology information?" to your vendor questionnaire. NetKV is not yet production software, but it establishes the requirement — and any platform shipping without this capability is leaving up to 21% TTFT performance on the table.

Sourceshttps://arxiv.org/abs/2606.03910

3. Microsoft Build 2026: First In-House Reasoning Model, Copilot Gets Faster, and MRC Tooling Goes Open

TL;DR: Microsoft Build 2026 this week marked a structural shift: Microsoft shipped MAI-Thinking-1, its first in-house reasoning model trained entirely without OpenAI data, rolled MAI-Code-1-Flash to all GitHub Copilot tiers, and open-sourced MRC transport tooling (libMRC and NCCL integrations) — reducing its dependency on OpenAI across the model, code assistance, and infrastructure stacks simultaneously.

Key Points:

• MAI-Thinking-1 is a Mixture of Experts model with one trillion total parameters and thirty-five billion active, with a two hundred fifty-six thousand token context window. Trained on commercially licensed data only, no distillation from any third-party model. Currently in private preview on Microsoft Foundry.
• MAI-Code-1-Flash is a one hundred thirty-seven billion parameter sparse model (five billion active) tuned specifically for GitHub Copilot workflows. Rolling to all Copilot tiers — Free, Pro, Pro+, Max — starting June 2.
• MRC (Multipath Reliable Connection) tooling open-sourced: libMRC, NCCL integrations, and a verbs shim so existing RDMA applications run on MRC without source changes. This makes MRC practically deployable for organizations that aren't Microsoft or OpenAI.
• Microsoft now has operational shipping alternatives at every developer-facing tier: reasoning, coding, transcription, voice, and image generation — none requiring OpenAI.
• This is a dependency-reduction play at every layer simultaneously: model, API, compute (Maia 200/Cobalt 200), and network protocol (MRC). The strategic direction is hard to miss.

So What? If you build on Azure or GitHub Copilot, audit which models you're using and which tier you're paying for — MAI-Code-1-Flash rolling to Free tier means the cost/performance floor just changed. On the infrastructure side, the MRC open tooling is the most important item: if your organization is building RDMA-based AI infrastructure, the verbs shim means you can evaluate MRC without rewriting applications.

Sourceshttps://www.cnbc.com/2026/06/02/microsoft-unveils-new-ai-models-lessen-reliance-on-openai-lower-costs.html, https://microsoft.ai/news/introducingmai-code-1-flash/, https://news.microsoft.com/build-2026/

Rain: RDMA-Assisted In-Network Scheduling Closes the Microsecond Latency Gap

Programmable switches have long been proposed as a way to run centralized scheduling logic close to the data path. The arXiv Rain paper delivers a concrete architecture: RDMA-assisted in-network scheduling where the switch maintains a centralized task queue but bounds per-worker local queues to prevent starvation. The bidirectional on-switch queuing mechanism matches tasks and worker tokens directly in the switch fabric — no software round-trip. For applications with microsecond-scale service time requirements and strict tail latency SLOs (storage backends, distributed database row locks, real-time telemetry processing), this is the design pattern to watch. The combination of centralized coordination visibility and line-rate switching is not achievable with purely software-based schedulers.

Sourceshttps://arxiv.org/abs/2606.03352

Intel Bets the Agentic Compute Tier Is CPU-Bound: 36,864 Cores in a 100kW Rack

Intel and Foxconn announced a rack-scale reference design at Computex this week targeting agentic AI workloads — up to 128 Clearwater Forest Xeon processors delivering 36,864 cores and 384 TB of DDR5 in a 100kW rack. The thesis: AI models run on GPUs and AI accelerators, but the agent harnesses connecting those models to tools, terminals, code interpreters, and external APIs run on CPUs. OpenClaw (Intel's open agent framework), tool-calling loops, and multi-agent orchestration are CPU-bound latency-sensitive workloads, not GPU-bound throughput workloads. Intel is positioning Xeon 6+ as the compute tier between the user request and the GPU cluster. Whether this framing holds under real production load is unverified, but the architecture question — what runs the agent harness and where — is one the industry hasn't answered definitively.

Partners named in the reference design: Foxconn, Siemens, Hitachi, and SambaNova (SN-50 RDUs for model inference in the same rack).

Sourceshttps://www.theregister.com/ai-and-ml/2026/06/02/intel-and-pals-cram-36864-cpu-cores-into-a-100kw-rack-while-chasing-the-agentic-ai-dragon/, https://newsroom.intel.com/data-center/intel-puts-agentic-ai-xeon-6-networking-ai-systems

Alphabet Raises $80 Billion to Fund AI Infrastructure Expansion

Alphabet announced a combined equity offering of eighty billion dollars to fund AI infrastructure capital expenditures, with Berkshire Hathaway committing ten billion in a private placement. The structure: thirty billion in underwritten public offerings (a mix of mandatory convertible preferred stock and Class A/C common stock) plus a forty billion dollar at-the-market program starting in Q3. Alphabet guided 2026 capex at one hundred eighty to one hundred ninety billion dollars — with 2027 capex expected to increase significantly from there. The Berkshire investment is notable: Warren Buffett's firm historically avoids technology companies. Its participation signals that AI infrastructure capital expenditure is being repriced from speculative growth to capital-intensive infrastructure — the kind of asset Berkshire is comfortable underwriting.

The operational implication for datacenter and networking teams: at this capex scale, every infrastructure decision Alphabet makes about fabric design, cooling architecture, and power sourcing becomes an industry reference point within eighteen to twenty-four months.

Sourceshttps://techcrunch.com/2026/06/01/alphabet-plans-to-raise-80-billion-to-pay-for-ai-buildout/, https://www.cnbc.com/2026/06/01/alphabet-to-raise-80-billion-from-stock-sales-to-fund-ai-buildout.html

Simon Willison Locks an Agent in a WebAssembly Jail — and GPT-5.5 Hasn't Escaped Yet

Simon Willison released datasette-agent-micropython 0.1a0 this week — a plugin that gives Datasette Agent the ability to generate and execute Python code safely by running MicroPython inside a WebAssembly sandbox. The approach is elegant in its simplicity: instead of trying to restrict what an AI agent can do with a real Python interpreter (a losing battle), you give it a Python interpreter that's structurally incapable of reaching the host OS because the WebAssembly runtime enforces the boundary. MicroPython runs inside wasmtime; the sandbox cannot write to the filesystem, cannot make network calls, cannot access environment variables. The note in the release: "GPT-5.5 has so far failed to break out of the sandbox." That sentence should be on a t-shirt at the next network automation conference.

The practical pattern here extends well beyond Datasette. Any agentic workflow that needs to execute generated code — config templating, validation scripts, diagnostic queries — faces the same problem: you want the agent to have programming capability without giving it blast radius. WebAssembly-sandboxed interpreters are the right architectural answer, and Willison's work shows how low the implementation overhead actually is.

Sourceshttps://simonwillison.net/2026/Jun/2/datasette-agent-micropython/, https://simonwillison.net/2026/Jun/2/micropython-wasm/

No significant security architecture updates today. The agentic authorization pattern (action-boundary enforcement, scoped toolsets) documented in Monday's Meta AI Instagram story and Tuesday's Itential FlowAI coverage remains the live thread to watch.

• vLLM Semantic Router (arXiv 2603.04444): A signal-driven routing framework for Mixture of Modality model deployments. Composable signal orchestration combines sub-millisecond heuristic features (keyword patterns, context length, role-based auth) with neural classifiers (domain, embedding similarity) through configurable Boolean routing policies. Worth tracking if you're running multi-model deployments — the routing-as-policy pattern is the right abstraction. Source: https://arxiv.org/abs/2603.04444

• AI Infrastructure Pragmatism (DCK): DataCenter Knowledge published a useful perspective piece on navigating the AI boom without overbuilding — drawing on lessons from previous datacenter cycles (cloud overbuild 2016-18, edge compute hype 2019-21). The core argument: operators who built for confirmed demand rather than projected demand came out of those cycles stronger. The article is vendor-neutral and worth reading as a counterweight to the capex maximalism dominating hyperscaler coverage right now. Source: https://www.datacenterknowledge.com/data-center-construction/the-case-for-pragmatism-in-the-ai-infrastructure-boom

• ipSpace.net EVPN series: The centralized routing series continues. Follow the ipSpace.net blog for the next installment — Pepelnjak has been publishing roughly weekly and the series is building toward a complete reference architecture.
• MRC tooling in the wild: Now that libMRC and the NCCL integration are open, watch for early adopter reports from the research community. The verbs shim is the critical piece — if it works cleanly, MRC adoption can happen without rewriting existing RDMA applications.
• NetKV and the network cost oracle: The interface design in the NetKV paper deserves attention from switch and NIC vendors. If this becomes a standard API between schedulers and network layers, it changes what you need to expose from your switching infrastructure.

• Articles processed: 62 (from 22 RSS feeds + targeted web research)
• Topics researched: networking, automation, ai-ml, datacenter, science
• Primary items: 7 + fun one
• Dedup rejections: 11 (all from 2026-06-02 coverage within 72-hour cooldown)
• Quality score: 4.5/5