*** From dhcp-server -- To unsubscribe, see the end of this message. ***
On Wed, Apr 28, 1999 at 12:55:45PM +0200, Jeroen Massar wrote:
> *** From dhcp-server -- To unsubscribe, see the end of this message. ***
>
> On Tue, 27 Apr 1999, Jasper O'Malley wrote:
>
> > On Tue, 27 Apr 1999, Jeroen Massar wrote:
> >
> > > Problem is that they call it a bridge and it acts like a switch...
> >
> > How are you defining the term "switch?" To me, a bridge is a dual-port
> > switch, and a switch is a multi-port bridge :) The Linux bridge behavior
> > described is just plain broken.
> Switch = multiple seperate segments getting only seeing packets for that segment...
> Bridge = multiple seperate segments seeing ALL packets..
Repeater = two port device that copies ALL packets from one port to the
other port.
[Shared] Hub = multi-port device that copies ALL packets from one port
to ALL other ports.
Bridge = two port device that copies packets received on one port to the
other port if the destination is known to be located off of the
other port. ALL packets are copied whose destination address'
location is unknown. ALL broadcast packets are copied.
Switch[ed hub] = multi-port device that copies any packet received on
one port to the appropriate port such that the packet's
destination address is known to be located behind that
port.
In other words:
Bridge = a smart repeater
Switch[ed hub] = a smart hub
Where "smart" means that hardware-address to port maps are dynamically
maintained (learned) by the device. The technique used to learn such
tables consists of noting the source hardware address of each incoming
packet as well as the port where the packet arrived.
> The linux bridge currently switches "outside" segments, it checks to see
> where a MAC address is and sends it to the correct segment.
> But whenever a packet originates FROM the host doing the switching itself,
> it simply uses the protocol's routing (or the programs mechanism), eg
> IProuting, for IP to determine where it needs to go...
The kernel should route the outgoing packet to the virtual interface
that represents the bridge. The bridge driver should use the mac-to-port
table for that bridge to forward the packet. Incoming packets (on either
physical interface) addressed to the bridging host should be put on the
virtual interface's input queue for the appropriate protocol.
Linux's approach to bridging+routing is incorrect. Instead of making two
interfaces visible to the IP layer, the bridge should make ONE (virtual)
interface visible to the IP layer. I say "IP layer" because one might
want to bridge+route some protocols, IP), and/or route some other
protocols (e.g., one might want to bridge NetBEUI on two interfaces, but
treat them as separate segments for IP). But the kernel need not provide
such a complex bridge some/route some interface; one could settle for a
bridge all or none approach.
> >
> > > What they should do now is check the destination mac addr and transmit it
> > > onto the correct device or both...
> >
> > This is what bridges/switches are supposed to do. If the Linux bridging
> > software does not, it's a bug.
> No bridges simply paste one segment to the other they are "dumb" and
> switches are "smart"... Linux only doesn't do the internal->outside
> correctly, this should be implemented with the virtual interface like Ted
> mentioned in the mails before...
See above.
> >
> > Cheers,
> > Mick
> >
> > The Reverend Jasper P. O'Malley dotdot:[EMAIL PROTECTED]
> > Systems Administrator ringring:asktheadmiral
> > Webnology, LLC woowoo:http://www.webnology.com/~jooji
> >
>
> Greets,
> Jeroen
>
Nico
--
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
------------------------------------------------------------------------------
To unsubscribe from this list, please visit http://www.fugue.com/dhcp/lists
If you are without web access, or if you are having trouble with the web page,
please send mail to [EMAIL PROTECTED] Please try to use the web
page first - it will take a long time for your request to be processed by hand.
Archives for this mailing list are available at
http://www.webnology.com/list-archives/dhcp/dhcp-server
------------------------------------------------------------------------------
