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 BIG-IP DO 1.17
BIG-IP 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 BIG-IP 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%100",
"network": "192.168.0.0%100/16"
},
"newSelfIp": {
"class": "SelfIp",
"address": "10.1.0.20%100/0",
"vlan": "newVlan"
},
"theRouteDomain": {
"class": "RouteDomain",
"id": 100,
"connectionLimit": 5432991,
"flowEvictionPolicy": "default-eviction-policy",
"ipIntelligencePolicy": "ip-intelligence",
"strict": false,
"routingProtocols": [
"BGP"
],
"vlans": [
"newVlan"
]
},
"AnotherRouteDomain": {
"class": "RouteDomain",
"id": 101,
"parent": "theRouteDomain",
"strict": false
}
}
}
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 BIG-IP Declarative Onboarding declaration.
{
"schemaVersion": "1.0.0",
"class": "Device",
"async": false,
"Common": {
"class": "Tenant",
"dagGlobals": {
"class": "DagGlobals",
"icmpHash": "ipicmp",
"ipv6PrefixLength": 101,
"roundRobinMode": "local"
}
}
}
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 BIG-IP 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 BIG-IP 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
}
}
}
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 BIG-IP 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"
}
}
}
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 BIG-IP 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"
}
}
}
Configuring VLAN Failsafe¶
In this example, we show how you can configure VLAN Failsafe settings in a BIG-IP 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 BIG-IP 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
}
}
}
Configuring a DNS Resolver¶
In this example, we show how you create a DNS Resolver in a BIG-IP Declarative Onboarding declaration using the DNS_Resolver class introduced in BIG-IP 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 BIG-IP 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 BIG-IP Declarative Onboarding declaration using the Tunnel class.
BIG-IP 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 BIG-IP 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"
}
}
}
Configuring Traffic Groups¶
This example shows how to create Traffic Groups using BIG-IP 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 BIG-IP DO usage and options.
Important
The HA Score failover method is not currently supported. BIG-IP DO uses the HA Order failover method.
Because BIG-IP 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"
]
}
}
}
Configuring routing prefix lists¶
This example shows how you can create network routing prefix lists using BIG-IP 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 BIG-IP DO usage and options.
BIG-IP DO 1.23 introduced the ability to use strings for the prefixLengthRange range property. Previous versions would only accept integers.
New in BIG-IP DO 1.40
BIG-IP DO 1.40 introduced the ability to define a route domain and assign it to a routing prefix list using the new routeDomain property in the RoutingPrefixList class.
The following example contains multiple prefix lists, but no other BIG-IP DO configuration. You can use this class as a part of a larger BIG-IP Declarative Onboarding declaration.
Important
If you try to use the following example with a version prior to 1.40, it will fail. For previous versions, remove the lines in yellow, and the commas from lines 43 and 61.
{
"schemaVersion": "1.40.0",
"class": "Device",
"async": true,
"Common": {
"class": "Tenant",
"hostname": "bigip.example.com",
"exampleVlan": {
"class": "VLAN",
"tag": 100,
"interfaces": [
{
"name": "1.1",
"tagged": true
}
]
},
"exampleRouteDomain": {
"class": "RouteDomain",
"id": 102,
"connectionLimit": 5432991,
"flowEvictionPolicy": "default-eviction-policy",
"strict": false,
"vlans": [
"exampleVlan"
]
},
"exampleRoutingPrefixList1": {
"class": "RoutingPrefixList",
"entries": [
{
"name": 10,
"action": "permit",
"prefix": "2001:db8::/127",
"prefixLengthRange": "128"
},
{
"name": 15,
"action": "deny",
"prefix": "2001:db8::/64",
"prefixLengthRange": "80:"
}
],
"routeDomain": "0"
},
"exampleRoutingPrefixList2": {
"class": "RoutingPrefixList",
"entries": [
{
"name": 20,
"action": "permit",
"prefix": "192.0.2.0/24",
"prefixLengthRange": ":30"
},
{
"name": 30,
"action": "deny",
"prefix": "192.0.2.1/24",
"prefixLengthRange": "25:27"
}
],
"routeDomain": "exampleRouteDomain"
}
}
}
Configuring BGP Routing in a declaration¶
This example shows how you can configure Border Gateway Protocol (BGP) routing in a BIG-IP 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 BIG-IP Declarative Onboarding classes (some of the classes were introduced in previous versions of BIG-IP Declarative Onboarding, but the main RoutingBGP class, which is required to use BGP routing, was introduced in BIG-IP DO 1.20). The links go to the Schema Reference for descriptions and BIG-IP DO usage.
- RoutingBGP
- RoutingAsPath
- RoutingPrefixList
- RouteMap
- RoutingAccessList (added in BIG-IP DO 1.24, not included in this example)
The RoutingBGP class contains a number of properties used in the following example, so be sure to see RoutingBGP for descriptions and options.
BIG-IP 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.
BIG-IP Declarative Onboarding 1.28 added support for specifying route domains in RoutingBGP and RouteMap.
New in BIG-IP DO 1.40
As noted in the previous example, BIG-IP DO 1.40 introduced the ability to define a route domain and assign it to a routing prefix list using the new routeDomain property in the RoutingPrefixList class.
Important
If you try to use the following example with a version prior to 1.40, it will fail. For previous versions, remove the lines in yellow, and the commas from lines 56 and 68.
{
"schemaVersion": "1.40.0",
"class": "Device",
"async": true,
"Common": {
"class": "Tenant",
"hostname": "bigip.example.com",
"exampleVlan": {
"class": "VLAN",
"tag": 100,
"interfaces": [
{
"name": "1.1",
"tagged": true
}
]
},
"exampleRouteDomain": {
"class": "RouteDomain",
"id": 102,
"connectionLimit": 5432991,
"flowEvictionPolicy": "default-eviction-policy",
"strict": false,
"vlans": [
"exampleVlan"
]
},
"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": "192.0.2.0/24",
"prefixLengthRange": 30
}
],
"routeDomain": "exampleRouteDomain"
},
"exampleRoutingPrefixList2": {
"class": "RoutingPrefixList",
"entries": [
{
"name": 30,
"action": "deny",
"prefix": "192.0.2.0/24",
"prefixLengthRange": 25
}
],
"routeDomain": "exampleRouteDomain"
},
"exampleRouteMap1": {
"class": "RouteMap",
"entries": [
{
"name": "33",
"action": "permit",
"match": {
"asPath": "exampleRoutingAsPath1",
"ipv4": {
"address": {
"prefixList": "exampleRoutingPrefixList1"
}
}
}
}
],
"routeDomain": "exampleRouteDomain"
},
"exampleRouteMap2": {
"class": "RouteMap",
"entries": [
{
"name": "44",
"action": "deny",
"match": {
"asPath": "exampleRoutingAsPath2",
"ipv4": {
"address": {
"prefixList": "exampleRoutingPrefixList2"
}
}
}
}
],
"routeDomain": "exampleRouteDomain"
},
"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": "192.0.2.1",
"addressFamilies": [
{
"internetProtocol": "ipv4",
"asOverrideEnabled": true
}
],
"ebgpMultihop": 2,
"peerGroup": "Neighbor"
},
{
"address": "192.0.2.2",
"ebgpMultihop": 3,
"peerGroup": "Neighbor"
}
],
"peerGroups": [
{
"name": "Neighbor",
"addressFamilies": [
{
"internetProtocol": "ipv4",
"routeMap": {
"in": "exampleRouteMap1",
"out": "exampleRouteMap2"
},
"softReconfigurationInboundEnabled": true
}
],
"remoteAS": 65020
}
],
"routeDomain": "exampleRouteDomain",
"routerId": "192.0.2.4"
}
}
}
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 BIG-IP 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 BIG-IP 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.2.20/24",
"vlan": "/Common/newVlan",
"stagedFirewallPolicy": "/Common/firewallPolicy"
},
"firewallAddressList1": {
"class": "FirewallAddressList",
"addresses": ["192.0.2.10", "192.0.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 BIG-IP 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 BIG-IP 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 BIG-IP Declarative Onboarding declaration using the ManagementIp class introduced in BIG-IP 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 BIG-IP DO status, use the new management IP.
- If you are only changing the mask, BIG-IP DO must delete the existing management IP address. This means it will only work when BIG-IP DO is running on the device being configured (not from BIG-IQ). This is a system limitation not a BIG-IP 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 BIG-IP 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 BIG-IP DO can preserve DHCP Management routes when you are adding new management routes in a BIG-IP DO declaration using 1.23 or later. By default, management routes are assigned by DHCP. In previous versions of BIG-IP DO, when you specified a new management route, BIG-IP 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 BIG-IP DO to preserve management routes (the default) but specify management routes in the declaration, BIG-IP DO disables DHCP for management routes. If you configure BIG-IP DO to preserve management routes, DHCP for management routes remains enabled.
See System for more information and BIG-IP DO usage.
{
"class": "Device",
"async": true,
"schemaVersion": "1.23.0",
"Common": {
"class": "Tenant",
"system": {
"class": "System",
"preserveOrigDhcpRoutes": true
},
"newManagementRoute": {
"class": "ManagementRoute",
"network": "192.0.2.4",
"gw": "192.0.2.1"
}
}
}
Configuring firewall rules on the management interface¶
This example shows how you can configure firewall rules on the management interface in a BIG-IP 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 BIG-IP DO usage on individual properties, see ManagementIpFirewall and ManagementIpFirewall_rules.
{
"schemaVersion": "1.30.0",
"class": "Device",
"async": true,
"Common": {
"class": "Tenant",
"netAddressList1": {
"class": "NetAddressList",
"addresses": ["192.0.2.10", "233.252.0.0/24"]
},
"netPortList1": {
"class": "NetPortList",
"ports": [8080, 8888]
},
"netPortList2": {
"class": "NetPortList",
"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/netAddressList1"
],
"portLists": [
"/Common/netPortList1",
"/Common/netPortList2"
]
},
"destination": {
"addressLists": [
"/Common/netAddressList1"
],
"portLists": [
"/Common/netPortList1",
"/Common/netPortList2"
]
}
}
]
}
}
}
Configuring routes and managementRoutes¶
These examples show how you can create routes and management routes in BIG-IP Declarative Onboarding declarations. BIG-IP DO has supported these objects, however an issue existed in BIG-IP 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 BIG-IP DO usage and options.
The following examples contain route configuration, but no other BIG-IP DO configuration. You can use these classes as a part of a larger BIG-IP 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 BIG-IP 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 BIG-IP DO usage and options.
The following example contains multiple access lists, but no other BIG-IP DO configuration. You can use this class as a part of a larger BIG-IP 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": "192.0.2.0/25",
"exactMatchEnabled": false,
"source": "192.0.2.80/25"
},
{
"name": "22",
"action": "deny",
"destination": "192.0.2.10",
"exactMatchEnabled": false,
"source": "192.0.2.11"
}
]
},
"exampleRoutingAccessList2": {
"class": "RoutingAccessList",
"entries": [
{
"name": "33",
"action": "permit",
"exactMatchEnabled": true,
"source": "2001:db8::/65"
},
{
"name": 44,
"action": "permit",
"source": "2001:db9::/65"
}
]
}
}
}
Configuring VXLAN tunnels¶
This example shows how you can create VXLAN tunnels using BIG-IP Declarative Onboarding 1.25 and later.
Virtual eXtended LAN (VXLAN) is a network virtualization scheme that overlays Layer 2 over Layer 3. VLXAN uses Layer 3 multicast to support the transmission of multicast and broadcast traffic in the virtual network, while decoupling the virtualized network from the physical infrastructure. See Configuring Network Virtualization Tunnels for more information and manual configuration.
Important
In BIG-IP DO 1.36 and later, when creating a VXLAN Tunnel, the acceptIpOptions property in the TraffficControls class no longer automatically to true. Instead it will remain the same or be set to the value in the declaration. See TrafficControl Class for more information about Traffic Control and acceptIpOptions. Also see the Traffic Control example on this page.
See Tunnel in the Schema Reference for BIG-IP DO usage and options.
The following example contains a VXLAN tunnel, but no other BIG-IP DO configuration. You can use this class as a part of a larger BIG-IP Declarative Onboarding declaration.
{
"schemaVersion": "1.25.0",
"class": "Device",
"async": true,
"label": "Configuring System",
"Common": {
"class": "Tenant",
"testTunnel": {
"class": "Tunnel",
"description": "none",
"autoLasthop": "default",
"mtu": 0,
"tunnelType": "vxlan",
"tos": "preserve",
"usePmtu": true,
"localAddress": "192.0.2.1",
"remoteAddress": "233.252.0.2",
"secondaryAddress": "any6",
"key": 0,
"mode": "bidirectional",
"transparent": false,
"trafficGroup": "none",
"defaultsFrom": "vxlan",
"port": 4789,
"floodingType": "multicast",
"encapsulationType": "vxlan"
}
}
}
Enabling management DHCP in a declaration¶
This example shows how you can explicitly enable or disable DHCP for management IP addresses and routes in the System class using the new mgmtDhcpEnabled property in BIG-IP DO 1.28 and later.
This property is associated with the preserveOrigDhcpRoutes property, which provides the ability to preserve those DHCP routes (see the Preserve DHCP routes example on this page).
Important
When you use both mgmtDhcpEnabled and preserveOrigDhcpRoutes, the values MUST match.
See System for more information and BIG-IP DO usage.
{
"async": true,
"schemaVersion": "1.28.0",
"class": "Device",
"Common": {
"class": "Tenant",
"system": {
"class": "System",
"mgmtDhcpEnabled": true,
"preserveOrigDhcpRoutes": true
}
}
}