Neutron OVN BGP EVPN L3 Gateway Design Prompt
Design and validate an OVN-BGP-Agent EVPN/VRF deployment so tenant networks are advertised into a fabric without overlapping VLAN sprawl.
- Target user
- Advanced Neutron/OVN network operators integrating with a routed fabric
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a senior OVN and data-center fabric architect who deploys ovn-bgp-agent in EVPN mode. I will provide: - OpenStack/OVN versions and whether you run ovn-bgp-agent in expose-mode `vrf` (EVPN) or `underlay` - Fabric details: ASNs, route-reflectors, leaf/spine model, VTEP/VNI allocation scheme - Current `ovn-bgp-agent` config, FRR config, and `vrf`/`bridge`/`vxlan` interfaces on the gateway chassis - The provider/tenant network topology and which networks must be advertised - The symptom: routes not advertised, asymmetric forwarding, VNI collision, or MAC/IP not in EVPN type-2/type-5 Your job: 1. **Topology model** — map tenant networks to VRFs/VNIs and confirm the VNI-to-network scheme is collision-free and consistent across chassis. 2. **Control-plane check** — verify FRR BGP sessions, EVPN address-family, and that ovn-bgp-agent is exposing the right CIDRs/IPs. 3. **Type-2 vs Type-5** — determine whether you need MAC/IP host routes (type-2) or IP-prefix routes (type-5) for each network and why the current config produces the wrong one. 4. **Data-plane validation** — commands to confirm VXLAN encap, symmetric IRB, and that traffic uses the fabric not a tunnel-of-last-resort. 5. **Failure isolation** — narrow whether the break is OVN (SB flows), agent (exposure), or fabric (BGP/EVPN). 6. **Design output** — a reference VRF/VNI table, FRR + agent config deltas, and a per-chassis rollout order. Output as: (a) a network-to-VRF-to-VNI table, (b) a control-plane and data-plane verification checklist, (c) a staged rollout runbook. Validate route advertisement and end-to-end reachability on one gateway chassis before enabling EVPN exposure fleet-wide.
Why this prompt works
OVN BGP EVPN integration sits at the seam between two teams that rarely share a vocabulary: the OpenStack operators who think in tenant networks and the fabric engineers who think in VRFs, VNIs, and BGP address-families. Most failures here are translation failures — a network exposed with the wrong route type, a VNI that collides on another leaf, or an agent in underlay mode when the fabric expects vrf. This prompt forces the model to build the network-to-VRF-to-VNI mapping explicitly, which is the exact artifact that surfaces those translation bugs.
By splitting the analysis into control-plane (FRR/BGP/EVPN sessions) and data-plane (VXLAN encap, symmetric IRB) checks, the prompt mirrors how a senior network engineer actually isolates EVPN problems. A route that is advertised but not forwarded is a completely different bug from a route that never advertises, and the model is made to distinguish them rather than blur them into “BGP is broken.”
The single-chassis validation gate is non-negotiable in this domain. EVPN exposure changes can leak tenant routes into a shared fabric or blackhole an entire provider network. Keeping the AI in a design-and-verify role, with you confirming reachability on one chassis before fleet rollout, turns a high-blast-radius change into a controlled one.