NeoAnd/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2025-07-21 11:37:21 -06:00
Code Issues Actions 10 Packages Projects Releases Wiki Activity

Updated Frequently Asked Questions (markdown)

Jeremy Stretch 2021-09-08 19:01:00 -04:00
parent 249060b45c
commit 9e76f3344a
1 changed files with 11 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
Frequently-Asked-Questions.md

@ -5,6 +5,7 @@
* [Why Does NetBox Support Only Image Attachments?](#user-content-why-does-netbox-support-only-image-attachments)
* [Why Aren't Device Type Component Modifications Retroactive?](#why-arent-device-type-component-modifications-retroactive)
* [Why Can't Circuits Have More Than Two Terminations?](#why-cant-circuits-have-more-than-two-terminations)
* [Why Can't I Pass Exported Data Directly Into the Import Form?](#why-cant-i-pass-exported-data-directly-into-the-import-form)
# Why Doesn't NetBox Scan for IPs?
@ -73,3 +74,13 @@ To avoid these problems, NetBox simply leaves it to the user to determine how be
This question often stems from conflating physical and virtual circuits. A physical circuit is established between exactly two endpoints, whereas a virtual circuit can connect an arbitrary number of endpoints via one or more physical circuits. In a scenario where it seems that a circuit has more than two endpoints, there are actually multiple circuits, each with its own A and Z side terminations, abstracted in a way that they seem to function as a single circuit. A good rule to keep in mind is that circuits possess no forwarding logic: A packet entering one end will always egress the other.
To date, NetBox support only the modeling of physical circuits, however support for virtual circuit modeling is planned for a future release.
# Why Can't I Pass Exported Data Directly Into the Import Form?
The bulk import and bulk export functions for objects in NetBox are two entirely different functions. When exporting a list of objects, NetBox will by default replicate the currently configured view, including only the columns configured for display in the user interface. NetBox also offers an "All Data" export option, which will include _all_ available fields.
However, this data is formatted for intended consumption by a human, which is to say it's prioritized for readability: Column headers are capitalized, punctuation is included, etc. This format often differs significantly from the expected format for bulk import data. The bulk import function also often requires additional contextual data that is _not_ present in any of the default export formats, for good reason.
For example, when exporting a list of devices, NetBox will include the assigned site and rack (if any), but not the rack's group. If there are multiple racks with the same name within the site, each within a different group, this data will not be sufficient to import devices: Additional information (i.e. the group assigned to each rack) is needed so that NetBox knows which rack to assign to each device. It would be extremely inefficient to include all such possible information in the default export format for all objects.
Additionally, redirecting data exported from NetBox back into NetBox is not a common use case. If you find yourself doing this, you may want to consider a more programmatic approach using the REST API or Python shell. However, if you decide this is the required course of action, you always have the option of creating a custom export template to arrange whatever data you need in whatever format you like. These can easily be used to export data in a format that is acceptable to NetBox's bulk import forms.