Declaring the same pool member server name multiple times validates, but only uses the last IP address and does not error out

[andrenrwn]

Environment

• Application Services Version: 3.45.0
• BIG-IP Version: 17.x

Summary

When declaring multiple pools with named server pool members with different IP addresses, only the last IP address is created, and there are no validation errors / warnings.

Steps To Reproduce

Steps to reproduce the behavior:

1. Submit the following declaration, noting that there are two pools that contain the same named node with different IP addresses: "pool_test01-vip": { "members": [{"servers": [{"name": "ns1.test.local","address": "10.1.1.1"}], and "pool_test01-vip-http": {"members": [{"servers": [{"name": "ns1.test.local","address": "10.3.3.3"}],

{
    "$schema": "https://raw.githubusercontent.com/F5Networks/f5-appsvcs-extension/master/schema/latest/as3-schema.json",
    "class": "AS3",
    "declaration": {
        "class": "ADC",
        "schemaVersion": "3.45.0",
        "label": "Converted Declaration",
        "test01-vip": {
            "class": "Tenant",
            "test01-vip-app": {
                "class": "Application",
                "template": "generic",
                "test01-vip": {
                    "remark": "test01-vip-app",
                    "layer4": "any",
                    "pool": "pool_test01-vip",
                    "translateServerAddress": false,
                    "translateServerPort": false,
                    "persistenceMethods": [],
                    "class": "Service_L4",
                    "virtualAddresses": [
                        "10.11.0.100"
                    ],
                    "virtualPort": 0,
                    "snat": "none"
                },
                "pool_test01-vip": {
                    "loadBalancingMode": "round-robin",
                    "members": [
                        {
                            "servers": [
                                {
                                    "name": "ns1.test.local",
                                    "address": "10.1.1.1"
                                }
                            ],
                            "servicePort": 0,
                            "shareNodes": true
                        }
                    ],
                    "class": "Pool"
                },
                "test01-vip-http": {
                    "remark": "test01-vip-app",
                    "layer4": "tcp",
                    "pool": "pool_test01-vip-http",
                    "translateServerAddress": true,
                    "translateServerPort": true,
                    "class": "Service_HTTP",
                    "profileTCP": {
                        "bigip": "/Common/f5-tcp-progressive"
                    },
                    "profileHTTP": {
                        "bigip": "/Common/http"
                    },
                    "virtualAddresses": [
                        "10.11.0.100"
                    ],
                    "virtualPort": 80,
                    "snat": "auto"
                },
                "pool_test01-vip-http": {
                    "loadBalancingMode": "round-robin",
                    "members": [
                        {
                            "servers": [
                                {
                                    "name": "ns1.test.local",
                                    "address": "10.3.3.3"
                                }
                            ],
                            "servicePort": 80,
                            "shareNodes": true
                        }
                    ],
                    "class": "Pool"
                }
            }
        }
    }
}

2. Observe that the :

{
  "results": [
    {
      "code": 200,
      "message": "success",
      "lineCount": 27,
      "host": "localhost",
      "tenant": "test01-vip",
      "runTime": 2942,
      "declarationId": "autogen_ec81e51f-57c6-445a-819e-edd0de5724fd"
    }
  ],

Expected Behavior

The declaration should fail because the declaration should not have the same named pool member with different IP addresses. The array keys for "servers" should be unique for each {"name","address"}

Actual Behavior

The declaration succeeds, but the customer / consulting deployment faced setbacks due to the unexpected behavior because they are incorrectly using the same name for different nodes.

But even though the incoming configuration is not correct (ie. named pool members should be unique) I don't think we should say that this is functioning as designed. Because what we really want is for this declaration to fail validation. This way our software is more user-friendly and we can ensure that incorrect customer delcarations does not produce unexpectedly validated non-working configurations.

Furthermore, we know that each node is unique can only be declared once, and each node should have been referenced via the name or IP address from the pool members list. Normally, BIG-IP automatically creates the nodes if they don't yet exist from adding a new pool member. So ideally an AS3 declaration should reference each pool member by name or IP to a master list of nodes. However, it seems like AS3 independently defines pool members separately from nodes or does not require nodes to be delcared, so therefore we think AS3 needs to explicitly validate whether named pool members are unique.

Can there be any possible solutions/modifications on how to validate this? JSON schema deeper object uniqueness A Vocabulary for Extended Validation of Arrays

[sunitharonan]

I understand the concern. In AS3, when you declare pool members with "serverAddresses" (and do not use addressDiscovery), each member implicitly or explicitly references a named address object in the BIG-IP config. If multiple members use the same name, only the last one wins, because AS3 treats them as the same object and overwrites the earlier ones.

I have created an internal backlog item AUTOTOOL-4709 to see if we could add validation. In order to prioritize this issue, please reach out to us at [email protected]

[andrenrwn]

I have created an internal backlog item AUTOTOOL-4709 to see if we could add validation. In order to prioritize this issue, please reach out to us at [email protected]

Thanks a lot for the fix! Normally we in the general public won't know what autotool or jira.f5net.com is about. I would rather you not include that inaccessible internal link unless necessary, but instead quote the release version name of the .rpm where this is fixed, and the commit link or diff that made the fix.

Before the fixed f5-appsvcs-3.54.0-9.noarch.rpm is released in a future release in this repo, F5 customers will be able to request the .rpm from F5 support by referencing ID 1937941.

Thanks for the fix!

[mdditt2000]

Resolved in AS3 55