Re: yet another unsupported PHY in fxp driver
> >It seems that the NetBSD folks have eliminated this ongoing pain in the >butt by using the mii interface for the intel cards. Is freebsd also moving >in this direction? Every few months there seems to be a problem, and its >difficult to fix it without docs The primary problems that have resulted in the "unsupported PHY" messages in the past year or so have been related to either the format or size of the SEEPROM changing. Using generic MII code doesn't fix the problem; the fxp's would still not work due to the MAC address being wrong, among other things, which is also read from the SEEPROM. This said, I think it is generally the right approach to use a generic MII PHY software interface and at some point the driver will likely be updated for that. It is low priority, however, since it doesn't solve any problems. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: etherchannel
Lyndon Nerenberg writes: > Mike> This is primarily conditional on Cisco or some other party > Mike> making the specifications for etherchannel freely available. > Mike> The last time I went looking for any actual documentation on > Mike> how to format things on the wire, I drew a complete blank. > > >http://www.cisco.com/warp/public/cc/techno/media/lan/ether/channel/prodlit/faste_an.htm > > It's pretty simple -- just an XOR of the bottom two bits of the destination > MAC address to determine which interface in the bundle to send the packet > out. If anyone is interested, I've got a "ng_one2many" netgraph node type that does simple round-robin packet delivery with no notion of failover. The intent is to eventually add support for different configurations, one of which would be Etherchannel, by configuring the node for the desired behavior. If you want to play with it, here is the current version: ftp://ftp.whistle.com/pub/archie/netgraph/ng_one2many.tgz -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: etherchannel
> "rbg" == rbg <[EMAIL PROTECTED]> writes: rbg> How does this compare with Intel's Adaptive Load Balancing rbg> (ALB) ? -- I guess it's closer to Intel's Link Aggregation Dunno, I'm not familiar with ALB. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: etherchannel
> "Mike" == Mike Smith <[EMAIL PROTECTED]> writes: Mike> This is primarily conditional on Cisco or some other party Mike> making the specifications for etherchannel freely available. Mike> The last time I went looking for any actual documentation on Mike> how to format things on the wire, I drew a complete blank. http://www.cisco.com/warp/public/cc/techno/media/lan/ether/channel/prodlit/faste_an.htm It's pretty simple -- just an XOR of the bottom two bits of the destination MAC address to determine which interface in the bundle to send the packet out. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: etherchannel
This is primarily conditional on Cisco or some other party making the specifications for etherchannel freely available. The last time I went looking for any actual documentation on how to format things on the wire, I drew a complete blank. Then we just need someone to lend a developer the requisite hardware... > I think someone got me wrong there: > > What I would like to ask the freebsd core team is if > an implementation of the etherchannel capability - the > way cisco uses the term - is planned in further > development (for multiple physical ethernet > interfaces not for isdn links). E.g. for channeling > all four ports of an Adaptec Starfire QuadPort card > to a cisco 6500 ;-) > So if anyone of the core team reads this > message just a quick reply would be much > appreciated. > > Thanks > > Andreas > > --- > > Andreas Brodmann > Network Management > Telecommunications Department > Gen. Migros Aare > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
etherchannel
I think someone got me wrong there: What I would like to ask the freebsd core team is if an implementation of the etherchannel capability - the way cisco uses the term - is planned in further development (for multiple physical ethernet interfaces not for isdn links). E.g. for channeling all four ports of an Adaptec Starfire QuadPort card to a cisco 6500 ;-) So if anyone of the core team reads this message just a quick reply would be much appreciated. Thanks Andreas --- Andreas Brodmann Network Management Telecommunications Department Gen. Migros Aare To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: etherchannel / bonding
> >It's used for other cases where a high capacity circuit is built out >of multiple physical channels. That's what the original claims about >EtherChannel were from cisco, and it's what we use it for. That it >continues to work if one the links has a failure is a bonus. It's a >substantial bonus, but it would be used even if it didn't. Well its wrong, so why perpetuate it? Higher minds are supposed to know better than to just follow the wallys. Anyone who ever worked at a telco knows how clueless they are about anything that doesnt have a red and a green light on it. DB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: etherchannel / bonding
On Wed, 12 Oct 1988, Dennis wrote: :At 09:01 AM 10/12/2000, David Scheidt wrote: :>On Wed, 11 Oct 2000, Dennis wrote: :> :>:We will have the feature in our bandwidth manager product for FreeBSD :>:shortly, including fallover. Its really load balancing; bonding is a bad :>:term (no doubt coined by the linux camp). :>: :> :>It's telco usage from before there was a linux (and probably before :>there was a Linus), so it's rather unlikely that they're responsible for :>it. : : :No, telcos used the term "bonding" for ISDN, which actually IS a physical :bonding technique. Its all the half-wits that think that load balancing is :the same thing that now associate virtual techniques to something very :different. It's used for other cases where a high capacity circuit is built out of multiple physical channels. That's what the original claims about EtherChannel were from cisco, and it's what we use it for. That it continues to work if one the links has a failure is a bonus. It's a substantial bonus, but it would be used even if it didn't. David To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: etherchannel / bonding
Dennis wrote: > > At 09:01 AM 10/12/2000, David Scheidt wrote: > >On Wed, 11 Oct 2000, Dennis wrote: > > > >:We will have the feature in our bandwidth manager product for FreeBSD > >:shortly, including fallover. Its really load balancing; bonding is a bad > >:term (no doubt coined by the linux camp). > >: > > > >It's telco usage from before there was a linux (and probably before > >there was a Linus), so it's rather unlikely that they're responsible for > >it. > > No, telcos used the term "bonding" for ISDN, which actually IS a physical > bonding technique. Its all the half-wits that think that load balancing is > the same thing that now associate virtual techniques to something very > different. The term was used to describe any channel aggregation when I worked for GTE, before Linus went to college, and before ISDN was really known in the USA. The Spacenet boys even used it to describe mutiplying bandwidth on satellite channels. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
yet another unsupported PHY in fxp driver
It seems that the NetBSD folks have eliminated this ongoing pain in the butt by using the mii interface for the intel cards. Is freebsd also moving in this direction? Every few months there seems to be a problem, and its difficult to fix it without docs DB Emerging Technologies, Inc. - http://www.etinc.com ISA and PCI T1/T3/V35/HSSI Cards for FreeBSD and LINUX Multiport T1 and HSSI/T3 UNIX-based Routers Bandwidth Management Standalone Systems Bandwidth Management software for LINUX and FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: etherchannel / bonding
At 09:01 AM 10/12/2000, David Scheidt wrote: >On Wed, 11 Oct 2000, Dennis wrote: > >:We will have the feature in our bandwidth manager product for FreeBSD >:shortly, including fallover. Its really load balancing; bonding is a bad >:term (no doubt coined by the linux camp). >: > >It's telco usage from before there was a linux (and probably before >there was a Linus), so it's rather unlikely that they're responsible for >it. No, telcos used the term "bonding" for ISDN, which actually IS a physical bonding technique. Its all the half-wits that think that load balancing is the same thing that now associate virtual techniques to something very different. DB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: etherchannel / bonding
On Wed, 11 Oct 2000, Dennis wrote: :We will have the feature in our bandwidth manager product for FreeBSD :shortly, including fallover. Its really load balancing; bonding is a bad :term (no doubt coined by the linux camp). : It's telco usage from before there was a linux (and probably before there was a Linus), so it's rather unlikely that they're responsible for it. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
