Using the Help Center

The Bitanix NetMan Help Center is an offline, searchable guide included with the application.

Find a topic

• Browse the category tree on the left.
• Search for a feature, field, command, workflow, or error message.
• Use Previous and Next to read topics in guide order.
• Use Back and Forward to revisit navigation history.

Bookmarks and related features

Select Bookmark to retain a frequently used topic. If a topic is connected to an application feature, Open Related Feature closes Help Center and opens that workspace.

Keyboard help

Press F1 from the application to open Help Center. Individual windows can provide their own topic ID for context-sensitive help.

Guide content is stored as offline application resources and included in packaged builds.

Continue with Welcome & Quick Start.

Quick Start: Document Your First Network

This walkthrough creates a small head-office project with an Internet cloud, firewall, router, core switch, server, and access point. It uses documentation only and does not require live credentials.

1. Start and name the project

1. Start in the ready-to-use untitled workspace.
2. Add the first device; a project file is not required yet.
3. Choose File → Save Project As, enter Head-Office.netdoc, and use a meaningful internal project name.

2. Build the topology

1. Add Cloud, Firewall, Router, Switch, Server, and Access Point from the Devices palette.
2. Double-click each device and complete Name, Type, Vendor, Model, Serial Number, management IPv4/IPv6, Notes, and Configuration where known.
3. Ctrl+click two devices and select Connect Selected Devices. Record both interface names, for example Firewall port2 ↔ Router Gi0/0.
4. Use Insert → Add Network Zone for LAN, DMZ, or Management areas and add explanatory text.

3. Add addressing and evidence

Open VLAN/IP Manager. Example: VLAN 10, name Management, subnet 10.10.10.0/24, gateway 10.10.10.1. Add interfaces and create a configuration snapshot titled Initial documented baseline.

4. Review and report

1. Open Project Dashboard and review missing documentation.
2. Run Security Audit only after reviewing the project data.
3. Use Fit Topology to Screen before exporting.
4. Generate Device Inventory or Comprehensive Documentation PDF.

Never paste production passwords, private keys, SNMP secrets, or API keys into Notes or Configuration. Use Credential Manager and the operating-system Keyring.

Save after each logical milestone. Auto Save is recovery protection, not a substitute for a tested backup.

Projects, Dashboard, Save & Recovery

Project lifecycle

Dashboard interpretation

The Dashboard summarizes saved project evidence: device and connection totals, known SNMP state, IP/VLAN coverage, configuration coverage, hardware assets, security findings, and recent documented activity. It does not invent traffic, CPU, uptime, or monitoring history.

Untitled Project appears only before a file is saved. For saved projects, the file name is used when an internal name is unavailable.

Auto Save

Enable Auto Save under File and choose an interval appropriate to the editing workload. The temporary file is a crash-recovery copy beside the application, not an archive with multiple generations.

Project password

Project Security uses authenticated encryption. Passwords require at least ten characters, a letter, and a number. The password is not stored and cannot be recovered. Changing or removing protection requires the current password.

Older project files

New feature tables and fields are added incrementally when required. Existing topology, inventory, and configuration rows are preserved. Always keep a backup before opening an irreplaceable project in a newer release.

Example: before redesigning a branch, use Save Project As to create Branch-Before-Redesign.netdoc.

Topology, Devices, Connections & Canvas

Device records

Supported visual types include Router, Switch, Firewall, Server, Access Point, PC, VoIP Gateway, IP Phone, Storage, NVR, Tape, IP Camera, Cloud, and Generic. Type controls the icon; it does not restrict manual documentation.

Connections

Select exactly two devices with Ctrl+click, connect them, and document local and remote interfaces. A line without port names is visually useful but incomplete for troubleshooting and handover. Double-click a connection to edit it.

Canvas controls

• Mouse wheel or toolbar: zoom.
• Middle mouse drag: pan.
• Fit Topology: recover items outside the viewport.
• Auto Layout: rearrange nodes without changing device records.
• Select a node and drag its resize handle to change icon size.

Text and Zones

Text labels document sites, paths, or warnings. Network Zones are resizable background rectangles for LAN, DMZ, WAN, or security boundaries. They remain behind devices and appear in topology exports.

