interfaces on network switch

Hello

As I understand typically the Layer2 switch may have one MAC address shared
by its every port (MAC address isn't necessary for frames forwarding, but is
for management functions). I would like to understand, how does the kernel
treat multiport switches - it it viewed as one single NIC, or every port is
a NIC for the kernel?

I believe it depends on a device driver's design - if so then what is the
right way to design the driver? And making it more complicated - how does
the OS view multiple VLANs, each of them may have its own IP address. Will
it be a single interface for OS?

Thanks for any valuable comments.

--
Mark

Mark <(E-Mail Removed)> wrote:
> As I understand typically the Layer2 switch may have one MAC address shared
> by its every port (MAC address isn't necessary for frames forwarding, but is
> for management functions). I would like to understand, how does the kernel
> treat multiport switches - it it viewed as one single NIC, or every port is
> a NIC for the kernel?

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.

> I believe it depends on a device driver's design - if so then what is the
> right way to design the driver? And making it more complicated - how does
> the OS view multiple VLANs, each of them may have its own IP address. Will
> it be a single interface for OS?

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
(E-Mail Removed) 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 :
> Mark <(E-Mail Removed)> wrote:
>> As I understand typically the Layer2 switch may have one MAC address shared
>> by its every port (MAC address isn't necessary for frames forwarding, but is
>> for management functions). I would like to understand, how does the kernel
>> treat multiport switches - it it viewed as one single NIC, or every port is
>> a NIC for the kernel?

What kind of switch are you talking about ? Hardware switch ? Linux
bridge created with brctl ? Virtual bridge such as VDE (virtual
distributed 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.

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.

Pascal Hambourg <boite-a-(E-Mail Removed)> wrote:
> Philip Paeps a écrit :
>> Mark <(E-Mail Removed)> wrote:
>>> As I understand typically the Layer2 switch may have one MAC address shared
>>> by its every port (MAC address isn't necessary for frames forwarding, but is
>>> for management functions). I would like to understand, how does the kernel
>>> treat multiport switches - it it viewed as one single NIC, or every port is
>>> a NIC for the kernel?
>
> What kind of switch are you talking about ? Hardware switch ? Linux
> bridge created with brctl ? Virtual bridge such as VDE (virtual
> distributed 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.
>
> 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:

http://www.freebsd.org/cgi/cvsweb.cg...ge.c?rev=1.113
http://www.freebsd.org/cgi/cvsweb.cg...1.112;r2=1.113



--
Philip Paeps Please don't email any replies
(E-Mail Removed) I follow the newsgroup.

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

Philip Paeps a écrit :
> Pascal Hambourg <boite-a-(E-Mail Removed)> wrote:
>>
>> 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 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.

Pascal Hambourg <boite-a-(E-Mail Removed)> wrote:
> Philip Paeps a écrit :
>> Pascal Hambourg <boite-a-(E-Mail Removed)> wrote:
>>>
>>> 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 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
(E-Mail Removed) 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

"Pascal Hambourg" <boite-a-(E-Mail Removed)> wrote in message
news:hflbno$kok$(E-Mail Removed)...
>> Mark <(E-Mail Removed)> wrote:
>>> As I understand typically the Layer2 switch may have one MAC address
>>> shared
>>> by its every port (MAC address isn't necessary for frames forwarding,
>>> but is
>>> for management functions). I would like to understand, how does the
>>> kernel
>>> treat multiport switches - it it viewed as one single NIC, or every port
>>> is
>>> a NIC for the kernel?
>
> What kind of switch are you talking about ? Hardware switch ? Linux
> bridge created with brctl ? Virtual bridge such as VDE (virtual
> distributed switch) ?

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

--
Mark

On 2009-12-09, Mark <(E-Mail Removed)> wrote:
>
> "Pascal Hambourg" <boite-a-(E-Mail Removed)> wrote in message
> news:hflbno$kok$(E-Mail Removed)...
>>> Mark <(E-Mail Removed)> wrote:

>>>> As I understand typically the Layer2 switch may have one MAC
>>>> address shared by its every port (MAC address isn't necessary
>>>> for frames forwarding, but is for management functions). I
>>>> would like to understand, how does the kernel treat multiport
>>>> switches - it it viewed as one single NIC, or every port is a
>>>> NIC for the kernel?
>>
>> What kind of switch are you talking about ? Hardware switch ? Linux
>> bridge created with brctl ? Virtual bridge such as VDE (virtual
>> distributed switch) ?
>
> In my original post I was talking about a hardware switch.

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

"Grant Edwards" <(E-Mail Removed)> wrote in message
news:hfna18$pat$(E-Mail Removed)...
>> In my original post I was talking about a hardware switch.
>
> 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.

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" <(E-Mail Removed)> wrote in
news:hfnboj$rio$(E-Mail Removed):

> "Grant Edwards" <(E-Mail Removed)> wrote in message
> news:hfna18$pat$(E-Mail Removed)...
>>> In my original post I was talking about a hardware switch.
>>
>> 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.
>
> 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).

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