Network Objects

The following are example declarations that contain networking objects.

Adding Route Domains to a declaration

In this example, we show how to use a Route Domain in a declaration. A route domain is a configuration object that isolates network traffic for a particular application on the network. For more information on Route Domains, see Route Domain documentation.

In the following declaration, we include a VLAN to show how to reference a VLAN that is being created. The SelfIp and the Route both show using the RouteDomain with %100, which is the id of the RouteDomain.

New in DO 1.17
Declarative Onboarding 1.17 added support for specifying a parent route domain. This is the route domain the system searches when it cannot find a route in the configured domain.

Important

The following declaration has been updated to include the parent property introduced in DO 1.17. If you attempt to use this declaration on a prior version, it will fail unless you remove the parent property.

{
    "schemaVersion": "1.0.0",
    "class": "Device",
    "async": true,
    "Common": {
        "class": "Tenant",
        "hostname": "bigip.example.com",
        "newVlan": {
            "class": "VLAN",
            "tag": 100,
            "interfaces": [
                {
                    "name": "1.1",
                    "tagged": true
                }
            ]
        },
        "Route": {
            "class": "Route",
            "gw": "10.1.0.1",
            "network": "192.168.0.0%100/16"
        },
        "newSelfIp": {
            "class": "SelfIp",
            "address": "10.1.0.20%100/0",
            "vlan": "newVlan"
        },
        "theRouteDomain": {
            "class": "RouteDomain",
            "id": 100,
            "bandWidthControllerPolicy": "bwcPol",
            "connectionLimit": 5432991,
            "flowEvictionPolicy": "default-eviction-policy",
            "ipIntelligencePolicy": "ip-intelligence",
            "enforcedFirewallPolicy": "enforcedPolicy",
            "stagedFirewallPolicy": "stagedPolicy",
            "securityNatPolicy": "securityPolicy",
            "servicePolicy": "servicePolicy",
            "strict": false,
            "routingProtocols": [
                "BGP"
            ],
            "vlans": [
                "newVlan"
            ]
        },
        "AnotherRouteDomain": {
            "class": "RouteDomain",
            "id": 101,
            "parent": "theRouteDomain"
        }
    }
}

Back to top


Setting the DAG IPv6 prefix length

In this example, we show how to use the DagGlobals class to set or modify the DAG global IPv6 prefix length. DAG Globals contain the global disaggregation settings; see the Disaggregation DAG modes documentation for more information.

In the following declaration snippet, we show only the DagGlobals class. You can use this class as a part of a larger Declarative Onboarding declaration.

{
    "schemaVersion": "1.0.0",
    "class": "Device",
    "async": false,
    "Common": {
        "class": "Tenant",
        "dagGlobals": {
            "class": "DagGlobals",
            "icmpHash": "ipicmp",
            "ipv6PrefixLength": 101,
            "roundRobinMode": "local"
        }
    }
}

Back to top

Configuring Traffic Control properties

In this example, we show how you can configure BIG-IP LTM global traffic control settings (ltm global-settings traffic-control) using a Declarative Onboarding declaration. For descriptions and usage details on these properties, see TrafficControl Class in the Schema Reference.

In the following declaration snippet we show only the classes related to Traffic Control. You can use this class as a part of a larger Declarative Onboarding declaration.

{
    "schemaVersion": "1.7.0",
    "class": "Device",
    "label": "Configuring traffic control",
    "async": true,
    "Common": {
        "class": "Tenant",
        "myglobals": {
            "class": "TrafficControl",
            "acceptIpOptions": true,
            "acceptIpSourceRoute": true,
            "allowIpSourceRoute": true,
            "continueMatching": true,
            "maxIcmpRate": 867,
            "maxPortFindLinear": 867,
            "maxPortFindRandom": 867,
            "maxRejectRate": 867,
            "maxRejectRateTimeout": 200,
            "minPathMtu": 867,
            "pathMtuDiscovery": false,
            "portFindThresholdWarning": false,
            "portFindThresholdTrigger": 10,
            "portFindThresholdTimeout": 200,
            "rejectUnmatched": false
        }
    }
}

Back to top


Using the CMP Hash property in a VLAN

Starting in 1.7.0, you have the option of using the cmp-hash property on a VLAN. The CMP Hash setting allows all connections from a client system to use the same set of TMMs, improving system performance. For more information, see Additional VLAN Configuration Options in the BIG-IP documentation. You can also see VLAN Class in the Schema Reference for usage options.

