Issue

You may observe that ICMP response (return) traffic is randomly dropped by the F5. This behaviour occurs when using tagged VLANs and packet-filters on the F5.
Below shows the issue in further detail. An ICMP Ping is initiated from the F5 and a packet capture is run.  We can see from the Ping that the Reply for seq=186 is not received.

[root@f5-ltm:Active] ~ # ping 192.168.1.100
PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
! output omitted !
64 bytes from 192.168.1.100: icmp_seq=185 ttl=255 time=1.10 ms
64 bytes from 192.168.1.100: icmp_seq=187 ttl=255 time=1.37 ms
64 bytes from 192.168.1.100: icmp_seq=188 ttl=255 time=0.992 ms

However within the packet capture we can see that seq=186 is seen by the F5 but incorrectly processed as VLAN 0 and in turn dropped.

[root@f5-ltm:Active] ~ # tcpdump -s 0 -ni TRUNK-SEGMENT-VLAN100:nnn host 192.168.1.100 and icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on TRUNK-SEGMENT-VLAN100:nnn, link-type EN10MB (Ethernet), capture size 65535 bytes
15:01:12.612487 IP 192.168.1.100 > 172.16.1.100: ICMP echo reply, id 23101, seq 186, length 64 in slot1/tmm0 lis= flowtype=0 flowid=0 peerid=0 conflags=0 inslot=0 inport=256 haunit=0 peerremote=00000000:00000000:00000000:00000000 peerlocal=00000000:00000000:00000000:00000000 remoteport=0 localport=0 proto=0 vlan=0
15:01:12.612113 IP 172.16.1.100 > 192.168.1.100: ICMP echo request, id 23101, seq 186, length 64 out slot1/tmm1 lis= flowtype=130 flowid=BBEA1C0 peerid=B95B800 conflags=E26 inslot=0 inport=0 haunit=0 peerremote=00000000:00000000:0000FFFF:0AA0FDEA peerlocal=00000000:00000000:0000FFFF:0BB0C0E2 remoteport=23101 localport=8 proto=0 vlan=100
15:01:13.611519 IP 172.16.1.100 > 192.168.1.100: ICMP echo request, id 23101, seq 187, length 64 out slot1/tmm1 lis= flowtype=130 flowid=BBEA1C0 peerid=B95B800 conflags=E26 inslot=0 inport=0 haunit=0 peerremote=00000000:00000000:0000FFFF:0AA0FDEA peerlocal=00000000:00000000:0000FFFF:0BB0C0E2 remoteport=23101 localport=8 proto=0 vlan=100
15:01:13.611872 IP 192.168.1.100 > 172.16.1.100: ICMP echo reply, id 23101, seq 187, length 64 in slot1/tmm1 lis= flowtype=130 flowid=BBEA1C0 peerid=B95B800 conflags=E26 inslot=0 inport=512 haunit=0 peerremote=00000000:00000000:0000FFFF:0AA0FDEA peerlocal=00000000:00000000:0000FFFF:0BB0C0E2 remoteport=23101 localport=8 proto=0 vlan=100
15:01:14.612884 IP 172.16.1.100 > 192.168.1.100: ICMP echo request, id 23101, seq 188, length 64 out slot1/tmm1 lis= flowtype=130 flowid=BBEA1C0 peerid=B95B800 conflags=E26 inslot=0 inport=0 haunit=0 peerremote=00000000:00000000:0000FFFF:0AA0FDEA peerlocal=00000000:00000000:0000FFFF:0BB0C0E2 remoteport=23101 localport=8 proto=0 vlan=100
15:01:14.613182 IP 192.168.1.100 > 172.16.1.100: ICMP echo reply, id 23101, seq 188, length 64 in slot1/tmm1 lis= flowtype=130 flowid=BBEA1C0 peerid=B95B800 conflags=E26 inslot=0 inport=512 haunit=0 peerremote=00000000:00000000:0000FFFF:0AA0FDEA peerlocal=00000000:00000000:0000FFFF:0BB0C0E2 remoteport=23101 localport=8 proto=0 vlan=100

This can cause a number of issues such as ICMP Node monitor failure and/or packet-loss to transit traffic.

Note : This issue only affects ICMP traffic.

Background

This issue was originally tracked (via CR120747) and resolved (via a hotfix) in version 10.1. However at present there is no documented hotfix for this bug within 10.2.

Workaround

As it stands there are 2 work-arounds

1. exclude the VLAN from the packet filter.
2. add an explicit allow for the ICMP reply (or return traffic). Further details can be found in the link below.

Reference

http://support.f5.com/kb/en-us/solutions/public/10000/100/sol10179.html