Service_Forwarding objects should disable arp and icmpEcho

[wncocz]

Environment

• Application Services Version: 3.21.0
• BIG-IP Version: 13.1.3.0.21.6

Summary

Service_Forwarding objects' virtualAddresses are created with arp and icmp-echo enabled. These larger-than-/32 VAs should have those two options disabled. Or there should be some way for us to specify that they should be disabled.

Steps To Reproduce

Steps to reproduce the behavior:

1. Submit the following declaration:

{
    "class": "ADC",
    "schemaVersion": "3.20.0",
    "id": "passthru-0001",
    "passthru": {
        "class": "Tenant",
        "passthru": {
            "class": "Application",
            "passthru_from_10.10.10.0_24_0": {
                "allowVlans": [
                    {
                        "bigip": "/Common/inside"
                    }
                ],
                "class": "Service_Forwarding",
                "forwardingType": "ip",
                "shareAddresses": true,
                "snat": "none",
                "translateServerPort": false,
                "virtualAddresses": [
                    [
                        "0.0.0.0",
                        "10.10.10.0/24"
                    ]
                ],
                "virtualPort": 0
            },
            "passthru_to_10.10.10.0_24_0": {
                "allowVlans": [
                    {
                        "bigip": "/Common/outside"
                    }
                ],
                "class": "Service_Forwarding",
                "forwardingType": "ip",
                "snat": "none",
                "translateServerPort": false,
                "virtualAddresses": [
                    "10.10.10.0/24"
                ],
                "virtualPort": 0
            },
            "template": "generic"
        }
    },
}

2. Observe that the virtual-address objects 0.0.0.0 and 10.10.10.0 are created with arp enabled and icmp-echo enabled.

Expected Behavior

The virtual-address objects should be created with arp and icmp-echo disabled. Such is the case when you manually enter (tmsh) create ltm virtual test destination 10.10.10.0:0 ip-forward mask 255.255.255.0 source 0.0.0.0/0 vlans add { outside } vlans-enabled

[dstokesf5]

You can take control of the virtual address parameters by explicitly defining the virtual address in your declaration using the Service_Address class: https://clouddocs.f5.com/products/extensions/f5-appsvcs-extension/latest/declarations/miscellaneous.html#advertising-a-route-for-a-service-address

[wncocz]

You can take control of the virtual address parameters by explicitly defining the virtual address in your declaration using the Service_Address class: https://clouddocs.f5.com/products/extensions/f5-appsvcs-extension/latest/declarations/miscellaneous.html#advertising-a-route-for-a-service-address

Thank you, I did not find that when I was looking for answers on my own.

But AS3 should have sensible defaults that align with TMSH.

[wncocz]

Is this issue going to remain "invalid?" I feel it's a valid issue where AS3 requires me to separately create a Service_Address object in order to implement the normal TMSH defaults for a larger-than-/32 virtual-address.

This is especially true in the case of a shared 0.0.0.0/0 address. This sort of thing should just work.

Would it help if I also opened a case with F5 Support?

[dstokesf5]

Unfortunately AS3 defaults cannot change without changing the behavior of older declarations. One of AS3's highest priority design goals is to never break older declarations.

[wncocz]

Can we take a vote? (Ha!)

This behavior is broken, at least for Service_Forwarding objects. Virtual-addresses created by these should not be answering ARP or ICMP-echo. Am I the only one using these?

[wncocz]

OK, I get it: no vote. Please, consider this situation which is very common for us:

We need to create virtuals that route traffic from 'inside' VLANs to 'outside' VLANs, using the destination 0.0.0.0/0:0.
We have other Apps (in other Tenants) that also need to use this wildcard virtual-address for traffic inbound from 'outside' to 'inside'.

We should be able to simply use virtualAddresses: [0.0.0.0/0] along with shareAddresses: true. We can do this, and AS3 will do it all automatically (thanks to the fixes in 3.22.1, right?).

But that leaves us answering all ARP requests and ICMP requests on all VLANs we're on. Triggering servers whining about "duplicate IP detected" and the like. This is not the way!

What do you suggest we do instead? Should we define "/Common/Shared/addr_0.0.0.0" in a separate declaration that is then referenced by each Tenant?

