From vigornj at gmail.com  Sun Jul  8 15:13:57 2012
From: vigornj at gmail.com (Russ Thompson)
Date: Sun, 8 Jul 2012 15:13:57 -0400
Subject: [OmniOS-discuss] Trouble with drive detection on Installation.
Message-ID: <CALg0+okmATU-5nSwbg5NBz9T02t0CeATg6NTjACdj3J6X7JuEA@mail.gmail.com>

Hello world,

I am in the process of evaluating OmniOS as an in house replacement for
Nexenta.  We have ran into several issues during the installation (albeit
minor).

Our setup consists of:
LSI HBA (cabled to Supermicro PCB/backplane).
12x 2TB drives (for our main pool)
6x   3TB drives (for our backup pool)
4x   250GB SSD Drives (L2Arch)
1x   4GB DDRdrive (ZIL)

The BIOS and LSI HBA detect all of the drives.  However during
installation, OmniOS detects all drives, except 3 of the SSD drives.  It's
only detecting one of those, all other drives are detected.  Downloaded the
LSI utility and am able to see the drives through the CLI once booted into
OmniOS.

What are we missing?

We also have two SSD hard drives connected to the onboard controller, these
drives are for the OS.  When we configure them in RAID1 (using Intel Rapid
Raid), OmniOS no longer detects the drive.  We can only see the drives when
they're not part of a RAID array.

Any-help is appreciated.

- Russ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20120708/8b00a4ed/attachment.html>

From jesus at omniti.com  Sun Jul  8 16:29:15 2012
From: jesus at omniti.com (Theo Schlossnagle)
Date: Sun, 8 Jul 2012 16:29:15 -0400
Subject: [OmniOS-discuss] Trouble with drive detection on Installation.
In-Reply-To: <CALg0+okmATU-5nSwbg5NBz9T02t0CeATg6NTjACdj3J6X7JuEA@mail.gmail.com>
References: <CALg0+okmATU-5nSwbg5NBz9T02t0CeATg6NTjACdj3J6X7JuEA@mail.gmail.com>
Message-ID: <CACLsApviaR2sg84yYDU8+3qx2V=p5tLraTqkDOoSVq6W=CKABA@mail.gmail.com>

Let's try to figure if this is an installer bug or an OS detection
bug.  When you boot the text installer image, there is an option to
drop to a prompt.  If you could run that and then run "format" from
there, you should be able to see *all* the disks.  If format works,
then there is a bug in the installer.  If format does not show the
disks, we have a more serious bug.

The ISO image installer we use in OmniOS is "caimam" from Oracle.  It
is subject to the evils of a close-core model.  The current open
source release of caiman relies on features and functions of the
underlying system that have been altered since they sources were
closed.  Because of this, we've found a few issues in the installer
itself acting poorly on our Illumos.

If you are going to be doing a lot of installs, consider the Kayak installer.

Of course, as this is all open... if you know the problem and can
propose a patch, we'll happily work to integrate it!

On Sun, Jul 8, 2012 at 3:13 PM, Russ Thompson <vigornj at gmail.com> wrote:
> Hello world,
>
> I am in the process of evaluating OmniOS as an in house replacement for
> Nexenta.  We have ran into several issues during the installation (albeit
> minor).
>
> Our setup consists of:
> LSI HBA (cabled to Supermicro PCB/backplane).
> 12x 2TB drives (for our main pool)
> 6x   3TB drives (for our backup pool)
> 4x   250GB SSD Drives (L2Arch)
> 1x   4GB DDRdrive (ZIL)
>
> The BIOS and LSI HBA detect all of the drives.  However during installation,
> OmniOS detects all drives, except 3 of the SSD drives.  It's only detecting
> one of those, all other drives are detected.  Downloaded the LSI utility and
> am able to see the drives through the CLI once booted into OmniOS.
>
> What are we missing?
>
> We also have two SSD hard drives connected to the onboard controller, these
> drives are for the OS.  When we configure them in RAID1 (using Intel Rapid
> Raid), OmniOS no longer detects the drive.  We can only see the drives when
> they're not part of a RAID array.
>
> Any-help is appreciated.
>
> - Russ
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>



-- 
Theo Schlossnagle

http://omniti.com/is/theo-schlossnagle

