Miscellaneous declarations¶
This section contains declarations that do not fit into one of the other categories.
Use the index on the right to locate specific examples.
1: Using PATCH to add a new Application to a Tenant¶
This example uses the same declaration as in the UDP Example, but we use the PATCH method to add an new Application to the Sample_non_http_01 tenant.
This PATCH creates the following objects on the BIG-IP:
- A new Application named NewApp.
- An HTTP service (virtual server) named serviceMain.
- A pool named web_poolnew with two servers monitored by the default http health monitor.
If necessary, review the declaration in Example 11 (or first use GET https://<BIG-IP>/mgmt/shared/appsvcs/declare/Sample_misc_11).
Then use PATCH https://<BIG-IP>/mgmt/shared/appsvcs/declare with the following
body (because this is a new object, we include the new name in the path):
[
{
"op": "add",
"path": "/Sample_non_http_01/NewAPP",
"value": {
"class": "Application",
"template": "http",
"serviceMain": {
"class": "Service_HTTP",
"virtualAddresses": [
"10.0.1.10"
],
"pool": "web_poolnew"
},
"web_poolnew": {
"class": "Pool",
"monitors": [
"http"
],
"members": [{
"servicePort": 80,
"serverAddresses": [
"192.0.1.10",
"192.0.1.11"
]
}]
}
}
}
]
After submitting this PATCH, the system returns the following (new application highlighted in yellow):
{
"results": [
{
"message": "success",
"lineCount": 20,
"code": 200,
"host": "localhost",
"tenant": "Sample_non_http_01",
"runTime": 1330
}
],
"declaration": {
"Sample_non_http_01": {
"class": "Tenant",
"DNS_Service": {
"class": "Application",
"template": "udp",
"serviceMain": {
"class": "Service_UDP",
"virtualPort": 53,
"virtualAddresses": [
"10.1.20.121"
],
"pool": "Pool1"
},
"Pool1": {
"class": "Pool",
"monitors": [
"icmp"
],
"members": [
{
"servicePort": 53,
"serverAddresses": [
"10.1.10.100"
]
},
{
"servicePort": 53,
"serverAddresses": [
"10.1.10.101"
]
}
]
}
},
"NewAPP": {
"class": "Application",
"template": "http",
"serviceMain": {
"class": "Service_HTTP",
"virtualAddresses": [
"10.0.1.10"
],
"pool": "web_poolnew"
},
"web_poolnew": {
"class": "Pool",
"monitors": [
"http"
],
"members": [
{
"servicePort": 80,
"serverAddresses": [
"192.0.1.10",
"192.0.1.11"
]
}
]
}
}
}
},
"class": "ADC",
"schemaVersion": "3.0.0",
"id": "UDP_DNS_Sample",
"label": "UDP_DNS_Sample",
"remark": "Sample of a UDP DNS Load Balancer Service",
"controls": {
"archiveTimestamp": "2018-06-04T21:54:18.255Z"
}
}
2: Using the Service_Generic class¶
This simple example shows how you can use the new Service_Generic class. This class allows the BIG-IP to accept any L4 protocols without requiring a fastl4 profile. For usage options, see https://clouddocs.f5.com/products/extensions/f5-appsvcs-extension/latest/refguide/schema-reference.html#service-generic
This declaration creates the following objects on the BIG-IP:
- Partition (tenant) named Sample_misc_02.
- A Generic service named generic_virtual on port 8080 (note that because this declaration uses the generic template, the service does not have to be named serviceMain).
{
"class": "ADC",
"schemaVersion": "3.5.0",
"id": "Service_Generic",
"Sample_misc_02": {
"class": "Tenant",
"Application": {
"class": "Application",
"template": "generic",
"generic_virtual": {
"class":"Service_Generic",
"virtualAddresses": [
"192.0.2.140"
],
"virtualPort": 8080
}
}
}
}
3: Using Metadata in a declaration¶
This example shows how you can add metadata to a service (virtual server) in a declaration. This can be useful for storing information about the application which could be leveraged by other tools for tasks such as validation or auditing.
This declaration creates the following objects on the BIG-IP:
- Partition (tenant) named Sample_misc_03.
- A generic virtual service named testItem with a metadata entry of example.
{
"class": "ADC",
"schemaVersion": "3.7.0",
"id": "Service_Generic",
"Sample_misc_03": {
"class": "Tenant",
"Application": {
"class": "Application",
"template": "generic",
"testItem": {
"class": "Service_Generic",
"virtualPort": 200,
"virtualAddresses": [
"192.0.2.21"
],
"metadata": {
"example": {
"value": "example",
"persist": true
}
}
}
}
}
}
4: Virtual service allowing only specific VLANs¶
This example uses our simple HTTP service in Example 1, but uses a feature introduced in AS3 version 3.2.0, which enables the ability to allow or deny client traffic from specific VLANs (IMPORTANT: The VLAN objects must already exist on the BIG-IP system).
In this case, we are using allowVlans to allow traffic from specific VLANs on our BIG-IP system to access our HTTP service, and denying all other traffic to that service. If we wanted to deny traffic from specific VLANs, we would use rejectVlans instead. In the rejectVlans case, the system would deny traffic from the specified VLANs, and would allow traffic from any other VLAN on the system. If you do not use this property, the system allows all VLANs by default.
This declaration creates the following objects on the BIG-IP:
- Partition (tenant) named Sample_misc_04.
- A virtual server named serviceMain which is only accessible from the internal-sales and internal-marketing VLANs (which already exist on the BIG-IP system).
- A pool named web_pool monitored by the default http health monitor.
{
"class": "AS3",
"action": "deploy",
"persist": true,
"declaration": {
"class": "ADC",
"schemaVersion": "3.2.0",
"id": "vlan-allow",
"label": "Sample Security 3",
"remark": "Simple HTTP application VLAN restriction",
"Sample_misc_04": {
"class": "Tenant",
"A1": {
"class": "Application",
"template": "http",
"serviceMain": {
"class": "Service_HTTP",
"virtualAddresses": [
"10.0.1.10"
],
"pool": "web_pool",
"allowVlans": [
{ "bigip":"/Common/internal-sales" },
{ "bigip":"/Common/internal-marketing" }
]
},
"web_pool": {
"class": "Pool",
"monitors": [
"http"
],
"members": [{
"servicePort": 80,
"serverAddresses": [
"192.0.1.10",
"192.0.1.11"
]
}]
}
}
}
}
}
5: Advertising a route for a Service Address¶
In this example, we show you how to use the Service Address class to advertise a route in your declaration. The Service_Address class allows you to add a number of properties to your (virtual) server address. This declaration shows how you can use the new routeAdvertisement property to advertise routes. For options and usage, see Schema Reference: Service_Address. This example uses the Service_Generic template.
..IMPORTANT:: When AS3 creates a Service_Address, it is placed in /tenant/serviceAddress (and not /tenant/app/serviceAddress) on the BIG-IP system.
This declaration creates the following objects on the BIG-IP:
- Partition (tenant) named Sample_misc_05.
- A virtual server named theService which includes a pointer to the Service_Address class.
- A Service_Address class named serviceAddress which includes a number of properties, including routeAdvertisement.
{
"class":"ADC",
"schemaVersion":"3.7.0",
"id":"Service_Address",
"Sample_misc_05":{
"class":"Tenant",
"Application":{
"class":"Application",
"template":"generic",
"theService": {
"class": "Service_HTTP",
"virtualPort": 123,
"virtualAddresses": [
{
"use": "serviceAddress"
}
]
},
"serviceAddress":{
"class":"Service_Address",
"virtualAddress":"123.123.123.123",
"arpEnabled":false,
"icmpEcho":"disable",
"routeAdvertisement":"any",
"spanningEnabled":true,
"trafficGroup":"/Common/traffic-group-local-only"
}
}
}
}
6: Using Clone Pools in a declaration¶
AS3 version 3.9.0 adds support for using Clone Pools in a declaration. You can use a clone pool when you want the BIG-IP system to send traffic to a pool of intrusion detection systems (IDSs) or a sniffer device. You can specify ingress, where the system replicates client-side traffic (prior to address translation) to the specified clone pool, or egress, where the system replicates server-side traffic (after address translation) to the specified clone pool, or both (as shown in this example).
This declaration creates the following objects on the BIG-IP:
- Partition (tenant) named Sample_clone_pool.
- Two virtual servers named testService and testService-1. The latter is automatically created because we specify two virtual addresses.
- A standard pool named web_pool monitored by the default HTTP health monitor.
- Two clone pools named testPoolIngress and testPoolEgress, which replicates ingress and egress traffic respectively.
{
"class": "ADC",
"schemaVersion": "3.9.0",
"id": "TEST_Clone_Pools",
"remark": "Clone Pools Support",
"Sample_clone_pool": {
"class": "Tenant",
"Application": {
"class": "Application",
"template": "generic",
"testService": {
"class": "Service_HTTP",
"virtualAddresses": [
"192.0.2.34",
"192.0.2.35"
],
"virtualPort": 80,
"pool": "web_pool",
"clonePools": {
"ingress": {
"use": "testPoolIngress"
},
"egress": {
"use": "testPoolEgress"
}
}
},
"testPoolIngress": {
"class": "Pool",
"members": [
{
"servicePort": 443,
"serverAddresses": [
"192.0.2.51",
"192.0.2.52"
]
}
]
},
"testPoolEgress": {
"class": "Pool",
"members": [
{
"servicePort": 443,
"serverAddresses": [
"192.0.2.54",
"192.0.2.55"
]
}
]
},
"web_pool": {
"class": "Pool",
"monitors": [
"http"
],
"members": [
{
"servicePort": 80,
"serverAddresses": [
"192.0.2.72",
"192.0.2.73"
]
}
]
}
}
}
}
7: Sending multiple declarations in a single request (container)¶
AS3 version 3.10.0 adds support for sending multiple declarations to different target BIG-IP devices in a single request. In this example, we are using AS3 in a Docker Container (see AS3 in a Container). This feature allows you configure multiple target BIG-IP devices from the container. This can be useful for orchestration and automation solutions.
This declaration does the following:
- On the BIG-IP device with IP address 10.10.10.11:
- AS3 redeploys the 3rd declaration saved in the target device’s declaration history (revisit POST Action: redeploy for more information).
- On the BIG-IP device with IP address 10.10.10.12:
- Partition (tenant) named AS3Request_Tenant1.
- A virtual server named serviceMain.
- A pool named web_pool1 monitored by the default HTTP health monitor.
[
{
"class": "AS3",
"action": "redeploy",
"redeployAge": 2,
"targetHost": "10.10.10.11",
"targetUsername": "admin",
"targetPassphrase": "admin"
},
{
"class": "AS3",
"action": "deploy",
"targetHost": "10.10.10.12",
"targetUsername": "admin",
"targetPassphrase": "admin",
"declaration": {
"class": "ADC",
"schemaVersion": "3.7.0",
"id": "AS3Request_Tenant1",
"updateMode": "selective",
"AS3Request_Tenant1": {
"class": "Tenant",
"App1": {
"class": "Application",
"template": "http",
"serviceMain": {
"class": "Service_HTTP",
"virtualAddresses": [
"198.19.192.14"
],
"pool": "web_pool1"
},
"web_pool1": {
"class": "Pool",
"monitors": [
"http"
],
"members": [
{
"servicePort": 80,
"serverAddresses": [
"198.19.192.72",
"198.19.192.73"
]
}
]
}
}
}
}
}
]
8: Sending multiple declarations in a single request (BIG-IQ)¶
AS3 version 3.10.0 adds support for sending multiple declarations to different target BIG-IP devices in a single request. In this example, we are using AS3 on BIG-IQ (see Using AS3 with BIG-IQ . This allows you to configure more than one BIG-IP device using BIG-IQ.
This declaration does the following:
- On the BIG-IP device with IP address 10.10.10.13:
- Partition (tenant) named bigiqTenant1.
- A virtual server named serviceMain, using the Fast L4 template/class.
- A pool named pool with a single member on port 8080 monitored by the TCP health monitor on the BIG-IP system.
- On the BIG-IP device with IP address 10.10.10.14:
- Partition (tenant) named bigiqTenant2.
- A virtual server named serviceMain, using the Fast L4 template/class.
- A pool named pool with a single member on port 8080 monitored by the TCP health monitor on the BIG-IP system.
[
{
"class": "ADC",
"id": "myid1",
"schemaVersion": "3.7.0",
"target": {
"address": "10.10.10.13"
},
"bigiqTenant1": {
"class": "Tenant",
"fastl4": {
"class": "Application",
"template": "l4",
"label": "simple tcp app VS_TCP",
"serviceMain": {
"class": "Service_L4",
"persistenceMethods": [],
"pool": "pool",
"profileL4": {
"bigip": "/Common/fastL4"
},
"snat": "auto",
"virtualAddresses": [
"10.11.11.121"
],
"virtualPort": 80
},
"pool": {
"class": "Pool",
"members": [
{
"serverAddresses": [
"192.168.128.112"
],
"servicePort": 8080
}
],
"monitors": [
{
"bigip": "/Common/tcp"
}
],
"remark": "fastl4"
}
}
}
},
{
"class": "ADC",
"id": "myid2",
"schemaVersion": "3.7.0",
"target": {
"address": "10.10.10.14"
},
"bigiqTenant2": {
"class": "Tenant",
"fastl4": {
"class": "Application",
"template": "l4",
"label": "simple tcp app VS_TCP",
"serviceMain": {
"class": "Service_L4",
"pool": "pool",
"profileL4": {
"bigip": "/Common/fastL4"
},
"snat": "auto",
"virtualAddresses": [
"10.11.11.131"
],
"virtualPort": 80
},
"pool": {
"class": "Pool",
"members": [
{
"serverAddresses": [
"192.168.128.113"
],
"servicePort": 8080
}
],
"monitors": [
{
"bigip": "/Common/tcp"
}
],
"remark": "fastl4"
}
}
}
}
]
9: Using Splunk as a log destination¶
With AS3 version 3.10.0 and later, you can use Splunk as a log destination. This enables the BIG-IP to format the logs in a way that can be used by Splunk. For more information, see the Configuring High Speed Remote Logging chapter of External Monitoring guide.
This declaration creates the following objects on the BIG-IP (note it does not include a virtual server, just a pool and the logging objects):
- Partition (tenant) named Splunk_Log_Destination.
- A pool named logPool with one member on port 443.
- A log destination of type remote high speed log. This is a BIG-IP requirement for logging servers that require data in a specific format.
- A log destination of type splunk that forwards to the remote high speed log destination.
- An additional Splunk log destination that forwards to syslog on the BIG-IP device.
{
"class": "ADC",
"schemaVersion": "3.10.0",
"id": "Splunk_Log_Destination",
"controls": {
"class": "Controls",
"trace": true,
"logLevel": "debug"
},
"Splunk_Log_Destination": {
"class": "Tenant",
"Application": {
"class": "Application",
"template": "generic",
"logPool": {
"class": "Pool",
"members": [
{
"servicePort": 443,
"serverAddresses": [
"192.0.2.53"
]
}
]
},
"remoteHSLog": {
"class": "Log_Destination",
"type": "remote-high-speed-log",
"pool": {
"use": "logPool"
}
},
"splunkLog1": {
"class": "Log_Destination",
"type": "splunk",
"forwardTo": {
"use": "remoteHSLog"
}
},
"splunkLog2": {
"class": "Log_Destination",
"type": "splunk",
"forwardTo": {
"bigip": "/Common/local-syslog"
}
}
}
}
}
11: Using the include property to reference one section of a declaration in another section¶
This example shows how you can use the include property to call a section of a declaration from another part of the same declaration. In the following example, we are showing a WAF policy declaration which uses this feature, although you can use include with any property. See Include in the schema reference for more information and usage.
This declaration creates a WAF policy in /Common using the shared template, and then references.
{
"class": "ADC",
"schemaVersion": "3.13.0",
"Common": {
"class": "Tenant",
"Shared": {
"class": "Application",
"template": "shared",
"wordpressWafPolicy": {
"class": "WAF_Policy",
"url": "https://example.com/wordpress_template_12.0.xml",
"ignoreChanges": true
},
"mobileDefenseProfile": {
"class": "DOS_Profile",
"application": {
"scrubbingDuration": 42,
"remoteTriggeredBlackHoleDuration": 10,
"mobileDefense": {
"enabled": true,
"allowAndroidPublishers": [{
"bigip": "/Common/default.crt"
}],
"allowAndroidRootedDevice": true,
"allowIosPackageNames": [
"theName"
],
"allowJailbrokenDevices": true,
"allowEmulators": true,
"clientSideChallengeMode": "challenge"
}
}
},
"constants": {
"class": "Constants",
"securityCollection": {
"policyWAF": {
"use": "/Common/Shared/wordpressWafPolicy"
},
"profileDOS": {
"use": "/Common/Shared/mobileDefenseProfile"
}
}
}
}
},
"Tenant1": {
"class": "Tenant",
"Application1": {
"class": "Application",
"template": "generic",
"vipOne": {
"class": "Service_HTTP",
"virtualPort": 8080,
"virtualAddresses": [
"192.0.2.1"
],
"include": [
"/Common/Shared/constants/securityCollection"
]
},
"vipTwo": {
"class": "Service_HTTP",
"virtualPort": 8080,
"virtualAddresses": [
"192.0.2.2"
],
"include": [
"/Common/Shared/constants/securityCollection"
]
}
}
}
}
12: Using both a source and destination address for a virtual service¶
In this example, we show how you can use both a source and destination address for your virtual service (BIG-IP virtual server). For specific information, see the Virtual Server documentation.
The Destination Address is the destination IP address to which the virtual service sends traffic and is required.
The Source Address property is optional, but allows you to specify an IP address or network from which the virtual server accepts traffic. If you include Source Address(es), the virtual server accepts clients only from one of these IP addresses.
This declaration creates the following objects on the BIG-IP:
- Partition (tenant) named source_example.
- Two virtual servers named service (the BIG-IP names the second service-1) using the Service_Generic class. Each virtual has a Destination address (the first IP address in the array) and a Source Address (the second IP address in the array).
{
"class": "ADC",
"schemaVersion": "3.0.0",
"id": "declarationId",
"source_example": {
"class": "Tenant",
"app": {
"class": "Application",
"template": "generic",
"service": {
"class": "Service_Generic",
"virtualAddresses": [
[
"192.0.2.11",
"1.2.3.4/32"
],
[
"192.0.2.12",
"1.2.3.5/32"
]
],
"virtualPort": 1000
}
}
}
}
13: Creating an internal virtual service¶
In this example, we show how you can create a virtual service (virtual server with a Type of Internal). This type of virtual service is useful for conditionally forwarding HTTP requests and HTTP responses to a pool of ICAP servers for modification, before sending a request to a web server or returning a response to the client system. For details on this implementation, see the Configuring Content Adaptation for HTTP Requests and Response. For information on BIG-IP virtual servers in general, see K15819.
This declaration creates the following objects on the BIG-IP:
- Partition (tenant) named Sample_Internal_Virtual.
- An Application named Internal_Service.
- A TCP virtual server named serviceMain with Type of Internal that references an existing ICAP profile on the BIG-IP.
{
"class": "ADC",
"schemaVersion": "3.16.0",
"label": "Internal_Virtual",
"remark": "Internal_Virtual",
"Sample_Internal_Virtual": {
"class": "Tenant",
"Internal_Service": {
"class": "Application",
"template": "tcp",
"serviceMain": {
"class": "Service_TCP",
"virtualType": "internal",
"sourceAddress": "192.0.2.0/24",
"profileICAP": {
"bigip": "/Common/icap"
}
}
}
}
}
14: Configuring virtual address settings while using Source address filtering¶
In this example, we show how you can configure virtual service settings on the destination address (such as disabling ARP and ICMP echo) while still specifying a source IP address to enable source address filtering. This is similar to Example 12, but in this case, we are configuring specific settings for the destination address and then including it in the array.
For specific information, see the Virtual Server documentation.
This declaration creates the following objects on the BIG-IP:
- Partition (tenant) named Sample_src_service_address.
- An Application named app.
- A virtual service address with ARP and ICMP echo disabled.
- A generic virtual server named service with a destination address that uses the virtual address above, and a source address of 1.2.3.4/32.
{
"class": "ADC",
"schemaVersion": "3.15.0",
"id": "declarationId",
"source_service_address_example": {
"class": "Tenant",
"app": {
"class": "Application",
"template": "generic",
"my_service_address": {
"class": "Service_Address",
"virtualAddress": "1.1.1.1",
"arpEnabled": false,
"icmpEcho": "disable"
},
"service": {
"class": "Service_Generic",
"virtualAddresses": [
[
{
"use": "my_service_address"
},
"1.2.3.4/32"
]
],
"virtualPort": 1000
}
}
}
}
15: Referencing pools and iRules in a declaration¶
In this example, we show how you can reference pools and iRules (including a persistence iRule) with the use pointer in AS3 3.17 and later. The use pointer has been available for other properties in AS3, but this version adds pools, iRules, and persistence Hash iRules.
This declaration creates the following objects on the BIG-IP:
- Partition (tenant) named Sample_pool_irule.
- An Application named SampleApp.
- A virtual server named serviceMain with a pool, iRules, and persistence method (which also includes an iRule) referenced later in the declaration.
- A pool named web_pool.
- Two iRules (non-functional in this example), named theRule1 and theRule2.
- A Hash persistence profile (persistRuleEx) that references an iRule (also non-functional) named ruleForPersis.
{
"class": "ADC",
"schemaVersion": "3.16.0",
"id": "8675309",
"Sample_pool_irule": {
"class": "Tenant",
"SampleApp": {
"class": "Application",
"template": "http",
"serviceMain": {
"class": "Service_HTTP",
"virtualAddresses": [
"10.1.10.10"
],
"pool": {
"use": "web_pool"
},
"persistenceMethods": [
{ "use": "persistRuleEx" }
],
"iRules": [
"theRule1",
{ "use": "theRule2" }
]
},
"web_pool": {
"class": "Pool",
"members": [
{
"servicePort": 80,
"serverAddresses": [
"10.128.0.209"
]
}
]
},
"theRule1": {
"class": "iRule",
"iRule": "when CLIENT_ACCEPTED { }"
},
"theRule2": {
"class": "iRule",
"iRule": "when HTTP_REQUEST { }"
},
"persistRuleEx": {
"class": "Persist",
"persistenceMethod": "hash",
"iRule": { "use": "ruleForPersist" }
},
"ruleForPersist": {
"class": "iRule",
"iRule": "when CLIENT_ACCEPTED { }"
}
}
}
}
16: Using the userAgent Controls property¶
In this example, we show how you can use the userAgent property in the Controls class. The userAgent property allows you to set a unique identifier in usage data.
This declaration creates the following objects on the BIG-IP:
- A Controls class with userAgent set to BIG-IQ/7.1 Configured by API.
- Partition (tenant) named useragentTenant.
- An Application named SampleApp.
- A virtual server named Stream_service.
{
"class": "ADC",
"schemaVersion": "3.18.0",
"id": "userAgent",
"controls": {
"class": "Controls",
"userAgent": "BIG-IQ/7.1 Configured by API"
},
"useragentTenant": {
"class": "Tenant",
"sampleApp": {
"class": "Application",
"template": "generic",
"Stream_service": {
"class": "Service_HTTP",
"virtualAddresses": [
"1.2.3.4"
],
"virtualPort": 100
}
}
}
}
17: Using traceResponse to enable traces in AS3 responses¶
In this example, we show how you can use the traceResponse property to enable more visibility into what AS3 is configuring. This property can be used in the Controls or ADC_Controls classes (links go to the Schema Reference).
This example shows both the declaration and the response from AS3. Note that in the ADC class, we set traceResponse to false, and only set it to true on the tenant. This limits the trace to the tenant only; if you set traceResponse to true at the ADC class level, you would get traces for all tenants in the declaration. You could also get it to true at the ADC level, and then to false for each tenant you do not want to trace.
This declaration creates the following objects on the BIG-IP:
- Partition (tenant) named trace_tenant.
- An Application named SampleApp.
- A virtual server named Sample_service.
{
"class": "ADC",
"schemaVersion": "3.18.0",
"id": "traceResponse",
"controls": {
"class": "Controls",
"traceResponse": false
},
"trace_tenant": {
"class": "Tenant",
"controls": {
"class": "Controls",
"traceResponse": true
},
"SampleApp": {
"class": "Application",
"template": "generic",
"Sample_service": {
"class": "Service_HTTP",
"virtualAddresses": [
"1.2.3.4"
],
"virtualPort": 100
}
}
}
}
Example Response Here is the response returned by AS3 from the declaration, showing the trace for the tenant.
{
"results": [
{
"code": 200,
"message": "success",
"lineCount": 22,
"host": "localhost",
"tenant": "trace_tenant",
"runTime": 6304
}
],
"declaration": {
"class": "ADC",
"schemaVersion": "3.18.0",
"id": "traceResponse",
"controls": {
"class": "Controls",
"traceResponse": false,
"archiveTimestamp": "2020-02-18T23:02:51.807Z"
},
"trace_tenant": {
"class": "Tenant",
"controls": {
"class": "Controls",
"traceResponse": true
},
"SampleApp": {
"class": "Application",
"template": "generic",
"Sample_service": {
"class": "Service_HTTP",
"virtualAddresses": [
"1.2.3.4"
],
"virtualPort": 100
}
}
},
"updateMode": "selective"
},
"traces": {
"trace_tenantDesired": {
"/trace_tenant/SampleApp/": {
"command": "sys folder",
"properties": {},
"ignore": []
},
"/trace_tenant/Service_Address-1.2.3.4": {
"command": "ltm virtual-address",
"properties": {
"address": "1.2.3.4",
"arp": "enabled",
"icmp-echo": "enabled",
"mask": "255.255.255.255",
"route-advertisement": "disabled",
"spanning": "disabled",
"traffic-group": "default"
},
"ignore": []
},
"/trace_tenant/SampleApp/Sample_service": {
"command": "ltm virtual",
"properties": {
"address-status": "yes",
"auto-lasthop": "default",
"connection-limit": 0,
"description": "\"SampleApp\"",
"destination": "/trace_tenant/1.2.3.4:100",
"ip-protocol": "tcp",
"last-hop-pool": "none",
"mask": "255.255.255.255",
"mirror": "disabled",
"persist": {
"/Common/cookie": {
"default": "yes"
}
},
"policies": {},
"profiles": {
"/Common/http": {
"context": "all"
},
"/Common/f5-tcp-progressive": {
"context": "all"
}
},
"source": "0.0.0.0/0",
"source-address-translation": {
"type": "automap"
},
"rules": {},
"security-log-profiles": {},
"source-port": "preserve",
"translate-address": "enabled",
"translate-port": "enabled",
"nat64": "disabled",
"vlans": {},
"vlans-disabled": " ",
"metadata": {},
"clone-pools": {}
},
"ignore": []
},
"/trace_tenant/": {
"command": "auth partition",
"properties": {
"default-route-domain": 0
},
"ignore": []
}
},
"trace_tenantCurrent": {},
"trace_tenantDiff": [
{
"kind": "N",
"path": [
"/trace_tenant/SampleApp/"
],
"rhs": {
"command": "sys folder",
"properties": {},
"ignore": []
},
"tags": [
"tmsh"
],
"command": "sys folder",
"lhsCommand": "",
"rhsCommand": "sys folder"
},
{
"kind": "N",
"path": [
"/trace_tenant/1.2.3.4"
],
"rhs": {
"command": "ltm virtual-address",
"properties": {
"address": "1.2.3.4",
"arp": "enabled",
"icmp-echo": "enabled",
"mask": "255.255.255.255",
"route-advertisement": "disabled",
"spanning": "disabled",
"traffic-group": "default"
},
"ignore": []
},
"tags": [
"tmsh"
],
"command": "ltm virtual-address",
"lhsCommand": "",
"rhsCommand": "ltm virtual-address"
},
{
"kind": "N",
"path": [
"/trace_tenant/SampleApp/Sample_service"
],
"rhs": {
"command": "ltm virtual",
"properties": {
"address-status": "yes",
"auto-lasthop": "default",
"connection-limit": 0,
"description": "\"SampleApp\"",
"destination": "/trace_tenant/1.2.3.4:100",
"ip-protocol": "tcp",
"last-hop-pool": "none",
"mask": "255.255.255.255",
"mirror": "disabled",
"persist": {
"/Common/cookie": {
"default": "yes"
}
},
"policies": {},
"profiles": {
"/Common/http": {
"context": "all"
},
"/Common/f5-tcp-progressive": {
"context": "all"
}
},
"source": "0.0.0.0/0",
"source-address-translation": {
"type": "automap"
},
"rules": {},
"security-log-profiles": {},
"source-port": "preserve",
"translate-address": "enabled",
"translate-port": "enabled",
"nat64": "disabled",
"vlans": {},
"vlans-disabled": " ",
"metadata": {},
"clone-pools": {}
},
"ignore": []
},
"tags": [
"tmsh"
],
"command": "ltm virtual",
"lhsCommand": "",
"rhsCommand": "ltm virtual"
},
{
"kind": "N",
"path": [
"trace_tenant"
],
"rhs": {
"command": "auth partition",
"properties": {
"default-route-domain": 0
},
"ignore": []
},
"tags": [
"tmsh"
],
"command": "auth partition",
"lhsCommand": "",
"rhsCommand": "auth partition"
}
],
"trace_tenantScript": "cli script __appsvcs_update {\nproc script::run {} {\nif {[catch {\ntmsh::modify ltm data-group internal __appsvcs_update records none\n} err]} {\ntmsh::create ltm data-group internal __appsvcs_update type string records none\n}\nif { [catch {\ntmsh::create auth partition trace_tenant default-route-domain 0\ntmsh::create sys folder /trace_tenant/SampleApp/\ntmsh::begin_transaction\ntmsh::modify auth partition trace_tenant description \\\"Updated by AS3 at [clock format [clock seconds] -gmt true -format {%a, %d %b %Y %T %Z}]\\\"\ntmsh::create ltm virtual-address /trace_tenant/1.2.3.4 address 1.2.3.4 arp enabled icmp-echo enabled mask 255.255.255.255 route-advertisement disabled spanning disabled traffic-group default\ntmsh::create ltm virtual /trace_tenant/SampleApp/Sample_service address-status yes auto-lasthop default connection-limit 0 description \\\"SampleApp\\\" destination /trace_tenant/1.2.3.4:100 ip-protocol tcp last-hop-pool none mask 255.255.255.255 mirror disabled persist replace-all-with \\{ /Common/cookie \\{ default yes \\} \\} policies none profiles replace-all-with \\{ /Common/http \\{ context all \\} /Common/f5-tcp-progressive \\{ context all \\} \\} source 0.0.0.0/0 source-address-translation \\{ type automap \\} rules none security-log-profiles none source-port preserve translate-address enabled translate-port enabled nat64 disabled vlans none vlans-disabled metadata none clone-pools none\ntmsh::commit_transaction\n} err] } {\ncatch { tmsh::cancel_transaction } e\nregsub -all {\"} $err {\\\"} err\ntmsh::modify ltm data-group internal __appsvcs_update records add \\{ error \\{ data \\\"$err\\\" \\} \\}\ncatch { tmsh::delete sys folder /trace_tenant/SampleApp/ } e\ncatch { tmsh::delete auth partition trace_tenant } e\n}}\n}"
}
}