Forum Discussion
7 Replies
- Faruk_AYDINNimbostratus
Hi Guy,
You must create a wildcard(0.0.0.0) "ip forwarding" virtual server, then you can create policy where you want to forward the traffic. Or you can do it with iRule. I wrote two sample iRule:use this for just looking the client network to redirect the traffic
when CLIENT_ACCEPTED { if {([IP::addr [IP::client_addr]/24 equals 10.10.10.0]) or ([IP::addr [IP::client_addr]/24 equals 11.11.11.0])} { forward the traffic to the first route pool pool_firstRoute } elseif {([IP::addr [IP::client_addr]/24 equals 40.40.40.0]) or ([IP::addr [IP::client_addr]/24 equals 41.41.41.0]) } { forward the traffic to the second route pool pool_secondRoute } else { forward the traffic to the default route forward } }
use this for more specific conditions
when CLIENT_ACCEPTED { switch -glob "src:[IP::client_addr] dst:[IP::local_addr] dport:[TCP::local_port]" "src:10.10.10.10 dst:20.20.20.20 dport:80" - "src:11.11.11.11 dst:20.20.20.20 dport:80" - "src:12.12.12.12 dst:3.3.3.3 dport:443" { forward the traffic to the first route pool pool_firstRoute } "src:40.40.40.40 dst:20.20.20.20 dport:80" - "src:41.41.41.41 dst:20.20.20.20 dport:80" - "src:42.42.42.42 dst:3.3.3.3 dport:443" { forward the traffic to the second route pool pool_secondRoute } default { forward the traffic to the default route forward } }
- Hannes_RappNimbostratus
Starting with the last question, yes F5 can do policy-based routing. Basic rulesets can be defined with
feature. For complex scenarios, you haveLocal Traffic Policy
which are not that complex to write. Both are available in LTM.iRules
In regards to deployment scenario, you can definitely achieve this. Since you mentioned ASM, just take note that you will have to decrypt SSL/TLS at the firewall or BigIP, otherwise ASM cannot inspect L7 contents.
@ Diagram I'm not sure if everyone will be able to read it the same. Does the Web Server depend on that Database Server service? Or is the Database a standalone service, not related to Web Server underneath Core 1 switch? This one is also unrelated to your questions, but why aren't Core 1 and Core 2 configured as stack of 2 units?.. Or are they?
- ESS-Gamal_35193Nimbostratus
Thank you for your answer yes web server depend on that database server service , also core 1 and core 2 configured as 2 unit not stack , so do you recommend to configured them as stack , and is this change our design ?
- Hannes_RappNimbostratus
Hello, ESS
Yes, I'd definitely configure them as stacked network switches.For your DB physical connectivity, take 1 port from each switch, configure an aggregate LACP link. Do the same for WebApp server(s). If network switches are standalone as on the diagram, you will have less fault tolerance. Upon NS Core1 or Core2 failure, you will lose either DB or WebApp and that's not what you want.
- Hannes_Rapp_162Nacreous
Starting with the last question, yes F5 can do policy-based routing. Basic rulesets can be defined with
feature. For complex scenarios, you haveLocal Traffic Policy
which are not that complex to write. Both are available in LTM.iRules
In regards to deployment scenario, you can definitely achieve this. Since you mentioned ASM, just take note that you will have to decrypt SSL/TLS at the firewall or BigIP, otherwise ASM cannot inspect L7 contents.
@ Diagram I'm not sure if everyone will be able to read it the same. Does the Web Server depend on that Database Server service? Or is the Database a standalone service, not related to Web Server underneath Core 1 switch? This one is also unrelated to your questions, but why aren't Core 1 and Core 2 configured as stack of 2 units?.. Or are they?
- ESS-Gamal_35193Nimbostratus
Thank you for your answer yes web server depend on that database server service , also core 1 and core 2 configured as 2 unit not stack , so do you recommend to configured them as stack , and is this change our design ?
- Hannes_Rapp_162Nacreous
Hello, ESS
Yes, I'd definitely configure them as stacked network switches.For your DB physical connectivity, take 1 port from each switch, configure an aggregate LACP link. Do the same for WebApp server(s). If network switches are standalone as on the diagram, you will have less fault tolerance. Upon NS Core1 or Core2 failure, you will lose either DB or WebApp and that's not what you want.