From denis at denisandyuki.net  Sun Jul  8 20:24:07 2012
From: denis at denisandyuki.net (Denis Cheong)
Date: Mon, 9 Jul 2012 10:24:07 +1000
Subject: [OmniOS-discuss] illumos bug #2869 duplicate packets with vnics
	over aggrs
Message-ID: <CABOCf+g27KySPG0hbA=kqwf3SiHHaHawc2dVNHacbn=r0wBpNg@mail.gmail.com>

Hi Theo

Is there an easy way that I can test your proposed fix to this issue?

I am having major network performance bottlenecks in KVM and I suspect that
it has something to do with the duplicate packets, so would like to test it
out.

Thanks

Denis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20120709/a8ba77ba/attachment.html>

From jesus at omniti.com  Sun Jul  8 20:53:32 2012
From: jesus at omniti.com (Theo Schlossnagle)
Date: Sun, 8 Jul 2012 20:53:32 -0400
Subject: [OmniOS-discuss] illumos bug #2869 duplicate packets with vnics
 over aggrs
In-Reply-To: <CABOCf+g27KySPG0hbA=kqwf3SiHHaHawc2dVNHacbn=r0wBpNg@mail.gmail.com>
References: <CABOCf+g27KySPG0hbA=kqwf3SiHHaHawc2dVNHacbn=r0wBpNg@mail.gmail.com>
Message-ID: <CACLsApueEEkFespjbOGzjD=tEJdEoO7-zmGRmA2NCS7WROdoZg@mail.gmail.com>

Yes. If you switch to the bloody repo, you should be able to do a pkg
update and get a new kernel.

The release publisher is: http://pkg.omniti.com/omnios/release/
Bloody's publisher is: http://pkg.omniti.com/omnios/bloody/

pkg unset-publisher omnios
pkg set-publisher -g http://pkg.omniti.com/omnios/bloody/ omnios
pkg update

This should give you a new BE running bloody to reboot into.

Alternatively, you could just snag the aggr module from bloody and
replace the one you have.

There are a couple of severe performance pathologies regarding
networking under qemu/kvm, can you say what the guest is?

On Sun, Jul 8, 2012 at 8:24 PM, Denis Cheong <denis at denisandyuki.net> wrote:
> Hi Theo
>
> Is there an easy way that I can test your proposed fix to this issue?
>
> I am having major network performance bottlenecks in KVM and I suspect that
> it has something to do with the duplicate packets, so would like to test it
> out.


-- 
Theo Schlossnagle

http://omniti.com/is/theo-schlossnagle

From esproul at omniti.com  Tue Jul 10 12:13:18 2012
From: esproul at omniti.com (Eric Sproul)
Date: Tue, 10 Jul 2012 12:13:18 -0400
Subject: [OmniOS-discuss] Updated release: r151002o
Message-ID: <CA+QY2RQ4=Nfi84rjgYrF__HSBAFYm5xW1Z6Z3VhDDMpXL_W8PQ@mail.gmail.com>

OmniOS weekly release r151002o updates system/pciutils and
system/pciutils/pci.ids to the latest release.

http://omnios.omniti.com/wiki.php/ReleaseNotes#r151002o

From denis at denisandyuki.net  Sat Jul 21 00:18:34 2012
From: denis at denisandyuki.net (Denis Cheong)
Date: Sat, 21 Jul 2012 14:18:34 +1000
Subject: [OmniOS-discuss] illumos bug #2869 duplicate packets with vnics
 over aggrs
In-Reply-To: <CABOCf+hBLYcKYrx9OVdnD7vS3WO8uCgbXxXvU2ay_SiKJ+6byg@mail.gmail.com>
References: <CABOCf+g27KySPG0hbA=kqwf3SiHHaHawc2dVNHacbn=r0wBpNg@mail.gmail.com>
	<CACLsApueEEkFespjbOGzjD=tEJdEoO7-zmGRmA2NCS7WROdoZg@mail.gmail.com>
	<CABOCf+hBLYcKYrx9OVdnD7vS3WO8uCgbXxXvU2ay_SiKJ+6byg@mail.gmail.com>
Message-ID: <CABOCf+jWDr+eqPJJCbuxEvSbaC78LX==+KCpxL3m-jw8tNPpug@mail.gmail.com>

