F5 BigIP V9 in Layer 2(bridging) mode in the design

Hi there,

 

 

I can't comment specifically on what F5 has told you, but I can say that just because something can be done with a BIG-IP doesn't mean it's ideal for every scenario. I'd suggest you either open a case with F5 Support to address the specific technical issues you're seeing or go back to the person that suggested you shouldn't use this configuration and ask them for clarification.

 

 

Maybe others here can provide more detail on why they do/don't like using BIG-IP in Layer 2 mode.

 

 

Aaron

Aaron,

 

Thanks for your comment. The issue currently we are having that is causing us not to cutover to production with F5 box is that when active F5 failed scenario is tested, standby F5 becomes active but 20% of the time ping packets gets lost for 10 packets instead of 1 packet restoring the services to the clients without loosing their sessions. Currently there is case with F5 and support engineers in Singapore is looking into it. At this point in time F5 is treating it as a bug in F5 and trying to come up with the hotfix. We have only two F5 and I need to load balance webfacing application servers as well as application servers in my internal application servers that cannot have access from the web facing subnets. Risk of using route mode config for F5 is during rules modifications if something goes wrong then there is a risk of webfacing vlans can be routed to internal Vlans without going through firewall. This is my high level understanding. F5 has not come back to me officially with their perspective yet. I want to know how many installations are using Layer 2 and their issues in on going management and support. Thanks. Prakash

Hi Prakash,

 

 

You can isolate VLANS in a Layer 3 config using the architecture I described in this post: (Click here).

 

 

Layer 2 mode was designed to be able to replace existing installations of other equipment that was operating in bridge mode, but I don't know of anyone that recommends it as a "best practice" because of the complexities involved and because it can make the network susceptible to broadcast storms if everything is not configured correctly.

 

 

Are you using the serial failover cable or network failover? If you are using the serial cable, make sure that you are NOT using network failover, it's much slower to react.

 

 

Denny

Hi Denny,

 

 

The original design requirement was to eliminate all config complexity on the LTM and dumb them down - hence the bridge-mode config and all routing/ security is enforced in the upstream firewalls.

 

 

Yes, we could have used virtual network forwarders per VLAN but the bridge mode config drives everything to the firewalls by default, and preventing any inter-zone traffic is critical.

 

 

In terms of the size of the broadcast domain, it's minimal (single hop into a Cisco 3750 to which the servers are directly attached) and the number of devices per VLAN is very low - no issues with broadcast storms. Of course the broadcast domain is the same size in L2 or L3 for the same VLANs.

 

 

So the question is not so much "what do we consider best practices?", but rather "which available F5 config best suited the overall customer needs?" As you point out, bridge-mode (and let's not forget L2 design best practices) have been around since Moses played quarterback for Nazareth, so this posed a low risk approach.

 

 

Of course in the absence of the various requirements and constraints, a route-mode design would have been a more elegant solution.

 

 

The key issue at this time is a corner case where the FDBs appear to behave non-deterministically when the failed primary LTM recovers and comes back online. The initial failover is clean, but recovery is not. The guys have spent a lot of time checking the obvious things on the LTMs and the 3750s, hence the support case.

 

 

Cheers,

 

 

Andrew