In the following declaration snippet we show only the VLAN class with cmp-hash using Source Address as the traffic disaggregation method. You can use this class as a part of a larger Declarative Onboarding declaration.

{
    "schemaVersion": "1.7.0",
    "class": "Device",
    "async": true,
    "webhook": "https://example.com/myHook",
    "Common": {
        "class": "Tenant",
        "external": {
            "class": "VLAN",
            "tag": 4094,
            "mtu": 1500,
            "interfaces": [
                {
                    "name": "1.1",
                    "tagged": true
                }
            ],
            "cmpHash": "src-ip"
        }
    }
}

Back to top


Configuring MAC Masquerading on Traffic Groups

In this example, we show how you can configure MAC Masquerading on Traffic Groups. This is a part of the new MAC_Masquerade class.

For detailed information about Mac Masquerade on the BIG-IP, see K13502: Configuring MAC masquerade.

See Mac_Masquerade in the Schema Reference for DO usage and options.

{
    "schemaVersion": "1.13.0",
    "class": "Device",
    "async": false,
    "Common": {
        "class": "Tenant",
        "myMac": {
            "class": "MAC_Masquerade",
            "source": {
                "interface": "1.1"
            },
            "trafficGroup": "traffic-group-1"
        }
    }
}

Back to top


Configuring VLAN Failsafe

In this example, we show how you can configure VLAN Failsafe settings in a Declarative Onboarding declaration. This is a part of the VLAN Class, and includes the new properties failsafeEnabled, failsafeAction, and failsafeTimeout.

For detailed information about VLAN Failsafe on the BIG-IP, see K13297: Overview of VLAN failsafe.

See VLAN Class in the Schema Reference for DO usage and options.

{
    "schemaVersion": "1.14.0",
    "class": "Device",
    "async": true,
    "Common": {
        "class": "Tenant",
        "external": {
            "class": "VLAN",
            "tag": 4094,
            "mtu": 1500,
            "interfaces": [
                {
                    "name": "1.1",
                    "tagged": true
                }
            ],
            "failsafeEnabled": true,
            "failsafeAction": "reboot",
            "failsafeTimeout": 300
        }
    }
}

Back to top


Configuring a DNS Resolver

In this example, we show how you create a DNS Resolver in a Declarative Onboarding declaration using the DNS_Resolver class introduced in DO 1.14. The DNS Resolver is the internal DNS resolver the BIG-IP system uses to fetch the internal proxy response.

See DNS_Resolver in the Schema Reference for DO usage and options.

For detailed information about the DNS Resolver, see BIG-IP DNS documentation on AskF5.

{
    "schemaVersion": "1.0.0",
    "class": "Device",
    "async": false,
    "Common": {
        "class": "Tenant",
        "myResolver": {
            "class": "DNS_Resolver",
            "answerDefaultZones": false,
            "cacheSize": 5767168,
            "randomizeQueryNameCase": true,
            "routeDomain": "0",
            "forwardZones": [
                {
                    "name": "forward.net",
                    "nameservers": [
                        "10.10.10.10:53",
                        "10.10.10.11:53"
                    ]
                }
            ],
            "useIpv4": true,
            "useIpv6": true,
            "useTcp": true,
            "useUdp": true
        }
    }
}

Configuring a TCP Forward Tunnel

In this example, we show how you create a TCP Forward Network Tunnel in a Declarative Onboarding declaration using the Tunnel class.

Declarative Onboarding 1.24 adds two tunnel types: gre and geneve. In previous versions, tcp_forward, for forward proxy connections, was the only supported type of tunnel.

See Tunnel in the Schema Reference for DO usage and options. The following example only shows the tcp_forward tunnel type.

{
    "class": "Device",
    "schemaVersion": "1.14.0",
    "async": true,
    "Common": {
        "class": "Tenant",
        "newTcpForwardTunnel": {
            "class": "Tunnel",
            "tunnelType": "tcp-forward",
            "mtu": 2000,
            "usePmtu": false,
            "typeOfService": 123,
            "autoLastHop": "default"
        }
    }
}

Back to top


Configuring Traffic Groups

This example shows how to create Traffic Groups using Declarative Onboarding 1.14 and later. A traffic group is a group of configuration objects on a BIG-IP which is able to float to another device in a device group in case of failure. For more information, see Traffic Group class on the Clustering page, and BIG-IP Device Service Clustering: Administration.

See TrafficGroup in the Schema Reference for DO usage and options.

Important

The HA Score failover method is not currently supported. DO uses the HA Order failover method.

