F5 → Nautobot: How to Model F5 VELOS in Nautobot

This guide defines a recommended way to represent an F5 VELOS platform inside Nautobot.

VELOS does not map cleanly into a simple parent/child device hierarchy. It contains physical containment relationships, logical virtualization relationships, and network relationships that cross those boundaries.

The goal is to model VELOS in a way that accurately represents the F5 architecture while still using Nautobot-native objects wherever possible.

The recommended model separates physical infrastructure (VELOS Chassis with its Controllers and Blades) from logical infrastructure (Chassis Partition, BIG-IP Tenant, Administrative Partition, Route Domain).

The overall model should look approximately like this:

VELOS Chassis
│
├── System Controller 1
├── System Controller 2
│
├── Blade 1
├── Blade 2
├── Blade 3
└── Blade 4

        │
        │ logical allocation
        ▼

Chassis Partition: PROD
│
├── Blade 1
├── Blade 2
├── Blade 3
└── Blade 4
│
├── BIG-IP Tenant A
│   │
│   ├── /Common
│   │   └── Route Domain 0
│   │
│   ├── /Payments
│   │   └── Route Domain 10
│   │
│   └── /Corporate
│       └── Route Domain 20
│
└── BIG-IP Tenant B
    └── ...

1. VELOS Chassis

Represent each VELOS chassis as a Nautobot Device.

Device Name:  DC1-VELOS01
Device Type:  F5 VELOS
Role:         Application Delivery Platform
Location:     DC1 / Rack A12

The VELOS chassis is the physical root of the hardware model. Do not represent every internal VELOS component as a separate Nautobot Device.

2. System Controllers

Represent VELOS System Controllers as Nautobot Modules installed in module bays belonging to the chassis.

DC1-VELOS01
├── Controller Bay 1
│   └── System Controller 1
└── Controller Bay 2
    └── System Controller 2

Example Nautobot objects: Device DC1-VELOS01, Module Bay Controller-1, Module System-Controller-1.

This preserves the physical relationship between the controller and the chassis.

3. VELOS Blades

Represent VELOS blades as Nautobot Modules. Create a module bay for every physical chassis slot.

DC1-VELOS01
├── Slot 1
│   └── Blade 1
├── Slot 2
│   └── Blade 2
├── Slot 3
│   └── Blade 3
└── Slot 4
    └── Blade 4

This represents physical hardware placement. The blade should not normally be modeled as a Nautobot Device because it operates as part of the VELOS chassis.

4. Chassis Partitions

Represent each VELOS Chassis Partition as a Nautobot Cluster. Recommended Cluster Type: F5 VELOS Chassis Partition.

DC1-VELOS01-CP-PROD
DC1-VELOS01-CP-NONPROD
DC1-VELOS01-CP-DNS

A Chassis Partition represents a logical compute boundary inside the physical chassis.

VELOS Chassis
    │
    ├── Chassis Partition PROD
    ├── Chassis Partition NONPROD
    └── Chassis Partition DNS

The relationship between a chassis and its Chassis Partitions is logical rather than physical containment.

5. Chassis Partition to Blade Assignment

A Chassis Partition consumes one or more VELOS blades. Model this using a custom relationship.

Recommended relationship: VELOS Chassis Partition Blades. Source: Cluster. Destination: Module. Type: One-to-Many.

CP-PROD
├── Blade 1
├── Blade 2
├── Blade 3
└── Blade 4

6. BIG-IP Tenants

Represent each BIG-IP VELOS tenant as a Nautobot Virtual Machine. The VM should belong to the Cluster representing the VELOS Chassis Partition.

Cluster: DC1-VELOS01-CP-PROD

Virtual Machines:
    BIGIP-LTM-01
    BIGIP-LTM-02
    BIGIP-DNS-01
    BIGIP-APM-01

VELOS Chassis
    │
    ▼
Chassis Partition
    │
    ├── BIGIP-LTM-01
    ├── BIGIP-LTM-02
    └── BIGIP-DNS-01

7. Tenant to Blade Placement

A BIG-IP tenant may run across multiple blades within its Chassis Partition. This is different from the blades assigned to the overall Chassis Partition.

Chassis Partition PROD

    Blade 1
    Blade 2
    Blade 3
    Blade 4

Tenant placement:

    BIGIP-LTM-01
        Blade 1
        Blade 2

    BIGIP-LTM-02
        Blade 3
        Blade 4

    BIGIP-DNS-01
        Blade 1
        Blade 2
        Blade 3
        Blade 4

Create a many-to-many custom relationship. Recommended relationship: VELOS Tenant Blade Placement. Source: Virtual Machine. Destination: Module. Type: Many-to-Many.

This allows Nautobot to answer questions such as:

• Which blades host this tenant?
• Which tenants are using this blade?
• Which tenants will be affected if a blade is taken out of service?
• How is tenant capacity distributed across a chassis?

8. VLAN Groups

Create a Nautobot VLAN Group for each VELOS Chassis Partition.

VLAN Group: DC1-VELOS01-CP-PROD