Thanks Theo, I will see what I can pull.  I think grabbing just the aggr
module is the best option at the moment.

The guest is Gentoo (Kernel 3.2.12).

Here's the performance bottleneck I'm seeing ..

gazoo is OmniOS host with 2 x igb in L4 aggr with main lan on VLAN 300
slate is Gentoo KVM on OmniOS with 1 x virtio vnic on aggr VLAN 300
myth is Gentoo phys with 1 x nvidia single gige with main lan on VLAN 300

Issue:
gazoo <> myth = good
anything <> slate = bad

Examples:

myth ~ # iperf -c gazoo
------------------------------------------------------------
Client connecting to gazoo, TCP port 5001
TCP window size: 22.5 KByte (default)
------------------------------------------------------------
[  3] local 192.168.245.136 port 60917 connected with 192.168.245.134 port
5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.09 GBytes   932 Mbits/sec

root at gazoo ~ # iperf -c myth
------------------------------------------------------------
Client connecting to myth, TCP port 5001
TCP window size: 48.0 KByte (default)
------------------------------------------------------------
[  4] local 192.168.245.134 port 36001 connected with 192.168.245.136 port
5001
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec  1.05 GBytes    899 Mbits/sec

root at gazoo ~ # iperf -c slate
------------------------------------------------------------
Client connecting to slate, TCP port 5001
TCP window size: 48.0 KByte (default)
------------------------------------------------------------
[  4] local 192.168.245.134 port 51500 connected with 192.168.245.152 port
5001
[ ID] Interval       Transfer     Bandwidth
*[  4]  0.0-10.0 sec  26.5 MBytes  22.2 Mbits/sec*


myth ~ # iperf -c slate
------------------------------------------------------------
Client connecting to slate, TCP port 5001
TCP window size: 22.5 KByte (default)
------------------------------------------------------------
[  3] local 192.168.245.136 port 56461 connected with 192.168.245.152 port
5001
[ ID] Interval       Transfer     Bandwidth
*[  3]  0.0-10.2 sec  91.8 MBytes  75.3 Mbits/sec*



On Mon, Jul 9, 2012 at 10:53 AM, Theo Schlossnagle <jesus at omniti.com> wrote:

> Yes. If you switch to the bloody repo, you should be able to do a pkg
> update and get a new kernel.
>
> The release publisher is: http://pkg.omniti.com/omnios/release/
> Bloody's publisher is: http://pkg.omniti.com/omnios/bloody/
>
> pkg unset-publisher omnios
> pkg set-publisher -g http://pkg.omniti.com/omnios/bloody/ omnios
> pkg update
>
> This should give you a new BE running bloody to reboot into.
>
> Alternatively, you could just snag the aggr module from bloody and
> replace the one you have.
>
> There are a couple of severe performance pathologies regarding
> networking under qemu/kvm, can you say what the guest is?
>
> On Sun, Jul 8, 2012 at 8:24 PM, Denis Cheong <denis at denisandyuki.net>
> wrote:
> > Hi Theo
> >
> > Is there an easy way that I can test your proposed fix to this issue?
> >
> > I am having major network performance bottlenecks in KVM and I suspect
> that
> > it has something to do with the duplicate packets, so would like to test
> it
> > out.
>
>
> --
> Theo Schlossnagle
>
> http://omniti.com/is/theo-schlossnagle
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20120721/a175f9e4/attachment.html>

From richard.elling at richardelling.com  Sun Jul 22 01:09:04 2012
From: richard.elling at richardelling.com (Richard Elling)
Date: Sat, 21 Jul 2012 22:09:04 -0700
Subject: [OmniOS-discuss] illumos bug #2869 duplicate packets with vnics
	over aggrs
In-Reply-To: <CABOCf+jWDr+eqPJJCbuxEvSbaC78LX==+KCpxL3m-jw8tNPpug@mail.gmail.com>
References: <CABOCf+g27KySPG0hbA=kqwf3SiHHaHawc2dVNHacbn=r0wBpNg@mail.gmail.com>
	<CACLsApueEEkFespjbOGzjD=tEJdEoO7-zmGRmA2NCS7WROdoZg@mail.gmail.com>
	<CABOCf+hBLYcKYrx9OVdnD7vS3WO8uCgbXxXvU2ay_SiKJ+6byg@mail.gmail.com>
	<CABOCf+jWDr+eqPJJCbuxEvSbaC78LX==+KCpxL3m-jw8tNPpug@mail.gmail.com>
