Re: [load balancing] VRRP and Big-IP

From: Nicolas Maury <nicolas.maury [izzat]>
Date: Fri Apr 28 2006 - 05:30:21 EDT

Actually in this case, you're right we have only one uplink and one

I indicated that because we have other platforms with two uplinks and
two downlinks.

FWIW we made more tests with option 1 (lasthop pool containing real
firewall addresses + action on service down --> reselect)
Firewalls (Fwn1 and Fwn2) work in active - stand by mode.

In our case, option 1 is not optimal : it works when we have Fwn1 goes
down, big-ip sends traffic to Fwn2.
But when Fwn1 goes up again, some traffic keep going through Fwn2,
because big-ip keep using the MAC address of Fwn2 for some sessions.

To resolve this problem we have to manually shutdown Fwn2 which is not
really an optimal solution.


Computer Guy wrote:

> Hamish: VMAC mode VRRP IIRC? What version of IPSO are you running? I
> only see VMAC modes VRRP, Static, Extended and Interface. We've tested
> each of these modes and they all produce the same result. From what I
> understand the only way to resolve the MAC address usage issue in
> checkpoint is to use clustering.
> Nicolas: "We didn't enable IP forwarding because when we have 2
> different vlansfor servers, we want traffic between these vlans to go
> through firewalls"
> I was assuming you had one uplink from the big-ip to the firewall
> (through a VLAN) and one downlink to the server VLAN. Assuming you are
> running this big-ip pair in the typical layer 3 mode (i.e. Netblock A
> to the firewall, Netblock B to server VLAN X and Netblock C to server
> VLAN Y) with your server default routes pointing to the big-ip self-ip,
> I don't see how your inter-server-VLAN communication will go through the
> firewall.
> */Hamish Marson <>/* wrote:
> Hash: SHA1
> Nicolas Maury wrote:
> > Hi,
> >
> > We didn't enable IP forwarding because when we have 2 different
> > vlans for servers, we want traffic between these vlans to go
> > through firewalls. Thanks for the tip about fastL4, I'm gonna have
> > a look at it.
> >
> > After reading all answers, I think I may have 2 choices :
> >
> > 1 - Use a lasthop pool containing real firewalls IP addresses and
> > not the VRRP IP address.
> That's only going to work correctly if you're using a firewall
> sandwhich and syncing the traffic between them. Autolasthop is going
> to be easier. Because the lasthop MAC will be filled in using the MAC
> address of the packet that created the connection table entry. If it's
> not, then it's a bug. Although I have yet to see it be a proper bug yet.
> Using explicit lasthop pools is IMO a hack. And if your replies beat
> the checkpoint table syncing between firewalls you will drop traffic
> when the connection table entry chooses the wrong firewall to send the
> traffic back.
> Of course you can solve this by using VMAC mode in the VRRP config
> (Set it to VRRP IIRC). You are using Nokia's aren't you (Sorry, small
> assumption there).
> > Cons : apparently, several comments indicate that lasthop pool is
> > not a good option.
> >
> > 2 - Globally disable auto lasthop Add a default route with the
> > configuration utility Add routes to networks that are behind the
> > management interface using the "bigpipe mgmt route" command.
> >
> > Cons : - Is it a good practice to mix virtual forwarding server and
> > routes ? Documentation always presents forwarding virtual server
> > but information about routes is a little scarce.
> I have done. But routes shouldn't be needed across the public
> interfaces...
> > - SSH connection to management interface takes much more time to be
> > established (!)
> >
> That sounds like a name resolution problem. Usually because
> connections initiated by the F5 device (e.g. DNS lookups) follow the
> normal routing table entries, and not the management port default
> entry. IIUC the management port default entry is only used by
> connections initiated TO the F5 device's management port (e.g. the
> actual ssh connection). Not sure why... I find it a bit
> annoying/confusing too...
> > In the research of the "best" option, has anybody hints or comments
> > that could influence my choice ? :)
> >
> [deleted]
> Version: GnuPG v1.4.2 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird -
> iD8DBQFEULjU/3QXwQQkZYwRAgswAKCbu47vgAWAyN1gbdj0nEjl4arwVQCgqCzS
> =X0jo
> ____________________
> The Load Balancing Mailing List
> Unsubscribe:
> Archive:
> LBDigest:
> MRTG with SLB:
> Hosted by:
> ------------------------------------------------------------------------
> Yahoo! Mail goes everywhere you do. Get it on your phone
> <*>.

Nicolas Maury | Applications Hosting | BT France | Tel: +33 (0)1 44 97
70 00 | E: nicolas.maury [izzat] |
Ce message électronique contient des informations confidentielles. Ces
informations sont à l'usage des destinataires indiqués, personnes
physiques ou morales. Si vous n'en êtes pas le destinataire, nous vous
informons que toute divulgation, copie, diffusion ou toute autre
utilisation de ces informations, est interdite. Si vous avez reçu ce
message électronique par erreur, nous vous remercions d'en avertir BT
France immédiatement par téléphone au numéro indiqué ci-dessous ou de le
signaler par retour à son expéditeur.
This electronic message contains information which may be privileged or
confidential. The information is intended to be for the use of the
individual(s) or entity named above. If you are not the intended
recipient be aware that any disclosure, copying, distribution or use of
the contents of this information is prohibited. If you have received
this electronic message in error, please notify us by telephone or email
(to the numbers or address below) immediately.
BT France | Siège social : Immeuble Jean Monnet - 11 place des Vosges -
92061 Paris La Défense Cedex - France | tel. +33 (0)1 46 67 28 00
The Load Balancing Mailing List
MRTG with SLB:
Hosted by:
Received on Fri Apr 28 05:29:53 2006

This archive was generated by hypermail 2.1.8 : Fri Apr 28 2006 - 05:53:01 EDT