0

I'm thinking of something that would need to emulate an ethernet switch.

We have a proprietary bus connecting a central unit with several "slave units", and I would like to move ethernet packets over this bus, too, as a secondary payload.

I thought about this setup, but I have never done something similar, so I may be completely wrong with my ideas...

I would add a PHY and connectors to our chips in the central and slave units.

When a device attached to a slave unit sends a packet, the slave unit would put it on the bus, sends it to the central unit, which catches the MAC and stores it in a table together with our local bus address, and sends it out through the central units' PHY into the world.

When a packet comes in at the central unit and matches one of the entries in the lookup table, it is put on the bus and rides as a payload to the unit, which would then put out to the units PHY. With a broadcast MAC address, it would be broadcasted to all units on the bus.

So apart from forwarding packets, does the central unit have to to do other jobs, like somehow informing its network partner that is expects packets for different MACs?

Is there any literature (online or offline) which would give some more insights? I tried to google a bit (and I've seen ads for switches that will last a lifetime), but either it's not there or I asked the wrong questions.

Instead of looking up a MAC in the central unit and sending it to a dedicated unit, what if I would just put any incoming packet on our bus as local broadcasts, and let the slave units do the MAC matching?

  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can provide and accept your own answer. – Ron Maupin Feb 19 '18 at 19:14
2

Basically an Ethernet switch does the following.

1. Use the source MAC address of the frame to update it's MAC address table.
2. Look up the destination MAC address of the frame in it's MAC address table.
3a. If there is a match in the table and the egress port is different from the ingress port forward the frame.
3b. If there is a match in the table and the egress port is the same as the ingress port drop the frame.
3c. If there is no match in the table flood the frame to every port EXCEPT the one it was received on.

If you ignore steps 1 through 3b of that list and only do step 3c you will have something that is functionally similar to an Ethernet HUB.

Basic switches don't inform each other of anything, they each independently build a table of which direction each MAC address is in. Some more advanced switches do communicate with each other for things like spanning tree protocol but you can ignore that for now.

What you must not do is send a frame back out the way it came in. With your network arrangement that means you need to record which node a frame entered through so that you can filter out echos on exit.

| improve this answer | |
  • 3a is simple. 3b would imply a unit has received a frame with matching source and destination address, so this could already be killed in the unit itself, no need to waste bus capacity for a packet that would have to be binned at the other end. 3c This is a tricky one, but I could broadcast it on the bus and filter it in the unit (i.e. if source matches local MAC, then don't export to port). Am I right that this would apply to broadcast destination packets, too? – Treczoks Sep 22 '17 at 6:25
2

In a nutshell, an Ethernet switch forwards frames based on their destination MAC address. For that it learns source addresses and associated ports. It also drops damaged frames that fail FCS. For this basic functionality, switches don't exchange information on their own, they just forward frames. Each one does its job independently.

Managed switches usually can do a lot more - they have a variety of additional functions (spanning tree, VLANs, ACLs, L3 switching/routing, ...).

| improve this answer | |
  • OK, thanks. I have to look up this FCS thing - am I right that this is some kind of checksum? – Treczoks Sep 22 '17 at 6:18
  • Yes, it's a CRC32 checksum. – Zac67 Sep 22 '17 at 6:19
2

Instead of looking up a MAC in the central unit and sending it to a dedicated unit, what if I would just put any incoming packet on our bus as local broadcasts, and let the slave units do the MAC matching?

What you're describing is functionally equivalent to an Ethernet hub

| improve this answer | |
  • No, as he describes it it's functionally broken because there is nothing to stop frames being sent back the way they came. – Peter Green Sep 21 '17 at 0:09
  • I disagree. He's describing an Ethernet bus, which a hub replicates. – Ron Trunk Sep 21 '17 at 3:43
  • No, this is not the way I plan to take. Yes, of course, matching in the units would be easier, but it would also mean that I would have to put unrelated packets on the bus, wasting capacities that could be used for other things. So a central filtering and forwarding mechanism in the central unit is a must. – Treczoks Sep 22 '17 at 6:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.