Forum Discussion
4 SNAT pools or a gigantic one?
Hello,
I am configuring Lync 2013 on LTM Viprion and we use 4 different FrontEnd VIPs (with all ports 443, 448, 5061, 5071, 8080, etc).
This is requested by Microsoft design to provide redundancy on FE services.
We expect a rough number of 150k or up to 200k (in some years time) requests distributed in total to all 4 VIPs.
Therefore we planned 20 SNAT IPs, but the dilemma is to use 1 big SNAT pool for all 4 IPs or 4 configure diffrent SNAT pools of 5 IPs for each VIP...
My idea is that having the same gigantic pool of 20 SNAT IPs for all 4 VIPs is more a flexible approach in case a VIP get more requests... What do you think? Will both work?
Does it matter if the same SNAT pool is used by 2 diffrent VIPs?
Thanks.
G
13 Replies
- What_Lies_Bene1
Cirrostratus
I would use four pools because;
1) 5 IPs should easily cover 200k connections (or even sessions)
2) You can then identify on the real servers or the BIG-IP which VIP a connection came through, making troubleshooting a little bit easier
A single pool obviously offers the most flexibility (say you wanted to preserve client source ports) and scale (1m+ connections) but I'd still prefer the four and you can always move addresses between them should the need ever arise. - Thanks for the reply.
Sorry, I meant to say 150k users with each of them opening up to 8-10 TCP requestes, so we are coming to grossomodo 1 milion entries for the SNAT , so 20 IPs are needed.
Another possibility would be to configure the lync servers in-line, but wouldn't it more intense from the resource point of view to configure it as inline those connections? any pro's con's apart from seeing the client source ip address, from the performance / redundancy point of view? - What_Lies_Bene1
Cirrostratus
Ah OK, understood. You could use OneConnect to reduce the server-side connections considerably.
Personally I'd be worried that I'd exhaust ports without some more addresses or I'd be looking at reducing Idle Timeouts.
Not sure what you mean by in-line? yes we are using oneconnect witn 255.255.255.255 subnet mask as suggested in the iapp.
idle timeout is 7200 in the iapp, but not sure i can reduce it for lync2013? what do you think?
by in-ljne i mean no SNAT pool and put all servers in a VLAN behind the LTM.... would be the best solution?
how are the performace be impacted by having all flows traverse rhe box from client VLAN to backend seever VLAN?
if we have 1 milkon connections passing through is the same as having SNAT, performance wisd?
we use Viprion 2400 with 2 blades
Thanks
yes we are using oneconnect witn 255.255.255.255 subnet mask as suggested in the iapp.
idle timeout is 7200 in the iapp, but not sure i can reduce it for lync2013? what do you think?
by in-ljne i mean no SNAT pool and put all servers in a VLAN behind the LTM.... would be the best solution?
how are the performace be impacted by having all flows traverse rhe box from client VLAN to backend seever VLAN?
if we have 1 milion connections passing through is the same as having SNAT, performance wise?
we use Viprion 2400 with 2 blades
Thanks
- What_Lies_Bene1
Cirrostratus
I'm afraid I've not the experience to offer a sensible opinion regarding the timeout.
I don't think there would be any performance difference difference between 'in-line' as you describe it and using an SNAT (and presumably having the real servers on a network not directly attached to the F5).
There are other options but it's hard to know what to recommend without understanding your infrastructure and the traffic profile. Regardless, do you need SNAT at all? If this is internet sourced traffic can't you just route as appropriate when required and put your servers wherever you want? - Traffic is coming from Intranet only... but the point is that if I put the servers in a backend VLAN, we will have a lot of connections (mainly UDP packets for voice) that are just passing through the LTMs...
So I think that it is better to go for your first idea to use 4 SNAT pools... - What_Lies_Bene1
Cirrostratus
Ah, OK, I think I misunderstood. You do actually mean fully in-line. That is my preferred design in most cases. The overhead of routing other packets (not to be load balanced by LTM) is normally pretty low and it also provides a great troubleshooting and packet capture tool in a significant place in the network which can help even with issues/flows that LTM doesn't handle as well as those it does. Of course, on the flip side, all traffic now relies on the F5, not just what you are specifically load balancing. So, as ever, what you do will depend on your needs and requirements and the constraints placed upon you.
An alternative which you might find attractive would be to have the these specific servers in an isolated VLAN directly connected to the F5 where the F5 is the L3 gateway for the network. The servers have a default gateway pointing at the F5 or, in your case, a route to the Intranet subnets. They can have multiple NICs in multiple networks for mgmt, backup whatever, just route as necessary. - Thank you for the email.
What I am not 100% confident in your answer is the "normally pretty low" for the traffic that does not need to be load balanced.
I have bad experiences in the past (not with F5 LTMs though but with Juniper WX Peribit) to allow all traffic passing transparently.
Its better for troubleshooting but a bit safer for all the other traffic.
The servers are in a backend VLAN with default GW pointing to the F5 and 1 interface each to the MGMT plane. - What_Lies_Bene1
Cirrostratus
I've used an in-line design with multiple HA pairs both internally and in internet facing environments on 1500 and 1600's without any issues even with large scale file transfers passing through. Not with connection counts like yours though and obviously it's something you'd want to test in some way; I can understand your caution.
Seems to me the current setup you have is ideal and there's no need to use an in-line design or SNAT. If the only way for traffic to get to and from the servers is via the F5 it's not required. Did I miss something?
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com