Re: [load balancing] BigIP's and trunking

From: tony bourke (tonyIZZATvegan.net)
Date: Wed Jan 16 2002 - 23:28:24 EST

  • Next message: Steve Birnbaum: "Re: [load balancing] Questions regarding Cisco Secure Content Acc elerator"

    Hi Tim,

    I would recommend highly with going to Gigabit Ethernet over EtherChannel.
    There are not XOR issues, you've got a clear Gigabit link, and it is just
    a much simpler, easier solution, with less to go wrong and less to trouble
    shoot. If you've got one single MAC address on one end, then the XOR
    wouldn't do much for traffic aggregation. Plus, I believe if one link
    dies, the EtherChannel dies (you can't have an odd number of links).

    From my experience at least, Gigabit Ethernet is just much simpler to deal
    with than EhterChannel.

    As far as the 340 Mbps limit, I believe that has more to do with what the
    BIG-IP can handle traffic-wise, not so much the Gigabit Ethernet itself.
    I don't know of any reason why EthernChannel wouldn't suffer any same
    limitations, whether it be capability, PCI bus, or whatever.

    Tony

    On Wed, 16 Jan 2002, Tim Maestas wrote:

    > John,
    >
    > Thank you for the information. I am now much less confused. It seems
    > what I'm looking for is not 802.1q VLAN tagging, so much as
    > 802.1ad/802.3ad link aggregations as in most of my BigIP configurations I
    > only have 1 VLAN per interface.
    >
    > I understand what you're talking about regarding sessions using the same
    > link in the trunk. From what I've read of Cisco's implementation of
    > 802.3ad (Fast/Gigabit Etherchannel) the switch determines what port in the
    > trunk to switch the packet to by performing an XOR of the source and
    > destination MAC addresses.
    >
    > A question: If I'm becoming concerned about bandwidth in and out of my
    > BigIP's, would you think I'd be better off trunking 4 100Meg ports, or
    > replacing my front and/or back interfaces with gig interfaces? Last I
    > saw, I believe the gig cards sold by F5 can do somethingl like 340Megs
    > tops, so from a strictly mathematical standpoint I'd get a bit more out of
    > a 400meg trunk, but I'm wondering if there are any other factors I should
    > be thinking about.
    >
    > Thanks again.
    >
    > -Tim
    >
    >
    > On Wed, 16 Jan 2002, John Hall wrote:
    >
    > >
    > > Trunking is unfortunately an over-used word, causing much confusion
    > > in the world today... :(
    > >
    > > Your reference to 802.1q leads me to believe you are talking about the
    > > trunks that are defined 802.1q Annex D where you have multiple tagged
    > > VLAN's configured on a single interface in order to pass traffic for
    > > multiple VLAN's between two switches. All BIG-IP versions after v3.1
    > > support tagged VLAN's (although I have to admit the support got *MUCH*
    > > better after v4.x) and assigning multiple VLAN's to a single interface
    > > for the purpose of VLAN trunking (that's what *I* call this use).
    > > Although I'm confused by your reference to "bandwidth aggregation".
    > >
    > > Rick has already replied to you referring to our "bigpipe trunk"
    > > command, which is used to configure 802.1ad Link Aggregations, which
    > > are used to make multiple links (physical ports) operate as a single
    > > interface providing the sum of the bandwidths of the aggregated links
    > > to the interface and also providing link failure protection (if one
    > > of several aggregated links goes down, the others continue to operate).
    > > One practical note is that, like most 802.1ad implementations, ours
    > > works most efficiently if the number of interfaces configured is a
    > > multiple of two. Another quirk of 802.1ad that is often not known
    > > is that all packets associated with a single IP connection (say a
    > > single telnet session) are *always* sent on the same link of an
    > > aggregation (this is required by the spec). So, if you setup a
    > > link aggregation, using 4 100BaseTX ports, and try to download a
    > > single huge file via FTP, that single download will only be allowed
    > > approximately 100Mb/s of bandwidth, but if you have a bunch of sessions
    > > going simultaneously, you will see all four links utilized.
    > >
    > > Before you ask, yes, you can configure a single set of links (say four
    > > 100BaseTX ports) to operate as an 802.1ad link aggregation (giving you
    > > close to 400Mb/s of bandwidth on the interface) with multiple tagged
    > > VLAN's going across that interface to another switch. One of our test
    > > configurations uses four gigabit interfaces aggregated to a single
    > > interface over which we pass traffic from four (two internal and two
    > > external) VLAN's and it works like a charm. Link aggregation allows
    > > you to use the full bandwidth capacity of your BIG-IP in a balanced
    > > way when your traffic load is asymmetric (such as with web traffic
    > > where the incoming requests are small, but the responses are large).
    > >
    > > Hope this helps,
    > > JMH
    > >
    > >
    > > Tim Maestas wrote:
    > > >
    > > > I was wondering if anyone has had any experiences (good, bad, or
    > > > otherwise) with using trunking under BigIP 4.x, in particular into a Cisco
    > > > 6500 series switch. In reading the 4.x documentation, there is no mention
    > > > of 802.1q trunk modes like there was in 3.x, so I'm not sure how I would
    > > > be able to make my Cisco treat my trunked interfaces as a group. In 4.x
    > > > it seems like outgoing packets from the BigIP would be
    > > > "load-balanced" between the interfaces, but I don't see how this is
    > > > possible for incoming packets, without something like 802.1q. Granted,
    > > > if nothing else trunks will give me interface failover, but I'm looking
    > > > more for bandwidth aggregation. Any info would be appreciated.
    > > >
    > > > -Tim
    > > >
    > > > ____________________
    > > > 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
    >

    -- 
    -------------- -- ---- ---- --- - - - -  -  -- -  -  -  -   -     -
    Tony Bourke				tonyIZZATvegan.net
    

    ____________________ 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 2b30 : Wed Jan 16 2002 - 23:35:30 EST