RE: [load balancing] F5 BigIP HA Questions

From: Catalin Matei (catalin_matei_seIZZAThotmail.com)
Date: Thu Jan 08 2004 - 03:30:33 EST

  • Next message: Octavian Popescu: "[load balancing] imap balancing"

    Hi,
    there is possible to assign public IPs on the nodes themselves; check the
    Bigip Sollution Guide chapter 18 "One IP network Topologies". You can
    actually have the nodes even outside the BigIP box ;-)
    I've designed solutions like this and ...it works just fine!
    Cheers,
    Catalin

    >From: "Chris Kirby" <ckirbyIZZATsolaristech.com>
    >Reply-To: lb-lIZZATvegan.net
    >To: <lb-lIZZATvegan.net>
    >Subject: RE: [load balancing] F5 BigIP HA Questions
    >Date: Tue, 6 Jan 2004 08:53:29 -0500
    >
    >A little off topic... I was not even aware that BigIP's could do load
    >balancing without NAT enabled.
    >
    >Is it actually possible to assign public IP's directly on the node members?
    >Just curious. If so, how is it done?
    >
    >Thanks,
    >
    >Chris.
    >
    >
    >
    >-----Original Message-----
    >From: owner-lb-lIZZATvegan.net [mailto:owner-lb-lIZZATvegan.net] On Behalf Of
    >Haine,
    >Mark : Enable
    >Sent: Tuesday, January 06, 2004 6:58 AM
    >To: 'lb-lIZZATvegan.net'
    >Subject: RE: [load balancing] F5 BigIP HA Questions
    >
    >Guys,
    >
    >My experience of the SSL persistence question is that it only matters if
    >your application cares about state. We use SSL-ID based persistence and I
    >think (although I've never read a sniffer decode of it) Internet explorer
    >re-negotiates the SSL session ID and it may be moved to a new node/Web
    >server by the load balancer. This doesn't affect application persistence
    >in
    >our case as it is handled by the app somewhere deeper in our system. I
    >imagine this scenario would also work if the application was stateless
    >except for the SSL session.
    >
    >To NAT or not to NAT? It's up to you and has pros and cons, and also rather
    >depends on your existing network design. If you really don't want to set
    >your BigIP as your default gateway (default config, where the BigIP only
    >changes the destination address as the packets pass through) you can set it
    >up, as Stephen says, to rewrite both the Destination and Source addresses.
    >We have done that using the SNAT automap feature and that seems to work
    >fine. The drawbacks are firstly it's a bit mind-bending when you're used to
    >the default BigIP way of doing things and it also increases the load on the
    >BigIP CPU (we have performance tested BigIPs and many other things gave up
    >before the BigIP so CPU is probably not a big issue.
    >
    >Hopefully this helps too..
    >
    >
    >
    >-----Original Message-----
    >From: Winter, R. Stephen [mailto:SWinterIZZATbecu.org]
    >Sent: 06 January 2004 02:31
    >To: lb-l
    >Subject: RE: [load balancing] F5 BigIP HA Questions
    >
    >
    >Mike, A quick caution before you but a second-hand pair. There is a
    >license file on the BigIP's that is required for the software to work. If
    >that's not there, you will need to "register" with F5 (we paid about 5k for
    >an HA pair I think, but we wanted maintenance and everything) If you lose
    >the hard-drive, you will need that license file, so make sure you copy it
    >somewhere safe. Also, if you ever change the NIC, you'll have problems.
    >The license is tied to the MAC address...
    >
    >Ok.. Without the SSL card you will not be able to terminate the SSL on the
    >Big IP. But, you can still load balance by passing the packets directly to
    >an SSL Server. I don't remember if the F5 can read the SSL ID, but I know
    >we did have some issues with the renegotiating of the SSL ID's, so you will
    >need to setup a different type of persistence (mabye by source address will
    >work for your situation)
    >
    >The source address of the original packet can be retained (default unless
    >you add the Natting). In a "normal" config, you usually only re-write the
    >destination address to the pool member. You can NAT the source address if
    >you want to. (and sometimes you need to). If you don't NAT, you will need
    >the BigIP to be the default gateway. You can setup the BigIP to NAT on the
    >way or (or not) for the pool member initiating traffic out pas the BigIP if
    >you do have it as the default gateway... (If you don't NAT, you can set it
    >to forward as well...)
    >
    >I hope I wrote this as clearly as I saw it in my head...
    >
    >-----Original Message-----
    >From: Michael Ferraro [mailto:mikeIZZATmyvest.com]
    >Sent: Monday, January 05, 2004 3:55 PM
    >To: lb-lIZZATvegan.net
    >Subject: [load balancing] F5 BigIP HA Questions
    >
    >
    >Hi,
    >
    >We're about to buy a pair of F5 BigIPs in the secondary market and I had
    >a few questions I was hoping somebody could help us with. Since we're
    >not looking to buy new, we can't really have the F5 sales engineers
    >helping us out too much...
    >
    >If the BigIP doesn't have an SSL accelerator, what functionality do we
    >lose aside from rapid decryption/re-encryption of traffic? Can a BigIP
    >still function as an SSL endpoint without the card? My impression is
    >no.
    >
    >If the BigIP can't be an SSL endpoint w/out an SSL Accelerator card, how
    >would it function to load-balance HTTPS traffic? My assumption is that
    >it can read the SSL session ID w/out decrypting the packets, use round
    >robin (or another method) to distribute the connections among pool
    >members, and use that SSL session ID to route future requests for that
    >session to the same pool member. If that's true, what about IE 5.5+'s
    >habit of changing (renegotiating) SSL IDs periodicially? Can BigIP
    >v4.2.6 account for that?
    >
    >When NAT'ing traffic to pool members, is the source IP address unchanged
    >by the BigIP? If not, I'm assuming that I have to have the BigIP's IP
    >be the default router for my pool members. Yuck. If the BigIP is the
    >default router, what about non-HTTPS traffic (e.g., SSH) originating
    >from the pool members -- will it simply forward that traffic, too?
    >
    >Thanks in advance!
    >
    >Regards,
    >Mike
    >
    >____________________
    >The Load Balancing Mailing List
    >Unsubscribe: mailto:majordomoIZZATvegan.net?body=unsubscribe%20lb-l
    >Archive: http://vegan.net/lb/archive
    >LBDigest: http://lbdigest.com
    >MRTG with SLB: http://vegan.net/MRTG
    >Hosted by: http://www.tokkisystems.com
    >
    >
    >
    >
    >NOTICE: This communication and any attachments may contain privileged or
    >otherwise confidential information. If you are not the intended recipient
    >or believe that you may have received this communication in error, please
    >reply to the sender indicating that fact and delete the copy you received
    >without printing, copying, retransmitting, disseminating, or otherwise
    >using
    >the information. Thank you.
    >
    >____________________
    >The Load Balancing Mailing List
    >Unsubscribe: mailto:majordomoIZZATvegan.net?body=unsubscribe%20lb-l
    >Archive: http://vegan.net/lb/archive
    >LBDigest: http://lbdigest.com
    >MRTG with SLB: http://vegan.net/MRTG
    >Hosted by: http://www.tokkisystems.com
    >
    >Internet communications are not secure and therefore the Barclays Group
    >does not accept legal responsibility for the contents of this message.
    >Although the Barclays Group operates anti-virus programmes, it does not
    >accept responsibility for any damage whatsoever that is caused by
    >viruses being passed. Any views or opinions presented are solely those
    >of the author and do not necessarily represent those of the Barclays
    >Group. Replies to this email may be monitored by the Barclays Group
    >for operational or business reasons.
    >
    >____________________
    >The Load Balancing Mailing List
    >Unsubscribe: mailto:majordomoIZZATvegan.net?body=unsubscribe%20lb-l
    >Archive: http://vegan.net/lb/archive
    >LBDigest: http://lbdigest.com
    >MRTG with SLB: http://vegan.net/MRTG
    >Hosted by: http://www.tokkisystems.com
    >
    >
    >
    >____________________
    >The Load Balancing Mailing List
    >Unsubscribe: mailto:majordomoIZZATvegan.net?body=unsubscribe%20lb-l
    >Archive: http://vegan.net/lb/archive
    >LBDigest: http://lbdigest.com
    >MRTG with SLB: http://vegan.net/MRTG
    >Hosted by: http://www.tokkisystems.com
    >

    _________________________________________________________________
    The new MSN 8: smart spam protection and 2 months FREE*
    http://join.msn.com/?page=features/junkmail

    ____________________
    The Load Balancing Mailing List
    Unsubscribe: mailto:majordomoIZZATvegan.net?body=unsubscribe%20lb-l
    Archive: http://vegan.net/lb/archive
    LBDigest: http://lbdigest.com
    MRTG with SLB: http://vegan.net/MRTG
    Hosted by: http://www.tokkisystems.com

    ____________________
    The Load Balancing Mailing List
    Unsubscribe: mailto:majordomoIZZATvegan.net?body=unsubscribe%20lb-l
    Archive: http://vegan.net/lb/archive
    LBDigest: http://lbdigest.com
    MRTG with SLB: http://vegan.net/MRTG
    Hosted by: http://www.tokkisystems.com



    This archive was generated by hypermail 2.1.4 : Thu Jan 08 2004 - 14:15:40 EST