Write down how the network forwards, not just what is plugged in.

Two ideas run through the whole module. A prefix list, a community list, an AS-path list, a routing policy, a keychain or a BFD profile is named once and used on every router that needs it. A static route, a BGP session or an OSPF interface belongs to one device or one virtual machine, and is scoped to that box's site exactly as the box is.

That split is what keeps a fabric describable. The SPINES peer group is written once and applies on every leaf; the session that uses it is a fact about one leaf.

An instance is router bgp on a device, one per table: its AS, its VRF (blank for the global table), router ID, cluster ID, graceful restart and whether BFD is the default for its neighbours. Each instance carries its address families, from ipv4-unicast through l2vpn-evpn, each with the networks it originates, its maximum paths, an import and an export policy, and what it redistributes.

A peer group is the neighbour settings named once: remote AS as a number or as *external* / *internal* for unnumbered fabrics, policies, BFD, multihop TTL, next-hop self, route-reflector client, timers and the keychain. A session names its far end by address or by interface, and inherits the group.

A session is one object with two ends, so it reads the same whichever device you open it from, and the topology map can draw it as a line between the two cards rather than a note on one of them.

The interior protocols are modelled the same way: an instance on the device, its areas or levels, and the interfaces that run it with their cost, type, timers and authentication. An interface's Routing card shows what it participates in without leaving the interface.

A leaf gets a VTEP with its source interface and the VNIs it carries, L2 VNIs bound to VLANs and an L3 VNI bound to a VRF, with anycast gateways where you want them. Ethernet segments cover multihoming, with their ESI and the interfaces in them.

Because the overlay is modelled rather than described, a fabric's leaves and spines can be rendered from the same template, and the map can draw the sessions that hold it together.

Everything modelled here reaches a device's config template as a routing block, so a single template renders the whole device in whatever vendor syntax you write. Danbyte renders what is modelled; the template stays yours.

Two complete worked templates, NX-OS style and FRR, ship in the docs, rendered against a leaf and spine fabric you can seed in one command.

The topology Diagram draws BGP sessions as their own line family, which you can hide like any other. The layout still follows cables, so the sessions are drawn over the physical shape rather than rearranging it.

A cloud router is a routing device that happens to be a VM, so virtual machines carry the same routing objects as hardware: instances, sessions, IGPs and static routes. A circuit can even terminate on a VM interface, which is how a CHR, pfSense, OPNsense or VyOS edge actually ends.