Drawbridge

Connectors

Drawing a connector

Two ways:

Release over the target device to create the connector. Map underlays never take an endpoint — cabling "the world" is meaningless, and it sits under everything.

Let go over empty space and the cable asks for its device. The device picker opens where you let go, titled with where the cable came from — "New device, cabled to FW-01, from the right side" — and the cable waits there, dashed. Type a name and press Enter: the device appears at the end of the cable, the cable is drawn to it, and both come off with one ⌘Z (Ctrl+Z). Esc puts the picker away and drops the cable; the Cable tool, if it was armed, stays armed. Only things a cable can reach are offered — devices, not zones or text.

Double-click a connector to give it a midpoint label (VLAN, circuit ID, whatever the diagram needs). Interface names at the two ends (ge-0/0/1, wan1) are typed under Ends on the cable's own card — select the cable — or on a device's Cables tab, one field per port, each captioned with the device whose port it is; they are placed automatically from the route's first and last segments. Where each of them sits is adjustable in the same place, directly under the name — see The cable card and The Cables tab below.

Connector types

Every connector has one of four types, set in the inspector's Connector section:

Type What it means
Auto Routed by the engine: orthogonal, avoids devices, keeps spacing. Geometry is recomputed, never stored.
Direct A straight line between the two devices. Ignores everything in between.
Arc A smooth curve between the two devices — for when a cable should read as "around", not "through". Select an Arc and drag the handle at its crest to tune how far (and to which side) it bows; double-click the handle to go back to the automatic bow. Click a diamond on the curve to add more control points and pull the curve into any smooth shape — the same gestures as Custom, splined instead of cornered. Switching between Arc and Custom keeps the points. Parallel arcs between the same pair bow at different heights so each stays visible.
Custom Your own path, through waypoints you place.

Custom is the one case where a connector's geometry is document data. Switching a connector to Custom seeds the waypoints from its current route, so it does not jump. Then:

Waypoints are absolute positions: they move with the connector when you move the whole selection, but they do not follow a device you move on its own.

New connectors can take their link type from the two devices they join, and reuse whatever you last chose for that pair of devices. It is on by default; the switch is Auto link detection in the app menu.

Two things happen, and they compose:

Nothing else is guessed, on purpose. A trunk is a VLAN fact, a LAG an aggregation fact, IPsec an encryption fact — none of them follow from two icons, and a badge claiming a tunnel that is not there is worse than a plain line. So two switches stay a plain line until you say otherwise.

It only ever applies to a connector as it is created — never to one that already exists. Connectors you drew before, and every connector in a file you open or import, are left exactly as they are: they are your data, not a guess to be revised. An explicit choice always wins, and every effect is one undo away.

What it learns is stored in your browser, not in the drawing: files you share carry no trace of your conventions, each install remembers separately, and two people editing the same page each apply their own. Forget learned link styles, next to the switch, clears the memory — turning the switch off keeps it, in case you want it back.

Default type, and converting a page

Two buttons sit under the type buttons:

Both act on the type the current selection agrees on, so they are disabled when the selection mixes types.

Through icons

When two devices are not quite in line, an Auto connector shifts where it meets each of them so the cable can still be one straight line — but only within the middle half of the device's side. Move them further out of line than that and the cable takes a step instead, rather than creeping out to the corner of the icon.

A connector normally meets a device at the edge of its tile and passes under it. Through icons, under the type buttons, changes what happens at a device the line passes through: there the connector runs across the middle of the icon and is drawn on top, so the line visibly crosses it. The connector's own two ends — the devices where it starts and stops — keep their normal anchors on the border, exactly like any cable.

It is worth it when a device is something a run passes through rather than ends at — an internet cloud, an ISP hand-off, a patch panel in the middle of a span. Set it on the connector arriving and the one leaving, and the pair reads as one long line with the icon strung on it; where a device has more than one cable in and out, One cable below says which continues as which. Off is the default and always will be: cables belong under the shapes.

The pair does not have to run straight through. When one connector arrives from above and the other leaves to the side, the two meet in the middle of the icon and turn — and the corner is rounded there exactly as it would be anywhere else along a route, so it reads as one cable bending inside the device rather than as two lines stopping against each other. Move either device and the bend follows.

The button is a toggle, and it applies to everything selected. The device itself stays exactly as grabbable as it was — a click in the middle of a crossed icon still picks the device, not the cable.

The cable is drawn on top of the icons by default — that is what "through" means — but it is only a default: select a device and press Arrange ▸ Bring to front and the device covers the cable instead, the way a run vanishes into a cloud. Toggling Through icons resets the cable itself to its default depth.

One cable, several connectors

Drawbridge works out which connector continues into which on its own wherever there is only one possible answer — one cable in, one out, and it bends them into a single line. Where a device has two cables in and two out there is no answer to work out: which of the two arriving cables continues as which of the two leaving ones is a fact about your cabling, not about the picture.

One cable, beside Through icons, is where you say. Select two connectors that meet at a device and press it; they become one cable that flows through the icon between them. To grow it, select the cable and the next connector together — clicking any part of a cable takes the whole of it — and the button reads Add to this cable: press it and the run takes the newcomer in, keeping its name and everything else about it. A cable can run through as many devices as you like. Unlink cable, which is what the button says when the selection is the cable itself, breaks it back into separate connectors, and nothing is lost when you do.

Once linked, the parts behave as one cable:

Thickness

Every connector is drawn at the width its link type gives it — a trunk heavier than a plain cable, a fieldbus finer — and the whole drawing can be made Fine, Normal or Bold at once from Document info. Thickness, under the connector type buttons, sets one connector's width outright: drag the slider, or type a number of pixels into the box beside it. It applies to everything selected, cables and the drawn line and flow arrow alike, and a whole drag is one Undo. The box shows the width the connector is currently drawn at, so an untouched plain cable reads 1.75 and a trunk 5.5 — that is the starting point, not a value that has been set. Once you change it, a Reset button appears; pressing it gives the connector its type's width back and the button goes away again.

