Hi All, I have to install LC, Need your suggestions and help on configuration. I don't want to do any changes(no NAT changes) on existing customer firewall. 1) My LC deployment architecture LAN ---> Bluecoat proxy ---> Firewall (Ext Int public IP from one ISP) ----->(Int int private IP) LC (ext int public IP) ----> two ISPs Do you see any mistake in deployment architecture 2) Bit confused with defining Link object configuration : - Router Address List - Uplink From your experience from any installation what ip address I have use in link object 3) How to achieve session persistence for outbound traffic using irule apart from destination affinity. This I need, since customer access few public website with first page on server 1 but after clicking login users are redirected to server 2. so both server 1 and server 2 request should go through one ISP. 4) Anybody tried bandwidth management for outbound traffic eg : http 50%, smtp 10%, etc

Your architecture looks sound. Is this for outbound traffic only, or will you be hosting inbound traffic as well? The link definition should use the next hop address for the router on the link, and should use the bigip_link monitor. Your destination address affinity profile can be changed to a larger subnet mask, such as a class C to eliminate the switching at the single host. I have not tried bandwidth management as of yet, admittedly. Thanks!

Thanks Chris. It is for outbound traffic. Customer has not yet asked for inbound. Do you feel any challenge if we inbound also? Regards, Sachin

Link Controller - Create Link(ISP) object

20 Replies

Chris_Wentland
Nimbostratus
Sep 04, 2014
Your architecture looks sound. Is this for outbound traffic only, or will you be hosting inbound traffic as well?

The link definition should use the next hop address for the router on the link, and should use the bigip_link monitor.

Your destination address affinity profile can be changed to a larger subnet mask, such as a class C to eliminate the switching at the single host.

I have not tried bandwidth management as of yet, admittedly.

Thanks!
- sachin_80710
  Nimbostratus
  Sep 05, 2014
  Thanks Chris. It is for outbound traffic. Customer has not yet asked for inbound. Do you feel any challenge if we inbound also? Regards, Sachin
- sachin_80710
  Nimbostratus
  Sep 05, 2014
  Hi Chris, Pls can u explain point 2 in my first post with example.
Chris_Wentland_
Nimbostratus
Sep 04, 2014
Your architecture looks sound. Is this for outbound traffic only, or will you be hosting inbound traffic as well?

The link definition should use the next hop address for the router on the link, and should use the bigip_link monitor.

Your destination address affinity profile can be changed to a larger subnet mask, such as a class C to eliminate the switching at the single host.

I have not tried bandwidth management as of yet, admittedly.

Thanks!
- sachin_80710
  Nimbostratus
  Sep 05, 2014
  Thanks Chris. It is for outbound traffic. Customer has not yet asked for inbound. Do you feel any challenge if we inbound also? Regards, Sachin
- sachin_80710
  Nimbostratus
  Sep 05, 2014
  Hi Chris, Pls can u explain point 2 in my first post with example.
sachin_80710
Nimbostratus
Sep 05, 2014
Thanks Chris. It is for outbound traffic. Customer has not yet asked for inbound. Do you feel any challenge if we inbound also?

Regards, Sachin
StephanManthey
MVP
Sep 05, 2014
The link definition will specify the next hop for outgoing connection from the LC´s perspective.
So it will be the "internal" interface of your ISP router which can be reached locally from your LC.
These interfaces (typically you are using two or even more ISP links) will be grouped as well in a "default_gateway_pool" which should be assigned as default route to your LC in the network settings.
(At least in the past this was a mandatory step to get the LC automatically configured as a server in the GTM configuration [LC is a hybrid of LTM & GTM].)
When forwarding requests (initiated by internal) clients to servers in the public internet somehow you need to make sure the responses will be routed back properly and symmetrically (return via same ISP link).
This can be achieved by applying SNAT for outgoing traffic. To capture outgoing traffic a wildcard network virtual server 0.0.0.0/0 has to be configured to listen on the LC´s internal interface. It will run in PerformanceL4 mode, with SNAT automap (requires floating self IPs on your interfaces towards the ISP router) use the default_gateway_pool and has the destination address affinty profile as recommended by Chris.
By default, the BIG-IP will SNAT only tcp and udp. To SNAT i.e. ICMP or ESP as well, you need to enable it first, please:
tmsh modify ltm global-settings general snat-packet-forward enabled tmsh save sys config
StephanManthey
MVP
Sep 05, 2014
In case of a standalone system SNAT automap should do it automatically. Indeed there were changes in behaviour (means a SNAT address [if configured] needs to belong to the same traffic-group as the virtual server). With SNAT automap a self IP will be picked and in case there is an available floating self IP on the egress interface the rule above applies.

To be on the very safe side you could put your both "external" self IPs into a SNATpool and associate it with your virtual server.

An iRule could be used to apply service specific selective SNAT. I.e. you provide 2 virtual servers for inbound mail and want to make sure outgoing mail will be source NATed with exactly these addresses (makes sense as the external receiving MTA may do a reverse lookup to validate the authenticity). For this enhancement you can still go ahead without an iRule. Just create a new network wildcard virtual server on the internal interface but set the service port i.e. to tcp/25 and use a SNATpool containing the IP addresses corresponding to your MX records and the default gateway pool.
Chris_Wentland
Nimbostratus
Sep 10, 2014
For point 2, In your VS configuration for outbound traffic, make sure to unselect address translation AND port translation from the Virtual settings. This will ensure that when pool member selection occurs, the destination address is not changed to the next hop router IP address. SNAT automap should suffice, although I would recommend using a different address from each link to source from. If you ever need to differentiate that traffic for access controls, having it on a separate IP would be helpful.Also, make sure you limit the default virtual server to only listen on your internal VLANs. There's nothing worse than taking a default deny device, and turning it into a router!

