Skip to content

IP Address Management

Regional Internet Registries (RIRs)

Regional Internet registries 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. Nautobot 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 and optionally assign prefixes to an RIR. The RIR model includes a boolean flag which indicates whether the RIR allocates only private IP space.

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 a prefix for each of these top-level networks, assigning it to its respective RIR.

Changed in version 2.0.0

The Aggregate model and its relationships to RIR were migrated to the Prefix model.

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.)

Each prefix can be assigned to a particular site (optionally also to a location within the site) and a 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.

Each prefix must be assigned a status and can optionally be assigned 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. The following statuses are provided by default:

  • Active - Provisioned and in use
  • Reserved - Designated for future use
  • Deprecated - No longer in use

Changed in version 2.0.0

The "Container" status was removed and its functionality was replaced by the Prefix.type field.

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.

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 model can be set to one of three types through the type field. The valid prefix types are:

  • Container
  • Network (default)
  • Pool

If a prefix's type is set to "Pool", Nautobot 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 type is set to "Container" or "Network", Nautobot will assume that the first and last (network and broadcast) addresses within an IPv4 prefix are unusable.

Changed in version 2.0.0

The is_pool field was removed and its functionality was replaced by the Prefix.type field.

A prefix can be assigned to an RIR to track which RIR has granted your organization permission to use the specified IP space on the public Internet.

The date_allocated field can be used to track any date and time you would like to define as the "allocated date" for a prefix. This could be the date an RIR assigned a prefix to your organization or the date a prefix was assigned to a specific internal team.

Added in version 2.0.0

The date_allocated and rir fields were added, migrating data from the removed Aggregate model.

Roles

The Role model represents a role that can be assigned to a device, rack, virtual machine, IP address, VLAN, or prefix. Each role is identified by a unique name and has a slug, weight, color and content-types associated with it.

Role Basics

The value of a role field on a model (such as Device.role) will be represented as a nautobot.extras.models.Role object.

When created, a Role can be associated to one or more model content-types using a many-to-many relationship. The relationship to each model is referenced across all user interfaces using the {app_label}.{model} naming convention (e.g. dcim.device).

Roles may be managed by navigating to Organization > Roles in the navigation menu.

Importing Objects with a role Field

When using CSV import to reference a role field on an object, the Role.name field is used.

Visit role-internals to learn more about working with role as a developer.

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.

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. The following statuses are available by default:

  • 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

When primary IPs are set for both IPv4 and IPv6, Nautobot will prefer IPv6. This can be changed by setting the PREFER_IPV4 configuration parameter.

Changed in version 2.0.0

prefix_length becomes mask_length and is intended to describe the desired subnet mask of the IP addresses when configured on interface(s).

Network Address Translation (NAT)

An IP address can be designated as the network address translation (NAT) inside IP address for one or more other IP addresses. 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.

Added in version 1.3.0

Support for multiple outside NAT IP addresses was added.

Virtual Routing and Forwarding (VRF)

A VRF object in Nautobot 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.

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, however its formatting is not strictly enforced.

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 Nautobot for each VRF. Any prefix or IP address not assigned to a VRF is said to belong to the "global" table.

By default, Nautobot 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.

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.

Route Targets

A route target is a particular type of extended BGP community used to control the redistribution of routes among VRF tables in a network. Route targets can be assigned to individual VRFs in Nautobot 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, similar to a VR route distinguisher.

Each route target can optionally be assigned to a tenant, and may have tags assigned to it.