A width you set is absolute. Changing the document's line weight to Fine or Bold moves every connector that has no width of its own and leaves the ones you set alone — which is what a number in pixels has to mean, and what keeps the two controls from fighting. Nothing is stored for a connector you never touched, so a drawing that never used this opens and saves exactly as before; a width you do set travels with the format painter, with a copy, through collaboration and into every export, and a file saved as .drawio carries it in draw.io's own stroke width, so it opens there at the width you chose.

Two devices pushed together until they touch keep the cable between their facing sides: it becomes the joint where the two tiles meet, with nothing to draw, and its port names stay — each beside its own device. It used to loop all the way round the pair instead.

Past about 8 pixels, cables that run side by side will touch. Connectors that share a route are spread a fixed 8px apart, and that spacing does not know how wide you have drawn them — so two thick cables in the same channel meet and read as one band. It is not a limit the editor enforces, because a single thick cable on its own is often exactly what a drawing needs. If two of them merge, thin them or move one of their devices so the two routes no longer share a channel.

Width is also half of how a link type is told apart — a trunk is heavier than a plain cable before you touch anything. Setting a width on one connector gives that reading up for that connector only; every other cable on the page still shows its type.

Orthogonal to the connector type is the Link type: what the connection is, not how it finds its path. Each type has exactly one fixed presentation — there is no per-link line styling — and all of them are keyed to the line colour, so they follow the theme and any colour override.

Pick it from the Link dropdown on the inspector's Facts tab. It shows the type the selected cables hold, and reads Mixed when they disagree — pick anything from there and every selected cable takes it. It is the same control, holding the same value and naming the types the same way, as Type on the Cables tab.

Link Drawn as
Normal A plain line. The default; needs no legend entry.
IPsec tunnel A dashed core running inside a translucent tunnel casing, with a padlock badge at the midpoint.
Trunk (802.1Q) A double line — a heavy stroke with a background-coloured stripe down the middle.
LAG (LACP) A heavy line with a midpoint badge: two strands bound in a small ring — the aggregate ring in miniature (see Aggregates below).
WAN link Long dashes.
Management Fine dots — out-of-band.
Wireless Dash-dot, with a radio-wave badge at the midpoint.
Conduit A solid core inside a translucent casing, no badge. The controlled channel between two zones in the IEC 62443 sense — a documented pipe, not an encrypted one, which is what separates it from an IPsec tunnel.
Fieldbus A thin, tightly dashed line. It is the only link drawn under 2 px, because that is the honest picture of a low-speed multidrop or serial run rather than an Ethernet trunk.
HA / heartbeat Short dashes in PAIRS — two marks, then a wider gap — with a paired-boxes badge at the midpoint: one member of the pair and its twin.

The dash rhythms are deliberately distinct — long dashes, fine dots, medium dashes, dash-dot, paired dashes — so the types stay tellable apart at 50% zoom. Badges live at the midpoint rather than along the line, because routes are orthogonal polylines and a decorated line mangles at every corner.

HA / heartbeat is for the cables between the two members of a high-availability pair: the dedicated heartbeat and session-sync links a cluster runs beside its data ports. It is worth marking because those cables are the ones a reader most often mistakes for ordinary uplinks, and the ones an outage post-mortem asks about first. Nothing guesses it for you — two firewalls side by side usually are an HA pair, but they are just as often a cluster, two tenants, or one box replacing another, and the icons cannot tell you which. Pick it yourself, on the cables you mean.

Speed is the second channel: the link type is the line style, the link speed is the line colour. They compose — a 10G WAN link is the WAN dash pattern painted in the 10G colour.

Pick it from the Speed dropdown beside Link. Nine presets are offered, ordered slow to fast:

1G · 2.5G · 5G · 10G · 25G · 40G · 100G · 400G · 800G

The model accepts any string, so a speed that arrives through Import or a .drawio — 200M, 2G — is kept, and joins the list while a selected cable carries it. There is no free-text box: the nine are what the drawing is designed around.

The default palette is an ordered cool-to-warm sweep (indigo → blue → teal → green → olive → amber → orange → red → magenta), so the colour also encodes the ranking. Because nine hues cannot all be told apart by everyone, the legend — colour plus the speed text — is the intended second reading; the on-canvas colour only has to read as "roughly this fast, different from its neighbours".

Recolouring is per document, not per connector: with a single speed selected, the Color control that appears under the picker changes that speed's colour everywhere on the document at once. Reset returns it to its default. A file with no recolouring stores no overrides.

An explicit per-connector colour, chosen from the Color swatches, always wins over the speed colour.

VLANs on a cable

VLAN, in the connector inspector, is what this link carries. It is drawn as a quiet second line under the cable's own label, in the same place and following the same placement, one size down.

It is free text, and deliberately so. A trunk carries a set, an access port carries one, and plenty of links carry neither:

10,20,30 native 1        access 40        Modbus/TCP        area 0

Type whatever is true. Nothing parses it, nothing validates it, and nothing renumbers it for you.

Select several cables and type once to set them all — six uplinks that carry the same VLANs are one edit, not six.

A cable with no label of its own still shows its VLAN; the line simply stands alone. To read the topology without the addressing, turn VLANs off under the eye in the toolbar — it is one of the six label switches there, beside device names and port labels, and exports follow what you can see. Turning Connector labels off takes the VLAN with it, because the VLAN is a line of that caption.