Message-ID: <94CDC993-FF94-4E2A-B8B5-14F6D03B6840@RichardElling.com>

You need to set the window size and ignore measurements of the startup.

Also, FWIW, I've not found L4 to be particularly useful. Link aggr is just lame.

Finally, dladm show-aggr -s, is your friend.
 -- Richard


On Jul 20, 2012, at 9:18 PM, Denis Cheong <denis at denisandyuki.net> wrote:

> Thanks Theo, I will see what I can pull.  I think grabbing just the aggr module is the best option at the moment.
> 
> The guest is Gentoo (Kernel 3.2.12).
> 
> Here's the performance bottleneck I'm seeing ..
> 
> gazoo is OmniOS host with 2 x igb in L4 aggr with main lan on VLAN 300
> slate is Gentoo KVM on OmniOS with 1 x virtio vnic on aggr VLAN 300
> myth is Gentoo phys with 1 x nvidia single gige with main lan on VLAN 300
> 
> Issue:
> gazoo <> myth = good
> anything <> slate = bad
> 
> Examples:
> 
> myth ~ # iperf -c gazoo
> ------------------------------------------------------------
> Client connecting to gazoo, TCP port 5001
> TCP window size: 22.5 KByte (default)
> ------------------------------------------------------------
> [  3] local 192.168.245.136 port 60917 connected with 192.168.245.134 port 5001
> [ ID] Interval       Transfer     Bandwidth
> [  3]  0.0-10.0 sec  1.09 GBytes   932 Mbits/sec
> 
> root at gazoo ~ # iperf -c myth
> ------------------------------------------------------------
> Client connecting to myth, TCP port 5001
> TCP window size: 48.0 KByte (default)
> ------------------------------------------------------------
> [  4] local 192.168.245.134 port 36001 connected with 192.168.245.136 port 5001
> [ ID] Interval       Transfer     Bandwidth
> [  4]  0.0-10.0 sec  1.05 GBytes    899 Mbits/sec
> 
> root at gazoo ~ # iperf -c slate
> ------------------------------------------------------------
> Client connecting to slate, TCP port 5001
> TCP window size: 48.0 KByte (default)
> ------------------------------------------------------------
> [  4] local 192.168.245.134 port 51500 connected with 192.168.245.152 port 5001
> [ ID] Interval       Transfer     Bandwidth
> [  4]  0.0-10.0 sec  26.5 MBytes  22.2 Mbits/sec
> 
> 
> myth ~ # iperf -c slate
> ------------------------------------------------------------
> Client connecting to slate, TCP port 5001
> TCP window size: 22.5 KByte (default)
> ------------------------------------------------------------
> [  3] local 192.168.245.136 port 56461 connected with 192.168.245.152 port 5001
> [ ID] Interval       Transfer     Bandwidth
> [  3]  0.0-10.2 sec  91.8 MBytes  75.3 Mbits/sec
> 
> 
> 
> On Mon, Jul 9, 2012 at 10:53 AM, Theo Schlossnagle <jesus at omniti.com> wrote:
> Yes. If you switch to the bloody repo, you should be able to do a pkg
> update and get a new kernel.
> 
> The release publisher is: http://pkg.omniti.com/omnios/release/
> Bloody's publisher is: http://pkg.omniti.com/omnios/bloody/
> 
> pkg unset-publisher omnios
> pkg set-publisher -g http://pkg.omniti.com/omnios/bloody/ omnios
> pkg update
> 
> This should give you a new BE running bloody to reboot into.
> 
> Alternatively, you could just snag the aggr module from bloody and
> replace the one you have.
> 
> There are a couple of severe performance pathologies regarding
> networking under qemu/kvm, can you say what the guest is?
> 
> On Sun, Jul 8, 2012 at 8:24 PM, Denis Cheong <denis at denisandyuki.net> wrote:
> > Hi Theo
> >
> > Is there an easy way that I can test your proposed fix to this issue?
> >
> > I am having major network performance bottlenecks in KVM and I suspect that
> > it has something to do with the duplicate packets, so would like to test it
> > out.
> 
> 
> --
> Theo Schlossnagle
> 
> http://omniti.com/is/theo-schlossnagle
> 
> 
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20120721/0e869154/attachment.html>

