Yar, good day.
> > >>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.
OK, no problem: we can keep the actual incoming interface in
the mbuf.
> > >>>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.
Yes, it is based on the wrong assumptions that were made
about 3-4
years ago in the NetBSD. And the real problem here is if we
want to
leave the current behaviour of locally destined packets or
we want
completely different thing. We asked in the list if someone
uses the
current behaviour, but no replies were received yet.
> > >>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.
Sure. And that is why all switches that can bear the IP on
their
interfaces have distinct MACs for each interface or/and the
only
one interface can have the IP. And that is why I am going
to
add the paragraph to the if_bridge(4) describing the current
situation
and giving advice on the setting IP for the bridge members
and the
bridge itself. Will provide the patch in a day or two.
> > >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.
>
> See bms_netdev, it's rather promising: with it, we
won't have to do
> duplicate checks for the destination MAC address.
Namely see lines
> 642-682 of
//depot/user/bms/netdev/sys/net/if_ethersubr.c#9.
> The things may need some moving around, but all code is
already there.
> Then the bridge_input code will be able to make use of
M_PROMISC to
> see if it must consume the packet or just update its
forwarding table.
I tried to understand this, because Bruce already gave me a
patch,
but I am a bit stupid: I do not see how M_PROMISC that is
cleared
unconditionally before BRIDGE_INPUT will help us to identify
the
right interface. As I see now, the BRIDGE_INPUT is called
once from
if_ethersubr.c, once from if_gif.c and once from
ng_ether.c:
http:/
/fxr.watson.org/fxr/ident?i=BRIDGE_INPUT
So there is no distinct code paths that can allow
BRIDGE_INPUT to
modify its behaviour based on the M_PROMISC flag.
But I feel that I am wrong in some place and missing some
discuission
on the M_PROMISC. Can anyone point me to the right place?
> So all the tangled if()s inside LIST_FOREACH() will be
gone completely
> from bridge_input().
But we still need to see if we want to consume the packet by
the
bridge or it members or to do forwarding. Am I missing
something?
> > >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.
I agree with you. That is why I patched if_bridge once again
to enable
the pfil hooks for the "physical" incoming
interface. And there are
two ways to solve the problem:
- to give each VLAN interface the distinct MAC, as Bruce
suggested,
- to refuse the "logical" interfaces completely
and to support only
"physical" ones. It is what my very first (and
very short) patch
did. But this can break some existing firewall rulesets. And
that
should be discuissed -- we do not need the total breakage
due to
out changes. And you're right: the best way for this
alternative is to
leave the current behaviour as the compatibility sysctl that
is turned
off by default and move to the filtering on the
"physical" interfaces
by default. No problem, but skilled network people that are
using
FreeBSD as the bridge for VLANs should say if they are happy
with it.
--
Eygene
_______________________________________________
freebsd-net freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscribefreebsd.org"
|
I pointed
out that the code matches on
destination MAC only at the moment.
vlan(4) is an abstraction of something which exists as part
of the
Ethernet framing, and is not a physical interface in its own
right, as
was correctly identified above.
> - to refuse the "logical" interfaces
completely and to support only
> "physical" ones. It is what my very first
(and very short) patch
> did. But this can break some existing firewall
rulesets. And that
> should be discuissed -- we do not need the total
breakage due to
> out changes. And you're right: the best way for this
alternative is to
> leave the current behaviour as the compatibility sysctl
that is turned
> off by default and move to the filtering on the
"physical" interfaces
> by default. No problem, but skilled network people that
are using
> FreeBSD as the bridge for VLANs should say if they are
happy with it.
>
I think it is acceptable for if_bridge(4) to know about the
existence of
VLAN interfaces and to deal with them accordingly as a
special case,
because Spanning Tree is specified differently in the case
where VLANs
are present. Therefore it is not unreasonable for
if_bridge(4) to be
looking at VLAN headers in the mbuf chain.
As such I think the behaviour Andrew Thompson and I were
discussing off
list should be made the default: that is, the first 802.1q
VLAN header
is stripped off and turned into an M_VLANTAG before being
passed to
other consumers in the stack.
The presence of M_VLANTAG makes it very easy to see that a
frame was
received with a VLAN header without involving vlan(4) and
reduces the
amount of 802.1q specific code across Layer 2 subsystems.
Regards,
BMS
_______________________________________________
freebsd-net