Because DO uses HA Order for failover, the declaration must include a hostname, located inside of a deviceGroup. In the following example, the declaration defines a Device Group with a host name. See Device Group class for information on Device Groups.

{
    "schemaVersion": "1.14.0",
    "class": "Device",
    "label": "Configuring System",
    "async": false,
    "Common": {
        "class": "Tenant",
        "hostname": "do.example.com",
        "failoverGroup": {
            "class": "DeviceGroup",
            "type": "sync-failover",
            "members": [
                "do.example.com"
            ],
            "owner": "do.example.com",
            "autoSync": true,
            "saveOnAutoSync": false,
            "networkFailover": true,
            "fullLoadOnSync": false,
            "asmSync": false
        },
        "testTrafficGroup": {
            "class": "TrafficGroup",
            "autoFailbackEnabled": false,
            "autoFailbackTime": 50,
            "failoverMethod": "ha-order",
            "haLoadFactor": 1,
            "haOrder": [
                "do.example.com"
            ]
        }
    }
}

Back to top


Configuring routing prefix lists

This example shows how you can create network routing prefix lists using Declarative Onboarding 1.18 and later. These prefix lists are a part of a larger BGP configuration, and enable you to specify allow and deny actions for each prefix address.

See RoutingPrefixList and RoutingPrefixList-Entries in the Schema Reference for DO usage and options.

New in DO 1.23
DO 1.23 introduced the ability to use strings for the prefixLengthRange range property. Previous versions would only accept integers.
Important If you try to use the following example on versions prior to 1.23, it will fail. If using a previous version, replace the values in the highlighted lines with integers.

The following example contains multiple prefix lists, but no other DO configuration. You can use this class as a part of a larger Declarative Onboarding declaration.

{
    "schemaVersion": "1.23.0",
    "class": "Device",
    "async": true,
    "Common": {
        "class": "Tenant",
        "hostname": "bigip.example.com",
        "exampleRoutingPrefixList1": {
            "class": "RoutingPrefixList",
            "entries": [
                {
                    "name": 10,
                    "action": "permit",
                    "prefix": "1111:2222::/127",
                    "prefixLengthRange": "128"
                },
                {
                    "name": 15,
                    "action": "deny",
                    "prefix": "f5f5:f5f5::/64",
                    "prefixLengthRange": "80:"
                }
            ]
        },
        "exampleRoutingPrefixList2": {
            "class": "RoutingPrefixList",
            "entries": [
                {
                    "name": 20,
                    "action": "permit",
                    "prefix": "10.3.3.0/24",
                    "prefixLengthRange": ":30"
                },
                {
                    "name": 30,
                    "action": "deny",
                    "prefix": "10.4.4.0/22",
                    "prefixLengthRange": "23:25"
                }
            ]
        }
    }
}

Back to top


Configuring BGP Routing in a declaration

This example shows how you can configure Border Gateway Protocol (BGP) routing in a Declarative Onboarding declaration.

For an excellent overview of BGP, see the F5 Lightboard lesson BGP overview.

Important

BGP Routing is an experimental (Early Access) feature on the BIG-IP system.

The BGP routing configuration uses the following Declarative Onboarding classes (some of the classes were introduced in previous versions of Declarative Onboarding, but the main RoutingBGP class, which is required to use BGP routing, was introduced in DO 1.20). The links go to the Schema Reference for descriptions and DO usage.

The RoutingBGP class contains a number of properties used in the following example, so be sure to see RoutingBGP for descriptions and options.

New in DO 1.24
Declarative Onboarding 1.24 introduced the ebgpMultihop property for BGP neighbors. This property allows you to specify between 1 and 255 external BGP members that are not on directly connected networks (the default is 1). See RoutingBGP_neighbors in the Schema Reference for more information.

Important

If you try to use the following example with a version prior to 1.24, it will fail. For previous versions, remove the lines in yellow.