A drawn link or zone documents intent; it does not prove live connectivity, routing, redundancy, or enforcement.

IPv4, IPv6, VLAN, Interfaces & Configuration

Addressing records

Use CIDR notation where a prefix is required. Example IPv4 subnet: 10.20.0.0/24; IPv6 subnet: 2001:db8:20::/64. Document gateway, VLAN ID, purpose, and reservations. Duplicate and invalid addresses are highlighted by IPAM checks.

Interfaces

Record interface Name, Description, Mode, VLAN, IPv4/IPv6, MAC address, Admin Status, Oper Status, and Speed. Use the exact device label, such as GigabitEthernet1/0/24 or ether1.

Example: Gi1/0/24, description AP-Office-01, mode Trunk, VLANs 10,20,30, operational state Up.

Configuration Parser

1. Open the intended device first.
2. Paste Cisco IOS-like or MikroTik export text.
3. Preview detected hostname, interfaces, addresses, and VLANs.
4. Review every proposed value before Apply.

The parser is bound to the open device to reduce accidental application to another node. Manual entry remains available and existing values should not be overwritten without review.

Configuration History

Create descriptive snapshots, compare two versions line-by-line, and record why the change occurred. A useful title is CHG-1042 — WAN failover enabled, not backup2. Restoring a snapshot changes documented current content; it does not automatically deploy commands to a live device.

Configuration text can contain secrets. Sanitize it before PDF, AI, ticket, or email distribution.

Discovery, SNMP, SSH & Credentials

Network Discovery

Enter an authorized IPv4 CIDR or bounded IPv6 target. Discovery combines available ICMP, TCP, ARP, OUI, and optional SNMP evidence. Review results before import; discovered hosts are never added automatically. OUI identifies the network-interface vendor, which may differ from the appliance brand.

Example: scan 192.0.2.0/28, review MAC/vendor and address, correct the proposed device type, then import only approved results.

SNMP collection

SNMP can populate identity, description, uptime, and interfaces. Prefer SNMPv3 authPriv. For SNMPv2c use a read-only community, management ACL, and isolated management network. Offline means the latest collection could not reach the endpoint; Unknown means no conclusive saved check.

Configuration retrieval

Cisco and MikroTik SSH retrieval presents collected configuration for review before it becomes device data. It does not replace a vendor backup system.

Interactive SSH Terminal

• Verify the host-key fingerprint on first connection.
• A changed key is a critical identity warning, not an inconvenience to bypass.
• Command completion supports Cisco and MikroTik interactive prompts.
• Multi-line paste requires confirmation.
• Logging is off by default; sanitized capture can become a configuration snapshot.

Credential Manager

Reusable SSH and SNMP secrets use the operating-system Keyring and are not stored in .netdoc. Device Notes, Runbooks, reports, and Emergency Packages are not credential stores.

Discovery, scanning, SNMP, and SSH must be used only on systems you are authorized to administer.

Hardware Inventory & Asset Records

Hardware Inventory is deliberately independent from topology devices. Use it for desktops, laptops, and servers that need asset documentation but may not belong on the network map.

Identity and ownership

Asset Tag must be unique inside the project. Record type, name, vendor/model, serial, assigned user, department, location, lifecycle status, purchase date, and warranty end. Dates use YYYY-MM-DD.

Technical specification

• Operating system and version
• CPU vendor, model, generation, cores, and threads
• Motherboard and GPU
• Individual RAM modules by slot, capacity, type, speed, and serial
• Individual HDD, SSD, NVMe, or SAS storage devices by bay and capacity

Maintenance history

Record service date, category, description, provider, cost, and next service date. Do not replace prior maintenance rows when new work occurs.

Example: Asset LAP-FIN-014, assigned to Finance, 2 × 8 GB DDR4, 512 GB NVMe, warranty ending 2027-05-30; maintenance entry records battery replacement and provider.

Outputs

Asset Certificate PDF documents one machine. Complete Inventory PDF summarizes asset counts, RAM capacities, CPU generations, storage technology, warranties, and upgrade candidates.

Security Center: Findings, Scans & Compliance

Security Center organizes defensive evidence. Automated results require qualified review and do not constitute a penetration test, compliance certificate, or guarantee of security.

Security Audit and Finding lifecycle

