headers
David Miller | 4 Jun 2008 01:00
Favicon

Re: [2.6 patch] bridge: update URL

From: Adrian Bunk <bunk <at> kernel.org>
Date: Tue, 20 May 2008 01:08:34 +0300

> This patch updates the URL of the bridge homepage.
> 
> Signed-off-by: Adrian Bunk <bunk <at> kernel.org>

Applied, thanks Adrian.
Permalink | Reply | 0 comments |
headers
yordanos beyene | 5 Jun 2008 00:00
Picon

linux bridging to forward traffic from physical to virtual interface of my linux box

Hi all,

I am new to Linux Bridge, and need some help.
I am trying to use Linux bridge (brctl) and ebtables to forward
incoming frames from my local interface into a set of virtual
interfaces in my linux box. I believe "ebtables" can be used to
selectively forward packets to virtual interfaces- for instance, based
on the source mac address of the frame (or source interface of frame).
I have created virtual interfaces but I am not able to add the virtual
interfaces to the bridge. I can i can only add physical interfaces.

Can any one advice me if Linux bridge works with virtual interfaces?
Let me know if you have any idea on this or other better mechanism.

Thanks.
Jordi
Permalink | Reply | 0 comments |
headers
Faruk Keskin | 5 Jun 2008 22:08
Picon
Picon
Favicon

VLAN-aware bridge : [PATCH] Add vlan id to bridge forward database

Hello everybody, hi Jaime,

I'm mailing to get more information about whether your patch
[PATCH] Add vlan id to bridge forward database
has been accepted so far.
I couldn't find the patched version yet - could you please tell me where I
can get the latest version of the patch or point out a reference to it ?

Has the vlan-aware bridge forwarding already been tested ?

And how about forwarding tagged packets ?
Until now, the bridge always stripped off the tag if present.

I'm currently thinking about extending the sk_buff data structure to
incorporate the vlan tag - to keep the VLAN information present when
exchanging packets from or to the bridge with the 8021q module and also
when a socket is bind to a interface (extending the sockaddr_ll struct in
that case).

Do you think thats's a sane approach ?

Thanks in advance, Faruk
Permalink | Reply | 2 comments |
headers
Stephen Hemminger | 5 Jun 2008 23:29
Favicon

Re: VLAN-aware bridge : [PATCH] Add vlan id to bridge forward database

On Thu, 5 Jun 2008 22:08:03 +0200 (CEST)
"Faruk Keskin" <faruk <at> eit.uni-kl.de> wrote:

> Hello everybody, hi Jaime,
> 
> I'm mailing to get more information about whether your patch
> [PATCH] Add vlan id to bridge forward database
> has been accepted so far.
> I couldn't find the patched version yet - could you please tell me where I
> can get the latest version of the patch or point out a reference to it ?

This only applys to bridge that is blindly bridging without any knowledge
of vlan's. You can already handle the case of bridging selected vlan's
if you tell the kernel about them. 

> Has the vlan-aware bridge forwarding already been tested ?

People do it all the time without patch by configuring the vlan's
first then bridging the vlan's.

> And how about forwarding tagged packets ?
> Until now, the bridge always stripped off the tag if present.

Not if you bridge the vlan's

> I'm currently thinking about extending the sk_buff data structure to
> incorporate the vlan tag - to keep the VLAN information present when
> exchanging packets from or to the bridge with the 8021q module and also
> when a socket is bind to a interface (extending the sockaddr_ll struct in
> that case).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonathan Thibault | 5 Jun 2008 23:46
Favicon

Re: VLAN-aware bridge : [PATCH] Add vlan id to bridge forward database

Greetings Faruk,

I'm not knowledgeable enough to comment on the approach but I am very 
interested in your progress on the matter.  We are currently deploying a 
solution where being able to link different vlans off a trunk would be a 
lifesaver.  It was always problematic, something to do with the bridge 
not forwarding some (but not all) arp replies properly.

Jonathan

Faruk Keskin wrote:
> Hello everybody, hi Jaime,
>
> I'm mailing to get more information about whether your patch
> [PATCH] Add vlan id to bridge forward database
> has been accepted so far.
> I couldn't find the patched version yet - could you please tell me where I
> can get the latest version of the patch or point out a reference to it ?
>
> Has the vlan-aware bridge forwarding already been tested ?
>
> And how about forwarding tagged packets ?
> Until now, the bridge always stripped off the tag if present.
>
> I'm currently thinking about extending the sk_buff data structure to
> incorporate the vlan tag - to keep the VLAN information present when
> exchanging packets from or to the bridge with the 8021q module and also
> when a socket is bind to a interface (extending the sockaddr_ll struct in
> that case).
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Faruk Keskin | 6 Jun 2008 01:47
Picon
Picon
Favicon