For inbound traffic, the control mechanism is DNS. I would HIGHLY recommend planning this strategy out as follows. You need to delegate a DNS domain to your Link Controller, something like "*.hosting.mycompany.com". The floating IP for each of your links on the LC should be used as the delegated address. UDP port 53 should be opened to the LC floating IP inbound on your ISPs.

Consistent naming is key to being able to track these relationships. Now you want to add your first domain, "www.mycompany.com" Add an DNS entry for www.mycompany.com as a cname pointing to www.hosting.mycompany.com Add virtual servers for www.hosting.mycompany.com for each link. Add a WideIP for www.hosting.mycompany.com which uses the virtual servers which were just created.

This can get interesting if you have more than one hosting facility. You would have to account for them separately such as ".denverhosting.mycompany.com" and ".virginaihosting.mycompany.com". If you have multiple hosting centers, name the appropriately, and they can be referenced with GTM to give you geographical diversity or HA.
- sachin_80710
  Nimbostratus
  Sep 11, 2014
  Thank you Chris
Chris_Wentland_
Nimbostratus
Sep 10, 2014
For point 2, In your VS configuration for outbound traffic, make sure to unselect address translation AND port translation from the Virtual settings. This will ensure that when pool member selection occurs, the destination address is not changed to the next hop router IP address. SNAT automap should suffice, although I would recommend using a different address from each link to source from. If you ever need to differentiate that traffic for access controls, having it on a separate IP would be helpful.Also, make sure you limit the default virtual server to only listen on your internal VLANs. There's nothing worse than taking a default deny device, and turning it into a router!

For inbound traffic, the control mechanism is DNS. I would HIGHLY recommend planning this strategy out as follows. You need to delegate a DNS domain to your Link Controller, something like "*.hosting.mycompany.com". The floating IP for each of your links on the LC should be used as the delegated address. UDP port 53 should be opened to the LC floating IP inbound on your ISPs.

Consistent naming is key to being able to track these relationships. Now you want to add your first domain, "www.mycompany.com" Add an DNS entry for www.mycompany.com as a cname pointing to www.hosting.mycompany.com Add virtual servers for www.hosting.mycompany.com for each link. Add a WideIP for www.hosting.mycompany.com which uses the virtual servers which were just created.

This can get interesting if you have more than one hosting facility. You would have to account for them separately such as ".denverhosting.mycompany.com" and ".virginaihosting.mycompany.com". If you have multiple hosting centers, name the appropriately, and they can be referenced with GTM to give you geographical diversity or HA.
- sachin_80710
  Nimbostratus
  Sep 11, 2014
  Thank you Chris
sachin_80710
Nimbostratus
Sep 11, 2014
Hi All,

Offline I have configured LTM to do link load balancing, since we didn't got LC license. Following are the configuration done: 1. 3 VLAN , internal VLAN and two ISP VLAN 2. ISP GW router as node 3. Pool from node configured earlier 4. Wildcard virtual server(performance layer4), with pool configured earlier. 5. Under network, default route we used again same pool configured earlier

Bit confused, I m using pool in virtual server and default GW. Do you think the load balancing decision will happen twice. First time when outbound request hit virtual, pool member(ISP router) is selected ; and when packet is about to leave f5 default route( ISP router pool) will again take load balancing decision on which link it has to send packet?

Pls suggest
StephanManthey
MVP
Sep 11, 2014
Hi Sachin,

there are actually two options to handle outbound traffic (which is the LTM component in LC anyway):

1. Wildcard network virtual server in mode ForwardingIP (requires to have a default route using a default_gateway_pool with the locally attached outbound router interfaces as poolmembers).

2. Wildcard network virtual server in mode Standard or PerformanceL4 in combination with the default_gateway_pool.

In both cases it´s required to use SNAT automap (works in default configuration for TCP and UDP only) or equivalent on the load balancer or to apply hiding NAT on the ISP routers.

To make outbound load balancing work, the ISP router interfaces need to be locally attached to the BIG-IP (connected on L2 with no additional L3 hops) and to have turned off (destination) NAT in the virtual server settings as mentioned before in this thread.

Thanks, Stephan
sachin_80710
Nimbostratus
Sep 12, 2014
Stephan, ISP routers are directly connected to f5. Destination NAT is disabled. Instead of SNAT automap we are doing SNAT using irule, like LB::server addr is ISP1/2 then use SNAT pool from that router subet. My only concern is. After load balancing request using pool(default_gw_pool) assigned to virtual server , same request will again get load balanced by default_gw_pool that is again used as default route pool in network-->route. If, default route pool select different ISP router instead of one that was selected by virtual server pool this will create problem for me.
- sachin_80710
  Nimbostratus
  Sep 12, 2014
  Also we are using destination affinity persistence. Thanks you Stephan and devcentral members for your suggestion and help.
- StephanManthey
  MVP
  Sep 12, 2014
  Hi Sachin, I´m sure the load balancing decission will overrule the default gateway configuration in your setup. This way it´s possible as well, to select a completely different path for specific traffic. Destination based persistence makes sense, if you want to make sure the target will always be reached by same link (and same source IP). Some servers tend to reject connections if a client IP is changing as they assume the session is going to be captured by an attacker. Destination address affinity is table based and limited in size by default. You can try to modify the hash method to CARP to avoid using table based persistency. (I have used this feature for source address affinity by now.) Thanks, Stephan