Repeated audits update the same fingerprint. Disappearing active findings become Resolved; detected resolved findings reopen. Record Owner, Due Date, Notes, and evidence.

Port & Service Scanner

Performs bounded TCP connection checks against one authorized address or CIDR. Presets or custom ports can be used. History compares completed scans with the same target and port set: New, Closed, or Unchanged. It does not exploit, brute-force, or authenticate.

Compliance Profiles

Essential Baseline, CIS Controls v8-aligned, and NIST CSF 2.0-aligned profiles combine automatic project evidence with human review. Statuses are Pass, Fail, Needs Review, and Not Applicable. Add reviewer evidence; mappings support gap assessment only.

TLS/SSH Assessment

TLS records negotiated protocol/cipher, certificate expiry, trust, hostname match, signature, public key, and fingerprint. SSH records negotiated banner, host key, cipher, and MAC without authentication. Results show this client's negotiation, not every server-supported algorithm.

Firmware & CVE Intelligence

Firmware snapshots preserve vendor, product, version, build, support status, evidence, and optional verified CPE 2.3 URI. CPE Exact is stronger association; Keyword Candidate is review-only. CVE/KEV results still require affected-range, configuration, and vendor-advisory validation.

Risk Overlay

• Red/orange/yellow: saved active device-linked risk.
• Green: assessed evidence exists with no active linked risk—not guaranteed secure.
• Gray: insufficient saved device-linked assessment evidence.

Run active checks only with written authorization and within an approved scope and maintenance policy.

Ubuntu Server Audit

Ubuntu Server Audit performs a bounded, read-only assessment over verified SSH. It supports Ubuntu Server 22.04 and 24.04. Selected findings offer separately approved assisted remediation; arbitrary commands are never accepted.

Register a target

1. Open Security Center → Ubuntu Server Audit.
2. Select an existing Server device or keep the target independent from topology.
3. Enter the SSH endpoint and choose an SSH profile stored in the operating-system credential store.
4. Save the target. Passwords and private-key passphrases are never written to the project.

Run the baseline

The baseline covers identity, kernel, CPU and memory, filesystem capacity, time synchronization, reboot state, updates, local and privileged accounts, sudo evidence, effective SSH configuration, firewall state, listening sockets, systemd service health, and logging/rotation. Commands are fixed, non-interactive, locale-stabilized, and executed without a PTY.

Interpret results

• Score reflects active weighted findings and severity caps.
• Coverage shows how many checks produced assessable evidence.
• ERROR and NOT_CHECKED reduce coverage and never count as a pass.
• Unsupported operating systems are recorded without continuing the Ubuntu-specific baseline.

Export saved evidence

Select a saved run and choose Export PDF for a readable report or Export JSON for machine-readable evidence. Export uses the saved snapshot and does not reconnect to the server.

The baseline does not treat SSH port 22 alone as a failure. A check that cannot obtain reliable evidence fails closed instead of guessing a pass.

Verify unknown SSH host-key fingerprints through an independent trusted channel. A changed key may indicate legitimate replacement or a man-in-the-middle attack.

Audit collection remains read-only. Results are evidence for qualified review, not a compliance certificate or guarantee of security.

Assisted remediation

For supported failed or warning checks, select Preview Assisted Fix. Review the exact affected component, backup, verification, rollback, and risk before typing the approval phrase.

• Supported actions cover NTP, the installed unattended-upgrades service, /etc/shadow metadata, limited SSH hardening, and UFW with the current SSH port preserved.
• Privileged changes use sudo -n. NetMan never requests or stores a sudo password.
• SSH and firewall changes require a second verified SSH connection and attempt automatic rollback if verification fails.
• Every transaction records operator, status, verification, and rollback history.

Remediation changes a remote server and can affect availability. Use a narrowly authorized maintenance account, verify out-of-band console access for high-risk changes, and review each transaction independently.

Advanced inspection

The read-only advanced baseline detects Docker metadata and public port publication, Nginx/Apache listeners, supported database listeners, Fail2ban state, readable Let's Encrypt certificate expiry, selected authentication-policy evidence, and backup-readiness indicators.

• Docker environment variables and container secrets are not collected.
• Database credentials are not requested and no database query is executed.
• Certificate private keys are never read.
• A detected backup tool or timer is not proof of a successful or restorable backup.