From jesus at omniti.com  Wed Jul 25 08:13:33 2012
From: jesus at omniti.com (Theo Schlossnagle)
Date: Wed, 25 Jul 2012 08:13:33 -0400
Subject: [OmniOS-discuss] illumos bug #2869 duplicate packets with vnics
 over aggrs
In-Reply-To: <94CDC993-FF94-4E2A-B8B5-14F6D03B6840@RichardElling.com>
References: <CABOCf+g27KySPG0hbA=kqwf3SiHHaHawc2dVNHacbn=r0wBpNg@mail.gmail.com>
	<CACLsApueEEkFespjbOGzjD=tEJdEoO7-zmGRmA2NCS7WROdoZg@mail.gmail.com>
	<CABOCf+hBLYcKYrx9OVdnD7vS3WO8uCgbXxXvU2ay_SiKJ+6byg@mail.gmail.com>
	<CABOCf+jWDr+eqPJJCbuxEvSbaC78LX==+KCpxL3m-jw8tNPpug@mail.gmail.com>
	<94CDC993-FF94-4E2A-B8B5-14F6D03B6840@RichardElling.com>
Message-ID: <CACLsAps3Ao7XpcBN3vnN=QPf9Ft6xLiktDSNJ_svYqUF5PD60Q@mail.gmail.com>

And for a different perspective, we have great success and happiness
with L2 link aggregation in our datacenters.

We do it for redundancy (not increased capacity) in the case where one
of our switch chasis fails (or PDU pops).

On Sun, Jul 22, 2012 at 1:09 AM, Richard Elling
<richard.elling at richardelling.com> wrote:
> You need to set the window size and ignore measurements of the startup.
>
> Also, FWIW, I've not found L4 to be particularly useful. Link aggr is just
> lame.
>
> Finally, dladm show-aggr -s, is your friend.
>  -- Richard
>
>
> On Jul 20, 2012, at 9:18 PM, Denis Cheong <denis at denisandyuki.net> wrote:
>
> Thanks Theo, I will see what I can pull.  I think grabbing just the aggr
> module is the best option at the moment.
>
> The guest is Gentoo (Kernel 3.2.12).
>
> Here's the performance bottleneck I'm seeing ..
>
> gazoo is OmniOS host with 2 x igb in L4 aggr with main lan on VLAN 300
> slate is Gentoo KVM on OmniOS with 1 x virtio vnic on aggr VLAN 300
> myth is Gentoo phys with 1 x nvidia single gige with main lan on VLAN 300
>
> Issue:
> gazoo <> myth = good
> anything <> slate = bad
>
> Examples:
>
> myth ~ # iperf -c gazoo
> ------------------------------------------------------------
> Client connecting to gazoo, TCP port 5001
> TCP window size: 22.5 KByte (default)
> ------------------------------------------------------------
> [  3] local 192.168.245.136 port 60917 connected with 192.168.245.134 port
> 5001
> [ ID] Interval       Transfer     Bandwidth
> [  3]  0.0-10.0 sec  1.09 GBytes   932 Mbits/sec
>
> root at gazoo ~ # iperf -c myth
> ------------------------------------------------------------
> Client connecting to myth, TCP port 5001
> TCP window size: 48.0 KByte (default)
> ------------------------------------------------------------
> [  4] local 192.168.245.134 port 36001 connected with 192.168.245.136 port
> 5001
> [ ID] Interval       Transfer     Bandwidth
> [  4]  0.0-10.0 sec  1.05 GBytes    899 Mbits/sec
>
> root at gazoo ~ # iperf -c slate
> ------------------------------------------------------------
> Client connecting to slate, TCP port 5001
> TCP window size: 48.0 KByte (default)
> ------------------------------------------------------------
> [  4] local 192.168.245.134 port 51500 connected with 192.168.245.152 port
> 5001
> [ ID] Interval       Transfer     Bandwidth
> [  4]  0.0-10.0 sec  26.5 MBytes  22.2 Mbits/sec
>
>
> myth ~ # iperf -c slate
> ------------------------------------------------------------
> Client connecting to slate, TCP port 5001
> TCP window size: 22.5 KByte (default)
> ------------------------------------------------------------
> [  3] local 192.168.245.136 port 56461 connected with 192.168.245.152 port
> 5001
> [ ID] Interval       Transfer     Bandwidth
> [  3]  0.0-10.2 sec  91.8 MBytes  75.3 Mbits/sec
>
>
>
> On Mon, Jul 9, 2012 at 10:53 AM, Theo Schlossnagle <jesus at omniti.com> wrote:
>>
>> Yes. If you switch to the bloody repo, you should be able to do a pkg
>> update and get a new kernel.
>>
>> The release publisher is: http://pkg.omniti.com/omnios/release/
>> Bloody's publisher is: http://pkg.omniti.com/omnios/bloody/
>>
>> pkg unset-publisher omnios
>> pkg set-publisher -g http://pkg.omniti.com/omnios/bloody/ omnios
>> pkg update
>>
>> This should give you a new BE running bloody to reboot into.
>>
>> Alternatively, you could just snag the aggr module from bloody and
>> replace the one you have.
>>
>> There are a couple of severe performance pathologies regarding
>> networking under qemu/kvm, can you say what the guest is?
>>
>> On Sun, Jul 8, 2012 at 8:24 PM, Denis Cheong <denis at denisandyuki.net>
>> wrote:
>> > Hi Theo
>> >
>> > Is there an easy way that I can test your proposed fix to this issue?
>> >
>> > I am having major network performance bottlenecks in KVM and I suspect
>> > that
>> > it has something to do with the duplicate packets, so would like to test
>> > it
>> > out.
>>
>>
>> --
>> Theo Schlossnagle
>>
>> http://omniti.com/is/theo-schlossnagle
>
>
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>