Re: VLAN-aware bridge : [PATCH] Add vlan id to bridge forward database

Hi all, hi Stephen,

seems like you've been discussing this issue fairly enough.

However, when you're saying selected vlan's this only works if you have an
exclusive bridge for each vlan.

Unless, the inter-vlan bridging is possible  with the current bridging
implementation (same mac address might also a problem). My understanding
is without a vlan aware fdb you'll need multiple bridges to have vlan
specific separate bridging domains enforced by the network topology. 
Having a single bridge is desirable because it will simplify dynamic VLAN 
management and ease up dynamic configuration, I would suppose.

Yes, the tag gets stripped off when a non-vlan device is forwarded to,
you're right. However, do I want non-vlan devices to get any vlan specific
data as such ? Again, I must properly configure the topology of the
bridges.

By topology I mean which devices (ethX, ethY.Z, ..) are attached to the
different bridges.

And yes, the extension I mentioned will be used to do some type of sniffing:
an userspace network management tool should among other stuff control the
VLAN configuration over a webinterface. With multiple bridges, the
sniffing  will also need some more attention as the might be added and
removed on runtime.

Anyway, thanks you Stephen for the reply.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Faruk Keskin | 11 Jun 2008 06:09
Picon
Picon
Favicon

Re: How to determine where bridged packets originally come from ?

> Hi all,
>
> I ended up using raw packet sockets (ETH_P_ALL) with BPF filters attached
> (binded on the bridge interface) to capture packets for the userspace
> host.
>
> Now having captured these packets from the bridge interface, how do I know
> which interface (eth0, wifi0, ..) the packets were send from originally ?
>
> Is there a handy solution to this without modifying the packet content ?
>
> Please help me out I you got the answer down pat.
>
> BR, Faruk
>

Hi all, there's been a patch which introduced a new option for packet
sockets returning the original device which was eventually bonded. It's
called ORIGDEV.

BR, Faruk
Permalink | Reply | 0 comments |
headers
Dietmar Maurer | 11 Jun 2008 10:27

Bridge MAC selection

Hi all,

We provid a management plattform for virtual machines (pve.proxmox.com),
and 
use a bridge access the network.

Currently the system choose the lowest MAC for the purposes of STP 
and also assigns this MAC to the bridge. This is a problem because the 
Bridge MAC changes when we start/stop virtual machines - leading to 
Network outage for several seconds.

Using the first (insteasd of lowest) MAC would avoid the problem. So are

There any side effects with the following patch?

--- br_stp_if.c.org     2008-06-11 09:15:16.000000000 +0200
+++ br_stp_if.c 2008-06-11 09:44:53.000000000 +0200
 <at>  <at>  -217,10 +217,7  <at>  <at> 
        struct net_bridge_port *p;

        list_for_each_entry(p, &br->port_list, list) {
-               if (addr == br_mac_zero ||
-                   memcmp(p->dev->dev_addr, addr, ETH_ALEN) < 0)
-                       addr = p->dev->dev_addr;
-
+               addr = p->dev->dev_addr;
        }

        if (compare_ether_addr(br->bridge_id.addr, addr))
(Continue reading)

Permalink | Reply | 6 comments |
headers
Stephen Hemminger | 11 Jun 2008 17:58
Favicon

Re: Bridge MAC selection

On Wed, 11 Jun 2008 10:27:54 +0200
"Dietmar Maurer" <dietmar <at> proxmox.com> wrote:

> Hi all,
> 
> We provid a management plattform for virtual machines (pve.proxmox.com),
> and 
> use a bridge access the network.
> 
> Currently the system choose the lowest MAC for the purposes of STP 
> and also assigns this MAC to the bridge. This is a problem because the 
> Bridge MAC changes when we start/stop virtual machines - leading to 
> Network outage for several seconds.
> 
> Using the first (insteasd of lowest) MAC would avoid the problem. So are
> 
> There any side effects with the following patch?

Not for you. But if it got changed now, it would surprise the existing
users (change in ABI behaviour).  

So if you need a particular mac address, you can set it with other tools
(ip or ifconfig).
Permalink | Reply | 5 comments |
headers
Dietmar Maurer | 12 Jun 2008 06:51

Re: Bridge MAC selection

> > There any side effects with the following patch?
> 
> Not for you. But if it got changed now, it would surprise the 
> existing users (change in ABI behaviour).  
> 
> So if you need a particular mac address, you can set it with 
> other tools (ip or ifconfig).

You are right, I can set the Hw address with ifconfig - but 
any 'brctl addif' later resets the address, so that is simply not 
usable.

- Dietmar
Permalink | Reply | 4 comments |

Gmane