Forum Discussion

Glenn_32974's avatar
Glenn_32974
Icon for Nimbostratus rankNimbostratus
Jan 11, 2012

Inter-VLAN Routing on F5

Hello Guys!

 

 

I have been given the 172.31.39.0 / 24 network in order to create 4 Subnets to assign to corresponding VLANS

 

 

 

so right now I have :

 

 

172.31.39.0 / 26 subnet (VLAN 1)

 

172.31.39.64 / 26 subnet (VLAN 2)

 

172.31.39.128 / 27 subnet (VLAN 3)

 

172.31.39.160 / 27 subnet (VLAN 4)

 

 

 

my problem is that I can not make host on different VLANs (subnets) talk to each other...

 

 

I know this should be pretty straight forward but i can´t find the way

 

 

 

thanks in advnced!

 

18 Replies

  • I agree that loose option can be good, but only if you have a plain network without some security zones, what I mean is that if you have firewalls between you point A and B the firewall will be stateful and because of that it will block the traffic before the F5 so the loose option will not be in use.

     

     

    IMHO a firewall should do firewalling, a router should do routing and a ADC should do loadbalancing as far as you can.

     

    Some service I know by myself can´t be used with SNAT so then the F5 will be the router.

     

    SNAT is also not so fun for server administration guys but they can be learned =)

     

     

     

    Good though that this topic came up =)

     

     

     

    Regards,

     

     

     

    Beinhard

     

  • IMHO there is (in most cases) no need for a cisco (or whatever brand you like ;-) router if you already have a viprion 2x00/4x00 in your datacenter. Specially if your trafficflows are so that 99% or so of them will pass the F5 anyway. The VS used for routing (forwarding ip) wont do any SNAT on the traffic, it will just shuffle the packets (that is packets that doesnt match any other better matching VS). Also when the F5 sits inline the need for SNAT will in many cases go away aswell (compared to when it sits on a stick).

     

     

    Compare the following flows as example:

     

     

    client -> switch -> F5 -> firewall -> server

     

     

    vs

     

     

    client -> switch -> ciscorouter -> F5 -> ciscorouter -> firewall -> server

     

     

    and it can be even worse if the netadmin didnt think at all like:

     

     

    client -> switch -> ciscorouter -> switch -> F5 -> switch -> ciscorouter -> firewall -> server

     

     

    and so on ;-)
  • I disagree :)

     

     

    Lets take your primary suspects for why choosing a dedicated router instead of a Viprion:

     

     

    Easy migration

     

     

    Far easier to migrate the F5 if you ask me. When I setup a VS this VS is automatically (once I click the sync link) synchronized with the failover parter. Using cisco (or any other brand for that matter) and acl you need to manually login to BOTH devices and do the same work twice (with the risk that both devices after a while doesnt have the same config for example regarding acls and stuff).

     

     

    Easy to extend to different "sites" (with BGP or similar)

     

     

    F5 have builtin support for BGP, IS-IS, OSPF, RIP for both IPv4 and IPv6 so no problem here. Compared to most regular routers your F5 can also inject (and withdraw) these routes based on different monitors (not only based on latency and such which IP-SLA will bring you but also L7 stuff like low latency AND reachable for x numbers of times AND a dnsserver bringing you correct replies etc as a single monitor).

     

     

    Only dedicated traffic will hit the f5 (Loadbalancing traffic and not for example backups)

     

     

    Well in this case loadbalanced traffic will hit your routers which will be unnecessary. Regarding backups it depends on where you place your backupservers. You can for example place them behind the internal firewall (since the backups contains sensitive data - wont they?) and let this firewall perform QoS for all traffic going to/from the backup-dmz (backup-traffic gets lowest priority) and voila - you can now even perform backups at lunch hours (and not forced to wait until 0200AM).

     

     

    There are plenty of other stuff that the F5 can do which an ordinary router most times cannot - but something thats "hot" nowadays is IPv6... with the F5 as corerouter you can easily do 6to4 and 4to6 (and 6to6 along with 4to4 etc :P) which gives that your servers can still be IPv4 only (no need to dualstack) but at the same time you can speak to the rest of the world using IPv6.

     

     

    But lets take a look at the capacity for each blade and see if thats enough?

     

     

    Viprion 2400 (2100Blade):

     

    40Gbps L7/blade

     

     

    Viprion 4400 (4200Blade):

     

    18Gbps L7/blade

     

     

    Rumours says that there are new blades coming for the 4400 series (or if it was 2400 series, cant remember) this spring which will yield 320gbit/s per blade.

     

     

    Also what Im speaking about here is not to replace all your routers with F5's (even if that would work but in most cases be somewhat expensive =) but rather instead of using 2xRouters + 2xF5 you can merge these 4 units into just 2xF5.

     

     

    Q1: With backends-vlan you mean like server-vlans? In that case I would suggest to place them behind a firewall so I can have control of which traffic will be allowed between the zones (for example DNS-servers in one, AD-servers in another and so on). Preferly a NGFW (application firewall) which will not only look at portnumbers but rather whats actually being transmitted in those packets who is passing by.

     

     

    Q2: See above :-) For 150 Vlans one would need a L2-modular switch connected to the firewall with high speed and the firewall would have the SVI (the defgw for each vlan is an ip-address configured on the firewall). Use 802.1Q to separate the networks (and make sure you dont f**k up the config - for example turn off VTP, set interfaces into static trunk or static access mode (not auto) and also set allowed vlan for each and every interface in your L2-modular switch). This also depends on your infosec regulations along with how many interfaces your firewall have.

     

     

    Q3: Well its up to you but I prefer to put the firewall close to my golden eggs (so the eggs wont get scrambled =). So if the AD-server from Q1 wish to speak to the DNS-server it will eaither speak directly on the physical ip (this way the traffic goes AD -> L2-switch -> firewall -> L2-switch (another vlan) -> DNS) OR speak to the VS-ip but then the traffic will go out from the firewall to the core-F5 who will then decide which DNS-server your request will actually be sent to (same site or different site, unless the F5 will reply on its own ;-)

     

     

    Q4: This will be by design when you put each system in its own VLAN behind the firewall (where the VLAN ip (the defgw for the server) is an ip configured on the firewall as described in Q2). You can also bundle the systems into larger VLANs if you prefer it that way (or the other way around - each server gets its own VLAN so even traffic between DNS1 and DNS2 needs to pass the firewall).

     

     

    Regarding your comment on my flow example sure - but having the F5 before the firewalls (meaning client - F5 - firewall - server) is the preffered method if you have multiple sites (this way the core-F5 will send the client to the server which is actually reachable no matter if its the server who is failing or the firewall in front of the server). Using this setup you can then also enable WON (wan acceleration) in your F5 because the setup will basically be: siteA-F5 <-> WAN (MPLS, EVLS, own wavelengths or whatever) <-> siteB-F5
  • 0) Dont use the quote "feature" on this forum - its really hard to answer each individual claim by requoting the requote who is a quote and so on...

     

     

    1) Im pretty sure the PCI requirements wont allow you to have the loadbalancer between the firewall and the server because this way you are breaking your security zones.

     

     

    2) Do you perhaps have some more information regarding zebos (since there are plenty out there using both zebos and zebra as RR and other features)?

     

     

    3) As I see it there is no need for router + F5 when F5 alone can do the work very well. Having the F5 as core will also make you able to loadbalance between sites without involving BGP etc. Also perform a loadbalance at L7 level.

     

     

    You wont leak backuptraffic since the firewall will separate the flows. How will you otherwise perform backups?

     

     

    The backups in this case can be server -> firewall -> backupserver, the clients on their own have no need to perform backups towards the backupservers. Also backups from servers at site A will be to the backupservers at site A. In case backupservers at site A fails for the servers at site A the servers at site A can do their backup to the backupservers at site B if you wish. In this case the QoS will throttle the traffic but you can of course apply the same QoS rules in the F5 aswell to also shape the backuptraffic which might go over the WAN-links.

     

     

    Using an internal firewall will protect your golden eggs where you can have one DMZ for servers (lets say one vlan per system or per server), one DMZ for backupservers, one DMZ for logservers, one DMZ for pki-servers and so on.

     

     

    4) Firewalling and firewalling. One great feature that F5 brings you (which most firewalls wont) is the ASM feature with for example xml-gateway firewalling (to protect soap/webservices stuff). When you have F5 inline I see no reason for why not using the ASM for the flows where it can be used for :)

     

     

    Q1: One design can be as follows (just an example, in real life one would use smaller netblocks and so on):

     

     

    Zones behind the firewall:

     

    DMZ1: 10.x.1.0/24

     

    DMZ2: 10.x.2.0/24

     

    DMZ3: 10.x.3.0/24

     

     

    where x is which site (well datacenter that is).

     

     

    and then let 10.0.0.0/24 to be the virtual range where you put individual VS's.

     

     

    The firewall in this case will be all transparent (only nexthop will be visible and perhaps if one do a traceroute).

     

     

    So to reach each physical dns-server the client can either address 10.1.1.1 / 10.2.1.1 / 10.3.1.1 OR the client can just address 10.0.0.1 and let the F5 decide which DNS server the request will be forwarded to.

     

     

    The VS in this case would look like:

     

     

    10.0.0.1:53/255.255.255.255

     

    ->

     

    10.1.1.1:53

     

    10.2.1.1:53

     

    10.3.1.1:53

     

     

    Q2: The firewall is the defgw for the servers (one vlan per system or server depending on your needs). The switches which the servers can be attached do only need to do L2 (vlan-802.1Q) so no need for expensive L3 devices here. So yes the firewall will do routing but only routing for the DMZ's directly attached (L3-interfaces on the firewall). The defgw for the firewall will be pointing to the F5.

     

     

    Q3: The F5 is outside the firewall from the server point of view. But of course this is up to you where you choose to place your F5.

     

     

    Q4: No, the client address the VS in the F5 which sits close to the clients. The F5 will then decide which server at which site your request will be sent to. Because the server sits behind the internal firewall the F5 will not only take care of if a server is failing but also if the internal firewall is failing. If the internal firewall at the local site is failing the client request will be sent to another site (where the F5 addresses the physical ip of the server otherwise you would end up with a routingloop if your local F5 addresses VS at the other site).

     

     

    The physical design can be:

     

     

    External net

     

    |

     

    External firewall

     

    |

     

    Client(s) - F5 - WAN (to other sites)

     

    |

     

    Internal firewall

     

    |

     

    Server(s)

     

     

    (both external and internal firewall is connected to the F5 which acts corerouter and loadbalancer even if my ascii drawing skillz is failing ;)

     

     

    But how your design looks like depends on many parameters. The above will be robust against DDoS arriving from the external net because you might expect the external firewall to go offline which will then protect the internal resources (comparing to if you would connect all the networks to a single firewall - even if the external firewall is offline the internal firewall is still functioning and can serve your clients).
  • Hey guys I guess enough said and alot of suggestions given ... which are all wonderful... but what was initially asked was something pretty straight fwd and simple... why do we have to go to the level of VS of different kinds just to make the two vlans talk to each other.... can't we achieve it by simply giving the static routes on the LTM box????????

     

     

    Regards,
  • Hamish's avatar
    Hamish
    Icon for Cirrocumulus rankCirrocumulus
    The quick answer is because the LTM isn't a Router... However only 1 (Default) network VS is REQUIRED for it to forward traffic. Your requirement to policy route that via the firewall leads to a more complex solution.

     

     

    H
  • I have combed this thread to know how inter-vlan was accomplished not clear. Understood the via off tangent.

     

     

    Scenario:

     

    I have two internal VLANs. All configure with Vs for external incoming traffic. Now, I want a server in VLAN A to communicate to a server in VLAN B. No Firewall

     

     

     

    | VS

     

    LTM

     

    / \

     

    / \

     

    / \

     

    Vlan A VLAN B

     

    Server A Server B

     

     

    I can ping both servers from LTM. Both VLANs shows connected to the LTM /tmsh.net/show route.

     

     

    Do I need to create a VS for these two servers to talk to each other?

     

  • Do I need to create a VS for these two servers to talk to each other?yes, object listner (virtual server, snat or nat) is required.