Hi, I’m Deniz 👋

Dual-homed servers use IP-unnumbered physical interfaces. A dedicated dummy interface (not lo) is assigned to each server as its IPv4 node address. FRR runs between the servers and the ToR switches to provide node-level connectivity, advertising the server’s node IP (dummy interface address) and receiving the default route from the ToRs. Using a bond interface between ToRs can also be used for redundancy and failover for server connectivity. You may also configure Layer 3 interfaces. The main issue is about node identity and service continuity during the failure of a single link. Using a bond interface or a dummy interface seems like a more usable approach. ...

ESI Multi-Homing and ARP Suppression Issue: Duplicate Packets & Flooding When ESI is not functioning correctly, you may observe duplicate packets destined for hosts behind the ESI. Remote switches might flood traffic toward the ESI switches instead of handling it efficiently. TCAM Carving for ARP Suppression To use the suppress-arp feature effectively and prevent unnecessary flooding, you must allocate sufficient TCAM resources on the switch hardware. 1 2 3 # Configure TCAM carving for ARP suppression hardware access-list tcam region racl 512 hardware access-list tcam region arp-ether 256 double-wide Warning: It was observed that enabling suppress-arp caused reachability and ARP resolution to break between hosts when attempting to use RFC 5549 (BGP Unnumbered / IPv6 underlay) between Spines and Leafs for IPv4 and EVPN. Note that an IPv6 underlay is generally not supported for Cisco Nexus 9300/9500v platforms in this context. ...

Overview This document outlines the security policies and dynamic routing configurations for the network gateway, including firewall rules via nftables and BGP peering via BIRD. How Zones are Defined and Connected In this architecture, zones (zone_blue, zone_green, zone_red, and wan) directly correspond to network interfaces (either physical NICs, VLAN tags, or bridge interfaces) on the Gateway Server. Chain Structure (nftables): The firewall strictly controls traffic flow by matching the input interface (iif) and output interface (oif). For example, iif zone_blue oif zone_green tcp dport 22 accept explicitly states: If a packet enters the server via the zone_blue interface and is destined to leave via the zone_green interface on TCP Port 22, allow it. ...

Overview This document describes a method for simulating multiple servers belonging to different network domains on a single Linux host. Each simulated server runs inside its own Linux network namespace and is connected to a dedicated VLAN. Training and demonstration environments Each namespace behaves as an independent server with: Its own IP address Its own MAC address An SSH service A simple HTTP server Network Topology The Linux host uses the following interfaces: ...

My intent is to test and understand the reside-on-chassis and redirect-type options on DVR ports. Topology I have used GNS3 for testing OVN setup; All servers are using Fedora-Cloud-Base-38-1.6. All servers have 3 interfaces; One interface for management access. One interface for OVN control packets and the overlay tunnel interface. One interface for external connection, simulating a TOR switch connection for the various purposes used in tests. I have not used gw2, it can be used for HA tests. ...

Why anycast inside the fabric is harder than it looks An anycast service is advertised from multiple hosts into the data center fabric — the same prefix, the same service IP, originated from several places at once. The promise is appealing: multiple next hops for one service prefix gives you load balancing, fast failover, and horizontal scalability without any state in the network. The catch is that for every leaf to actually use all of those origins, the fabric has to carry and install multiple equal-cost paths for a single prefix end to end. That is not BGP’s default behavior, and the moment you combine it with two things modern fabrics love — an IPv6 unnumbered underlay and IPv4-in-IPv6 next hops (RFC 5549) — one of the most common EVPN disambiguation tricks stops working. This post walks through why, and what the realistic options are. ...

Companion posts. This is the hands-on lab — real NX-OSv configs, the tests I ran, and where they broke. For the high-level summary see Anycast Inside the Data Center; for the deeper protocol write-up (overlay index, recursive resolution, why pure-IP fabrics lose per-host ECMP) see Anycast in EVPN/VXLAN Fabrics: The IPv6 Unnumbered and RFC 5549 Problem. Why Anycast is used for horizontal scaling and for better failure response. With modern orchestration and virtualization, a new instance of a service can be spawned on demand — by an engineer or by the system itself. ...

Part of an anycast series. This is the high-level summary. For the hands-on NX-OS lab (configs, the RFC 5549 failure, the working EVPN solution) see Anycast Inside an EVPN/VXLAN Fabric with BGP Unnumbered (RFC 5549), and for the deeper protocol treatment see Anycast in EVPN/VXLAN Fabrics: The IPv6 Unnumbered and RFC 5549 Problem. Why Anycast services are advertised from multiple hosts into the data center. The same service prefix is originated from several places at once, which gives you multiple next hops for that service — and with it, load balancing, better failover, and scalability. ...

In an EVPN/VXLAN fabric, the MAC address table is part of the control plane: when a MAC is learned or removed, the switch generates a BGP EVPN update so the rest of the fabric stays in sync. That tight coupling is exactly what makes EVPN work — but it also means that ordinary MAC aging on a quiet host can turn into a stream of BGP churn. This post is about a problem we chased down to the interaction between ARP timeout and MAC address-table timeout, and why the common assumption about “any packet refreshes the timer” is wrong. ...

⚠️ Modernization Notice These notes were written in 2018–2019. IPv6 CPE and OS support, DHCPv6 implementations, and ISP best practices have evolved significantly since then. Treat this as a record of real testing and the architectural decisions behind it, and validate against current RFCs, CPE datasheets, and OS release notes before deploying in production. Overview This post brings together two pieces of work I did on IPv6 for PPP broadband. The first is a set of notes and lab tests on running a single dual-stack PPP session per subscriber and assigning IPv6 prefixes to the CPE from a Cisco IOS XE BNG. The second is a design sketch for assigning static IPv6 prefixes per customer from a RADIUS/AAA backend. They belong together: the lab work shows how Cisco ISG/IOS XE actually behaves when prefixes arrive over RADIUS, and the design sketch is the natural next step once you decide that static, per-customer prefixes are what you want. ...