The VLAN travels everywhere the cable does: it is in the cable schedule CSV, in the describe output, in vlan= in the DOT profile, and ⌘/Ctrl F finds a cable by it. Copying or duplicating a cable brings its VLAN along — it is a fact about the link, not an identifier of one box, so the second cable to the next access switch starts on the same VLANs. Compare reports a changed VLAN as its own line rather than as a restyle.

Addresses at each end

A cable has two ends and each end is its own interface, so the address is typed per end, under Ends on the cable's card (or on a device's Cables tab) — in that end's own column, under the port name, beside the placement controls for it. The card's headings name the devices, so there is never a question of which end you are typing into.

Anything goes in: 10.0.0.1/30, 2001:db8::1, dhcp, unnumbered. Nothing is validated, because half of those would fail a validator and all of them are true.

Each address draws as a quiet second line under its own port label, on the side that label is already on, so it moves with it and never crosses the cable. An end with an address and no port name shows the address alone, as close to the cable as the port name would have been. When a cable runs straight out of a device with Side on Auto, both of its ends take the same side — above a horizontal cable, to the right of a vertical one — so a point-to-point link reads as one pair of numbers rather than one over the line and one under it.

Type an address on one end and, while the other end has none, it gets the partner: 10.10.10.1/30 on one firewall puts 10.10.10.2/30 on the other, a /31 pairs the same way, and on a wider prefix the far end takes the next address up while that is still a host of the subnet. It follows as you type, so the prefix arrives with the number, and it is one undo step with your typing. An address you put on the far end yourself is never overwritten. It is IPv4 only — 2001:db8::1/127 or dhcp leaves the other end alone — and Fill the other end's address in the app menu (☰ next to the title) switches it off.

Addresses under the eye in the toolbar turns them off — for reading the topology without the numbers. Turning Port labels off takes the addresses with them, since they hang under those labels.

They travel like every other cable fact: A address and B address in the cable schedule CSV, fromip=/toip= in the DOT profile, address on each end of the describe output, and ⌘/Ctrl F finds them. Searching an address finds the end that carries it — and the zone whose subnet contains it, which is a different, equally useful answer to the same question.

Circuits and providers

Set a connector's Link type to WAN link or Wireless and the inspector offers two more fields: Circuit ID and Provider. They are the carrier's reference for the service and the carrier's name — SE-12345, Telia.

They appear for those two link types only, exactly as Wavelength appears only for optical cable types. A patch lead between two switches in one rack has no carrier, and a field that can only ever be empty is clutter on every other cable. Nothing hides a value you have already set: retype a WAN link as Normal and its circuit stays in the file, in the schedule and in the exports — losing a circuit id to a mis-click would be much worse than a field you cannot currently see.

When a WAN link has no label of its own, the circuit becomes its caption: Telia · SE-12345, or whichever half you filled in. Give the cable a label and the label wins — a WAN caption is usually the service ("Internet 1Gb/s"), and printing the circuit under it says the same thing twice in the busiest part of the drawing. The id is still one click away in the inspector, and it is in every export.

Every provider named on the page becomes a row in the generated legend, in with the link types, drawn with the line style that provider's own cables use. A reader can then answer "who supplies that line?" from the sheet.

Circuit and Provider are columns in the cable schedule CSV, circuit=/provider= in the DOT profile, and ⌘/Ctrl F finds a link by either — which is the search you do with a carrier on the phone.

There is no Bandwidth field: Speed already takes 200M.

Cable length

Every cable has an optional Length, under Cable on the cable card — 3 m, 0.5 m, 10 ft. Select several cables and type it once to give them all the same length, the way you would six patch leads to the same switch. It is also a column in the Cables tab of the table, shown by default, so a whole rack's worth can be typed straight down from a tape measure. Wireless links do not offer it: there is no cable to measure.

It is free text and nothing requires it. The schedule prints exactly what you typed. Where something needs a number — NetBox, the transceiver count — Drawbridge reads 3 m, 3m, 0,5 m, 10 ft and 10', and takes a bare 3 as metres. Anything it cannot read, such as 2 x 5m, is still printed as you typed it, and left blank where a number is required rather than guessed.

Lengths by cable type. The Length field suggests the lengths each type is sold in — patch leads and fibre from half a metre to 50 m, a DAC only up to the 7 m passive twinax reaches, an AOC out to 100 m. Type anything else you like. Copper is held to its standard: twisted pair runs 100 m (IEEE 802.3), 30 m at 25G and 40G, and 30 m for a 10GBASE-T module in an SFP+ cage; a passive DAC runs 7 m up to 10G and at 40G, 5 m at 25G–100G and 3 m above. A longer copper length is refused when you enter it — on the card, in the Cables table and in Add cable… — and the field says why. A cable that already has one, from an import or because it was re-typed to copper later, is listed by Checks. Fibre and AOCs are not limited here; their reach depends on the optics.

Where it shows up:

Copying a cable keeps its length; the format painter does not paint it, because two cables are not the same length for looking alike. length= carries it in the DOT profile, and a CSV import reads a length column.

Cable type, and how many transceivers you need

Cable says what the link physically is. It paints nothing — it exists so Drawbridge can tell you what to order. It is the third dropdown in the Look group, under Speed:

RJ45 copper · DAC (twinax) · AOC · Multimode (SR) · Single-mode (LR) · Single-mode long (ER) · BiDi · CWDM · DWDM · Breakout DAC/AOC (4×) · MPO breakout (SR4 → 4×SR) · RJ45 copper on SFP

The line under the picker names the part your choice resolves to, so the consequence is readable without opening the report.

The speed already fixes the cage — 10G is an SFP+, 100G a QSFP28 — so speed and cable type together name a part: a 25G multimode link is an SFP28 25G SR 850 nm, one module at each end. A DAC or AOC is one cable assembly and no modules at all; an RJ45 run is neither.

