Forum Discussion

Thomas_McLean_1's avatar
Thomas_McLean_1
Icon for Nimbostratus rankNimbostratus
Jun 21, 2012

why internal and external

All,

 

 

can you explain why when setting up the big-ip you should have an internal vlan and an external vlan? I'm getting more comfortable with F5 kit but the more aware I get the more curious I become - this can only be a good thing in the long run...

 

 

So in summary is there a reason why we do internal and external vlans? If so is there documentation for me to read to understand this.

 

 

Thanks in advance.

 

  • This is for very basic configurations, and is rarely used in my experience. If you know enough about your network I typically recommend to click the "Finished" button on the initial setup, and to configure your interfaces, VLANs, etc. manually. The basic configuration assumes you will be routing through the BIG-IP, hence the Internal and External names. Often the BIG-IP may be configured in a one-arm mode, and then use SNAT. If you are using a routed mode configuration it would be more likely that you would want more than 2 VLANS, placing a VLAN and SelfIP on each network that will house servers, and a "transport VLAN" on the "External" side that will have the inbound routes for the VIPS, and the default route out.
  • Thomas: To elaborate a bit on Eric's response, there are a several modes that the BigIP can operate in. Note that the terms 'external' and 'internal' really only mean the client-facing or server facing vlans in question. At least that's the definition I'm using for the examples below. Onward...

     

     

    1) In line, routed mode. This is the impetus for the internal and external vlan setup for the most part. The idea here is you've got two (or more) distinct vlans - 'external' facing and 'internal' facing, although this is an arbitrary distinction. For in line routed mode your servers point to the floating IP on the internal facing vlan as their default route. The BigIP will process the flows like this:

     

     

    client-> VIP (external) -> DNAT/DPAT -> Servers

     

     

    Then the servers will respond out their default route, in this case the float, and the BigIP will reverse the translations and respond to the client.

     

     

    2) One-armed mode. This is defined by having the VIPs and the destination pool members on the same VLAN. The servers point to another default route (usually, although not strictly required in one-armed-mode). In order to avoid route asymmetry, the BigIP will source the traffic from a SNAT that you define, or the default of the floating IP address on the VLAN in question.

     

     

    3) N-Path or direct server return. This is a rare edge case that used to make sense but rarely does anymore. I won't go into it here.

     

     

    4) "L3" mode, which is one of my favorites and I consider it to be best practice, particularly in large environments. On the one hand it seems advanced, but on the other it simplifies things, especially during fail over events. The idea is to have a Self-IP on the external facing side. You've got a normal 'internal' vlan setup. The trick with this deployment is all in the virtual server setup. The virtual servers can be bound to any addresses that you want, as you disable ARP on them. They won't advertise themselves to the network at all. The only address (or object, in BigIP parlance) that knows about them is the Self-IP address. It'll forward to them correctly and generally do the right thing. Your upstream routers should be setup to know to forward traffic destined for the VIP address(es) to the Self-IP of the LTM, hence the "L3" deployment. The advantage of this particular design is that it dramatically reduces the amount of GARP that happens during failover - the only IPs that GARP are now the Self-IPs - and it allows you to handle your VIP addressing in much more creative ways than being on a real network :)

     

     

    Anyhow, I hope this helps.

     

     

    --Matt
  • As Matt said, internal/external is just a name, there is no difference in how they operate like the designation would indicate in a traditional firewall product. And to Eric's point, I agree, I usually drop out of the initial configuration ahead of the network configuration so I can define the vlan names in a meaningful way specific to my environment.
  • Everyone, all great answers - and it does clear a lot of things up for me - to me the hardest part of the F5 experience (or most challenging) was the setup of the devices - I just believe it wasn't as helpful as it should be.

     

     

    You guys have given me extra food for thought and explained it concisely.

     

     

    Thanks again!