Not Applicable commonly means a component was not detected. Error means evidence could not be collected reliably and never counts as a pass.

Policies, profiles, drift, and schedules

Use Policies & Schedules to create validated project policies for Generic, Web, Docker, Database, Application, or Bastion roles. Each completed run stores its own immutable policy snapshot.

Use History & Drift to compare a run with its previous snapshot. Drift distinguishes new findings, resolved findings, changed evidence, and added or missing checks while ignoring uptime and volatile memory values.

Schedules are checked while the Ubuntu Audit window is open. A due run always requires confirmation and follows the normal credential and SSH host-key workflow. Selecting No snoozes it until the window is reopened.

CIS labels are navigation references only. They do not claim benchmark coverage, compliance, certification, or conformance.

Reports, PDF, AI Analysis & External Export

Choose the smallest useful report

The topology image is placed on a dedicated page when included. Reports use the project/file name, orange branding, confidential footer, and current saved evidence.

AI Network Analysis

1. Select the analysis purpose and a supported model.
2. Review the prepared project context.
3. Choose reasoning level where available.
4. Start the background request and review—not blindly apply—the response.

The OpenAI API key belongs in OS Keyring. AI output can be incomplete, incorrect, or unsafe for the exact platform.

External AI Export

For users without API access, create a sanitized package and prepared prompt for ChatGPT or another model. Automated redaction cannot recognize every organization-specific secret. Open and inspect the exported file before uploading it.

Never treat AI advice as authorization to deploy commands. Validate syntax, model, firmware, scope, backup, verification, and rollback.

Knowledge Base, Runbooks & Run Mode

Articles

An Article stores reusable operational knowledge independently from topology. Complete Title, Type, Category, Status, Author, Tags, Summary, and rich Content. Statuses are Draft, Approved, and Archived. Approval should represent a real review process, not cosmetic formatting.

Runbooks

A Runbook adds ordered executable steps. Every step can contain Instructions, Commands, Verification criteria, Rollback procedure, and a Safety-sensitive flag.

Example — Restart an access switch:

1. Pre-check: confirm maintenance approval and out-of-band access. Verification: current config backup is readable. Rollback: stop if either is missing.
2. Capture state: save interface and spanning-tree state. Commands are vendor-specific and must be reviewed.
3. Perform change: execute only the approved action.
4. Validate: uplinks, management, endpoints, monitoring, and logs must pass.

Revision History

Every explicit save creates a new immutable revision of article content and Runbook steps. Loading an older revision places it in the editor; history changes only when you save a new revision.

Attachments and device links

Attachments up to 25 MB are embedded in .netdoc, increasing project size. Device links are optional and do not require the article to appear on topology.

Run Mode

Start with an operator name, check steps as performed, and record observations. Completing with unchecked steps requires confirmation. Completed or Aborted execution history can be exported as a PDF.

Built-in templates are starting points. Review vendor syntax, safety, authorization, verification, and rollback before execution.

Network Handover Mode

Handover Mode converts saved documentation into an audience-specific operational transfer. It does not collect live state while generating the handover.

Audience

• Executive: ownership, resilience, gaps, and business context.
• Network Engineer: management, connectivity, configuration, and recovery.
• Help Desk: service impact and escalation.
• Contractor: approved scope and device identity.
• Auditor: saved evidence and control coverage.

Readiness Score

The score evaluates documented scope, topology, ownership, escalation contacts, acceptance, addressing, vendor/model/serial, configuration recovery, interfaces, firmware, and approved or linked Runbooks. It measures documentation readiness—not network uptime or security.

Guided Tour

Devices are ordered from Internet/edge toward firewall, routing, switching, access, servers, and storage. Select an entry and choose Show Selected Device on Topology.

Profile and Acceptance

Record Prepared By, Recipient, Organization, support/escalation contacts, known issues, and emergency notes. Review every acceptance statement with the recipient and add notes for exceptions.

Knowledge Quiz

Questions are generated from current documented facts, such as the most connected node, device count, subnet/VLAN count, and an approved Runbook. Attempts are recorded for onboarding evidence, not professional certification.

Outputs

