Linux as "dumb" Ethernet packet repeater

My boss is trying to find a way to eliminate Ethernet switches from an
embedded system network, and his idea is this: Given a Linux computer
with two Ethernet devices, he thinks it should be a simple matter,
when an Ethernet frame arrives at one eth device, if the destination
MAC is not ours, simply write it out the other eth device. Then you
daisy-chain your Linux devices together, and you can build a switch-
less expandable network. You could do it with IP routing but
configuration would be more manual/painful.

Would this be a daft idea? Ignoring the potential failure modes
(which are serious and will probably doom the idea) my argument is
that no such handy Ethernet-frame-repeater-driver exists, so we'd have
to code it up. We really don't want to dive into Linux drivers.

Hello,

Richard Krehbiel a écrit :
> My boss is trying to find a way to eliminate Ethernet switches from an
> embedded system network, and his idea is this: Given a Linux computer
> with two Ethernet devices, he thinks it should be a simple matter,
> when an Ethernet frame arrives at one eth device, if the destination
> MAC is not ours, simply write it out the other eth device. Then you
> daisy-chain your Linux devices together, and you can build a switch-
> less expandable network.
>
> Would this be a daft idea?

Yes, it is a totally crazy idea.

> Ignoring the potential failure modes
> (which are serious and will probably doom the idea)

You cannot ignore them.

> my argument is
> that no such handy Ethernet-frame-repeater-driver exists

It does exist in the kernel : it is the bridge function, which is
controlled by brctl from the bridge-utils package. It acts as a software
ethernet switch and even supports the spanning tree protocol.
<http://linuxfoundation.org/en/Net:Bridge>

Richard Krehbiel wrote:

> My boss is trying to find a way to eliminate Ethernet switches from an
> embedded system network, and his idea is this: Given a Linux computer
> with two Ethernet devices, he thinks it should be a simple matter,
> when an Ethernet frame arrives at one eth device, if the destination
> MAC is not ours, simply write it out the other eth device. Then you
> daisy-chain your Linux devices together, and you can build a switch-
> less expandable network. You could do it with IP routing but
> configuration would be more manual/painful.
>
> Would this be a daft idea? Ignoring the potential failure modes
> (which are serious and will probably doom the idea) my argument is
> that no such handy Ethernet-frame-repeater-driver exists, so we'd have
> to code it up. We really don't want to dive into Linux drivers.

It would be a bit daft;

1) generally switches are more reliable than PC hardware.
2) Each machine has to do more work, once you have more than a couple of
boxes you'll be creating a bit of overhead on each box.
3) reliability: if one box goes out, there's a rick that you'll segment your
network.

Having said that, you can easily do it with linux bridging. Install the
bridge software, create a bridge virtual interface (br0) bridge the ethernet
cards & the bridge virtual interface. Let linux worry about the forwarding
for you.

Bruce

Bruce Cook <bruce-(E-Mail Removed)> wrote:
> It would be a bit daft;

> 1) generally switches are more reliable than PC hardware.

Agreed.

> 2) Each machine has to do more work, once you have more than a
> couple of boxes you'll be creating a bit of overhead on each box.

Especially the boxes in the "middle" of this chain, or the root of the
spanning tree if they are physically connected in a ring. If we
ass-u-me that each box is talking to every other box evenly, the ones
in the middle will probably end-up spending a _lot_ of time forwarding
traffic in which they have no interest.

> 3) reliability: if one box goes out, there's a rick that you'll
> segment your network.

> Having said that, you can easily do it with linux bridging. Install
> the bridge software, create a bridge virtual interface (br0) bridge
> the ethernet cards & the bridge virtual interface. Let linux worry
> about the forwarding for you.

I guess if you use the two ports to connect the systems in a
circle/ring then spanning tree etc might allow recovery from a single
system failure.

Still, given a box with two ports, my preference would be to buy _two_
switches, interconnect them, and connect one port of each system to
each switch.

rick jones
--
The computing industry isn't as much a game of "Follow The Leader" as
it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose."
- Rick Jones
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

David Brown a écrit :
> bridging in the kernel is easy. You also gain the flexibility to
> control the traffic if you want - either use normal routing rather than
> bridging (and then standard iptables firewalling), or use bridging and
> brtables.

ebtables.
Bridged ARP, IPv4 and IPv6 packets can also be filtered with arptables,
iptables and ip6tables respectively if "netfilter bridge" (bridge-nf) is
enabled in the kernel.

On Feb 10, 10:29*am, David Brown
<david.br...@hesbynett.removethisbit.no> wrote:

> Ethernet switches are also much faster. *They usually have
> "fast-forwarding" of packets - as soon as the destination address is
> known and the destination Ethernet port is established, they start
> forwarding the packet. *Bridging with the Linux kernel will (as far as I
> know) have to wait until the entire packet is received, then start
> forwarding it.

Actually, cut-through switching is pretty much obsolete. The vast
majority of modern switches are purely store-and-forward devices.
Still, an Ethernet switch will probably be at least a little faster
than a PC because the switch has dedicated hardware and the PC has to
process an interrupt and use software tables.

DS

David Schwartz wrote:
> On Feb 10, 10:29 am, David Brown
> <david.br...@hesbynett.removethisbit.no> wrote:
>
>> Ethernet switches are also much faster. They usually have
>> "fast-forwarding" of packets - as soon as the destination address is
>> known and the destination Ethernet port is established, they start
>> forwarding the packet. Bridging with the Linux kernel will (as far as I
>> know) have to wait until the entire packet is received, then start
>> forwarding it.
>
> Actually, cut-through switching is pretty much obsolete. The vast
> majority of modern switches are purely store-and-forward devices.
> Still, an Ethernet switch will probably be at least a little faster
> than a PC because the switch has dedicated hardware and the PC has to
> process an interrupt and use software tables.
>

It looks like I learned something here - a bit of research shows that
store-and-forward is used on all but the most high-end Gb switches for
HPC, where the latency for Gb jumbo frames is more relevant.

Richard Krehbiel <(E-Mail Removed)> wrote:
> when an Ethernet frame arrives at one eth device, if the destination
> MAC is not ours, simply write it out the other eth device.

Remember that the MAC address would now be that of the intermediate box.
How would you handle dhcp, arp, rarp, bootp and other initialization or
other such MAC address based traffic between hosts either side of the
repeater?

--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/

Maxwell Lol wrote:
> (E-Mail Removed) (Mark Hobley) writes:
>
>> Richard Krehbiel <(E-Mail Removed)> wrote:
>>> when an Ethernet frame arrives at one eth device, if the destination
>>> MAC is not ours, simply write it out the other eth device.
>> Remember that the MAC address would now be that of the intermediate box.
>> How would you handle dhcp, arp, rarp, bootp and other initialization or
>> other such MAC address based traffic between hosts either side of the
>> repeater?
>
> Well, if you configure the linux box to be a bridge, it should work.
>
> But then again - how do you plan to manage them if they are not
> addressable.


A Linux bridge solves the problem of MAC addresses
by putting the interface receive into promiscuous
mode (which means receiving all frames coming in).

The sender address in a frame is set by the controlling
software - the interface chip does not handle the 14
byte Ethernet header (6 bytes destination MAC, 6 bytes
source MAC and 2 bytes length/payload type) at all.

The same interface can handle traffic destined to the
host it is in, and to hosts on the other side of the
bridge.

--

Tauno Voipio
tauno voipio (at) iki fi