mirror of
https://github.com/netbox-community/netbox.git
synced 2025-07-16 04:02:52 -06:00
Updated Frequently Asked Questions (markdown)
parent
d9f621d25a
commit
bc9a22066b
@ -3,7 +3,8 @@
|
||||
* [Why Can't I Connect a Virtual Circuit to an Interface?](#why-cant-i-connect-a-virtual-circuit-to-an-interface)
|
||||
* [How Can I Add New Interface Types?](#how-can-i-add-new-interface-types)
|
||||
* [Why Does NetBox Support Only Image Attachments?](#user-content-why-does-netbox-support-only-image-attachments)
|
||||
* [Why Aren't Device Type Component Modifications Retroactive?](#user-content-why-arent-device-type-component-modifications-retroactive)
|
||||
* [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 Doesn't NetBox Scan for IPs?
|
||||
|
||||
@ -65,4 +66,10 @@ This is because automatically removing components requires NetBox to make very d
|
||||
|
||||
There's a similar issue when attempting to _add_ components automatically. Say you had created a number of devices from an incomplete device type (perhaps they're missing a few interfaces), then you create the missing components on the device type. If NetBox were to populate these components automatically on the existing device instances, it would risk colliding with any components that had already been added to the devices. This would force us to either trigger an error, and prevent the new component templates from being added to the device type, or to ignore the collision, possibly resulting in an unexpected state (e.g. the device components may have been created with incorrect or missing data).
|
||||
|
||||
To avoid these problems, NetBox simply leaves it to the user to determine how best to rectify potential discrepancies. Once a device type has been updated, its device instances can easily have components added or removed in bulk. This approach ensures that all changes are driven by intent rather than by assumptions.
|
||||
To avoid these problems, NetBox simply leaves it to the user to determine how best to rectify potential discrepancies. Once a device type has been updated, its device instances can easily have components added or removed in bulk. This approach ensures that all changes are driven by intent rather than by assumptions.
|
||||
|
||||
# Why Can't Circuits Have More Than Two Terminations?
|
||||
|
||||
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.
|
||||
|
Loading…
Reference in New Issue
Block a user