The PDF contains readiness gaps, tour, inventory, addressing, Runbooks, and acceptance. The .bnhp Emergency Package uses Scrypt and AES-256-GCM. It deliberately excludes credentials and raw configuration.

Store the package password separately. It cannot be recovered. Validate emergency information periodically and after major changes.

Licensing, Data Safety & Operational Limits

Trial and activation

A new machine exports a Trial Request and imports an owner-signed three-day Trial Response for offline evaluation. Commercial activation separately supports signed one-month, three-month, six-month, or Lifetime licenses. Every entitlement is bound to the intended system.

Data locations and secrets

• .netdoc contains project documentation and embedded Knowledge attachments.
• OS Keyring stores supported SSH, SNMP, NVD, and API secrets.
• Auto Save is temporary recovery data.
• Encrypted projects and .bnhp packages use passwords that cannot be recovered.

Before an operational change

1. Confirm written authorization and scope.
2. Verify identity, model, firmware, and management endpoint.
3. Create and validate a current backup.
4. Use an approved Runbook with explicit success and rollback criteria.
5. Arrange console or out-of-band recovery where appropriate.
6. Record the result and update project documentation.

Interpretation limits

• Discovery evidence is not a complete inventory.
• SNMP Online is not proof that all services are healthy.
• Risk Overlay green is not a security guarantee.
• CVE association is not proof of exploitability.
• Compliance mapping is not certification.
• AI output is advisory and requires expert validation.
• A topology line documents a relationship; it does not prove reachability.

Use scanning and remote administration only on authorized systems. Follow local law, contract, change control, and organizational policy.

Tutorial: Document an Existing Network

Scenario: You inherited a small office with one Internet circuit, firewall, router, two switches, three servers, storage, and four access points. Documentation is incomplete.

Outcome

A saved and backed-up project with traceable inventory, topology, addressing, configuration baselines, and documentation gaps.

1. Define scope before collection

1. Record site name, owner, authorized management ranges, and excluded systems.
2. Collect existing diagrams, IP spreadsheets, configuration backups, rack labels, and support contacts.
3. Create Office-Current-State.netdoc. Do not redesign the network while documenting the baseline.

2. Build inventory and identity

Add devices manually from the edge inward. Use operational names such as HQ-FW-01. Complete hostname, vendor, model, serial, management IPv4/IPv6, physical location, and non-secret notes. Use Generic only until the actual type is verified.

3. Document connectivity

Connect Internet → Firewall → Router/Core → Access switches → Servers/APs. Enter interface names at both ends. Where information is uncertain, say Unverified rather than guessing.

4. Build the logical layer

Add VLANs, subnets, gateways, IP reservations, and important interface addresses. Example: VLAN 20 Servers, 10.20.0.0/24, gateway 10.20.0.1. Run duplicate and overlap checks.

5. Establish configuration evidence

For each managed network device, import a reviewed current configuration and save a snapshot titled with date and source, for example 2026-08-10 — Console-verified baseline.

6. Validate

• Fit topology and inspect every connection.
• Review Dashboard coverage.
• Resolve duplicate IPs and incomplete identities.
• Generate Device Inventory and Addressing reports.
• Save, close, reopen, and verify the project before delivery.

Keep a separate evidence list of facts that remain unverified. Accurate incompleteness is safer than confident fiction.

Tutorial: Discover and Onboard Devices

Scenario: You are authorized to inventory 192.0.2.0/28 and want to add only verified network equipment.

1. Prepare

1. Confirm written scope and scan window.
2. Save the project first.
3. Know which addresses must not be scanned.
4. Prepare read-only SNMP credentials if authorized; prefer SNMPv3 authPriv.

2. Discover

Open Discovery, enter the bounded range, choose conservative checks, and start. Cancellation is safe; incomplete results should not be treated as a completed inventory.

3. Review each result

Example: OUI says Intel but SNMP describes a Linux server. Classify from verified device evidence—not OUI alone.

4. Import deliberately

Correct proposed Name, Type, Vendor, and address. Select only approved rows. Existing manual values should remain unless the new evidence is more authoritative and reviewed.

5. Enrich Cisco and MikroTik devices

Open Device Details, verify identity, then use authorized SNMP or SSH retrieval. Preview configuration parser results before Apply. Save the first configuration snapshot and document interfaces.

Verification

