headers
Courtney | 2 Jul 2006 00:52
Picon

[KJ] is it me you looking for?

Hi,
Hopaea I am not writing to wrong address. I am anice, pretty looking
girl. I am planning on visiting your town thisa bmonth. Can 
we meet each other in person? Message me back at rl <at> snail4mail.com
Permalink | Reply | 0 comments |
headers
Bernd Kischnick | 4 Jul 2006 17:48
Picon

[BUG/PATCH/RFC] bridge: locally generated broadcast traffic may block sender

Hello Stephen,

I may have tracked down some unexpected behaviour from a common bridge
setup, and would like to incite expert oppinion on my observations.
The issue relates to both 2.6 and 2.4 kernel series bridging code,
and as far as I can see might have been present in all releases hitherto.

Consider this setup:
- two ethernet devices in a simple bridge configuration
- bridge-interface configured for IPv4
- local application multicasting heavy UDP traffic down the bridge
- one of the ethernet links goes down (=> disconnect cable).

I would expect that IP-multicast/Ethernet-broadcast traffic is simply sent
out of all the bridged interfaces still available and link-up.

Instead we observe that the result --- rather surprisingly --- depends on
WHICH of the ethernet links is down.

One of the two ports doesn't cause troubles: the traffic flows out from
that port which stays up, and the application doesn't mind.

But if you disconnect the OTHER link, then SOME traffic is still sent out of
the port that stays up, but then the sending application is blocked in the
sendto() call. Consequentially, the network traffic then ceases, even
though one of the interfaces is still up and available.
When the link comes up again, everything continues as normal.

You can create a testbed like this:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephen Hemminger | 7 Jul 2006 20:46
X-Face

Re: bridge+filter+failover+rules&state sync+traffic shaping

On Tue, 27 Jun 2006 16:11:01 +0200
Tristan DEFERT <tristan.d <at> alphamosa.fr> wrote:

> hi list!
> i'm trying to find a convenient way to build a redundant filtering
> bridge under linux
> 
> i looked at carp project, but carp doesn't support bridge
> 
> now i thing the most appropriate way is using stp or rstp
> it seems that 2.6 kernel supports stp but what about rstp?

The 2.6.18 kernel has hooks to allow building STP protocols in user land.
There is a student working on RSTP as a Google Summer of Code project.
Permalink | Reply | 3 comments |
headers
Stephen Hemminger | 7 Jul 2006 20:49
X-Face

Re: Network seperation and ethernet bridge...

On Thu, 22 Jun 2006 16:06:39 +0200
Etienne Pretorius <etiennep <at> kingsley.co.za> wrote:

> Hello all,
> 
> I would like to know if it is possible to have 2 bridge instances 
> running - one for the internal network and the other for the external 
> network.

Yes, you can have two separate bridge instances in the system.

> What I need to explain is that I need the internal bridge to go though 
> the Linux Kernel and pass its packets to the external network bridge.
> I am also hopeful that the internal network bridge will not need an IP 
> address as I am hoping to allocate the internal network clients a gateway
> address beyond the external network bridge and so when I have 2 similar 
> machines running with both internal and external network bridges
> that when one machine dies completely then the other will take over. 
> Sooooo what I need to know is will I require proxy-arp and/or ip_forwarding?
> 
> 
> [internal NW] ---> [internal bridge port 1 of  2]----[external bridge 
> port 4 of 4] --->[GW router]----> www.google.com

No, you can't bridge a bridge.
This is done to prevent creating loops and causing deep stack nesting.

> I would like to make it so that no request can obviously enter the 
> internal network via the external bridge without having been requested 
> from the
(Continue reading)

Permalink | Reply | 5 comments |
headers
Stephen Hemminger | 7 Jul 2006 20:53
X-Face

Re: Performance problems on vlan bridge

On Thu, 22 Jun 2006 21:09:01 -0500
Ethan Sommer <sommere <at> gac.edu> wrote:

