interfaces on network switch

It depends on the hardware. Most multiport Ethernet NICs I've seen, have a MAC and a PHY per port. In this case, the kernel creates a network interface device per port (eth0, eth1, eth2, eth3). If you bridge those all together, the bridge will either use a randomly generated MAC address, or the address of the first port you add to the bridge.

In the case where a multiport card has a PHY and a MAC per card, the kernel will see four distinct cards. If the card shares a MAC between all the PHYs, the driver will only see frames addressed to that MAC. The chip may offer a method to push other frames up too, but that depends. In the case of VLANs, if the chip is a bit intelligent, it will handle them in hardware. If not, the kernel will need to provide tagged frames and remove tags itself.

- Philip

--
Philip Paeps                                    Please don't email any replies
philip@paeps.cx                                     I follow the newsgroup.

  hundred-and-one symptoms of being an internet addict:
  21. Your dog has its own home page.

Hello,

Philip Paeps a écrit :

What kind of switch are you talking about ? Hardware switch ? Linux bridge created with brctl ? Virtual bridge such as VDE (virtual distributed switch) ?

Actually the Linux bridge code uses the lowest MAC address of all ports. IMO that sucks, because the bridge adress may change when you add a port.

I thought that has been made configurable. But it turns out misremember. It also turns out that there's an amusing bug in the implementation. :-)

# brctl addbr br0 (MAC is now random) # brctl addif br0 eth0 (MAC is now MAC of eth0) # brctl addif br0 eth1 (MAC is now MAC of eth0) # brctl delif br0 eth0 (MAC is now MAC of eth1) # brctl delif br0 eth1 (MAC is now all zeros)

So indeed: it sucks that the address of the bridge may change, but it doesn't change when you add interfaces (except for the first one). It changes when you remove interfaces though. And it changes in a particularly nasty way when you remove the last interface.

At one point, I modified the FreeBSD kernel to have the bridge take the MAC address of the first interface put into the bridge. My implementation was careful to keep track of the randomly generated address though, so that it could be restored when the last interface was removed from the bridge.[1]

It was quickly discovered that MAC addresses changing in the network made a number of things unpredictable, so I reverted that. It also turned out that some hardware (and device drivers) tried to be clever about certain kinds of frames addressed to (their perception of) their MAC address, which broke ARP on some systems and even multicast in one case.

I don't know why the problems I saw on FreeBSD don't manifest themselves on Linux (or if they do, why this manifestation doesn't cause as many problems). I imagine it's more device driver related than anything, but that's just a guess.

My current feeling is that bridges should keep their MAC addresses for their entire lifetime. Either randomly generated or computed from a physical MAC address belonging to an interface in the machine.

It's been a while since I've played with these things in depth though.

- Philip

[1] If you're interested in the FreeBSD implementation at all:

--
Philip Paeps                                    Please don't email any replies
philip@paeps.cx                                     I follow the newsgroup.

  There is a solution to every problem;
  the only difficulty is finding it.

It does change when the added interface has a lower MAC address. I bet that eth0 has a lower address than eth1, so if you add eth1 first, then the bridge address will change when you add eth0.

You're right. Interesting! I had misinterpreted "lower" originally, as in "lower in the list". This is amusing.

- Philip

--
Philip Paeps                                    Please don't email any replies
philip@paeps.cx                                     I follow the newsgroup.

  Don't mess with me, I've got a laser!
  	-- Peter Linington, to a student who left his phone on in a lecture

In my original post I was talking about a hardware switch.

--
Mark

Typically, hardware switches present to Linux as two bits:

1) They present a network interface that connects to a virtual port on the switch. 2) They present the switch itself, with the ability to configure whatever configurable parameters each port has.

Probably the most common case is small wireless routers with built in switches. They typically have five physical 10/100 ports on the back of the router and one 100Mbps port connected to the CPU. Typically, the only configuration of the switch itself is which VLANs each port can pass and whether they're tagged or untagged. Typically, the network interface from the CPU to the switch is in every VLAN and is configured as sub-interfaces.

DS

Then the question doesn't make any sense. The kernel doesn't "treat it" as anything. The kernel neither knows nor cares of its existence. A switch is not a NIC. The NIC is the Ethernet intrface in the computer. A hardware switch is an external box who's operation is transparent from the viewpoint of the other devices on the network (unless it's doing layer 3 router stuff).

--
Grant

Well, I think it's obvious I was talking about Layer2 switch implemented in ASIC. And many such chips have Linux ported on them (example - Realtek).

--
Mark

"Mark" wrote in news:hfnboj$rio$ snipped-for-privacy@aioe.org:

A "layer 2" switch does not have any MAC addresses. It has ports that are attached to various other devices (routers, hosts, etc.). Those other devices typically have MAC addresses. The switch keeps track of the correspondence between MAC address xyz and port N. This is what a switch does.

If a packet shows up destined for MAC address xyz and the switch doesn't know which port it should go to, it "floods" the packet to all its ports (likewise, if the MAC address is a broadcast MAC address). The switch learns which MAC addresses should go to which ports by watching packets flow through over time and maintaining a table in memory. Once it sees packets coming from port N with a given source MAC address, it then knows that it can route packets *destined to* that MAC address via that port.

Now many modern switches tend to be more than just a 'layer 2' switch. They may also have significant internal configuration, do routing and a host of other things. In this case, they typically have MAC addresses (and IP addresses) themselves. (Otherwise, there is no way to "address" the box in order to configure it.)

GH

Apparently nobody else thought it was obvious. :)

I'm still don't know what you're asking, but I'll take another guess at an answer:

Some switch chips will add tags to incoming packets to indicate which port they came in on. They also support tags in outbound packets which control which port they are sent from. That allows the CPU in the same 'box' as the switch to do things like split the switch up into VLANs and support spanning tree algorithms.

--
Grant Edwards                   grante             Yow! My uncle Murray
                                  at               conquered Egypt in 53 B.C.
                               visi.com            And I can prove it too!!

I th7.12.2 Bridge Ports

The individual MAC Entity associated with each Bridge Port shall have a separate individual MAC Address. This address is used for any MAC procedures required by the particular MAC. ...

It's true that the bridge does not need a MAC to _forward frames_, but unique addresses must be provided to allow some low-level protocols to function properly, for instance Full-duplex PAUSE, link aggregation control protocol and such.

And I was not asking about the principles of the switch operations. I would like to undestand what a switch's device driver looks alike from the point of view of the kernel. Therefore was my analogy with computer's network card, which is a one port device (consider the simpliest case). I'm familiar with the way network drivers are implemented in Linux, but not enough to understand how the switch, being a more complex hardware, is treated by the kernel.

I hope at this time I have made my question clear :-)

--
Mark

It looks reasonable: one MAC -> one interface exposed to the user. Should the same apply to VLANs, i.e. should every distinct VLAN be represented with a single interface?

--
Mark

Ok, let's consider a simple example - 4-port switch with a MAC per each port. One port will connect a control CPU running all the software, 3 ports remain for LAN. Consider that the switch is memory mapped, so we might want to:

1) grab the memory region with request_mem_region() 2) fill in the fields of 'net_device' instance, including open/close interface hooks, interrupt handler 3) register IRQ handlers with request_irq() etc.

Somewhere deep in the kernel this new network device will be registered. So will it be done for every port, and upon calling 'ifconfig -a' we will have

3(4?) interfaces listed ?

--
Mark

... and spanning tree