Kernel panics with 7.2 and ANS

Jeremy Stoltz jstoltz at oz.net
Wed Nov 7 11:16:01 CST 2001


Glen,

Thanks for taking the time to explain how etherchannel works for me and some
of the disadvantages of using it on the hosts.

I'm just beginning to research and test different options for providing
redundancy between two interfaces. I'm not using etherchannel to increase
the bandwidth. Most of the server's will be using less then 10 Mbps. The
backend server's which need more bandwidth are using Gigabit NIC's.

Our network is currently designed with redundant router's and firewalls
going into a 6509 switch. Each machine has two interfaces connected to a
different blade on the switch. Initially Intel's iANS drivers seemed like a
good solution. But after a few weeks of stability issues I'm going to try
some other options.

I'm going to try bonding next. Does anyone have any other solutions which
would work in this situation.

Jeremy


----- Original Message -----
From: "Glen Turner" <glen.turner at aarnet.edu.au>
To: "Ard van Breemen" <ard at telegraafnet.nl>
Cc: "Jeremy Stoltz" <jstoltz at oz.net>; <Linux-PowerEdge at dell.com>
Sent: Tuesday, November 06, 2001 4:45 PM
Subject: Re: Kernel panics with 7.2 and ANS


> Ard van Breemen wrote:
> >
> > Are there any other options then iANS to use etherchannel or at
> > least load balancing between two nics?
>
> > Yes, it is called bonding.
>
> I'm a network engineer and using EtherChannel for NIC
> load sharing to hosts sends a chill up my spine every time.
>
> Cisco's EtherChannel uses a hash of the two MAC addresses
> to determine which port to transmit the packet.  Let's
> do that calculation for a router and a large host:
>
>    hash(mac_a, mac_b, channels) = (lowbits(mac_a) XOR lowbits(mac_b)) AND
channels
>    lowbits(mac) = (mac AND 3)  # Lowest two bits of MAC address
>
> implying
>
>    hash(router_mac, host_mac, 2) = *the same answer every time*
>
> so no load sharing happens on router->host traffic in the topology
>
>    +--------+      +--------+       +------+
>    |        |      |        +-------+      |
>    | Router |------| Switch |       | Host |
>    |        |      |        +-------+      |
>    +--------+      +--------+       +------+
>
> Cisco do this because EtherChannel is designed for switch-to-
> switch interconnection.  It is important not to reorder frames, as
> this can kill TCP performance.  So all frames between pairs of
> hosts are sent down the same link.  These links can have differing
> latencies, as is usually the case between a main and backup path.
> The variety of MAC addresses leads to load sharing.
>
> The Linux bonding driver sends the packets in a strict round-robin.
> So it load shares in the topology above (in the host->router direction).
> If the topology or the switch software favours one link over another
> then frame reordering can occur.  It is important to test that
> this is not happening.  I'd suggest using adjacent switch ports that
> do not cross power-of-two boundaries (eg: 1,2 but not 4,5).
> Knowing the internal structure of the switch also helps (eg: if
> it has a module servicing ports 1 to 4 then use ports 1,2 and
> leave idle ports 3,4).
>
> In summary
>                           MAC address hash     Round robin
> Host load sharing               No                 Yes
> Packets in order always         Yes                No
> Differing length links          Yes                No
> Strict 50:50 load               No                 Yes
> Any number of links         Power-of-2             Yes
>
> Really you need the choice of hash or round-robin in
> both the switch and host so that you can select the
> correct algorithm for your topology.
>
> --
>  Glen Turner                                 Network Engineer
>  (08) 8303 3936      Australian Academic and Research Network
>  glen.turner at aarnet.edu.au          http://www.aarnet.edu.au/
> --
>  The revolution will not be televised, it will be digitised
> _______________________________________________
> Linux-PowerEdge mailing list
> Linux-PowerEdge at dell.com
> http://lists.us.dell.com/mailman/listinfo/linux-poweredge
>




More information about the Linux-PowerEdge mailing list