Yar Tikhiy wrote:
On Mon, Mar 12, 2007 at 05:38:11PM +0300, Eygene Ryabinkin wrote:
Yar,
2. In the case where 802.3ad trunking is implemented, the same Ethernet
address may be used by multiple physical interfaces.
3. As Eygene explained well: there are a number of consumers of
Ethernet frames in the stack. As if_bridge may potentially be passed
mbuf chains containing packets for these consumers first, it must
examine the destination address to determine if it should claim the
packet or not.
Finally, because of the above points, the Ethernet destination address
cannot be regarded as a unique key in the bridge code, or indeed the
general Ethernet path, for where packets should be relayed in the stack
as a whole.
But why are we relying solely on the Ethernet destination address?
Probably because if_bridge is written for Ethernet, 802.11 and
may be some other 802 interfaces:
-----
DESCRIPTION
The if_bridge driver creates a logical link between two or more IEEE 802
networks that use the same (or ``similar enough'') framing format. For
example, it is possible to bridge Ethernet and 802.11 networks together,
but it is not possible to bridge Ethernet and Token Ring together.
-----
The IEEE standards don't prevent us from keeping the pointer to the
receive interface and using it to identify the interface unambiguously.
That's what I meant.
Each frame was received via a particular interface, which is recorded
in mbuf's recvif. As the frame moves between levels of abstraction,
such as a physical interface, vlan, bridge, recvif can change, but
at each level the pointer to an entity in the previous level should
be enough, shouldn't it?
Excuse me, but are we talking about the problem that is cured by
our patch, or about some general points? If about the former, then
this problem shows up only for the packet that is destined for the
local interface at the L2. And the pfil gots the wrong interface name
due to the bug.
A patch is unlikely to be correct if it's based on wrong assumptions.
Read my "very long email" again. The model used by the bridge to deliver the
packet for our host is not wrong.
E.g., if several vlan interfaces are
bridged, if_bridge shouldn't need to know which physical interfaces
are used by the vlans. OTOH, it can know which particular vlan the
frame came through, although vlan MACs can be the same.
And who is saying that if_bridge should need to know about the
underlying (parent) interface for the VLAN? The word 'physical' that
we use here denotes the VLAN interface in which the packet showed up
at ether_input. And the word 'logical' means the interface that
the L2 packet is destined for. Perhaps it is the source of confusion?
Quite likely. Even pfil is confused. ;^) As I've managed to figure
out finally, the "physical" interface (in this discussion) is the
interface the L2 packet actually came from, and the "logical" one
just bears the MAC address equal to that in the destination field
of the packet.
The problem is that we cannot determine the "logical" interface
reliably in the presence of interfaces sharing the same MAC address.
No hacks can help us with that.
Assume that a host has two physical interfaces, say, em0 and em1,
with different MAC addresses. We set up a few vlans on the former
and a few vlans on the latter, and then bridge all vlans together.
Now an Ethernet packet comes via, say, em0.7, with its destination
MAC address equal to that of em1 (and its vlans). Which of em1.*
vlans would you "logically" assign the packet to, and why?
This problem was described in my "very long e-mail". And yes it can not be
fixed. Only if we will try to assign the packet to every interfaces in
bridge
with the same MAC, until the rules for the one allow this packet. This
is too
heavy solution. But if we can't fix the all sides of this problem it
doesn't mean
we shouldn't try to fix one that possible.
rik
I'm afraid there is a serious flaw in the very notion of such a
"logical" interface. If it's true, we should start by admitting
that the support for "logical" interfaces should be a side hack for
compatibility, and not something that can live forever on the main
code path.
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