• No duplicate device or management IP exists.
• Imported count matches selected rows.
• Vendor/type uncertainty is documented.
• Credential secrets are absent from project fields.

Tutorial: Prepare and Document a Network Change

Scenario: Add VLAN 40 for voice to two switches while retaining a clear rollback path. Bitanix documents and guides the change; it does not grant authorization.

1. Capture the before state

1. Verify device identity, model, firmware, and management address.
2. Retrieve or paste the current configuration.
3. Create snapshot CHG-2041 — Before voice VLAN.
4. Record current interfaces, trunks, VLANs, addressing, and monitoring state.

2. Create the Runbook

In Knowledge Base create an Approved Runbook linked to both switches.

3. Execute in Run Mode

Enter the operator, check only completed steps, and record exceptions. Do not mark verification complete based only on command acceptance.

4. Record the after state

Save CHG-2041 — Completed voice VLAN, compare it with the before snapshot, update VLAN/interface documentation, and export the execution report.

Success criteria

• Voice VLAN works on intended ports.
• Existing production VLANs remain healthy.
• No unexplained configuration diff exists.
• Rollback remains possible and documented.

Tutorial: Perform a Defensive Security Review

Scenario: Produce an evidence-based internal review for a documented branch. Obtain explicit written authorization before any active network check.

1. Improve input quality

Complete device identity, management addresses, configurations, interfaces, firmware records, and ownership. Weak documentation produces weak conclusions.

2. Run the project audit

Open Security Center and run Security Audit. Assign owners and due dates to active findings. Use Accepted Risk or False Positive only with review notes and evidence.

3. Assess exposed services

Run a bounded Port & Service Scan against approved management targets. Compare with previous completed history. Investigate newly exposed Telnet, HTTP, database, or remote administration services.

4. Review transport security

Run TLS/SSH Assessment without credentials. Validate certificate identity/expiry, negotiated protocol, cipher, SSH host key, banner, and integrity algorithm. Remember that SSH negotiation is not exhaustive algorithm enumeration.

5. Add firmware intelligence

Record exact firmware evidence. Prefer a verified CPE for NVD queries. Treat Keyword Candidate matches as leads. Confirm every CVE against vendor advisories and affected ranges.

6. Complete a profile

Select Essential Baseline, CIS-aligned, or NIST CSF-aligned review. Add human evidence for Needs Review controls and explain Not Applicable decisions.

7. Interpret Risk Overlay

Red through yellow indicates active saved risk; green indicates saved assessment with no active linked issue; gray means insufficient device-linked evidence. Hover for evidence and missing coverage.

8. Report and verify

Generate Integrated Security Posture PDF. Manually validate priority findings, CVEs, scope, timestamps, and limitations before distribution.

Never describe this workflow as a penetration test, certification, or proof that a green device is secure.

Tutorial: Build a Customer Handover Package

Scenario: Transfer a completed branch project from an implementation engineer to the customer's network team.

1. Complete operational knowledge

Approve at least one recovery Runbook, one connectivity incident Runbook, and any site-specific maintenance procedure. Link critical devices where useful. Attach only non-secret supporting files.

2. Open Handover Mode

Select Network Engineer as the primary audience. Record preparer, recipient, organization, support/escalation contacts, known issues, maintenance restrictions, and emergency notes.

3. Raise readiness

Review every gap. Correct missing management addresses, hardware identity, serial numbers, configuration snapshots, interfaces, firmware, topology links, and Runbook coverage. Do not fabricate unavailable facts to improve the score.

4. Conduct the Guided Tour

Walk from Internet edge through firewall/router, core/access switching, wireless, servers, and storage. Select each entry to center it on topology. Explain business impact and recovery ownership.

5. Validate understanding

Ask the recipient to complete the generated Knowledge Quiz. Discuss incorrect answers; the score is onboarding evidence, not certification.

6. Accept and export

Review all eight Acceptance items together and document exceptions. Generate the branded Handover PDF. If an offline emergency copy is required, create an encrypted .bnhp file and communicate its password through a separate approved channel.

Final verification

• Open the delivered project on a clean authorized workstation.
• Verify PDFs and embedded attachments.
• Confirm credential ownership separately.
• Record recipient acceptance and remaining limitations.

