Forum Discussion
Cirrus2 traffic-groups, routed VIP subnet and Best Practises with Active-Active mode
Hi, we want to use 2 or more traffic-groups and assign each VIP or server subnet to separated traffic-group. We now have all configuration in one traffic-group and I am not sure what objects to add to each traffic-group to keep whole box functional. Aditinally we use interconnect vlan FW-LB and VIP subnet is routed on FW by static route pointing to interconnect IP on LB -> when I want to add VIP pool to traffic-group 2, do I have to add there also floating IP from interconnect vlan (FW-LB)?
Also how about default route then? If I am correct with having floating IP assigned to traffic group together with routed VIP pool, then I guess I need multiple floating IPs in box when having more than one VIP pool, or I need to have multiple interconnect vlans and therefore have to thing about routing there.
For me it looks like the best approach in Active-Active mode is to keep traffic groups separated in different partitions/routing domain, what do you think? Also, this will guarantee that VIPs will be assigned automatically to right traffic-group (?).
Thanks for advices or tips, Zdenek
6 Replies
NikhilBEmployee
You can certainly keep multiple traffic groups in a active/active setup. It depends on how much 'load' you want to balance across both LTM's. You can selectively move or create VS's & floating IP's to whichever traffic group of your choice.
Unless you want to segment traffic and use existing IP's then a routing domain is for you.
ZdendaYep, since we need to keep current "one traffic-group" design, we have to use routing domain separation and therefore also partitioning (we never have multiple routing domain in one partition).
I was thinking that we can have design using one routing domain with multiple traffic-groups, but looks like in this case our vlans connected to LB (interconnect, server vlan) should have more floating IPs - each dedicated for own traffic group.
For example I am not sure if LB supports scenario when standard VIP is active on A unit, but floating IP of server vlan is active on B unit (together with forwarding VIP for server vlan). Will A unit still be able to send and receive users traffic to/from server vlan? I would say yes, but have no experience in this yet
- NikhilBWhy do you need separate partitions in this case? (why not work off the Common - root folder)
- ZdendaMainly because traffic-group is not an option specified during creating new virtual server and I am pretty sure that this would be making mixed up config in future and therefore not all VIPs would be in proper traffic-group.
StephanMantheyNacreous
Hi Zdenda,
it will require two traffic-groups (traffic-group-1 [default] and an additional traffic-group-2).
The traffic group contains all virtual adresses belonging to a service.
Virtual addresses include virtual IPs for virtual servers, SNAT translation addresses (created via SNAT List or SNATpool configuration objects), NAT addresses and last but not least floating self IPs.
Especially in case you want to use the floating self IPs for SNAT AutoMap or as next hop to provide a route in your locally attached networks they become mandatory for the traffic-group.
A virtual server using SNAT Automap has to have a floating self IP on the egress VLAN in it´s traffic-group.
So yes, multiple floating self IPs are required and you need to make sure to assign them to the different traffic-groups.
Routing through the BIG-IP is still an issue, as the virtual IP of 0.0.0.0/0.0.0.0 (used as wildcard network virtual "address" can be active on a single machine only.
That´s why you probably have to use SNAT generally for one of your traffic-groups. Otherwise you will observe asymmetric traffic. But this will break the proxy functions and is not enabled by default on your systems (look after VLAN keyed connections feature, please).
Thanks, Stephan- Zdenda
Thank you Stephan, what you wrote is exactly what was my understanding. So my worries about all failover objects which needs to be assigned to traffic-group were reasonable, thank you for confirming my theory. Now I need to think about best approach for our case and that will most probably be using separated routing domain for each traffic group.
Thanks, Zdenek
