VyOS · Self-assessment
Knowledge checks
Every knowledge check in this course, in curriculum order. Each link opens the page at its quiz. The questions are auto-graded in the browser and nothing is recorded — a wrong answer costs you only the explanation, which is the part worth reading.
- Knowledge checks
- 342
- Parts covered
- 57
- Of all lessons
- 100%
Part I
Networking Foundations for Routing Engineers
6 checks
- Ethernet, MAC and ARP — the Layer 2 the routing engineer must readHow VyOS handles Ethernet frames, MAC addresses, ARP, neighbour tables and why the routing engineer must read Layer 2 evidence to debug a routing incident.→
- IPv4, IPv6, CIDR and subnetting — the arithmetic the routing engineer must do in their headIPv4 addressing, IPv6 addressing, CIDR notation, subnetting math, prefix aggregation, and the calculations a VyOS operator runs every day.→
- TCP, UDP and ICMP — the transport protocols the routing decisions affectHow TCP, UDP, and ICMP travel across a VyOS router, what the routing engineer must know about ports, sequence numbers, MSS, PMTUD, ICMP unreachable, and how the router treats each.→
- MTU and fragmentation — the constraint every tunnel violatesWhy MTU matters for a routing engineer, how fragmentation works, what every tunnel costs in bytes, and how to diagnose the path-MTU blackhole.→
- DNS and DHCP — the services every routing change depends onHow DNS and DHCP work on VyOS 1.5: the single service dns forwarding node in both its forwarding and recursive modes, the Kea DHCP server and its subnet-id, the DHCP relay, and the failure modes that surface as routing incidents.→
- ARP vs NDP — neighbour discovery at Layer 2 / Layer 3, IPv4 and IPv6 side by sideA side-by-side treatment of ARP (IPv4) and NDP (IPv6) — how the kernel maintains the neighbour table for each family, what the messages do, and what breaks when either fails.→
Part II
Routing Fundamentals
6 checks
- Routing tables — what an entry actually isHow the Linux kernel routing table works on VyOS, what each field means, the relationship between FIB and RIB, and the operational commands that read the routing state.→
- Longest-prefix match — the algorithm that decides every packetHow longest-prefix match works on a VyOS router, the trie structure the kernel uses, the interaction with administrative distance, and the production failure modes.→
- Connected routes — the free routes the interface gives youHow the kernel automatically adds connected routes, why they have AD 0, how they interact with static and dynamic routes, and the production failure modes that surface as connectivity incidents.→
- Static and default routes — explicit pathsHow static and default routes work on VyOS, how to configure them with next-hop, interface, distance, and reject/blackhole, and the production failure modes.→
- Administrative distance — how a router prefers one source over anotherAdministrative distance is an FRR concept, not a Linux one. How zebra assigns a distance to each routing source, the defaults FRR 10 actually ships, the VyOS 1.5 commands that override them, and the production failure modes that surface when a distance is wrong.→
- ECMP — equal-cost paths and the per-flow decisionHow Equal-Cost Multi-Path works on VyOS 1.5, how the Linux FIB hashes packets to next-hops, why the hash is stateless rather than flow-pinned, and the production failure modes.→
Part III
VyOS Architecture
6 checks
- Linux base — what VyOS is at the bottomWhat the Linux kernel provides to VyOS at the bottom of the stack — netfilter, iproute2, cgroups, namespaces, capabilities, the boot sequence — and why the routing engineer must know which subsystem is which.→
- FRRouting and the routing daemons — the dynamic brainHow FRRouting is structured, what each daemon does, how they communicate via zebra, how the routing policy language works, and what the routing engineer can see from vtysh.→
- The configuration tree — where every set command livesHow the VyOS configuration tree is structured, how `set` translates into kernel state, how `compare` and `show configuration` work, and the operational conventions the routing engineer must know.→
- The commit engine — from candidate to runningHow the VyOS commit engine takes a candidate configuration, validates it, generates the subsystem configuration, and applies it — and what happens when validation fails.→
- Generated runtime configuration — what VyOS hands to FRR and the kernelHow the VyOS configuration tree translates into the FRRouting and Linux configurations the kernel actually uses — interfaces, FRR routing policy, nftables, sysctl.→
- Services, web UI, HTTP API — what is reachable and howHow VyOS exposes services — SSH, the web GUI, the HTTP API, syslog, SNMP — what ports each binds, how authentication is configured, and the security implications of each service.→
Part IV
Installation and Initial Deployment
6 checks
- ISO install — booting VyOS from a long-support imageHow to obtain, verify, and install a VyOS 1.5 LTS (circinus) ISO on bare metal and as a recovery path for an existing router; how the installer partitions the disk, lays down the squashfs root, configures the bootloader, and what the production routing engineer must do before they let the box take real traffic.→
- VM deployment — running VyOS as a guest on Proxmox, VMware, KVMHow to deploy VyOS 1.5 LTS as a virtual machine on the hypervisors the routing engineer actually meets in production — Proxmox VE, VMware vSphere, and plain KVM; what NIC types map to which VyOS interface names, how virtio changes the operational picture, and what to verify before the box takes real traffic.→
- Cloud image — running VyOS on AWS, GCP, Azure, and OpenStackHow to launch a VyOS 1.5 LTS cloud image on AWS, GCP, Azure, and OpenStack; what metadata drives the first-boot configuration, how the operator injects cloud-init directives, and what the routing engineer must verify before the cloud router peers with its on-prem counterpart.→
- Console access and initial management — first contact with the boxHow to reach a freshly installed VyOS 1.5 LTS box on its first boot: the serial console, the VGA console, the management VRF, the SSH server, the default accounts, and the first configuration commands the routing engineer runs before the box leaves the console.→
- Post-install hardening — what to change before the box touches the public InternetThe post-install hardening sequence every VyOS 1.5 LTS box needs before it touches a routed interface: default password change, SSH key-only, listen-address and VRF binding, login banner, NTP, syslog, SNMP, the first firewall rules, and the brute-force protection VyOS actually ships.→
- Image management — upgrades, downgrades, dual-image rollbackHow to manage the VyOS 1.5 LTS dual-image model: add a new image, switch the boot default, roll back after a failed upgrade, and recover from a corrupted boot. The two-slot design that makes VyOS upgrades safer than most Linux distros.→
Part V
Configuration Model
6 checks
- configure / set / delete / show / compare — the operational vocabularyThe five commands every VyOS routing engineer types hundreds of times per day: how `configure` enters the candidate, `set` builds it, `delete` trims it, `show` inspects it, and `compare` reviews the diff. The shell in which every routing change is composed.→
- Candidate, active, saved — the three configurations every VyOS box hasThe three configurations on every VyOS box and the operators that move them: the candidate (in configure mode), the active (running) configuration, and the saved configuration on disk. Why every commit needs a save, why every reboot reverts the running to the saved, and how the change of authority between them drives every operational pattern.→
- Hierarchical tree — the schema the operator navigatesThe hierarchical configuration tree that drives every VyOS configuration: nodes, tag nodes and leaf nodes, how scope works inside `edit`, where the schema actually lives on a 1.5 router, and how to read a node definition instead of guessing at it.→
- show configuration and compare — inspecting the candidate without leaving itThe two commands that read the candidate without changing it: `show` to print nodes and leaves, `compare` to see what would change on commit. The review surface the routing engineer uses hundreds of times per day.→
- save / discard / exit — exiting configure mode with intentThe three exits from configure mode and what each commits, throws away, or preserves. Why `discard` is not the default, why `exit` leaves a candidate that survives the next entry, and how to leave the shell with a clean conscience.→
- Common configuration traps — patterns that bite every operator at least onceThe configuration traps that catch every VyOS operator at least once: a commit that never reached disk, the wrong edit scope, an unquoted value, a firewall group that matches nothing, a ruleset nothing jumps to, and the VRF drift that commits cleanly and routes nothing. Each with the 1.5 syntax that actually applies and the recovery that actually works.→
Part VI
Commit and Rollback Safety
6 checks
- commit semantics — what the commit engine actually doesHow `commit` turns the candidate configuration into runtime state on VyOS 1.5: where value constraints are enforced, what the per-subtree get_config / verify / generate / apply scripts do, why a failed commit can leave the box half-changed, and how to read the revision history afterwards.→
- commit-confirm — the rollback safety net for remote changesHow `commit-confirm` schedules a reversion if the operator does not confirm within a window, what the default reboot action really costs, and why it is the standard pattern for any change that touches the very access path the operator is using.→
- Configuration history — the archive of every successful commitHow `/config/archive/` records every successful commit as a timestamped snapshot; how to list, diff, load, and prune archive entries; and why the archive is the operator's safety net for every change that has ever been applied.→
- rollback — the in-place revert to a known-good stateHow `rollback N` reverts the candidate to the N-th archive entry, the standard recovery pattern for bad changes. When to use rollback, when to use `load <path>`, and how to combine both with `commit-confirm` for safe reverts.→
- save — making the configuration persistThe `save` command, what it writes, where it writes, and how the operator uses it as part of every change. The discipline that turns a live configuration change into a persistent one.→
- Remote change discipline — the operational standard for changes the operator cannot seeThe operational discipline for changes made to a router the operator cannot physically reach: commit-confirm, change windows, peer review, the commit archive, and the post-change verification checklist. The standard that turns a remote change from a leap of faith into a routine operation.→
Part VII
Interface Fundamentals
6 checks
- Ethernet interfaces — naming, MAC, driver mappingHow VyOS 1.5 LTS names Ethernet interfaces, maps Linux kernel names to VyOS names, handles MAC address assignment, and presents the physical interface to the routing engineer. The foundation for every other interface lesson in the course.→
- IP addressing on interfaces — static, DHCP, and address-lessHow VyOS 1.5 LTS handles IP addressing on Ethernet interfaces: static addresses, DHCP client, DHCPv6, address-less interfaces, secondary addresses, and the failure modes that surface when addresses are misconfigured.→
- MTU on the interface — the most misunderstood setting on a routerHow MTU works on a VyOS Ethernet interface, why the default of 1500 bytes is rarely what production needs, how tunnel overhead eats into the MTU, and how to verify end-to-end with ping and tracepath.→
- Administrative and operational state — the four states of an interfaceHow administrative state (configured up/down) and operational state (link up/down) combine into the four states every interface can be in. How to read the state with `show interface`, how to disable an interface, and the failure modes that surface as silent interfaces.→
- Interface diagnostics — what to run when an interface is brokenThe diagnostic commands every VyOS routing engineer runs when an interface is misbehaving: `show interface`, `ip`, `ethtool`, `tcpdump`, `mtr`, and how to read each output. The triage flow that turns "the interface is down" into "the cable is bad on port 4 of switch B".→
- Interface anti-patterns — the configurations that always cause troubleThe interface configurations that always cause trouble in production: the wrong MTU, the wrong address, the wrong speed/duplex, the wrong VLAN, the missing firewall rule, the over-subscribed interface, and how to recognise each.→
Part VIII
VLANs
6 checks
- IEEE 802.1Q — the tagging modelHow 802.1Q VLAN tagging works at the frame level: the 4-byte VLAN tag, the 12-bit VLAN ID, the 3-bit priority code point, native VLAN, QinQ double tagging, and how VyOS implements the model.→
- VLAN sub-interfaces — eth0.10, eth0.20, ...How to create VLAN sub-interfaces on VyOS: the `vif N` directive, how the kernel maps to eth0.N, how to address each sub-interface, and the failure modes that surface when sub-interfaces do not match the trunk configuration.→
- Trunks and access — what the operator controls at each end of the cableThe access port and trunk port model from the operator's perspective: how to configure a VyOS interface as an access port (one VLAN, untagged) or trunk port (multiple VLANs, tagged), and how the configuration must match the switch.→
- VLAN routing — moving packets between VLANs on the same routerHow VyOS 1.5 routes between VLANs on a single trunk link: inter-VLAN routing, the router-on-a-stick pattern, where the firewall actually attaches now that per-interface bindings are gone, and the failure modes that surface when VLAN routing breaks.→
- VLAN troubleshooting — finding the broken VLAN in five minutesThe diagnostic flow for a broken VLAN: tcpdump with `-e` for tagged frames, `vlan` filter, sub-interface state, switch port configuration, and the common VLAN failure modes the operator must recognise.→
- VLAN security — VLAN hopping, native VLAN attacks, and the mitigationsThe security risks of VLAN deployments: VLAN hopping, native VLAN attacks, double tagging, MAC flooding, and the VyOS and switch mitigations every operator must apply.→
Part IX
Bridges
6 checks
- Bridges — Layer 2 forwarding in softwareHow VyOS implements Linux bridges for Layer 2 forwarding between interfaces, the kernel bridge module, MAC learning, STP, and when bridges are appropriate in a routing engineer's estate.→
- Bridge configuration — members, addressing, STPThe detailed bridge configuration in VyOS: member interfaces, the bridge IP address, STP options, MTU, and the failure modes the operator must recognise.→
- Bridge vs routing — when to bridge, when to routeThe decision framework for choosing bridges over routing: Layer 2 vs Layer 3, broadcast domain size, performance, when each is appropriate, and the trade-offs in production.→
- Bridge troubleshooting — finding the broken bridge fastThe diagnostic flow for a broken bridge: MAC learning, FDB state, STP state, member state, broadcast storms, and the common bridge failure modes the operator must recognise.→
- Bridge + VRF — combining Layer 2 and Layer 3 segmentationHow to combine bridges with VRFs: a bridge in a VRF, IP address on the bridge in the VRF, members outside the VRF. The pattern for transparent Layer 2 forwarding across VRF boundaries.→
- Bridge anti-patterns — what not to do with bridgesThe bridge configurations that always cause trouble: bridging different subnets, missing STP, IP on member, complex topology with too many bridges, and how to recognise each anti-pattern.→
Part X
Bonding and Link Aggregation
6 checks
- LACP — the protocol that aggregates linksHow IEEE 802.1AX Link Aggregation Control Protocol negotiates a bundle: LACPDUs, actor and partner, system ID, operational key, port state, active versus passive, fast versus slow rate, and how VyOS 1.5 LTS exposes all of it under set interfaces bonding.→
- Bond modes — balance-rr, active-backup, balance-xor, 802.3ad, balance-tlb, balance-albThe six Linux bonding modes, the trade-off each one makes between bandwidth, redundancy, and switch requirements, and how VyOS 1.5 LTS exposes them through set interfaces bonding mode. The mode choice is the decision that determines the entire operator experience.→
- Switch dependencies — LAG, port-channel, MLAG, and switch model specificsHow the upstream switch must be configured to aggregate links to a VyOS host. Static LAG versus LACP, port-channel on Cisco, MLAG on Arista and modern switches, the bookmarking that goes in the interface inventory, and the model-specific gotchas that bite production teams.→
- Bond failure modes — slave down, LACP flap, hash mismatch, MTU mismatchThe eight failure modes that a production bond can exhibit: slave down, LACP flap, hash mismatch, MTU mismatch, speed mismatch, single-side passive, inter-switch cable, and the silent-failure case. The evidence each one leaves and the remediation the operator must run.→
- Bond + VLAN — trunk on a bond, sub-interfaces on bond members, native VLAN ruleCombining a bond with VLANs: the bond as a single trunk port, VLAN sub-interfaces on top of the bond, the native VLAN rule on the switch side, the MTU chain, and the failure modes that produce silent drops.→
- Bond validation — /proc/net/bonding, show bonding, throughput testingThe validation command set for a production bond: the canonical source of truth (/proc/net/bonding), the VyOS-level view (show bonding), the kernel-level counters (ip -s link), the switch-side cross-check, and the throughput test that proves the aggregate is doing what the configuration says.→
Part XI
IPv6
6 checks
- IPv6 fundamentals — 128-bit addressing, headers, ICMPv6, NDPHow IPv6 differs from IPv4 at the bit and protocol level: 128-bit addresses, the simplified 40-byte header, ICMPv6 taking over roles that ICMPv4 and ARP handled separately, and why link-local addresses and EUI-64 are the foundation every IPv6 lesson builds on.→
- IPv6 addressing — global unicast, ULA, link-local, multicast, anycast, prefix delegationThe IPv6 address types a production router must distinguish: global unicast from the IANA registry, unique local addresses for internal numbering, link-local for neighbour and routing protocols, multicast for one-to-many delivery, anycast for one-to-nearest, and prefix delegation for handing subnets downstream.→
- IPv6 router advertisements — SLAAC, prefix options, M/O flags, RDNSSHow router advertisements (ICMPv6 type 134) tell hosts how to autoconfigure: the prefix they should use, how long the prefix is valid, whether to use SLAAC or DHCPv6, and which DNS resolvers to query. The M/O and A/P flags that decide what hosts do with the message.→
- DHCPv6 — stateful vs stateless, IA_NA, IA_PD, RDNSSHow DHCPv6 supplements what Router Advertisements cannot do: stateful address assignment with IA_NA, prefix delegation with IA_PD for downstream sites, stateless DNS via RDNSS, and DHCPv6 relay when the server is on a different segment.→
- IPv6 routing — static routes, OSPFv3, BGP, MP-BGP, IPv6 in VRFHow IPv6 routes in VyOS 1.5 LTS: static IPv6 routes through FRR, OSPFv3 (the IPv6 successor to OSPFv2), BGP for IPv6 with MP-BGP carrying the IPv6 NLRI alongside IPv4, and IPv6 inside a VRF instance. The dual-stack control plane the production network engineer must operate.→
- IPv6 troubleshooting — ping6, traceroute6, neighbour cache, MTU 1280, fragmentationHow to debug IPv6 from the operator seat: ping6 with link-local and zone identifiers, traceroute6 with the right source, the IPv6 neighbour cache and its INCOMPLETE / STALE / REACHABLE / DELAY / PROBE states, the 1280-byte MTU floor, the "no fragmentation in transit" rule, and the Path MTU Discovery failure modes that surface as silent packet loss.→
Part XII
Static Routing
6 checks
- Static routes — the foundation of a routed estateHow static routes work in VyOS 1.5 LTS and FRR. The route configuration tree, prefix, next-hop, interface, distance, metric, and the operational commands that prove the route is installed in the kernel FIB.→
- Default route — 0.0.0.0/0, dual default, floating default, ICMP unreachableHow the default route works in VyOS 1.5 LTS. The 0.0.0.0/0 prefix as the least-specific catch-all, dual-default redundancy, floating-default failover, ICMP unreachable generation when no route matches, and how a missing default breaks Internet connectivity.→
- Static route options — tag, description, on-link, VRF, disableThe non-essential but production-important attributes of a VyOS 1.5 LTS static route: tag for redistribution policy, description for operational documentation, on-link for next-hops outside the connected subnet, vrf for table isolation, and disable for staged rollout.→
- Blackhole routes — silent drops for martians, aggregation, and DDoS mitigationHow blackhole static routes work in VyOS 1.5 LTS. The set protocols static route blackhole idiom, the difference between blackhole and reject, the martian-prefix use case, the BGP route-aggregation blackhole pattern, and the operational evidence in show ip route.→
- Recursive routing — indirect next-hops, MTU, and RFC 8308 path MTUHow recursive static routes work in VyOS 1.5 LTS. The kernel's recursive lookup, route-to-next-hop, MTU and ICMP-fragmentation issues, RFC 8308 path MTU discovery, and the operational evidence when the next-hop is not directly connected.→
- Static route troubleshooting — show ip route, traceroute, looking-glass, asymmetric routingThe troubleshooting command set for a VyOS 1.5 LTS static-routing estate. show ip route, show ip route static, traceroute, looking-glass, asymmetric-routing detection, return-path validation, and the post-incident evidence package.→
Part XIII
Policy-Based Routing
6 checks
- Policy-based routing — concept, FIB vs RIB, table selection, why PBR existsHow policy-based routing differs from destination-based routing in VyOS 1.5 LTS. The Linux FIB vs RIB split, the role of ip rule and routing tables, the case for PBR in multi-WAN, multi-VRF, and source-routed designs, and the production failure modes that arise when destination-based routing is not enough.→
- Route-maps — match clauses and set clauses for PBRHow VyOS 1.5 LTS builds policy-based routing on top of FRR's route-map. Match clauses for source address, destination address, prefix-list, and interface. Set clauses for next-hop, local-preference, metric, and community. Sequence numbering, action permit/deny, and the rule-evaluation order the operator must reason about.→
- PBR rules — the policy route tree, its interface, ip rule, and the table it points atHow a policy route becomes an effective PBR rule on VyOS 1.5 LTS: the set policy route tree, the interface attachment that moved off the interface in 1.4, the routing table the rule selects, the nftables-plus-ip-rule render the operator reads during troubleshooting, and why a route-map is not policy-based routing.→
- PBR for IPv6 — IPv6 source/destination matches, IPv6 next-hop, IPv6 interfaceHow PBR works for IPv6 in VyOS 1.5 LTS. The IPv6 prefix-list, IPv6 source/destination matches in route-maps, IPv6 next-hop set clause, IPv6 interface binding, the ip -6 rule and ip -6 route show table commands, and the dual-stack PBR pattern where both IPv4 and IPv6 traffic from a subnet take the same provider path.→
- PBR troubleshoot — show ip route, show ip rule, traceflow, asymmetry, countersHow to diagnose a PBR deployment in VyOS 1.5 LTS when the rule is installed but the traffic is taking the wrong path. The show ip route / show ip rule / show policy route-map / ip rule show / ip route show table / ip route get ladder, the per-rule counters in FRR, the traceflow pattern for matching a packet to a rule, the asymmetry signal between forward and return path, and the kernel netlink debug for rule installation failures.→
- PBR anti-patterns — PBR everywhere, conflicting route-maps, missing table, asymmetric PBRThe production anti-patterns the engineer must recognise in a PBR deployment on VyOS 1.5 LTS. PBR as a substitute for proper routing design, conflicting route-maps that mask each other, missing PBR tables, asymmetric PBR that breaks stateful firewalls, route-maps bound to too many interfaces, and the operational smell that flags each pattern.→
Part XIV
Multiple Routing Tables
6 checks
- The routing-table concept — RIB, FIB, FRR, and the Linux kernel datapathWhat a routing table actually is on VyOS 1.5 LTS. The RIB (Routing Information Base) as the source of truth, the FIB (Forwarding Information Base) as the data-plane lookup structure, FRRouting's zebra dataplane pushing routes into the kernel through netlink, and the default table 254 the kernel uses when no policy rule intervenes.→
- Multiple routing tables and the ip rule policy databaseHow VyOS 1.5 LTS exposes Linux's multiple routing table model. The ip rule policy database, table priority (32766 for main, 32767 for default), the operator-facing set system ipv4 rule tree, and the alias-naming convention that keeps table IDs human-readable across operators.→
- Table ID namespace — reserved IDs, custom IDs, and VRF conflictThe numeric namespace of Linux routing table IDs. Reserved IDs (0 local, 253 default, 254 main, 255 local alias), the operator-defined IDs in between, the /etc/iproute2/rt_tables alias file, and the namespace collision with VRF table IDs that catches operators who do not plan the ID layout.→
- Source-based routing — binding traffic to a table by sourceHow to bind traffic to a routing table by its source address on VyOS 1.5 LTS. The ip rule add from <src> table <id> pattern, the multi-homing use case where two upstream ISPs serve different source subnets, the configuration idiom that survives a reboot, and the return-path discipline that prevents asymmetric routing.→
- Routing table troubleshooting — ip route show table all, ip rule show, asymmetryThe troubleshooting command set for a VyOS 1.5 LTS multiple-routing-table deployment. ip route show table all for the full table inventory, ip rule show for the RPDB walk, ip route get for end-to-end validation, traceroute -s for forward-path confirmation, and the asymmetry-detection pattern that catches the most common production failure.→
- Routing table anti-patterns — too many tables, conflicting priorities, FRR not pushingThe anti-patterns that catch operators deploying multiple routing tables on VyOS 1.5 LTS. Too many tables without documentation, conflicting rule priorities, custom tables without matching rules, FRR not pushing routes to a custom table, and the asymmetric-routing trap that breaks connections despite a correct forward path.→
Part XV
VRFs
6 checks
- VRF concept — L3VPN, the kernel vrf driver, and how VyOS implements routing tables per VRFWhat a VRF actually is, why service providers and multi-tenant enterprises use them, how the Linux kernel vrf driver models VRFs, and how VyOS 1.5 LTS wires FRR's per-VRF routing tables to kernel FIBs.→
- VRF configuration — set vrf name, table ids, attaching interfaces, addressesHow to configure VRFs in VyOS 1.5 LTS: set vrf name with a table id, attach an interface, configure addresses inside a VRF, and validate the result end to end. Includes the naming and table-id rules the validator actually enforces and the reference checks that block a delete.→
- VRF routing protocols — OSPF, BGP, and crossing the VRF boundary on purposeHow to run OSPF and BGP inside a VRF on VyOS 1.5 LTS, where the per-VRF stanzas live in the configuration tree, and the two mechanisms VyOS actually provides for moving a route between VRFs — static next-hop-vrf leaking and BGP import vrf — including how to tell when a leak silently did nothing.→
- IPv6 inside a VRF — link-local next-hops, OSPFv3 and BGP per VRF, leaking route6Running IPv6 inside a VyOS 1.5 LTS VRF: which IPv6 routes land in the per-VRF table, why the interface and not the VRF is what disambiguates a link-local address, OSPFv3 and BGP IPv6 configured under `vrf name`, leaking an IPv6 prefix with the `vrf` leaf that renders FRR's `nexthop-vrf`, and the IPv6-specific failure modes.→
- VRF troubleshooting — RIB versus FIB, `ip vrf exec`, and the leak that installs nothingThe operator's playbook when a VRF-bound configuration misbehaves on VyOS 1.5 LTS: the four places VRF state lives, reading `show ip route vrf` against `ip route show vrf` to separate FRR's intention from the kernel's forwarding table, running diagnostics inside a VRF with `ip vrf exec`, and the failure signatures of a route leak that commits cleanly and forwards nothing.→
- VRF anti-patterns — VRFs for non-routing problems, overlapping space, leaks that install nothing, MTUThe production anti-patterns that turn a multi-VRF estate into an incident factory on VyOS 1.5 LTS: reaching for a VRF when the problem is firewall policy, overlapping tenant address space that only bites the day something must be shared, shared-service leaks written without the `vrf` next-hop leaf, leaking into the default VRF because it is easier, MTU that is set on the wrong interface, and configuration drift across per-VRF routing instances.→
Part XVI
Route Leaking Between VRFs
6 checks
- Route leaking between VRFs — concept, RFC 4364, shared servicesWhat route leaking actually is on VyOS 1.5 LTS — installing a route in one routing table whose next hop is resolved in another — why production needs it for shared services like DNS and NTP, how the RFC 4364 L3VPN reference model relates to it, and the failure mode that makes leaking worth a whole part of the course: a leak that commits cleanly and installs nothing.→
- Route leaking configuration — static next-hop-vrf, BGP import vrf, filteringHow to configure route leaking between VRFs on VyOS 1.5 LTS: static leaking with a vrf value on the next hop, BGP leaking with import vrf, prefix-list and route-map filtering, and the verification order that distinguishes a leak that installed from a leak that only committed.→
- Leaking and firewall — dispatch by interface, state, asymmetric pathsHow firewall policy interacts with route leaking on VyOS 1.5 LTS: the base-chain and jump-target model that replaced per-interface bindings, why VyOS has no VRF selector in a firewall rule and what to use instead, how connection tracking behaves across a leak, and the interface-pair asymmetry that drops the reply of a flow whose request was permitted.→
- IPv6 leaking — dual-stack leaks, RDNSS sharing, prefix delegationRoute leaking for IPv6 on VyOS 1.5 LTS: the route6 static leak and the vrf leaf that renders FRR nexthop-vrf, why a dual-stack pair is four statements and not two, sharing an RDNSS across VRFs with service router-advert, what VyOS does and does not expose for DHCPv6 prefix delegation across a VRF boundary, and the IPv6-specific failure modes — link-local next-hops, ICMPv6 Packet Too Big, and multicast that does not cross.→
- Troubleshooting leaking — routes missing, route-map blocking, asymmetric pathSystematic troubleshooting of broken route leaks on VyOS 1.5 LTS: the leak that commits and installs nothing, the next-hop that does not resolve in the table you named, the one-way leak that reads like a firewall drop, the BGP import that imports nothing, and the firewall and MTU failures at the leak boundary — with the evidence order that separates them.→
- Anti-patterns — leaking everything, leaking without firewall, MTU-naive leakingThe route-leaking anti-patterns that reach production on VyOS 1.5 LTS: the default route that dissolves a VRF, the leak with no firewall behind it, the MTU-naive leak, the IPv4-only leak for a dual-stack service, the undocumented leak, the /24 that was meant to be three /32s, and the validation that proves nothing — with what VyOS can and cannot filter, and a review checklist that catches each one before commit.→
Part XVII
Routing Protocol Fundamentals
6 checks
- Adjacency — the neighbour relationship that has to exist before any routing can happenWhat a routing adjacency is on VyOS 1.5 LTS with FRR 10.x. How hello packets discover neighbours, what the hello and dead intervals actually control, the OSPF Down-to-Full state machine, the RFC 4271 BGP states, the FRR configuration VyOS renders underneath, and the production failure modes that keep an adjacency from forming.→
- Convergence — when the network agrees it has the same topology as beforeWhat convergence means on VyOS 1.5 LTS with FRR 10.x. How a topology change propagates, how the FRR SPF throttle actually backs off, what VyOS exposes for RIP and BGP timing, and the production trade-offs between fast and stable convergence.→
- Control plane versus data plane — what FRR decides and what the Linux kernel forwardsThe separation between the routing decision (control plane, FRR) and the packet movement (data plane, Linux kernel FIB) on VyOS 1.5 LTS. How the RIB and FIB differ, how zebra pushes routes over netlink, which VyOS commands show which view, and the production failure modes where the two diverge.→
- IGP versus EGP — the inside and outside of an Autonomous SystemThe split between Interior Gateway Protocols (OSPF, IS-IS) and Exterior Gateway Protocols (BGP) in VyOS 1.5 LTS. What an Autonomous System is, why the IGP / EGP boundary exists, and the deployment shapes where each protocol is the right answer.→
- Route preference — administrative distance, longest-prefix-match, and which route winsHow VyOS 1.5 LTS and FRR pick one route when two routing sources advertise the same prefix. Administrative distance, metric as tie-break, longest-prefix-match, and the production cases where the operator must engineer preference.→
- Protocol metrics — cost, MED, IS-IS wide metrics, and how operators shift trafficHow routing protocols signal path preference with metrics. OSPF cost, IS-IS wide metrics, BGP MED, route-map metric manipulation, and the production patterns where the operator shifts traffic by setting metrics deliberately.→
Part XVIII
OSPF Fundamentals
6 checks
- Link-state routing — Dijkstra, the LSDB, and SPF calculationHow OSPF builds and maintains a link-state database that every router in an area converges into the same Shortest Path Tree, the difference from distance-vector protocols, the SPF triggers and throttle that cause CPU spikes, and the production failure modes that surface when the LSDB cannot converge.→
- OSPF neighbours and adjacency — the hello protocol and the eight-state machineHow OSPF discovers peers, agrees the parameters that must agree, and walks through Down -> Init -> 2-Way -> ExStart -> Exchange -> Loading -> Full. The hello/dead intervals, the network mask check, the priority, the authentication options, and the production failure modes that surface as a missing neighbour or one parked in ExStart.→
- OSPF LSA types — Type 1 through Type 11 and what each one carriesEvery OSPF LSA type, its flooding scope, what it advertises, and how to read the LSDB on VyOS 1.5 LTS. Router LSA (Type 1), Network LSA (Type 2), Summary LSA (Type 3), ASBR-Summary LSA (Type 4), External LSA (Type 5), NSSA (Type 7), Opaque LSAs (Type 9/10/11), and the production failure modes that surface as missing, duplicated or un-removable LSAs.→
- OSPF areas — backbone, stub, NSSA, ABR, and area range aggregationHow OSPF areas structure a large OSPF domain, the role of the backbone area 0, the area types (normal, stub, totally-stubby, NSSA), the role of the ABR, the virtual link remediation, and the area-range aggregation primitive. The production failure modes that surface as misaligned area boundaries or routing loops in transit areas.→
- DR/BDR election — designated router, broadcast vs point-to-point, and why the DR existsWhy OSPF on a multi-access segment needs a central router to describe the topology, the DR/BDR election rule (priority, then router-id), the difference between broadcast and point-to-point network types, and the production failure modes that surface as DROther pre-election or stuck DR.→
- OSPF SPF and cost — Dijkstra's metric, reference bandwidth, and tuning pathsHow OSPF computes the SPF tree using cost, the formula cost = reference-bandwidth / interface-bandwidth, per-interface and global cost tuning, auto-cost reference-bandwidth, and how route summarisation affects the cost chosen by the SPF tree. The production failure modes that surface as suboptimal traffic engineering or all-paths-equal.→
Part XIX
OSPF Configuration
6 checks
- OSPF basics — enabling OSPF, router-id, default route, and area assignmentHow to enable OSPF on VyOS 1.5 LTS, why the router-id matters more than the IP on the loopback, when to advertise a default route into OSPF, and how a router's interface assignment to an OSPF area drives the rest of the configuration.→
- OSPF interface configuration — network type, timers, MTU, passivePer-interface OSPF configuration on VyOS 1.5 LTS: how to set the network type (broadcast vs point-to-point), how hello/dead timers interact with neighbour formation, how MTU mismatch causes EXSTART, and when to mark an interface as passive to OSPF.→
- OSPF area configuration — area types, area range, and per-area authenticationConfiguring OSPF area types (stub, NSSA, totally-stubby) on VyOS 1.5 LTS, area range aggregation to reduce LSDB size, and per-area authentication that overrides per-interface authentication.→
- OSPF redistribution — static, connected, BGP, and route-map filteringHow to redistribute routes from other sources (static, connected, BGP, kernel, OSPF process) into OSPF on VyOS 1.5 LTS, the difference between metric-type 1 and metric-type 2, and how route-maps filter what gets redistributed.→
- OSPF authentication — plaintext, MD5, SHA-256, key chain, virtual linksConfiguring OSPF authentication on VyOS 1.5 LTS: per-interface and per-area plaintext, MD5, and SHA-256 authentication, key chains for key rotation, and virtual-link authentication for partitioned backbones.→
- OSPF cost tuning — auto-cost reference-bandwidth, manual cost, ECMPTuning OSPF cost on VyOS 1.5 LTS: the auto-cost reference-bandwidth, per-interface manual cost, route-map metric-set on redistributed routes, and maximum-paths for ECMP across equal-cost OSPF paths.→
Part XX
OSPF Areas and Design
6 checks
- OSPF area types — backbone, standard, stub, totally stubby, NSSA, totally NSSAThe OSPF area-type catalogue: backbone, standard non-backbone, stub, totally stubby, NSSA, totally NSSA. The LSA-flooding boundaries each type imposes, the design constraints RFC 2328 and RFC 3101 encode, and the VyOS 1.5 LTS / FRR configuration idioms that activate each type.→
- Stub and NSSA mechanics — Type 5 blocking, ABR default, Type 7 propagationThe stub and NSSA area types in depth: what the ABR blocks, how the default route is injected, why a stub cannot contain an ASBR, how NSSA introduces Type 7 LSAs and the P-bit, and how the ABR translates Type 7 to Type 5 at the boundary.→
- Inter-area summarisation — area range, ABR aggregation, prefix-list filteringOSPF inter-area summarisation on VyOS 1.5 LTS: the `area range` configuration, how the ABR replaces intra-area Type 1 / Type 2 LSAs with a single Type 3 Summary LSA, the metric and discard implications, prefix-list filtering at the area boundary, and the production impact of aggressive summarisation on route visibility.→
- Virtual links — patching the backbone across a transit areaOSPF virtual links on VyOS 1.5 LTS: why they exist (the backbone-must-be-contiguous rule), how they extend area 0 across a non-backbone transit area, the restrictions on the transit area (must be standard, must have a full routing table), the configuration, the operational caveats, and the security implications.→
- Multi-area design — two-tier hierarchy, hub-and-spoke, scalability limitsOSPF multi-area design patterns on VyOS 1.5 LTS: the two-tier hierarchy (backbone + non-backbone), the hub-and-spoke pattern for remote sites, why operators distribute areas at all, the scalability limits (LSDB size, SPF cost, flooding scope), and the design decisions that decide which area type fits a site.→
- OSPF area troubleshooting — LSDB inconsistencies, area mismatch, stuck states, NSSA issuesOSPF area troubleshooting on VyOS 1.5 LTS: LSDB inconsistencies across the area boundary, area-id and area-type mismatches, neighbours stuck in Init / Exstart, NSSA Type 7 translation issues (P-bit, forward address), and the operational diagnostics for each failure mode.→
Part XXI
OSPFv3 / IPv6 Routing
6 checks
- OSPFv3 concept — IPv6 link-state, link-local source, per-link semanticsOSPFv3 on VyOS 1.5 LTS: why OSPFv3 is not OSPFv2 with longer addresses, the link-local source-address rule, per-link instead of per-subnet operation, the new LSA format that no longer carries a prefix, and the operational consequences of separating protocol from address family.→
- OSPFv3 configuration — router-id, area assignment, interface parameters, IPv6-onlyOSPFv3 configuration on VyOS 1.5 LTS: the `set protocols ospfv3` configuration tree, the explicit router-id requirement, per-interface area assignment under `area 0 interface eth0`, the per-interface parameters (cost, passive, network-type, priority), and the IPv6-specific configuration idioms (link-local as next-hop, IPv6 prefix-lists for route-maps).→
- OSPFv3 vs OSPFv2 — protocol differences, address family separation, new LSA types, R-bitSide-by-side comparison of OSPFv3 and OSPFv2 on VyOS 1.5 LTS: address family separation (IPv4-only vs IPv6-only), per-link vs per-subnet operation, the new LSA types (Type 8 Link-LSA, Type 9 Intra-Area-Prefix-LSA), the R-bit in Type 3 Summary-LSAs, authentication moved to IPsec / RFC 7166, and the practical consequences for dual-stack deployments.→
- OSPFv3 troubleshooting — neighbour stuck, link-local issues, LSDB inconsistencies, IPv6 ACLsOSPFv3 troubleshooting on VyOS 1.5 LTS: neighbour stuck because of link-local mismatch, IPv6 ACLs dropping OSPFv3 control packets, Type 8 / Type 9 LSA inconsistencies, area mismatch on OSPFv3 interfaces, IPv6 routing table divergence, and the diagnostic sequence specific to OSPFv3.→
- Dual-stack OSPF — running OSPFv2 and OSPFv3 on the same networkDual-stack OSPF on VyOS 1.5 LTS: two independent processes on one wire, the router-id a dual-stack box borrows and an IPv6-only box does not have, the VyOS 1.5 input-filter rules both families need, why cross-family redistribution between OSPFv2 and OSPFv3 does not and cannot exist, and the production scenarios for an IPv4 retirement.→
- OSPFv3 with BGP — BGP carrying OSPFv3 routes, IPv6 NLRI, route-map filteringOSPFv3 and BGP on VyOS 1.5 LTS: BGP carrying IPv6 NLRI learned from OSPFv3, redistributing OSPFv3 routes into BGP, BGP as the upstream transit for IPv6, route-map filtering at the redistribution boundary, and the production scenarios for service-provider IPv6 transit.→
Part XXII
OSPF Troubleshooting
6 checks
- Neighbour stuck in EXSTART / EXCHANGE / Loading — MTU, DD exchange, LSR retransmissionDiagnosing OSPF neighbour states stuck in EXSTART, EXCHANGE, or LOADING on VyOS 1.5 LTS: the Database Description exchange and master/slave negotiation, MTU mismatch as the dominant cause of EXSTART, the LSR retransmission list in LOADING, and the diagnostic sequence for each stuck state.→
- MTU mismatch — DF bit, fragmentation, `ip ospf mtu-ignore`, vendor behaviourDiagnosing and remediating OSPF MTU mismatch on VyOS 1.5 LTS: how the OSPF DBD packet carries the interface MTU, why the larger DBD is dropped on the smaller-MTU interface, the Don't Fragment bit and ICMP Fragmentation Needed messages, the `ip ospf mtu-ignore` operational escape hatch, vendor-specific MTU handling, and the production playbook for tunnel and VLAN MTU reduction.→
- Area mismatch — hello area field, type 1 mismatch, summary vs external in stubDiagnosing OSPF area mismatch on VyOS 1.5 LTS: the Hello packet area-id field, the E-bit and N-bit Options flags, area-id and area-type mismatches that prevent adjacency, Type 1 mismatch flags in the diagnostic output, summary vs external routes in stub / NSSA areas, and the production playbook for area migration.→
- OSPF authentication — simple-text, MD5, SHA, key-id mismatch, key chain timingOSPF authentication on VyOS 1.5 LTS: simple-text (insecure, removed), MD5 with key-id, SHA-1 / SHA-256 / SHA-384 / SHA-512, key-id mismatch as the dominant cause of authentication failures, key chain timing for key rotation, and the production playbook for cryptographic authentication.→
- Duplicate router-id — Type 1 LSA conflict, why uniqueness matters, recoveryDiagnosing duplicate OSPF router-id on VyOS 1.5 LTS: the Type 1 LSA conflict that fragments the LSDB, why a unique router-id matters inside the OSPF domain, the diagnostic sequence, the recovery procedure (`clear ip ospf process`), and the production playbook for router-id hygiene.→
- Missing route — SPF not running, summarisation hiding route, LSA not flooded, area filterDiagnosing missing OSPF routes on VyOS 1.5 LTS: the route is in the LSDB but not in the RIB (SPF did not run, summarisation hides it, area filter blocks it), the route is not in the LSDB (originator is not advertising, area scope is wrong, LSA not flooded), and the production playbook for route-trace diagnostics.→
Part XXIII
BGP Fundamentals
6 checks
- Autonomous system numbers2-byte and 4-byte AS numbers, public and private allocation ranges, notation, and safe ASN migration on VyOS 1.5 LTS.→
- eBGP and iBGPHow eBGP and iBGP sessions differ in TTL, route advertisement, split-horizon behavior, and operational design on VyOS 1.5 LTS.→
- Path-vector routing and AS_PATHHow BGP path-vector attributes carry policy information, reject loops, and shape route selection in a VyOS 1.5 LTS network.→
- BGP RIB and FRR table architectureAdj-RIBs-In, Loc-RIB, Adj-RIBs-Out, and the FRR bgpd and zebra path from received BGP route to installed forwarding state on VyOS 1.5 LTS.→
- BGP best-path decisionThe eleven-step BGP best-path sequence, local policy controls, and a repeatable FRR validation method on VyOS 1.5 LTS.→
- BGP session lifecycleIdle, Connect, Active, OpenSent, OpenConfirm, and Established: the VyOS 1.5 LTS BGP state machine and the evidence used to move between states.→
Part XXIV
BGP Session Establishment
6 checks
- BGP configuration foundationsBuild a VyOS 1.5 LTS BGP process with system-as, router ID, network origination, and controlled redistribution.→
- BGP neighbour identity and source addressDefine BGP neighbors, remote AS values, stable source addresses, unnumbered interfaces, descriptions, and passive behavior on VyOS 1.5 LTS.→
- BGP timers and advertisement intervalsTune keepalive, hold time, ConnectRetry, TCP keepalive, MRAI, and advertisement interval with production safeguards on VyOS 1.5 LTS.→
- BGP authentication and GTSMProtect VyOS 1.5 LTS BGP TCP sessions with TCP-MD5, understand SHA and TCP-AO direction, manage key chains, and apply GTSM deliberately.→
- eBGP multihop and peer groupsDesign routed eBGP sessions with explicit TTL, stable source addresses, peer groups, and a guarded allowas-in policy on VyOS 1.5 LTS.→
- BGP session troubleshootingA state-first method for diagnosing VyOS 1.5 LTS BGP sessions stuck in Active, OpenSent, OpenConfirm, or flapping, including AS, MD5, and TTL failures.→
Part XXV
BGP Route Advertisement
6 checks
- The BGP network statement — origin and exact-match semanticsHow `address-family ipv4-unicast network <prefix>` selects which prefixes BGP originates on VyOS 1.5 LTS / FRR 10.x. Exact-match behaviour, the route-map filter on the network statement, the difference from redistribute, where the tree moved in 1.4, and the production failure modes when a prefix the operator expects to see is not advertised.→
- BGP aggregation — aggregate-address, summary-only, and as-setHow `aggregate-address` summarises more-specific prefixes into a BGP aggregate on VyOS 1.5 LTS / FRR 10.x. Where the node lives in the 1.5 address-family tree, what summary-only suppresses, what as-set preserves, where the aggregate's ORIGIN actually comes from, and the production failure modes where the operator expected the more-specifics to be advertised alongside the aggregate but they are not.→
- Redistributing static routes into BGP — metric, route-map, and route leakHow `redistribute static` brings static routes into the BGP table on VyOS 1.5 LTS / FRR 10.x. Default origin `incomplete`, default metric handling, route-map filtering for leak prevention, and the production failure modes where an operator accidentally advertised an internal static route externally.→
- Redistributing OSPF into BGP — E1/E2 metric types, route-maps, and feedbackHow `redistribute ospf` brings OSPF routes into BGP on VyOS 1.5 LTS / FRR 10.x. The difference between OSPF external type 1 (E1) and type 2 (E2) metrics, where the BGP MED actually comes from, route-map filtering and FRR's implicit-deny semantics, the OSPF-into-BGP-into-OSPF feedback problem, and the production failure modes where an operator accidentally advertised internal OSPF routes externally.→
- BGP conditional advertisement — advertise-map and non-exist-mapHow BGP conditional advertisement works on VyOS 1.5 LTS / FRR 10.x. The per-neighbour advertise-map with exist-map or non-exist-map, the scanner timer that decides how fast it reacts, the backup-path use case, and the production failure modes where the operator expected conditional behaviour but the advertisement never fired.→
- BGP advertisement troubleshooting — prefix not advertised, route-map blocking, next-hop unreachableThe systematic diagnostic for the canonical BGP advertisement failures on VyOS 1.5 LTS / FRR 10.x. Why a prefix is not in the BGP table, why a prefix is in the table but not advertised, why a peer receives the prefix but cannot use it, and the production discipline that catches these failures before the user notices.→
Part XXVI
BGP Attributes
6 checks
- Local preference — the iBGP outbound path selectorHow BGP local preference selects the outbound path on VyOS 1.5 LTS / FRR 10.x. The well-known discretionary attribute, iBGP-only propagation, route-map configuration, tie-breaking with weight, and the production failure modes where the operator expected the higher local preference to win but traffic goes the other way.→
- AS path — prepend, aggregation loss, and the loop preventionHow the BGP AS_PATH attribute works on VyOS 1.5 LTS / FRR 10.x. The well-known mandatory classification, AS path prepend for outbound traffic engineering, attribute loss during aggregation, loop prevention, and the production failure modes where an operator's prepend was ignored or the AS path caused an unexpected loop detection.→
- BGP origin — IGP, EGP, and incomplete in FRRHow the BGP ORIGIN attribute works on VyOS 1.5 LTS / FRR 10.x. The three values (IGP, EGP, incomplete), how each origination primitive sets the origin, FRR rendering in `show ip bgp`, and the production failure modes where the operator expected `igp` but the route was `incomplete` (or vice versa).→
- BGP MED — multi-exit discriminator, eBGP-only, and always-compare-medHow the BGP MED (multi-exit discriminator) attribute works on VyOS 1.5 LTS / FRR 10.x. Optional non-transitive, eBGP-only propagation, MED oscillation, the `always-compare-med` knob, and the production failure modes where the operator's MED setting did not influence the peer's selection.→
- BGP communities — well-known, extended, and largeHow BGP communities work on VyOS 1.5 LTS / FRR 10.x. Standard 32-bit communities, the RFC 1997 well-known communities (no-export, no-advertise, no-export-subconfed), NOPEER, BLACKHOLE and GRACEFUL_SHUTDOWN, extended 64-bit communities, large 96-bit communities, route-map matching and setting on the 1.4+ configuration tree, and the production failure modes where the operator's community policy was silently ignored.→
- BGP attribute anti-patterns — missing local-preference, MED oscillation, attribute loss on aggregationThe canonical anti-patterns in BGP attribute configuration on VyOS 1.5 LTS / FRR 10.x. Why missing local-preference on outbound routes is dangerous, how MED oscillation happens and how to detect it, the attribute loss during aggregation without `as-set`, the consequences of well-known community misconfiguration, and the discipline that prevents these patterns from being deployed.→
Part XXVII
BGP Best Path
6 checks
- The 11-step BGP best-path algorithm — how FRR decides which route winsComplete walk-through of the BGP best-path decision process on VyOS 1.5 LTS: the eleven tie-break steps in order, why each step exists, what evidence each step leaves in show ip bgp, and how the operator predicts the outcome of a multi-peer prefix before touching the configuration.→
- The Weight attribute — a local-only tie-breaker, per-neighbour and per-prefixHow Weight works on VyOS 1.5 LTS / FRR 10.x: why it is not a BGP protocol attribute and is never propagated, the two places VyOS exposes it (the per-neighbour address-family leaf and route-map `set weight`), the scope difference against Local Preference, and the production patterns where Weight is the right tool and where it is the wrong one.→
- AS Path prepending — making your own AS path look longer to influence inbound trafficHow AS Path prepending works on VyOS 1.5 LTS, the RFC 4271 implementation, why operators prepend their own AS on export to influence upstream selection, the canonical inbound traffic-engineering pattern, and the failure modes that follow from over-prepending.→
- Origin and MED — the IGP/EGP/incomplete origin and the MED tie-break between same-AS pathsHow the Origin attribute drives step 5 (IGP < EGP < incomplete) and how MED drives step 6 (lowest MED between paths from the same AS) on VyOS 1.5 LTS. The operational consequences of using redistribute vs network, why MED is ignored between paths from different ASes, and the deterministic-med knob that makes MED comparison order-independent.→
- IGP cost tiebreak — when AS Path and other attributes tie, lowest IGP cost to next-hop winsHow step 8 of the BGP best-path algorithm uses the IGP cost to the next-hop as the tiebreaker, why iBGP paths often have higher IGP cost than eBGP paths, how to influence the next-hop reachability without changing the BGP configuration, and the production failure modes where the lowest-cost path is selected accidentally.→
- BGP best-path troubleshooting — missing routes, suboptimal path, why MED is ignoredThe systematic troubleshooting of BGP best-path failures on VyOS 1.5 LTS: routes not received, suboptimal path selected, MED ignored between paths from different ASes, the deterministic-med and missing-as-worst parameters under protocols bgp, and the evidence-gathering discipline that turns a 'wrong path' ticket into a precise remediation.→
Part XXVIII
BGP Prefix Filtering
6 checks
- Prefix-list semantics — ordered, sequential, ge/le/exact-match, implicit denyHow prefix-lists work on VyOS 1.5 LTS: the ordered sequential evaluation, the ge and le operators that match prefix-length ranges, the exact-match operator, the implicit deny at the end, and the operational difference between a prefix-list and an access-list.→
- Prefix-list configuration — sequence numbers, ge/le operators, descriptions, hit countersHow to configure prefix-lists on VyOS 1.5 LTS: the set policy prefix-list syntax, sequence numbers with room for insertion, the ge and le operators and the invariant FRR enforces on them, the description field for self-documentation, the hit counters FRR keeps without being asked, and the import/export attachment on a BGP neighbour.→
- Distribute-list — applying an ACL or prefix-list to a BGP neighbour in/outHow distribute-list works on VyOS 1.5 LTS: it takes a numbered access-list, it lives under the neighbour's address-family, and its directions are import and export. What it filters (NLRI on receive, NLRI on advertise), why prefix-list is the node you almost always want instead, and the canonical import and export filter patterns.→
- AS-path filter-list — regex matching on AS_PATH for BGP neighbour filteringHow filter-list works on VyOS 1.5 LTS: binding an AS-path-list under a BGP neighbour address family with import or export, the AS-path regex semantics FRR actually implements, the canonical patterns for filtering routes from specific upstreams by AS number, and the production failure modes around regex boundaries and the implicit deny.→
- Maximum-prefix — bounding the number of prefixes a BGP peer can sendHow maximum-prefix works on VyOS 1.5 LTS: the `maximum-prefix` leaf under a neighbour address family, `maximum-prefix-out` for the other direction, what FRR does at the 75% threshold and at the limit, why VyOS exposes no warning-only or restart node, and the production failure modes around a limit set too low or too high.→
- Filter troubleshooting — prefix not received, prefix not advertised, regex errors, AS-path-list syntaxThe systematic troubleshooting of BGP filter failures on VyOS 1.5 LTS: prefix not received from peer, prefix not advertised to peer, regex errors in filter-list, AS-path-list syntax errors, and the evidence-gathering discipline that turns a 'route is missing' ticket into a precise remediation.→
Part XXIX
BGP Communities
6 checks
- BGP communities — the optional transitive attribute, the AA:NN format, and well-known communitiesWhat BGP communities are inside an UPDATE, why they are optional transitive, the canonical AA:NN 32-bit encoding, the four well-known values (no-export, no-advertise, no-export-subconfed, no-peer), and how VyOS 1.5 LTS exposes them through FRR's `show ip bgp` and the configuration tree.→
- Configuring community-lists and route-maps — set community add, replace, and the choice VyOS makes you stateHow VyOS 1.5 LTS exposes BGP community policy through `policy community-list` and `policy route-map`, why the 1.5 tree forces an explicit `add` or `replace` on every `set community`, how the single `regex` leaf on a community-list behaves, and the production pattern that labels, strips, and rewrites communities on inbound and outbound routes.→
- Large communities — RFC 8092, the 12-byte format, and the 4-byte ASN problemWhy the standard 32-bit community cannot carry a 4-byte ASN in its AA field, the RFC 8092 12-byte format (Global Administrator 4 bytes + Local Data 8 bytes), the canonical `large-community:65001:100:42` triple, and how VyOS 1.5 LTS exposes them through `set large-community` and `show ip bgp large-community`.→
- Extended communities — the 8-byte format, MPLS VPN RT/RD, and link-bandwidthHow BGP extended communities (RFC 4360) extend the 32-bit standard community into an 8-byte value with a 1-byte type field, the role of Route Target (RT) and Route Distinguisher (RD) in MPLS VPN, the link-bandwidth extended community for per-flow load-balancing, and how VyOS 1.5 LTS surfaces them through the VRF BGP address-family tree and the VPN RIB.→
- Community-driven policy — matching communities to set local-pref, AS-path prepend, MED, and geographic taggingThe canonical BGP production pattern: tag routes with a community where they enter the AS, then match that community later to drive local-preference, AS-path prepending and MED. Why the tag belongs on the eBGP import route-map, where the decision can legitimately be made, and how VyOS 1.5 LTS exposes all of it through `set policy community-list`, `set policy route-map` and `set protocols bgp neighbor <ip> address-family ipv4-unicast route-map import|export`.→
- Community troubleshooting — community not propagated, transitive vs non-transitive, regex matchingThe diagnostic workflow for the most common community failures: the community is dropped on egress (replace vs additive), the community-list over-matches because an expanded rule is a regex over the whole community string, the route-map rule order or binding is wrong, and the community never leaves the router because send-community was disabled. How to read FRR JSON for the raw attribute, read the route-map hit counters, and use `tcpdump` to confirm the UPDATE carries the attribute.→
Part XXX
BGP Route Reflectors
6 checks
- iBGP full-mesh problem — why IBGP requires a full mesh, what the route reflector solves, and the loop-prevention trio (originator-id, cluster-list, cluster-id)Why iBGP speakers must form a full mesh by default (the split-horizon rule: a route learned from one iBGP peer must not be re-advertised to another iBGP peer), why the full mesh is the scaling bottleneck, the route reflector as the structural fix, and the three reflection attributes that prevent loops: originator-id, cluster-list, and cluster-id.→
- Route reflector configuration — `route-reflector-client`, the two-RR cluster, and the canonical client/server meshThe VyOS 1.5 LTS configuration of a route reflector: the `route-reflector-client` flag where it actually lives (inside the neighbour's address family), the cluster-id under `protocols bgp parameters`, the canonical two-RR cluster where every client peers with both, and the reflection rules RFC 4456 actually specifies. How to verify reflection from the Originator and Cluster list attributes, and the next-hop reachability failure that catches every first deployment.→
- Cluster-id — the deduplication key, and why it decides how your clients must peerThe cluster-id as the per-cluster loop-prevention key on VyOS 1.5 LTS: where it lives in the 1.5 BGP tree, what a route reflector actually stamps and when, why two RRs sharing a cluster-id must both peer with every client, the best-path tie-break that decides which copy a client installs, and the failure modes of a mismatched or colliding cluster-id.→
- Confederations — sub-AS, AS_CONFED segments, eBGP-within-confederation, and when to use RR vs confederationThe confederation alternative to route reflection on VyOS 1.5 LTS / FRR 10.x: the AS is split into sub-ASes with private ASNs, eBGP-within-confederation preserves LOCAL_PREF and the sub-AS path, the AS_CONFED_SEQUENCE and AS_CONFED_SET segment types inside AS_PATH, the public ASN as the confederation identifier, and the production pattern of choosing between route reflection and confederation for AS scaling.→
- Multipath-relax — `bestpath as-path multipath-relax`, the identical-AS_PATH default, and eBGP/iBGP multipathBGP multipath on VyOS 1.5 LTS and FRR 10.x: why the default requires an identical AS_PATH rather than merely an equal-length one, what `bestpath as-path multipath-relax` does and does not relax, how `maximum-paths ebgp` and `maximum-paths ibgp` differ, `bestpath peer-type multipath-relax` for mixing the two, and how to read the multipath flag in the BGP table.→
- Route reflector troubleshooting — missing client flag, loop-guard rejections, and the attributes an RR must not touchThe diagnostic workflow for the seven route reflector failures an operator actually meets: the client flag is missing, the flag is set in only one address family, CLUSTER_LIST rejects a path by design, ORIGINATOR_ID rejects a path because two routers share a router-id, the iBGP session never reaches Established, an export policy on the RR rewrites attributes RFC 4456 says it must not, and the expectation that traffic load-balances across the reflectors. A seven-step audit that walks a reflection failure from symptom to cause on VyOS 1.5 LTS.→
Part XXXI
BGP Troubleshooting
6 checks
- BGP session states — Idle, Connect, Active, OpenSent, OpenConfirm, Established, and the Notification codes that knock a peer out of eachHow the BGP finite state machine progresses on VyOS 1.5 LTS / FRR 10.x: the six high-level states (Idle, Connect, Active, OpenSent, OpenConfirm, Established), why a session gets stuck in Active, what the OpenConfirm hold-time countdown means, the six Notification error codes RFC 4271 defines, and the operational evidence each state leaves in show ip bgp summary and show ip bgp neighbors.→
- BGP routes missing — not received, not advertised, not installedThe three failure points for a missing BGP route on VyOS 1.5 LTS: not received (peer filter, session down, attribute rejection), not advertised (network statement, aggregate, redistribution, route-map), not installed (next-hop unreachable, rib failure, FIB rejection). How to walk the BGP RIB, the Adj-RIBs-In, the Loc-RIB, and the FIB to find which stage dropped the route.→
- BGP session flapping — interface, route-flap damping, BFD, peer resetDiagnosing BGP session flapping on VyOS 1.5 LTS: physical interface flapping (cable, SFP, optics), route-flap damping suppressing a prefix after repeated withdrawal/re-advertise, BFD tearing down the session faster than the hold-time, and the operator-driven peer reset cycle. How to read the up/down timer, the dampening history, and the BGP log to identify the flapping cause.→
- BGP route oscillation — next-hop resolution, MED, and reflectorsDiagnosing BGP route oscillation on VyOS 1.5 LTS / FRR 10.x: iBGP paths that never become best because the next hop does not resolve, MED-induced oscillation between paths from the same neighbouring AS, and route reflectors turning partial visibility into a sustained cycle. Includes the parameters that actually exist on 1.5 — deterministic-med, cluster-id, network-import-check — and the ones operators expect and will not find.→
- BGP blackhole — route leak, prefix hijack, RPKI invalid, BGP dampeningDiagnosing BGP blackhole on VyOS 1.5 LTS / FRR 10.x: route leak (an AS advertises a prefix it does not own), prefix hijack (an AS advertises a more-specific prefix to attract traffic), RPKI invalid (a route that fails origin validation), and route-flap dampening suppression. How to use protocols rpki, prefix-list, filter-list, maximum-prefix and the RFC 7999 blackhole community to prevent and respond.→
- BGP performance — MRAI, route-refresh, soft-reconfiguration, ORF, large BGP tablesTuning BGP performance on VyOS 1.5 LTS: MRAI (Minimum Route Advertisement Interval) timer for outbound batching, route-refresh and soft-reconfiguration for inbound updates without session reset, ORF (Outbound Route Filter) for the peer to filter its outbound updates to the local router, and strategies for large BGP tables (memory, CPU, peering scaling).→
Part XXXII
BFD
6 checks
- BFD concept — Bidirectional Forwarding Detection, sub-second failure detection, control-plane independentHow BFD works on VyOS 1.5 LTS / FRR 10.x: the lightweight UDP-based failure detection protocol, sub-second detection intervals, control-plane independence (BFD does not rely on the routing protocol's keepalive), the three-way handshake, the transmit/receive interval and multiplier, and how BFD integrates with BGP, OSPF, and static routes.→
- BFD configuration — protocols bfd, peer configuration, transmit/receive interval, multiplierHow to configure BFD on VyOS 1.5 LTS: the protocols bfd node, BFD profiles for reusable configurations, peer configuration (single-hop and multi-hop), the transmit/receive interval and multiplier knobs, echo mode, and the operational commands to validate.→
- BFD with BGP — neighbor bfd, sub-second failure detection, and the profile that owns the timersIntegrating BFD with BGP on VyOS 1.5 LTS: enabling BFD on a peer under set protocols bgp neighbor, why the FRR default timers give roughly 900ms rather than 150ms, how the BFD profile owns every timer because the BGP neighbour exposes none, and the operational commands that prove the integration is live.→
- BFD with OSPF — ip ospf bfd, sub-second OSPF failure detection, faster SPFIntegrating BFD with OSPF on VyOS 1.5 LTS: how to enable BFD on an OSPF interface with `ip ospf bfd`, how BFD bypasses the OSPF dead-interval (40s default) for sub-second failure detection, the interaction between BFD profile and OSPF interface configuration, and how BFD triggers faster SPF recalculation.→
- BFD with static routes — tracking a static next-hop, and the distance that makes it a fallbackIntegrating BFD with static routes on VyOS 1.5 LTS: the bfd node on a static next-hop and its profile, the 1.4+ interval receive/transmit/multiplier leaves, how staticd withdraws the route when BFD goes down, why a fallback static route needs an explicit distance, and the operational commands that actually exist.→
- BFD troubleshooting — session down, misconfigured timers, asymmetric intervalsDiagnosing BFD session failures on VyOS 1.5 LTS: BFD session in Down state (firewall blocking UDP 3784/4784, peer not running BFD, VRF mismatch), BFD session flapping (interval too aggressive, asymmetric intervals negotiated, peer CPU saturated), BFD session Up but routing protocol not using it (missing bfd clause on routing protocol), and asymmetric intervals — how to read show bfd peer for negotiated parameters.→
Part XXXIII
Route Policy
6 checks
- Policy concept — the vocabulary, the building blocks, the evaluation orderHow VyOS 1.5 LTS / FRR 10.x organises routing policy. The five primitives (prefix-list, community-list, as-path-list, route-map, sequence), the implicit-deny at the end of every list, and the order in which a route is evaluated against them.→
- Prefix-list — sequence, ge, le, exact-match, deny vs permitHow to configure a prefix-list on VyOS 1.5 LTS / FRR 10.x. Sequence-numbered rules, the ge and le operators, exact-match, and the production failure modes that arise from over-broad ge/le combinations.→
- Community-list — standard, expanded, and regular-expression matchingHow BGP community-lists work on VyOS 1.5 LTS / FRR 10.x. The standard form (exact-match communities), the expanded form (regular expressions), sequence semantics, and the production failure modes that arise from a community-list that matches too broadly or too narrowly.→
- AS-path-list — regular-expression matching over the BGP AS_PATH attributeHow BGP as-path access-lists work on VyOS 1.5 LTS / FRR 10.x. POSIX regular expressions over the AS_PATH string, sequence semantics, deny vs permit, and the production failure modes that arise from a regex that matches too much or too little.→
- Route-map composition — match and set clauses, sequence ordering, implicit denyHow route-maps combine match and set clauses on VyOS 1.5 LTS / FRR 10.x. The match semantics (AND across match types, OR within a match type), the set clauses (metric, community, local-preference, as-path prepend, next-hop), the sequence ordering, the implicit-deny on no-match, and the production failure modes.→
- Policy validation — testing with vtysh, clearing route-maps, sequence numbering gotchasHow to validate a policy change on VyOS 1.5 LTS / FRR 10.x. The vtysh show commands for each primitive, the clear commands to reset hit counts, the sequence-numbering gotchas that cause silent policy bypass, and the production validation discipline.→
Part XXXIV
Route Redistribution
6 checks
- Redistribution concept — why redistribute, route-map filtering, metric preservation, seed metricHow redistribution between routing protocols works on VyOS 1.5 LTS / FRR 10.x. The route-map filtering, the seed metric, the metric-type selection, the administrative-distance trap, and the production failure modes where unfiltered redistribution leaks routes or causes routing loops.→
- Redistributing static into BGP — route-map filtering, seed metric, community tagsHow to redistribute static routes into BGP on VyOS 1.5 LTS / FRR 10.x. The route-map filter, the seed metric, the community tag for downstream filtering, and the production failure modes where unfiltered redistribution leaks internal prefixes.→
- Redistributing OSPF into BGP — what survives the boundary, the MED, and feedback preventionHow to redistribute OSPF routes into BGP on VyOS 1.5 LTS / FRR 10.x. What an OSPF route loses when it crosses into BGP, where the E1/E2 metric-type actually lives, the route-map filter, the seed metric as BGP MED, and breaking the OSPF-into-BGP-into-OSPF feedback loop with a community or a route tag.→
- Redistributing connected routes — physical interface routes, when to include, when to excludeHow to redistribute connected routes into BGP on VyOS 1.5 LTS / FRR 10.x. The address-family placement of the redistribute statement, the connected-source semantics, which interface subnets belong in BGP and which do not, why an iBGP loopback belongs in the IGP instead, and the production failure modes.→
- Redistributing kernel routes — what `redistribute kernel` really carries, and why it is rarely the right answerHow `redistribute kernel` behaves on VyOS 1.5 LTS / FRR 10.x. What zebra classifies as a kernel route, the narrow cases where redistributing it is justified, the VyOS-native alternatives that are almost always better, and the production failure mode where a route nobody configured is advertised to a peer.→
- Redistribution anti-patterns — bidirectional loops, missing tags, suboptimal pathsThe production anti-patterns of redistribution on VyOS 1.5 LTS / FRR 10.x. Bidirectional redistribution loops, missing route-maps, missing feedback-prevention tags, suboptimal path selection due to administrative distance, and the diagnostic discipline to identify each pattern.→
Part XXXV
Route Summarisation
6 checks
- Route summarisation concept — aggregation, prefix length, route-map filteringWhy a VyOS 1.5 LTS routing estate summarises prefixes: control-plane overhead, route-flap propagation, the summary-vs-specific trade-off, prefix length arithmetic, and the route-map tool that decides what leaves the router.→
- BGP aggregation — aggregate-address, summary-only, as-set, attribute inheritanceHow `aggregate-address` summarises more-specific prefixes into a BGP aggregate on VyOS 1.5 LTS / FRR 10.x. Summary-only suppresses the more-specifics, as-set preserves the contributing AS-path as a set, attribute inheritance via route-map, atomic-aggregate flag, and the production failure modes around attribute loss and unintended suppression of more-specifics.→
- OSPF summarisation — area range, ABR summarisation, totally-stubby areaHow OSPF area range summarises inter-area routes on the ABR on VyOS 1.5 LTS / FRR 10.x. Type-3 LSA generation, the difference between intra-area and inter-area summarisation, totally-stubby and NSSA areas, cost manipulation on the summary, and the production failure modes around missing ranges, downstream blackholes, and LSA translation issues.→
- RIPv2 summarisation — default-metric, automatic classful-boundary summaryHow RIPv2 summarises on classful boundaries on VyOS 1.5 LTS / FRR 10.x. Automatic summarisation enabled by default, the classful-boundary rule, default-metric for redistribution, the production failure modes around subnetted classful networks and the discontiguous subnet problem.→
- Blackhole routes for summary prefixes — null0, discard, loop preventionHow the blackhole (null0) route protects a summary prefix on VyOS 1.5 LTS / FRR 10.x. The discard primitive, ICMP unreachable generation, the routing-loop prevention model, and the production failure modes around long-lived blackholes, ICMP rate limiting, and unwanted discards.→
- Summarisation troubleshooting — missing summaries, more-specific leaks, attribute lossHow to diagnose summarisation failures on VyOS 1.5 LTS / FRR 10.x. Missing aggregate (no components in the BGP table), more-specifics still leaking, attribute loss on the aggregate, ICMP unreachable floods from a blackhole, what a collapsed RIP prefix really means when ripd has no auto-summary to blame, and the diagnostic ladder for each.→
Part XXXVI
ECMP
6 checks
- ECMP concept — Equal-Cost Multi-Path, kernel flow-based or route-based hashing, throughput scalingWhy a VyOS 1.5 LTS routing estate uses Equal-Cost Multi-Path (ECMP). The kernel's per-flow or per-packet hashing model, the throughput scaling argument, the trade-offs of flow-based vs route-based, the asymmetric routing problem, and the production failure modes where only one path is used.→
- ECMP configuration — multiple next-hops, max-paths, load-balancing algorithmHow to configure ECMP on VyOS 1.5 LTS / FRR 10.x. Multiple next-hops for static routes, `maximum-paths` under the BGP address-family and directly under OSPF, the kernel hash policy set through system sysctl, what VyOS does not expose, and the production failure modes around unequal-cost paths and missing failure detection.→
- BGP ECMP — maximum-paths, eBGP/iBGP, multipath-relax, AS_PATH length requirementBGP ECMP on VyOS 1.5 LTS / FRR 10.x. maximum-paths for eBGP and iBGP, multipath-relax for AS_PATH-unequal peers, the per-peer next-hop tracking, and the production failure modes around best-path divergence, MED mismatches, and missing multipath-relax.→
- OSPF ECMP — equal-cost behaviour, default configuration, when ECMP appliesOSPF ECMP on VyOS 1.5 LTS / FRR 10.x. The default maximum-paths, how OSPF cost determines ECMP eligibility, the Type-1 and Type-3 LSA paths, the intra-area vs inter-area ECMP distinction, and the production failure modes around cost mismatches and LSA translation issues.→
- Per-class ECMP — policy routes, alternate tables, and the fwmark VyOS ownsGiving different traffic classes different ECMP sets on VyOS 1.5 LTS: the policy route rule-set that selects an alternate table, the multiple next-hops that make that table an ECMP set, the fwmark VyOS derives and controls itself, why 'mark it then match the mark' is not available for forwarded traffic, and the failure modes that make a policy silently do nothing.→
- ECMP troubleshooting — only one path used, asymmetric traffic, next-hop unreachableA state-first method for diagnosing ECMP failures on VyOS 1.5 LTS. Only one path used (unequal costs, missing maximum-paths), asymmetric traffic breaking stateful firewalls, next-hop unreachable after a failure (no BFD), and the diagnostic ladder for each failure mode.→
Part XXXVII
Firewall Fundamentals
6 checks
- Stateful vs stateless filtering — conntrack, NEW/ESTABLISHED/RELATED, the performance argumentHow VyOS 1.5 LTS builds its stateful firewall on nf_conntrack and nftables. The packet states, where the ruleset is actually evaluated, why there is no implicit fast path for established traffic, what a flowtable does instead, and the production failure where a rule with no state clause admits out-of-state traffic.→
- Zones and chains — base chains, named rule-sets, `firewall zone`, and jump targetsHow VyOS 1.5 LTS organises firewall policy: three base chains bound to netfilter hooks, named rule-sets reached with `action jump`, and the `firewall zone` tree that replaced `zone-policy` in 1.4. The from-direction zone model, default-action semantics including `return`, and the production failure modes where a rule-set is never reached or the reverse direction was never written.→
- Rule ordering — sequence numbers, first-match, action accept/drop/rejectHow VyOS 1.5 LTS evaluates firewall rules in sequence order. The rule number, the action (accept, drop, reject), the first-match semantics, and the production failure modes where a too-broad rule shadows a more-specific rule, or where reject sends ICMP unreachable that masks a deeper problem.→
- State tracking — connection marks, recent, and the limits of the conntrack matchesHow VyOS 1.5 LTS uses the conntrack table beyond simple state matching: connection marks that survive both directions of a flow, `recent` for per-source rate tracking, `limit` for rule-level rate control, and an honest account of the per-source concurrent-connection cap that VyOS does not expose at all.→
- Default deny — WAN-IN posture, established accept, INVALID log, the production reference architectureThe canonical WAN-facing firewall posture on VyOS 1.5 LTS. Default deny in the custom chain, established/related handling as a global state policy or as rules at the top, INVALID logging to surface scanners, explicit permits for the legitimate inbound services, and the production reference architecture that every operator can start from.→
- Firewall troubleshooting — log, conntrack, packet capture, the diagnostic methodHow to diagnose a VyOS 1.5 LTS firewall that is not admitting traffic it should, or is admitting traffic it should not. The firewall log, the conntrack table, packet capture with tcpdump, the diagnostic method that walks the chain from ingress to egress, and the production failure modes where the firewall appears to be working but is silently bypassed.→
Part XXXVIII
NAT Fundamentals
6 checks
- SNAT vs DNAT concept — source vs destination NAT, the kernel nftables primitivesHow VyOS 1.5 LTS implements source NAT (SNAT) and destination NAT (DNAT) on top of the Linux kernel's nftables NAT primitives. The translation direction, the conntrack interaction, the kernel hooks (PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING), and the production failure modes where the NAT direction is wrong or the conntrack entry is stale.→
- Masquerade — dynamic source NAT for the WAN interfaceHow VyOS 1.5 LTS implements masquerade, the dynamic source NAT pattern that uses the WAN interface's IP at translation time. The masquerade vs SNAT tradeoff, the conntrack interaction, the use cases (dynamic WAN IP, DHCP, PPPoE), and the production failure modes where masquerade silently breaks when the WAN IP changes.→
- Port forwarding — DNAT, translation table, hairpin NAT, firewall rulesHow VyOS 1.5 LTS implements inbound port forwarding with DNAT. The destination NAT rule, the firewall rules that must permit the post-NAT traffic, the hairpin NAT pattern for LAN-to-public-IP access, and the production failure modes where the firewall blocks the translated traffic or the hairpin NAT is missing.→
- One-to-one NAT — 1:1 static NAT, both directions, no conntrack asymmetryHow VyOS 1.5 LTS implements 1:1 static NAT. The bidirectional translation, the difference from port forwarding (1:1 maps all ports, not just one), the routing requirement on the private host, the conntrack considerations, and the production failure modes where the host's default gateway is wrong or the firewall blocks the traffic.→
- NAT with firewall — rule placement, established match, conntrack interactionHow VyOS 1.5 LTS coordinates NAT and firewall rules: why the filter hooks see a post-DNAT, pre-SNAT packet, how a named rule set is reached from the forward chain with action jump, the established match that admits NAT'd return traffic, and the production failure modes where a rule is written against an address the firewall never sees.→
- NAT troubleshooting — hairpin failure, port exhaustion, asymmetric routing, conntrack flushHow to diagnose a VyOS 1.5 LTS NAT deployment that is not translating traffic correctly. The conntrack table as the source of truth, the hairpin NAT failure mode, port exhaustion, asymmetric routing, the conntrack flush procedure, and the production anti-patterns the operator must avoid.→
Part XXXIX
Multi-WAN
6 checks
- Multi-WAN concept — the three mechanisms VyOS actually offers, and the asymmetry each one createsThe conceptual foundation for multi-WAN on VyOS 1.5 LTS. The three mechanisms the platform really ships (ECMP static routes, the load-balancing wan policy engine, and hand-written policy routing), what each one does to the routing table, why source-address asymmetry rather than route asymmetry is what breaks flows, and the production failure modes where a failover is silent.→
- WAN failover — the floating static design, the load-balancer design, and why they are verified differentlyHow VyOS 1.5 LTS actually builds WAN failover. The floating static route with BFD, which moves the routing table; the load-balancing wan policy engine, which does not; the failure-count and success-count damping that replaces a timer; and the controlled test that turns a configuration into a failover.→
- WAN load sharing — ECMP across two circuits, and what the hash seesHow VyOS 1.5 LTS spreads traffic across two WANs: kernel ECMP with two equal-cost default routes, what fib_multipath_hash_policy actually selects between, why static routes have no weight and where weighting really lives, and the asymmetric-routing and conntrack failure modes that decide whether active-active works at all.→
- WAN policy routing — policy route rule-sets, alternate tables, and the mark that gets overwrittenHow VyOS 1.5 LTS actually implements policy routing for multi-WAN: the policy route rule-set applied to an ingress interface, alternate routing tables under protocols static table, policy local-route for router-originated traffic, and the documented constraint that set table overwrites the packet mark.→
- WAN health check — the three test types VyOS ships, the counters that replace a threshold, and the targets worth probingWhat load-balancing wan interface-health actually offers on VyOS 1.5 LTS: the ping, ttl and user-defined test types, resp-time as a timeout rather than a latency SLA, failure-count and success-count as the only damping, the absence of an interval knob, and how to write the checks VyOS does not ship.→
- Multi-WAN troubleshoot — which mechanism is in play, marks, conntrack, asymmetry, hairpinHow to diagnose a VyOS 1.5 LTS multi-WAN deployment that is not steering traffic the way the configuration claims. Establishing which of the two multi-WAN mechanisms the router is actually running, the routing / NAT / conntrack / firewall / return-path walk with real 1.5 operational commands, the connection mark as the source of truth, the inbound asymmetry that sticky-connections fixes, the hairpin NAT failure, and the failure modes where multi-WAN silently does nothing at all.→
Part XL
VRRP High Availability
6 checks
- VRRP concept — Virtual Router Redundancy Protocol, master/backup, virtual MACWhat VRRP is at the protocol level, why production networks use it for first-hop redundancy, how master/backup election works, and what the virtual MAC address buys you.→
- VRRP priority and skew — how election really works, the master-down-interval calculationHow the VRRP priority field (1-255) determines master/backup election, how the skew field delays backup failover, and how the master-down-interval is computed from priority, skew, and advertisement-interval.→
- VRRP preemption — higher priority takes over, and when to disable itWhat VRRP preemption does, why higher-priority routers take over from lower-priority masters after recovery, and the production trade-offs of leaving preemption enabled versus disabled.→
- VRRP advertisements — packet format, IP protocol 112, multicast 224.0.0.18The VRRP advertisement packet format, the IP protocol number (112), the multicast destination (224.0.0.18), and how to read a packet capture to validate VRRP state.→
- VRRP tracking — decrement priority on link failure, react to upstream stateHow VRRP tracking decrements the router's priority when a tracked interface (uplink, peer, or remote IP) goes down, why production networks use tracking to influence master election.→
- VRRP troubleshooting — split-brain, both-master, asymmetric traffic, missed electionsHow to diagnose VRRP failures — split-brain (both-master), asymmetric traffic from routing/state asymmetry, missed elections, and the diagnostic flow from symptom to root cause.→
Part XLI
WireGuard
6 checks
- WireGuard concept — kernel WireGuard, Noise protocol, UDP-based VPNWhat WireGuard is at the protocol level, why it is a kernel-space VPN, what the Noise Protocol Framework provides, and how it differs from IPsec and OpenVPN.→
- WireGuard keys — Curve25519 key pairs, preshared key, key managementHow WireGuard uses Curve25519 key pairs (private and public), what the preshared key adds, how VyOS 1.5 generates keys with generate pki wireguard and stores them in the configuration rather than on disk, and the production key-rotation discipline.→
- WireGuard peers — named peers, allowed-ips, peer address and port, persistent keepaliveHow a WireGuard peer is configured on VyOS 1.5 — a named node carrying public-key, address and port, allowed-ips and persistent-keepalive — what allowed-ips really mean, and the production patterns for peer management.→
- WireGuard routing — routing over WireGuard, MTU 1420, MSS clampingHow routing works over a WireGuard tunnel, why the MTU is 1420 bytes (not 1500), how to clamp the MSS at the firewall for TCP-over-tunnel, and the production patterns for tunnel routing.→
- WireGuard firewall and outer-packet routing — UDP port, input chain, multi-WANHow to configure the VyOS 1.5 firewall for WireGuard (UDP 51820 on the input chain, the forward chain for tunnelled traffic), why the encrypted outer packet is locally originated and therefore steered with policy local-route rather than a firewall mark, and the production failure modes of WireGuard firewall configuration.→
- WireGuard troubleshooting — handshake never happens, allowed-ips mismatch, MTU issuesHow to diagnose WireGuard failures on VyOS 1.5 — the handshake that never completes, the tunnel that is up and carries nothing, MTU and clamping problems, and NAT binding expiry — using show interfaces wireguard wg0 summary, the kernel counters and tcpdump.→
Part XLII
IPsec
6 checks
- IPsec concept — IKE, ESP, transport vs tunnel mode, the IPsec suiteWhat IPsec is at the protocol level, the IKE and ESP protocols, the difference between transport and tunnel mode, and how IPsec compares to WireGuard at the deployment level.→
- IKEv2 — Internet Key Exchange v2, RFC 7296, MOBIKE, EAP authenticationHow IKEv2 differs from IKEv1, the four-message handshake (IKE_SA_INIT and IKE_AUTH), MOBIKE for mobility, EAP for remote-access authentication, and the production benefits of IKEv2.→
- ESP proposals — ciphers, integrity, DH/PFS groups, configurationHow to configure ESP proposals (AES-GCM, ChaCha20-Poly1305), PFS groups for forward secrecy, ESP lifetime and anti-replay, and the production cipher choices.→
- Route-based VTI — Virtual Tunnel Interface, route-based IPsec, ip xfrmRoute-based IPsec on VyOS 1.5 LTS: what `set interfaces vti vtiN` actually creates in the kernel, how `vti bind` associates it with a site-to-site peer, why `disable-route-autoinstall` is mandatory, and how to verify a VTI tunnel without mistaking a control-plane check for a data-plane one.→
- NAT-T — NAT traversal for IPsec, UDP 4500 encapsulationWhy ESP cannot cross a NAT, how IKEv2 detects NAT and moves the exchange to UDP 4500, what VyOS 1.5 actually exposes (and what it deliberately does not), and the failure modes an operator meets in production.→
- IPsec troubleshooting — IKE debug, ESP debug, MTU, PFS mismatchThe VyOS 1.5 command set for diagnosing IPsec, the log strings each failure actually produces, and a flow that separates the five agreements a tunnel depends on so you fix the one that is broken.→
Part XLIII
VPN Routing
6 checks
- VPN routing basics — routing over tunnels, recursive routing, BGP/OSPF over VPNHow routes get onto a WireGuard or IPsec VTI tunnel on VyOS 1.5, the two mechanisms that produce recursive routing and what each looks like, choosing between BGP and OSPF over a tunnel, and static fallbacks that actually lose to the dynamic route.→
- BGP over VPN — iBGP over WireGuard or IPsec, peer addresses, route reflectionHow to configure BGP over VPN tunnels (WireGuard, IPsec VTI) on VyOS 1.5, what update-source actually pins, tunnel-address versus loopback peering, and route reflection for hub-and-spoke topologies.→
- OSPF over VPN — the multicast problem, NBMA with static neighbours, and area designWhy OSPF does not simply work over a WireGuard or IPsec VTI tunnel on VyOS 1.5, what the network type actually changes about the hello destination, how to configure NBMA with static neighbours, and the area design for hub-and-spoke.→
- VPN failover — why a tunnel route never withdraws itself, BFD on the next-hop, and ECMPHow to build dual-VPN failover on VyOS 1.5: why a WireGuard interface stays up when the peer is gone, why administrative distance alone gives you nothing, attaching BFD to a static next-hop, and when ECMP across tunnels is and is not appropriate.→
- VPN MTU — tunnel MTU, MSS clamping, fragmentationHow to calculate the MTU of a VPN tunnel, configure MSS clamping for TCP, handle Path MTU Discovery (PMTUD), and troubleshoot fragmentation issues.→
- VPN routing validation — end-to-end, asymmetric, BGP convergenceHow to validate VPN routing end-to-end, identify asymmetric traffic through firewalls, verify BGP convergence over VPN, and the diagnostic flow for VPN routing failures.→
Part XLIV
VXLAN
6 checks
- VXLAN concept — RFC 7348, VNI 24-bit, UDP 4789, overlay networkingWhat VXLAN is at the protocol level, RFC 7348, the 24-bit VNI for tenant segmentation, UDP 4789 transport, and how VXLAN differs from traditional VLANs.→
- VXLAN VNI — 24-bit namespace, tenant segmentation, VNI assignmentHow VXLAN Network Identifier (VNI) provides tenant segmentation, VNI assignment strategies, the 16M address space, and the production patterns for multi-tenant data centers.→
- VXLAN underlay — underlay routing, MTU 1550, jumbo framesHow the VXLAN underlay (Layer 3 network between VTEPs) must be configured on VyOS 1.5: where the 50 bytes of encapsulation overhead come from, why the underlay needs MTU 1550, how to route the VTEP loopbacks, and the production failure modes.→
- VXLAN with BGP EVPN — EVPN Type-2/3/5 routes, BGP as control planeHow BGP EVPN serves as the control plane for VXLAN, the EVPN route types (Type-2 for MAC, Type-3 for BUM, Type-5 for IP prefixes), and the VyOS 1.5 configuration surface that actually implements them.→
- VXLAN without EVPN — flood-and-learn, multicast underlayHow VXLAN works without BGP EVPN — flood-and-learn with multicast in the underlay, the limitations, and the production patterns.→
- VXLAN troubleshooting — VNI mismatch, underlay MTU, EVPN routes that never arriveHow to diagnose VXLAN failures on VyOS 1.5: a VNI or bridge that does not match, an underlay that cannot carry a 1550-byte packet, an EVPN control plane that is Established and advertising nothing, and multicast that never joins — with the operational commands that actually exist for each.→
Part XLV
QoS Fundamentals
6 checks
- QoS concept — traffic classes, scheduling, the QoS pipelineWhat QoS (Quality of Service) is, the traffic classes, the scheduling algorithms (FIFO, priority, WFQ, HTB), and the production use cases for QoS on VyOS.→
- DSCP marking — RFC 2474, the DiffServ field, PHB classificationsWhat DSCP (Differentiated Services Code Point) is, RFC 2474, the DiffServ field in the IP header, the standard PHB (Per-Hop Behavior) classes, and how to mark DSCP on VyOS.→
- Classification and matching — filters, match rules, fwmark, QoS classesHow packet classification works in QoS — filter rules, match criteria (DSCP, fwmark, port, IP), Linux qdisc filter (u32), and the production patterns for classification.→
- Queuing and shaping — HTB tree, fq_codel leaves, bandwidth shapingHow queuing and shaping work in Linux — HTB tree for shaping, fq_codel for leaf fairness, policing, and the production patterns for QoS queuing.→
- Trust boundaries — trust at access, untrusted at WAN, the operator's disciplineQoS trust boundaries — the discipline of trusting DSCP markings at access (LAN) and untrusting them at WAN, the marking strategy, and the production patterns for multi-tenant networks.→
- QoS troubleshooting — latency, jitter, packet loss, the diagnostic flowHow to diagnose QoS failures — high latency, jitter, packet loss, misclassified traffic, and the systematic diagnostic flow from symptom to root cause.→
Part XLVI
DHCP Services
6 checks
- DHCPv4 server — shared-network, subnet, range, optionsHow VyOS 1.5 LTS runs a Kea-based DHCPv4 server. Shared-network grouping, the mandatory subnet-id, the option subtree, dynamic ranges, high availability, and the production failure modes where leases silently stop.→
- DHCPv4 static-mapping — fixed address by MAC, hostname, reservationsHow VyOS 1.5 LTS binds a fixed IP address to a host's MAC address through DHCP static-mapping. Per-host options, hostname delivery, the difference between static-mapping and a separate subnet, and the production failure modes where two hosts collide on the same fixed address.→
- DHCPv4 relay — forwarding across segments, giaddr, the relay loop failure modeHow VyOS 1.5 LTS runs a DHCPv4 relay when the server is on a different segment. The relay agent forwards broadcasts as unicast, the giaddr field carries the relay's address, the option 82 insertion, and the production failure modes where a relay loop silently blocks DHCP.→
- DHCPv6 server — stateful IA_NA, prefix delegation IA_PD, the broadband CPE patternHow VyOS 1.5 LTS runs a DHCPv6 server with stateful address assignment (IA_NA) and prefix delegation (IA_PD). The shared-network / prefix-pool structure, the link between RA flags and DHCPv6, and the production failure modes where the upstream assigns but the downstream drops.→
- DHCP troubleshooting — lease exhaustion, conflict detection, relay loops, silent failuresHow to diagnose DHCP failures on VyOS 1.5 LTS. Lease exhaustion, IP conflict detection, relay loops, giaddr mismatches, server bound to the wrong interface, the diagnostic flow from symptom to root cause.→
- DHCP monitoring — lease statistics, syslog export, Prometheus exporterHow to monitor DHCP services on VyOS 1.5 LTS for capacity, performance, and security. Lease utilisation metrics, syslog export to a central log server, the Kea statistics socket, the Prometheus exporter, alerting on pool exhaustion.→
Part XLVII
Management Plane Hardening
6 checks
- SSH hardening — key-only auth, port, listen-address, mgmt VRFHow to harden SSH on VyOS 1.5 LTS. Disable password authentication, enforce key-only auth, move off port 22, bind to a management VRF, restrict to operator subnets, and the production failure modes where the operator locks themselves out.→
- HTTP API authentication — keys, localhost binding, TLS, the gRPC alternativeHow VyOS 1.5 LTS exposes an HTTP API for automation. API key authentication, the localhost binding for local automation, the TLS configuration for remote automation, the rate-limit and audit-log controls, and the gRPC alternative for high-throughput automation.→
- Source restrictions — listen-address, allow-client, and the firewall input chainHow to restrict the management plane to known source IPs on VyOS 1.5 LTS. Which layer actually filters by client address (the firewall input chain and `service https allow-client`), why the SSH daemon has no source allow-list of its own, what `dynamic-protection` does instead, and the production failure modes where over-restriction locks the operator out.→
- Out-of-band access — OOB management VRF, console server, IPMI, the lockout safety netHow to design and operate an out-of-band (OOB) management plane on VyOS 1.5 LTS. OOB management network, console server, IPMI, the lockout recovery procedure, the OOB-vs-production separation, and the production failure modes where OOB access is missing or broken.→
- User roles — RBAC, privilege levels, the role-per-concern patternHow to implement role-based access control on VyOS 1.5 LTS. The built-in roles (admin, operator, disable), custom user roles with the `set system login user` tree, the privilege levels for read-only vs full-access, the principle of least privilege, and the production failure modes where role misconfigurations lock the operator out.→
- PKI and certificate rotation — x509, ACME, Let's Encrypt, the rotation scheduleHow to operate a PKI on VyOS 1.5 LTS for the HTTP API, IPsec, WireGuard, and the OpenVPN services. Self-signed certificates, internal CA, ACME / Let's Encrypt integration, certificate rotation schedules, the expiry failure mode, and the production discipline of pre-expiry rotation.→
Part XLVIII
Logging and Remote Syslog
6 checks
- Local logging — rsyslog, journald, logrotate, retentionHow to configure local logging on VyOS 1.5 LTS. The rsyslog daemon, the journald journal, the logrotate policy, the disk-space failure mode, and the production discipline of bounded retention.→
- Routing daemon logs — zebra, bgpd, ospfd, the log-level configurationHow to configure and interpret logs from FRRouting routing daemons on VyOS 1.5 LTS. zebra, bgpd, ospfd, ripd, the log-level configuration, the log file location, and the production failure modes where routing daemons silently fail.→
- Firewall logs — default-log, the prefix VyOS generates, and reading the entriesHow to enable and interpret firewall logs on VyOS 1.5 LTS. The default-log directive on the 1.4+ firewall tree, the log prefix VyOS generates for you (and why there is no log-prefix option to set), log-options level and group, the log interpretation, and the production failure modes where the firewall logs nothing or logs everything.→
- VPN logs — IKE logs, charon, WireGuard, the diagnostic captureHow to enable and interpret VPN logs on VyOS 1.5 LTS. IPsec IKE logs (charon), WireGuard wg show and wg-quick, the log interpretation, the diagnostic packet capture, and the production failure modes where the VPN tunnel silently fails.→
- Remote syslog — RFC 5425 TLS syslog, the central server, the failoverHow to configure remote syslog export from VyOS 1.5 LTS to a central server. Plain syslog (UDP/TCP), RFC 5425 TLS syslog, the failover configuration, the log volume tuning, and the production failure modes where logs are lost.→
- Log validation — log integrity, SIEM ingestion, retention policyHow to validate log integrity, configure SIEM ingestion, and operate the retention policy on VyOS 1.5 LTS. Hash chaining for tamper detection, SIEM forwarding, the retention / archival policy, and the production failure modes where logs are tampered with or lost.→
Part XLIX
Monitoring and Observability Integration
6 checks
- Interface metrics — SNMP, NETCONF, gNMI, and the Prometheus exporterVyOS 1.5 LTS interface metrics: what to collect (octets, packets, errors, discards, per-queue, per-CPU), how to collect it (SNMPv2c/v3, NETCONF YANG, gNMI telemetry, Prometheus node_exporter textfile), and the operational discipline that prevents the metrics layer from becoming a flooding source itself.→
- BGP telemetry — BMP, RIB monitoring, and FRR streaming stateVyOS 1.5 LTS BGP telemetry: what to monitor (session state, RIB count, update bursts, prefix counters, route churn), how to collect it (BGP Monitoring Protocol, FRR's northbound telemetry, gNMI, SNMP BGP4-MIB), and the operational discipline that turns BGP into evidence rather than a guess.→
- OSPF telemetry — LSDB export, SPF runtimes, and FRR per-LSA monitoringVyOS 1.5 LTS OSPF telemetry: what to monitor (LSDB size, SPF runtimes, LSA counts, neighbour state, area topology), how to collect it (FRR's `show ip ospf json`, gNMI telemetry, SNMP OSPF-MIB, custom textfile collector), and the operational discipline that turns OSPF into evidence rather than a guess.→
- VRRP telemetry — master/backup state, gratuitous ARP, and failover event auditingVyOS 1.5 LTS VRRP telemetry: what to monitor (VRRP state, master/backup transitions, advertisement intervals, gratuitous ARP, tracked-interface state), how to collect it (keepalived's VRRP state, gNMI, SNMP, custom textfile collector), and the operational discipline that turns VRRP failover into evidence rather than a guess.→
- System metrics — CPU, memory, disk, temperature, and the prometheus-vyos-exporterVyOS 1.5 LTS system metrics: what to monitor (CPU per-core, memory, swap, disk usage, temperature, sensor health, OOM events, file descriptor count), how to collect it (node_exporter, SNMP HOST-RESOURCES-MIB, gNMI, custom textfile collector), and the operational discipline that turns system metrics into evidence rather than a guess.→
- Prometheus exporters — textfile collector, custom scripts, and the SNMP exporterVyOS 1.5 LTS Prometheus exporters: the textfile collector pattern for derived metrics, custom Python/Bash exporters for protocol-specific state, the SNMP exporter for legacy NMS integration, and the production discipline that turns ad-hoc metrics into a maintainable observability layer.→
Part L
Performance Troubleshooting
6 checks
- CPU saturation — top, mpstat, softirq vs hardirq vs userspace, Linux schedulerDiagnosing VyOS 1.5 LTS CPU saturation: distinguishing userspace CPU (FRR zebra, bgpd, ospfd) from softirq CPU (kernel NAPI processing) from hardirq CPU (NIC interrupts), the per-CPU view, the load average fallacy, and the canonical fixes (interrupt affinity, RSS, NUMA, queue discipline).→
- Interrupt affinity — /proc/irq, RSS, NUMA, IRQBALANCE_BANNED_CPUSDistributing NIC interrupts across CPU cores on VyOS 1.5 LTS: /proc/irq/<n>/smp_affinity, Receive Side Scaling (ethtool -L/-X), NUMA-pinned NICs and the first-touch locality rule, irqbalance configuration, and the IRQBALANCE_BANNED_CPUS discipline that prevents automatic rebalancing from undoing deliberate pinning.→
- Packet drops — softnet_stat, per-NIC counters, drop reasonsDiagnosing packet drops on VyOS 1.5 LTS: /proc/net/softnet_stat per-CPU queue depth and dropped counts, /sys/class/net/<nic>/statistics for rx_dropped, tx_dropped, rx_missed_errors, the kernel drop reasons (backlog full, headroom exhausted, socket buffer full), and the production-grade fix for each.→
- Crypto performance — AES-NI offload, IPsec throughput, kTLS, single-core bottleneckDiagnosing VyOS 1.5 LTS crypto performance: AES-NI hardware offload detection (cat /proc/cpuinfo flags), IPsec throughput single-core bottleneck (strongSwan VTI mode), kernel TLS (kTLS) for HTTPS/TLS termination, WireGuard's modern cryptography and CPU-bound profile, and the canonical fix for each.→
- Route churn — FRR zebra CPU, route-flap, iBGP convergence, OSPF SPFDiagnosing VyOS 1.5 LTS route churn: FRR zebra CPU saturation from BGP update bursts, iBGP convergence storms, OSPF SPF thrash, route-flap propagation across IGPs, the route-map dampening and stub-area primitives that bound the blast radius, and the canonical fix for each churn source.→
- Performance baselines — pbench, record baselines, alert on deviation, golden imageBuilding VyOS 1.5 LTS performance baselines: capturing baseline CPU, memory, throughput, latency, and route-convergence metrics with pbench and sysstat, golden-image comparison, alert thresholds for deviation, and the production discipline that turns baselines into an early-warning system for routing regressions.→
Part LI
MTU and Fragmentation
6 checks
- MTU basics — 1500 default, jumbo 9000, 802.1Q tag 4 bytes, IPv6 minimum 1280VyOS 1.5 LTS MTU fundamentals: 1500-byte Ethernet default, 9000-byte jumbo frames for data-centre backbones, 802.1Q VLAN tag's 4-byte overhead, IPv6's 1280-byte minimum MTU floor, the layer-2 vs layer-3 MTU distinction (L2 includes FCS), and the canonical VyOS interface MTU configuration.→
- Tunnel overhead — WireGuard 32-80, IPsec 50-66, GRE 24, VXLAN 50Calculating tunnel overhead on VyOS 1.5 LTS: WireGuard's 32-byte (IPv4) or 80-byte (IPv6) overhead, IPsec's 50-66-byte ESP overhead (AES-GCM, SHA, anti-replay), GRE's 24-byte IP+GRE overhead, VXLAN's 50-byte UDP+VXLAN overhead, and the canonical MTU calculations for each tunnel type.→
- PMTUD — RFC 1191, RFC 8201, ICMP Frag Needed, black hole detection, MTU 1280 floorVyOS 1.5 LTS Path MTU Discovery: RFC 1191 (IPv4) and RFC 8201 (IPv6), ICMP Fragment Needed messages, the 'PMTUD black hole' failure mode when ICMP is filtered, the 1280-byte MTU floor for IPv6, the Don't Fragment flag, and the production diagnostic for path-MTU failures.→
- MSS clamping — ip adjust-mss, MSS = MTU - 40, clamp-mss-to-pmtu, and which interface to clamp onVyOS 1.5 LTS MSS clamping: the TCP MSS option, MSS = MTU - 40 (TCP 20 + IP 20), the per-interface ip adjust-mss and ipv6 adjust-mss nodes that replaced the pre-1.4 firewall arrangement, when to clamp instead of relying on PMTUD, and how to prove the clamp is working on the wire.→
- MTU and fragmentation troubleshoot — ping -M do -s, tracepath, ICMP filteringDiagnosing VyOS 1.5 LTS MTU and fragmentation failures: ping -M do -s for path-MTU probing, tracepath for per-hop MTU discovery, identifying ICMP filtering that breaks PMTUD, the ping-dont-fragment fragmentation test, and the production diagnostic for end-to-end MTU mismatches.→
- MTU validation — end-to-end verification, jumbo on all path, sub-interface alignmentEnd-to-end MTU validation on VyOS 1.5 LTS: validating the path MTU before deployment, jumbo-frame verification across all interfaces in the path, 802.1Q sub-interface alignment, tunnel inner MTU validation, and the production discipline that prevents MTU mismatches from reaching users.→
Part LII
Troubleshooting Methodology
6 checks
- Define and scope — ticket triage, scope boundaries, who is affectedVyOS 1.5 LTS troubleshooting methodology — define and scope: ticket triage (severity, urgency, priority), scope boundaries (single user, site, network-wide), who is affected (impact assessment), the difference between symptom and scope, and the production discipline that prevents scope confusion.→
- Evidence first — collect before changing, write down symptoms, no action without dataVyOS 1.5 LTS troubleshooting methodology — evidence first: collect before changing (logs, counters, state), write down symptoms before testing hypotheses, no action without data, the evidence-first checklist for routing protocols, and the production discipline that prevents evidence-less changes.→
- Hypothesis-driven — generate hypotheses, test each, bisection, post-mortemVyOS 1.5 LTS troubleshooting methodology — hypothesis-driven: generate hypotheses from evidence, test each hypothesis with a single change, bisection to narrow the scope, the post-mortem discipline, and the production workflow that converts evidence into a defensible root-cause analysis.→
- Subsystem by subsystem — kernel, FRR, firewall, interface, application, isolate layerVyOS 1.5 LTS troubleshooting methodology — subsystem by subsystem: kernel (network stack, routing table, FIB), FRR (zebra, bgpd, ospfd), firewall (nftables, conntrack), interface (link state, MTU, counters), application (SSH, BGP, OSPF, IPsec), and the discipline of isolating the failing layer.→
- Return-path — forward and reverse, asymmetric routing, return-path sanityVyOS 1.5 LTS troubleshooting methodology — return-path verification: forward path vs reverse path, asymmetric routing, what actually drops the reverse packet on Linux, the return-path sanity check, and the production discipline for bidirectional verification.→
- Troubleshooting anti-patterns — reboot before evidence, blame the firewall, cargo-cult configsVyOS 1.5 LTS troubleshooting anti-patterns to avoid: rebooting before evidence, blaming the firewall without verification, cargo-cult configurations copied from the internet without understanding, escalation without a clear symptom, change-and-pray, and the production discipline that prevents these anti-patterns.→
Part LIII
Security Hardening
6 checks
- Routing protocol authentication — what VyOS actually exposes, and what it does notRouting-protocol authentication on VyOS 1.5 LTS / FRR 10.x: the OSPF, BGP, RIP and IS-IS nodes the CLI really has, the key-id overlap that lets an OSPF key roll without dropping the adjacency, the absence of HMAC-SHA and TCP-AO in the VyOS tree and what to do about it, and the production failure modes where a mismatch produces a silent outage with no error on anyone's terminal.→
- max-prefix as a security control — bounding a peer, and the outage it trades forPrefix limits as a control-plane security control on VyOS 1.5 LTS: what `maximum-prefix` under a neighbour address family actually bounds, the availability it trades away because VyOS exposes no warning-only or restart node, why OSPF and IS-IS have no equivalent, and the production failure modes of a limit set too tight or too loose.→
- Prefix filtering — prefix-list, AS-path, RPKI invalid, and the leak firewallHow prefix filtering protects a BGP speaker from receiving or advertising unwanted prefixes. The prefix-list for IP-range matching, the AS-path filter for AS-path matching, the integration with RPKI for cryptographic validation, and the production patterns where these combine to form a leak firewall.→
- RPKI — Route Origin Authorisation, validation cache, and route validationHow RPKI (Resource Public Key Infrastructure) cryptographically validates the origin AS of a BGP route. The ROA structure, the validator cache, the cache-to-router protocol (RTR), and the production deployment pattern where RPKI invalid drop is the cryptographic complement to prefix-list filtering.→
- Control-plane protection — the input chain, BGP TTL security (GTSM), and authentication on every peerHow to protect the router's control plane from being overwhelmed. VyOS has no CoPP subsystem; the control plane is the firewall ipv4 input filter chain plus firewall global-options. GTSM (RFC 5082) rejects BGP packets from peers that are not the configured number of hops away, and authentication on every peer rejects packets from anyone without the key.→
- Router hardening checklist — configuration review, OOB management, audit logThe production router hardening checklist: the configuration review (every peer has authentication, every interface has a description, every CoPP rule is in place), the out-of-band management path (serial console, IPMI, dedicated management VLAN), and the audit log (configuration changes, authentication attempts, system events).→
Part LIV
API and Automation
6 checks
- VyOS HTTP API — the /configure endpoint, key authentication, and one commit per requestHow the VyOS HTTP API exposes the router over HTTPS: the service https api tree and its keys, the key-in-the-request authentication the API actually uses, the /configure endpoint that commits on every call, /retrieve for configuration and /show for operational output, and the production failure modes of driving a router this way.→
- VyOS Ansible integration — vyos.vyos collection over network_cli, modules, idempotent playbooksHow Ansible drives VyOS through the vyos.vyos collection. The ansible.netcommon.network_cli SSH connection the collection actually uses, the vyos_config module for declarative configuration, vyos_command for operational commands, the match-line idempotency model, and the production failure modes where an abbreviated command produces a playbook that reports changed on every run.→
- Configuration as code — Git repository, Jinja2 templates, render and applyHow configuration as code works on VyOS 1.5 LTS: a Git repository as the source of truth, Jinja2 templates that render the router configuration from variables, the render-and-apply pipeline that pushes the rendered configuration to the router, and the production failure modes where the render is correct but the apply is wrong.→
- Automated validation — pre-commit hooks, smoke tests, rollback on failureHow automated validation protects a configuration-as-code pipeline: pre-commit hooks catch errors before the commit, smoke tests verify the change after the apply, and rollback-on-failure ensures the router returns to the previous state if any check fails. The production failure modes where validation is missing or skipped.→
- Change management — ticket, peer review, audit log, post-deploy verificationHow change management wraps the configuration-as-code pipeline: every change is associated with a ticket, peer-reviewed before apply, audited in the commit log, and verified after deploy. The production discipline that prevents the "I never made that change" defence in the post-incident review.→
- Automation anti-patterns — skip review, run-and-pray, no rollback pathThe seven automation anti-patterns that consistently produce production outages: skip review, run-and-pray, no rollback path, no validation, manual override, undocumented change, and untested playbook. The discipline that catches each anti-pattern and the alternative production pattern.→
Part LV
Backup, Restore, Disaster Recovery
6 checks
- Saved configuration — /config/config.boot, scp, off-box copy, versioningHow VyOS 1.5 LTS persists the configuration across reboot. The /config/config.boot file, the difference between commit and save, the off-box copy via scp, and the version-controlled backup that the operator maintains alongside the router's local file.→
- Remote backup — cron + rsync, version control commit, S3 bucketHow to back up the VyOS 1.5 LTS configuration to a remote system: cron-driven rsync to an off-box file server, Git commits to a version control repository, and S3 bucket archival for off-site disaster recovery. The production patterns that ensure every save is backed up to three locations.→
- Restore onto the same appliance — load saved, verify, commit, saveHow to restore a saved configuration onto the same VyOS 1.5 LTS router. The load command, the verify step, the commit, and the save. The production scenarios where a same-appliance restore is needed: configuration corruption, accidental deletion, or rollback to a known-good state.→
- Restore onto a different appliance — hardware replacement, configuration migration, IP changesHow to restore a VyOS 1.5 LTS configuration onto a different router. The hardware replacement scenario (RMA), the configuration migration scenario (a new router takes over the old one's role), the IP and interface changes that may be required, and the production failure modes where the migration goes wrong.→
- Full router loss — RMA, replacement, restore, verify adjacencyHow to recover from a complete router loss: the RMA process, the replacement router, the configuration restore from the Git repository, the verification of routing-protocol adjacency, and the production failure modes where the recovery goes wrong. The end-to-end disaster recovery procedure.→
- DR validation — quarterly DR drill, full restore, scenario testHow to validate the disaster recovery procedure on a regular schedule. The quarterly DR drill, the full restore from the Git repository, the scenario test (e.g. router loss, RMA, configuration restore), and the production failure modes where the DR procedure has never been tested.→
Part LVI
Software Images and Production Upgrades
6 checks
- Image management — dual-image model, add system image, alt slotHow VyOS 1.5 LTS manages system images with the dual-image model. The primary boot slot, the alternate boot slot, the add system image command, the boot behaviour on upgrade failure, and the production failure modes where the dual-image rollback does not fire.→
- Rolling upgrade — dual-router topology, upgrade one at a time, verify trafficHow to perform a rolling upgrade on a VyOS 1.5 LTS deployment: the dual-router topology (edge-01 and edge-02), the procedure of upgrading one router at a time, the verification of traffic on the upgraded router before proceeding, and the production failure modes where the rolling upgrade is interrupted.→
- FRR compatibility — what an FRR version bump changes on VyOS, and what it does notFRR compatibility on VyOS 1.5 LTS: why an FRR syntax change never reaches your config.boot, what a VyOS config-migration script actually rewrites, the three kinds of FRR change that are visible to an operator, and the upgrade capture-and-diff procedure that catches all three.→
- Upgrade validation — lab test, staged rollout, monitoringHow to validate a VyOS 1.5 LTS upgrade before deploying to production. The lab test (boot the new image, verify the configuration, test the routing protocols), the staged rollout (deploy to a subset of routers first), the production monitoring (verify the upgrade did not regress any behaviour), and the production failure modes where the validation is missing.→
- Upgrade rollback — dual-image, automatic, manual, verify alt bootHow to roll back a VyOS 1.5 LTS upgrade when the new image produces a regression. The dual-image automatic rollback (bootloader falls back to the alternate slot), the manual rollback (set the default boot to the previous image), the verification that the alternate boot is working, and the production failure modes where the rollback does not fire.→
- Upgrade anti-patterns — skip lab test, no rollback, double-firmware upgradeThe seven upgrade anti-patterns that consistently produce production outages: skip lab test, no rollback path, double-firmware upgrade, no staged rollout, no monitoring, undocumented upgrade, and untested playbook. The discipline that catches each anti-pattern and the production alternative.→
Part LVII
Production Reference Architecture
6 checks
- Reference topology — a complete dual-DC, dual-router VyOS production estateThe RunBook Academy dual-DC, dual-router reference topology: two sites, two routers per site, two ISPs, BGP multihoming, OSPF underlay, VRF segmentation, WireGuard and IPsec VPN, VRRP for first-hop redundancy, and the monitoring, backup, and DR layers that turn the topology into a production estate.→
- Reference rationale — design decisions, trade-offs, and why the topology is shaped this wayThe design rationale for the RunBook Academy dual-DC, dual-router reference topology: why dual-DC instead of single-DC, why dual-router instead of single-router, why BGP multihoming instead of single-ISP, why WireGuard plus IPsec instead of one VPN technology, why VRRP for first-hop redundancy, and the production trade-offs of every choice.→
- Reference failure domains — blast radius, isolation, and failover for every layerThe blast radius and isolation discipline for the RunBook Academy dual-DC, dual-router reference topology: failure domain per layer (underlay, IGP, BGP, VPN, services, monitoring, backup), isolation mechanism per layer, failover mechanism per layer, and the production discipline that prevents a failure in one layer from cascading to another.→
- Reference monitoring — Prometheus, Grafana, Loki, and Tempo for the production estateThe reference monitoring stack for the RunBook Academy dual-DC, dual-router production estate: Prometheus for metrics, Grafana for visualisation, Loki for logs, Tempo for traces, Alertmanager for alerting, and the production discipline that turns observability into evidence rather than a guess.→
- Reference DR — backup strategy, RTO, RPO, and quarterly drillsThe reference disaster recovery plan for the RunBook Academy dual-DC, dual-router production estate: backup strategy (configuration, image, offsite), RTO and RPO targets, quarterly DR drills, the recovery runbook, and the production discipline that ensures the DR plan works when it is needed.→
- Reference validation — end-to-end smoke tests, change windows, and the rollout disciplineThe reference validation discipline for the RunBook Academy dual-DC, dual-router production estate: end-to-end smoke tests (per layer, per failure scenario), change windows (planned, emergency, freeze), the rollout discipline (canary, fleet-wide, rollback), and the production discipline that ensures every change is validated before it affects production.→