We have tried adding 'addr_0.0.0.0' to the application, but it is created within the Tenant's partition (even though shareAddresses: true!).

What is the use case for configuring arp/icmp enabled on 0.0.0.0/0? Does anyone want this? (What about other smaller subnets?)

[wncocz]

We did this. We created a Shared declaration that creates:

"vs_0.0.0.0_0": {
          "class": "Service_Address",
          "virtualAddress": "0.0.0.0/0",
          "arpEnabled": false,
          "icmpEcho": "disable",
}

We deployed that, and it looks fine:

# list ltm virtual-address /Common/Shared/va_0.0.0.0_0
ltm virtual-address va_0.0.0.0_0 {
    address any
    arp disabled
    icmp-echo disabled
    inherited-traffic-group true
    mask any
    traffic-group /Common/traffic-group-1
}

But then we deployed the passthru Tenant: with a virtual like so:

                "passthru_from_10.11.12.0_24.oc.w11_0": {
                    "allowVlans": [ { "bigip": "/Common/inside" } ],
                    "class": "Service_Forwarding",
                    "forwardingType": "ip",
                    "profileL4": { "bigip": "/Common/fastL4" },
                    "snat": "none",
                    "translateServerPort": false,
                    "virtualAddresses": [
                        [
                            { "bigip": "/Common/Shared/va_0.0.0.0_0" },
                            "10.11.12.0/24"
                        ]
                    ],
                    "virtualPort": 0
                },

The cli script generated has "mask 255.255.255.255" which causes our /Common/Shared/va_0.0.0.0_0 to get assigned a mask of 255.255.255.255. Perhaps this should be a separate issue. I'm now officially at my wits end. I don't see a means to build the tmsh-default stuff using AS3 here.

edit: Sorry, it was a very long day. Submitted new issue #339 (but I still don't understand these defaults).

[dstokesf5]

@wncocz I understand the current defaults are frustrating for you. When these features were added we were unaware that virtual-address objects had different defaults based on the IP address. Changes to defaults after a feature is released means there is a change in behavior that could break a customer's setup when they upgrade. That being said, I do see a potential case for calling this a bug. Not because the default is different from tmsh, but because the user would expect AS3 to generate a reasonable virtual-address object when only an IP address is given on a Service_* declaration.

I would like to gather some additional information before we go down that route though.

1. With Unable to deploy common partition  #399 resolved, are you currently encountering any issues with a Service_Address object with an address of 0.0.0.0 declared in /Common/Shared and referenced with a use-pointer in another tenant/application?
2. Are you aware of any use case where a user may want to have ICMP echo or ARP enabled on a virtual address object with an address of 0.0.0.0?
3. Are you aware of any use case where a user may want to have ICMP echo or ARP enabled on a virtual server of type forwarding with an address other than 0.0.0.0?

[wncocz]

1. With Unable to deploy common partition  #399 resolved, are you currently encountering any issues with a Service_Address object with an address of 0.0.0.0 declared in /Common/Shared and referenced with a use-pointer in another tenant/application?

Assuming you meant #339 -- It looks like my /Common/Shared/va_0.0.0.0 no longer gets its mask clobbered, so that is good.

2. Are you aware of any use case where a user may want to have ICMP echo or ARP enabled on a virtual address object with an address of 0.0.0.0?
3. Are you aware of any use case where a user may want to have ICMP echo or ARP enabled on a virtual server of type forwarding with an address other than 0.0.0.0?

I'm not aware of any use cases for either of these. They both sound like bad recipes.

[dstokesf5]

Yes, I meant #339. Thank you for your additional feedback. I will pass it on to the developers.

[dstokesf5]

Added AUTOTOOL-2265 to our internal product backlog to make sure that Service_Forwarding classes do not generate virtual-address objects that have arp and icmp-echo enabled. Thank you for your patience and assistance in helping us better understand this issue.

[wncocz]

Thank you for all your help on this. We just tried a declaration equivalent to the original in Steps to Reproduce with AS3 3.27.0 (on BIG-IP 14.1.4.1), and it works as desired. The /Common/0.0.0.0 v-a is automatically created with the correct arp/icmp settings, and the 10.10.10.0/24 v-a is created in the tenant partition, also with the correct arp/icmp settings. We no longer have to "manually" manage virtual-address objects for ip-forward virtuals.