VLANs:
    100 FRONTEND
    110 BACKEND
    200 SERVICES
    500 TRANSIT

Chassis Partition PROD
        │
        ▼
    VLAN Group
        │
        ├── VLAN 100
        ├── VLAN 110
        ├── VLAN 200
        └── VLAN 500

Using a VLAN Group gives the VLANs an appropriate Nautobot scope and helps avoid ambiguity where VLAN IDs may be reused elsewhere.

9. Tenant VLAN Assignment

VLAN assignment is not simply parent/child. A VLAN can be presented to more than one BIG-IP tenant.

             VLAN 100
             /      \
            /        \
BIGIP-LTM-01      BIGIP-LTM-02

Create a custom many-to-many relationship. Recommended relationship: VELOS Tenant VLANs. Source: Virtual Machine. Destination: VLAN. Type: Many-to-Many.

This allows Nautobot to answer:

• Which VLANs are assigned to this BIG-IP tenant?
• Which tenants can see VLAN 100?
• Is a network currently presented to more than one tenant?

10. BIG-IP Administrative Partitions

BIG-IP Administrative Partitions such as /Common, /Payments, /Corporate, and /DMZ should not be represented using the Nautobot Tenant object.

The Nautobot Tenant object should remain available for business ownership: customers, departments, application owners, or organizational tenancy.

Instead, create a custom Nautobot model such as F5 Administrative Partition. Recommended fields:

• Name
• BIG-IP Tenant
• Description
• Default Route Domain
• Status

BIGIP-LTM-01
│
├── /Common
├── /Payments
├── /Corporate
└── /DMZ

Recommended relationship: BIG-IP Tenant (1) to F5 Administrative Partition (N).

11. Route Domains

Represent BIG-IP Route Domains as Nautobot VRFs.

BIGIP-LTM-01-RD0
BIGIP-LTM-01-RD10
BIGIP-LTM-01-RD20

Recommended VRF custom fields:

• f5_route_domain_id
• f5_strict_isolation
• f5_is_partition_default
• f5_bigip_partition

/Common
    Route Domain 0

/Payments
    Route Domain 10

/Corporate
    Route Domain 20

Recommended relationship: F5 Administrative Partition (1) to VRF (N). This maintains the distinction between the BIG-IP Administrative Partition, the BIG-IP Route Domain, and the Nautobot VRF.

12. Route Domain Parent Relationships

Route Domains can have parent Route Domains. This relationship is independent of the Administrative Partition structure.

             RD 0
            /    \
           /      \
        RD 10     RD 20
          |
        RD 11

This means RD 10 parent = RD 0, RD 20 parent = RD 0, and RD 11 parent = RD 10.

Create a self-referential VRF relationship. Recommended relationship: F5 Route Domain Parent. Source: VRF. Destination: VRF. Type: Many-to-One.

/Payments
    RD10
      |
      | parent
      ▼
/Common
    RD0

13. Namespaces and Duplicate Address Space

BIG-IP Route Domains allow overlapping IP address space. For example, Route Domain 10 and Route Domain 20 may both contain 10.10.10.0/24. These are different routing domains and both networks may legitimately exist.

To preserve this behavior in Nautobot, use a separate Namespace for each Route Domain where overlapping IP space may occur.

Namespace: BIGIP-LTM-01-RD10
VRF:       BIGIP-LTM-01-RD10
Prefix:    10.10.10.0/24

and:

Namespace: BIGIP-LTM-01-RD20
VRF:       BIGIP-LTM-01-RD20
Prefix:    10.10.10.0/24

14. Route Domain to VLAN Relationships

Route Domains and VLANs should also be explicitly related.

Recommended relationship: F5 Route Domain VLANs. Source: VRF. Destination: VLAN. Type: One-to-Many or Many-to-Many depending on organizational requirements.

RD10
│
├── VLAN 100 FRONTEND
└── VLAN 110 BACKEND

This relationship allows automation to determine which networks participate in a particular BIG-IP routing domain.

15. BIG-IP HA Relationships

BIG-IP HA peers should not be represented using parent/child relationships. Two BIG-IP tenants may reside in different Chassis Partitions, on different VELOS chassis, in different racks, or in different data centers while still participating in the same BIG-IP HA configuration.

VELOS-DC1-01
    |
    +-- CP-PROD
         |
         +-- BIGIP-LTM-01
                  |
                  | HA
                  |
         +----------------------+
                                |
VELOS-DC2-01                    |
    |                           |
    +-- CP-PROD                 |
         |                      |
         +-- BIGIP-LTM-02 <----+

Create a custom relationship. Recommended relationship: F5 HA Peer. Source: Virtual Machine. Destination: Virtual Machine. Type: Many-to-Many.

If the organization enforces strictly paired BIG-IP systems, this may instead be implemented as a one-to-one relationship.

The following matrix summarizes which objects are true containment relationships and which should be modeled as relationships.

The following Nautobot custom relationships should be created.

Consider the following physical environment:

DC1-VELOS01

Controllers:
    Controller 1
    Controller 2

Blades:
    Blade 1
    Blade 2
    Blade 3
    Blade 4