Copper comes in two bills. RJ45 copper is a patch lead between two built-in ports and buys no hardware at all. RJ45 copper on SFP is the same lead between two SFP cages, and buys a BASE-T module at each end — SFP 1000BASE-T at 1G, SFP+ 10GBASE-T at 10G, and the multi-gig parts at 2.5G and 5G. No BASE-T module is made above 10G, so a 25G or 100G run on this type is listed as a gap (100G BASE-T) and counted as incomplete, rather than as a part you would not be able to order. Cat6a is the lead, not the part, so there is no category field: NetBox's type column is left blank for both copper types for exactly that reason.

For the optical types a Wavelength field appears under the picker, with the CWDM grid and the DWDM C-band offered as presets (C21, 1310 nm, 1471 nm, …). You can type anything — it is your channel plan. The wavelength is part of the part, so eight DWDM links on eight channels come out as eight order lines rather than one line of sixteen.

Multimode says 850 nm on its own, at every speed, because that is what SR is — so a plain SR link, a breakout's SR children and a cable you typed 850 nm on are all the same order line instead of three that read alike. No other type fills a wavelength in for you: LR is 1310 nm on one platform and a CWDM channel on the next, and a WDM part needs the channel from your plan.

Nothing is ever guessed. A cable with no type set is counted into an Unspecified row instead of being assumed to be short-reach, because a plausible wrong number is worse than a visibly missing one. Setting the type on the first cable between two kinds of device makes the next one come out the same way, like the other connector conventions.

Blocks → Optics in the toolbar drops a block on the page listing what this page's cables call for, and refreshes in place as you draw. It is a switch — clear it and the block comes off again. It is ordinary page content, so it exports, prints and shares like anything else. For the whole document, Optics report in the app menu shows the totals and a per-device breakdown, and Optics CSV in the Export menu is the same thing as a file.

Four counts are approximate and say so:

Breakouts

The last two types are the one cable that is not one link. A breakout takes one 4-lane port at one end and fans it out to four ports at the other, and you draw it as a single line:

Which end aggregates is read from the way you drew the cable: the end you started at gets the single parent, the end you finished at gets the four. Draw it the other way round and the two swap. The wavelength is filled in from the type — 850 nm for anything SR, 1310 nm for the 400G DR4 — and you can still type your own. So the four children of a 100G breakout and the ordinary 25G multimode links beside them are counted as one line of SFP28 25G SR 850 nm, which is how you order them.

The MPO-to-4×LC harness itself is not counted, for the same reason a WDM mux is not: it is patch plant rather than something the drawing knows. Speeds with no standard four-way split (10G, 800G) stay in the Unspecified row instead of being invented. And both breakout types leave the type column of the NetBox export empty: NetBox has no breakout cable type, and one breakout is four cables there, so any value we wrote would be a wrong answer to a question the row cannot ask. Everything else about the row — the devices, the ports, the status — exports as usual.

The cable schedule, and ticking cables off

Cable schedule in the app menu turns the document into one row per cable — a kopplingsschema — grouped by device, because you work one rack at a time. The same checklist can live beside the drawing: Edit layout → Cable schedule docks it (along the bottom, where the groups run side by side), with its own search, Hide done and progress bar, and Print, labels, CSV… opening this dialog for the rest.

Each row is the port you are standing at, where the other end goes, and what the cable is:

et1/2  →  SPINE-02 · et1/1        100G · Single-mode (LR) · 10,20,30 · Po1

The CSV carries more than the line above shows: the VLAN and the address at each end are columns of their own.

Ports sort the way you read them, so et1/2 comes before et1/10 rather than after it.

One row per run

A cable you joined with One cable is one row, not one per connector. That is what it is on the floor: you pull a single cable from a switch to a wall box and it passes through two patch panels on the way, so three rows would be three ticks for one piece of work — and two of them could never be done separately anyway.

The row's two ends are the ends of the whole run, and the devices it passes through are named in the middle, in the order the cable meets them:

et1/1  →  WALL-12 · eth0        via PP-A:12 → PP-B:12 · 10G · OM4 (SR)

Each one names the position the cable is patched to. Where a run enters a panel on one position and leaves on another, both are shown — PP-A:12/24 — because a cross-patch is exactly the thing worth spotting before you go looking for the far end. A device you never named a port on shows as just its name.

Ticking the row ticks the whole cable, all of it at once, and the run counts as connected only when every part is. Facts every part agrees on — the speed, the cable type, the VLAN — are the run's; where the parts disagree, the cell is left empty rather than picking one of them.

The schedule CSV has a Via column at the end carrying the same text, blank on an ordinary cable. The NetBox export is the one place this does not apply: it still writes a row per hop, because a NetBox cable terminates on exactly two interfaces and a patch panel really is two cables there.

This applies to a run through anything, not only a patch panel — joining the connectors is you saying they are one cable, and what the icon in the middle happens to be is not the point.

Tick a cable when you have run it. The tick is stored in the document, not in your browser, and that is the point: two people patching the same hall see each other's ticks live through collaboration, the state survives a reload on a tablet, and the file you hand over afterwards says what is actually connected. A mis-tick is one undo away.

Progress shows at the top as a figure and a bar, with a smaller bar per device so you can see which rack is still outstanding. Hide done clears what is finished out of the way. The panel is laid out for a phone held in one hand — that is where it gets used.

A cable with no port name at either end shows (no port) in amber, on the end that is missing one. It still counts, but NetBox cannot import it, so it is worth naming before you export.

Print puts the same schedule on A4 with real tick boxes, so it works on paper when the phone is in a pocket. It prints what you are looking at, so searching or hiding the done ones first prints just that. The sheet is headed with the document — the open file's name without its extension, or Untitled before it has been saved — because the schedule covers every page, not the one you happen to be on.

