1 03:56
To: Archie Cobbs
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: call for testers: port aggregation netgraph module
> Bill Paul writes:
> > http://www.freebsd.org/~wpaul/FEC/4.x/fec.tar.gz
> > http://www.freebsd.org/~wpaul/FEC/5.x/fec.tar.gz
> >
> > This
> >> >Each link is checked once every second to see if the link is still up.
> >> >An attempt to send a packet over a dead link will cause the packet to
> >> >be shifted over to the next link in the bundle.
> >>
> >> Any chance this can be done through an async event rather
> >> than by polling?
>> >Each link is checked once every second to see if the link is still up.
>> >An attempt to send a packet over a dead link will cause the packet to
>> >be shifted over to the next link in the bundle.
>>
>> Any chance this can be done through an async event rather
>> than by polling?
>
>If there
> >Each link is checked once every second to see if the link is still up.
> >An attempt to send a packet over a dead link will cause the packet to
> >be shifted over to the next link in the bundle.
>
> Any chance this can be done through an async event rather
> than by polling?
If there was, I w
At 03:42 PM 03/10/2001, Justin T. Gibbs wrote:
> >Each link is checked once every second to see if the link is still up.
> >An attempt to send a packet over a dead link will cause the packet to
> >be shifted over to the next link in the bundle.
>
>Any chance this can be done through an async event
>Each link is checked once every second to see if the link is still up.
>An attempt to send a packet over a dead link will cause the packet to
>be shifted over to the next link in the bundle.
Any chance this can be done through an async event rather
than by polling?
--
Justin
To Unsubscribe: s
-On [20010212 00:30], Rogier R. Mulhuijzen ([EMAIL PROTECTED]) wrote:
>There's a IEEE standard these days for link aggregation. 802.3AD if I'm not
>mistaken. When my workload at work lightens up I'll be spending time on this.
You are correct.
--
Jeroen Ruigrok vd Werven/Asmodaiasmodai@[wxs
> Date: Sat, 10 Feb 2001 15:29:17 +0100
> From: Rainer Clasen <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: call for testers: port aggregation netgraph module
>
> On Thu, Feb 08, 2001 at 01:25:09PM -0800, Bill Paul wrote:
> >
Bill Paul writes:
> > > This is a call for testers for a netgraph module that can be used to
> > > aggregate 2 or 4 ethernet interfaces into a single interface. Basically,
> > > it lets you do things like the following:
>
> You know, so far I've gotten close to a dozen replies to this e-mail,
> b
Bill Paul wrote:
>
one other thing..
In ng_fec.h you have kept the same cookie number as ng_iface
which means that messages for these two can be confused.
You should use a differnt cookie
by tradition we use date -u +'%s'
to generate or change the cookie.
Since the first 3 commands you have a
Bill Paul wrote:
>
> >
> You know, so far I've gotten close to a dozen replies to this e-mail,
> but none of contain the one thing I really wanted, namely test results.
actually I saw one person say it worked flawlessly for them
(see mail from: Rainer Clasen <[EMAIL PROTECTED]> )
(workin
> Bill Paul writes:
> > http://www.freebsd.org/~wpaul/FEC/4.x/fec.tar.gz
> > http://www.freebsd.org/~wpaul/FEC/5.x/fec.tar.gz
> >
> > This is a call for testers for a netgraph module that can be used to
> > aggregate 2 or 4 ethernet interfaces into a single interface. Basically,
> > it lets you d
Bill Paul writes:
> http://www.freebsd.org/~wpaul/FEC/4.x/fec.tar.gz
> http://www.freebsd.org/~wpaul/FEC/5.x/fec.tar.gz
>
> This is a call for testers for a netgraph module that can be used to
> aggregate 2 or 4 ethernet interfaces into a single interface. Basically,
> it lets you do things like
> > I actually tried to set the ports on the 3COM switch up as trunk
> > ports, it didn't work right. Maybe 3COM is doing something entirely
> > different.
>Prolly. FEC is cisco-specific thingy, like ISL...
There's a IEEE standard these days for link aggregation. 802.3AD if I'm not
mistaken. W
On Thu, Feb 08, 2001 at 01:25:09PM -0800, Bill Paul wrote:
> http://www.freebsd.org/~wpaul/FEC/4.x/fec.tar.gz
I've tried this with 4.2-RELEASE on a single PIII-500 with 128 MB RAM and
2 fxp0 Interfaces. It was attached to a Nortel Baystack 450 running a 2
port "Multinlink Trunk" Configuration.
I
Sorry, my brain's fried this afternoon.
< u_int64_t mask = ~0 & (n-1);/* mask for iftab index */
> u_int64_t mask = n-1; /* mask for iftab index */
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
> "Chris" == Chris Dillon <[EMAIL PROTECTED]> writes:
>> Its not real trunking. Your incoming traffic will still come on
>> a single link, only outbound traffic will be shared. (Or at
>> least that's how I think compaq stuff will work).
Chris> Yes, I think that is how it work
> On Fri, 9 Feb 2001, Chris Dillon wrote:
>
> > On Fri, 9 Feb 2001, Dan Nelson wrote:
>
> > Cool, if thats all it will take, I'll give it a try. But, whatever
> > method Compaq/Intel is using doesn't require me to set up the ports on
> > the switch as being part of a trunk. It "just works". A
On Fri, 9 Feb 2001, Alex Pilosov wrote:
> On Fri, 9 Feb 2001, Chris Dillon wrote:
>
> > Cool, if thats all it will take, I'll give it a try. But, whatever
> > method Compaq/Intel is using doesn't require me to set up the ports on
> > the switch as being part of a trunk. It "just works". And II
The crock in these trunking schemes is all the trouble and effort expended
to avoid re-ordering frames across the trunk bundle. This is why you
see things like the hashing techniques so that an individual flow of
traffic doesn't get reordered because it always is serialized over the
a single pat
On Fri, 9 Feb 2001, Chris Dillon wrote:
> On Fri, 9 Feb 2001, Dan Nelson wrote:
> Cool, if thats all it will take, I'll give it a try. But, whatever
> method Compaq/Intel is using doesn't require me to set up the ports on
> the switch as being part of a trunk. It "just works". And IIRC, when
On Fri, 9 Feb 2001, Dan Nelson wrote:
> In the last episode (Feb 08), Chris Dillon said:
> > > The channel bonding is done using the Cisco fast etherchannel
> > > mechanism. The default hashing mechanism uses the MAC address,
> > > however you can select IP address hashing as well. IPv4 and IPv6
> I've just finished scouring Cisco's documentation, and it doesn't look
> like FEC is anything beyond plain old trunking (with the option of
> autoconfiguration on some hardware). As long as you configure the
> appropriate ports on the switch on the other end as "SA-Trunk", or
> "Trunk", you sho
In the last episode (Feb 08), Chris Dillon said:
> > The channel bonding is done using the Cisco fast etherchannel
> > mechanism. The default hashing mechanism uses the MAC address,
> > however you can select IP address hashing as well. IPv4 and IPv6
> > address *should* work, though I must admit
Welcome to netgraph.. I hope it was not an unpleasant experience..
Suggestions and complaints are definitly eccepted with pleasure.
E.g. Was the differnce between 4.x and 5.x too much of a pain.?
(it was needed for SMP)
I will be making a backport of SOME of the added functionality
of 5.x to 4.x
On Thu, 8 Feb 2001, Bill Paul wrote:
> http://www.freebsd.org/~wpaul/FEC/4.x/fec.tar.gz
> http://www.freebsd.org/~wpaul/FEC/5.x/fec.tar.gz
>
> This is a call for testers for a netgraph module that can be used
> to aggregate 2 or 4 ethernet interfaces into a single interface.
> Basically, it lets
http://www.freebsd.org/~wpaul/FEC/4.x/fec.tar.gz
http://www.freebsd.org/~wpaul/FEC/5.x/fec.tar.gz
This is a call for testers for a netgraph module that can be used to
aggregate 2 or 4 ethernet interfaces into a single interface. Basically,
it lets you do things like the following:
# kldload ./ng
27 matches
Mail list logo