A production Chassis Partition exists: DC1-VELOS01-CP-PROD. It uses Blade 1 through Blade 4.

The partition hosts BIGIP-LTM-01, BIGIP-LTM-02, and BIGIP-DNS-01. Tenant blade placement:

BIGIP-LTM-01
    Blade 1
    Blade 2

BIGIP-LTM-02
    Blade 3
    Blade 4

BIGIP-DNS-01
    Blade 1
    Blade 2
    Blade 3
    Blade 4

The Chassis Partition contains VLAN 100 FRONTEND, VLAN 110 BACKEND, and VLAN 500 TRANSIT. BIGIP-LTM-01 receives VLAN 100, VLAN 110, and VLAN 500.

BIGIP-LTM-01 contains:

/Common
    RD0

/Payments
    RD10

/Corporate
    RD20

Route Domain parentage: RD10 to RD0, and RD20 to RD0.

The resulting logical Nautobot representation is:

DEVICE
DC1-VELOS01
│
├── MODULE Controller-1
├── MODULE Controller-2
├── MODULE Blade-1
├── MODULE Blade-2
├── MODULE Blade-3
└── MODULE Blade-4

CLUSTER
DC1-VELOS01-CP-PROD
│
├── VM BIGIP-LTM-01
├── VM BIGIP-LTM-02
└── VM BIGIP-DNS-01

BIGIP-LTM-01
│
├── F5 Partition /Common
│       │
│       └── VRF RD0
│
├── F5 Partition /Payments
│       │
│       └── VRF RD10
│
└── F5 Partition /Corporate
        │
        └── VRF RD20

Cross-cutting relationships:

CP-PROD
    -> Blade 1
    -> Blade 2
    -> Blade 3
    -> Blade 4

BIGIP-LTM-01
    -> Blade 1
    -> Blade 2

BIGIP-LTM-02
    -> Blade 3
    -> Blade 4

BIGIP-LTM-01
    -> VLAN 100
    -> VLAN 110
    -> VLAN 500

RD10
    -> Parent RD0

RD20
    -> Parent RD0

BIGIP-LTM-01
    <-> HA Peer BIGIP-LTM-02

The primary Nautobot object model should therefore be:

Device
    VELOS Chassis

Module
    System Controller
    VELOS Blade

Cluster
    VELOS Chassis Partition

Virtual Machine
    BIG-IP Tenant

VLAN Group
    VELOS Chassis Partition VLAN scope

VLAN
    VELOS VLAN

Custom Model
    F5 Administrative Partition

VRF
    BIG-IP Route Domain

Namespace
    BIG-IP Route Domain address-space boundary

Prefix
    Network/Subnet

IP Address
    Self IP, Floating IP, Management IP, Service IP

Custom relationships:

Cluster -> Module              VELOS Chassis Partition Blades
VM      -> Module              VELOS Tenant Blade Placement
VM      -> VLAN                VELOS Tenant VLANs
VM      -> Admin Partition     BIG-IP Administrative Partitions
Admin   -> VRF                 F5 Partition Route Domains
VRF     -> VRF                 F5 Route Domain Parent
VRF     -> VLAN                F5 Route Domain VLANs
VM      <-> VM                 F5 HA Peer

When adding VELOS systems to Nautobot, follow these rules:

1. A VELOS chassis is a Nautobot Device.
2. Controllers and blades are Modules inside the chassis.
3. A VELOS Chassis Partition is a Nautobot Cluster.
4. A BIG-IP tenant is a Nautobot Virtual Machine belonging to that Cluster.
5. Physical blade allocation to a Chassis Partition is a relationship, not physical containment.
6. BIG-IP tenant blade placement is a separate many-to-many relationship.
7. VLANs are scoped using a VLAN Group associated with the Chassis Partition.
8. Tenant-to-VLAN assignment is many-to-many.
9. Do not use Nautobot Tenant objects for BIG-IP Administrative Partitions.
10. BIG-IP Administrative Partitions should use a dedicated custom model.
11. BIG-IP Route Domains should be represented as VRFs.
12. Route Domain parentage should be explicitly modeled and must not be inferred from the Administrative Partition hierarchy.
13. Use a dedicated Namespace per Route Domain when overlapping address space must be supported.
14. BIG-IP HA relationships should be modeled independently from chassis, blade, Cluster, and data-center placement.
15. Keep physical containment, logical ownership, network relationships, and HA relationships separate.

This design preserves the real separation between the layers of VELOS:

PHYSICAL

Datacenter
    ↓
Rack
    ↓
VELOS Chassis
    ↓
Controller / Blade

COMPUTE / VIRTUALIZATION

VELOS Chassis
    ↓
Chassis Partition
    ↓
BIG-IP Tenant

BIG-IP LOGICAL CONFIGURATION

BIG-IP Tenant
    ↓
Administrative Partition
    ↓
Route Domain

Each layer keeps its own identity in Nautobot, so physical inventory, compute allocation, and BIG-IP configuration can be modeled, queried, and automated independently. Nothing is forced into a parent/child hierarchy it does not actually have.