Printing labels

Print labels, next to Print, prints the stickers for both ends of every cable. Each label says where that end is plugged in, where the other end goes, and the cable's own label underneath when it has one:

LEAF-01 · et1/1
→ SPINE-02 · et1/1
Po1

The other end of the same cable gets the mirror of that, so whichever end you are holding, the label tells you where the rest of it comes out. Port names are set in a typewriter face, because et1/1 and et1/l have to be different things at the back of a rack at two in the morning; a name too long for the label is cut short with an ellipsis rather than wrapped onto the next one.

The sheet is A4 with three labels across and eight down, 63.5 × 33.9 mm each — the geometry sold as Avery L7159 or J8159, and as a house brand by most stationers. There is nothing else on the page, no title and no date, because anything above the labels would push the whole grid off the die-cuts. Print one on plain paper and hold it against a sheet of the real stock before committing a full sheet, and turn any "fit to page" or "shrink to fit" option in the print dialog off — scaling is what moves the grid.

Like Print, it prints what you are looking at: search for a rack and you get that rack's stickers. Filter until nothing is left and the button greys out, because there is nothing to print.

Sending the checklist to whoever is patching

Share, in the same row of buttons, copies a link to this schedule. Send it over chat to the engineer standing in the hall and they open the checklist on their phone — no account, no install, nothing to sign in to. The cables travel inside the link itself, in the part of a URL that browsers never send to a server, so there is nothing to host and nobody in between ever sees the schedule. It is the same kind of link as the import links described in Diagrams from code.

What they get is the checklist and nothing else. The drawing is not in the link and no document is opened, so there is nothing to edit by accident; searching, Hide done, the progress bars and Print all work exactly as they do here. The CSV and NetBox buttons are not offered, because there is no document behind them to export.

The line above the figure says Shared schedule · ticks stay on this device, and it means it. Their ticks are kept in that phone's own storage and are keyed to the schedule, so they survive a reload or a pull-to-refresh — and they do not come back to you. There is no server for them to come back through. Cables you had already ticked when you shared arrive ticked; everything after that is theirs, and your own document keeps saying whatever you ticked in it.

Because the ticks are keyed to the cables rather than to the exact link, sending a corrected schedule to the same phone keeps the morning's progress: fixing a speed or a label does not clear anything, and the new link replaces the old schedule even when it is opened in the tab that still shows it. A link that a chat window has truncated, or that has been edited by hand, says what is wrong instead of showing half a list.

The link points at whatever copy of Drawbridge you shared it from, because that is the address it was copied at. Share from drawbridge.fortiknight.com and anyone can open it. Share from a copy running on your own machine — a localhost address — and it will not open anywhere else, because on their phone localhost means their phone. The same is true of an instance inside a company network: the link works for whoever can reach that instance, which may mean being on the VPN. If a link does not open for the person you sent it to, that is almost always why.

Getting their progress back

Their ticks stay on their phone, but they can hand them to you as a short piece of text. In the shared view there is a Send progress button: it copies a code that starts with drawbridge-ticks: to their clipboard, and they paste it into whatever you already use to talk to each other — chat, mail, a ticket. Nothing is uploaded and nothing leaves the phone on its own; the code is what they choose to send.

The code carries only which cables are done, as identifiers. There are no device names, no ports and no drawing in it, and it is small: a 54-cable job comes back in about 188 characters, which pastes into any chat window without being broken across lines.

On your side, open Cable schedule and press Progress. A field appears under the filters. Paste the code into it and press Apply, or just press Enter.

Applying only ever ticks. It never unticks anything, and that is deliberate: a code says "I have run these", not "everything else is undone". Your document may well hold cables the engineer never saw — on another page, or added after you shared — and a code that could untick would quietly clear them.

The result is written under the field, in one line: Ticked 12 cables · 3 already ticked · 1 is not in this document. The whole apply is a single undo step, so if it was the wrong code, one Undo takes all of it back.

That last count is how you recognise a code from a different job: every cable comes back as not in this document, and nothing is ticked. A cable or two counted that way is normal — you deleted them, or renamed the link since sharing — but a number that matches the whole code means you have pasted the wrong site's progress.

A code that cannot be used says why rather than doing nothing. An empty field asks you to paste the code; text that is not a code at all says so; a code a chat window has broken or truncated says it is damaged and to ask for it again unbroken; and a code made by a different version of Drawbridge says that instead of half-applying.

This is a manual step in both directions, by design. The engineer has to send you the code and you have to paste it; there is no sync, no polling and no server, so nothing arrives while you are not looking. Ask for a code at the end of the day and you get the day, not a live feed.

Label placement

The inspector's Label placement section moves a connector's own caption — the midpoint one — without moving the cable. The interface names at the two ends are placed from Ends instead, beside the fields you type them into; see The cable card below.

Unlike the port names, this row works on a whole selection: pick every cable on the page and "make all of these follow the line" is one press and one undo.

"Above" and "Below" are measured against the cable, not the screen, so they mean the same thing whichever way a connector runs — on a vertical cable "above" is the right-hand side. That is also why a label on a vertical connector sits beside its line rather than across it. A caption left at its default moves to its own cable's other side when another cable runs right beside it on that side — between two cables it would read as either one's. Choose a side yourself and it stays exactly where you put it.

A caption wraps to the connector it sits on: a long cable or arrow gets a long line, and only a short one breaks the caption onto a second line — so Tunnel-Private-Group-ID 103 stays on one line across a long run and breaks at the space on a short one. It keeps clear of both ends rather than running the whole length — a fifth of a short cable, and a fixed margin of about a port label's length on a long one, so a long cable gives the caption nearly all of its run — and it never breaks a word in half: a name too long for the line stands a little proud of the cable instead. A caption that follows the connector measures along the line; an upright one measures across the page, so a vertical connector wraps as narrowly as a short one. All of this is measured on the part of the connector you can see: a cable attached at a device's centre runs under the device for half a tile, and neither the middle nor the room is counted from there — so a cable attached at the centre of one device and the edge of the other still carries its caption in the middle of the visible line.

