Forum Discussion

boo_radley_1114's avatar
boo_radley_1114
Icon for Nimbostratus rankNimbostratus
Apr 11, 2011

new to F5 - basic understanding of VLAN and config

Hi folks -- I just inherited an F5 LTM (6900) that is being used in a test lab, and would love to ask a couple of very general and "newbie"ish questions on the configuration if I might?

 

 

First, for my general understanding -- in *all* cases does traffic from the servers balanced by the F5 return back through the F5 to avoid the 'asymetric routing' issue? Or in some cases can this be configured differently?

 

 

Anyway, all of our test traffic is on a private, physically separate LAN with an ip address schema of 10.10.20.* and netmask 255.255.255.0. There is a second LAN, used for management, internet access, etc., but it's not involved with the F5 (except that the F5 managment port is on it). I have a single VLAN configured called "internal" using interface 1.1 (the only interface used), and a self-ip address. I have about ten different virtual servers being load balanced, and each is defined to use "SNAT AUTOMAP".

 

 

1) Would I gain an advantage by configuring an additional VLAN? In Chapter 5 of the BIG-IP Network and Managment Guide, if I read it correctly if I have a second VLAN group and it shares the 'same address space' (ie, same subnet?) I won't need SNAT. If I create a second VLAN group would I need to change my network addressing, and create a new subnet?

 

 

2) I'm concerned at overwhelming the single interface eventually. Currently I'm seeing peaks of around 200Mbps, but I would expect about 7x more traffic eventually. Would creating a second VLAN help me here -- eg., I could have client traffic coming in on 1 VLAN and port 1.1, and traffic to the back-end servers on port 1.2? (Utimately, I probably want to truck the interfaces, as well, but can't do that until I get more modern, managed switches). Thx!

 

basic
getting started
new to f5

2 Replies

Sort By
  • Hamish's avatar
    Hamish
    Icon for Cirrocumulus rankCirrocumulus
    Apr 11, 2011
    Well.

     

     

    Asymmetric routing is supported. It's usually referred to as n-path routing in F5 world. However the limitation of that is that you can't perform any manipulation of traffic from server back to client.

     

     

    There's two methods of having the return traffic pass via the F5. SNAT (Where the F5 actually looks like the proxy it really is :) that you're already using, and routed where the return path to the client from the server is via the F5. (The return traffic usually has to return via the same interface that the F5 sent it to the server on BTW, returning to the F5 via a separate interface doesn't work (Or didn't used to. It may have been fixed, but I don't think it has)). The routed method means that the server sees the connection as coming from the original client IP. Very useful for debugging, especially where protocols don't support the equivalent of X-ForwardFor headers like in HTTP (Because you can tcpdump on the clients IP at the server).

     

     

    Now. Your questions.

     

     

    1. If you configure an additional VLAN, I'd doit as a separate subnet. Not the same address space. Same address space implies bridging. Which is seldom conducive to scaling. To create a new subnet you don't have to change your addressing scheme. Just allocate another /24 network and use that.

     

     

    2. If you create a new subnet and slit services over them, you'll reduce your traffic on your VLAN interface by whatever amount. If you're concerned about traffic across your VS VLAN, you could create two of them too. Or more. But ideally etherchannels (F5 calls them trunks, but they're not the same as a cisco trunk) or link aggregation (Using LACP) is best for scaling traffic without subnetting your network and trying to split traffic that way).

     

     

    H

     

     

     

     

     

  • boo_radley_1114's avatar
    boo_radley_1114
    Icon for Nimbostratus rankNimbostratus
    Apr 12, 2011
    Thanks, Hamish.

     

     

    I will look into link aggregation although I'm not certain our switches support it (they're unmanaged linksys switches), and also creating some additional subnets, although the latter more for management ease.