Tutorial: Use AI With or Without an API

Scenario A — OpenAI API

1. Open AI Network Analysis.
2. Select an analysis goal such as documentation quality or configuration review.
3. Select a listed supported model and reasoning level.
4. Store the API key in OS Keyring if desired.
5. Review the prepared context, start the request, and save the result as Markdown.

Scenario B — No API access

1. Select Export for ChatGPT / External AI.
2. Create the sanitized analysis file and prepared prompt.
3. Open the file manually and search for passwords, communities, tokens, private addresses, customer names, and configuration secrets.
4. Remove anything not approved for disclosure.
5. Upload only under your organization's data-sharing policy.

Example request

Review the attached sanitized network documentation. Identify documentation gaps, risky management protocols, configuration inconsistencies, and five prioritized remediation actions. Separate confirmed evidence from assumptions.

Validate the response

• Does every conclusion cite supplied evidence?
• Is command syntax correct for vendor/model/firmware?
• Could a recommendation interrupt access?
• Are backup, verification, and rollback included?
• Did the model claim vulnerability or compliance without proof?

Sanitization reduces exposure but cannot guarantee removal of organization-specific secrets. AI output is advisory and must never be deployed without expert review and authorization.

Troubleshooting: Projects, Canvas & Auto Save

Project opens but topology appears empty

Symptoms: device count is non-zero but canvas looks blank. Likely cause: saved nodes are outside the current viewport or zoom is extreme. Resolution: select Fit Topology to Screen, then Reset Zoom. Check Dashboard and Device list before assuming data loss. Verification: all expected device names appear. Prevention: fit and save after major layout work.

Project cannot be opened

Diagnosis: distinguish invalid file, password failure, permission failure, and damaged/incomplete copy. Confirm extension, file size, storage availability, keyboard layout, and whether the file begins as an encrypted Bitanix project. Work only on a copy if corruption is suspected.

Resolution: use the exact password; restore a known-good backup if damaged. Forgotten encryption passwords cannot be recovered.

Changes disappeared after a crash

Likely cause: final save did not occur and Auto Save was disabled, unwritable, or older than the last edit. Locate the Bitanix recovery file, preserve a copy, and open it through the application's recovery workflow. Verify data before replacing the primary project.

Auto Save file remains after closing

This can indicate abnormal shutdown or failed final save. Do not delete it until the primary project opens and contains the latest work. A normal successful save and exit removes the temporary recovery copy.

Controls are hidden on a small monitor

Maximize the window, use the Devices panel scrollbar, and reduce Windows display scaling only if appropriate. Do not resize or edit the project database manually.

Password-protected project repeatedly rejects a known password

Check Caps Lock, keyboard language, copied whitespace, and that the correct file is selected. Authentication failure can also indicate file modification. Test a backup; do not attempt destructive “repair” on the only copy.

Troubleshooting: Discovery, SNMP & SSH

Discovery finds no hosts

Causes: wrong CIDR/interface, host firewall, ICMP blocked, TCP probes blocked, no local route, excessive IPv6 scope, or missing authorization-dependent SNMP evidence. Diagnosis: verify the local route and one known host outside Bitanix; reduce to a single approved address; confirm scan status completed rather than cancelled. Resolution: correct the range and approved probe settings. Do not disable production controls solely for discovery.

Vendor is Unknown or unexpected

OUI describes a MAC interface manufacturer, not always the system vendor. Virtual NICs, OEM hardware, and locally administered MACs can mislead. Confirm with SNMP identity, device label, serial, and authorized management access; edit the proposed vendor before import.

SNMP is Offline

Check: management address, IPv4/IPv6 route, UDP/161 ACL, SNMP version, username/community, auth/privacy algorithms, engine/time synchronization, and read-only view. Test the same endpoint from the same workstation and management path. Verification: identity and interface data populate and Last SNMP Sync updates.

SSH connects but no usable prompt appears

Confirm an interactive shell is allowed, terminal width/height negotiation succeeded, and the account does not launch a restricted command. Wait for the device banner; press Enter once. MikroTik and Cisco may use control sequences. Disconnect should close the channel and worker; if the UI remains active, close the session tab and preserve logs for diagnosis.

Every command appears twice