Dragging a caption

Three stops and three sides cannot separate two captions that land in the same place — two cables crossing at a shallow angle put both of them at the midpoint, just above the line. So drag the caption itself: it moves freely along its cable, and away from it, as far as you need.

Dragging is not a free-floating offset. Where the caption ends up is still recorded against the cable — how far along the route, which side, and how far off — so moving a device, or anything that makes the router re-draw the run, carries the caption with the line instead of stranding it in empty space. Crossing the line while dragging flips it to the other side, and dropping it on the line puts it On, knockout and all; the inspector's buttons keep showing which side it ended up on.

Dropping a caption back roughly where it started snaps it to the default, so a label you have nudged and put back is exactly a label nobody has ever touched. Pressing Start, Middle or End always wins over a drag and puts the caption on that stop — including the stop that is already marked, which is how a caption dragged along its own default comes home; pressing the side it is already on puts the distance back to the standard one, which is the quickest way to undo a lot of fiddling.

The format painter carries all of this, so you can set one connector up the way you want it and paint the rest.

The cable card

Select a cable and the inspector's Facts tab is about that cable. Its header names it by its two ends, A first — FW-01 to SW-CORE — over its caption, with chips for its speed, its link type and how it is routed. Swap ends beside them turns it round: A becomes B, and everything that belongs to an end goes with it — the device, the port name, the address, where the port label sits — while the line on the page stays exactly where it was. One ⌘Z / Ctrl Z turns it back. A cable that is one segment of a run through patch points cannot be swapped on its own; its ends are the run's.

First come its Ends: for each end, in a column under that device's name, the port, its address, which side of the cable the port's name sits on and whether it follows the cable's angle — then the cable's Caption and where it sits along the line. A selected cable has no Cables tab: its two ends are its card. Several selected cables that make up an aggregate show the aggregate's own card there instead, with the ring's caption and where it sits.

Then three sections in the order you think about a cable: Link — what it carries: its Type, Speed, VLANs, the Cable itself (with the optic it implies, and a wavelength for an optical one), and a Circuit ID and Provider when it is a WAN or wireless link — then Route — how it is drawn: Auto, Direct, Arc or Custom, Through icons, joining it into one cable, and Use as the default and Apply to every cable — then Aggregate, when it is bound into one or could be. How it looks — its colour, its weight, its caption's typeface — is on the Look tab.

The Cables tab

The inspector has three tabs. Facts is what the selection is — its name, kind, link type and speed, where it sits — and Look is how it looks: colour, icon, line weight, text and where its name goes. Cables lists every cable touching what you have selected, so you can read and edit a device's links without hunting down each one on the canvas — the tab itself carries the count, so "how many things is this wired to" is answered before you even open it.

Select a device and you get a card per connector: which device it goes to, its label, both port names — each captioned with the device whose port it is, so a cable drawn the other way round cannot quietly swap them — plus its link type, its speed and what the cable itself is, as text: Normal · 100G · DWDM C21, with the channel on an optical one. Under that line is the part the cable comes to — QSFP28 100G DWDM C21 — one at each end — so what a link costs in optics is readable from the device you selected rather than one card deeper. A cable with no cable type yet says neither: nothing is added to the line and no part is named. Every other field edits in place, and edits land exactly as they would on the cable's own card, one undo step each. The type, the speed, the cable and its channel are all set on the cable's own card — select it, under Link — so there is one place to change them, and here they are read. Tab walks the fields in order — port name, address, its Side and Follow, then the other end's, then the next card — so a device with eight links is filled in without touching the mouse; ⇧Tab walks back.

Under each port name is where that name goes: a Side picker — Auto, Above, On or Below — and a Follow checkbox that turns the label to the cable's own angle instead of keeping it horizontal. Auto is the default, and it is a real choice rather than an empty one: the label picks the side pointing away from its own device and steps out of the way of anything already there. Pick a side and that stops; if two labels then want the same spot they slide further along their cable rather than crossing back over it. On a cable too short for its caption and both names, a name gives up a little of its own device rather than land on the caption or beside the device at the other end — and on a diagonal, a label stands far enough off its cable that none of its letters cross the line. "Above" and "Below" mean here exactly what they mean for the connector caption — measured against the cable, not the screen.

The two ends are set separately because they are genuinely different places: ge-0/0/1 leaving a switch at the top of the page and wan1 arriving at a firewall at the bottom have different things in the way, and one shared setting could only ever suit one of them.

The arrow at the top of a card says where the other device is on the page — → for one beside it, ↓ for one below, ↘ for one diagonally down and right. It is measured from the drawing, not from which end of the cable you happened to draw first, so a card can be matched to the picture without reading a name.

Hovering a card highlights that cable on the canvas, which is the quickest way to tell which of eight links is which.

Each card also has Copy and Paint, the format painter on one connector: copy the look of the cable you have got right, then paint it onto the others without leaving the panel. It is the same clipboard as the inspector's own Copy/Paint, so a look copied here can be painted on the canvas and the other way round. A cable that already looks like the copied one says so rather than appearing to ignore the press.

Delete, on the left of the same row, removes the cable itself — unwiring a device is part of editing its connections, and it should not require finding the cable on the canvas first. It is the same delete as selecting the connector and pressing the key: one undo step brings it back.

