VLAN group

If you think about firewall load balancing for example, and you want to deploy a load balancer "transparently" between routers and firewalls that sits in the same VLAN, within the same IP range, and for a reason, you don't want to split the subnet or rearchitecture (i have seen customers doing BGP/OSPF here, and don't want to involve the F5 in the dynamic routing process). All the traffic that is crossing the load balancer is sent to destination IPs that are not the firewall, but servers behind the firewalls. So in that case, you just need to load balance "MAC adresses" as the "nexthop" for the load balancer, and not touch at the IPs (source or destination). It is not making sense in most of the cases to have the load balancer do something different than load balancing the firewalls. And because you don't have an option to sit in the L3 path, then you have to do it in L2 (or "transparent at L3). This is one of the reason why L2 Load Balancing exists (same for Cache load balancing for example). For the second point, you can do it with VLANGroups WITHOUT SNAT. In some cases, it is not allowed to NAT the client IP. So putting clients on a VLAN, and servers on another VLAN, the BigIP is acting then as a "bridge" for both of them (you can here select with "transparent", "translucent", ... ho the system behave when managing the MAC adresses by rewriting part of them or not). HTH

Hi Hamzeh,

point number two : this can be achieved without vlan group by creating a specific virtual server with the source is the internal subnet and using snat auto map ) , what is the added value of vlan group in this case ???

Actually the case you are referring to is when both hosts reside on the same subnet and same VLAN. The VLAN group allows hosts on the same subnet but different VLANs to talk.

in general , how the f5 box will decide that this host is a member of vlan 10 and the other host is a member of vlan 20 when both of them are in the same subnet ?

The interface on which ingress traffic arrives in combination with the 802.1q tag (or lack thereof) tells the LTM which VLAN a source host is on.

Thank you Philou and Joanna, your descriptions are very accurate , I got them.

but regarding to the second point , Joanna you are true this is the case , in this case as you said the host and the server communicate through the vlan group , as the f5 will broadcast the arp sent by the host to the servers vlan , then they will communicate directly , but what if the host want to hit the virtual server not the physical server , then it will be the case of virtual server with snat auto map and the vlan group will not benefit us , right ?

If both your servers are in the same subnet, same VLAN, then the virtual server with SNAT is the way to go.

VLAN groups are for bridging VLANs which doesn't sound like what you want to do.

Hi Philou, Kindly regarding to the scenario of transparency of F5 between routers and firewalls , its clear that F5 vs will be (forwarding layer 2) so when the traffic comes to f5 it will send it to the firewalls but how , where it looks ( to the route table or arp table or what) and if we keep the router and the firewall in the same vlan without vlan group , whats the problem ? i think the router will drop the arps and no problems will happen , what is the added value of vlan group in this case ?

I have an issue which I wonder if a VLAN group, which I don't yet understand fully from the available documentation, would help.

There is a BIG-IP active/standby pair monitored via SNMP. The SNMP client connects to a floating address (not a virtual server) in the internal VLAN of the F5 device, querying its SNMP server. It does so so that it would always get the state of the active device.

From time to time, the connection from the SNMP client to the F5 active device will timeout, causing the SNMP query to fail and generate a false alarm through an alert to application service owners.

A packet capture on the F5 shows that when the issue occurs, the BIG-IP uses "127.0.0.1" as the source address in its response packet, making the SNMP response invalid. Also, the same capture file shows that there are occasions when the SNMP query comes from the external SNMP client address directly destined for "127.0.0.1".

The SNMP client machine resides in a VLAN that is also present on the F5 pair, which has a floating IP address as well as a local IP address on each of the F5 devices in that VLAN.

Any help is appreciated.

A packet capture on the F5 shows that when the issue occurs, the BIG-IP uses "127.0.0.1" as the source address in its response packet, making the SNMP response invalid.

have you opened a support case? i do see this known issue but not sure if it matches yours. it is discovered in 11.5.0 and is fixed in 12.0.0.

ID458585 BIG-IP SNMP-response has wrong source address of localhost (127.0.0.1)

A packet capture on the F5 shows that when the issue occurs, the BIG-IP uses "127.0.0.1" as the source address in its response packet, making the SNMP response invalid.

have you opened a support case? i do see this known issue but not sure if it matches yours. it is discovered in 11.5.0 and is fixed in 12.0.0.

ID458585 BIG-IP SNMP-response has wrong source address of localhost (127.0.0.1)