Cause: local echo plus server echo, or duplicate key/input signal handling. Ensure only the live terminal widget has focus and use the current build. Do not paste repeated commands. Verify with a harmless read-only command such as /system identity print or show clock.

Tab completion does not work

Completion depends on a live interactive Cisco or MikroTik session and recognizable prompt. Click the terminal, type an incomplete command, then press Tab. If the device uses a custom shell or restricted prompt, server-side completion may not be available.

Host-key warning

An unknown key requires out-of-band fingerprint verification. A changed key may indicate replacement, reinstallation, load balancing, or interception. Stop and investigate; never accept it only to make the warning disappear.

Troubleshooting: Security Evidence & Risk Overlay

Every device shows Not Assessed

Meaning: no device-linked saved assessment evidence is available. Run the project Security Audit and relevant authorized checks. Completed clean Security Audit, Port Scan, TLS/SSH Assessment, Firmware/CVE evidence, or known SNMP evidence contributes coverage. Toggle Risk Overlay off/on to refresh. Hover a device to see Evidence and Missing Coverage.

A device is green but you know it has problems

Green means no active device-linked risk was found in the saved evidence—not secure. Confirm the finding Asset matches device name/hostname/IP, the finding is active, and recent evidence is saved in this project. Manual knowledge not recorded in Bitanix cannot affect the overlay.

Finding disappeared or reopened

Audit lifecycle resolves active findings absent from a later run and reopens them if detected again. Inspect Finding History, Last Seen, status, and review notes. Accepted Risk and False Positive decisions are preserved unless deliberately changed.

Port scan history shows no comparison

Comparison requires a previous Completed run with the same normalized target and port set. Cancelled, Failed, or Interrupted runs are retained for audit history but do not become comparison baselines.

TLS certificate appears untrusted

Check endpoint, SNI/server name, system trust store, certificate chain, expiry, hostname, and inspection proxy. An IP target often fails hostname validation unless the certificate contains that IP identity. Do not suppress trust errors without an approved alternative validation method.

NVD query fails or returns no CVEs

Confirm Internet access, system clock, NVD availability, timeout, API-key validity, and CPE syntax. No result can mean no association, incorrect CPE, rate limiting, or query failure. Keyword search can generate candidates but not confirmation.

Compliance score seems lower than expected

Open each Needs Review or Fail result. Automatic controls use only saved project evidence; organizational controls require reviewer evidence. Mark Not Applicable only with scope rationale. The score is an internal gap indicator, not certification.

Troubleshooting: PDF, AI & License

PDF cannot be created

Check: destination exists and is writable, the same PDF is not locked by a viewer, filename is valid, and disk space is available. Try a short filename in Documents. Verification: file begins with a valid PDF header and opens normally.

Topology is clipped or too small in PDF

Fit Topology to Screen, remove accidental distant annotations, and review node positions. Comprehensive output places topology on a dedicated page, but extremely wide diagrams may still scale down. Split operational views with zones or separate projects when one diagram is unreadable.

AI model list or request fails

Confirm network access, valid API key in OS Keyring, supported model selection, account/project permissions, quota, and provider status. A timeout or cancelled request should not be treated as a completed analysis. Never paste the API key into project Notes.

External AI export still contains sensitive data

Automated sanitization is pattern-based. Remove customer names, internal identifiers, addresses, secrets, and proprietary configuration manually. If policy prohibits external processing, do not upload the file.

License is rejected

Copy the exact Machine Code from the target system, use a license generated for that code, preserve all license text, and correct Windows date/time/time zone. A license from another system is invalid. If hardware identity changed, contact the issuer.

Evaluation is unavailable or expires unexpectedly

Export a Trial Request and import the matching owner-signed Trial Response. The evaluation is valid for three days and tied to the requesting system. Obvious clock rollback may block use as secondary evidence. Correct the clock and re-import the valid response; legacy unsigned trial state is never trusted.

Assessment / Beta license is expired or rejected

An Assessment License is an owner-signed BNL1 entitlement for controlled testing, distinct from the three-day BNE1 evaluation and normal commercial licenses. Confirm the exact target Machine Code, signed not-before and expiry timestamps, system clock and complete token. It cannot be lifetime, cannot be moved to another computer, and deleting settings does not restart or extend it. Expiration does not delete projects.