-- 
Theo Schlossnagle

http://omniti.com/is/theo-schlossnagle

From richard.elling at richardelling.com  Wed Jul 25 13:21:19 2012
From: richard.elling at richardelling.com (Richard Elling)
Date: Wed, 25 Jul 2012 10:21:19 -0700
Subject: [OmniOS-discuss] illumos bug #2869 duplicate packets with vnics
	over aggrs
In-Reply-To: <CACLsAps3Ao7XpcBN3vnN=QPf9Ft6xLiktDSNJ_svYqUF5PD60Q@mail.gmail.com>
References: <CABOCf+g27KySPG0hbA=kqwf3SiHHaHawc2dVNHacbn=r0wBpNg@mail.gmail.com>
	<CACLsApueEEkFespjbOGzjD=tEJdEoO7-zmGRmA2NCS7WROdoZg@mail.gmail.com>
	<CABOCf+hBLYcKYrx9OVdnD7vS3WO8uCgbXxXvU2ay_SiKJ+6byg@mail.gmail.com>
	<CABOCf+jWDr+eqPJJCbuxEvSbaC78LX==+KCpxL3m-jw8tNPpug@mail.gmail.com>
	<94CDC993-FF94-4E2A-B8B5-14F6D03B6840@RichardElling.com>
	<CACLsAps3Ao7XpcBN3vnN=QPf9Ft6xLiktDSNJ_svYqUF5PD60Q@mail.gmail.com>
Message-ID: <2787EAB1-32F8-4F0C-92AB-AC7734AC4DED@richardelling.com>

On Jul 25, 2012, at 5:13 AM, Theo Schlossnagle wrote:

> And for a different perspective, we have great success and happiness
> with L2 link aggregation in our datacenters.
> 
> We do it for redundancy (not increased capacity) in the case where one
> of our switch chasis fails (or PDU pops).

Indeed, this is the use case for which it was designed: protecting the link.
As you try to move up the stack, above L2, you can get into all sorts of
gnarly issues, though... I've seen switches fall to their knees, begging for
forgiveness :-)

To make this work across switches in a multi-vendor environment is, last I
checked, not possible. I've got old, healed scars from Cisco and Arista
implementations of link aggregation across switches. As you note, L2 is a
good choice.
 -- richard

--
ZFS Performance and Training
Richard.Elling at RichardElling.com
+1-760-896-4422



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20120725/a34aa01c/attachment.html>