Select several devices and each gets its own section, because which device you are looking from is what decides which port name belongs to which end. Select connectors instead and they are listed together under one heading, one card each — a card names both of its ends, so a selected cable is one card and not two.

Aggregates in the tab

An aggregate is one card, not one card per member. The head names every device the ring reaches, the line under it says which ring it is and how many cables it stands for, and everything the members share — the label, the type, the speed, the cable and its channel — is shown once, with the part the ring comes to under it when every member buys the same one. Fields the members disagree on read Mixed; picking a value there sets it on all of them. Members on different cable types read mixed cables, and members on one cable type but different channels read mixed channels — and either way no part is named, because there is no single one to name. Below that is one row of port names per member, so the only thing that genuinely differs cable by cable is the only thing listed cable by cable. A fan-out that reaches two devices (an MC-LAG) gets a heading per device, over its own members, rather than one heading that is only true of the first cable. Hovering the card highlights the whole ring; hovering one member line highlights just that cable. Delete ×4 removes the whole aggregate in one undo step.

You can also decide what goes in a ring from here. Every cable that could be aggregated gets a Ring picker: put it in an existing ring, take it out again, or choose New ring… to spawn another one beside the first. A ring holding a single cable is not drawn yet — the panel says so and names the devices, so the next step is to pick that ring on another cable of one of them; it starts being drawn as soon as that second cable joins. A waiting ring is marked by its cable in the picker, for example Ring 2 ×1 — Hub–Core-SW, and the panel points you to it by that cable rather than by its number: rings are numbered in the order they appear in the drawing, so making another ring can renumber one that is waiting. While a cable is waiting like that it is not offered another New ring…, and neither is a cable no other cable could join: a ring of one on its own would only ever be a ring nobody can see.

A cable inside a ring is a row of port names on the ring's card, without the Side and Follow controls — there is no room for them beside eight members at this width. Click that cable on the canvas and it gets a card of its own, with the full set.

Inside a ring's card, each member row ends in the same picker in miniature, under a Ring heading: the ring's number, — to take that cable out, + for a new ring. That is how an aggregate is split in two — give one member a new ring, then send the next member to it — and it is the only ring control a cable inside a ring has, since it gets no card of its own. Taking a cable out that would leave a single cable behind dissolves the ring rather than leaving one you cannot see.

A cable can be in more than one ring

A cable has two ends, and each end can be part of its own port-channel. In a spine/leaf pod the four cables leaving a leaf are one aggregate there, while the two arriving at each spine are an aggregate at that spine — three rings over four cables, which is what the switches themselves think is going on.

So binding adds a ring rather than replacing one. Select all four cables and press Bind as aggregate for the leaf's ring; select the two that run to one spine and press it again for that spine's ring; repeat for the other spine. A subset of a ring is how the next ring gets made, so binding stays available there. When the selection is a whole ring exactly as it already is, the button reads Add another ring instead, and after that Add a third ring.

A set of cables carries one, two or three rings, and never more: one in the middle, one at each end, or all three — the drawings people actually make. A second ring over the same pair of devices would land on top of the first, so it is placed at the other end of the run, and the first moves to the near end to make room; a third goes back to the middle. At three the button goes quiet and says why. Drag any ring along its cables to put it exactly where you want it — it follows the pointer whichever end it hugs.

Unbind removes one ring — the one you pressed on the canvas, or the one picked in the Ring list when the selection touches several — and leaves the other rings those cables are in exactly as they were. The button's tooltip names the ring it is about to remove.

A ring always stands square across its cables, whichever way they run, and a ring that hugs a device sits just outside its tile rather than over it.

Taking a cable out of one ring leaves its other rings alone — pulling a cable out of the leaf's aggregate does not take it out of its spine's.

Because of that, Ring color in the inspector adds a Ring picker as soon as your selection touches more than one aggregate. It lists each ring by its own name — its port-channel label if it has one, otherwise its number in the drawing — with how many cables it holds, and the colour, Reset and Set default below act on the one you have picked. With a single ring selected there is nothing to choose and the picker stays away.

Naming a ring

An aggregate card has Ring label above Cable label, because they are two different facts: the ring's name is the port-channel (Po1, ae0), while a cable's label is the circuit it carries. Writing the port-channel's name on all four cables to say it once is exactly the repetition these cards exist to remove.

Double-click the oval to name a ring without going near the inspector — the caption edits in place, exactly like a device's or a cable's. Aim at the oval's own line: its inside belongs to the cables it encircles, so a double-click in there edits the cable you hit, which is usually what you meant if that is where you clicked.

Those placement controls appear in the ring's card the moment the name is committed — a ring with no caption has nothing to place, so until you have typed one they are not there. The ring's caption is placed the same three ways a connector's label is, measured against the ring rather than a cable: Along runs down the ring's sweep — Start just outside one end, Middle across the middle of it, End just outside the other; Side steps it off the ring in the direction of the cables; and Follow the ring turns it to the ring's angle instead of keeping it horizontal, never upside down. A caption sitting on the ring gets the same knockout a label on its own cable does, so the line does not run through the letters.

What the tab deliberately does not do is re-point a cable at a different device. That is a change to the shape of the diagram rather than to what a cable is, it has a direct gesture already — drag the endpoint handle — and doing it from a list would make the row you are editing disappear out from under you.

Selecting a connector

A selected connector gets a soft band along its length, in the selection colour, with a round handle at each end that you can drag to re-attach it. Each handle sits on the cable just clear of its device, never on the device's edge, so wherever the pointer shows the grab hand, pressing takes the cable's end — pressing on the device itself still moves the device. Hovering shows the same band, fainter — hover and selection are the same idea at two volumes. The hover band belongs to the pointer, so it goes out as soon as the pointer leaves the drawing, however fast it leaves; the selection band stays until you select something else.

