mirror of
https://github.com/netbox-community/netbox.git
synced 2024-05-10 07:54:54 +00:00
Update IPAM models documentation
This commit is contained in:
jeremystretch
@ -20,9 +20,23 @@ NetBox allows us to specify the portions of IP space that are interesting to us
|
||||
* 192.168.0.0/16 (RFC 1918)
|
||||
* One or more /48s within fd00::/8 (IPv6 unique local addressing)
|
||||
|
||||
Each aggregate is assigned to a RIR. For "public" aggregates, this will be the real-world authority which has granted your organization permission to use the specified IP space on the public Internet. For "private" aggregates, this will be a statutory authority, such as RFC 1918. Each aggregate can also annotate that date on which it was allocated, where applicable.
|
||||
Each aggregate is assigned to a [RIR](./rir.md). For "public" aggregates, this will be the real-world authority which has granted your organization permission to use the specified IP space on the public Internet. For "private" aggregates, this will be a statutory authority, such as RFC 1918. Each aggregate can also annotate that date on which it was allocated, where applicable.
|
||||
|
||||
Prefixes are automatically arranged beneath their parent aggregates in NetBox. Typically you'll want to create aggregates only for the prefixes and IP addresses that your organization actually manages: There is no need to define aggregates for provider-assigned space which is only used on Internet circuits, for example.
|
||||
Prefixes are automatically arranged beneath their parent aggregates in NetBox. Typically, you'll want to create aggregates only for the prefixes and IP addresses that your organization actually manages: There is no need to define aggregates for provider-assigned space which is only used on Internet circuits, for example.
|
||||
|
||||
!!! note
|
||||
Because aggregates represent swaths of the global IP space, they cannot overlap with one another: They can only exist side-by-side. For instance, you cannot define both 10.0.0.0/8 and 10.16.0.0/16 as aggregates, because they overlap. 10.16.0.0/16 in this example would be created as a container prefix and automatically grouped under the 10.0.0.0/8 aggregate. Remember, the purpose of aggregates is to establish the root of your IP addressing hierarchy.
|
||||
Because aggregates represent segments of the global IP space, they cannot overlap with one another: They can only exist side-by-side. For instance, you cannot define both 10.0.0.0/8 and 10.16.0.0/16 as aggregates, because they overlap. 10.16.0.0/16 in this example would be created as a container prefix and automatically grouped under the 10.0.0.0/8 aggregate. Remember, the purpose of aggregates is to establish the root of your IP addressing hierarchy.
|
||||
|
||||
## Fields
|
||||
|
||||
### Prefix
|
||||
|
||||
The IPv4 or IPv6 network this aggregate represents.
|
||||
|
||||
### RIR
|
||||
|
||||
The [Regional Internet Registry](./rir.md) or similar authority which governs allocations of this address space from the global pool.
|
||||
|
||||
### Date Added
|
||||
|
||||
The date on which the address space was allocated or deployed.
|
||||
|
||||
@ -1,15 +1,19 @@
|
||||
# ASN
|
||||
|
||||
ASN is short for Autonomous System Number. This identifier is used in the BGP protocol to identify which "autonomous system" a particular prefix is originating and transiting through.
|
||||
An Autonomous System Number (ASN) is a numeric identifier used in the BGP protocol to identify which [autonomous system](https://en.wikipedia.org/wiki/Autonomous_system_%28Internet%29) a particular prefix is originating and transiting through. NetBox support both 32- and 64- ASNs.
|
||||
|
||||
The AS number model within NetBox allows you to model some of this real-world relationship.
|
||||
ASNs must be globally unique within NetBox, must each may be assigned to multiple [sites](../dcim/site.md).
|
||||
|
||||
Within NetBox:
|
||||
## Fields
|
||||
|
||||
* AS numbers are globally unique
|
||||
* Each AS number must be associated with a RIR (ARIN, RFC 6996, etc)
|
||||
* Each AS number can be associated with many different sites
|
||||
* Each site can have many different AS numbers
|
||||
* Each AS number can be assigned to a single tenant
|
||||
### AS Number
|
||||
|
||||
The 32- or 64-bit AS number.
|
||||
|
||||
### RIR
|
||||
|
||||
The [Regional Internet Registry](./rir.md) or similar authority responsible for the allocation of this particular ASN.
|
||||
|
||||
### Sites
|
||||
|
||||
The [site(s)](../dcim/site.md) to which this ASN is assigned.
|
||||
|
||||
@ -1,10 +1,31 @@
|
||||
# FHRP Group
|
||||
|
||||
A first-hop redundancy protocol (FHRP) enables multiple physical interfaces to present a virtual IP address in a redundant manner. Example of such protocols include:
|
||||
A first-hop redundancy protocol (FHRP) enables multiple physical interfaces to present a virtual [IP address](./ipaddress.md) (VIP) in a redundant manner. Examples of such protocols include:
|
||||
|
||||
* Hot Standby Router Protocol (HSRP)
|
||||
* Virtual Router Redundancy Protocol (VRRP)
|
||||
* Common Address Redundancy Protocol (CARP)
|
||||
* Gateway Load Balancing Protocol (GLBP)
|
||||
* [Hot Standby Router Protocol](https://en.wikipedia.org/wiki/Hot_Standby_Router_Protocol) (HSRP)
|
||||
* [Virtual Router Redundancy Protocol](https://en.wikipedia.org/wiki/Virtual_Router_Redundancy_Protocol) (VRRP)
|
||||
* [Common Address Redundancy Protocol](https://en.wikipedia.org/wiki/Common_Address_Redundancy_Protocol) (CARP)
|
||||
* [Gateway Load Balancing Protocol](https://en.wikipedia.org/wiki/Gateway_Load_Balancing_Protocol) (GLBP)
|
||||
|
||||
NetBox models these redundancy groups by protocol and group ID. Each group may optionally be assigned an authentication type and key. (Note that the authentication key is stored as a plaintext value in NetBox.) Each group may be assigned or more virtual IPv4 and/or IPv6 addresses.
|
||||
When creating a new FHRP group, the user may optionally create a VIP as well. This IP address will be automatically assigned to the new group. (Virtual IP addresses can also be assigned after the group has been created.)
|
||||
|
||||
## Fields
|
||||
|
||||
### Protocol
|
||||
|
||||
The wire protocol employed by cooperating servers to maintain the virtual [IP address(es)](./ipaddress.md) for the group.
|
||||
|
||||
### Group ID
|
||||
|
||||
The group's numeric identifier.
|
||||
|
||||
### Authentication Type
|
||||
|
||||
The type of authentication employed by group nodes, if any.
|
||||
|
||||
### Authentication Key
|
||||
|
||||
The shared key used for group authentication, if any.
|
||||
|
||||
!!! warning
|
||||
The authentication key value is stored in plaintext in NetBox's database. Do not utilize this field if you require encryption at rest for shared keys.
|
||||
|
||||
@ -1,5 +1,19 @@
|
||||
# FHRP Group Assignments
|
||||
|
||||
Member device and VM interfaces can be assigned to FHRP groups, along with a numeric priority value. For instance, three interfaces, each belonging to a different router, may each be assigned to the same FHRP group to serve a common virtual IP address. Each of these assignments would typically receive a different priority.
|
||||
Member device and VM interfaces can be assigned to [FHRP groups](./fhrpgroup.md) to indicate their participation in maintaining a common virtual IP address (VIP). For instance, three interfaces, each belonging to a different router, may each be assigned to the same FHRP group to serve a shared VIP. Each of these assignments would typically receive a different priority.
|
||||
|
||||
Interfaces are assigned to FHRP groups under the interface detail view.
|
||||
|
||||
## Fields
|
||||
|
||||
### Group
|
||||
|
||||
The [FHRP group](./fhrpgroup.md) being assigned.
|
||||
|
||||
### Interface
|
||||
|
||||
The device or VM interface to which the group is being assigned.
|
||||
|
||||
### Priority
|
||||
|
||||
A value between 0 and 255 indicating the interface's priority for being elected as the master/primary node in the group.
|
||||
|
||||
@ -1,30 +1,8 @@
|
||||
# IP Addresses
|
||||
|
||||
An IP address comprises a single host address (either IPv4 or IPv6) and its subnet mask. Its mask should match exactly how the IP address is configured on an interface in the real world.
|
||||
An IP address object in NetBox comprises a single host address (either IPv4 or IPv6) and its subnet mask, and represents an IP address as configured on a network interface. IP addresses can be assigned to [device](../dcim/device.md) and [virtual machine](../virtualization/virtualmachine.md) interfaces, as well as to [FHRP groups](./fhrpgroup.md). Further, each device and virtual machine may have one of its interface IPs designated as its primary IP per address family (one for IPv4 and one for IPv6).
|
||||
|
||||
Like a prefix, an IP address can optionally be assigned to a VRF (otherwise, it will appear in the "global" table). IP addresses are automatically arranged under parent prefixes within their respective VRFs according to the IP hierarchy.
|
||||
|
||||
Each IP address can also be assigned an operational status and a functional role. Statuses are hard-coded in NetBox and include the following:
|
||||
|
||||
* Active
|
||||
* Reserved
|
||||
* Deprecated
|
||||
* DHCP
|
||||
* SLAAC (IPv6 Stateless Address Autoconfiguration)
|
||||
|
||||
Roles are used to indicate some special attribute of an IP address; for example, use as a loopback or as the the virtual IP for a VRRP group. (Note that functional roles are conceptual in nature, and thus cannot be customized by the user.) Available roles include:
|
||||
|
||||
* Loopback
|
||||
* Secondary
|
||||
* Anycast
|
||||
* VIP
|
||||
* VRRP
|
||||
* HSRP
|
||||
* GLBP
|
||||
|
||||
An IP address can be assigned to any device or virtual machine interface, and an interface may have multiple IP addresses assigned to it. Further, each device and virtual machine may have one of its interface IPs designated as its primary IP per address family (one for IPv4 and one for IPv6).
|
||||
|
||||
!!! note
|
||||
!!! tip
|
||||
When primary IPs are set for both IPv4 and IPv6, NetBox will prefer IPv6. This can be changed by setting the `PREFER_IPV4` configuration parameter.
|
||||
|
||||
## Network Address Translation (NAT)
|
||||
@ -32,4 +10,44 @@ An IP address can be assigned to any device or virtual machine interface, and an
|
||||
An IP address can be designated as the network address translation (NAT) inside IP address for exactly one other IP address. This is useful primarily to denote a translation between public and private IP addresses. This relationship is followed in both directions: For example, if 10.0.0.1 is assigned as the inside IP for 192.0.2.1, 192.0.2.1 will be displayed as the outside IP for 10.0.0.1.
|
||||
|
||||
!!! note
|
||||
NetBox does not support tracking one-to-many NAT relationships (also called port address translation). This type of policy requires additional logic to model and cannot be fully represented by IP address alone.
|
||||
NetBox does not currently support tracking application-level NAT relationships (also called _port address translation_ or PAT). This type of policy requires additional logic to model and cannot be fully represented by IP address alone.
|
||||
|
||||
## Fields
|
||||
|
||||
### Address
|
||||
|
||||
The IPv4 or IPv6 address and mask, in CIDR notation (e.g. `192.0.2.0/24`).
|
||||
|
||||
### Status
|
||||
|
||||
The operational status of the IP address.
|
||||
|
||||
!!! tip
|
||||
Additional statuses may be defined by setting `IPAddress.status` under the [`FIELD_CHOICES`](../../configuration/data-validation.md#field_choices) configuration parameter.
|
||||
|
||||
### Role
|
||||
|
||||
The functional role fulfilled by this IP address. Options include:
|
||||
|
||||
* **Loopback:** Configured on a loopback interface
|
||||
* **Secondary:** One of multiple IP addresses configured on an interface
|
||||
* **Anycast:** Employed for anycast services
|
||||
* **VIP:** A general-purpose virtual IP address
|
||||
* **VRRP:** A virtual IP address managed with the VRRP protocol
|
||||
* **HSRP:** A virtual IP address managed with the HSRP protocol
|
||||
* **GLBP:** A virtual IP address managed with the GLBP protocol
|
||||
* **CARP:** A virtual IP address managed with the CARP protocol
|
||||
|
||||
!!! tip
|
||||
Virtual IP addresses should be assigned to [FHRP groups](./fhrpgroup.md) rather than to actual interfaces to accurately model their shared nature.
|
||||
|
||||
### VRF
|
||||
|
||||
The [Virtual Routing and Forwarding](./vrf.md) instance in which this IP address exists.
|
||||
|
||||
!!! note
|
||||
VRF assignment is optional. IP addresses with no VRF assigned are considered to exist in the "global" table.
|
||||
|
||||
### DNS Name
|
||||
|
||||
A DNS A/AAAA record value associated with this IP address.
|
||||
|
||||
@ -1,14 +1,30 @@
|
||||
# IP Ranges
|
||||
|
||||
This model represents an arbitrary range of individual IPv4 or IPv6 addresses, inclusive of its starting and ending addresses. For instance, the range 192.0.2.10 to 192.0.2.20 has eleven members. (The total member count is available as the `size` property on an IPRange instance.) Like prefixes and IP addresses, each IP range may optionally be assigned to a VRF and/or tenant.
|
||||
This model represents an arbitrary range of individual IPv4 or IPv6 addresses, inclusive of its starting and ending addresses. For instance, the range 192.0.2.10 to 192.0.2.20 has eleven members. (The total member count is available as the `size` property on an IPRange instance.) Like [prefixes](./prefix.md) and [IP addresses](./ipaddress.md), each IP range may optionally be assigned to a [VRF](./vrf.md).
|
||||
|
||||
IP also ranges share the same functional roles as prefixes and VLANs, although the assignment of a role is optional. Each IP range must be assigned an operational status, which is one of the following:
|
||||
## Fields
|
||||
|
||||
* Active - Provisioned and in use
|
||||
* Reserved - Designated for future use
|
||||
* Deprecated - No longer in use
|
||||
### VRF
|
||||
|
||||
The status of a range does _not_ have any impact on its member IP addresses, which may have their statuses modified separately.
|
||||
The [Virtual Routing and Forwarding](./vrf.md) instance in which this IP range exists.
|
||||
|
||||
!!! note
|
||||
VRF assignment is optional. IP ranges with no VRF assigned are considered to exist in the "global" table.
|
||||
|
||||
### Start & End Address
|
||||
|
||||
The beginning and ending IP addresses (inclusive) which define the boundaries of the range. Both IP addresses must specify the correct mask.
|
||||
|
||||
!!! note
|
||||
The maximum supported size of an IP range is 2^32 - 1.
|
||||
|
||||
### Role
|
||||
|
||||
The user-defined functional [role](./role.md) assigned to the IP range.
|
||||
|
||||
### Status
|
||||
|
||||
The IP range's operational status. Note that the status of a range does _not_ have any impact on its member IP addresses, which may have their statuses defined independently.
|
||||
|
||||
!!! tip
|
||||
Additional statuses may be defined by setting `IPRange.status` under the [`FIELD_CHOICES`](../../configuration/data-validation.md#field_choices) configuration parameter.
|
||||
|
||||
@ -1,8 +1,20 @@
|
||||
# L2VPN
|
||||
|
||||
A L2VPN object is NetBox is a representation of a layer 2 bridge technology such as VXLAN, VPLS or EPL. Each L2VPN can be identified by name as well as an optional unique identifier (VNI would be an example).
|
||||
A L2VPN object is NetBox is a representation of a layer 2 bridge technology such as VXLAN, VPLS, or EPL. Each L2VPN can be identified by name as well as by an optional unique identifier (VNI would be an example). Once created, L2VPNs can be terminated to [interfaces](../dcim/interface.md) and [VLANs](./vlan.md).
|
||||
|
||||
Each L2VPN instance must have one of the following type associated with it:
|
||||
## Fields
|
||||
|
||||
### Name
|
||||
|
||||
A unique human-friendly name.
|
||||
|
||||
### Slug
|
||||
|
||||
A unique URL-friendly identifier. (This value can be used for filtering.)
|
||||
|
||||
### Type
|
||||
|
||||
The technology employed in forming and operating the L2VPN. Choices include:
|
||||
|
||||
* VPLS
|
||||
* VPWS
|
||||
@ -13,9 +25,17 @@ Each L2VPN instance must have one of the following type associated with it:
|
||||
* EP-TREE
|
||||
* EVP-TREE
|
||||
* VXLAN
|
||||
* VXLAN EVPN
|
||||
* VXLAN-EVPN
|
||||
* MPLS-EVPN
|
||||
* PBB-EVPN
|
||||
|
||||
!!! note
|
||||
Choosing VPWS, EPL, EP-LAN, EP-TREE will result in only being able to add two terminations to a given L2VPN.
|
||||
Designating the type as VPWS, EPL, EP-LAN, EP-TREE will limit the L2VPN instance to two terminations.
|
||||
|
||||
### Identifier
|
||||
|
||||
An optional unique numeric identifier.
|
||||
|
||||
### Import & Export Targets
|
||||
|
||||
The [route targets](./routetarget.md) associated with this L2VPN to control the import and export of forwarding information.
|
||||
|
||||
@ -1,15 +1,18 @@
|
||||
# L2VPN Termination
|
||||
|
||||
A L2VPN Termination is the termination point of a L2VPN. Certain types of L2VPNs may only have 2 termination points (point-to-point) while others may have many terminations (multipoint).
|
||||
|
||||
Each termination consists of a L2VPN it is a member of as well as the connected endpoint which can be an interface or a VLAN.
|
||||
|
||||
The following types of L2VPNs are considered point-to-point:
|
||||
A L2VPN termination is the attachment of an [L2VPN](./l2vpn.md) to an [interface](../dcim/interface.md) or [VLAN](./vlan.md). Note that the L2VPNs of the following types may have only two terminations assigned to them:
|
||||
|
||||
* VPWS
|
||||
* EPL
|
||||
* EP-LAN
|
||||
* EP-TREE
|
||||
|
||||
!!! note
|
||||
Choosing any of the above types will result in only being able to add 2 terminations to a given L2VPN.
|
||||
## Fields
|
||||
|
||||
### L2VPN
|
||||
|
||||
The [L2VPN](./l2vpn.md) instance.
|
||||
|
||||
### VLAN or Interface
|
||||
|
||||
The [VLAN](./vlan.md), [device interface](../dcim/interface.md), or [virtual machine interface](../virtualization/virtualmachine.md) attached to the L2VPN.
|
||||
|
||||
@ -1,18 +1,43 @@
|
||||
# Prefixes
|
||||
|
||||
A prefix is an IPv4 or IPv6 network and mask expressed in CIDR notation (e.g. 192.0.2.0/24). A prefix entails only the "network portion" of an IP address: All bits in the address not covered by the mask must be zero. (In other words, a prefix cannot be a specific IP address.)
|
||||
A prefix is an IPv4 or IPv6 network and mask expressed in CIDR notation (e.g. 192.0.2.0/24). A prefix entails only the "network portion" of an IP address: All bits in the address not covered by the mask must be zero. (In other words, a prefix cannot be a specific IP address.) Prefixes are automatically organized by their parent [aggregate](./aggregate.md) and assigned [VRF](./vrf.md).
|
||||
|
||||
Prefixes are automatically organized by their parent aggregates. Additionally, each prefix can be assigned to a particular site and virtual routing and forwarding instance (VRF). Each VRF represents a separate IP space or routing table. All prefixes not assigned to a VRF are considered to be in the "global" table.
|
||||
## Fields
|
||||
|
||||
Each prefix can be assigned a status and a role. These terms are often used interchangeably so it's important to recognize the difference between them. The **status** defines a prefix's operational state. Statuses are hard-coded in NetBox and can be one of the following:
|
||||
### Prefix
|
||||
|
||||
* Container - A summary of child prefixes
|
||||
* Active - Provisioned and in use
|
||||
* Reserved - Designated for future use
|
||||
* Deprecated - No longer in use
|
||||
The IPv4 or IPv6 network this prefix represents.
|
||||
|
||||
On the other hand, a prefix's **role** defines its function. Role assignment is optional and roles are fully customizable. For example, you might create roles to differentiate between production and development infrastructure.
|
||||
### Status
|
||||
|
||||
A prefix may also be assigned to a VLAN. This association is helpful for associating address space with layer two domains. A VLAN may have multiple prefixes assigned to it.
|
||||
The prefix's operational status. Note that the status of a prefix does _not_ have any impact on its member [IP addresses](./ipaddress.md), which may have their statuses defined independently. The "container" status indicates that the prefix exists merely as a container for organizing child prefixes.
|
||||
|
||||
The prefix model include an "is pool" flag. If enabled, NetBox will treat this prefix as a range (such as a NAT pool) wherein every IP address is valid and assignable. This logic is used when identifying available IP addresses within a prefix. If this flag is disabled, NetBox will assume that the first and last (broadcast) address within an IPv4 prefix are unusable.
|
||||
!!! tip
|
||||
Additional statuses may be defined by setting `Prefix.status` under the [`FIELD_CHOICES`](../../configuration/data-validation.md#field_choices) configuration parameter.
|
||||
|
||||
### VRF
|
||||
|
||||
The [Virtual Routing and Forwarding](./vrf.md) instance in which this prefix exists.
|
||||
|
||||
!!! note
|
||||
VRF assignment is optional. Prefixes with no VRF assigned are considered to exist in the "global" table.
|
||||
|
||||
### Role
|
||||
|
||||
The user-defined functional [role](./role.md) assigned to the prefix.
|
||||
|
||||
### Is a Pool
|
||||
|
||||
Designates whether the prefix should be treated as a pool. If selected, the first and last IP addresses within the prefix (normally reserved as the network and broadcast addresses, respectively) will be considered usable. This option is ideal for documenting NAT pools.
|
||||
|
||||
### Mark Utilized
|
||||
|
||||
If selected, this prefix will report 100% utilization regardless of how many child objects have been defined within it.
|
||||
|
||||
### Site
|
||||
|
||||
The [site](../dcim/site.md) to which this prefix is assigned (optional).
|
||||
|
||||
### VLAN
|
||||
|
||||
The [VLAN](./vlan.md) to which this prefix is assigned (optional). This mapping is helpful for associating IP space with layer two domains. A VLAN may have multiple prefixes assigned to it.
|
||||
|
||||
@ -2,6 +2,18 @@
|
||||
|
||||
[Regional Internet registries](https://en.wikipedia.org/wiki/Regional_Internet_registry) are responsible for the allocation of globally-routable address space. The five RIRs are ARIN, RIPE, APNIC, LACNIC, and AFRINIC. However, some address space has been set aside for internal use, such as defined in RFCs 1918 and 6598. NetBox considers these RFCs as a sort of RIR as well; that is, an authority which "owns" certain address space. There also exist lower-tier registries which serve particular geographic areas.
|
||||
|
||||
Users can create whatever RIRs they like, but each aggregate must be assigned to one RIR. The RIR model includes a boolean flag which indicates whether the RIR allocates only private IP space.
|
||||
Users can create whatever RIRs they like, but each [aggregate](./aggregate.md) must be assigned to one RIR. For example, suppose your organization has been allocated 104.131.0.0/16 by ARIN. It also makes use of RFC 1918 addressing internally. You would first create RIRs named "ARIN" and "RFC 1918," then create an aggregate for each of these top-level prefixes, assigning it to its respective RIR.
|
||||
|
||||
For example, suppose your organization has been allocated 104.131.0.0/16 by ARIN. It also makes use of RFC 1918 addressing internally. You would first create RIRs named "ARIN" and "RFC 1918," then create an aggregate for each of these top-level prefixes, assigning it to its respective RIR.
|
||||
## Fields
|
||||
|
||||
### Name
|
||||
|
||||
A unique human-friendly name.
|
||||
|
||||
### Slug
|
||||
|
||||
A unique URL-friendly identifier. (This value can be used for filtering.)
|
||||
|
||||
### Private
|
||||
|
||||
Designates this RIR as an authority for private/local IP space only (e.g. an RFC).
|
||||
|
||||
@ -1,3 +1,17 @@
|
||||
# Prefix/VLAN Roles
|
||||
|
||||
A role indicates the function of a prefix or VLAN. For example, you might define Data, Voice, and Security roles. Generally, a prefix will be assigned the same functional role as the VLAN to which it is assigned (if any).
|
||||
|
||||
## Fields
|
||||
|
||||
### Name
|
||||
|
||||
A unique human-friendly name.
|
||||
|
||||
### Slug
|
||||
|
||||
A unique URL-friendly identifier. (This value can be used for filtering.)
|
||||
|
||||
### Weight
|
||||
|
||||
A numeric weight employed to influence the ordering of roles. Roles with a lower weight will be listed before those with higher weights.
|
||||
|
||||
@ -2,4 +2,8 @@
|
||||
|
||||
A route target is a particular type of [extended BGP community](https://tools.ietf.org/html/rfc4360#section-4) used to control the redistribution of routes among VRF tables in a network. Route targets can be assigned to individual VRFs in NetBox as import or export targets (or both) to model this exchange in an L3VPN. Each route target must be given a unique name, which should be in a format prescribed by [RFC 4364](https://tools.ietf.org/html/rfc4364#section-4.2), similar to a VR route distinguisher.
|
||||
|
||||
Each route target can optionally be assigned to a tenant, and may have tags assigned to it.
|
||||
## Fields
|
||||
|
||||
### Name
|
||||
|
||||
The route target identifier formatted in accordance with [RFC 4360](https://tools.ietf.org/html/rfc4360).
|
||||
|
||||
@ -1,5 +1,23 @@
|
||||
# Services
|
||||
|
||||
A service represents a layer four TCP or UDP service available on a device or virtual machine. For example, you might want to document that an HTTP service is running on a device. Each service includes a name, protocol, and port number; for example, "SSH (TCP/22)" or "DNS (UDP/53)."
|
||||
A service represents a layer seven application available on a device or virtual machine. For example, a service might be created in NetBox to represent an HTTP server running on TCP/8000. Each service may optionally be further bound to one or more specific interfaces assigned to the selected device or virtual machine.
|
||||
|
||||
A service may optionally be bound to one or more specific IP addresses belonging to its parent device or VM. (If no IP addresses are bound, the service is assumed to be reachable via any assigned IP address.)
|
||||
To aid in the efficient creation of services, users may opt to first create a [service template](./servicetemplate.md) from which service definitions can be quickly replicated.
|
||||
|
||||
## Fields
|
||||
|
||||
### Name
|
||||
|
||||
A service or protocol name.
|
||||
|
||||
### Protocol
|
||||
|
||||
The wire protocol on which the service runs. Choices include UDP, TCP, and SCTP.
|
||||
|
||||
### Ports
|
||||
|
||||
One or more numeric ports to which the service is bound. Multiple ports can be expressed using commas and/or hyphens. For example, `80,8001-8003` specifies ports 80, 8001, 8002, and 8003.
|
||||
|
||||
### IP Addresses
|
||||
|
||||
The [IP address(es)](./ipaddress.md) to which this service is bound. If no IP addresses are bound, the service is assumed to be reachable via any assigned IP address.
|
||||
|
||||
@ -1,3 +1,17 @@
|
||||
# Service Templates
|
||||
|
||||
Service templates can be used to instantiate services on devices and virtual machines. A template defines a name, protocol, and port number(s), and may optionally include a description. Services can be instantiated from templates and applied to devices and/or virtual machines, and may be associated with specific IP addresses.
|
||||
Service templates can be used to instantiate [services](./service.md) on [devices](../dcim/device.md) and [virtual machines](../virtualization/virtualmachine.md).
|
||||
|
||||
## Fields
|
||||
|
||||
### Name
|
||||
|
||||
A service or protocol name.
|
||||
|
||||
### Protocol
|
||||
|
||||
The wire protocol on which the service runs. Choices include UDP, TCP, and SCTP.
|
||||
|
||||
### Ports
|
||||
|
||||
One or more numeric ports to which the service is bound. Multiple ports can be expressed using commas and/or hyphens. For example, `80,8001-8003` specifies ports 80, 8001, 8002, and 8003.
|
||||
|
||||
@ -1,11 +1,28 @@
|
||||
# VLANs
|
||||
|
||||
A VLAN represents an isolated layer two domain, identified by a name and a numeric ID (1-4094) as defined in [IEEE 802.1Q](https://en.wikipedia.org/wiki/IEEE_802.1Q). VLANs are arranged into VLAN groups to define scope and to enforce uniqueness.
|
||||
A Virtual LAN (VLAN) represents an isolated layer two domain, identified by a name and a numeric ID (1-4094) as defined in [IEEE 802.1Q](https://en.wikipedia.org/wiki/IEEE_802.1Q). VLANs are arranged into [VLAN groups](./vlangroup.md) to define scope and to enforce uniqueness.
|
||||
|
||||
Each VLAN must be assigned one of the following operational statuses:
|
||||
## Fields
|
||||
|
||||
* Active
|
||||
* Reserved
|
||||
* Deprecated
|
||||
### ID
|
||||
|
||||
As with prefixes, each VLAN may also be assigned a functional role. Prefixes and VLANs share the same set of customizable roles.
|
||||
A 12-bit numeric ID for the VLAN, 1-4094 (inclusive).
|
||||
|
||||
### Name
|
||||
|
||||
The configured VLAN name.
|
||||
|
||||
### Status
|
||||
|
||||
The VLAN's operational status.
|
||||
|
||||
!!! tip
|
||||
Additional statuses may be defined by setting `VLAN.status` under the [`FIELD_CHOICES`](../../configuration/data-validation.md#field_choices) configuration parameter.
|
||||
|
||||
### Role
|
||||
|
||||
The user-defined functional [role](./role.md) assigned to the VLAN.
|
||||
|
||||
### VLAN Group or Site
|
||||
|
||||
The [VLAN group](./vlangroup.md) or [site](../dcim/site.md) to which the VLAN is assigned.
|
||||
|
||||
@ -1,7 +1,23 @@
|
||||
# VLAN Groups
|
||||
|
||||
VLAN groups can be used to organize VLANs within NetBox. Each VLAN group can be scoped to a particular region, site group, site, location, rack, cluster group, or cluster. Member VLANs will be available for assignment to devices and/or virtual machines within the specified scope.
|
||||
VLAN groups can be used to organize [VLANs](./vlan.md) within NetBox. Each VLAN group can be scoped to a particular [region](../dcim/region.md), [site group](../dcim/sitegroup.md), [site](../dcim/sitegroup.md), [location](../dcim/location.md), [rack](../dcim/rack.md), [cluster group](../virtualization/clustergroup.md), or [cluster](../virtualization/cluster.md). Member VLANs will be available for assignment to devices and/or virtual machines within the specified scope.
|
||||
|
||||
Groups can also be used to enforce uniqueness: Each VLAN within a group must have a unique ID and name. VLANs which are not assigned to a group may have overlapping names and IDs (including VLANs which belong to a common site). For example, two VLANs with ID 123 may be created, but they cannot both be assigned to the same group.
|
||||
|
||||
## Fields
|
||||
|
||||
### Name
|
||||
|
||||
A unique human-friendly name.
|
||||
|
||||
### Slug
|
||||
|
||||
A unique URL-friendly identifier. (This value can be used for filtering.)
|
||||
|
||||
### Minimum & Maximum VLAN IDs
|
||||
|
||||
A minimum and maximum child VLAN ID must be set for each group. (These default to 1 and 4094 respectively.) VLANs created within a group must have a VID that falls between these values (inclusive).
|
||||
|
||||
Groups can also be used to enforce uniqueness: Each VLAN within a group must have a unique ID and name. VLANs which are not assigned to a group may have overlapping names and IDs (including VLANs which belong to a common site). For example, you can create two VLANs with ID 123, but they cannot both be assigned to the same group.
|
||||
### Scope
|
||||
|
||||
The domain covered by a VLAN group, defined as one of the supported object types. This conveys the context in which a VLAN group applies.
|
||||
|
||||
@ -1,14 +1,26 @@
|
||||
# Virtual Routing and Forwarding (VRF)
|
||||
|
||||
A VRF object in NetBox represents a virtual routing and forwarding (VRF) domain. Each VRF is essentially a separate routing table. VRFs are commonly used to isolate customers or organizations from one another within a network, or to route overlapping address space (e.g. multiple instances of the 10.0.0.0/8 space). Each VRF may be assigned to a specific tenant to aid in organizing the available IP space by customer or internal user.
|
||||
A VRF object in NetBox represents a Virtual Routing and Forwarding (VRF) domain. Each VRF is essentially an independent routing table. VRFs are commonly used to isolate customers or organizations from one another within a network, or to route overlapping address space (e.g. multiple instances of the 10.0.0.0/8 space). Each VRF may be assigned to a specific tenant to aid in organizing the available IP space by customer or internal user.
|
||||
|
||||
Each VRF is assigned a unique name and an optional route distinguisher (RD). The RD is expected to take one of the forms prescribed in [RFC 4364](https://tools.ietf.org/html/rfc4364#section-4.2), however its formatting is not strictly enforced.
|
||||
Each [prefix](./prefix.md), [IP range](./iprange.md), and [IP address](./ipaddress.md) may be assigned to one (and only one) VRF. If you have a prefix or IP address which exists in multiple VRFs, you will need to create a separate instance of it in NetBox for each VRF. Any such object not assigned to a VRF is said to belong to the "global" table.
|
||||
|
||||
Each prefix and IP address may be assigned to one (and only one) VRF. If you have a prefix or IP address which exists in multiple VRFs, you will need to create a separate instance of it in NetBox for each VRF. Any prefix or IP address not assigned to a VRF is said to belong to the "global" table.
|
||||
## Fields
|
||||
|
||||
By default, NetBox will allow duplicate prefixes to be assigned to a VRF. This behavior can be toggled by setting the "enforce unique" flag on the VRF model.
|
||||
### Name
|
||||
|
||||
The configured or administrative name for the VRF instance.
|
||||
|
||||
### Route Distinguisher
|
||||
|
||||
A route distinguisher is used to map routes to VRFs within a device's routing table e.g. for MPLS/VPN. The assignment of a route distinguisher is optional. If defined, the RD is expected to take one of the forms prescribed in [RFC 4364](https://tools.ietf.org/html/rfc4364#section-4.2), however its formatting is not strictly enforced.
|
||||
|
||||
### Enforce Unique Space
|
||||
|
||||
By default, NetBox will permit duplicate prefixes to be assigned to a VRF. This behavior can be toggled by setting the "enforce unique" flag on the VRF model.
|
||||
|
||||
!!! note
|
||||
Enforcement of unique IP space can be toggled for global table (non-VRF prefixes) using the `ENFORCE_GLOBAL_UNIQUE` configuration setting.
|
||||
|
||||
Each VRF may have one or more import and/or export route targets applied to it. Route targets are used to control the exchange of routes (prefixes) among VRFs in L3VPNs.
|
||||
### Import & Export Targets
|
||||
|
||||
Each VRF may have one or more import and/or export [route targets](./routetarget.md) applied to it. Route targets are used to control the exchange of routes (prefixes) among VRFs in L3VPNs.
|
||||
|
||||
Reference in New Issue
Block a user