{
    "schemaVersion": "1.20.0",
    "class": "Device",
    "async": true,
    "Common": {
        "class": "Tenant",
        "hostname": "bigip.example.com",
        "exampleRoutingAsPath1": {
            "class": "RoutingAsPath",
            "entries": [
                {
                    "name": 10,
                    "regex": "^165001 *"
                }
            ]
        },
        "exampleRoutingAsPath2": {
            "class": "RoutingAsPath",
            "entries": [
                {
                    "name": 20,
                    "regex": "^165005$"
                }
            ]
        },
        "exampleRoutingPrefixList1": {
            "class": "RoutingPrefixList",
            "entries": [
                {
                    "name": 20,
                    "action": "permit",
                    "prefix": "10.3.3.0/24",
                    "prefixLengthRange": 32
                }
            ]
        },
        "exampleRoutingPrefixList2": {
            "class": "RoutingPrefixList",
            "entries": [
                {
                    "name": 30,
                    "action": "deny",
                    "prefix": "10.4.4.0/23",
                    "prefixLengthRange": 24
                }
            ]
        },
        "exampleRouteMap1": {
            "class": "RouteMap",
            "entries": [
                {
                    "name": "33",
                    "action": "permit",
                    "match": {
                        "asPath": "exampleRoutingAsPath1",
                        "ipv4": {
                            "address": {
                                "prefixList": "exampleRoutingPrefixList1"
                            }
                        }
                    }
                }
            ]
        },
        "exampleRouteMap2": {
            "class": "RouteMap",
            "entries": [
                {
                    "name": "44",
                    "action": "deny",
                    "match": {
                        "asPath": "exampleRoutingAsPath2",
                        "ipv4": {
                            "address": {
                                "prefixList": "exampleRoutingPrefixList2"
                            }
                        }
                    }
                }
            ]
        },
        "exampleRoutingBGP": {
            "class": "RoutingBGP",
            "localAS": 65010,
            "addressFamilies": [
                {
                    "internetProtocol": "ipv4",
                    "redistributionList": [
                        {
                            "routingProtocol": "kernel",
                            "routeMap": "exampleRouteMap1"
                        },
                        {
                            "routingProtocol": "static",
                            "routeMap": "exampleRouteMap2"
                        }
                    ]
                }
            ],
            "gracefulRestart": {
                "gracefulResetEnabled": true,
                "restartTime": 120,
                "stalePathTime": 60
            },
            "holdTime": 35,
            "keepAlive": 10,
            "neighbors": [
                {
                    "address": "10.1.1.2",
                    "ebgpMultihop": 2,
                    "peerGroup": "Neighbor"
                },
                {
                    "address": "10.1.1.3",
                    "ebgpMultihop": 3,
                    "peerGroup": "Neighbor"
                }
            ],
            "peerGroups": [
                {
                    "name": "Neighbor",
                    "addressFamilies": [
                        {
                            "internetProtocol": "ipv4",
                            "routeMap": {
                                "in": "exampleRouteMap1",
                                "out": "exampleRouteMap2"
                            },
                            "softReconfigurationInboundEnabled": true
                        }
                    ],
                    "remoteAS": 65020
                }
            ],
            "routerId": "10.1.1.1"
        }
    }
}

Configuring a Firewall policy in a declaration

This example shows how you can configure a firewall policy in a declaration. BIG-IP Network Firewall policies combine one or more rules and apply them as a combined policy to one context, such as a self IP as shown.

The AFM features we use in this declaration are well-documented in the AFM documentation.

You must have BIG-IP AFM provisioned as shown in the example.

See FirewallPolicy, FirewallAddressList, FirewallPortList, and associated classes in the Schema Reference for descriptions and DO usage.

Note

The firewallAddressList class supports using FQDNs, however, FQDNs require a DNS Resolver on the BIG-IP which is not yet configurable using DO. If you want to use FQDNs, you must manually configure a DNS Resolver before submitting the declaration. See Network Firewall documentation for manual configuration information.

{
    "schemaVersion": "1.20.0",
    "class": "Device",
    "async": true,
    "Common": {
        "class": "Tenant",
        "provisioning": {
            "class": "Provision",
            "afm": "nominal"
        },
        "newVlan": {
            "class": "VLAN",
            "interfaces": [
                {
                    "name": "1.1"
                }
            ]
        },
        "selfOne": {
            "class": "SelfIp",
            "address": "192.0.2.10/24",
            "vlan": "/Common/newVlan",
            "enforcedFirewallPolicy": "/Common/firewallPolicy"
        },
        "selfTwo": {
            "class": "SelfIp",
            "address": "192.0.3.20/24",
            "vlan": "/Common/newVlan",
            "stagedFirewallPolicy": "/Common/firewallPolicy"
        },
        "firewallAddressList1": {
            "class": "FirewallAddressList",
            "addresses": ["192.0.2.10", "192.1.2.0/24"]
        },
        "firewallPortList1": {
            "class": "FirewallPortList",
            "ports": [8080, 8888]
        },
        "firewallPortList2": {
            "class": "FirewallPortList",
            "ports": ["8123", "8234", "8300-8350"]
        },
        "firewallPolicy": {
            "class": "FirewallPolicy",
            "label": "Example of all firewall policy properties",
            "remark": "firewall policy description",
            "rules": [
                {
                    "name": "firewallPolicyRule",
                    "label": "Example of all firewall policy rule properties",
                    "remark": "firewall policy rule description",
                    "action": "reject",
                    "protocol": "tcp",
                    "loggingEnabled": true,
                    "source": {
                        "addressLists": [
                            "/Common/firewallAddressList1"
                        ],
                        "portLists": [
                            "/Common/firewallPortList1",
                            "/Common/firewallPortList2"
                        ],
                        "vlans": [
                            "/Common/newVlan"
                        ]
                    },
                    "destination": {
                        "addressLists": [
                            "/Common/firewallAddressList1"
                        ],
                        "portLists": [
                            "/Common/firewallPortList1",
                            "/Common/firewallPortList2"
                        ]
                    }
                }
            ]
        }
    }
}

