Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge

On Mon, Mar 12, 2007 at 09:36:43AM +0000, Bruce M. Simpson
wrote:
> Hi,
> 
> Eygene Ryabinkin wrote:
> >
> >Speaking about vlan problems: the original problem
is to do something
> >with VLAN interfaces only because they are sharing
the MAC of their
> >physical parent. The problem itself is not
VLAN-specific -- if there
> >will be two physical interfaces with the same MACs
and they will be
> >bridged, the problem will still be here.
> >  
> I see this also.
> 
> What would be good is if there was a way to record
additional MAC 
> addresses for each ifnet, in addition to the if_lladdr
member. This 
> would cut down the cruft in ether_input(), if_bridge(4)
and possibly 
> also carp(4).
> 
> For network cards with more than one perfect hash
filter entry in the 
> hardware, programming these into the card would
*perhaps* be more 
> efficient when trying to achieve line rate with gigabit
and beyond.
> 
> This would most likely require an ABI change. The VLAN
handling problem 
> doesn't go away; we will still need to check if a
bridge member is a 
> VLAN interface because we can't uniquely key off the
MAC as you point out.

Guys, excuse me, but I still fail to see how the case of
VLANs'
sharing a single MAC differs from the case of several
physical
interfaces with the same MAC from the POV of a bridge.  A
bridge
can have no own MAC addresses at all, it plays with foreign
MAC
addresses only.  Therefore I can't see why our bridge code
needs
to know local MAC addresses, let alone why it fails when
they're
the same.  Could you give me a hint?  Thanks!

-- 
Yar
_______________________________________________
freebsd-netfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscribefreebsd.org"

Yar, good day.

Mon, Mar 12, 2007 at 02:20:56PM +0300, Yar Tikhiy wrote:
> On Mon, Mar 12, 2007 at 09:36:43AM +0000, Bruce M.
Simpson wrote:
> > Eygene Ryabinkin wrote:
> > >
> > >Speaking about vlan problems: the original
problem is to do something
> > >with VLAN interfaces only because they are
sharing the MAC of their
> > >physical parent. The problem itself is not
VLAN-specific -- if there
> > >will be two physical interfaces with the same
MACs and they will be
> > >bridged, the problem will still be here.
> > >  
> > I see this also.
> > 
> > What would be good is if there was a way to record
additional MAC 
> > addresses for each ifnet, in addition to the
if_lladdr member. This 
> > would cut down the cruft in ether_input(),
if_bridge(4) and possibly 
> > also carp(4).
> > 
> > For network cards with more than one perfect hash
filter entry in the 
> > hardware, programming these into the card would
*perhaps* be more 
> > efficient when trying to achieve line rate with
gigabit and beyond.
> > 
> > This would most likely require an ABI change. The
VLAN handling problem 
> > doesn't go away; we will still need to check if a
bridge member is a 
> > VLAN interface because we can't uniquely key off
the MAC as you point out.
> 
> Guys, excuse me, but I still fail to see how the case
of VLANs'
> sharing a single MAC differs from the case of several
physical
> interfaces with the same MAC from the POV of a bridge.

It does not differ at all, you're right. VLAN case is just
an
illustration for the problem, but the problem itself is not
limited
to a VLAN interfaces.

> A bridge can have no own MAC addresses at all, it plays
with foreign MAC
> addresses only.  Therefore I can't see why our bridge
code needs
> to know local MAC addresses, let alone why it fails
when they're
> the same.  Could you give me a hint?  Thanks!

This is a different point. The bridge wants to know about
bridge
members MACs just because it should catch the packets that
are
destined to the bridge members. It is the only way for an L2
thing
that is operating in the promiscious mode.

For our case (when MACs are the same): I think that rik has
explained
it rather good, so you should read his message once again.
Perhaps,
we can talk about this off-list and in Russian, if you
prefer.
-- 
Eygene
_______________________________________________
freebsd-netfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscribefreebsd.org"

Yar Tikhiy wrote:
> Guys, excuse me, but I still fail to see how the case
of VLANs'
> sharing a single MAC differs from the case of several
physical
> interfaces with the same MAC from the POV of a bridge. 
A bridge
> can have no own MAC addresses at all, it plays with
foreign MAC
> addresses only.  Therefore I can't see why our bridge
code needs
> to know local MAC addresses, let alone why it fails
when they're
> the same.  Could you give me a hint?  Thanks!
>   

A few points:

1. A bridge *does* have a MAC address; it is automatically
assigned one 
to participate in IEEE 802.1d Spanning Tree.

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.

Regards,
BMS
_______________________________________________
freebsd-netfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscribefreebsd.org"

Julian, good day.

> >+.Pp
> >+The packets destined to the bridging host will be
seen by the filter
> >+on the interface with the MAC address equal to the
packet's destination
> >+MAC. Be prepated to the situation when some of the
bridge members are sharing
> 
> prepated to ?
> prepared for? ???

You're right, thanks for spotting the error. The corrected
patch
is attached.
-- 
Eygene

_______________________________________________
freebsd-netfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscribefreebsd.org"