The band sits underneath the cable rather than replacing it, which is deliberate: the cable keeps its own colour while it is selected, so a 100G link still reads as 100G and still matches the legend. Selecting several connectors at once bands each of them individually, so parallel runs stay countable.

A cable drawn from a device's centre ends at that centre, under the icon — so its handle is drawn a little way out along the cable, just clear of the tile, where you can actually grab it. Pressing inside a device always means "move the device", and that has not changed: the handle simply steps outside so both gestures have room. Drag it onto another device, or onto a different side of the same one, exactly like any other endpoint.

Line jumps

Where two connectors cross, the upper one (the one painted later) hops over the lower with a small arc — the wiring-schematic cue that crossing cables are not connected. Nothing to turn on.

Connectors that share an endpoint device do not jump over each other behind that device — where its own tile covers the meeting, a bump would be a mark on a piece of cable nobody can see, and the fan of wires arriving at one switch reads as a junction rather than as a pile of crossings. Everywhere the crossing is actually visible, it bumps: a switch's downlinks crossing mid-run, and Direct cables converging on one firewall, which cross close in by their very nature and used to come out flat.

Two connectors between the same pair of devices would otherwise be drawn exactly on top of each other and be impossible to click. Instead each member of the pair gets a deterministic sideways offset, so the group fans apart around the original centreline: two members sit either side of it, three sit at −1/0/+1, and so on. The fan is derived from the connectors, not stored, so it is stable across redraws and file round-trips. Each member takes its place by sliding along the border of the device it leaves, so a fan still meets both devices when the run is diagonal — when one of the pair is dragged out of line, the outer cables slide further along the two tiles rather than drifting off them. Within a bundle the cables are ordered by their port labels, naturally — Gi1/0/2 before Gi1/0/10 — so the labels read in order down the side of a device whichever way the connectors were drawn; the same order applies to Auto, Direct and Arc connectors.

That is separate from a true aggregate. Select two or more connectors that share at least one endpoint device and press Bind as aggregate, in the inspector's Aggregate section, to make them one logical LACP bundle, drawn with a ring encircling the members. Unbind makes them independent again. The ring's colour can be changed, reset, or made the default for all rings — and when your selection is in more than one ring, a Ring picker above the colour says which one you are about to change. Members that leave one device for two peers — an access switch's uplinks to both switches of a distribution pair — make an MC-LAG (MCLAG, multi-chassis LAG): bind them exactly the same way, and one ring encloses the fan to both peers, while the connections tab and the cable schedule name the far device of each member. The other way round works too: when the cables share no device but run into devices you have grouped (⌘/Ctrl G) — two switches cabled to the two members of a pair — the group counts as the one end they share, and the ring sits across the cables just outside the group's frame. Ungroup the pair and the ring stops being drawn until it is grouped again. And when the cables share neither a device nor a group, you can still bind them on purpose: the first press of Bind as aggregate turns the button into a warning, Press again to bind anyway, and the hint says what is missing; press again and the ring is drawn midway along the cables, where you can drag it like any other. To draw the two peers themselves as one logical switch, with the link between them, make them an MC-LAG pair. Note the distinction from the LAG link type, which is "one line that represents an aggregate"; binding is the real multi-member concept. The two share their look on purpose — the LAG badge is that same ring drawn in miniature around two strands, so both notations read as the one networking idea.

How automatic routing works

Auto connectors are routed by libavoid, an obstacle-avoiding orthogonal router. In plain terms:

A connector that attaches to a zone or a rack skips the router entirely and is drawn as a straight centre-to-centre segment.

Very large drawings

On a very large page — several hundred Auto connectors, the scale of a whole enterprise imported at once — cables that converge on the same heavily-wired device (a datacenter hub firewall with a tunnel from every branch, an ISP cloud carrying half the WAN) are drawn as a fan of smooth curves instead of orthogonal paths. At that density an orthogonal bundle into one device is a solid, unreadable bar, and routing it is also what used to make huge imports take minutes — the fan keeps the drawing readable and the import takes seconds. Everything else on the page keeps normal obstacle-avoiding routing, drawings below this scale are not affected at all, and nothing about your file changes: the connectors are still Auto, and a page that shrinks back below the threshold routes orthogonally again.

Dragging stays responsive on such a page too. A change is rerouted only as far as it can reach — the devices and cables around it, never the far end of the page — so on most large drawings the cables follow a device while you drag it and a drop settles at once. Only where one densely-wired area is too big to reroute as fast as the pointer moves do the cables attached to what you are moving follow as straight lines for the duration of the gesture, snapping to their exact routes the moment you drop.

Once you stop editing, the app quietly recomputes the full-quality version of that page in the background — every cable, hubs included, routed orthogonally with obstacle avoidance, exactly as if the page were small — and swaps it in when it finishes. A small "Refining cables…" pill shows while it works (seconds on a couple of thousand devices; Cancel keeps the fans). An edit that moves something brings the fans back instantly and the refinement starts over; renaming a device, recolouring it or editing its notes leaves the refined cables where they are. Exports wait for the full-quality version by default, so the file you hand someone always carries the best cabling available — the export dialog offers "Export current view" if you would rather not wait.

Why connectors move when you move a device

Routes are derived, not stored. Every time the diagram changes, the router re-solves — and it solves every connector the change could affect, not just the one you touched: everything wired to, or routed near, what moved. Moving one device changes the obstacle field, which can change the cheapest path for connectors that have nothing to do with that device. This is normal, and it is the price of never having to clean up cabling by hand. The routes come out exactly as if the whole page had been solved at once.

Recomputation is batched to one pass per animation frame, so dragging a device stays smooth however many connectors are attached.

If you need a path that will never change, switch that connector to Direct or Custom. Direct and Custom geometry is yours, and the router does not touch it.