Configuring Auto Last Hop on VLANs

This example shows how you can configure Auto Last Hop on VLANs in a Declarative Onboarding declaration. Auto Last Hop allows the system to send return traffic to the MAC address that transmitted the request, even if the routing table points to a different network or interface. As a result, the system can send return traffic to clients even when there is no matching route.

There are three possible values for the autoLastHop property: enabled, disabled, and default, which inherits the value from the global settings.

For detailed information on Auto Last Hop, see Overview of the Auto Last Hop setting on AskF5.

See VLAN Class for description and DO usage.

{
    "schemaVersion": "1.22.0",
    "class": "Device",
    "async": true,
    "Common": {
        "class": "Tenant",
        "external": {
            "class": "VLAN",
            "tag": 4094,
            "mtu": 1500,
            "interfaces": [
                {
                    "name": "1.1",
                    "tagged": true
                }
            ],
            "autoLastHop": "disabled"
        },
        "internal": {
            "class": "VLAN",
            "tag": 4093,
            "mtu": 1500,
            "interfaces": [
                {
                    "name": "1.2",
                    "tagged": true
                }
            ],
            "autoLastHop": "default"
        }
    }
}

Specifying a static management IP address in a declaration

This example shows how you can specify a management IP address in a Declarative Onboarding declaration using the ManagementIp class introduced in DO 1.23. The ability to set a static management IP address is useful in scenarios such as updating the BIG-IP after a NIC swap in the Google Cloud Platform.

When using ManagementIp, you must keep in mind the following:

  • You must also update the ManagementRoute for the new management IP. See Management Route class.
  • If running remotely (on BIG-IQ), the remote device must be able to route to the new management IP.
  • When polling for DO status, use the new management IP.
  • If you are only changing the mask, DO must delete the existing management IP address. This means it will only work when DO is running on the device being configured (not from BIG-IQ). This is a system limitation not a DO limitation.
  • No response is returned if running in synchronous mode. Always use asynchronous mode when changing the management IP address (see Base Components).
  • To handle rollback to a dynamically configured IP, do not set the remark for the ManagementIp to ‘configured-by-dhcp’. The default value is fine.

See ManagementIp for DO usage.

{
    "schemaVersion": "1.23.0",
    "class": "Device",
	"async": true,
    "Common": {
    	"class": "Tenant",
        "hostname": "bigip.example.com",
        "myManagementIp": {
            "class": "ManagementIp",
            "address": "10.10.10.1/18",
            "remark": "this is my management ip"
        }
    }
}

Preserving DHCP routes when adding new management routes

This example shows how DO can preserve DHCP Management routes when you are adding new management routes in a DO declaration using 1.23 or later. By default, management routes are assigned by DHCP. In previous versions of DO, when you specified a new management route, DO would remove the route assigned by DHCP.

This feature provides the ability to preserve those DHCP routes using the new preserveOrigDhcpRoutes property set to true in the System class.

Important

If you do not configure DO to preserve management routes (the default) but specify management routes in the declaration, DO disables DHCP for management routes. If you configure DO to preserve management routes, DHCP for management routes remains enabled.

See System for more information and DO usage.

{
    "class": "Device",
    "async": true,
    "schemaVersion": "1.23.0",
    "Common": {
        "class": "Tenant",
        "system": {
            "class": "System",
            "preserveOrigDhcpRoutes": true
        },
        "newManagementRoute": {
            "class": "ManagementRoute",
            "network": "1.2.3.4",
            "gw": "4.3.2.1"
        }
    }
}

