LocalLBVirtualServer.get_type() not returning correct values.

Hi!

I don't have a 11.2.1 available, but it seems to be working in 11.5.1, with the latest powershell snapin (have you installed, or upgraded recently?).

Sample config:

ltm virtual /Common/Forwardtest {
    destination /Common/10.1.1.0:0
    ip-protocol tcp
    mask 255.255.255.0
    profiles {
        /Common/fastL4 { }
    }
    source 0.0.0.0/0
    translate-address disabled
    translate-port disabled
}

ltm virtual /Common/Reject {
    destination /Common/1.1.1.1:0
    ip-protocol tcp
    mask 255.255.255.255
    profiles {
        /Common/tcp { }
    }
    reject
    source 0.0.0.0/0
    translate-address enabled
    translate-port enabled
}
ltm virtual /Common/Stateless {
    destination /Common/2.2.2.2:80
    ip-protocol udp
    mask 255.255.255.255
    pool /Common/PajoIIS-8080-8081_pool
    profiles {
        /Common/udp { }
    }
    source 0.0.0.0/0
    stateless
    translate-address enabled
    translate-port enabled
}

Powershell code:

Initialize Snapin

if ( (Get-PSSnapin | Where-Object { $_.Name -eq "iControlSnapIn"}) -eq $null ){
    Add-PSSnapIn iControlSnapIn
}

$User = "iUser"
$Password = "mypassword"
$Partition = "Common"
$BigIP = "192.168.161.10"

Connect to the BigIP
$Success = Initialize-F5.iControl -HostName $BigIP -Username $User -Password $Password

Get an iControl Handle
$F5 = Get-F5.iControl

$vslist = $f5.LocalLBVirtualServer.get_list()
$f5.LocalLBVirtualServer.get_type($vslist)

Output:

RESOURCE_TYPE_L2_FORWARDING
RESOURCE_TYPE_REJECT
RESOURCE_TYPE_STATELESS

Probably not the answer you were hoping for, but I'd suggest upgrading the PS snapin and then, if needed, the LTM.

Hope it helped.

/Patrik

I am seeing the same behavior between a standard and Perf L4 VS in v11.5.0 (albeit using python/bigsuds):

ltm virtual test_asm_vs {
    destination 1.1.1.1:http
    ip-protocol tcp
    mask 255.255.255.255
    pool test_asm_pl
    profiles {
        http { }
        tcp { }
    }
    source 0.0.0.0/0
    vs-index 2
}
    ltm virtual test_asm_fastl4_vs {
    destination 1.1.1.6:80
    ip-protocol tcp
    mask 255.255.255.255
    profiles {
        fastL4 { }
    }
    source 0.0.0.0/0
    vs-index 6
}

Python:

>>> b.LocalLB.VirtualServer.get_type(['test_asm_vs'])
['RESOURCE_TYPE_POOL']
>>> b.LocalLB.VirtualServer.get_type(['test_asm_fastl4_vs'])
['RESOURCE_TYPE_POOL']

Since VS-type as is not necessarily a configuration item within the VS config, you may need to identify a VS by examining the profiles in combination with VirtualServer.get_type(). Seems a little weird, but its an option:

>>> b.LocalLB.VirtualServer.get_profile(['test_asm_fastl4_vs'])
[[{'profile_name': '/Common/fastL4', 'profile_context': 'PROFILE_CONTEXT_TYPE_ALL','profile_type': 'PROFILE_TYPE_FAST_L4'}]]

I am seeing the same behavior between a standard and Perf L4 VS in v11.5.0 (albeit using python/bigsuds):

ltm virtual test_asm_vs {
    destination 1.1.1.1:http
    ip-protocol tcp
    mask 255.255.255.255
    pool test_asm_pl
    profiles {
        http { }
        tcp { }
    }
    source 0.0.0.0/0
    vs-index 2
}
    ltm virtual test_asm_fastl4_vs {
    destination 1.1.1.6:80
    ip-protocol tcp
    mask 255.255.255.255
    profiles {
        fastL4 { }
    }
    source 0.0.0.0/0
    vs-index 6
}

Python:

>>> b.LocalLB.VirtualServer.get_type(['test_asm_vs'])
['RESOURCE_TYPE_POOL']
>>> b.LocalLB.VirtualServer.get_type(['test_asm_fastl4_vs'])
['RESOURCE_TYPE_POOL']

Since VS-type as is not necessarily a configuration item within the VS config, you may need to identify a VS by examining the profiles in combination with VirtualServer.get_type(). Seems a little weird, but its an option:

>>> b.LocalLB.VirtualServer.get_profile(['test_asm_fastl4_vs'])
[[{'profile_name': '/Common/fastL4', 'profile_context': 'PROFILE_CONTEXT_TYPE_ALL','profile_type': 'PROFILE_TYPE_FAST_L4'}]]