> We have been having some performance problems with our linux bridge. I 
> have no idea where to look to start diagnosing the problem, so I'll 
> explain what we've done and hope that you might tell me where to start 
> looking. Almost everything appears to work fine, but when I try to 
> stream music using WMP or mp3 streaming, I can only stream about 30 
> seconds before it cuts out. I used to be able to stream for hours.
> 
> 
> We used to have a firewall which seperated our wireless network from the 
> rest of the network. It is a dual 2.8ghz xeon with two Intel GB network 
> cards. It used to have two interfaces, eth0 which was the default 
> gateway and eth1 which was the wireless subnet.
> 
> 
> The Problem:
> We had a large amount of broadcast traffic on the network (often about 
> 1Mpbs), and occasionally would have network storms where we would have 
> 50-60Mbps of broadcast traffic (clearly not desirable for a network 
> specifically for wireless clients.) We considered subnetting the 
> network, but we'd like to allow people to register once with our 
> wireless network and be able to roam anywhere we have wireless APs.
> 
> Our solution (well, if we can get it to work):
> 
> One day I had an epiphany: we could use a linux bridge and use iptables 
> to block unwanted broadcast packets from going between buildings.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Shankar_Natarajan | 7 Jul 2006 22:36

Re: bridge+filter+failover+rules&state sync+traffic shaping


> -----Original Message-----
> From: bridge-bounces <at> lists.osdl.org
[mailto:bridge-bounces <at> lists.osdl.org]
> On Behalf Of Stephen Hemminger
> Sent: Friday, July 07, 2006 11:46 AM
> To: Tristan DEFERT
> Cc: bridge <at> lists.osdl.org
> Subject: Re: [Bridge] bridge+filter+failover+rules&state sync+traffic
> shaping
> 
> On Tue, 27 Jun 2006 16:11:01 +0200
> Tristan DEFERT <tristan.d <at> alphamosa.fr> wrote:
> 
> > hi list!
> > i'm trying to find a convenient way to build a redundant filtering
> > bridge under linux
> >
> > i looked at carp project, but carp doesn't support bridge
> >
> > now i thing the most appropriate way is using stp or rstp
> > it seems that 2.6 kernel supports stp but what about rstp?
> 
> The 2.6.18 kernel has hooks to allow building STP protocols in user
land.
> There is a student working on RSTP as a Google Summer of Code project.

Is there a customary wary of posting/watching status/progress on this
RSTP work? How is the work progressing? Any dates that can be shared?
(Continue reading)

Permalink | Reply | 2 comments |
headers
Stephen Hemminger | 8 Jul 2006 00:36
X-Face

Re: [BUG/PATCH/RFC] bridge: locally generated broadcast traffic may block sender

On Tue, 4 Jul 2006 17:48:42 +0200 (CEST)
"Bernd Kischnick" <kisch+linux <at> sesamstrasse.dyndns.tv> wrote:

> Hello Stephen,
> 
> I may have tracked down some unexpected behaviour from a common bridge
> setup, and would like to incite expert oppinion on my observations.
> The issue relates to both 2.6 and 2.4 kernel series bridging code,
> and as far as I can see might have been present in all releases hitherto.
> 
> Consider this setup:
> - two ethernet devices in a simple bridge configuration
> - bridge-interface configured for IPv4
> - local application multicasting heavy UDP traffic down the bridge
> - one of the ethernet links goes down (=> disconnect cable).
> 
> I would expect that IP-multicast/Ethernet-broadcast traffic is simply sent
> out of all the bridged interfaces still available and link-up.
> 
> Instead we observe that the result --- rather surprisingly --- depends on
> WHICH of the ethernet links is down.
> 
> One of the two ports doesn't cause troubles: the traffic flows out from
> that port which stays up, and the application doesn't mind.
> 
> But if you disconnect the OTHER link, then SOME traffic is still sent out of
> the port that stays up, but then the sending application is blocked in the
> sendto() call. Consequentially, the network traffic then ceases, even
> though one of the interfaces is still up and available.
> When the link comes up again, everything continues as normal.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tristan DEFERT | 8 Jul 2006 13:25
Picon

