# Drawing your network > Drawing a finished network sweep as a blueprint, with a Physical view of the network devices and their links, a Routing view of BGP, OSPF and IS-IS sessions and route next hops, a stratum per drawn device, and redrawing after later sweeps. Blueprintr draws a finished network sweep as a blueprint: the switches, routers, firewalls and other network devices the sweep reached, the links between them with their ports where there is room to show them, and how traffic is routed between them. The drawing is a Continuum tab, like a [Continuum Cloud](/foliums/blueprintr-user-guide/continuum/continuum-cloud) diagram, so it has the same **View** menu, a stratum for each drawn device, and the same rules when it is redrawn: your layout is kept, what changed is marked, and new devices wait for you to add them. Blueprintr draws from the sweep results it already holds, so drawing works with every agent, including an agent on 0.2.0 configured from its own file. What the Routing view can show depends on what the agent reads, as [The Routing view](#the-routing-view) describes. ## Draw a sweep > [!STEPS] > > === Open a finished sweep > > In **Settings → Continuum**, under **Network sweeps**, choose **View results** > on a sweep that has finished. A sweep that was cancelled or stopped partway > can be drawn too, if it found at least one device. > > === Choose Draw this network > > The button is in the header of the results page. > > === Choose where it goes > > **A new draft blueprint**, titled after the agent unless you type a title, or > **Update** one of this agent's existing drawings that you can edit. The five > drawn from the newest sweeps are offered. > > === Choose Draw > > Blueprintr says what it drew, for example "Drew 6 devices, 8 links and 16 > routing sessions." **Open the blueprint** opens it. A new drawing opens in the > editor as a private draft. Until you publish it, only people who can edit the > organisation's or team's blueprints can open it. You need `continuum_integrations.manage` on the organisation or team that owns the agent, and that organisation needs an Enterprise plan, as for starting a sweep. A new blueprint for an organisation also needs you to be one of its owners or admins, and one for a team needs you to be a member of it. Updating a drawing needs edit access to its blueprint. Your account needs a username, because the blueprint records its maintainer. Each person can start three drawings a minute. When the sweep did not finish, the panel says so before you draw. A new drawing then holds only the devices the sweep reached, and an update leaves the devices it did not reach as they were. ## The views The tab's **View** menu swaps between these. A view adds or removes lines; the devices stay where they are. | View | Shows | | --- | --- | | **Physical** | The default. The drawn devices and the LLDP and CDP links between them, grouped into sites. | | **Routing** | The same devices with their routing sessions, or the route next hops between them, drawn along the cables they run over. See [The Routing view](#the-routing-view). | | **Route next hops** | Offered when some device reported routing sessions. Every device's route next hops, as dotted arrows. | | **Management links** | Offered when the sweep found links on a management network. Those links, dashed grey. | A line under the tab's header says which sweep the drawing came from and what it holds, for example "Drawn from the sweep of 2026-09-26 09:14 UTC by agent lab-agent. 6 devices, 8 links, 16 BGP sessions, 12 route next hops, 6 management links." It adds a sentence only when one applies: that the sweep did not finish, that the agent reads no routing sessions, or how many devices were left off. Editors also get **See the sweep**. ## What is drawn ### Devices Each device is drawn with an icon for its role, taken from the class the agent gave it: | Role | Devices | | --- | --- | | Router | Routers | | Layer 3 switch | Switches that route | | Switch | Switches | | Firewall | Firewalls | | Load balancer | F5 and Citrix devices, the vendors the agent can tell apart as load balancers | | Wireless | Access points and wireless controllers | | Server | Servers, hypervisors, storage and other hosts | | Network device | Anything else | - Routers, switches, firewalls, load balancers and wireless devices are always drawn. A server or other device is drawn when an LLDP or CDP link joins it to a drawn device, or when it reports a routing session, as a route server or FRR on Linux does. The rest are counted in the line under the header, for example "14 endpoints with no link to a network device are not drawn." - An Arista device that an agent before 0.3.0 classed as a server, as it does an older cEOS image that reports its Linux kernel, is drawn as a layer 3 switch. - A neighbour that LLDP or CDP reported but the sweep did not reach, such as a switch outside your ranges, is drawn as an unswept neighbour when it reports itself as a router, switch or access point. Phones and computers heard over LLDP are not drawn. - A BGP peer that no swept device matches is drawn as a BGP peer, labelled with its AS number and address. - A device that answered on several addresses is drawn once. - A device already in the drawing that a later sweep did not reach, but that its neighbours still hear over LLDP or CDP or still hold sessions with, is not drawn a second time: those links and sessions stay with the device already on the canvas. A drawing holds at most 300 swept devices, 100 unswept neighbours, 32 BGP peers outside the sweep and 24 site frames. Over the device limit, routers are kept first, then firewalls, load balancers, layer 3 switches, switches, wireless devices, servers and anything else, and within a role the devices with the most links. The line under the header counts the devices left off, the panel lists anything else left off when you draw, and every device stays on the sweep's results page. ### Links One line joins each pair of linked devices, however many cables and whichever protocol reported them. Two or more cables between the same pair are labelled "x2", "x3" and so on. The layout puts cores and spines at the top and access switches below them, and puts two devices of the same role that are cabled together and share a neighbour, such as a core pair or an MLAG pair, side by side. A line shows its port names, up to three per end and then "+2" and so on, only where they can be read: at an end whose side of the device has no other line, and where the name does not land on another label, a device or its caption. On a short line only the lower end's port is named. In a fabric, where every device has several lines on each side, no port names are shown. Every port is listed in the device's stratum, under its neighbours. Links between management ports, which LLDP hears on a shared management network such as a lab's management bridge, are left out of **Physical** and drawn in **Management links**. Agent 0.3.0 marks them; from an older agent, a link is a management link when the ports at both ends are named as management ports. ### Sites Devices are grouped into a frame per site, taken from each device's SNMP location (`sysLocation`): the text before the first comma, semicolon or pipe, compared without regard to case. `London DC1, rack 14` and `london dc1; row B` are the same site. Frames are drawn only when at least two sites each hold at least two drawn devices. A device with no location, or alone at its site, is drawn outside the frames. ### Strata Every drawn device gets a stratum, with what the device reported: its role, vendor, model, operating system, version, location and management address; its addresses; its interfaces (64 rows, then a count of the rest); its neighbours; its BGP sessions, OSPF neighbours and IS-IS adjacencies; and a summary of its routes by protocol. Connected devices and routing peers link to their own strata. Each stratum ends "Reported by the Continuum Local agent in a network sweep. Blueprintr does not change anything on this device." ## The Routing view What **Routing** shows depends on whether the agent reads routing sessions. **With routing sessions**, from an agent on 0.3.0 or later with the `bgp`, `ospf` and `isis` collectors on, it draws one line per pair of devices for each protocol: | Line | Label | Colour | | --- | --- | --- | | BGP | `eBGP AS65001 to AS65100` or `iBGP AS65000`, then `· EVPN` when either end reports the L2VPN EVPN address family, and `· 2 sessions` when there is more than one | Blue for eBGP, violet for iBGP | | OSPF | `OSPF area 0.0.0.0`, listing each area when there are several | Green | | IS-IS | `IS-IS L2`, `IS-IS L1` or `IS-IS L1L2` | Amber | A session that is not up is drawn dashed red and labelled `· not established`, `· not full` or `· not up`. An OSPF neighbour in the two-way state, which is normal between two routers that are not the designated router, is labelled `· 2-way`. Route next hops that no session explains, such as a static route, are added as dotted grey arrows. Blueprintr works out which device is at the far end of each session from every device in the sweep: first from a session both ends report, then from the router ID or IS-IS system ID, then from the peer's address, and for an unnumbered session from the LLDP link on the same interface. Each BGP session in a stratum says how it was matched. A BGP peer that matches no swept device is drawn outside the sweep. A session or next hop between two devices that are cabled together is drawn along the cable, in place of it, so **Routing** keeps the layout of **Physical**. Next hops both ways over one cable read as one line with an arrow at each end. Where a label has no room, it is shortened to `eBGP 65001 to 65100 · EVPN` or `eBGP · EVPN`, keeping `· not established` and the other states; every session is listed in full in the stratum of each device that reports it. **Without routing sessions**, from agent 0.2.0, or when no device reported any, **Routing** draws each device's route next hops: a dotted arrow from each device to each device that is a next hop in its routing table, labelled with the protocols and how many prefixes, such as `BGP · 12 prefixes · default`. Connected and local routes are left out. Agent 0.2.0 reads IPv4 routes only; 0.3.0 reads IPv4 and IPv6. When the view shows next hops only, the line under the header says why. The agent reads at most 5,000 routes per device, so a router with a full internet table shows the next hops of the routes it read. Which platforms serve routing sessions over SNMP, and what they need turned on, is under [Routing sessions](/foliums/blueprintr-user-guide/continuum/local-agent/network-discovery#routing-sessions). ## Redrawing - **Redraw from latest sweep**, in the tab's settings cog, draws this agent's newest finished sweep. - **Draw this network** on any sweep's results page, then **Update** and the drawing, draws that sweep over it. - Blueprintr checks every 15 minutes, and redraws a drawing when its agent has a newer finished sweep of the same ranges, up to five drawings each time. A scheduled sweep therefore usually has its drawing redrawn within 15 minutes of finishing, with no one pressing anything. A sweep that cannot be drawn is tried again after an hour and after four more hours, then not until a newer sweep finishes. A redraw keeps every device where you put it and follows the rules in [Keeping diagrams true](/foliums/blueprintr-user-guide/continuum/keeping-diagrams-true): a new device waits on the notes layer, outlined green, until you promote it, and a device the sweep no longer finds is outlined dashed grey, then red. The change bar lists what changed. A sweep of other ranges, or one that did not finish, is never picked automatically. Drawn by hand, it adds and updates devices and marks none as missing. > [!NOTE] > A device swept by agent 0.3.0 is identified by its SNMP engine ID or LLDP > chassis ID where it reports one, and a device swept by 0.2.0 by its SNMP > system name and object ID (`sysName` and `sysObjectID`). A redraw keeps the > identity a device was first drawn with while it reports the same name and > object ID, so upgrading the agent from 0.2 to 0.3.0 does not mark those devices > as missing. A device renamed at the same time, or one with no name or a default > name such as `localhost`, is drawn again as new: promote it and delete the > shape marked missing. Restoring an older version of a blueprint that holds a drawing is refused, as for every Continuum diagram. See [Version restore is refused](/foliums/blueprintr-user-guide/continuum/keeping-diagrams-true#version-restore-is-refused). ## Who sees a drawing A drawing is part of its blueprint. Everyone who can read the blueprint sees each drawn device's name, location, management address, interfaces and addresses, the links between devices, and their routing, in the canvas and in the strata. A new drawing is a private draft until you publish it; check what it shows before you publish it to a wider audience. A drawing never holds ARP or forwarding table entries, a device's contact field or anything about the SNMP credentials. It stays until you remove its tab or delete its blueprint, while the sweep it came from is kept for 90 days, as [What Blueprintr keeps](/foliums/blueprintr-user-guide/continuum/local-agent/network-discovery#what-blueprintr-keeps) says. ## When a drawing is refused | The message says | What to do | | --- | --- | | This sweep is still running, failed, or found no devices, so there is nothing to draw. | Wait for the sweep to finish, or run a new one. | | The sweep found no network devices to draw. Its devices are listed on the sweep page. | The sweep found only servers, printers and other endpoints with no link to a network device. Check that LLDP or CDP is on for the ports between them, or widen the ranges to take in the switches. | | This network has too many links between its devices to draw as one diagram. | The drawing would hold more than 800 links, or links that skip across many tiers of devices, as a full mesh of 20 or more routers does. Sweep a smaller range and draw that. | | The agent that drew this network was removed, so it cannot be redrawn. | Draw a sweep from another agent into a new blueprint. | | Only an owner or admin of this organization can create a blueprint for it. | Ask an owner or admin to draw it, or update a drawing you can edit. | | Only a member of this team can create a blueprint for it. | Ask a member of the team to draw it, or update a drawing you can edit. | | You can't edit the blueprint this drawing is on, so it can't be updated from here. | Ask for edit access to the blueprint, or draw into a new one. | | Your account needs a username before it can own a blueprint. | Set a username in your profile settings. | | You have started several drawings in the last minute. | Wait a minute. | | The network could not be drawn. Nothing was changed. | Try again, and contact support if it keeps failing. | A plan that has lapsed, a storage limit that is full, or a blueprint at its tab limit refuses a drawing with the same message it gives anywhere else. ## Limits - One agent per drawing. A drawing takes no Continuum Cloud scopes. - Drawings start from a sweep's results page. The blueprint wizard, AI Assist and the MCP server cannot start one. - Only the default SNMP context of each device is read, so routing in other VRFs is not drawn unless the vendor's MIB lists every instance in it. - VXLAN tunnel endpoints, VNIs and EVPN routes are not drawn. - At most 800 links per drawing, and no mesh whose links skip across many tiers of devices (a full mesh of 20 routers is refused; one of 12 is drawn). - A drawing with more than 96 lines, or with a device that has more than 24, keeps the layout's own routes for its lines, which may run alongside each other. Lines a redraw adds to such a drawing are drawn straight until it is laid out again. - Routing lines with no cable under them, such as a session across a fabric, are routed around the devices only when there are at most 40 of them and their combined length is at most 30,000 pixels. Otherwise they are drawn as curves across the canvas.