Configuring firewall rules on the management interface

This example shows how you can configure firewall rules on the management interface in a DO declaration. If you are deploying on BIG-IP 13.1-13.x, you must have the AFM module licensed and provisioned. BIG-IP versions 14.1 and later do not have this requirement.

This feature uses the new ManagementIpFirewall class, which includes the ManagementIpFirewall_rules settings.

For more detail on Firewall rules and manual configuration instructions, see Restrict access to the BIG-IP management interface using network firewall rules on AskF5.

For more information and DO usage on individual properties, see ManagementIpFirewall and ManagementIpFirewall_rules.

{
    "schemaVersion": "1.24.0",
    "class": "Device",
    "async": true,
    "Common": {
        "class": "Tenant",
        "firewallAddressList1": {
            "class": "FirewallAddressList",
            "addresses": ["192.0.2.10", "192.1.2.0/24"]
        },
        "firewallPortList1": {
            "class": "FirewallPortList",
            "ports": [8080, 8888]
        },
        "firewallPortList2": {
            "class": "FirewallPortList",
            "ports": ["8123", "8234", "8300-8350"]
        },
        "managementIpFirewall": {
            "class": "ManagementIpFirewall",
            "label": "Example of all management IP firewall properties",
            "remark": "management IP firewall description",
            "rules": [
                {
                    "name": "firewallRule",
                    "label": "Example of all firewall rule properties",
                    "remark": "firewall rule description",
                    "action": "reject",
                    "protocol": "tcp",
                    "loggingEnabled": true,
                    "source": {
                        "addressLists": [
                            "/Common/firewallAddressList1"
                        ],
                        "portLists": [
                            "/Common/firewallPortList1",
                            "/Common/firewallPortList2"
                        ]
                    },
                    "destination": {
                        "addressLists": [
                            "/Common/firewallAddressList1"
                        ],
                        "portLists": [
                            "/Common/firewallPortList1",
                            "/Common/firewallPortList2"
                        ]
                    }
                }
            ]
        }
    }
}

Configuring routes and managementRoutes

These examples show how you can create routes and management routes in Declarative Onboarding declarations. DO has supported these objects, however an issue existed in DO prior to v1.23 that would not allow a type of interface on Management routes.

See Route and ManagementRoute in the Schema Reference for DO usage and options.

The following examples contain route configuration, but no other DO configuration. You can use these classes as a part of a larger Declarative Onboarding declaration.

{
    "schemaVersion": "1.14.0",
    "class": "Device",
	"async": true,
    "Common": {
    	"class": "Tenant",
        "hostname": "bigip.example.com",
        "myRoute": {
            "class": "Route",
            "network": "default",
            "target": "external"
        }
    }
}

{
    "schemaVersion": "1.23.0",
    "class": "Device",
	"async": true,
    "Common": {
    	"class": "Tenant",
        "hostname": "bigip.example.com",
        "myManagementRoute": {
            "class": "ManagementRoute",
            "network": "10.10.10.1/32",
            "type": "interface"
        }
    }
}

Configuring routing access lists

This example shows how you can create network routing access lists using Declarative Onboarding 1.24 and later. These access lists are a part of a larger BGP configuration, and enable you to specify allow and deny actions for source and destination addresses (or ranges).

See RoutingAccessList and RoutingAccessList-Entries in the Schema Reference for DO usage and options.

The following example contains multiple access lists, but no other DO configuration. You can use this class as a part of a larger Declarative Onboarding declaration.

{
    "schemaVersion": "1.24.0",
    "class": "Device",
    "async": true,
    "Common": {
        "class": "Tenant",
        "hostname": "bigip.example.com",
        "exampleRoutingAccessList1": {
            "class": "RoutingAccessList",
            "entries": [
                {
                    "name": "11",
                    "action": "permit",
                    "destination": "10.10.0.0/16",
                    "exactMatchEnabled": false,
                    "source": "10.11.0.0/16"
                },
                {
                    "name": "22",
                    "action": "deny",
                    "destination": "10.12.13.14",
                    "exactMatchEnabled": false,
                    "source": "10.13.14.15"
                }
            ]
        },
        "exampleRoutingAccessList2": {
            "class": "RoutingAccessList",
            "entries": [
                {
                    "name": "33",
                    "action": "permit",
                    "exactMatchEnabled": true,
                    "source": "1111:2222::/64"
                },
                {
                    "name": 44,
                    "action": "permit",
                    "source": "1111:3333::/64"
                }
            ]
        }
    }
}