Re: bridge+filter+failover+rules&state sync+traffic shaping

I suggest that anyone interested in building a failover filtering bridge
with rules and connection state synching / QoS+TC to join me about
building this project: if we are enough with good skills we can do great
job.

What we have:
* STP protocol is already implemented
* Traffic shaping and QoS with iptables + cbq (or another traffic
shaper) should be fine in this context (needs to be tested)

What we need:
* an elegant way of synching rules and conntrack
* testers and volunteers !
* documentation

What should be nice:
* load balancing

Any idea or contributor welcome!

Feel free to contact me, and list me your resources & skills !

Le vendredi 07 juillet 2006 à 16:36 -0400, Shankar_Natarajan <at> emc.com a
écrit :
> 
> > -----Original Message-----
> > From: bridge-bounces <at> lists.osdl.org
> [mailto:bridge-bounces <at> lists.osdl.org]
> > On Behalf Of Stephen Hemminger
> > Sent: Friday, July 07, 2006 11:46 AM
(Continue reading)

Permalink | Reply | 1 comment |
headers
Gary W. Smith | 8 Jul 2006 18:10

Re: bridge+filter+failover+rules&state sync+traffic shaping

Tristan, 

I believe there have been a few threads in the netfilter list talking about connection synching between
cluster nodes.  I believe they have some scripts for this in the contrib directory on the distribution files.

We currently run a Linux-HA clustered bridge and it works great.  We aren't synching the connections at this
time though.  

Hope that helps, 

Gary 

> -----Original Message-----
> From: bridge-bounces <at> lists.osdl.org [mailto:bridge-bounces <at> lists.osdl.org]
> On Behalf Of Tristan DEFERT
> Sent: Saturday, July 08, 2006 4:25 AM
> Cc: bridge <at> lists.osdl.org
> Subject: Re: [Bridge] bridge+filter+failover+rules&state sync+traffic
> shaping
> 
> I suggest that anyone interested in building a failover filtering bridge
> with rules and connection state synching / QoS+TC to join me about
> building this project: if we are enough with good skills we can do great
> job.
> 
> What we have:
> * STP protocol is already implemented
> * Traffic shaping and QoS with iptables + cbq (or another traffic
> shaper) should be fine in this context (needs to be tested)
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
cyberfunk | 9 Jul 2006 05:52
Picon

Bridging two private lans w/ PPP and brtcl

Hi all, I'm trying to do the following (ASCII art diagram viewable in
fixed-width font at end of message):

Take 2 private LANs, seperated by the internet, and bridge them by
creating a bridge from 2 ethernet devices and a ppp interface tunneled
over ssh between the two linux boxes concerned.

The setup on each of the two networks is nearly identical, and is as follows:

The network has it's own router (cable modem) that serves as the local
gateway for the network to the internet.  We dont care about this
except that it provides us a path to the internet through which to
tunnel ppp.

The internet connection is distributed by NAT forwarding, facilitated by
a hub/switch in between the router and the end users.  There are 2
types of end users; "regular" which are not part of the bridged
network, and "bridged" whose ethernet frames are to be forwarded back
and forth over the ssh tunneled ppp connection.  The "regular" users
are connected directly to the same hub as the router.  The "bridged"
users are connected to the Linux box.

Each linux box has 2 ethernet interfaces, eth0 and eth1; eth0 is the
"bridged" users side, and anything connected to this side will have
it's packets bridged through the ppp connection, over the internet,
and to the other bridged users, and vice versa.  eth1 connects the
linux box to the rest of the local network.  Note: it is important for
the "bridged" users on each local network to see the "regular" users
on their same network, but NOT the "regular" users of the OTHER
network.  Therefore, the solution that occurred to me was the
(Continue reading)

Permalink | Reply | 1 comment |

Gmane